RE: Subranging InetAddressPrefixLength

["C. M. Heard" <heard@pobox.com>]

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.

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