[Gnso-newgtld-wg] New gTLD Subsequent Procedures PDP WG - Initial Report

Thu Jun 21 02:03:12 UTC 2018

There was no consensus. There was no consensus call.  There were no “findings” and there is nothing getting “derailed”, but that is an interesting choice of words on your part.

From the GNSO Working Group Guidelines:  “It is the responsibility of the WG members to make sure any initial drafts represent as much of the diversity of views as possible.”

[cid:image003.png at 01D408C9.5489E940]

Jeff advised these issues will be addressed. I’ll check the redline.
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 01D408C9.54B82530]

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, June 20, 2018 6:32 PM
To: Aikman-Scalese, Anne
Cc: gnso-newgtld-wg at icann.org
Subject: Re: [Gnso-newgtld-wg] New gTLD Subsequent Procedures PDP WG - Initial Report

Anne,

I can say that because it's a fact, one that you keep trying to say different and have to set the record straight each time.

On 20 Jun 2018, at 20:08, Aikman-Scalese, Anne <AAikman at lrrc.com<mailto:AAikman at lrrc.com>> wrote:

Rubens,
I honestly don’t know how you can say that this was not discussed in the Work Track and was only mentioned by me.  You are essentially forcing me to copy and paste the language from the email I had attached into this email  - to document something which is very clear from the November 30 call.  Below I highlight in bold the relevant language regarding the issues raised and the fact that Kurt Pritz was also vocal about this.  (Further,  even if Kurt had not chimed in, the fact that only one person raises an issue for discussion and public comment does not mean it can be roundly ignored. )

By definition of consensus, which doesn't compose unanimity, one person/group position doesn't derail a finding. Multistakeholder group working is not about satisfying each and every member.

Copied and pasted from my confirming email from the November 30 which was circulated to the Work Track 4 list several times:

“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.

Kurt's comment was about additional registry services; his point is that applications trying to innovate and propose new registry services shouldn't be penalised. It has nothing to do with aggregated technical evaluation.

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.)  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.

As I mentioned during the calls, there is a confusion between many of the RSEP acronyms: P for Policy, P for Process, P for Procedure. Neither SubPro policy trumps RSEP policy or vice-versa; they define rules for different audiences (applicants x registries). What was said is the SubPro Registry Services would benefit from following the RSEP Process, and this was actually done in 2012 by ICANN's Org own reckoning,

Since it's not in our charter to redefine the RSEP Policy, we can't even go there; it would be like discussing Transfer Policy in SubPro.

Registry Services was the topic of many calls before its final discussion in person in San Juan, so quoting just one of its discussions does not bring the whole truth to the matter.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg/attachments/20180621/1f693cb7/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 21457 bytes
Desc: image003.png
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg/attachments/20180621/1f693cb7/image003-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 6500 bytes
Desc: image002.png
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg/attachments/20180621/1f693cb7/image002-0001.png>