Steven Bakker <Steven.Bakker@dante.org.uk> writes: How about making the inetnum object the parent of the route object? I think it would make sense to allow the "owner" of the inetnum to create the route objects.. You can also keep the owner in the "notify:" field of the route object, so once you delegate maintenance of the route object to someone else, you can still keep track of what's happening with it.
Or does this sound ludicrous?
Not ludicrous but not obviously a widely accepted soloution either: It mixes allocation and routing registry which is maybe muddling things too much for us and certainly not implementable for routing-only registries. I would expect concerns from ISPs if customers have to change data in order for routing to be registrered. The expectation is that ISPs are more versed in registration issues. I believe that the originating AS should be in control of routes registered as originating from it. After all they control what they originate in reality. I therefore propose a simple two-tier hierarchy with the aut-num object controlling authorisation for creating route objects with an origin: attribute value equal to the AS irrespective of the prefixes. Note that may still be possible to create a route object in one RR that is protected by hierarchical authorisation in another. This fact is more relevant than with allocation registry authorisation since current practise for routing registry tools is to use the superset of all RRs (the IRR) in some way or other. Cheers Daniel