Subject: Re: [regext] I-D Action: draft-ietf-regext-tmch-func-spec-00.txt

From: "James Galvin" <[email-masked]>
Date: Fri, 03 Jun 2016 14:50:09 -0400

I want to remind the working group that we have the following unresolved 
comments regarding draft-ietf-regext-tmch-func-spec.  We need to address 
these comments before this document can move forward.

And please note that draft-ietf-regext-launchphase is dependent on this 
document.  It is ready for publication but can not move forward until we 
can move both it and tmch-func-spec together.

Thanks,

Jim

On 23 Apr 2016, at 1:53, Patrik Fältström wrote:

> Comments (some of this can also be fund in SSAC document SAC-060 23 
> July 2013):
>
> 1. It is not clear how permutations of strings are to be calculated 
> (by whom, and how) in the case confusability risks might arise. For 
> example by the use of language tables or other mechanisms like LGRs.
>
> 2. The term "leftmost" is a bit confusing when talking about labels in 
> DNS. I propose using "first" as in logical order.
>
> 3. The matching algorithm is not described, who is implementing it 
> etc.
>
> 4. There are no instructions on how to handle cases where the matching 
> algorithm in TMCH is different from matching algorithm one "expect" 
> ("one" as in the trademark holder).
>
>    Patrik
>
> On 22 Apr 2016, at 22:39, [email-masked] wrote:
>
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>> This draft is a work item of the Registration Protocols Extensions of 
>> the IETF.
>>
>>         Title           : ICANN TMCH functional specifications        
>> Author          : Gustavo Lozano
>> 	Filename        : draft-ietf-regext-tmch-func-spec-00.txt
>> 	Pages           : 60
>> 	Date            : 2016-04-22
>>
>> Abstract:
>>    This document describes the requirements, the architecture and the 
>>   interfaces between the ICANN Trademark Clearinghouse (TMCH) and   
>> Domain Name Registries as well as between the ICANN TMCH and Domain   
>> Name Registrars for the provisioning and management of domain names   
>> during Sunrise and Trademark Claims Periods.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-regext-tmch-func-spec/
>>
>> There's also a htmlized version available at:
>> https://tools.ietf.org/html/draft-ietf-regext-tmch-func-spec-00
>>
>>
>> Please note that it may take a couple of minutes from the time of 
>> submission until the htmlized version and diff are available at 
>> tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> I-D-Announce mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext

---

From: Roger D Carney <[email-masked]>
Date: Mon, 6 Jun 2016 21:13:05 +0000

Good Afternoon,

In addition to those items that Patrik mentioned, we have been discussing, off list with several people, a couple issues around: the 48 hour timing requirement/reference, the use of <tmNotice:notAfter> for expiring, TCNs being generated twice daily and the verifications/validations required by registries and registrars.

Ideally a TCN would be valid indefinitely and only change if claims on a label have changed, I am not sure why the TMCH is updating these every 12 hours (twice daily) maybe there are good reasons and I just don't know them:). Additionally the old TCN should remain valid for a certain amount of time (e.g. 7 days) so that a customer that has seen and accepted a claim can process their registration over a reasonable amount of time (many domains are registered after sitting in a shopping cart for days). I think this could remove some of the registry checks as well. Current setup makes pre-orders very inefficient (possibly requiring multiple registrant acceptances of the same claim information) and results in frustrated customers and dramatically lower go-live GA registration numbers.

It is a bit hard to say what to do with this wording in this RFC. I would say that these details should be extracted and referenced by this RFC, but what would we reference today? Is there a way to document these things external to the RFC and have the Claims review of the RPM PDP review that document and update/approve it (or consume into another document) on their findings? Except for moving these items to an external document I think until the RPM PDP discusses these issues, the current values should stay (just in another document) as almost everyone (Registries and Registrars) already follows these details today, we can just make it better.

Thanks

Roger

-----Original Message-----
From: regext [mailto:[email-masked]] On Behalf Of James Galvin
Sent: Friday, June 03, 2016 1:50 PM
To: Patrik Fältström <[email-masked]>; Gustavo Lozano <[email-masked]>
Cc: [email-masked]
Subject: Re: [regext] I-D Action: draft-ietf-regext-tmch-func-spec-00.txt

I want to remind the working group that we have the following unresolved comments regarding draft-ietf-regext-tmch-func-spec.  We need to address these comments before this document can move forward.

And please note that draft-ietf-regext-launchphase is dependent on this document.  It is ready for publication but can not move forward until we can move both it and tmch-func-spec together.

Thanks,

Jim

> On 22 Apr 2016, at 22:39, [email-masked]<mailto:[email-masked]> wrote:

>> [email-masked]<mailto:[email-masked]>

>> Internet-Draft directories: http://www.ietf.org/shadow.html or

>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt

> [email-masked]<mailto:[email-masked]>

regext mailing list

[email-masked]<mailto:[email-masked]>

---

From: Gustavo Lozano <[email-masked]>
Date: Tue, 7 Jun 2016 22:16:28 +0000

Patrick,

Apologies for the late response, I was on paternity leave, and still
behind on my email.

Comments inline.

Regards,
Gustavo

On 4/22/16, 22:53, "regext on behalf of Patrik Fältström"
<[email-masked] on behalf of [email-masked]> wrote:

>Comments (some of this can also be fund in SSAC document SAC-060 23 July
>2013):
>
>1. It is not clear how permutations of strings are to be calculated (by
>whom, and how) in the case confusability risks might arise. For example
>by the use of language tables or other mechanisms like LGRs.

There are two places where permutations may need to be calculated:

* Trademark registration in the TMDB. In this case, the matching rules
defined in "Explanatory Memorandum: Implementing the Matching Rules"
(https://newgtlds.icann.org/en/about/trademark-clearinghouse/matching-rules
-24sep12-en.pdf) are used by the TMV (i.e. the company receiving the
trademark registrations) to calculate permutations, if any.

* Domain name registration path. Registries, as described in their
Registry Agreement, must follow the "IDN Implementation Guidelines"
(https://www.icann.org/resources/pages/implementation-guidelines-2012-02-25
-en). Per the Registry Agreement, each Registry may define their
IDN-variant policies. Section 4.1.3 of the RPM Requirements makes this
clear to Registry Operators (i.e.
https://newgtlds.icann.org/en/about/trademark-clearinghouse/rpm-requirement
s-30sep13-en.pdf).

>DNS. I propose using "first" as in logical order.

We only use A-labels in algorithms in the Internet-Draft; I think
"leftmost" works, no?

>
>3. The matching algorithm is not described, who is implementing it etc.

The scope of this Internet-Draft is to define the technical interfaces to
allow Registrars, Registries, TMV and TMDB to interact.

Regarding the matching algorithms, please see answer to 1 above.

>("one" as in the trademark holder).

Sorry, I didn't get the question, could you please rephrase?

>>interfaces between the ICANN Trademark Clearinghouse (TMCH) and   Domain
>>Name Registries as well as between the ICANN TMCH and Domain   Name
>>Registrars for the provisioning and management of domain names   during
>>Sunrise and Trademark Claims Periods.
>>
>>

---

From: Gustavo Lozano <[email-masked]>
Date: Tue, 7 Jun 2016 22:21:12 +0000

Roger,

The expiration of the acknowledgment and TCN (48 hours) was the result of
consultations with the community.
 
In hindsight, those values (i.e. expiration of the acknowledgment and TCN)
should probably been defined in a different document, but they ended in this
draft. 
 
Modifying those values would require the involvement of the ICANN community,
because there may be different points of view (some may want the values to
be larger and others shorter).
 
My suggestion is to update the Internet-Draft in order to say that 48 hours
is the default, but the values used by implementations may be different
based on policy.

Regards,
Gustavo

From:  regext <[email-masked]> on behalf of Roger D Carney
<[email-masked]>
Date:  Monday, June 6, 2016 at 14:13
To:  "[email-masked]" <[email-masked]>
Subject:  Re: [regext] I-D Action: draft-ietf-regext-tmch-func-spec-00.txt

> Good Afternoon,
>  
> In addition to those items that Patrik mentioned, we have been discussing, off
> list with several people, a couple issues around: the 48 hour timing
> requirement/reference, the use of <tmNotice:notAfter> for expiring, TCNs being
> generated twice daily and the verifications/validations required by registries
> and registrars.
>  
> Ideally a TCN would be valid indefinitely and only change if claims on a label
> have changed, I am not sure why the TMCH is updating these every 12 hours
> (twice daily) maybe there are good reasons and I just don't know them:).
> Additionally the old TCN should remain valid for a certain amount of time
> (e.g. 7 days) so that a customer that has seen and accepted a claim can
> process their registration over a reasonable amount of time (many domains are
> registered after sitting in a shopping cart for days). I think this could
> remove some of the registry checks as well. Current setup makes pre-orders
> very inefficient (possibly requiring multiple registrant acceptances of the
> same claim information) and results in frustrated customers and dramatically
> lower go-live GA registration numbers.
>  
> It is a bit hard to say what to do with this wording in this RFC. I would say
> that these details should be extracted and referenced by this RFC, but what
> would we reference today? Is there a way to document these things external to
> the RFC and have the Claims review of the RPM PDP review that document and
> update/approve it (or consume into another document) on their findings? Except
> for moving these items to an external document I think until the RPM PDP
> discusses these issues, the current values should stay (just in another
> document) as almost everyone (Registries and Registrars) already follows these
> details today, we can just make it better.
>  
>  
> Thanks
> Roger
>  
>  
> comments regarding draft-ietf-regext-tmch-func-spec. We need to address these
> comments before this document can move forward.
>  
> document. It is ready for publication but can not move forward until we can
> move both it and tmch-func-spec together.
>  
> Thanks,
>  
> Jim
>  
>  
>  
>>> <https://datatracker.ietf.org/doc/draft-ietf-regext-tmch-func-spec/>
>>> >> 
>>> <https://tools.ietf.org/html/draft-ietf-regext-tmch-func-spec-00>
>>> >> 
>>> >> 
>>> >> ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>
>>> >> 
>>> >> [email-masked] <mailto:[email-masked]>
>>> <https://www.ietf.org/mailman/listinfo/i-d-announce>
>>> <http://www.ietf.org/shadow.html>  or
>>> <ftp://ftp.ietf.org/ietf/1shadow-sites.txt>
>> > [email-masked] <mailto:[email-masked]>
>> <https://www.ietf.org/mailman/listinfo/regext>
>  
> [email-masked] <mailto:[email-masked]>
> <https://www.ietf.org/mailman/listinfo/regext>

---

From: "Patrik Fältström" <[email-masked]>
Date: Wed, 08 Jun 2016 08:31:07 +0200

On 8 Jun 2016, at 0:16, Gustavo Lozano wrote:

> * Trademark registration in the TMDB. In this case, the matching rules defined in "Explanatory Memorandum: Implementing the Matching Rules"
> (https://newgtlds.icann.org/en/about/trademark-clearinghouse/matching-rules -24sep12-en.pdf) are used by the TMV (i.e. the company receiving the trademark registrations) to calculate permutations, if any.
>
> * Domain name registration path. Registries, as described in their Registry Agreement, must follow the "IDN Implementation Guidelines"
> (https://www.icann.org/resources/pages/implementation-guidelines-2012-02-25 -en). Per the Registry Agreement, each Registry may define their IDN-variant policies. Section 4.1.3 of the RPM Requirements makes this clear to Registry Operators (i.e.
> https://newgtlds.icann.org/en/about/trademark-clearinghouse/rpm-requirement s-30sep13-en.pdf).

My view is that this must be explained in detail how it works in the I-D so that implementors of the I-D "do the right thing" depending on what role the implementor have.

> We only use A-labels in algorithms in the Internet-Draft; I think "leftmost" works, no?

Well, maybe, but you should clarify this. It is not clear today.

> The scope of this Internet-Draft is to define the technical interfaces to allow Registrars, Registries, TMV and TMDB to interact.
>

Noted, but the algorithm used to normalize a string before doing the matching must be specified or very explicitly referenced via a normative reference. For example the "remove space" (or something similar) which I do not understand what it means given "space" is quite undefined (or can mean multiple things) when using Unicode.

> Sorry, I didn't get the question, could you please rephrase?

The matching algorithm (or rather, the normalization that is defined) for TMCH is done for english and latin script. Other languages and scripts might want different normalization algorithms. That might create a surprise and that should be explained.

   Patrik

---

From: Gustavo Lozano <[email-masked]>
Date: Thu, 9 Jun 2016 18:36:25 +0000

Patrick,

I just published a new version of the I-D
(https://tools.ietf.org/html/draft-ietf-regext-tmch-func-spec-01) that
incorporates your suggestions.

Regarding your comments about the matching algorithm, I will channel those
to the appropriate person within ICANN.

You may see the changes in the following link:
https://tools.ietf.org/rfcdiff?url2=draft-ietf-regext-tmch-func-spec-01.txt

I appreciate your feedback. If neccesary, I will publish a new version, at
the end, publishing a new version is cheap.

Regards,
Gustavo

On 6/7/16, 23:31, "Patrik Fältström" <[email-masked]> wrote:

>>>July
>>(https://newgtlds.icann.org/en/about/trademark-clearinghouse/matching-rul
>>es -24sep12-en.pdf) are used by the TMV (i.e. the company receiving the
>>(https://www.icann.org/resources/pages/implementation-guidelines-2012-02-
>>25 -en). Per the Registry Agreement, each Registry may define their
>My view is that this must be explained in detail how it works in the I-D
>so that implementors of the I-D "do the right thing" depending on what
>role the implementor have.
>
>> The scope of this Internet-Draft is to define the technical interfaces
>>to allow Registrars, Registries, TMV and TMDB to interact.
>>
>Noted, but the algorithm used to normalize a string before doing the
>matching must be specified or very explicitly referenced via a normative
>reference. For example the "remove space" (or something similar) which I
>do not understand what it means given "space" is quite undefined (or can
>mean multiple things) when using Unicode.
>
>The matching algorithm (or rather, the normalization that is defined) for
>TMCH is done for english and latin script. Other languages and scripts
>might want different normalization algorithms. That might create a
>surprise and that should be explained.
>
>   Patrik

---

From: Gustavo Lozano <[email-masked]>
Date: Thu, 9 Jun 2016 18:37:34 +0000

Roger,

Regards,
Gustavo

---

From: Gustavo Lozano <[email-masked]>
Date: Thu, 16 Jun 2016 23:35:20 +0000

Dear chairs, working group,

I have not received any further comments on the draft
(draft-ietf-regext-tmch-func-spec).

I think that version 01 of the draft
(https://tools.ietf.org/html/draft-ietf-regext-tmch-func-spec-01)
is ready for publication.

Regards,
Gustavo

---

From: "James Galvin" <[email-masked]>
Date: Fri, 17 Jun 2016 09:36:12 -0400

Gustavo,

Unfortunately, as Patrik noted, the document needs a normative reference 
to a matching algorithm.  You have stated that you will bring that to 
the attention of the appropriate ICANN folks, but I do not see how this 
document can move forward without that.

It is a technical issue and affects interoperability, which makes a 
resolution essential.

I’m interested in other opinions but I do not believe this document 
can move forward without this.

Jim

---

From: "Patrik Fältström" <[email-masked]>
Date: Fri, 17 Jun 2016 15:40:48 +0200

Jim, thanks,

I have been busy with $dayjob, but before my questions below are answered I do not think the document is ready. I did not feel I had to repeat them.

   Patrik

On 17 Jun 2016, at 15:36, James Galvin wrote:

> Gustavo,
>
> Unfortunately, as Patrik noted, the document needs a normative reference to a matching algorithm.  You have stated that you will bring that to the attention of the appropriate ICANN folks, but I do not see how this document can move forward without that.
>
> It is a technical issue and affects interoperability, which makes a resolution essential.
>
> I’m interested in other opinions but I do not believe this document can move forward without this.
>
> Jim
>
>
>

---

From: Gustavo Lozano <[email-masked]>
Date: Fri, 17 Jun 2016 22:13:52 +0000

Jim and Patrick,
 
I thought provided a response to your questions, but if not,, please let me
know specific issues and I will try to address them promptly.

Let me try to explain the approach of the draft.

The Trademark Validator (TMV) implements an algorithm
(https://newgtlds.icann.org/en/about/trademark-clearinghouse/matching-rules-
24sep12-en.pdf ) to translate a trademark into one or more (permutations are
possible) A-labels or NR-LDH labels (i.e. potential labels for registration
and/or protection), which I added as a normative reference in my draft. The
potential labels for registration and/or protection are included in the SMD,
sunrise and claims lists.
 
During the sunrise period, a registry needs to validate that the domain name
being allocated is included in the list of potential labels for registration
within the SMD. 
 
During claims, a registry needs to validate the assertion that the Registrar
showed a claims notice if the domain name being allocated is included in the
claims list. 
 
The RPM requirements document
(https://newgtlds.icann.org/en/about/trademark-clearinghouse/rpm-requirement
s-30sep13-en.pdf ) defines the requirements in case of IDN variants:
"During the Claims Period, if Registry Operator has established IDN variant
policies for Allocation of domain names in the TLD, Registry Operator must
check all labels in a variant set against the Domain Name Label List before
any domain names in the set are registered. "
 
People may not agree with the algorithm used by the TMV, but this document
was defined in the context of the new gTLD program. Even if the algorithm
were to be updated, the specification defined in my draft continues to be
the same, because it uses the output of the algorithm as a black box.
 
The matching rules document is now part of the "Normative References", and
it is mentioned in the Glossary, in order to allow a reader to understand
the complete picture of the TMCH/TMDB model, but a developer (TMDB, Registry
or Registrar) of this draft should be able to implement the requirements
without knowing about the [MatchingRules].

Regards,
Gustavo

On 6/17/16, 06:36, "James Galvin" <[email-masked]> wrote:

> I¹m interested in other opinions but I do not believe this document