Maintainer creation policy

> 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...

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?

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.


Regards,

- Håvard