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

["Patrik Fältström " <[e-mail]>]

On 11 Oct 2016, at 20:04, Gustavo Lozano wrote:

> 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.

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.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;

Ok, we 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.

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.

> As of now, there are no universal IDN tables used by all gTLDs, the
> 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.

> 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.

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

>>>> 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.
>>
>> 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".

This is a transformation step.

> 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.

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

> 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?

Hope what I wrote above made this clearer.

>> 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.

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

>> Why is this turned an I-D/RFC in the first place btw?
>
> 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.

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