RE: Subranging InetAddressPrefixLength

[shawn.routhier@windriver.com]

Comments in line

>-----Original Message-----
>From: owner-mreview@ops.ietf.org [mailto:owner-mreview@ops.ietf.org]On
>Behalf Of C. M. Heard
>Sent: Saturday, January 31, 2004 7:01 AM
>To: Mreview (E-mail)
>Subject: RE: Subranging InetAddressPrefixLength
>
>
>On Sat, 31 Jan 2004, Wijnen, Bert (Bert) wrote:
>> > -----Original Message-----
>> > From: C. M. Heard [mailto:heard@pobox.com]
>...
>> > In the just-announced draft draft-ietf-ipv6-rfc2096-update-06.txt
>> > this definition caugt my eye:
>> > 
>> >   inetCidrRoutePfxLen OBJECT-TYPE
>> >       SYNTAX     InetAddressPrefixLength (0..128)
>...
>> > If we discourage people from putting size constraints on 
>InetAddress
>> > objects and from putting value constraints on InetAddressType
>> > objects, all in order to ensure future extensibility, it seems to
>> > me that we should similarly discurage putting range restrictions on
>> > InetAddressPrefixLength objects.
>> > 
>> I think that Shawn put it in cause I mentioned a WARNING from SMICng
>> that states that a range must be specified. we discussed a bit if 128
>> makes sense or if maybe a larger value (I can think of 1K, 32K, 64K,
>> 4billion) makes sense. The response from Shawn was that if the 
>> length of an IP address gets longer than the 128 for IPv6, that
>> many more changes will be needed.  So I am kind of OK with128.
>
>So based on that reasoning why would you not be OK with putting the
>following into the object definitions (as opposed to compliance
>statements):
>
>    inetCidrRouteDestType OBJECT-TYPE
>        SYNTAX      InetAddressType (ipv4(1), ipv6(2),
>                                     ipv4z(3), ipv6z(4))
>        [ ... ]
>        ::= { inetCidrRouteEntry 1 }
>
>    inetCidrRouteDest OBJECT-TYPE
>        SYNTAX      InetAddress (SIZE (4 | 8 | 16 | 20))
>        [ ... ]
>        ::= { inetCidrRouteEntry 2 }
>
>Also, as a side issue, allow me to point out that currently the
>(current) address size cap is 20 octets, but a prefix length of 128
>bits corresponds to 16 octets.

The address size cap of 20 octets includes 4 octets for scope index
information, which won't be included in the prefix length.  128 is
correct for the current addresses.

Aside from the logistics of changing the value I don't have an issue
with a different size or with no size.  If we do choose a size 2040
does sound like a better choice.



>
>> > Neither RFC 3291 nor draft-3291bis addresses this explicitly;
>> > maybe the next rev of 3291bis should do so.
>> ??
>
>What I meant was that RFC 3291 goes to great length telling people
>that they SHOULD NOT subtype InetAddress or InetAddressType in
>object definitions.  For consistency, shouldn't the same be done for
>inetCidrRoutePfxLen?  In other words, shouldn't the 3291bis draft
>say that inetCidrRoutePfxLen objects SHOULD NOT be subtyped, MIB
>compiler warnings to the contrary notwithstanding?
>
>Mike
>
>