Jeff,

I believe the leadership proposal detailed below more accurately reflects the output of this WG. What the Board suggested was considered but not preferred by the WG. 
So while I am neutral regarding the WG chosen option and the Board suggested option, unless we have a consensus to change it I don't see us doing so. 


Rubens


On 7 Dec 2020, at 14:17, Jeff Neuman <jeff@jjnsolutions.com> wrote:

 
This is the Ninth Topical E-mail on outstanding questions being “put to the list.”  This covers a question stemming from the ICANN Board’s comment that applications for strings not integrated in the RZ-LGR should not be processed at all.  (Topic 25)
 
Remember:  We are down to the wire on this, so unless you have a VERY strong objection to these, we will put these into the document.  If you do have a big issue with the responses to these (all of which were previously discussed and in emails over the past 1.5 months), please let us know ASAP.  Only comments that provide the rationale for the objection with proposed replacement text to address the specific outstanding questions will now be considered.
 
Let’s not let the perfect be the enemy of the good.
 
Language from Draft Final Report Implementation Guidance 25.3: If a script is not yet integrated into the RZ-LGR, applicants should be able to apply for a string in that script, and it should be processed up to but not including contracting.
 
Comment from the ICANN Board:  The Board suggests that any applied-for string in a script not integrated in the RZ-LGR should not be processed until its validity and variant labels can be determined by RZ-LGR, following the Recommendation 5 of the RZ-LGR Study Group. 
 
Leadership Proposal. Based on the discussions that took place on the call as well as in other discussions of similar topics, we would recommend:
 
  1. Leaving the language in the report as is with respect to the recommendation.  Rationale:  Although the Study Group recommended that the label should not “proceed through evaluation”, it did not offer any thoughts as to whether the other uniquely GNSO new gTLD processes should apply.  It did not discuss contention sets, public comments, objections, etc.  This is most likely because the group with comprised of ccNSO members (as well as GNSO) and the aforementioned processes are uniquely for new gTLDs and not for the ccTLD Fast Track.
 
  1. Include a warning for applicants that apply for scripts that have not been integrated into the RZ-LGR (one will be included in the next draft) that states that there is a chance that the application may not ever pass evaluation and that the applicant may be responsible for the costs of additional evaluations of that string.  This is mentioned in the Study Group Report as “Option B”.
 
Please have your comments (If any) by no later than 23:59:59 UTC on Wednesday, December 9, 2020.
 
Sincerely,
 
Jeff & Cheryl
SubPro Co-Chairs
 
 
 
_______________________________________________
Gnso-newgtld-wg mailing list
Gnso-newgtld-wg@icann.org
https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg
_______________________________________________
By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.