I'm ambivalent about the addition of a constraint. I agree with Mike that if we keep a constraint switching it to 2040 would fit in better with the rest of the inet address constructs.
regards, Shawn >-----Original Message----- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >Behalf Of Brian >Haberman >Sent: Sunday, February 01, 2004 11:03 AM >To: C. M. Heard >Cc: [EMAIL PROTECTED]; Wijnen, Bert (Bert) >Subject: Re: I-D ACTION:draft-ietf-ipv6-rfc2096-update-06.txt > > >Mike, > >C. M. Heard wrote: >> On Fri, 30 Jan 2004 [EMAIL PROTECTED] 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. >>> >>> Title : IP Forwarding Table MIB >>> Author(s) : M. Wasserman, B. Haberman >>> Filename : draft-ietf-ipv6-rfc2096-update-06.txt >>> Pages : 36 >>> Date : 2004-1-29 >> >> >> Brian, >> >> The following change from the previous version caught my attention: >> >> 28 Jan 2004 Added range of (0..128) to inetCidrRoutePfxLen >> >> The corresponding object definition now reads: >> >> inetCidrRoutePfxLen OBJECT-TYPE >> SYNTAX InetAddressPrefixLength (0..128) >> MAX-ACCESS not-accessible >> STATUS current >> DESCRIPTION >> "Indicates the number of leading one bits which form the >> mask to be logical-ANDed with the destination address >> before being compared to the value in the >> inetCidrRouteDest field. >> >> The values for the index objects inetCidrRouteDest and >> inetCidrRoutePfxLen must be consistent. When the value >> of inetCidrRouteDest is x, then the bitwise logical-AND >> of x with the value of the mask formed from the >> corresponding index object inetCidrRoutePfxLen MUST be >> equal to x. If not, then the index pair is not >> consistent and an inconsistentName error must be >> returned on SET or CREATE requests." >> ::= { inetCidrRouteEntry 3 } >> >> There are two things (IMHO) that are wrong with this definition: >> >> 1.) RFC 3291 and its successor draft-ietf-ops-rfc3291bis-03.txt >> both go to great lengths to tell MIB authors not to sub-type >> InetAddressType and InetAddress objects: >> >> The InetAddressType and InetAddress objects SHOULD NOT be >sub-typed >> in object definitions. Sub-typing binds the MIB module to specific >> address formats, which may cause serious problems if new address >> formats need to be introduced. Note that it is possible to write >> compliance statements in order to express that only a >subset of the >> defined address types must be implemented to be compliant. >> >> Since the same kinds of problems can be introduces by sub-typing >> InetAddressPrefixLength, it seems to me that if we are consistent in >> our usage we should not sub-type InetAddressPrefixLength objects, >> either. I've raised this issue on the mreview (Mib Doctors) mailing >> list; archives are at http://ops.ietf.org/lists/mreview/ for those >> who wish to review the discussion. >> >> If the reason why inetCidrRoutePfxLen got a range restriction was to >> silence warning from SNICng or some other MIB compiler then a better >> solution would be to use the range (0..2040), which will accomodate >> an address length up to 255 octets. Since InetAddress objects >> already have a size restriction of 255 octets, this does not impose >> any additional arbitrary limitations other than those already >> imposed by the InetAddress TC itself. Another possibility, of >> course, is to remove the range restriction, since it is not required >> by the SMI (in this case compiler warning != illegal practice). >> > >The range was added based on a comment from Bert. I similar change >was made in the IP MIB update (2011bis). I believe the comment I >saw was that adding a range to the prefix length was not a big deal >since the addition of another address type would require other >changes in the mib. > >My preference is to leave it unrestricted (i.e. no range), but I could >argue it either way. > >I would like to hear others' comments on this issue since both 2011bis >and 2096bis are very close to being done. > >> 2.) The following problem is one that neither I (nor, apparently, >> any other reviewers) noticed up to now: inetCidrRoutePfxLen allows >> the value zero, but the object definition does not specify what the >> value zero means. Note that RFC 3291 requires that if the value >> zero is allowed, then its meaning must be specified in the object >> definition: >> >> The value zero is object-specific and must be defined as >> part of the description of any object which uses this >> syntax. Examples of the usage of zero might include >> situations where the Internet network address prefix >> is unknown or does not apply. >> >> To me, the meaning when inetCidrRoutePfxLen is set to zero >is clear: >> the corresponding row represents a default route. But that might >> not be true for everyone, and it would be good to spell this out in >> the DESCRIPTION clause, as RFC 3291 requires. > >I can add text to the DESCRIPTION that states that the value 0 >indicates >a default route. > >Thanks, >Brian > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >[EMAIL PROTECTED] >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
