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

policy proposal 2012-07, "RIPE NCC Services to Legacy Internet Resource Holders"
by Dimitri I Sidelnikov 23 Oct '13

23 Oct '13

Hi. Let me express my support for policy proposal 2012-07. -- Kind regards, --- D.Sidelnikov

2 1

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

23 Oct '13

Dear colleagues - On 10.10.2013 16:07, Marco Schmidt wrote: > - An amendment to the existing policy document ripe-592 ...which is the following: Replace section 5.5 of ripe-592, currently: "Any LIR is allowed to re-allocate complete or partial blocks of IPv4 address space that were previously allocated to them by either the RIPE NCC or the IANA." with "Any LIR is allowed to re-allocate complete or partial blocks of IPv4 address space that were previously allocated to them by the RIPE NCC or otherwise through the Regional Internet Registry System." Shall my understanding be that the rationale for replacing "the IANA" by "otherwise through the Regional Internet Registry System" is that the former - implying Legacy Internet Resources - would be in contradiction with the second paragraph: "Any existing or future RIPE policy referring to resources shall not apply to legacy resources unless the policy explicitly includes legacy resources in its scope." of section 1.2 "Scope" of the proposal? If not, what else is the rationale for this side effect on ripe-592 then? Anhow: the proposal gets my support - I'd like to see it becoming policy. Best, -C.

1 0

RIPE Policy Proposal 2012-07 "RIPE NCC Services to Legacy Internet Resource Holders"
by herve.clement＠orange.com 23 Oct '13

23 Oct '13

As this policy proposal brings clarification on management of Legacy Internet Resources, Orange supports its adoption as RIPE policy. Best regards [cid:image001.gif@01CECFE1.24CB7D70]<http://www.orange.com/> Hervé CLEMENT Naming, Addressing and Numbering Project Manager Orange/IMT/OLN/AQS/NAN tél. +33 (0)1 57 36 17 97 mob. +33 (0)6 78 91 39 38 herve.clement(a)orange.com<mailto:herve.clement@orange.com> _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.

1 0

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

22 Oct '13

Marco Schmidt wrote: > Dear colleagues, > > 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. While working through the Impact Analysis I am somewhat at a loss how Option 1 and Option 3 are to be handled. In particular, going for Option 1: would the Legacy Resource lose its status: LEGACY and be relabelled to PI or PA? If this is the case, I do not see the rationale for the text in Option 3: In the latter case, however, it should be made clear that the RIPE NCC will not allow the Legacy Resource Holder to become the sponsoring LIR for its own Legacy Internet Resources. In case the status: LEGACY for Option 1 is preserved, then I can agree to the restriction as quoted. Any clarification would be appreciated. Thanks, Wilfried

2 2

2012-08 Publication of Sponsoring LIR for Independent Number Resources Moved to Last Call
by Lindqvist Kurt Erik 17 Oct '13

17 Oct '13

All, following the discussions regarding policy proposal 2012-08 in the NCC-Services WG the chairs have decided a consensus for moving forward exists and thus the proposal is moved to Last Call. Kurtis & Bijal NCC Services WG chairs

8 15

2013-04 Proposal Accepted (Resource Certification for non-RIPE NCC Members)
by Marco Schmidt 16 Oct '13

16 Oct '13

Dear colleagues, Consensus has been reached, and the proposal described in 2013-04 has been accepted by the RIPE community. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2013-04/ The new RIPE document is ripe-596 and it is available at: https://www.ripe.net/ripe/docs/ripe-596 An announcement regarding the implementation will follow. Thank you for your input. Regards Marco Schmidt Policy Development Office RIPE NCC

1 0

2013-04 Resource Certification for non-RIPE NCC Members has concluded
by Lindqvist Kurt Erik 16 Oct '13

16 Oct '13

The policy proposal 2013-04 has concluded and the WG Chairs collective have declared that the PDP process has been followed. Announcement to follow from the RIPE NCC. Kurtis & Bijal

1 0

2012-08 Last Call for Comments (Publication of Sponsoring LIR for Independent Number Resources)
by Marco Schmidt 16 Oct '13

16 Oct '13

Dear colleagues, The proposal described in 2012-08, Publication of Sponsoring LIR for Independent Number Resources, is now in its Concluding Phase. The RIPE NCC Services Working Group co-Chairs have declared that consensus for the proposal has been reached and it will now move to Last Call. As per the RIPE Policy Development Process (PDP), the purpose of these coming four weeks of Last Call is to give the community the opportunity to present well-justified objections in case anyone missed the previous two phases and want to oppose the proposal. Any objection must be made by 14 November 2013 and must be supported by an explanation. If no substantive objections are raised by the end of Last Call, the proposal will complete the PDP and will be evaluated by the co-Chairs of all RIPE Working Groups for consensus. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2012-08 Please e-mail any final comments about this proposal to ncc-services-wg(a)ripe.net before 14 November 2013. Regards Marco Schmidt Policy Development Office RIPE NCC

1 0

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

15 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://lirportal.ripe.net/training/courses 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

Fwd: [db-wg] Improvements to RIPE Database Software Release Management
by Wilfried Woeber 14 Oct '13

14 Oct '13

Dear Services and Routing folks, please see below fyi. My apologies for the short notice and/or duplicate messages. Regards, Wilfried -------- Original Message -------- Subject: [db-wg] Improvements to RIPE Database Software Release Management Date: Mon, 7 Oct 2013 13:31:06 +0200 From: Johan Åhlén <jahlen(a)ripe.net> To: db-wg(a)ripe.net <db-wg(a)ripe.net> Dear colleagues, Following recent discussion regarding the release management of the RIPE Database software, we looked closely at our procedures and would like to propose some improvements. Together with the Database Working Group chairs, we've scheduled an informal meeting during RIPE 67, open for anyone that is interested in this topic, to discuss the proposals and talk about how we can improve our procedures. The meeting will take place on Monday, 14 October from 18:00-19:00 in room Sigma + Theta. We hope you will join us. Of course, you can also send your feedback and suggestions to this list. This is what we propose: - Split the RIPE Database software into smaller modules. Modularisation would minimise the release frequency for our services. For instance, with a modern API like RDAP we might have bi-weekly major releases and weekly minor releases to quickly respond to changes in the specification. With the NRTM feed, there might be just one major release per year or even less. - Replace the "emergency release" with a "minor release" that only contains patches for operational purposes and bug fixes. No new functionality would be introduced and no feature changes. We would also have "major releases" where functionality is added, changed or removed. With major releases we would keep the minimum two-week user test period leading up to the production release as stated in the previously proposed release procedure. With any minor release, we would put it in production as soon as it's available. Most bugs affect some users. Rather than trying to determine urgency based on numbers of users, size of users, number of networks affected, importance of functionality affected, etc., we would treat all bugs the same. In short, if someone reports an issue to us, we fix it right away. This process has generally worked well over recent years. - Improve the test environment. We know that users would like to have their real data to do proper testing. To solve this issue, we propose to use snapshots of the current database for this purpose. - Improve communication surrounding new releases. This covers all documentation and how we inform users about changes. We hope that you find this way forward beneficial. Kind regards, Johan Åhlén Assistant Manager Database RIPE NCC

1 0

Account/login (Customer number : 112319 , Registry ID : be.zapfinv , Reference : RIPE)
by Sitaula, Dipak 10 Oct '13

10 Oct '13

Dear, We got an e-mail from RIPE to update our contact information of the RIPE account but we have lost our Login (username and password) detail. Technical contact is : KDM Can u provide us our login detail please... Kind regards, -- Dipak Sitaula Network Administrator M: +32 495 267467 E: dipak.sitaula(a)zapfi.com www.zapfi.com Intelligent Mobile Marketing Click<http://content.zapfi.com/disclaimer/ZFDisclaimer.html> to view our disclaimer. We are committed to the preservation of the environment. We encourage you to only print this email if absolutely necessary.

2 1

2012-07 New Draft Document and Impact Analysis Published (RIPE NCC Services to Legacy Internet Resource Holders)
by Marco Schmidt 10 Oct '13

10 Oct '13

Dear colleagues, 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. Regards Marco Schmidt Policy Development Office RIPE NCC

1 0

Expansion of eligible address space for Resource Certification (RPKI)
by Alex Band 10 Oct '13

10 Oct '13

Dear colleagues, When the Resource Certification (RPKI) service was launched in 2011, only address space allocated to the RIPE NCC directly by IANA was eligible for certification. Today, we are happy to announce that all address space that was historically transferred to the RIPE NCC from other Regional Internet Registries (RIRs) is also eligible. These ranges are so called "minority" address space, meaning that the full /8 block is managed by one of the four other RIRs, but a subset is managed by the RIPE NCC. LIRs who hold address space in these minority ranges will automatically have those resources added to their certificate, if they already have one. Starting today, they can create Route Origin Authorisations (ROAs) for the BGP announcements that they make with these prefixes. Resource Certification (RPKI) is a free service offered by all RIRs to offer BGP Origin Validation. It allows operators to request a digital certificate containing their Internet number resources and make cryptographically verifiable statements about their intended BGP announcements. These ROAs allow other network operators to make reliable routing decisions. In the RIPE NCC service region, more than 1,600 LIRs have requested a resource certificate and created ROAs for over six /8s worth of address space. To read more about this service, please visit: http://ripe.net/certification If you have any questions, please do not hesitate to contact us at <certification(a)ripe.net> Kind regards, Alex Band Product Manager RIPE NCC

1 0

Syntax Change to Aut-num Object in the RIPE Database
by Denis Walker 09 Oct '13

09 Oct '13

Dear colleagues, We would like to give you a heads-up about a proposal, currently being considered, to add two new attributes to the aut-num object in the RIPE Database: "import-via:" and "export-via:". In this email we are not concerned with the details of this specific change so much as the fact that a change is being considered. We know that these objects are very important for routing and many of them are updated daily in the RIPE Database. We also know that many scripts exist for auto-generating these objects and processing the contents. Although the RFC for RPSL clearly states that scripts should be written to ignore attributes they don't recognise, we don't know if all scripts are written this way. The RIPE NCC is considering the best ways to get information about any changes to routing object syntax in the RIPE Database out to the people who need to know. We would welcome any feedback on this issue from the community. Regards, Denis Walker Business Analyst RIPE NCC Database Team

1 0

NCC Services WG Draft Agenda - RIPE 67
by Bijal Sanghani 02 Oct '13

02 Oct '13

Dear colleague, Please see below and online the draft agenda for the NCC Services WG - RIPE 65 - https://ripe67.ripe.net/programme/meeting-plan/services-wg/ Date: Wednesday 26 September 2012 Time: 16.00 - 17.45 Chair: Kurtis Lindqvist Co-Chair: Bijal Sanghani A. Administrative Matters (5 minutes) Welcome Select a scribe Finalise agenda Approve minutes from RIPE 66 B. RIPE NCC Survey Results - Serge Radovcic, RIPE NCC and Desiree Miloshevic, Oxford Internet Institute (15 minutes) C. RIPE NCC outlook - Axel Pawlik, RIPE NCC (20 minutes) D. Services update and address hijacking issues - Andrew de la Haye, RIPE NCC (20 minutes) E. Policy Proposals Update - NCC Services WG Chairs (10 minutes) - 2012-07, RIPE NCC Services to Legacy Internet Resource Holders - 2012-08, Publication of Sponsoring LIR for Independent Number Resources, Nick Hilliard, INEX - 2013-04, Resource Certification for non-RIPE NCC members F. Open Microphone Session Z. AOB regards, Bijal & Kurtis NCC Services WG Chairs

1 0

Re: [ncc-services-wg] [db-wg] RIPE Database Release 1.69 Available Now
by Denis Walker 01 Oct '13

01 Oct '13

Dear Aris This was a small change that we implemented quite some time ago. It was not included in previous releases and added into the latest which is probably why we missed it in the release notes. We had previously announced the change in the 'DIFF' implementation with this now being the default behaviour. We were asked at the last RIPE Meeting for this dry-run behaviour. If it is still considered useful to have a subject line keyword to trigger a dry-run we can change it to a new keyword (DRY-RUN) on the next release. Regards Denis Walker Business Analyst RIPE NCC Database Team On 01/10/2013 13:03, Aris Lambrianidis wrote: > Thanks for the explanation Denis! > > Perhaps it'd be prudent to clarify that somewhere on the website. In > my mind the deprecated use of the DIFF keyword was a completely > separate issue from the dry-run option, as those modifications as to > how objects are parsed were done at different points in time. > > Plus, the warnings and errors produced are not as helpful, there's > the (standard) warning about using the DIFF keyword and then an error > about "dry-run being supported only when a single object is > specified". > > Kind regards, > > Aris Lambrianidis AMS-IX B.V. Tel.+31 (0)6 23 59 41 58 > http://www.ams-ix.net/ > > > > > On Oct 1, 2013, at 12:51 , Denis Walker <denis(a)ripe.net> wrote: > >> Dear Aris, >> >> If you use the keyword 'DIFF' in a subject line of an email update >> the software will treat the update as a dry-run and does not handle >> multiple objects. >> >> There is no need to use 'DIFF' as a keyword to get a diff output. >> By default all notification messages for object modifications now >> return the diff output followed by the full new object. >> >> Regards Denis Walker Business Analyst RIPE NCC Database Team >> >> >> On 01/10/2013 12:34, Aris Lambrianidis wrote: >>> Hello Denis and all, >>> >>> Any chance the new feature broke multiple object updates via a >>> single email (without using the dry-run option, ofc.)? We seem to >>> be getting error messages when trying to do that, I've already >>> notified auto-dbm@ about it. >>> >>> Aris Lambrianidis AMS-IX B.V. Tel.+31 (0)6 23 59 41 58 >>> http://www.ams-ix.net/ >>> >>> On Sep 23, 2013, at 15:50 , Denis Walker <denis(a)ripe.net> wrote: >>> >>>> Dear colleagues, >>>> >>>> Release 1.69 of the RIPE Database has now been fully deployed. >>>> >>>> Regards, >>>> >>>> Denis Walker Business Analyst RIPE NCC Database Team >>>> >>>> >>>> >>>> >>>> -------- Original Message -------- Subject: [db-wg] RIPE >>>> Database Release 1.69 Available Soon Date: Mon, 09 Sep 2013 >>>> 15:27:50 +0200 From: Denis Walker <denis(a)ripe.net> >>>> Organization: RIPE NCC To: Database WG <db-wg(a)ripe.net>, NCC >>>> Services WG <ncc-services-wg(a)ripe.net> >>>> >>>> Dear colleagues, >>>> >>>> The RIPE NCC is pleased to announce that we have deployed a >>>> new release of the RIPE Database to the TEST Database >>>> environment. Detailed information about the new release, >>>> including dates and information about the changes can be found >>>> here: >>>> https://www.ripe.net/data-tools/db/release-notes/ripe-database-release-1.69 >>>> >>>> >>>> >> >>>> Of special note in this release is the inclusion of "dry-run". Using the >>>> dry-run function you can test whether an update would succeed >>>> or not. The update procedure runs as normal except that no >>>> change is made to the database. Find out more about the dry-run >>>> function here: >>>> https://labs.ripe.net/Members/denis/dry-run-testing-in-the-ripe-database >>>> >>>> >>>> >> >>>> Due to recent issues with the REST API, we've extended the migration >>>> period up until the 1.70 release. This release is currently >>>> scheduled for the end of October. >>>> >>>> If you have any questions or comments, we look forward to >>>> hearing them! >>>> >>>> Regards, >>>> >>>> Denis Walker Business Analyst RIPE NCC Database Team >>>> >>>> >>>> >>>> >>>> >>> >

2 1

Re: [ncc-services-wg] [db-wg] RIPE Database Release 1.69 Available Now
by Denis Walker 01 Oct '13

01 Oct '13

Dear Aris, If you use the keyword 'DIFF' in a subject line of an email update the software will treat the update as a dry-run and does not handle multiple objects. There is no need to use 'DIFF' as a keyword to get a diff output. By default all notification messages for object modifications now return the diff output followed by the full new object. Regards Denis Walker Business Analyst RIPE NCC Database Team On 01/10/2013 12:34, Aris Lambrianidis wrote: > Hello Denis and all, > > Any chance the new feature broke multiple object updates via a single > email (without using the dry-run option, ofc.)? We seem to be getting > error messages when trying to do that, I've already notified > auto-dbm@ about it. > > Aris Lambrianidis AMS-IX B.V. Tel.+31 (0)6 23 59 41 58 > http://www.ams-ix.net/ > > On Sep 23, 2013, at 15:50 , Denis Walker <denis(a)ripe.net> wrote: > >> Dear colleagues, >> >> Release 1.69 of the RIPE Database has now been fully deployed. >> >> Regards, >> >> Denis Walker Business Analyst RIPE NCC Database Team >> >> >> >> >> -------- Original Message -------- Subject: [db-wg] RIPE Database >> Release 1.69 Available Soon Date: Mon, 09 Sep 2013 15:27:50 +0200 >> From: Denis Walker <denis(a)ripe.net> Organization: RIPE NCC To: >> Database WG <db-wg(a)ripe.net>, NCC Services WG >> <ncc-services-wg(a)ripe.net> >> >> Dear colleagues, >> >> The RIPE NCC is pleased to announce that we have deployed a new >> release of the RIPE Database to the TEST Database environment. >> Detailed information about the new release, including dates and >> information about the changes can be found here: >> https://www.ripe.net/data-tools/db/release-notes/ripe-database-release-1.69 >> >> >> Of special note in this release is the inclusion of "dry-run". Using the >> dry-run function you can test whether an update would succeed or >> not. The update procedure runs as normal except that no change is >> made to the database. Find out more about the dry-run function >> here: >> https://labs.ripe.net/Members/denis/dry-run-testing-in-the-ripe-database >> >> >> Due to recent issues with the REST API, we've extended the migration >> period up until the 1.70 release. This release is currently >> scheduled for the end of October. >> >> If you have any questions or comments, we look forward to hearing >> them! >> >> Regards, >> >> Denis Walker Business Analyst RIPE NCC Database Team >> >> >> >> >> >

3 2