2023-06-13 ICANN77 Session 2 IDNs EPDP

Draft Agenda

1. Roll Call and SOI Updates 
2. Welcome and Chair Updates 
3. Continued deliberation on D4, C4a, D6, D7: Variant Label Behavior in Domain Name Lifecycle
4. AOB 
5. EPDP-IDNs Team Social (last 30 minutes)

Slides: ICANN77 EPDP Team Working Sessions - D4, C4a, D6, D7.pdf

Notes:

Welcome and Chair Updates

• Intent is to pick up discussions on domain name life cycle following the tutorial during the last meeting.
• There has been a lot of chatter about the timeline. There is concern that because November 2025 is the due date for the Final Report, it will hold up the next round. There may be a messaging problem here. What have others heard? There seems to be the interpretation that our timeline is on the critical path, and potentially a blockage for the next round. If that is the case, there is probably a disconnect in messaging. The EPDP Team undertook a detailed analysis per the Board request. Phase 1 should be wrapped up by the end of the year, but what is being done on the second level may not be on the critical path?
• Team is already working to the max - cannot push more, but the team will try to do as much as possible, including F2F meeting. The goal is definitely to get things done before November 2025. Whatever messaging that is carried back to Council should be socialized first with the EPDP Team.
• May need to look closer at the actual dependencies for the next round? Team is looking at existing TLDs so there may already be efficiencies that can be worked on.
• Agreement that this is a very difficult topic that needs time to resolve.
• Why would current work prevent the next round from starting? Could further explanation be provided that even if the EPDP Team would go up to November 2025, what would the impact be or why it would prevent launch of next round? Have not seen project plan yet from ICANN. Everyone may be jumping the gun.
• This EPDP was never on the critical path until the KL meeting - first time that ICANN identified this work as being on the critical path.
• The timeline includes a lot of wiggle room that has been built in - could also be included in messaging.
• On phase 1 public comment, can input be expected from ICANN org? Yes, is in final stages and not expected to be anything controversial.
• From ALAC side comment is also expected to be light.

 

Continued deliberation on D4, C4a, D6, D7: Variant Label Behavior in Domain Name Lifecycle

• What D4 is asking: Regarding second-level domain names, should a variant set behave as one unit, i.e., the behavior of one domain name is replicated across the other variant domain names? Or should each variant domain name have its own independent domain name life cycle? Consider the operational and legal impact of the “same entity” principle, if any, to all aspects of a domain name lifecycle.

 Discussion questions: 1. How is a variant label set determined for the second-level variant domains?

• Variant at the second level should be the same as at the top level - need a primary to distinguish between blocked and allocatable variants. Apart from that, IDN table LGR is responsible to define the variant set, like the LGRs at the top level.
• Registries may use certain approaches internally. Would rather not use language - not intention to prescribe how to label, should be left for registries to define. Variant is allocated to same entity and from there Ry can manage.
• Aim to level set because to get through these questions, the group needs to agree how a variant label set is determined at the second level? It is about getting a common understanding of how it works. How to categorize when putting into policy language.
• Meaning of “variant label set” at top-level:
  • The set of labels that is calculated by the RZ-LGR using the primary label. The variant label set consists of: primary label + allocatable variant label(s) + blocked variant label(s).
  • In the context of future new gTLD applications, a primary label is identified by the applicant as the main applied-for label that acts as a source against which variant labels and disposition values are calculated using the RZ-LGR
  • For existing gTLD registry operators who apply for variant labels, their existing gTLDs will automatically become the primary label
• How is the variant set going to be determined at the second level - that is the key question.
• One point that we need to remember is that when talking about the second level, we are not only talking about a variant label set but also about a variant domain set. At the second level, there are two labels - it is a combination of the label at the top level and the one at the second level. The Ry will define what the variant labels of the second level will be, and the combination with the label at the top level will form the variant domain set which the registrant will use to register the domain. Need to consider both as we are considering the behavior of a domain.
• We should use different terms for the different levels to avoid confusion.
• Whatever is determinant for the label at the primary, should be controlling for the second level - could that be an approach?
• Whatever the Ry calls the set, is in the best interest of the integrity of the Ry operations. No need for this group to focus on. Question should be how we want the variant set to behave, including top-level. Need to think with the end in mind, the lifecycle, and how this interaction between the entity and the label set is expected to be reflected.
• Same entity constraint should continue to apply. What happens to the set if one is not renewed?
• What simple language can be used so that the end-user understands?
• Whatever is in the rootzone LGR is not necessarily the same in the IDN Table. LGR sets variants at the top level. IDN tables are set by Registries.
• What is the label set at the second level and who sets it? Need to answer that and then go through the life cycle.
• Determining the variants at the second level may be difficult. Is it within scope for the group to change what is in the IDN Table? Would it be possible to have a unified IDN Table, is that within scope? Response: No - responsibility for IDN tables is with Registries and that should not be changed, but there is a need for harmonization which is what is being recommended by the EPDP Team.
• Need to address whose responsibility it is to determine what is the primary label? It is the registrant who comes to the registrar to register a domain name. If it is part of a variant set, it will have consequences.
• Second level it is the registrant who will register the domain name who will determine the variant set. The consequence of whether that set needs to remain together during the domain name life cycle needs to be answered next.
• Question: 2. What does“behaving as one unit” mean in the context of lifecycle management of variant domains? Are there parallels with the “integrity of the set” principle at the top-level? See slide 21 for the meaning of integrity of the set at top-level and how this is reflected in the phase 1 Initial Report.
• What may be good to clarify (for Same registry service provider for each Critical Function) is that some may get confused and think that it means that inside a variant label set, the same company or the same entity needs to have the allocated name server, but it is not what it means. The critical function or the authoritative nameserver that hosts the domain. May need to have a footnote to help understand that you are not requiring the registrar to provision the same nameserver for all the variants in the set, but they need to be hosted across the same Ry nameserver infrastructure.
• Preliminary Recommendation 7.7: The registry service provider for each one of the Critical Functions as defined in the Base Registry Agreement for an existing IDN gTLD from the 2012 round must be the same as for its delegated variant labels. The Critical Functions are: DNS Service, DNSSEC proper resolution, EPP, RDDS, and Data Escrow.
• 1) Should a primary label be identified for variant domain registration? Primary domain is determined by the registrant by registering a domain name.
• 2) Can a registrant register any allocatable second-level label from the variant label set at any time? Would this need to happen at the time of original registration or can this be done at different times? Need to factor in that at different times would also have different expiration dates.
• This should be left to the Ry and the policy that they want to make. Shouldn’t be for the EPDP Team to make rules about this.
• What is the current practice? Some just withhold the variants. May be good to understand.
• This question should be read in the context of if the Registry allows the registration of variant labels at the second level, as there may be policies in place that do not allow this.
• At CREATE the same entity applies. EPP CREATE can happen at any time per registry policy.
• If it is discretionary on the Ry, what is the consequence of focusing on the impact throughout the life cycle of the variant set?
• The life cycle is up to the Ry. Important reason to not prescribe is it will lead to creation of new EPP extensions which will create a lot of work. Maybe transfer should be done for old variants, but otherwise no need to spend time here.
• The only restriction to make is that the same entity principle is adhered to all the time during the lifecycle for all the variants with the variant set. Should not make any policies when a variant can be added or removed or how they should behave.
• Don’t need to make policy because by maintaining the same entity principle it just works and it is not necessary to create other rules.
• Only time it becomes relevant is if some part of the set would change hands but as long as the same entity principle is maintained, it shouldn’t be an issue.
• IDN guidelines (that were paused) included that in some cases for some communities there might be automatic activation, not only at the request of the registrant.
• Will the same entity rule cover that the primary name needs to be registered first? Is a separate recommendation needed for that? Once you register that becomes the primary. As long as the set is kept together, it is for the Ry to determine if others can be registered or not. Is at the discretion of the registrar.
• How to address inherited situation whereby multiple entities have variants from the same set? Would be grandfathered, but no further registrations in that variant set.
• If there are variants registered with multiple registrants, then there is no primary.
• See slide 22 - State 2 active questions. Question 1) No but is decided by Ry policy. 2) Maybe specify something here? Need to be really careful here - need to focus on same entity principle. Would need to specify where it is updated - Ry or Rr. Should restrict that after the update the same principle must still be upheld. How this is done is out of scope. 3) Yes, if one goes all go. Need to consider whether a separate rec is needed or whether the same entity covers that? This is the implication of the same entity principle. Could list in the same entity principles what this implies and include this. How would one validate that it is the same entity? Not possible to validate across registrar boundaries. 4)