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

From: [email-masked]
Date: Fri, 20 Jun 2003 14:29:40 -0400

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 document defines a portion of the Management Information Base
(MIB) for use with network management protocols in the Internet
community.  In particular, it describes managed objects related to
the forwarding of Internet Protocol (IP) packets, in an IP version
independent manner.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipv6-rfc2096-update-03.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ipv6-rfc2096-update-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ipv6-rfc2096-update-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "C. M. Heard" <[email-masked]>
Date: Tue, 24 Jun 2003 12:21:53 -0700 (PDT)

On Fri, 20 Jun 2003 [email-masked] 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.
> 

Greetings,

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

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
     DESCRIPTION
            "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 }

to:

 inetCidrRouteDiscards OBJECT-TYPE
     SYNTAX     Counter32
     MAX-ACCESS read-only
     STATUS     current
     DESCRIPTION
            "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
     DESCRIPTION
            "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> 
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
detailed).

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
http://www.ietf.org/IESG/STATEMENTS/MIB-COPYRIGHT.txt.

(b) Please change the 2nd REVISION/DESCRIPTION pair
from:
        REVISION      "200301130000Z"
        DESCRIPTION
               "Revised to support CIDR routes."
to:
        REVISION      "199609190000Z"
        DESCRIPTION
               "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"
        DESCRIPTION
               "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 [email-masked]
--------------------------------------------------------------------

---

From: Brian Haberman <[email-masked]>
Date: Thu, 26 Jun 2003 08:35:29 -0400

Mike,
      Thanks for the comments.  I have a few follow-ups in-line...

> to make it perfectly clear exactly what is being counted.

I agree with the proposed text.  In addition, I will add some
description to Section 4 describing the relationship between
this object and the deprecated object in the 2011 update.

> note that there was agreement on this point in the e-mail that I

I agree.  I will re-instate inetCidrRouteNumber.

> Please add these documents to the list of normative references.

Will do.

> that are being obsoleted.)

OK.

> the same in the RFC and the final draft.

Yep.

> to the most recent REVISION clause if the latter were a bit more

I will update the REVISION clause with text pointing out the
added objects (e.g. inetCidrRouteDiscards), the overall goal
of making the MIB IP version independent, and adding the read-only
conformance.

> http://www.ietf.org/IESG/STATEMENTS/MIB-COPYRIGHT.txt.

No problem.

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

OK.

>                "Initial version, published as RFC 1354."

OK.

> raised previously that were not yet dealt with.

Thanks for the review, Mike.

Regards,
Brian