Subject: Some comments on draft-ietf-ipv6-rfc2096-update-04.txt

From: "C. M. Heard" <[email-masked]>
Date: Sat, 5 Jul 2003 23:46:00 -0700 (PDT)

Greetings,

I notice that Brian Haberman incorporated the changes I suggested
for the -03 draft.  However, there is an editing error in the
incorporation of the MIB copyright and there are some things in the
MIB that were revealed by running the MIB through smilint and by
checking against the other stuff in the MIB review checklist in
<draft-ietf-ops-mib-review-guidelines-01.txt>.

First the editing error:  the following part of the MODULE-IDENTITY
invocation

    DESCRIPTION
           "The MIB module for the management of CIDR multipath IP
            Routes."
    REVISION      "200306270800Z"
    DESCRIPTION
           "IPv4/v6 version-independent revision.  Minimal changes
            were made to the original RFC 2096 MIB, to allow easy
            upgrade of existing IPv4 implementations to the
            version-independent MIB.  These changes include:

            Adding inetCidrRouteDiscards as a replacement for the
            deprecated ipRoutingDiscards and ipv6DiscardedRoutes
            objects.

            Adding a new conformance statement to support the
            implementation of the IP Forwarding MIB in a
            read-only mode.

            Copyright (C) The Internet Society (2003). This version
            Of this MIB module is part of RFC xxxx; see the RFC
            itself for full legal notices.

            published as RFC xxxx."

should actually read:

    DESCRIPTION
           "The MIB module for the management of CIDR multipath IP
            Routes.

            Copyright (C) The Internet Society (2003). This version
            Of this MIB module is part of RFC xxxx; see the RFC
            itself for full legal notices."
    -- RFC Ed.: replace xxxx with actual RFC number & remove this note
    REVISION      "200306270800Z"
    DESCRIPTION
           "IPv4/v6 version-independent revision.  Minimal changes
            were made to the original RFC 2096 MIB, to allow easy
            upgrade of existing IPv4 implementations to the
            version-independent MIB.  These changes include:

            Adding inetCidrRouteDiscards as a replacement for the
            deprecated ipRoutingDiscards and ipv6DiscardedRoutes
            objects.

            Adding a new conformance statement to support the
            implementation of the IP Forwarding MIB in a
            read-only mode.

            Published as RFC xxxx."
    -- RFC Ed.: replace xxxx with actual RFC number & remove this note

i.e., the copyright notice goes in the main DESCRIPTION clause, and
"published as" should be "Published as" (the RFC Editor notes are
optional but are recommended).

Next, the smilint messages:

IP-FORWARD-MIB:1048: [4] {hyphen-in-label} named number `is-is' must
not include a hyphen in SMIv2
IP-FORWARD-MIB:1049: [4] {hyphen-in-label} named number `es-is' must
not include a hyphen in SMIv2
IP-FORWARD-MIB:186: [6] {index-element-no-size} index element
`inetCidrRoutePolicy' of row `inetCidrRouteEntry' should but cannot
have a size restriction
IP-FORWARD-MIB:106: [5] {index-exceeds-too-large} index of row
`inetCidrRouteEntry' can exceed OID size limit by 89
subidentifier(s)
IP-FORWARD-MIB:509: [5] {index-element-accessible} index element
`ipCidrRouteDest' of row `ipCidrRouteEntry' should be not-accessible
in SMIv2 MIB
IP-FORWARD-MIB:509: [5] {index-element-accessible} index element
`ipCidrRouteMask' of row `ipCidrRouteEntry' should be not-accessible
in SMIv2 MIB
IP-FORWARD-MIB:509: [5] {index-element-accessible} index element
`ipCidrRouteTos' of row `ipCidrRouteEntry' should be not-accessible
in SMIv2 MIB
IP-FORWARD-MIB:509: [5] {index-element-accessible} index element
`ipCidrRouteNextHop' of row `ipCidrRouteEntry' should be
not-accessible in SMIv2 MIB
IP-FORWARD-MIB:865: [5] {index-element-accessible} index element
`ipForwardDest' of row `ipForwardEntry' should be not-accessible in
SMIv2 MIB
IP-FORWARD-MIB:865: [5] {index-element-accessible} index element
`ipForwardProto' of row `ipForwardEntry' should be not-accessible in
SMIv2 MIB
IP-FORWARD-MIB:865: [5] {index-element-accessible} index element
`ipForwardPolicy' of row `ipForwardEntry' should be not-accessible
in SMIv2 MIB
IP-FORWARD-MIB:865: [5] {index-element-accessible} index element
`ipForwardNextHop' of row `ipForwardEntry' should be not-accessible
in SMIv2 MIB
IP-FORWARD-MIB:70: [4] {group-membership} node `inetCidrRouteNumber'
must be contained in at least one conformance group

Most of these diagnostics are from the deprecated parts of the MIB module
and can be safely ignored;  the three at lines 70, 106, and 186, however,
are in the current part of the MIB module and some corrective action is
either required or recommended.

The message at line 70, viz., "`inetCidrRouteNumber' must be
contained in at least one conformance group", indicates an
error that MUST be corrected.  The correction is simple: add
`inetCidrRouteNumber' to the object group
`inetForwardCidrRouteGroup'.

The messages at lines 186 and 106, i.e., "index element
`inetCidrRoutePolicy' of row `inetCidrRouteEntry' should but cannot
have a size restriction" and "index of row `inetCidrRouteEntry' can
exceed OID size limit by 89 subidentifier(s)" point out that (i) it
is theoretically possible for the OIDs of column instances to exceed
128 octets and (ii) it is not possible for SIZE constraints to fix
that problem.  So, it is suggested to drop the index object SIZE
constraints and instead document the constraints that must be obeyed
in the inetCidrRouteEntry DESCRIPTION clause (see section 4.6.5 of
<draft-ietf-ops-mib-review-guidelines-01.txt>).  Specifically, this
means:

Change the SYNTAX values of inetCidrRouteDest and
inetCidrRouteNextHop from

               InetAddress (SIZE(0..36))
to
               InetAddress

and change the DESCRIPTION clause of inetCidrRouteEntry from

           "A particular route to a particular destination, under a
            particular policy.

            Dynamically created rows will survive an agent reboot."

to

           "A particular route to a particular destination, under a
            particular policy.

            Dynamically created rows will survive an agent reboot.

            Implementors need to be aware that if the total number
            of elements (octets or sub-identifiers) in
            of inetCidrRouteDest, inetCidrRoutePolicy, and
            inetCidrRouteNextHop exceeds 111 then OIDs of column
            instances in this table will have more than 128 sub-
            identifiers and cannot be accessed using SNMPv1, SNMPv2c,
            or SNMPv3."

Note that <draft-ietf-ops-rfc3291bis-01.txt> drops the requirement
for index objects of type InetAddress to have a SIZE clause and
allows the constraints to be documented in a DESCRIPTION clause as
recommended above.

I've also made the time to go back through the MIB review checklist
(Appendix A of <draft-ietf-ops-mib-review-guidelines-01.txt>) and
this is what I found:

1.) I-D Boilerplate -- OK

2.) Abstract -- I suggest changing the second sentence
from:
    In particular, it describes managed objects related to
    the forwarding of Internet Protocol (IP) packets, in an
    IP version independent manner.
to:
    In particular, it describes managed objects related to
    the forwarding of Internet Protocol (IP) packets in an
    IP version-independent manner.

(If the editor agrees with both of the above changes, then
the edit s/version independent/version-independent/ should
be applied globally.)

3.) MIB Boilerplate -- OK

4.) IPR Notices -- the notices required by RFC 2026
sections 10.4 (A) and (B) are missing;  please add a
section entitled "Intellectual Property" containing
these notices.  Also, check the IPR disclosures on
the IETF web site;  if any apply, please also include
the notice from RFC 2026 10.4(D).

5.) References -- [RFC2026] is not cited in the text and
does not seem to be needed.  (It is mentioned in the I-D
boilerplate, but that will go away upon publication.)
Also, RFC 3291 is slated to be replaced by
<draft-ietf-ops-rfc3291bis-01.txt>, and it would therefore
be wise to add an RFC Editor note requesting that the
reference (and citations in the text) be updated if
RFC3291bis is published before or at the same time as
this document.

6.) Security Considerations Section -- excellent, statements
of vulnerabilities are well though out.

7.) IANA Considerations Section -- OK (none present and
none required).

8.) Copyrights -- see above for MIB module copyright notice;
others are OK.

9.) MIB compilation -- see above for smilint report.  The
smidiff report, excluding diagnostics that are merely
informational, is as follows:

IP-FORWARD-MIB:943 [3] {to-implicit} implicit type for
`ipForwardPolicy' replaces type `Integer32'
IP-FORWARD-MIB:943 [3] {range-added} range `(0..2147483647)' added
to type used in `ipForwardPolicy'
IP-FORWARD-MIB:586 [3] {to-implicit} implicit type for
`ipCidrRouteTos' replaces type `Integer32'
IP-FORWARD-MIB:586 [3] {range-added} range `(0..2147483647)' added
to type used in `ipCidrRouteTos'

The objects in question are index objects that were originally not
explicitly constrained to have non-negative values;  however, this
constraint is implicit, since index objects cannot be negative.
Thus, these changes do not change the semantics and so are
considered editorial (see <draft-ietf-ops-mib-review-guidelines-01.txt>
section 4.9).  In other words, there is no problem.

10.) Other issues -- (a) I notice that the "Editor's Contact
Information" section has contact information for only one
of the editors listed on the front page.  It should probably
contain information for both editors (as does the CONTACT-INFO
clause) and if it does, it should be be re-titled
"Editors' Contact Information" or "Editors' Addresses";  or,
alternatively, only the one editor should appear on the
front page and CONTACT-INFO section.  Check with the RFC
Editor to make sure of this.  (b) I notice mixed tenses in
Section 6, Changes from RFC 2096.  Either s/Utilized/Utilizes/
or s/Creates/Created/.

11.) Technical content -- no issues noted other than those
already mentioned.

I probably should have caught most of these things in my previous
review of the document, and I apologize for not having done so.
I hope that it will not annoy the editors and WG too much to hear
of them now.

Thanks and regards,

Mike Heard

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------