[Comments-technical-rz-lgr-15may19] Integration Panel comments on Technical Utilization of the RZ-LGR

[Asmus Freytag]

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


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.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/comments-technical-rz-lgr-15may19/attachments/20190620/fffdaddc/attachment.html>