[Gnso-newgtld-wg-wt4] Registry Services straw-person

Aikman-Scalese, Anne AAikman at lrrc.com
Fri Jan 19 19:06:19 UTC 2018

Thanks Rubens – I am pasting the relevant language as to Consensus from the GNSO Working Group Guidelines below.  Happy to develop either a Divergence Statement or a Minority View Statement for the issues raised with the slides as needed and to bring that before the plenary at the proper time.  This would, of course, not apply to any items “Still To Be Defined” until after further discussion by WT4 participants.  In this regard, I’ll await the Co-Chair’s determination of issues “still to be defined/discussed” in Work Track 4 as per the points raised in my attached e-mail.  Hopefully further discussion by WT4 participants of the issues raised in the attached e-mail will avoid the need for a Minority View Statement.

Could we please get these issues on the agenda for the next call?
Thank you,

Full text of Working Group Guidelines:


3.6 Standard Methodology for Making Decisions
The Chair will be responsible for designating each position as having one of the following designations:
•Full consensus when no one in the group speaks against the recommendation in its last readings.
This is also sometimes referred to as Unanimous Consensus.

•Consensus - a position where only a small minority disagrees but most agree

For those that are unfamiliar with ICANN usage, you may associate the definition of „Consensus‟ with other definitions and terms of art such as rough consensus or near consensus. It should be noted, however, that in the case of a GNSO PDP
originated Working Group, all reports, especially Final Reports, must restrict themselves to the term „Consensus‟ as this may
have legal implications.

•Strong support but significant opposition  - a position where, while most of the group supports a
recommendation, there are a significant number of those who do not support it.

•Divergence (also referred to as No Consensus)
-a position where there isn't strong support for
any particular position, but many different points of view. Sometimes this is due to irreconcilable
differences of opinion and sometimes it is due to the fact that no one has a particularly strong or
convincing viewpoint, but the members of the group agree that it is worth listing the issue
in the report nonetheless.

•Minority View refers to a proposal where a small number of people support the recommendation.
This can happen in response to a Consensus, Strong support but significant Opposition,  and No Consensus; or, it can happen in cases where there is neither support nor opposition to a suggestion made by a small number of individuals.  In cases of Consensus, Strong support but significant opposition, and No Consensus, an effort should be made to document that variance in viewpoint and to present any Minority View recommendations that may have been made. Documentation of Minority View recommendations normally depends on text offered by the proponent(s).

Anne E. Aikman-Scalese

Of Counsel

520.629.4428 office

520.879.4725 fax

AAikman at lrrc.com<mailto:AAikman at lrrc.com>


[cid:image003.png at 01D3911D.E8B40F70]

Lewis Roca Rothgerber Christie LLP

One South Church Avenue, Suite 2000

Tucson, Arizona 85701-1611


From: Rubens Kuhl [mailto:rubensk at nic.br]
Sent: Wednesday, January 17, 2018 6:16 PM
To: Aikman-Scalese, Anne
Cc: Jeff Neuman; Cheryl Langdon-Orr; gnso-newgtld-wg-wt4 at icann.org
Subject: Re: [Gnso-newgtld-wg-wt4] Registry Services straw-person

On 17 Jan 2018, at 20:07, Aikman-Scalese, Anne <AAikman at lrrc.com<mailto:AAikman at lrrc.com>> wrote:

Dear Subsequent Procedures Work Track 4 Leadership and Participants,

I reviewed the chat and the mp3 recording from Call #21 which occurred November 30, 2017.  The slides were referred to consistently as “rough consensus” and are drafted as “Consensus Re”.  (Rubens also refers to “rough consensus” in writing in the chat.)

As I mentioned a few times, rough consensus is IETF nomenclature, while GNSO classifies the same level of agreement as consensus; even so, saying "rough consensus" usually helps in reminding people that consensus in GNSO doesn't mean full consensus. https://gnso.icann.org/en/council/summary-gnso-wg-guidelines-26mar14-en.pdf, page 3, has such definitions. The original SCI recommendation (https://gnso.icann.org/en/council/annex-1-gnso-wg-guidelines-07apr11-en.pdf) mentioned this about consensus terminology: "For those that are unfamiliar with ICANN usage, you may associate the definition of „Consensus‟ with other definitions and terms of art such as rough consensus or near consensus. It should be noted, however, that in the case of a GNSO PDP originated Working Group, all reports, especially Final Reports, must restrict themselves to the term „Consensus‟ as this may have legal implications."

So while we from time to time might explain "Consensus" by analogy with rough consensus or near consensus, written materials should restrict to writing "consensus" as much as possible for that situation.

Please note Maxim echoed in chat my comment that it would be good to get slides before the call – at least 24 hours if possible.

That's a good point for most meetings, but I fail to see the need in this specific meeting since it was a recap, not a meeting for deciding anything.

 In addition, at 52 minutes, Jeff Neuman stated in chat that the slides would be forwarded to the WT4 list for further comment.

It was sent by Julie Hedlund the same day, attached to the message regarding notes and action items. The message is archived here:

The link to the slides is:

Items as to which we, as members of the WT 4 group,  had input during the call include:

1.       At 15 minutes into the call, discussion of policy regarding aggregated technical evaluation should not affect order of processing applications, subject to the policy-making recommendations of Work Track ___  “as much as feasible (and consistent the order of processing of applications as recommended by Work Track X”.  This concept was supported vocally by Kurt Pritz at 18 minutes into the call and said “Additional technical evaluation should not retard or slow down applications….they should retain their place in queue and should not be penalized in any way from a timing standpoint”.  Kurt did not like the “as much as feasible” language either.  He said it was too vague as policy language.

In policy language there is always a thin balance between too prescriptive and too vague. But I think the point here goes to more than just language; it seems the difference between evaluation and result release was missed. Places in queues, like the one from the 2012 raffle, are part of results and contracting phase. Whatever the policy that is determined to guide in which order results are published and in which order applications go to contracting or to contention set resolution is not linked to how evaluation is performed.

BTW, In the likely scenario for the next procedure where most technical evaluations won't need to be performed due to the RSP Program, most evaluations will probably be done in a short period and be ready almost at the same time. So any suggestions on how to order applications for passing other bottlenecks in the system like contracting and auction is some other than WT4 mission to define.

2.       At 27 minutes into the call – Registry Services Slide  (Slide 8?)  – Clarify the issue Still to Be Defined – “whether a new gTLD applicant should be required to disclose new services at the time of application”.   Cheryl said this additional bullet is at 34 min into the call.   Cheryl also confirms in this discussion that there are in fact three Straw models still under discussion on this question and that this can be clarified in the slides.    (The second bullet point is misleading in that it states that RSEP is “the tool”  (emphasis added) for proposing new services.  This implies a consensus that RSEP trumps the existing policy that requires disclosure of proposed new services in a new gTLD application.)

During of after the call it has become clear that the RSEP acronym has a number of meanings in ICANN policies contracts, the more notable two being P as in Policy and P as in Procedure. I will mention the later P unabridged in order to be clear what I am talking.

It's not a consensus, it's a fact. RSEPpolicy can be invoked by a registry as soon as it gets a contract, because the contract comes with all benefits and requirements of consensus policies, RSEPpolicy included. And since this PDP is not tasked with reviewing RSEPolicy, there is nothing preventing an applicant that has not disclosed its intentions of applying for a new registry service  in its application, to apply to one after getting a contract.

What was mentioned both during the discussions and during the recap was to use RSEProcedure to evaluate proposed registry services. Which BTW was almost what happened in 2012 (Confirmed by ICANN Org), because in the absence of more detailed guidelines in AGB, RSEProcedure was mimicked to what was done. The change from 2012 would be to state that upfront, giving more clarity to applicants and ensuring fairness among applicants and registries since new services from both would be evaluated by the same rule.

Nowhere in the slides is there a reference to the discussion re the three Straw models.  Thus, this is an issue “Still To Be Defined”.  As per Cheryl’s comment, “This is clearly being marked out as work still to be done.”  Maxim also points out in chat that RSEP is only for registries that have a Registry Agreement and might not be so for Applicants.

RSEPolicy only for registries; RSEProcedure could be for applicants if the policy says so, or not if doesn't. The use of RSEProcedure in RSEPolicy doesn't preclude its use in SubPro.

3.       At 40 minutes into the call –Slide 11 – discussion of name collision “rough consensus”.  The following points were made:

(a)    When we speak of “delegating execution of name collision controlled interruption to ICANN”, we mean the act of controlled interruption, not the policy or the determination of the period of controlled interruption

Exactly. Good point when we come to a proposed language on this.

(b)   Regarding the period, it is still to be determined whether Work Track 4 is recommending 90 days or 120 days

Since there was no consensus to change it, it would still be 90 days minimum as in 2012. It would be hard to justify expanding to 120 days since available evidence points to 60 days being enough... but there was no consensus to change it 60 days, in the same way there would be no consensus to change it to 120 days.

And considering that it would be started by ICANN soon enough, it will likely ran for 150 days or more, as ICANN would still be processing most of the applications at the time. But policy-wise, it would be 90-day minimum.

(c)    Re “do not apply” and “exercise care” lists, we need to consider a process whereby applicants could be notified early on if a gTLD that is not on the “do not apply” list will not be allowed to proceed due to name collision risk, or alternatively, will at least be advised very quickly of the category of name collision risk.   (This needs to be done so no applicants are stuck with applications pending for years as occurred in the 2012 round.)

Since both these lists would be ready prior to the procedure, the application system itself could prevent applications to strings in the "do not apply" list, and give a warning and require a name collision mitigation framework to be submitted for "exercise care" lists.

(d)   Regarding the point “Still to be Defined” re “possible applicant opinion and submission of collision framework”, clarify that we are discussing the possibility that the applicant could submit its own assessment and its own proposal re name collision mitigation

Exactly, but I don't see where this would impact language... but if/when it does, we sure need to specify applicant's assessment is an opinion, not a self-certification.

 Again, I found this call difficult in that the slides were presented as “Consensus Re” and had not been circulated prior to the call.   (I have made this same comment/request more than once in relation to Work Track 4.)

Answered above.

Nevertheless, reviewing the chat and the mp3, everyone did their best to give input and this work should be reflected in whatever version of the slides Jeff and Cheryl elect to circulate to the list.

You mean a possible new version to be circulated supplanting  the slides as presented in the meeting that were already circulated.



This message and any attachments are intended only for the use of the individual or entity to which they are addressed. If the reader of this message or an attachment is not the intended recipient or the employee or agent responsible for delivering the message or attachment to the intended recipient you are hereby notified that any dissemination, distribution or copying of this message or any attachment is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender. The information transmitted in this message and any attachments may be privileged, is intended only for the personal and confidential use of the intended recipients, and is covered by the Electronic Communications Privacy Act, 18 U.S.C. §2510-2521.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg-wt4/attachments/20180119/ebc67da4/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 6518 bytes
Desc: image003.png
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg-wt4/attachments/20180119/ebc67da4/image003-0001.png>
-------------- next part --------------
An embedded message was scrubbed...
From: "Aikman-Scalese, Anne" <AAikman at lrrc.com>
Subject: RE: [Gnso-newgtld-wg-wt4] Registry Services straw-person
Date: Wed, 17 Jan 2018 22:07:42 +0000
Size: 54398
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg-wt4/attachments/20180119/ebc67da4/REGnso-newgtld-wg-wt4RegistryServicesstraw-person-0001.mht>

More information about the Gnso-newgtld-wg-wt4 mailing list