Dear Working Group members, Please see below the notes from the working sessions on 17 November 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-11-17+New+gTLD+Subsequent+Pro.... Kind regards, Julie == Notes and Action Items: Action Items: Topic 41: Contractual Compliance<https://docs.google.com/spreadsheets/d/1PglquKDd8amHiqI6Wfko0Plb80RPpbEjTMS_...> Row 13 – ALAC re: Compliance should publish thresholds and guidelines to assess registry/registrar practices. ACTION ITEM: Rec 41.2 – Adding text on the information we are seeking. Staff will consult with leadership on the new wording. Topic 37: Registrar Non-Discrimination / Registry/Registrar Standardization<https://docs.google.com/spreadsheets/d/1mkfwWZtyGAOdIbN3LsgNtDnVs6ehPmgrONzl...> Row 17 – RrSG re: Exempted registries must demonstrate unsuccessful outreach to registrars. ACTION ITEM: Rewrite the recommendation to provide clarity about this recommendation on the impact of .brands. Topic 25: IDNs<https://docs.google.com/spreadsheets/d/1YJJDm9mdmSssXav1P08Uhw6Ofyp0KtfTX8QS...> Row 11 – RySG re: Warn applicant if risk of string never being delegated; consider related work in progress. ACTION ITEM: Revise the recommendation to include the warning for an applicant that there is a risk of a string never being delegated. Row 14 – ICANN Board re: Don't process applied-for strings in script not integrated in the RZ-LGR; assess impacts on other processes; clarify which IDN tables “pre-vetted by the community” could still be used to remove IDN table testing for the new gTLDs. ACTION ITEM: The WG should work on the list to find middle ground on this issue. ACTION ITEM: Provide a rationale as to why the WG considered the Board’s comments on Recommendations 5 and 6 and didn’t address them. Row 15 – ALAC re: Supports offering IDN variants to registry operator of existing/applied for gTLDs, not separate application; metrics to evaluate promotion/availability of IDNs at top level. ACTION ITEM: Add this as Implementation Guidance. ACTION ITEM: Add a reference in the rationale re: offering IDN variants to registry operator of existing/applied for gTLDs, not separate application. Row 16 – ICANN Org re: various issues ACTION ITEM: Clarify definition of 1-character codes in accordance with ICANN Org's comments and what “single entity” means. ACTION ITEM re: “ICANN org notes that the PDP WG has taken into account the Variant TLD Recommendations, and has also identified areas which do not appear to be directly addressed. ICANN org understands that, following the work of the ​IDN Scoping Team​, the GNSO is considering initiating another policy development effort focused on IDNs to address these areas. Until discussion on these additional topics is complete, some details may be unclear around how to proceed with IDN TLDs and variant labels in subsequent rounds. Thus, moving forward with the next round of TLD applications may have some dependency on the GNSO PDP on IDNs.” -- Take this issue to the WG list on this issue and the status of the IDN EPDP, and circle back with the IDN team in ICANN Org. 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: Topic 41: Contractual Compliance<https://docs.google.com/spreadsheets/d/1PglquKDd8amHiqI6Wfko0Plb80RPpbEjTMS_...> Row 9 -- Swiss Government OFCOM re: Strengthen compliance enforcement with financial penalties; Rec 41.2 insufficient. Leadership Comments: Do we want to introduce sanctions akin to RAA? Row 10 – IPC; Row 11 – INTA and Row 12 – GBOC (also anti-abuse); Row 19 -- BC re: Strengthen compliance Leadership Comments: Noted. Also related to DNS abuse provisions. Row 13 – ALAC re: Compliance should publish thresholds and guidelines to assess registry/registrar practices. Leadership Comments: Do we want to introduce more transparency into actions taken (and measurements used) for compliance actions that do not result in breach? Discussion: -- Usually these types of comments are closed. Contracted parties wouldn’t want this disclosed. -- Possible action to withhold the name of the entity. -- No clear indication of the thresholds to assess. -- Ask for what is it that ICANN Org is using to assess undesirable behavior by the contracted parties. -- We could add a few words that including the threshold…so long it is not publishing information about the registry operator. -- Question: Are we talking about setting up two compliance programs? We can’t reach backward. Answer: If we added the ALAC action about action, and instead added a few words about what ICANN is already doing then we wouldn’t be making new policy. --- Support introducing standards and thresholds. -- We can address this by adding a few words to the recommendation. ACTION ITEM: Rec 41.2 – Adding text on the information we are seeking. Staff will consult with leadership on the new wording. Row 17 – ICANN Board re: Recommended data is already being published. Leadership Comments: We believe Compliance Dashboard covers our recommendations sufficiently. Row 18 – ICANN Org re: WG should provide specific examples of data to be published and/or examples. Leadership Comment: ICANN Org asks why we believe this is only relevant for next rounds of new gtLDs? Response: We are not saying it is only relevant for the next rounds, but it is outside our scope to recommend anything with respect to legacy TLDs. Topic 37: Registrar Non-Discrimination / Registry/Registrar Standardization<https://docs.google.com/spreadsheets/d/1mkfwWZtyGAOdIbN3LsgNtDnVs6ehPmgrONzl...> Row 10 – BRG re: Supports exemption for .Brand TLD/include in Spec 13. Leadership Comments: Do we grant additional extensions (namely, not having to use a registrar at all)? This was discussed within Work Track, but not carried forward. Row 13 – ICANN Org re: No registrar application in New gTLD application; keep process separate and Row 21 InfoNetworks LLC re: Consider a consolidated Registry/Registrar Agreement. Leadership Comments: Do we want to revisit the notion of allowing both accreditations in same TLD application? Discussion: -- Did not have support in the WG to elevate this to a recommendation. Row 17 – RrSG re: Exempted registries must demonstrate unsuccessful outreach to registrars. Leadership Comments: Do we want to add this clarification (eg., true demonstration of outreach and then if policies change, a re-evaluation of exemption is needed). Discussion: -- Seems to add more clarity to an existing recommendation. -- Don’t see strong support for the exemption. Concern that ICANN’s role is to make the TLDs available, it’s up to the registries to make them successful. -- Comments were lukewarm. -- Goes back to what the BRG said. -- With .brands, we have never proposed getting rid of the exemption for Spec 13. Not sure that this question that was out for community input would affect .brands. -- The action item here is to provide clarification of the impact on .brands from this recommendation. ACTION ITEM: Rewrite the recommendation to provide clarity about this recommendation on the impact of .brands. Topic 38: Registrar Support for New TLDs<https://docs.google.com/spreadsheets/d/1mkfwWZtyGAOdIbN3LsgNtDnVs6ehPmgrONzl...> Row 10 – InfoNetworks LLC re: Registrars without an RAA shouldn't be able to object to proposed RAA amendments. Leadership Comments: New idea: Limit Registrars review of RRA Amendments to only those Registrars that have signed the RRA, (Include with Base Agreement discussion). Probably just affect existing TLDs and not new TLDs. Topic 25: IDNs<https://docs.google.com/spreadsheets/d/1YJJDm9mdmSssXav1P08Uhw6Ofyp0KtfTX8QS...> Row 8 – Anthony Lee and other comments re: Continue to develop a mechanism that also takes the concerns of both the SSAC and Joint ccNSO-GNSO IDN Workgroup reports into consideration. Overarching Leadership Comment: Consider referring all of our recommendations to the GNSO IDN Scoping Team for including in their PDP. Row 9 -- Wei Wang (Individual) re: Waiving application fees of IDN gTLD variant and existing/applied IDN gTLD with same registry operator. Leadership Comments: Noted. Row 10 – IAB Leadership Comments: Noted. Row 11 – RySG re: Warn applicant if risk of string never being delegated; consider related work in progress. Leadership Comments: Warning sounds like a good clarification recommendation; See above on referring all recommendations to IDN Groups to consider. ACTION ITEM: Revise the recommendation to include the warning for an applicant that there is a risk of a string never being delegated. Row 12 – WIPO re: Domain abuse by homograph spoofing. Leadership Comments: This is an issue for IDN Group, RPM PDP and future DNS Abuse efforts. Row 12 – RrSG re: Vet IDN tables/variants prior to delegation, not outright rejection. Leadership Comments: Could this be part of the RSP Pre-approval process? -- We don’t talk about the tables being rejected. Row 14 – ICANN Board re: Don't process applied-for strings in script not integrated in the RZ-LGR; assess impacts on other processes; clarify which IDN tables “pre-vetted by the community” could still be used to remove IDN table testing for the new gTLDs. Leadership Comments: -- Review Recommendations 5 and 6 of Variant TLD Recommendations? The Board asks the PDP WG to clarify which IDN tables “pre-vetted by the community” could still be used to remove IDN table testing for the new gTLDs. The Board suggests that the PDP WG considers Reference IDN tables being published by ICANN org as the candidate pre-vetted IDN tables. (Pg. 178) ACTION ITEM: The WG should work on the list to find middle ground on this issue. ACTION ITEM: Provide a rationale as to why the WG considered the Board’s comments on Recommendations 5 and 6 and didn’t address them. Discussion: -- Board suggestion is different from the WG’s recommendation. -- Not sure how realistic the Board suggestion is. -- Would be difficult to do the evaluation if the RZL isn’t part of the rules. -- We discussed this at some length didn't we? I understand ICANN Board's desire for efficiency, but weren't we balancing out others who may be caught up in contention sets or want to file objections? -- The idea of having the RZ generation rules was that you could have a situation where you were using the rules is that you needed to have some rules for those that weren’t in the RZ generation rules. -- Is there a way to do both? The applicant would be entering contention at its own risk. It should be able to go through a number of steps until the RZ generation rules are finalized. -- For a string in a script that is not part of the RZ-LGR, there is no guarantee it will ever be valid. ACTION ITEM: The WG should work on the list to find middle ground on this issue. Row 15 – ALAC re: Supports offering IDN variants to registry operator of existing/applied for gTLDs, not separate application; metrics to evaluate promotion/availability of IDNs at top level. Leadership Comments: Noted. Discussion: -- Question: What does it mean: “and the corresponding level of assignment of ICANN staff support and evaluators”? This seems like an IRT issue. This will be noted by IRT. -- To be a meaningful measure then staff commitment comparison to other non IDNs need to be looked at as well NEW and yes Implementation. -- Question: Will this go to the IRT? ACTION ITEM: Add this as Implementation Guidance. ACTION ITEM: Add a reference in the rationale re: offering IDN variants to registry operator of existing/applied for gTLDs, not separate application. Row 16 – ICANN Org re: various issues Leadership Comments: -- Does the Working Group want to specify that unless and until new IDN rules are finalized, that it not hold up subsequent rounds, which will apply existing rules (eg., not allow variants). -- In the same token, should this group formally refer issues of "(a) the process by which an existing registry operator could apply for, or be given, an IDN variant for its existing gTLD; and (b) the process by which an applicant applying for a new IDN gTLD could seek and obtain any allocatable IDN variant(s) ICANN Org does not believe any string should be processed if the Label Generation Rules for that script are not integrated into the RZ-LGR; AND that these applications should not hold up other ones that are integrated. -- Clarify definition of 1 character codes in accordance with ICANN Org comments. Clarify what Single entity means. ACTION ITEM: Clarify definition of 1-character codes in accordance with ICANN Org's comments and what “single entity” means. ACTION ITEM re: “ICANN org notes that the PDP WG has taken into account the Variant TLD Recommendations, and has also identified areas which do not appear to be directly addressed. ICANN org understands that, following the work of the ​IDN Scoping Team​, the GNSO is considering initiating another policy development effort focused on IDNs to address these areas. Until discussion on these additional topics is complete, some details may be unclear around how to proceed with IDN TLDs and variant labels in subsequent rounds. Thus, moving forward with the next round of TLD applications may have some dependency on the GNSO PDP on IDNs.” -- Take this issue to the WG list on this issue and the status of the IDN EPDP, and circle back with the IDN team in ICANN Org.