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

Barrier-free acces to archived RIPE-Meeting Videos
by Felix Resch 16 Sep '16

16 Sep '16

Hello, i have to ask that Barrier-Free Access (Browser-Plugin beeing the Barrier) to the archived Recordings of the RIPE-Meeting Videos before and including RIPE68 be added (eg. The 'Download Video' Button/Directlink). Video Players (eg. VLC) can Play the .flv files just fine and i am hesitant to ask Information-Extractor-Middleware Projects (eg. Livestreamer/youtube-dl) to add RIPE Site-Structure to their liste of Supported Sites, as i think RIPE 'is better than this'. thanks Felix

1 0

[training] RIPE NCC Training Courses October-December 2016
by Training Services 01 Sep '16

01 Sep '16

Dear colleagues, Our training team travels the RIPE NCC service region to deliver training courses to our members without any additional cost. Over the next few months, we'll be in Yerevan, Bucharest, Amman, Bern, Minsk, Belgrade, Dublin, Athens. Visit the following page to register and to check which training courses we are giving in your area: https://lirportal.ripe.net/training/courses The RIPE NCC delivers the following training courses: - LIR Training Course - RIPE Database Training Course - Basic IPv6 Training Course - DNSSEC Training Course - Measurements Tools Workshop - 2 days Advanced IPv6 Training Course - 2 days BGP Operations and Security Training Course For more information visit: https://www.ripe.net/support/training/courses With kind regards, Rumy Spratley-Kanis Training Services Manager

1 0

objection to RIPE policy proposla 2016-02
by Ruediger Volk 26 Jun '16

26 Jun '16

Dear colleagues, I spoke up at the Copenhagen meeting objecting to proposal 2016-02. - the proposal is inappropriate for a RIPE policy - and at least not acceptable for passing - and most certainly so in it's current form. The proposed policy has two sentences. The second sentence looks somewhat appropriate for a policy (though the use of "should" seems strangely fuzzy - at least in the context of the use of "MUST" in the proposal which looks like trying to invoke RFC 2119). The first sentence "requests ... NCC implement functionality" actually implying - specification - design - implementation - deployment - and appropriate documentation (for various stages) of a security [related] system - apparently intended to be used globally as a kind of Internet standard. It would be fine to request the NCC to develope a technical proposal (spec, design, interface documentation) or contribute to work on such - and that's more an issue for activity plan and resource allocation and certainly NOT for a policy. Of course the questions of other contributors and venue for the technical work come to mind. Technically the proposal text is not that clear and complete; I understand incompleteness is intentional. So neither the proposal nor a potential future NCC design can be scrutinized as required for security functionality. But the proposal - as it stands - would imply commitment to deployment when asking for the development. That is not acceptable. I doubt that the RIPE PDP is adequate for doing serious technical specifications; referencing of fully developed specs for use in NCC services is fine in general (though specific cases warrant scrutiny). Thanks for your attention and consideration. Ruediger Volk

1 0

2016-02 Discussion Period Extended Until 29 June 2016 (Resource Authentication Key ( RAK ) code for third party authentication)
by Marco Schmidt 31 May '16

31 May '16

Dear colleagues, The Discussion Phase for RIPE Policy proposal 2016-02, "Resource Authentication Key ( RAK ) code for third party authentication" has been extended until 29 June 2016. The proposal aims to allow all number resources, in exacts and more specifics, to be authenticated via an API-key that expires on a certain date. 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>. Regards, Marco Schmidt Policy Development Officer RIPE NCC

1 0

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