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