[dp-tf] Quadlogy of person proposals

Dear Denis,

> I agree that these chains can get very complex. The issue for this
> proposal is to only look for those simple couples of person and mntner
> objects which reference each other and nothing else. As soon as other
> references are involved it gets difficult. We will tackle the more
> complex issues later. As a follow on from this one time cleanup we will
> put forward a proposal for a regular cleanup process. That will analyse
> data much more and identify clusters of objects with no connection to
> any operational data. But that is outside the scope of this proposal.

Agreed. I think the general solution is complex enough to deserve
a separate planning phase. At this moment what you propose is enough.

It may be useful though to mention the above fact in one sentence so
that others do not make the the same comment I made (i.e. we should point
out that we are aware of the complexity, but do not want to handle
all cases - you point this out in case of the role object, but probably
not strongly enough in case of person only).


>>>Changes to objects
>>
>>>Add a "not-ref:" attribute to person/role objects. This
>>>indicates that the person/role object is not referenced
>>>and the date when it last became unreferenced. ...
>>
>>Is it not the date when it _first_ became unreferenced
>>(i.e. when you first noticed it is unreferenced)?
> 
> I think this is semantics :) It is when we first notice it last became
> unreferenced. An object can be referenced now. Then it becomes
> unreferenced for a while, then referenced again and then unreferenced
> again. So this date reflects the start of the period in which it last
> became unreferenced.

OK, I now understand. :) The original text is fine. :)

>>>A user can apply to have their person object linked to
>>>the white pages. They should select the category and contact
>>>the moderator. The user needs to send their full person object
>>>to the moderator. This should either include the plain text
>>>password or be a signed message providing the authentication
>>>to modify this person object. ...
>>
>>I think this is what Elmar objected to as well... (Never send
>>passwords to somebody else.)
> 
> 
> This is not a new situation. Double authorisation is required for route
> creation. We simply point out the two options for achieving this.
> Clearly it is not a good idea to give someone your password, so it may
> encourage more people to change to PGP authorisation method.

Fine. However, the way it is now seems to suggest we do encourage
people to do so (to send their password). Perhaps it should be
rephrased to:

The user needs to send their full person object to the moderator.
This should either include the plain text password (which we
strongly recommend against) or be a signed message providing the
authentication to modify this person object.

> <dreaming>
> But an idea that just came to mind now....it would not be difficult to
> introduce a 'one use only' password feature. So you could add this to
> your mntner:
> 
> auth:   MD5-PW-ONE $1$...$....  <object>
> 
> The first time this password is used for authorisation, it is removed
> from the mntner by the database software. It would only pass if used on
> the specified object. This allows you to give this one time password to
> someone (that you trust). They can use it for the requested purpose and
> then it is removed.
> 
> This is also outside the scope of this proposal, but if it is considered
> a useful feature we could look more closely at it. We are already
> introducing the concept of a user requesting an update and the database
> software expanding that into more than one update. This is needed for
> the chicken and egg situation in the mntner proposal.
> </dreaming>

It would lower the risks, but would not eliminate them. You
would have no control over what that password would be used for
(e.g. deleting all maintaned objects, etc...).
At present you can still do roughly the same: you temporarily
modify the password to something you tell the other person, and
once he/she performed the change you asked for, change the
password. It is not automatic, but does not need further
change to code.


>>>Requests for additional white pages categories can be sent
>>>to Customer Services at RIPE NCC. These requests will be
>>>forwarded to the WG chairs mailing list for approval.
>>>If approved the RIPE NCC will create the new organisation
>>>object, update the web page and notify the moderator.
>>
>>I think you mean _appoint_ a moderator. (Once appointed, he/she
>>will be have to be notified as well, of course.)
> 
> 
> Again the RIPE NCC does not want to make these decisions. We would
> either assume the person requesting the new category would become the
> moderator, if approved, or the WG chairs will nominate the moderator.

Agreed. In this case a small addition:

If approved, and the moderator is appointed, the RIPE NCC will
create the new organisation...


Best regards,
Janos