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).
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 PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
