Hi, Gert Doering wrote: [...]
We currently implement RPSS, as best we understand it.
I won't claim that I understand RPSS, but I claim to have observed actual practice :-)
I think the idea is that if there is a route object in the database, then it's creation has been authorised, and that it represents an actual route announcement. If somebody else starts advertising either the same IP space with a different origin, or a more specific route then it will affect traffic to the existing origin, so they should approve the creation.
Given this explanation, do you still think that the database should permit the creation of the new object?
Yes. I think that the creation of the new route: should NOT check the authorization on any existing route: objects, but should check mnt-routes: on the corresponding/encompassing inetnum: and on the AS-Object.
"Unauthorized routes" should be sufficiently prevented by the inetnum: check.
I personally agree with you. There are a few reasons why it should be done the way you described. Unfortunately, that is definitely not what RFC2725 specifies. In order to change the behaviour we probably have to bring this up at IETF and update the spec.
Yes, I am aware that this doesn't work for inetnum:s registered in a different database, unless distributed rps-auth is implemented. I do not have a proposal how to solve this in the mean time.
We are working on such proposal, which is less complex than rps-dist. We discussed this with other RIRs as they are store authoritative information about address allocations. [...] Regards, Andrei Robachevsky RIPE NCC