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

2016-02 New Policy Proposal (Resource Authentication Key ( RAK ) code for third party authentication)
by Marco Schmidt 19 May '16

19 May '16

Dear colleagues, A new RIPE Policy Proposal 2016-02, "Resource Authentication Key ( RAK ) code for third party authentication" has been made and is now available for discussion. The proposal aims to allow all number resources, in exacts and more specifics, to be authenticated via an date expiring API-key. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2016-02 We encourage you to review this proposal and send your comments to <ncc-services-wg(a)ripe.net> before 31 May 2016. Regards, Marco Schmidt Policy Development Officer RIPE NCC

7 8

Improving the Management of RIPE Database Objects with Joint Responsibility
by Alex Band 18 May '16

18 May '16

Dear colleagues, As announced to the RIPE NCC Services Working Group on 22 April, we have been working on simplifying information management in the RIPE Database. Some objects in the RIPE Database have joint responsibility: allocations for IP resources and the ORGANISATION object. The result is that some attributes can only be changed by the RIPE NCC, and others could only be changed through the so-called LIR Portal Object Editors. Today we have deployed business rules in the RIPE Database to determine which attributes you can change and which ones can only be changed by the RIPE NCC. In addition, we have made improvements to the LIR Portal, making the Object Editors obsolete. What this means for you: 1. In the LIR Portal, users will have to go through a one-time operation of selecting a "default" maintainer, which is placed on all existing and new objects that have joint responsibility 2. Changes such as selecting another technical or administrative contact for an allocation for IP resources should be done in the RIPE Database from now on Please note that it is not required to take action immediately. It is only when you want to change information in one of your allocations for IP resources and the ORGANISATION object that you will first have to select the "default" maintainer on this page: https://my.ripe.net/#/account-details You can read more on this functionality in this article on RIPE Labs: https://labs.ripe.net/Members/AlexBand/improving-the-management-of-ripe-dat… Kind regards, Alex Band Product Manager RIPE NCC

1 0

New on RIPE Labs: RIPE NCC Membership and Available IPv4 Statistics - an Update
by Mirjam Kuehne 18 May '16

18 May '16

Dear colleagues, Ahead of RIPE 72, we wanted to take another look at our membership statistics. Was membership growth affected by the Executive Board's resolution preventing multiple LIR accounts? And how will the growth in new LIRs affect the projected lifespan of the available IPv4 pool? Please read more on RIPE Labs: https://labs.ripe.net/Members/wilhelm/ripe-ncc-membership-and-available-ipv… Kind regards, Mirjam Kuehne RIPE NCC

1 0

NCC Services WG Agenda
by Kurt Erik Lindqvist 17 May '16

17 May '16

Resource Authentication Key ( RAK ) code for third party authentication - Erik Bais (15 minutes) A. Administrative Matters (5 minutes) - Welcome - Select a scribe - Finalise agenda - Approve minutes from RIPE 71 B. RIPE NCC Survey 2016 - Serge Radovcic (10 minutes) C. RIPE NCC Report on Outreach - Paul Rendek (15 minutes) D. RIPE NCC outreach/communication as a work of community secretariat - Alexander Isavnin (10 minutes) E RIPE NCC Update - Axel Pawlik (20 minutes) F. IETF Endowment Update - Jari? (10 minutes) G. 2016-02, "Resource Authentication Key ( RAK ) code for third party authentication - Erik Bais (15 minutes) H. Open Microphone Session (5 minutes) Z. Any other business Best regards, Kurt Erik Lindqvist kurtis(a)kurtis.pp.se

1 0

RIPE Policy Proposal 2016-03 Affects Certification for Allocations from IPv4 Pool
by Marco Schmidt 17 May '16

17 May '16

Dear colleagues, A new RIPE Policy proposal, 2016-03, "Locking Down the Final /8 Policy" is available for discussion on the Address Policy Working Group mailing list. The goal of this proposal is to limit IPv4 from the remaining address pool to one /22 per LIR (regardless of how it was received). These allocations will receive a separate status with several restrictions. As this proposal introduces implicit limitations for the certification for such IPv4 ranges, we would like to notify the RIPE NCC Services Working Group and invite you to discuss the proposal on the Address Policy Working Group mailing list. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2016-03 We encourage you to review this proposal and send your comments to <address-policy-wg(a)ripe.net> before 15 June 2016. Regards, Marco Schmidt Policy Development Officer RIPE NCC

1 0

Phasing out the LIR Portal object editors
by Alex Band 22 Apr '16

22 Apr '16

Dear colleagues, Over the last year the RIPE NCC has been making a considerable amount of incremental changes to the RIPE Database user interface. Especially the implementation of streamlined authentication using RIPE NCC Access has put us in a position where we can further improve the user experience in other areas. As the next step in this process, we intend to phase out the so-called LIR Portal object editors. Currently, the object editors are necessary to allow you to make changes to particular attributes of RIPE Database objects that are maintained by the RIPE NCC. For example, you can use them to change the tech-c and admin-c in the inetnum object for the allocation that you hold. This system has always been the cause of much confusion. User data that you expect to be able to change in the RIPE Database can only be changed through the LIR Portal, whereas other information can be edited in the RIPE Database itself. Our plan is to bring all of this to the place where it belongs and where users expect it, the RIPE Database. The way we intend to do this involves a couple of steps. The first step is to use business rules to determine which attributes you can change, and which ones can only be changed by the RIPE NCC. For example, in an inetnum for an allocation only the RIPE NCC can change the range, but you can change the admin-c and tech-c. The second step is setting the authorisation for the attributes that you control. The RIPE NCC already has a maintainer on the allocation, RIPE-NCC-HM-MNT. In the system we envision, we would allow you to select an additional maintainer, to authorise changes over the attributes that you are authoritative for. You will be able to select this maintainer in the LIR Portal. We will place this maintainer on all existing and new objects that have joint responsibility: allocations for IP resources and the Organisation object. It is important to note that none of these changes have a fundamental impact on the RIPE Database itself. We are only making changes to the business rules and the way you determine authorisation. We look forward to your feedback! Kind regards, Alex Band Product Manager RIPE NCC

2 1

Call for agenda items
by Kurt Erik Lindqvist 20 Apr '16

20 Apr '16

Dear WG, we are closing in on RIPE72 in Copenhagen. If you have any agenda items for the NCC-Services WG please email ncc-services-wg-chairs(a)ripe.net! The WG will meet on Wednesday the 25 May 2016 at 16:00. Kurtis , WG-Chair

1 0

[training] Training Course: Exploring RIPE Database API
by Training Services 31 Mar '16

31 Mar '16

Dear colleagues, We are happy to announce that a RIPE NCC training course will take place on Sunday 22 May, before RIPE 72 begins on Monday 23 May, in Copenhagen. This course will focus on using RIPE Database RESTful API to programmatically manipulate RIPE Database objects. The course is free of charge and is open to anyone interested. ---------------- Course details ---------------- Exploring RIPE Database API ---------------- Course goals ---------------- By the end of this course, you will be able to perform operations on object in the RIPE Database using RESTful API. ---------------------------------------- Who will benefit from this course? ---------------------------------------- Anyone managing objects in the RIPE Database and considers automating this process or integrating with other software will find this course useful. --------------- Prerequisites: --------------- - Basic programming experience - Basic knowledge of the RIPE Database ------------------------- Course outline: ------------------------- - RIPE Database Overview - Exploring RESTful API - Using RESTful API - Building simple IPAM ---------------------------- Additional information ---------------------------- - Free of charge - Coffee and lunch will be provided - Delivered by the RIPE NCC’s Training Services ----------------------------------------- Registration for RIPE NCC members ----------------------------------------- Please register via the following page: https://lirportal.ripe.net/training/register/courseCode/LIR20160008 ------------------------------------ Registration for non-members ------------------------------------- Please fill out the following information email it to: <training(a)ripe.net>: - Email: - Course name: - Full name : - Vegetarian: yes/no Be quick - we only have 45 seats available on a first-come, first-served basis! If there is enough interest, we will continue to offer courses on different topics of interest alongside future RIPE Meetings. Kind regards, RIPE NCC Training Services

1 0

Updated 5th Draft SLA for the IANA Numbering Services
by Athina Fragkouli 18 Mar '16

18 Mar '16

Dear Colleagues Please find below the latest NRO announcement regarding the Fifth version of the draft SLA. https://www.nro.net/news/updated-5th-draft-sla-for-the-iana-numbering-servi… Kind regards, Athina Fragkouli Head of Legal RIPE NCC ===== UPDATED FIFTH DRAFT SERVICE LEVEL AGREEMENT FOR THE IANA NUMBERING SERVICES (SLAv5) AND CALL FOR PUBLIC COMMENTS 17 March 2016 Background On 15 January 2015, the Consolidated RIR IANA Stewardship Proposal (CRISP) Team submitted the Internet Number Community Proposal to the request for proposals issued by the IANA Stewardship Coordination Group (ICG). One of the key elements of the Internet Number Community proposal is to replace the current NTIA IANA agreement with a new contract, a Service Level Agreement (SLA), between the IANA Numbering Services Operator and the five RIRs. A first draft of the SLA was published on 1 May 2015 and opened for public comments until 14 June 2015. The first draft of the SLA is available at: https://www.nro.net/sla-v1 A second draft of the SLA was published on 6 August 2015 and opened for public comments until 31 August 2015. The second draft of the SLA is available at: https://www.nro.net/sla-v2 A third draft of the SLA was published on 30 October 2015 and invited ICANN legal staff to provide comments by November 30th 2015. The third draft of the SLA is available at: https://www.nro.net/sla-v3 A fourth draft of the SLA was published on 25 February and invited ICANN to move forward to signing the SLA. The fourth draft of the SLA is available at: https://www.nro.net/sla-v4 Fifth Draft SLA As a result of ICANN comments on the fourth draft and additional feedback received at meetings during ICANN 55 in Marrakech, a fifth draft of the SLA has been produced and is available at: https://www.nro.net/sla The SLAv5 is open for public comments. Comments can be sent to IANAXFER mailing list at https://www.nro.net/mailman/listinfo/ianaxfer. The deadline for comments is April 15th 2016. For the sake of clarity, you can find a track changes version of SLAv5 against the fourth draft at: https://www.nro.net/sla-track-changes Additionally, a document with the comments on SLAv5 and the legal team responses is available at: https://www.nro.net/slav4-comments In accordance with the transparency commitment to our the community, we share the exchange of a clear track of comments between ICANN and RIR staff working towards a final SLA document. About the Fifth Draft SLA The fifth draft of the SLA has been developed by a team consisting of individuals from different RIRs. It responds to the principles included in the Internet Number Community proposal and is based on the already existing provisions of the NTIA IANA agreement. The content of SLAv5 is the result of consideration of public comments received during the public comment period on the second draft SLA,informational meetings with ICANN staff regarding the operational provisions of the SLA, and ICANN’s written comments regarding the third and fourth draft SLA. It is written in such a way that it can be signed as part of the implementation of the IANA transition when this occurs or before, without pre-judging the outcome of the ICG coordinated proposal. The SLA includes legally important provisions, such as those that regulate the five RIRs collective actions and responsibilities in its dealings with ICANN under the SLA. It also includes background and definitions. The SLA also includes explanatory footnotes that reference the source of each article according to the Internet Number Community proposal principles or the NTIA IANA agreement. Next Steps The RIRs thank the community and ICANN staff for its thoughtful comments and now publish this SLAv5 in the interest of transparency and keeping the community apprised of progress being made on the SLA. We trust that all comments and concerns have been addressed and that the current draft, SLAv5, represents a mutually acceptable SLA that is consistent with the principles found within the Internet Number Community proposal. We invite public comments as we approach the final version, which will be signed with ICANN/IANA as part of the IANA Transition planning process and will take effect upon release of their existing agreement with NTIA. _______________________________________________

1 0

How to change the geolocation of my IP's?
by Dmitry Vorozhtsov 17 Mar '16

17 Mar '16

Hello! I’ve got an address block using transfer a few weeks ago. So I tried to change geoloc info and sent a request to MaxMind. Unfortunately, I’ve got a message - «Sorry, we can not accept your request, because location you specified, does not match the data, that we received from this network» I asked once more, but received no answer. I have a record in RIPE DB for this address block. How can I change the geoloc info? Best regards, Dmitry Vorozhtsov

1 0