Michael Young | 20 Dec 2011 22:38
Picon

Extensions in regards to NTLDs

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.

(Continue reading)

Francisco Obispo | 20 Dec 2011 22:56

Re: Extensions in regards to NTLDs

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,

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

> 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
(Continue reading)

Michael Young | 20 Dec 2011 23:04
Picon

Re: Extensions in regards to NTLDs

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:fobispo <at> isc.org] 
Sent: December-20-11 4:57 PM
To: Michael Young
Cc: provreg <at> ietf.org; Frank Thompson; Oliver Fries; stpeter <at> stpeter.im;
presnick <at> qualcomm.com; Len
Subject: Re: [provreg] Extensions in regards to NTLDs

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,
(Continue reading)

Gavin Brown | 21 Dec 2011 10:32
Gravatar

Re: Extensions in regards to NTLDs

On 20/12/2011 21:56, Francisco Obispo wrote:
> 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.

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.
_______________________________________________
(Continue reading)

Jothan Frakes | 21 Dec 2011 10:53
Picon
Gravatar

Re: Extensions in regards to NTLDs

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 <gavin.brown <at> centralnic.com> wrote:
> On 20/12/2011 21:56, Francisco Obispo wrote:
>>
>> 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.
>
>
(Continue reading)

Klaus Malorny | 21 Dec 2011 11:42
Picon
Favicon

EU data protection, was: Extensions in regards to NTLDs

On 21/12/11 10:32, Gavin Brown wrote:
> On 20/12/2011 21:56, Francisco Obispo 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
(Continue reading)

Hollenbeck, Scott | 21 Dec 2011 13:14
Picon
Favicon

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

> -----Original Message-----
> From: provreg-bounces <at> ietf.org [mailto:provreg-bounces <at> ietf.org] On
> Behalf Of Klaus Malorny
> Sent: Wednesday, December 21, 2011 5:42 AM
> To: Gavin Brown
> Cc: provreg <at> ietf.org
> 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).

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
_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg
(Continue reading)

Klaus Malorny | 21 Dec 2011 15:40
Picon
Favicon

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

On 21/12/11 13:14, Hollenbeck, Scott wrote:
>> -----Original Message----- From: provreg-bounces <at> ietf.org
>> [mailto:provreg-bounces <at> ietf.org] On Behalf Of Klaus Malorny Sent:
>> Wednesday, December 21, 2011 5:42 AM To: Gavin Brown Cc: provreg <at> ietf.org
>> 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).
>
> 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.
>
 > [...]

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.

(Continue reading)

Patrik Fältström | 21 Dec 2011 15:54
Picon
Gravatar

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


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.
(Continue reading)

Jim Reid | 21 Dec 2011 13:49

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.
(Continue reading)

Klaus Malorny | 21 Dec 2011 15:27
Picon
Favicon

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

On 21/12/11 13:49, Jim Reid wrote:
> 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

_______________________________________________
provreg mailing list
(Continue reading)

Alexander Mayrhofer | 21 Dec 2011 09:10
Picon
Favicon

Re: Extensions in regards to NTLDs

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

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

_______________________________________________
provreg mailing list
provreg <at> ietf.org
https://www.ietf.org/mailman/listinfo/provreg

Francisco Obispo | 21 Dec 2011 09:16

Re: Extensions in regards to NTLDs

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:

>> 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,
> 
> 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: fobispo <at> isc.org
Phone: +1 650 423 1374 || INOC-DBA *3557* NOC
Key fingerprint = 532F 84EB 06B4 3806 D5FA  09C6 463E 614E B38D B1BE
(Continue reading)


Gmane