[Gnso-newgtld-wg-wt4] Notes and Action Items: New gTLD Subsequent Procedures PDP WG - Track 4 - 30 November 2017
Julie Hedlund
julie.hedlund at icann.org
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>
More information about the Gnso-newgtld-wg-wt4
mailing list