<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="Title" content="">
<meta name="Keywords" content="">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@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:0cm;
margin-bottom:.0001pt;
font-size:12.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;}
span.EmailStyle17
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.msoIns
{mso-style-type:export-only;
mso-style-name:"";
text-decoration:underline;
color:teal;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:595.0pt 842.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body bgcolor="white" lang="EN-US" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt">Dear Working Group members,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Please note that there was an error in the meeting notes that I circulated earlier for the 29 August call. Please see correction below in red. My apologies for any confusion this may have caused. It was due
to a misunderstanding on my part. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">The notes have also been updated on the wiki.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Kind regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Emily<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span style="color:black">From: </span></b><span style="color:black">Emily Barabas <emily.barabas@icann.org><br>
<b>Date: </b>Tuesday 29 August 2017 at 13:48<br>
<b>To: </b>"gnso-newgtld-wg@icann.org" <gnso-newgtld-wg@icann.org><br>
<b>Subject: </b>Notes and Action Items: New gTLD Subsequent Procedures PDP WG - 29 August 2017<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt">Dear Working Group members,</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Please see below the action items and notes from the meeting today. <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
or transcript.</i> See the chat transcript, recording and call transcript at: <a href="https://community.icann.org/display/NGSPP/2017-08-29+New+gTLD+Subsequent+Procedures+PDP">
https://community.icann.org/display/NGSPP/2017-08-29+New+gTLD+Subsequent+Procedures+PDP</a>.</span><o:p></o:p></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt"> </span></b><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Kind regards,</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Emily</span><o:p></o:p></p>
<div style="border:none;border-bottom:solid windowtext 1.0pt;padding:0cm 0cm 1.0pt 0cm">
<p class="MsoNormal"><b><span style="font-size:11.0pt"> </span></b><o:p></o:p></p>
</div>
<p class="MsoNormal"><b><span style="font-size:11.0pt"> </span></b><o:p></o:p></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt">ACTION ITEM: Staff will develop a graphic to show the timing issue.</span></b><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Notes:</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">1) Welcome/SOIs </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">- Avri Doria has an SOI update - contract project with Donuts has ended. <br>
<br>
<br>
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">2) Work Track Updates </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">- WT1: Next week the WT is continuing discussion on CC2, focus on Applicant Support and Communications. </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">- WT2: Next week the WT is continuing discussion on Registrant Protections, CC2 comments on this topic. May also begin discussing Closed Generics. WT2 will have weekly meetings in September.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">- WT3: Meeting this week will continue to focus on CC2 comments on Objections, including GAC Advice and Independent Objector.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">- WT4: Last meeting focused on Registry Services and technical evaluation. Conversation on applicant evaluations will continue in the upcoming meeting.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">- WT5: Letters have gone out to GNSO, ccNSO, GAC, and ALAC inviting them to nominate a member for the leadership team. The ccNSO nominated Annebeth Lange. ALAC and GNSO are working on nominations. <s>Cheryl Langdon-Orr is expected as ALAC lead</s>. <b><span style="color:red">Cheryl
Langdon-Orr plans to be an active participant in WT5. Any role from ALAC is TBD</span></b>. GNSO Council discussed WT5 during the Council meeting last week. Question was raised about whether this WT will take place within the GNSO PDP framework. The intention is that it will. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">- From the GNSO Council perspective, the appointment of leaders of WTs typically happens through the Working Group. This should be the same for WT5. </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">- There have been conversations between WG chairs and potential candidates, but the leads are still working on this process.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">- There are still some concern about the procedures and in particular that the output will be considered by the full PDP. This might be a problem from the ccNSO perspective.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">- Question: Are the responsibilities of the co-leaders defined somewhere? Answer: The first item of business will be to run a draft TOR by the new co-leaders once they have been selected. Efforts will be made to make
sure everyone is as comfortable as possible within the GNSO framework. </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">- Intention is that all participants from the community will be participants on equal footing.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">chat excerpt:</span><o:p></o:p></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt">Rubens Kuhl: </span></b><span style="font-size:11.0pt">There are no minority or majority concepts in a consensus-based decision making. </span><o:p></o:p></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt">Kavouss Arasteh: </span></b><span style="font-size:11.0pt">Rubens, but there are some concerns about consensus meaning</span><o:p></o:p></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt">Rubens Kuhl: </span></b><span style="font-size:11.0pt">Kavouss, consensus in a GNSO PDP can only mean one thing... but it shares its properties with the IETF rough consensus tradition, where even one view can change the outcome. </span><o:p></o:p></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt">Rubens Kuhl: </span></b><span style="font-size:11.0pt">This is for instance the case of many encryption standards (TLS) where a single Google comment was able to change the outcome, since they were recognized as having the experience to point out things that don't work in scale. </span><o:p></o:p></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt">Kavouss Arasteh: </span></b><span style="font-size:11.0pt">Ihope there would be no more than one person from each 4 group</span><o:p></o:p></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt">Steve Chan: </span></b><span style="font-size:11.0pt">You can review GNSO PDP decision making rules under section 3.6 here in the WG guidelines: <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_en_council_annex-2D1-2Dgnso-2Dwg-2Dguidelines-2D01sep16-2Den.pdf&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=mBQzlSaM6eYCHFBU-v48zs-QSrjHB0aWmHuE4X4drzI&m=5t7Vhc_Z21cemGHDSQV-uIWGXusO-BuOp4bxc6TdvEo&s=cCYjvt5miJCVOLgO9HQSvZ2ymXfllN1GiWRyYuM7mxo&e=" target="_blank">https://gnso.icann.org/en/council/annex-1-gnso-wg-guidelines-01sep16-en.pdf[gnso.icann.org]</a></span><o:p></o:p></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt">Heather Forrest: </span></b><span style="font-size:11.0pt">@Jeff, Avri, good to know that this is in progress, and in accordance with standard practice. I wouldn't anticipate that Council itself would make nominations (as that would come through the SSC)</span><o:p></o:p></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt">Rubens Kuhl: </span></b><span style="font-size:11.0pt">Kavouss, it's never about quantity. </span><o:p></o:p></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt">Kavouss Arasteh: </span></b><span style="font-size:11.0pt">That is not as simple as you qualified</span><o:p></o:p></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt">Robin Gross: </span></b><span style="font-size:11.0pt">Policy for generic names is guided by the GNSO under ICANNs bylaws. It sounds like some have a problem with the structure of ICANN.</span><o:p></o:p></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt">Anne Aikman-Scalese (IPC): </span></b><span style="font-size:11.0pt">I think it is a bit diifferent when ccNSO participates in a PDP. They don't really have quite the same policy-making process, do they?</span><o:p></o:p></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt">Annebeth Lange, ccNSO: </span></b><span style="font-size:11.0pt">I am happy to hear that, Avri, since geographical names are of special interest to more groups than GNSO than any other gTLDs</span><o:p></o:p></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt">Jim Prendergast: </span></b><span style="font-size:11.0pt">so just to recap. the ccNSO has put forth someone, waiting on GNSO and ALAC but they are moving on it and we think GAC may be addressing it this week on leadership call. is that correct? and what is the best guess on when the leadership will be settled?</span><o:p></o:p></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt">Robin Gross: </span></b><span style="font-size:11.0pt">When does the GNSO get to participate in CCnso policy making?</span><o:p></o:p></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt">Greg Shatan: </span></b><span style="font-size:11.0pt">Would it make sense to have a webinar on the GNSO PDP Working Group guidelines for those unfamiliar with them?</span><o:p></o:p></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt">Philip Corwin: </span></b><span style="font-size:11.0pt">I don't understand how sincere outreach in the cause of inclusion could be regarded as an attempt to construct an 'alibi".</span><o:p></o:p></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt">Rubens Kuhl: </span></b><span style="font-size:11.0pt">Anne, ccNSO does have PDPs... their PDPs are usually less time-sensitive and less controversial, but they share some DNSO origins with GNSO, including PDPs. </span><o:p></o:p></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt">Greg Shatan: </span></b><span style="font-size:11.0pt">That might allay some of these fears.</span><o:p></o:p></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt">Karen Day: </span></b><span style="font-size:11.0pt">Good thought Greg.</span><o:p></o:p></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt">Greg Shatan: </span></b><span style="font-size:11.0pt">It should be noted that GNSO PDP Working Groups are ALWAYS open to any participant from any group or no group.</span><o:p></o:p></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt">Rubens Kuhl: </span></b><span style="font-size:11.0pt">Jim, GNSO Council will not be putting a name forward for GNSO. Those names were referred to reach out to the full WG chairs (Jeff and Avri) and come forward with their application. </span><o:p></o:p></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt">Annebeth Lange, ccNSO: </span></b><span style="font-size:11.0pt">But Greg, in the end it will be the GNSO council that decides, will it not?</span><o:p></o:p></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt">Anne Aikman-Scalese (IPC): </span></b><span style="font-size:11.0pt">It is a very positive that GAC representatives and ccNSO participate actively in Sub Pro.</span><o:p></o:p></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt">Karen Day: </span></b><span style="font-size:11.0pt">@Kavouss - I can confirm that is the way this PDP is already operating with regard to work team co-leads. </span><o:p></o:p></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt">Robin Gross: </span></b><span style="font-size:11.0pt">I'm trying to imagine what it would be like for GNSO participants to have equal footing with GAC in their working groups.</span><o:p></o:p></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt">Greg Shatan: </span></b><span style="font-size:11.0pt">The Working Group's final report, after probably 2 rounds of public comment, and approval by the Working Group, will go to the Council for approval. But it is up to the WG to write and approve the report.</span><o:p></o:p></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt">Heather Forrest: </span></b><span style="font-size:11.0pt">The GNSO Council is required, under ICANN Bylaws, to vote on any recommendations of GNSO PDPs - but Council obviously respects the work of the PDP WGs</span><o:p></o:p></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt">Rubens Kuhl: </span></b><span style="font-size:11.0pt">Annebeth, GNSO Council is a process manager, not a legislative body... so the Council can verify if anything went outside of PDP process or conflicts with bylaws, but wouldn't replace the WG report with their own views on something. </span><o:p></o:p></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt">Heather Forrest: </span></b><span style="font-size:11.0pt">(Greg, Rubens and I have all just made the same point in different words - great minds think alike - and of course it would have to be that Council couldn't simply legislate on its own or we wouldn't have or need PDP WGs)</span><o:p></o:p></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt">Greg Shatan: </span></b><span style="font-size:11.0pt">Good points Rubens and Heather (both on Council, by the way). The GNSO Council is also NOT a policy development body - that is the job of the (always open) Working Groups.</span><o:p></o:p></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt">Annebeth Lange, ccNSO: </span></b><span style="font-size:11.0pt">I think there is a special sensitivity when it comes to geographical names among the other stakeholders, as many do not consider them "true generics". Since we only have 2 categories in TLDs, these naturally fall under gTLDs. However, what I was reporting here were the concerns I hear. Since ICANN Bylaws are as they are, we have to try to make the best out of it to avoid the same problems we had in the last round, when many years of discussion took place after the first AGB was produced.</span><o:p></o:p></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt">Rubens Kuhl: </span></b><span style="font-size:11.0pt">Annebeth, I offer another angle on this: having the GNSO policy on those names defined is a kind of insurance that makes that if those names are considered gTLDs, they are also protected by reasonable rules to assure they are not misused. </span><o:p></o:p></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt">Jim Prendergast: </span></b><span style="font-size:11.0pt">don't forget impact of GAC advice as well<br>
<br>
<br>
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">3) Drafting Team Discussion – Predictability Framework </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">- Background - there were a number of issues that were not expected in the original policy. Some issues are being addressed under the specific topic areas in the PDP. There may still be changes that need to take place in subsequent procedures. This framework seeks to address how to manage these types of issues if they do come up.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">- It is expected that the issues will not be as great as they were in the 2012 round. </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">- For issues that arise when the IRT is operating, the IRT can address these issues. </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">- There is still a question of what happens when the program launches and changes need to take place. </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">- Some changes may only impact applicants, other issues came up after applications were revealed but before contract signing. Other issues surfaced and were raised to the community later.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">chat excerpt:</span><o:p></o:p></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt">Kavouss Arasteh: </span></b><span style="font-size:11.0pt">I suggest we say "SOME LEVEL"of preditabilty instead of "A LEVEL "</span><o:p></o:p></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt">Kavouss Arasteh: </span></b><span style="font-size:11.0pt">Ialso suggest to add the word"relative"before stability<br>
<br>
<br>
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">- Clarification on chat comment -- it is difficult to predict stability, and nothing is totally stable, therefore include the word "relative" before stability. </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">- We are never going to be able to predict every change that needs to happen, but having a framework for managing these changes can help to provide additional predictability.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">chat excerpt:</span><o:p></o:p></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt">Michael Flemming: </span></b><span style="font-size:11.0pt">Jeff, question for clarity. Predictability in our discussion is limited to the process itself and not necessarily the outcome as in delay in some TLDs to launch/use their TLD, correct?</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">- Correct -- this discussion is primarily about the predictability in the process itself. We may in the future also want to consider thresholds, but for the moment, the focus is on the process.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">- Example- imagine a flaw/glitch in application system. In 2012, ICANN staff put up a page saying that there was an issue and that updates would be provided. What would be an alternate way to handle this issue? </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">- We need more predictability into the SLAs and community input into those SLAs, more transparency from those working on the issue.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">- If an issue came up where ICANN had to change application process, is this purely implementation? Is it something the community should weigh in on?</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">chat excerpt:<br>
<b>Maxim Alzoba (FAITID): </b>RFP for system?</span><o:p></o:p></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt">Maxim Alzoba (FAITID): </span></b><span style="font-size:11.0pt">at the first place</span><o:p></o:p></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt">Greg Shatan: </span></b><span style="font-size:11.0pt">It seems like the processes created by the Policy & Implementation Working Group should be applied to many of these instances.</span><o:p></o:p></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt">Greg Shatan: </span></b><span style="font-size:11.0pt">Has this been considered?</span><o:p></o:p></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt">Anne Aikman-Scalese (IPC): </span></b><span style="font-size:11.0pt">Yes - Greg - I agree. The big issue here is Who should determine whether an issue involves policy or not. I think IRT should determine. I don't necessarily buy the notion that that staff or some informal discussion can determine whether or not policy issues are involved. Current draft of Predictability Framework says "staff will collaborate with the comm</span><o:p></o:p></p>
<p class="MsoNormal"><b>Heather Forrest: </b>Looks like we have 2 different conversations here in the chat - one on policy vs implementation, the other on the system<o:p></o:p></p>
<p class="MsoNormal"><b>Anne Aikman-Scalese (IPC): </b>@Heather - the policy and implementation WG determined that it is not valuable to try to decide whether or not an issue is policy or implementation - it is only important to determine how the policy maker (GNSO) decides to treat that topic - whether or not it involves policy.<o:p></o:p></p>
<p class="MsoNormal"><b>Michael Flemming: </b>Depends on the issue, no?<o:p></o:p></p>
<p class="MsoNormal"><b>Heather Forrest: </b>I agree with Jeff but it's not clear to me how we determine whether something goes back to the IRT or not<o:p></o:p></p>
<p class="MsoNormal"><b>Michael Flemming: </b>Couldn't we have development of the system by one third party and then a risk analysis by another third party?<o:p></o:p></p>
<p class="MsoNormal"><b>Rubens Kuhl: </b>I don't think we can avoid an IRT, since this is a PDP WG . Non-PDP WGs perhaps could chose that. <o:p></o:p></p>
<p class="MsoNormal"><b>Anne Aikman-Scalese (IPC): </b>I have commented on the list that IRT should be "standing" - to be consulted whenever an issue arises.<o:p></o:p></p>
<p class="MsoNormal"><b>Greg Shatan: </b>I think trying to say some of these are not implementation issues is causing confusion.<o:p></o:p></p>
<p class="MsoNormal"><b>Greg Shatan: </b>Just as implementation problems raise policy issues, execution problems raise implementation issues.<o:p></o:p></p>
<p class="MsoNormal"><b>Kavouss Arasteh: </b>Jeff, I have some difficulties with you new term execution versus implemenation<o:p></o:p></p>
<p class="MsoNormal"><b>Greg Shatan: </b>Maybe we need an Implementation & Execution Working Group....<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">- What happens if changes arise once the program has already launched. There could be certain issues that arise that may not need to go to the IRT to get resolution.<o:p></o:p></p>
<p class="MsoNormal">- Any issue where the implementation is not working should go back to the IRT. Any cases outside of this should be very narrowly drawn. Not clear what this alternate method should be dealing with. It would need to be more nimble. But in general we should be looking at the issues in terms of policy and implementation. <o:p></o:p></p>
<p class="MsoNormal">- Maybe another word should be used - execution - example, what if information was exposed in the application system that should not have been exposed. Are there cases where issues do not have to go to the full IRT? <o:p></o:p></p>
<p class="MsoNormal">- Policy and Implementation WG looked at a number of issues that came up in 2012 round and examined resolution. The distinction between implementation and execution is not clear. Your perspective may depend on which side of the issue you are on. The WG determined that trying to draw a distinction between policy and implementation is not always helpful.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">From the chat:<o:p></o:p></p>
<p class="MsoNormal"><b>Rubens Kuhl: </b>Jeff, the type of issues you mentioned sounds similar to the IANA CSC (Customer Standing Committee) to me. Perhaps we could recomend something in that direction ? NTAG (New gTLD Applicant Group) and BRG (Brand Registry Group) both made interesting interactions with staff during the program. <o:p></o:p></p>
<p class="MsoNormal"><b>Kavouss Arasteh: </b>Jeff, may we avoid to use "Execution" ias it may cause some confusion with implemenation<o:p></o:p></p>
<p class="MsoNormal"><b>Jeff Neuman: </b>@Kavouss - is there a better word to use?<o:p></o:p></p>
<p class="MsoNormal"><b>Maxim Alzoba (FAITID): </b>name collisions were poor third party report issue<o:p></o:p></p>
<p class="MsoNormal"><b>Jim Prendergast: </b>name collision was actually a security and stability issue but your point is still valid<o:p></o:p></p>
<p class="MsoNormal"><b>Rubens Kuhl: </b>Name collisions actually surfaced during policy development, nobody cared... surfaced during implementation, nobody cared... it ended up being defined at execution time, but it was not execution. <o:p></o:p></p>
<p class="MsoNormal"><b>Kavouss Arasteh: </b>Not to use it at all but stay with implementation only<o:p></o:p></p>
<p class="MsoNormal"><b>Rubens Kuhl: </b>If CSC doesn't have a say in preventing a matter to be discussed at IRT, then when don't have to discuss what is execution, what is implementation, what is policy... <o:p></o:p></p>
<p class="MsoNormal"><b>avri doria: </b>if we decide to use execution, we will obviously need to define it. I suggest we try and base our discrimination between the two based on the analysis done by the GNSO and published as a report.<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><b>avri doria: </b>and as Anee said, it determined that the two were never completely disentagled, though at the beginning of a project it was mostly policy and at the end it was mostly implementation.<o:p></o:p></p>
<p class="MsoNormal">- IRT has a definitive beginning and end, may be helpful to think about something like a standing committee remains to address issues down the line.<o:p></o:p></p>
<p class="MsoNormal">- Perhaps such a standing committee could help determine whether the issue needs to go to the IRT or perhaps requires consultation with a group of experts. <o:p></o:p></p>
<p class="MsoNormal">- How would standing committee differ from the IRT?<o:p></o:p></p>
<p class="MsoNormal">- There is no concept of a standing IRT. <o:p></o:p></p>
<p class="MsoNormal">- A standing committee would not necessarily be composed of GNSO volunteers. They could be experts that provide a different type of assistance. <o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">chat excerpt:<o:p></o:p></p>
<p class="MsoNormal"><b>Greg Shatan: </b>How would the ExCSC differ from the IRT?<o:p></o:p></p>
<p class="MsoNormal"><b>Kavouss Arasteh: </b>yes to the question you raised<o:p></o:p></p>
<p class="MsoNormal"><b>Rubens Kuhl: </b>Greg, usually less members, with roles representing different parties. In IANA they are gTLD registries, non-registries GNSO, ccTLD registries, RIRs, protocols;<o:p></o:p></p>
<p class="MsoNormal"><b>Kavouss Arasteh: </b>Jeff, as you suggested ,we need to give a hand to ICANN Staff in those circumstances<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">- At times staff did want to consult with experts but did not have a mechanism to do so. <o:p></o:p></p>
<p class="MsoNormal">- The CSC was created for a specific reason. Having a special group to look at customer concerns (those that deal directly with the IANA function) made sense in this case. <o:p></o:p></p>
<p class="MsoNormal">- There is a risk of ICANN becoming a self-regulatory body. This is counter to the multistakeholder model. <o:p></o:p></p>
<p class="MsoNormal">- Keeping things in the hands of the "customers" is a troubling development. <o:p></o:p></p>
<p class="MsoNormal">- This discussion is heading in a direction that we should return from.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">chat excerpt:<o:p></o:p></p>
<p class="MsoNormal"><b>Rubens Kuhl: </b>For a SubPro CSC, it could be "applicants", "current registries", "objectors" and "communities" or something like that.<o:p></o:p></p>
<p class="MsoNormal"><b>Trang Nguyen: </b>The process documentation work that we recently did can help to clarify the phases. There is the policy development process, carried out by the community. Once the Board adopts, then it's the policy implementation phase carried out by ICANN and IRT. This phase concludes upon the effective date of the policy, which in this context would be the opening of the application process. Then it moves into the operations phase. The CPIF and IRT are applicable to the policy implementation phase. Once the policy is in operation and issues arise, we need some guidance on how to deal with issues, particularly issues where the policy is silent on.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt">- One distinction is one on timing. This is something that can be better clarified in a graphic. <o:p></o:p></p>
<p class="MsoNormal"><b>ACTION ITEM: Staff will develop a graphic to show the timing issue.</b><o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">- What if ICANN changed the mechanism by which they conducted testing, which had an impact of pre-delegation testing? The change would still be achieving the same policy and criteria. This does not seem to be a policy or implementation issue, but more of an operational issue that impacts applicants. Would a different process be appropriate?<o:p></o:p></p>
<p class="MsoNormal">- If someone cares and feels that it creates a different outcome, at the very least you have an implementation issue.<o:p></o:p></p>
<p class="MsoNormal">- But if it impacts applicants, the applicants will care, even if it does not impact every constituency. <o:p></o:p></p>
<p class="MsoNormal">- The testing provider released notes on the testing protocol, it was not something that the IRT was involved.<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt">- If people care about the issue, it should go back to the multistakeholder community, not just to those who have a vested interest in the outcome.<o:p></o:p></p>
<p class="MsoNormal">chat excerpt:<o:p></o:p></p>
<p class="MsoNormal"><b>Kavouss Arasteh: </b>How we are ensured that such action does not have any impact on policy developped<o:p></o:p></p>
<p class="MsoNormal"><b>Rubens Kuhl: </b>@Kavouss, that can be a post-facto control: somebody would file an RfR (Request for Consideration) for such action. <o:p></o:p></p>
<p class="MsoNormal"><b>Rubens Kuhl: </b>I did care a lot for that particular change Jeff mentioned.<o:p></o:p></p>
<p class="MsoNormal"><b>Maxim Alzoba (FAITID): </b>I think multistakeholder model works with policy and not with at implementation <o:p></o:p></p>
<p class="MsoNormal"><b>Greg Shatan: </b>I absolutely disagree with the idea that the multistakeholder model doesn't work with implemementation.<o:p></o:p></p>
<p class="MsoNormal"><b>Greg Shatan: </b>IRTs are multistakeholder.<o:p></o:p></p>
<p class="MsoNormal"><b>Kavouss Arasteh: </b>I also have difficulties the MSH be involved in the implementation process<o:p></o:p></p>
<p class="MsoNormal"><b>Trang Nguyen: </b>The discussion around taking things back to IRTs imply that implementation needs to be changed/modified when in fact I think of the example about PDT test specs as operational evolution. From that perspective, I like Jeff's suggestion of a standing panel.<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><b>avri doria: </b>I tend to beleive that all processes in ICANN should be mulitstakeholder at their base.<o:p></o:p></p>
<p class="MsoNormal">- Does an IRT have a specific end, or is the end of the first application period serve as a determinate end. We should go back to the documentation and see, but a long standing IRT may not be contrary to the rules. <o:p></o:p></p>
<p class="MsoNormal">- Can we accept the changes in the document and begin working with a clean copy?<o:p></o:p></p>
<p class="MsoNormal">- Idea of separation of responsibilities -- multistakeholder community guides policy but then implementation is a different responsibility. <o:p></o:p></p>
<p class="MsoNormal">- Some people believe some functions should not involve the full IRT, others think the full IRT should not be the default for everything.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"><b>Greg Shatan: </b>It sounds like some people don't like the idea of IRTs?<o:p></o:p></p>
<p class="MsoNormal"><b>avri doria: </b>i think that directly affected and indirectly affected are incredibly hard to disentangle.<o:p></o:p></p>
<p class="MsoNormal"><b>Greg Shatan: </b>The indirectly affected can be more objective about the issues.<o:p></o:p></p>
<p class="MsoNormal"><b>Kavouss Arasteh: </b>Any thing that slow down the process should be avoided<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</body>
</html>