<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;"><div><div><div><div>Dear PDP WG members,</div><span id="OLK_SRC_BODY_SECTION"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><span id="OLK_SRC_BODY_SECTION"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><span id="OLK_SRC_BODY_SECTION"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div><br></div><div>Please see below the discussion notes and action items captured by staff from the meeting on 04 April. These high-level notes are designed to help PDP WG members navigate through the content of the call and are not meant as a substitute for the transcript. The MP3 and transcript are provided separately and are posted to the calendar at: <a href="http://gnso.icann.org/en/group-activities/calendar#nov" target="_blank" style="font-size: 15px; color: purple;">http://gnso.icann.org/en/group-activities/calendar</a>. Please also reference the chat room, which has been captured and provided by the GNSO Secretariat via separate email.</div><div><br></div><div>Kind regards,</div><div>Julie</div><div>Julie Hedlund, Policy Director</div></div></span><div><b><br></b></div><div><b>Discussion Notes/Actions: New gTLD Subsequent Procedures PDP WG Meeting, 04 April 2016</b></div></div></span><div><br></div></div></span><div><i>1. <span style="font-size: 10.5pt;">Discussion on response to Dr. Crocker (attached).</span></i></div><div><span style="font-size: 10.5pt;"><br></span></div><div><b>Action Item</b>: Send <span style="font-family: -webkit-standard; font-size: medium;">the letter to the GNSO Council leadership via Paul McGrady, the GNSO Council liaison, </span><span tabindex="0" class="" style="font-family: -webkit-standard;">after the meeting today</span><span style="font-family: -webkit-standard; font-size: medium;">. Once the Council leadership reviews and approves, it will be sent to Dr. Crocker and the Board. </span></div><div><br></div><span id="OLK_SRC_BODY_SECTION"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div><i><font face="Calibri,sans-serif">2. </font><span style="font-size: 10.5pt;">Discussion regarding principles from 2007 Final Report (please reference the attached excerpt):</span></i></div></div></span><div><br></div><div><u>Decision making: </u></div><span id="OLK_SRC_BODY_SECTION"><b><i>Action Items</i></b>: 1) Document in the notes actions to be taken at a next meeting (noting that a first reading is normally the result of discussion so may not be documentable ahead of time); 2) Keep a decision log on all decisions that have been made and the results.<br></span><span id="OLK_SRC_BODY_SECTION"><br><div><font face="Calibri,sans-serif"><u>Principle A</u></font></div></span><div>Jeff Neuman: Will be addressed later as an overarching principle.</div><span id="OLK_SRC_BODY_SECTION"><br><div><font face="Calibri,sans-serif"><u>Principle B</u></font></div></span><span id="OLK_SRC_BODY_SECTION">Alan Greenberg: Not sure this is needed anymore as it is moot.</span><span id="OLK_SRC_BODY_SECTION">Vanda Scartezini: Could just state that TLDs can be in both ASCII and IDN formats. (General agreement in the discussion.)<br></span><span id="OLK_SRC_BODY_SECTION"><br><div><font face="Calibri,sans-serif"><u>Principle C</u></font></div></span><div><font face="Calibri,sans-serif">Robert Burlingame (Pillsbury): Suggested text: "One of the reasons for introducing new top-level domains is that there is demand from potential applicants for new top-level domains in both ASCII and IDN formats. Furthermore, the introduction of new top-level domains has the potential to promote: competition in the provision of registry services; consumer choice; market differentiation; and geographical and service-provider diversity."</font></div><span id="OLK_SRC_BODY_SECTION"><br><u>Principle D</u> (Summary of discussion) — Make sure that the principles sync with the new Bylaws.<br></span><span id="OLK_SRC_BODY_SECTION"><br><div><font face="Calibri,sans-serif"><u>Principle E</u></font></div></span><span id="OLK_SRC_BODY_SECTION">Jeff Neuman: Clarify that the capability criteria are operational and financial?</span><span id="OLK_SRC_BODY_SECTION">Alan Greenberg: Leave as is for now, recognizing that we'll probably need to add sub-paragraphs to provide additional detail.<br></span><span id="OLK_SRC_BODY_SECTION"><br><u>Principle F</u> (Summary of discussion) — No action. Still applies.<br></span><span id="OLK_SRC_BODY_SECTION"><br><u>Principle G</u> </span><span id="OLK_SRC_BODY_SECTION">Ayden Ferdeline: Why only the "applicant's" freedom of expression?</span><span id="OLK_SRC_BODY_SECTION">Carlton Samuels: Say more about the string evaluation process?</span><span id="OLK_SRC_BODY_SECTION">Greg Shatan: Put this into the recommendations, rather than principles?</span><span id="OLK_SRC_BODY_SECTION">Kavouss Arasteh: Change the "protected" to “provided" in front of "internationally recognized”.</span><span id="OLK_SRC_BODY_SECTION">Steve Coates: Or change to: "that are recognized under international principles of law."</span><span id="OLK_SRC_BODY_SECTION">Robin Gross: Objection to moving from principles to recommendations.<div>Jeff Neuman: Should be there be a way or method in the recommendations to add things that are based on new circumstances or not anticipated?</div></span><span id="OLK_SRC_BODY_SECTION"><div>Steve Coates (Twitter): Consider implications to "rolling procedures."</div><br><div><font face="Calibri,sans-serif"><u>Recommendation 1</u></font></div></span><div>Steve Coates (Twitter): Recommendation 1 should not be negotiable. </div><span id="OLK_SRC_BODY_SECTION"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div>Robert Burlingame (Pillsbury): I agree that "should" would be better than "must" in the Recommendations.</div><div>Kurt Pritz: It is ok that a recommendation include the word "must." "Recommendation" means Policy Recommendations that were later approved by the ICANN Board.</div><div>Jeff Neuman: In addition to high-level principles there were things we wanted to be sure were included ("must").</div><div>Alan Greenberg & Greg Shatan: They may start as recommendations, but once approved by the Board they are policy.</div></div></span><span id="OLK_SRC_BODY_SECTION"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Greg Shatan: The taxonomy may be out of date/pre-go-live set up.</div></span><span id="OLK_SRC_BODY_SECTION"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Jeff Neuman: Should we list these as policies?</div></span><span id="OLK_SRC_BODY_SECTION"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Kavouss Arasteh: If you change to "policy" that may solve a lot of issues. Be very careful not to use "must" if we don't mean "must" -- minimize the use of must.</div></span><span id="OLK_SRC_BODY_SECTION"><div>Kurt Pritz: Use "must" and "shall" in the definition adopted by ICANN (<a href="https://www.ietf.org/rfc/rfc2119.txt">https://www.ietf.org/rfc/rfc2119.txt</a>).</div><br><div><font face="Calibri,sans-serif"><u>Recommendation 2</u></font></div></span><span id="OLK_SRC_BODY_SECTION">Jeff Neuman: On this one there may be inherent questions -- what does "Reserve" mean? There was a subgroup in 2006-7 that worked on this definition, "what is a Reserved Name?" "Strings" here point to top-level domains. Move forward subject to definiting the terms?<br></span><span id="OLK_SRC_BODY_SECTION"><br><div><font face="Calibri,sans-serif"><u>Recommendation 3</u></font></div></span><span id="OLK_SRC_BODY_SECTION">Jeff Neuman: This was used to create some of the objection criteria for the 2012 round. This will be discussed in one of the tracks, although not necessarily a rights-protection mechanism since this refers to strings at the top level. </span><span id="OLK_SRC_BODY_SECTION">Robin Gross: Freedom of Expression concerns were left out of the implemention of Recommendation 3 (which only focused on trademark protection).<br></span><span id="OLK_SRC_BODY_SECTION"><br><div><font face="Calibri,sans-serif"><u>Recommendation 4</u></font></div></span><span id="OLK_SRC_BODY_SECTION">Jeff Neuman: Would think this is non-contentious. </span><span id="OLK_SRC_BODY_SECTION">Alan Greenberg: Change the nomenclature to "concepts" and then if there should be a taxonomy work through it later.<br></span><span id="OLK_SRC_BODY_SECTION"><br><div><font face="Calibri,sans-serif"><u>Recommendation 5</u></font></div></span><span id="OLK_SRC_BODY_SECTION">Jeff Neuman: Define "Reserved Word" and provide more context, as suggested by Kavouss.<br></span><span id="OLK_SRC_BODY_SECTION"><br><div><font face="Calibri,sans-serif"><u>Recommendation 6</u></font></div></span><span id="OLK_SRC_BODY_SECTION">Jeff Neuman: The group that deals with this work track should look at how this was defined. Work with it initially as a concept.<br></span><span id="OLK_SRC_BODY_SECTION"><br><div><font face="Calibri,sans-serif"><u>Recommendation 7</u></font></div></span><span id="OLK_SRC_BODY_SECTION">Jeff Neuman: I am not sure the evaluation looked at the purpose that the applicant set out, just whether a registry could run as a registry. We will probably come back to this. </span><span id="OLK_SRC_BODY_SECTION">Alan Greenberg: I am not sure it makes any sense. Steve Coates: Agree on the language of "purpose" tied to "technical".</span><span id="OLK_SRC_BODY_SECTION">Kavouss Arasteh: How is this demonstration made?</span><span id="OLK_SRC_BODY_SECTION">Rubens Kuhl: Currently they demonstrate passing a pre-delegation test: <a href="https://newgtlds.icann.org/en/applicants/pdt">https://newgtlds.icann.org/en/applicants/pdt</a>. </span><span id="OLK_SRC_BODY_SECTION">Jeff Neuman: Not done during the application process. May need to consider if we decide to accredit registry providers whether we do think a demonstration needs to be approved, in track 1 (process) track 5 (technical criteria/demonstration).<br></span><span id="OLK_SRC_BODY_SECTION"><br><div><font face="Calibri,sans-serif"><u>Recommendation 8</u></font></div></span><span id="OLK_SRC_BODY_SECTION">Jeff Neuman: Never asked to demonstrate financial capabilities, but ICANN received statements and financial information. </span><span id="OLK_SRC_BODY_SECTION">Rubens Kuhl: Only looked an financial with the angle of a commercial registry. We might choose to let financial be only a due diligence requirement for contract signing but not an application evaluation criteria. </span><span id="OLK_SRC_BODY_SECTION">Jeff Neuman: Look at that in the relevant track.<br></span><span id="OLK_SRC_BODY_SECTION"><br><div><font face="Calibri,sans-serif"><u>Recommendation 9</u></font></div></span><span id="OLK_SRC_BODY_SECTION">Jeff Neuman: Look at the ICANN Implementation Report, but for this one gets some comments in from the actual evaluators. </span><span id="OLK_SRC_BODY_SECTION">Robin Gross: Do better on recommendation 9. Too much was changed after the fact and it wasn't fair. </span><span id="OLK_SRC_BODY_SECTION">Rudi Vansnick: Agreed. </span><span id="OLK_SRC_BODY_SECTION">Kavouss Arasteh: To whom is this addressed? What is the relation to "objective and measurable criteria" and "pre-published application process? Reword or say what we mean. </span><span id="OLK_SRC_BODY_SECTION">Jeff Neuman: Agree that we can word this better that there should be criteria set out in advance so applicants know how they will be measured. </span><span id="OLK_SRC_BODY_SECTION">Alan Greenberg: There may well be things that are non-objective but we should try to put in these that are non-discriminatory. </span><span id="OLK_SRC_BODY_SECTION">Kavouss Arasteh: Are we asking ICANN to do this?</span><span id="OLK_SRC_BODY_SECTION">Rubens Kuhl: Add "non-discriminatory"</span><span id="OLK_SRC_BODY_SECTION">Jeff Neuman: That is a good addition. Or "except as otherwise set forth here?"</span><div>Greg Shatan: Or "Where possible"?</div><span id="OLK_SRC_BODY_SECTION"><br><div><font face="Calibri,sans-serif"><u>Recommendation 10</u></font></div></span><span id="OLK_SRC_BODY_SECTION">Jeff Neuman: This is one where there have been comments that there should be different base contracts? But the concept is that the applicant should know what contractual terms would apply to them. Reword that there is not only one base contract? We should talk about base contract(s) -- track 2 -- whether there should be a process to institute changes before a contract is signed. </span><span id="OLK_SRC_BODY_SECTION">Steve Coates (Twitter): Could use improvement with additional clauses, and application of new clauses.<br></span><span id="OLK_SRC_BODY_SECTION"><br><u>Recommendation 11</u> — Replaced with 20.<br></span><span id="OLK_SRC_BODY_SECTION"><br><div><font face="Calibri,sans-serif"><u>Recommendation 12</u></font></div></span><span id="OLK_SRC_BODY_SECTION">Jeff Neuman: We need to build in some what to have changes. Applicants need to know what dispute processes might be used against them. </span><span id="OLK_SRC_BODY_SECTION">Robin Gross: GAC objections impact recommendation 12, not understanding what a government might object to.</span></div></div></div><div><span><br></span></div></body></html>