[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> 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
> 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 email@example.com