[connect-wg] BCOP for the use of IRR DBs in IXP RS - Last call

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:
>
> 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
>
>
>
> _______________________________________________
> connect-wg mailing list
> connect-wg at ripe.net
> https://lists.ripe.net/mailman/listinfo/connect-wg
>
> To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/connect-wg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ripe.net/ripe/mail/archives/connect-wg/attachments/20240605/1f16cbbe/attachment.html>