I have no idea Job. It has been like this for as long as I can remember, maybe at least the last 20 years since we implemented the RPSL version of the RIPE Database.

Tom gave some reasons for it in his reply. The database mechanics simply reflect the policies and practices. There are different options:
-error, as it is now
-warning that another ROUTE object exists
-send notification to existing ROUTE ASN holder
-allow creation and do nothing
-???

If there is strong feeling that something should be changed or looked at again, maybe you should start a discussion on the best options for these situations on the Routing WG mailing list. The impact of any change is a routing issue. Then come back to DB WG if something needs changing.

cheers
denis

co-chair DB-WG

On Thursday, 11 June 2020, 15:30:46 CEST, Job Snijders via db-wg <db-wg@ripe.net> wrote:


On 11/06/2020 03:26, ripedenis--- via db-wg wrote:
> If there is an existing, exact matching ROUTE object the creation of the
> new ROUTE object must be authorised by the existing object. There is a
> flow chart here explaining the sequence of checks:
> https://www.ripe.net/support/training/material/bgp-operations-and-security-training-course/route-object-creation-flowchart.pdf

Ah - great pointer. thanks.

Denis, do you remember *why* that is the rule?

I don't see a lot of benefit to requiring the existing object to
authorise the creation of a *new* object, when the new object is
authorised by the inetnum (in this case both through mnt-routes: and
mnt-by:).


>>  ***Error:  Authorisation for [route] 194.76.156.0/22AS20676 failed
>>  using "mnt-by:" not authenticated by: PLUSNET-NOC
>
> Could we reduce the confusion, and/or spread some more clue, by being
> more specific with this error? e.g.
>
>    Authorisation for [blah] failed using "mnt-by:"
>    - matching route object already exists
>    - not authenticated by: PLUSNET-NOC


Perhaps instead of an error message, the operation that Sasha tried to
do should just be allowed?

Kind regards,

Job