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

From: Gustavo Lozano <[email-masked]>
Date: Tue, 4 Oct 2016 23:13:16 +0000

<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode:
space; -webkit-line-break: after-white-space; font-family: Calibri,
sans-serif; font-size: 14px; color: rgb(0, 0, 0);"><div>Thank you
Patrik,</div><div><br></div><div>Comments
inline.</div><div><br></div><div>Regards,</div><div>Gustavo</div><div><br></
div><div>On 9/30/16, 06:50, "Patrik Fältström" &lt;<a
href="mailto:[email-masked]">[email-masked]</a>&gt;
wrote:</div><div><br></div><blockquote
id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid;
PADDING:0 0 0 5; MARGIN:0 0 0 5;"><div>On 18 Jun 2016, at 0:13, Gustavo
Lozano wrote:</div><div><br></div><blockquote
id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid;
PADDING:0 0 0 5; MARGIN:0 0 0 5;"><div> I thought provided a response to
your questions, but if not,, please</div><div>let me know specific issues
and I will try to address them
promptly.</div></blockquote><div><br></div><div>Sorry for being behind here,
and thanks Jim for the push on checking
on</div><div>this.</div><div><br></div><div>I think there is a general
confusion here and I will try to explain</div><div>myself better this
time.</div><div><br></div><blockquote
id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid;
PADDING:0 0 0 5; MARGIN:0 0 0 5;"><div> Let me try to explain the approach
of the draft.</div><div><br></div><div> The Trademark Validator (TMV)
implements an algorithm</div><div> </div><div>(<a
href="https://newgtlds.icann.org/en/about/trademark-clearinghouse/matching-r
ul">https://newgtlds.icann.org/en/about/trademark-clearinghouse/matching-rul
</a></div><div>es-</div><div> 24sep12-en.pdf ) to translate a trademark into
one or more</div><div>(permutations are possible) A-labels or NR-LDH labels
(i.e. potential</div><div>labels for registration and/or protection), which
I added as a normative</div><div>reference in my draft. The potential labels
for registration and/or</div><div>protection are included in the SMD,
sunrise and claims lists.</div></blockquote><div><br></div><div>I claim you
can not have such normative
references.</div></blockquote><div><br></div><div>Based on your comments, my
understanding is that you object to having such</div><div>normative
reference(s) if the I-D is a standards track document, but
you</div><div>would be ok if is informational,
correct?</div><div><br></div><div><br></div><blockquote
id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid;
PADDING:0 0 0 5; MARGIN:0 0 0 5;"><div><br></div><div>This because the rules
might change by whatever processes ICANN use, and</div><div>for IETF it is
important to know that/whether the rules are interoperable</div><div>with
whatever the current version of IDNA2008 explain or
not.</div><div><br></div><div>This of course is one of the issues that is
ultimately to be validated</div><div>during last call of the
document.</div><div><br></div><div>Now when I read it I also must point out
that you do not follow the</div><div>terminology in RFC7719. That you
redefine terms is not good. That will</div><div>absolutely lead to
confusion. Example, that you instead of using the term</div><div>in RFC7719
that is "Label", you say "DNL".</div></blockquote><div><br></div><div>DNL is
a subset of Label as defined in RFC7719, I am going to update
the</div><div>definition to make this clear.</div><div><br></div><blockquote
id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid;
PADDING:0 0 0 5; MARGIN:0 0 0 5;"><div><br></div><blockquote
id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid;
PADDING:0 0 0 5; MARGIN:0 0 0 5;"><div> During the sunrise period, a
registry needs to validate that the domain</div><div>name being allocated is
included in the list of potential labels for</div><div>registration within
the SMD.</div></blockquote><div><br></div><div>If you look at 5.2.1, there
is no wording there (for example) that</div><div>indicate who is to
calculate all permutations of the possible domain</div><div>names and who do
the repeated matching
tries?</div></blockquote><div><br></div><div>Registries calculate the
permutations of possible domain names using their</div><div>published IDN
tables, basically the same way as during general</div><div>availability and
this is not related to the TMCH, therefore this does not</div><div>belong in
this document.</div><div><br></div><blockquote
id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid;
PADDING:0 0 0 5; MARGIN:0 0 0 5;"><div><br></div><div>Part of the confusion
is of course that the whole ICANN TMCH process call</div><div>the
transformation function that is applied to a string a
"matching</div><div>algorithm". In reality what you always do when you have
two strings that</div><div>are to be compared
are:</div><div><br></div><div>1. Transform string A to some normalized form
A', which might lead to</div><div>more than one A'</div><div>2. Transform
string B to some normalized form B', which might lead to</div><div>more than
one B'</div><div>3. Compare A' and B' and repeat for every version of A' and
B'</div></blockquote><div><br></div><div>This is the idea behind the design.
The design is documented in several</div><div>documents: [Claims50],
[QLP-Addendum], [RPM-Requirements] and this
I-D.</div><div><br></div><blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE"
style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0
5;"><div><br></div><div>The algorithm ICANN has specified in the "matching
rules" document is to</div><div>me more a "transformation" mechanism that
someone have the responsibility</div><div>to implement, while the comparison
is character by character (in what</div><div>charset?). And in reality what
is said in the I-D is that labels in A'</div><div>and B' must be valid
domain name labels (and even A-labels, which</div><div>confuses me as there
is an 1:1 mapping between A-label, and U-label, but</div><div>thats a
detail).</div></blockquote><div><br></div><div>This I-D describes an atomic
comparison, which</div><div><div>is basically a single A-label vs a single
A-label, in case of IDNs.</div><div><br></div></div><div><div><div>All the
labels included in the data files published</div><div>by the TMDB are either
an A-label or a NR-LDH labels. The data files defined in the</div><div>draft
use code points from the US-ASCII repertoire only. The HTTP server of
the</div><div>TMDB defines the encoding of the datafile using the
Content-Type header, therefore&nbsp;</div><div>I think there is no issue
with the comparison of labels.</div><div><br></div></div></div><blockquote
id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid;
PADDING:0 0 0 5; MARGIN:0 0 0 5;"><div><br></div><blockquote
id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid;
PADDING:0 0 0 5; MARGIN:0 0 0 5;"><div> During claims, a registry needs to
validate the assertion that the</div><div>Registrar showed a claims notice
if the domain name being allocated is</div><div>included in the claims
list.</div><div><br></div><div> The RPM requirements document</div><div>
</div><div>(<a 
href="https://newgtlds.icann.org/en/about/trademark-clearinghouse/rpm-requir
em">https://newgtlds.icann.org/en/about/trademark-clearinghouse/rpm-requirem
</a></div><div>ent s-30sep13-en.pdf ) defines the requirements in case of
IDN variants:</div><div> "During the Claims Period, if Registry Operator has
established IDN</div><div>variant policies for Allocation of domain names in
the TLD, Registry</div><div>Operator must check all labels in a variant set
against the Domain Name</div><div>Label List before any domain names in the
set are registered. "</div></blockquote><div>, </div><div>I do not see this
specified in the I-D. And how it is to be
implemented.</div></blockquote><div><br></div><div>This is defined in the
RPM requirements document, and I don’t think that</div><div>is a good idea
to define the same thing in two documents.</div><div><br></div><div><div>I
am going to move the [Claims50],</div><div>[QLP-Addendum] and
[RPM-Requirements] to the normative reference section,</div><div>because I
think that they are required in order to have the complete picture
of</div><div>the TMCH, my mistake for not including those in the normative
references</div><div>before.</div><div><br></div></div><blockquote
id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid;
PADDING:0 0 0 5; MARGIN:0 0 0 5;"><div><br></div><blockquote
id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid;
PADDING:0 0 0 5; MARGIN:0 0 0 5;"><div> People may not agree with the
algorithm used by the TMV, but this</div><div>document was defined in the
context of the new gTLD program. Even if the</div><div>algorithm were to be
updated, the specification defined in my draft</div><div>continues to be the
same, because it uses the output of the algorithm as</div><div>a black
box.</div></blockquote><div><br></div><div>Fair. And it is true I think the
algorithm is extremely non-optimal, but</div><div>you try to identify what
is actually implemented. But for that I suggest</div><div>an informational
and not standards track.</div><div><br></div><blockquote
id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid;
PADDING:0 0 0 5; MARGIN:0 0 0 5;"><div> The matching rules document is now
part of the "Normative References",</div><div>and it is mentioned in the
Glossary, in order to allow a reader to</div><div>understand the complete
picture of the TMCH/TMDB model, but a developer</div><div>(TMDB, Registry or
Registrar) of this draft should be able to implement</div><div>the
requirements without knowing about the
[MatchingRules].</div></blockquote><div><br></div><div>If this is to be a
standards track document (which it looks like), I must</div><div>object to
such normative references. Up to the last call</div><div>process/procedures
to say something about of
course.</div></blockquote><div><br></div><div><div>Based on your comments,
it appears that this</div><div>I-D should be an informational document, and
I have no objections for making</div><div>this I-D an informational
document. This I-D is included in</div><div>draft-ietf-regext-launchphase
(standards track) as a normative reference, and is</div><div>my
understanding that is possible to include an informational RFC as
a</div><div>normative reference in an standards track document, @chairs
please correct me if</div><div>I am wrong.</div><div><br></div><div>
</div><div>Publishing a new version of an I-D is cheap, therefore I
published&nbsp;</div><div>a new version (<a
href="https://tools.ietf.org/html/draft-ietf-regext-tmch-func-spec-02">https
://tools.ietf.org/html/draft-ietf-regext-tmch-func-spec-02</a>)</div><div>th
at I think solves the issues raised in this email and the issues
raised&nbsp;</div><div>in the previous IETF
meeting.</div><div><br></div></div><div><br></div><div><br></div><blockquote
id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid;
PADDING:0 0 0 5; MARGIN:0 0 0 5;"><div><br></div><div>&nbsp;&nbsp;
Patrik</div></blockquote><div><br></div></body></html>

---

From: Gustavo Lozano <[email-masked]>
Date: Tue, 4 Oct 2016 23:21:37 +0000

[Apologies for the previous message, it appears that Outlook did some
magic]

Thank you Patrik,

Comments inline.

Regards,
Gustavo

On 9/30/16, 06:50, "Patrik Fältström" <[email-masked]> wrote:

>On 18 Jun 2016, at 0:13, Gustavo Lozano wrote:
>
>> 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.
>
>Sorry for being behind here, and thanks Jim for the push on checking on
>this.
>
>I think there is a general confusion here and I will try to explain
>myself better this time.
>
>> 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-rul
>>es-
>> 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.
>
>I claim you can not have such normative references.

Based on your comments, my understanding is that you object to having such
normative reference(s) if the I-D is a standards track document, but you
would be ok if is informational, correct?

>
>This because the rules might change by whatever processes ICANN use, and
>for IETF it is important to know that/whether the rules are interoperable
>with whatever the current version of IDNA2008 explain or not.
>
>This of course is one of the issues that is ultimately to be validated
>during last call of the document.
>
>Now when I read it I also must point out that you do not follow the
>terminology in RFC7719. That you redefine terms is not good. That will
>absolutely lead to confusion. Example, that you instead of using the term
>in RFC7719 that is "Label", you say "DNL".

DNL is a subset of Label as defined in RFC7719, I am going to update the
definition to make this clear.

>
>> 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.
>
>If you look at 5.2.1, there is no wording there (for example) that
>indicate who is to calculate all permutations of the possible domain
>names and who do the repeated matching tries?

Registries calculate the permutations of possible domain names using their
published IDN tables, basically the same way as during general
availability and this is not related to the TMCH, therefore this does not
belong in this document.

>
>Part of the confusion is of course that the whole ICANN TMCH process call
>the transformation function that is applied to a string a "matching
>algorithm". In reality what you always do when you have two strings that
>are to be compared are:
>
>1. Transform string A to some normalized form A', which might lead to
>more than one A'
>2. Transform string B to some normalized form B', which might lead to
>more than one B'
>3. Compare A' and B' and repeat for every version of A' and B'

This is the idea behind the design. The design is documented in several
documents: [Claims50], [QLP-Addendum], [RPM-Requirements] and this I-D.

>
>The algorithm ICANN has specified in the "matching rules" document is to
>me more a "transformation" mechanism that someone have the responsibility
>to implement, while the comparison is character by character (in what
>charset?). And in reality what is said in the I-D is that labels in A'
>and B' must be valid domain name labels (and even A-labels, which
>confuses me as there is an 1:1 mapping between A-label, and U-label, but
>thats a detail).

This I-D describes an atomic comparison, which
is basically a single A-label vs a single A-label, in case of IDNs.

All the labels included in the data files published
by the TMDB are either an A-label or a NR-LDH labels. The data files
defined in the
draft use code points from the US-ASCII repertoire only. The HTTP server
of the
TMDB defines the encoding of the datafile using the Content-Type header,
therefore 
I think there is no issue with the comparison of labels.

>
>> 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-requirem
>>ent 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. "
>
>I do not see this specified in the I-D. And how it is to be implemented.

This is defined in the RPM requirements document, and I don¹t think that
is a good idea to define the same thing in two documents.

I am going to move the [Claims50],
[QLP-Addendum] and [RPM-Requirements] to the normative reference section,
because I think that they are required in order to have the complete
picture of
the TMCH, my mistake for not including those in the normative references
before.

>
>> 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.
>
>Fair. And it is true I think the algorithm is extremely non-optimal, but
>you try to identify what is actually implemented. But for that I suggest
>an informational and not standards track.
>
>> 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].
>
>If this is to be a standards track document (which it looks like), I must
>object to such normative references. Up to the last call
>process/procedures to say something about of course.

Based on your comments, it appears that this
I-D should be an informational document, and I have no objections for
making
this I-D an informational document. This I-D is included in
draft-ietf-regext-launchphase (standards track) as a normative reference,
and is
my understanding that is possible to include an informational RFC as a
normative reference in an standards track document, @chairs please correct
me if
I am wrong.

Publishing a new version of an I-D is cheap, therefore I published
a new version 
(https://tools.ietf.org/html/draft-ietf-regext-tmch-func-spec-02)
th at I think solves the issues raised in this email and the issues raised
in the previous IETF meeting.

>   Patrik

---

From: "Patrik Fältström" <[email-masked]>
Date: Wed, 05 Oct 2016 07:16:23 +0200

On 5 Oct 2016, at 1:21, Gustavo Lozano wrote:

> Based on your comments, my understanding is that you object to having such normative reference(s) if the I-D is a standards track document, but you would be ok if is informational, correct?

That is my *personal* view, but is ultimately defined by the IETF at time of last call.

> DNL is a subset of Label as defined in RFC7719, I am going to update the definition to make this clear.

But the main problem is that you do not use the RFC7719 terminology. You use your own terms. It makes the document extremely hard to read and understand.

There is a reason why I supported RFC7719 strongly and why the community wanted it. It is because people should use it.

Please do!

> Registries calculate the permutations of possible domain names using their published IDN tables, basically the same way as during general availability and this is not related to the TMCH, therefore this does not belong in this document.

It is absolutely part of the TMCH. SSAC have even said that a better solution is to have the receiving end of the path do the calculations than the sending part. You require the registrars to have knowledge about all permutations possible, in all scripts, and then you have to send the whole set of names to do the notifications.

I.e. this design is from my perspective broken, and should not have been accepted in ICANN in the first place, and the question is whether IETF should accept it. Maybe as an informational RFC of course as it describes the situation.

> This is the idea behind the design. The design is documented in several documents: [Claims50], [QLP-Addendum], [RPM-Requirements] and this I-D.

Then please do explain it as one transformation step and one comparison step. They are even done by different parties.

> is basically a single A-label vs a single A-label, in case of IDNs.

No, as I explain above, it explains one transformation step and then one comparison.

> by the TMDB are either an A-label or a NR-LDH labels. The data files defined in the
> draft use code points from the US-ASCII repertoire only. The HTTP server of the
> TMDB defines the encoding of the datafile using the Content-Type header, therefore

Well, if you do comparison according to what DNS does, then it is case insensitive for the A-Z octets, and then byte by byte for the other octets. Or is it octet by octet? Or?

Is that what you use?

> This is defined in the RPM requirements document, and I don¹t think that is a good idea to define the same thing in two documents.

Obviously I feel your document do not explain how variant calculations come into the state diagram of yours, specifically together with the transformation step I describe above that you claim the registrar (sending side) must do.

> [QLP-Addendum] and [RPM-Requirements] to the normative reference section, because I think that they are required in order to have the complete picture of
> the TMCH, my mistake for not including those in the normative references before.

Ok.

> I-D should be an informational document, and I have no objections for making
> draft-ietf-regext-launchphase (standards track) as a normative reference, and is
> my understanding that is possible to include an informational RFC as a normative reference in an standards track document, @chairs please correct me if
> I am wrong.

When I was an AD, that was not possible. And that is the whole point with Standards Track. To implement it you do only rely on documents that have a well known change process that is accepted and documented. Some organizations (IETF and ISO etc) do have agreements how to make normative references between each others documents. I do not think IETF and ICANN do.

My view, my personal view, is that the documents you reference normatively are not stable enough to be normative references in an IETF Standards Track Document (even a few hops away). The process for changing them in ICANN is not even near as predictive as the IETF Standards Track Process.

Why is this turned an I-D/RFC in the first place btw?

> Publishing a new version of an I-D is cheap, therefore I published a new version
> th at I think solves the issues raised in this email and the issues raised in the previous IETF meeting.

Ok.

   paf

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 5 Oct 2016 11:51:20 +0300

Hi Gustavo,

> On 5 Oct 2016, at 02:21, Gustavo Lozano <[email-masked]> wrote:
> 
> This I-D is included in

You are correct. Although it would be considered a "downref" (reference at a document at a lower maturity level) and thus will have to be explained.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 5 Oct 2016 11:56:35 +0300

To followup on my previous reply:

> When I was an AD, that was not possible. And that is the whole point with Standards Track. To implement it you do only rely on documents that have a well known change process that is accepted and d…

Patrick,
Do you think IESG should discuss referencing ICANN documents and come to some kind of consensus?

> My view, my personal view, is that the documents you reference normatively are not stable enough to be normative references in an IETF Standards Track Document (even a few hops away). The process f…

And that might be a good enough reason while a normative document to ICANN document might not be appropriate.

---

From: "Patrik Fältström" <[email-masked]>
Date: Wed, 05 Oct 2016 11:10:44 +0200

> Do you think IESG should discuss referencing ICANN documents and come to some kind of consensus?

My immediate reaction is "yes", as last call processes might be messy if we are unlucky.

So IESG might have to prepare themselves (via TEG?) on mapping the ICANN PDP's into IETF PDPs.

And come with indications on what is needed on the ICANN side for a normative reference.

And no, personally I have no idea.

> And that might be a good enough reason while a normative document to ICANN document might not be appropriate.

I am, as some people on this list might know, an individual that is conservative and careful regarding normative references.

Think about when a document on IETF side move forward on standards track, and we have a move from Proposed standard because two independent implementation exists that are interoperable. If then some normative reference change, what is to happen?

I.e. there is a reason why a document on one level on Standards Track can not have a normative reference to a different Standards Track document on a lower level.

And implications like that must be discussed, I think, before normative references are made from Standards Track Documents in IETF to documents produced in the ICANN PDPs.

   Patrik

---

From: "Patrik Fältström" <[email-masked]>
Date: Wed, 05 Oct 2016 11:11:21 +0200

> You are correct. Although it would be considered a "downref" (reference at a document at a lower maturity level) and thus will have to be explained.

+1

I was sloppy in my response. My apologies.

   Patrik

---

From: "Marc Blanchet" <[email-masked]>
Date: Wed, 05 Oct 2016 09:26:33 -0400

On 5 Oct 2016, at 5:10, Patrik Fältström wrote:

>>>> my understanding that is possible to include an informational RFC 
>>>> as a normative reference in an standards track document, @chairs 
>>>> please correct me if
>>>> I am wrong.
>>>
>>> When I was an AD, that was not possible. And that is the whole point 
>>> with Standards Track. To implement it you do only rely on documents 
>>> that have a well known change process that is accepted and 
>>> documented. Some organizations (IETF and ISO etc) do have agreements 
>>> how to make normative references between each others documents. I do 
>>> not think IETF and ICANN do.
>>
>> Patrick,
>>> My view, my personal view, is that the documents you reference 
>>> normatively are not stable enough to be normative references in an 
>>> IETF Standards Track Document (even a few hops away). The process 
>>> for changing them in ICANN is not even near as predictive as the 
>>> IETF Standards Track Process.
>>
> I am, as some people on this list might know, an individual that is 
> conservative and careful regarding normative references.
>
> Think about when a document on IETF side move forward on standards 
> track, and we have a move from Proposed standard because two 
> independent implementation exists that are interoperable. If then some 
> normative reference change, what is to happen?
>
> I.e. there is a reason why a document on one level on Standards Track 
> can not have a normative reference to a different Standards Track 
> document on a lower level.
>
> And implications like that must be discussed, I think, before 
> normative references are made from Standards Track Documents in IETF 
> to documents produced in the ICANN PDPs.

I somewhat agree with Patrick here. My take is that a lot of ICANN 
documents will never be « formatted » as needed for protocol 
referenced documents, since they just serve different purposes. They 
will have a lot of additional stuff not relevant for technical protocol 
and might not be organized for technical reference.  One idea might be 
to extract the technical stuff from ICANN documents and make it an IETF 
document and then make it normative. A bit more work on IETF side but 
parties involved have the incentive to do it and will probably result in 
a better framework of technical documents.

Regards, Marc.

>
>    Patrik
> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext

---

From: Peter Koch <[email-masked]>
Date: Wed, 5 Oct 2016 15:31:12 +0200

> document and then make it normative. A bit more work on IETF side but 

interesting side effect is that change control is with the IETF afterwards.

Why exactly does the draft under consideration have to be Standards Track?

-Peter

---

From: "Gould, James" <[email-masked]>
Date: Wed, 5 Oct 2016 14:09:08 +0000

There is a normative reference from the Standards Track draft-ietf-regext-launchphase to draft-ietf-regext-tmch-func-spec to describe the claims phase.  Should draft-ietf-regext-launchphase remove this normative reference and provide a brief description of the claims phase directly?  

—

JG

James Gould
Distinguished Engineer
[email-masked] <applewebdata://6F44D04D-8815-4E5D-AE61-17C7BBC4E394/[email-masked]>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

VerisignInc.com <http://verisigninc.com/>
> On Oct 5, 2016, at 9:31 AM, Peter Koch <[email-masked]> wrote:
>

---

From: Gustavo Lozano <[email-masked]>
Date: Wed, 5 Oct 2016 16:36:43 +0000

Comments inline.

Regards,
Gustavo

>Why exactly does the draft under consideration have to be Standards Track?

The idea was to make this document an Standards Track document, because
it¹s going to be referenced from another document intended to be Standards
Track. After the comments in this email thread, I think that it should be
Informational.

---

From: Gustavo Lozano <[email-masked]>
Date: Wed, 5 Oct 2016 16:42:40 +0000

I don't think that is a good idea to have the definition of the same process
in two different documents. @Alexey confirmed that an Informational document
can be used as a normative reference (i.e. downref reference), if an
explanation is provided, maybe this is the way forward?

Regards,
Gustavo

From:  regext <[email-masked]> on behalf of "Gould, James"
<[email-masked]>
Date:  Wednesday, October 5, 2016 at 07:09
To:  Peter Koch <[email-masked]>
Cc:  "[email-masked]" <[email-masked]>
Subject:  Re: [regext] I-D Action: draft-ietf-regext-tmch-func-spec-00.txt

> There is a normative reference from the Standards Track
> draft-ietf-regext-launchphase to draft-ietf-regext-tmch-func-spec to describe
> the claims phase.  Should draft-ietf-regext-launchphase remove this normative
> reference and provide a brief description of the claims phase directly?
> 
> ‹
> 
> 
> 
> JG
> 
> 
> 
> 
> James Gould
> Distinguished Engineer
> [email-masked]
> 
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
> 
> VerisignInc.com <http://VerisignInc.com>
>

---

From: Gustavo Lozano <[email-masked]>
Date: Tue, 11 Oct 2016 18:04:11 +0000

Comments inline.

Regards,
Gustavo

On 10/4/16, 22:16, "Patrik Fältström" <[email-masked]> wrote:

>> Based on your comments, my understanding is that you object to having
>>such normative reference(s) if the I-D is a standards track document,
>>but you would be ok if is informational, correct?
>
>But the main problem is that you do not use the RFC7719 terminology. You
>use your own terms. It makes the document extremely hard to read and
>understand.
>
>There is a reason why I supported RFC7719 strongly and why the community
>wanted it. It is because people should use it.
>
>Please do!

I reviewed the glossary, and with the update to the DNL definition in the
latest version, I don’t see any other term/acronym that is being redefined
from RFC7719. Please let me know if I missing any other term/acronym.

>> Registries calculate the permutations of possible domain names using
>>their published IDN tables, basically the same way as during general
>>availability and this is not related to the TMCH, therefore this does
>>not belong in this document.
>
>It is absolutely part of the TMCH. SSAC have even said that a better
>solution is to have the receiving end of the path do the calculations
>than the sending part. You require the registrars to have knowledge about
>all permutations possible, in all scripts, and then you have to send the
>whole set of names to do the notifications.
>
>I.e. this design is from my perspective broken, and should not have been
>accepted in ICANN in the first place, and the question is whether IETF
>should accept it. Maybe as an informational RFC of course as it describes
>the situation.

I respectfully disagree; I don't think the handling of variants is part of
the TMCH. Registries and Registrars handle variants in periods where the
TMCH is not involved, for example, general availability.

As of now, there are no universal IDN tables used by all gTLDs, the
authoritative source for IDN tables and policies is each Registry.

The TM notice acknowledgement is per domain name *effectively allocated*.
The Registry Agreements of the new gTLDs supporting variant activation
require the Registries to block variants by default, and activate them if
requested by the Registrar; therefore the Registrar knows a-priori the
variants to be effectively allocated because the Registrar trigger the
allocation. 

>Then please do explain it as one transformation step and one comparison
>step. They are even done by different parties.

I am not sure what is the issue here, but maybe the following example
could help me understand the issue.

For 1, the Trademark Validator (TMV) receives a trademark (e.g. "cafe
cafe"), and transforms it to "cafe-cafe" and "cafecafe". From the
Registry's perspective, the TMCH is a blackbox that says: please show a
claims notice for "cafe-cafe" and "cafecafe". This transformation
algorithm is defined in the [Matching Rules] document, which is not part
of this draft.
 
For 2, the Registrar tells the Registry that the Registrant wants to
register "cafe-cafe". The Registry Agreement has the rules regarding which
labels can be registered.

My understanding is that your comment regarding repeat for every version
of 'A' and 'B' in 3 is related to variants, and I provided an explanation
regarding variants above.

If there is an issue that I cannot see, could you please provide text to
solve this in the draft?

>Well, if you do comparison according to what DNS does, then it is case
>insensitive for the A-Z octets, and then byte by byte for the other
>octets. Or is it octet by octet? Or?
>
>Is that what you use?

The domains allocated by the Registry could be activated in the DNS,
therefore the comparison is done according to what the DNS does. The
labels are either A-label or NR-LDH, and RFC5890 says: Traditional LDH
labels already have a notion of equivalence: within that list of
characters, uppercase and lowercase are considered equivalent.... Matches
between a pair of A-labels, using normal DNS case-insensitive matching
rules.

I am going to add text to the I-D clarifying this.

>> This is defined in the RPM requirements document, and I don¹t think
>>that is a good idea to define the same thing in two documents.
>
>Obviously I feel your document do not explain how variant calculations
>come into the state diagram of yours, specifically together with the
>transformation step I describe above that you claim the registrar
>(sending side) must do.
>
>> [QLP-Addendum] and [RPM-Requirements] to the normative reference
>>section, because I think that they are required in order to have the
>>complete picture of
>>normative reference in an standards track document, @chairs please
>>correct me if
>> I am wrong.
>
>When I was an AD, that was not possible. And that is the whole point with
>Standards Track. To implement it you do only rely on documents that have
>a well known change process that is accepted and documented. Some
>organizations (IETF and ISO etc) do have agreements how to make normative
>references between each others documents. I do not think IETF and ICANN
>do.
>
>normatively are not stable enough to be normative references in an IETF
>Standards Track Document (even a few hops away). The process for changing
>them in ICANN is not even near as predictive as the IETF Standards Track
>Process.
>

At the time, it was suggested that the technical aspects of the TMCH
should be specified as an I-D, and this I-D is now part of the base
registry agreement, therefore having a stable reference is important.

---

From: "Patrik Fältström" <[email-masked]>
Date: Wed, 12 Oct 2016 09:35:42 +0200

> from RFC7719. Please let me know if I missing any other term/acronym.

Once again. You do not use the terms in 7719. You redefine them. Sure, a 1:1 mapping, but that is not the point. You define a new terminology and you do not in the draft use the terminology in 7719 but your own terms.

> I respectfully disagree;

Ok, we disagree.

> I don't think the handling of variants is part of

You and I have different views on what Variants are in ICANN. See the issues with traditional and simplified chinese for example, or the whole IDN ccTLD fast track discussions for arabic based scripts.

> authoritative source for IDN tables and policies is each Registry.

That is not a really a variant issue.

> The TM notice acknowledgement is per domain name *effectively allocated*.

Well, not really. Could as well be allocatable in the case of variants.

> variants to be effectively allocated because the Registrar trigger the

Correct, and that is why TMCH must take this calculation of variants into account. This so that the match is towards all variants.

> cafe"), and transforms it to "cafe-cafe" and "cafecafe".

This is a transformation step.

> From the

This is the matching step (match “cafe-cafe” with “cafe-cafe”, and that is a match if we use NFC, Unicode etc).

> If there is an issue that I cannot see, could you please provide text to

Hope what I wrote above made this clearer.

> I am going to add text to the I-D clarifying this.

Thanks, that is the matching rules (see above), not the transformation step.

> registry agreement, therefore having a stable reference is important.

So there is a normative reference to an I-D?

That is not according to what IETF say should be done. I am surprised ICANN (that is said to have a good relationship with IETF) in the ICANN PDP allow such reference.

   paf

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 12 Oct 2016 13:54:20 -0400

I am just now wading into this since Alexey has passed shepherding duties onto me for this group and this is not my area of expertise so please feel free to correct me. 

It seems to me there is a fairly straightforward resolution to the reference issue. As pointed out below, the only reason that draft-ietf-regext-launchphase appears to have a normative reference to draft-ietf-regext-tmch-func-spec is to be able to reference the definition of trademark claims phase (although draft-ietf-regext-tmch-func-spec calls this the trademark claims period). But none of the other phases have definitional citations, presumably because the phase definitions are taken as given based on existing ICANN policy (in the same way that when a document talks about a time frame of “1 day” it does not need to provide any citation about how 1 day equals 24 hours because the definition of 1 day is taken as a given). And draft-ietf-regext-tmch-func-spec isn’t really the source of the definition anyway, since the definition there is derived from existing ICANN policy. So either deleting the reference in  draft-ietf-regext-launchphase or making it informative seems legitimate. And in either case draft-ietf-regext-tmch-func-spec could then be made informational, which seems more appropriate than standards track, in which case the issue of normative references to ICANN PDPs is avoided.

Alissa

> On Oct 5, 2016, at 10:09 AM, Gould, James <[email-masked]> wrote:
> 
> <BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png>
> 
> James Gould
> Distinguished Engineer
> [email-masked] <x-msg://46/[email-masked]>
> 
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
> 
>> On Oct 5, 2016, at 9:31 AM, Peter Koch <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> [email-masked] <mailto:[email-masked]>