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

New RIPE NCC PGP Key
by Andrea Cima 27 Dec '10

27 Dec '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [Apologies for duplicate e-mails] Dear Colleagues, On Wednesday, 5 January 2011 we will start using our 2011 key to sign e-mail from our ticketing system. The new key has been signed by the old key as described in the key-management policy on our web site: https://www.ripe.net/rs/pgp/index.html The old key remains valid until Thursday, 3 February 2011. If you have any questions about this, please contact <ncc(a)ripe.net>. Kind Regards, Andrea Cima RIPE NCC -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAk0YtfEACgkQXOgsmPkFrjOY9wCgtImM+qFN1KAqyVniORJ8jbf8 P9UAoKn11gqoeDn1QCx+S4A0YkBqeHgR =fHuQ -----END PGP SIGNATURE-----

1 0

2007-01 Policy Implementation - 4 January 2011 Last Day to submit End User Documentation
by Arne Kiessling 21 Dec '10

21 Dec '10

Dear Colleagues, The RIPE NCC will finish Phase Two of the 2007-01 policy implementation "Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region" at the beginning of January 2011, as was announced during the RIPE NCC Services Working Group session at RIPE 61. LIRs have until 4 January 2011 to upload the required documentation for the independent resources they have marked as "My End User". This is a hard deadline; the uploading tool will no longer be available on the LIR Portal after 4 January 2011. This step is necessary to start Phase Three of the policy implementation in January 2011. The RIPE NCC will publish the procedure document for Phase Three of the policy implementation, and any other necessary information, before Phase Three starts. Draft procedure document: http://www.ripe.net/news/2007-01-phase3.html Information on the documentation required: http://ripe.net/rs/pi-existing-assignments.html Please contact <enduser-contract(a)ripe.net> if you have any questions or comments. Kind regards, Arne Kiessling IP Resource Analyst RIPE NCC

1 0

Changes to Reverse DNS DOMAIN Objects in the RIPE Database
by Denis Walker 09 Dec '10

09 Dec '10

[Apologies for duplicate mails] Dear colleagues, It was agreed at RIPE 59 in Lisbon that reverse DNS zones in the RIPE Database should not have child objects. Documentation relating to this decision and the discussion surrounding it can be found in the minutes of the RIPE 59 DNS and Database Working Groups: http://www.ripe.net/ripe/wg/dns/r59-minutes.html http://www.ripe.net/ripe/wg/db/minutes/ripe-59.html The RIPE NCC is now ready to deploy this change and clean-up the existing data. This will be done in the week commencing 13 December 2010. After deployment it will not be possible to create a reverse DNS DOMAIN object in the RIPE Database if either a more or less specific object already exists. During the data clean-up you may receive a notification that your DOMAIN object has been deleted. If this is the case there will be a less specific DOMAIN object in the database. Your object was only for documentation purposes and did not have any effect on reverse DNS. If you have any questions please contact us at <ripe-dbm(a)ripe.net>. Regards, Denis Walker Business Analyst RIPE NCC Database Group

1 0

RIPE NCC Resource Certification System: Initial Deployment 1 January 2011
by Alex Band 01 Dec '10

01 Dec '10

Dear colleagues, With just seven IPv4 address blocks available in the IANA pool, we are hurtling towards the end of an era. With this prospect, the registry function of the five Regional Internet Registries (RIRs) is going to be crucial to the Internet community. More than ever, it is important to know who is the legitimate holder of a block of IP addresses. With this as a primary driver, the RIPE NCC (in coordination with the other four RIRs) is planning to deploy a system that attaches digital certificates to Internet number resources (IP address blocks and Autonomous System (AS) Numbers). A more complete description of the benefits of resource certification can be found at: http://www.ripe.net/certification/ The RIPE NCC has had a beta platform for certification up and running for several months now. More than 100 RIPE NCC members have enabled certification under this pilot program, providing the RIPE NCC with valuable feedback. On 1 January 2011, the RIPE NCC will launch a hosted production system, which will allow all LIRs to generate a certificate of holdership, which will be held in a repository maintained by the RIPE NCC. Network operators will also be able to start making routing decisions based on the system as of this date. Further iterations of this system will be deployed over the coming 12 months, including the option for LIRs to host their own Certificate Authority and generate certificates for their own customers. Digital certificates have helped make business on the Internet more secure. Now we are using resource certificates to make the Internet itself more secure. For more information, please visit: http://ripe.net/certification If you have any questions or comments, please email <ncc(a)ripe.net>. Best regards, Alex Band Product Manager, RIPE NCC

3 2

NCC Services draft minutes from RIPE 61
by Amanda Gowland 01 Dec '10

01 Dec '10

Hi Kurtis and Bijal, Please find attached the draft minutes from RIPE 61. Can you please distribute to the WG for comment? Once we've received your approval, we will publish the draft minutes to the website. Many thanks, Amanda -------------------------- 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.

1 0

Returning Unannounced Legacy Space
by Mirjam Kuehne 17 Nov '10

17 Nov '10

Dear colleagues, Are you willing to make resources available for reallocation? Read more on RIPE Labs: http://labs.ripe.net/Members/mirjam/returning-unannounced-legacy-ipv4-addre… This will also be presented later today in the NCC Services WG. Kind Regards, Mirjam Kuehne RIPE NCC

1 0

Announcement: RIPE NCC Training Courses
by Training Mailbox 16 Nov '10

16 Nov '10

[Apologies for duplicate e-mails] Dear Colleagues, The RIPE NCC invites you to register for one of our upcoming training courses: - The LIR Training Course This course teaches LIRs how to request Internet number resources and interact with the RIPE NCC. A course outline is available at: http://www.ripe.net/training/lir/outline.html - The Routing Registry Training Course This course teaches LIRs how to use the RIPE Database for routing. A course outline is available at: http://www.ripe.net/training/rr/outline.html - The IPv6 Training Course This course teaches LIRs about the need for IPv6 and includes basic information on how to plan your deployment. A course outline is available at: http://www.ripe.net/training/ipv6/outline.html To see the location of upcoming courses and to register, please use the LIR Portal or complete the registration form on our website at: RIPE NCC Upcoming Courses List & Registration https://lirportal.ripe.net/lirportal/training/course-list.html If you have any questions, please do not hesitate to contact us at <training(a)ripe.net>. Kind regards, Rumy Kanis Training Services Manager RIPE NCC

1 0

LIR Portal Migration is done
by Mirjam Kuehne 16 Nov '10

16 Nov '10

Dear colleagues, In addition to the announcement sent out yesterday, you can find some more information about the new LIR Portal on RIPE Labs: https://labs.ripe.net/Members/mirjam/lir-portal-migration-main-improvements Kind Regards, Mirjam Kuehne RIPE NCC -------- Original Message -------- Subject: [staff] [ncc-announce] LIR Portal Migration is done Date: Mon, 15 Nov 2010 17:18:47 +0100 From: Kaveh Ranjbar <kranjbar(a)ripe.net> Reply-To: kaveh.ranjbar(a)ripe.net To: ncc-announce(a)ripe.net Dear RIPE NCC members, We are proud to announce that the LIR Portal migration project is completed. This means we migrated the LIR Portal to a completely new platform that supports the RIPE NCC's modern back-end technologies. We will be able to respond much faster to changes and will be better able to maintain the LIR Portal. Please email <sw-bugs(a)ripe.net> if you have any issue or suggestion concerning the LIR Portal. More detailed technical information will be published on RIPE Labs shortly. Kind regards, Kaveh Ranjbar, Senior Software Engineer, Business Applications Department, RIPE NCC

1 0

Discrepancy between WHOIS and delegated-ripencc
by Peter Kosinar 06 Nov '10

06 Nov '10

Hello! This might not be the appropriate place for my question; if that is so, I apologize in advance. I've noticed that the data provided by the RIPE WHOIS database is sometimes inconsistent with the data shown in the delegated-ripencc-latest file, available from the ftp://ftp.ripe.net/ripe/stats/ server. For example, consider these two entries: ------------------------------------------------------- $ whois 91.212.135.0/24 inetnum: 91.212.135.0 - 91.212.135.255 netname: YABA-NET descr: YabaMedia Ltd country: RU $ grep 91.212.135.0 delegated-ripencc-latest ripencc|CZ|ipv4|91.212.135.0|256|20090409|assigned ------------------------------------------------------- $ whois 193.105.207.0/24 inetnum: 193.105.207.0 - 193.105.207.255 netname: ALFAHOSTNET descr: Alfa-host LLP. country: KZ $ grep 193.105.207.0 delegated-ripencc-latest ripencc|CZ|ipv4|193.105.207.0|256|20100315|assigned ------------------------------------------------------- As you can see, the data differs in the "country" field -- in both cases, the range is attributed to Czech Republic, while the block is actually assigned to anothers. Since the delegated-ripencc-latest file is used by some reputable and often-used sources (like Team Cymru; http://www.team-cymru.org/Services/ip-to-asn.html), this can sometime result in misleading and completely useless reports (as you can probably guess, it was Czech Republic getting unfair load of hostile sites attributed to it). There are two questions now: 1) What is the source of this discrepancy? 2) If it was caused by some kind of an error, can the databases be put in sync? If it is intentional, which source is more "reliable"? Thanks, Peter -- [Name] Peter Kosinar [Quote] 2B | ~2B = exp(i*PI) [ICQ] 134813278

3 2

Draft Agenda - NCC Services WG - RIPE 61
by Bijal Sanghani 05 Nov '10

05 Nov '10

Dear All, Please see below the draft agenda for the NCC Services Working Group - DRAFT: Services WG Agenda - RIPE 61 A. Administrative Matters Welcome Select a Scribe Distribute participants list Finalise agenda Approve minutes from RIPE 60 B. RIPE NCC Update - RIPE NCC Senior Management Team (35 min) C. RIPE NCC Processes and IPv4 Address Space End-Game - Andrea Cima (15 min) D. Update on the 2007-1 Project - Arne Kiessling (10 min) E. Resource Certification - Alex Band (15 min) F. LIR Closure and Deregistration Procedure - Athina Fragkouli (15 min) Z. AOB You can also find the agenda here - http://ripe61.ripe.net/programme/meeting-plan/services-agenda/ look forward to seeing you in Rome! 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