[db-wg] re-evaluate route-object authorisation model

Job
Responding to the Questions in your 13 May email, thanks for helping me 
get up to speed.

|    - should the authorisation model work differently for RIPE managed
|      space versus non-RIPE managed space? Should we even continue to
|      allow route-objects covering non-RIPE managed space?

No.  Authorisation for an AS to originate a route needs to come from the 
maintainer of the address space.
If the address space is assigned by a different RIR then Creating a 
Route Object in RIPE should be disallowed.
Legacy v4 may need special case, I do not know.

However, a global routing information database will need to contain 
copies of information from other regions, but it would support no 
modification of the copied records.  Mirror only.

|    - should the authorisation model work differently when creating a
|      route-object for RIPE managed space with a non-RIPE managed
|      autnum? If yes, how so?

No.  We should follow the more recent thinking behind RPKI:
"the design of the rpki is that an address resource
holder is the sole authority over what ASs may announce that resource", 
Randy Bush

|    - although in this idea the autnum owner is no longer required to
|      approve /creation/ of a route-object, would it be a good idea to
|      allow the autnum owner to /delete/ any route-object in which 
their
|      autnum is referenced as origin?

I see no need, since the AS still has the choice whether or not to 
announce the route. The database grants authority, not compulsion, to 
announce.

|    - Is RFC 2725 the only reason why the authorisation model was
|      implemented as it was implemented, can someone remember practical
|      reasons for doing it this way? During the BoF it was pointed out
|      that any potential DoS vector already exists today.

Wilfried Woeber's concerns in 2006 seem largely to be about 
accreditation and authority of what is now the inetnum maintainer.  
Those concerns may still be valid, and may need addressing, but are not 
directly related to this discussion.  The worst examples of IRR seem to 
have many exploitable faults independently of this.
Our objective is to inspire confidence in RIPE's routing database for 
use in routing policy,  to facilitate the completeness of the routing 
database by reducing a hindrance to maintaining its correctness, whilst 
retaining the higher standards adopted in RIPE.

Steve Nash