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