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

[Michael Bauland]

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 at knipp.de
      Software Development        E-mail: Michael.Bauland at knipp.de

                                  Register Court:
                                  Amtsgericht Dortmund, HRB 13728

                                  Chief Executive Officers:
                                  Dietmar Knipp, Elmar Knipp