[db-wg] Proposed change of "mnt-lower:" behaviour: procedure and timelines

[Apologies for duplicate messages]

Dear colleagues,

In March 2003, the RIPE NCC circulated the proposal to change the behaviour
of the "mnt-lower:" attribute in inetnum, inet6num  and domain objects. Currently, if the "mnt-lower" attribute of a parent object is absent, anybody can create more-specific objects.

The goal is to change this behaviour to a more secure Routing Policy System Security (RPSS) style scheme.
In RPSS, objects use "mnt-lower:" to specify a maintainer which has the ability to authorise the creation of more-specific objects. If a "mnt-lower:" attribute is not present, then the "mnt-by:" of the less-specific object is used. A similar scheme is already used for route object creation ("mnt-routes:" attribute).

As inetnum objects representing allocations are maintained by the RIPE NCC, 
deployment of this scheme may not allow LIRs to create assignments 
from their allocation if the LIR does not have a "mnt-lower:" attribute 
pointing to the LIR's maintainer.

To solve this problem, allocation objects have to be modified to include a
"mnt-lower" attribute. We have applied certain heuristics to determine the most
suitable maintainer for an allocation. If there is no maintainer, a new maintainer will be generated.

Details about project assumptions and heuristics were presented at RIPE 46:
http://www.ripe.net/ripe/meetings/ripe-46/presentations/ripe46-db-allocations-and-mnt-lower.pdf

The initial proposal was sent in March 2003:
http://www.ripe.net/ripe/mail-archives/db-wg/2003/msg00033.html

The RIPE NCC suggests the following implementation plan:

Step 1.
   Distribute this plan for approval.   
Time: 2 weeks

Step 2.
   Notify contacts whose allocations need to be modified 
   Wait for feedback and people making updates themselves
Time: 1 month

Step 3.
   RIPE NCC will check all affected allocations again and update the ones still requiring modification,
   generating necessary maintainers and notifying contacts. 
Time: 1 day

Step 4.
   Passwords for generated maintainers made available through the LIR Portal.
   Wrong modifications can be corrected through the LIR Portal as well.
Time: 1 day

Step 5. 
   Deploy the change in the RIPE Whois Database Software to support new
   scheme.
Time: to be announced

Any suggestions or comments on this plan are welcome.
If your allocation doesn't have a "mnt-lower:" attribute, we encourage 
you to update it as soon as possible through the LIR portal. If you don't have a "mnt-lower:" after this proposal has been implemented, you won't be able to create any new assignments for your allocations.

We believe that this change will be beneficial for all RIPE Whois Database users and we hope the migration will go as smoothly as possible.

Thanks for your co-operation.

Katie Petrusha
Database Group
RIPE NCC