Dear all, Please find below the notes from today’s meeting on Thursday, 10 February 2022 at 13:30 UTC. Kind regards, Ariel, Steve, and Emily Action Items: None Notes – IDNs EPDP Call – 10 February 2022 SOI Updates * Satish Babu’s SOI has been updated to reflect that he is now the ALAC Liaison to the UASG. Welcome & Chair Updates * Reminders: * Staff has sent draft language for charter questions A5 and A6 to the mailing list. Members are encouraged to respond on list, even if they approve of the language. * Some of the charter questions have been re-sequenced, the questions we address today reflect this new order. Charter question B3 * Slide 3 – context on charter question B3. * Comment: It may be useful to consider that the backend registry service provider can be different after some time. * Response: The registry should keep using the same RSP. If a change of owner happens, all variant TLDs should be migrated at the same time, so that it is easier to enforce policies that not only cover the top level but the second level as well. * Comment: It is not necessary to enforce that the same nameservers are used for all in a set if the registry operator and backend service provider are the same. The same rules from the registry can be enforced if those policies are in place. * Comment: In case of a backend change, all variants should change to the same backend at the same time. * Comment: Physically, you will not be able to have the same nameservers without damaging the cloud. Support expressed for not requiring the same nameservers. * Summary: There does not appear to be anything new to add for B3. * General support expressed for the idea that if there is a change in the backend, all variants should change to the same backend at the same time. Some support expressed for including this as implementation guidance. * Suggestion to note that this is a matter of implementation rather than something for the IRT to handle. Charter question D1 * Slide 5 – overview of D1. Charter question D1a * Slide 6 – context on D1a. * Comment: There is nothing wrong with having one agreement where there is a new schedule that covers variants. This is important because there is a relationship between the way the operator manages the TLD and variants and it is too confusing if there are separate agreements. It will be inefficient to have multiple agreements. There could be a special agreement when an IDN is delegated and its variants are delegated. Base terms and conditions will apply, but there are special provisions for the variant relationships that should be in a schedule. * Questions: What do separate agreements entail? Would these agreements be associated with registration fees later? * Response: The RAs are posted on ICANN’s website. We have not yet answered the question about fees. * Comment: It seems logical to have one agreement that includes the variants. * Additional support expressed for having one agreement. The agreement is an important part of mapping the label and the variant labels together. In terms of fees, these would be based on billable transactions under the TLD. These would be generally uniform but dependent on the TLD implementation. * Comment: Creating a new agreement will take a significant amount of time. Annex A is an appropriate place to include provisions relating to variants. * Comment: If we agree that a single contract is appropriate, we can leave it to implementation to determine exactly how the contract is adapted for this purpose. * Comment: Having one agreement for multiple TLDs is common practice in the industry (for example in RRAs), so it should be possible in this context. * Comment: Additional support for keeping all labels in a “bundle” under a single contract because they are closely interlinked. EPDP might want to consider using and defining a term, perhaps “bundle”, to refer to such a group. * Comment: We shouldn’t use marketing terms for a technical concept. Bundling is a marketing term, which doesn’t necessarily refer to variants. Using this term will create confusion. We should use “IDN label and its variants.” * Comment: We need to be clear in terms of terminology – for example, the term is “set” in the staff paper. * Comment: We are currently talking about the agreement itself – rights and obligations of contracted parties – this should be separate from the discussion of fees. * Comment: We are talking about the same entity principle. It seems logical and efficient that the legal agreement comes in a single form with a schedule, exhibit, or annex that provides details about the variant set. These TLDs are supposed to behave as a set. The same entity principle will exist throughout the lifecycle. This can be accounted for in a single agreement. * Question: The RA doesn’t currently call out the registry service provider for an registry operator. If we have a requirement that a set has the same RSP, does this need to be included in the RA? * Question: Should the group have a recommendation or implementation guidance to update the RA in line with this discussion? * Comment: Support expressed for a glossary to define label states discussed in A9 and A10, as well as language related to sets, reserved strings, etc. At the same time, it is important to be clear about the different categories of terms and make sure they are not conflated. * Comment: The only thing we need to say for this charter question is that there should be a single RA for a set. The rest can be handled by org implementation. * Comment: The RA has provisions and requirements for the RSP and there are rules for changing the RSP. It is easy to add to the RA that an registry operator can’t change a material subcontractor for one part of the set without changing it for the rest of the set. * Summary: General agreement that it is appropriate to have one shared RA per variant set. * Comment: A separate process for existing IDN TLDs should be developed. * Comment: We have not had variants before. That was not possible from a policy perspective. The NGO-ONG case was an example of a “bundle.” This could be looked at more closely. Charter question D1b * Slide 7 - context on D1b. * Suggestion: First focus on the process by which an applicant applies for a new IDN gTLD and seeks to obtain allocatable variants. * Comment: We should not think about trying to keep the number of applications low by imposing fees. Each variant label should not be a separate complete application. A registry needs to prove to evaluators that it can manage the set. This should be reflected in the application. ICANN and the evaluators need to be able to look at the big picture and it is not manageable to do this with multiple applications. This issue should be considered apart from the fee question. * Additional support for the idea from a technical and security and stability perspective, the applicant should be able to explain how it will manage the set. If the applicant is applying for multiple strings in a set at the same time, this should be one application. If variants in a set are applied for a different times, then there need to be separate applications. * Further support for one application. For applications that involve IDN variants that need to be activated, there need to be additional application questions to address how the set will be handled operationally. The cost should be covered as a separate discussion. The application process is completed on a cost recovery basis per round. This is an important principle. Some applications are more complicated and some are less complicated, but they pay the same fee. We should make sure that IDN applications are not “second class” or required to pay more. In some cases, the TLD is not complete without variants. The variants are part of the TLD experience. We should not penalize the applicant in these cases. * Comment: If you have a set of variants, it will likely have to go through special panel which is not required in the case of a single application for a single string. If the applicant pays the same fee for the set, it is not fair to other IDN applicants that have to pay for each string separately. * Comment: There are three possible scenarios: 1. The RO is applying for a new gTLD and also a variant 2. The RO already has a gTLD and is applying only for a variant. 3. Other scenarios, for example if an RO is applying for more than one variant TLD at the same time against a given gTLD. Each might call for different sub-processes. * Response: For the purposes of the current discussion, we are only talking about scenario 1. * Summary: Some agreement that from a process perspective, for a new application, there is only one application for the label and its variant set. There is a need for the applicant to explain how it will manage the set. * Next topic: Discussion about process by which an existing RO could apply for or be allocated a variant for its existing gTLD. * Does this need to happen during an application round or can it happen outside of a round? Would there need to be the same requirements to demonstrate the ability to manage the set? * Additional considerations: When a TLD string goes through the application process, it there is an opportunity for community review. There is an objection process, string similarity process, etc. A variant, while administratively bound, is still a string that goes into the root zone. From a technical perspective, it may need to go through many of the same steps and reviews as other strings. Would the applicant need to apply for the potential variants to go through the processes or would there be some type of pre-approval process that could take place? * Response: It makes sense that the evaluations and objections processes be done up front. The entire set of variants need to be considered throughout the process, including from the beginning. * Clarification regarding charter questions: Topic E of the charter discusses string similarity, objection, contention sets, reserved strings, and other details. Question B4 covers the timing and sequence aspect of the application process. Charter question B4 * In initial discussions that touch on the fees issue, there appears to be different perspectives. The group will need to return to this topic.