Re: privacy

[Patrik Fältström <paf@cisco.com>]

Let me rephrase what I heard IESG saying, as sponsoring AD for this 
document. As IESG is cc:ed people can jump in and correct me, or add 
more/different things.

First IESG completely agree the issues with privacy is complicated. The 
laws and requirements in different countries are very different, and 
basically differ in for example the following ways for "white-pages 
information":

  - Whether opt-in or opt-out in a public database is the function needed
  - Whether the opt-in/opt-out is allowed to be implicit, or if it
    must be implicit
  - What information a registry can say is mandatory to allow being
    public
  - ...

These requirements which certainly differ not only between registries 
but also what legislation the registrant belong to is clear. In various 
communities discussions exists wether for example it is ok for the 
registry outside of Sweden to publicly publish social information about 
a domain name holder from Sweden if the registrant is a private person. 
The input I have got from lawyers in Sweden is that publication of such 
information in whois is not ok if not the registrant has explicitly 
said yes to it. And, competition legislation say it is not ok for a 
registry to require this (implicit opt-in) to get the service.

Of course, these people I have talked with can be wrong, but similar 
examples exists in Austria, Switzerland and the Netherlands. This issue 
is discussed heavily in for example CENTR Legal group (I forgot the 
name of this group) because the "requirements" ICANN has put on whois 
and ccTLD is violating the local law in some countries.

These differences together with the requirement in RFC 3375 that the 
protocol MUST be able to handle the cases that one have:

  - multiple registrars connected to one registry
  - one registrar connecting to multiple registries
  - one object being associated with other objects, possibly under
    authoritative control of a different registrar
  - one registry being thin, another thick (when looking at
    where social information is stored)

These three rules are just some signs that the protocol MUST be 
something which is interoperable between multiple implementations, and 
this in turn lead to the need for multiple implementations which can 
handle the various permutations of legal rules for handling of the 
social information about a registrant.

Now, what IESG is concerned about is _INTEROPERABILITY_, not so much 
privacy.

Are you surprised? I hope not.

Now, IF the wg explain in the specification of epp how interoperability 
in the real world is guaranteed, then we are done. Interoperability in 
mixed environments when multiple different privacy models are used.

Does this explain the issue better?

    paf


On onsdag, jan 8, 2003, at 18:35 Europe/Stockholm, Rick Wesson wrote:

>
> Patrik,
>
>> What IESG want is _some_ mandatory to implement mechanism which makes
>> it possible for the registrar to say to the registry "Do not disclose
>> this attribute to a third party". If the wg want to have the mandatory
>> to implement mechanism more powerful than that, fine. What is not ok 
>> is
>> the protocol not having any mandatory to implement privacy mechanism 
>> in
>> it, only extensions.
>
> The issue that some folks have with and IESG mandatory to implement
> privacy capability in the prov-reg domain registration context is that
> addressing privacy just in epp is not a solution. Addressing privacy in
> epp also requires addressing it in the publishing protocols.
>
> privacy is a thick issues and I've not seen/herd one prov-reg 
> participant
> stand up and say "we understand privacy and here is what should happen"
> What we do see on the list and in the meetings is that we are not the
> people who should develop a privacy context and we don't know how to do
> it.
>
> we have asked for additional direction and get a responses that are 
> obtuse
> and confusing. Everyone appears to agree that privacy is a more complex
> issue than the IESG is willing to accept and that provreg may not be 
> the
> place to define such capabilities.
>
> I request that you consider that this working group may not be capable 
> of
> addressing the problem and appreciate your thoughts on the next step if
> this proves to be true.
>
> -rick
>
>