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

[Brian Haberman <[e-mail]>]

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