2022-09-08 IDNs EPDP - Meeting #51

Notes/ Action Items

Notes and Action Items

IDNs EPDP Meeting #51

8 September 2022

Action Items:

Action Item 1: Recommendation 3.4: Add “or Change of Control” after “Registry Transition Process” in the first sentence: “After the Registry Transition Process is completed . . ”

Action Item 2: Response to Charter Question D3: Change “policies” to “requirements”, consistent with Specification 2 of the RA.

Action Item 3: Response to Charter Question D3: Possible revision to bullet 1: “Existing data escrow requirements for existing gTLDs must apply to IDN gTLDs and variant labels as provided for in their RAs.”

Action Item 4: Response to Charter Question D3: In bullet 2, change “provider” to “agent.”

Action Item 5: Response to CQ D3: Leadership to propose language for bullet 3. This will also influence Implementation Guidance 3.9.

Action Item 6: Replace “policies” with “requirements” in recommendations 3.8 and 3.9.

Action Item 7: Rationale for recommendations 3.8 and 3.9: Change “enhance” to “maintain.”

Action Item 8: Rationale for recommendations 3.8 and 3.9: Revise language to be consistent with updated text in bullet 3 of the Answer to Charter Question D3.

Action Item 9: Rationale for Recommendation 3.2-3.3: Keep text highlighted by Dennis marked to revisit and review after the EPDP Team has resolved the string similarity issue.

Notes:

Welcome, Chair Updates & ICANN75 Planning

• Leadership team is preparing for ICANN75 sessions. There will be three focus areas:
• The “chunking exercise,” which involves breaking our work into two parts to allow us to complete a draft report for phase one focused on top level issues. The second segment will be on second level issues.
• Leadership team is investigating the possibility of engaging ICANN org’s risk management function during ICANN75 to learn more about the tools this group might be able to use to conduct risk assessment. This may be able to help the group identify where there are edge cases and how to evaluate risks associated with those edge cases.
• Org staff has been working on marking up the new gTLD process flow and mapping our draft recommendations to New gTLD processes. This will help us to consider whether there is anything we missed and whether anything needs adjustment.

Second reading of group 3 charter questions

• Google doc: https://docs.google.com/document/d/1C6xKX87w2LtN4Is0mehuRgc1GqjKmbbhT14KbvUH5Sw/edit

• Recommendation 3.4: Sarmad provided feedback that we need to make clear that the Registry Transition or Change of Control process must encompass the IDN gTLD and all its allocated and/or delegated variant gTLD label(s), if any, at the same time.  Proposed redlines address this feedback.

• Recommendation 3.4: Question from RySG: “Should we consider not allowing any new activation request of allocatable variant TLD labels during any transition until the process is completed, after which the successor registry operator would be the only registry operator entitle to activate any new variant labels?” Suggestion to add a recommendation that the activation requests are not allowed until the transition process is completed.
• Clarification: This may be contingent to how the RO applied for the allocatable variant. If variants are only requested in rounds, this will foreclose the issue. But if we are thinking that activation of variants is possible between rounds, we might need to close this loophole.
• Comment: This comment brings up an interesting point. We should look at the process flow to see if something is needed. In the interim, we should make a note of this point. This applies also to PDDRP use case. We may also look at a requested variant for which the process has not been completed, after which there is a registry transition.
• Summary: We are trying to convey that during a change of control process everything is frozen. Until the registry transition is complete, a request to activate a variant that hasn’t been delegated yet or applied for yet can’t happen until the registry transition is complete. Team will make a note and revisit in analysis of process flow.
• This could be an expansion of 3.4 or potentially a new recommendation.
• Recommendation 3.5: Comment from Justine: Do we need to mention change of control in the text of this recommendation for consistency?

Action Item 1: Recommendation 3.4: Add “or Change of Control” after “Registry Transition Process” in the first sentence: “After the Registry Transition Process is completed . . ”

• Registry Transition Process may encompass Change of Control but it doesn’t hurt to add explicit reference to Change of Control.
• Both can be right. At any point in time a TLD only has one registry.
• RySG proposed redline edits to draft response to Charter Question D3.
• Clarification: At the point the registry agreement is executed the RO starts to need to comply with the contractual requirements.
• Question: If the variant isn’t delegated, the data escrow requirements would be applicable, even if they would be blank?
• Response: Yes.
• Question: On the issue of the term “requirements” vs. “policy”, policy has a connotation in the ICANN environment. It makes sense to use the term “requirements” to be clear about the distinction.
• Comment: To the question is whether a delegated label has always been allocated, the answer is yes. However, an allocated label might not be delegated.
• Question: When do data escrow obligations kick in? Is it when it is delegated legally or delegated into the root.
• Response: When the RA is signed.
• Comment: From the last round, ICANN compliance enforced escrow obligations when the record was in IANA.
• Note: That is different from the point that the RA is signed.
• Comment: Escrow is the process of saving data in case a contracted party goes out of business. Those files have no value and there is no risk before there is a record in IANA.
• Question: Can we check for certain how this was done in the previous round? Did the obligation start at contract signing or when delegated to the root zone? We should stick with the same procedure.
• Summary: If we are not sure about how this is enforced, maybe we just want to emphasize that the escrow requirements apply for variants the same way they apply for other TLDs.
• Comment: Two situations: One where there is a new TLD and there are no record, a second scenario is a registry transition where there is a zone file. In the registry transition, the new registry will have the same obligations.

Action Item 2: Response to Charter Question D3: Change “policies” to “requirements”, consistent with Specification 2 of the RA.

Action Item 3: Response to Charter Question D3: Possible revision to bullet 1: “Existing data escrow requirements for existing gTLDs must apply to IDN gTLDs and variant labels as provided for in their RAs.”

• In bullet 2, Dennis suggests changing “provider” to “agent”

Action Item 4: Response to Charter Question D3: In bullet 2, change “provider” to “agent.”

• Written input on bullet 3: Dennis suggests talking about data escrow files instead of agents. We care about the outcome. What we are saying is that Specification 2 gives the requirements about how to process the deposits. It is consistent in intent, it’s just how we talk about it. We should focus on the outcome, which is the deposit files.
• Question: Does the RO have to submit different escrow files for each TLD or do they submit one file for all TLDs? Who has to separate the files? Is this of concern to us?
• Response: If you look at file naming convention, the file is called using the TLD name. All variants have different TLD names. Logically, it is different files. There is no reason to upload it as a bunch. It will change procedures.
• Comment: The point is that escrow data needs to be separated for each TLD.
• Comment: If we are pointing as a reference the data escrow requirements, it’s about how the RO submits those files, which is on a per-TLD basis. Make clear who has an obligation to submit the file, which is the RO, on a per TLD basis.
• Summary: We want to be consistent with the Spec 2 requirements, so we can just point to those requirements.
• Question: Is the reference to the data escrow agent incorrect?
• Response: Not sure. The data escrow has an agreement with the RO, not ICANN. It’s not clear whether our rationale will effectuate something in that agreement. What is done today is working. We don’t need to introduce new complexity.
• Comment: The emphasis should be on the idea that the data should be stored in different files.
• Comment: From the technical perspective, the fewer operations the better.

Action Item 5: Response to CQ D3: Leadership to propose language for bullet 3. This will also influence Implementation Guidance 3.9.

• Next item: Rationale for recommendations 3.8 and 3.9.

Action Item 6: Replace “policies” with “requirements” in recommendations 3.8 and 3.9.

• Additional RySG input: Since each gTLD in a variant set is a unique and independent entry in the root zone, each gTLD must have the same data escrow requirement to create a gTLD-specific data escrow deposit files. We are making clear that each gTLD in a set must comply individually, and since we are not creating new requirements I don't see how this practice (in the context of variants) enhances the stability of the associated domain name registrations.

Action Item 7: Rationale for recommendations 3.8 and 3.9: Change “enhance” to “maintain.”

Action Item 8: Rationale for recommendations 3.8 and 3.9: Revise language to be consistent with updated text in bullet 3 of the Answer to Charter Question D3.

• Question: Is it even possible to have the data in a single file?
• Response: At the moment, a RA covers one TLD. We have a recommendation that if you have a IDN label and variants, there can be one RA. What is the impact on the data escrow requirements? We want to be clear that in the future that if you have an RA that covers a TLD and variants, the escrow requirements need to apply to all, each with a different file.
• Question: Do we know how they store the data now?
• Response: We do know how it’s done now, because gTLDs have been operating for 10 years. All we are saying is that if there is a TLD with variants in the future, store it the same way but in different files.
• Suggestion: It might be helpful for everyone to review Spec 2 language, which refers to multiple files. The process is working now and we shouldn’t change it.
• For reference: Spec 2 Part B #4 — “ Integrity and Confidentiality.  Escrow Agent will be required to (i) hold and maintain the Deposits in a secure, locked, and environmentally safe facility, which is accessible only to authorized representatives of Escrow Agent, (ii) protect the integrity and confidentiality of the Deposits using commercially reasonable measures”

• Google Doc: https://docs.google.com/document/d/1RLvsyQvliafNEA9Ja1RCObywpAWfp1kTmte0WZlyqqs/edit
• Next Item: Charter Question E5
• Rationale for Recommendation 3.2-3.3 excerpt: The EPDP Team recognized that if the Reserved Names list were to expand by including the variants, all of the added variants (almost all of which are blocked and can never be delegated to the rootzone) also need to be checked against during the String Similarity Review. It means that every applied-for gTLD string would have been compared against an enormous pool of Reserved Names. Therefore, the EPDP Team agreed that the Reserved Names list should stay as is and no variants should be added. The implementation complexity of adding variants to the Reserved Names list would have outweighed the potential security and stability benefits, if any.
• Comment on the text from Dennis: We may need to revisit this part since it argues for a practical solution since blocked variants can never be delegated and they don't need be part of the string similarity process — It argues against the Hybrid Model.
• Note: The EPDP team is still deliberating on the hybrid model and will soon get input on a possible risk management approach to considering this.
• Dennis: This language was written before discussion of the hybrid model. Dennis found it interesting that there is a contrast between this and the hybrid model. They are not the same, but they are related. Do we need to consider the potential consistency between the approaches?

Action Item 9: Rationale for Recommendation 3.2-3.3: Keep text highlighted by Dennis marked to revisit and review after the EPDP Team has resolved the string similarity issue.

• The process of checking recommendations against the process flow may help us confirm that our recommendations are consistent before we put a draft report out for comment.

Continue discussion of objections (Limited Public Interest, Community, and Legal Rights)

• We are pausing discussion of the String Confusion Objection because it is closely tied to String Similarity evaluation, which the EPDP Team will revisit soon. We will come back to this.
• There is one proposal on the table for Limited Public Interest, but options have been put forward for Community and Legal Rights Objection.
• Slide 41 – Review of Small Group recommendation on Limited Public Interest Objection.
• No concerns raised with the approach suggested by the small group.
• Slide 42 – Review of options for recommendations from the small team on Legal Rights Objection
• Slide 32 -- Additional Rationale for Option 2
• The presumption is that round 1 and 2 are in sequence and that round 2 opens after round 1 closes.
• It may not be possible to draw a conclusion on this item until the WG has made a determination about the hybrid model, because the examples arguing for Option 2 draws on the hybrid model from staff’s perspective, but there is some nuance.

AOB

• Reminder, no call next week. Next meetings will be our sessions at ICANN75.