[Gnso-epdp-idn-team] RZ-LGR and DNS stability review

Tue Sep 28 19:27:46 UTC 2021

Good evening

This does, as far as I understand process, seem very sensible. We should,
within rules, be trying to maximise opportunities for applicants and part
of this is an appeals process that is flexible and fair. Agree with Jeff
that we cannot assume applicants have a complete understanding of all
relevant criteria.

Best

Nigel

On Tue, 28 Sep 2021, 00:47 Jeff Neuman, <jeff at jjnsolutions.com> wrote:

> Thanks for this explanation Dennis.  I still believe that there should be
> a challenge process for applicants even if the end result for an applicant
> is to just send it through the Label Generation Rules procedure.
>
>
>
> At the end of the day, at the time the LGR rules came out (or will come
> out in the future), many of the would-be applicants in future rounds may
> not be paying attention to ICANN, the LGR Rules, or the official challenge
> process.  It may not be until the applicant fails the DNS Stability
> evaluation that it realizes there was an official process to challenge the
> LGR for that script.  That could be years after the LGR was approved.
>
>
>
> All of this means that we cannot expect that applicants would have been
> aware of the LGR official challenge process, but applicants should be able
> to seek redress if it believes that the results were wrong (for whatever
> reason).  Therefore, I believe we should still have the challenge process
> for the corner case where this becomes an issue.
>
>
>
> To that end, I believe it is only the applicant that can challenge the
> result of the evaluation if it fails the String Similarity evaluation. It
> should not be challengeable by another 3rd party if the applicant passes
> the evaluation and the 3rd party believes that it should not have.  And I
> believe that the “arbiter” of the challenge should be a person from the
> Panel that performs the technical DNS Stability review (preferably one that
> did not evaluate the original application).
>
>
>
> The arbiter looks at whether the LGR rules were applied appropriately and
> that the results were in fact justified under the current LGR rules. [I
> know the process is “automated”, but mistakes can always be made].   If the
> rules were applied appropriately and the results were correct, then the
> challenge should be denied and the Applicant encouraged to utilize the
> formal LGR procedure which would have effect in a subsequent round.
>
>
>
> The applicant can on its own seek to modify the LGR rules through the
> official process, and if successful could resubmit its application in a *subsequent
> round*, but in my opinion, it should not be allowed back in to that
> current round.  If the string would have been in a contention set in the
> current round, then the applicant may not be able to apply for the string
> it wanted in the next round (due to it being confusingly similar to at that
> point a granted string), but that is the risk the applicant takes.  I
> believe it would be such a corner case for an applicant to have its string
> fail a DNS Stability review in Round 2, succeed in modifying the LGR tables
> for round 3, but be prohibited from applying for it again because another
> string in Round 2 went through that is confusingly similar.
>
>
>
> I hope all of that makes sense and I hope this proposal allows this issue
> to be resolved more quickly.
>
>
>
> Jeffrey J. Neuman
>
> Founder & CEO
>
> JJN Solutions, LLC
>
> p: +1.202.549.5079
>
> E: jeff at jjnsolutions.com
>
> http://jjnsolutions.com
>
>
>
>
>
> *From:* Gnso-epdp-idn-team <gnso-epdp-idn-team-bounces at icann.org> *On
> Behalf Of *Tan Tanaka, Dennis via Gnso-epdp-idn-team
> *Sent:* Thursday, September 23, 2021 3:09 PM
> *To:* gnso-epdp-idn-team at icann.org
> *Subject:* [Gnso-epdp-idn-team] RZ-LGR and DNS stability review
>
>
>
> Hello —during today’s meeting some of you referred to the DNS stability
> review process as the function to determine whether an applied-for string
> if deemed fit for the root zone. I also observed that we might want to
> focus on the very limited function of the RZ-LGR, and to deal with
> contention sets and other evaluation procedures later on.
>
>
>
> To that end, I looked at the old applicant guide book and searched for the
> DNS stability: string requirements (2.2.1.3.2). Basically, string
> requirements is broken down into three parts: Part I (technical
> requirements for all labels, Part II (requirements for IDNs), and Part III
> (policy requirements for gTLDs).
>
>
>
> The RZ-LGR, I believe, is meant to “replace” or “automate” Parts I and II
> of the string requirements review process (a copy of the text is down below
> for your reference). In addition to those functions, also helps with the
> calculation of variant labels, so that the applicants don’t have to come up
> with IDN variant rules of their own.
>
>
>
> The difference between the prior AGB and the RZ-LGR (if adopted), are
>
>    1. that the latter starts with a smaller universe of “valid” letters.
>    Before RZ-LGR, virtually all protocol valid code points were available to
>    be used in a TLD string (with exception of course of hyphen and digits).
>    The RZ-LGR starts with a smaller repertoire than IDNA2008 (i.e. Maximal
>    Starting Repertoire) which is further limited by each script generation
>    panel. The result of each generation panel’s work is merged into the
>    RZ-LGR. So, one applicant might challenge the RZ-LGR’s results because it
>    did not accept one letter, or a combination or some script rule. This
>    should be okay to challenge, but the process by which the applicant finds
>    resolution would be through the established LGR procedure (i.e. make the
>    case for inclusion of a new letter or rule) to maintain the stability of
>    the RZ-LGR.
>    2. the RZ-LGR is designed to calculate the variant labels. The prior
>    DNS stability review process did not do that; applicants were asked to
>    provide these self-identified variant labels.
>
>
>
> I hope this helps the discussion.
>
>
>
> Best,
>
> Dennis
>
>
>
> *Part I -- Technical Requirements for all Labels (Strings) *– The
> technical requirements for top-level domain labels follow.
>
>    1. 1.1  The ASCII label (i.e., the label as transmitted on the wire)
>    must be valid as specified in technical standards *Domain Names:
>    Implementation and Specification *(RFC 1035), and *Clarifications to
>    the DNS Specification *(RFC 2181) and any updates thereto. This
>    includes the following:
>
> 1.1.1  The label must have no more than 63 characters.
>
> 1.1.2  Upper and lower case characters are treated as identical.
>
>    1. 1.2  The ASCII label must be a valid host name, as specified in the
>    technical standards *DOD Internet Host Table Specification *(RFC 952), *Requirements
>    for Internet Hosts — Application and Support *(RFC 1123), and *Application
>    Techniques for Checking and Transformation of Names (RFC 3696),
>    Internationalized Domain Names in Applications (IDNA)(RFCs 5890-5894), and
>    any updates thereto. *This includes the following:
>
> 1.2.1 The ASCII label must consist entirely of letters (alphabetic
> characters a-z), or
>
> 1.2.2 The label must be a valid IDNA A-label (further restricted as
> described in Part II below).
>
> *Part II -- Requirements for Internationalized Domain Names *
>
> *– *These requirements apply only to prospective top-level domains that
> contain non-ASCII characters. Applicants for these internationalized
> top-level domain labels are expected to be familiar with the Internet
> Engineering Task Force (IETF) IDNA standards, Unicode standards, and the
> terminology associated with Internationalized Domain Names.
>
>    1. 2.1  The label must be an A-label as defined in IDNA, converted
>    from (and convertible to) a U-label that is consistent with the definition
>    in IDNA, and further restricted by the following, non-exhaustive, list of
>    limitations:
>
> 2.1.1  Must be a valid A-label according to IDNA.
>
> 2.1.2  The derived property value of all codepoints used in the U-label,
> as defined by IDNA, must be PVALID or CONTEXT (accompanied
>
> 2.1.3  The general category of all codepoints, as defined by IDNA, must be
> one of (Ll, Lo, Lm, Mn, Mc).
>
> 2.1.4  The U-label must be fully compliant with Normalization Form C, as
> described in *Unicode Standard Annex #15: Unicode Normalization Forms. *See
> also examples in http://unicode.org/faq/normalization.html.
>
> 2.1.5  The U-label must consist entirely of characters with the same
> directional property, or fulfill the requirements of the Bidi rule per RFC
> 5893.
>
>    1. 2.2  The label must meet the relevant criteria of the ICANN *Guidelines
>    for the Implementation of Internationalised Domain Names*. See
>    http://www.icann.org/en/topics/idn/implementation-guidelines.htm. This
>    includes the following, non- exhaustive, list of limitations:
>
> 2.2.1  All code points in a single label must be taken from the same
> script as determined by the Unicode Standard Annex #24: Unicode Script
> Property (See http://www.unicode.org/reports/tr24/).
>
> 2.2.2  Exceptions to 2.2.1 are permissible for languages with established
> orthographies and conventions that require the commingled use of multiple
> scripts. However, even with this exception, visually confusable characters
> from different scripts will not be allowed to co-exist in a single set of
> permissible code points unless a corresponding policy and character table
> are clearly defined.
>
>
> _______________________________________________
> Gnso-epdp-idn-team mailing list
> Gnso-epdp-idn-team at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-epdp-idn-team
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/gnso-epdp-idn-team/attachments/20210928/010e9c93/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 67520 bytes
Desc: not available
URL: <https://mm.icann.org/pipermail/gnso-epdp-idn-team/attachments/20210928/010e9c93/image001-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 67520 bytes
Desc: not available
URL: <https://mm.icann.org/pipermail/gnso-epdp-idn-team/attachments/20210928/010e9c93/image001-0003.png>