Hi Niall On Fri, 2 Jul 2021 at 17:21, Niall O'Reilly via db-wg <db-wg@ripe.net> wrote:
George, Ed, everybody,
This seems as good a moment as any to wave the POLA, transparency, and due-process banners.
On 1 Jul 2021, at 23:46, George Michaelson via db-wg wrote:
I don't think this problem has a single simple fix. You can do a post-hoc sweep of the records periodically, with some process, and probably solve the classic 80/20 of this situation.
I wonder what criterion (or set of criteria) is available as the basis for such a sweep.
As Edward Shryane via db-wg wrote on 1 Jul 2021, at 17:18:
We dropped the authentication requirement for the origin as part of NWI-5, which went into production on 4th September 2018.
As I read this (from Ed), data such as are involved in “this situation” are currently acceptable for insertion into the database, according to criteria concretized in the implementation of NWI-5.
Not exactly. NWI-5 was about authorisation of correct data. It removed the requirement for mandatory authorisation by the ASN holder as well as the address space holder. It wasn't an invitation for resource holders to create ROUTE(6) objects referencing non existing ASNs or for ROUTE(6) objects to persist after the AUT-NUM object referenced in the origin is deleted.
It seems to follow that anyone who has placed such data in the database may reasonably expect that they remain there, without interference, not only for as long as these acceptance criteria remain in effect, but also beyond that until action to remove or rectify prior data has been agreed by consensus in the WG, passed as a new NWI to the NCC, and implemented with due notice to the interested parties.
Maybe the low hanging fruit here is to not allow a ROUTE(6) object to be created if it references an unregistered ASN at the time of creation. Although George did say: "Some people think use of private ASN in public routing is a "Bogon" but there are reasons for making route objects and ROA for private ASN routing surely?" But prior to NWI-5 (in 2018) if ROUTE(6) objects were created for private ASNs they would have had to create an AUT-NUM object in the RIPE Database for the private ASN to authorise the route creation. That was only possible for non RIPE ASNs. So is routing with private ASNs in the RIPE Database a recent activity? I will bow to advice from routing experts on this. cheers denis co-chair DB-WG
Process and following it are tedious.
Premature action is surprising, lacks transparency, and is unfair.
I suggest keeping to the “yellow brick road”.
Best regards, Niall
— However far away I may place my hat, some of you will be convinced you can see its shadow.