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-rules- > 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. 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". > 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? 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' 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). > 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-requirement > 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. > 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. Patrik
signature.asc
Description: OpenPGP digital signature
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
