[dp-tf] Quadlogy of person proposals

Hi all,

Thanks Denis for the excellent job done. Of course agree on the line to
have all the objects maintained.

Just a comment more: don't forget that the core for us is not to have
fields to store private data, but, probably, have one_field_more to get
the owner authorization to publish them.

So, the big problem is that we normally have contacts from our maintainers
that aren't owners of all data maintained. The question is who get the
responsability to put the "yes" in that field. This is a rule that, I
think, we have to build.

Cheers
Manfredo

--
Manfredo Miserocchi
Network & Information Security Administration
Mobile: +41 76 5708123
e-mail: mis at wari.net
--
Warinet Global Services SA
Via Soave, 2
CH-6901 Lugano
Switzerland
--


-----Original Message-----
From: Denis Walker <denis at ripe.net>
To: "Elmar K. Bins" <elmi at 4ever.de>
Cc: dp-tf at ripe.net
Date: Mon, 11 Jun 2007 18:20:16 +0200
Subject: Re: [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.
> >
> >   
> 


Si precisa che le informazioni contenute in questo messaggio sono riservate e ad uso esclusivo del destinatario. Qualora il presente messaggio Le fosse pervenuto per errore, La invitiamo ad eliminarlo senza copiarlo ed a non inoltrarlo a terzi, dandocene gentilmente comunicazione. Grazie.

You are hereby informed that this message contains confidential informations intended for the addressee's use only. If yu're not the addressee and have received this message by mistake, please delete it and immediately notify us. You may not copy or disseminate this message to anyone. Thank you.