[Gnso-epdp-idn-team] RZ-LGR and DNS stability review
Michael.Bauland at knipp.de
Wed Oct 6 14:21:54 UTC 2021
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
> 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
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.
| knipp | Knipp Medien und Kommunikation GmbH
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
Amtsgericht Dortmund, HRB 13728
Chief Executive Officers:
Dietmar Knipp, Elmar Knipp
More information about the Gnso-epdp-idn-team