[dp-tf] Quadlogy of person proposals

Janos Zsako wrote:
> 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).
>

agreed

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

agreed

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

sometimes I dream a bit too much :)

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

agreed

cheers
denis
>
>
> Best regards,
> Janos
>