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

On Sat, 20 Dec 2003, Randy Presuhn wrote:
[ ... description of development history deleted ... ]
> 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.

Agree.

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

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

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

Agree emphatically.

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

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:
> 
> > -- { docsDevFilterPolicyEntry 3} Skipped
> > -- { docsDevFilterPolicyEntry 4 } Skipped

Sounds good to me.

//cmh