C. M. Heard wrote:
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).
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 [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
