<html xmlns:v="urn:schemas-microsoft-com:vml" 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:mv="http://macVmlSchemaUri" xmlns="http://www.w3.org/TR/REC-html40"><head><meta name=Title content=""><meta name=Keywords content=""><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:"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;
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;}
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:12.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle18
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle19
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle20
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
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.EmailStyle41
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle42
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle43
{mso-style-type:personal-compose;
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:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:445394889;
mso-list-template-ids:-932034370;}
@list l1
{mso-list-id:2141528708;
mso-list-template-ids:-1046194868;}
@list l1:level1
{mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level2
{mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level3
{mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level4
{mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level5
{mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level6
{mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level7
{mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level8
{mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level9
{mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1027"/>
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1"/>
</o:shapelayout></xml><![endif]--></head><body bgcolor=white lang=EN-US link="#0563C1" vlink="#954F72"><div class=WordSection1><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>Dear WG Members,<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'> <o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>Please see below the action items and discussion notes captured by staff from the meeting on 08 January 2018. <i>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 or recording</i>. The MP3, transcript, and chat room notes will be provided separately.<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'> <o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>For reference see the following links to the documents, excerpts from the chat below, and also the attached slides:<o:p></o:p></span></p><ol style='margin-top:0in' start=1 type=1><li class=MsoNormal style='margin-left:0in;mso-list:l1 level1 lfo3;text-autospace:none'><span style='font-size:10.5pt'>Drafting Team Discussion continued – Different TLD Types (Wiki Page: </span><span style='font-size:10.5pt'><a href="https://community.icann.org/x/YKLRAw">https://community.icann.org/x/YKLRAw</a></span><span style='font-size:10.5pt'> and Working Document: </span><span style='font-size:10.5pt'><a href="https://docs.google.com/spreadsheets/d/1mA_hTUhLhJSsfcmoQwREtUqxykZ5KfJffzJAAhEvNlA/edit?usp=sharing">https://docs.google.com/spreadsheets/d/1mA_hTUhLhJSsfcmoQwREtUqxykZ5KfJffzJAAhEvNlA/edit?usp=sharing</a></span><span style='font-size:10.5pt'> <o:p></o:p></span></li><li class=MsoNormal style='margin-left:0in;mso-list:l1 level1 lfo3;text-autospace:none'><span style='font-size:10.5pt'>Drafting Team Discussion continued – Predictability Framework (Wiki Page: </span><span style='font-size:10.5pt'><a href="https://docs.google.com/document/d/1lzXxBLMtFr03BKnHsa-Ss7kR7EAJt7pCI1EP3H81tfQ/edit?usp=sharing">https://docs.google.com/document/d/1lzXxBLMtFr03BKnHsa-Ss7kR7EAJt7pCI1EP3H81tfQ/edit?usp=sharing</a></span><span style='font-size:10.5pt'> <o:p></o:p></span></li></ol><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'> <o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>Best regards,<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>Julie<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'> <o:p></o:p></span></p><div style='border:none;border-bottom:solid windowtext 1.0pt;padding:0in 0in 1.0pt 0in'><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>Julie Hedlund, Policy Director<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'> <o:p></o:p></span></p></div><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'> <o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><b><span style='font-size:10.5pt'>Actions/Discussion Notes</span></b><span style='font-size:10.5pt'><o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'> <o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>1. SOI Updates: None.<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'><o:p> </o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>2. Work Track Updates:<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'><o:p> </o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>Work Track 1: <o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>-- Next meeting is 09 January at 0300 UTC.<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>-- Draft recommendations on Application Fees and time permitting Variable Fees.<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'><o:p> </o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>Work Track 2: Next meeting is 18 January at 0300 UTC.<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'><o:p> </o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>Work Track 3:<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>-- 09 January at 1500 UTC.<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>-- Continuing third pass on objections -- specifically legal rights and confusing similarity objections.<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'><o:p> </o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>Work Track 4:<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>-- Next meeting 11 January at 1500 UTC.<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>-- Financial evaluation will be discussed including different models.<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>-- Getting into details on how the evaluations will occur. Areas where there had been a lot of debate and consternation among applicants.<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'><o:p> </o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>Work Track 5:<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>-- At the last meeting the WT5 members went through the Terms of Reference. A revised version is out for review.<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>-- Circulating a request today for input regarding the definitions surrounding geographic names at the top level.<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>-- Application types is a top that carries over into WT5.<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'><o:p> </o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>3. Overarching Issue: Predictability Framework (https://docs.google.com/document/d/1lzXxBLMtFr03BKnHsa-Ss7kR7EAJt7pCI1EP3H81tfQ/edit )<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'><o:p> </o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>-- Come up with a predictable process that will carry us through any issues.<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>-- Examples from the last round as case studies include:<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'><o:p> </o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>1. Change of vendor for an application type: Change that ICANN.org did of using a customized software solution to Sales Force. A change in the application process without input from the community. Would that type of change be done the same way under the next predictability framework.<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'><o:p> </o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>2. Change in the pre-delegation testing procedures. Decided by the vendor of the pre-delegation testing in coordination with ICANN.org and consultants. Notice was provided to the contracted parties. Impacted the registries.<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'><o:p> </o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>3. Change from Digital Archery to Random Selection process. Impacted applicants. Introduced because the intial way of moving forward with Digital Archery had security flaws. There was a comment period, but the decision was made by ICANN.org.<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'><o:p> </o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>4. Name Collisions. Substantial changes that were made to the delegation process and launch processes. Several comment periods and research by consultants and input from the SSAC. <o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'><o:p> </o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>Discussion:<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'><o:p> </o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>On the example of a freeze on the legal agreement: -- The episode from the last round cannot be repeated. Significant rules were changed in the registry agreement.<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>-- Concerned about anything that would put some applications on hold, such as with GAC advice. May need to be some compromise to move forward with an application.<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>-- If acceptance of an application is subjected to new terms being added to a contract (such as for technical/security changes), how do we handle that? Urge the GAC to issue broad advice before the next window opens.<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>-- What do we do with a rolling contracting process? Individual applicants ought to be aware that a wholesale changes to terms of the agreement -- for those that haven't begun performance should have a right to challenge.<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'><o:p> </o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>Any examples of changes to the process that we could discuss with respect to a stress test? <o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>-- Also need to consider how to address changes as a result of Board decisions; whole class of changes where we can say, "sorry, we aren't going to change." We do have to contemplate what to do should an issue come up after the program has started. Provide some guidance on whether and when the program could be halted.<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>-- Some changes may not fall into a policy or policy implementation category.<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'><o:p> </o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>From the chat:<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>Jim Prendergast: outside the negotiation windows allowed for in the current RA, we cannot have the RA changing after ICANN has taken $$ from applicants. There needs to be some sort of freeze in place so applicants have prediciability when it comes to the nature of the relationship they will have with ICANN.<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>Heather Forrest: +1 Jim - from a legal perspective there would potentially be a question as to enforceability of a contract (or parts thereof) lacking sufficient clarity for the parties<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>Maxim Alzoba (FAITID): situation where TAS passwords were changed randomly without request from applicants<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>Maxim Alzoba (FAITID): @Jeff, please add a task for me to supply additional info (cases e.t.c.)<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>Phil Buckingham: Jeff , another change - ICANN advisories on answering questions ( especially Q50 ) <o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>Heather Forrest: (sorry - boring law professor comment here) - In terms of timing I'm thinking performance of the contract should start before changes occur<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>Maxim Alzoba (FAITID): @Heather , formally ICANN has no responcibility for the failure to perform (unlike Applicants and RAs)<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>Heather Forrest: @Maxim - I understand, but we're talking about validity of the agreement, ie whether the applicant/Registry can agree to a contract that lacks certainty, not whether ICANN can breach (if there is no valid contract, neither party can breach!)<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>Rubens Kuhl: There were three type of PICs: mandatory for all, mandatory for some strings, truly voluntary. The first one was post-application change. <o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>Jim Prendergast: Thats why I think GAC advice that pertains to wide swaths of applications should be submitted prior to the opening of the round.<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>Maxim Alzoba (FAITID): @Heather, the required wording of Letter of Credit allowes ICANN to send a note via SWIFT "we need your money" and a request for a money<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>Susan Payne: Other "stress test" scenarios: .MAIL CORP and HOME. Although related to the name collision issue this issue is not resolved in relation to these three strings they are still in limbo<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>Rubens Kuhl: @Jim, GNSO Policy can not dictate requirements for GAC. <o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>Maxim Alzoba (FAITID): @Heather, also in other industries the tactics of bait and switch leads to criminal cases for fraud<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>Phil Buckingham: Jim +1 <o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>Susan Payne: and treatment of closed generics. I know this is a WT2 topic, but the scenario of changing the rules mid-process is relevant to predictability. Perhaps as an example of the impact of late GAC advice<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>Rubens Kuhl: Specifically regarding changing the agreement, we might use the same approval thresholds among applicants that exists today among registries. <o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>Heather Forrest: We're not dealing with the typical consumer contract-type scenario, where the consumer lacks any bargaining power. We definitely don't want that applicants/ registries to have that perception. I suppose what I'm saying is that each applicant/registry needs to treat its agreement as 'unique', so to speak, and not just one of many identical agreements<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>Maxim Alzoba (FAITID): I meant this thing (about changing a wholesale agreement) http://www.dca.ca.gov/publications/legal_guides/m-1.shtml and BAIT AND SWITCH - B&P 17500 (includes internet), CC1770(a)(9),(a)(10), 16 CFR Part 238<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>Maxim Alzoba (FAITID): but on the other hand - we can not entirely block ability of ICANN to change policies, it is about applicablility ot application process<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>Maxim Alzoba (FAITID): during the application window<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>Maxim Alzoba (FAITID): *applicability of such changes to the application process :)<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>Rubens Kuhl: Possibly the same criteria that allows ICANN to implement Temporary Policies could justify changing things on the fly.<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>Maxim Alzoba (FAITID): for example : some horrible security flaw of EPP is discovered and there is a need of a correction of some policy<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>Mary Wong: Note that, in the implementation principles adopted by the GNSO Council in late 2015, there is a process within the IRT framework that provides guidance for escalation as well as referral back to the GNSO Council for new policy issues.<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>Rubens Kuhl: "Temporary Policies. Registry Operator shall comply with and implement all specifications or policies established by the Board on a temporary basis, if adopted by the Board by a vote of at least two-thirds of its members, so long as the Board reasonably determines that such modifications or amendments are justified and that immediate temporary establishment of a specification or policy on the subject is necessary to maintain the stability or security of Registry Services or the DNS (“Temporary Policies”)."<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>Alan Greenberg: Note emergency policies according to current processes, expire after a year.<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>Alan Greenberg: Note temp policies are not in the Bylaws but in the Ry/Rr agreements and only apply after they are signed, so not clear they apply in the current situation.<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'><o:p> </o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>4. Overarching Issue: Application Types (https://docs.google.com/spreadsheets/d/1mA_hTUhLhJSsfcmoQwREtUqxykZ5KfJffzJAAhEvNlA/edit?usp=drive_web )<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'><o:p> </o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>-- What are we trying to achieve when we talk about establishing types of applications or categories?<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>-- What we haven't identified the rationale why we should, if we should, different types of applications. Do we believe they should have different contractual requirements, priority, should not have all of the contractual requirements? Need to solidify this. <o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>-- In the last round we didn't call them "categories" but we had different classes. The only reason to have them is if we treat them differently.<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>-- Number of members of the GAC that those from developing countries should have a category of applications that is treated different from those from developed countries.<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>-- Object to the term "exceptions". A lot of the costs that might be different in different scenarios. Or situations such as a brand registry not needing to use registrars. Or the public interest.<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>-- There will be demand for names with distinct purposes (such as geographic names).<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>-- May need to be categories because not everyone will use a top-level domain in a standardized way. There should be some way to deal with uses in a way that was not conceived of in the round's beginning, or in the standard way.<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>-- What is the goal of the TLD? The could result in variations in the contracts.<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>-- What are we trying to achieve as a community? If we looked at what happened in the last round there were restrictions on community applications to create some level of trust. Why would the TLD be operated differently.<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>-- Trying to extrapolate the reasons for why we created the previous categories. See if same rationale is useful.<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>-- If we start making value judgments about certain application then we could get into content regulation.<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>-- Perhaps where there is some restriction or validation or some way of appealing to a particular subset of the population of registrants that may be appropriate to look at as separate from the traditional open gTLD.<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>-- May be a need based on the nature of the string being requested for a separate category.<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>-- Is there anything from the CC1 and CC2 responses that would help with this discussion? There were cetain groups that did talk about the need to create categories. Input received through CC1 is available here: https://community.icann.org/pages/viewpage.action?pageId=59645660<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>-- ICANN.org would need to know if there are specific requirements in the registry agreement.<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>-- There have been a number of categories identified, but need to identify where contractual or procedural differences are needed. Might not be about the category, but about the attributes.<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>-- The top-level should not be the driving part; should consider the business model as well. If we are going to add categories it is important to keep in mind that our group will not imagine all of the business cases.<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>-- Can we come up with a way to ask for differential treatment to allow you as a TLD to innovate or do a different type of business model.<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>-- For those that belong to existing categories if you could look through those requirements and suggest what changes would be needed in the next round. Example, Brand TLDs needing a trademark.<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'><o:p> </o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>From the chat:<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>Rubens Kuhl: Perhaps leaving that definition for last ? We would just need to specify how applications are treated, both equally and differently, and then finding names for the application groups that are treated differently. <o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>Susan Payne: Can we be clear about whether we are talking about new categories? or also the existing ones?<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>Rubens Kuhl: @Maxim, they were already this way in 2012. For instance, a GeoTLD that is also a community TLD and is also a government-organisation registry. <o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>Maxim Alzoba (FAITID): I wonder if using of types of applications should be tag like (and not mutually exclusive )<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>Maxim Alzoba (FAITID): @Alexander, last time Offshores where added to EU region <o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>Annebeth Lange, co-lead WT5: We already have some categories already, haven't we, brands? Out of recognition of the interest of trademark owners? In the same way, as Alan said, there might be a group that are not "true" generics that should take care of the public interest. <o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>Alexander Schubert: @Maxim: E.g. Seychelles: EU?<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>Martin Sutton: Jeff - we already have dotBrands and the rationale behind it, are you requesting for attendees to repeat these and for other categories established during the last application round?<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>Maxim Alzoba (FAITID): @Alexander, I hope it was done for simplicity , but some big companies used it<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>Annebeth Lange, co-lead WT5: Likewise, some geonames, that should be taken "care of" of the nations, through support/non-objection like for example capitols had in the AGB 2012<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>Susan Payne: Brand category already recognised the existing value and importance of the trade mark to the applicant, such that certain provisions of the base RA (including assignment of the registry to someone else) were incompatible with the existing legal rights <o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>Phil Buckingham: that should be the only "exception " - it is either an open or a closed TLD . . Business models whether commercial or not should NOT be templated ( as was last time ) <o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>Annebeth Lange, co-lead WT5: I agree, Susan, but there are also political "rights" to be taken into consideration for names of great value for nations<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>Rubens Kuhl: Restricted TLDs: Brand TLDs, TLDs with eligibility requirements (Spec 12, PIC or simply registry policy), Exclusive Use TLDs. <o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>Donna Austin, Neustar: One of the aims of new gTLDs is to encourage innovation. Being too prescriptive may work against this principle. <o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>Maxim Alzoba (FAITID): +1 Donna<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>Maxim Alzoba (FAITID): @Annabeth, different cultures sometimes have conflicting values and we will not be able to resolve it and thus the approach of protection of cultural values might not work<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>Rubens Kuhl: I wonder if our charter gives us authority to look into merging Spec 12 (registration restriction for Community TLDs) and PICs. Because I believe Spec 12 is just a special case of PIC and PIC could be the overall umbrella for enforceable commitments. <o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>Hadia Elminiawi: I believe that as a community we want to give an opportunity to all categories/communities, while ensuring a fair process <o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>Donna Austin, Neustar: Categories become murky and difficult to process and evaluate when the strings are in contention. <o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>Kristina Rosette (Amazon Registry): +1 Donna. There's the additional issue that the speed (or lack thereof, more accurately) is not conducive to being prescriptive What is an innovative use at application could be completely obsolete 3+ years later (or 6+ as is the case with some of the still-pending contention sets). <o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>Jamie Baxter | dotgay: @Steve .. +1 ... for example it was about registration restrictions for some gTLDs, not about whether they were just community, geo or otherwise<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>Phil Buckingham: Trang - I agree . Its is the contract that will require different specs pertaining to a "said category " . As you say the evaluators will evaluate according to the conrtract specifications .<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span style='font-size:10.5pt'>Annebeth Lange, co-lead WT5: And brands had special needs that in the end were listened to through the clearing house. But there might be other "categories" that have other needs that should be taken into consideration.<o:p></o:p></span></p></div></body></html>