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@jjnsolutions.com

http://jjnsolutions.com

 

 

From: Gnso-epdp-idn-team <gnso-epdp-idn-team-bounces@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@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.