Em 31 de ago de 2017, à(s) 14:10:000, Aikman-Scalese, Anne <AAikman@lrrc.com> escreveu:

Well here we are definitely establishing a disincentive to proposing new innovative services. We are saying in this straw proposal that if you propose new services, it is going to cost you more to apply and we don't know how much more. This is a terrible idea running a program which is otherwise touted as fostering innovation and competition.

Anne, Competition doesn't necessarily need new services, only new players and/or new methods to deliver current services. As for innovation, the evidence-driven nature of PDPs makes it undeniable that none was suggested in 2012. The only examples some may quote are Google dotless proposal, which is similar to what Verisign did for a while in .COM/.NET, and .frogans, an innovation that required no new registry services (see https://www.icann.org/sites/default/files/tlds/frogans/frogans-agmt-html-19d... <https://www.icann.org/sites/default/files/tlds/frogans/frogans-agmt-html-19d...> agreement for reference). We don't know how much would be the fee because we can't know at this point, but that's something will have to be clear to any applicants, and goes more to the predictability discussions than to WT4 discussions.

My proposal is that there be two tracks - and not that the application fee changes if you propose new services. If no new services are proposed in evaluation, you go to one dept/staff set. If new services are proposed, you go to another section for evaluation so that at least some new services proposals get launched in parallel to those proceeding without new services.

That is exactly the opposite of streamlining, and the opposite of cost-recovery. But the WT dealing with applicant support could be amenable to the idea of subsidizing innovative applications, and I suggest raising that at that forum...

New services should in fact be part of evaluation (and not delayed to contracting phase where the community is not involved.)

The Registry Services Policy already specifies that community involvement in new services only happens when a security and stability concern is identified, and we can't go against that policy. And this is something that already happens every day... even services where a competition concern is identified are not prevented from being deployed: they just get a 45-day penalty where a competition authority may or may not prevent the launch of the service. Some references on the current Registry Services policy: https://gnso.icann.org/en/issues/registry-services/final-rpt-registry-approv... <https://gnso.icann.org/en/issues/registry-services/final-rpt-registry-approv...> (GNSO Policy as approved by Council) https://gnso.icann.org/en/meetings/review-process-registry-change-requests25... <https://gnso.icann.org/en/meetings/review-process-registry-change-requests25...> (Process flowchart as approved by Council) https://www.icann.org/resources/board-material/resolutions-2005-11-08-en <https://www.icann.org/resources/board-material/resolutions-2005-11-08-en> (Board resolution approving GNSO Registry Services Policy) https://www.icann.org/resources/unthemed-pages/net-registry-agreement-2005-0... <https://www.icann.org/resources/unthemed-pages/net-registry-agreement-2005-0...> (.NET agreement of the time, mentioned in Board Resolution) Rubens

On Aug 31, 2017, at 7:23 PM, Aikman-Scalese, Anne <AAikman@lrrc.com> wrote:

If no innovation occurred in 2012, then we have a serious problem because there is little reason for the program to exist to establish unlimited domains.

Co-chair hat on: The question of whether should there be new gTLDs was one of the first the Full WG addressed, and the answer was yes. WT4 is not empowered to reopen that question. Co-chair hat off: Even if there was no innovation, the CCT review indicates increase in competition and customer choice, so at least those objectives were achieved. I believe that most innovation that could occur is currently deterred by the gTLD framework itself, so the same factors preventing current registries from launch innovative services deter new gTLDs that could bring innovation; it's not a different string that would enable an innovation that wasn't possible before. I think I sent once to this list, but it's a good time to send it again: a TED presentation that identified why startups succeed... the (spoilers ahead) answer is timing. And considering the gigantic failure of the program in having predictable timing, it's not a surprise that no innovation came of it. https://www.ted.com/talks/bill_gross_the_single_biggest_reason_why_startups_... Also of notice is that most of what we are seeing in this century derives from permission-less innovation, and a program that subjects ideas to one evaluation after another is anything but permission-less. If that's what it takes to have stability in a foundational resource such as the DNS, then what we do is justified, but we have to admit guilt in sacrificing innovation in order to safeguard stability. Rubens

On Aug 31, 2017, at 8:22 PM, Aikman-Scalese, Anne <AAikman@lrrc.com> wrote:

Rubens, I don’ t have an objection to establishing 2 tracks – one for established services evaluation and one for new proposed services evaluation.

You don't, but most people do, as both the call and the mailing list discussion have shown.

I do object to charging more for an application that proposes new services – it’s against the goal of innovation and creativity.

Something that can be raised for applicant support. It's a worthy cause, and lots of jurisdiction give tax breaks to R&D, innovation, entrepreneurship ... it's just out of scope for WT4.

I do object to dealing with proposals for new services in the contracting phase. It is not transparent to the community.

Not including the community in registry services reviews is how current GNSO policy is. This WG is not chartered to review it. Rubens

And please don’t tell me I am free to file a complaint. That is not the answer. There were two people in chat who supported the notion of two tracks and you want to ignore that because it is not your solution. This is not the proper role for a co-chair. You should be raising the different proposals and asking for full discussion of them. Jeff specifically asked me for a proposal. I had to force you to take my comment to communicate that proposal. Then two other people supported it. I have never before experienced such a biased working group environment. 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@01D32278.0AD66900] Lewis Roca Rothgerber Christie LLP One South Church Avenue, Suite 700 Tucson, Arizona 85701-1611 lrrc.com<http://lrrc.com/> From: gnso-newgtld-wg-wt4-bounces@icann.org [mailto:gnso-newgtld-wg-wt4-bounces@icann.org] On Behalf Of Aikman-Scalese, Anne Sent: Thursday, August 31, 2017 4:33 PM To: 'Rubens Kuhl' Cc: gnso-newgtld-wg-wt4@icann.org Subject: Re: [Gnso-newgtld-wg-wt4] Registry Services straw-person Frankly, most people aren’t expressing opinions at this time on the list or on the call. I am very surprised as I think the role of a Co-Chair (and the Sub Pro Chairs) is to facilitate discussion. I don’t see that happening here. The environment from you and from Jeff is hostile. Anne E. Aikman-Scalese Of Counsel 520.629.4428 office 520.879.4725 fax AAikman@lrrc.com<mailto:AAikman@lrrc.com> _____________________________ [cid:image003.png@01D32277.E8C6ED80] 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: Thursday, August 31, 2017 4:28 PM To: Aikman-Scalese, Anne Cc: gnso-newgtld-wg-wt4@icann.org<mailto:gnso-newgtld-wg-wt4@icann.org> Subject: Re: [Gnso-newgtld-wg-wt4] Registry Services straw-person On Aug 31, 2017, at 8:22 PM, Aikman-Scalese, Anne <AAikman@lrrc.com<mailto:AAikman@lrrc.com>> wrote: Rubens, I don’ t have an objection to establishing 2 tracks – one for established services evaluation and one for new proposed services evaluation. You don't, but most people do, as both the call and the mailing list discussion have shown. I do object to charging more for an application that proposes new services – it’s against the goal of innovation and creativity. Something that can be raised for applicant support. It's a worthy cause, and lots of jurisdiction give tax breaks to R&D, innovation, entrepreneurship ... it's just out of scope for WT4. I do object to dealing with proposals for new services in the contracting phase. It is not transparent to the community. Not including the community in registry services reviews is how current GNSO policy is. This WG is not chartered to review it. 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.

Anne, I would like to apologize if I have in any way created a hostile environment for anyone in any work track or in the Working Group. I will try to be more cognizant of my actions in the future. It certainly was not my intent to stifle ideas coming forward. Just the opposite was intended when I asked that you submit a proposal that achieved the goals of efficiency, expediency, but also encouraged innovation. I view part of my job as overall co-chair to make sure all viewpoints are expressed and then to get Working Group members to try to think outside of the box, put themselves in the shoes of the other sides and try to come up with a compromise solution that can attempt to satisfy all points (or as many as possible). You have presented a proposal and we absolutely need to make sure that proposal is considered. Rubens has presented his strawperson, you have presented yours. Is there a way to merge the two? There may be other proposals out there and I strongly encourage those to come forward. On the issue of whether applicants that propose new services should pay to have these new services reviewed, this is a complex issues. On the one hand, as you state, it may be a disincentive to propose new innovative services. On the other hand, reviewing new services does come with a cost for evaluation. New services may require a different skill set of reviewers that reviewing the existing services. Reviewing new services may require a more thorough security analysis, competition analysis, etc. than existing services (which are already reviewed and proven). So not charging those applicants that propose new services for the evaluation of those new services results in those that do not propose new types of registry services subsidizing those that do. From a policy perspective, that may be ok, but it is a policy decision we should all make. FYI, the existing Registry Agreements do require registries to pay the costs of proposing new registry services if a Technical Panel has to be called in to review the new services. I believe there may be a cap of $50,000, but I could be confusing that with the 2012 Round costs. Thanks for keeping the discussion going and I hope you do feel free expressing your ideas/proposals going forward. If not, please bring that to my attention (or to Avri’s attention if you are more comfortable with that). I am trying my best to be neutral and encourage discussion, but I am not infallible. Best regards, Jeffrey J. Neuman Senior Vice President |Valideus USA | Com Laude USA 1751 Pinnacle Drive, Suite 600 Mclean, VA 22102, United States E: jeff.neuman@valideus.com<mailto:jeff.neuman@valideus.com> or jeff.neuman@comlaude.com<mailto:jeff.neuman@comlaude.com> T: +1.703.635.7514 M: +1.202.549.5079 @Jintlaw From: gnso-newgtld-wg-wt4-bounces@icann.org [mailto:gnso-newgtld-wg-wt4-bounces@icann.org] On Behalf Of Aikman-Scalese, Anne Sent: Thursday, August 31, 2017 4:42 PM To: Aikman-Scalese, Anne <AAikman@lrrc.com>; 'Rubens Kuhl' <rubensk@nic.br> Cc: gnso-newgtld-wg-wt4@icann.org Subject: Re: [Gnso-newgtld-wg-wt4] Registry Services straw-person And please don’t tell me I am free to file a complaint. That is not the answer. There were two people in chat who supported the notion of two tracks and you want to ignore that because it is not your solution. This is not the proper role for a co-chair. You should be raising the different proposals and asking for full discussion of them. Jeff specifically asked me for a proposal. I had to force you to take my comment to communicate that proposal. Then two other people supported it. I have never before experienced such a biased working group environment. Anne Anne E. Aikman-Scalese Of Counsel 520.629.4428 office 520.879.4725 fax AAikman@lrrc.com<mailto:AAikman@lrrc.com> _____________________________ [cid:image001.png@01D3229D.2092AE50] Lewis Roca Rothgerber Christie LLP One South Church Avenue, Suite 700 Tucson, Arizona 85701-1611 lrrc.com<http://lrrc.com/> From: gnso-newgtld-wg-wt4-bounces@icann.org<mailto:gnso-newgtld-wg-wt4-bounces@icann.org> [mailto:gnso-newgtld-wg-wt4-bounces@icann.org] On Behalf Of Aikman-Scalese, Anne Sent: Thursday, August 31, 2017 4:33 PM To: 'Rubens Kuhl' Cc: gnso-newgtld-wg-wt4@icann.org<mailto:gnso-newgtld-wg-wt4@icann.org> Subject: Re: [Gnso-newgtld-wg-wt4] Registry Services straw-person Frankly, most people aren’t expressing opinions at this time on the list or on the call. I am very surprised as I think the role of a Co-Chair (and the Sub Pro Chairs) is to facilitate discussion. I don’t see that happening here. The environment from you and from Jeff is hostile. Anne E. Aikman-Scalese Of Counsel 520.629.4428 office 520.879.4725 fax AAikman@lrrc.com<mailto:AAikman@lrrc.com> _____________________________ [cid:image002.png@01D3229D.2092AE50] 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: Thursday, August 31, 2017 4:28 PM To: Aikman-Scalese, Anne Cc: gnso-newgtld-wg-wt4@icann.org<mailto:gnso-newgtld-wg-wt4@icann.org> Subject: Re: [Gnso-newgtld-wg-wt4] Registry Services straw-person On Aug 31, 2017, at 8:22 PM, Aikman-Scalese, Anne <AAikman@lrrc.com<mailto:AAikman@lrrc.com>> wrote: Rubens, I don’ t have an objection to establishing 2 tracks – one for established services evaluation and one for new proposed services evaluation. You don't, but most people do, as both the call and the mailing list discussion have shown. I do object to charging more for an application that proposes new services – it’s against the goal of innovation and creativity. Something that can be raised for applicant support. It's a worthy cause, and lots of jurisdiction give tax breaks to R&D, innovation, entrepreneurship ... it's just out of scope for WT4. I do object to dealing with proposals for new services in the contracting phase. It is not transparent to the community. Not including the community in registry services reviews is how current GNSO policy is. This WG is not chartered to review it. 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.

OK ... So I take a break away from connectivity to deal with other Non ICANN (yes they exist!) matters after our earlier WT call, and so much has happened on the list! Clearly (well in my view at least ;-) we still have plenty to discuss regarding the Registry Services question, and as Jeff mentioned in his earlier email => "...we absolutely need to make sure that [all] proposal[s] is [/are] considered. .... ..... ..... There may be other proposals out there and I strongly encourage those to come forward." So in keeping with that spirit of exploration let's keep on discussing and proposing options on this, and over the next day or two we will put together some sort of matrix from our meetings and these list discussions to ensure we capture as much as possible both in opinions, options and variable support for the alternatives with a view to then fully discussing matters further at our next or the following meeting. Thank you all for your valuable contributions so far mind we hope that more WT members doing so over the coming week or so. *Cheryl Langdon-O**rr ... *(CLO) about.me/cheryl.LangdonOrr [image: Cheryl Langdon-Orr on about.me] <http://about.me/cheryl.LangdonOrr> On 1 September 2017 at 14:59, Rubens Kuhl <rubensk@nic.br> wrote:

You have presented a proposal and we absolutely need to make sure that proposal is considered. Rubens has presented his strawperson, you have presented yours. Is there a way to merge the two? There may be other proposals out there and I strongly encourage those to come forward.

Actually, I presented a first straw person in the meeting before this one, and it was to strike Q23 altogether... that was the only one that only come out that I could claim copyright to. The one presented at the start of the call was already modified due to WT members input, Anne included, and the one I sent after call was based on what was discussed in the call... so it is already at the 3rd generation with many thumbprints, and there is no reason not to change further. It's not final until it is sent to Council labeled "final report".

On the issue of whether applicants that propose new services should pay to have these new services reviewed, this is a complex issues. On the one hand, as you state, it may be a disincentive to propose new innovative services. On the other hand, reviewing new services does come with a cost for evaluation. New services may require a different skill set of reviewers that reviewing the existing services. Reviewing new services may require a more thorough security analysis, competition analysis, etc. than existing services (which are already reviewed and proven). So not charging those applicants that propose new services for the evaluation of those new services results in those that do not propose new types of registry services subsidizing those that do. From a policy perspective, that may be ok, but it is a policy decision we should all make.

I'm all for the SubPro WG making this decision, but I'm unsure that it belongs to WT4, since application fees looks more like WT1 to me.

FYI, the existing Registry Agreements do require registries to pay the costs of proposing new registry services if a Technical Panel has to be called in to review the new services. I believe there may be a cap of $50,000, but I could be confusing that with the 2012 Round costs.

That applied to 2012, and even there might not be a real cap but only an indication of value, since some fees charged during the process differed from the guidebook. On RSTEPs that occurred after the new gTLD program, there was only one I'm aware of, PIR's .ong/.ngo bundling, which cost was much higher than USD 50k.

Thanks for keeping the discussion going and I hope you do feel free expressing your ideas/proposals going forward. If not, please bring that to my attention (or to Avri’s attention if you are more comfortable with that). I am trying my best to be neutral and encourage discussion, but I am not infallible.

Likewise, WT4 do have one co-chair that was not mentioned as discouraging discussion, Cheryl, if someone feels more comfortable raising an issue.

Rubens

_______________________________________________ Gnso-newgtld-wg-wt4 mailing list Gnso-newgtld-wg-wt4@icann.org https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg-wt4

As indicated during the chat (didn’t have phone with me) I wanted to memorialize that I support the principles behind Anne’s suggestion and I agree with the sentiment of Kurt’s comments below Thanks From: gnso-newgtld-wg-wt4-bounces@icann.org [mailto:gnso-newgtld-wg-wt4-bounces@icann.org] On Behalf Of Kurt Pritz Sent: Friday, September 01, 2017 9:36 AM To: gnso-newgtld-wg-wt4@icann.org Subject: [EXTERNAL] Re: [Gnso-newgtld-wg-wt4] Registry Services straw-person Hi all: I have not been part of the discussion so please forgive my taking the liberty to comment. I agree with Anne’s points. If we zoom up from the operational details and consider the overall policy that we are currently constructing, I think it is worthwhile for us to state that, as a policy, “the gTLD Program should be administered in a way that encourages innovation.” Or maybe “…in a way that encourages innovation, competition and choice.” Given that policy, then naturally ICANN would not charge additional fees, nor delay applications with innovative uses for the TLD. Practically speaking (and to the extent we offer implementation advice), given that an RSEP is supposed to take 15 days and the (somewhat rare) technical review takes 45 days, I see no reason why those reviews cannot happen easily within the initial evaluation period. It may be slightly inefficient to conduct those RSEP reviews before the application passes the other substantive reviews but if it is our policy to encourage innovation, then that inefficiency is a small price to pay. While we have not seen great innovation to date, I don’t think that should change our thinking. I have worked with one TLD that does have some great (I think) ideas for alternative uses and I know there are some others. This should not dissuade us from our policies that we lay the most fertile ground for innovation that we can. Thanks & regards, Kurt On Sep 1, 2017, at 5:07 AM, Jeff Neuman <jeff.neuman@comlaude.com<mailto:jeff.neuman@comlaude.com>> wrote: Anne, I would like to apologize if I have in any way created a hostile environment for anyone in any work track or in the Working Group. I will try to be more cognizant of my actions in the future. It certainly was not my intent to stifle ideas coming forward. Just the opposite was intended when I asked that you submit a proposal that achieved the goals of efficiency, expediency, but also encouraged innovation. I view part of my job as overall co-chair to make sure all viewpoints are expressed and then to get Working Group members to try to think outside of the box, put themselves in the shoes of the other sides and try to come up with a compromise solution that can attempt to satisfy all points (or as many as possible). You have presented a proposal and we absolutely need to make sure that proposal is considered. Rubens has presented his strawperson, you have presented yours. Is there a way to merge the two? There may be other proposals out there and I strongly encourage those to come forward. On the issue of whether applicants that propose new services should pay to have these new services reviewed, this is a complex issues. On the one hand, as you state, it may be a disincentive to propose new innovative services. On the other hand, reviewing new services does come with a cost for evaluation. New services may require a different skill set of reviewers that reviewing the existing services. Reviewing new services may require a more thorough security analysis, competition analysis, etc. than existing services (which are already reviewed and proven). So not charging those applicants that propose new services for the evaluation of those new services results in those that do not propose new types of registry services subsidizing those that do. From a policy perspective, that may be ok, but it is a policy decision we should all make. FYI, the existing Registry Agreements do require registries to pay the costs of proposing new registry services if a Technical Panel has to be called in to review the new services. I believe there may be a cap of $50,000, but I could be confusing that with the 2012 Round costs. Thanks for keeping the discussion going and I hope you do feel free expressing your ideas/proposals going forward. If not, please bring that to my attention (or to Avri’s attention if you are more comfortable with that). I am trying my best to be neutral and encourage discussion, but I am not infallible. Best regards, Jeffrey J. Neuman Senior Vice President |Valideus USA | Com Laude USA 1751 Pinnacle Drive, Suite 600 Mclean, VA 22102, United States E: jeff.neuman@valideus.com<mailto:jeff.neuman@valideus.com> or jeff.neuman@comlaude.com<mailto:jeff.neuman@comlaude.com> T: +1.703.635.7514 M: +1.202.549.5079 @Jintlaw From: gnso-newgtld-wg-wt4-bounces@icann.org<mailto:gnso-newgtld-wg-wt4-bounces@icann.org> [mailto:gnso-newgtld-wg-wt4-bounces@icann.org] On Behalf Of Aikman-Scalese, Anne Sent: Thursday, August 31, 2017 4:42 PM To: Aikman-Scalese, Anne <AAikman@lrrc.com<mailto:AAikman@lrrc.com>>; 'Rubens Kuhl' <rubensk@nic.br<mailto:rubensk@nic.br>> Cc: gnso-newgtld-wg-wt4@icann.org<mailto:gnso-newgtld-wg-wt4@icann.org> Subject: Re: [Gnso-newgtld-wg-wt4] Registry Services straw-person And please don’t tell me I am free to file a complaint. That is not the answer. There were two people in chat who supported the notion of two tracks and you want to ignore that because it is not your solution. This is not the proper role for a co-chair. You should be raising the different proposals and asking for full discussion of them. Jeff specifically asked me for a proposal. I had to force you to take my comment to communicate that proposal. Then two other people supported it. I have never before experienced such a biased working group environment. Anne Anne E. Aikman-Scalese Of Counsel 520.629.4428 office 520.879.4725 fax AAikman@lrrc.com<mailto:AAikman@lrrc.com> _____________________________ <image001.png> Lewis Roca Rothgerber Christie LLP One South Church Avenue, Suite 700 Tucson, Arizona 85701-1611 lrrc.com<http://lrrc.com/> From: gnso-newgtld-wg-wt4-bounces@icann.org<mailto:gnso-newgtld-wg-wt4-bounces@icann.org> [mailto:gnso-newgtld-wg-wt4-bounces@icann.org] On Behalf Of Aikman-Scalese, Anne Sent: Thursday, August 31, 2017 4:33 PM To: 'Rubens Kuhl' Cc: gnso-newgtld-wg-wt4@icann.org<mailto:gnso-newgtld-wg-wt4@icann.org> Subject: Re: [Gnso-newgtld-wg-wt4] Registry Services straw-person Frankly, most people aren’t expressing opinions at this time on the list or on the call. I am very surprised as I think the role of a Co-Chair (and the Sub Pro Chairs) is to facilitate discussion. I don’t see that happening here. The environment from you and from Jeff is hostile. Anne E. Aikman-Scalese Of Counsel 520.629.4428 office 520.879.4725 fax AAikman@lrrc.com<mailto:AAikman@lrrc.com> _____________________________ <image002.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: Thursday, August 31, 2017 4:28 PM To: Aikman-Scalese, Anne Cc: gnso-newgtld-wg-wt4@icann.org<mailto:gnso-newgtld-wg-wt4@icann.org> Subject: Re: [Gnso-newgtld-wg-wt4] Registry Services straw-person On Aug 31, 2017, at 8:22 PM, Aikman-Scalese, Anne <AAikman@lrrc.com<mailto:AAikman@lrrc.com>> wrote: Rubens, I don’ t have an objection to establishing 2 tracks – one for established services evaluation and one for new proposed services evaluation. You don't, but most people do, as both the call and the mailing list discussion have shown. I do object to charging more for an application that proposes new services – it’s against the goal of innovation and creativity. Something that can be raised for applicant support. It's a worthy cause, and lots of jurisdiction give tax breaks to R&D, innovation, entrepreneurship ... it's just out of scope for WT4. I do object to dealing with proposals for new services in the contracting phase. It is not transparent to the community. Not including the community in registry services reviews is how current GNSO policy is. This WG is not chartered to review it. 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. _______________________________________________ Gnso-newgtld-wg-wt4 mailing list Gnso-newgtld-wg-wt4@icann.org<mailto:Gnso-newgtld-wg-wt4@icann.org> https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg-wt4

Jeff, Thanks for your note. I certainly don’t see a problem with charging fees if a Technical Panel has to be called in – in other words, maintain the status quo in this regard. With respect to maintaining the status quo, my understanding of the existing Application Question is that it states as follows: 23. Provide name and full description of all the Registry Services to be provided. Descriptions should include both technical and business components of each proposed service, and address any potential security or stability concerns. The following registry services are customary services offered by a registry operator: A. Receipt of data from registrars concerning registration of domain names and name servers. B. Dissemination of TLD zone files. C. Dissemination of contact or other information concerning domain name registrations (e.g., port-43 WHOIS, Web- based Whois, RESTful Whois service). D. Internationalized Domain Names, where offered. E. DNS Security Extensions (DNSSEC). The applicant must describe whether any of these registry services are intended to be offered in a manner unique to the TLD. Additional proposed registry services that are unique to the registry must also be described. (Emphasis added by me.) You indicated that both Straw proposals would be discussed and considered. Later Sarah and I received a redline of the existing (Rubens) proposal from Kurt Pritz which he said Rubens had asked him to prepare. That redline raises additional issues. For example, it says that preapproved services will include (a) IDN registrations. (permitting IDN registrations raise issues of customer confusion. It also raises trademark Sunrise issues since many TM owners hold idn trademark registrations for their English marks. ) (b) “additional marketplace Rights Protection Mechanisms that have been identified as “blocks”. (I find myself wondering whether Avri has any comments on this in her personal capacity. I may really like this but it doesn’t change the procedural aspect of what we are doing.) (c) Bulk Transfer After Partial Portfolio Acquisition (BTPPA). (Sorry I don’t know what a “BTPPA” service is.) So we have more to discuss than the two Straw Person proposals put forward. We also need to discuss the preapproved services. Charging fees for evaluation of additional services is not the only policy issue. There is also a policy issue as to which point in time the proposed services will be evaluated. My proposal says proposed new services should be included in the application phase for proper transparency and evaluation at that time. (This seems to be the case in the existing version of Question 23.) The redline circulated by Kurt to me and Sarah (apparently at Ruben’s request), says the applicant can choose at what stage it wants the new services to be evaluated. So as I see it , there are three clear policy issues that must be discussed here: 1. Should new registry services be proposed in the application itself or at any stage chosen by the applicant, including at contracting and after contracting? Why are we changing the time of evaluation of proposed new registry services when the existing application says “Additional proposed registry services that are unique to the registry must also be described.”? Do registries prefer this be a discussion that occurs only between contracting parties and ICANN? 2. What existing services should be pre-approved for the next round? Does it include idn registrations and RPMs with blocking? 3. Should applicants pay fees for evaluation of proposed new services even if no Technical Panel is needed? Why is this being changed from the process followed in the 2012 round? I think that these questions need to be discussed openly before we go to the redlining phase. I do not believe that these issues are being adequately clarified for participants. 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@01D3263B.77207C60] Lewis Roca Rothgerber Christie LLP One South Church Avenue, Suite 700 Tucson, Arizona 85701-1611 lrrc.com<http://lrrc.com/> From: Jeff Neuman [mailto:jeff.neuman@comlaude.com] Sent: Thursday, August 31, 2017 9:07 PM To: Aikman-Scalese, Anne; 'Rubens Kuhl' Cc: gnso-newgtld-wg-wt4@icann.org Subject: RE: [Gnso-newgtld-wg-wt4] Registry Services straw-person Anne, I would like to apologize if I have in any way created a hostile environment for anyone in any work track or in the Working Group. I will try to be more cognizant of my actions in the future. It certainly was not my intent to stifle ideas coming forward. Just the opposite was intended when I asked that you submit a proposal that achieved the goals of efficiency, expediency, but also encouraged innovation. I view part of my job as overall co-chair to make sure all viewpoints are expressed and then to get Working Group members to try to think outside of the box, put themselves in the shoes of the other sides and try to come up with a compromise solution that can attempt to satisfy all points (or as many as possible). You have presented a proposal and we absolutely need to make sure that proposal is considered. Rubens has presented his strawperson, you have presented yours. Is there a way to merge the two? There may be other proposals out there and I strongly encourage those to come forward. On the issue of whether applicants that propose new services should pay to have these new services reviewed, this is a complex issues. On the one hand, as you state, it may be a disincentive to propose new innovative services. On the other hand, reviewing new services does come with a cost for evaluation. New services may require a different skill set of reviewers that reviewing the existing services. Reviewing new services may require a more thorough security analysis, competition analysis, etc. than existing services (which are already reviewed and proven). So not charging those applicants that propose new services for the evaluation of those new services results in those that do not propose new types of registry services subsidizing those that do. From a policy perspective, that may be ok, but it is a policy decision we should all make. FYI, the existing Registry Agreements do require registries to pay the costs of proposing new registry services if a Technical Panel has to be called in to review the new services. I believe there may be a cap of $50,000, but I could be confusing that with the 2012 Round costs. Thanks for keeping the discussion going and I hope you do feel free expressing your ideas/proposals going forward. If not, please bring that to my attention (or to Avri’s attention if you are more comfortable with that). I am trying my best to be neutral and encourage discussion, but I am not infallible. Best regards, Jeffrey J. Neuman Senior Vice President |Valideus USA | Com Laude USA 1751 Pinnacle Drive, Suite 600 Mclean, VA 22102, United States E: jeff.neuman@valideus.com<mailto:jeff.neuman@valideus.com> or jeff.neuman@comlaude.com<mailto:jeff.neuman@comlaude.com> T: +1.703.635.7514 M: +1.202.549.5079 @Jintlaw From: gnso-newgtld-wg-wt4-bounces@icann.org<mailto:gnso-newgtld-wg-wt4-bounces@icann.org> [mailto:gnso-newgtld-wg-wt4-bounces@icann.org] On Behalf Of Aikman-Scalese, Anne Sent: Thursday, August 31, 2017 4:42 PM To: Aikman-Scalese, Anne <AAikman@lrrc.com<mailto:AAikman@lrrc.com>>; 'Rubens Kuhl' <rubensk@nic.br<mailto:rubensk@nic.br>> Cc: gnso-newgtld-wg-wt4@icann.org<mailto:gnso-newgtld-wg-wt4@icann.org> Subject: Re: [Gnso-newgtld-wg-wt4] Registry Services straw-person And please don’t tell me I am free to file a complaint. That is not the answer. There were two people in chat who supported the notion of two tracks and you want to ignore that because it is not your solution. This is not the proper role for a co-chair. You should be raising the different proposals and asking for full discussion of them. Jeff specifically asked me for a proposal. I had to force you to take my comment to communicate that proposal. Then two other people supported it. I have never before experienced such a biased working group environment. Anne Anne E. Aikman-Scalese Of Counsel 520.629.4428 office 520.879.4725 fax AAikman@lrrc.com<mailto:AAikman@lrrc.com> _____________________________ [cid:image005.png@01D32635.F2163460] Lewis Roca Rothgerber Christie LLP One South Church Avenue, Suite 700 Tucson, Arizona 85701-1611 lrrc.com<http://lrrc.com/> From: gnso-newgtld-wg-wt4-bounces@icann.org<mailto:gnso-newgtld-wg-wt4-bounces@icann.org> [mailto:gnso-newgtld-wg-wt4-bounces@icann.org] On Behalf Of Aikman-Scalese, Anne Sent: Thursday, August 31, 2017 4:33 PM To: 'Rubens Kuhl' Cc: gnso-newgtld-wg-wt4@icann.org<mailto:gnso-newgtld-wg-wt4@icann.org> Subject: Re: [Gnso-newgtld-wg-wt4] Registry Services straw-person Frankly, most people aren’t expressing opinions at this time on the list or on the call. I am very surprised as I think the role of a Co-Chair (and the Sub Pro Chairs) is to facilitate discussion. I don’t see that happening here. The environment from you and from Jeff is hostile. Anne E. Aikman-Scalese Of Counsel 520.629.4428 office 520.879.4725 fax AAikman@lrrc.com<mailto:AAikman@lrrc.com> _____________________________ [cid:image006.png@01D32635.F2163460] 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: Thursday, August 31, 2017 4:28 PM To: Aikman-Scalese, Anne Cc: gnso-newgtld-wg-wt4@icann.org<mailto:gnso-newgtld-wg-wt4@icann.org> Subject: Re: [Gnso-newgtld-wg-wt4] Registry Services straw-person On Aug 31, 2017, at 8:22 PM, Aikman-Scalese, Anne <AAikman@lrrc.com<mailto:AAikman@lrrc.com>> wrote: Rubens, I don’ t have an objection to establishing 2 tracks – one for established services evaluation and one for new proposed services evaluation. You don't, but most people do, as both the call and the mailing list discussion have shown. I do object to charging more for an application that proposes new services – it’s against the goal of innovation and creativity. Something that can be raised for applicant support. It's a worthy cause, and lots of jurisdiction give tax breaks to R&D, innovation, entrepreneurship ... it's just out of scope for WT4. I do object to dealing with proposals for new services in the contracting phase. It is not transparent to the community. Not including the community in registry services reviews is how current GNSO policy is. This WG is not chartered to review it. 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.

Rubens, I have communicated separately with you off-list and to Leadership regarding your response. The following comments are circulated to the entire list: A. Please circulate the second Straw Proposal in addition to your own for comparison purposes. The second proposal is that the language of Question 23 remain the same as in the 2012 round which states that all new services to be offered MUST BE DESCRIBED (see below) with the following addition: “Applicant acknowledges that ICANN may establish two application evaluation tracks which will operate separately, one for applications which propose new registry services and one for applications which contain only the following pre-approved registry services: LIST PRE-APPROVED SERVICES HERE (TO BE DISCUSSED ON THE NEXT CALL). B. You state that it is “out-of-scope” for Work Track 4 for us to discuss the policy issue of incurring additional fees for evaluation of additional new registry services. However, it is in fact your Straw Proposal that suggests such additional fees are appropriate. If this is policy work that is “out-of-scope” for Work Track 4, then the language of your Straw Proposal is itself “out-of-scope”. C. You state that I cannot raise issues regarding effect on RPM policy because that is for the RPM PDP, not for Work Track 4. If you are advocating a policy change that affects RPM policy, it has to be raised and flagged, not buried as “out of scope” for Work Track 4.) How will the RPM PDP even KNOW that such an issue is being created by a proposed change in Question 23 if not discussed and brought to their attention? Again, I believe the three issues which must be clearly outlined and discussion facilitated are: 1. Should new registry services be proposed in the application itself or at any stage chosen by the applicant, including at contracting and after contracting? Why are we changing the time of evaluation of proposed new registry services when the existing application says “Additional proposed registry services that are unique to the registry must also be described.”? Do registries prefer this be a discussion that occurs only between contracting parties and ICANN? 2. What existing services should be pre-approved for the next round? Does it include idn registrations and RPMs with blocking? (Here do we mean idn registrations within the application for a non-idn Top Level Domain or something else? If both are recommended, how does Sub Pro alert the RPM PDP as to the possible implications for RPM policy?) And how can Sub Pro stay on course and recommend moving forward to the next round if it creates policy issues that RPM PDP has not yet been able to address?) 3. Should applicants pay fees for evaluation of proposed new services even if no Technical Panel is needed? Why is this being changed from the process followed in the 2012 round? Isn’t this proposed change in fact creating a policy issue because the entire purpose of unlimited gTLDs was to encourage innovation and competition? 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@01D3264E.36824D10] 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, September 05, 2017 12:36 PM To: Aikman-Scalese, Anne Cc: Jeff Neuman; gnso-newgtld-wg-wt4@icann.org Subject: Re: [Gnso-newgtld-wg-wt4] Registry Services straw-person Em 5 de set de 2017, à(s) 15:38:000, Aikman-Scalese, Anne <AAikman@lrrc.com<mailto:AAikman@lrrc.com>> escreveu: Jeff, Thanks for your note. I certainly don’t see a problem with charging fees if a Technical Panel has to be called in – in other words, maintain the status quo in this regard. With respect to maintaining the status quo, my understanding of the existing Application Question is that it states as follows: It is actually a bit different than that, i'll explain that below. 23. Provide name and full description of all the Registry Services to be provided. Descriptions should include both technical and business components of each proposed service, and address any potential security or stability concerns. The following registry services are customary services offered by a registry operator: A. Receipt of data from registrars concerning registration of domain names and name servers. B. Dissemination of TLD zone files. C. Dissemination of contact or other information concerning domain name registrations (e.g., port-43 WHOIS, Web- based Whois, RESTful Whois service). D. Internationalized Domain Names, where offered. E. DNS Security Extensions (DNSSEC). The applicant must describe whether any of these registry services are intended to be offered in a manner unique to the TLD. Additional proposed registry services that are unique to the registry must also be described. (Emphasis added by me.) You indicated that both Straw proposals would be discussed and considered. Later Sarah and I received a redline of the existing (Rubens) proposal from Kurt Pritz which he said Rubens had asked him to prepare. That redline raises additional issues. For example, it says that preapproved services will include I can't comment on it while it has not been posted on the list, so if Sarah, Kurt and you believe it's ready I encourage all to send it to the list... just as reference, the latest straw-person (which as I said I don't think it's a one's person proposal since it's already in its 4th generation after many suggestions) was sent to the list by me September 1, 1331 UTC. (a) IDN registrations. (permitting IDN registrations raise issues of customer confusion. Those issues of customer confusions are already address in the IDN Guidelines, a document that was the primary reference during the 2012-round and still is. It also raises trademark Sunrise issues since many TM owners hold idn trademark registrations for their English marks. ) I don't recall any suggestion during the IDN discussions to stop provisioning IDN registration services due to TM issues... and that would contradict years of ICANN efforts in that regard. Anyway, that would be on-topic for the RPM PDPs WG, not for Subsequent Procedures... (b) “additional marketplace Rights Protection Mechanisms that have been identified as “blocks”. (I find myself wondering whether Avri has any comments on this in her personal capacity. I may really like this but it doesn’t change the procedural aspect of what we are doing.) (c) Bulk Transfer After Partial Portfolio Acquisition (BTPPA). (Sorry I don’t know what a “BTPPA” service is.) Curiously one piece news including BTPPA surfaced after the call, and it can give a first glimpse on what BTPPA is: http://domainnamewire.com/2017/09/01/namecheap-sues-enom-tucows-demands-tran... The original Verisign BTAPPA request can be found here: https://www.icann.org/en/system/files/files/verisign-btappa-request-29jul09-... So we have more to discuss than the two Straw Person proposals put forward. We also need to discuss the preapproved services. Since at least one of them mentioned pre-approved services, we can discuss that while discuss the straw person(s)... Charging fees for evaluation of additional services is not the only policy issue. And while it's a policy issue, it's not a WT4 issue... There is also a policy issue as to which point in time the proposed services will be evaluated. My proposal says proposed new services should be included in the application phase for proper transparency and evaluation at that time. (This seems to be the case in the existing version of Question 23.) The redline circulated by Kurt to me and Sarah (apparently at Ruben’s request), The only message I sent was sent to the list; no message was sent by me to any of 3 and no request to be passed along was made. The only suggestion I did, during the call and after in the list, was for those said they are willing to propose something different, to compile something and send it to the list. says the applicant can choose at what stage it wants the new services to be evaluated. So as I see it , there are three clear policy issues that must be discussed here: 1. Should new registry services be proposed in the application itself or at any stage chosen by the applicant, including at contracting and after contracting? Why are we changing the time of evaluation of proposed new registry services when the existing application says “Additional proposed registry services that are unique to the registry must also be described.”? Do registries prefer this be a discussion that occurs only between contracting parties and ICANN? Actually, we identified that some registries could prefer discussing at application time, contracting time or after contracting depending on their preferred balance of predictability, time to market and innovativeness of the service. Note that we would be adding one intermediary option, at contracting; both application time and after contracting were options already available in the 2012-round, and would continue to be available. 2. What existing services should be pre-approved for the next round? Possibly the same services that would be pre-approved for all gTLD registries by then. But we could establish which services at a minimum should be there, similar to what we are doing with bundled technical evaluation and the RSP program. Does it include idn registrations and RPMs with blocking? Certainly IDN registrations, since it's the most prolific registry service request there is. 3. Should applicants pay fees for evaluation of proposed new services even if no Technical Panel is needed? Why is this being changed from the process followed in the 2012 round? There were actually two different panels in 2012: - Registry Services Evaluation Panel (which shouldn't be confused with Registry Services Evaluation Procedure, or RSEP), performed by an ICANN contractor - Registry Services Technical Evaluation Panel (RSTEP), performed by technical experts from the community (https://www.icann.org/resources/pages/technical-evaluation-panel-2012-02-25-...) All applications were evaluated by the former, and the cost of that was included in the 185,000 application fee. Besides issuing CQs or failing applications, the evaluators could have referred the application to an RSTEP, which if called upon, would have cost an extra fee, estimated by AGB at 50,000. Nothing is being changed about RSTEP, but instead of the evaluation panel, applicant would have the option of checking a box saying "only pre approved services" and avoiding that evaluation altogether. And if that evaluation was requested by applicant, that would be done by same ICANN Org staff that currently does RSEP for the already contracted registries. The reason for a possible fee, which I will remind again is off-topic for WT4 recommendations but we can discuss the theme, is that RSEP costs are currently carried out by the quarterly registry fee, and in this case applicants wouldn't still be paying ICANN fees, so it wouldn't be unreasonable for ICANN to charge a fee. But if WT1 prefers recommending ICANN not to charge fees in order to foster innovation, that would be fine too; both are reasoned policy 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.

Rubens, My Straw Proposal is actually stated in A. below, and yet you have said you did not receive it. It would be good to have the two side by side. 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@01D32650.A51FCC00] 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, September 05, 2017 2:05 PM To: Aikman-Scalese, Anne Cc: Jeff Neuman; gnso-newgtld-wg-wt4@icann.org Subject: Re: [Gnso-newgtld-wg-wt4] Registry Services straw-person Em 5 de set de 2017, à(s) 17:52:000, Aikman-Scalese, Anne <AAikman@lrrc.com<mailto:AAikman@lrrc.com>> escreveu: Rubens, I have communicated separately with you off-list and to Leadership regarding your response. The following comments are circulated to the entire list: A. Please circulate the second Straw Proposal in addition to your own for comparison purposes. The second proposal is that the language of Question 23 remain the same as in the 2012 round which states that all new services to be offered MUST BE DESCRIBED (see below) with the following addition: “Applicant acknowledges that ICANN may establish two application evaluation tracks which will operate separately, one for applications which propose new registry services and one for applications which contain only the following pre-approved registry services: LIST PRE-APPROVED SERVICES HERE (TO BE DISCUSSED ON THE NEXT CALL). As I mentioned, I haven't received the second straw proposal. I believe Sarah, Kurt, and perhaps you could join them, were going to send one... as soon as one does, let's start circulating them both. Or three or more if it needs be... Note also the agenda for the next call was defined long before this discussion, and doesn't include registry services... if there is AOB time for it, it's sure a topic to add. B. You state that it is “out-of-scope” for Work Track 4 for us to discuss the policy issue of incurring additional fees for evaluation of additional new registry services. However, it is in fact your Straw Proposal that suggests such additional fees are appropriate. If this is policy work that is “out-of-scope” for Work Track 4, then the language of your Straw Proposal is itself “out-of-scope”. The latest straw person actually removed any fees reference, exactly due to that. BTW, this was added due to a comment during the call that was one made not by me or Cheryl... but anyway, it's removed both due to opposition and to be out of scope. C. You state that I cannot raise issues regarding effect on RPM policy because that is for the RPM PDP, not for Work Track 4. If you are advocating a policy change that affects RPM policy, it has to be raised and flagged, not buried as “out of scope” for Work Track 4.) How will the RPM PDP even KNOW that such an issue is being created by a proposed change in Question 23 if not discussed and brought to their attention? On the connection with RPM PDP WG, while there is not something currently foreseen at the work-track level, there is at the WG level, and every WT definition comes first to the WG, doesn't go into final report before that. From our charter: "Second-Level Rights Protection Mechanisms: Proposing recommendations directly related to RPMs is beyond the remit of this PDP. There is an anticipated PDP on the "current state of all rights protection mechanisms (RPMs) implemented for both existing and new gTLDs, including but not limited to the UDRP and the URS...". Duplication or conflicting work between the New gTLD Subsequent Procedures PDP and the PDP on RPMs must be avoided. If topics related to RPMs are uncovered and discussed in the deliberations of this PDP, those topics should be relayed to the PDP on RPMs for resolution. To assure effective coordination between the two groups, a community liaison, who is a member of both Groups, is to be appointed jointly by both Groups and confirmed by the GNSO Council." The first topic you mentioned seemed to me an aspect of the sunrise/claims process, which is being actively worked by the RPM PDP WG. The other one is about registry services in general so is not directly related to RPMs; either way, every one of the SubPro recommendations will need, at the end, an analysis of whether it uncovered a new topic that should be forwarded to the RPM PDP or not. (remaining text already replied to) 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, Are you saying that your Straw Proposal includes a proposal to delete the existing Question 23 language asking applicants to propose specifically any new registry services (and listing customary services) whereas mine proposes to maintain it and establish two tracks for processing – that is, one for Fastrack “no new services” applications and another for regular “proposed new services” applications? For clarity, the existing language is pasted below in purple with my proposal in red. It is not clear to me whether your proposal includes Question 23 text as is (with additions) or whether you want to delete the current text in the application (shown in purple below from existing application). It appears you propose (and advocate in this debate) four substantive changes: 1. Applicant is NOT required to list proposed new registry services in the application as was the case in 2012. 2. Applicant can choose when to propose new services (in the application, at contracting, or after contracting) and when they will be evaluated, using only the RSEP procedure. 3. You propose to delete the list of “customary services” in Question 23. (BTW for participants, this includes port-43 WHOIS, Web-based Whois, RESTful Whois) 4. You propose to delete the text which states that the Applicant must describe whether any of the customary registry services listed are going to be offered in a manner unique to the TLD. Is that correct? Thank you, Anne " 23. Provide name and full description of all the Registry Services to be provided. Descriptions should include both technical and business components of each proposed service, and address any potential security or stability concerns. The following registry services are customary services offered by a registry operator: A. Receipt of data from registrars concerning registration of domain names and name servers. B. Dissemination of TLD zone files. C. Dissemination of contact or other information concerning domain name registrations (e.g., port-43 WHOIS, Web- based Whois, RESTful Whois service). D. Internationalized Domain Names, where offered. E. DNS Security Extensions (DNSSEC). The applicant must describe whether any of these registry services are intended to be offered in a manner unique to the TLD. Additional proposed registry services that are unique to the registry must also be described. "Applicant acknowledges that ICANN may establish two application evaluation tracks which will operate separately, one for applications which propose new registry services and one for applications which contain only the following pre-approved registry services: LIST PRE-APPROVED SERVICES HERE" Anne E. Aikman-Scalese Of Counsel 520.629.4428 office 520.879.4725 fax AAikman@lrrc.com _______________________________ Lewis Roca Rothgerber Christie LLP One South Church Avenue, Suite 700 Tucson, Arizona 85701-1611 lrrc.com -----Original Message----- From: Rubens Kuhl [mailto:rubensk@nic.br] Sent: Tuesday, September 05, 2017 2:43 PM To: Aikman-Scalese, Anne Cc: Jeff Neuman; gnso-newgtld-wg-wt4@icann.org Subject: Re: [Gnso-newgtld-wg-wt4] Registry Services straw-person So we are still missing one from Kurt and Sarah... but so far, we have: Straw-proposal 1: (from Sep 1) "Applicants will be allowed but not required to specify additional registry services. List of previously approved registry services (IDN Languages, GPML, BTPPA) to be included by reference in AGB and contract. If applicant informs additional registry services, they will be evaluated thru RSEP. Applicant will choose whether the evaluation is to occur at evaluation time, contracting time or after contract signing." Straw-proposal 2: "Applicants should provide name and full description of all the Registry Services to be provided. Descriptions should include both technical and business components of each proposed service, and address any potential security or stability concerns. "Applicant acknowledges that ICANN may establish two application evaluation tracks which will operate separately, one for applications which propose new registry services and one for applications which contain only the following pre-approved registry services: LIST PRE-APPROVED SERVICES HERE" (disclaimer: I compiled the language from Q23 and the mailing list discussion, and is prone to errors since it was not submitted in entirety by proposal author) Similarities: - Both foresee pre-approved services and mention a list - Both are silent on whether using only pre-approved services would have a different fee Differences between the two so far: - (1) incorporates a list of pre-approved services by reference, although mentioning some, while (2) explicitly names a list - (1) allows a service to be evaluated at contracting time while (2) does not; (* note: although 1 foresees a option after contract signing, that's already a fact due to Registry Services policy *) - (1) is silent of the processing of applications, although in practice create 2 tracks since RSEP is an already established procedure outside of the subsequent procedures evaluation program. (2) explicitly creates two tracks. - (1) only requires applicant to inform about registry services that are not in the pre-approved list while (2) requires all services to be informed and described at application time Feedback taken from the latest discussions on the list: - The list of services on (1) and (2) could be expanded to the "minimal pre-approved services" that would be allowed even if there is no such list for already established registry operators. - Some already mentioned the list in AGB as a possible starting point: "A. Receipt of data from registrars concerning registration of domain names and name servers. B. Dissemination of TLD zone files. C. Dissemination of contact or other information concerning domain name registrations (e.g., port -43 WHOIS, Web - based Whois, RESTful Whois service). D. Internationalized Domain Names, where offered. E. DNS Security Extensions (DNSSEC)." </co-chair> - The mention of registry services evaluation after contract signing in (1) is probably misplaced, since it's part of a policy not covered in our charter. It's also redundant. - The requirement of specifying pre-approved services in the application in (2) is likely ineffective if there is such a list for registry operators, since a registry could activate them just after contract signing since they are pre-approved. It has an effect though if no such list for registry operators exists at that time. A question arises: do we assume such a list will exist or think on both scenarios ? <co-chair> Any further thoughts, feedback or new straw proposals ? Rubens

Em 5 de set de 2017, à(s) 18:09:000, Aikman-Scalese, Anne <AAikman@lrrc.com<mailto:AAikman@lrrc.com>> escreveu:

Rubens,

My Straw Proposal is actually stated in A. below, and yet you have said you did not receive it. It would be good to have the two side by side.

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

From: Rubens Kuhl [mailto:rubensk@nic.br]

Sent: Tuesday, September 05, 2017 2:05 PM

To: Aikman-Scalese, Anne

Cc: Jeff Neuman; gnso-newgtld-wg-wt4@icann.org<mailto:gnso-newgtld-wg-wt4@icann.org>

Subject: Re: [Gnso-newgtld-wg-wt4] Registry Services straw-person

Em 5 de set de 2017, à(s) 17:52:000, Aikman-Scalese, Anne <AAikman@lrrc.com<mailto:AAikman@lrrc.com>> escreveu:

Rubens,

I have communicated separately with you off-list and to Leadership regarding your response. The following comments are circulated to the entire list:

A. Please circulate the second Straw Proposal in addition to your own for comparison purposes. The second proposal is that the language of Question 23 remain the same as in the 2012 round which states that all new services to be offered MUST BE DESCRIBED (see below) with the following addition: “Applicant acknowledges that ICANN may establish two application evaluation tracks which will operate separately, one for applications which propose new registry services and one for applications which contain only the following pre-approved registry services: LIST PRE-APPROVED SERVICES HERE (TO BE DISCUSSED ON THE NEXT CALL).

As I mentioned, I haven't received the second straw proposal. I believe Sarah, Kurt, and perhaps you could join them, were going to send one... as soon as one does, let's start circulating them both. Or three or more if it needs be...

Note also the agenda for the next call was defined long before this discussion, and doesn't include registry services... if there is AOB time for it, it's sure a topic to add.

B. You state that it is “out-of-scope” for Work Track 4 for us to discuss the policy issue of incurring additional fees for evaluation of additional new registry services. However, it is in fact your Straw Proposal that suggests such additional fees are appropriate. If this is policy work that is “out-of-scope” for Work Track 4, then the language of your Straw Proposal is itself “out-of-scope”.

The latest straw person actually removed any fees reference, exactly due to that. BTW, this was added due to a comment during the call that was one made not by me or Cheryl... but anyway, it's removed both due to opposition and to be out of scope.

C. You state that I cannot raise issues regarding effect on RPM policy because that is for the RPM PDP, not for Work Track 4. If you are advocating a policy change that affects RPM policy, it has to be raised and flagged, not buried as “out of scope” for Work Track 4.) How will the RPM PDP even KNOW that such an issue is being created by a proposed change in Question 23 if not discussed and brought to their attention?

On the connection with RPM PDP WG, while there is not something currently foreseen at the work-track level, there is at the WG level, and every WT definition comes first to the WG, doesn't go into final report before that. From our charter:

"Second-Level Rights Protection Mechanisms: Proposing recommendations directly related to RPMs is beyond the remit of this PDP. There is an anticipated PDP on the "current state of all rights protection mechanisms (RPMs) implemented for both existing and new gTLDs, including but not limited to the UDRP and the URS...". Duplication or conflicting work between the New gTLD Subsequent Procedures PDP and the PDP on RPMs must be avoided. If topics relatedto RPMs are uncovered and discussed in the deliberations of this PDP, those topics should be relayed to the PDP on RPMs for resolution. To assure effective coordination between the two groups, a community liaison, who is a member of both Groups, is to be appointed jointly by both Groups and confirmed by the GNSO Council."

The first topic you mentioned seemed to me an aspect of the sunrise/claims process, which is being actively worked by the RPM PDP WG. The other one is about registry services in general so is not directly related to RPMs; either way, every one of the SubPro recommendations will need, at the end, an analysis of whether it uncovered a new topic that should be forwarded to the RPM PDP or not.

(remaining text already replied to)

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.

Dear all, The Work Track 4 meeting tomorrow now conflicts with the ICANN Policy MSSI Update for all Commercial Stakeholders. Accordingly, could we move discussion of the 2 Straw Proposals on Question 23 to the call after the one tomorrow? This would mean discussion financial evaluation during the Thursday call and Question 23 SPs to the next call after. I would very much appreciate this is if it can be done. 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@01D32BB7.58A0D060] Lewis Roca Rothgerber Christie LLP One South Church Avenue, Suite 700 Tucson, Arizona 85701-1611 lrrc.com<http://lrrc.com/> From: Aikman-Scalese, Anne Sent: Tuesday, September 05, 2017 3:18 PM To: 'Rubens Kuhl' Cc: Jeff Neuman; gnso-newgtld-wg-wt4@icann.org; Greg Shatan; 'Metalitz, Steven' Subject: RE: [Gnso-newgtld-wg-wt4] Registry Services straw-person Rubens, Are you saying that your Straw Proposal includes a proposal to delete the existing Question 23 language asking applicants to propose specifically any new registry services (and listing customary services) whereas mine proposes to maintain it and establish two tracks for processing – that is, one for Fastrack “no new services” applications and another for regular “proposed new services” applications? For clarity, the existing language is pasted below in purple with my proposal in red. It is not clear to me whether your proposal includes Question 23 text as is (with additions) or whether you want to delete the current text in the application (shown in purple below from existing application). It appears you propose (and advocate in this debate) four substantive changes: 1. Applicant is NOT required to list proposed new registry services in the application as was the case in 2012. 2. Applicant can choose when to propose new services (in the application, at contracting, or after contracting) and when they will be evaluated, using only the RSEP procedure. 3. You propose to delete the list of “customary services” in Question 23. (BTW for participants, this includes port-43 WHOIS, Web-based Whois, RESTful Whois) 4. You propose to delete the text which states that the Applicant must describe whether any of the customary registry services listed are going to be offered in a manner unique to the TLD. Is that correct? Thank you, Anne " 23. Provide name and full description of all the Registry Services to be provided. Descriptions should include both technical and business components of each proposed service, and address any potential security or stability concerns. The following registry services are customary services offered by a registry operator: A. Receipt of data from registrars concerning registration of domain names and name servers. B. Dissemination of TLD zone files. C. Dissemination of contact or other information concerning domain name registrations (e.g., port-43 WHOIS, Web- based Whois, RESTful Whois service). D. Internationalized Domain Names, where offered. E. DNS Security Extensions (DNSSEC). The applicant must describe whether any of these registry services are intended to be offered in a manner unique to the TLD. Additional proposed registry services that are unique to the registry must also be described. "Applicant acknowledges that ICANN may establish two application evaluation tracks which will operate separately, one for applications which propose new registry services and one for applications which contain only the following pre-approved registry services: LIST PRE-APPROVED SERVICES HERE" Anne E. Aikman-Scalese Of Counsel 520.629.4428 office 520.879.4725 fax AAikman@lrrc.com<mailto:AAikman@lrrc.com> _______________________________ Lewis Roca Rothgerber Christie LLP One South Church Avenue, Suite 700 Tucson, Arizona 85701-1611 lrrc.com -----Original Message----- From: Rubens Kuhl [mailto:rubensk@nic.br] Sent: Tuesday, September 05, 2017 2:43 PM To: Aikman-Scalese, Anne Cc: Jeff Neuman; gnso-newgtld-wg-wt4@icann.org<mailto:gnso-newgtld-wg-wt4@icann.org> Subject: Re: [Gnso-newgtld-wg-wt4] Registry Services straw-person So we are still missing one from Kurt and Sarah... but so far, we have: Straw-proposal 1: (from Sep 1) "Applicants will be allowed but not required to specify additional registry services. List of previously approved registry services (IDN Languages, GPML, BTPPA) to be included by reference in AGB and contract. If applicant informs additional registry services, they will be evaluated thru RSEP. Applicant will choose whether the evaluation is to occur at evaluation time, contracting time or after contract signing." Straw-proposal 2: "Applicants should provide name and full description of all the Registry Services to be provided. Descriptions should include both technical and business components of each proposed service, and address any potential security or stability concerns. "Applicant acknowledges that ICANN may establish two application evaluation tracks which will operate separately, one for applications which propose new registry services and one for applications which contain only the following pre-approved registry services: LIST PRE-APPROVED SERVICES HERE" (disclaimer: I compiled the language from Q23 and the mailing list discussion, and is prone to errors since it was not submitted in entirety by proposal author) Similarities: - Both foresee pre-approved services and mention a list - Both are silent on whether using only pre-approved services would have a different fee Differences between the two so far: - (1) incorporates a list of pre-approved services by reference, although mentioning some, while (2) explicitly names a list - (1) allows a service to be evaluated at contracting time while (2) does not; (* note: although 1 foresees a option after contract signing, that's already a fact due to Registry Services policy *) - (1) is silent of the processing of applications, although in practice create 2 tracks since RSEP is an already established procedure outside of the subsequent procedures evaluation program. (2) explicitly creates two tracks. - (1) only requires applicant to inform about registry services that are not in the pre-approved list while (2) requires all services to be informed and described at application time Feedback taken from the latest discussions on the list: - The list of services on (1) and (2) could be expanded to the "minimal pre-approved services" that would be allowed even if there is no such list for already established registry operators. - Some already mentioned the list in AGB as a possible starting point: "A. Receipt of data from registrars concerning registration of domain names and name servers. B. Dissemination of TLD zone files. C. Dissemination of contact or other information concerning domain name registrations (e.g., port -43 WHOIS, Web - based Whois, RESTful Whois service). D. Internationalized Domain Names, where offered. E. DNS Security Extensions (DNSSEC)." </co-chair> - The mention of registry services evaluation after contract signing in (1) is probably misplaced, since it's part of a policy not covered in our charter. It's also redundant. - The requirement of specifying pre-approved services in the application in (2) is likely ineffective if there is such a list for registry operators, since a registry could activate them just after contract signing since they are pre-approved. It has an effect though if no such list for registry operators exists at that time. A question arises: do we assume such a list will exist or think on both scenarios ? <co-chair> Any further thoughts, feedback or new straw proposals ? Rubens

Em 5 de set de 2017, à(s) 18:09:000, Aikman-Scalese, Anne <AAikman@lrrc.com<mailto:AAikman@lrrc.com>> escreveu:

Rubens,

My Straw Proposal is actually stated in A. below, and yet you have said you did not receive it. It would be good to have the two side by side.

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

From: Rubens Kuhl [mailto:rubensk@nic.br]

Sent: Tuesday, September 05, 2017 2:05 PM

To: Aikman-Scalese, Anne

Cc: Jeff Neuman; gnso-newgtld-wg-wt4@icann.org<mailto:gnso-newgtld-wg-wt4@icann.org>

Subject: Re: [Gnso-newgtld-wg-wt4] Registry Services straw-person

Em 5 de set de 2017, à(s) 17:52:000, Aikman-Scalese, Anne <AAikman@lrrc.com<mailto:AAikman@lrrc.com>> escreveu:

Rubens,

I have communicated separately with you off-list and to Leadership regarding your response. The following comments are circulated to the entire list:

A. Please circulate the second Straw Proposal in addition to your own for comparison purposes. The second proposal is that the language of Question 23 remain the same as in the 2012 round which states that all new services to be offered MUST BE DESCRIBED (see below) with the following addition: “Applicant acknowledges that ICANN may establish two application evaluation tracks which will operate separately, one for applications which propose new registry services and one for applications which contain only the following pre-approved registry services: LIST PRE-APPROVED SERVICES HERE (TO BE DISCUSSED ON THE NEXT CALL).

As I mentioned, I haven't received the second straw proposal. I believe Sarah, Kurt, and perhaps you could join them, were going to send one... as soon as one does, let's start circulating them both. Or three or more if it needs be...

Note also the agenda for the next call was defined long before this discussion, and doesn't include registry services... if there is AOB time for it, it's sure a topic to add.

B. You state that it is “out-of-scope” for Work Track 4 for us to discuss the policy issue of incurring additional fees for evaluation of additional new registry services. However, it is in fact your Straw Proposal that suggests such additional fees are appropriate. If this is policy work that is “out-of-scope” for Work Track 4, then the language of your Straw Proposal is itself “out-of-scope”.

The latest straw person actually removed any fees reference, exactly due to that. BTW, this was added due to a comment during the call that was one made not by me or Cheryl... but anyway, it's removed both due to opposition and to be out of scope.

C. You state that I cannot raise issues regarding effect on RPM policy because that is for the RPM PDP, not for Work Track 4. If you are advocating a policy change that affects RPM policy, it has to be raised and flagged, not buried as “out of scope” for Work Track 4.) How will the RPM PDP even KNOW that such an issue is being created by a proposed change in Question 23 if not discussed and brought to their attention?

On the connection with RPM PDP WG, while there is not something currently foreseen at the work-track level, there is at the WG level, and every WT definition comes first to the WG, doesn't go into final report before that. From our charter:

"Second-Level Rights Protection Mechanisms: Proposing recommendations directly related to RPMs is beyond the remit of this PDP. There is an anticipated PDP on the "current state of all rights protection mechanisms (RPMs) implemented for both existing and new gTLDs, including but not limited to the UDRP and the URS...". Duplication or conflicting work between the New gTLD Subsequent Procedures PDP and the PDP on RPMs must be avoided. If topics relatedto RPMs are uncovered and discussed in the deliberations of this PDP, those topics should be relayed to the PDP on RPMs for resolution. To assure effective coordination between the two groups, a community liaison, who is a member of both Groups, is to be appointed jointly by both Groups and confirmed by the GNSO Council."

The first topic you mentioned seemed to me an aspect of the sunrise/claims process, which is being actively worked by the RPM PDP WG. The other one is about registry services in general so is not directly related to RPMs; either way, every one of the SubPro recommendations will need, at the end, an analysis of whether it uncovered a new topic that should be forwarded to the RPM PDP or not.

(remaining text already replied to)

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.

Thank you. When will the two SP proposals be discussed further? Anne E. Aikman-Scalese Of Counsel 520.629.4428 office 520.879.4725 fax AAikman@lrrc.com<mailto:AAikman@lrrc.com> _____________________________ [cid:image003.png@01D32BB8.5BD48EB0] 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, September 12, 2017 11:10 AM To: Aikman-Scalese, Anne Cc: Jeff Neuman; gnso-newgtld-wg-wt4@icann.org Subject: Re: [Gnso-newgtld-wg-wt4] Registry Services straw-person Anne, What you mentioned was already the plan anyways... Registry Services would only be raised, if raised, as an AOB item; per you request we will deny its inclusion in AOB if someone asks. Rubens Em 12 de set de 2017, à(s) 15:07:000, Aikman-Scalese, Anne <AAikman@lrrc.com<mailto:AAikman@lrrc.com>> escreveu: Dear all, The Work Track 4 meeting tomorrow now conflicts with the ICANN Policy MSSI Update for all Commercial Stakeholders. Accordingly, could we move discussion of the 2 Straw Proposals on Question 23 to the call after the one tomorrow? This would mean discussion financial evaluation during the Thursday call and Question 23 SPs to the next call after. I would very much appreciate this is if it can be done. 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: Aikman-Scalese, Anne Sent: Tuesday, September 05, 2017 3:18 PM To: 'Rubens Kuhl' Cc: Jeff Neuman; gnso-newgtld-wg-wt4@icann.org<mailto:gnso-newgtld-wg-wt4@icann.org>; Greg Shatan; 'Metalitz, Steven' Subject: RE: [Gnso-newgtld-wg-wt4] Registry Services straw-person Rubens, Are you saying that your Straw Proposal includes a proposal to delete the existing Question 23 language asking applicants to propose specifically any new registry services (and listing customary services) whereas mine proposes to maintain it and establish two tracks for processing – that is, one for Fastrack “no new services” applications and another for regular “proposed new services” applications? For clarity, the existing language is pasted below in purple with my proposal in red. It is not clear to me whether your proposal includes Question 23 text as is (with additions) or whether you want to delete the current text in the application (shown in purple below from existing application). It appears you propose (and advocate in this debate) four substantive changes: 1. Applicant is NOT required to list proposed new registry services in the application as was the case in 2012. 2. Applicant can choose when to propose new services (in the application, at contracting, or after contracting) and when they will be evaluated, using only the RSEP procedure. 3. You propose to delete the list of “customary services” in Question 23. (BTW for participants, this includes port-43 WHOIS, Web-based Whois, RESTful Whois) 4. You propose to delete the text which states that the Applicant must describe whether any of the customary registry services listed are going to be offered in a manner unique to the TLD. Is that correct? Thank you, Anne " 23. Provide name and full description of all the Registry Services to be provided. Descriptions should include both technical and business components of each proposed service, and address any potential security or stability concerns. The following registry services are customary services offered by a registry operator: A. Receipt of data from registrars concerning registration of domain names and name servers. B. Dissemination of TLD zone files. C. Dissemination of contact or other information concerning domain name registrations (e.g., port-43 WHOIS, Web- based Whois, RESTful Whois service). D. Internationalized Domain Names, where offered. E. DNS Security Extensions (DNSSEC). The applicant must describe whether any of these registry services are intended to be offered in a manner unique to the TLD. Additional proposed registry services that are unique to the registry must also be described. "Applicant acknowledges that ICANN may establish two application evaluation tracks which will operate separately, one for applications which propose new registry services and one for applications which contain only the following pre-approved registry services: LIST PRE-APPROVED SERVICES HERE" Anne E. Aikman-Scalese Of Counsel 520.629.4428 office 520.879.4725 fax AAikman@lrrc.com<mailto:AAikman@lrrc.com> _______________________________ Lewis Roca Rothgerber Christie LLP One South Church Avenue, Suite 700 Tucson, Arizona 85701-1611 lrrc.com<http://lrrc.com> -----Original Message----- From: Rubens Kuhl [mailto:rubensk@nic.br] Sent: Tuesday, September 05, 2017 2:43 PM To: Aikman-Scalese, Anne Cc: Jeff Neuman; gnso-newgtld-wg-wt4@icann.org<mailto:gnso-newgtld-wg-wt4@icann.org> Subject: Re: [Gnso-newgtld-wg-wt4] Registry Services straw-person So we are still missing one from Kurt and Sarah... but so far, we have: Straw-proposal 1: (from Sep 1) "Applicants will be allowed but not required to specify additional registry services. List of previously approved registry services (IDN Languages, GPML, BTPPA) to be included by reference in AGB and contract. If applicant informs additional registry services, they will be evaluated thru RSEP. Applicant will choose whether the evaluation is to occur at evaluation time, contracting time or after contract signing." Straw-proposal 2: "Applicants should provide name and full description of all the Registry Services to be provided. Descriptions should include both technical and business components of each proposed service, and address any potential security or stability concerns. "Applicant acknowledges that ICANN may establish two application evaluation tracks which will operate separately, one for applications which propose new registry services and one for applications which contain only the following pre-approved registry services: LIST PRE-APPROVED SERVICES HERE" (disclaimer: I compiled the language from Q23 and the mailing list discussion, and is prone to errors since it was not submitted in entirety by proposal author) Similarities: - Both foresee pre-approved services and mention a list - Both are silent on whether using only pre-approved services would have a different fee Differences between the two so far: - (1) incorporates a list of pre-approved services by reference, although mentioning some, while (2) explicitly names a list - (1) allows a service to be evaluated at contracting time while (2) does not; (* note: although 1 foresees a option after contract signing, that's already a fact due to Registry Services policy *) - (1) is silent of the processing of applications, although in practice create 2 tracks since RSEP is an already established procedure outside of the subsequent procedures evaluation program. (2) explicitly creates two tracks. - (1) only requires applicant to inform about registry services that are not in the pre-approved list while (2) requires all services to be informed and described at application time Feedback taken from the latest discussions on the list: - The list of services on (1) and (2) could be expanded to the "minimal pre-approved services" that would be allowed even if there is no such list for already established registry operators. - Some already mentioned the list in AGB as a possible starting point: "A. Receipt of data from registrars concerning registration of domain names and name servers. B. Dissemination of TLD zone files. C. Dissemination of contact or other information concerning domain name registrations (e.g., port -43 WHOIS, Web - based Whois, RESTful Whois service). D. Internationalized Domain Names, where offered. E. DNS Security Extensions (DNSSEC)." </co-chair> - The mention of registry services evaluation after contract signing in (1) is probably misplaced, since it's part of a policy not covered in our charter. It's also redundant. - The requirement of specifying pre-approved services in the application in (2) is likely ineffective if there is such a list for registry operators, since a registry could activate them just after contract signing since they are pre-approved. It has an effect though if no such list for registry operators exists at that time. A question arises: do we assume such a list will exist or think on both scenarios ? <co-chair> Any further thoughts, feedback or new straw proposals ? Rubens

Em 5 de set de 2017, à(s) 18:09:000, Aikman-Scalese, Anne <AAikman@lrrc.com<mailto:AAikman@lrrc.com>> escreveu:

Rubens, My Straw Proposal is actually stated in A. below, and yet you have said you did not receive it. It would be good to have the two side by side. 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, September 05, 2017 2:05 PM To: Aikman-Scalese, Anne Cc: Jeff Neuman; gnso-newgtld-wg-wt4@icann.org<mailto:gnso-newgtld-wg-wt4@icann.org> Subject: Re: [Gnso-newgtld-wg-wt4] Registry Services straw-person

Em 5 de set de 2017, à(s) 17:52:000, Aikman-Scalese, Anne <AAikman@lrrc.com<mailto:AAikman@lrrc.com>> escreveu:

Rubens, I have communicated separately with you off-list and to Leadership regarding your response. The following comments are circulated to the entire list:

A. Please circulate the second Straw Proposal in addition to your own for comparison purposes. The second proposal is that the language of Question 23 remain the same as in the 2012 round which states that all new services to be offered MUST BE DESCRIBED (see below) with the following addition: “Applicant acknowledges that ICANN may establish two application evaluation tracks which will operate separately, one for applications which propose new registry services and one for applications which contain only the following pre-approved registry services: LIST PRE-APPROVED SERVICES HERE (TO BE DISCUSSED ON THE NEXT CALL).

As I mentioned, I haven't received the second straw proposal. I believe Sarah, Kurt, and perhaps you could join them, were going to send one... as soon as one does, let's start circulating them both. Or three or more if it needs be...

Note also the agenda for the next call was defined long before this discussion, and doesn't include registry services... if there is AOB time for it, it's sure a topic to add.

B. You state that it is “out-of-scope” for Work Track 4 for us to discuss the policy issue of incurring additional fees for evaluation of additional new registry services. However, it is in fact your Straw Proposal that suggests such additional fees are appropriate. If this is policy work that is “out-of-scope” for Work Track 4, then the language of your Straw Proposal is itself “out-of-scope”.

The latest straw person actually removed any fees reference, exactly due to that. BTW, this was added due to a comment during the call that was one made not by me or Cheryl... but anyway, it's removed both due to opposition and to be out of scope.

C. You state that I cannot raise issues regarding effect on RPM policy because that is for the RPM PDP, not for Work Track 4. If you are advocating a policy change that affects RPM policy, it has to be raised and flagged, not buried as “out of scope” for Work Track 4.) How will the RPM PDP even KNOW that such an issue is being created by a proposed change in Question 23 if not discussed and brought to their attention?

On the connection with RPM PDP WG, while there is not something currently foreseen at the work-track level, there is at the WG level, and every WT definition comes first to the WG, doesn't go into final report before that. From our charter: "Second-Level Rights Protection Mechanisms: Proposing recommendations directly related to RPMs is beyond the remit of this PDP. There is an anticipated PDP on the "current state of all rights protection mechanisms (RPMs) implemented for both existing and new gTLDs, including but not limited to the UDRP and the URS...". Duplication or conflicting work between the New gTLD Subsequent Procedures PDP and the PDP on RPMs must be avoided. If topics relatedto RPMs are uncovered and discussed in the deliberations of this PDP, those topics should be relayed to the PDP on RPMs for resolution. To assure effective coordination between the two groups, a community liaison, who is a member of both Groups, is to be appointed jointly by both Groups and confirmed by the GNSO Council."

The first topic you mentioned seemed to me an aspect of the sunrise/claims process, which is being actively worked by the RPM PDP WG. The other one is about registry services in general so is not directly related to RPMs; either way, every one of the SubPro recommendations will need, at the end, an analysis of whether it uncovered a new topic that should be forwarded to the RPM PDP or not.

(remaining text already replied to)

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.

Folks I am travelling today can you give me a day or two to respond? Sorry for the delay Sent from my iPhone On 12 Sep 2017, at 14:08, Aikman-Scalese, Anne <AAikman@lrrc.com<mailto:AAikman@lrrc.com>> wrote: Dear all, The Work Track 4 meeting tomorrow now conflicts with the ICANN Policy MSSI Update for all Commercial Stakeholders. Accordingly, could we move discussion of the 2 Straw Proposals on Question 23 to the call after the one tomorrow? This would mean discussion financial evaluation during the Thursday call and Question 23 SPs to the next call after. I would very much appreciate this is if it can be done. 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@01D32BB7.58A0D060] Lewis Roca Rothgerber Christie LLP One South Church Avenue, Suite 700 Tucson, Arizona 85701-1611 http://lrrc.com<http://lrrc.com/> From: Aikman-Scalese, Anne Sent: Tuesday, September 05, 2017 3:18 PM To: 'Rubens Kuhl' Cc: Jeff Neuman; gnso-newgtld-wg-wt4@icann.org<mailto:gnso-newgtld-wg-wt4@icann.org>; Greg Shatan; 'Metalitz, Steven' Subject: RE: [Gnso-newgtld-wg-wt4] Registry Services straw-person Rubens, Are you saying that your Straw Proposal includes a proposal to delete the existing Question 23 language asking applicants to propose specifically any new registry services (and listing customary services) whereas mine proposes to maintain it and establish two tracks for processing – that is, one for Fastrack “no new services” applications and another for regular “proposed new services” applications? For clarity, the existing language is pasted below in purple with my proposal in red. It is not clear to me whether your proposal includes Question 23 text as is (with additions) or whether you want to delete the current text in the application (shown in purple below from existing application). It appears you propose (and advocate in this debate) four substantive changes: 1. Applicant is NOT required to list proposed new registry services in the application as was the case in 2012. 2. Applicant can choose when to propose new services (in the application, at contracting, or after contracting) and when they will be evaluated, using only the RSEP procedure. 3. You propose to delete the list of “customary services” in Question 23. (BTW for participants, this includes port-43 WHOIS, Web-based Whois, RESTful Whois) 4. You propose to delete the text which states that the Applicant must describe whether any of the customary registry services listed are going to be offered in a manner unique to the TLD. Is that correct? Thank you, Anne " 23. Provide name and full description of all the Registry Services to be provided. Descriptions should include both technical and business components of each proposed service, and address any potential security or stability concerns. The following registry services are customary services offered by a registry operator: A. Receipt of data from registrars concerning registration of domain names and name servers. B. Dissemination of TLD zone files. C. Dissemination of contact or other information concerning domain name registrations (e.g., port-43 WHOIS, Web- based Whois, RESTful Whois service). D. Internationalized Domain Names, where offered. E. DNS Security Extensions (DNSSEC). The applicant must describe whether any of these registry services are intended to be offered in a manner unique to the TLD. Additional proposed registry services that are unique to the registry must also be described. "Applicant acknowledges that ICANN may establish two application evaluation tracks which will operate separately, one for applications which propose new registry services and one for applications which contain only the following pre-approved registry services: LIST PRE-APPROVED SERVICES HERE" Anne E. Aikman-Scalese Of Counsel 520.629.4428 office 520.879.4725 fax AAikman@lrrc.com<mailto:AAikman@lrrc.com> _______________________________ Lewis Roca Rothgerber Christie LLP One South Church Avenue, Suite 700 Tucson, Arizona 85701-1611 http://lrrc.com -----Original Message----- From: Rubens Kuhl [mailto:rubensk@nic.br] Sent: Tuesday, September 05, 2017 2:43 PM To: Aikman-Scalese, Anne Cc: Jeff Neuman; gnso-newgtld-wg-wt4@icann.org<mailto:gnso-newgtld-wg-wt4@icann.org> Subject: Re: [Gnso-newgtld-wg-wt4] Registry Services straw-person So we are still missing one from Kurt and Sarah... but so far, we have: Straw-proposal 1: (from Sep 1) "Applicants will be allowed but not required to specify additional registry services. List of previously approved registry services (IDN Languages, GPML, BTPPA) to be included by reference in AGB and contract. If applicant informs additional registry services, they will be evaluated thru RSEP. Applicant will choose whether the evaluation is to occur at evaluation time, contracting time or after contract signing." Straw-proposal 2: "Applicants should provide name and full description of all the Registry Services to be provided. Descriptions should include both technical and business components of each proposed service, and address any potential security or stability concerns. "Applicant acknowledges that ICANN may establish two application evaluation tracks which will operate separately, one for applications which propose new registry services and one for applications which contain only the following pre-approved registry services: LIST PRE-APPROVED SERVICES HERE" (disclaimer: I compiled the language from Q23 and the mailing list discussion, and is prone to errors since it was not submitted in entirety by proposal author) Similarities: - Both foresee pre-approved services and mention a list - Both are silent on whether using only pre-approved services would have a different fee Differences between the two so far: - (1) incorporates a list of pre-approved services by reference, although mentioning some, while (2) explicitly names a list - (1) allows a service to be evaluated at contracting time while (2) does not; (* note: although 1 foresees a option after contract signing, that's already a fact due to Registry Services policy *) - (1) is silent of the processing of applications, although in practice create 2 tracks since RSEP is an already established procedure outside of the subsequent procedures evaluation program. (2) explicitly creates two tracks. - (1) only requires applicant to inform about registry services that are not in the pre-approved list while (2) requires all services to be informed and described at application time Feedback taken from the latest discussions on the list: - The list of services on (1) and (2) could be expanded to the "minimal pre-approved services" that would be allowed even if there is no such list for already established registry operators. - Some already mentioned the list in AGB as a possible starting point: "A. Receipt of data from registrars concerning registration of domain names and name servers. B. Dissemination of TLD zone files. C. Dissemination of contact or other information concerning domain name registrations (e.g., port -43 WHOIS, Web - based Whois, RESTful Whois service). D. Internationalized Domain Names, where offered. E. DNS Security Extensions (DNSSEC)." </co-chair> - The mention of registry services evaluation after contract signing in (1) is probably misplaced, since it's part of a policy not covered in our charter. It's also redundant. - The requirement of specifying pre-approved services in the application in (2) is likely ineffective if there is such a list for registry operators, since a registry could activate them just after contract signing since they are pre-approved. It has an effect though if no such list for registry operators exists at that time. A question arises: do we assume such a list will exist or think on both scenarios ? <co-chair> Any further thoughts, feedback or new straw proposals ? Rubens

Em 5 de set de 2017, à(s) 18:09:000, Aikman-Scalese, Anne <AAikman@lrrc.com<mailto:AAikman@lrrc.com>> escreveu:

Rubens,

My Straw Proposal is actually stated in A. below, and yet you have said you did not receive it. It would be good to have the two side by side.

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

http://lrrc.com

From: Rubens Kuhl [mailto:rubensk@nic.br]

Sent: Tuesday, September 05, 2017 2:05 PM

To: Aikman-Scalese, Anne

Cc: Jeff Neuman; gnso-newgtld-wg-wt4@icann.org<mailto:gnso-newgtld-wg-wt4@icann.org>

Subject: Re: [Gnso-newgtld-wg-wt4] Registry Services straw-person

Em 5 de set de 2017, à(s) 17:52:000, Aikman-Scalese, Anne <AAikman@lrrc.com<mailto:AAikman@lrrc.com>> escreveu:

Rubens,

I have communicated separately with you off-list and to Leadership regarding your response. The following comments are circulated to the entire list:

A. Please circulate the second Straw Proposal in addition to your own for comparison purposes. The second proposal is that the language of Question 23 remain the same as in the 2012 round which states that all new services to be offered MUST BE DESCRIBED (see below) with the following addition: “Applicant acknowledges that ICANN may establish two application evaluation tracks which will operate separately, one for applications which propose new registry services and one for applications which contain only the following pre-approved registry services: LIST PRE-APPROVED SERVICES HERE (TO BE DISCUSSED ON THE NEXT CALL).

As I mentioned, I haven't received the second straw proposal. I believe Sarah, Kurt, and perhaps you could join them, were going to send one... as soon as one does, let's start circulating them both. Or three or more if it needs be...

Note also the agenda for the next call was defined long before this discussion, and doesn't include registry services... if there is AOB time for it, it's sure a topic to add.

B. You state that it is “out-of-scope” for Work Track 4 for us to discuss the policy issue of incurring additional fees for evaluation of additional new registry services. However, it is in fact your Straw Proposal that suggests such additional fees are appropriate. If this is policy work that is “out-of-scope” for Work Track 4, then the language of your Straw Proposal is itself “out-of-scope”.

The latest straw person actually removed any fees reference, exactly due to that. BTW, this was added due to a comment during the call that was one made not by me or Cheryl... but anyway, it's removed both due to opposition and to be out of scope.

C. You state that I cannot raise issues regarding effect on RPM policy because that is for the RPM PDP, not for Work Track 4. If you are advocating a policy change that affects RPM policy, it has to be raised and flagged, not buried as “out of scope” for Work Track 4.) How will the RPM PDP even KNOW that such an issue is being created by a proposed change in Question 23 if not discussed and brought to their attention?

On the connection with RPM PDP WG, while there is not something currently foreseen at the work-track level, there is at the WG level, and every WT definition comes first to the WG, doesn't go into final report before that. >From our charter:

"Second-Level Rights Protection Mechanisms: Proposing recommendations directly related to RPMs is beyond the remit of this PDP. There is an anticipated PDP on the "current state of all rights protection mechanisms (RPMs) implemented for both existing and new gTLDs, including but not limited to the UDRP and the URS...". Duplication or conflicting work between the New gTLD Subsequent Procedures PDP and the PDP on RPMs must be avoided. If topics relatedto RPMs are uncovered and discussed in the deliberations of this PDP, those topics should be relayed to the PDP on RPMs for resolution. To assure effective coordination between the two groups, a community liaison, who is a member of both Groups, is to be appointed jointly by both Groups and confirmed by the GNSO Council."

The first topic you mentioned seemed to me an aspect of the sunrise/claims process, which is being actively worked by the RPM PDP WG. The other one is about registry services in general so is not directly related to RPMs; either way, every one of the SubPro recommendations will need, at the end, an analysis of whether it uncovered a new topic that should be forwarded to the RPM PDP or not.

(remaining text already replied to)

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. _______________________________________________ Gnso-newgtld-wg-wt4 mailing list Gnso-newgtld-wg-wt4@icann.org<mailto:Gnso-newgtld-wg-wt4@icann.org> https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg-wt4

Hi Rubens and everyone: Here is my suggestion for Question 23. It didn’t get much traction wth Anne (who suggested her own version) or Sarah so take it for what it is worth. It is written in keeping with Anne’s policy goal to encourage innovation. The last section (on fees) has two options and rationale for each of those two options. (Even though another group is considering fees, we can still make a recommendation when it come to the handling of this application aspect.) Q23a: Please list Additional Registry Services to be offered by the Applicant. Q23a: Please list Additional Registry Services to be offered by the Applicant. Applicants will be allowed (but not required) to specify additional registry services. Registry services that can be included at any time and are already approved are: IDN registrations, certain additional marketplace Rights Protection Mechanisms that have been identified a “blocks”), and Bulk Transfer After Partial Portfolio Acquisition (BTPPA). If the applicant includes additional registry services, the applicant is to specify whether it wants those services should be evaluated in parallel with the application evaluation, during te contract negotiation and execution process, or after the contract signing. ICANN will use the RSEP policy and process <https://www.icann.org/resources/pages/rsep-2014-02-19-en> for evaluation of additional services. Timing: Additional Registry Services evaluation should not extend the evaluation process and is likely to extend the contract negotiation process. Fees: In the event that the evaluation triggers a technical evaluation (see, https://www.icann.org/resources/pages/rsep-2014-02-19-en <https://www.icann.org/resources/pages/rsep-2014-02-19-en>), the applicant might incur additional fees of $xxxx. or Fees: There will be no additional fees for the evaluation on new registry services. Note: Zero fees provide two policy benefits: (1) it will encourage the adoption of new services, (2) it will encourage applicants to identify new services early, where the evaluation is “free.” Zero fees are likely to have a negative impact: ICANN will spread the high cost of technical evaluations over the all applications. ICANN will take a conservative approach and overestimate the number of technical evaluation that will occur, falsely driving up the application fee. Thanks for inviting my contribution, Kurt

On Sep 14, 2017, at 4:38 PM, Rubens Kuhl <rubensk@nic.br> wrote:

Sarah,

Do you mean regarding Registry Services ? Sure, Anne already asked for it not be included in our call even as an AOB item, and that still stands... I'm cc'ing Kurt that also mentioned proposing something in that regard.

Rubens

...

Em 13 de set de 2017, à(s) 08:23:000, Langstone, Sarah <slangstone@verisign.com <mailto:slangstone@verisign.com>> escreveu:

Folks I am travelling today can you give me a day or two to respond? Sorry for the delay

Sent from my iPhone

On 12 Sep 2017, at 14:08, Aikman-Scalese, Anne <AAikman@lrrc.com <mailto:AAikman@lrrc.com>> wrote:

...

Dear all, The Work Track 4 meeting tomorrow now conflicts with the ICANN Policy MSSI Update for all Commercial Stakeholders. Accordingly, could we move discussion of the 2 Straw Proposals on Question 23 to the call after the one tomorrow? This would mean discussion financial evaluation during the Thursday call and Question 23 SPs to the next call after.

I would very much appreciate this is if it can be done. 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 http://lrrc.com <http://lrrc.com/>

From: Aikman-Scalese, Anne Sent: Tuesday, September 05, 2017 3:18 PM To: 'Rubens Kuhl' Cc: Jeff Neuman; gnso-newgtld-wg-wt4@icann.org <mailto:gnso-newgtld-wg-wt4@icann.org>; Greg Shatan; 'Metalitz, Steven' Subject: RE: [Gnso-newgtld-wg-wt4] Registry Services straw-person

Rubens, Are you saying that your Straw Proposal includes a proposal to delete the existing Question 23 language asking applicants to propose specifically any new registry services (and listing customary services) whereas mine proposes to maintain it and establish two tracks for processing – that is, one for Fastrack “no new services” applications and another for regular “proposed new services” applications? For clarity, the existing language is pasted below in purple with my proposal in red. It is not clear to me whether your proposal includes Question 23 text as is (with additions) or whether you want to delete the current text in the application (shown in purple below from existing application).

It appears you propose (and advocate in this debate) four substantive changes: 1. Applicant is NOT required to list proposed new registry services in the application as was the case in 2012. 2. Applicant can choose when to propose new services (in the application, at contracting, or after contracting) and when they will be evaluated, using only the RSEP procedure. 3. You propose to delete the list of “customary services” in Question 23. (BTW for participants, this includes port-43 WHOIS, Web-based Whois, RESTful Whois) 4. You propose to delete the text which states that the Applicant must describe whether any of the customary registry services listed are going to be offered in a manner unique to the TLD.

Is that correct?

Thank you, Anne

" 23. Provide name and full description of all the Registry Services to be provided. Descriptions should include both technical and business components of each proposed service, and address any potential security or stability concerns. The following registry services are customary services offered by a registry operator: A. Receipt of data from registrars concerning registration of domain names and name servers. B. Dissemination of TLD zone files. C. Dissemination of contact or other information concerning domain name registrations (e.g., port-43 WHOIS, Web- based Whois, RESTful Whois service). D. Internationalized Domain Names, where offered. E. DNS Security Extensions (DNSSEC). The applicant must describe whether any of these registry services are intended to be offered in a manner unique to the TLD. Additional proposed registry services that are unique to the registry must also be described. "Applicant acknowledges that ICANN may establish two application evaluation tracks which will operate separately, one for applications which propose new registry services and one for applications which contain only the following pre-approved registry services: LIST PRE-APPROVED SERVICES HERE"

Anne E. Aikman-Scalese Of Counsel 520.629.4428 office 520.879.4725 fax AAikman@lrrc.com <mailto:AAikman@lrrc.com> _______________________________

Lewis Roca Rothgerber Christie LLP One South Church Avenue, Suite 700 Tucson, Arizona 85701-1611 http://lrrc.com <http://lrrc.com/>

-----Original Message----- From: Rubens Kuhl [mailto:rubensk@nic.br <mailto:rubensk@nic.br>] Sent: Tuesday, September 05, 2017 2:43 PM To: Aikman-Scalese, Anne Cc: Jeff Neuman; gnso-newgtld-wg-wt4@icann.org <mailto:gnso-newgtld-wg-wt4@icann.org> Subject: Re: [Gnso-newgtld-wg-wt4] Registry Services straw-person

So we are still missing one from Kurt and Sarah... but so far, we have:

Straw-proposal 1: (from Sep 1)

"Applicants will be allowed but not required to specify additional registry services. List of previously approved registry services (IDN Languages, GPML, BTPPA) to be included by reference in AGB and contract. If applicant informs additional registry services, they will be evaluated thru RSEP. Applicant will choose whether the evaluation is to occur at evaluation time, contracting time or after contract signing."

Straw-proposal 2: "Applicants should provide name and full description of all the Registry Services to be provided. Descriptions should include both technical and business components of each proposed service, and address any potential security or stability concerns. "Applicant acknowledges that ICANN may establish two application evaluation tracks which will operate separately, one for applications which propose new registry services and one for applications which contain only the following pre-approved registry services: LIST PRE-APPROVED SERVICES HERE" (disclaimer: I compiled the language from Q23 and the mailing list discussion, and is prone to errors since it was not submitted in entirety by proposal author)

Similarities: - Both foresee pre-approved services and mention a list - Both are silent on whether using only pre-approved services would have a different fee

Differences between the two so far: - (1) incorporates a list of pre-approved services by reference, although mentioning some, while (2) explicitly names a list - (1) allows a service to be evaluated at contracting time while (2) does not; (* note: although 1 foresees a option after contract signing, that's already a fact due to Registry Services policy *) - (1) is silent of the processing of applications, although in practice create 2 tracks since RSEP is an already established procedure outside of the subsequent procedures evaluation program. (2) explicitly creates two tracks. - (1) only requires applicant to inform about registry services that are not in the pre-approved list while (2) requires all services to be informed and described at application time

Feedback taken from the latest discussions on the list: - The list of services on (1) and (2) could be expanded to the "minimal pre-approved services" that would be allowed even if there is no such list for already established registry operators. - Some already mentioned the list in AGB as a possible starting point: "A. Receipt of data from registrars concerning registration of domain names and name servers. B. Dissemination of TLD zone files. C. Dissemination of contact or other information concerning domain name registrations (e.g., port -43 WHOIS, Web - based Whois, RESTful Whois service). D. Internationalized Domain Names, where offered. E. DNS Security Extensions (DNSSEC)."

</co-chair> - The mention of registry services evaluation after contract signing in (1) is probably misplaced, since it's part of a policy not covered in our charter. It's also redundant. - The requirement of specifying pre-approved services in the application in (2) is likely ineffective if there is such a list for registry operators, since a registry could activate them just after contract signing since they are pre-approved. It has an effect though if no such list for registry operators exists at that time. A question arises: do we assume such a list will exist or think on both scenarios ? <co-chair>

Any further thoughts, feedback or new straw proposals ?

Rubens

...

Em 5 de set de 2017, à(s) 18:09:000, Aikman-Scalese, Anne <AAikman@lrrc.com <mailto:AAikman@lrrc.com>> escreveu:

Rubens, My Straw Proposal is actually stated in A. below, and yet you have said you did not receive it. It would be good to have the two side by side. 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 http://lrrc.com <http://lrrc.com/>

From: Rubens Kuhl [mailto:rubensk@nic.br <mailto:rubensk@nic.br>] Sent: Tuesday, September 05, 2017 2:05 PM To: Aikman-Scalese, Anne Cc: Jeff Neuman; gnso-newgtld-wg-wt4@icann.org <mailto:gnso-newgtld-wg-wt4@icann.org> Subject: Re: [Gnso-newgtld-wg-wt4] Registry Services straw-person

Em 5 de set de 2017, à(s) 17:52:000, Aikman-Scalese, Anne <AAikman@lrrc.com <mailto:AAikman@lrrc.com>> escreveu:

Rubens, I have communicated separately with you off-list and to Leadership regarding your response. The following comments are circulated to the entire list:

A. Please circulate the second Straw Proposal in addition to your own for comparison purposes. The second proposal is that the language of Question 23 remain the same as in the 2012 round which states that all new services to be offered MUST BE DESCRIBED (see below) with the following addition: “Applicant acknowledges that ICANN may establish two application evaluation tracks which will operate separately, one for applications which propose new registry services and one for applications which contain only the following pre-approved registry services: LIST PRE-APPROVED SERVICES HERE (TO BE DISCUSSED ON THE NEXT CALL).

As I mentioned, I haven't received the second straw proposal. I believe Sarah, Kurt, and perhaps you could join them, were going to send one... as soon as one does, let's start circulating them both. Or three or more if it needs be...

Note also the agenda for the next call was defined long before this discussion, and doesn't include registry services... if there is AOB time for it, it's sure a topic to add.

B. You state that it is “out-of-scope” for Work Track 4 for us to discuss the policy issue of incurring additional fees for evaluation of additional new registry services. However, it is in fact your Straw Proposal that suggests such additional fees are appropriate. If this is policy work that is “out-of-scope” for Work Track 4, then the language of your Straw Proposal is itself “out-of-scope”.

The latest straw person actually removed any fees reference, exactly due to that. BTW, this was added due to a comment during the call that was one made not by me or Cheryl... but anyway, it's removed both due to opposition and to be out of scope.

C. You state that I cannot raise issues regarding effect on RPM policy because that is for the RPM PDP, not for Work Track 4. If you are advocating a policy change that affects RPM policy, it has to be raised and flagged, not buried as “out of scope” for Work Track 4.) How will the RPM PDP even KNOW that such an issue is being created by a proposed change in Question 23 if not discussed and brought to their attention?

On the connection with RPM PDP WG, while there is not something currently foreseen at the work-track level, there is at the WG level, and every WT definition comes first to the WG, doesn't go into final report before that. From our charter: "Second-Level Rights Protection Mechanisms: Proposing recommendations directly related to RPMs is beyond the remit of this PDP. There is an anticipated PDP on the "current state of all rights protection mechanisms (RPMs) implemented for both existing and new gTLDs, including but not limited to the UDRP and the URS...". Duplication or conflicting work between the New gTLD Subsequent Procedures PDP and the PDP on RPMs must be avoided. If topics relatedto RPMs are uncovered and discussed in the deliberations of this PDP, those topics should be relayed to the PDP on RPMs for resolution. To assure effective coordination between the two groups, a community liaison, who is a member of both Groups, is to be appointed jointly by both Groups and confirmed by the GNSO Council."

The first topic you mentioned seemed to me an aspect of the sunrise/claims process, which is being actively worked by the RPM PDP WG. The other one is about registry services in general so is not directly related to RPMs; either way, every one of the SubPro recommendations will need, at the end, an analysis of whether it uncovered a new topic that should be forwarded to the RPM PDP or not.

(remaining text already replied to)

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. _______________________________________________ Gnso-newgtld-wg-wt4 mailing list Gnso-newgtld-wg-wt4@icann.org <mailto:Gnso-newgtld-wg-wt4@icann.org> https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg-wt4 <https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg-wt4>

On Aug 31, 2017, at 9:49 PM, Alan Greenberg <alan.greenberg@mcgill.ca> wrote:

Rubens, what GNSO Policy are you referring to? The only one I am aware of is the RSEP.

This one: https://gnso.icann.org/en/issues/registry-services/final-rpt-registry-approv... (GNSO Policy as approved by Council) https://gnso.icann.org/en/meetings/review-process-registry-change-requests25... (Process flowchart as approved by Council) https://www.icann.org/resources/board-material/resolutions-2005-11-08-en (Board resolution approving GNSO Registry Services Policy) https://www.icann.org/resources/unthemed-pages/net-registry-agreement-2005-0... (.NET agreement of the time, mentioned in Board Resolution) While RSEP is indeed its nickname, it was born as "Procedure for use by ICANN in considering requests for consent and related contractual amendments to allow changes in the architecture or operation of a gTLD registry".

Although public consultation is not specified in the policy, the implementation of the policy publishes the RSEP requests and has included an opportunity for public input during the 15 day evaluation process.

If the current implementation is right or wrong is terms of following the policy is something for ICANN staff to argue. The implementation has been updated quite heavily over the years, without any community input, so both the policy and the policy implementation framework might not have been observed. Sticking to GNSO and Board approved policy helps us not go into down into this discussion. What I can assure you than ICANN does not treat that 15-day interval as a capital P capital C capital P Public Comment Period. I have once questioned that in one RSEP request I filed in 2014 (RSEP 2014082, 2-char SLDs release), and they were pretty clear in not considering that 15-day as such. On a curious note, even ICANN does not know who receives the e-mails for registryservice@icann.org , which is the channel for the providing comments during that 15-day period: http://mm.icann.org/pipermail/registryservice/2017q3/000081.html (In fact it's a comment forum with more forum spam than actual comments) What could be aligned with policy is for ICANN to take public input on the decision of whether a registry service creates a security, stability or competition concern. There is no other criteria in the policy to be assessed for a registry service, so if someone is willing to help ICANN making its mind on these 3 topics, I think it's only fair to help them, as long as ICANN follows the policy-specified deadlines (15 days for the initial determination, 45 days after determination for competition concerns) and investigates only the subject matters above. Rubens