Given that this is a GNSO sponsored PDP and there are certain preliminary recommendations intended for gTLD registries to implement, the RySG highly recommends making a global change to replace the term “registry operator(s)” to “gTLD registry operator(s)” to avoid confusion as to who is requested to perform the activities. 

SAC060 states only that the maximum number should be as small as possible. Consistent with that, IG 2 recommends that ROs set a maximum and keep that maximum to a minimum. However, in order to ensure interoperability implementors need a minimum value for the number of elements in the variant set that must be supported. A technical standard is beginning development to support these recommendations and it will choose a minimum value. What guidance should be provided for the value to be chosen?

Add a sentence to the end of the Recommendation:

The requirement (of having the same registrant and the same sponsoring registrar) will not be applied retroactively.  gTLD Registries must determine variant sets for each grandfathered label as if it was a source domain name and protect from registration all variant labels in all such variant sets in all variant gTLDs, as appropriate.

Please refer to the comment in Implementation Guidance 2 with regards to replacing “registry operator” with “gTLD registry operator”.

The RySG appreciates that the topic on minimum IDN variant deployment requirements at the second-level was one of the most challenging topics during the Phase 2 work and a lengthy collaborative process between the RySG and ICANN org have resulted in Recommendation 6 and Implementation Guidance 7. The RySG urged that these two items be considered as a pair for next steps, particularly in the call for relevant expertise to undertake the development of minimum IDN variant deployment requirements (i.e., variant sets) at the second-level.

The RySG appreciates that the topic on minimum IDN variant deployment requirements at the second-level was one of the most challenging topics during the Phase 2 work and a lengthy collaborative process between the RySG and ICANN org have resulted in Recommendation 6 and Implementation Guidance 7. The RySG urged that these two items be considered as a pair for next steps, particularly in the call for relevant expertise to undertake the development of minimum IDN variant deployment requirements (i.e., variant sets) at the second-level.

Critical wording changes are needed in the rationale to support the intent of this Recommendation. Without these changes it is not supported.

This Recommendation could be supported with the critical wording changes in the Rationale described below. Without these changes it is not supported.

The RySG could support this Recommendation as written as long as the following operational use case is approved and included in the Rationale. This use case is derived from an understanding of the complete set of Recommendations and documented Rationales in this proposed policy.

Please note this use case requires defining the term “Initial Source Domain Name”, which is included later in this response in the section asking about the Glossary.

The Rationale currently includes the following sentence: 'The EPDP Team came to the conclusion that each allocated variant domain should be allowed to have its own domain name lifecycle, which is independent from that of another allocated variant domain from the same variant domain set.'

Operationally, there are two exceptions to this statement that must be accounted for.

Consider that the policy does not allow for the source domain name to be changed as the source domain name determines the disposition state for each member of the variant set. The operational complexity associated with changing the source domain name would be challenging and the RySG agrees that the value of this is exceeded by the complexity of its implementation. In addition, under the Deactivation bullet the following sentence is included: 'The EPDP Team understood that registry operators would not allow a situation where the change or deactivation of the source domain name, if permitted, renders its allocated variant domain name(s) “blocked” due to compliance requirement of IDN Table implementation.'

Taking everything above into account, this leads to the inescapable conclusion that while each variant domain name can have its own domain name lifecycle, the exception is that the end of “Pending Delete” for a source domain name has a direct impact on all labels in its variant set in the gTLD for which it is the source domain name.

Specifically, when a source domain name reaches the end of its “Pending Delete” and moves once again to being “Available”, at that point in time all variant labels in its variant set in the gTLD in which it is the source domain name must also be deleted and move to being “Available”.

Further, when the Initial Source Domain Name reaches the end of its “Pending Delete”, in addition to all variant labels in its variant set in the gTLD in which it is the source domain being deleted, all other variant labels in all other TLDs in the corresponding gTLD variant set (if appropriate) must also be deleted.

These exceptions must be noted and explained in the Rationale.

For Recommendation 10, 11, and Implementation Guidance 12:

The RySG recommends that rather than recommending a particular change to this policy, the EPDP should recommend that the relevant policy be examined for the need for a possible change in the context of the results of the IDN EPDP. The rationale for this recommendation is that the policy (much like the IDN policy) is complex, nuanced, and the result of detailed negotiations among various stakeholders and providing an outcome when lacking certain relevant context may disturb the balance of the existing policy. The RySG suggests that the IDN EPDP instead follow the example set by the Registration Data Policy EPDP in its Recommendation 27, which suggested the examination of various policies for a "review for impacts" by the Registration Data Policy.

For Recommendation 10, 11, and Implementation Guidance 12:

The RySG recommends that rather than recommending a particular change to this policy, the EPDP should recommend that the relevant policy be examined for the need for a possible change in the context of the results of the IDN EPDP. The rationale for this recommendation is that the policy (much like the IDN policy) is complex, nuanced, and the result of detailed negotiations among various stakeholders and providing an outcome when lacking certain relevant context may disturb the balance of the existing policy. The RySG suggests that the IDN EPDP instead follow the example set by the Registration Data Policy EPDP in its Recommendation 27, which suggested the examination of various policies for a "review for impacts" by the Registration Data Policy.

For Recommendation 10, 11, and Implementation Guidance 12:

The RySG recommends that rather than recommending a particular change to this policy, the EPDP should recommend that the relevant policy be examined for the need for a possible change in the context of the results of the IDN EPDP. The rationale for this recommendation is that the policy (much like the IDN policy) is complex, nuanced, and the result of detailed negotiations among various stakeholders and providing an outcome when lacking certain relevant context may disturb the balance of the existing policy. The RySG suggests that the IDN EPDP instead follow the example set by the Registration Data Policy EPDP in its Recommendation 27, which suggested the examination of various policies for a "review for impacts" by the Registration Data Policy.

The RySG believes that outreach would be helpful given the complexity and nuance of the IDN topic. During the development of such outreach materials, ICANN org should engage with various implementers to seek their input and feedback on the content.

To account for the same entity principle and its implications for variant domain names, ICANN org should work with relevant stakeholders to develop and enable a service to discover the allocated variant domain names for a given domain name, including an indication of the source domain name(s) and initial source domain name of the variant domain set. [deletion] The grandfathered variant domain names pursuant to Preliminary Recommendation 3 are exempt from this requirement.

Rationale:

The RySG agrees both with the need for visibility of a complete variant set when provided with a UDRP or URS disputed domain name (if appropriate) and with the potential operational complexities of providing such a discovery service. The RySG also notes both that visibility of a complete variant set is expected to be available to registrars partners of registries via a method that will be set by registry policy and that registries routinely respond to UDRP and URS requests as appropriate. Thus, the intent of this recommendation will already be available as part of ordinary operation. However, none of this is a public service.

The RySG agrees with the intent of this recommendation but, as worded, this recommendation suggests that a public discovery service is required and the RySG does not agree with that. The rationale does not include any motivation for a public service nor is there any motivation that distinguishes the requested service from current operational requirements. Further, given the potential operational complexities the RySG rejects the mandated requirement but is willing to accept the requirement to work with relevant stakeholders to identify a possible solution.

Implementation Guidance 15 does not appear to add anything that is not already stated in Recommendation 14. Its reference to RDDS seems to be an attempt to propose a solution and that particular solution has two problems. First, RDDS is a simple query-response transaction system with contractually enforced Service Level Agreements that are specific to its expected behaviour. The functionality proposed here is outside that scope of behaviour and would likely require a review of those SLAs. Second, the RDDS is a public service and there is no expected need for this proposed service to be public.

Implementation Guidance 15 should be deleted for these reasons.

The Rationale for Implementation Guidance 15 should have the following two paragraphs deleted:

'As noted in its implementation guidance … the variant domain set.'

'To provide such visibility, … variant domain names in their response.'

Proposed new wording:

In particular, such policies should reflect the implementation of Preliminary Recommendations 1, 3-5, [deletion] and Implementation Guidance 2.

Rationale:

The change is to drop Recommendation 14 from the list of policies to be included in the policy statement. This is necessary to be consistent with our response to Recommendation 14 to change the requirement to be future work development.

Proposed new wording: 

The existing process for developing and updating the IDN Implementation Guidelines, that includes establishing a working group of community experts and ICANN org staff, under the governance of ICANN Board [deletion] must be maintained.

Rationale: 

The process for developing and updating the IDN Implementation Guidelines must be formalized and documented to enhance its predictability, transparency, rigor, efficiency, and effectiveness. The ICANN Board will be responsible for documenting the process, in consultation with the ICANN community.

The ICANN Board IDN-UA Working Group (IDN-UA WG) is not a permanent structure of the ICANN Board and as such the revised wording should sufficiently reflect the intent of the recommendation to have Board oversight on this process. In addition, policy recommendations coming out of the IDN EPDP should not direct what the ccNSO must do with respect to IDN Implementation Guidelines.

With the suggested wording change in Recommendation 18, the RySG do not believe Recommendation 20 is necessary.

The term “Initial Source Domain” needs to be defined. See Recommendation 9 for its usage. The RySG suggests adding a row for the term and the definition should say, “See Source Domain”. Then, in the definition for Source Domain, we suggestion the following paragraph be added at the end: 'The Initial Source Domain Name refers to the first source domain name registered from a variant domain set under any TLD in the gTLD variant label set.'

The EPDP on IDNs is a GNSO sponsored PDP and there are certain preliminary recommendations intended for gTLD registries to implement, the RySG therefore highly recommends making a global change to the report to replace the term “registry operator(s)” to “gTLD registry operator(s)” to avoid confusion as to who is requested to perform the activities.

The Registries Stakeholder Group (RySG) welcomes the opportunity to comment on the Phase 2 Initial Report and provided feedback on the different draft recommendations and implementation guidelines.