RIPE 34 LIR WG Draft Agenda
[ Moderator note: changed local-ir@ripe.net -> lir-wg@ripe.net ] Dear Working Group Member ! I have put together a first draft of the agenda for the upcoming working group meeting. Please read it carefully and make suggestions for additions and changes. Remember: this is YOUR forum, please send me YOUR suggestions on what you want us to spend time on at the meeting in Amsterdam, Looking forward to meet you there, Hans Petter Holen LIR WG Chair ---------------------------------------------------- RIPE 34 - Local IR Working Group first draft Agenda 1. Admin scribe participant list charter mailinglists 2. Agenda 3. Introduction of the new Registration Services manager, Nurani Nimpuno. meet the RIPE NCC hostmasters 4. RIPE 33 minutes actions 5. Reports from the Registries RIPE APNIC 6. The RIPE community POLICY making process by Mirjam Discussion: is this well understood and 7. ICANN - ASO Current status, Further work Definition of the selection procedure for the address council selection 8. AOB
hph@sys.sol.no wrote:
Remember: this is YOUR forum, please send me YOUR suggestions on what you want us to spend time on at the meeting in Amsterdam,
I think that it could be useful to start some discussion on whether an additional value for the inetnum "status" field would be useful. What I would like to see, and which would be useful for a large registry such as "eu.eunet" which I coordinate, is somethig like "LIR-ALLOCATED" which could be used to tag a block of addresses as being sub-allocated by a local registry for some purpose (e.g. identifying a block as being used for assignments by a particular local operation, PoP, etc.) but which wouldn't cause all the real assignments under that block to be flagged as overlaps or duplicates by the NCC's registry auditing processes. James ----- ___ - James Aldridge, Senior Network Engineer, ---- / / / ___ ____ _/_ -- EUnet Communications Services BV --- /--- / / / / /___/ / --- Singel 540, 1017 AZ Amsterdam, NL -- /___ /___/ / / /___ /_ ---- Tel: +31 20 530 5327; Fax: +31 20 625 5913 - ----- 24hr emergency number: +31 20 421 0865
On 10th September I wrote:
I think that it could be useful to start some discussion on whether an additional value for the inetnum "status" field would be useful.
What I would like to see, and which would be useful for a large registry such as "eu.eunet" which I coordinate, is somethig like "LIR-ALLOCATED" which could be used to tag a block of addresses as being sub-allocated by a local registry for some purpose (e.g. identifying a block as being used for assignments by a particular local operation, PoP, etc.) but which wouldn't cause all the real assignments under that block to be flagged as overlaps or duplicates by the NCC's registry auditing processes.
I've seen no comments on this so maybe I need to explain a bit more why I think that a LIR-ALLOCATED value in the status field would be useful: ---------- "Status: LIR-ALLOCATED" Considered Useful ========================================= 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). An example: 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 ... 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: REGY-ZZZ-MNT ... 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: REGY-ZZZ-MNT ... ---------- Any comments? James ----- ___ - James Aldridge, Senior Network Engineer, ---- / / / ___ ____ _/_ -- EUnet Communications Services BV --- /--- / / / / /___/ / --- Singel 540, 1017 AZ Amsterdam, NL -- /___ /___/ / / /___ /_ ---- Tel: +31 20 530 5327; Fax: +31 20 625 5913 - ----- 24hr emergency number: +31 20 421 0865
Any comments?
James
Only one short: Would be nice if it will be implemented as fast as possible. It might help us in some situation, and other companies are also benefitting of this proposal. Jan
"Status: LIR-ALLOCATED" Considered Useful =========================================
Sounds useful, as long as it's only effect is adding nodes to the maintainer tree. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far!
Poul-Henning Kamp wrote:
"Status: LIR-ALLOCATED" Considered Useful =========================================
Sounds useful, as long as it's only effect is adding nodes to the maintainer tree.
I see its main use as adding nodes to the maintainer tree and also as a way of documenting use of address space without actually making an assignment. Without specific "ASSIGNED" objects below a "LIR-ALLOCATED" object the address space would still be treated as unassigned as if the new object wasn't there at all. James ----- ___ - James Aldridge, Senior Network Engineer, ---- / / / ___ ____ _/_ -- EUnet Communications Services BV --- /--- / / / / /___/ / --- Singel 540, 1017 AZ Amsterdam, NL -- /___ /___/ / / /___ /_ ---- Tel: +31 20 530 5327; Fax: +31 20 625 5913 - ----- 24hr emergency number: +31 20 421 0865
x-noarchive: no
Any comments?
I support the proposal :-) Bernard I strongly disagree with this message to be indexed by WWW search engines.
participants (5)
-
bernard.steiner＠eunet.ch -
hph＠sys.sol.no -
James Aldridge -
Jan Ahrent Czmok -
Poul-Henning Kamp