<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:Wingdings;
        panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:#0563C1;
        text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
        {mso-style-priority:34;
        margin-top:0in;
        margin-right:0in;
        margin-bottom:0in;
        margin-left:.5in;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
span.EmailStyle20
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
/* List Definitions */
@list l0
        {mso-list-id:133529555;
        mso-list-type:hybrid;
        mso-list-template-ids:-1259571822 542803726 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
        {mso-level-number-format:bullet;
        mso-level-text:-;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:"Calibri",sans-serif;
        mso-fareast-font-family:Calibri;}
@list l0:level2
        {mso-level-number-format:bullet;
        mso-level-text:o;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:"Courier New";}
@list l0:level3
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:Wingdings;}
@list l0:level4
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:Symbol;}
@list l0:level5
        {mso-level-number-format:bullet;
        mso-level-text:o;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:"Courier New";}
@list l0:level6
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:Wingdings;}
@list l0:level7
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:Symbol;}
@list l0:level8
        {mso-level-number-format:bullet;
        mso-level-text:o;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:"Courier New";}
@list l0:level9
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:Wingdings;}
@list l1
        {mso-list-id:222259522;
        mso-list-type:hybrid;
        mso-list-template-ids:-1414071070 305048814 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l1:level1
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:Wingdings;
        mso-fareast-font-family:Calibri;
        mso-bidi-font-family:Calibri;}
@list l1:level2
        {mso-level-number-format:bullet;
        mso-level-text:o;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:"Courier New";}
@list l1:level3
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:Wingdings;}
@list l1:level4
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:Symbol;}
@list l1:level5
        {mso-level-number-format:bullet;
        mso-level-text:o;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:"Courier New";}
@list l1:level6
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:Wingdings;}
@list l1:level7
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:Symbol;}
@list l1:level8
        {mso-level-number-format:bullet;
        mso-level-text:o;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:"Courier New";}
@list l1:level9
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:Wingdings;}
@list l2
        {mso-list-id:533735601;
        mso-list-type:hybrid;
        mso-list-template-ids:-1808224410 -249553820 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l2:level1
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:Wingdings;
        mso-fareast-font-family:Calibri;
        mso-bidi-font-family:Calibri;}
@list l2:level2
        {mso-level-number-format:bullet;
        mso-level-text:o;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:"Courier New";}
@list l2:level3
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:Wingdings;}
@list l2:level4
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:Symbol;}
@list l2:level5
        {mso-level-number-format:bullet;
        mso-level-text:o;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:"Courier New";}
@list l2:level6
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:Wingdings;}
@list l2:level7
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:Symbol;}
@list l2:level8
        {mso-level-number-format:bullet;
        mso-level-text:o;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:"Courier New";}
@list l2:level9
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:Wingdings;}
ol
        {margin-bottom:0in;}
ul
        {margin-bottom:0in;}
--></style>
</head>
<body lang="EN-US" link="#0563C1" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal">Dear Working Group members,<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Please see below the notes from the working sessions on 17 November at 03:00 UTC.
<b><i>These high-level notes are designed to help WG members navigate through the content of the call and are not a substitute for the recording, transcript, or the chat,</i></b> which will be posted at:
<a href="https://community.icann.org/display/NGSPP/2020-11-17+New+gTLD+Subsequent+Procedures+PDP">
https://community.icann.org/display/NGSPP/2020-11-17+New+gTLD+Subsequent+Procedures+PDP</a>.
<o:p></o:p></p>
<p class="MsoNormal">  <o:p></o:p></p>
<p class="MsoNormal">Kind regards,<br>
Julie<o:p></o:p></p>
<p class="MsoNormal">==<o:p></o:p></p>
<p class="MsoNormal"><b>Notes and Action Items:</b><o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"><b>Action Items:</b><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="color:black"><a href="https://docs.google.com/spreadsheets/d/1PglquKDd8amHiqI6Wfko0Plb80RPpbEjTMS_F-5t4sU/edit#gid=1163822586">Topic 41: Contractual Compliance</a><o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:black">Row 13 – ALAC re: Compliance should publish thresholds and guidelines to assess registry/registrar practices.<o:p></o:p></span></p>
<p class="MsoNormal"><b><span style="color:black">ACTION ITEM: Rec 41.2 – Adding text on the information we are seeking. Staff will consult with leadership on the new wording.<o:p></o:p></span></b></p>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black"><o:p> </o:p></span></p>
<p class="MsoNormal" style="caret-color: rgb(0, 0, 0);font-variant-caps: normal;orphans: auto;text-align:start;widows: auto;-webkit-text-size-adjust: auto;-webkit-text-stroke-width: 0px;word-spacing:0px">
<span style="color:black"><a href="https://docs.google.com/spreadsheets/d/1mkfwWZtyGAOdIbN3LsgNtDnVs6ehPmgrONzl85gWD2I/edit#gid=1163822586" title="https://docs.google.com/spreadsheets/d/1mkfwWZtyGAOdIbN3LsgNtDnVs6ehPmgrONzl85gWD2I/edit#gid=1163822586">Topic
 37: Registrar Non-Discrimination / Registry/Registrar Standardization</a><o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:black">Row 17 – RrSG re: Exempted registries must demonstrate unsuccessful outreach to registrars.<o:p></o:p></span></p>
<p class="MsoNormal"><b><span style="color:black">ACTION ITEM: Rewrite the recommendation to provide clarity about this recommendation on the impact of .brands.<o:p></o:p></span></b></p>
<p class="MsoNormal"><span style="color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:black"><a href="https://docs.google.com/spreadsheets/d/1YJJDm9mdmSssXav1P08Uhw6Ofyp0KtfTX8QSRChrVNI/edit#gid=1163822586">Topic 25: IDNs</a></span><span style="font-size:12.0pt;color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Row 11 – RySG re: Warn applicant if risk of string never being delegated; consider related work in progress.<o:p></o:p></p>
<p class="MsoNormal"><b>ACTION ITEM: Revise the recommendation to include the warning for an applicant that there is a risk of a string never being delegated.<o:p></o:p></b></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Row 14 – ICANN Board re: Don't process applied-for strings in script not integrated in the RZ-LGR; assess impacts on other processes; clarify which IDN tables “pre-vetted by the community” could still be used to remove IDN table testing
 for the new gTLDs.<o:p></o:p></p>
<p class="MsoNormal"><b>ACTION ITEM: The WG should work on the list to find middle ground on this issue.<o:p></o:p></b></p>
<p class="MsoNormal"><b>ACTION ITEM: Provide a rationale as to why the WG considered the Board’s comments on Recommendations 5 and 6 and didn’t address them.<o:p></o:p></b></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Row 15 – ALAC re: Supports offering IDN variants to registry operator of existing/applied for gTLDs, not separate application; metrics to evaluate promotion/availability of IDNs at top level.<o:p></o:p></p>
<p class="MsoNormal"><b>ACTION ITEM: Add this as Implementation Guidance.<o:p></o:p></b></p>
<p class="MsoNormal"><b>ACTION ITEM: Add a reference in the rationale re: offering IDN variants to registry operator of existing/applied for gTLDs, not separate application.<o:p></o:p></b></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Row 16 – ICANN Org re: various issues<o:p></o:p></p>
<p class="MsoNormal"><b>ACTION ITEM: Clarify definition of 1-character codes in accordance with ICANN Org's comments and what “single entity” means.</b><o:p></o:p></p>
<p class="MsoNormal"><b>ACTION ITEM re: “ICANN org notes that the PDP WG has taken into account the Variant TLD Recommendations, and has also identified areas which do not appear to be directly addressed. ICANN org understands that, following the work of the
 ​IDN Scoping Team​, the GNSO is considering initiating another policy development effort focused on IDNs to address these areas. Until discussion on these additional topics is complete, some details may be unclear around how to proceed with IDN TLDs and variant
 labels in subsequent rounds. Thus, moving forward with the next round of TLD applications may have some dependency on the GNSO PDP on IDNs.”<o:p></o:p></b></p>
<p class="MsoNormal"><b>-- Take this issue to the WG list on this issue and the status of the IDN EPDP, and circle back with the IDN team in ICANN Org.<o:p></o:p></b></p>
<p class="MsoNormal"><b><o:p> </o:p></b></p>
<p class="MsoNormal"><b>Notes:</b><o:p></o:p></p>
<p class="MsoNormal">  <o:p></o:p></p>
<p class="MsoNormal">1. Updates to Statements of Interest: None provided.<o:p></o:p></p>
<p class="MsoListParagraph" style="margin-left:0in"> <o:p></o:p></p>
<div>
<p class="MsoNormal">2. Review draft Final Report Public Comments – to prepare see the links to the Public Comment Review Tool on the wiki at:
<a href="https://community.icann.org/display/NGSPP/h.+Published+Draft+reports">https://community.icann.org/display/NGSPP/h.+Published+Draft+reports</a> and review the following topics and comments:<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"><span style="color:black"><a href="https://docs.google.com/spreadsheets/d/1PglquKDd8amHiqI6Wfko0Plb80RPpbEjTMS_F-5t4sU/edit#gid=1163822586" title="https://docs.google.com/spreadsheets/d/1PglquKDd8amHiqI6Wfko0Plb80RPpbEjTMS_F-5t4sU/edit#gid=1163822586">Topic
 41: Contractual Compliance</a><o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:black">Row 9 -- Swiss Government OFCOM re: Strengthen compliance enforcement with financial penalties; Rec 41.2 insufficient.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">Leadership Comments: Do we want to introduce sanctions akin to RAA?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:black">Row 10 – IPC; Row 11 – INTA and Row 12 – GBOC (also anti-abuse); Row 19 -- BC  re: Strengthen compliance<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">Leadership Comments: Noted. Also related to DNS abuse provisions.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:black">Row 13 – ALAC re: Compliance should publish thresholds and guidelines to assess registry/registrar practices.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">Leadership Comments: Do we want to introduce more transparency into actions taken (and measurements used) for compliance actions that do not result in breach?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><u><span style="color:black">Discussion:<o:p></o:p></span></u></p>
<p class="MsoNormal"><span style="color:black">-- Usually these types of comments are closed.  Contracted parties wouldn’t want this disclosed.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">-- Possible action to withhold the name of the entity.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">-- No clear indication of the thresholds to assess.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">-- Ask for what is it that ICANN Org is using to assess undesirable behavior by the contracted parties.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">-- We could add a few words that including the threshold…so long it is not publishing information about the registry operator.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">-- Question: Are we talking about setting up two compliance programs?  We can’t reach backward. Answer: If we added the ALAC action about action, and instead added a few words about what ICANN is already doing
 then we wouldn’t be making new policy.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">--- Support introducing standards and thresholds.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">-- We can address this by adding a few words to the recommendation.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span style="color:black">ACTION ITEM: Rec 41.2 – Adding text on the information we are seeking. Staff will consult with leadership on the new wording.<o:p></o:p></span></b></p>
<p class="MsoNormal"><span style="color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:black">Row 17 – ICANN Board re: Recommended data is already being published.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">Leadership Comments: We believe Compliance Dashboard covers our recommendations sufficiently.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:black">Row 18 – ICANN Org re: WG should provide specific examples of data to be published and/or examples.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">Leadership Comment: ICANN Org asks why we believe this is only relevant for next rounds of new gtLDs? Response: We are not saying it is only relevant for the next rounds, but it is outside our scope to recommend
 anything with respect to legacy TLDs.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black"><o:p> </o:p></span></p>
<p class="MsoNormal" style="caret-color: rgb(0, 0, 0);font-variant-caps: normal;orphans: auto;text-align:start;widows: auto;-webkit-text-size-adjust: auto;-webkit-text-stroke-width: 0px;word-spacing:0px">
<span style="color:black"><a href="https://docs.google.com/spreadsheets/d/1mkfwWZtyGAOdIbN3LsgNtDnVs6ehPmgrONzl85gWD2I/edit#gid=1163822586" title="https://docs.google.com/spreadsheets/d/1mkfwWZtyGAOdIbN3LsgNtDnVs6ehPmgrONzl85gWD2I/edit#gid=1163822586">Topic
 37: Registrar Non-Discrimination / Registry/Registrar Standardization</a><o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:black">Row 10 – BRG re: Supports exemption for .Brand TLD/include in Spec 13.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">Leadership Comments: Do we grant additional extensions (namely, not having to use a registrar at all)? This was discussed within Work Track, but not carried forward.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:black">Row 13 – ICANN Org re: No registrar application in New gTLD application; keep process separate and Row 21 InfoNetworks LLC re: Consider a consolidated Registry/Registrar Agreement.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">Leadership Comments: Do we want to revisit the notion of allowing both accreditations in same TLD application?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><u><span style="color:black">Discussion</span></u><span style="color:black">:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">-- Did not have support in the WG to elevate this to a recommendation.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:black">Row 17 – RrSG re: Exempted registries must demonstrate unsuccessful outreach to registrars.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">Leadership Comments: Do we want to add this clarification (eg., true demonstration of outreach and then if policies change, a re-evaluation of exemption is needed).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><u><span style="color:black">Discussion</span></u><span style="color:black">:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">-- Seems to add more clarity to an existing recommendation.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">-- Don’t see strong support for the exemption.  Concern that ICANN’s role is to make the TLDs available, it’s up to the registries to make them successful.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">-- Comments were lukewarm.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">-- Goes back to what the BRG said.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">-- With .brands, we have never proposed getting rid of the exemption for Spec 13.  Not sure that this question that was out for community input would affect .brands. 
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">-- The action item here is to provide clarification of the impact on .brands from this recommendation.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span style="color:black">ACTION ITEM: Rewrite the recommendation to provide clarity about this recommendation on the impact of .brands.<o:p></o:p></span></b></p>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black"><o:p> </o:p></span></p>
<p class="MsoNormal" style="caret-color: rgb(0, 0, 0);font-variant-caps: normal;orphans: auto;text-align:start;widows: auto;-webkit-text-size-adjust: auto;-webkit-text-stroke-width: 0px;word-spacing:0px">
<span style="color:black"><a href="https://docs.google.com/spreadsheets/d/1mkfwWZtyGAOdIbN3LsgNtDnVs6ehPmgrONzl85gWD2I/edit#gid=1163822586" title="https://docs.google.com/spreadsheets/d/1mkfwWZtyGAOdIbN3LsgNtDnVs6ehPmgrONzl85gWD2I/edit#gid=1163822586">Topic
 38: Registrar Support for New TLDs</a><o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:black">Row 10 – InfoNetworks LLC re: Registrars without an RAA shouldn't be able to object to proposed RAA amendments.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">Leadership Comments: New idea: Limit Registrars review of RRA Amendments to only those Registrars that have signed the RRA, (Include with Base Agreement discussion).  Probably just affect existing TLDs and not
 new TLDs.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black"><o:p> </o:p></span></p>
<p class="MsoNormal" style="caret-color: rgb(0, 0, 0);font-variant-caps: normal;orphans: auto;text-align:start;widows: auto;-webkit-text-size-adjust: auto;-webkit-text-stroke-width: 0px;word-spacing:0px">
<span style="color:black"><a href="https://docs.google.com/spreadsheets/d/1YJJDm9mdmSssXav1P08Uhw6Ofyp0KtfTX8QSRChrVNI/edit#gid=1163822586" title="https://docs.google.com/spreadsheets/d/1YJJDm9mdmSssXav1P08Uhw6Ofyp0KtfTX8QSRChrVNI/edit#gid=1163822586">Topic
 25: IDNs</a></span><span style="font-size:12.0pt;color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Row 8 – Anthony Lee and other comments re: Continue to develop a mechanism that also takes the concerns of both the SSAC and Joint ccNSO-GNSO IDN Workgroup reports into consideration.<o:p></o:p></p>
<p class="MsoNormal">Overarching Leadership Comment: Consider referring all of our recommendations to the GNSO IDN Scoping Team for including in their PDP.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Row 9 -- Wei Wang (Individual) re: Waiving application fees of IDN gTLD variant and existing/applied IDN gTLD with same registry operator.<o:p></o:p></p>
<p class="MsoNormal">Leadership Comments: Noted.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Row 10 – IAB<o:p></o:p></p>
<p class="MsoNormal">Leadership Comments: Noted.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Row 11 – RySG re: Warn applicant if risk of string never being delegated; consider related work in progress.<o:p></o:p></p>
<p class="MsoNormal">Leadership Comments: Warning sounds like a good clarification recommendation; See above on referring all recommendations to IDN Groups to consider.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><b>ACTION ITEM: Revise the recommendation to include the warning for an applicant that there is a risk of a string never being delegated.<o:p></o:p></b></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Row 12 – WIPO re: Domain abuse by homograph spoofing.<o:p></o:p></p>
<p class="MsoNormal">Leadership Comments: This is an issue for IDN Group, RPM PDP and future DNS Abuse efforts.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Row 12 – RrSG re: Vet IDN tables/variants prior to delegation, not outright rejection.<o:p></o:p></p>
<p class="MsoNormal">Leadership Comments: Could this be part of the RSP Pre-approval process?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">-- We don’t talk about the tables being rejected.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Row 14 – ICANN Board re: Don't process applied-for strings in script not integrated in the RZ-LGR; assess impacts on other processes; clarify which IDN tables “pre-vetted by the community” could still be used to remove IDN table testing
 for the new gTLDs.<o:p></o:p></p>
<p class="MsoNormal">Leadership Comments: <o:p></o:p></p>
<p class="MsoNormal">-- Review Recommendations 5 and 6 of Variant TLD Recommendations? The Board asks the PDP WG to clarify which IDN tables “pre-vetted by the community” could still be used to remove IDN table testing for the new gTLDs. The Board suggests
 that the PDP WG considers Reference IDN tables being published by ICANN org as the candidate pre-vetted IDN tables. (Pg. 178)<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><b>ACTION ITEM: The WG should work on the list to find middle ground on this issue.<o:p></o:p></b></p>
<p class="MsoNormal"><b>ACTION ITEM: Provide a rationale as to why the WG considered the Board’s comments on Recommendations 5 and 6 and didn’t address them.<o:p></o:p></b></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><u>Discussion</u>:<o:p></o:p></p>
<p class="MsoNormal">-- Board suggestion is different from the WG’s recommendation.<o:p></o:p></p>
<p class="MsoNormal">-- Not sure how realistic the Board suggestion is.<o:p></o:p></p>
<p class="MsoNormal">-- Would be difficult to do the evaluation if the RZL isn’t part of the rules.<o:p></o:p></p>
<p class="MsoNormal">-- We discussed this at some length didn't we?  I understand ICANN Board's desire for efficiency, but weren't we balancing out others who may be caught up in contention sets or want to file objections?
<o:p></o:p></p>
<p class="MsoNormal">-- The idea of having the RZ generation rules was that you could have a situation where you were using the rules is that you needed to have some rules for those that weren’t in the RZ generation rules.<o:p></o:p></p>
<p class="MsoNormal">-- Is there a way to do both?  The applicant would be entering contention at its own risk.  It should be able to go through a number of steps until the RZ generation rules are finalized.<o:p></o:p></p>
<p class="MsoNormal">-- For a string in a script that is not part of the RZ-LGR, there is no guarantee it will ever be valid.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><b>ACTION ITEM: The WG should work on the list to find middle ground on this issue.<o:p></o:p></b></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Row 15 – ALAC re: Supports offering IDN variants to registry operator of existing/applied for gTLDs, not separate application; metrics to evaluate promotion/availability of IDNs at top level.<o:p></o:p></p>
<p class="MsoNormal">Leadership Comments: Noted.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><u>Discussion</u>:<o:p></o:p></p>
<p class="MsoNormal">-- Question: What does it mean: “and the corresponding level of assignment of ICANN staff support and evaluators”?  This seems like an IRT issue.  This will be noted by IRT.<o:p></o:p></p>
<p class="MsoNormal">-- To be a meaningful measure then staff commitment comparison to other non IDNs need to be looked at as well  NEW and yes Implementation.<o:p></o:p></p>
<p class="MsoNormal">-- Question: Will this go to the IRT?<o:p></o:p></p>
<p class="MsoNormal"><b><o:p> </o:p></b></p>
<p class="MsoNormal"><b>ACTION ITEM: Add this as Implementation Guidance.<o:p></o:p></b></p>
<p class="MsoNormal"><b>ACTION ITEM: Add a reference in the rationale re: offering IDN variants to registry operator of existing/applied for gTLDs, not separate application.<o:p></o:p></b></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Row 16 – ICANN Org re: various issues<o:p></o:p></p>
<p class="MsoNormal">Leadership Comments: <o:p></o:p></p>
<p class="MsoNormal">-- Does the Working Group want to specify that unless and until new IDN rules are finalized, that it not hold up subsequent rounds, which will apply existing rules (eg., not allow variants).
<o:p></o:p></p>
<p class="MsoNormal">-- In the same token, should this group formally refer issues of "(a) the process by which an existing registry operator could apply for, or be given, an IDN variant for its existing gTLD; and (b) the process by which an applicant applying
 for a new IDN gTLD could seek and obtain any allocatable IDN variant(s) ICANN Org does not believe any string should be processed if the Label Generation Rules for that script are not integrated into the RZ-LGR; AND that these applications should not hold
 up other ones that are integrated.<o:p></o:p></p>
<p class="MsoNormal">--  Clarify definition of 1 character codes in accordance with ICANN Org comments. Clarify what Single entity means.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><b>ACTION ITEM: Clarify definition of 1-character codes in accordance with ICANN Org's comments and what “single entity” means.</b><o:p></o:p></p>
<p class="MsoNormal"><b><o:p> </o:p></b></p>
<p class="MsoNormal"><b>ACTION ITEM re: “ICANN org notes that the PDP WG has taken into account the Variant TLD Recommendations, and has also identified areas which do not appear to be directly addressed. ICANN org understands that, following the work of the
 ​IDN Scoping Team​, the GNSO is considering initiating another policy development effort focused on IDNs to address these areas. Until discussion on these additional topics is complete, some details may be unclear around how to proceed with IDN TLDs and variant
 labels in subsequent rounds. Thus, moving forward with the next round of TLD applications may have some dependency on the GNSO PDP on IDNs.”<o:p></o:p></b></p>
<p class="MsoNormal"><b>-- Take this issue to the WG list on this issue and the status of the IDN EPDP, and circle back with the IDN team in ICANN Org.</b><o:p></o:p></p>
</div>
</div>
</body>
</html>