Dear Nick, On Wed, Sep 30, 2020 at 09:15:11PM +0100, Nick Hilliard wrote: > Job Snijders via db-wg wrote on 30/09/2020 21:07: > > I agree. The combination of NWI-5 and RIPE-731 obsoleted NWI-3. > > > > There is nothing left for RIPE to further improve here. RIPE-NONAUTH is > > slowly and steadily decreasing in size. AFRINIC resource holders have > > all the tools available to publish their routing intentions in either > > the AFRINIC IRR or under the AFRINIC RPKI TAL. > > > > NWI-3 can be closed. > > do we want to change the scope of the NWI?
A change of scope probably warrants a new NWI, as NWI-3 was (at the time, in that context) specificly targetted to help mop up after the transfer of inetnum/inetnum6s when AFRINIC was instantiated. > E.g. if there is a route(6): object in Afrinic which conflicts with an > existing entry in the ripedb, should the RIPE version be deleted? > Could this also apply to APNIC objects? > > If the network block is split into multiple blocks by the allocating > RIR, should the route(6): object be deleted? What if it's deallocated > or transferred to a new party. The thinking in developing RIPE-731 was that RPKI information supersedes IRR information as following: RPKI information (when applying the RFC 6811 procedure with EBGP 'invalid == reject' import policies) result in a state of the network where what conflicting RIPE-NONAUTH route/route6 objects document would be rejected because of RPKI ROV. As such automated deletion of the objects is warranted. In this regard RPKI data exists on a different (higher?) 'plane' than the data in the unvalidated IRR 'plane'. Building city upon city so to speak. The same cannot trivially be said for IRR objects superseding other IRR objects, I've never seen documentation from standards bodies describes how one IRR route object could warrant the removal of an IRR object in another IRR database under different administration. Of course, in practise such removals happens from time to time as operators send complaints to IRR database operators 'look, in the authoritative APNIC database we documented XYZ, the objects in NTTCOM/RADB/RIPE-NONAUTH are not what we want'. All such instances require manual research, as there are also plenty of examples where a supernet is registered in IRR database X, suballocations/subassignments happen and those are documented in database IRR Y. Also in practise the recommendation towards the complaint issuer would be to ask them to create RPKI ROAs as that provides unambigious verifiable attestation on what the routing intentions are. Given that RIPE-731 came to be through a run of the PDP process and not as a NWI, I suspect that further enhancements to the RIPE-NONAUTH cleanup algorithm should be handled through a similar process. > The idea here is to create a process which will, over time, eliminate > fossils. I personally believe RIPE-731 is sufficient of a cleanup process to eventually eliminate all problematic fossils... but it is a multi-year process. Kind regards, Job
