Thanks for the MIB doctor review Mike. And thanks to the authors/editors to get this in good shape. Sounds like we're getting real close to IETF Last Call ??
Thanks, Bert > -----Original Message----- > From: C. M. Heard [mailto:[EMAIL PROTECTED] > Sent: zaterdag 30 augustus 2003 19:06 > To: IPv6 Mailing List > Cc: Bert Wijnen > Subject: MIB doctor review of: draft-ietf-ipv6-rfc2096-update-05.txt > > > Greetings, > > I have reviewed draft-ietf-ipv6-rfc2096-update-05.txt, and I believe > that the document is now ready to proceed to IETF last call. In > particular, I have verified that all requested changes have been > made (both the ones discussed in the presentation slides for the > Vienna IETF and the ones recommended in previous reviews), and I > have gone back through the MIB review checklist (Appendix A of > <draft-ietf-ops-mib-review-guidelines-02.txt>) to make sure that no > new problems have been introduced. Here are the checklist results: > > 1.) I-D Boilerplate -- OK > > 2.) Abstract -- OK > > 3.) MIB Boilerplate -- OK > > 4.) IPR Notices -- OK > > 5.) References -- OK > > 6.) Security Considerations Section -- excellent, statements > of vulnerabilities are well though out. > > 7.) IANA Considerations Section -- OK (none present and > none required). > > 8.) Copyrights -- OK > > 9.) Other issues (i.e., stuff in http://www.ietf.org/ID-nits.html > other than MIB compilation issues) -- OK > > 10.) Technical content -- the MIB design appears to be sound, and > the MIB compilation results from smilint and smidiff appear to be > satisfactory. The results from smilint are as follows: > > This command (smilint 0.4.2-pre1, as of Tue Aug 05 15:58:53 2003) > has been processed to get the following results: > smilint -m -s -l 6 rfc2096-update-05.mi2 > > rfc2096-update-05.mi2:1060: [4] {hyphen-in-label} warning: named > number `is-is' must not include a hyphen in SMIv2 > rfc2096-update-05.mi2:1061: [4] {hyphen-in-label} warning: named > number `es-is' must not include a hyphen in SMIv2 > rfc2096-update-05.mi2:203: [5] {index-element-no-size} warning: > index element `inetCidrRoutePolicy' of row `inetCidrRouteEntry' > should but cannot have a size restriction > rfc2096-update-05.mi2:115: [5] {index-exceeds-too-large} warning: > index of row `inetCidrRouteEntry' can exceed OID size limit by 527 > subidentifier(s) > rfc2096-update-05.mi2:517: [5] {index-element-accessible} warning: > index element `ipCidrRouteDest' of row `ipCidrRouteEntry' should be > not-accessible in SMIv2 MIB > rfc2096-update-05.mi2:517: [5] {index-element-accessible} warning: > index element `ipCidrRouteMask' of row `ipCidrRouteEntry' should be > not-accessible in SMIv2 MIB > rfc2096-update-05.mi2:517: [5] {index-element-accessible} warning: > index element `ipCidrRouteTos' of row `ipCidrRouteEntry' should be > not-accessible in SMIv2 MIB > rfc2096-update-05.mi2:517: [5] {index-element-accessible} warning: > index element `ipCidrRouteNextHop' of row `ipCidrRouteEntry' should > be not-accessible in SMIv2 MIB > rfc2096-update-05.mi2:875: [5] {index-element-accessible} warning: > index element `ipForwardDest' of row `ipForwardEntry' should be > not-accessible in SMIv2 MIB > rfc2096-update-05.mi2:875: [5] {index-element-accessible} warning: > index element `ipForwardProto' of row `ipForwardEntry' should be > not-accessible in SMIv2 MIB > rfc2096-update-05.mi2:875: [5] {index-element-accessible} warning: > index element `ipForwardPolicy' of row `ipForwardEntry' should be > not-accessible in SMIv2 MIB > rfc2096-update-05.mi2:875: [5] {index-element-accessible} warning: > index element `ipForwardNextHop' of row `ipForwardEntry' should be > not-accessible in SMIv2 MIB > > Most of these diagnostics are from the deprecated parts of the MIB > module and can be safely ignored. The ones that pertain to the new > parts of the MIB modue are those for lines 115 and 203. The former > warns that it is theoretically possible for the OIDs of column > instances in inetCidrRouteEntry to exceed the 128 sub-identifier > limit imposed by the SMI and the SNMP by as many as 527 > subidentifiers. This is dealt with by the warning to implementors > in the inetCidrRouteEntry DESCRIPTION clause that the aggregate size > of the index components inetCidrRouteDest, inetCidrRoutePolicy, and > inetCidrRouteNextHop must not exceed 111 components. The diagnostic > for line 203 is just a warning that the object identifier-valued > index column inetCidrRoutePolicy does not have a SIZE constraint. > Since the SMI does not allow such constraints, this warning can and > should be ignored. In other words, there are no problems revealed > by the smilint report. > > The smidiff report, excluding diagnostics that are merely > informational, is as follows: > > rfc2096-update-05.mi2:953 [3] {to-implicit} implicit type for > `ipForwardPolicy' replaces type `Integer32' > rfc2096-update-05.mi2:953 [3] {range-added} range `(0..2147483647)' > added to type used in `ipForwardPolicy' > rfc2096-update-05.mi2:594 [3] {to-implicit} implicit type for > `ipCidrRouteTos' replaces type `Integer32' > rfc2096-update-05.mi2:594 [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. > Since these changes do not change the semantics they are considered > to be editorial (see <draft-ietf-ops-mib-review-guidelines-02.txt> > section 4.9). In other words, there is no problem. > > This concludes the review of draft-ietf-ipv6-rfc2096-update-05.txt. > > 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 PROTECTED] --------------------------------------------------------------------
