[dp-tf] Quadlogy of person proposals

On Fri, 15 Jun 2007, Denis Walker wrote:

> Larisa A. Yurkina wrote:
> > On Wed, 13 Jun 2007, Janos Zsako wrote:
> >
> >
> >> Dear all,
> >>
> >>
> >>> 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.
> >>>
> >> Very good point. I think the best approach is to have the responsibilty
> >> reside with the maintainer. It would be good to have this in the service
> >> contract (i.e. the service contract should say that by putting a person
> >> object in the RIPE database, you acknowledge that you did get the approval
> >> of the person to publish his/her data). This is what we have in the .hu
> >> registration rules.
> >>
> >
> > in the .ru registration rules we had approximately the same, untill a Pers.data act
> > was issued about half a year ago. Act states that a person have right
> > to keep his/her data secret, even if he/she is resonsible for the resourse.
> > It means that person is not mandatory anymore, a problem of access to the resp. party
> > arises. I'm afraid, a person object in the RIPE database is very much the same,
> > like TLD registrar the RIPE NCC may face the necessity to legally prove their right
> > to openly publish smbd's personal data.
> >
>
> There are some interesting issues coming from these discussions. Maybe a
> more basic question about personal data is why do we need it? Is it for
> accountability, contactability or both?
>
> If some of it is there for accountability only, then it is questionable
> if it needs to be publicly displayed. For contactability maybe we should
> give people a choice of how they wish to be contacted and levels of
> access to that information. If they choose email only, we can hide
> emails and provide a mail forwarding service. Maybe they could provide a
> phone number but specify it is to be available to members only and not
> the whole public.
>
> It is certainly questionable if an ISPs customers need to be contactable
> by the general public. Most of them are not going to be any help solving
> network problems either. Maybe these need to be only accountable and
> therefore not displayed publicly.
>
> So before we go too far down the road on issues of authentication,
> authorisation, permissions and contracts, maybe we need to answer these
> basic questions:
>
>    * what personal data do we need
>    * who needs access to it and by what means
>    * what do we need it for

one more question, sorry

     do wee really need it

>
> We are trying to address these questions in the privacy statement, but
> in a general way. If we can really focus in on these questions and
> comprehensively answer them, all the other issues will flow out of this.
>
> cheers
> denis
> >
> >
> >> As far as I remember, the GM is now authorized to change the service contract
> >> in such a way to be mandatory for all members (i.e. we do not have to have
> >> all members sign again). We should bring this up at the next GM. Of course
> >> this should be checked with the lawyers too.
> >>
> >> Best regards,
> >> Janos
> >>
> >>
> >>
> >
> >
> > With respect,
> > Larisa Yurkina
> > ---
> > RIPN Registry center
> > -----
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
>


With respect,
Larisa Yurkina
---
RIPN Registry center
-----