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

["C. M. Heard" <[e-mail]>]

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

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.

Thanks and regards,

Mike Heard


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