LIR and DB Working Groups (with apologies for duplicate email), Discussed at RIPE-34 but with little subsequent action, I would like to repropose the addition of LIR-ALLOCATED as a valid status value for inetnum objects in the RIPE database. Attached is a slightly revised version of the document ("troff -ms" source version available on request) I last posted a year ago as a result of LIR-WG Action LIR-34.8. The suggestion then was that this could be massaged into a RIPE document (I think dfk volunteered!) to update ripe-185 (European Internet Registry Policies and Procedures) and that support for the new value be added to the database (and NCC tools as necessary). Regards, James -- Senior Network Engineer, IP Archictecture Group, KPNQwest Singel 540, 1017 AZ Amsterdam, NL ----------cut here---------- "Status: LIR-ALLOCATED" Considered Useful James Aldridge ----- -------- This document proposes a new value for the status field of the inetnum object in the RIPE database in addition to those listed in sections 3.4.2 (PA vs PI space) and 4.4 (Allocation Registration) of the "European Internet Registry Policies and Procedures" document ripe-185. For various reasons large registries often need to distribute their allocated address space between various parts of their organisation (for example we have separate national operations in 20 or so countries obtaining address space through the eu.eunet registry). In these situations it makes sense to document this redistribution in the RIPE database but there is currently no way to do this without throwing up errors in the RIPE NCC's auditing procedures or by removing flexibility and adding more work to the already busy NCC hostmasters by having each local operation treated as having their own allocation. Previously the RIPE database software allowed anyone to register an object with a status value of "ALLOCATED" but this was abused by people who didn't know what they were doing and so this is no longer possible and all non-NCC registered inetnum objects must now have the status of "ASSIGNED". However, having multiple levels of assignments in the RIPE database causes error reports from the NCC's auditing processes which now see anything under the higher- lever sub-allocation as being a duplicate (or overlapping) assignment which makes finding "real" problem assignments difficult or impossible. By allowing a local IR to register an inetnum object with a new status value of "LIR-ALLOCATED" it becomes possible to differentiate between a higher level sub-allocation ("status: LIR-ALLOCATED") and a final assignment by a LIR ("status: ASSIGNED"). By allowing this registration of intermediate objects it would also be possible to restrict changes to lower-level objects differently in different blocks of addresses within the LIR's allocation by setting different "mnt-lower" values without having to open the whole allocated block up for changes by anyone who might have a valid reason for updating a particular (range of) inetnum object(s). -2- An example may help to explain things at this point: inetnum: 10.1.0.0 - 10.1.255.255 netname: ZZ-REGY-19990916 descr: REGY Allocation country: EU ... status: ALLOCATED PA mnt-by: RIPE-NCC-HM-MNT ... source: RIPE inetnum: 10.1.0.0 - 10.1.31.255 netname: ZZZ-REGY-ALLOC descr: REGY - Local assignments in ZZZ country: ZZ ... status: LIR-ALLOCATED PA mnt-by: REGY-MNT mnt-lower: REGYZZ-MNT ... source: RIPE inetnum: 10.1.0.0 - 10.1.0.63 netname: CUSTOMER-XYZ-NET descr: Customer XYZ in ZZZ country: ZZ ... status: ASSIGNED PA mnt-by: REGYZZ-MNT ... source: RIPE Here the first inetnum object refers to the top-level allocation made to a local IR by the RIPE NCC and has the normal RIPE-NCC-HM-MNT maintainer field which restricts changes to the RIPE NCC Hostmasters only. The second inetnum object is registered by the central administrator of the local IR and the normal maintainer object for that administrator - REGY-MNT in this case. There is also a mnt- lower field permitting the national administrator to whom this sub-block is "allocated" to register end-user assignments. The final inetnum object here is a final assignment from the national organisation to a customer.