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

From: "C. M. Heard" <[email-masked]>
Date: Sun, 1 Feb 2004 10:43:57 -0800 (PST)

On Fri, 30 Jan 2004 [email-masked] 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
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Brian Haberman <[email-masked]>
Date: Sun, 01 Feb 2004 14:03:19 -0500

Mike,

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

> 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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 2 Feb 2004 10:35:01 +0100

On Sun, Feb 01, 2004 at 02:03:19PM -0500, Brian Haberman wrote:

> was made in the IP MIB update (2011bis).  

I believe there is no problem with not having a range restriction 
since the type is an Unsigned32 which should nicely fit into an OID
subidentifier.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: "C. M. Heard" <[email-masked]>
Date: Tue, 3 Feb 2004 08:06:12 -0800 (PST)

Brian,

Here is another small thing I just noticed:

    inetCidrRouteIfIndex OBJECT-TYPE
        SYNTAX     InterfaceIndex
        MAX-ACCESS read-create
        STATUS     current
        DESCRIPTION
               "The ifIndex value which identifies the local interface
                through which the next hop of this route should be
                reached.  A value of 0 is valid and represents the
                scenario where no interface is specified."
        ::= { inetCidrRouteEntry 7 }

The SYNTAX value above should be InterfaceIndexOrZero, since
InterfaceIndex does not allow values of zero.

Sorry for not catching this earlier.  The fix is easy, though:
just make a global substitution s/InterfaceIndex/InterfaceIndexOrZero/

Mike

---

From: "C. M. Heard" <[email-masked]>
Date: Wed, 4 Feb 2004 07:34:58 -0800 (PST)

Brian,

If interpreted literally, the following language in the DESCRIPTION
clauses for inetCidrRouteDest and inetCidrRoutePfxLen seems to
prohibit having a non-zero zone index in inetCidrRouteDest:

            returned on SET or CREATE requests.

This is so because the mask formed from inetCidrRoutePfxLen is
contiguous and does not include the zone index part.  Thus, the
bitwise logical-AND of the value of inetCidrRouteDest and the value
of the mask formed from the corresponding index object
inetCidrRoutePfxLen will necessarily have zeroes in the zone index
position.

It seems to me that an easy fix for this problem would be to alter
the text to exclude the zone index from the comparison.  Here is
my suggestion:

            The values for the index objects inetCidrRouteDest and
            inetCidrRoutePfxLen must be consistent.  When the value
            of inetCidrRouteDest (excluding the zone index, if one
            is present) 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.

Thanks,

Mike

---

From: Brian Haberman <[email-masked]>
Date: Wed, 04 Feb 2004 10:46:21 -0500

>             returned on SET or CREATE requests.

After reading through the thread again and looking at the text, I agree
that it is wrong wrt scoped addresses.  I like your suggested text with
one caveat.  I believe we need to include some words in the DESCRIPTION
that talk about what to do when a zone index is present in the address.
I need to think some more about what that text should be and where it
should go.

Regards,
Brian

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 4 Feb 2004 18:02:38 +0100

On Wed, Feb 04, 2004 at 07:34:58AM -0800, C. M. Heard wrote:

[...]
 
>             returned on SET or CREATE requests.

This text is clearly an improvement over what has been there before.

/js