RE: I-D ACTION:draft-ietf-ipv6-rfc2096-update-06.txt

[[e-mail]]

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: [e-mail] [mailto:[e-mail]]On 
>Behalf Of Brian
>Haberman
>Sent: Sunday, February 01, 2004 11:03 AM
>To: C. M. Heard
>Cc: [e-mail]; 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 [e-mail] 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
>[e-mail]
>Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
>--------------------------------------------------------------------
>

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------