Dear Working Group members, Please see below the notes from the meeting on 28 April at 0300 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-04-28+New+gTLD+Subsequent+Pro.... Kind regards, Julie Notes and Action Items: Actions: 2.7.5 Internationalized Domain Names: Recommendation xx (rationale 2): Implementation Guidance xx (Rationale 2): ACTION ITEM: Revise the text to make the changes in brackets and strikeout: “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] but it should not be delegated [and it should be processed up to but not including contracting]. Recommendation xx (Rationale 4): ACTION ITEM: Remove the brackets and check if language is consistent with the recommendations in the IDN Variant TLD Recommendations Analysis Report for the requirement for the back-end registry service provider: https://www.icann.org/en/system/files/files/idn-variant-tld-recommendations-.... 2.7.6 Security and Stability Recommendation xx (Rationale 1): ACTION ITEM: ICANN Org will provide delegation statistics. Implementation Guidance xx (Rationale 1): ACTION ITEM: Replace “Verisign” with “Root Zone Manager”. Notes: 1. Updates to Statements of Interest: No updates provided. 2. Discussion of Final Report Topics: https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om52... a. 2.7.5 Internationalized Domain Names, page 77 Recommendation xx (rationale 2): Compliance with Root Zone Label Generation Rules (RZ-LGR) must be required for the generation of IDN TLDs and variants labels, [including the determination of whether the label is blocked or allocatable]. Discussion: -- Comment From Staff: There is a recommendation in Registry System Testing about whether IDN tables need to be tested during PDT. The relevant recommendation in this section was removed for the time being, so as not to duplicate. The IG from Registry System Testing is: Implementation Guidance xx (rationale 3): The testing of Internationalized Domain Name (IDN) tables should be removed if the applicant is using tables that are pre-vetted by the community. To the extent an applicant is proposing tables that are not pre-vetted by the community, the tables should be reviewed during the evaluation process and the evaluator should utilize IDN tools available at the time of review. ACTION ITEM: Add the bracketed text and drop the brackets. Implementation Guidance xx (Rationale 2): 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] but it should not be delegated. Discussion: -- Should not go to contracting until the RZ-LGR for that script are integrated. -- Are we giving applicants sufficient warning that contracting may be held up subject to RZ-LGR? -- Could take it all the way up until contracting. -- Make sure this is consistent with the Registry System Testing section. ACTION ITEM: Revise the text to make the changes in brackets and strikeout: “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] but it should not be delegated [and it should be processed up to but not including contracting]. Recommendation xx (Rationale 4): IDN gTLDs deemed to be variants of already existing or applied for TLDs will be allowed provided they have the same registry operator [and back-end registry service provider,] implementing by force of written agreement a policy of cross-variant TLD bundling. Discussion: -- The same registry operator must be the same for variants of already existing or applied for TLDs. -- Registry SG suggested the bracketed language – requiring the same back-end operator. -- Do we need to be this prescriptive? -- In the recommendations on IDN Variant TLDs passed by the Board last year it does address this point – specifically the same back-end operator if applicable: https://www.icann.org/en/system/files/files/idn-variant-tld-recommendations-... ACTION ITEM: Remove the brackets and check if language is consistent with the recommendations in the IDN Variant TLD Recommendations Analysis Report for the requirement for the back-end registry service provider: https://www.icann.org/en/system/files/files/idn-variant-tld-recommendations-.... Recommendation xx (Rationale 5): A given second-level label under any allocated IDN variant TLD must only be allocated to the same entity/registrant, or else withheld for possible allocation only to that entity (e.g., s1 under {t1, t1v1, …}, e.g., s1.t1 and s1.t1v1). Recommendation xx (Rationale 5): For second-level IDN variant labels that arise from a registration based on a second-level IDN table, all allocatable IDN variant labels in the set must only be allocated to the same entity or withheld for possible allocation only to that entity (e.g., all allocatable second-level labels {s1, s1v1, …} under all allocated variant TLD labels {t1, t1v1, …}). Discussion: -- Question: Wonder how we link contractually two or three contracts are independent now. It might cause issues later, for example, there are three IDN variant TLDs and a registry decides to terminate one of those because of no registration – is a registry not allowed to take down one of the variants? Contracts should be able to be separated. Answer: Don’t think it is an insurmountable problem. In the case of IDN variant TLDs there isn’t a reason that you could have a new specification about how you handle multiple variant TLDs – you could have one contract but have provisions that would only relate to registry operators that operate multiple variant TLDs. Not sure we should be prescriptive for how they should do that. -- That's possibly something that the RO could specify in the RSEP request to stop variant X from being offered to new registrations. -- The variants do not all have to be active - however, if TLDs are delegated as variant labels based on the LGR, their status as variants would not change. -- Question: Might we need another Implementation Guidance regarding another RA Specification for IDNs? Answer: We don’t need to be so prescriptive here. -- In terms of the contract and retiring of variant TLDs – might need one contract for both or contracts tied together. If a registry wants to retire a variant TLD it won’t be possible for another registry to pick it up. -- Since ICANN can’t look at content the registrant can – they could be in two completely different web sites (traditional and simplified Chinese for example). Out of our control. -- Question: Do we need a recommendation relating to URS and UDRP? Answer: Don’t know if we know enough about that issue to make any recommendations. Might refer to the RPMs PDP WG Phase 2. -- UDRP is meant to address a large share of trademark issues, but there is always the possibility of only a court being able to settle a dispute. As long as UDRP keeps working for a near totality, it doesn't have to deal with all possible cases. b. 2.7.6 Security and Stability, page 80 Recommendation xx (Rationale 1): ICANN must honor and review the principle of conservatism when adding new gTLDs to the root zone. Recommendation xx (Rationale 1): ICANN must focus on the rate of change for the root zone over smaller periods of time (e.g., monthly) rather than the total number of delegated strings for a given calendar year. Discussion: -- There was no basis for 1000 delegations. -- the 1000 per year came from an ICANN operational assessment, which then served as the basis for security and stability considerations. -- ICANN Org has presented the data on number and rate of delegations. -- Looking at contracts only it looks like we had around 500 delegations per year. ACTION ITEM: ICANN Org will provide delegation statistics. Implementation Guidance xx (Rationale 1): The Office of the Chief Technology Officer (OCTO) should consult with PTI, Verisign, the root operators via RSSAC, and the larger DNS technical community on the implementation of these recommendations. Discussion: -- In this one, we should replace Verisign with Root Zone Manager. It's currently Verisign, but we don't know whether this will change or not. Should be the role and not the organization. ACTION ITEM: Replace “Verisign” with “Root Zone Manager”.