hierarchical auth with route objects

 Dear colleagues,

 hierarchical authorization in the RIPE-db as a new feature presented at
 the last RIPE meeting is not limited to inetnum objects or the domain
 name space. It is also applicable to route objects. However, it has not
 yet been implemented for route objects because no consensus was found on
 how to do it. With this mail I want to start the discussion again. Please
 note, that this is only the draft of a draft - nothing final. So drop your
 comments here!

 In my opinion, route objects are not much different from inetnum objects
 regarding hierarchical authorization. Both span a certain range of IP
 addresses and in both cases hierarchical authorization controls definition
 of IP subranges. Following this reasoning it seems to be simple to implement
 within the IP prefix tree.

 However, route objects are not standing alone but are logically linked to
 AS objects via the origin tag. Applying hierarchical authorization within
 the IP prefix tree *alone* does allow uncontrolled creation of route objects
 of differing origin. Therefore, AS objects which match the origin AS of a
 route object may be considered as parent objects of route objects. I think
 this is a very useful approach (even though it links different types of
 objects in one authorization hierarchy).

 There have been ideas that route objects should only be created if proper
 address allocation occured. However, it has also been pointed out that it
 is not a good idea to mix address allocation and routing for several rea-
 sons, e.g. some registries are pure routing registries and all registries
 should have the same structure. Moreover, changes in routing might make
 changes in address registration necessary (and vice versa). There have been
 some good comments on this topic on the database wg mailing list. Never-
 theless, if no route objects exist for allocated address space, any AS
 owner may generate route objects uncontrolled in this registry (creation
 of objects in one registry which are protected by hierarchical authorization
 in another is also not covered but this is an entirely different problem).

 Obviously, there are still some loose ends. But I think that the approach
 of AS objects as parents of route objects from corresponding origin com-
 bined with hierarchical authorization within the IP prefix tree is very
 useful and may be applied here.  Shall we go for this?

 Regards
    Joachim Schmitz
_____________________________________________________________________________

 Dr. Joachim Schmitz                                   schmitz@localhost
 DFN Network Operation Center
 Rechenzentrum der Universitaet Stuttgart              ++ 711 685 5553 voice
 Allmandring 30                                        ++ 711 678 8363  FAX
 D-70550 Stuttgart                                     FRG (Germany)
_____________________________________________________________________________