[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: I-D ACTION:draft-ietf-ipv6-rfc2096-update-03.txt

On Fri, 20 Jun 2003 Internet-Drafts@ietf.org wrote:
> A New Internet-Draft is available from the on-line
> Internet-Drafts directories. This draft is a work item of the IP
> Version 6 Working Group Working Group of the IETF.
> 	Title		: IP Forwarding Table MIB
> 	Author(s)	: M. Wasserman, B. Haberman
> 	Filename	: draft-ietf-ipv6-rfc2096-update-03.txt
> 	Pages		: 30
> 	Date		: 2003-6-20


This version addresses some, but not all, of the WG Last Call
comments that I made in the late January to early February time
frame, and I would like to discuss the comments that remain

1.) The rationale for adding inetCidrRouteDiscards (and deprecating
ipRoutingDiscards in 2011-update) is not documented.  While I don't
entirely agree with that decision, I can accept it based on the
following explanation from Bill Fenner:

>>>>> On Fri, 31 Jan 2003, Bill Fenner wrote:
Bill> The IP-MIB revision (draft-ietf-ipv6-rfc2011-update-01.txt)
Bill> deprecates ipRoutingDiscards and ipv6DiscardedRoutes in favor
Bill> of inetCidrRouteDiscards. The thought was that you can't tell
Bill> whether an ipRouteDiscards counts v4-only (as it would if a
Bill> system implemented RFC2011+2465) or both, so it's better to
Bill> define a new object with well defined semantics.  If we
Bill> decide that's not a good justification, we should remove
Bill> inetCidrRouteDiscards and un-deprecate ipRouteDiscards in
Bill> 2011-update.

Since the point has been controversial, I would like to suggest that
some text along these lines be added to the narrative part of the
document, perhaps in the required but as-yet unwritten "Changes from
RFC 2096" section (see item (6) below).  I would also like to
suggest that the object's DESCRIPTION clause be change from:

 inetCidrRouteDiscards OBJECT-TYPE
     SYNTAX     Counter32
     MAX-ACCESS read-only
     STATUS     current
            "The number of routing entries which were chosen to be
             discarded even though they are valid.  One possible
             reason for discarding such an entry could be to free-up
             buffer space for other routing entries."
     ::= { ipForward 8 }


 inetCidrRouteDiscards OBJECT-TYPE
     SYNTAX     Counter32
     MAX-ACCESS read-only
     STATUS     current
            "The number of entries in the inetCidrRouteTable which
             were chosen to be discarded even though they were valid.
             One possible reason for discarding such an entry could
             be to free up buffer space for other routing entries."
     ::= { ipForward 8 }

to make it perfectly clear exactly what is being counted.

2.) inetCidrRouteNumber has not been re-instated, but there are
still a number of references to it in the document.  Either it
should be re-instated with the following definition:

 inetCidrRouteNumber OBJECT-TYPE
     SYNTAX     Gauge32
     MAX-ACCESS read-only
     STATUS     current
            "The number of current inetCidrRouteTable entries that
             are not invalid."
 ::= { ipForward 6 }

or else the dangling references to it should be removed from Section
4 and from the DESCRIPTION clause of ipCidrRouteNumber. In the
latter case the OID assignments under ipForward should also be
reshuffled to avoid gaps in the assignments (e.g., by changing the
sub-ID assigned to inetCidrRouteDiscards to 6 from 8).

My very strong recommendation is to re-instate the object.  I'll
note that there was agreement on this point in the e-mail that I
quoted above:

>>>>> On Fri, 31 Jan 2003, Bill Fenner wrote:
Bill> I agree that there should be an inetCidrRouteNumber.

The reason for wanting a summary counter is because the potentially
huge size of the inetCidrRouteTable makes it inefficient (and
probably infeasible) for a manager to derive that information by
downloading the whole table.

The arguments quoted for its removal -- namely, that it may not
agree with the count of the in-view rows for some users and that it
may be difficuly for distributed agents to implement -- are, in my
opinion, irrelevant and unconvincing, respectively.  Focusing on the
latter, the distributed agent implementation problems are not
insurmountable, and in any case must be weighed against the problems
caused for managers.  And as Mike MacFaden has pointed out, agents
already have to solve that problem anyway for ipCidrRouteNumber --

>>>>> On Fri, 7 Feb 2003, Mike MacFaden wrote:
MM> Another thing not considered in Margaret's latest 2096
MM> replacement draft is that both rfc2096 and its successor are
MM> both active in the same agent at the same time.
MM> So I think ipCidrRouteNumber will apply
MM> to both the existing and replacement table regardless,
MM> it will just be a count of the ipv4 routes...

When this issue came up back in February there was a discussion on
the mreview mailing list, and contrary to some reports there is no
consensus among the MIB doctors that summary objects like these are
evil.  See the thread "ifNumber and its ilk considered harmful" at
this URL: http://ops.ietf.org/lists/mreview/mreview.2003#00159

The rest of what follows below are MIB doctor-type nits.

3.) Normative references for some MIB modules that appear in the
IMPORTS list are missing.  They are:

MIB module        document

IF-MIB            RFC 2863
IP-MIB            draft-ietf-ipv6-rfc2011-update-02.txt
IANA-RTPROTO-MIB  http://www.iana.org//assignments/ianaiprouteprotocol-mib

Please add these documents to the list of normative references.

4.) RFC 2096 appears as a normative reference.  That is
inappropriate because it is not needed to implement the spec.  All
it does is supply historical information, and so it should be turned
into an informative reference.  (Note also that standards-track
documents are not normally allowed to refer normatively to documents
at a lower maturity level -- and that certainly applies to documents
that are being obsoleted.)

5.) The material in Section 1 will need to be removed prior to
publication as an RFC.  It would probably be a good idea to an an
RFC Editor note to that effect.  It might also be a good idea to
make this an un-numbered section so that the section numbers stay
the same in the RFC and the final draft.

6.) When the document is published as an RFC, it should have a
change log detailing what was changed since RFC 2096 (it could point
to the most recent REVISION clause if the latter were a bit more

7.) Several changes are needed in the MODULE-IDENTITY invocation:

(a) Please add the standard MIB copyright notice to
the DESCRIPTION clause.  For details see Section 3.8
of <draft-ietf-ops-mib-review-guidelines-01.txt>, or

(b) Please change the 2nd REVISION/DESCRIPTION pair
        REVISION      "200301130000Z"
               "Revised to support CIDR routes."
        REVISION      "199609190000Z"
               "Revised to support CIDR routes.
                Published as RFC 2096."

i.e., please retain the original RFC 2096 rev date.

(c) Please add a 3rd REVISION/DESCRIPTION pair just
below that says:

        REVISION      "199207022156Z"
               "Initial version, published as RFC 1354."

Note that the UTC time is taken from the date stamp on
http://www.rfc-editor.org/rfc/rfc1354.txt ... the
original module is in SMIv1 and so have no such clause.

There may be more such stuff as I have not done a complete
MIB doctor review;  I've covered only those issues that I
raised previously that were not yet dealt with.

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 majordomo@sunroof.eng.sun.com