Re: AppleTalk MIB question

[RL Bob Morgan <[e-mail]>]

    If we should decide that an item in 1243 is bogus on closer inspection, 
    what can we do in Appletalk MIB II to correct the situation?  

I claim that the time to do this sort of thing to the current version of
AT-MIB-II is long past.  I would hope that in the interest of moving forward we
could let lie a sleeping dog like this one.  I'd hate to see contention over
this object hold AT-MIB-II up any more.  It can be reviewed again in as little
as six months after it becomes a Proposed Standard.  At that time arguments can
be made about (eg) the uselessness and overhead of objects.

    Can we at least indicate that the object is present only for backward 
    compatibility?  

The official term is "deprecated."  AT-MIB-II deprecates several objects from
RFC 1243.  This is an indication that management applications shouldn't use this
object any more.  But agent vendors still have to support it, at least to the
extent that they fear censure and retribution from outraged users of older
management apps.

    Can we state that an object can be optionally supported, or is it better to
just remove it?   

The rule is that groups can be optional as a whole, not individual objects.
Again, "deprecated" captures it.  After some long time as deprecated, objects
can be removed altogether.

    Or should we just let it go and always just return a value of 0?

If you've gotten away without implementing something up to now, then I suppose
the likelihood is that you'll continue to get away with it.  SNMPv2's
conformance statement gives you a formal way of stating your non-implementation
of an object, and you can editorialize all you want in the comments.

I suppose this discussion points out why it's important to be extremely critical
of proposed objects up front.  Once they're in a standard MIB then some agents
will implement them, and some management apps will use them, and even if they're
pretty pointless and most implementations (and users) ignore them it's more work
to take them out than to just leave them as is.

 - RL "Bob"