<html theme="default-light" iconset="color"><head> <meta http-equiv="Content-Type" content="text/html; charset=windows-1252"> </head><body text="#485663">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 type="cite" cite="mid:DBBPR08MB623479AB89685D87E9F43CE8AFF82@DBBPR08MB6234.eurprd08.prod.outlook.com" style="word-wrap:break-word"> <meta http-equiv="Content-Type" content="text/html; charset=windows-1252"> <meta name="Generator" content="Microsoft Word 15 (filtered medium)"> <style></style> <div class="WordSection1"> Hi folks,<o:p></o:p> <o:p>�</o:p> 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.<o:p></o:p> <o:p>�</o:p> 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. <o:p></o:p> <o:p>�</o:p> 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).<o:p></o:p> <o:p>�</o:p> <o:p>�</o:p> <o:p>�</o:p> Kind Regards<o:p></o:p> <o:p>�</o:p> Stavros, Marco, Will, Andrei<o:p></o:p> </div> <fieldset class="mimeAttachmentHeader"></fieldset> <pre wrap="">_______________________________________________ connect-wg mailing list <a class="moz-txt-link-abbreviated" href="mailto:connect-wg@ripe.net">connect-wg@ripe.net</a> <a class="moz-txt-link-freetext" href="https://mailman.ripe.net/">https://mailman.ripe.net/</a> To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: <a class="moz-txt-link-freetext" href="https://mailman.ripe.net/">https://mailman.ripe.net/</a> </pre> </blockquote> </body></html>