Page History

Notes/ Action Items

Action Item 1: In recommendation 1.5, change “user” to “registrant” and add bracketed text [consistent] [predictable] as possible alternatives to [positive].

Action Item 2: For recommendation 2.2 - GDS team to come back to the group with clarification about its recommendation regarding “critical functions” in this text.

Action Item 3: In recommendation 2.2, clarify language to state that whichever service provider provides for a function, that same provider should be used for both existing TLD and newly delegated variants.

Action Item 4: Leadership team to refine Implementation Guidance 2.xx to make it consistent with Recommendation 2.6, clarifying that this question is not scored. 

Action Item 5: Replace “sanctity of the set” with “integrity of the set” in Rationale for Recommendations 2.16-2.18 and throughout the document.

Action Item 6: Consolidate text of 2.16-2.18 to focus on the fact that any breach of the contract in any label removes the whole set.

Action Item 7: Leadership team to draft new recommendations on base application fee based on today’s discussion (23 March 2023) and refine draft recommendation 2.24, 2.25, 2.26, and 2.27.

Action Item 8: Leadership Team to revise draft recommendation 2.25 to reference a reduced fee based on a cost recovery basis for variants applied for beyond the set number that are included without additional costs with the primary.

Welcome and Chair Updates

• The EPDP Team will meet twice a week for the next two weeks to get through the upcoming workload.

Second Reading of Draft Text

Charter Question A5: https://docs.google.com/document/d/1Bt0LT45UaLynFNverh1nJhyvq6q6NxgSFAOnOp2LG44/edit

• Current text of Recommendation 1.5: “A framework for developing best practice guidelines in the management of gTLDs and their variant labels by registries and registrars must be formulated with a view to encourage a positive user experience.”
• In last week’s discussion, concerns were expressed about the use of the term “positive user experience.”

Discussion points:

• ROs and registrars do not influence end user experience. That will depend on the usage of the domain.
• In all agreements, from the user perspective, the only party is mentioned is the registrant. It is more logical to refer to the registrant in this text.
• Support expressed for substituting “registrant” for “user.”
• It was noted that the term “positive” is subjective. Predictable and consistent are possible alternatives.
• It was noted that a registrant experience could be consistently negative, so in this regard, positive might be preferable for those advocating for a good user experience.

Action Item 1: In recommendation 1.5, change “user” to “registrant” and add bracketed text [consistent] [predictable] as possible alternatives to [positive].

• Implementation Guidance 1.6: The framework should outline the scope and the steps involved in developing future best practice guidelines, which at a minimum should involve relevant stakeholders, such as registries, registrars, and registrants who have experience with IDNs and variant labels.
• Written comment regarding IG 1.6: “Could the implementation team find a group of registrants that represents the needs of all? given that the variant definition is script-dependent, I'm thinking we would need at least a representative for each script community. An even then, they might have their own biases. Unlike the registries and registrars who have stakeholder groups who can review an opine of ongoing work, there isn't a registrant stakeholder group.”

Discussion points:

• It was noted that that this is implementation guidance, and some details may need to be sorted in implementation.
• It was noted that ALAC, CSG, and NCSG could potentially serve as proxies for registrants.
• Suggestion to add a caveat such as: “registrants, to the extent that is it is possible to find appropriate representatives for this group.”

Charter Question B2: https://docs.google.com/document/d/15YGISgNQYL_VfcVVZ6E97qbo42GPziP6x089bR3wgZw/edit

• Recommendation 2.2: All Critical Functions as defined in the base Registry Agreement for the existing IDN gTLD from the 2012 round and its delegated variant labels must be provided by the same registry service provider. The Critical Functions are: DNS Service, DNSSEC proper resolution, EPP, RDDS, and Data Escrow.
• Suggestion to replace existing text with: “A gTLD operator, legacy or new, must use the same registry service provider to provide all Critical Functions to any given variant TLD set.”

Discussion Points:

• There are several TLD services that do not just use the DNS service of the RSP but use multiple service provides to have their DNS published. How would that work in that context if we restrict it to one service provider?
• This text is attempting to capture that the entity that provides the service in the existing gTLD must also provide it in the variant labels.
• The party generating the database of records must be the same. We shouldn’t conflate critical services of the operator and registry services.
• The EPDP Team used “critical functions” in the text because it’s defined in the RA and in our scope.
• If it’s in the RA, why would we try to cover off services not in those functions?

Action Item 2: For recommendation 2.2 - GDS team to come back to the group with clarification about its recommendation regarding “critical functions” in this text.

• Reference to critical functions in the text is unnecessary. If a registry does not follow rules for critical functions, it is in breach. If we say that the registry must use to same registry service provider for primary and variants, we are covered.
• The goal is to say that the registry operator uses the same service provider for critical functions.
• Reminder: Sub Pro recommended that going forward a primary and the variants need to have the same RSP. It doesn’t speak to the case where the primary is already delegated and then variants are requested later. The goal of this recommendation is to fill that gap.

Action Item 3: In recommendation 2.2, clarify language to state that whichever service provider provides for a function, that same provider should be used for both existing TLD and newly delegated variants.

Charter Question B5: https://docs.google.com/document/d/15YGISgNQYL_VfcVVZ6E97qbo42GPziP6x089bR3wgZw/edit

• Editorial suggestions to response to charter question accepted.

Charter Question D1b: https://docs.google.com/document/d/1C6xKX87w2LtN4Is0mehuRgc1GqjKmbbhT14KbvUH5Sw/edit

• Suggested IG provided by ALAC: “Implementation Guidance 2.xx [for recommendation 2.6]: Criteria for evaluating the explanations submitted by applicants on the usability goals for the variant label(s) should be pre-identified and applied consistently by evaluators with the requisite expertise.” Suggested addition to the Rationale: “[The EPDP Team agreed] that Recommendation 2.6 is intended to ensure that the applicants’ usability goals for the variant label(s) sought help contribute to positive end user experiences. For this reason, the criteria for assessing the applicants’ explanations for the variant label(s) sought should be pre-identified and applied consistently by evaluators with the requisite expertise.”

Discussion points:

• ALAC raised concern that there needs to be checks and balances on the number of variants in a set.
• Text regarding “requisite expertise” is not necessary. It cuts off existing ROs of gTLDs from participating, because there are no variants in management. Only ccTLD operators will have experience with variants.
• When ICANN sources evaluators, it will determine the requisite expertise. The IG is just trying to make the point that certain things are important for IDN TLDs and variants and consistent rules need to be applied by evaluators.
• General acceptance for the keeping the proposed text in the draft.
• Recommendation 2.6 focuses on question in the application about why the applicant wants a variant label, which is similar to existing question 18a and 18b in the 2012 application. Recommendation 2.6 is envisioning a similar, unscored question. Is new IG 2.xx envisioning a scored question or just requesting additional detail?

Action Item 4: Leadership team to refine Implementation Guidance 2.xx to make it consistent with Recommendation 2.6, clarifying that this question is not scored.

Charter Question D8: https://docs.google.com/document/d/1C6xKX87w2LtN4Is0mehuRgc1GqjKmbbhT14KbvUH5Sw/edit

• Rationale for Recommendations 2.16-2.18: Suggestion to replace “sanctity of the set” with “integrity of the set” in this instance and throughout the document.

Action Item 5: Replace “sanctity of the set” with “integrity of the set” in Rationale for Recommendations 2.16-2.18 and throughout the document.

• Regarding the following text in the Rationale for Recommendations 2.16-2.18: “Nevertheless, in the event a variant label is removed from the root zone as a consequence of its registry operator’s breach of the Registry Agreement, the primary IDN gTLD and its other delegated variant label(s) must also be removed from the root zone.”
• Comment: “Is this scenario possible? a breach of a registry agreement that triggers removal of a variant label before its primary. If we accept one registry agreement for the set as a principle, then a breach of a registry agreement will affect not just one label in the set but all of it.”

Discussion points:

• The EPDP Team didn’t discuss the probability of this situation, but rather the consequence for the set.
• This text could address the situation where the variant is delegated ahead of the primary.
• Agreement that is ok to keep it for completeness.
• Regarding Recommendation 2.18: “In the event that a variant label is removed from the root zone as a consequence of its registry operator’s breach of the Registry Agreement, the associated delegated primary IDN gTLD and its other delegated variant label(s) must also be removed from the root zone.” Suggestion that this outcome is too extreme if there are no security consequences to leaving the primary in the root.
• This recommendation was drafted with guidance from GDS.
• Reminder: 2.18 is one recommendation in a set that are all related. 2.16 focuses on the case where the primary is removed. 2.17 refers to the case where the delegated variant label is voluntarily removed. 2.18 refers to the case where a variant is involuntarily removed.
• Suggestion to clarify that any breach of the contract for any label removes the whole set. It’s not so much focused on the variant triggering the breach, but the label within a set triggering removal for the whole set.

Action Item 6: Consolidate text of 2.16-2.18 to focus on the fact that any breach of the contract in any label removes the whole set.

Charter Question E5: https://docs.google.com/document/d/1RLvsyQvliafNEA9Ja1RCObywpAWfp1kTmte0WZlyqqs/edit

• Review of new Text in Rationale for Recommendation 3.2-3.3 – new revisions applied to final three paragraphs.

Discussion points:

• “From an implementation perspective, the EPDP Team envisioned that if an applicant enters a variant label of a Reserved Name as its applied-for gTLD string, the application system will recognize the variant label and will reject the application.” The text appears to imply that this is an automated process, but this needs to be a manual check, correct?
• It is likely be part of the algorithmic check, but if we are not sure we can soften the language.
• Algorithmic approach will only be able to find exact matches. Similarity check will not be possible via algorithm.
• This text is talking about an exact match of a variant of a reserved name, which is anticipated to be an automated comparison.

Discussion of variant label application fees applied to existing gTLD registry operators

• Discussion Question: What should the base application fee be when an existing RO applies for variants of an already delegated primary string?
• Agreement from ICANN76 – for future applicant, a single base application fee will apply for the primary and the variants as a set up to a certain number of variants.

Discussion points:

• Possible options:
  • Recommendation to waive the application fee for existing ROs
  • Recommendation that the applicant pay the application fee for the new round
  • Sliding scale fee
• This will only apply to the 44 TLDs from the 2012 round.
• The survey conducted of this 44 is not instructive, but it’s likely that not all 44 will apply for variants in the next round.
• Do we need to make a special case here? Is this different from the case where in subsequent round 1 an applicant applies for a primary and then applies for variants in subsequent round 2 or 3?
• It might make sense to have a single rule for any case where the applicant applies for the primary and variants in different rounds.
• Counterpoint: The 2012 applicants were unable to apply for variants. In the future, it will be possible to apply for primary and variants in the same round.
• Question: If we do have an exception, it would be one-off for existing ROs and in the next round only?
• Suggestion that this would be a special case limited to the next round.
• Perhaps for this case the application for variants should be free of charge to compensate for the period of time that variants are unavailable.
• Suggestion that there is an exception for 2012 gTLD applicants, based on the fact that they paid the standard fee in 2012 and were unable to apply for variants. If they apply for variants in the next subsequent round, the application fee will be waived.
• Some support expressed for this approach.
• Do we also need a policy recommendation for cases where the 2012 applicant for a primary does not apply for variants in the next subsequent round but applies for variants in later subsequent rounds?
• Reminder: In Cancun, the group reached general agreement that there should be a maximum limit to the number of variants that would be included in the single base fee.
• Did this mean that if four variants are “free”, this is limited to a single round, or would it also be “free” if you apply for two variants with the primary and two more in a later round? It would cause a lot of work to spread this across rounds. Perhaps it should be limited to applications including variants within the same round that the applicant applies for the primary.
• Suggestion that if you apply for more variants in a later round, perhaps a discount can apply (percentage of base application fee)?
• Suggestion that we should try to have a mechanism to encourage applicants to apply for minimum number of variants instead of maximum number of variants - to focus on variants “needed”. If signing up for more variants earlier gives a financial reward, people might apply for more variants then are needed.
• The expectation is that the applicant will apply for the primary and the variants in the same round that is optimal for their business needs.
• It’s difficult without a factual evaluation method to determine how many variants is too many.
• As a reminder, only the Arabic GP has not indicated a ceiling number.
• While we don’t want to encourage excessive number of variants, there are real needs to meet for some language communities, therefore it makes sense to have a limited number of variants included in the fee. An additional fee for applications for variants beyond that might meet the goal of applications for excessive number of variants. Ultimately the applicant will still need to demonstrate why it is applying for variants and justify the need.

Suggestion

New Applications:

=================

First application including 0-4 variants: Pay 200,000 USD

First application including 5-8 variants: Pay 220,000 USD.

Follow-up applications:

=======================

Existing TLD with any number of variants. Apply for 0-4 additional variants: Pay 20,000 USD

Existing TLD with any number of variants. Apply for 5-8 additional variants: Pay 40,000 USD

Exemption for 2012 round:

=========================

Apply for 0-4 additional variants: Free, no charge

Apply for 5-6 additional variants: Pay 20,000 USD

• Summary: We are headed to applying a proportion of the base fee if an applicant applies for additional variants in later rounds apart from the primary.

Action Item 7: Leadership team to draft new recommendations on base application fee based on today’s discussion (23 March 2023) and refine draft recommendation 2.24, 2.25, 2.26, and 2.27.

• As a reminder Arabic GP is going to be providing feedback on a reasonable number of variants in the Arabic script.
• Question: for Recommendation 2.25 – how does the group expect the reduced fee to be structured? Current draft text: “Recommendation 2.25: If more than xx of variant labels are being applied-for in the same application, the applicant will be charged, in addition to the base application fee, [20%] of the base application fee to specifically cover the cost of evaluating each of the additional variant label(s) above the threshold number.”
• Suggestion that the policy recommendation should not suggest a formula. The EPDP Team doesn’t regulate costs.
• Rather than having a percentage, note in IG that the intent is that once the evaluation costs are known, ICANN will decide the additional fee.

Action Item 8: Leadership Team to revise draft recommendation 2.25 to reference a reduced fee based on a cost recovery basis for variants applied for beyond the set number that are included without additional costs with the primary.

• Additional redlines are available based on ICANN org feedback that are editorial in nature

Review of recommendations in place, look at sequence and order

• PDF was shared on the mailing list before ICANN76.
• Charter questions are clustered by topic. In developing recommendations, it became clear that a different organization may be more logical for the reader. Suggestion: Order recommendations based on the process flow of the New gTLD Program. Principle-based recommendations are listed first. After the principle-based recommendations, sections follow the flow of the New gTLD Program.
• Document also includes definition of underlying principles.
• Question: Should there be a distinct section focused on an existing RO applying for variants in a future round or should this be included in the overall process flow?

AOB

• Leadership team will confirm tomorrow whether the group will cancel or go ahead with the meeting on Monday.
• Leadership team had a meeting with some Board members at ICANN76. A communication has gone to Council requesting a timeframe from the EPDP on when the team can get the phase 2a charter questions done. These are the ones that have been pushed to phase 2 but have been identified as a dependency for developing the AGB.
• Priority at the moment is to publish the Phase 1 Initial Report.