2017-11-30 New gTLD Subsequent Procedures PDP Work Track 4

Notes/ Action Items

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.