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

Re: snmpconf to-do deadline today



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...

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?

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?

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?

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.

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?

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?

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.

How do you envision this function being useful?

sw> Plus, treat as "on the table" stuff previously brought up by Wes, Bob,
sw> David, and Bert. For David and Bert I am referring to a private email
sw> from David

I have now forwarded that mail to the list so that everyone knows
what this is about.

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?

sw> BCP
sw> 
sw> 1. Not sure if we want the PBCM acronym.
sw> 
sw> 2. Suggest renaming "policy objects" to "provisioning objects".
sw>
sw> 3. HVAC MIB needs a name that can be used to easily find templates
sw>    across agents.

Perhaps you've sent something to the BCP authors explaining the
rationale for these suggestions.  Could you expound on the issues
that you aim to address with these three?

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.

Again, thanks very much for the list.

Cheers,

dlp