<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" <<a href="mailto:p...@frobbit.se";>p...@frobbit.se</a>> 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 </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 </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 </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> Patrik</div></blockquote><div><br></div></body></html>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
