2022-07-28 IDNs EPDP - Meeting #45

Notes/ Action Items

Action Items

Action Item 1: Leadership team will send proposed revisions to to Recommendation 2.3 under Charter Question B2 [docs.google.com], and Recommendations 2.5 and 2.6 under Charter Question D1b (part 2) [docs.google.com] to the mailing list to give those not on the call an opportunity to review the revised text.

Action Item 2: Staff to consider if rationale for recommendation 2.5 can be further clarified, perhaps by adding “Where the primary label is sought with one or more variant labels at the same time.”

Welcome and Chair Updates

• A number of EPDP Team members are absent today. We will go over several edits, but also give absent members an opportunity to review following the call.
• The EPDP Team had a good conversation with the ccPDP4 Team on Tuesday. The leadership team may look into adopting the “stress test” methodology that the ccPDP4 Team described on Tuesday’s call.

Recommendation 2.3 under Charter Question B2

Proposed revision:

Recommendation 2.3: If the registry operator of an IDN operating a variant gTLD label changes its back-end registry service provider, that IDN gTLD and any additional delegated variant label(s) associated with that gTLD  all the variant gTLD label(s) in the set must also simultaneously transition to the same new back-end registry service provider.  

B2 Draft Rationale for Recommendations and Implementation Guidance:

Rationale for Recommendation 2.2 and Recommendation 2.3: For feasible and consistent implementation of the “same entity” requirement at the top-level, the EPDP Team affirms to extend the SubPro PDP and the Staff Paper recommendations to existing gTLDs and their variant labels. The EPDP Team further recommends that the same back-end registry service provider must operate all delegated variant gTLD label(s) in the set at any given time. If the registry operator operating a variant gTLD label changes its back-end registry service provider, all variant gTLD label(s) in the set must also transition to the same new back-end registry service providerTo that end, the transition to a new back-end registry service provider must apply to the primary gTLD and all of its delegated variant labels at the same time.

• New edits try to capture that the primary the gTLD and variant labels are included in the recommendation.
• The rationale seeks to provide further clarification that the transition applies to both.
• Leadership team notes the email on the mailing list pointing out the potential consequences of the way the working group has been using the term “primary TLD”. Leadership team notes that we will need to clean up terminology to ensure it is consistent and correct and also develop a glossary.

Action Item 1: Leadership team will send proposed revisions to to Recommendation 2.3 under Charter Question B2 [docs.google.com], and Recommendations 2.5 and 2.6 under Charter Question D1b (part 2) [docs.google.com] to the mailing list to give those not on the call an opportunity to review the revised text.

Recommendation 2.5 under Charter Question D1b (part 2)

Proposed revision:

Keep recommendation language for 2.5 as it is and revise rationale.

Rationale for Recommendation 2.5: The EPDP Team noted SubPro PDP’s recommendation that future applications of new gTLDs “must be assessed in rounds”. The EPDP Team agreed that for the next application round and each subsequent round, an applicant who applies for a primary new IDN gTLD and some or all of its allocatable variant label(s) in the same set will only be required to submit one application for the set. This would allow for an efficient and streamlined process.

• Provides context about the SubPro recommendation regarding the use of rounds for subsequent procedures.
• Intent of this recommendation is that instead of submitting multiple applications at the same time, the applicant can submit one application for the label and the allocatable variants they want to activate.
• It is not clear from the text of recommendation that the original application may need a supplemental application if the applicant wants to activate additional variants at a later date.
• Suggestion: Add to rationale that the EPDP Team has not yet addressed when and how a gTLD RO can apply for additional variants.
• The recommendation also seems to imply that every time subsequent applications are submitted the primary also needs to be part of that application, which may not be the intent.
• The discussion of the process for activating subsequent variants for strings that had previously been requested and allocated will be addressed in future discussions of D1b (part 1).

Action Item 2: Staff to consider if rationale can be further clarified, perhaps by adding “Where the primary label is sought with one or more variant labels at the same time.”

Recommendation 2.6 under Charter Question D1b (part 2)

Proposed Revision:

Rationale for Recommendation 2.6: As IDN gTLDs and variant labels that are considered a set are yet to be delegated and operated at the root zone level, there is uncertainty about how the set will be managed and operated by the registry operator from a technical and user perspective. Therefore, it will be important that applicants are able to explain their need for a set of IDN variant label(s) as well as demonstrate their technical capability to operate and manage the set. Therefore, the applicant will be required to respond to additional application questions to address why they seek to activate those variant label(s) in addition to the primary new gTLD (i.e., necessity and expected usage of the variant labels), as well as how it plans to manage the set operationally to achieve the security, stability, and usability goals for IDN variants as well as how it plans to manage the set operationally, with a view to ensuring a secure, stable, and consistent user experience. The applicant’s response to these questions is expected to be a critical component in the evaluation process. Evaluators with requisite expertise are expected to assess these responses.

• Attempts to address RySG concern that registry should not and can not be responsible for ensuring a “consistent user experience” as well as ALAC’s feedback that the user experience is an important element of implementing IDNs.
• The proposed text attempts to provide a compromise that accommodates the concerns expressed by both groups.
• Noting that some RySG and ALAC members are not in attendance, EPDP will wait for additional feedback on the mailing list.