IETF Logo Mail Archive

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

Gustavo Lozano <gustavo.lozano@icann.org> Tue, 04 October 2016 23:13 UTC

Return-Path: <gustavo.lozano@icann.org>
X-Original-To: regext@ietfa.amsl.com
Delivered-To: regext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEAE3129573 for <regext@ietfa.amsl.com>; Tue, 4 Oct 2016 16:13:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.195
X-Spam-Level:
X-Spam-Status: No, score=-7.195 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0cHBdqBD9JuQ for <regext@ietfa.amsl.com>; Tue, 4 Oct 2016 16:13:19 -0700 (PDT)
Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CC25129568 for <regext@ietf.org>; Tue, 4 Oct 2016 16:13:19 -0700 (PDT)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 4 Oct 2016 16:13:17 -0700
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Tue, 4 Oct 2016 16:13:16 -0700
From: Gustavo Lozano <gustavo.lozano@icann.org>
To: Patrik Fältström <paf@frobbit.se>
Thread-Topic: [regext] I-D Action: draft-ietf-regext-tmch-func-spec-00.txt
Thread-Index: AQHSHpTjUvV9k0ZvVU2z5yJLm62B3Q==
Date: Tue, 04 Oct 2016 23:13:16 +0000
Message-ID: <D417E9C3.124964%gustavo.lozano@icann.org>
References: <20160422203936.7591.51321.idtracker@ietfa.amsl.com> <BD015A74-7404-4342-9B4C-8C790D86F464@frobbit.se> <58CB89C8-195C-4DB0-A813-79659FDDA274@elistx.com> <D38885A2.10A45F%gustavo.lozano@icann.org> <14B77B99-79B6-416B-AE8C-14635C82B9E9@elistx.com> <D389C207.10A6FD%gustavo.lozano@icann.org> <4D23885F-0F51-4C68-9003-8D78FB2F35E0@frobbit.se>
In-Reply-To: <4D23885F-0F51-4C68-9003-8D78FB2F35E0@frobbit.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.6.8.160830
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.0.35.1]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="B_3558442393_3756595"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/-QQwaUoObHVQLw7ivb0otY7T1No>
Cc: "regext@ietf.org" <regext@ietf.org>, James Galvin <galvin@elistx.com>
Subject: Re: [regext] I-D Action: draft-ietf-regext-tmch-func-spec-00.txt
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Registration Protocols Extensions <regext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/regext>, <mailto:regext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/regext/>
List-Post: <mailto:regext@ietf.org>
List-Help: <mailto:regext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/regext>, <mailto:regext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Oct 2016 23:13:21 -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:paf@frobbit.se">paf@frobbit.se</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>

v2.23.0 | Report a Bug | By Email