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

[training] RIPE NCC Webinars - new dates
by Training Mailbox 29 Aug '13

29 Aug '13

[Apologies for duplicate e-mails] Dear colleagues, We are pleased to announce the launch of new dates for our Webinars for LIRs. The RIPE NCC Webinars are live, one hour online training courses that allow participants to interact with our trainers without leaving their desks. 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<e-learning(a)ripe.net>. We look forward to seeing you online. Kind regards, RIPE NCC Training Services

2 2

Certifying of PI End User Address Space
by de Brün, Markus 12 Apr '13

12 Apr '13

Hey Andrew, I was hoping PI-space would eventually be coverd by RPKI. As a PI-space holder, who is not a RIPE NCC member, I would prefer option 2. Since the sponsoring LIR (in our case Deutsche Telekom) already has a contractual relationship with the RIPE NCC, this seems to be the straightforward approach. Option 3 is also okay although I understand the issue of non-members benefiting of RIPE-NCC services. If it comes to that, I am prepared to pay a fee as well ;-) Regards, Markus de Brün

4 4

Pre-PDP discussion: "Yearly list of services by RIPE"
by Richard Hartmann 02 Apr '13

02 Apr '13

Dear all, this is the fifth suggestion: RIPE will create a yearly list of all services it provides to members or the general public This list will include at least: * Name of the service * Cost in time and money of maintaining and possibly extending this service * Cost in time and money of maintaining the backend needed for this service; this is to catch stuff that relies on old and brittle infra * Number of users if applicable/traceable per year * Number of queries/transactions if applicable/traceable per year * General usefulness of the service from RIPE's POV * Status of service, such as "active, supported", "deprecated", or "scheduled for decommissioning on YYYY-MM-DD" * A suggestion for the future status of the service If in doubt, RIPE will focus less on detailed interpretation and analysis and more on giving out as many hard facts and stats as possible. Interpretation will happen on the mailing lists anyway. RIPE will implement this policy in a light-weight manner that is not a drain on resources in and as of itself.

7 14

Pre-PDP discussion: "All RIPE documents should be plain text"
by Richard Hartmann 30 Mar '13

30 Mar '13

Dear all, this is the first in a series of emails which I hope will advance into PDPs and then updated policies. Some of them are closely related, but I submit them individually so that if there are any hold-ups with a specific one, the other ones can still progress. My first suggestion is: The canonical and binding format of all documents is plain text in UTF-8 encoding. If a document can not reasonably be stored as plain text, PDF/A-1a[1] will be used. If any document exists in both plain text and PDF/A-1a, plain text is binding. Any other form is considered non-binding as soon as a plain text or PDF/A-1a variant exist. All legacy documents which are still valid or relevant to current policies will be transformed within a year of this proposal becoming policy. The reasoning behind this should be obvious: Ensure that all documents will be in the most simple-to-parse format now and forever. Richard [1] https://en.wikipedia.org/wiki/PDF/A

10 20

Pre-PDP discussion: "All PDP emails, documents and websites should come with unified diff"
by Richard Hartmann 30 Mar '13

30 Mar '13

Dear all, this is the third suggestion: All PDP-related emails, web pages, and other documents by RIPE will either carry a unified diff (diff -ruN) or directly link to a page which shows said unified diff. Other formats, like full text, old/new text, etc are encouraged as well, but the diff is the binding format in which PDPs are published, documented, and discussed. Rationale: It's needlessly hard to read and compare full or partial text dumps, forcing people to do work by themselves and for themselves which a computer could do once and for all. A XML-based format that's parse-able by new tools has been proposed as an alternative. This would mean extra work while defining the XML format, to write new tools, and cut of the extensive tools and workflows around unified diffs. The point has also been raised that word diffs may be easier to read. Quoth the manpage: Nevermerge! Show words as [-removed-] and {+added+}. Makes no attempts to escape the delimiters if they appear in the input, so the output may be ambiguous. Ironically, --word-diff in git comes with an option that allows parsing, --porcelain, which turns word-based diff back into line-based diffs: Use a special line-based format intended for script consumption. Added/removed/unchanged runs are printed in the usual unified diff format, starting with a +/-/` ` character at the beginning of the line and extending to the end of the line. Newlines in the input are represented by a tilde ~ on a line of its own. Long story short: Unified diffs are called unified diffs and universally accepted for a reason. Richard

2 2

Pre-PDP discussion: "All published documents and PDPs are maintained with git"
by Richard Hartmann 30 Mar '13

30 Mar '13

Dear all, this is the fourth suggestion: All RIPE documents are made available by means of a git repository, both via anonymous pull and via a web interface. The read-only access is open to everyone, RIPE member or not. Within RIPE, this git repository is the canonical place for all published documents. All published documents are copied from it. All PDPs will be maintained as a separate branch. Every new version of a PDP is an update within that branch. The branch will either be merged back into master or left unmerged but intact, depending on if they are accepted or not. Old documents and PDPs, if still on record, will be put into separate branches that reflect correct history. The master branch is then merged into old history, creating one single history. This will happen one year after this policy comes into effect at the latest. If the proposal "All PDP emails, documents and websites should come with unified diff" is accepted, all diffs will be generated from git. Rationale: git is here to stay, it's highly efficient, allows off-line work, and has generally won the fight for version control systems in the foreseeable future. Not relying on technical tools which were created with ever-chaning text files in mind is inefficient at best. I offer to help maintain said git repository pro bono for at least 12 months or until the history has been merged, whichever is later. Richard PS: Think of those five emails as a patchset ;)

6 26

Pre-PDP discussion: "PDPs should be renamed from YYYY-NN to RIPE-PDP-YYYY-NN-vN"
by Richard Hartmann 30 Mar '13

30 Mar '13

Dear all, this is the second suggestion: The canonical name of all PDPs will be RIPE-PDP-YYYY-NN. Updated versions will receive suffixes like Internet Drafts, i.e. -v1, -v2, -v3. Old-style PDP names of the format YYYY-NN will remain valid, but all new documentation and communication by RIPE will use the new format. Alternatively, the name of the Working Group may be embedded in all names, e.g. RIPE-PDP-APWG-YYYY-NN, or RIPE-APWG-PDP-YYYY-NN. Rationale should again be obvious: Encoding information in names is good practice. Unique names make life easier for everyone involved. If other RIRs follow suit, cross-referencing becomes easier. Rationale for keeping "PDP" in the WG option is because a WG may want to publish something other than a PDP at some point. The alternatives should be decided upon during the discussion phase of the PDP. Richard

9 13

2012-07 Draft Document and Impact Analysis will be produced (RIPE NCC Services to Legacy Internet Resource Holders)
by Emilio Madaio 28 Mar '13

28 Mar '13

Dear Colleagues, The discussion period for the proposal described in 2012-07, "RIPE NCC Services to Legacy Internet Resources Holders", has ended. A draft document and the RIPE NCC Impact Analysis will now be prepared for review. We will publish the documents shortly and we will make an announcement. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2012-07 Regards Emilio Madaio Policy Development Officer RIPE NCC

4 4

Improving Data Quality on the FTP Site
by Laura Cobley 28 Mar '13

28 Mar '13

Dear colleagues, As part of our efforts to improve data quality across the RIPE NCC, we would like to update a file within the FTP site: ftp://ftp.ripe.net/pub/stats/ripencc/membership/alloclist.txt According to our records, this file should contain a list of allocated address space held by the RIPE NCC membership. However, in addition to the expected data, the file also contains a number of references to obsoleted member accounts which no longer exist. These include, for example, accounts created for internal testing and accounts which have subsequently been renamed and therefore appear twice. We are therefore proposing a clean-up of this data so that it shows only allocated address space held by the RIPE NCC membership. Other than removing the erroneous information, the format of the data will not be changed. We plan to begin the clean-up three weeks from today (Thursday 28 March, 2013) and would be grateful for any feedback via this mailing list or sent to <ncc(a)ripe.net> before then. Kind regards, Laura Cobley RIPE NCC Customer Services Manager

3 5

Certifying of PI End User Address Space
by Andrew de la Haye 27 Mar '13

27 Mar '13

Jim, Of the three implementation options, the most straightforward is option 1, where the PI End User becomes a full member, as this requires no additional development for the RIPE NCC. Note that the additional income from this scenario would exceed any additional cost. For option 2 (going through the sponsoring LIR) and option 3 (going to the RIPE NCC directly), there is a 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 Please keep in mind that in both estimates, where the actual cost falls in the given broadband depends on the amount of manual verification that is desired, which can range from random periodic audits to verification of every application by RIPE NCC staff. Also, the additional costs with smaller or larger uptake are estimated to be quite low. Option 2: A one time cost of 65 kEUR, with a running cost of 45 kEUR, based on an estimated uptake of 15% or approximately 2,500 PI End Users. Option 3: A one time cost of 70kEUR, with a running cost of 70 kEUR, based on an estimated uptake of 15% or approximately 2,500 PI End Users. Lastly, it is important to point out that as the certificate is valid for only one year, providing this service to PI End Users creates an opportunity for periodic confirmation of the 2007-01 End User Assignment Agreement, further improving the robustness of our Registry. Kind regards, Andrew de la Haye Chief Operations Officer RIPE NCC

5 6

Re: [ncc-services-wg] 2012-07: Fresh draft
by Niall O'Reilly 25 Mar '13

25 Mar '13

On 25 Mar 2013, at 09:45, Dave Wilson wrote: > Morning, Niall! > > I was just wondering if the new draft went to the co-chairs and Emilio? Yes, on 8 March. > Is there anything I can do to help? I think you just have! Thanks for asking. /Niall

2 2

Certifying of PI End User Address Space
by Andrew de la Haye 21 Mar '13

21 Mar '13

Dear colleagues, On 11 February, the RIPE NCC asked the RIPE NCC membership and the RIPE community for feedback on how to make Provider Independent (PI) End User address space eligible for resource certification (RPKI). Although we’ve received valuable input at several operator meetings and through various other communication channels, we want to emphasise the importance of your participation on this mailing list. We strongly encourage further feedback on this important issue, before the consultation period comes to a close. To summarise, the discussion so far involves three possible implementation options: 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 ROA management system themselves, or delegates 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 The feedback provided so far clearly differentiates between two groups of PI End Users: those who use the sponsoring LIR solely to request the PI resources but manage everything else themselves, and 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 both options 2 and 3, while option 1 will continue to remain available at all times. These options have different expected impacts on the RIPE NCC’s operations. The RIPE NCC does not expect option 1 or 2 to have a major impact, as they align with our current business practices. Option 3 would require PI End Users to have a direct contact with the RIPE NCC. As this would be a new venture for the RIPE NCC, we expect it would be the most labour intensive of the three options and would have the greatest impact in terms of resources. Some feedback has pointed out the lack of RIPE Policy on this issue. At this time, the RIPE NCC is requesting feedback on whether or not resource certification should expand beyond a RIPE NCC member service. Discussions about potential RIPE Policy, should this happen, can take place via the appropriate channels. Again, we strongly encourage your feedback before the consultation period ends on 30 March 2013, after which time the RIPE NCC Executive Board will recommend which option(s) to implement. We look forward to hearing from you. Kind regards, Andrew de la Haye Chief Operations Officer RIPE NCC

13 26

End User Agreement question
by Hank Nussbacher 20 Mar '13

20 Mar '13

While reviewing the suggested RIPE NCC End User Agreement located at: http://www.ripe.net/lir-services/resource-management/independent-resources/… I see in section 4.3.a: "The End User shall use the Independent Internet Number Resources assigned to it for internal purposes within its own network only." Legal counsel has stated that based on the text provided, any IP address block or ASN assigned could only be used within a company/corporate/organization Intranet and publishing such resource on the global Internet would violate the End User Agreement. Who has used this draft agreement and did you change the text? Strange that no one has spotted this before. Regards, Hank

6 11

Soft launch of "abuse-c:", ripe-563: Improving Abuse Contact Information
by Kaveh Ranjbar 19 Mar '13

19 Mar '13

[Apologies for duplicate emails] Dear Colleagues, RIPE NCC has initiated a soft launch of phase one of RIPE Policy 563: "Abuse Contact Management in the RIPE Database". All facilities to provide abuse contact information for organisations registered in the RIPE Database are be in production state. Please see the announcement sent earlier to the RIPE Anti-Abuse Working Group mailing list (http://www.ripe.net/ripe/mail/archives/anti-abuse-wg/2013-March/002226.html) Kind Regards, Kaveh Ranjbar Database Group Manager RIPE NCC

1 0

End User Assignment Agreement in Word?
by Hank Nussbacher 18 Mar '13

18 Mar '13

I am looking for a RIPE End User Agreement in Word format. The standard format can be found here: http://www.ripe.net/lir-services/resource-management/independent-resources/… or a PDF version can be found here: http://www.ripe.net/lir-services/resource-management/independent-resources/… But RIPE NCC does not provide a Word format which can then be editted by LIRs - sooooo I am looking for someone else who has taken the sample and converted it into Word format. Thanks, Hank

1 0

Pre-PDP discussion: "All RIPE documents should be plain text"
by Richard Hartmann 15 Mar '13

15 Mar '13

--Resending as the first mail seems to have been eaten by a grinch-- Dear all, this is the first in a series of emails which I hope will advance into PDPs and then updated policies. Some of them are closely related, but I submit them individually so that if there are any hold-ups with a specific one, the other ones can still progress. My first suggestion is: The canonical and binding format of all documents is plain text in UTF-8 encoding. If a document can not reasonably be stored as plain text, PDF/A-1a[1] will be used. If any document exists in both plain text and PDF/A-1a, plain text is binding. Any other form is considered non-binding as soon as a plain text or PDF/A-1a variant exist. All legacy documents which are still valid or relevant to current policies will be transformed within a year of this proposal becoming policy. The reasoning behind this should be obvious: Ensure that all documents will be in the most simple-to-parse format now and forever. Richard [1] https://en.wikipedia.org/wiki/PDF/A

1 0

Call for Agenda Items RIPE66 -RIPE NCC Services WG
by Bijal Sanghani 14 Mar '13

14 Mar '13

Dear NCC-Services WG, RIPE66 is just round the corner and we are putting the agenda together for the NCC Services WG. This is your opportunity to let the RIPE NCC know what you want from them, if you would like to suggest a topic for discussion or have a presentation you have or would like to see presented please get in touch with Kurtis or myself. Kind regards, Bijal Sanghani RIPE NCC Services WG Co-Chair

1 0

2012-07 Discussion Period extended until 21 February 2013 (RIPE NCC Service to Legacy Internet Resource Holders)
by Emilio Madaio 06 Mar '13

06 Mar '13

Dear Colleagues, The text of the policy proposal 2012-07, "RIPE NCC Services to Legacy Internet Resource Holders", has been revised based on the community feedback received on the mailing list. We have published the new version (version 2.0) today. As a result a new Discussion Phase is set for the proposal. Highlights of the changes: -general rearrangement of the proposal sections -overall rewording of the whole policy proposal text -new Rationale section You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2012-07 We encourage you to review this policy proposal and send your comments to <ncc-services-wg(a)ripe.net>. Regards, Emilio Madaio Policy Development Officer RIPE NCC

21 96

Policy Proposal 2012-06 Revert "Run Out Fairly" implemented
by David Hilario 06 Mar '13

06 Mar '13

[Apologies for duplicate emails] Dear colleagues, We are pleased to announce that RIPE Policy Proposal 2012-06, Revert "Run Out Fairly" , has been implemented. The RIPE NCC is now ready to accept requests for IPv4 assignments and IPv4 allocations under this policy. The full proposal can be found at: http://www.ripe.net/ripe/policies/archived-policy-proposals/proposals/2012-… The updated "IPv4 Address Allocation and Assignment Policy" document is available at: http://www.ripe.net/ripe/docs/ripe-582 IPv4 assignments request forms have been updated. You can access the request forms through the LIR Portal or online at: http://www.ripe.net/ripe/docs/ripe-583 The supporting notes are available at: http://www.ripe.net/ripe/docs/ripe-584 If you have any questions, please contact<ncc(a)ripe.net>. Regards, David Hilario Registration Services RIPE NCC

1 0

DNS outage
by Romeo Zwart 05 Mar '13

05 Mar '13

[Apologies for duplicate emails] Dear colleagues, This morning, the RIPE NCC briefly experienced a problem on the ripe.net DNS servers. Operation of K-root and other public DNS services was not impacted at any time during this outage. At 11:45 UTC this morning, an error in the deployment script used to update the ripe.net zone caused a partial zone file to be activated. This caused the ripe.net DNS servers to return NX-domain responses for some valid hosts and/or subdomains in the ripe.net zone, which effectively rendered some of the RIPE NCC services unavailable during this period. DNS resolution for ripe.net was fully restored at 12:15 UTC. Caching of the erroneous responses may have caused reachability problems until 13:15 UTC. The error in the script has been identified and is only triggered in a specific corner case. This error will be corrected today. We apologise for any inconvenience caused. Incident start: 05-Mar-2013 11:45:01 UTC Incident end: 05-Mar-2013 12:14:58 UTC Regards, Romeo Zwart GII Services Manager RIPE NCC

1 0