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

Mon Jan 22 17:23:34 UTC 2018

Rubens,
Please see responses in line below.  Thank you.
Anne

Anne E. Aikman-Scalese

Of Counsel

520.629.4428 office

520.879.4725 fax

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

_____________________________

[cid:image002.png at 01D3936B.0D75BD00]

Lewis Roca Rothgerber Christie LLP

One South Church Avenue, Suite 2000

Tucson, Arizona 85701-1611

lrrc.com<http://lrrc.com/>

From: Rubens Kuhl [mailto:rubensk at nic.br]
Sent: Friday, January 19, 2018 5:33 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 19 Jan 2018, at 17:06, Aikman-Scalese, Anne <AAikman at lrrc.com<mailto:AAikman at lrrc.com>> wrote:

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.

Divergence statements only apply for reports, not for internal WT-WG deliberations... exactly because any WT deliberation that goes to WG Plenary might still be discussed at that point, if there is WG interest. So it's useful indeed to compile a list of divergences with WT consensus to recall them during WG deliberations, but it can have any format that is useful for discussion and trying to persuade others of your views on it.   Yes - This is why I think it would be helpful to modify the slides to highlight the points of disagreement raised in the November 30 call.

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.

I don't think I followed this one. Could you restate the specific questions on stills to be defined/discussed ?   These are very clearly set forth in my attached e-mail and in the mp3 and the chat transcript from the call of November 30.

Hopefully further discussion by WT4 participants of the issues raised in the attached e-mail will avoid the need for a Minority View Statement.

I think minority views are to embraced, not to be avoided. They are an integral part of the multistakeholder model, and usually is a better indication that the model is working than having no minority views at all in a policy document.
For instance, it worries me much more items where we haven't reached consensus than ones that haven't full consensus but had consensus.

And for the record, some of the items that I listed as consensus were actually full-consensus... but I prefer to leave open the possibility of someone questioning points that had full-consensus during a call, which would make them consensus instead of full-consensus. We'll have to tag the two strictly in making the initial report, but for WT-level discussions congregating them sounds more productive.

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

We'll get to them in the calls ahead, possibly divided by themes instead of during the same call.   Thank you very much.

Rubens

Thank you,
Anne

Full text of Working Group Guidelines:

https://gnso.icann.org/en/council/annex-1-gnso-wg-guidelines-07apr11-en.pdf

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

Footnote:
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>

_____________________________

<image003.png>

Lewis Roca Rothgerber Christie LLP

One South Church Avenue, Suite 2000

Tucson, Arizona 85701-1611

lrrc.com<http://lrrc.com/>

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<mailto: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:
http://mm.icann.org/pipermail/gnso-newgtld-wg-wt4/2017-November/000212.html

The link to the slides is:
http://mm.icann.org/pipermail/gnso-newgtld-wg-wt4/attachments/20171130/d68745f6/SubProWT4Meeting21-0001.pdf

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.

Rubens

________________________________

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.
<RE [Gnso-newgtld-wg-wt4] Registry Services straw-person.eml>

________________________________

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/20180122/722684d9/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 6488 bytes
Desc: image002.png
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg-wt4/attachments/20180122/722684d9/image002-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 6488 bytes
Desc: image002.png
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg-wt4/attachments/20180122/722684d9/image002-0003.png>