These are some general documentation/MIB Doctor comments on draft-ietf-ipv6-rfc2096-update-02.txt. They may well be incomplete, as I have not attempted to go through the entire MIB review checklist. Note that several substantive technical comments were posted in a previous message and are not duplicated here.
1.) It should be noted in the abstract that the document obsoletes RFC 2096. 2.) Please use the current mib boilerplate and references from http://www.ops.ietf.org/mib-boilerplate.html 3.) Please update the security considerations section per http://www.ops.ietf.org/mib-security.html 4.) Please split normative/informative references. I would suggest the [RFC2119] style instead of the numbered style, as it is easier both to read and to maintain. When you do this make sure that there is a normative reference for each MIB module that you IMPORT from (this is often overlooked). 5.) You have numbered a lot of sections that should not be numbered. See http://www.ietf.org/IESG/IDNITS.html or http://www.ietf.org/ID-nits.html (they are the same). 6.) When the document is published as an RFC, it should have a change log section detailing what was changed since RFC 2096 (it could point to the most recent REVISION clause if the latter were a bit more detailed). On the other hand, the changes between I-D versions should not appear. 7.) Please remove Unsigned32 from the IMPORTS list since it is not used. 8.) Please update the LAST-UPDATED and most recent REVISION clauses to the current date. 9.) Please use 4-digit year format in all older REVISION clauses, and mention the RFC in which the revision appeared. You should probably add a REVISION clause corresponding to the RFC 1354 version (it introduced the now-obsolete ipForwardTable). 10.) Please add a copyright notice to the MODULE-IDENTITY DESCRIPTION clause, as mandated by http://www.ietf.org/IESG/STATEMENTS/MIB-COPYRIGHT.txt, and update _all) copyright dates to the current year (the one on the front page still says 2001). 11.) I notice that ranges have been added to ipForwardPolicy and ipCidrRouteTos index variables to ensure that they are non-negative. That's not actually required by the SMI, and, strictly speaking, it is not a legal revision. It is probably acceptable since it cannot possibly change anything on the wire, but another solution would be to leave these as-is and turn off the the strict checking in your SMICng include file (#removeOpt "B"). 12.) Please do not use numbered references in the body of the MIB module (such as the ones in the DESCRIPTION clauses of inetCidrRouteDestType, inetCidrRouteDscp, and inetCidrRouteNextHopType). These turn into "dangling pointers" when the MIB module is extracted from the RFC (as it always will be when it is used). 13.) The row object inetCidrRouteEntry admits dynamic creation of instances but contains neither a StorageType column nor a statement in its DESCRIPTION clause as to the fate of rows created by management applications upon an agent re-initialization. You must provide one or the other; in this case a statement in the DESCRIPTION clause that dynamically created rows survive an agent reboot is probably what you want. 14.) The DESCRIPTION clause for the status column inetCidrRouteStatus does not say whether or not read-create rows can be modified when the status value is active(1). This is required by RFC 2579 (see the DESCRIPTION clause of the RowStatus TC). If the rules vary from one column to another, you should specify in each read-create column's DESCRIPTION clause whether or not it can be modified when the status is active(1), and the inetCidrRouteStatus DESCRIPTION clause should say that each read-create column's DESCRIPTION clause states whether or not that column may be modified while the status is active(1). //cmh -------------------------------------------------------------------- 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] --------------------------------------------------------------------
