From mschmidt at ripe.net Mon May 2 14:12:40 2016 From: mschmidt at ripe.net (Marco Schmidt) Date: Mon, 02 May 2016 14:12:40 +0200 Subject: [ncc-services-wg] 2016-02 New Policy Proposal (Resource Authentication Key ( RAK ) code for third party authentication) Message-ID: <57274438.2040902@ripe.net> 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 before 31 May 2016. Regards, Marco Schmidt Policy Development Officer RIPE NCC From ak at list.ak.cx Mon May 2 14:27:57 2016 From: ak at list.ak.cx (=?UTF-8?Q?Andr=c3=a9_Keller?=) Date: Mon, 2 May 2016 14:27:57 +0200 Subject: [ncc-services-wg] 2016-02 New Policy Proposal (Resource Authentication Key ( RAK ) code for third party authentication) In-Reply-To: <57274438.2040902@ripe.net> References: <57274438.2040902@ripe.net> Message-ID: <9b14acab-2139-953e-7c60-18913e84c0d7@list.ak.cx> Hi, On 02.05.2016 14:12, Marco Schmidt wrote: > We encourage you to review this proposal and send your comments to > before 31 May 2016. Isn't this something that is already possible using the RPKI ROAs ? Regards Andr? From gert at space.net Mon May 2 14:31:46 2016 From: gert at space.net (Gert Doering) Date: Mon, 2 May 2016 14:31:46 +0200 Subject: [ncc-services-wg] 2016-02 New Policy Proposal (Resource Authentication Key ( RAK ) code for third party authentication) In-Reply-To: <57274438.2040902@ripe.net> References: <57274438.2040902@ripe.net> Message-ID: <20160502123146.GQ56633@Space.Net> Hi, On Mon, May 02, 2016 at 02:12:40PM +0200, Marco Schmidt wrote: > 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 > before 31 May 2016. I might be a bit old and stupid, but let me paraphrase if I understand this right: - people put crap into the RADB all day long - so we add an API for the RIPE DB so that the RADB operators can auto-check whether a given (prefix,as) tupel has been authorized by the owner in their corresponding registry (here: RIPE) correct? If yes, I don't think this is a good approach - because if the RADB and other operators actually were *interested* in reducing the amount of crap in their database, they could cross-check RIPE route:/route6: objects already today, without any new API needed. Evidence shows that they are not interested, even when presented with "hey, there is garbage in your database, look at the RIPE DB for the correct route: object" nothing happens. Ceterum censeo: RADB must die, and as this proposal will not speed up the process, so it's not helping. (NTT, on the other side, is already cross-checking - so I'm not sure I see the benefit for them. But if Job convinces me that it makes life easier for them, I stand corrected) Gert Doering -- router operator, and victim of RADB garbage -> hijacks -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From job at instituut.net Mon May 2 15:30:22 2016 From: job at instituut.net (Job Snijders) Date: Mon, 2 May 2016 15:30:22 +0200 Subject: [ncc-services-wg] 2016-02 New Policy Proposal (Resource Authentication Key ( RAK ) code for third party authentication) In-Reply-To: <20160502123146.GQ56633@Space.Net> References: <57274438.2040902@ripe.net> <20160502123146.GQ56633@Space.Net> Message-ID: <20160502133022.GG926@57.rev.meerval.net> Hi Gert, On Mon, May 02, 2016 at 02:31:46PM +0200, Gert Doering wrote: > On Mon, May 02, 2016 at 02:12:40PM +0200, Marco Schmidt wrote: > > 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 > > before 31 May 2016. > > If yes, I don't think this is a good approach - because if the RADB > and other operators actually were *interested* in reducing the amount > of crap in their database, they could cross-check RIPE route:/route6: > objects already today, without any new API needed. > > Evidence shows that they are not interested, even when presented with > "hey, there is garbage in your database, look at the RIPE DB for the > correct route: object" nothing happens. It is my experience with both RADB and NTTCOM that when you email the database operator and present them with evidence, it gets cleaned up (might take up to three weeks). Admittedly I've not been succesful with all database operators out there. > Ceterum censeo: RADB must die, and as this proposal will not speed up > the process, so it's not helping. We can put the third-party databases to rest once we have 100% feature parity in their respective replacements, those successors need to be accessible both in terms of reading & writing to all relevant stakeholders. > (NTT, on the other side, is already cross-checking - so I'm not sure I > see the benefit for them. But if Job convinces me that it makes life > easier for them, I stand corrected) Just like RADB, NTTCOM (the IRR Registry by NTT) is _not_ doing any cross-checking at this moment. It's unfortunate, but any NTTCOM mntner can create garbage objects. When NTT staff come across garbage (or are made aware), the garbage is mopped up. NTTCOM & RADB use the same IRRd software. Differences are the operating company & staff, original database content and mirror selection criteria. As third-party IRR database operator, I have a strong interest in anything that can help improve the quality of the data. I can't imagine it's any different for Merit. I think you are referring "irrlockdown" which is a slightly different approach on route-filter generation. IRRLockdown promotes the idea of outright ignoring route-objects which are covered by RIPE NCC managed IP space, from all IRR databases except RIPE itself. Today "irrlockdown" has not been deployed in NTT due to certain as of yet unresolved software & communication challenges. I guess irrlockdown and proposal 2016-02 aim for the same result, but come from very different directions. One approach hinges on "don't publish or consume unverifiable data" the other is I guess "make it possible to verify data prioir to publishing and consumption". As to the policy proposal itself: I would probably benefit from a (highlevel) diagram displaying which interactions on which pieces of the data happen where and how that results in something useful. Kind regards, Job From gert at space.net Mon May 2 16:02:15 2016 From: gert at space.net (Gert Doering) Date: Mon, 2 May 2016 16:02:15 +0200 Subject: [ncc-services-wg] 2016-02 New Policy Proposal (Resource Authentication Key ( RAK ) code for third party authentication) In-Reply-To: <20160502133022.GG926@57.rev.meerval.net> References: <57274438.2040902@ripe.net> <20160502123146.GQ56633@Space.Net> <20160502133022.GG926@57.rev.meerval.net> Message-ID: <20160502140215.GS56633@Space.Net> Hi, On Mon, May 02, 2016 at 03:30:22PM +0200, Job Snijders wrote: > I think you are referring "irrlockdown" which is a slightly different > approach on route-filter generation. IRRLockdown promotes the idea of > outright ignoring route-objects which are covered by RIPE NCC managed IP > space, from all IRR databases except RIPE itself. Today "irrlockdown" > has not been deployed in NTT due to certain as of yet unresolved > software & communication challenges. Oh, indeed. I assumed that this has been implemented and is live already (and I applaud you for the effort, even if it's still being stalled). > I guess irrlockdown and proposal 2016-02 aim for the same result, but > come from very different directions. One approach hinges on "don't > publish or consume unverifiable data" the other is I guess "make it > possible to verify data prioir to publishing and consumption". > > As to the policy proposal itself: I would probably benefit from a > (highlevel) diagram displaying which interactions on which pieces of the > data happen where and how that results in something useful. ... and some argument why it cannot be done with a RPKI ROA lookup, or a plain whois lookup. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From erik at bais.name Mon May 2 16:02:39 2016 From: erik at bais.name (Erik Bais) Date: Mon, 2 May 2016 14:02:39 +0000 Subject: [ncc-services-wg] 2016-02 New Policy Proposal (Resource Authentication Key ( RAK ) code for third party authentication) In-Reply-To: <20160502123146.GQ56633@Space.Net> References: <57274438.2040902@ripe.net> <20160502123146.GQ56633@Space.Net> Message-ID: <862A73D42343AE49B2FC3C32FDDFE91C01613CCF19@E2010-MBX03.exchange2010.nl> Hi Gert, > I might be a bit old and stupid, but let me paraphrase if I understand this right: > - people put crap into the RADB all day long > - so we add an API for the RIPE DB so that the RADB operators can > auto-check whether a given (prefix,as) tupel has been authorized by > the owner in their corresponding registry (here: RIPE) > correct? That is the initial described intention .. but it could be used in the future for other things as well. Like a digital LOA .. or apps .. > If yes, I don't think this is a good approach - because if the RADB and > other operators actually were *interested* in reducing the amount of crap > in their database, they could cross-check RIPE route:/route6: objects > already today, without any new API needed. If there would be a route object in the RIPE DB, the problem wouldn't exist would it .. ? The issue is specifically for NON-RIPE AS numbers with RIPE IP Resources .. that aren't maintained for route objects in the RIPE DB ... > Evidence shows that they are not interested, even when presented with > "hey, there is garbage in your database, look at the RIPE DB for the > correct route: object" nothing happens. I don't share the same experience that you have on this with RADB, I do see that with Savvy for instance ..... Level3 just takes a month.. but it will be picked up is my current experience.. > Ceterum censeo: RADB must die, and as this proposal will not speed up the process, so it's not helping. That is a bit harsh ... > (NTT, on the other side, is already cross-checking - so I'm not sure I see > the benefit for them. But if Job convinces me that it makes life easier > for them, I stand corrected) I'm sure that NTT could provide insight in how they are currently doing it. > Gert Doering > -- router operator, and victim of RADB garbage -> hijacks The goal is to limit the options so that spammers can't initiate hijacks ... So there is a common goal .. Regards, Erik Bais From gert at space.net Mon May 2 16:25:57 2016 From: gert at space.net (Gert Doering) Date: Mon, 2 May 2016 16:25:57 +0200 Subject: [ncc-services-wg] 2016-02 New Policy Proposal (Resource Authentication Key ( RAK ) code for third party authentication) In-Reply-To: <862A73D42343AE49B2FC3C32FDDFE91C01613CCF19@E2010-MBX03.exchange2010.nl> References: <57274438.2040902@ripe.net> <20160502123146.GQ56633@Space.Net> <862A73D42343AE49B2FC3C32FDDFE91C01613CCF19@E2010-MBX03.exchange2010.nl> Message-ID: <20160502142557.GU56633@Space.Net> Hi, On Mon, May 02, 2016 at 02:02:39PM +0000, Erik Bais wrote: > > If yes, I don't think this is a good approach - because if the RADB and > > other operators actually were *interested* in reducing the amount of crap > > in their database, they could cross-check RIPE route:/route6: objects > > already today, without any new API needed. > > If there would be a route object in the RIPE DB, the problem wouldn't exist would it .. ? > The issue is specifically for NON-RIPE AS numbers with RIPE IP Resources .. that aren't maintained for route objects in the RIPE DB ... Well, RPKI ROAs would certainly work for arbitrary ASes - so "RIPE IP resources with non-RIPE AS numbers" have a working technical mechanism today. I'm not exactly sure about non-RIPE AS numbers, but that *should* be doable for route:/route6: objects as well (there's always the "must be authorized by the AS holder" catch, which might get in the way here). > > Evidence shows that they are not interested, even when presented with > > "hey, there is garbage in your database, look at the RIPE DB for the > > correct route: object" nothing happens. > > I don't share the same experience that you have on this with RADB, > I do see that with Savvy for instance ..... Level3 just takes a > month.. but it will be picked up is my current experience.. "A month" is a very very long time in Internet standards. > > Ceterum censeo: RADB must die, and as this proposal will not speed up the process, so it's not helping. > That is a bit harsh ... Yeah, it's a bit unfair to single out RADB. "Any IRR DB that is used by people to build BGP filters and at the same time permits arbitrary people to put in arbitrary routing resource records without verification with their home RIR must die." 20 years ago, when the Internet was a place full of friendly people that worked together to the common good, such a open databases had their place and were a good thing. Today, it's highly problematic. People have good intentions and *do* build BGP filters from these heaps of crap, which effectively do nothing to stop hijackers and intentional abusers. [..] > The goal is to limit the options so that spammers can't initiate > hijacks ... So there is a common goal .. I still fail to see why this new technical mechanism is better than the existing mechanism (RPKI, at least, and possibly route/route6 objects), *and* why these database operators would actually *use* them, if they fail to do verification today for the existing and easy cases. OTOH, some evidence of buy-in from L3, RADB, etc. that this is something they are only waiting for and stuff will get implemented quickly afterwards would convince me that it's a good thing :-) Gert Doering -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From ebais at a2b-internet.com Mon May 2 17:56:02 2016 From: ebais at a2b-internet.com (Erik Bais) Date: Mon, 2 May 2016 17:56:02 +0200 Subject: [ncc-services-wg] 2016-02 New Policy Proposal (Resource Authentication Key ( RAK ) code for third party authentication) In-Reply-To: <20160502142557.GU56633@Space.Net> References: <57274438.2040902@ripe.net> <20160502123146.GQ56633@Space.Net> <862A73D42343AE49B2FC3C32FDDFE91C01613CCF19@E2010-MBX03.exchange2010.nl> <20160502142557.GU56633@Space.Net> Message-ID: <01b001d1a48b$30e1d150$92a573f0$@a2b-internet.com> On Mon, May 02, 2016 at 02:26:46PM +0200, Gert Doering wrote: > [..] On Mon, May 02, 2016 at 02:02:39PM +0000, Erik Bais wrote: >> The goal is to limit the options so that spammers can't initiate >> hijacks ... So there is a common goal .. >I still fail to see why this new technical mechanism is better than the >existing mechanism (RPKI, at least, and possibly route/route6 objects), >*and* why these database operators would actually *use* them, if they >fail to do verification today for the existing and easy cases. The issue with RPKI .. is that that not everything is signed ... Another issue due to the distributed options in RPKI, one can run their own certification environment.. The intention is to use a system that would fix it for the all IP resources within a single region (RIPE in this example) in order to close idiotic input into those DB's.... Yes, there is currently garbage in some of those databases.. I'm personally still waiting on a reply from the Savvy DB maintainers for a ticket update send 2 months ago .. perhaps longer .. If the third party database isn't updating to the new way of authorizing prefixes to the originating RIR and not doing any housekeeping on expired objects ... their usefulness is close to zero for future use and inclusion in any prefix filter development that is in the future. I would personally like to see future developments of bgpq3 or the IRR Toolset to limit their default inclusion to those DB's that actually validate input ... >OTOH, some evidence of buy-in from L3, RADB, etc. that this is something >they are only waiting for and stuff will get implemented quickly >afterwards would convince me that it's a good thing :-) Agree, I think that this would indeed be a good thing ... Regards, Erik Bais From mschmidt at ripe.net Tue May 17 14:09:25 2016 From: mschmidt at ripe.net (Marco Schmidt) Date: Tue, 17 May 2016 14:09:25 +0200 Subject: [ncc-services-wg] RIPE Policy Proposal 2016-03 Affects Certification for Allocations from IPv4 Pool Message-ID: <573B09F5.2030904@ripe.net> 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 before 15 June 2016. Regards, Marco Schmidt Policy Development Officer RIPE NCC From kurtis at kurtis.pp.se Tue May 17 17:54:36 2016 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Tue, 17 May 2016 17:54:36 +0200 Subject: [ncc-services-wg] NCC Services WG Agenda Message-ID: 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 at kurtis.pp.se -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: Message signed with OpenPGP using GPGMail URL: From mir at ripe.net Wed May 18 09:56:47 2016 From: mir at ripe.net (Mirjam Kuehne) Date: Wed, 18 May 2016 09:56:47 +0200 Subject: [ncc-services-wg] New on RIPE Labs: RIPE NCC Membership and Available IPv4 Statistics - an Update Message-ID: <09f00658-a353-4393-eade-df89ee8b33c7@ripe.net> 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-ipv4-statistics-an-update?pk_campaign=labs&pk_kwd=list-services Kind regards, Mirjam Kuehne RIPE NCC From alexb at ripe.net Wed May 18 14:56:30 2016 From: alexb at ripe.net (Alex Band) Date: Wed, 18 May 2016 14:56:30 +0200 Subject: [ncc-services-wg] Improving the Management of RIPE Database Objects with Joint Responsibility Message-ID: 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-database-objects-with-joint-responsibility Kind regards, Alex Band Product Manager RIPE NCC From ljb at merit.edu Thu May 19 22:07:12 2016 From: ljb at merit.edu (Larry Blunk) Date: Thu, 19 May 2016 16:07:12 -0400 Subject: [ncc-services-wg] 2016-02 New Policy Proposal (Resource Authentication Key ( RAK ) code for third party authentication) In-Reply-To: <20160502133022.GG926@57.rev.meerval.net> References: <57274438.2040902@ripe.net> <20160502123146.GQ56633@Space.Net> <20160502133022.GG926@57.rev.meerval.net> Message-ID: <573E1CF0.90400@merit.edu> On 05/02/2016 09:30 AM, job at instituut.net (Job Snijders) wrote: > Hi Gert, > > On Mon, May 02, 2016 at 02:31:46PM +0200, Gert Doering wrote: >> On Mon, May 02, 2016 at 02:12:40PM +0200, Marco Schmidt wrote: >>> 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 >>> before 31 May 2016. >> >> If yes, I don't think this is a good approach - because if the RADB >> and other operators actually were *interested* in reducing the amount >> of crap in their database, they could cross-check RIPE route:/route6: >> objects already today, without any new API needed. >> >> Evidence shows that they are not interested, even when presented with >> "hey, there is garbage in your database, look at the RIPE DB for the >> correct route: object" nothing happens. > > It is my experience with both RADB and NTTCOM that when you email the > database operator and present them with evidence, it gets cleaned up > (might take up to three weeks). Admittedly I've not been succesful with > all database operators out there. (Apologies for belated reply -- I'm on the Database WG list, but just recently joined the NCC Services WG list) Just to follow up on Job's comment. We (Merit RADB) have been working on training our 24x7 NOC team the last couple years to provide RADB support and integration with their existing ticketing system and believe ourselves to be responsive to requests for clean up's. We've also be more proactive on monitoring new account creation requests and looking for certain suspicious indications. > >> Ceterum censeo: RADB must die, and as this proposal will not speed up >> the process, so it's not helping. > > We can put the third-party databases to rest once we have 100% feature > parity in their respective replacements, those successors need to be > accessible both in terms of reading & writing to all relevant > stakeholders. > >> (NTT, on the other side, is already cross-checking - so I'm not sure I >> see the benefit for them. But if Job convinces me that it makes life >> easier for them, I stand corrected) > > Just like RADB, NTTCOM (the IRR Registry by NTT) is _not_ doing any > cross-checking at this moment. It's unfortunate, but any NTTCOM mntner > can create garbage objects. When NTT staff come across garbage (or are > made aware), the garbage is mopped up. > > NTTCOM & RADB use the same IRRd software. Differences are the operating > company & staff, original database content and mirror selection > criteria. As third-party IRR database operator, I have a strong interest > in anything that can help improve the quality of the data. I can't > imagine it's any different for Merit. We certainly agree with this statement and have resources we can allocate to making improvements. > > I think you are referring "irrlockdown" which is a slightly different > approach on route-filter generation. IRRLockdown promotes the idea of > outright ignoring route-objects which are covered by RIPE NCC managed IP > space, from all IRR databases except RIPE itself. Today "irrlockdown" > has not been deployed in NTT due to certain as of yet unresolved > software & communication challenges. > > I guess irrlockdown and proposal 2016-02 aim for the same result, but > come from very different directions. One approach hinges on "don't > publish or consume unverifiable data" the other is I guess "make it > possible to verify data prioir to publishing and consumption". > > As to the policy proposal itself: I would probably benefit from a > (highlevel) diagram displaying which interactions on which pieces of the > data happen where and how that results in something useful. I can see value in this proposal and would also welcome a highlevel diagram with some additional details of interactions. Regards, Larry Blunk Merit Network From mschmidt at ripe.net Tue May 31 16:15:01 2016 From: mschmidt at ripe.net (Marco Schmidt) Date: Tue, 31 May 2016 16:15:01 +0200 Subject: [ncc-services-wg] 2016-02 Discussion Period Extended Until 29 June 2016 (Resource Authentication Key ( RAK ) code for third party authentication) Message-ID: <574D9C65.8000009@ripe.net> 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 . Regards, Marco Schmidt Policy Development Officer RIPE NCC