Hi all,
On 13 Dec 2017, at 19:25, denis walker <ripedenis@yahoo.co.uk> wrote:
Hi all
From: Nick Hilliard via db-wg <db-wg@ripe.net> To: Tim Bruijnzeels <tim@ripe.net> Cc: Database WG <db-wg@ripe.net> Sent: Tuesday, 12 December 2017, 23:16 Subject: Re: [db-wg] NWI-5 Out of region ROUTE(6)/AUT-NUM objects implementation request
Tim Bruijnzeels via db-wg wrote:
Dear working group,
We are tasked by the co-chairs on 19 October 2017 to come up with an implementation proposal for NWI-5.
One final issue that hasn't been addressed: should it be possible for new objects to be created with source: RIPE-NONAUTH? My preference would be not, but this is something that we might want to discuss in the working group.
Before answering this question, perhaps Tim you can say if it will still be possible to create foreign ROUTE objects after this implementation?
The proposal I wrote was scoped to the following only, as per request of the co-chairs: 1) Remove the "origin:" authorization requirement 2) Flag "route:" objects for non-RIPE-managed space with "source: RIPE-NONAUTH" to identify non-authoritative data. So, in my mind this will still allow the creation of new ROUTE(6) objects with “source: RIPE-NONAUTH”. I am not opposed to disallowing this, and only allow existing objects to be modified or deleted. We get a lot of complaints about out-of-region objects - and we don’t have a clear mandate to do anything with these objects. Preventing the creation of additional objects will at least prevent this situation from getting worse. It would also be a strong indication that such objects should be created in the authoritative databases as far as they exist, especially the APNIC and AFRINIC databases. For ARIN and LACNIC space this may not be possible though: I believe that ARIN has plans to work on their IRR, but for the moment RADB would then be the de-facto place. LACNIC does not currently support ROUTE(6) objects, but does have good RPKI data that one could use: https://lirportal.ripe.net/certification/content/static/statistics/world-roa... But, as RIPE NCC staff, I believe the working group should discuss this and my opinion on this is secondary.
Currently there are place holder INET(6)NUM objects in the RIPE Database covering all non RIPE address space. These objects have an "mnt-routes:" attribute referencing the MNTNER object with the public password. This is necessary to (by)pass the address space auth requirements for creating ROUTE(6) objects. Do you plan to make any changes to this mechanism/arrangement with this implementation?
If no more new RIPE-NONAUTH ROUTE(6) objects may be created then the “mnt-routes:” attribute on these placeholders should be removed. Kind regards Tim
cheers denis co-chair DB WG
Nick