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

Re: snmpconf to-do deadline today

David, rather than have a long message, I have included only the points
that I have specific comments about:

> 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 have to agree. I was wanted to have OBJECT DESCRIPTORs but apparently
did not argue effectivly. My desire is to either really add them and get
value or not at all. I would not favor a half measure.

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

Very much agree. See additional comment below.

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

I like the optional proposal because I also do not think it will be used
much this way and that it will take a lot of time and make things more
complex. I would only want to undertake the work after the other items
have been completed on our to do list.


Jon Saperia		     saperia@jdscons.com
			     Phone: 617-744-1079
			     Fax:   617-249-0874