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 Anne E. Aikman-Scalese Of Counsel 520.629.4428 office 520.879.4725 fax AAikman@lrrc.com<mailto:AAikman@lrrc.com> _____________________________ [cid:image003.png@01D38FA4.EADAE960] 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@nic.br] Sent: Wednesday, December 20, 2017 5:20 PM To: Aikman-Scalese, Anne Cc: Cheryl Langdon-Orr; gnso-newgtld-wg-wt4@icann.org; Jeff Neuman Subject: Re: [Gnso-newgtld-wg-wt4] Registry Services straw-person On 20 Dec 2017, at 21:02, Aikman-Scalese, Anne <AAikman@lrrc.com<mailto:AAikman@lrrc.com>> wrote: Rubens, Please excuse the delay in my reply as I have been traveling. I do not understand why you would require that I duplicate effort at a later stage of the subgroup’s deliberations. I'm not requiring, I'm suggesting that by bringing each topic when they are discussed there is more chance of the suggestions being adopted. No one is required to do anything, and I will again point out that my suggestion was done regardless of any slides being changed or not. The call was characterized as a “rough consensus” call and the slides state “Consensus Re” throughout. There were no objections on the call to the language I suggested and Kurt supported one change very vocally. Cheryl specifically asked for suggested language changes during the call and these were provided in chat. As I already mentioned, the call was characterised as a "recap", and repeating this mischaracterisation won't change that. In order for the work of the Subgroup to be “up to date” and to clearly present the issues discussed, I must request once again that the slides be revised in accordance with the call transcript and that the most current work product of the group be posted to the wiki. Hopefully this third written request will not be ignored by Leadership. Your first request was directed to WT Leadership and answered promptly. Your second request was the first directed to Full WG Leadership, and this is the first reiteration of that request. In any case, only them can answer a request made to them. 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.

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. 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. Hopefully further discussion by WT4 participants of the issues raised in the attached e-mail will avoid the need for a Minority View Statement. Could we please get these issues on the agenda for the next call? 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@lrrc.com<mailto:AAikman@lrrc.com> _____________________________ [cid:image003.png@01D3911D.E8B40F70] 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@nic.br] Sent: Wednesday, January 17, 2018 6:16 PM To: Aikman-Scalese, Anne Cc: Jeff Neuman; Cheryl Langdon-Orr; gnso-newgtld-wg-wt4@icann.org Subject: Re: [Gnso-newgtld-wg-wt4] Registry Services straw-person On 17 Jan 2018, at 20:07, Aikman-Scalese, Anne <AAikman@lrrc.com<mailto:AAikman@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/d6874... 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.

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@lrrc.com<mailto:AAikman@lrrc.com> _____________________________ [cid:image002.png@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@nic.br] Sent: Friday, January 19, 2018 5:33 PM To: Aikman-Scalese, Anne Cc: Jeff Neuman; Cheryl Langdon-Orr; gnso-newgtld-wg-wt4@icann.org Subject: Re: [Gnso-newgtld-wg-wt4] Registry Services straw-person On 19 Jan 2018, at 17:06, Aikman-Scalese, Anne <AAikman@lrrc.com<mailto:AAikman@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@lrrc.com<mailto:AAikman@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@nic.br] Sent: Wednesday, January 17, 2018 6:16 PM To: Aikman-Scalese, Anne Cc: Jeff Neuman; Cheryl Langdon-Orr; gnso-newgtld-wg-wt4@icann.org<mailto:gnso-newgtld-wg-wt4@icann.org> Subject: Re: [Gnso-newgtld-wg-wt4] Registry Services straw-person On 17 Jan 2018, at 20:07, Aikman-Scalese, Anne <AAikman@lrrc.com<mailto:AAikman@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/d6874... 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.

Many thanks Cheryl. The work actually done by the group on the “rough consensus” slides should be reflected. One of the reasons for this is that there are references made throughout the slides to “consensus re”. Have a happy New Year! Anne Anne E. Aikman-Scalese Of Counsel 520.629.4428 office 520.879.4725 fax AAikman@lrrc.com<mailto:AAikman@lrrc.com> _____________________________ [cid:image004.png@01D38001.756285B0] Lewis Roca Rothgerber Christie LLP One South Church Avenue, Suite 2000 Tucson, Arizona 85701-1611 lrrc.com<http://lrrc.com/> From: Cheryl Langdon-Orr [mailto:langdonorr@gmail.com] Sent: Wednesday, December 20, 2017 7:53 PM To: Aikman-Scalese, Anne; Jeff Neuman Cc: Rubens Kuhl; gnso-newgtld-wg-wt4@icann.org Subject: Re: [Gnso-newgtld-wg-wt4] Registry Services straw-person Anne, Firstly, if I may be so bold as to speak on behalf of both Jeff and me, we understand that at this time of year and with travel commitments of many of us, delays in response, (especially for volunteers) can be delayed from time to time. Secondly, let me assure you that the Leadership is not ignoring previous messages at all. Thirdly, for now, please rest assured that like all the voices and opinions of our WT and PDP Members, your points of view are being heard and will, along with all other inputs, be considered by the WT as it works towards beginning the drafting of its preliminary recommendations at the start of the 2018 calendar year, for our March Timeline milestone. Finally, when Jeff and I have our next Co-Chair call for 2017, I can assure you that your correspondence on this matter will be on our Agenda to discuss. Cheryl Langdon-Orr ... (CLO) about.me/cheryl.LangdonOrr On 21 December 2017 at 10:02, Aikman-Scalese, Anne <AAikman@lrrc.com<mailto:AAikman@lrrc.com>> wrote: Rubens, Please excuse the delay in my reply as I have been traveling. I do not understand why you would require that I duplicate effort at a later stage of the subgroup’s deliberations. The call was characterized as a “rough consensus” call and the slides state “Consensus Re” throughout. There were no objections on the call to the language I suggested and Kurt supported one change very vocally. Cheryl specifically asked for suggested language changes during the call and these were provided in chat. In order for the work of the Subgroup to be “up to date” and to clearly present the issues discussed, I must request once again that the slides be revised in accordance with the call transcript and that the most current work product of the group be posted to the wiki. Hopefully this third written request will not be ignored by Leadership. Anne Anne E. Aikman-Scalese Of Counsel 520.629.4428 office 520.879.4725 fax AAikman@lrrc.com<mailto:AAikman@lrrc.com> _____________________________ [cid:image003.png@01D38001.753FE280] Lewis Roca Rothgerber Christie LLP One South Church Avenue, Suite 700 Tucson, Arizona 85701-1611 lrrc.com<http://lrrc.com/> From: Rubens Kuhl [mailto:rubensk@nic.br<mailto:rubensk@nic.br>] Sent: Wednesday, December 13, 2017 2:22 PM To: Aikman-Scalese, Anne Cc: Cheryl Langdon-Orr; gnso-newgtld-wg-wt4@icann.org<mailto:gnso-newgtld-wg-wt4@icann.org> Subject: Re: [Gnso-newgtld-wg-wt4] Registry Services straw-person Importance: High Anne, Since your request was directed to WG co-chairs I can't answer on it specifically, but regardless of what happens regarding the meeting #21 slides, I suggest that you table the changes you meant for specific topics for meetings that happen in the future so these positions have consideration at some point, and they are either incorporated into proposed languages or considered but not incorporated. When we have meetings for those topics I doubt people will look at the slide archive, but they will definitely join the call, listen to recording or read transcripts. Rubens Em 13 de dez de 2017, à(s) 16:25:000, Aikman-Scalese, Anne <AAikman@lrrc.com<mailto:AAikman@lrrc.com>> escreveu: Cheryl and Jeff, Rubens says there will be no changes to the slides even though I was asked during the call to suggest language and even though the understanding was changes would be made to the slides since the items were noted as “consensus re”. I must strongly object to Rubens’ refusal to revise the slides in accordance with the transcript from the call, including Kurt Pritz’ very vocal support for one of the changes and no objections from others to the other requested changes. As written, the slides are not reflective of the last call. If Rubens refuses to revise the slides, then please ask staff to do so based on the language that was typed into chat and agreed in the recording. Thank you, Anne Anne E. Aikman-Scalese Of Counsel 520.629.4428 office 520.879.4725 fax AAikman@lrrc.com<mailto:AAikman@lrrc.com> _____________________________ <image003.png> Lewis Roca Rothgerber Christie LLP One South Church Avenue, Suite 700 Tucson, Arizona 85701-1611 lrrc.com<http://lrrc.com/> From: Rubens Kuhl [mailto:rubensk@nic.br] Sent: Tuesday, December 12, 2017 5:33 PM To: Aikman-Scalese, Anne Cc: Cheryl Langdon-Orr; gnso-newgtld-wg-wt4@icann.org<mailto:gnso-newgtld-wg-wt4@icann.org> Subject: Re: [Gnso-newgtld-wg-wt4] Registry Services straw-person Importance: High On 12 Dec 2017, at 20:31, Aikman-Scalese, Anne <AAikman@lrrc.com<mailto:AAikman@lrrc.com>> wrote: Cheryl and Rubens, There were consistent references to “rough consensus” in the discussion during this meeting. As was mentioned right when the meeting started, it wasn't a meeting to decide anything, so no any mention was a reference to previous meetings when decisions were made. In addition, there were several changes to the slides which were recommended and agreed. These changes do not appear in the slides at this time. When may we expect them? We won't rewrite history and pretend something different than actually presented had happened. It was a recap, so anything that might require change has to be decided during meetings that actually decide any of the topics where you can suggest changes to actual decisions. 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. ________________________________ 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. ________________________________ 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.