[Gnso-epdp-idn-team] Notes and action items - IDNs EPDP Meeting #22 - 3 February 2022

Emily Barabas emily.barabas at icann.org
Thu Feb 3 15:39:54 UTC 2022


Dear all,

Please find below the notes from today’s meeting on Thursday, 3 February 2022 at 13:30 UTC.

Kind regards,

Ariel, Steve, and Emily



Action Items:

Action Item #1: Staff to draft a document overlaying definitions with label states in the New gTLD process.

Action Item #2: Dennis to respond on the mailing list about the status/outcome of the ccPDP discussion related to charter questions A9 and A10.

Action Item #3: Leadership team to develop text for charter questions B1 and B2 in support of extending SubPro and Staff Paper recommendations to existing TLDs.


Notes – IDNs EPDP Call – 3 February 2022

Welcome & Chair Updates

  *   There have been no objections to the proposed updates to the sequence of charter questions, so the EPDP Team will go forward with that plan.
  *   The leadership team is revising language for charter questions A5, A6, and A7 and plans to send text to the mailing list by Monday 7 February, giving the group two weeks for input. If there are substantive comments, the EPDP Team will review the input. Otherwise, the draft will be considered stable.

Charter question A9

  *   Slide 3 – Background for charter question A9.
  *   Slide 4 – Proposed definition details in staff paper: Blocked, Withheld-same-entity, Rejected, Allocated, Delegated.
  *   Slide 5 – State of deliberations and proposals/suggestions discussed so far.
  *   Question: What does withheld-same-entity (rejected) mean?
  *   Response: Within withheld-same-entity there are different states that might be helpful differentiate. There are strings that are withheld-same-entity that are then requested to be activated. The request may be rejected.
  *   Response: Rejected means that a TLD label has an allocatable variant label, the applicant wants to activate it, but this label can’t be allocated because it doesn’t pass the evaluation process. It is then rejected.
  *   Question: Is a label allocated before or after execution of the contract?
  *   Response: Allocated relates to an administrative step and delegated relates to a technical step. From the perspective of ccTLDs, the administrative step occurs at successful evaluation. There is a formal announcement. For gTLDs, allocated would likely be when the string is formally administratively assigned to the applicant. It may be the signing of the contract, but staff can confirm if this is helpful.
  *   Comment: We may need consistency of definitions across gTLDs and ccTLDs. This may need to be taken into consideration.
  *   Questions: Do we also want to include in the definitions cases where a script is not attached to the RZ-LGR?
  *   There may be a circumstance where an application is rejected based on the outcome of application processes but then circumstances change. What if a label was in a contention set during an application process, but the label is later no longer in the root zone? There is no longer a reason for the string to be ineligible and could go through in the future. We may need to think more about the rejection not as a permanent status but something that might be able to change based on circumstances.
  *   We may be getting into A10 – the label states. We are talking about definitions for multiple processes – the New gTLD application process, the Fast Track process, and RZ-LGR process itself. Are there distinctions between the three processes that are creating difficulty? Maybe we should check the definitions against the three processes, or perhaps just the new g and RZ-LGR processes.

Charter question A10

  *   Comment: The process was intended to show a TLD string as it goes through multiple states. When a TLD is accepted and it has variants, some variants would be blocked from an application process based on the disposition given to them, some will be allocatable (withheld-same-entity). The applicant can apply for these withheld-same-entity, and then these labels become allocated (if they are not rejected). Then they are delegated.
  *   Question: If a domain is removed from the DNS, why would you still want to have it allocated (step 5)?
  *   Response: If it is taken out of the root it remains a possibility that it can be used by someone else in the future that applies for it. It is essentially going back into the pool.
  *   Response: Some TLDs got terminated but allocation means that only the same entity will be able to do something with it. If it’s still attached to some legal entity, it will likely only be available to them.
  *   Response: There is also an EBERO process in which the TLD’s state changes. Step 5 may require additional discussion, but EBERO is one topic to consider.
  *   Comment: EBERO may not be something changing the state of the TLD. It is a change of the owner or operator.
  *   Comment: Further explanation might be needed around step 5. It’s important to make sure we are clear for what processes we are defining label states and transitions.
  *   Hypothetical situation relating to allocated and delegated state transition: There is a string and three variants that are withheld-same-entity and they are allocated. There is a process to get all four delegated, but the entity decides it doesn’t need one. That one is still allocated. It is just not delegated.
  *   Additional flow chart suggested for consideration (see attachment 1).
  *   Comment: This flow chart covers the most common case, but there could be additional things that could happen between LGR calculation and withheld-same-entity.
  *   Question: Where is the RA in this additional diagram?
  *   Response: Right after LGR calculation. An additional circle could be added for contention resolution to make it clearer.
  *   Comment: In relation to activation request – this status is important and we didn’t have it in our original diagram.
  *   Question: Is a variant of a reserved string reserved or blocked? Example: International Red Cross designation in Chinese. Additional examples: https://www.icann.org/resources/pages/reserved-2013-07-08-en
  *   Response: We haven’t decided whether to make a definition for blocked.
  *   Response: It is not clear if variants of reserved names have been identified and if they will be identified going forward.
  *   On the diagram: This represents new gTLD application for a main string. There should also be an option in the diagram to apply for a variant where the original is already delegated. This process may be slightly different. It may be helpful to add another circle in the diagram representing the step of allocated, which would be followed by delegated.
  *   Comment: Allocated is a process of application processing. Before the contract is executed it cannot be delegated. The delegation occurs only after contract is executed.
  *   Summary: We need to apply the label states practically to the New gTLD process and fill in any gaps. We need to add where the contracting part fits in. This might be easier to reach agreement on for group.
  *   Updated flow chart suggested for consideration (see attachment 2).
  *   Comment: The diagram on slide 7 of today’s deck should include contract execution as an explicit step. It’s important to show where the contract fits in.
  *   Comment: We may need to map this new diagram to the label states in addition to adding in when contract is executed and when it may be terminated. Transitioning from delegated back to allocated may have a few possibilities that may need to fleshed out further.
  *   Question: Does a blocked variant come into consideration in any contention resolution?
  *   Different perspectives were expressed about whether this should be the case.
  *   Org Response: This is a policy consideration that this group should decide. For example, whether blocked strings should be part of the string similarity review.
  *   Comment: We need to map this process to the ccTLD process. Instead of blocked, we should use the term reserved.
  *   It is important to understand the purpose of the definitions. Once you start applying definitions to a process that has similar words that don’t mean the same things, it becomes more confusing. The definitions we are trying to nail down are associated with the New gTLD process. We also need to be mindful that there is consistency with the ccTLD fast track process. There might be some differences in what happens after delegations with gTLDs and ccTLDs because the processes are different.

Action Item #1: Staff to draft a document overlaying definitions with label states in the New gTLD process.

Action Item #2: Dennis to respond on the mailing list about the status/outcome of the ccPDP discussion related to charter questions A9 and A10.

Charter questions B1 & B2

  *   Slide 10 – overview of charter questions B1 & B2
  *   Slide 11 – SubPro recommendation 25.5
  *   Slide 12 – Staff Paper recommendation 2 & 7
  *   Comment: Panels should understand that there could be a court case against them if they update the RZ-LGR in a way that is not backwards compatible. Currently the TLD contracts do not account for this.
  *   Question: What is the rationale for recommending “same entity” requirements?
  *   Response: B1 consists of two questions. First, is it reasonable to have the same entity to manage variant labels, where the variant is one in the same? Second, who is the same entity? In the gTLD world, we use the term “Registry Operator” for the entity that manages the TLD.
  *   In the framework for managing variant labels, variants are strings that are deemed to be the same. The goal is to protect against denial of service and misconnection. Denial of service means that you do not get to the resource at all. Misconnection means that you think you are going to website A but you go to website B instead. With variants, there is an expectation of the same behavior and the same experience, and therefore the there is the idea variants should be managed by the same entity.
  *   We talked with the SSAC about the fact that there is not technical solution for synchronization. It is the registrant that sets up website, services, and other elements that set up this behavior. At the top-level, the RO is far away from that experience. If the labels are delegated to the same entity, the RO still cannot guarantee the same experience because it is so far removed from the end user.
  *   Comment: What if we used the term TLD manager as defined in the IANA database rather than Registry Operator. This is the same in gTLDs and ccTLDs.
  *   Comment: IANA uses “Sponsoring Organization.”
  *   Question: Why weren’t the SubPro recommendations expanded to existing TLDs previously?
  *   Comment: This is the first opportunity to address this question. It hasn’t been considered previously in a PDP.
  *   Summary: Support expressed for extending SubPro and Staff Paper recommendations to existing TLDs.

Action Item #3: Leadership team to develop text for charter questions B1 and B2 in support of extending SubPro and Staff Paper recommendations to existing TLDs.





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/gnso-epdp-idn-team/attachments/20220203/3b7308b0/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: idngtldstatus v1.png
Type: image/png
Size: 51906 bytes
Desc: idngtldstatus v1.png
URL: <https://mm.icann.org/pipermail/gnso-epdp-idn-team/attachments/20220203/3b7308b0/idngtldstatusv1-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: idngtldstatus v2.png
Type: image/png
Size: 73892 bytes
Desc: idngtldstatus v2.png
URL: <https://mm.icann.org/pipermail/gnso-epdp-idn-team/attachments/20220203/3b7308b0/idngtldstatusv2-0001.png>


More information about the Gnso-epdp-idn-team mailing list