Subject: [provreg] Extensions in regards to NTLDs

From: "Michael Young" <[email-masked]>
Date: Tue, 20 Dec 2011 16:38:34 -0500

Hi all,

It's been a few years since I've posted to this list and I wonder how many
of us are still subscribed to it. Hopefully enough to make this question
meaningful.

If you are tracking the new GTLD process closely you will have noticed a
requirement in the draft Registry Agreement  to format any EPP extensions in
I-D format.

<If Registry Operator requires the use of functionality outside the base EPP
RFCs, Registry
Operator must document EPP extensions in Internet-Draft format following the
guidelines described in
RFC 3735. Registry Operator will provide and update the relevant
documentation of all the EPP Objects
and Extensions supported to ICANN prior to deployment.>

It occurs to me that once Operators have gone to the trouble of doing this,
numerous extensions may be submitted to the IETF for possibly the standards
track but maybe even more commonly as informational.

Here's my concern, that we will see numerous extensions with heavily
overlapping purposes to solve the common problems of running and launching a
TLD registry.  It seems to me that it would be great to have a group of
volunteers trying to rally disparate efforts to solve similar registry
problems and create standardized extensions where feasible.  I know we've
talked about this sort of idea before around EPP extensions, but given the
impending expansion of the TLD space I thought it was worth raising again.

Thoughts? Comments?

Best Regards,

Michael Young
M:+1-647-289-1220

---

From: Francisco Obispo <[email-masked]>
Date: Tue, 20 Dec 2011 13:56:45 -0800

Hi Michael,

I'm envisioning at least two:

1) Launch Phase extension (currently a draft from Wil Tan),

2) IDN - for collecting the "language tag" as required by
   ICANN's IDN implementation guidelines.

I've written a draft for #2, which I could share/submit 
if you guys find it useful.

Francisco,

> impending expansion of the TLD space I thought it was worth raising again.

Francisco Obispo 
email: [email-masked]
Phone: +1 650 423 1374 || INOC-DBA *3557* NOC
Key fingerprint = 532F 84EB 06B4 3806 D5FA  09C6 463E 614E B38D B1BE

---

From: "Michael Young" <[email-masked]>
Date: Tue, 20 Dec 2011 17:04:34 -0500

That would be great if you could submit  #2, I think it would be extremely
useful. I saw Wil's submission and am reviewing it currently.  It seems like
a sensible idea as well.

Best Regards,

Michael Young
M:+1-647-289-1220

-----Original Message-----
From: Francisco Obispo [mailto:[email-masked]] 
Sent: December-20-11 4:57 PM
To: Michael Young
Cc: [email-masked]; Frank Thompson; Oliver Fries; [email-masked];
[email-masked]; Len
Subject: Re: [provreg] Extensions in regards to NTLDs

Hi Michael,

I've written a draft for #2, which I could share/submit if you guys find it
useful.

Francisco,

On Dec 20, 2011, at 1:38 PM, Michael Young wrote:

> overlapping purposes to solve the common problems of running and 
> launching a TLD registry.  It seems to me that it would be great to 
> have a group of volunteers trying to rally disparate efforts to solve 
> similar registry problems and create standardized extensions where 
> feasible.  I know we've talked about this sort of idea before around 
> EPP extensions, but given the impending expansion of the TLD space I
thought it was worth raising again.
> M:+1-647-289-1220

Francisco Obispo
email: [email-masked]
Phone: +1 650 423 1374 || INOC-DBA *3557* NOC Key fingerprint = 532F 84EB
06B4 3806 D5FA  09C6 463E 614E B38D B1BE

---

From: Francisco Obispo <[email-masked]>
Date: Wed, 21 Dec 2011 00:16:23 -0800

Dear *,

Yes, we will be doing that in a very short time, it is currently being reviewed by a colleague who will do the actual submission.

Will keep you informed.

Best regards

On Dec 21, 2011, at 12:10 AM, Alexander Mayrhofer wrote:

> please submit and share the document. As an implementor of NTLD
> registries, i'd find it very useful if the community could agree on one
> single way to do that.
> 
> Alex

Francisco Obispo 
email: [email-masked]

---

From: Gavin Brown <[email-masked]>
Date: Wed, 21 Dec 2011 09:32:01 +0000

>     ICANN's IDN implementation guidelines.

3) an extension to cover legal/natural person information and whois 
opt-in/out for contact objects, to meet EU data protection rules. Telnic 
has this, and PuntCAT recently submitted a RSTEP application for such an 
extension, but any other EU based gTLD registry will probably need 
something similar (although I am not sure if the existing 
<contact:disclose> element doesn't already provide this).

G.

-- 
Gavin Brown
Chief Technology Officer
CentralNic Ltd
Innovative, Reliable and Flexible Registry Services
for ccTLD, gTLD and private domain name registries
https://www.centralnic.com/

CentralNic Ltd is a company registered in England and Wales with company
number 4985780. Registered Offices: 35-39 Moorgate, London, EC2R 6AR.

---

From: Jothan Frakes <[email-masked]>
Date: Wed, 21 Dec 2011 01:53:13 -0800

Gavin, you may be correct on <contact:disclose>

What about extensions in support of the trademark clearinghouse
functionality like registrant notices that registrars might be
compelled to display...

I think there's still some TBD in there, but also some of these will
probably be out of band to the SRS/EPP communication.

Happy Holidays to all my fellow EPP registry programmer friends out there.

-Jothan

Jothan Frakes
+1.206-355-0230 tel
+1.206-201-6881 fax

On Wed, Dec 21, 2011 at 1:32 AM, Gavin Brown <[email-masked]> wrote:
> opt-in/out for contact objects, to meet EU data protection rules. Telnic has
> this, and PuntCAT recently submitted a RSTEP application for such an
> extension, but any other EU based gTLD registry will probably need something
> similar (although I am not sure if the existing <contact:disclose> element
> doesn't already provide this).
>
> G.
>
> --
> Gavin Brown
> Chief Technology Officer
> CentralNic Ltd
> _______________________________________________
> provreg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/provreg

---

From: Alexander Mayrhofer <[email-masked]>
Date: Wed, 21 Dec 2011 09:10:06 +0100

Francisco,

Alex

---

From: Klaus Malorny <[email-masked]>
Date: Wed, 21 Dec 2011 11:42:21 +0100

On 21/12/11 10:32, Gavin Brown wrote:
> [...]
> 3) an extension to cover legal/natural person information and whois opt-in/out
> for contact objects, to meet EU data protection rules. Telnic has this, and
> PuntCAT recently submitted a RSTEP application for such an extension, but any
> other EU based gTLD registry will probably need something similar (although I am
> not sure if the existing <contact:disclose> element doesn't already provide this).
>
> G.
>

Hi,

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. So the chosen 
solution of associating the protection with the domain instead of the contact 
should IMHO not be regarded as exemplary.

BTW, regarding data protection, it sounds quite strange that you can gain an 
extra point in the score in the application for a new gTLD (item #26) if one 
provides a searchable Whois. At least in the EU, the data protection officers 
would likely go crazy. But that's probably out of scope of this list.

Regards,

Klaus

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 21 Dec 2011 12:14:17 +0000

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Klaus Malorny
> Sent: Wednesday, December 21, 2011 5:42 AM
> To: Gavin Brown
> Cc: [email-masked]
> Subject: [provreg] EU data protection, was: Extensions in regards to
> NTLDs
> 

I'm going to disagree (again) on the "design flaw" point. As described in 5733:

- The server operator publishes a data collection policy.
- The client has the choice of accepting the policy *and* requesting exceptions (that is, granting and denying disclosures) as part of the same <create> command.

The server operator needs to publish a policy that meets the requirements of the local operating environment, such as is defined in the EU.  It would be a design flaw to allow the client to grant and/or deny disclosures in conflict with the server operator's data collection policy.  Doing so would put the server operator in an untenable state with respect to the client's data.

Scott

---

From: Jim Reid <[email-masked]>
Date: Wed, 21 Dec 2011 12:49:58 +0000

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.

---

From: Klaus Malorny <[email-masked]>
Date: Wed, 21 Dec 2011 15:27:41 +0100

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

Hi Jim,

first, I think I have stated clearly enough that this was my very personal opinion.

Second, my insight *mostly* refers to my work with puntCAT. I got aware of some 
correspondence between the involved parties, including, but not limited to, the 
puntCAT organization and ICANN. Indeed, as you guessed, Telnic's/Neustar's 
deployed model played a major role and caused very valid arguments to be 
disregarded. And these arguments were not new. Whoever worked on the Telnic 
solution must have come across these also, and you actually confirmed it in your 
response to my e-mail.

Regarding data protection, I have a clear opinion, namely that ICANN's claims 
have to recede behind the EU's and national privacy regulations, if the registry 
is located in the EU. And that the right of a person to have his data not to be 
disclosed does not depend on the use of the contact, so that the contact is the 
only valid place to define the disclosure. That said, I don't want to kick off a 
discussion here about the various views, but simply to explain my motivation.

Regards,

Klaus

---

From: Klaus Malorny <[email-masked]>
Date: Wed, 21 Dec 2011 15:40:30 +0100

On 21/12/11 13:14, Hollenbeck, Scott wrote:
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Klaus Malorny Sent:
>> Wednesday, December 21, 2011 5:42 AM To: Gavin Brown Cc: [email-masked]
>> Subject: [provreg] EU data protection, was: Extensions in regards to NTLDs
>>
>> IMHO<contact:disclose>  already provides sufficient control (except for
>> the design flaw that you cannot grant and deny disclosures at the same
>> time).
>
> - The server operator publishes a data collection policy. - The client has
> the choice of accepting the policy *and* requesting exceptions (that is,
> granting and denying disclosures) as part of the same<create>  command.
>
 > [...]

Hi Scott,

come on, we discussed this already quite a lot, if I remember correctly. If you 
have, say, the address to be disclosed, but the phone number to be undisclosed 
by default by the registry policy, you can't issue a create or update request 
that makes the address undisclosed and the phone number disclosed at the same 
time. If, for example, the "flag" attribute had been placed on the child 
elements of the <disclose> element, this would have been possible. As the 
example I gave is IMHO a valid desire, I consider this as a flaw, although not 
as a serious one.

Regards,

Klaus

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 21 Dec 2011 15:54:44 +0100

On 21 dec 2011, at 15:40, Klaus Malorny wrote:

> come on, we discussed this already quite a lot, if I remember correctly. If you have, say, the address to be disclosed, but the phone number to be undisclosed by default by the registry policy, you can't issue a create or update request that makes the address undisclosed and the phone number disclosed at the same time. If, for example, the "flag" attribute had been placed on the child elements of the <disclose> element, this would have been possible. As the example I gave is IMHO a valid desire, I consider this as a flaw, although not as a serious one.

The problem we have is that in some cases the "disclose" flag on certain attributes is a mix between the interest of the registrant and various policies. Including what is invented by the registrar, invented by the registry, legislation in the area where the registry is, where the registrar is, or where the registrant is. And that boils down to various disclosure flags be set by the registry, and others by the registrar, and a third possibly by either registry or registrar. And the protocol unfortunately is *E* pp where the E is a bit too extensive instead of (for example with this disclosure flag on attributes) "us" trying to solve the problem that exists.

That have lead to each registry invent their own extensions that lead to a pain for the registrars that try to communicate with more than one registry.

Which of course is very simple as the "cost" for private extensions is linear to the number of extensions a registry has, but exponential on the registrar as the combination of some policies / extensions are very very hard to combine.

So, I would encourage people to have as a very explicit goal to have as few extensions as possible, and saying "we need a different extension because our policy is this" is for me not good enough. It is possible to either change or tweak the policy so that an already existing extension can be used.

To conclude: I do not care how the disclose mechanism is implemented, I want one. And only one.

And no pony attached with it.

   Patrik -- fighting specifically as implementor on registrar side with VERY weird registry decisions so far in the world