October 2023 - Gnso-epdp-idn-team

Phase 1 Final Report for Approval - by EOB Tuesday, 7 November
by Ariel Liang 13 Nov '23

13 Nov '23

Dear All, Following the completion of the consensus call process of the Phase 1 final recommendations, we are sending the draft Phase 1 Final Report for your review and approval by EOB Tuesday, 7 November. Please find the PDF document attached. Please share on list or email staff if you spot any typo, grammatical error, or other editorial issues. According to our project plan, we are expected to submit the Phase 1 Final Report to the GNSO Council no later than 9 November. Congratulations to everyone for this amazing work done! Also, we want to express our immense appreciation to Donna and Justine for their leadership in shepherding this policy effort. Let’s keep this momentum for Phase 2 deliberation, and fingers crossed we will see the light at the end of the tunnel very soon. Thank you all! Ariel, Steve, Dan

2 5

**MEETING CANCELLED** Meeting Invitation | IDNs EPDP Team | Thursday, 02 November 2023 at 12:00 UTC
by Devan Reed 30 Oct '23

30 Oct '23

**This meeting has been cancelled. Please remove it from your calendars. Dear all, The IDNs EPDP Team meeting is scheduled on Thursday, 02 November 2023 at 12:00 UTC for 2 hours. 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/bAJ6E * Check your time zone: https://tinyurl.com/3622utwt [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/3622utwt__;!!PtGJab4!9mTxOM5…> 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

Canceled: IDNs EPDP Team meeting
by ICANN Policy Calendar 30 Oct '23

30 Oct '23

Meeting: IDNs EPDP Team Date/time: Thursday, 02 November 2023 at 12:00 UTC for 2 hours 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 page: https://community.icann.org/x/bAJ6E * Check your time zone: https://tinyurl.com/3622utwt 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.

1 0

Photos from ICANN78
by Ariel Liang 27 Oct '23

27 Oct '23

Dear All, So wonderful seeing the members and participants who participated in ICANN78 in person. And thanks very much to those who joined us remotely. You are surely missed! The ICANN photographers captured some moments during our first working session on Saturday. Sharing these with you for good memories. https://drive.google.com/drive/folders/12yZeoIBY7vCdyfZiYL1Palef_bSGOBL3?us… See you online soon! Best Regards, Ariel

1 0

Meeting Invitation | IDNs EPDP Team | Thursday, 02 November 2023 at 12:00 UTC
by Devan Reed 25 Oct '23

25 Oct '23

Dear all, The IDNs EPDP Team meeting is scheduled on Thursday, 02 November 2023 at 12:00 UTC for 2 hours. 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/bAJ6E * Check your time zone: https://tinyurl.com/3622utwt 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

IDNs EPDP Team meeting
by ICANN Policy Calendar 25 Oct '23

25 Oct '23

Meeting: IDNs EPDP Team Date/time: Thursday, 02 November 2023 at 12:00 UTC for 2 hours 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 page: https://community.icann.org/x/bAJ6E * Check your time zone: https://tinyurl.com/3622utwt 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.

1 0

Notes from EPDP IDNs Sessions at ICANN78
by Daniel Gluck 25 Oct '23

25 Oct '23

Moin! Please find below the notes and action items from the three EPDP IDNs sessions in Hamburg. Here are the wiki space pages for all three sessions: Session 1: https://community.icann.org/x/KgGWDw Session 2: https://community.icann.org/x/LAGWDw Session 3: https://community.icann.org/x/LgGWDw Best Regards, Ariel, Steve, and Dan SESSION 1 ACTION ITEMS * Limited the text for the definition of Source Domain Name by linking to the recommendation, to avoid redundant or contradictory text. * Revise definition to ensure adherence of the same entity principle and make clear that the disposition value is a part of the definition. SESSION 1 NOTES Roll Call and SOI Updates * None Welcome and Chair Updates * Started consensus call on Phase 1 recommendations and today is the deadline. Heard back from registrars and ALAC. No response is assumed to mean support. Expect to hear from the GAC as well. Once midnight hits, it means we have hit an enormous milestone and will deliver the Final Report to the Council no later than 9 Nov. * Goal for sessions at ICANN78 is to make progress on Phase 2 questions. Continued Discussion of Source Domain: D4 * Slide 4: Refresher - Source Domain Name * Slide 5: Open questions remain. Question 1: Should there be one source domain name per gTLD? * Preliminary Agreement is that yes, there should be one source domain identified per gTLD. * Slide 6: Example shows that the valid labels can differ between each gTLD, and a given variant. * Persian, Arabic, Urdu use the same script, but languages might not use the same character set. Otherwise, no objections to the preliminary agreement. * Slide 7: Question 2: Must the source domain name be register? * Preliminary Agreement: The source domain name must be registered but may or may not be activated. No objection to the preliminary agreement. * Slide 8: Michael B proposal - It should be possible to delete or change a source domain name as long as its active variant domain names remain allocatable. * Slide 9: Question 3: Can a source domain name be changed or deleted? * Preliminary Agreement: No need to prescribe policy recommendation in response to this question. * Certain attributes of a domain name cannot be edited. The string in particular cannot be edited. It must be deleted and re-registered. If the source is deleted, the rest of the variants should also conclude their lifecycle. Essentially, there should be no remnants from the variant set. * Slide 10: Source Domain Name and Variant Domain Set are suggested items to be included in the Glossary. Definitions are suggested and were read out to the team during the meeting. * Suggestion to add: “should be at the second-level (or levels for which the registry provides registration for)”. Some concern that the recommendations have been limited to the second level. * Suggestion that the recommendation should be limited to the second level since the contracts generally do not prescribe actions for the third level. Third level and beyond, if allowed, are generally up to the registrant to manage. * Agreement with this comment and belief that this question is actually out of scope. IDN tables are actually not even required at the third level and beyond. * Confirmation that the text related to the registrant and sponsoring registrar jointly identify the primary source domain is also captured as a recommendation. * Suggestion to remove the last sentence since it’s also captured in the recommendation. Could also reference recommendation for clarity and consistency. * Concern/question: Are we creating rules beyond the extent of IDNs? There are generally not variants for non-IDNs. * Suggestion that the recommendations and definitions must be consistent. Agreement that this is indeed important. Action Item: Limited the text for the definition of Source Domain Name by linking to the recommendation, to avoid redundant or contradictory text. * For the Variant Domain Set definition, it is currently limited to the primary gTLD. Would it be extended to variant gTLDs? It would seem that this definition should be consistent with the preliminary agreement [add reference to agreement] * Might need another layer to connect variant domain sets across gTLD variants. This coherence is needed to help ensure the same entity principle is applied across the gTLD variants. * The definition is not clear whether or not the disposition values are a part of the set. * Clarified that the top-level definition does in fact include the disposition value, so there might be a benefit to be consistent. * Question whether the disposition terminology is the same for top-level and second level. Confirmation that the terminology is consistent. * Suggestion that the definition should include domain names across all of the variant gTLDs, which would aid in the issue of ensuring same entity across the variant gTLDs. Action Item: Revise definition to ensure adherence of the same entity principle and make clear that the disposition value is a part of the definition. Identifying the Same Registrant: C3, C3a * CPH TechOps was requested to provide a presentation on this topic. * Slide 12: Preliminary Recommendation 2: The “same entity” principle applies to the activation of future variant domain names. This means that all allocatable variant domain names from a variant domain set must be activated or withheld for possible allocation only to the same registrant at the same sponsoring registrar. * Slide 13: Context about charter questions C3 and C3a * Slide 14: Domain Name Registration flow and parties involved. * A person or entity wanting a certain domain name goes to a registrar, which communicates with the registry (via EPP). The EPP command is domain create, which includes the domain name and the required registrant information. This command is a billable transaction. * The result is either a confirmation or an error output. If successful, the entry gets added to the database and registration data server. * For variant activation (not necessarily registration, since it might not require an EPP command), it could be a create command (which would be billable) or an update command (which would not be billable). * Need to consider resellers, who might not be able to easily determine or enforce same entity rules who are in some ways, like a registrant in terms of information known. Registrar sees the reseller contacts, not necessarily for the ultimate registrant. SESSION 2 ACTION ITEMS * Develop a response to this charter question. There will not be a recommendation to prescribe a mechanism. * Consider getting data about usage of ROID, for inclusion in rationale. SESSION 2 NOTES * For resellers, this question is likely relevant for the next part of our conversation. * RAA already has provisions about responsibilities of registrars vis a vis their resellers. * Question about who is maintaining the RDDS information and how to enforce the same entity requirements. * There are two instances of the RDDS information - at the registry and registrar level, with potentially different levels of data. * How to enforce same entity requirements when the registration data is that of the registering party, not necessarily the registrant. The true registrant information is masked. * For privacy proxy and for masked registration data, the responsibility resides with the registrar to enforce. * Slide 15: Refresher on ROID, which C3 suggested as the mechanism to enforce same entity requirements. All registry contacts, including domain objects, have a ROID. * Under GDPR, using the same ROID helps associate domains to a single entity. * Slide 16: Refresher on ROID cont., which includes benefits and drawbacks. * The point about a ROID being assigned after domain creation is not accurate. The ROID is assigned before. * Slide 17: Where we left off. * Question 1: Should ROID be used to identify a registrant as the same entity? * ROID may be a reasonable mechanism, but contracted parties cannot be forced to use it * Question 2: In, what would be a better mechanism? * A joint responsibility between the registry and the registrar to identify the same registrant; The registry enforces the same registrar, and the registrar enforces the same registrant; Registry may have to reuse contact object IDs * Question 3: Any additional info needed for this discussion? * ACTION: RySG and RrSG members to take solicit input from CPH TechOps group regarding verifying the same registrant, also taking into consideration implications of resellers * Slide has summarized CPH TechOps well. Reinforced that ROID is sometimes not available, such as in thin registries. The logic for determining what are variants resides with the registry. The relationship with the registrant resides with the registrar. The CPH TechOps has talked about developing an EPP command to help with managing these transactions. * The registry identifies the variants. * The registrar ensures that the same entity check has completed. * ROID currently is not fit for purpose. Could an extended ROID make sense? How to extend same entity across gTLDs? * Would the registrars be told how to enforce same entity, or do they just need to comply with the requirement? The suggestion from CPH TechOps is yes, enforce the requirement as they see fit. * Clarification: ROID is often sufficient, but in some cases, it is not. Therefore, it is problematic as a hard requirement. * EPP creates interoperability. But EPP Extensions can be different across registries. * Data does not, or cannot, be transferred across registries. ROID does not translate across registries. * Could consider noting that the ROID is sensible, in the context of implementation guidance. Should consider the impact of data escrow, or how the relational nature of the set is captured in the registration data. * Data is escrowed at the registry and the registrar level, separately. All of the registration data will be escrowed. * Model 3 could have split responsibilities but define the allowable method(s). * Question about whether the use of ROID is directly linked to thick versus thin registration data. * Question about how many registries do not use ROID? Which parties would not be able to meet a requirement to use ROID? * Even if all registries use ROID, registrars are not required to reuse ROID. * COM, NET, JOBS are thin registries. The registration data policy will transfer the discussion to the minimum data set. ROID is not currently included in that minimum data set. * Could the recommendation be about the registries and registrars agreeing to develop a mechanism be a way to go? Currently, there are already two ways to establish variant domain names. The CPH desire is to stay at the level of what is to be accomplished, but not prescribe the how. * There are a lot of moving parts, which makes it hard to recommend a singular way to enforce the same entity requirement. * Noted that from a contractual point of view, there is no shared responsibilities. The registries and the registrars are independently responsible for their respective requirements. Registry would enforce same registrar and the registrar would enforce same registrant. * If we end up with various mechanisms to enforce same entity, will it create consistency issues across the industry (e.g., EPP, data escrow). Within the single gTLD, there will only be a single model. * Support to concentrate on just the goal of what is desired to be accomplished and leave details to implementation. * Concern that the same registrar requirement forces a registrant to use the same registrar for any variant domain names. If a registrant is displeased with a registrar, they are free to move to another registrar. * It does not seem that models 1 or 2 are the answers. However, the agreement is that the policy recommendation will be about the same registrar and same entity. * During pre-delegation testing, this may create a more challenging testing environment for evaluation of the RO/RSP. This seems to be out of scope for the IDNs EPDP. * The question could be different for an RO versus RSP. RO would be asked how and the RSP would be asked to confirm that they can do it. Action Item: Develop a response to this charter question. There will not be a recommendation to prescribe a mechanism. Action Item: Consider getting data about usage of ROID, for inclusion in rationale. Variant Domain Transaction Fees: D5 * Slide 21: Review of charter question. Similar to Phase 1 charter question. * Slide 22: Discussion Question: Once a source domain name is registered by a registrant, its allocatable variant domains may be calculated for potential activation. If the registrant decides to activate one or more of its variant domains, should ICANN charge the $0.18 mandatory annual fee for each year of registration, renewal, or transfer of each activated variant domain? * Noted that registries also pay a fee for <50k, as well as an incremental cost per additional DUMs. * The answer may be that it depends. There are two models to activate a variant, either use EPP create or EPP update command. The first would incur a fee, the latter would not. * Belief that the source and variants should all be treated as registrations, upon activation. * The variants will not always have the same lifecycle as the primary. How would that affect the billing cycle? This scenario would come from EPP create and would result in separate charges. The two models exist now for registries. * Suggestion that the registrant usage should potentially dictate the fee structure. Concern about going into these aspects for our discussions. * There seems to be agreement that the source domain must be first. Currently, some registries choose to treat as create versus others that treat as updates. To dictate a single model now would change the approach for existing registrants. * However, the existing registrations could be grandfathered if the EPDP wants to recommend a single approach. * Question about whether the Phase 1 recommendation would be inconsistent if the EPDP elects to keep the status quo (i.e., allow for variable treatment of create or update). The Phase 1 recommendation seems to assume that each variant should be treated as an independent registration. * It seems that create would be counted, but update would not. So, no inconsistency is created * The intent could be inferred. If the usage is similar/interlinked, maybe it’s update? And if the usage is independent, maybe it’s created? Noted that the status quo is not documented, it is just what is done. This EPDP could therefore enshrine the current practices. * We need to be careful to not infringe on current implementation models since registry models are built upon what is counted as a billable transaction. * Should our recommendation be at the high level, of what the goal is for the recommendation? SESSION 3 ACTION ITEMS Leadership will review the notes and transcript to best determine how to address Charter Question D5 SESSION 3 NOTES * Roll Call and SOI Updates * Welcome and Chair Updates * The Chair welcomed everyone to the meeting and handed the mic over to GNSO Chair Sebastian Ducos for some remarks * The GNSO Chair congratulated the EPDP team on achieving full consensus for the Phase 1 Final Report * The EPDP Chair thanked the GNSO chair and congratulated the team as well * Continued Discussion of Source Domain: D4 * Staff then introduced the topics for the day, including the continued discussion regarding the source domain. * Staff asked if there was any comment or question from the team, but there was no objection for the rationale updates for Preliminary Rec 5 * Identifying the Same Registrant: C3, C3a * Staff described the updates to developing responses to the charter questions C3 and C3a. * This received approval in chat from multiple team members * Variant Domain Transaction Fees: D5 * Staff described the preliminary recommendation to capture the agreement about mandatory annual fees for registration, renewal, or transfer for each REGISTERED variant domain name. Activated variant domain names would not be charged the annual fee. * One team member commented that this might not be necessary. If a variant is not registered, then it doesn't get charged. They are not sure why it would have to be * The chair replied that they would like to view the language in the registrar and registry agreements regarding this as it might not matter if it is in or not in a variant domain set. “A domain name is a domain name is a domain name” * A team member commented in chat with the following excerpt from the registry agreement “The registry-level transaction fee will be equal to the number of annual increments of an initial or renewal domain name registration (at one or more levels, and including renewals associated with transfers from one ICANN-accredited registrar to another, each a “Transaction”), during the applicable calendar quarter multiplied by US$0.25” * Taken from Article 6, 6.1 Registry-Level Fees: https://itp.cdn.icann.org/en/files/registry-agreements/nrw/nrw-agmt-html-21… * Another team member commented “situation where some registries are to pay for each variant in the set and some not - is going to be a huge issue” * They spoke about the possibility of angering regulators and tax agencies about this. * The chair mentioned they would like to get to an understanding where it doesn't matter if the registered domain is being used as part of a variant set or not. It should be treated equally * A different team member questioned legal distinction between registration and activation * The chair replied that registration is a specific process and that garners a fee being charged. * There is a need to clear up language regarding this * The vice chair discussed the meaning of registration. * “If the domain name is used, will it trigger fees” * The vice chair continued, what are the use cases of activating but not registering? * One team member discussed the process of reserved domain names * If you change the property of a reserved variant, it should not incur a fee, they suggested. * The GNSO Chair discussed that Reserved Names are set aside for future registrations. If the name applied for is on this list of set asides, then the application fails. · They are not sure how this applies to this question. * A team member posted: “if the result of activation is indistinguishable from the results of the activation - there is an issue in courts around the globe. it sounds pretty much like an allocation without the registration. I think registered domains without NS records are still used , at least as a proof in UDRP or courts. fees are not applicable to reserved names. reserved might be different from allocation or can mean the same depends on the implementation. fees are for registered domains” * They continued by talking about the process including escrow and accounting. For the reasons of potentially * Another team member described the two labels that can be applied for registrars regarding this process in EPP: Escrow and Not a Domain Name (NADN) * The chair mentioned that this depends on the registry policy * A team member from the RySG mentioned that if the registry policy says that a variant domain name is the same as a regular domain name, then it goes through the regular reporting and billing process. * If variant domain names are qualified in a different way, then they won't trigger the billing process. * The same entity principal enforcement is also going to be key, per a different team member. * The chair mentioned that there is a fee associated with each domain name. Leadership will research appropriate language that will future proof for variant domains at the second level. It should not be convoluted and can probably be thought of as being straight forward. * ACTION ITEM: Leadership will review the notes and transcript to best determine how to address Charter Question D5. * A team member asked whether or not ICANN receives a fee for every registered domain name. If yes, they believe there should be a fee. Whether or not a registry charges for variants, they should have to pay for them. If they want to make it free, then it is a marketing expense. * A member of staff asked if there are different ways for domains to come into the DNS and serve content, but some can be billable and some cannot. * One way to instantiate a domain is to put an EPP create command in, which creates a billable transaction * Another method is to activate a domain, it serves content, but it is not billable. * There is not alignment on this, but this seems to be the general understanding * The chair is not concerned with updating processes and lower-level information; they are concerned at the high level. * The GNSO chair delineated transaction vs domain names. ICANN will match the amount of domain names to what the registrars report. * AOB * The chair thanked Dennis Tan for his fantastic work and efforts for this group subject matter. * Staff provided an update on the final reporting process, pursuant to the final deadline of 7 November for delivery to the GNSO council. * The chair announced they would like to finish all charter questions by the time they leave the Kuala Lumpur Face-to-Face meeting.

1 0

Re: [Gnso-epdp-idn-team] Consensus Call for EPDP-IDNs Phase 1 Final Recommendations: 12 October - 21 October 2023
by Ariel Liang 22 Oct '23

22 Oct '23

Dear All, This message is to notify you the closing of the consensus call process on the EPDP-IDNs Phase 1 final recommendations. Many thanks to the positive responses from RrSG, ALAC, NCSG, RySG, and GAC representatives. Given that there is no disagreement by the EPDP Team with the proposed consensus designations by the leadership team, staff will incorporate them into the Phase 1 Final Report. To confirm, all of the Phase 1 final recommendations received “full consensus” designation. Congratulations to the EPDP Team on achieving this major milestone!! Best Regards, Ariel From: Gnso-epdp-idn-team <gnso-epdp-idn-team-bounces(a)icann.org> on behalf of Ariel Liang <ariel.liang(a)icann.org> Date: Thursday, October 12, 2023 at 9:51 PM To: "gnso-epdp-idn-team(a)icann.org" <gnso-epdp-idn-team(a)icann.org> Subject: [Gnso-epdp-idn-team] Consensus Call for EPDP-IDNs Phase 1 Final Recommendations: 12 October - 21 October 2023 Dear EPDP Team Members, On behalf of the leadership team, and as discussed during meeting #100<https://community.icann.org/x/1YyZDg> on Thursday, 12 October, this message is to notify you of the opening of the Consensus Call process on the EPDP-IDNs Phase 1 final recommendations. The leadership team has proposed a consensus designation for every final recommendation that the EPDP Team has finalized by 12 October. These consensus designations are contained in the attached document titled “Leadership Proposed Consensus Designation”. This Consensus Call process opens today, Thursday, 12 October 2023 for a 10-day period, closing on Saturday, 21 October 2023. In accordance with the GNSO Working Group Guidelines, EPDP Team Members are required to indicate via reply to this message whether they accept, or do not accept, the leadership team’s proposed consensus designations. If no objection is raised by any Member, the consensus designation is considered accepted by that EPDP Team Member. If you do not respond before 21 October 2023, the leadership team will take this as acceptance of the consensus designations. If any objection is raised for any specific final recommendation(s), the leadership team is expected to reevaluate the consensus designation of such recommendation(s) and publish an updated designation to be reviewed by the EPDP Team. In the event there is no disagreement by the EPDP Team with the proposed consensus designations, staff will incorporate them into the Phase 1 Final Report. As set out in the EPDP Team charter, only Members appointed by their representative groups are expected to participate in the Consensus Call process. Participants and observers will not be able to participate. For reference, please see the attached document titled “Phase 1 Final Recommendations” that contains the sixty-nine (69) recommendations and contextual language to be included in the Phase 1 Final Report. For more information about Consensus Call, you may review the GNSO Working Group Guidelines [gnso.icann.org]<https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/file/…> (Section 3.6) and EPDP Team Charter [gnso.icann.org]<https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/polic…> (Section VI: Decision Making Methodologies). Best Regards, Ariel, Steve, Dan

7 7

Consensus Call for EPDP-IDNs Phase 1 Final Recommendations: 12 October - 21 October 2023
by Ariel Liang 21 Oct '23

21 Oct '23

Dear EPDP Team Members, On behalf of the leadership team, and as discussed during meeting #100<https://community.icann.org/x/1YyZDg> on Thursday, 12 October, this message is to notify you of the opening of the Consensus Call process on the EPDP-IDNs Phase 1 final recommendations. The leadership team has proposed a consensus designation for every final recommendation that the EPDP Team has finalized by 12 October. These consensus designations are contained in the attached document titled “Leadership Proposed Consensus Designation”. This Consensus Call process opens today, Thursday, 12 October 2023 for a 10-day period, closing on Saturday, 21 October 2023. In accordance with the GNSO Working Group Guidelines, EPDP Team Members are required to indicate via reply to this message whether they accept, or do not accept, the leadership team’s proposed consensus designations. If no objection is raised by any Member, the consensus designation is considered accepted by that EPDP Team Member. If you do not respond before 21 October 2023, the leadership team will take this as acceptance of the consensus designations. If any objection is raised for any specific final recommendation(s), the leadership team is expected to reevaluate the consensus designation of such recommendation(s) and publish an updated designation to be reviewed by the EPDP Team. In the event there is no disagreement by the EPDP Team with the proposed consensus designations, staff will incorporate them into the Phase 1 Final Report. As set out in the EPDP Team charter, only Members appointed by their representative groups are expected to participate in the Consensus Call process. Participants and observers will not be able to participate. For reference, please see the attached document titled “Phase 1 Final Recommendations” that contains the sixty-nine (69) recommendations and contextual language to be included in the Phase 1 Final Report. For more information about Consensus Call, you may review the GNSO Working Group Guidelines<https://gnso.icann.org/sites/default/files/file/field-file-attach/annex-1-g…> (Section 3.6) and EPDP Team Charter<https://gnso.icann.org/sites/default/files/policy/2021/presentation/Charter…> (Section VI: Decision Making Methodologies). Best Regards, Ariel, Steve, Dan

7 7

Notes and Action Items - IDNs EPDP Meeting #100 - 12 October 2023
by Daniel Gluck 17 Oct '23

17 Oct '23

Hi All, Please find below the notes and action items from the 12 October 2023 IDNs EPDP meeting #100<https://community.icann.org/x/1YyZDg> at 12:00 UTC. Best Regards, Ariel, Steve, and Dan ACTION ITEMS * The team will book travel for the Face-to-Face workshop by 16 October * The team will complete the Consensus Call Process by 21 October * Leadership will review the language used in the D4 Team Response, but recommendations will not be changed at this time. * The ALAC team will review Preliminary Recommendation 5 and the proposed edits in the document. NOTES * Roll Call and SOI Updates (2min) * Welcome and Chair Updates (5min) * The Chair welcomed everyone to the 100th call of the EPDP WG. * They also reminded the team about the December face-to-face meeting in Kuala Lumpur and the travel notices that were sent by ICANN Travel Support, which has a deadline for booking of 16 October. * ACTION ITEM: The team will book travel for the Face-to-Face workshop by 16 October * Review of comments on Rec 3.5, IG 3.6, and Rec 4.4 (20) * Staff went over the scenario of a gTLD variant application and ccTLD application being submitted at the same time and what would happen. * In the proposed text shared by Leadership in 4.4.3.1 this is accounted for, and this received support from the Team. * There was a discussion about the role of ccTLDs and GeoTLDs for 4.4.3.2. * There may be a need to clarify 4.4.3.2.2 and specify the role of GeoTLDs * One team member asked if this is related to string similarity * Another proposed changing “required approval” to “when required” to 4.4.3.2.1 to cover cases where Geographic TLD applications are required but also as to not preclude other types of applications. * This was agreed to by the team * Staff added to the discussion by saying the text in 4.4.3.2.1 originally came from the 2012 Applicant Guidebook * Staff discussed the change from “contention” to “conflict” to be clearer in 4.4.3.3 that this is not about string contention resolution, but other conflict. * This was agreed to by the team. * Finally, staff discussed updated rationale language in the document to reflect changes made over the past meetings and proposals from the team. * This included the change from “retrospective” to “retroactive” throughout the document to better reflect the actual intent of the policy * The chair reminded the team that pending no further comments, the language presented in the Phase 1 Final recommendations during this call will be the language put into the Consensus Call. * There were no additional comments, and the text should be considered final * Review of Consensus Call Procedures * The updated timeline for the Consensus Call process was shared * The Consensus Call will be initiated today, 12 October and concluded no later than 21 October (during ICANN78). * ACTION ITEM: The team will complete the Consensus Call Process by 21 October. * If there are any challenges to consensus designations, they will be resolved no later than 23 October. * The goal is to inform the GNSO council of a finalized Phase 1 Final Report on 25 October. * Minority Statements would be due 30 October, if applicable. * 9 November is the deadline for submission for the Phase 1 Final Report. * The process was summarized, with the designations of consensus call being described, as well as the steps from initiating the Consensus Call, Confirming Member acceptance / non-acceptance, Drafting of Minority Statements, and the Final Report Documentation. * The levels of designation for consensus were asked about by a member of the team. It was shared that the GNSO uses their own levels of consensus and that is why they may seem different than the levels used in other SO/ACs. * Consensus decisions are made on an individual member basis, unless a Group has more than one representative, then they will speak together. Each delegation will get one vote. * Review of the phase 2 charter questions (90min) * There was a discussion on the language in Preliminary Recommendation (PR) 2 * It was suggested to replace registered with activated, which was agreed to by the team after clarification by the recommender. * Rationale for PR 2 and PR 3 were also discussed in relation to the grandfathering recommendation in PR 2 and general wording questions in PR 3 * The D4 team response was discussed for the proposed change from “allocatable” to “allocated” and the technical background for the lifecycle of the process. * This seems to be addressed in Final Recommendation 9.3 of the Phase 1 Final Report. * The flow chart in the recommendation visualizes this correct verbiage to use but does not adequately address allocated vs allocatable. * Per the chart, allocatable encompasses withheld-same-entity, delegated, allocated * ACTION ITEM: Leadership will review the language used in the D4 Team Response, but recommendations will not be changed at this time. * Rationale is a possible venue to reflect these ideas. * The rationale for PR 5 received a few comments and edits that were discussed. Specific cases for source labels were discussed * Each namespace has its own rules. They are independent gTLD and the registries set their own processes. A team member discussed this along with the process to calculate the disposition of a variant domain under a variant gTLD in a superset. The primary gTLD source is straightforward but adding a variant gTLD in the set complicates the matter. * One recommendation would be for the registrant to select the primary label for each variant gTLD. Not one primary label across ALL variant gTLDs, but one per EACH gTLD. * A question from a different team member about source disposition was asked about whether they must be registered and how they will be defined. * The proposed edits will be accepted after discussion by the team, which is believed to be sufficient to address the above discussion. * ACTION ITEM: The ALAC team will review Preliminary Recommendation 5 and the proposed edits in the document. * There was also discussion related the topic addressed in RFC 2119 (Should vs Must) * The rationale for PR 5 will be addressed at ICANN78, as well as PR 5 itself at a later date. * AOB (3min) * Leadership and Staff discussed a plan / rough agenda for ICANN78. Probable topics include: * Continued Discussion of Source Domain: D4 * Identifying the Same Registrant: C3, C3a (TechOps presentation) * Variant Domain Transaction Fees: D5 o There will be no Call on 19 October due to ICANN78 Travel. o The Chair wished everyone safe travel to Hamburg and adjourned the meeting.

1 0