Subject: RE: [ipcdn] MIB reviewer comments on draft-ietf-ipcdn-device-mibv 2-06.txt

From: "Woundy, Richard" <[email-masked]>
Date: Sat, 20 Dec 2003 12:08:46 -0500

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.

-- Rich

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Randy Presuhn
Sent: Friday, December 19, 2003 1:33 PM
To: [email-masked]
Subject: Re: [ipcdn] MIB reviewer comments on
draft-ietf-ipcdn-device-mibv2-06.txt

Hi -

> From: "Woundy, Richard" <[email-masked]>
> To: "'Randy Presuhn'" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Friday, December 19, 2003 5:18 AM
> Subject: RE: [ipcdn] MIB reviewer comments on
draft-ietf-ipcdn-device-mibv2-06.txt
...
> Those two MIB objects (docsDevFilterPolicyType, docsDevFilterPolicyAction)
> were defined in the original preparation of RFC 2669, but those MIB
objects
> were commented out prior to RFC publication. The purpose of this object
> group is to identify those MIB objects so that the OIDs would not
> accidentally be reassigned.

This seems really bizarre.  If they were taken out prior to publication,
then those object identifiers were never really assigned.

> If there is a better approach for the draft to take, let me know.
...

I'm still trying to figure out what the real objective was.

Randy

_______________________________________________
IPCDN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipcdn

_______________________________________________
IPCDN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipcdn

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 20 Dec 2003 12:45:30 -0800

Hi -

> Sent: Saturday, December 20, 2003 9:08 AM
> Subject: RE: [ipcdn] MIB reviewer comments on draft-ietf-ipcdn-device-mibv2-06.txt
>

...

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

---

From: "C. M. Heard" <[email-masked]>
Date: Sat, 20 Dec 2003 13:16:42 -0800 (PST)

On Sat, 20 Dec 2003, Randy Presuhn wrote:
[ ... description of development history deleted ... ]
> in "preserving" the object identifiers.

Agree.

> since they're in the middle of the row.

Agree here too (but the section reference should be 10.2(7))

> numbering gap does not make sense.

Agree emphatically.

> that would suggest that gaps are actually a problem.

That's true.  When I see gaps in a MIB module I am reviewing I
usually suggest to reassign the OIDs unless folks have a reason
not to, but I hasten to add that this is only a suggestion and
not a requirement of the SMIv2 documents or of the reviewer
guidelines.

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

Sounds good to me.

//cmh