October 2013 - ncc-services-wg

RIPE Database Release 1.70 Available
by Denis Walker 06 Nov '13

06 Nov '13

Dear colleagues, The RIPE NCC is pleased to announce that we will deploy a new release of the RIPE Database to the TEST Database environment on Thursday, 31 October 2013. The release is scheduled for production deployment on Thursday, 12 November 2013. Detailed information about the new release, including dates and information about the changes, can be found at: https://www.ripe.net/data-tools/db/release-notes/ripe-database-release-1.70 Of special note in this release is the inclusion of "pending route authentication". This is an alternative and simplified way of authorising route object creation. Two separate updates for a single route/route6 object are treated as one create request. This has no impact on users who still submit a complete route object with all authorisations included. If you have any questions or comments, we look forward to hearing them. Regards, Denis Walker Business Analyst RIPE NCC Database Team

1 1

Policy proposal 2012-07, "RIPE NCC Services to Legacy Internet Resource Holders"
by Mihael Dimec 30 Oct '13

30 Oct '13

Hello all, I would like to add my support for policy proposal 2012-07. Best regards, Mihael Dimec

1 0

[training] RIPE NCC Webinars - new dates
by Training Team 29 Oct '13

29 Oct '13

Dear colleagues, We are pleased to announce the launch of new dates for our Webinars. The RIPE NCC Webinars are live and take only one hour. You can interact with our trainers without leaving your desk. We focus on the topics and issues most important for LIRs. Register now at https://www.ripe.net/lir-services/training/e-learning/webinars Participation is limited to 20 people, so don't hesitate if you want to take part! If you have questions, please email <training(a)ripe.net>. We look forward to seeing you online. Kind regards, RIPE NCC Training Services

1 0

[8-1123000002024] Peering down between AS57633 and Google [ref a76933]
by nst＠google.com 28 Oct '13

28 Oct '13

Google Network Incident Notification - Reference *a76933* ------------------------------ Our monitoring systems have detected the following problem: BGP peering session with AS 57633 is down. Details: Google ASN: 15169Peer ASN: 57633Google Address:37.49.236.2 Peer Address: 37.49.236.226 Symptom(s): Hold Timer Expired Error Please investigate and provide an update via this email thread. Thank you for peering with Google! ------------------------------ PRIVILEGE AND CONFIDENTIALITY NOTICE: The information in this e-mail communication and any attached documents may be privileged, confidential or otherwise protected from disclosure and is intended only for the use of the designated recipient(s). If the reader is neither the intended recipient nor an employee or agent thereof who is responsible for delivering it to the intended recipient, you are hereby notified that any review, dissemination, distribution, copying or other use of this communication is strictly prohibited. If you have received this communication in error, please immediately notify us by return e-mail and promptly delete the original electronic e-mail communication and any attached documentation. Receipt by anyone other than the intended recipient is not a waiver of any attorney-client or work-product privilege.

2 1

Re: [ncc-services-wg] 2012-07 New Draft Document and Impact Analysis Published (RIPE NCC Services to Legacy Internet Resource Holders)
by Niall O'Reilly 26 Oct '13

26 Oct '13

On 10 Oct 2013, at 15:07, Marco Schmidt wrote: > The draft document for version 4.0 of the policy proposal 2012-07, "RIPE NCC Services to Legacy Internet Resource Holders" has now been published, along with an impact analysis conducted by the RIPE NCC. > > Some of the main differences from version 3.0 include: > > - Rewording and new text in section 1.2 (Scope) > - Rewording and new text in section 2.6 (No relationship) > - New section 2.7 (Lapse of relationship or agreement) > - Rewording and new text in section 3.0 (Contractual requirements) > - An amendment to the existing policy document ripe-592 Thanks to Marco for a concise and accurate list of differences. Thanks also to Athina and Andrea for making us proposers aware of gaps in the previous version and of passages where divergent readings of the text could lead to differences of understanding. Here's Marco's list again, with some extra detail. - Rewording and new text in section 1.2 (Scope) Proposed policy will supersede provisions of any existing RIPE policy which refer to legacy resources. Part of one sentence of RIPE-592 is the only policy identified as affected by this. Proposed policy will allow scope of any future RIPE policy to include legacy resources, but only if this is done explicitly. Proposed policy deliberately avoids specifying or restricting what rights are enjoyed by the holders of legacy resources. Proposed policy provides for surrender or conversion of legacy resources on the basis of informed choice by the holder. - Rewording and new text in section 2.6 (No relationship) Redundant text was removed; remaining text was tidied up. - New section 2.7 (Lapse of relationship or agreement) RIPE NCC identified the absence of guidance on how to handle lapse of agreement as a gap in the previous version of the proposal. - Rewording and new text in section 3.0 (Contractual requirements) New text focuses on mutual obligations, and avoids reference to rights of legacy resource holders, as these are placed out of scope in the current version of the proposal. - An amendment to the existing policy document ripe-592 This amendment was recognized as necessary in order to ensure coherency between RIPE-592 and the proposed new policy. Best regards, Niall O'Reilly

2 1

Re: [ncc-services-wg] 2012-07 New Draft Document and Impact Analysis Published (RIPE NCC Services to Legacy Internet Resource Holders)
by Marcus Stoegbauer 25 Oct '13

25 Oct '13

On 10.10.2013, at 16:07, Marco Schmidt <mschmidt(a)ripe.net> wrote: > The draft document for version 4.0 of the policy proposal 2012-07, "RIPE NCC Services to Legacy Internet Resource Holders" has now been published, along with an impact analysis conducted by the RIPE NCC. > > Some of the main differences from version 3.0 include: > > - Rewording and new text in section 1.2 (Scope) > - Rewording and new text in section 2.6 (No relationship) > - New section 2.7 (Lapse of relationship or agreement) > - Rewording and new text in section 3.0 (Contractual requirements) > - An amendment to the existing policy document ripe-592 > > You can find the full proposal and impact analysis at: > https://www.ripe.net/ripe/policies/proposals/2012-07 > > And the draft document at: > https://www.ripe.net/ripe/policies/proposals/2012-07/draft > > We encourage you to read the draft document text and send any comments to ncc-services-wg(a)ripe.net before 8 November 2013. > in my eyes this proposal provides a very good balance between the expectations of the legacy resource holders and the RIPE NCC members. I fully support it and like to thank everyone involved for their hard and excellent work. Marcus -- man-da.de GmbH, AS8365 Phone: +49 6151 16-71022 Mornewegstr. 30 Fax: +49 6151 16-71198 D-64293 Darmstadt e-mail: ms(a)man-da.de Geschäftsführer Marcus Stögbauer AG Darmstadt, HRB 94 84

1 0

Re: [ncc-services-wg] 2012-07 New Draft Document and Impact Analysis Published (RIPE NCC Services to Legacy Internet Resource Holders)
by Jarle Greipsland 25 Oct '13

25 Oct '13

"Marco Schmidt" <mschmidt(a)ripe.net> writes: > You can find the full proposal and impact analysis at: > https://www.ripe.net/ripe/policies/proposals/2012-07 > > And the draft document at: > https://www.ripe.net/ripe/policies/proposals/2012-07/draft > We encourage you to read the draft document text and send any > comments to ncc-services-wg(a)ripe.net before 8 November 2013. I think this a sound policy proposal, and I support its adaption as RIPE policy. -jarle -- Of course there's no reason for it, it's just our policy.

6 6

IP Analyser for Android Pilot - Proposed Discontinuation
by Alex Band 24 Oct '13

24 Oct '13

Dear colleagues, In 2012, the RIPE NCC introduced the IP Analyser mobile client for Android pilot to gauge interest from the membership. After careful evaluation of the usage, feedback and available resources to maintain or expand this pilot, we propose to discontinue the pilot from 20 November 2013. The IP Analyser for Android was a very lightweight trial to see if members would be interested in having IP Analyser information available on the go. Considering the amount of active installations and queries from mobile clients, it is apparent that spending the available resources on expanding the web interface and API is more valuable. For example, we plan to develop IPv6 functionality in the near future. By removing this service, the RIPE NCC would be in a position to focus its resources on the remaining services that provide the most value to members. If you have any questions or comments, please do not hesitate to contact us. Kind regards, Alex Band Product Manager RIPE NCC

3 2

Implementation of Resource Certification (RPKI) for PI End User Resources
by Alex Band 23 Oct '13

23 Oct '13

Dear colleagues, In March of this year, the RIPE NCC held a community consultation about the certification of Internet number resources held by non-RIPE NCC members. The discussion that unfolded led to RIPE Policy Proposal 2013-04, "Resource Certification for non-RIPE NCC Members". This proposal reached consensus on 16 October 2013. Now that the Community has decided that certification of non-member resources should be a RIPE NCC service, we would once again like to summarise the three possible implementation options for PI End User resources: 1) A PI End User becomes a RIPE NCC member 2) A PI End User requests a resource certificate through their sponsoring LIR and gets access to the Route Origin Access (ROA) management system themselves, or they delegate management to the sponsoring LIR 3) A PI End User requests a resource certificate directly from the RIPE NCC, without becoming a member, and obtains access to the ROA management system It became apparent from the discussion that PI End Users fall into two groups: - Those who use the sponsoring LIR solely to request the PI resources but manage everything else themselves - Those who rely on the sponsoring LIR for everything, ranging from BGP routing to RIPE Database updates In order to cater to both groups, the feedback so far suggests we facilitate options 2 and 3, while option 1 will continue to remain available at all times. For option 2 (going through the sponsoring LIR) and option 3 (going to the RIPE NCC directly), there is the possibility to provide an automated solution for which only PI End Users who have submitted a 2007-01 End User Assignment Agreement are eligible. This means the RIPE NCC will need to develop a solution where the following informational elements are cross-referenced with each other: a) The authoritative control over the address space (i.e. the ability to authenticate against the relevant objects in the RIPE Database) b) The End User Assignment Agreement that was submitted and verified by the RIPE NCC c) The RIPE NCC Access credentials for accessing the certification management interface In order to offer insight into the resources required for the implementation, the RIPE NCC has provided a cost estimate. One of the clarifications that was given during the discussion is the fact that there is a lot of overlap in the implementation of option 2 and 3, meaning that building both would not result in a significantly higher cost than offering just one of them. The only aspect that remained a discussion point were the requirements that the RIPE NCC should impose on PI End Users when they would like to request a resource certificate directly from the RIPE NCC (option 3). We would like to ask you to provide further feedback on this topic. The issue is: A PI End user must prove to the RIPE NCC that they truly are the legitimate holder of the resources they would like to have a certificate for. What proof do they need to give to the RIPE NCC before we grant them access to the system? While this discussion is ongoing, we would like to propose to start building the framework to offer this functionality, and deliver option 2 as soon as it is ready. We look forward to your feedback. Kind regards, Alex Band Product Manager RIPE NCC P.S. The RIPE NCC has explained the implementation options and associated cost at the following locations: http://www.ripe.net/ripe/mail/archives/ncc-services-wg/2013-March/002145.ht… http://www.ripe.net/ripe/mail/archives/ncc-services-wg/2013-March/002149.ht… http://www.ripe.net/ripe/mail/archives/ncc-services-wg/2013-March/002252.ht… http://www.ripe.net/ripe/mail/archives/ncc-services-wg/2013-March/002256.ht…

5 7

Re: [ncc-services-wg] 2012-07 New Draft Document and Impact Analysis Published (RIPE NCC Services to Legacy Internet Resource Holders)
by Rob Evans 23 Oct '13

23 Oct '13

Hi, > We encourage you to read the draft document text and send any comments to ncc-services-wg(a)ripe.net before 8 November 2013. I (personally, of course) support this proposal. In the interests of discussion, though, I'll note that my interpretation of 'Registry Service Elements' in section 1.1 was any single service provided by the RIR, either current or future. However, in the impact analysis the RIPE NCC has interpreted it as only any one of the specific existing services mentioned in 1.1. Does that match with the authors' intention? (If not, does it matter?) Not knowing how the RIPE NCC performs checks on the holder of legacy resources, the onus appears to be on the holder to submit appropriate documentation. Is it safe to assume that the NCC also has a record of relevant InterNIC records to match who the resources were originally assigned to, and so if the holder hasn't changed then the documentation could be along the lines of just checking the organisations match? I'll also note that we had a brief discussion in last week's routing working group session relevant to the part of section 'D' of the impact analysis relating to adding an attribute to the aut-num object. Most of the comments tended to suggest that as long as the RFC says unknown attributes should be ignored, then there should be little problem. However, sufficient notice will need to be given so that tools that work off local copies of the aut-num will submit it with the relevant fields (or given that it isn't something the holder can change, the update software can add the correct line in if it is missing in an update). Cheers, Rob

8 7