- Gnso-epdp-idn-team - lists.icann.org

Proposed Change to Sequencing of Charter Questions
by Ariel Liang Jan. 26, 2022

Jan. 26, 2022

[Please see below the message sent on behalf of Donna] Dear EPDP Team, As you may have noticed from the proposed agenda for this week’s meeting, we will discuss possible changes to the sequencing of our charter questions. The goal is to ensure a logical order is being followed and provide efficiencies to our deliberations. In consultation with Dennis Tan Tanaka, who was the IDNs EPDP Charter Drafting Team Chair, the EPDP leadership team is proposing the following changes: https://docs.google.com/spreadsheets/d/1YfnJPAO7Ey6MRpVCR7N8uMPHmGWdnHcxioO… - gid=0<https://docs.google.com/spreadsheets/d/1YfnJPAO7Ey6MRpVCR7N8uMPHmGWdnHcxioO…> In summary: * Complete the first pass of Topic A questions related to RZ-LGR * Address questions with implications to IDNs at the top-level (application process, legal/operational framework): B1-B3, D1-D1b, B4-B4a, B5, E1-E7, D2-D3 * Followed by questions with implications to the second-level and beyond (lifecycle management, RPMs, etc.): C1-C6, D4-D8, E6, F1-F2 * And lastly, the IDN Implication Guidelines related questions: G1, G1a * The proposed sequencing takes into account the “explicit” dependencies, which are called out in the Charter, as well as the “implicit” dependencies identified by Dennis and the Leadership Team. The implicit dependencies column will be updated as the EPDP Team discovers additional ones along the way. We recognize that the revised sequencing won’t be perfect, particularly as we are learning the topics and working through the charter questions in an iterative manner. To that end, we will maintain the flexibility to adjust the sequencing if necessary in the future. I don’t want this exercise to become a distraction and take time away from out actual work. If agreement for the proposed sequencing becomes difficult and time consuming, we will default back to the original workplan and tackle the charter questions topic by topic. Thank you for your review in advance. We look forward to the discussion this Thursday. Best Regards, Donna

1 0

15 MINUTES **REMINDER** Meeting Invitation | IDNs EPDP Team | Thursday, 20 January 2022 at 13:30 UTC
by Devan Reed Jan. 20, 2022

Jan. 20, 2022

Dear all, The IDNs EPDP Team meeting is scheduled on Thursday, 20 January 2022 at 13:30 UTC for 90 minutes. Please click link to join the webinar: https://icann.zoom.us/j/94276275950?pwd=dG5hanFzMlpsYmh0NnFjTEQwOUV1dz09 <https://urldefense.com/v3/__https:/icann.zoom.us/j/94276275950?pwd=dG5hanFz…> Passcode: !!0tV0Wh&K For Audio only: One tap mobile : US: +13017158592,,94276275950#,,,,*5259149775# or +13126266799,,94276275950#,,,,*5259149775# Webinar ID: 942 7627 5950 Passcode: 5259149775 International numbers available: https://icann.zoom.us/u/adP1jJ0gRH <https://urldefense.com/v3/__https:/icann.zoom.us/u/adP1jJ0gRH__;!!PtGJab4!v…> If this is your first time with Zoom, please take a look here: Welcome to Zoom <https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/polic…> Members, participants, and observers all have different access and participation directions, please read below! ALL: Before joining the call * Please send dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only * Please be sure you have read the ICANN Expected Standards of Behavior <https://urldefense.com/v3/__https:/www.icann.org/resources/pages/expected-s…> * Visit the Wiki agenda page: https://community.icann.org/x/m4H3Cg * Check your time zone: https://tinyurl.com/4mr2byj5 [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/4mr2byj5__;!!PtGJab4!pYQ0pkq…> ONLY for Members and Participants * Please join via the above Main Zoom Webinar link and staff will promote you to panelist. * Please select Everyone, when posting to the chat in order for everyone to see and to be captured afterwards. Only for Observers: * Observers will have ability to view member chat and information shared in the zoom webinar room. * Observers will not be able to use chat or raise hands. Thank you. Kind regards, Devan

3 2

Notes and action items - IDNs EPDP Meeting #20 - 20 January 2022
by Emily Barabas Jan. 20, 2022

Jan. 20, 2022

Dear all, Please find below the notes from today’s meeting on Thursday, 20 January 2022 at 13:30 UTC. Kind regards, Ariel, Steve, and Emily Action Items: Action Item #1: Leadership team will update the recommendations based on today’s discussion and share with the EPDP Team for review. Notes – IDNs EPDP Call – 20 January 2022 Welcome & Chair Updates * The leadership team continues to look into reordering charter questions and will provide feedback in a week or two. They will only suggest changes to the order if they think there is substantive benefit. The EPDP Team will work through the rest of Topic A before any changes are made to the order. * Update on GNSO Council Approach to IDN Implementation Guidelines v.4.0: The Council has agreed with the Board’s suggestion to continue to defer items that overlap with the EPDP. The Council drafted a letter identifying items in the Guidelines that overlap with the EDPD charter. This is a discussion item on today’s Council call and the letter is expected to be sent by the end of the week. As liaisons, Dennis and Anil will relay relevant updates to the ccNSO and ccPDP4. Charter question A5 * Last week, the EPDP Team discussed with SSAC members whether there should be a ceiling mechanism for variants. This week, the EPDP Team will reflect on the SSAC’s input. * Follow up on data collection exercise for this charter question: Org checked all scripts in the RZ-LGR and those that will be incorporated in next version to see if there are mechanisms in place to reduce the number of allocatable variants. * Presentation of results: slide 4 lists scripts with no variant labels, scripts with no allocatable variant labels, and scripts that have allocatable variant labels. * Scripts with allocatable variant labels: Arabic, Bengali, Chinese, Greek, Latin, Myanmar, Tamil. * Question: Does this list only cover gTLDs and ccTLDs? * Answer: The same would apply to both gTLDs and ccTLDs. It includes all scripts in the RZ-LGR. * Question: What do we have these three categories listed on slide 4? Is the categorization a technical decision or a policy issue? * Two distinctions: First is the question of variants versus no allocatable variants (column 1 versus column 2). This depends on the judgment of the script community and the way they define variants for the script. For those scripts that have variants, there is the question of whether they are allocatable (column 2 versus column 3). The question about whether they are allocatable is primarily an issue of usability. Once you define something as a variant and determine that it will be treated as such, the security aspect is contained, but the usability aspect is not. Allocation may be appropriate for usability reasons. * Clarification: The security challenges are the same for column 2 and 3, arising from the fact that there could be code points that are the same within a script or between scripts. By declaring such code points as variant code points, the security issues are addressed in both column 2 and 3. We may want to have them as allocatable because of usability requirements. * Question: Is there a reason to think that security issues might change as we add more scripts and that security panels will need to reassess allocatable variants? * Clarification: When saying that the security issues are addressed by considering the labels variants, this is referring to security issues as defined in a limited context – those with respect to “same” code points. It does not address all possible security issues, for example those related to string similarity. * Comment: Evaluation at the root level is to address similar looking TLDs. Providing an example of the difference between allocatable and non-allocatable, in Chinese U+39DF = U+64D3 are considered equivalent. If you apply for the TLD to the left, the one to the right can’t be applied for independently. The question is whether the two can be allocated to the same entity. The question is whether the label stands on its own and is unique. If it is not, an application for the TLD should fail. * Org data collection: Looking at scripts in column 3 on slide 4, org went through existing list of TLDs which are delegated and ran them through the RZ-LGR to see how many variants are created. See slides 5-6. Most scripts have been able to put a reasonable ceiling on the number of variants. There are at least two scripts – Arabic and Chinese that might create an unanticipated number of variant labels. * Question: Is the analysis in slide 4 an official analysis? * Answer: ICANN org staff collated information from the RZ-LGR proposals for use by this group. * Question: For the Latin script proposal, does the analysis take into account public comments that have been received. * Response: Yes, the public comments have been taken into account and they don’t impact definitions of allocatable variants. * Comment: The SSAC members seemed to agree that we shouldn’t come up with an arbitrary limit/ceiling value but focus on evaluation criteria in order to understand that the registry can manage any issues that arise with variants. * Question: Do the Registries and Registrars have insight into the challenges that arise with the bundling exercise? * Comment: When you apply for the TLD, you shouldn’t automatically be granted variants. You should be protected against other applicants obtaining variants. If ICANN wants to offer variants, from a Registry perspective and a DNS perspective, that’s a separate zone and there is maintenance of two zone files involved. It’s two separate TLDs that the Registry needs to facilitate and operate. * Comment: In general, the concept of IDN variants is not “look alike.” In Chinese, up to 5% of users will type the variant. It’s not just an issue of protection, it’s also an issue of usability, at least in the Chinese case. * Comment: Agree that we shouldn’t automatically give applicants variants, but the question is whether there should be a limit. * Org comment: When we are generating allocatable variants through the RZ-LGR process, even though panels work to manage the number of allocatable variants, the process still over-generates as a byproduct of making some of the solutions work. When people use variants, they do it from a language perspective. Since the RZ-LGR is script based, variants are generated with code points across languages in the script. Therefore, not all allocatable variants are equally usable. * Questions: Should further guidelines be developed and if so, should the working group provide recommendations and/or implementation guidance for those guidelines? * Summary: This is a limited issue impacting a limited number of scripts. We are not recommending a ceiling value. There is some support for idea that this is something for the market to provide for. We may come back to put some ideas in place for the guidelines with input from the Registries and Registrars. Charter question A6 * Org question: The are a set of variants labels that are blocked. There will be a smaller set, allocatable to the same applicant. There will be an even smaller set that will be delegated variant labels. If a variant label or string is delegated, it has a high stability bar. It should remain delegated unless there is an extreme circumstance. Allocatable variants are not yet in the root, so changes there may be less critical. Since for blocked strings are not able to be used, changes there are even less critical. For recommendations 1.4 and 1.5, we talk about variants – do we want to differentiate between these three groups? * Question: What are the implications of the different buckets referenced above as they apply to recommendations 1.4 and 1.5? * Clarification: If a variant TLD was delegated and in the root and there is a change in the RZ-LGR saying that that variant should be blocked, or that it is no longer a variant, it should be grandfathered. But if the variant is blocked and then it becomes allocatable, that doesn’t create as significant and issue compared to changing something that is in the root zone and delegated. The categories speak to how much of a stability impact that change can have on the root zone. * Comment: Suggest restricting these recommendations to delegated and allocated variants and not address blocked variants. There is no harm done if the blocked variant is taken away due to a change. * Support expressed for limiting the recommendations to delegated and allocated variants. * Suggestion to use “variant labels” instead of “variants.” * Question from org regarding recommendation 1.6: RZ-LGR has a built-in stability clause. Would you still want to go back and update RZ-LGR procedures? Additional comment: It may not be possible to anticipate all applicable circumstances that would result in an update to the RZ-LGR. * Comment: We did think some elaboration of the circumstances would be helpful for predictability. * Question regarding 1.5: what are we trying to say by “extremely strong”? Are we trying to say that there are circumstances where the presumption could be rebutted? * Question: After the public comment process, will it be the panel that makes the decision about grandfathering? * Clarification: Determining whether a specific label should be delegated in the root zone is outside the purview of the Generation Panels, as their responsibility is currently defined. * Comment: This group can set a policy that if there is a change, an existing TLD is grandfathered. The question is if there is a presumption, what if anything can result in an exception. * Comment: The Generation Panel does not have the power to change Registry contracts as currently set up. Contracted parties have little reason to agree to change this. * Suggestion: Grandfathering should be absolute in recommendation 1.5. * Suggestion: in recommendation 1.5: "except as set forth in 1.6, all existing gtLDs…….will be grandfathered." * Question: Can we seek public opinion before granting grandfather status? * Response: This may be covered in recommendation 1.4. * Comment: This will be implemented in contracts. We shouldn’t give a panel power over contracts they are not a party to. It’s ok for the panel to make a recommendation, subject to a process between ICANN and the Registry. But the panel is not a party to the contract. * Comment: Further discussion may be needed about what that process would be following the recommendation from the panel. * Summary: Recommendation 1.5 to be updated to say that the TLD will be grandfathered, except as set forth in 1.6. Additional edits may be appropriate for 1.6.

1 0

Post Call | IDNs EPDP Team call | Thursday, 20 January 2022 at 13:30 UTC
by Devan Reed Jan. 20, 2022

Jan. 20, 2022

Dear all, All recordings for the IDNs EPDP Team call held on Thursday, 20 January 2022 can be found on the agenda wiki page <https://community.icann.org/x/m4H3Cg> (attendance included) and the GNSO Master Calendar. <https://urldefense.com/v3/__https:/gnso.icann.org/en/group-activities/calen…> These include: * Attendance (please let me know if your name has been left off the attendance list) * Audio recording * Zoom chat archive * Zoom recording (including audio, visual, rough transcript) * Transcript For additional information, you may consult the mailing list archives <https://mm.icann.org/pipermail/gnso-epdp-idn-team/> and the main wiki page<https://community.icann.org/x/uAPpCQ>. Thank you! Kind Regards, Devan

1 0

Meeting Invitation | IDNs EPDP Team | Thursday, 27 January 2022 at 13:30 UTC
by Devan Reed Jan. 20, 2022

Jan. 20, 2022

Dear all, The IDNs EPDP Team meeting is scheduled on Thursday, 27 January 2022 at 13:30 UTC for 90 minutes. Please click link to join the webinar: https://icann.zoom.us/j/94276275950?pwd=dG5hanFzMlpsYmh0NnFjTEQwOUV1dz09 <https://urldefense.com/v3/__https:/icann.zoom.us/j/94276275950?pwd=dG5hanFz…> Passcode: !!0tV0Wh&K For Audio only: One tap mobile : US: +13017158592,,94276275950#,,,,*5259149775# or +13126266799,,94276275950#,,,,*5259149775# Webinar ID: 942 7627 5950 Passcode: 5259149775 International numbers available: https://icann.zoom.us/u/adP1jJ0gRH <https://urldefense.com/v3/__https:/icann.zoom.us/u/adP1jJ0gRH__;!!PtGJab4!v…> If this is your first time with Zoom, please take a look here: Welcome to Zoom <https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/polic…> Members, participants, and observers all have different access and participation directions, please read below! ALL: Before joining the call * Please send dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only * Please be sure you have read the ICANN Expected Standards of Behavior <https://urldefense.com/v3/__https:/www.icann.org/resources/pages/expected-s…> * Visit the Wiki agenda page: https://community.icann.org/x/nYH3Cg * Check your time zone: https://tinyurl.com/m8c7umcx ONLY for Members and Participants * Please join via the above Main Zoom Webinar link and staff will promote you to panelist. * Please select Everyone, when posting to the chat in order for everyone to see and to be captured afterwards. Only for Observers: * Observers will have ability to view member chat and information shared in the zoom webinar room. * Observers will not be able to use chat or raise hands. Thank you. Kind regards, Devan

1 0

**REMINDER** Meeting Invitation | IDNs EPDP Team | Thursday, 20 January 2022 at 13:30 UTC
by Julie Bisland Jan. 19, 2022

Jan. 19, 2022

Dear all, The IDNs EPDP Team meeting is scheduled on Thursday, 20 January 2022 at 13:30 UTC for 90 minutes. Please click link to join the webinar: https://icann.zoom.us/j/94276275950?pwd=dG5hanFzMlpsYmh0NnFjTEQwOUV1dz09 <https://urldefense.com/v3/__https:/icann.zoom.us/j/94276275950?pwd=dG5hanFz…> Passcode: !!0tV0Wh&K For Audio only: One tap mobile : US: +13017158592,,94276275950#,,,,*5259149775# or +13126266799,,94276275950#,,,,*5259149775# Webinar ID: 942 7627 5950 Passcode: 5259149775 International numbers available: https://icann.zoom.us/u/adP1jJ0gRH <https://urldefense.com/v3/__https:/icann.zoom.us/u/adP1jJ0gRH__;!!PtGJab4!v…> If this is your first time with Zoom, please take a look here: Welcome to Zoom <https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/polic…> Members, participants, and observers all have different access and participation directions, please read below! ALL: Before joining the call * Please send dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only * Please be sure you have read the ICANN Expected Standards of Behavior <https://urldefense.com/v3/__https:/www.icann.org/resources/pages/expected-s…> * Visit the Wiki agenda page: https://community.icann.org/x/m4H3Cg * Check your time zone: https://tinyurl.com/4mr2byj5 [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/4mr2byj5__;!!PtGJab4!pYQ0pkq…> ONLY for Members and Participants * Please join via the above Main Zoom Webinar link and staff will promote you to panelist. * Please select Everyone, when posting to the chat in order for everyone to see and to be captured afterwards. Only for Observers: * Observers will have ability to view member chat and information shared in the zoom webinar room. * Observers will not be able to use chat or raise hands. Thank you. Kind regards, Devan

1 0

Proposed Agenda - IDN EPDP Meeting #20 - 20 January 2022 at 13:30 UTC for 90 minutes
by Steve Chan Jan. 19, 2022

Jan. 19, 2022

Dear all, Please find below the proposed agenda for our meeting on 20 January 2022 at 13:30 UTC. Kind regards, Ariel, Emily, and Steve IDN EPDP Meeting #20 Proposed Agenda 1. Roll Call & SOI Updates (5 minutes) 2. Welcome & Chair Updates / Update on GNSO Council Approach to IDN Implementation Guidelines v.4.0 (10 minutes) 3. Continued Deliberations on Topic A: Consistent Definition and Technical Utilization of RZ-LGR (Topic A working document: live version [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1I9dSd7alSvz9…> in Google Docs, archived versions in MS Word on wiki<https://community.icann.org/display/epdpidn/Working+Documents>) * Charter question A5 – impressions from meeting with SSAC members, brief presentation regarding allocatable variant labels in scripts through RZ-LGR (30 minutes) * Charter question A6 – deliberations on open items (see Open Items under A6 in the Draft Outcome document<https://docs.google.com/document/d/1Bt0LT45UaLynFNverh1nJhyvq6q6NxgSFAOnOp2…>) (40 minutes) * Time permitting, return to charter questions A7, A9, and A10 4. AOB (5 minutes) Steven Chan  Senior Director, GNSO Support Internet Corporation for Assigned Names and Numbers (ICANN) 12025 Waterfront Drive, Suite 300 Los Angeles, CA 90094-2536  Email: steve.chan(a)icann.org<mailto:steve.chan@icann.org> Skype: steve.chan55 Mobile: +1.310.339.4410 Find out more about the GNSO by visiting: https://learn.icann.org/<https://urldefense.proofpoint.com/v2/url?u=https-3A__learn.icann.org_&d=DwM…> Follow @GNSO on Twitter: https://twitter.com/ICANN_GNSO<https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_ICANN-5FGN…> Transcripts and recordings of GNSO Working Group and Council events are located on the GNSO Master Calendar <https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_en_grou…>

1 0

Notes and action items - IDNs EPDP Meeting #19 - 13 January 2022
by Emily Barabas Jan. 17, 2022

Jan. 17, 2022

Dear all, With apologies for the delay, please find below the notes from today’s meeting on Thursday, 13 January 2022 at 13:30 UTC. Kind regards, Ariel, Steve, and Emily Action Items: Action Item #1: EPDP Team members to provide input on draft text in response to charter question A6 and open items. Notes – IDNs EPDP Call – 13 January 2022 Welcome & Chair Updates * Staff shared draft text for a response to charter question a6. The leadership team has identified a number of questions for the EPDP team in the document. EPDP Team members are encouraged to review and provide feedback. These items will be discussed further on the 20 January call. * If there are any questions in the interim, please share them on the mailing list. Action Item #1: EPDP Team members to provide input on draft text in response to charter question A6 and open items. Engagement session with SSAC members to discuss SSAC's early input and additional Q&A General comments from SSAC members: * There is nothing technically in the DNS protocol or other technical protocols (e.g. SMTP for mail, X509 used in TLS) that indicates relationships between two strings that are called variants. Once in use, there is no difference between a variant and another domain name. They are two domain names. It is important to think about the implications of this and how it may be abused. * There might be cases where two strings are confusable. For confusability reasons, they can’t be given to two different registries. But there may be a business arrangement where they might be delegated to the same registry. * Clarification on the use of the term “confusable”: It might be the case that there are different rules if applications for two strings come from the same applicant or two different applicants. The term variant is one that is used between applicants and those that evaluate applications. Once delegated, there are only domain names. * Question: Have you had discussions about whether there needs to be a central index of strings that are variants in IANA? * Response: There have not been discussion of this issue. Each registry that handles variants keeps its own records. * This group needs to talk about how IDN variants are delegated first and then will talk about how this is tracked, for example in IANA. Question regarding responses to A1 & A4: * When looking at different characters and code points that can be allowed, we need to separate code points that are allowed in a zone as a whole vs. code points that are allowed in a label together. Sub domains to the domain may also have specific rules. * The SSAC recommends that the root zone must use one and only one set of rules for the Root LGR procedure for validation of TLD labels and their variants. * Clarification of the question: The comment on A4 seemed to imply that if the string was IDNA valid, it should be allowed. * Clarification: The RZ-LGR should be an absolute quantifier or rule set for what should be allowed in the root zone. If an existing TLD applies for a variant TLD label whose script is not yet supported by the applicable version of the RZ-LGR, then the best way is to put the application on hold, the community to work together to produce a LGR for that script and integrate into the LGR. Question regarding responses to A2: * SSAC members point to ccTLDs specifically because there may be a mix of policies with ccTLDs and gTLDs, so it is important to look at synchronized TLDs to ensure continuity of policies. Yes, the word variant in ccTLDs is wrong, the right term is “synchronized TLDs” * If such a situation mentioned in A2 did happen, the applicant can request a review on the LGR to see if LGR needs to be updated. It is important not to make ad hoc exceptions that could potentially undermine the LGR. * The existence of LGR not only set a boundary on the strings an applicant can apply for, it also creates a predictive environment for the users of domain names, in services, applications, user interfaces and ultimately the users that use these applications and services. ALAC question 1 regarding responses to A5 & C2: * Don’t blanket delegate all variants because you can. Look at the bundled experience you want users to have and only delegate the ones you need. The larger the set, the harder it is to keep everything synchronized. * Question: If the Registry is interested in applying for many variants, is there any reason that they should be prevented from doing so from the perspective of technical risks? * Response: This is too hypothetical to answer from the SSAC perspective. There is no ability to separate between two variants and two domain names from a technical perspective. The SSAC approaches the issue from this perspective. * Response: In a particular language community, the concept of variants is important. The SSAC is saying that it is hard to make that work, because there is no technical way to set this up. If you are going to make it work the way that a language community expects, there needs to be a lot of work done to make it work. If you are going to make it work, it is a lot easier to limit the number of variants in a bundle. From a security and stability standpoint, you can have as many as you want, as long as you keep them synchronized and do the work to do that. * As an example, if you have a language community with two very important variants, SSAC doesn’t see a problem for the community having a policy for allowing the applicant to have two labels for the price of one. But after the business transaction, the entity has two domain names. There is no technical solution to keep those variants together. * We already have examples in ccTLDs where they implement policies where variants don’t point to the same website. SSAC doesn’t have a problem with that from a technical point of view. This concerns business and policy. ALAC question 2 regarding responses to A5 & C2: * This follows from the suggestion to only instantiate variants that your language community needs. The SSAC recommends that the language communities are in a better position than SSAC to make decisions about criteria for limits. In making that decision, the people involved should keep in mind that every time they add to the bundle, they add to the challenge of managing the bundle. * Question: No one really speaks for a language community authoritatively, so how can this be implemented? Possible alternative – criteria for a registry to demonstrate in the application process that it is in a position to effectively manage the variants it is requesting. * Response: There may be different elements of this evaluation depending on what is being proposed in terms of variants. * Question: Was some of this thinking done with ccTLDs in mind? The ccTLD Fast Track process was relatively fast moving compared to the gTLD process. Was there any thinking in the SSAC discussion about the differences? * Response: I don’t believe the differences were discussed. * From an application evaluation standpoint, how can one determine whether an applicant is capable of making a set of variants work? There are not technical tools to make that work. This is a problem for the EPDP to solve. * Question: Could the SSAC help in thinking about the things that need to be synchronized to make variants work? This would help formulate a list of things for an evaluator to consider? * Answer: It’s not possible to make a complete list because we don’t know how the domains will be used. * Answer: It’s possible to provide illustrative examples, but would be concerning if those examples were converted into definitive criteria. Jeff’s questions regarding A5: * Apply a very tight limit at the start to ensure that you have a conservative start. As operators gain experience, you may decide to make the rules more permissive. · Start with the question: Is one label sufficient? If not, are two sufficient? If not, which candidate variants are uniquely differentiated from the primary label, widely used in the community? · For example, the Chinese community allows for three variant labels, one which has been applied-for, one which is the Simplified Chinese version and one which is the Traditional Chinese version. A similar limit may be imposed in the beginning to ensure conservatism, and which may be relaxed over time, as the community gains experience with IDN variant TLD delegation and associated usability and manageability challenges. * There could be cases where more variants than are necessary may be applied for because of economic value, but there is concern that hundred or tens of variants for a label may create technical and management challenges for the parties involved. * Question: How do you apply the proposed questions above in practice? An applicant for variants will always argue that they are necessary. How can you evaluate what is or is not necessary? * Response: The SSAC advises a conservative approach initially rather than a self-regulatory system. The SSAC is not assuming that actors or good or bad. The SSAC is interested in reducing the risk of a combinatory explosion. * It is for policy work to define synchronization and determine how synchronization can be achieved. * This combinatorial explosion creates a stability issue at both registrars and registries, and will likely complicate account management and user experience for registrants. Questions regarding B3 and C4a: * We call them variants, but in fact they are different domain names. Whatever you do to make them the same in practice is entirely up to the registrant. Any policy you make is going to be something you cannot do mechanically. You can make rules, but they need to be phrased in a way that is not technical. * In practice the implementation of variants has been poor. If we are going to make a good user experience better, we need to make sure that that measures are in place to implement them more effectively. Example: .cat d-names. * Issues can come up anywhere you have to compare two versions of a name. It’s not just an issue of DNS lookups. Additional questions: * Question: Most registries now just activate one name and block the variants? * Response: Correct, most follow this model. * Question: Is there a technical barrier to having a policy that allows a registrant to switch which is the primary and which is the variant at the second level. * Response: The cause for concern is if the variant is going to a different registrant, but there is otherwise not a technical concern.

1 0

Post Call | IDNs EPDP Team call | Thursday, 13 January 2022 at 13:30 UTC
by Devan Reed Jan. 13, 2022

Jan. 13, 2022

Dear all, All recordings for the IDNs EPDP Team call held on Thursday, 13 January 2022 can be found on the agenda wiki page <https://community.icann.org/x/iYH3Cg> (attendance included) and the GNSO Master Calendar. <https://urldefense.com/v3/__https:/gnso.icann.org/en/group-activities/calen…> These include: * Attendance (please let me know if your name has been left off the attendance list) * Audio recording * Zoom chat archive * Zoom recording (including audio, visual, rough transcript) * Transcript For additional information, you may consult the mailing list archives <https://mm.icann.org/pipermail/gnso-epdp-idn-team/> and the main wiki page<https://community.icann.org/x/uAPpCQ>. Thank you! Kind Regards, Devan

1 0

Meeting Invitation | IDNs EPDP Team | Thursday, 20 January 2022 at 13:30 UTC
by Devan Reed Jan. 13, 2022

Jan. 13, 2022

Dear all, The IDNs EPDP Team meeting is scheduled on Thursday, 20 January 2022 at 13:30 UTC for 90 minutes. Please click link to join the webinar: https://icann.zoom.us/j/94276275950?pwd=dG5hanFzMlpsYmh0NnFjTEQwOUV1dz09 <https://urldefense.com/v3/__https:/icann.zoom.us/j/94276275950?pwd=dG5hanFz…> Passcode: !!0tV0Wh&K For Audio only: One tap mobile : US: +13017158592,,94276275950#,,,,*5259149775# or +13126266799,,94276275950#,,,,*5259149775# Webinar ID: 942 7627 5950 Passcode: 5259149775 International numbers available: https://icann.zoom.us/u/adP1jJ0gRH <https://urldefense.com/v3/__https:/icann.zoom.us/u/adP1jJ0gRH__;!!PtGJab4!v…> If this is your first time with Zoom, please take a look here: Welcome to Zoom <https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/polic…> Members, participants, and observers all have different access and participation directions, please read below! ALL: Before joining the call * Please send dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only * Please be sure you have read the ICANN Expected Standards of Behavior <https://urldefense.com/v3/__https:/www.icann.org/resources/pages/expected-s…> * Visit the Wiki agenda page: https://community.icann.org/x/m4H3Cg * Check your time zone: https://tinyurl.com/4mr2byj5 ONLY for Members and Participants * Please join via the above Main Zoom Webinar link and staff will promote you to panelist. * Please select Everyone, when posting to the chat in order for everyone to see and to be captured afterwards. Only for Observers: * Observers will have ability to view member chat and information shared in the zoom webinar room. * Observers will not be able to use chat or raise hands. Thank you. Kind regards, Devan

1 0