Page History

Audio Recording

Zoom Recording

Chat Transcript 

GNSO transcripts are located on the GNSO Calendar

Attendance

Apologies:   Tomslin Samme-Nlar

Notes/ Action Items

Action Items:

 Action Item #1: Reminder: WG to review draft response to charter questions A1-A3 and provide input by Monday 13 December 2021.

Notes – IDNs EPDP Call – 9 December 2021

Welcome & Chair Updates

• Reminder: 13 December is the deadline for comments and question on the draft language for charter questions A1-A3. If there are substantive comments, these will be discussed on last week’s call.
• We tried to get some members of SSAC to join this call to continue the discussion A5, but we were not able to so. Instead, will focus on A6 and A7. We will try to find a time early next year to bring SSAC members on the call to go over relevant SSAC Advice. Members can start thinking about targeted questions about the SSAC.
• Donna will be working from Australia for the next few months. We will try to keep the weekly meeting at this same time, but Donna will let the group know if we need to make a change.
• Reminder: An email was sent to the group to change next week’s call to Friday (17 Dec) at 13:30 to avoid a scheduling conflict with the Council meeting. There were no objections, so the call was rescheduled.
• Dennis has given some thought to a possible sequence of addressing charter questions. The leadership team will give additional thought over the holiday break to determine if it is better to re-order the charter questions.

Charter question A6

• Slide 3 – summary of the charter question
• Context for recommendations 7 and 12 from the TSG: These were written when a previous version of the RZ-LGR was in place. RZ-LGR is not intended to be static. New rules could be put into place. There is a possibility of this happening but the probability is low because of the measures that are in place. But we need to think about this possibility to be complete.
• Slide 4 - Scope: Focus on future update of the RZ-LGR and its implication on existing gTLDs in the future. Based on data collected, all current existing TLDs are valid.
• Slide 5 – Trigger events for RZ-LGR updates – mostly involve adding materials as opposed to subtracting materials from the RZ-LGR.
• Slide 6 – Backward compatibility - Invalidating an existing gTLD and its variant labels (if any) by the proposed RZ-LGR update is extremely unlikely, as it will cause instability in the root-zone
• Slide 7 – TSG recommendation 12 provides a recommendation to address cases where backwards compatibility cannot be achieved. Does the EPDP Team agree with the TSG’s approach? If so, to what extent should the TLD policies and procedures be updated to grandfather an existing TLD and its variants (if any), which are not validated by a script LGR?
• Is there additional information that the GP could provide during the public comment period recommended by the TSG?
• Should the potential damage to the TLD be highlighted in the public comment period?
• Comment: In general, agree with the TSG suggestion. Two theoretical cases 1. RZ-LGR could say that an existing TLD is no longer valid 2. RZ-LGR says an existing variant of an existing TLD is not an allocatable variant anymore. In these cases, the existing TLDs should remain as they are in “frozen” state. They will not be able to get further variants if not valid with the new RZ-LGR but existing TLDs and relationships should be kept.
• Comment: We need to check if whatever we create is in line with the ICANN Bylaws. We need to take into account potential damage to registries and also registrants.
• Comment: Agree with grandfathering existing TLDs and variants just in case but we should stress the importance of maintain full backwards compatibility. We should make sure this remains a hypothetical situation that does not happen in practice.
• Summary: Support for grandfathering existing TLDs and potentially their variants with an emphasis on the importance of backward compatibility.
• Suggestion: Maintain backward compatibility and recommend grandfathering as a plan B should an extremely rare situation arise. Would a recommendation that becomes policy be enforcable over the GPs and IPs? If that is not the case, we should focus on what we can control which is what goes in the root and stays in the root?
• Question: What happens as a result of the public comment period if there is extreme dissatisfaction in the public comment if a GP expresses that a TLD is at risk?
• Comment: If GP encounters this unlikely situation, they communicate with the Board which works with the community to address the issue. Their powers should be limited to a special report.
• Question: If the GP was to recommend that a TLD should be “retired” who would make the ultimate decision? It becomes complicated if we don’t decide to grandfather.
• Question: What is the power of this WG over the TSG, GP or IP?
• Comment: All existing TLDs have contracts with ICANN. There are provisions in the RA regarding material change. Changes dictated by a GP are outside the scope of allowable changes under the contract.
• Question: Would a policy of grandfathering mean that the TLD would exist in perpetuity?
• Org comment: As noted above, the scenario addressed in this charter question is an unlikely one. As part of the development of the RZ-LGR, the GP or else the IP runs proposals through the existing TLD database to see that they are supported. The GPs are cautious and wary in that they don’t want to destabilize the root zone. If this scenario came up, there would probably be a very significant reason. Grandfathering is a good idea, but it is also a good idea to understand the extreme circumstance before going forward with grandfathering.
• Comment: There are examples of changes in rules that came with RZ-LGR 4 that caused problems for Registries in relation to IDN tables (issues related to the second level). Registries were told that there wouldn’t be problems and then there were problems.
• Suggestion: Perhaps a combination of grandfathering and assurances from ICANN/IP that retaining 100% backward compatibility is a hard requirement, anything contrary to 100% BC needs to have a very high bar to pass? Putting this in policy would create double assurance.
• Org Comment: There are multiple layers to consider below the GP/IP layer: IDNA2008 layer and Unicode layer at the base. A change to the RZ-LGR in the future could be motivated by one of these other layers.
• Comment: changes to IDNA or Unicode are a high bar to pass.
• TSG recommendation 12: “In the event that backward compatibility cannot be achieved, the GP must call out such an exception (that an existing TLD is not validated by their proposed solution) during the public comment period and explain the analysis and reasons for not supporting the existing TLD in their script LGR proposal.” If the WG supports this, is there anything we need to add? Is there anything specific that needs to be covered in "analysis and reasons" by a GP.
• Suggestion: potential impact on the TLD.
• Comment: It may be useful to explain in the recommendation why future versions of the RZ-LGR need to be backwards compatible.
• WG supported approach: Combination of grandfathering and assurances from ICANN/IP that retaining 100% backward compatibility is a hard requirement, anything contrary to 100% BC needs to have a very high bar to pass? Putting this in policy would create double assurance.

Charter question A7

• Slide 9 – overview of charter question a7 – focuses on mechanism or criteria, does not request the WG to identify specific languages/scripts.
• Slide 10 – origins of this charter question.
• Slide 11 – SubPro recommendation 25.4
• Slide 12 – RSG Report Appendix B
• Slide 13 – SAC052 Finding
• Slide 14-15 – SAC052 Recommendation 1
• Slide 16 – JIG Final Report on Single Character IDN TLDs – Recommendation D
• Question: Is there any background material regarding technical instability associated with single charter TLDs?
• Response: We are talking about single character U-Labels, which translate into more than 4 characters in ASCII if it’s an IDN. On the DNS level there is no impact. The potential impact is only on the user side.
• Comment: Maybe it should be outsourced to identify ideograph and ideograms scripts to support further analysis by the WG.
• Comment: The solution is to use the existing GPs and IP or formulate a new mechanism or committee that is able to identify if the script can be used for characters and then which characters can be used.
• Org comment: Han script is the only ideographic script that is being used in the root zone. If we are looking only at ideographic scripts, it might still be useful to go back to the relevant GPs to see if they have identified characters that might be appropriate for single character TLDs.
•  Comment: The original thinking about this issue was to avoid situations where a single stroke of the keyboard would enter a TLD – typos could result in security issue. Usually with ideographs, it takes more than a single keyboard stroke to type the TLD. If in the future, there would be voice input, a single word would suffice to enter a TLD. They key issue for consideration regarding ideographs – for Han characters (Chinese, Japanese, Korean) -- One ideograph could represent a whole concept/word.