[dp-tf] Quadlogy of person proposals

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

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