Please send me your comments, updates & corrections. Many thanks to Roger for providing theese minutes. -hph Minutes of the LIR Working Group session of the RIPE 37 Meeting held at the Grand Ballroom of the Krasnapolsky Hotel in Amsterdam on September 13, 2000 -------------------------------------------------------- Chair: Hans Petter Holen Scribe: Roger Arcilla, RIPE NCC AGENDA 1. Admin scribe, participant list, charter, mailinglists 2. Agenda 3. Meet the RIPE NCC hostmasters 4. RIPE 36 Minutes Actions 5. Report from the RIPE NCC Hostmasters by Nurani Nimpuno 5. Reports from the other registries APNIC (ARIN sends their apologies) (ICANN) (Status of the LACNIC and AFRI NiCs) 6. Report from the Address Council by Hans Petter Holen, Wilfried Woeber, Sabine Jaume 7. Restoring the Transparency by Masataka Ohta 8. Report from the 17th of may Task Force by Stephen Burley 9. PGP for hostmaster@ripe.net. (35.4 and 35.5) by Olaf Kolkman 10. Election procedures for the Address Council 11. Presentations of Candidates for the AC election 12. Status of the ICANN ad Hoc group 13. RIPE 174 Abitravtion Philip Bridge, Nextra (Schweiz) AG 14. AOB. Note that issues concerning IPv6 policy will be discussed in a separate session. =========================================================================== 2. Agenda: The Chair, Hans Petter Holen, noted that he has sent the "3rd Draft Agenda LIR-WG 37" shown above to the mailing list <lir-wg@ripe.net>. Since he has received no suggestions for changes, it is considered approved by the body. 4. RIPE 36 Minutes: Hans Petter Holen called the attention of the body that the minutes of RIPE 36 has been in the RIPE NCC web site for sometime after the RIPE 36 Meeting in Budapest in May 2000. No one has proposed any changes or corrections. It is declared approved by the body. 5. Report from NURANI NIMPUNO, RIPE NCC Registration Services Manager http://www.ripe.net/ripe/meetings/archive/ripe-37/presentations/ Some points NOT in the slide presentation: * Nurani introduced the RIPE NCC Hostmasters one by one. * The May 17 in the name "May 17th Task Force" was after the National Day of Norway when the task force was formed during the RIPE 36 Meeting in Budapest, Hungary held from May 16 to 19, 2000. (The Chair of the LIR Working Group comes from Norway.) * At the end of the slide presentation, Nurani asked if there are any questions from the audience. HANS Petter Holen recalled that during the RIPE 36 in Budapest, the problem of the wait queue was also taken up and proposals presented to solve the problem. He also expressed understanding of the enormous problems faced by Registration Services of RIPE NCC as indicated in the presentation of Nurani. NURANI Nimpuno indicated that RIPE NCC is exerting its utmost with regards the problem of the wait queue; hiring more Hostmasters, patiently training them, and the Software department programming more tools to automate the processes involved in evaluating IP assignment requests. Furthermore, Nurani explained that intense efforts have been made to target the newer LIRs that often are not completely familiar with the relevant policies and procedures by improving documentation, further developing an FAQ and a TIPS page and by creating a Helpdesk Mailbox. The hope is that by making the information more available to the members it will reduce the educational workload on the Registration Services. Nurani also reported that RIPE NCC has had several fruitful discussions with the May 17th Task Force which resulted in many useful suggestions. However, these proposals are waiting for the input from the LIR Working Group before they can be implemented and have an actual effect. She acknowledged that the effects of some of these efforts may not be immediately visible to the membership and indeed the wait queue is still higher than normal. However she did express the confidence that these combined efforts will have its effect in the long term. (APPLAUSE after the presentation and additional statement of Nurani Nimpuno) 5. Report from other Regional Internet Registries: APNIC: Report from GERARD ROSS, Documentation Manager of Asia Pacific Network Information Centre. http://www.ripe.net/ripe/meetings/archive/ripe-37/presentations/ Some points NOT in the slide presentation: * APNIC has expanded its staff by more than 3 times during the last 18 months, from 6 staffmembers to 21. * While here for the RIPE 37 Meeting in Amsterdam, he had extensive talks with Paul Rendek (RIPE NCC Communications Officer) for closer coordination and cooperation between APNIC and RIPE NCC. (APPLAUSE after the APNIC presentation) ARIN: MIRJAM KUEHNE (Head of External Relations of RIPE NCC) said that ARIN (American Registry for Internet Numbers) has sent its apologies that it could not send a delegate to the RIPE 37 Meeting. - -------------------------------------- 7. RESTORING THE TRANSPARENCY - -------------------------------------- Presentation with slides by MASATAKA OHTA, Ph. D, Research Associate at the Computer Center of Tokyo Institute of Technology. http://www.ripe.net/ripe/meetings/archive/ripe-37/presentations//address/ind ex.html NOTE: There was a line up of speakers before the microphone and a barrage of questions after Mr. Ohta's presentation, which stimulated a lively and spirited discussion on the ideas he presented. STEPHEN BURLEY: "That is suicide!" [Mr. Ohta's proposal]. "Why? Why limit an already limited resource to a few ISP/providers using IPv4. In other words, use up all the IP's left and force people to use IPv6. Rather like digging up all the coal left in the world to force people to use gas power stations. It is not a practical suggestion and IPv6 will naturally be taken up as systems become ready and services (mobile) demand more space for valid uses. "We are forcing people into a corner in which they have no choice" MASATAKA OHTA: "I am just giving incentive, but if you call it 'forcing people', then Usage Based Allocation, which you are using, is forcing people to use NAT." GUY VEGODA: On the need to speed up IPv6 take up, I'd say that IP preservation is working. It is not currently a huge problem as the amount of space that exists will last well into an era of IPv6. If it ain't broke - don't fix it. Augment it, perhaps, as the IPv6 technology will not replace IPv4, certainly not at the beginning. The number of entities that will refuse to renumber, even in an environment of IPv6 deployment will cause a widespread use of v4 to v6 translation. When the technology has been proved stable and is cost efficient, the rapid depreciation and turnover of routing hardware will mean that it is slowly implemented as part of a natural course of events. Most LIRs, if they have not already, are soon seeing that the lifespan of a technology five or ten years ago is already plummeting to, in many cases, less than three years. Technology will naturally be replaced, and we know that the equipment manufacturers will be moved by market forces to implement IPv6, when the market is ready. Certainly, Juniper as of this moment have not announced any IPv6 equipment. If IPv6 is forced, it'll be a rushed job. We do not want to force the issue. Where the technology is so far unfinished, buggy and incomplete, if we were to deploy it now, you just KNOW that it would cause havoc. Many people want NAT for reasons other than IP preservation. It is a useful form of security, fire-walling and IP masquerading. Many customers want NAT for their own reasons. Therefore, they should be allowed to make use of the technology. Since customers do not want it yet, there is a certain lack of point in forcing LIRs to "switch over". I am telling you now, there is no way that you are going to get every small network in Europe or the world to renumber. In essence, IPv6 will come when its ready, and to begin with, as an extension to IPv4, not a replacement. It is my opinion that because of the safety net that NAT provides, and because of the familiarity of IPv4, that it would always be preferable to suffer a long IPv6 implementation curve, than to suffer the consequences of too hasty an implementation. Another SPEAKER: It is not good to consume IPv4 address space quickly. MASATAKA OHTA: "It will be consumed anyway. What is important is to consume it wisely." Another SPEAKER: We should wait for a while because it's not yet time. MASATAKA OHTA: "It is the time." WILFRIED WOEBER: "My statements are neither in support of the recommendations of Mr. Ohta in the draft, nor are they meant to criticise the draft. I urge everyone in the community to read the draft, as it clearly describes some fundamental issues in today's IPv4-based Internet. "In response to Stephen Burley's comments on fairness, I think that the current approach to IPv4 address distribution is intrinsically unfair, when taking into account that someone has a "Class A" address sitting on a shelf, or some smaller university has got hold of a Class B in the past, while we bug the new kids on the block to demonstrate the need for a, say, /26. "In particular, the thoughts expressed by Mr. Ohta in the draft become even more interesting when seen in the light of the presentations and assertions during Tuesday's (Sept. 12) mobile communications stream at the European Operators' Forum." (APPLAUSE after presentation and Q & A part of Mr. Ohta.) - ------------------------------------------------------------------------- 8. Report from the 17th of May Task Force Presentation with slides by STEPHEN BURLEY of the May 17th Task Force - ------------------------------------------------------------------------- http://www.ripe.net/ripe/meetings/archive/ripe-37/presentations/ BEFORE the presentation, Hans Petter Holen, LIR Working Group Chair, explained the background of the formation of the May 17 Task Force, among which is the improvement of services to the membership. AFTER his presentation, Stephen Burley of the May 17 Task Force asked the audience if they have any ideas regarding the proposals in the presentation, and encourage them to present them at the meeting. The proposals on a FLEXIBLE ASSIGNMENT WINDOW and AUTOMATIC APPROVALS of IP address space request after a certain number of days in the wait-queue drew several responses, some of them are quoted below. Several participants and speakers had an extended discussion and exchange of ideas and arguments on the merits and demerits of the proposals. Some called for caution and time to study the matter. Some asked more questions, "Is that the best way to go." Some agreed with the proposals, that the flexible Assignment Window is the way to go forward. Some suggested to get the opinions of RIPE NCC Hostmasters. STEPHEN BURLEY called for a consensus on the proposals the Task Force presented. The Task Force was not set up, he said, to answer all questions; it will act as a catalyst and help in finding solutions to the problems of the community. NURANI NIMPUNO recalled that since the RIPE 36 Meeting in Budapest, some of the proposals from the May 17 Task Force have been implemented, like the setting up of the LIR Help Mailbox, improving documentation, creating a Hostmaster Centre at the RIPE meeting, etc. Radical proposals like a flexible Assignment Window, she said, could be discussed further but would need the approval from the LIR Working Group before it could be implemented by the RIPE NCC. JOHN LEROY CRAIN: (Concerning the proposal of the May 17 Task Force) "The idea of a flexible Assignment Window needs serious reconsideration. Those that have an Assignment Window of 0 should not be raised. The fact that they have a zero Assignment Window shows that they need all their requests reviewed. To audit all of the tagged requests, after the fact, will actually create more work for the Hostmasters and if they turn out to be unjustified assignments then returning the address space is not an option. Commercial bodies cannot take back services from a customer easily. "The issue of Allocations being delayed is technically solvable with ease. Allocation requests are easily identifiable and could be moved to the top of the wait queue. That assumes though that this is what the community wants. "The idea of having Local Internet Registries actively pre-check their data before requesting allocations, keeping their house in order, is one I support. This will lessen the work of Hostmasters and reduce the wait queue." ANA SUSANJ: (RIPE NCC Hostmaster) With regards the proposal for a flexible Assignment Window and also the 5-day automatic approval, I would like to express the concern that this might be open to abuse. It wouldn't be difficult for a Registry to get its Assignment Window raised by sending a few /25 requests for a /23. This way they: 1. increase the number of approvals in their registry records 2. increase the number of tickets in the wait queue 3. from 2, it follows that this can bring us to 5+ days long wait queue 4. from 3, this would take us to automatic approvals 5. automatic approvals would lead to a low wait queue in the beginning, but it follows that from this Hostmasters would have many more auto-approved tickets to audit. ANNELOES VAN AARST: (RIPE NCC Hostmaster) With regard to the proposal for automatic approvals, I would like the Task Force to take security into consideration. As long as the PGP signing for Hostmaster mails is not in place, the only way to check if a request is from a valid contact person - at the moment - is checking the address of the sender manually. It would be very bad if automatic approvals would be sent to non-contacts, or even worse end users. (APPLAUSE after presentation and Q & A session) - ------------------------------------------------ 9. PGP for Hostmaster@ripe.net Presentation with slides by OLAF KOLKMAN - ------------------------------------------------ http://www.ripe.net/ripe/meetings/archive/ripe-37/presentations/ Question-and-Answer after the presentation: DAVID PRATT: Is it possible to use two Master keys, one as a backup stored off-line and one for regular communication. If one of the Master keys gets compromised then the ability to communicate still exists. OLAF KOLKMAN: It's suggested to store the Master Key off-line and use a slave key in the day-to-day communication. This has the same effect. NOTE: Although the WaveLAN setup was outside the scope of his talk, Olaf issued the warning that WaveLAN is not a trusted environment, that it is a shared medium where passwords in-the-clear are not safe. (APPLAUSE after presentation and Q & A of Olaf Kolkman) - -------------------------------------------------- 10. Election procedures for the Address Council Presentation with slides by HANS PETTER HOLEN - -------------------------------------------------- At this point, the time alloted for the LIR Working Group session was up. It was suggested that important matters not taken up due to lack of time be presented at the Plenary Session.