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

Jeff Neuman jeff at jjnsolutions.com
Thu Sep 30 14:26:20 UTC 2021

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 at jjnsolutions.com

-----Original Message-----
From: Gnso-epdp-idn-team <gnso-epdp-idn-team-bounces at icann.org> On Behalf Of Michael Bauland
Sent: Wednesday, September 29, 2021 10:15 AM
To: gnso-epdp-idn-team at 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,


     |       |
     | knipp |            Knipp  Medien und Kommunikation GmbH
      -------                    Technologiepark
                                 Martin-Schmeisser-Weg 9
                                 44227 Dortmund

     Dipl.-Informatiker          Fon:    +49 231 9703-0
                                 Fax:    +49 231 9703-200
     Dr. Michael Bauland         SIP:    Michael.Bauland at knipp.de<mailto:Michael.Bauland at knipp.de>
     Software Development        E-mail: Michael.Bauland at knipp.de<mailto:Michael.Bauland at 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 at icann.org<mailto:Gnso-epdp-idn-team at icann.org>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/gnso-epdp-idn-team/attachments/20210930/7a2a2d76/attachment-0001.html>

More information about the Gnso-epdp-idn-team mailing list