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
[email protected]
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
_______________________________________________
connect-wg mailing list
[email protected]
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
