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

[Rubens Kuhl]

> On 17 Jan 2018, at 20:07, Aikman-Scalese, Anne <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 <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 <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 <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 <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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg-wt4/attachments/20180117/8a7faa28/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 529 bytes
Desc: Message signed with OpenPGP
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg-wt4/attachments/20180117/8a7faa28/signature-0001.asc>