- lir-wg - mailman.ripe.net

RIPE 42 - IP Request Tutorial announcement
by Rumy Kanis 11 Apr '02

11 Apr '02

Dear Colleagues, During the RIPE 42 Meeting, an "IP Request Tutorial" will be held on Monday, 29 April 2002, from 14:00 - 17:30. The goal of the "IP Request Tutorial" is to explain address space assignment and allocation procedures. It contains selected parts from the LIR course that the RIPE NCC provides to its members: How to Interact with the RIPE Whois Database How to Request Address Space - Completing the Request Form - Evaluation Assignment Window PI Assignments It is not necessary to register. All RIPE meeting participants are more than welcome to attend this tutorial. More information about the course that the RIPE NCC offers to its members is available at: http://www.ripe.net/training/ Material will soon be available at the RIPE Meeting web pages: http://www.ripe.net/ripe/meetings/current/ripe-42/tutorials/ip_request.html Kind regards, Rumy o-----------------------------------o | Rumy Kanis rumy(a)ripe.net | | Training Team Leader | | | | RIPE NCC tel. +31 20 535 4444 | | www.ripe.net | o-----------------------------------o

1 0

Current wait times
by RIPE NCC Hostmaster 11 Apr '02

11 Apr '02

Dear Colleagues, As you are probably aware, the period of time you are waiting for a first reply to your requests and queries has risen recently. Current wait times for the <hostmaster(a)ripe.net> <lir-help(a)ripe.net> and <new-lir(a)ripe.net> mail boxes are running at over two weeks. We understand that this is very inconvenient for you and want to keep you informed as to the reasons and our actions to improve the situation. There are three key factors in the rise of the wait queues: Firstly, the number of tickets opened by LIRs during the first three months of 2002 was approximately 6% higher than that period in 2001. Secondly, the number of mergers and closures of LIRs have more than doubled and their complexity has risen. We are seeing far more mergers involving six or more LIRs. Fuller details will be presented at the next RIPE meeting (RIPE42, 29 April - 3 May 2002 in Amsterdam). Finally, the "criteria for an initial /20 PA allocation" policy implemented in November 2001 has placed an additional load on our New-LIR Co-ordinators. The combination of these three factors has had a negative impact on the service we aim to provide our membership. We are currently streamlining our processes and reviewing our internal procedures. Additional and revised documentation of policies and procedures will be published shortly. We look forward to seeing you at the next RIPE meeting in Amsterdam. A full report from the RIPE NCC Registration Services will be given in the LIR Working Group session on Wednesday morning, 1 May 2002. Kind regards, Dominic Spratley Registration Services Assistant Manager

2 1

Draft Agenda for LIR WG at RIPE42
by James Aldridge 11 Apr '02

11 Apr '02

Herewith the first draft of the agenda for the forthcoming LIR-WG meeting at RIPE42. It would be good if we could have some on-list discussion on these topics before the meeting itself. Regards, James LIR-WG Co-Chair ---------- LIR WORKING GROUP Draft Agenda for RIPE 42 (version 1.4) 09:00-12:30 Wednesday, 1st May 2002 Chair: Hans Petter Holen Co-chairs: James Aldridge, Denesh Bhabuta Note that some items currently have zero time allocated to them; this may change as we get an idea of how long some of the regular presentations will take. We have a lot to get through so I would urge people not to celebrate Queensday too excessively on Tuesday so we can make a prompt start on Wednesday morning. 09:00 - 09:05 A. Admin: scribe, participant list, charter, mailing lists 09:05 - 09:10 B. Agenda bashing 09:10 - 09:20 C. RIPE 41 minutes and actions [Has anyone seen the minutes from the last meeting? I've only seen those for the IPv6 Policy sessions] 09:20 - 09:40 D. Report from the RIPE NCC Hostmasters - Presentation [Sabrina Wilmot ?] 09:40 - 09:55 E. Report from the Address Council - Presentation [Hans Petter Holen ?] 09:55 - 10:30 F. IPv4 Assignment and Allocation Policy F.1 Do we need to bring the IPv4 assignment policy into line with the new (Nov 2001) "Minimum Allocation Criteria" policy? - Summary of problem [Sabrina Wilmot ?] - Proposed solution (?) - Discussion F.2 "Official Sub-Allocations" Proposal [Gert Doering] F.3 "MIR/SUB-LIR" Proposal (WG action from RIPE40) http://www.ripe.net/ripe/mail-archives/lir-wg/20010701-20020101/msg00138.ht… Is this still needed following the implementation of "status: LIR-PARTITIONED" (documentation) or do we still need a more hierarchical allocation scheme (policy)? 10:30 - 11:00 Coffee break 11:00 - 12:30 G. IPv6 Allocation Policy Can this community agree with the consensus reached at the recent APNIC and ARIN meetings? - Summary presentation [Mirjam Kuehne ?] - IPv6 WG Input [David Kessens ?] - Discussion - Consensus! 00:00 - 00:00 X. Any other business 00:00 - 00:00 Y. Summary of actions arising from this meeting 00:00 - 00:00 Z. Open microphone

3 2

Re: Draft Agenda for LIR WG at RIPE42
by jhma+ripe＠mcvax.org 11 Apr '02

11 Apr '02

Havard Eidnes asked: > Can you please send a pointer to the LIR mailing list which points > towards the policy which there appers to be consensus on? Attached is a message posted to the global-v6 list by Takashi Arano following the last APNIC meeting. The ARIN meeting has just finished and I haven't yet seen any formal report from that meeting but I am lead to believe that the same consensus was reached. James

2 1

Hostmaster Centre at RIPE 42
by RIPE NCC Staff 10 Apr '02

10 Apr '02

Dear all, RIPE NCC Registrations Services are pleased to announce that during the RIPE 42 Meeting in Amsterdam we will open a RIPE NCC Hostmaster Centre. RIPE NCC Hostmasters will be available for questions related to IP and ASN requests, as well as any general policy questions and LIR set up issues. A timesheet at the centre will be made available for appointments, though 'walk-in's will also be welcome. Please note the following time-table: Monday April 29th. 12:30 - 17:30 Wednesday May 1st. 12:30 - 17:30 Thursday May 2nd. 9:00 - 17:30 Friday May 3rd. 9:00 - 14:00 We look forward to meeting you. Regards, RIPE NCC Hostmasters Information about the RIPE 42 Meeting can be found at: http://www.ripe.net/ripe/meetings/current/ripe-42/

1 0

Reopen discussion: Sub-Allcations vs. LIR-PARTITIONED
by Gert Doering 10 Apr '02

10 Apr '02

Hi, as you might remember, there was a lengthy discussion on this list about sub-allocations, reservations (yes, the ugly word) of IP address blocks for LIR customers that are themselves resellers, and so on. James Aldridge originally proposed something that ended up in being "status: LIR-PARTITIONED PA/PI". I just checked the RIPE DB, and there are just 7 objects in the RIPE database that use this at all, and 6 of them are by one maintainer. This matches my feelings of LIR-PARTITIONED - "nice try, but this isn't what I imagined". I think "official sub-allocations" are more useful, and have written up a proposal for this (based on the discussion here and at the LIR-WG meeting in Prague). Give it a good discussion and let's decide something in Amsterdam... gert --------- snip ---------- Motivation: - Some LIRs have internal hierarchies, like "resellers that have their own end customers". - For aggregation reasons internal to the LIR network, LIRs "allocate" address space to their resellers ("hierarchical sub-LIRs"), who then "assign" addresse from that to their customers. Usually the LIR has to approve all end-user requests, but the sub-LIR is doing the actual assignment from the "allocated" space. - The current policy doesn't explicitely permit this, but acknowledges to some extent that it is done. - When the LIR goes to the RIR to get another allocation, the 80% rule does not take into account the fact that some of the "not assigned" space may be in fact "sub-allocated" to a "sub-LIR", thus it may be very hard to reach 80% (and will lead to internal fragmentation). (This is what Wilfried calls "reservation") - The sub-allocations are not documented, so an outsider cannot see who might be the best contact (the reseller!) if one of the end customers misbehaves (this part could be solved with "LIR-PARTITIONED"). Proposal: - permit LIRs to sub-allocate the address allocation they receive from a RIR to "downstream parties", from now on called sub-LIRs - the Sub-Allocations are documented as an inetnum: object with "status: SUB-ALLOCATED PA" in the RIPE database. I do not like "LIR-PARTITIONED", because it isn't partitioned ("equal parts"), and also because it doesn't go far enough. - All assignments from the Sub-Allocation are done by the Sub-LIR. The Sub-LIR is responsible to the LIR for following policies and procedures. The LIR is responsible to the RIR for making sure that the Sub-LIR follows the procedures. This is no big difference from what is being *done* now, it's just "officially documented". - When the LIR has to apply for an additional allocation, the Sub-Allocation are counted for the "80% utilization rule". So, to show an extreme example, a LIR that has sub-allocated 90% to its resellers, and they have only assigned a total of 30% of the total allocation yet, the LIR *would be* entitled to get a new allocation (under the current policy, it is not). In extreme cases, it might be necessary to show lots of good documentation to the RIR as for "why did you allocate so much". Points of Concern: - "They will just waste address space". Yes, it will waste some space, due to better aggregation. It is not expected that this will waste space due to "sloppyness" in following the policies and procedures - each hierarchy level will be fully responsible for making sure that the next-lower level will understand the rules and follow them. It is similar to what IANA and the RIRs do. The RIRs try to hand out address space in a responsible way (which does not always succeeed, which is why changes to the procedures are made, like /19 -> /20 for the initial allocation), and in this proposal, the LIRs have to hand out space to the sub-LIRs in a responsible way. If the RIRs mess up, they have a problem with IANA, if the LIRs mess up, they have a problem with their RIR. - "How big shall the sub-allocation be"? The exact numbers for the default case would have to be defined. Again, this is similar to the RIR->LIR case. A LIR by default gets a /20, but might get a bigger space in case it produces a good forecast that shows a reasonable need for a bigger space. I propose to give a Sub-LIR a /24 to start with, except in cases that they show evidence for needing more. Rationale: it's not too much, and you can delegate DNS on /24 boundaries without ugly tricks. When the Sub-Allocation is used up (= 80% of the space in there is ASSIGNED), the Sub-LIR can ask for more. If a customer asks for more space than the Sub-LIR has left, the Sub-Allocation can also be increased / a new Sub-Allocation be made. - "What's the size of networks a Sub-LIR can assign to their customers"? It can not go over the AW of the LIR. This part is fixed due to the RIR/LIR relation. As for the rest, I propose that this should be a matter between the LIR and the Sub-LIR. They have a contract, and it's the LIRs job to make sure that the Sub-LIR follows the official policies and procedures, maybe introducing their own Sub-AW per Sub-LIR etc. --------- snip ---------- -- Total number of prefixes smaller than registry allocations: 74810 (74196) SpaceNet AG Mail: netmaster(a)Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299

1 0

Test
by RIPE NCC Mailing Lists Moderator 10 Apr '02

10 Apr '02

1 0

update lir object
by Fabio Bracali - Local Internet Registry - Casaweb 04 Apr '02

04 Apr '02

I would like to update my lir object with new contact persons and new email addresses. How can i do it? what is ripe email address that I must use to send the form? thanks in advance

2 1

Re: more authority for mnt-lower in the allocation objects
by Sabrina Wilmot 16 Mar '02

16 Mar '02

For security and consistency reasons the RIPE NCC maintains the inetnum objects describing allocations with all their information. Requests for changes should be submitted to the <lir-help(a)ripe.net> mailbox. This procedure will continue until the development of accessing and modifying the LIRs own data using currently avaiable technologies such as a secure web site is finished. An LIR might experience delays in the handling of its request when necessary information is not provided to the RIPE NCC. If the reason for changing contact/maintainer information is that an LIR acquires other ISPs/LIRs then there are more RIPE NCC procedures to follow then just requesting a change of contacts in the allocation objects. Kind regards, Sabrina Wilmot -- o------------------------------------------o | Sabrina Wilmot sabrina(a)ripe.net | | Registration Services Operations Manager | | | | RIPE NCC tel +31 20 535 4444 | | www.ripe.net fax +31 20 535 4445 | o------------------------------------------o

2 1

more authority for mnt-lower in the allocation objects
by Tanja Heimes 15 Mar '02

15 Mar '02

Hi Lir-WG, this is a hostmasters argument upon my question why I am not able to change the contacts and mnt-routes in my own allocation by myself. I am interested if somebody else is sharing my opinion. Hostmasters argument: "It is not possible for you to update an allocation object because RIPE NCC is the maintainer of these objects, which makes sense. :)" This is my opinion: Yes, it makes sence that RIPE NCC is the maintainer of a LIRs allocation. But in my opinion it makes NO sence that Cable and Wireles (and all other LIRs) as mnt-lower do not have the authority to change their own administrative and technical contacts in the allocation. There must be an restricted authority for a mnt-lower to change things like that by their own. I think especially about following attributes: (marked with +++) inetnum: 62.208.0.0 - 62.208.255.255 netname: DE-ECRC-970502 descr: ECRC GmbH country: DE +++++admin-c: EN65-RIPE +++++tech-c: EN65-RIPE status: ALLOCATED PA mnt-by: RIPE-NCC-HM-MNT mnt-lower: CW-EUROPE-GSOC +++++mnt-routes: CW-EUROPE-GSOC changed: hostmaster(a)ripe.net 20010814 source: RIPE In my opiniom it makes no sence that for a very simple change in the allocation, that does actually not affect the allocation itself we have to send requests to the hostmasters and wait sometimes weeks for their handling. I think that persons that stand behind the respective reg-id should have this authority. Best regards, Tanja Heimes -- Tanja Heimes / IP Engineer E-Mail Tanja.Heimes(a)de.cw.com Cable & Wireless Deutschland GmbH TEL. + 49 89 92699-0 Landsberger Strasse 155 Fax. + 49 89 92699-810 D-80687 Munich, Germany web: http://www.cw.com/de

3 4