Dear Working Group members, Please see below the notes from the meeting on 29 August 2019. These high-level notes are designed to help WG members navigate through the content of the call and are not a substitute for the recording, transcript, or the chat, which will be posted at: https://community.icann.org/display/NGSPP/2019-08-29+New+gTLD+Subsequent+Pro.... Kind regards, Julie Julie Hedlund, Policy Director Notes and Action Items: Actions: ACTION ITEM 1 re: High-Level Agreement (as relates to RySG comments): “If an applicant is compliant with IDNA2008 (RFCs 5890-5895) or its successor(s) and applicable LGRs for the scripts it intends to support, Pre-Delegation Testing should be unnecessary for the relevant scripts.” Seek clarification from RySG as this is reflected as a high-level agreement, but there is divergence from the ALAC and ICANN Org. Notes: 1. Updates to Statements of Interest: No updates provided. 2. Review of summary document – See: https://docs.google.com/document/d/1Q6_DxsCvSA_3B7ArncO2U4tWNY3vH7Wi4nINrouR... a. IDNs (page 26) Note: The GNSO Council has convened a scoping team to examine the policy implications from the IDN Variant TLD Implementation<https://www.icann.org/public-comments/managing-idn-variant-tlds-2018-07-25-e...> and Final Proposed Draft Version 4.0<https://www.icann.org/resources/pages/implementation-guidelines-2012-02-25-e...> of the IDN Implementation Guidelines. After examining the policy implications, the group will accordingly suggest to the GNSO Council a mechanism to address (e.g., SubPro, new PDP/EPDP, other) the relevant issues. Outstanding Items - New Ideas/Concerns/Divergence Root Zone Label General Rules: -- A lot of the rules for the root have erred on the side of being very conservative as they could affect users globally. -- There are 28 scripts identified for RZ-LGR at this time
 of which 18 have completed their proposals. -- There currently a study group from SOs and ACs and Internet Architecture Board (IAB) -- Study on Technical Use of Root Zone Label Generation Rules -- and they have made recommendations for public comment on root LGR: https://www.icann.org/public-comments/technical-rz-lgr-2019-05-15-en -- if a script is not integrated in the root zone LGR then that application should wait, which is slightly different from what is currently recommended. -- Most of the scripts would be done by the next round, except for maybe two or three. -- Should we say that they shouldn’t be able to apply for it, or if they do they have to wait for the LGR to be in place before delegated? Could let them apply and get processed, but not delegated until the LGR are in place. -- There was some discussion around this in the Study Group. It is the GNSO’s call how to decide that. If we don’t allow people to apply they lose the opportunity until the next round. So the suggest from the Study Group is that they apply but are not delegated until the LGR goes into effect. -- Application could be processed, go through contention resolution, objection, but no delegation until the root zone LGR are implemented. -- Status of different scripts: https://www.icann.org/resources/pages/generation-panel-2015-06-21-en for RZ-LGR. -- Would this also be positive in prioritizing the activities that might come about if certain scripts are applied for in more numbers than others. Automation of the RZ-LGR: -- RZ-LGR tool is currently available online: https://www.icann.org/resources/pages/lgr-toolset-2015-06-21-en -- Those cases that allow for script mixing are already accounted for in the RZ-LGR. Pre-Delegation Testing: -- Clarifying: The original recommendation is that pre-delegation testing may not be necessarily as there is compliance with IDNA2008. So, the assumption that something is compliant to IDNA2008 then you don’t need pre-delegation testing is not quite right as compliance itself is not sufficient. There should be steps to address confusability for example. Taking away the pre-delegation testing from this process then how do we determine that those additional requirements for the second level are addressed? -- The comments suggest you shouldn’t have to check if the second level is compliant because that’s the registry’s responsibility. -- One of the concerns to address is end user security and confusability, so the registry is not the only stakeholder. Should the high-level agreement be adjusted (because ALAC and ICANN Org have divergence views): If an applicant is compliant with IDNA2008 (RFCs 5890-5895) or its successor(s) and applicable LGRs for the scripts it intends to support, Pre-Delegation Testing should be unnecessary for the relevant scripts. Allocation of IDN variant TLDs: -- Please see. IDN Variant TLD management recommendations: https://www.icann.org/en/system/files/files/idn-variant-tld-recommendations-... -- Recommendation 7: Same registry service provider for IDN variant TLDs. They can be different, but per this recommendation they have to be the same. -- There should be a recommendation that includes that concept. Bundling of 2nd-level IDN variants: -- Second level variants need to be harmonized under the top-level variants. -- Can variants both be used by the same registrant for different purposes? Recommendation 4 is if you have a label under one TLD variant -- my name then that same label under TLD variants should come to the same registrant. If they are delegated at the second level but then given to the same registrant. SSAC Concerns: -- This part of the SSAC comment seems to speak to the discussion about using the 2nd-level variants for different purposes: “There is no indication that PIR will market the service as causing a pair of names from a bundle to “be the same,” to “act the same,” or other phrases that would cause more significant security and stability issues.
 -- Variants are, by definition, “same” for the script community. -- Preserving user preference. Additional inputs on 1-Unicode character gTLDs: -- SSAC Concerns: variants can be different for different scripts but mean the same thing: For ideographic scripts such as Han, not only can a single character represent a complete “word” or idea, but in some cases different single characters can represent the same “word” or idea. Were ICANN to delegate each such different single character as a TLD label (whether to the same or to a different registrant), users would likely be subject to confusion based on varying deployments of the single character, defined by registry policy.