Dear all, Please find below the notes from today’s meeting on Thursday, 27 January 2022 at 13:30 UTC. Kind regards, Ariel, Steve, and Emily Action Items: Action Item #1: Staff to send follow up message to the mailing list reminding members to provide any comments. Members to provide any input by 2 February 2022. Action Item #2: Leadership team to ensure that the recommendations in relation to A6 provide safeguards for the existing contracted parties. Be more explicit by what we mean by grandfathering. In recommendation 1.4, take out “to the extent feasible”, include that the RZ-LGR MUST be updated. Add implementation guidance explaining specific expectations regarding the limited circumstances for exceptions to backwards compatibility. Action Item #3: Leadership team to add a recommendation reaffirming the principle of backward compatibility. Action Item #4: Leadership team to update recommendation 1.6 to be more specific in the definition of grandfathering and the circumstances throughout the TLD lifecycle where this applies. Action Item #5: Leadership team to draft implementation guidance in relation to recommendation 1.5 focused on who should provide that information as part of the public comment. Notes – IDNs EPDP Call – 27 January 2022 Sequence of Charter Questions * Staff sent a message to the list earlier this week regarding sequence of charter questions. Comments are welcome regarding proposed reordering of the questions. * Leadership proposal is largely consistent with proposal from Dennis regarding order. * Some support expressed for reordering as proposed. Absent any comments in the coming week, this order will be adopted. There will be an opportunity to make additional changes to the ordering as we go through the questions where it makes sense to do so. Action Item #1: Staff to send follow up message to the mailing list reminding members to provide any comments. Members to provide any input by 2 February 2022. Charter question A6 – continued deliberations on open items (see open items under A6 in the Draft Outcome document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1Bt0LT45UaLynF...>) * Slide 3: Draft recommendations for this charter question. * Suggestion: We should have a recommendation that anyone responsible for updating the RZ-LGR must ensure backward compatibility and if they can’t, they should specify why. * Response: It is possible to make this explicit in our recommendations, but as discussed, this is already part of the RZ-LGR process. There might be rare exceptions. Backwards compatibility cannot be 100% guaranteed. * Question: If the LGR is unable to retain backward compatibility, some TLDs will be “illegal.” What are the mechanics of this? There may be legal issues. This TLD is not going to pass any assessment of the backend. * Response: In recommendation 1.6, the gTLD and delegated and allocated variants will be grandfathered. Therefore, there will no change to the Registry Agreement. Recommendation 1.5 calls out the exception, requires explaining why it is necessary, and provides balance of information through the public comment process. Perhaps we need to be more explicit. * Comment: If a registry is grandfathered and it needs to make a change, it may need to pass technical tests. This is the point where issues will arise. We need to add that these mechanics are not a reason for termination of a TLD. * Suggestion: Would the concern be addressed to add text to 1.6 that the TLD will continue to operate as it has been delegated? * Response: This will not provide assurance in cases where there needs to be a change to the TLD, because the change will have to go through processes for which it will fail. * Clarification regarding recommendation 1.4: Why do we use the text “to the extent feasible”? This seems to dilute the point that the circumstances are limited. * Response: This text was added because there is uncertainty about whether our recommendations could have an effect on a separate procedure. The RZ-LGR process is not under the GNSO. However, this text could be removed if the group supports it. * Some support expressed for removing “to the extent feasible.” * Question: For recommendation 1.5, is the expectation/intent that the RO, customers, and end users provide input to the public comment period or is it that the GP affirmatively seeks input in their rationale and this is included in their output? * Response: This speaks to one of our outstanding questions. This could be addressed as implementation guidance or rationale. We will get to this issue in the discussion. * Comment: If the RZ-LGR can’t maintain backwards compatibility, then maybe the registries don’t need to follow the LGR. We don’t need to be so passive. We can say that the LGR has a duty of backwards compatibility and registries have a duty to comply with the RZ-LGR. * Comment: We may need to identify the impact on contracts as something to consider further. * Comment: Agreement with the sentiment regarding obligations of different parties. At the same time, we need to understand that there are things outside of the control of GPs and IPs, such as a change in IDNA and Unicode. They are rare, but the policy needs to make clear that there are those external risks. The RZ-LGR update process already ensures backwards compatibility to the greatest extent possible. * ICANN org comment: Important to emphasize that this is a very rare, if ever, phenomenon. There are stability mechanisms built into three layers – Unicode has its own stability clauses that makes those cases extremely rare; stability clauses built into IDNA 2008 standard; in the RZ-LGR itself there is a stability clause. Even if the GP tries to change something, the IP would need to review and approve those changes. The IP is very conservative about changes that would impact an existing TLD. It’s an extremely high bar. * Comment: We need a safeguard, for example, absent a change to Unicode and IDNA, it should be prohibited to make a change that is contrary to backwards compatibility. * Response: There was a lot of thought and consideration that has gone into the development of the RZ-LGR. Decisions will be taken with due care. At the same time, we can make an effort to put in additional safeguards. * Comment: It doesn’t matter how rare the circumstance might be, we can make recommendations about what we expect the RZ-LGR to do. If they don’t meet their end of the bargain, we don’t have to follow the RZ-LGR. Action Item #2: Leadership team to ensure that the recommendations in relation to A6 provide safeguards for the existing contracted parties. Be more explicit by what we mean by grandfathering. In recommendation 1.4, take out “to the extent feasible”, include that the RZ-LGR MUST be updated. Add implementation guidance explaining specific expectations regarding the limited circumstances for exceptions to backwards compatibility. * Slide 4: Outstanding question #1 * Question: From the conversation it sounds like we do need to add something about the impact on existing RAs. Are there other existing policies and procedures to address? * Response: We should not leave this to an IRT. We should provide explicit guidance to the IRT. We should have a recommendation that the panel makes best effort for backwards compatibility. They are not beholden to this. There should be a backout clause for any cases where they don’t meet that expectation. * Comment: If there are principles in the contract, for example any exceptions to the process, this needs to be in the recommendations. Action Item #3: Leadership team to add a recommendation reaffirming the principle of backward compatibility. * The WG might need a small team to look at the contractual issues. * Comment: Outright rejecting the RZ-LGR where there is not backward compatibility might be too loose, we should put boundaries around that. * Concern: Grandfathering could mean that anything done is allowed, but anything new must follow the new process. * Donna Summary: With 1.5, we’ve tried to strike a balance, by bringing in the impact of an exception to backwards compatibility using the public comment period. It might be necessary to better explain what we mean by “grandfathering” – specifically, leadership sees it as no change to the operation of the gTLD. * Comment: this needs to be made explicit, so that the interpretation is shared by all parties. * Comment: The RZ-LGR is used in one moment in time in the TLD lifecycle, at the evaluation of the application. There are additional use cases in which the grandfathering would apply within the TLD lifecycle. We should focus on those use cases. * Comment: Maybe we can define grandfathering: In case RZ-LGR is updated, all existing TLDs will be subject to the version that applied when they were allocated. Action Item #4: Leadership team to update recommendation 1.6 to be more specific in the definition of grandfathering and the circumstances throughout the TLD lifecycle where this applies. * Slide 4 – Outstanding Question 3 * Question: Why are we calling out the GP, as opposed to the IP, in this clarification question? * Response: It is the GP that conducts the public comment. The GP proposes the update that may cause the incompatibility. They are best positioned to consider mitigatory action. * Clarification: The IP only has a review role, they provide feedback and demarcation, but the solution for the script is provided by the GP. The GP provides the solution, releases it for public comment. Based on public comment GP submits proposal to IP, IP evaluates, reviews and makes final determination about whether the proposal meets criteria (also taking into account public comments). * Clarification: 1.5 seeks to ensure the GP takes into account the impact of its actions. Who is best placed to do the analysis? * Response: The RO should have an opportunity to provide an assessment, Org should provide an assessment. If there is a disagreement, there should be a process to address any conflicts between the assessments. * Org comment: The scope of this particular study is beyond the scope of what the GP and IP are tasked to do, so they may not be well positioned to do the study. * Question: Is there anything in the process that allows the GP to consult with the RO that will be impacted? * Response: There is nothing requiring a consultation but it is also not forbidden. Action Item #5: Leadership team to draft implementation guidance in relation to recommendation 1.5 focused on who should provide that information as part of the public comment. * Slide 4 – Outstanding Question 4 * Comment: To the extent that ICANN can propose a solution, they should do so and the RO and comment on that. The contract already has mechanisms for disagreements. The answer is essentially the same as outstanding question 3. Charter questions A7 * Slide 6 – current status * Suggestion in response to the first question: For the policy recommendation, state that single character TLDs are allowed for scripts with ideographs/ideograms. The implementation is the specific languages listed on the slide. * For the second question, support expressed for outsourcing the question and providing a clear set of instructions. * Note: We will reaffirm SubPro rec in the text of the report. * Question regarding the second clarification question on the slide: if it not practical to outsource, we have discussed the possibility of a thorough review process. Are we suggesting that this review process takes place through something other than the DNS Stability Review? It does not seem that an additional review process is needed and could be done as part of the DNS Stability Review. * Support expressed for the idea that the evaluation process should be the same and maybe there is one more additional question to ask. * Summary: We’ve reaffirmed the SubPro policy that single character IDN TLDs are allowed and we need to talk about mechanisms for criteria. There does not appear to be support for a separate process as part of the application process. * Comment: SSAC has provided feedback that a single character without additional context may be more confusing. This is a string similarity problem. One possibility is that the new gTLD string similarity panel could take up an additional role with respect to evaluation of these applications.