<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:"MS Gothic";
panose-1:2 11 6 9 7 2 5 8 2 4;}
@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;}
@font-face
{font-family:"\@MS Gothic";
panose-1:2 11 6 9 7 2 5 8 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:"Plain Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.PlainTextChar
{mso-style-name:"Plain Text Char";
mso-style-priority:99;
mso-style-link:"Plain Text";
font-family:"Calibri",sans-serif;}
span.EmailStyle21
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle22
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle23
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle24
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle25
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle26
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle27
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle28
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle29
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle30
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle31
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle32
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle33
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle34
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle35
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle36
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle37
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle38
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle39
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle40
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.apple-converted-space
{mso-style-name:apple-converted-space;}
span.EmailStyle42
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle43
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle44
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle45
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle46
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle47
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle48
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle49
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle50
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle51
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle52
{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;}
--></style>
</head>
<body lang="EN-US" link="#0563C1" vlink="#954F72">
<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 meeting on 16 September 2019.
<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/2019-09-16+New+gTLD+Subsequent+Procedures+PDP">
https://community.icann.org/display/NGSPP/2019-09-16+New+gTLD+Subsequent+Procedures+PDP</a>.
<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Kind regards,<o:p></o:p></p>
<p class="MsoNormal">Julie<o:p></o:p></p>
<p class="MsoNormal">Julie Hedlund, Policy Director<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"><b> </b><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt">1. Updates to Statements of Interest: No updates provided.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">2. Review of summary documents:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">a. Name Collisions -- See: <a href="https://docs.google.com/document/d/1Q6_DxsCvSA_3B7ArncO2U4tWNY3vH7Wi4nINrouR4AI/edit?usp=sharing">
https://docs.google.com/document/d/1Q6_DxsCvSA_3B7ArncO2U4tWNY3vH7Wi4nINrouR4AI/edit?usp=sharing</a>, page 55<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">Outstanding Items - New Ideas/Concerns/Divergence:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">-- GNSO Council letter to the Board asking about dependencies with the NCAP report with respect to the new gTLD subsequent procedures.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">-- More Unknowns than knowns at this stage from the NCAP work. So we need to draw some lines in the sand for our work re: dependencies.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">-- The lack of high-level agreements so far reflect divisions in the community and in the WG that will make us default to 2012 implementation in most of the topics.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">-- Some vendors have opted not to bid for the RFP for Study 1, but RFP is still open.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">-- In the comments, there is no consensus in deferring or not deferring to NCAP or SSAC.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">-- WG needs to plan for both circumstances: 1) NCAP is completed; 2) NCAP is not completed.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">-- Question: how many languages/scripts are involved? Answer: name collisions are about strings in ASCII characters. Name collisions only happen "in the wire", meaning that only in ASCII, even though that
could be the IDNA representation of an IDN string.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">-- Question: Has any work been done on the RYSG ask for a look at the effectiveness of the previous mitigation measures? (sorry on mobile so slower reaction time)? Answer: Final report issued by the JAS advisors.
Based on their data they do believe the previous mitigation measures have worked. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">-- Zero mishaps perhaps because we don’t know if controlled interruption actually worked effectively to alert us.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">-- From a evidence-driven PDP methodology, the only available data says 0.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">If NCAP work is not completed prior to the next application round, should the default be that the same name collision mitigation frameworks in place today be applied to those TLDs approved for the next round?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">-- Re: RySG comment, “No. ICANN should, at a minimum, release the studies its done on the names collision frameworks so that the community can judge if the same frameworks should be applied. If ICANN cannot
do that, ICANN should conduct a prompt, formal study that quantifies and measures the efficacy of the previous controlled interruption framework should be conducted before modifying or replacing the system, without delaying the next round. Without these baseline
measurements, assessing the risks of an alternative CI framework is not possible.” Question: Is there any evidence to the contrary since the JAS report? Answer: NCAP is looking to see if there was anything else.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">-- There is no evidence that controlled interruption worked as intended.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">-- Only by asking all Internet users if it worked or not could there be evidence of it having worked 100%.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">-- Hard to find evidence that may or may not be out there.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">-- An additional concern is that it wasn’t a vetted community driven design</span><span style="font-size:12.0pt;font-family:"MS Gothic"">
</span><span style="font-size:12.0pt"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"MS Gothic"">
</span><span style="font-size:12.0pt">-- But for all anybody knows, it worked. Despite some FUD on the other direction.</span><span style="font-size:12.0pt;font-family:"MS Gothic"">
</span><span style="font-size:12.0pt"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"MS Gothic"">
</span><span style="font-size:12.0pt">-- It is another unknown as it is a risk assessment ratio risk. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">-- In response to Rubens…. Rubens part of the scope of Study 1 of NCAP to review the papers and results to come to an assessment - we should not be trying to do that now, as a pdp WG - NCAP will make an independent
assessment as per its scope.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">-- In order to prove it worked, ICANN would have to make some representative strings not go through controlled interruption, and see what happened in that control group compared to the full slate.</span><span style="font-size:12.0pt;font-family:"MS Gothic"">
</span><span style="font-size:12.0pt"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">-- NCAP study 1 is just a collection of published material, with no conclusion to be made.</span><span style="font-size:12.0pt;font-family:"MS Gothic"">
</span><span style="font-size:12.0pt"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">-- Suggestion to the final report: 2012 implementation (due to lack of consensus) + substantial refund + possibility of disabling CI on a per-string basis at ICANN Org request.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">-- Good for the WG to acknowledge the findings of SAC90 and potentially agree with them with respect to collaboration.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">b. Objections -- See: <a href="https://docs.google.com/document/d/1BkRn9nYeBNjyx2mTw-3nIDn22jTumWd4w1PZR-KNrPs/edit?usp=sharing">
https://docs.google.com/document/d/1BkRn9nYeBNjyx2mTw-3nIDn22jTumWd4w1PZR-KNrPs/edit?usp=sharing</a>, page 2<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">High-Level Agreements:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">Re: ICANN must publish, for each type of objection, all supplemental rules as well as all criteria to be used by panelists for the filing of, response to, and evaluation of each objection. Such guidance for
decision making by panelists must be more detailed than what was available prior to the 2012 round. (High-Level Agreement C) <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">-- Could the WG include a recommendation this should be done prior to accepting any applications? For those who were part of the community applications, there were supplemental rules created after applications
were submitted and after objections. If there are going to be supplemental rules they need to be published prior to applications being submitted.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">-- Seems like the first three bullets could be very costly, depending on how implemented.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">-- Don’t think the WG is asking for new rules, just for transparency in supplemental rules and in selecting panelists.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">-- So there does need to be a balance between transparency and flexibility. There will be some unknowns prior to the applications being submitted.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">-- Basically anything that is meant to apply to objection procedures must be made available upfront.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">-- Should we carve out community applications, versus community objections?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">-- Those that filed/responded to LPI and other objections would liekly agree with increased transparency.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">-- Community objections were also used by community applications to try resolving their contention sets, not only by standard applications against declared as community applications.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">-- Do we need to make a There appears to be a concern about the latter being developed on the fly.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">-- The point is not about CPE here, but rather about how supplemental documents for CPE were published years after ICANN accepted community applications. Unless we are clear in subsequent procedures about
supplemental materials not being permitted for objections, then we don’t have any way of preventing them from doing so.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">-- Important to know costs ahead of time.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">-- Basically anything that is intended to apply to objection procedures must be made available upfront.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">-- Can we separate CPE into a separate category of objections?</span><span style="font-size:12.0pt;font-family:"MS Gothic"">
</span><span style="font-size:12.0pt">Community Objections are a different discussion.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">-- Perhaps providing a list of the changed elements would assist the group in understanding the issues you are presenting.</span><span style="font-size:12.0pt;font-family:"MS Gothic"">
</span><span style="font-size:12.0pt"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">-- CPE is part of string contention resolution.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"></span><o:p></o:p></p>
</div>
</body>
</html>