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

Rubens Kuhl rubensk at nic.br
Thu Jun 21 01:31:41 UTC 2018


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg/attachments/20180620/d140e521/attachment.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/attachments/20180620/d140e521/signature.asc>


More information about the Gnso-newgtld-wg mailing list