hierarchical route objects, part 1

Hi,

just a few quick comments to your proposal.

>  regarding hierarchical authorization of route objects in the
>  RIPE database: from what I have heard there is a general
>  feeling that it is needed and the basic scheme to implement it
>  should follow the lines:

You say very little about the reasons and motivations for wanting
the modified behaviour.  I think that is important to state.
I've made some guesses below -- correct them as appropriate.

>  * The root of the authorization tree is an AS-object (aut-num
>    object). If it contains a "mnt-lower" attribute it controls
>    all route-objects which have this AS as origin.

Aren't the route objects with a given origin already controlled
by the authorization specified in the aut-num object?  (Sorry,
it's been a while since I twiddled "my" route objects, so I'm a
bit rusty on this now.)  If I'm in error here and this is
modified behaviour, what would the motivation be for it?

>  * Then for route-objects the same rules apply as for
>    inetnum-objects with respect to IP subranges: If a
>    route-object contains a "mnt-lower" attribute it controls
>    all more specific route-objects immediately below.

The motivation seems to be to have the option of controlling the
use of the given address space covered, e.g. to require
intervention by the maintainer/"owner" of the address space
should a customer want to leave and take the address space within
this address block with him, or to prevent such a move. (?)


Other than that I think your suggestions make sense.

- Håvard