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

[Gustavo Lozano <[e-mail]>]

[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" <[e-mail]> 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