Comments inline. Regards, Gustavo
On 10/4/16, 22:16, "Patrik Fältström" <p...@frobbit.se> wrote: >On 5 Oct 2016, at 1:21, Gustavo Lozano wrote: > >>>> 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-r >>>>ul >>>> 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? > >That is my *personal* view, but is ultimately defined by the IETF at time >of last call. > >>> 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. > >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. > >>>> 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. > >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. > >>> 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". 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? > >>> 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. > >No, as I explain above, it explains one transformation step and then one >comparison. > >> 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. > >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. > >>>> 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-requir >>>>em >>>> 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. > >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. > >> 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. > >Ok. > >>> 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. > >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? 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. > >> 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. > >Ok. > > paf
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
