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

From: Bill Fenner <[email-masked]>
Date: Mon, 14 Dec 2015 15:20:59 -0500

On Sat, Dec 5, 2015 at 10:01 PM, C. M. Heard <[email-masked]> 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

---

From: "C. M. Heard" <[email-masked]>
Date: Tue, 22 Dec 2015 09:07:57 -0800

> uninteresting collection of document diffs.

Thank you, that was very helpful.

> IMO, a complete review from a MIB doctor is not worth the time for this

I agree with this - a MIB doctor review is to cover legality of the changes
is appropriate, but we are not looking to criticize the existing MIB module
designs.

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

 I believe that the concept is sound.

> materials I linked to above will help to review the implementation.

The materials were helpful, but I went ahead and and extracted the the
updated modules from draft-ietf-6man-ipv6-mibs-obsolete-00.txt and ran the
tool smidiff (part of the libsmi suite) to check what had changed between
the modules in the libsmi archive and the updated modules (note: the libsmi
distribution, which includes smidiff and the extracted MIB modules, is
available for download at http://www.ibr.cs.tu-bs.de/projects/libsmi/).
Here are my findings:

1.) The tool found only one erroneous change: the date in the oldest
REVISION clause of IPV6-MIB was incorrectly transcribed from RFC 2465.
Suggested fix:

OLD
     REVISION "9801082155Z"
     DESCRIPTION
       "First revision, published as RFC2465"
NEW
     REVISION "9802052155Z"
     DESCRIPTION
       "First revision, published as RFC2465"
END

2.) The original IPV6-MIB had an instance of illegal sub-typing in a
SEQUENCE definition for a table.  That error was corrected in the libsmi
distribution in order to prevent compilation errors.  Since the purpose of
this draft is to provide updated modules for repositories, where clean
compilation is necessary or at least highly desirable, I would like to
suggest that this fix be incorporated into the draft, even though it is not
strictly within the original scope of the project.  The fix would be:

OLD

 Ipv6AddrPrefixEntry ::= SEQUENCE {
      ipv6AddrPrefix                     Ipv6AddressPrefix,
      ipv6AddrPrefixLength               INTEGER (0..128),
      ipv6AddrPrefixOnLinkFlag           TruthValue,
      ipv6AddrPrefixAutonomousFlag       TruthValue,
      ipv6AddrPrefixAdvPreferredLifetime Unsigned32,
      ipv6AddrPrefixAdvValidLifetime     Unsigned32
     }

NEW

 Ipv6AddrPrefixEntry ::= SEQUENCE {
      ipv6AddrPrefix                     Ipv6AddressPrefix,
      ipv6AddrPrefixLength               INTEGER,
      ipv6AddrPrefixOnLinkFlag           TruthValue,
      ipv6AddrPrefixAutonomousFlag       TruthValue,
      ipv6AddrPrefixAdvPreferredLifetime Unsigned32,
      ipv6AddrPrefixAdvValidLifetime     Unsigned32
     }

END

3.) The original IPV6-UDP-MIB also had an instance of illegal sub-typing,
the fix for which would be:

OLD

 Ipv6UdpEntry ::= SEQUENCE {
    ipv6UdpLocalAddress    Ipv6Address,
    ipv6UdpLocalPort       INTEGER (0..65535),
    ipv6UdpIfIndex         Ipv6IfIndexOrZero }

NEW

 Ipv6UdpEntry ::= SEQUENCE {
    ipv6UdpLocalAddress    Ipv6Address,
    ipv6UdpLocalPort       INTEGER,
    ipv6UdpIfIndex         Ipv6IfIndexOrZero }

END

4.) The original IPV6-TCP-MIB had two instances of illegal sub-typing, both
in the same SEQUENCE; the fix would be:

OLD

 Ipv6TcpConnEntry ::=
    SEQUENCE { ipv6TcpConnLocalAddress    Ipv6Address,
               ipv6TcpConnLocalPort       INTEGER (0..65535),
               ipv6TcpConnRemAddress      Ipv6Address,
               ipv6TcpConnRemPort         INTEGER (0..65535),
               ipv6TcpConnIfIndex         Ipv6IfIndexOrZero,
               ipv6TcpConnState           INTEGER }

NEW

 Ipv6TcpConnEntry ::=
    SEQUENCE { ipv6TcpConnLocalAddress    Ipv6Address,
               ipv6TcpConnLocalPort       INTEGER,
               ipv6TcpConnRemAddress      Ipv6Address,
               ipv6TcpConnRemPort         INTEGER,
               ipv6TcpConnIfIndex         Ipv6IfIndexOrZero,
               ipv6TcpConnState           INTEGER }

END

I think #1 above is self-explanatory, and I don't expect controversy that
it is a "must fix".

Regarding #2, #3, and #4, see the next-to-last paragraph of RFC 2578
section 7.1.12, and in particular the text right at the top of page 26.  I
am aware that correcting errors in the old modules was not within the
original scope of the draft, and there is certainly little incentive to put
effort into improving modules that are obsolete.  On the other hand, the
fixes are simple, and will probably need to be made anyway by those who
incorporate the updated modules into their repositories.  Given the minimal
level of effort involved, I would rate them as "should fix".  Back when I
served as a MIB doctor, we would normally request fixes for such errors
when modules were being updated.

In addition to looking at the output of the tools, I also checked that
every STATUS clause value was indeed changed to "obsolete" (they were), and
I spot-checked the updates to the DESCRIPTION clauses.  All the DESCRIPTION
clauses I looked at appeared to be right.  The author obviously put a lot
of work into that, for which he deserves our thanks.  I am sorry that I
don't have time to review every one in detail.

After correction of issue #1 (and optionally #2, #3, and #4), I think this
document will be ready to submit for publication.

ASIDE: while doing the review, I noted that IPV6-MLD-MIB (RFC 3019)
and IGMP-STD-MIB
(RFC 2933) have both been obsoleted by MGMD-STD-MIB (RFC 5519) and might be
good candidates for a similar project.

Mike Heard