Dear Working Group members, Please see below the notes from the WG meeting on 10 December at 03:00 UTC. 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/2020-12-10+New+gTLD+Subsequent+Pro.... Kind regards, Julie == Notes and Action Items: Action Items: Topic 21.1: Geographic Names<https://docs.google.com/spreadsheets/d/1YJJDm9mdmSssXav1P08Uhw6Ofyp0KtfTX8QS...> Row 11 -- dotBERLIN GmbH & Co. KG and Hamburg Top-Level-Domain GmbH, this statement was also included as "new information" by the GeoTLD Group re: Reiterates proposals and position discussed in WT5; Always require letters for Non-Capital City Names ACTION ITEM: Refer to the EPDP on IDNs. Topic 4: Different TLD Types<https://docs.google.com/spreadsheets/d/11HrbnRk2Sf5FvdOuynJyXfkLrzQAD1jkYpRy...> Row 17 – ICANN Org 2. Note the change of language between IDN Variant and Variant TLD. Agree we should change the term when applying at the TLD level. ACTION ITEM: Note the use of terms and make sure they are consistent. Notes: 1. Updates to Statements of Interest: None provided. 2. Review draft Final Report Public Comments – to prepare see the links to the Public Comment Review Tool on the wiki at: https://community.icann.org/display/NGSPP/h.+Published+Draft+reports and review the following topics and comments: -- Goal is to start the Consensus Call on 23 December and end it on Tuesday, 05 January 2021. -- Co-Chairs to post consensus designations on 06 December and to ask for responses by 08 January along with any minority statements. -- WG members should start to prepare minority statements as soon as possible. -- Deliver everything to the Council by the motion and document deadline by 11 January 2021. -- Consideration should be given to packaging the recommendations and that should be communicated well ahead of time. -- The guidelines for the Consensus Call and designations will be sent out in an email. Topic 21: Reserved Names<https://docs.google.com/spreadsheets/d/1YJJDm9mdmSssXav1P08Uhw6Ofyp0KtfTX8QS...> Row 10 -- Thomas Barrett (Individual) re: Define process for unreserving a reserved string. Leadership Comments: WG to discuss guideline on principles (perhaps) but process to IRT Jeff: I think this relates to names at the second level and was discussed initially within WT 2 (I think) - So, it should just be noted. Row 11 – ARTICLE 19 re: Concerns about freedom of expression. Leadership Comments: CLO: Discussed and reservation IS the exception IMO. Jeff: Correct, and most names currently reserved are IGOs which is separate PDP. Row 16 -- Internet Architecture Board Leadership Comments: We should propose referencing in the rationale SAC113 on the Private Use TLD proposal, but I am not sure we are in a position to affirm. Row 17 – WIPO Leadership Comments: Noted - This should be referred to RPM PDP Phase 2. Row 19 – ICANN Org re: “Has the PDP WG considered the inclusion of a process by which words on the reserved names listed in the 2012 round could be released to the related organization to operate as a registry (for example, the string ‘IETF’ released to the Internet Engineering Task Force)?” Leadership Comments: WT did discuss this with the geographic terms and WG agreed that any such process for the release of those should be a separate effort. Discussion: -- Maybe think about the two-characters – there is language in the registry agreement to allowing for two letters at the second level. Maybe language that gives ICANN Org discretion. -- Is it really that names are being reserved for a particular entity or because of confusion with that entity. May need to be resolved by a separate PDP. Row 20 – SSAC members re: Call with SSAC Working Party members on 19 October 2020 (https://gnso.icann.org/sites/default/files/policy/2020/transcript/transcript...): - Two character letter digit combinations should not be allowed. - Notes SAC113. Leadership Comments: There was a lot of discussion on this in WT2, also in WT5. The WG did not recommend character-letter. Topic 21.1: Geographic Names<https://docs.google.com/spreadsheets/d/1YJJDm9mdmSssXav1P08Uhw6Ofyp0KtfTX8QS...> Row 10 -- Swiss Government OFCOM re: Reiterates proposals and position discussed in WT5; Notification Tool Leadership Comments: Noted. Let’s check the "notifications" we have with other sections and perhaps add an ability to receive notifications for any applications that indicate they are a geoTLD. WG to consider new Implementation Guidance to publish or notify everyone that these applications are geographic, or are of which type of string. Isn't this already in the application status? The difference is that this would be an outward push. Discussion: -- We talked about this for a long while in WT5. It always begs the question which is notified by who and also how that who decides what should be notified. I don't think we should be second guessing this at this late stage. -- It only seems to be workable if it is an 'opt in' notification. -- More useful to have notification system for public comments on individual applications rather than having to monitor the individual application page. -- It will be difficult to find a system that works completely. -- At best this is a "nice to have". Let's focus on critical things. -- The problem is building a system to do what can be done just by reading the source material available to all. -- Also, there is nothing keeping ICANN Org from doing this voluntarily of their own free will. I don't think we should codify this in the report in any way. -- Doesn’t need to be policy. Row 11 -- dotBERLIN GmbH & Co. KG and Hamburg Top-Level-Domain GmbH, this statement was also included as "new information" by the GeoTLD Group re: Reiterates proposals and position discussed in WT5; Always require letters for Non-Capital City Names Leadership Comments: (E) Noted 1. Noted as this was discussed in Work Track 5 and not supported to go forward. 3. Non-Capital City - Noted as this was discussed in Work Track 5 and not supported to go forward. Discussion: -- Could the substance fall under the scope of the EPDP on IDN Variants? -- Forward to the EPDP on IDNs. ACTION ITEM: Refer to the EPDP on IDNs. Row 19 -- Xiaodong Lee (Individual) re: Reduce/waive charges for city Name TLDs. Leadership Comments: Noted. This service would have to go through an RSEP (Or initial RSTEP during APPLICATION). Row 20 – ALAC and Row 21 – GAC re: Develop and implement a Notification Tool: no limiting criteria, opt-in basis; or limited to GAC members. Leadership Comments: 1. Open notification tool - See above 2. The GAC can always work with their ICANN support staff to have such a tool regardless of whether we recommend this or not as official policy. Row 22 – ICANN Org re: Clarify if reserved names with variant labels according to the RZ-LGR will also be reserved; provide guidance relating to "relevant governments or public authorities". Leadership Comments: Variant issue should be with reserved names section. This should be looked at by ePDP IDN group. Topic 4: Different TLD Types<https://docs.google.com/spreadsheets/d/11HrbnRk2Sf5FvdOuynJyXfkLrzQAD1jkYpRy...> Row 11 -- National Association of Boards of Pharmacy (NABP) re: Must be able to change application to Category 1 if string is found to be in that category. Leadership Comments: There would be status in the portal/look up website, which would change based on the evaluation Row 17 – ICANN Org Leadership Comments: 1. Let’s display the Table during the call as it could provide a good visual guide. 2. Note the change of language between IDN Variant and Variant TLD. Agree we should change the term when applying at the TLD level. ACTION ITEM: Note the use of terms and make sure they are consistent. 3. Geographic Names are both an application type and a string type. The application type means those applications that apply for a geographic TLD with the intent to use it as a geographic TLD (For the ones of course not reserved). Those must have support, etc. A string, however, can be geographic (when used in one context), but the application is not for a geographic TLD (in the sense it is not being used in its geographic capacity) and therefore may not need support. This is more of a semantic distinction as opposed to having 2 "categories of TLDs 4. "Exceptional Circumstances" is hard to predict in advance. But in theory it is possible for someone to propose adding a TLD that is to be used with IoT. It may have no "registrants" in the sense we normally thing of them, but rather may have registered "devices". If that were the case, then that applicant could propose eliminating some of the contractual provisions, or other requirements that don’t make sense to apply to them. This in theory could result in the creation of a new category of TLDs. We have no idea if anyone would ever apply for something like that, but we do believe some flexibility should be in place. Refer to the general principles of encouraging innovation and competition. Stating that while the WG is clear that they don't support creating new categories for the sake of doing so, but there should be some flexibility for new types. Exceptional circumstances should be dealt with in a transparent manner in a case-by-case basis per the predictability framework. Discussion: -- Important for ICANN Org to be responsive to innovation and change. -- ICANN Org doesn’t have to do this alone.