--- Begin Message ---
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 <j...@instituut.net>
> To: "Carlos M. Martinez" <carlosm3...@gmail.com>, "Sascha Luck [ml]"
> <d...@c4inet.net>
> Cc: Database WG <db-wg@ripe.net>, denis walker <ripede...@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
>
>
--- End Message ---
