May 2001 - lir-wg - mailman.ripe.net

Acrion list after RIPE 39
by Hans Petter Holen 04 May '01

04 May '01

35.4 NCC PGP Key exchange procedure Low prio 35.5 NCC Implement PGP for hm Low prio 36.5 Chair Assignment window applied on infrastructure Proposed change 36.6 AP Collect arbitrators Taken care of. 36.7 NCC Keep lir-wg updated on pre RIR address space changes Db-wg presentation 37.1 WG Further discuss restoring the transparency Ntr 38.2 NCC Implement changes to the form while taking into account the comments from the WG In progress 38.3 WG Reopen policy discussion - do we need a major revision of RIPE 185 RIPE 40 38.4 AC Consider how to coordinate Address prediction work Work launced 38.5 NCC Implement 34.6 LIR-ALLOCATED 38.6 NCC Propose PI policy to the WG Ongoing 39.1 NCC Better metrics & more relevant stats 39.2 NCC Suggest procedure and possible policy changes 39.3 NCC Call for AC nominations 39.4 Chairs Define & divide work 39.5 Chairs Beta test 6 weeks deadline for proposals

1 0

lir-wg draft minutes from RIPE 38
by Hans Petter Holen 01 May '01

01 May '01

Dear lir-wg, I am sorry for submitting the draft minutes to you at such a late stage, it is partly due to the fact that I myself got the minutes rather late, partly due to my own lack of time to go trough them. Hans Petter --------- Draft Minutes Tuesday 23 January 2001. Scribe: RIPE NCC Hostmaster - Geoff Charters, Roger Arcilla Hans Petter Holen (HPH) opens the meeting by describing the way policies are developed in this region. Policies are developed in open forums (LIR-WG in the RIPE region). The Address Council (AC) oversees the process and gives resommendations to the ICANN board. He asks the audience to give input to the AC. He also stresses that the AC are elected by the regional policy foras like the lir-wg and that we are not there to make policy ourselves, but merely to oversee the policy making in the regions. (http://www.ripe.net/ripe/meetings/archive/ripe-38/presentations.html#LIR)5 HPH introduces the members of the AC: There are 3 members from the APNIC region, 3 from the ARIN region, 3 from the RIPE region (see http://www.aso.icann.org/ac/) Sabine Jaumes term is ending. At the RIPE 38 plenary session elections will take place. HPH describes how the AC operates: The AC makes an effort not only to attend open policy forums and other events in the recpetive region, but also to gather input trough special input foras. The AC and the RIRs have recently sent out a call for nominations for a vacant ICANN board seat. Nominations can be submitted by anyone. There is also a possibility to express support for nominees. In order to keep the geographic diversity on the ICANN board, the new board member cannot come from Europe or the Asian Pacific region. Address allocation policies are developed in a bottom-up manner in each region. How is global policy developed? Is a proposal first discussed in each region and then coordinatd between the RIRs? This can be a long process. Do we need to create a gobal mechanism? Is there more co-ordination necessary between the RIRs or the regional open policy forums? What are global issues, what are regional? HPH reports from the workshop the AC had with the RIRs and IANA in Brisbane in November 2000. It was a very productive and effective workshop. The role of the AC was discussed. Is the AC too active or not active enough? An action was placed on the RIR's to compare regional policies. The goal is not to produce the same policies - but to find the differences. There might reasons for different policies. The general issue on how to take care of resource (IP addresses, ASNs). Is it a public resource that need to be protected or should it be market driven or auctioned? The AC is committed to be more proactive in informing the community about their acivities by creating a publically archived mailing list which is used for AC meeting agendas, minutes and policy discussions. Only about 5 people in the audience looked at the ASO web site. HPH encourgaes everyone to follow the developments. One achievement during last year was the discussion related to address space needed for GPRS. This has been taken up in all regions and is being handled in a consistent way. Up til now, address requirements for the GPRS infrastructure has been discussed. Further discussions need to take addresses for handsets into account. Many of these developments address issues listed by the Ad hoc group. The Ad hoc group will present its final report to ICANN shortly and will then be closed. The RIRs submitted a document to the AC and to ICANN listing criteria to be used by ICANN when approving emerging RIR. According the ASO MoU it is ICANN that makes the final decision about the approval of a new RIR. One important criteria is strong support from within the region of the emerging RIR. Similar to the RIPE LIR-WG there are open policy forums in the ARIN and APNIC regions. HPH wonders if this was a useful overview of AC activities and asks for feedback. What should be on the AC's list of actions for 2001? The audience feels this was useful. Mark McFadden wants the AC to do more. In particular: there is a lot of discussion about scarcity of IPv4 addresses and ASNs. A lot of work is done in an uncoordinated way. Wants the AC to co-ordinate this. Spreaded activities all over the world, wants the AC to combine this work. He is not suggesting that they do the work themselves. He also wants the AC be more active in globalising addressing policies. He also feels that RFC2050 should be revised, the AC should not do this, but another group. It is out of date and incomplete. Randy Bush agrees with Marks second point, it would be nice to have policies/procedures more aligned. To the first point, this work is ongoing in the IETF. The only useful addition one could be to compile and bundle this work for people who do not have the time to follow all developments. Mark points out that there is engineering work being done outside the IETF, the AC could play a role in this. Wilfried Woeber would like to share some of his experiences with this 'flying circus': sometimes one finds out that one was part of a feedback loop. Requirement to interact with different people and groups, this is a good thing about the Internet industry self-regulation. On the issue of global policy, thinks the AC did a good start by asking the RIRs to look at each other policies and define which ones are different and why. Then this could be given back to the communities asking if they want to keep it the way, because they are used to this and it doesn't harm or if they want to put energy in it to try to make them more aligned. Carsten Schiefner wonders if there a transition plan from the established RIRs to the emerging RIRs. HPH explains that this is done in a bottom-up manner: ISPs in the area cannot be forced to either stay or move, they have to show support. Randy wonders if there will be competition between the RIRs? Mirjam: No, RIRs operate in geographic regions, it has been working well so far, they are not proposals on the table to change this. Juergen Rauschenbach notes that the IPv6 policy document still pending, because one of the communities did not agree. He wonders if additional RIRs will impose even more delay on these kinds of issues. Mirjam explains that policies are in place so that IPv6 operations are not delayed through that. SubTLAS are handed out. ARIN community set up a working group to look into the policy. Richard Jimmerson from ARIN reports from the status of the ARIN IPv6-WG. Juergen suggests to implement regional policies if one of the regional communities cannot make a decision to go along with the others. Mirjam urges everybody to try to develop globally consistent allocation policy for IPv6. The RIRs are still committed to that. She reminds the audience that the fact that some of the IPv4 allocation policies have not been aligned has created constant criticism. Lets try to avoid this in IPv6. Paul Mylotte: Presentation on global address forecast (http://www.ripe.net/ripe/meetings/archive/ripe-38/presentations.html#LIR) Juergen believes that both methods are flawed 1. method: H-Ratio has not taken into account Even though there are 400 million addresses still available it will be hard to push density above 116 million addresses used, currently density at about 105 - 110 millions 2. method: good numbers if the growth is staying stable. There are more factors: mobile devices, address needs in China etc. Scott Markus also comments on method 2: not on the total numbers allocated, but on the growth itself; change in the change, no change in the base. Geoff Huston for instance calculates 7% of addresses allocated Mark MacFadden acknowledges that substantial work has been done in a number of areas. Personally he believes the H-ratio is questionable. He would like to see some harmony between the work that is going on. They all relate to different things, difficult to compare. We need to bring this information together. The AC should take on this work. Scott agrees with Mark. There was a discussion among the RIRs themselves to put more effort into this, will make the base data more widely available and put more work into this. Leos Vegoda: presentation (http://www.ripe.net/ripe/meetings/archive/ripe-38/presentations.html#LIR) Wilfried wonders if we really want to go into a lot of details for such small amount of address space? Should there be a standard size of address space where one is entitled to have one without any questions asked? Joao believes that this would mean a shift from assignments based on actual need to more simplification. Gerd is in favour of giving people public addresses instead of private addresses if they don't want it. He would be happy to give everyone a /29. This would make life easier for people and would also pushes the deployment of IPv6. John Klensin notes that these kind of limits (/29 in this case) seem to be made up by magic. He advocates to be careful with looking at these numbers and to draw conclusions from them or to assume all kinds of things that might not be valid in the future. PaulW points out that this proposal has also global implications. In the APNIC region there is very rapid deployment of cable and ADSL in a number of countries. Any decision that is made here, will be used and seen as a precedent in other regions. This will increase the usage rate significantly. He suggests to still have it dependend on the network and the application, not on the technology. An assignment of a /29 to all cable and ADSL customers seem to be very dangerous and not at all necessary. HPH proposes to introduce a separate assignment window for infrastructure. Maybe together with some safeguard to review this once a year or so. Discussion will be continued on the mailing list. Finally the ASO General Assembly Meeting was announced to be held in San Francisco on 4 April 2001.

1 0

IPMT specification rough draft
by Manuel Valente 01 May '01

01 May '01

Hi, Following a presentation by Guy Vegoda at the Tools BOF at RIPE37 of an IP Management Tool, interest was expressed in the development of an Open Source version of such a tool and we used the lirwg list to draw up Requirements for this. We have now produced some rough specifications for this tool that we will present at the upcoming Tools WG tomorrow. We will target as users 'The Hostmaster staff of Local Internet Registries which are Customers of the RIPE NCC and who need to manage their IP Allocations and Assignments and the requests for same that they send to the RIPE NCC'. We would now like the help of such potential users to refine these specifications into something that the RIPE NCC and interested developers can go away and implement. So, if you're interested by such a tool, please come along to the RIPE39 Tools WG tomorrow at 16h00 in the Europa Auditorium. Thanks. -- Manuel Valente - Software Manager - RIPE NCC ------------------------------------------------------------------ Draft of Specifications for an IP Management Tool Manuel Valente, Leo Vegoda, Maldwyn Morris RIPE NCC swcontact(a)ripe.net 20010419 0. Introduction Following a presentation of an IP Management Tool by Guy Vegoda at the Tools BOF at RIPE 38 [1], interest was expressed in the development of an Open Source version of such a tool and we drew up Requirements (qv) 1. General Points Open Source: We will release this software under the LGPL licence [2]. We use this instead of GPL [3] because this means we will remain able to using non-GPL'ed libraries, should that prove necessary. The RIPE NCC is happy to support this project, but of course its Open Source nature means anyone else can use the code to begin their own Open Source project. We are also happy about that. IPV6: We would be foolish not to consider the possibility of using this tool for managing IPV6 addresses and writing it such that this is possible, but we think it will be useful even if it does not and do not consider IPV6 support a requirement. 2. Definitions: Parties : RIPE NCC: The European Regional Internet Registry, which grants IPV4 address allocations to its customers, the LIRs. LIR: A customer of the RIPE NCC which interracts with the RIPE NCC in order to make IPV4 address assignments to their LIRCustomers from the LIR's IPV4 address allocation. LIR Customer: A person or organisation which wants to receive IPV4 address assignments. LIR Hostmaster: A person working for a LIR whose job it is to make IPV4 address assignments to the LIR Customers. Registered IPV4 Address Information: There are two forms of IPV4 address information which are registerd by the RIPE NCC and which are stored in the RIPE Whois Database: IPV4 Address allocations and IPV4 Address assignments. IPV4 Address allocations: A range of IPV4 addresses from which the RIPE NCC allows a certain LIR to make IPV4 Address assignments to their LIRCustomers. IPV4 Address assignments: A range of IPV4 addresses from a LIR's IPV4 Address allocations which the RIPE NCC and the LIR allows a certain LIRCustomer to use on the Internet. Interactions: I1: LIR Customer Assignment Request: An LIRCustomer asks their LIR for an IPV4 Address assignment and the LIR replies. Composed of: I1.1: LIRCustomer communicates request for IPV4 Address assignment to LIR I1.2: LIRHostmaster evaluates request I1.3: LIRHostmaster queries LIRCustomer about request I1.4: LIRHostmaster actions request I1.5: LIRHostmaster informs LIRCustomer of request outcome I1.6: LIRHostmaster completes request for LIR Customer I2: LIR Assignment Request: An LIR asks the RIPE NCC for approval of an IPV4 Address assignment and the RIPE NCC replies. I2.1: LIRHostmaster formulates query I2.2: LIRHostmaster sends request to NCC I2.3: LIRHostmaster handles response I2.4: LIRHostmaster completes request I3: LIR Allocation Request: An LIR asks the RIPE NCC for an IPV4 Address allocation and the RIPE NCC replies. I3.1: LIRHostmaster formulates query I3.2: LIRHostmaster sends request to NCC I3.3: LIRHostmaster handles response I3.4: LIRHostmaster completes request I4: LIRH Manages Customers I4.1: LIRHostmaster composes report(s) of info on one customer I4.2: LIRHostmaster composes report(s) on all customers I4.3: Creation of new customer I4.3: Update customer info I4.3: Delete customer I5: LIRH Manages LIR's Assignments I5.1: LIRHostmaster composes report of all assignments I5.2: LIRHostmaster composes report on a specific assignment I6: LIRH Manages LIR's Allocations I6.1: LIRHostmaster composes report of all allocations I6.2: LIRHostmaster composes report on a specific allocation 3. IPMT Functional Breakdown The functions the IPMT tool must provide, divided per Interaction. I1: LIR Customer Assignment Request: I1.1. LIRCustomer communicates request for IPV4 Address assignment to LIR IPMT: F1: receive the LIR Customer Assignment Request F2: store request info F3: LIR Hostmaster sees new request I1.2 LIRHostmaster evaluates request IPMT: F4: Check request correctly formatted and I1.5: Deny if not F5: Check request valid and I1.5: Deny if not F6: Check LIR Customer valid and I1.5: Deny if not I1.3: LIRHostmaster queries LIRCustomer about request IPMT: F7: Get more info from LIR Customer regarding request F8: update request info F9: -> I1.2: Evaluate I1.4: LIRHostmaster actions request F11: Need to ask RIPE to perform request ? -> I2 if so F12: Check request F13: Update request info F14: Check other info concerning assignments F15: Update other info based on request I1.5: LIRHostmaster informs LIRCustomer of request outcome F16: Communicate request outcome and info to LIR Customer I1.6: LIRHostmaster fills in customer request F17: Generate info about request, possible with F7 4. Implementation proposals ?? LIR Hostmaster interracts with IPMT via a GUI. ?? IPMT GUI will have HTML form range of elements ( text, buttons, single-line text, multi-line text, radio buttons, check boxes ). I1.1 LIRCustomer communicates request for IPV4 Address assignment to LIR F1: receive the LIR Customer Assignment Request ?? LIR Customer sends request : - via html form - by snailmail/phone/other & LIRH fills in a GUI form - by email to designated address - address served by mail robot ? - FORGET for now - too complex ? - LIRH uses CLI to fill in - Other LIR fills in using IPMT via API F2: store request info ?? Store in 'LIR Customer request' record in DB ?? Request record: Request id LIR Customer email address date raw request info - from LIR customer comm.s LIRH ID - 'request owner' F3: LIR Hostmaster sees new request ?? IPMT 'fetch next request' button to show next LIR Customer Request in GUI - wait queue... - IPMT perfroms F4,F5,F6 I1.2 LIRHostmaster evaluates request F4: Check request correctly formatted and I1.5: Deny or I1.6 if not IPMT parses 'LIR Customer Request' record, extracts and stores in it: LIR customer id request size in num of IP addresses request category: ?? status: ?? IPMT informs LIR Hostmaster if parse fails F5: Check request valid and I1.5: Deny or I1.6 if not ?? IPMT checks 'LIR Customer request' record ?? I1.3 if more info needed OK ?? IPMT sets 'checked' flag F6: Check LIR customer valid and I1.5: Deny or I1.6 if not IPMT looks up LIR customer info ?? LIR customer info stored in a DB ?? 'LIR customer' record LIR customer id customer email addresses and other contact info. request ids of previous requests total space size of assignments - enough info to make Whois DB person object ? IPMT informs LIR Hostmaster if customer not valid I1.3: LIRHostmaster queries LIRCustomer about request F7: Get more info from LIR customer regarding request ?? LIR Hostmaster uses IPMT to compose and send email to LIR customer ?? LIR customer reply automatically added to 'customer request' record or LIRH can use IPMT to do this ( e.g. : enter phone conversation ) ?? IPMT 'action needed' button to show customer reply received F8: update request info LIR Hostmaster updates 'customer' and 'customer request' records F9: -> I1.2: Evaluate I1.4: LIRHostmaster actions request F11: Need to ask RIPE to perform request ? -> I2 if so IPMT Check LIR Assignment window vs size of request - force insert of NCC# ticket number of approval if it's needed - need access to LIR Assignment window reports to LIR Hostmaster F12: Check request IPMT examines request record vs customer and LIR assignment and allocation records ?? assignment records - in whois ??: - or IPMT stores this locally - or LIR's records ?? via defined API ?? ipv4 range - IPMT makes _suggestion_ - allow choice of methods by config file as debatable - what methods are there ? netname - IPMT makes _suggestion_ ?? allocation records - in whois ??: - or IPMT stores this locally - or LIR's own records ?? via defined API ?? ipv4 range F13: Update request info ?? IPMT generates assignment addresses from 'customer request' record and assignment and allocation records LIR Hostmaster agrees or alters assignment addresses F14: Check other info concerning assignments - too varied so LIR to implement - IPMT provides I4,5,6 to allow LIRH access to info it has ?? LIR workflow stats ?? LIR Hostmaster stats ?? LIR infrastructure updates ?? LIR customer billing F15: Update other info based on request IPMT stores assignment addresses in 'customer request' record I1.5: LIRHostmaster informs LIRCustomer of request outcome F16: Communicate request outcome and info to customer LIR Hostmaster uses IPMT to compose and send email to customer Update 'customer request' record I2: LIR Assignment Request: An LIR asks the RIPE NCC for approval of an IPV4 Address assignment and the RIPE NCC replies. I2.1: LIRHostmaster formulates query F20: LIRH uses IPMT to produce a filled-out 141 Form. Gets data from customer, request and assignment records I2.2: LIRHostmaster sends request to NCC F21: Send request to RIPE-NCC by e-mail I2.3: LIRHostmaster handles response F22: Check response of RIPE-NCC and resent request if necessary -> repeat F20 I2.4: LIRHostmaster completes request F23: Update customer, request and assignment records. I3: LIR Allocation Request: An LIR asks the RIPE NCC for an IPV4 Address allocation and the RIPE NCC replies. I3.1: LIRHostmaster formulates query F30: Gets data from assignment and allocation records and fills out pro-forma request to RIPE-NCC. I3.2: LIRHostmaster sends request to NCC F31: Send request by e-mail. I3.3: LIRHostmaster handles response F32: Check response of RIPE-NCC and resent request if necessary -> repeat F30 I3.4: LIRHostmaster completes request F33: Update assignment and allocation records

1 0