- ncc-services-wg - mailman.ripe.net

Minutes from RIPE60
by Lindqvist Kurt Erik 04 May '11

04 May '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Apparently the WG minutes from RIPE 60 was never posted to the list. Please provide any comments or feedback ASAP on these. If noone objects we will post these in a week. Best regards, - - kurtis - - ---------- Minutes from RIPE 61 RIPE Meeting: 61 Working Group: RIPE NCC Services Status: Draft Revision Number: 1 * Content to the Chair of the working group. * Format to webmaster(a)ripe.net. RIPE 61 RIPE NCC Services Working Group Rome, 17 November 2010, 16:00 - 17:30 Co-Chairs: Kurtis Lindqvist, Bijal Sanghani (not present) A: Administrative Matters Kurtis Lindquist started the session at 16:00 local time. He welcomed the attendees, announced that the minutes from RIPE 60 were approved, and introduced the RIPE NCC senior management team. B. RIPE NCC Update - RIPE NCC Senior Management Team RIPE NCC's Axel Pawlik, Daniel Karrenberg, Paul Rendek, Jochem de Ruig and Andrei Robachevsky gave updates on the RIPE NCC's current activities. The presentations are available at: http://ripe61.ripe.net/presentations/331-Update_RIPE_NCC_R61.pdf Brian Nisbet, Anti-Abuse Working Group chair, asked the RIPE NCC to come up with a single plan to deal with all of the proposals being put forth with regards to the registry (anti-abuse and the membership, proactive checks on information, relationship towards sponsoring LIRs). He asked when the RIPE NCC might be able to produce such a plan. Daniel Karrenberg answered that the RIPE NCC are doing quite a lot already, including developing some ideas about data accuracy and maintenance in the database. He added that they haven't done much with reputation issues yet, but that Training Services have surveyed attendees at LIR training courses and we were currently studying the results. Daniel said that the RIPE NCC would work quickly on such a plan if they got clear direction from the community. He suspected that there might be some conflict of interest in what the anti-abuse working group wanted and other members of the community and that there needed to be consensus. He added that RIPE NCC was committed to working with the community on any such plan. Brian Nisbet added that the immediacy for the request was that 2010-09 and 10 were in discussion phase in the Anti-Abuse Working Group (and Database WG) and he doesn't want a lot of work to go into it unnecessarily. What they want to achieve is giving people what they want in the best way that the database and registry can provide. Brian said that he spoke to the proposers and they are willing to hold back discussions until the RIPE NCC comes up with an answer, but dates or an arrangement will have to be put in place some point in the near future. Daniel agreed and said the best strategy is to talk to each other about it to make sure everyone's going in the same direction. Shane Kerr from Internet Systems Consortium (ISC) praised the work going into governance and documenting processes. He asked Jochem de Ruig if the documentation process had any implications on the Policy Development Process. Jochem said it was a good point and that's why the RIPE NCC is going to carefully bring such documents forward to the community, and when there is a conflict, it needs to be discussed. He added that perhaps some pieces of a document would have to become a policy document, rather than a procedural document. Shane asked if these documents would be published through the RIPE NCC Services Working Group. Jochem replied that the documents would be published through the RIPE NCC Services Group and any other relevant Working Groups. C. RIPE NCC Processes and IPv4 Address Space End Game - Andrea Cima Andrea Cima from the RIPE NCC gave an update on the RIPE NCC Processes and IPv4 Address Space End-Game The presentation is available at: http://ripe61.ripe.net/presentations/332-andrea_PPt_Nov_2010-3.pdf James Blessing from Limelight Networks asked if the reason to have to agents checking each request was to speed the process up. Andrea said that was one part of it, and that it's also for improved consistency when they're down to the last few resources. James asked if there would be a delay in dealing with requests while people get used to having two people for every request. Andrea replied that he didn't foresee any big delays because having two people evaluating requests might actually speed it up. Alain Bidron from France Telecom asked about seeing firmer visibility on the depletion of the RIPE NCC's IPv4 pool. Andrea said that maximizing transparency was being discussed and he could not say if there would be a IPv4 depletion counter posted on the RIPE NCC website in the future. Niall O'Reilly from University College Dublin asked when the RIPE NCC would be in a position to say something about the introduction of non-allocation related registration services, particularly for the ERX community and for transfers rather than allocations. Andrea asked if he was asking about when the RIPE NCC runs out of IPv4. Niall said that there were two aspects of it. The first aspect is when IPv4 runs out and he expects a need to track transfers. The second aspect is the formalisation of the relationship with legacy resource holders. Andrea replied that in some cases, the ERX space holders are already members of the RIPE NCC and that they've moved their resources under the LIR umbrella. Andrea said that Rob could better answer the rest of the question. Rob Blokzijl, RIPE Chair, said that work was going on to define the registry of Internet resources currently in the RIPE NCC service region. He added that this was a registry of resources, not a list of resource holders. He emphasized that in one year, it will be difficult to explain to 'new kids on the block' the difference between a resource and a historical resource (ERX), which the RIPE NCC has administrative responsibility for. He added that in many cases, the RIPE NCC doesn't have a formal relationship with ERX holders, but that was a problem we needed to solve. Rob then proposed working on a unified registration policy. In short, Rob and the RIPE NCC are working on it and as soon as something is on paper, it will go out to the community. Daniel Karrenberg pointed out that the framework for this was already presented at RIPE 60. D. Update on the 2007-1 Project - Arne Kiessling Arne Kiessling from the RIPE NCC gave an update on 2007-01. The presentation is available here: http://ripe61.ripe.net/presentations/333-RIPE_61_Arne_Kiesslingv2.pdf There were no questions. E. Resource Certification - Alex Band Alex Band from the RIPE NCC gave an update on Resource Certification. The presentation is available here: http://ripe61.ripe.net/presentations/233-Certification-update-RIPE61.key James Blessing from Limelight Networks asked Alex to also keep a simple version for 2 a.m. emergencies and Alex agreed to it. F. LIR Closure and Deregistration Procedure - Athina Fragkouli Athina Fragkouli from the RIPE NCC gave an update on the Local Internet Registry (LIR) Closure and Deregistration Procedure document. The presentation is available here: http://ripe61.ripe.net/presentations/234-Closure_of_LIR_and_deregistration_… Sander Steffann asked how it could be the contributor's responsibility to de-register if they've gone bankrupt. He also asked Athina to clarify the usage of 'responsibility.' Athina said that the contributors manage resources, so if something happens the contributor, the procedure dictates that the NCC will take over. Rudiger Volk from Deutsche Telecom gave thanks for the difficult work that went into the document, a document that presented the big picture. He then asked about different meanings of failing for bankruptcy in different jurisdictions. He said that in Germany, legal system bankruptcy was not the right time for returning resources as they would be getting legal protection and could continue operations, so that was the point still to be ironed out. Athina agreed with Rudiger. Alain Bidron from France Telecom asked about having to comply with these rules within the RIPE NCC service region. Athina said that RIPE NCC is governed by Dutch law and must comply with Dutch court orders only. Lu Heng from Outside Heaven asked if the RIPE NCC has to validate legal orders from Dutch court only. Athina confirmed it that this was the case. Wilfried Woeber from ACOnet/Vienna University asked about the definition of a court order delivered by a local infrastructure, as he saw a potential hardship for End User assignments: If the sponsoring LIR got into trouble, the assignment would be lost. Athina said this needed further clarification but there was another document on contractual relationship changes between End User and a sponsoring LIR (the End User has to find another Sponsoring LIR). Yakovenko Volodymyr from Google asked what happens if the LIR is unresponsive to emails due to technical difficulties. Athina replied that there are several ways of contacting LIRs and this procedure is described in the document. Yakovenko then asked if the Dutch law jurisdiction is universal and applied everywhere in the world (as it is the case with UK law). Athina said that national authorities may have agreements between each other, but she could not specify the details. As time for the session was running out , Kurt suggested that further discussion on the topic should be taken to the mailing list. Z.A.O.B. There were no AOBs. Kurtis ended the session at 17:40 local time. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAk3BZYIACgkQAFdZ6xrc/t510QCgpMRF8cIztfHkU99Bp6nkyG18 hqsAniS4tRXvRNokrU9pzgBVT3pdELI+ =v3qk -----END PGP SIGNATURE-----

1 1

IPv6 RIPEness - One Year later
by Mirjam Kuehne 04 May '11

04 May '11

[apologies for duplicates] Dear colleagues, A year ago we introduced IPv6 RIPEness - a system that rates IPv6 deployment of Local Internet Registries based on certain criteria. Now, one year later, we were curious to see how the numbers have changed. Please read the update on RIPE Labs: http://labs.ripe.net/Members/becha/ipv6-ripeness-one-year-later Kind Regards, Mirjam Kuehne RIPE NCC

1 0

Announcement: New IPv6 information videos available now
by Nathalie Trenaman 28 Apr '11

28 Apr '11

Dear Colleagues, The RIPE NCC is pleased to announce the launch of four new information videos on real-life IPv6 deployment experiences. The following videos are now available in the RIPE NCC's E-Learning Centre at: http://www.ripe.net/lir-services/training/e-learning/ipv6 - Jan Žorž talks about "Mobile IPv6" - Tore Anderson gives an overview on "IPv6 and Content Providers" - Nuno Viera talks about "IPv6 in Hosting Environments" - Teun Vink is interviewed about "IPv6 and ISPs" The RIPE NCC E-Learning Centre is free and available to everyone. If you have any questions about this, please contact us at <e-learning(a)ripe.net>. Regards, Nathalie Trenaman Trainer RIPE NCC

1 0

Draft Agenda - NCC Services WG RIPE 62
by Bijal Sanghani 26 Apr '11

26 Apr '11

Dear All, Please see below Draft Agenda for the RIPE NCC Services Working Group - RIPE 62 16:00 Wednesday, 4 May 2011 A: Administrative Matters * Welcome * Scribe * Chat monitor * Microphone etiquette * Agenda B. RIPE NCC Update - RIPE NCC Senior Management Team (40 mins) C. Update on the 2007-1 Project - Arne Kiessling (10 mins) D. Resource Certification Update - Alex Band (15 mins) E. Update on RIPE NCC Governance Documents, Transfer Document - Athina Fragkouli (15 minutes) Z. AOB The agenda can also be found online - http://ripe62.ripe.net/programme/meeting-plan/ncc-services Kind regards, Bijal Sanghani The information contained in this e-mail message is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you should return it to the sender immediately. Please note that while we scan all e-mails for viruses we cannot guarantee that any e-mail is virus-free and accept no liability for any damage caused by any virus transmitted by this email.

1 0

Re: [address-policy-wg] 2008-08 New Draft Document Published (Initial Certification Policy in the RIPE NCC Service Region)
by Ruediger Volk, Deutsche Telekom T-Com - TE141-P1 25 Apr '11

25 Apr '11

Dear colleagues, > Dear Colleagues, > > Following the feedback received, the draft document for the proposal > described in 2008-08 was edited and published. > > The new impact analysis that was conducted for this proposal has also > been published. > > You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2008-08 > > and the draft document at: > > http://www.ripe.net/ripe/policies/proposals/2008-08/draft > > We encourage you to read the draft document text and send any comments > to address-policy-wg(a)ripe.net before 26 April 2011. I agree to passing this policy in this (or the previous version 3.0 of 2011-02-09) form. My objection to excluding IPv6 has been taken care of (while I note that the undated NCC certification FAQ anyway tells "... certify their PA address allocations. This includes both IPv4 and IPv6 ...", and ripe-513 dated 2011-02-07 even in the title did know about PA space in IPv6 context). (my mail of Date: Thu, 24 Feb 2011 00:00:40 +0100) I'm not aware what concern or argument has been raised in order to include IPv4 "ALLOCATED UNSPECIFIED"; this inclusion seems to be opposite direction to quickly covering the most simple cases. I'd not be surprised if later on some complications with this hit. I'm NOT seeing this as a show stopper. Beyond these changes my arguments and concerns from the last revision (my mail from Date: Thu, 24 Feb 2011 00:00:40 +0100) essentially still apply - but I did NOT raise them as show stoppers then, and still regard them again as challenges for making required further progress. Looking forward to discuss required and planned activities at RIPE62. It is not easy to track what actually has changed, and a summary of changes actually would seem helpfull for discussing revised proposals; in particular I'm not sure about the 4 related documents. The only one I somewhat accidentally know that it has not changed is the CPS (that's still the one dated 2010-12-30 which is clearly different from the previous draft of 2010-11-01). Is ripe-517 (dated 2011-03-07) the same as the previously referenced draft? What about the two (undated!) terms and conditions documents? Regards, Ruediger Ruediger Volk Deutsche Telekom AG -- Internet Backbone Engineering E-Mail: rv(a)NIC.DTAG.DE

1 0

Analysis of the ‘Maximum Length’ Option in Certification ROAs
by Alex Band 20 Apr '11

20 Apr '11

[apologies for duplicates] Dear colleagues, We just published an article on RIPE Labs on the usage of the 'Maximum Length' option in ROAs. We compared all the prefixes in the Repository which are covered by a ROA to the prefixes seen by RIS. It gives a good indication how people are using this option, and what the effects are when people base routing decisions on validation results. You can read the article here: https://labs.ripe.net/Members/AlexBand/using-the-maximum-length-option-in-r… Kind regards, Alex Band Product Manager

2 2

Proposal to Introduce SHA2 Passwords in the RIPE Database
by Denis Walker 20 Apr '11

20 Apr '11

[Apologies for duplicate emails] Dear Colleagues, What follows is a short proposal to introduce SHA2 passwords as an authentication method in MNTNER objects in the RIPE Database. Regards, Denis Walker Business Analyst RIPE NCC Database Group Proposal to Introduce SHA2 Passwords in the RIPE Database The RIPE NCC has looked at the possibility of introducing SHA2 as a password algorithm, as requested by AP61.2. >From a technical point of view this is certainly possible. There are C and Java libraries available for generating SHA2 algorithms. We can provide SHA2 as an additional password option alongside MD5. In addition we would also provide a web service to generate SHA2 passwords similar to the one provided for MD5. If the community requires MD5 to be deprecated we would suggest fixing a time period for users to update their MNTNER objects. From the start of that period no MD5 passwords can be added to a MNTNER, but existing ones will remain valid. At the end of that period the RIPE NCC can replace/remove all remaining MD5 passwords. As with the crypt-pw deprecation, we would provide an automated web service to reinstate access to a MNTNER object if you can validate against one of the original MD5 passwords. The time limits used for the crypt-pw deprecation were a 6 month period for users to update their MNTNER objects and a 3 year period to reinstate user access via the web service.

1 0

Proposal to Change the Dash ('-') Notation in Reverse DOMAIN Objects
by Denis Walker 18 Apr '11

18 Apr '11

[Apologies for duplicate emails] Dear Colleagues, What follows is a short proposal to change the process of creating and updating reverse DOMAIN objects in the RIPE Database. Because this is a proposed RIPE Database change, please direct any discussion to the RIPE Database Working Group mailing list to keep it focused in one place. Regards, Denis Walker Business Analyst RIPE NCC Database Group Proposal to change the dash ('-') notation in reverse DOMAIN objects Introduction ------------ Reverse delegation DOMAIN objects allow the use of a dash ('-') in the syntax. The current arrangement causes problems with DNSSEC. We propose to drop the current behaviour. We would also introduce a new syntax using the dash notation to avoid the need for manual intervention for classless delegations. Both the current and the new behaviour described in this document only apply to IPv4 delegations. Feature to be deprecated ------------------------ Currently, we allow a dash in the third octet of an IPv4 reverse delegation. So, for the address range 10.2.1.0 - 10.2.100.255, the syntax allows a reverse delegation DOMAIN object to be submitted as 1-100.2.10.in-addra.arpa. The RIPE Database update software will expand this into 100 separate objects in the database with prefixes from 1.2.10.in-addra.arpa to 100.2.10.in-addra.arpa. Apart from the prefix, all the other data in the submitted object will be duplicated in all 100 objects. To modify or delete this set of objects, the user has to process all 100 objects individually. No bulk operations are possible after the original object has been expanded in the database. This feature is not compatible with using DNSSEC. The value of the "ds-rdata:" attribute is a hash that includes the delegation. By definition, this must be different for each DOMAIN object. These different hash values for multiple objects cannot be entered by submitting a single object with the dash notation. This issue was raised by members of the DNS community, and the RIPE NCC now proposes to deprecate this update feature. Feature to be added ------------------- Classless delegations, according to RFC2317 (http://www.ietf.org/rfc/rfc2317.txt), are currently handled manually by the DNS Department at the RIPE NCC. Although the objects can be created in the RIPE Database, they will not be propagated to the zone files. The RIPE NCC proposes to allow a dash in the fourth octet of an IPv4 reverse delegation. So, for the address range 10.2.1.6 - 10.2.1.25, the syntax would allow a reverse delegation DOMAIN object to be submitted as 6-25.1.2.10.in-addra.arpa. This object would not be expanded by the RIPE Database update software into 20 separate objects, as it is with the feature described above. It would be created in the database as a single object, including the dash in the range. New DNS provisioning software would handle the new dash notation and propagate this delegation to the zone file. However, the range 0-255 is a special case and would not be allowed in the fourth octet. Modification and deletion can be performed on the single object in the database. Any change would be propagated into the zone file by the new delegation software.

6 10

APNIC Announces its IPv4 Address Pool Reaches Final /8
by Axel Pawlik 15 Apr '11

15 Apr '11

[Apologies for duplicate emails] Dear Colleagues, Today, Friday 15 April 2011, APNIC, the Regional Internet Registry (RIR) for the Asia Pacific region, announced that it has distributed the final IPv4 address space from its reserves of IPv4. This means that APNIC is now supplying IPv4 address space to its members from the last /8 it holds according to the guidelines in section 9.10 in "Policies for IPv4 address space management in the Asia Pacific region": http://www.apnic.net/policy/add-manage-policy This event does not affect the RIPE NCC's reserves of IPv4 address space and we will continue to distribute these resources to our members on the basis of need until we reach the last /8. According to RIPE Document ripe-509, section 5.6, once the RIPE NCC reaches the last /8 of IPv4 address space, each Local Internet Registry (LIR) can receive one /22 (1024 IPv4 addresses) upon application for IPv4 resources. In order to obtain this /22 allocation, the LIR must already have an IPv6 allocation and have a demonstrated need for address space. IPv6 - Act Now --------------- The RIPE NCC cannot predict how long its own supply of IPv4 address space will last and has worked for several years to inform all stakeholders of the urgent need to deploy IPv6. It is now imperative that all stakeholders deploy IPv6 on their networks to ensure the continuity of their online operations and the long-term growth of the Internet. For more information on IPv6 and its deployment, advice from experts and where to get training, please see: www.ipv6actnow.org Further Information -------------------- For more information on IPv4 exhaustion, please see: http://www.ripe.net/internet-coordination/ipv4-exhaustion For more information on how the RIPE NCC's last /8 will be distributed, please see: http://www.ripe.net/ripe/docs/ripe-509 For information about the amount of IPv4 address space left in the RIPE NCC's available pool of IPv4, please see the graph online at: http://www.ripe.net/internet-coordination/ipv4-exhaustion/ipv4-available-po… Regards, Axel Pawlik Managing Director RIPE NCC

1 0

Next RIPEstat live demo on 19 April 2011
by Mirjam Kuehne 14 Apr '11

14 Apr '11

[apologies for duplicates] Dear colleagues, The next RIPEstat Live Demo is scheduled for Tuesday, 19 April 2011 at 11:30 - 12:00 Amsterdam time (9:30 - 10:00 UTC). Please observe the change to summer time. I hope you will join us. Details on how to join the demo session can be found on RIPE Labs: http://labs.ripe.net/Members/markd/ripestat-live-demo-4 The minutes of the last sessions and some more information about RIPEstat can be found on RIPE Labs: http://labs.ripe.net/ripestat Kind Regards, Mirjam Kuehne RIPE NCC

1 0