Maintainer creation policy

 Havard.Eidnes at runit.sintef.no writes:
 * > the RIPE NCC is considering relaxing the requirements for obtaining a
 * > maintainer.  This has certain consequences that we would like people
 * > to consider and then put forward comments either supporting or
 * > rejecting this proposal.
 * >
 * > We propose the following new policy:
 * >
 * > - The RIPE NCC will create maintainers for all users whose person/role
 * >   object is mentioned in any object in the RIPE database except if it is
 * >   only mentioned in other person or role objects.
 * > - If the person/role is not mentioned in any other object, the
 * >   maintainer will not be created.
 * >
 * > This should allow all users to protect their data but prevent the
 * > database from becoming some sort of "phone book".
 * 
 * Maybe I'm getting out of touch with things, but frankly, I do not see
 * how this solves the "phone book" problem or any other problem for that
 * matter.  Instead I see it creating a few new problems...
 * 

Per se, it doesn't. But it prevents users from protecting their objects if the 
only thing they have is a person (or role) object. And, as experience goes,
anything can happen to an unprotected object.

As for interpretations...
This is just the criteria we will use to create (or not) a new maintainer upon 
a user request.
The RIPE NCC will not create maintainers *automatically* nor will it modify 
users' objects after
creating a new maintainer (eg. to include mnt-by lines). This is up to the 
user.

This doesn't reduce the phone book problem but it doesn't increase it as it 
would if we gave out maintainers to everyone.
May be, eventually, some day, somehow, someone will carry out a free-standing, 
un-referenced object cleanup.

The problem with creating maintainers is that they require a security 
override, so normal users can't do it themselves. The RIPE NCC does it upon 
request.

 * I also do not really understand from the description above what exactly
 * is going to happen.  Some interpretations:
 * 
 *  o All "person" objects referenced from other objects (except "role"
 *    objects) will result in the creation of a new maintainer object for
 *    that user, and the user's maintainer will be added as a mnt-by:
 *    attribute of the objects where the person was referenced earlier.
 * 
 *    If the total size of the database is a problem (and I think it is),
 *    this will not help one little bit, as this will add new objects
 *    corresponding to a *large* percentage of the person objects in the
 *    database.
 * 
 *    Furthermore, it is not necessarily true that users referenced as
 *    admin-c, tech-c or zone-c *own* the information registered, although
 *    there may be consensus that this is so for the Internet registry part
 *    of the RIPE database.  For the other "subparts" of the database there
 *    may be policy implications of updating the information, a prime
 *    example could be information from the domain registry side.
 * 
 *  o The RIPE NCC will add mnt-by: attributes on all person objects
 *    referenced from other objects (except "role" objects).  Which
 *    maintainer is to be used is not exactly stellar clear.  I consider
 *    this to be an unlikely interpretation, although I must say that the
 *    statements above are sufficiently unclear that I do not clearly
 *    understand what is going to happen.
 * 
 * I do not understand at all how this will reduce the "phone book" problem
 * of the RIPE database, as this will not prevent the creation of "free-
 * standing" objects in the RIPE database (?).  I furthre presume that the
 * "phone book" problem is exactly this -- free-standing, un-referenced
 * person objects?  Another alternative to the "phone book" problem could
 * be that a large part of the RIPE database is indeed objects resulting
 * from it making double duty as a domain registry information repository,
 * although I still seem to remember statements by the RIPE NCC to the
 * effect that this is not regarded as a problem.
 * 
 * Why not just permit maintainer object creation by anyone satisfying the
 * above requirements ("reference exists"), but not create the maintainer
 * objects themselves or the mnt-by: attributes?
 * 
 * 
 * I cannot see that there have been any comments to this proposal, so am I
 * the only one who does not understand what is going to happen, and what
 * the rationale for it is?
 * 

Well, I have tried to explain above what this is about. If there are more 
questions I will happily answer them.

 * I do however think that the effective time between announcement and
 * implementation is way too short -- with IETF and Christmas and New Year
 * holdays in-between it comes down to 1-2 weeks only.
 * 

May be it's 1-2 weeks for a particular individual but it's nevertheless a 
month with a lot of working days.
If people think extending the implementation period is a good thing, we can do 
it, but it's only worth it if there is going to be a discussion about this.

Keep in mind that this is mostly a RIPE NCC internal procedure (modification 
of the criteria for creating/denying maintainers) and the announcement is 
mainly intended to wake up people that have unprotected objects before 
maintainer availability becomes more widespread (just in case someone misuses 
maintainers).


Regards,
Joao Damas
RIPE NCC

 * 
 * Regards,
 * 
 * - Håvard
 *