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-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?
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! >>> 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. >> 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. >> 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? >>> 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. 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? > 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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
