Re: 6MAN WG Last Call - draft-ietf-6man-ipv6-mibs-obsolete

[Bill Fenner <[e-mail]>]

On Sat, Dec 5, 2015 at 10:01 PM, C. M. Heard <[e-mail]> wrote:

> On 3 Dec 2015 19:08:02 -0300, Fernando Gont <fgont at si6networks.com>
> wrote:
> > On Dec 3, 2015, at 12:59 PM, Bob Hinden <bob.hinden at gmail.com> wrote:
> > > Hi,
> > >
> > > While the chairs think there is support for advancing this document,
> > > we only received one response so far to the w.g. last call for this
> > > document.
> > >
> > > We would like to ask for two reviewers who can review and comment
> > > on the document.  Please let us know.
>

The supporting materials that I used for correctness checking while I was
working on the document are available at
http://fenner.github.io/ipv6-mibs-historic/ .  This includes diffs of the
MIB contents (e.g., to make sure that all of the DESCRIPTIONs got
additional information about what the current object is) and a somewhat
uninteresting collection of document diffs.


> >
> > Just looking at the abstract and Intro (and not being a MIB person), my
> > question is: What's the reason for publishing this document as opposed
> > to just publish a short document that simply obsoletes:
> >    IP-MIB [RFC4293], UDP-MIB [RFC4113], TCP-MIB [RFC4022]
> >    and IP-FORWARD-MIB [RFC4292] modules ?
> >
> > Is it to obsolete only part of the contents, or what?
>
> Fernando: as stated in the text, but not in the abstract, the purpose is
> to update the MIB modules so that each object has a status of OBSOLETE.
> Since the document obsoletes the above-mentioned RFCS, the MIB
> modules it contains should replace the ones from those RFCs in MIB
> module repositories.  That will make the status of the old MIB modules
> clear by looking just at the repositories, without having to chase down
> the status of the RFCs.
>
> Chairs: I am a former MIB Doctor with limited time.  If you can wait until
> the end of the month, I am willing to do a complete review.
>

IMO, a complete review from a MIB doctor is not worth the time for this
document.  I think of this document as there being two things to review:

1. The concept: this is something we've never done before.  As such, we got
agreement from INT and OPS area directors before embarking down this path.
The problem that this document attempts to address is the availability of
modules like IPV6-MIB in MIB repositories like http://www.net-snmp.org/mibs/
with "STATUS current" for each object.  Nobody checks the RFC index for
obsoleted-by when they download a MIB module from such a repository.

2. The implementation: I started out hoping to take a shortcut and not
update the DESCRIPTION as required by RFC2578 section 10.2.(3), but then I
realized that was an inappropriate and unnecessary shortcut - it did not
take that long to update all of the DESCRIPTION clauses.  Hopefully the
materials I linked to above will help to review the implementation.

Thanks,
  Bill