Re: [dp-tf] Quadlogy of person proposals

["Elmar K. Bins" <]

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.

The alternative of exempting person objects seems to be a good idea.

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.

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@localhost
changed:        denis@localhost
source:         RIPE

mntner:         AUTO-2
descr:          Mntner for denis' objects.
admin-c:        AUTO-1
tech-c:         AUTO-1
upd-to:         denis@localhost
auth:           X509-1
notify:         denis@localhost
mnt-by:         AUTO-2
referral-by:    RIPE-DBM-MNT
changed:        denis@localhost
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, who defines categories in the first place,
who points out moderators?

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.

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

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



Yours,
	Elmar.