Re: MIB reviewer comments on draft-ietf-ipcdn-device-mibv2-06.txt

Hi -

> From: "Woundy, Richard" <[email protected]>
> To: "'Randy Presuhn'" <[email protected]>
> Cc: <[email protected]>
> Sent: Saturday, December 20, 2003 9:08 AM
> Subject: RE: [ipcdn] MIB reviewer comments on draft-ietf-ipcdn-device-mibv2-06.txt
>

> Randy,
>
> I am not the author of RFC 2669, where the two objects were defined but
> commented out. Here is what is in RFC 2669:
> -- docsDevFilterPolicyType ::= { docsDevFilterPolicyEntry 3} Removed
> -- docsDevFilterPolicyAction ::= { docsDevFilterPolicyEntry 4 } removed
>
> I was the author of this draft back in March 2001, when I originally added
> the "really bizarre group". I think I added it due to comments from a MIB
> doctor about how to handle these commented-out MIB objects, but I can't find
> those specific comments in my mail archives anymore. This was two employers
> and over 2 1/2 years ago.
>
> So what do you want me to do with respect to these commented-out objects
> from RFC 2669 in this internet-draft?
> 1. Leave the commented-out objects from RFC 2669 in the internet-draft
> as-is? (This option seemed to cause heartburn to a previous MIB doctor, at
> least.)
> 2. Delete the commented objects from the internet-draft? (This leaves an OID
> numbering hole in the internet-draft, with potentially no explanation.)
> 3. Use the "really bizarre group" to obsolete the non-existant objects, per
> the current internet-draft? (This explains that there are useless
> objects/OIDs from RFC 2669, but admittedly it is "bizarre".)
> 4. Do something else. (Tell me what.)
>
> This discussion is about never-implemented -- and never-will-be-implemented
> -- MIB objects. All I care about is consistent, rationale guidance.
...

Thanks for the clear description of the history.

Since the objects have never been implemented, and never will be
implemented, and never even appeared in an RFC, there is no value
in "preserving" the object identifiers.

The rules for extending tables (RFC 2578 section 10.7 (7)) would
put any new assignments at the end, so I don't see any way in
which those two object identifiers could ever be re-used,
since they're in the middle of the row.

The only question is what to do about the hole in the numbering.

I think creating bogus objects and a bogus group to explain the
numbering gap does not make sense.

I have seen tools that whine about numbering gaps, but I haven't
been able to find anything in the SMI or MIB review guidelines
that would suggest that gaps are actually a problem.  The current
texts in RFC 2669 and in draft-ietf-ipcdn-device-mibv2-06.txt
confused, rather than enlighted me.  The question at the bottom
of it all is this: how much of the pre-RFC history do you really
want/need to preserve here?  I think the least confusing solution
would be to simply say:

> -- { docsDevFilterPolicyEntry 3} Skipped
> -- { docsDevFilterPolicyEntry 4 } Skipped


I'm cc-ing the MIB review mailing list to give other MIB reviewers
opportunity to comment.  Perhaps someone else has a better
rationale for doing it one way or another, or can cite a recommendation
I've missed.

Randy