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.
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. [cid:image001.png@01D7B3D5.DFE03DE0] Jeffrey J. Neuman Founder & CEO JJN Solutions, LLC p: +1.202.549.5079 E: jeff@jjnsolutions.com<mailto: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.
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@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@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.
_______________________________________________ Gnso-epdp-idn-team mailing list Gnso-epdp-idn-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-idn-team
Hi Jeff, thanks for writing down your suggestion for the challenge process. If I understand this correctly you say that once the next round started, no one will be able to challenge (or dispute, or whatever the correct expression is) the RZ-LGR in order for the current application to be accepted, but instead they have to wait until the next round. If that's the case, I tend to disagree. If I apply for a TLD and the RZ-LGR says: No. Then I should have to opportunity to get that fixed in the current round without the need to (i) wait another 10 years and (ii) pay the application fee once again. After all, it's not my fault that the RZ-LGR was incorrect/incomplete (yes, I could have contended it, when it got published, but as you say, the majority of all people is not aware of what's happening here). A simple example would be, that I would like to apply for a TLD in a script for which no Generation Panel has been created and therefore the script is simply not contained in the current RZ-LGR version. Of course, fixing the RZ-LGR might not be possible in a few weeks or even months, but I think my application should remain on hold (and possibly also other applications that might be considered variants of mine) until either my the RZ-LGR challenge has been accepted or rejected. There is of course a problem with the determination of potential variant TLDs in the same round for my TLD, if my TLD's script is not yet contained in the RZ-LGR, but I guess in that case the similarity review team will have to take care of that somehow. Best regards, Michael -- ____________________________________________________________________ | | | knipp | Knipp Medien und Kommunikation GmbH ------- Technologiepark Martin-Schmeisser-Weg 9 44227 Dortmund Germany Dipl.-Informatiker Fon: +49 231 9703-0 Fax: +49 231 9703-200 Dr. Michael Bauland SIP: Michael.Bauland@knipp.de Software Development E-mail: Michael.Bauland@knipp.de Register Court: Amtsgericht Dortmund, HRB 13728 Chief Executive Officers: Dietmar Knipp, Elmar Knipp
In an attempt to try and clarify the proposal with examples, consider: 1. Applications for strings in a script for which LGR exist that are Invalid Applicant applies for a string that is declared invalid because one or more of the characters used in the string are not valid - Applicant should be able to challenge and have the script re-run through the tool as is OR if it was due to a typo, should be able to resubmit the string without the typo. In order to resubmit because of a typo, it must be clear on its face that there was a typo and this should not be used as an opportunity to submit a new string that bears no real relationship to the first submitted string. - If Applicant now passes the evaluation (i.e., a successful challenge), the application proceeds. - If Applicant does not pass the evaluation (i.e., the challenge is not successful), the application is not able to proceed and if there are any other valid strings that were in a contention set with that string, those other applications may proceed. - Applicant can still take advantage of the LGR Appeals process and to try and revise the LGR for that script, but that would be done outside of the new TLD process and would have no bearing on the current round even if the LGR is eventually changed. 2. Applications for strings in a script for which no LGR exists Applicant applies for a string which may or may not be valid, but no LGR rules exist for that script. In such a case, the application's DNS Stability review will be paused. Applicant will have the right to withdraw its application at that point (and get the applicable refund at that point in time), or it can elect to proceed with all other evaluations, objections, contention resolution (if applicable), etc. However, a contract for that string may not be signed unless and until an LGR Panel is convened for that script and the string is able to pass the DNS Stability evaluation (eg., it is valid according to that script's newly developed LGR). Please note that this was the recommendation of SubPro which was approved by Full Consensus of the Working Group and by the GNSO Council with a Unanimous vote. It was made after a review of all of the previous papers by the Technical Advisory Group and the report by ICANN staff. In addition, please consider: a) SubPro recommends successive uninterrupted rounds. So although it has been more than a decade between rounds so far now, in the future it is not supposed to work that way. b) Whether the applicant in situation 1 above decides to re-apply in the next round is solely up to that applicant. c) It is a separate question as to whether that applicant in situation 1 that reapplies must pay fees to reapply in the next round. But I would say it should because it could have used the tool before hand to determine whether the string was valid AND the evaluators still have to get paid for doing the work that they have done (and will do). I hope this helps. Jeffrey J. Neuman Founder & CEO JJN Solutions, LLC p: +1.202.549.5079 E: jeff@jjnsolutions.com http://jjnsolutions.com -----Original Message----- From: Gnso-epdp-idn-team <gnso-epdp-idn-team-bounces@icann.org> On Behalf Of Michael Bauland Sent: Wednesday, September 29, 2021 10:15 AM To: gnso-epdp-idn-team@icann.org Subject: Re: [Gnso-epdp-idn-team] RZ-LGR and DNS stability review Hi Jeff, thanks for writing down your suggestion for the challenge process. If I understand this correctly you say that once the next round started, no one will be able to challenge (or dispute, or whatever the correct expression is) the RZ-LGR in order for the current application to be accepted, but instead they have to wait until the next round. If that's the case, I tend to disagree. If I apply for a TLD and the RZ-LGR says: No. Then I should have to opportunity to get that fixed in the current round without the need to (i) wait another 10 years and (ii) pay the application fee once again. After all, it's not my fault that the RZ-LGR was incorrect/incomplete (yes, I could have contended it, when it got published, but as you say, the majority of all people is not aware of what's happening here). A simple example would be, that I would like to apply for a TLD in a script for which no Generation Panel has been created and therefore the script is simply not contained in the current RZ-LGR version. Of course, fixing the RZ-LGR might not be possible in a few weeks or even months, but I think my application should remain on hold (and possibly also other applications that might be considered variants of mine) until either my the RZ-LGR challenge has been accepted or rejected. There is of course a problem with the determination of potential variant TLDs in the same round for my TLD, if my TLD's script is not yet contained in the RZ-LGR, but I guess in that case the similarity review team will have to take care of that somehow. Best regards, Michael -- ____________________________________________________________________ | | | knipp | Knipp Medien und Kommunikation GmbH ------- Technologiepark Martin-Schmeisser-Weg 9 44227 Dortmund Germany Dipl.-Informatiker Fon: +49 231 9703-0 Fax: +49 231 9703-200 Dr. Michael Bauland SIP: Michael.Bauland@knipp.de<mailto:Michael.Bauland@knipp.de> Software Development E-mail: Michael.Bauland@knipp.de<mailto:Michael.Bauland@knipp.de> Register Court: Amtsgericht Dortmund, HRB 13728 Chief Executive Officers: Dietmar Knipp, Elmar Knipp _______________________________________________ Gnso-epdp-idn-team mailing list Gnso-epdp-idn-team@icann.org<mailto:Gnso-epdp-idn-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-idn-team
Hi Jeff, thanks very much for writing this down including the examples. I think this helps a lot to better understand what we're actually talking about. I'll add my thoughts in-line. On 30.09.2021 16:26, Jeff Neuman wrote:
In an attempt to try and clarify the proposal with examples, consider: 1. _Applications for strings in a script for which LGR exist__that are Invalid_ Applicant applies for a string that is declared invalid because one or more of the characters used in the string are not valid
Just a very small clarification: I would simply write that the label is declared invalid as there might also be cases in which the character on itself is ok, but its context causes the problem (i.e., the character may not appear if another character is before or after it).
- Applicant should be able to challenge and have the script re-run through the tool as is OR if it was due to a typo, should be able to resubmit the string without the typo. In order to resubmit because of a typo, it must be clear on its face that there was a typo and this should not be used as an opportunity to submit a new string that bears no real relationship to the first submitted string.
I'm unsure whether a change of the label should be permitted. I think a real typo in the sense that someone actually mistyped the label, but intended to register a different one is highly unlikely. If you pay hundreds of thousands of dollars for a few letters, you thoroughly thoroughly ... thoroughly check it (I would). The more likely case is that it was not an (accidental) typo, but the label I want is simply not allowed to the LGR. Should I then be able to slightly change the label to make it pass the LGR? If yes, we need a definition of what changes are ok and what changes are not allowed. In that case surely changing "cel·la" to "presó" should not be allowed, whereas changing it to "cella" should probably be considered to be ok. But not all cases will be this clear-cut.
- If Applicant now passes the evaluation (i.e., a successful challenge), the application proceeds. - If Applicant does not pass the evaluation (i.e., the challenge is not successful), the application is not able to proceed and if there are any other valid strings that were in a contention set with that string, those other applications may proceed > - Applicant can still take advantage of the LGR Appeals process and to try and revise the LGR for that script, but that would be done outside of the new TLD process and would have no bearing on the current round even if the LGR is eventually changed.
Here again I'm unsure and tend to disagree. If they successfully appeal and get the LGR changed, it might make sense to still include the label in the round it was applied for. After all, even though an LGR appeal might take a year or two, the next round could be 10-15 years later. If I were the applicant, I would be quite angry with ICANN if I had to wait 10 more years, just because there was an "error" in the LGR (which was not my fault ... well, at least if it wasn't the Latin script part of the LGR ;-) ). On the other hand I see the downside of keeping the application undecided until the LGR appeal was decided. This could cause other labels, that are visually very similar to also be put on hold until the LGR appeal gets decided. However since (i) contentions are not too likely and (ii) the wait time would "only" be 1-2 years compared to the 10-15 years, I think this is acceptable. Another reason for keeping the application in the same round (even if the next round is around the corner) is due to contentions: Say in the current round there is one application for "cella" and I apply for "cel·la" and at the same time (or maybe even slightly before) have appealed to change the LGR to have my label validated. If my application does not stay in this round, I can ignore the LGR appeal's result. I won't get my TLD label in any case, because "cella" will already have been approved and allocated by then, making my appeal futile.
2. _Applications for strings in a script for which no LGR exists_ Applicant applies for a string which may or may not be valid, but no LGR rules exist for that script. In such a case, the application's DNS Stability review will be paused. Applicant will have the right to withdraw its application at that point (and get the applicable refund at that point in time), or it can elect to proceed with all other evaluations, objections, contention resolution (if applicable), etc. However, a contract for that string may not be signed unless and until an LGR Panel is convened for that script and the string is able to pass the DNS Stability evaluation (eg., it is valid according to that script's newly developed LGR). *Please note **that this was the recommendation of SubPro which was approved by Full Consensus of the Working Group and by the GNSO Council with a Unanimous vote.** It was made after a review of all of the previous papers by the Technical **Advisory Group and the report by ICANN staff. *
Sounds ok to me. Best regard, Michael -- ____________________________________________________________________ | | | knipp | Knipp Medien und Kommunikation GmbH ------- Technologiepark Martin-Schmeisser-Weg 9 44227 Dortmund Germany Dipl.-Informatiker Fon: +49 231 9703-0 Fax: +49 231 9703-200 Dr. Michael Bauland SIP: Michael.Bauland@knipp.de Software Development E-mail: Michael.Bauland@knipp.de Register Court: Amtsgericht Dortmund, HRB 13728 Chief Executive Officers: Dietmar Knipp, Elmar Knipp
participants (4)
-
Jeff Neuman -
Michael Bauland -
Nigel Hickson -
Tan Tanaka, Dennis