<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 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:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
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;}
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;}
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-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:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style></head><body bgcolor=white lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal>Dear Work Track members,<o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal>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 and recording at: <a href="https://community.icann.org/x/ERohB">https://community.icann.org/x/ERohB</a>.<o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal>Slides are attached for reference and some chat room excerpts are included.<o:p></o:p></p><p class=MsoNormal><b> </b><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>----------------------------------------------------------------------------------------<o:p></o:p></p><p class=MsoNormal><b>Notes and Action Items: New gTLD Subsequent Procedures PDP WG - Track 4 – 30 November 2017</b><o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>1. SOIs: None.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>2. Recap of pending issues:<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Slide 5 -- IDNs<o:p></o:p></p><p class=MsoNormal>Consensus so far:<o:p></o:p></p><p class=MsoNormal>-- Supporting continuing having IDN TLDs.<o:p></o:p></p><p class=MsoNormal>-- Support allowing 1-char IDN TLDs in specific situations.<o:p></o:p></p><p class=MsoNormal>-- Use then-current version of RZ-LGR (RZ-LGR-2 at this point).<o:p></o:p></p><p class=MsoNormal>-- Automate RZ-LGR compliance checking as much as feasible (algorithmically) in the application system.<o:p></o:p></p><p class=MsoNormal>-- Support IDN Variant TLDs if operated by same RO -- still pending: policy requirements.<o:p></o:p></p><p class=MsoNormal>-- NOTE: All consensus cals on this topic still require confirmation of language.<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>Rubens Kuhl: Consenus as stated in GNSO guidelines, which is rough consensus. <o:p></o:p></p><p class=MsoNormal>Rubens Kuhl: Rough consensus is how IETF prefer calling it. <o:p></o:p></p><p class=MsoNormal>Anne Aikman-Scalese (IPC): GNSO Working Group Guidelines specify several different levels of consensus. These include Minority Statement where applicable.<o:p></o:p></p><p class=MsoNormal>Maxim Alzoba (FAITID): what kind of specific situations for 1-char IDN TLDs we forsee? Does Unicode Character 'BEER MUG' (U+1F37A) count as one?<o:p></o:p></p><p class=MsoNormal>Cheryl Langdon-Orr (CLO - PDP Co-Chair): After today as we review we will then put together a more detailedtime line for what we need to still deal with and settle where possible before the publication of the Preliminary Report in March<o:p></o:p></p><p class=MsoNormal>Cheryl Langdon-Orr (CLO - PDP Co-Chair): Maxim wouldn't that be an emoji?<o:p></o:p></p><p class=MsoNormal>Cheryl Langdon-Orr (CLO - PDP Co-Chair): not an IDN<o:p></o:p></p><p class=MsoNormal>Maxim Alzoba (FAITID): a single item describing the concept, I am not sure we will not have enoji TLDs<o:p></o:p></p><p class=MsoNormal>Maxim Alzoba (FAITID): similar to hyerogliphs e.t.c.<o:p></o:p></p><p class=MsoNormal>Cheryl Langdon-Orr (CLO - PDP Co-Chair): Internationalized Domain Names Languages have to date only referred to 'official <o:p></o:p></p><p class=MsoNormal>Maxim Alzoba (FAITID): thanks for the clarification<o:p></o:p></p><p class=MsoNormal>Cheryl Langdon-Orr (CLO - PDP Co-Chair): ' languages and scripts but I do not beleive Symbols per se<o:p></o:p></p><p class=MsoNormal>Cheryl Langdon-Orr (CLO - PDP Co-Chair): But I am not an expert in this<o:p></o:p></p><p class=MsoNormal>Cheryl Langdon-Orr (CLO - PDP Co-Chair): 6 <o:p></o:p></p><p class=MsoNormal>Maxim Alzoba (FAITID): so far IANA IDN tables have hyeroglyps https://www.iana.org/domains/idn-tables/tables/accenture_egyp_2.5.txt for example. and as I understand all current TLD's IDNs are to be allowed <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Slide 6 -- Universal Acceptance<o:p></o:p></p><p class=MsoNormal>Consensus so far:<o:p></o:p></p><p class=MsoNormal>-- Support mentioning UASG to applicants.<o:p></o:p></p><p class=MsoNormal>-- Not create additional requirements regarding UA.<o:p></o:p></p><p class=MsoNormal>-- Consensus calls on this topic still require confirmration of language.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Slide 7 -- Technical Evaluation<o:p></o:p></p><p class=MsoNormal>Consensus so far:<o:p></o:p></p><p class=MsoNormal>-- Support aggregating technical evaluation as much as feasible -- including between procedrues, which enables the RSP Program.<o:p></o:p></p><p class=MsoNormal>-- Support staff recommendation for technical questions only being pass or fail, not 0-1-2 points in some cases.<o:p></o:p></p><p class=MsoNormal>-- Drill down int CQs still pending information from GDD -- number of CQs at 2012 deemed excessive, suggesting improvements to questions language.<o:p></o:p></p><p class=MsoNormal>-- Other than language and scoring improvements, Technical Evaluation model deemed to be used by SubPro, probably as RSP Program Criteria.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Discussion:<o:p></o:p></p><p class=MsoNormal>-- Friendly amendment with respect to the first bullet re: "as much as feasible" we need to also say "(and consistent was policy as to the order of processing to be determined by [Work Track X])".<o:p></o:p></p><p class=MsoNormal>-- Until the time comes for the order of that applicant to be released -- the order of the processing and publishing comes from the other Work Track.<o:p></o:p></p><p class=MsoNormal>-- Could be even a little stronger. We thought that additional technical evaluation shouldn't slow down those applications -- they should retain their place in queue. They shouldn't be penalized from a timing statement. Concerned about a statement that says "as much as feasible" since that is vague.<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>Anne Aikman-Scalese (IPC): My proposal for the friendly amendment refers to the fact that aggregating should be (consistent with order of priority to be determined by Work Track ___ recommendations). Agree with Kurt that innovative proposals should not be disadvantaged.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Slide 8 -- Registry Services<o:p></o:p></p><p class=MsoNormal>Consensus so far:<o:p></o:p></p><p class=MsoNormal>-- Support a list of pre-approved services.<o:p></o:p></p><p class=MsoNormal>-- Define RSEP as the tool to evaluate new registry services.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Still to define:<o:p></o:p></p><p class=MsoNormal>-- Whether applicants need to specify which pre-approved services would be provided.<o:p></o:p></p><p class=MsoNormal>-- Pre-approved services list, or a minimum list and a process to expand such list in implementation.<o:p></o:p></p><p class=MsoNormal>-- Processing of applications suggesting new registry services.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Discussion:<o:p></o:p></p><p class=MsoNormal>-- There is an issue that isn't clearly defined: when we say processing of applications I think we are talking about the order of processing. The point that is missing is whether or not a TLD registry application is required to disclose new registry services, which is the policy in the AGB. ap We know it can do something later and use RSEP.<o:p></o:p></p><p class=MsoNormal>-- Reframe it slightly? Any changes to existing requirements for disclosing new registry services? <o:p></o:p></p><p class=MsoNormal>-- Bullet point 2 implies that we are changing the policy -- define RSEP as the tool to evaluate new registry services.<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>Anne Aikman-Scalese (IPC): "whether a new gTLD application should be required to disclose new services at the time of application"<o:p></o:p></p><p class=MsoNormal>Jeff Neuman: Actually RSEP was always how new registry services is evaluated<o:p></o:p></p><p class=MsoNormal>Rubens Kuhl: Consensus is not unanimity. <o:p></o:p></p><p class=MsoNormal>Maxim Alzoba (FAITID): The RSEP only for the Registries (who have Registry Agreement), and might not be so for Applicants <o:p></o:p></p><p class=MsoNormal>Maxim Alzoba (FAITID): at least the policy itself is older than the therm Applicant<o:p></o:p></p><p class=MsoNormal>Maxim Alzoba (FAITID): *term<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal> Slide 9 -- Financial Evaluation<o:p></o:p></p><p class=MsoNormal>Consensus so far:<o:p></o:p></p><p class=MsoNormal>-- Rebuild it from scratch.<o:p></o:p></p><p class=MsoNormal>-- No to evaluate business-model but look into "marketplace health".<o:p></o:p></p><p class=MsoNormal>-- Nuanced interpretation of how 2012 evaluation was not a business-model evaluation -- still pending.<o:p></o:p></p><p class=MsoNormal>-- 2 straw models already presented, 2 new straw models yet to be presented.<o:p></o:p></p><p class=MsoNormal>-- Consideration of whether to include third-party certification.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Slide 10 -- Name Collisions in legacy and 2012 gTLDs<o:p></o:p></p><p class=MsoNormal>-- Consensus on keeping the procedures for 2012-round gTLDs as they are.<o:p></o:p></p><p class=MsoNormal>-- Discussions on name collisions in legacy gTLDs still pending.<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>Maxim Alzoba (FAITID): legacy TLDs have different contracts then new gTLDs , so Name Collisions are not applicable<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Slide 11 -- Name collisions for subsequent procedures<o:p></o:p></p><p class=MsoNormal>Consensus so far:<o:p></o:p></p><p class=MsoNormal>-- On expanding 2012 Framework with categorization of low, aggravated, and high risk.<o:p></o:p></p><p class=MsoNormal>-- On elaborating "do not apply" and "exercise care" lists.<o:p></o:p></p><p class=MsoNormal>-- On keeping readiness requirement for life-threatening collisions.<o:p></o:p></p><p class=MsoNormal>-- For low-risk strings, consensus on starting controlled interruption ASAP and delegate execution to ICANN.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Still pending:<o:p></o:p></p><p class=MsoNormal>-- Guidelines, or guidance to make guidelines, for categorization and list creation, including possible applicant opionion and collision framework.<o:p></o:p></p><p class=MsoNormal>-- Definition of SLA for collision readiness.<o:p></o:p></p><p class=MsoNormal>-- Integration with Board-requested SSAC guidance.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Discussion:<o:p></o:p></p><p class=MsoNormal>-- Thought we had consensus on the "do not apply" and "exercise care" lists that this has to be an early evaluation.<o:p></o:p></p><p class=MsoNormal>-- What does "delegate execution to ICANN" mean in the 4th bullet? Suggest new wording to make it more clear.<o:p></o:p></p><p class=MsoNormal>-- If an applicant believed there wouldn't be a collision risk they could state that.<o:p></o:p></p><p class=MsoNormal>-- Might help to use the word "proposal" from the applicant.<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>Rubens Kuhl: Means ICANN would do the controlled interruption, not the registries<o:p></o:p></p><p class=MsoNormal>Maxim Alzoba (FAITID): there were talks about 90 days and 120 days , as I remember<o:p></o:p></p><p class=MsoNormal>Rubens Kuhl: About the length, it would be the same as 2012, since there was no consensus to change it. <o:p></o:p></p><p class=MsoNormal>Maxim Alzoba (FAITID): ok<o:p></o:p></p><p class=MsoNormal>Maxim Alzoba (FAITID): do we know how much time name collisions lists calculation takes next time? a year like last time?<o:p></o:p></p><p class=MsoNormal>Rubens Kuhl: That means than an applicant could mention whether they believe the string is low risk, aggravated risk, or high risk. And if one of the later two, they can suggest a framework in the application. <o:p></o:p></p><p class=MsoNormal>Nathaniel Edwards: Wouldn't applicants always claim there isn't a collision risk?<o:p></o:p></p><p class=MsoNormal>Rubens Kuhl: Note those slides are recap, they are not tentative language. <o:p></o:p></p><p class=MsoNormal>Cheryl Langdon-Orr (CLO - PDP Co-Chair): No doubt<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Slide 12 -- Root Zone Scaling<o:p></o:p></p><p class=MsoNormal>-- Consultation sent to SSAC, RSSAC, and OCTO.<o:p></o:p></p><p class=MsoNormal>-- Consensus on separating application processing and contracting capacity from root zone scalability.<o:p></o:p></p><p class=MsoNormal>-- WT apparently leaning towards removing hard ceilings, replacing with continued monitoring.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p></div></body></html>