[dp-tf] Quadlogy of person proposals

Hi Elmar

Thanks very much for your quick feedback. You raise some interesting
points. But I think some of the issues may mean I did not explain my
thoughts clearly enough in the proposals. My replies are inline below.

Elmar K. Bins wrote:
> Hi Denis, hi group,
>
> just a couple of comments that came to my mind.
>
>
>
>
> [Maintaining (as many) objects (as possible)]
>
> I consider it a splendid idea to have all DB objects maintained, so
>   - I know who _must_ have once had knowledge about the object in question
>   - I know where to go to have something updated / to inquire
>
> Others may find the idea appealing in order to create a string of
> objects that belong together (amazing what you can find out about
> people/companies that way). That does seem to create other privacy
> issues.
>   

>From a public accountability point of view it may not be a bad idea to
be able to find out some of this information. From a company point of
view maybe some rationalisation is needed. Do companies really have 20
staff responsible for administering IP addresses, all of whom need to be
publicly addressable? Or do some people just want to be in the RIPE
Database (White Pages)? There are ways of using the database now to
allow 20 people to work with the data, but only have one or two as the
publicly accountable and contactable persons. The other 18 don't need to
have there personal details in the database. If public accountability vs
company confidentiality becomes an issue then we can look at that as a
separate item.
> The alternative of exempting person objects seems to be a good idea.
>   

Not sure where this comes from. The proposals don't mention any
exemption from being maintained. The only person exemption is from being
deleted if in the white pages.
> Anyway, the chicken-and-egg problem does persist with all solutions
> where I need the objects created at the same time, because the normal
> and desired way of creating objects in the RIPE-DB is by using the
> "AUTO-xxx" variable instead of a preassumed name (DW1, AARDVARK-MNT).
> That those in the know define their object names themselves after
> having checked them to be available doesn't help the others.
>   

Although I have used 'real' data in the example, it is not the lack of
AUTO- tags that causes the chicken and egg situation. The example you
show below still has the chicken and egg. You have two objects, each
with an auto generated name. But each object references the auto
generated name from the other object. So which ever one you create first
needs to reference the 'as yet not generated' name from the other object.
> If we could use the object creation mechanism like the following,
> we can circumvent the chicken-and-egg problem. I have not tried
> it, so I'm not certain it will work already. If not, this could
> be item 2 in the proposal.
>
> person:         Denis Walker
> address:        RIPE Network Coordination Centre (NCC)
> address:        Singel 258
> address:        1016 AB Amsterdam
> address:        The Netherlands
> phone:          +31 20 535 4444
> nic-hdl:        AUTO-1
> mnt-by:         AUTO-2
> notify:         denis at ripe.net
> changed:        denis at ripe.net
> source:         RIPE
>
> mntner:         AUTO-2
> descr:          Mntner for denis' objects.
> admin-c:        AUTO-1
> tech-c:         AUTO-1
> upd-to:         denis at ripe.net
> auth:           X509-1
> notify:         denis at ripe.net
> mnt-by:         AUTO-2
> referral-by:    RIPE-DBM-MNT
> changed:        denis at ripe.net
> source:         RIPE
>
>
> Apart from the creation issue I concur with this proposal. The linked-objects
> privacy issue can be circumvented, but with the ability of inverse lookups
> already built into the RIPE DB, this poses no _new_ issues.
>
>
>
> [White pages]
>
> I'm not certain if the RIPE NCC should create a new "phone directory" for
> "significant persons". Who defines significance, who decides whether the
> user-selected category applies,

This is why we introduced the idea of moderators as the RIPE NCC has no
idea how to make these decisions.

>  who defines categories in the first place,
> who points out moderators?
>   

We hope this will be a small list and perhaps WG chairs and co-chairs
have been around long enough (and I say that in the nicest possible way
:) ) to know who these 'significant people' are. If it becomes heavily
used then we are talking about social networking. Then we need to look
at alternative solutions (if we still think there is a problem here to
be solved).

> Concerning the moderation process...
>
>   - Is it really a good idea to have users send their maintainer password
>     to a moderator?
>   - Since a changed object needs re-signing, in the case of PGP or X.509
>     key security, the moderator needs the private keyring involved.
>   

We do not advise anyone to send their passwords to other people. So that
requires use of PGP.  Now your other point shows a flaw in my logic,
which I will correct in the proposal. The user will have to add the
organisation reference to their person object, sign it and send it to
the moderator. If the moderator approves it, they just need to sign it
again and send it to the database.

>   - Alternatively the moderator can have special rights to the RIPE DB.
>     Well.
>   

This is not something we want to do.

>   - Can a user be kept from adding any org: attribute to an object?
>     (That's not a rhetorical question, I couldn't find that it be
>     checked, even though I have a faint inkling here)
>   

Adding an "org:" reference to any object needs to be authenticated by
the "mnt-ref:" of the organisation object.

Thanks again for your feedback. These are the issues we need to sort out
before publishing the proposals.

regards
Denis Walker
RIPE NCC

>
>
> Yours,
> 	Elmar.
>
>