<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=Windows-1252"> <meta name="Generator" content="Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang="en-NL" link="blue" vlink="purple" style="word-wrap:break-word"> <div class="WordSection1"> Hi Nick,<o:p></o:p> <o:p> </o:p> Thank you very much for participating in this discussion, much appreciated. <o:p></o:p> <o:p> </o:p> I agree with Marco’s replies on your feedback, and I would like to add 1-2 short comments:<o:p></o:p> <ul style="margin-top:0cm" type="disc"> <li class="MsoListParagraph" style="margin-left:0cm;mso-list:l0 level1 lfo3">I do believe the second argument of yours is not that strong. This doc is just a BCOP in the RIPE region with a narrow scope, is not even a policy that is enforced from RIPE NCC. Actually, I would be more concerned about the ongoing Cyber Resilience Act that could send the route servers to the graveyard and eliminate similar future discussions. <o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0cm;mso-list:l0 level1 lfo3">If an organization has such a size that holds resources in multiple RIRs and those resources are being updated so frequently, I believe would not be an issue to put some development resources to adopt a few REST APIs which I expect to be similar (due to the adoption of IRRDv4). I know that so far RIPE, ARIN, APNIC and LACNIC offer REST APIs to manage resources in the databases. Here in AMS-IX (which is a small organization) we do have it in our 2024 pipeline to adopt those APIs. If however the tooling is the obstacle, then I would be happy to see how can I contribute in this aspect. <o:p></o:p></li></ul> <o:p> </o:p> <o:p> </o:p> Kind Regards<o:p></o:p> Stavros<o:p></o:p> <o:p> </o:p> <div id="mail-editor-reference-message-container"> <div> <div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm"> From: Nick Hilliard (INEX) <nick@inex.ie> Date: Thursday, 6 June 2024 at 00:04 To: Stavros Konstantaras <stavros.konstantaras@ams-ix.net> Cc: Connect-WG <connect-wg@ripe.net> Subject: Re: [connect-wg] BCOP for the use of IRR DBs in IXP RS - Last call<o:p></o:p> </div> Hi Stavros / authors, I don't think connect-wg should adopt this document as a BCOP, at least not for the moment. Apart from the concerns raised by Job, Randy and also Arnold's comments at the mic during the connect-wg meeting, there are a couple of reasons for this which I'd like to add. The first, and main one, is that this isn't current operational practice across a lot of IXPs. It might happen one day that it'll be adopted widely across IXPs, but as far as I'm aware, we're not at that point yet. When we're sure that it's reasonable and widely-deployed current operational practice, then that would be the point at which it might be appropriate to starting thinking of designating it as best current operational practice. But it would be premature to make the leap from our current position to BCOP status, without several years of widespread deployment. The second concern I have is that routing security is a hot topic in regulatory circles right now. As an industry, we need to be very careful about what is published with the stamp of approval from industry groups and quasi-SDOs, because regulatory authorities adopt documents of this sort as mandatory national or supra-national requirement lists and sometimes do so without a full understanding of the downstream consequences. The lifetime of regulatory standards is measured in years / decades, and if it turns out that there are unforeseen issues with the proposals in this doc, then it will be difficult to unscramble the egg. From this point of view alone, i.e. separate to the issue of whether the positions stated in the document are technically advisable or not, the language in this document needs serious work before it would be suitable for publication. The current text is very prescriptive and this is not a good thing for a technical policy document. In the case of routing security, there are still difficulties for organisations who have ASNs, as-sets and route lists which span different RIRs, and for whom third party IRRDBs provide a reasonable and responsible mechanism for expressing their intended routing policies. Cutting these organisations off is not going to help routing security overall - they'll simply bypass route servers and then the industry will be back to unfiltered bgp sessions again. In terms of object conflicts, there are certainly issues. I think it would be good to address these issues and to try to get common processes in place to remove conflicts when it's obvious that non-canonical IRRDBs are maintaining stale information. The RIPE NCC continually addresses this in RIPE-NONAUTH and there is no reason that other IRRDBs couldn't do similar things. Nick Stavros Konstantaras wrote on 04/06/2024 12:16: <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <div> Hi folks, We are discussing this subject since RIPE86 and we have presented our progress in both RIPE87 and RIPE88. Every time we bring this subject, we receive strong support from the community, both during the presentations and in personal discussions. We thank you all for that as it provides us fuel and motivation to continue our work. I have discussed the process with RIPE NCC employees and they are happy to adopt it as an official RIPE BCP/document, as long as the support is documented in this mailing list. Thus, we would like to make a call for adoption for this working item. Please find attached the latest version of the draft and feel free to submit your comments in case you find mistakes (e.g. typos, grammar, etc etc). Kind Regards Stavros, Marco, Will, Andrei </div> <o:p></o:p> <pre>_______________________________________________</pre> <pre>connect-wg mailing list</pre> <pre><a href="mailto:connect-wg@ripe.net">connect-wg@ripe.net</a></pre> <pre><a href="https://mailman.ripe.net/">https://mailman.ripe.net/</a></pre> <pre><o:p> </o:p></pre> <pre>To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: <a href="https://mailman.ripe.net/">https://mailman.ripe.net/</a></pre> </blockquote> <o:p> </o:p> </div> </div> </div> </body> </html>