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

 

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.   In addition, at 52 minutes, Jeff Neuman stated in chat that the slides would be forwarded to the WT4 list for further comment. 

 

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.

 

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.

 

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

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

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

(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

 

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

 

Thank you,

Anne