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

Updated RIPE NCC Procedural Document Available
by Arne Kiessling 15 Mar '11

15 Mar '11

Dear Colleagues, The RIPE NCC has published an updated procedural document, ripe-518, "Implementation of RIPE Policy 'Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region' - Phase 3". This document replaces ripe-511, which was published recently. The updated document is available at: http://www.ripe.net/ripe/docs/ripe-518 -- Kind Regards Arne Kiessling IP Resource Analyst RIPE Network Coordination Centre

2 2

New RIPE NCC Procedural Document Available
by Arne Kiessling 10 Mar '11

10 Mar '11

Dear Colleagues, The RIPE NCC has published the new procedural document ripe-511, "Implementation of RIPE Policy 'Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region' - Phase 3". This document describes the RIPE NCC procedure when contacting End Users of independent Internet number resources who have not yet entered into a contractual relationship with sponsoring Local Internet Registry (LIR) or the RIPE NCC. It also describes the possible consequences if End Users of independent Internet number resources fail to respond when approached by the RIPE NCC or are not compliant with the policies of the RIPE community. The new document is available at: http://www.ripe.net/ripe/docs/ripe-511 -- Kind Regards Arne Kiessling IP Resource Analyst RIPE Network Coordination Centre

2 1

Closure of LIR and Deregistration of Internet Number Resources
by Axel Pawlik 10 Mar '11

10 Mar '11

[Apologies for duplicate emails] Dear colleagues, The RIPE NCC, after receiving feedback from the RIPE community on the draft version, has published the procedural RIPE Document ripe-517, "Closure of LIR and Deregistration of Internet Number Resources". The document is available at: https://www.ripe.net/ripe/docs/ripe-517 This document replaces sections in two RIPE Documents that deal with the closure of LIRs and the deregistration of resources: - Sections 3.0 and 4.0 of ripe-301, "Mergers, Acquisitions, Takeovers and Closures of Organisations Operating an LIR". These sections are entitled "Closing an LIR" and "When an LIR is Closed by the RIPE NCC", respectively. The updated version of this RIPE Document is available at: https://www.ripe.net/ripe/docs/ripe-515 - Sections 4.0, 4.1 and 4.2 of ripe-475, "Independent Internet Number Resources - Contractual Relationship Changes between sponsoring LIR and End User". These sections are entitled “De-registering of Independent Internet Number Resources”, “Closure of Sponsoring LIR” and "Violation of RIPE Policy, Law or Contract", respectively. The updated version of this RIPE Document is available at: https://www.ripe.net/ripe/docs/ripe-516 The RIPE NCC would like to thank the RIPE community for its feedback. An interactive chart that helps to explain the process of closure of LIRs and deregistration of Internet number resources will be available shortly. Best regards, Axel Pawlik Managing Director RIPE NCC

1 0

documentation about the minimum allocation/assignment sizes for v4 and v6 across the RIRs
by Wilfried Woeber, UniVie/ACOnet 10 Mar '11

10 Mar '11

I got a request from one of our customers, regarding documentation of the minimum allocation and assignment sizes of the various IPv4 and IPv6 address blocks. The initial cause of the research was creating filters that reasonably allow IPv6 PI prefices (which are longer than /35 or /32). I found the relevant info for the RIPE NCC's Service Region in http://www.ripe.net/ripe/docs/ripe-510 Now I am wondering - does anyone have a list of URLs or pointers to docs for the other 4 RIRs, which would provide similar information? As an aside, it would be nice to have such information accessible in one place, maybe by way of the NRO's website :-) TIA, Wilfried.

1 0

Results of Registry Quality Data project on RIPE Labs
by Mirjam Kuehne 08 Mar '11

08 Mar '11

Dear colleagues, In 2009 the RIPE NCC started the Registry Data Quality project. A new article on RIPE Labs describes this activity, the problems we found and how we fixed them: http://labs.ripe.net/Members/xavier/ensuring_registry_data_quality Kind Regards, Mirjam Kuehne RIPE NCC

1 0

Outage Report for RIPE Database Updates
by Agoston Horvath 07 Mar '11

07 Mar '11

[Apologies for duplicate emails] Dear colleagues, Between approximately 13:25 and 13:48 (UTC) on 7 March 2011, we experienced an outage of the RIPE Database update service. During this period, no updates were processed. It was not possible to access the update service via any of the web-based or synchronous interfaces. Updates sent via email are queued and will be executed later. However, we recommend that users check their acknowledgement reports. We apologise for any inconvenience this may have caused. Regards, Paul Palse Database Group RIPE NCC

1 0

Short video explaining Resource Certification
by Alex Band 06 Mar '11

06 Mar '11

Dear colleagues, Under the NRO flag, we have just released a short video about Resource Certification, explaining what it is and why it is important for your organisation: http://youtu.be/rH3CPosGNjY For information on how to set up and use the hosted Resource Certification service the RIPE NCC provides, please watch this video we posted earlier: http://youtu.be/Q0C0kEYa1d8 Kind regards, Alex Band Product Manager, RIPE NCC

4 4

Whither dnsmon?
by Hank Nussbacher 04 Mar '11

04 Mar '11

RIPE NCC lists dnsmon here: http://www.ripe.net/data-tools/stats/dnsmon/ripe-ncc-dns-monitoring-services and indicates on that page to go to: http://dnsmon.ripe.net/ yet going to that link provides an "internal server error". Aren't RIPE NCC services monitored to make sure they are up? -Hank

2 2

New RIPE NCC Procedural Document Available
by Andrea Cima 28 Feb '11

28 Feb '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [Apologies for duplicate emails] Dear Colleagues, The RIPE NCC has published a new RIPE NCC procedural document: ripe-475, "Independent Internet Number Resources – Contractual Relationship Changes between sponsoring LIR and End User" This document describes the steps to be taken when there are changes in the contractual relationship between the End User of independent Internet number resources and the sponsoring Local Internet Registry (LIR). It also describes the scenarios in which the RIPE NCC may de-register independent Internet number resources and what happens to those resources once they are de-registered. The new document is available at: http://www.ripe.net/ripe/docs/ripe-475.html 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 iEYEARECAAYFAkpfPukACgkQXOgsmPkFrjNlEwCcDtE364DhQCU0USBoK3kJhord yBgAoMbRsLFCStkXfvEaV6Mtm5b2sfxW =fKC3 -----END PGP SIGNATURE-----

8 11

Re: [routing-wg] [address-policy-wg] REMINDER; WAS Re: 2008-08 New Version and Draft Document Published (Initial Certification Policy for Provider Aggregatable Address Space Holders)
by Ruediger Volk, Deutsche Telekom T-Com - TE141-P1 25 Feb '11

25 Feb '11

Dear colleagues, I apologize for my bad habits and tradition for sending comments at the very last minute. > Dear Colleagues, > > The new version of RIPE Policy Proposal 2008-08, "Initial Certification > Policy for Provider Aggregatable Address Space Holders", was published > on 9 February 2011. The time period for community review ends on 23 > February 2011. > > Some feedback was sent to the Address Policy Working Group mailing list. > However, to maintain the discussion, we strongly recommend that you > share your ideas and comments and clearly let the community know if you: > > - Support the implementation of the proposal I support the implementation of the proposal; please find additional comments below that point out some problems and some ideas regarding required work. > - Support the general principle of the proposal but would prefer another > wording > - Support the general principle with some details changed but agree to > postpone this discussion until another stage of the policy proposal > review. (This is an initial proposal that covers only PA resources. If > the community supports extending certification to all resources, then > another version of the proposal will be necessary.) > - Do not support the proposal (please explain your motivations) > > > 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 > > Please send an email with your comments to address-policy-wg(a)ripe.net by > 23 February 2011. > > Best regards, > Emilio Madaio My "vote" on the proposal is: I agree to the policy proposal (consisting of "Summary", "Policy Text", and "Rationale") and want to see it fully executed as a minimum first step of implementing full RPKI support by RIPE NCC fitting into the global RPKI infrastructure. This MUST NOT be delayed any further (considering the long time this has been worked AND having missed a committed delivery date [Jan 1 2011] already. I have more comments (which may seem to dilute the primary statement, but hopefully help to fix problems and make more progress) This policy is simpler and more limited than would seem adequate and desirable in today's situation; it was more appropriate when initial versions were proposed. Even while some open ends are recognized the initial policy should be put in place to clearly indicate that the RIPE community is in control of setting policy for the operation of the NCC RPKI service; however we also need to recognize there is a challenge to deal here with more complexity and deeper technical detail compared with [most] other RIPE policies; this includes even the question of just how to identify/separate community and user relevant policy from implementation details. I see need for discussion of the NCC's impact analysis and other related documents (potentially including the process for document control). I have one clear and simple problem (=objection) to the NCC's impact analysis: I do not understand how the NCC can conclude that "this proposal only applies to IPv4 ..."; I do not see such restriction in the language of the proposal - and I'm sure that contributors to the proposal certainly would have expressed this unambiguously if that had been the intention. So I would like to emphasize that the intended policy OF COURSE covers both address families - and the definition of RPKI anyway! Inclusion of IPv6 is a MUST! If RIPE NCC has not yet implemented support of IPv6 they need to tell us the expected delivery date! As related documents I see (a) CPS (b) "... Deregistration of Internet number resources" (c) Certification Service Terms and Conditions (d) Certification Repository Terms and Conditions The need for (a) and (b) has been pointed out for more than 2 years; progress has been slow and late. Having a CPS is a standard requirement for serious [R]PKI CAs. I don't remember that there has been any mentioning of something like (c) and (d) in previous discussion and so they show up as somewhat of a surprise. The documents and their relation need some discussion, in particular with regard to how functions are distributed and to identify (and place) the relevant policy pieces. Somewhat as an example I'd like to mention: The elaborate standard structure that is defined for the CPS clearly includes parts that are defining user relevant policy details (some of which came up in the discussion of this policy proposal) as well as documentation of lots of implementation details that clearly should be left completely in the NCC's responsibility. (c) duplicates parts of the CPS and claims priority over the CPS and classifies the CPS as "explanatory document" - this looks questionable to me. Is it really acceptable that no notifications about replacements for revoked certificates are provided? (maybe OK for hosted service; hard to believe with full RPKI distributed CAs) For meeting the challenges and more satisfactory and satisfying results we need to establish a more detailed activity plan and focussed work. Regards, Ruediger Ruediger Volk Deutsche Telekom AG -- Internet Backbone Engineering E-Mail: rv(a)NIC.DTAG.DE

2 1