<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <meta name="Generator" content="Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang="EN-IE" link="#0563C1" vlink="#954F72"> <div class="WordSection1"> Hi Felipe, <o:p></o:p> <o:p> </o:p> Thank you for the email. <o:p></o:p> <o:p> </o:p> I haven’t seen any minutes of the discussion of the EB on that topic, what was the result of that discussion ? <o:p></o:p> <o:p> </o:p> If you ask me, publishing at the RIR that also provided the resources should be the only way … <o:p></o:p> <o:p> </o:p> As a community we have been dealing with objects in the RIPE DB for years ( and still have, if you look at the RIPE NON-Auth issues ) .. and I would like to avoid any pollution.<o:p></o:p> <o:p> </o:p> It will make things a lot easier if the RIPE member, can only publish self-signed RIPE resources to the RIPE parent. <o:p></o:p> <o:p> </o:p> If a particular member is both an ARIN and RIPE member, and everything is published to the RIPE parent .. and at some day, the RIPE membership is stopped.. the ARIN resources will also not be accepted anymore .. <o:p></o:p> And this will have similar scenario’s the other way around .. <o:p></o:p> <o:p> </o:p> So not for a security point of view, as each RIR will have its own certificates that will sign the respective resources .. and you could publish them theoretically everywhere .. however it will be easier to troubleshoot, if the stuff is kept within the respective RIR .. if you want to publish in parent.. <o:p></o:p> <o:p> </o:p> It isn’t called .. Publish in Parent for no reason ... it isn’t called Publish in Uncle/Aunt .. <o:p></o:p> <o:p> </o:p> So for publishing software, I would expect them to accept the delegation from a parent ( a RIR, which holds the delegated resources that it can then sign for .. ) and also publish it back to the respective RIR where the delegation came from. <o:p></o:p> <o:p> </o:p> Regards,<o:p></o:p> Erik Bais <o:p></o:p> <o:p> </o:p> <o:p> </o:p> <div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm"> From: routing-wg <routing-wg-bounces@ripe.net> on behalf of Felipe Victolla Silveira <fvictolla@ripe.net> Date: Thursday 29 September 2022 at 16:15 To: "routing-wg@ripe.net" <routing-wg@ripe.net> Subject: [routing-wg] Publish in Parent - input requested<o:p></o:p> </div> <div> <o:p> </o:p> </div> Dear all, As some of you are aware, the RIPE NCC has been working on a new service for RPKI, called Publish in Parent. This service is intended for RPKI users who have chosen to run their own Certificate Authority (delegated RPKI) but don’t want to take the burden of maintaining a highly available publication point. By using this service, it will be possible for our members with delegated RPKI to publish their signed RPKI objects in the RIPE NCC repositories (RRDP and rsync) instead of maintaining their own. Following a discussion with the Executive Board in our meeting last June, we would like to ask our community for input on the requirements for this service. The service was originally designed to allow all objects to be published in our repositories, regardless of whether the associated resources are part of the RIPE NCC or another RIR, and this is how we would like to proceed. However, it has been argued that there should be a restriction in this service so that it allows only RIPE NCC resources to be published and not resources belonging to a different RIR. If you are potential user of this service, what are your expectations for its functionality? Do you want to be able to publish all your objects in RIPE NCC repositories, regardless of whether they are from the RIPE NCC or not? Or will you publish each object in the corresponding RIR repositories? Please note that we are only talking about publication. The objects out of region will be signed with their own parent certificate. If you are a developer of one of the Relying Party softwares, will the presence or absence of such a restriction impact your software package in any way? Do you expect the need to make changes, depending on the direction this takes? To make informed decisions on how we should progress with Publish in Parent, we need input from potential users of the service. Please reply with your feedback until 14 October so we can incorporate it in our planning and inform you about our progress at RIPE 85. Kind regards, <o:p></o:p> <div> <o:p></o:p> <div> Felipe Victolla Silveira<o:p></o:p> </div> <div> Chief Operations Officer<o:p></o:p> </div> <div> RIPE NCC<o:p></o:p> </div> </div> </div> </body> </html>