- comments-technical-rz-lgr-15may19@icann.org

[Comments-technical-rz-lgr-15may19] RySG Comments on the Study on Technical Use of Root Zone Label Generation Rules
by Demetriou, Samantha July 19, 2019

July 19, 2019

Hello, On behalf of the gTLD Registries Stakeholder Group (RySG), please find attached our comments on the Study on Technical Use of Root Zone Label Generation Rules. In the interest of time, we did not conduct a vote on these comments. We did discuss them on our mailing list and during a biweekly conference call, and no member opposed their submission. Please feel free to contact me with any questions or concerns. Best, Samantha Demetriou RySG Vice Chair, Policy

1 0

[Comments-technical-rz-lgr-15may19] Integration Panel comments on Technical Utilization of the RZ-LGR
by Asmus Freytag June 20, 2019

June 20, 2019

The Integration Panel has reviewed the work of the RZ-LGR-SG. Please find below our comments on the Technical Utilization of the RZ-LGR, as published at https://www.icann.org/en/system/files/files/recommendations-rz-lgr-14may19-… Regards, Asmus Freytag For the Integration Panel ============================================= section 3.2: Self-identified variants are to our knowledge not being delegated. Therefore, they should not be taken into account. Instead, the RZ-LGR should be the only normative source of variants. If such a self-identified label happens to have variant status under the RZ-LGR, it should be processed as any other variant label would. If it happens to be an invalid label, or not a variant, it should not be delegated, or not be delegated as variant. section 4: This section appears to duplicate the application of the RZ-LGR to an applied for label. The individual recommendations appear to focus only on code points, which fall short: a future RZ-LGR may also relax a context rule, for example, which could make some labels valid. section 4.2: we agree with this recommendation and it should be retained. The bulk of section 4 should be deleted and replaced by: «(1) Conformance with LGR Procedure. Policy or procedure must not override the results of the RZ-LGR. That is, policy or procedure alone cannot turn an “invalid” label to a “valid” label, or vice-versa. Doing so would invalidate the entire RZ-LGR. Any change to the RZ-LGR (e.g. repertoire, variant rules or WLEs) must be undertaken using the process stipulated in the LGR Procedure.» « (2) If an applied-for label is invalid according to the RZ-LGR at the time of application, it may be re-validated when a new RZ-LGR version becomes available. » « (3) the application process must require that labels are to be submitted normalized to NFC. » section 5: Option A: we agree section 5: Option B. The IP strongly disagrees with Option B. That option appears to be trying to replicate the Procedure while not really following it. Experience of past and current work of GPs and IP have shown how complex the study of scripts repertoire and variants can be, including complex rules. Cross-script interaction is also key to this assessment. The cross-script study can only be done in a consistent way by people looking at the whole process and all the scripts, not by a restricted set of people familiar only with the script being studied. Moreover, Option B is in some ways bypassing the whole process of the procedure. Finally, by not looking at the whole problem space, Option B may introduce labels that will be incompatible with the future script LGR. Option B must not be considered. section 6. While the SG may have decided to punt the issue of the number of delegated variants, it remains a very significant potential problem that should be undertaken. If no recommendation about this issue is agreed with the community, then we may end up later with applicants asking for a large number of variants, which will have way too many implications in security, in deployment, in software, … We have to remind ourselves that, in general, tools to manage and use variants in the DNS do not really exist. This issue has to be undertaken, soon. multiple sections: The text as currently written appears to imply in many places that the RZ-LGR is a single XML file. On the contrary, it should be noted that the RZ-LGR consists of a set of normative XML files together with supporting documents, which in turn consist of a set of HTML files as well as several PDFs. Without these supporting documents, correct understanding and use of the normative information cannot be guaranteed. The normative part of the RZ-LGR consists of multiple XML files; one for each script and a common (merged) file. Each are used in different stages of processing an application (see section 5 of the LGR-3 overview document). nits: section 10. The reference is misplaced. As it is, it seems to say that the IANA authoritative files are provided by the toolset. Instead of « but as a tool for community service. Only the XML file of the RZ-LGR published by PTI/IANA is to be considered authoritative or normative.[10] » , the suggested modification would be: « but as a tool for community service[10]. Only the XML file of the RZ-LGR published by PTI/IANA is to be considered authoritative or normative. » section 11: The Procedure does not ask the RZ-LGR to be backward compatible with existing TLDs. However, it does say that if some delegated TLDs are not valid under the LGR when published, then they should be grand-fathered. The IP, the GPs and the community have been active in verifying these and should continue to do so. The recommendation should be amended to reflect this. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

[Comments-technical-rz-lgr-15may19] various comments on Technical Utilization of the RZ-LGR
by Marc Blanchet May 20, 2019

May 20, 2019

Please find my comments on the Technical Utilization of the RZ-LGR, as published at https://www.icann.org/en/system/files/files/recommendations-rz-lgr-14may19-… My comments are provided as an individual. Regards, Marc Blanchet ============================================= section 3.2: Self-identified variants are to my knowledge not being delegated. Therefore, they should not be taken into account. Instead, the RZ-LGR should be the only normative source of variants. section 4.1: in this context, IDNA2008 is not enough precise. IDNA2008 provides rules that are applied to Unicode properties. Therefore the assessment of if a code point is DISALLOWED or UNASSIGNED depends on which Unicode version it is applied. History has shown that new Unicode versions may not automatically be applied. Suggested modification of text: « An applied-for label containing any DISALLOWED or UNASSIGNED code point(s) per IDNA 2008 applied to the most recent supported Unicode version, at the time of the verification, or its successors, must not proceed. » section 5: Option B. I strongly disagree in opting for Option B. Option B is trying to replicate the Procedure while not really doing it. Experience of past and current work of GPs and IP have shown how much complex can be the study of scripts repertoire and variants, including complex rules. Cross-script interaction is also key to this assessment. The cross-script study can only be done in a consistent way by people looking at the whole process and all the scripts, not by a restricted set of people familiar with the script being studied. Moreover, Option B is in some ways bypassing the whole process of the procedure. Finally, by not looking at the whole problem space, Option B may bring incompatible labels for the future script LGR. Option B must not be considered. section 6. While the SG may have decided to punt the issue of the number of delegated variants, it remains a very significant potential problem that should be undertaken. If no recommendation about this issue is agreed with the community, then we may end up later with applicants asking for a large number of variants, which will have way too many implications in security, in deployment, in software, … We have to remind ourselves that, in general, tools to manage and use variants in the DNS do not really exist. This issue has to be undertaken, soon. multiple sections: It should be noted that the RZ-LGR consists of multiple XML files, or is an XML files set. Current writing in many places imply a single XML file. nits: section 10. The reference is misplaced. As it is, it seems to say that the IANA authoritative files are provided by the toolset. Instead of « but as a tool for community service. Only the XML file of the RZ-LGR published by PTI/IANA is to be considered authoritative or normative.[10] » , the suggested modification would be: « but as a tool for community service[10]. Only the XML file of the RZ-LGR published by PTI/IANA is to be considered authoritative or normative. »

1 0