Re: EU data protection, was: Extensions in regards to NTLDs

On 21 Dec 2011, at 10:42, Klaus Malorny wrote:

> IMHO <contact:disclose> already provides sufficient control (except  
> for the design flaw that you cannot grant and deny disclosures at  
> the same time). However, having some insight, decisions were made  
> less with the intention to provide the best technical solution or  
> the best protection.

Klaus, you were not involved in those discussions or design decisions  
and are therefore not in a position to meaningfully comment on them.  
You are very wrong both personally and professionally to claim those  
decisions did not have those intentions. You're entitled to your  
opinion of course. But it's not based on insight into what was done  
for the .tel registry and why.

As the person who had to make those decisions for the .tel registry, I  
do have that insight. [You had no interaction with ICANN or the UK DPA  
or Telnic management or its registry provider or too many lawyers on  
this issue whatsoever. I did.] What ended up being implemented was the  
best (or least-worst) choice that could be made at the time, given all  
the prevailing constraints. This had to take account of a lot of  
factors that were unknown to you. And apparently still are.

> So the chosen solution of associating the protection with the domain  
> instead of the contact should IMHO not be regarded as exemplary.

The same goes for a disclosure flag on the contact object.

The short answer is there is no "one size fits all" solution to this  
problem. All answers are bad or flawed in some way.

For starters, there is no common view on Data Protection law or its  
enforcement across the EU even though each national law is derived  
from the same EU directive(s). In some cases, a disclosure flag on a  
domain object will be the best (or least-worst) option. In others, it  
won't. For some, the option of having this flag on the contact object  
will work better. For others, it won't.

Consider a contact object that's referenced from two domain objects.  
When the disclosure flag is on the contact object, this could be  
illegal and/or violate the registry contract with ICANN. If one of the  
domains that references the contact object is for an organisation, its  
Personal Data would not be getting disclosed when it should be made  
available. If the flag goes on the domain object, disclosure of the  
contact's Personal Data is determined by whether the domain is for an  
individual (not allowed) or an organisation (allowed and/or required).  
Which means the Personal Data could be obtained via a whois lookup of  
the Contact-ID when that data shouldn't be disclosed.

Now it's possible to get round these problems by insisting on discrete  
contact objects with different disclosure flag settings when the  
registrant has a domain name for themself and another for their  
business. However registrants and some registrars tend to be less than  
enthusiastic about doing that for the obvious reasons. Another icky  
work-around is to consider using privacy/proxy services for whois.  
Which brings yet another set of hassles and rat-holes. Or the  
disclosure flags get applied to both domain and contact objects. Which  
is ugly. Pick your poison.

We should also bear in mind on this list that there is not going to be  
an over-arching or perfect protocol solution to a layer-9 and above  
problem.

FWIW, I have not followed PuntCAT's proposal. My guess is they may be  
cloning the Telnic one as the path of least resistance. If PuntCAT  
need to get their ICANN contract amended to comply with local Data  
Protection law, the quickest, cheapest and least painful way to do  
that might be to follow in Telnic's footsteps who sort of followed in  
GNR's (.name's) footsteps. [Though that depends on whether the UK and  
Spanish DPAs have a common view.] Doing anything else would open a  
world of pain that I wouldn't wish on anyone.
_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg