[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: snmpconf to-do deadline today

David Partain wrote:
> Hi Steve (and WG),
> Thank you for the mail with the issues.  I've added most of
> them to the todo list (although the "Issue" part is blank
> in some cases).  I do, though, want to ask some questions
> about some of the items.  It may be that I'm just thick,
> but I didn't get some of these and need your assistance.
> Sorry for the length of this mail...

Sorry I didn't add more detail. Much of this was cut-and-paste from my
own todo list and I didn't have time to elaborate on them.

> sw> 1. Add pmPolicyElementTypeFilter object to restrict a policy to run
> sw>    only on certain element types
> I recall that we spoke about this during meetings in
> Minneapolis.  For the benefit of those who weren't there,
> let me clarify what I believe this means.  Basically, we
> want to be able to limit a particular policy to running
> on elements of type "interface", or whatever it might be.
> This is specifically about efficiency.  Did I get it right?

Yes. I also had a couple of slides about this in Minneapolis.

> sw> 2. Change form of pmElementTypeRegOIDPrefix so that the OID is
> sw>    specified up to the table.entry part.
> I don't recall this discussion.  Can you help me to understand
> why we want to do this?

It simplifies the text and makes it easier to understand. Plus it
eliminates an algorithm that the manager would otherwise have to perform
to eliminate duplicate entries. This came out of an email-list
discussion in which we agreed that table.entry would be better.

> sw> 10. In snmp accessor functions, allow integer values to be specified
> sw>     in the form "descriptor(1)" so that the code can self-document
> sw>     enumeration values. The descriptor text is completely ignored by
> sw>     the function.
> sw>
> sw>     We could go further and define the integer coercion rules so that
> sw>         ToInteger("descriptor(1)") -- 1
> sw>     I still have a couple of unresolved issues here so I'm thinking a
> sw>     bit.
> I think this needs to be grounded in a WG discussion before this
> becomes part of the document.
> Many moons ago, we made a decision not to include the ability
> to use OBJECT DESCRIPTORs rather than OIDs for naming objects
> that we are manipulating.  We did this because we didn't
> want to force agent systems to have mappings between OIDs and
> OBJECT DESCRIPTORs.  This item is trying to get around some
> of the problem that we created by not having MIB information
> available in the agent system.
> I think that this suggestion is a beginning down that slippery
> slope.  Does the working group want to go there?

I don't think it goes down the slippery slope because it still doesn't
force the agent to have mappings between OIDs and descriptors.

All it says is that rather than writing:
	setvar("ifAdminStatus.$0", 2, Integer);
you could also express it as:
	setvar("ifAdminStatus.$0", "down(2)", Integer);

Characters before the parenthesis will be discarded and the number
inside the parenthesis will be used directly (i.e. with no mapping).

The first proposal is real easy to accept because it just involves
changes to the accessor functions.

The second proposal is a bit harder. First of all it isn't fully baked
yet because there are some unresolved issues (maybe unresolvable).
Second, we should be more careful with changes to the language than the
accessor functions and the second proposal is more like a change to the
language. I'm not going to push the second part until I resolve my own
issues with it.
> sw> 13. Add optional context/addressing arguments to roleMatch() and
> sw> capMatch()
> I specifically do not think we need to have it in capMatch.
> Any subordinate systems can register their capabilities in the
> capabilitiesOverrideTable, which will mean that a capMatch()
> will just work.  I don't think we should add addressing in
> capMatch.
> There is already an item on the list regarding "off-the-box"
> operations which I believe covers this issue.

The part where capMatch() "just works" is when you ask for a capability
in your own context.

But if I'm going to do on-the-box operations to management objects in
another context (on the same box), then capMatch() needs to know which
context that is. And if I'm doing off-box operations I need the address
as well.

> sw> 15. Bug: if/for/while must call ToBoolean on their expression
> Can you please expand on this?  Is the bug that they must or that
> they don't?

They don't currently, but they should.

> sw> 23. Fix race condition problem with codeTable
> sw>
> sw> 24. Receive/send traps/notifications?
> sw>
> sw> 25. Possibly change who points to who between policy table and code
> sw>     table.
> sw>
> sw> 28. Have policy re-execute on all elements if filter or action
> sw>     changes or if parameter is changed. Also clear the scratchpad for
> sw>     all PolicyElement or Policy execution contexts for this policy.
> sw>     If changing the code requires that I modify 6 code segments, take
> sw>     care to not re-execute 6 times.
> sw>
> sw> 29. Allow filters to do sets?
> sw>
> sw> 32. Potentially rename pmElementTypeRegName
> For these six, can you please explain what the issue is?

These descriptions are still pretty quick-and-dirty. I'll elaborate in
even more detail later as needed:

#23 is the security problem I mentioned in an email on 4/3 about Issue
#17, Security.

#24: should the accessor function library include functions to receive
traps and notifications and/or send traps and notifications?

#25: Upon further reflection, I'm withdrawing this one.

#28: If the filter code changes we need to discard all filter return
values for that policy because they might have changed due to the logic
changing (therefore we need to rerun the filter on all elements). If the
action changes we need to rerun the action because it might need to make
something different happen. We need to take care that if the manager is
making updates to more than one code segment, that we don't re-execute
on all elements for each segment that is updated. Maybe we take the
policy offline for a moment, update the segments, and then turn it back
online, and that's when it would update the filters/actions. Finally, if
code changes, the semantics of scratchpad variables might changed so
it's important to delete any existing scratchpad vars for that policy.

#29: I think the restriction that filters cannot do sets is unnecessary
and counterproductive. While it's certainly not the "role" of the filter
to do configuration (rather the filter's job is to make a decision).
sometimes, making a decision involves performing a set.

#32: pmElementTypeRegName: I don't want the reader to be confused that
this "Name" is used to identify or index the elementType, when it is
just meant to describe the element to humans. "Label", "Caption", or
"Description" would be more appropriate - probably "Description".

> sw> 30. Should setvar() return an error code?
> What do you have in mind?  Would it be something like
> error-status?


> sw> 31. Add function to retrieve the context/address of this execution
> sw>     context.
> I continue to hope that we can minimize complexity of the policy
> engine and fear the whole off-the-box thread.  Like the proxy
> part of SNMPv3, I believe the off-the-box portion of the PM
> Module work should be optional, since I don't believe most
> will use it that way.  On the other hand, that doesn't mean
> we shouldn't be rigorous in definition of how that works.

I agree with the optional part and that we should, as much as possible,
make it modular to make it simpler for non-mid-level-manager
implementations (I used to say proxy, but it is really mid-level-manager
or MLM).

I know it is attractive to lump all the off-the-box stuff into the same
category, but as I described in my two messages on 4/5, they are really
two different categories and it's worth getting to know the differences
between them. Figuring out whether optionality is appropriate here is an
example of that.

First, note that scripts routinely need to know their "address" (the
address of "this element", or $0, $1, ...) to do their work. This is
true whether they are being run locally or remotely. Similarly, a script
may need to know the context or network address of the element it is
running on, even if it is running locally. In other words, it might need
that information to accomplish its task and will need that information
regardless of whether it happens to be running on the same system as the
element or on a different system.

> How do you envision this function being useful?

How about the following repeater policy filter:

  // only run this script on the first repeater in a stack: "repeater1"
  if (elementContext() == "repeater1")
    return 1;
    return 0;

> sw> and Bert's markup of a printed copy of the PM MIB, in my
> sw> posession. I know we're not being that lawyerly about this but I just
> sw> want to make it "official".
> Thanks.  Can you perhaps enumerate what Bert's after?

As near as I can tell, Bert is pursuing a complex evil plan that will
ultimately result in the installation of aliens into key positions of
power throughout the globe.

Oops, that was a different document. Nevermind!

Actually, Bert's markup points out areas where terms are used
inconsistently, wording suggestions, logical inconsistencies and
syntactical improvements.  I haven't seen any yet that are controversial
enough to warrant discussion but I'll bring them up if they crop up.

> sw> BCP
> sw>
> sw> 1. Not sure if we want the PBCM acronym.

First I'm not sure that we need an acronym at all. But further, in what
way is the architecture focused on configuration? I think we've built a
policy-based management architecture and that was exactly what the
doctor ordered in order to make configuration management with SNMP more
practical. It's also useful for other things. So I'm not fond of the
acronym or the term.

> sw> 2. Suggest renaming "policy objects" to "provisioning objects".

I think that the objects in the HVAC MIB (as an example) don't have much
to do with policy but rather implement a MIB that allows for more
sensible provisioning practices. 

> sw> 3. HVAC MIB needs a name that can be used to easily find templates
> sw>    across agents.

I'll expand on this in another message.

> sw> 4. I think we need a number of changes to the model in Section 7
> sw>    and Section 8: need to decouple instance-independence
> sw>    from implementation/mechanism/domain-independence.  Further, use of
> sw>    the phrase "xxx-specific" is confusing WRT dependend/independent.
> sw>    Also make sure that implementation guidance is consistent with
> sw>    current state of PM MIB. Also need to come to further agreement
> sw>    on what is a mechanism-specific MIB.
> The taxonomy is already #1 under the BCP.  Please make a
> proposal for changes that we can talk about.