Nurani Nimpuno wrote:
Proposed Name ------------- RIPE NCC proposes to use the term: "LIR-PARTITIONED" ("LIR-PARTITIONED PA" and "LIR-PARTITIONED PI") rather than "LIR-ALLOCATED", to clarify the use of this added database feature. As "LIR-ALLOCATED" could be misinterpreted as a policy feature, we believe that "LIR-PARTITIONED" is a more suitable term, not involving policy terminology, but merely describing a partition of the LIR's allocation.
I don't mind too much what it's called as long as the functionality is there.
Functionality ------------- When creating or modifying the inetnum object the database will check the value of the "status:" attribute according to the following rules:
- The value of "ALLOCATED PA" or "ALLOCATED PI" is allowed if the object is maintained by the RIPE-NCC-HM-MNT mntner (this name is specified in ALLOCMNT variable of the configuration file)
- The value of "LIR-PARTIONED PA" is allowed if one level less specific ^^^^^^^^^ "PARTIONED"?
inetnum object contains a "status:" attribute with the value of "ALLOCATED PA".
- The value of "LIR-PARTITIONED PI" is allowed if one level less specific inetnum object contains a "status:" attribute with the value of "ALLOCATED PI".
If I read this correctly, this means that only one level of partitioning is allowed - i.e. an inetnum block with "status: LIR-PARTITIONED" cannot have more specific blocks with the same status as then the "one level less specific inetnum object" wouln't have "status: ALLOCATED". I'm not sure that this would be a problem (although it would rule out some of the more general uses of this new value which have been mentioned by others on this list) and in any case if the more specific inetnum objects were created before the less specific then the checks would pass anyway. If the reason for these checks is to ensure consistency with the PI/PA value of the corresponding "ALLOCATED" object then maybe it is this top level object which should be checked against rather than the "one level less specific inetnum object".
If the general feeling in the community is that the "LIR-PARTITIONED" proposal does not cover the LIRs' need, but a more significant change to current IP allocation policy is necessary, then I propose that this be discussed in detail in the LIR-WG.
Whatever policy changes take place (and I believe that a review may be in order), I think that this proposal from the NCC is a good step forward in providing added functionality to the RIPE database and I would like to thank Nurani and the NCC staff for the work they have put into it. Regards, James -- James Aldridge, Senior Network Engineer (IP Architecture) KPNQwest, Singel 540, 1017 AZ Amsterdam, NL Tel: +31 70 379 37 03; GSM: +31 65 370 87 07