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.

2. 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.

2. 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.