Dear Work Track members, Please see below the action items and notes from the meeting today. 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. See the chat transcript and recording at: https://community.icann.org/x/ERohB. Slides are attached for reference and some chat room excerpts are included. Kind regards, Julie Julie Hedlund, Policy Director ---------------------------------------------------------------------------------------- Notes and Action Items: New gTLD Subsequent Procedures PDP WG - Track 4 – 30 November 2017 1.     SOIs: None. 2.     Recap of pending issues: Slide 5 -- IDNs Consensus so far: -- Supporting continuing having IDN TLDs. -- Support allowing 1-char IDN TLDs in specific situations. -- Use then-current version of RZ-LGR (RZ-LGR-2 at this point). -- Automate RZ-LGR compliance checking as much as feasible (algorithmically) in the application system. -- Support IDN Variant TLDs if operated by same RO -- still pending: policy requirements. -- NOTE: All consensus cals on this topic still require confirmation of language.

From the chat:

Rubens Kuhl: Consenus as stated in GNSO guidelines, which is rough consensus. Rubens Kuhl: Rough consensus is how IETF prefer calling it. Anne Aikman-Scalese (IPC):  GNSO Working Group Guidelines specify several different levels of consensus.  These include Minority Statement where applicable. 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? 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 Cheryl Langdon-Orr (CLO - PDP Co-Chair): Maxim wouldn't that be an emoji? Cheryl Langdon-Orr (CLO - PDP Co-Chair): not an IDN Maxim Alzoba (FAITID): a single item describing the concept, I am not sure we will not have enoji TLDs Maxim Alzoba (FAITID): similar to hyerogliphs e.t.c. Cheryl Langdon-Orr (CLO - PDP Co-Chair): Internationalized Domain Names Languages have to date only referred to 'official Maxim Alzoba (FAITID): thanks for the clarification Cheryl Langdon-Orr (CLO - PDP Co-Chair): ' languages and scripts  but I do not beleive Symbols per se Cheryl Langdon-Orr (CLO - PDP Co-Chair): But I am not an expert in this Cheryl Langdon-Orr (CLO - PDP Co-Chair): 6 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 Slide 6 -- Universal Acceptance Consensus so far: -- Support mentioning UASG to applicants. -- Not create additional requirements regarding UA. -- Consensus calls on this topic still require confirmration of language. Slide 7 -- Technical Evaluation Consensus so far: -- Support aggregating technical evaluation as much as feasible -- including between procedrues, which enables the RSP Program. -- Support staff recommendation for technical questions only being pass or fail, not 0-1-2 points in some cases. -- Drill down int  CQs still pending information from GDD -- number of CQs at 2012 deemed excessive, suggesting improvements to questions language. -- Other than language and scoring improvements, Technical Evaluation model deemed to be used by SubPro, probably as RSP Program Criteria. Discussion: -- 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])". -- 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. -- 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.

From the chat:

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. Slide 8 -- Registry Services Consensus so far: -- Support a list of pre-approved services. -- Define RSEP as the tool to evaluate new registry services. Still to define: -- Whether applicants need to specify which pre-approved services would be provided. -- Pre-approved services list, or a minimum list and a process to expand such list in implementation. -- Processing of applications suggesting new registry services. Discussion: -- 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. -- Reframe it slightly?  Any changes to existing requirements for disclosing new registry services?  -- Bullet point 2 implies that we are changing the policy -- define RSEP as the tool to evaluate new registry services.

From the chat:

Anne Aikman-Scalese (IPC): "whether a new gTLD application should be required to disclose new services at the time of application" Jeff Neuman: Actually RSEP was always how new registry services is evaluated Rubens Kuhl: Consensus is not unanimity. Maxim Alzoba (FAITID): The RSEP only for the Registries (who have Registry Agreement), and might not be so for Applicants Maxim Alzoba (FAITID): at least the policy itself is older than the therm Applicant Maxim Alzoba (FAITID): *term Slide 9 -- Financial Evaluation Consensus so far: -- Rebuild it from scratch. -- No to evaluate business-model but look into "marketplace health". -- Nuanced interpretation of how 2012 evaluation was not a business-model evaluation -- still pending. -- 2 straw models already presented, 2 new straw models yet to be presented. -- Consideration of whether to include third-party certification. Slide 10 -- Name Collisions in legacy and 2012 gTLDs -- Consensus on keeping the procedures for 2012-round gTLDs as they are. -- Discussions on name collisions in legacy gTLDs still pending.

From the chat:

Maxim Alzoba (FAITID): legacy TLDs have different contracts then new gTLDs , so Name Collisions are not applicable Slide 11 -- Name collisions for subsequent procedures Consensus so far: -- On expanding 2012 Framework with categorization of low, aggravated, and high risk. -- On elaborating "do not apply" and "exercise care" lists. -- On keeping readiness requirement for life-threatening collisions. -- For low-risk strings, consensus on starting controlled interruption ASAP and delegate execution to ICANN. Still pending: -- Guidelines, or guidance to make guidelines, for categorization and list creation, including possible applicant opionion and collision framework. -- Definition of SLA for collision readiness. -- Integration with Board-requested SSAC guidance. Discussion: -- Thought we had consensus on the "do not apply" and "exercise care" lists that this has to be an early evaluation. -- What does "delegate execution to ICANN" mean in the 4th bullet?  Suggest new wording to make it more clear. -- If an applicant believed there wouldn't be a collision risk they could state that. -- Might help to use the word "proposal" from the applicant.

From the chat:

Rubens Kuhl: Means ICANN would do the controlled interruption, not the registries Maxim Alzoba (FAITID): there were talks about 90 days and 120 days , as I remember Rubens Kuhl: About the length, it would be the same as 2012, since there was no consensus to change it. Maxim Alzoba (FAITID): ok Maxim Alzoba (FAITID): do we know how much time name collisions lists calculation takes next time? a year like last time? 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. Nathaniel Edwards: Wouldn't applicants always claim there isn't a collision risk? Rubens Kuhl: Note those slides are recap, they are not tentative language. Cheryl Langdon-Orr (CLO - PDP Co-Chair): No doubt Slide 12 -- Root Zone Scaling -- Consultation sent to SSAC, RSSAC, and OCTO. -- Consensus on separating application processing and contracting capacity from root zone scalability. -- WT apparently leaning towards removing hard ceilings, replacing with continued monitoring.