[dp-tf] Quadlogy of person proposals

Janos Zsako wrote:
> Dear Denis,
>
> Thank you for the nice work! Overall, I think it is very good.
>
> I have a couple of comments below:
>
>>    Clean up of unreferenced person objects
>
>> Targeting 'loose' mntner objects will catch the mutually
> > referencing pairs. There may be many more of these when it
> > is required to maintain person objects. In this case we will
> > only target the person/mntner object pairs. To include role
> > objects implies person/role/mntner groups with many more
> > references. This is too complicated to handle within the
> > scope of this one time cleanup process.
>
> You do not need the role objects to make things complicated.
>
> Actually the mntner-person "pairs" can cause you some more headache
> as well. Consider the case:
>
> mntner1: admin-c: p1 tech-c: p2
> p1: mnt-by: mntner2
> p2: mnt-by: mntner3
> mntner2: admin-c: p1 tech-c: p2
> mntner3: admin-c: p1 tech-c: p2
>
> You have here five objects that reference each other, but nothing
> else. Of course, this can be made as complex as you wish:
>
> mntner1: admin-c: p1
> p1: mnt-by: mntner2
> mntner2: admin-c: p2
> p2: mnt-by: mntner3
> mntner3: admin-c: p3
> p3: mnt-by: mntner4
> ...
> mntner"n": admin-c: p"n"
> p"n": mnt-by: mntner1
>
> Do I miss something?

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

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

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

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

>
>
>
>>   Authentication for referencing of person and role objects
>
> I think I would call this _authorization_ rather than authentication.
> This applies to the other uses of this term throughout this document.

agreed

>
>
>
>
>>   Structuring of address attributes in person, role and organisation
>> objects
>
>
>> Stage 2
>>
>>     * Whenever a person/role/organisation object is modified with
>> only "address:"
> > attributes an error message will be added to the acknowledgement.
>>     * Whenever a person/role/organisation object is referenced with
>> only "address:"
> > attributes an error message will be added to the acknowledgement and
> the update
> > will fail.
>
> Delete the word "only" in the two bullets above, as you either have
> "address:"
> attribute(s) or the other set, not both.

agreed

regards
Denis
RIPE NCC

>
> I hope this helps.
>
> Please let me know if I misunderstood something, or if what I was
> trying to say is
> not clear enough.
>
> Best regards,
> Janos
>