I think its time to stop disrespecting external source of authority on this. You argued for a position based on the desire of RIPE entities needing to import foreign objects into their RPSL But you did not address the far larger body of people who are exposed to risks from the public maintainer and foreign object model, which we know is causing problems. I have presented three times on this at RIPE meetings in Dublin, Bucharest and Amsterdam pointing out that APNIC helpdesk and hostmaster are mediating calls from members who are concerned at how their ASN wound up in the RIPE RPSL. I also spoke recently at the APNIC services meeting to this, calling for a bit more dialogue on what we want to do. Lets build an ecology which can handle disparate sources, and stop demanding a bogus security model. The open maintainer is yesterdays man. a) Move the non-local stuff to another source and be explicit its an import to allow people to discriminate. We should do this irrespective of any other work: its not in RIPE data management, its not part of RIPE authoritative statements. A declaration of intent through an open maintainer is functionally indistinguishable from a lie. b) We can think about ROA. There is no permission from the origin-as to be referred to in a ROA, and we know that people regard the ROA as semantically in the same space as the route: object which demands the aut-num import. So we have a clear signal that routing praxis is now not that concerned with ASN authority to be cited in origin-AS. If you remove the dependency on aut-num maintainer, you will removed the dependency on foreign object import. The validity of authority over the aut-num can be understood from its appropriate RIR or NIR declaration, as an imported source. -George On Wed, Oct 11, 2017 at 8:06 AM, Job Snijders via db-wg <db-wg@ripe.net> wrote:

---------- Forwarded message ---------- From: Job Snijders <job@instituut.net> To: "Carlos M. Martinez" <carlosm3011@gmail.com>, "Sascha Luck [ml]" <dbwg@c4inet.net> Cc: Database WG <db-wg@ripe.net>, denis walker <ripedenis@yahoo.co.uk> Bcc: Date: Wed, 11 Oct 2017 15:06:04 +0000 Subject: Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision?

On Wed, 11 Oct 2017 at 16:52, Sascha Luck [ml] via db-wg <db-wg@ripe.net> wrote:

...

On Wed, Oct 11, 2017 at 11:30:06AM -0300, Carlos M. Martinez wrote:

...

IMHO, any idea that starts with “Let´s create a central X” is doomed from the start.

We must think along other lines.

Maybe "central" was the wrong word to use. Think a DB that every RIR provides a copy of and authenticates the bits that "belong" to it. This would even be necessary to avoid compromise. One could pick the copy to use for filter generation or even query them all and implement a majority decision if there are discrepancies. Of course it would require all RIRs to use the same RPSL format but that appears more of a political than a technical problem.

We already have that “central IRR” in the form of the likes of the RADB Whois server. RIPE’s data is the odd one out here.

RIPE is the _only_ IRR source where we cannot differentiate between authenticated data and non-authenticated data.

For all other sources we know that either the route objects have been authenticated against the inetnum’s specified maintainer (APNIC, AFRINIC, JPIRR) or is entirely without such verification (ARIN, NTTCOM, ALTDB, RADB itself, etc).

The value of the data in the RIPE DB would significantly increase if this difference is shown.

Kind regards,

Job