Modifications to the inet6num in the RIPE Database
Dear all, A week has passed and no comments against the proposed modifications to the IPv6 object have been put forward. Therefore we take it that everyone is happy with it and will procede with the implementation. We expect this to be available in about two weeks. The original message is repeated below for your reference. Regards, Joao Damas DB Group RIPE NCC ------- Begin Original Message From: Joao Luis Silva Damas <joao@ripe.net> Date: Thu, 04 Mar 1999 10:20:17 +0100 To: lir-wg@ripe.net, db-wg@ripe.net 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 - - addition of "mnt-lower" capabilities, as in the IPv4 object. We would like to open a comment period of 1 week from today to gather input and proceed with implementation if there is consensus. Regards, Joao Damas DB Group RIPE NCC ------- End Original Message
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@ripe.net> Date: Thu, 04 Mar 1999 10:20:17 +0100 To: lir-wg@ripe.net, db-wg@ripe.net 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. ---
participants (2)
-
David Kessens -
Joao Luis Silva Damas