Mike,
Thanks for the comments. I have a few follow-ups in-line...
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.
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.
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:
I agree. I will re-instate inetCidrRouteNumber.
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.
Will do.
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.)
OK.
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.
Yep.
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).
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.
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.
No problem.
(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.
OK.
(c) Please add a 3rd REVISION/DESCRIPTION pair just below that says:
REVISION "199207022156Z" DESCRIPTION "Initial version, published as RFC 1354."
OK.
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 for the review, Mike.
Regards, Brian
-------------------------------------------------------------------- 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 PROTECTED] --------------------------------------------------------------------
