<div dir="ltr">Emily <div><br></div><div>Good afternoon; thanks for this; just realised no Call today (Happy Thanksgiving to all); but also wondered about next week; 1st December, as thought we were not meeting as many of us involved in UN IGF (but may be wrong); </div><div><br></div><div>best</div><div><br></div><div>Nigel </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 17 Nov 2022 at 15:31, Emily Barabas <<a href="mailto:emily.barabas@icann.org">emily.barabas@icann.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">





<div lang="en-BE" style="overflow-wrap: break-word;">
<div>
<p class="MsoNormal"><span lang="EN-US">Dear all, <u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">Please</span><span style="color:black"> find below the notes
</span><span lang="EN-US">and action items </span>
<span style="color:black">from today’s meeting on </span><span lang="EN-US" style="color:black">Thursday</span><span lang="EN-US">,<span style="color:black">
</span>17 November 2022 </span><span style="color:black">at </span><span lang="EN-US" style="color:black">1</span><span lang="EN-US">3<span style="color:black">:</span>3<span style="color:black">0</span></span><span style="color:black"> UTC.</span><span>
</span><span lang="EN-US"><u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">Kind regards,<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">Ariel, Steve, and Emily<u></u><u></u></span></p>
<div style="border-top:none;border-right:none;border-left:none;border-bottom:1.5pt solid windowtext;padding:0cm 0cm 1pt">
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
</div>
<p class="MsoNormal"><b><u><span lang="EN-US"><u></u><span style="text-decoration:none"> </span><u></u></span></u></b></p>
<p class="MsoNormal"><b><u><span lang="EN-US">Notes and Action Items - </span></u></b><b><u><span lang="EN-US" style="color:black">IDNs EPDP Call –
</span></u></b><b><u><span lang="EN-US">17 November<span style="color:black"> 2022</span><u></u><u></u></span></u></b></p>
<p class="MsoNormal"><b><u><span lang="EN-US"><u></u><span style="text-decoration:none"> </span><u></u></span></u></b></p>
<p class="MsoNormal"><b><u><span lang="EN-US">Action Items<u></u><u></u></span></u></b></p>
<p class="MsoNormal"><b><u><span lang="EN-US"><u></u><span style="text-decoration:none"> </span><u></u></span></u></b></p>
<p class="MsoNormal"><b><span lang="EN-US">Action Item 1</span></b><span lang="EN-US">: EPDP Team members to review input from ICANN org and send any clarification questions to the mailing list.
</span><span lang="EN-US" style="font-size:12pt"><u></u><u></u></span></p>
<p class="MsoNormal"><b><span lang="EN-US">Action Item 2</span></b><span lang="EN-US">: Leadership Team to draft text in response to Charter Question B4 based on today’s discussion.<u></u><u></u></span></p>
<p class="MsoNormal"><b><u></u> <u></u></b></p>
<p class="MsoNormal"><b><u><span lang="EN-US">Notes<u></u><u></u></span></u></b></p>
<p class="MsoNormal"><b><u><span lang="EN-US"><u></u><span style="text-decoration:none"> </span><u></u></span></u></b></p>
<p class="MsoNormal"><b>Welcome and Chair Updates<u></u><u></u></b></p>
<ul style="margin-top:0cm" type="disc">
<li style="margin-left:0cm">
<span lang="EN-US">The GNSO Council approved the EPDP’s Project Change Request during the November Council meeting. There was some discussion on this list about the timeline, to which the leadership team provided a reply. As a reminder, the EPDP Team seeks
 to complete the Phase 1 Initial Report by April 2023. Donna may request to make calls two hours in length to continue making progress towards this goal.<u></u><u></u></span></li><li style="margin-left:0cm">
<span lang="EN-US">ICANN Org has provided early input on the EPDP’s stable recommendations. The substance of this input will be covered on calls once everyone has had a chance to review.<u></u><u></u></span></li><li style="margin-left:0cm">
<span lang="EN-US">Multiple org SMEs provided input on operational impacts of the recommendations. The org document includes three types of input: substantive, non-substantive, and assumptions (org’s interpretations of the text to be confirmed by the EPDP).
 There are also some general comments at the top of the document that apply to multiple sections of the text. There is an impact analysis of the String Similarity hybrid model at the end of the document. The org team did not explicitly look at other models
 but could do so upon request of the EPDP Team.<u></u><u></u></span></li><li style="margin-left:0cm">
<span lang="EN-US">This may be something the EPDP Team requests in the future if it can’t find a path forward.<u></u><u></u></span></li></ul>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><b><span lang="EN-US">Action Item 1</span></b><span lang="EN-US">: EPDP Team members to review input from ICANN org and send any clarification questions to the mailing list.
<u></u><u></u></span></p>
<p class="MsoNormal"><b><span lang="EN-US"><u></u> <u></u></span></b></p>
<p class="MsoNormal"><b>Continued Discussion of <a href="https://urldefense.com/v3/__https:/docs.google.com/document/d/1LlorzuwJlZ1jUZTw9Frwy-wJkTdQ559p0R2ogGRRTTU/edit__;!!PtGJab4!4hAeImyxiBfQZX0bH1wzyavbOEHm1nicx5lL8D4WnTqbgZAHntZKfkqK5vDZCigj4ESGXR1swsWBg_eSy0kU_rz-nq5ZyFg$" target="_blank">Charter
 Question B4 [docs.google.com]</a> - Delegation of variants gTLDs vis a vis primary string<u></u><u></u></b></p>
<ul style="margin-top:0cm" type="disc">
<li style="margin-left:2.9pt">
<span lang="EN-US">Introduction: The EPDP Team previously discussed the possibility of delegating the variant string ahead of the primary string. From a technical perspective, it is possible to delegate the variant ahead of the primary string. But is it what
 we want to do from a policy perspective? Should strings in a set be delegated within the same set timeframe or should this be flexible?</span><u></u><u></u></li><li style="margin-left:2.9pt">
<span lang="EN-US">Slide 4 – B4 Additional Discussion Topic</span><u></u><u></u></li><li style="margin-left:2.9pt">
<span lang="EN-US">B4: </span>What should an application process look like in terms of timing and sequence for an existing and future Registry Operator with respect to applying or activating their allocatable variant TLD labels?
<u></u><u></u></li><li style="margin-left:2.9pt">
Discussion Questions: <span lang="EN-US">1. </span>Should a variant gTLD be allowed for delegation prior to delegation of the primary string? <span lang="EN-US">2.
</span>Should the primary string and allocatable variant labels that pass evaluation be delegated within the timeframe as affirmed by SubPro recommendations?
<span lang="EN-US">3. Should the variant string and the primary be delegated at the same time?</span><u></u><u></u></li><li style="margin-left:2.9pt">
<span lang="EN-US">Slide 5 – Question 1 Example and Factors for Consideration</span><u></u><u></u></li><li style="margin-left:2.9pt">
<span lang="EN-US">What are the assumptions of the group about whether the intent is that all of the TLDs in a set need to be delegated in close timing to one another or whether it can be done over a period of time? As a reminder, the group previously discussed
 that whichever string is delegated first must be delegated within a 12 months. </span>
<u></u><u></u></li><li style="margin-left:2.9pt">
<span lang="EN-US">Comment: There are four steps 1. Application for a variant set 2. Evaluation process 3. Execution of the RA with expectation of delegation 4. Sunrise. The question of whether the primary needs to be delegated first is not trivial. The 12
 month timeframe for delegation results in all of the contractual obligations kicking in. If there were different options for the timing of strings in a set, someone would have to manage that. There is no requirement for sunrise and the timing is up to the
 RO. In that way, they can manage the sequencing while complying with the obligations for those variant sets. The concern is the burden of managing the variants in the set. Is that something for ICANN org to manage or for the RO to manage?</span><u></u><u></u></li><li style="margin-left:2.9pt">
<span lang="EN-US">Clarification: Sunrise is the process of starting to offer registrations in the TLD. This is done by the RO based on certain requirements, but the RO picks the date to sunrise.
</span><u></u><u></u></li><li style="margin-left:2.9pt">
<span lang="EN-US">Comment: Support for the idea that if an applicant applies for several variant labels that they all need to be activated at once or in a small window of time. The RO could decide to wait on a sunrise for certain strings based on business
 choices. But what would this mean for fees that the RO pays? The RO may not want to pay fees for a string it is not ready to sunrise. Additional point: If we say that the main string always needs to exist along with the variant, would you be able to delete/remove/sunset
 the main label and keep that variant?</span><u></u><u></u></li><li style="margin-left:2.9pt">
<span lang="EN-US">Comment: On the one hand, it might benefit end users to have all of the TLDs in a set available at once. On the other hand, the RO may end up paying more fees for strings they are not yet ready to use. If there is one contract for a variant
 set, they should all be launched within 12 months.</span><u></u><u></u></li><li style="margin-left:2.9pt">
<span lang="EN-US">Comment: It seems more complex to have serial launch of TLDs in a set and then manage that coordination/harmonization by retrofitting. It seems hard to imagine a use case where you would want that complexity rather than launching at the same
 time and doing coordination/harmonization of the set at once.</span><u></u><u></u></li><li style="margin-left:2.9pt">
<span lang="EN-US">Response: This is something that we will have to deal with anyway, because every TLD operator will be able to apply for variant TLDs in later rounds, and the complexity associated with this later activation will need to be managed.</span><u></u><u></u></li><li style="margin-left:2.9pt">
<span lang="EN-US">Question: It was noted that for Chinese TLDs from the first round, the ROs were disadvantaged because they couldn’t get their variants. When they are able to get their variants, how will this be managed?</span><u></u><u></u></li><li style="margin-left:2.9pt">
<span lang="EN-US">Response: Currently without the IDN variant TLD, there are users who are not able to access certain domains as expected. This will be resolved once variants are available. It is up to the registries to deal appropriately with the addition
 of variants. Their plan to do so will be evaluated as part of the application process.</span><u></u><u></u></li><li style="margin-left:2.9pt">
<span lang="EN-US">Comment: What does appropriate mean respect to the operation of variants?</span><u></u><u></u></li><li style="margin-left:2.9pt">
<span lang="EN-US">Response: There is no guarantee of a consistent user experience. The policy is intended to enable the possibility of a consistent user experience. But it is up to the registry, registrar, and registrant to make that happen in practice.
</span><u></u><u></u></li><li style="margin-left:2.9pt">
<span lang="EN-US">Comment: We should not talk about guaranteeing the experience of the end user in the context of this work. There are too many steps between this work and the final experience of the end user. We can seek to make a better experience, but we
 can’t make guarantees. </span><u></u><u></u></li><li style="margin-left:2.9pt">
<span lang="EN-US">Comment: There is a different between delegation and use. Delegation means introduction to the root. Once the applicant gets the TLD and the variants, we could have a baseline position that those strings get delegated into the root. They
 would be subject to the associated fees. We should not go into questions related to sunrise. This is up to the RO to manage. If an RO wants to delay delegation of the set or part of the set, they should apply to ICANN for an extension. Why are we looking beyond
 delegation in this discussion?</span><u></u><u></u></li><li style="margin-left:2.9pt">
<span lang="EN-US">Response: Agree that our discussion should focus on delegation. But reviewing the details of sunrise helped the group understand what happens after delegation.</span><u></u><u></u></li><li style="margin-left:2.9pt">
<span lang="EN-US">Suggestion: The policy doesn’t mandate the order in which the strings are delegated. There is an expectation that the primary and the variants will be delegated within a set period of time.
</span><u></u><u></u></li><li style="margin-left:2.9pt">
<span lang="EN-US">Slide 6 – Question 2 – Factors for Consideration </span><u></u><u></u>
<ul style="margin-top:0cm" type="circle">
<li style="margin-left:2.9pt">
<span lang="EN-US">Question 2: </span>Should the primary string and allocatable variant labels that pass evaluation be delegated within the timeframe as affirmed by SubPro recommendations?<u></u><u></u></li></ul>
</li><li style="margin-left:2.9pt">
<span lang="EN-US">Clarification regarding SubPro recommendation: based on the rationale, the term “use” draws on the existing definition – delegation into the root and meeting of the associated contractual commitments.
</span><u></u><u></u></li><li style="margin-left:2.9pt">
<span lang="EN-US">Staff note: The question with respect to applicant intent on slide 6 may need to be revisited and restructured for clarity.</span><u></u><u></u></li><li style="margin-left:2.9pt">
<span lang="EN-US">Comment: We intend to be consistent with the SubPro recommendations regarding required timeframes for entering into an RA and for delegation. If multiple strings are under the same RA, it makes sense that they all follow the same timeframe
 requirements. To do otherwise would create excessive complexity.</span><u></u><u></u></li><li style="margin-left:2.9pt">
<span lang="EN-US">Summary: There seems to be support for the idea that the sequence for delegation should not be mandated in policy, but the set should be delegated within the same timeframe. The question of how annual fees will be incurred is still outstanding
 and will be discussed in the future.</span><u></u><u></u></li></ul>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><b><span lang="EN-US">Action Item 2</span></b><span lang="EN-US">: Leadership Team to draft text in response to Charter Question B4 based on today’s discussion.<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<ul style="margin-top:0cm" type="disc">
<li style="margin-left:0cm">
<span lang="EN-US">Additional potential question for future consideration: Should an applicant be able to apply for a variant and not the primary label of a set.<u></u><u></u></span></li></ul>
<p style="margin-left:38.9pt">
<u></u> <u></u></p>
<p class="MsoNormal"><b>Continued Discussion of <a href="https://urldefense.com/v3/__https:/docs.google.com/document/d/1glGuJwSoYlYFvdRWtDWf9UvrLKk2hq7kW-osHJeGK14/edit__;!!PtGJab4!4hAeImyxiBfQZX0bH1wzyavbOEHm1nicx5lL8D4WnTqbgZAHntZKfkqK5vDZCigj4ESGXR1swsWBg_eSy0kU_rz-Ic9e9_A$" target="_blank">Charter
 Question E2 [docs.google.com]</a>- Options for Legal Rights and Community Objections<u></u><u></u></b></p>
<ul style="margin-top:0cm" type="disc">
<li style="margin-left:0cm">
<span lang="EN-US">Deferred to a future call.</span><u></u><u></u></li></ul>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><span lang="EN-US">AOB<u></u><u></u></span></p>
<ul style="margin-top:0cm" type="disc">
<li style="margin-left:0cm">
<span lang="EN-US">No call next week. <b><u></u><u></u></b></span></li><li style="margin-left:0cm">
<span lang="EN-US">Joint Meeting between IDNs EPDP Team and ccPDP4 is on Tuesday 29 November 2022 at 14:00 UTC for 90 minutes.<u></u><u></u></span></li><li style="margin-left:0cm">
<span lang="EN-US">Next regular EPDP call is on Thursday 1 December at 13:30 UTC.<u></u><u></u></span></li></ul>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
</div>
</div>

_______________________________________________<br>
Gnso-epdp-idn-team mailing list<br>
<a href="mailto:Gnso-epdp-idn-team@icann.org" target="_blank">Gnso-epdp-idn-team@icann.org</a><br>
<a href="https://mm.icann.org/mailman/listinfo/gnso-epdp-idn-team" rel="noreferrer" target="_blank">https://mm.icann.org/mailman/listinfo/gnso-epdp-idn-team</a></blockquote></div>