[Gnso-newgtld-wg-wt4] Notes and Action Items: New gTLD Subsequent Procedures PDP WG - Track 4 - 30 November 2017

Thu Nov 30 21:50:51 UTC 2017

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg-wt4/attachments/20171130/d68745f6/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SubPro WT4 Meeting #21.pdf
Type: application/pdf
Size: 502872 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg-wt4/attachments/20171130/d68745f6/SubProWT4Meeting21-0001.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4630 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg-wt4/attachments/20171130/d68745f6/smime-0001.p7s>