Subject: RE: MIB doctor review of: draft-ietf-ipv6-rfc2096-update-05.txt

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Sat, 30 Aug 2003 19:24:53 +0200

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-masked]]
> 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-masked]
--------------------------------------------------------------------

---

From: Margaret Wasserman <[email-masked]>
Date: Sat, 30 Aug 2003 14:29:25 -0400

>Thanks for the MIB doctor review Mike.

Yes, thanks Mike for a very thorough job!

>good shape. Sounds like we're getting real close to

Yup.  Three of the IPv6 MIBs (TCP, IP and IP Forwarding) went
through another WG last call before Vienna with only a few
minor issues raised, and we are attempting to clean up those
issues quickly and get these MIBs to IETF last call ASAP.

The UDP MIB is running a bit behind the others, but we hope
to have a final WG last call for the UDP MIB soon.

Margaret