Re: Modifications to the inet6num in the RIPE Database

[David Kessens david@localhost]

Joao,

On Fri, Mar 12, 1999 at 12:21:52PM +0100, Joao Luis Silva Damas wrote:
> 
> A week has passed and no comments against the proposed modifications to the 
> IPv6 object have been put forward.

I am a bit late too, and do have a few comments, though not very
significant.

> ------- Begin Original Message
> From: Joao Luis Silva Damas joao@localhost
> Date: Thu, 04 Mar 1999 10:20:17 +0100
> To:       lir-wg@localhost, db-wg@localhost
> Subject:  Modifications to the inet6num in the RIPE Database
> 
> Dear all,
> below are the proposed modifications to the inet6num object in the RIPE 
> Database as discussed during the past RIPE Meeting.
> 
> These are mainly to bring the IPv6 object up to the IPv4 object's 
> functionality.
> 
> The two suggested changes are:
> 
> - - addition of a "status" attribute with the following possible values:
>   TLA, NLA and SLA.
>   Syntax checks will be done so that:
>   TLA is only allowed if the prefix length is 3<x<=16
>   NLA is only allowed if the prefix length is 16<x<=48
>   SLA is only allowed if the prefix length is 48<x<=64

This is fine although, I am not entirely convinced that we really need
it. It's a bit redundant information. By definition something is a
TLA/NLA/SLA so you can just look at the 'inet6num:' field and you
already know what it is. Can't you just generate this field
automatically ?!?

> Joao writes:
> Actually I would even add to your comments by saying that inet6num
> objects
> +should be rejected if the prefix is in the reserved field except if
> the TLA is
> +the one reserved for sub-TLAs (0x0001).
> In that case the status field should have the sub-TLA value if the
> prefix is +16<l<27.

I don't think this should be part of the syntax checks or the object
description. This is more a local configuration issue.

For now, certain limits are set. I think that those limits belong
either in the configuration file or the objects can be shielded from
use by using allocation 'inet6num:' objects in combination with
'mnt-lower:' (which is the least amount of work). These limits might
not always stay the same and are not part of the basic specification.

> - - addition of "mnt-lower" capabilities, as in the IPv4 object.

In the only kind of production 'inet6num:' registry in the world, the
6bone, this is already implemented and used for over a year time. So I
don't have trouble with adding something that already exists ;-).

There is something missing in your definition though, when adding
'mnt-lower:' attributes, you always need to define the hierarchy order
that you want to use. Is it indeed the same order as in the 'inetnum:'
object ?!? I would rather like to choose not to allow anybody to put
in top level objects as is the case with 'inetnum:' objects.

David K.
---