August 2017 - Gnso-newgtld-wg-wt4

Registry Services straw-person
by Rubens Kuhl Sept. 14, 2017

Sept. 14, 2017

Hi all. Based on our call today, this is a new straw-person to base our discussion on Q23 (Registry Services): "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, applicant will specify whether it wants it evaluated thru RSEP at evaluation time, contracting time or after contract signing, acknowledging that exception processing in evaluation or contracting could incur additional application fees. If applicant has not informed additional registry services, RSEP will only be available after contract signing. " Rubens

7 33

Re: [Gnso-newgtld-wg-wt4] Registry Services straw-person
by Aikman-Scalese, Anne Aug. 31, 2017

Aug. 31, 2017

Thanks John. As mentioned on the call and in my email, it is not an objection to having two different tracks. And I am not insisting on the old system. The objection is to charging applicants more for making applications that propose new services - that language is in the new straw person. Charging more for applications that propose new services runs counter to the stated purpose of the new gTLD program, i.e. to encourage innovation and competition. I also object to delaying discussion of new services to the contracting phase. I believe these new services form part of the evaluation process. Anne Anne E. Aikman-Scalese Of Counsel 520.629.4428 office 520.879.4725 fax AAikman(a)lrrc.com _______________________________ Lewis Roca Rothgerber Christie LLP One South Church Avenue, Suite 700 Tucson, Arizona 85701-1611 lrrc.com -----Original Message----- From: John R. Levine [mailto:johnl@iecc.com] Sent: Thursday, August 31, 2017 10:27 AM To: Aikman-Scalese, Anne Cc: gnso-newgtld-wg-wt4(a)icann.org Subject: Re: [Gnso-newgtld-wg-wt4] Registry Services straw-person > 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. I was one of the people who evaluated the registry services in the current round, and I can say that a list of pre-approved services is an excellent idea. In this round, most service proposals were cut and pasted from boilerplate provided by a handful of backend registries, and we spent a lot of time effectively looking for cut and paste errors. (I wrote some text comparison tools to speed it up.) Then when we found such errors, there'd be a round or two of negotiation to fix them, generally just changing the text to what it should have been in the first place. There were some services that were actually different and needed skilled evaluation but they were a small minority. The alternative to some services approved quickly and some evaluated slowly is to have them all evaluated slowly again. I don't see how that would help anyone other than running up the billable hours for us evaluators. Regards, John Levine, johnl(a)iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly ________________________________ 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.

1 0

Updated slides re: Actions/Discussion Notes: Work Track 4 Sub Team Meeting 31 August
by Julie Hedlund Aug. 31, 2017

Aug. 31, 2017

Dear Sub Team Members, Please see the attached updated slides from today’s call. Best regards, Julie From: <gnso-newgtld-wg-wt4-bounces(a)icann.org> on behalf of Julie Hedlund <julie.hedlund(a)icann.org> Date: Thursday, August 31, 2017 at 11:59 AM To: "gnso-newgtld-wg-wt4(a)icann.org" <gnso-newgtld-wg-wt4(a)icann.org> Subject: [Gnso-newgtld-wg-wt4] Actions/Discussion Notes: Work Track 4 Sub Team Meeting 31 August Dear Sub Team Members, Please see below the action items and discussion notes captured by staff from the meeting on 31 August. These high-level notes are designed to help Work Track Sub Team members navigate through the content of the call and are not meant to be a substitute for the recording. Please also see the recording on the meetings page at: https://community.icann.org/display/NGSPP/Work+Track+4+Meetings. Note also that the referenced slides for today’s meeting are attached and excerpts from the chat room are included below. Best regards, Julie Julie Hedlund, Policy Director Action Items/Discussion Notes 31 August Application Evaluation (continued) Non-scored questions (slide 5) -- Is that a theme for WT4: -- Apparent consensus: Forward to Q18 to WT2 (incorporation into agreement) and WT3 (objections and advices) -- Keep Q23 with WT4 (Registry Services) >From the chat: Trang Nguyen: Note that Q18, although not scored, is used by the Tech/Fin panel as context for those evals. Registry Services (slide 6) -- Mainly used as a means to collection information to build "Exhibit A" (Approved Services in registry contracts -- Probably less useful when technical evaluation is done in bulk or not done at all (RSP Program) -- Undergooing discussions might streamline registry service adoption Registry Services -- Straw-person (slide 7) -- Applicants allowed but not required to specify additional registry services [reference slide for details] -- Services evaluated through RSEP -- If no additional services, RSEP will be used after contract signing Discussion: -- Good middle ground. Only concern is with the technical streamlining: how this affects the order of processing of applications. Could it somehow affect how we evaluate applications for the same string? Have we thought about how this middle ground would affect identical strings but with different services? -- All possible applicants to the same strings will follow the same path. Doesn't change the order of processing even if one applicant has proposed different services for one string. -- So, the description of the additional services will be described in the application so that would be transparent. There would an award before the services are approved? -- Two issues: First, it is not clear that an applicant will be able to answer the questions associated with RSEP at the time of application. It may not be practical at that time. If this is really an ancillary service that the registry can do or not depending on how the RSEP is treated that could be find. But if this is a service that the registry has to provide because of its business model, then that is problematic. Also, in the normal RSEP process ICANN gives a quick decision, then there is a public comment process, and then maybe a panel. Not clear that it is feasible for the registry to wait to go through that process. I think they need a heads up earlier. -- If you want the fast track to contractual delegation then don't propose any additional services, but some applicants might want those services evaluated before contention sets. -- We are looking for innovation. There could be a case where if we are looking for new ideas I'm not sure this supports that direction. That is an issue that needs to be considered. -- An applicant can describe additional services, but is not obliged to. Maybe move to an RSEP light. -- In the 2012 round there was a separate registry services evaluation. That evaluation had a set of criteria that was used. What happened was at contracting time for the purpose of pulling together exhibit A of the contract we went through the process again, which was not very efficient. The registry services were provided in question 23 of the application. That was not written in a way that it could be used as exhibit A. There are some improvements that could be made there. If you waited until you signed a contact and then applied for a new service it went through the RSEP process. Doesn't make sense for it to go through a different process before and after the contract is signed. -- Nothing wrong with doing a segmented process on new applications, but the process described above is reasonable because it is fair because if something should fail the applicant should know early. Perhaps we should ask if this is a service that is necessary and would they withdraw the application if it is not approved. I don't think we gave the public an opportunity to comment on these registry services. -- Devil's advocate: The slowness of the process discouraged innovation. Speeding up the process could encourage innovation. -- Could be the failure to identify and address the root causes of the delays. When you are working on remedies for that you have different types of remedies. One could be not enough qualified staff to process applications. If you want to encourage innovation you will find a way to train and hire qualified people and you will address the issue of how contract evaluations get done without disfavoring those who provide these additional services. -- Is there a different way we could look at this. Not just speed (fast or slow) but about efficiency. If the process is more efficient it will benefit everyone. Instead of doing things twice let's figure out if we can do the process once and then figure out where that would happen -- before contention resolution or after. -- In 2012 the majority were services that were already being offered so having them go through an additional evaluation is not very efficient. -- Agree: more about efficiency than speed. One of the problems was that every time someone suggested something new or different members of the community objected. The fact that things need to go back to an IRT that can result in incredible delays. The fact that some brands proposed closed models the community said we hadn't thought about that. Name collision issue also caused delays. There is no one root cause as to why there were delays. If we could try to address those by creating a more efficient application and evaluation process, and having a more solid predictability framework that doesn't rely on having long community discussions and processes. But if we have and RFP program to approve them and a predictability framework these will help. I think we need to not think about each thing in its own silo. -- Proposal that there are departments in ICANN one that processes contracts that don't have new services and one that processes contracts that do. From the chat: [Anne Aikman-Scalese (IPC): PROPOSAL - ICANN Should have two sections for processing applications: one would process applications that contain no new services proposals. The other would handle applications which contain proposals for new services. In this manner, they would proceed in parallel so that processing of applications with new services proceeds apace and is not disadvantaged by being considered later at the contracting phase. The other problem with this is that applicants will come in with basic services in order to get approval and then raise new services later in contracting that may not be part of evaluation but maybe should have been part of evaluation.] [Move this discussion to the list. Note that if we cannot come up with a consensus for change then the process will stay as it is.] >From the chat: Jeff Neuman: @Rubens - I am not sure that was what I understood. If you have contention resolution prior to evaluating the new services, then in theory if there are auctions, the participant of the auction that proposed the new ancillary service will be assuming that the service will be approved in determining how much it wants to bid. IF the service is refused, that could be a huge hit on the winner Anne Aikman-Scalese (IPC): @Jeff - I am very concerned about streamlining and granting early contracting to applicants that are not offering new services. Agree with Alan we are looking for innovation and new ideas. This proposal does not support that direction. hil Buckingham: @ Trang I agree.. The question is whether to drop Q18 . What happens if an applicant wishes to change their mission statement ( Q18 ) post acheiving a financial / technical evaluation pass . Should the evaluations need to be redone based on the new mission statement . Jeff Neuman: Because the last process took years for applications to be evaluated, approved, contracted, etc.....those that did want to innovate either had huge staff turnover, lost budget, lost staff, lost resources, etc. between the application submission in 2012 and when they were finally approved/contracted in 2015/2016 Jeff Neuman: @Anne - you are assuming a limited 3rd party registration model Jeff Neuman: you need to think bigger than that Jeff Neuman: One of the biggest reasons I have found that brands have not launched or have not launched as big as we all throught they would, is the time lage between app submission and approval Jeff Neuman: all of the delays took its toll Anne Aikman-Scalese (IPC): Odd refference to my type of thinking Jeff - please be more specific - it doesn't help to just say my thinking is somehow not big enought for you. Cheryl Langdon-Orr (CLO): indeed Jeff Jeff Neuman: So I would argue that the slowness discouraged innovation greatly Anne Aikman-Scalese (IPC): @Jeff - so the problem is how quickly we process applications - it may be about not having enough qualified conttractting staff that is temporary. The root cause could be something other than you say. Cheryl Langdon-Orr (CLO): yes Alan Rubens Kuhl: Personal opinion: brands are wating for Google to use non-legacy TLDs. ;-) bens Kuhl: Personal opinion: brands are wating for Google to use non-legacy TLDs. ;-) Alan Greenberg: @Jeff, that is exactly the type of registry that may NEED a special service. Jeff Neuman: There were a lot of factors they caused the delays. There was not just one root cause Jeff Neuman: @Anne - I disagree that that is the root cause avri doria: i would probably arrgue that there are several contenders for root cause. Rubens Kuhl: Amdahl's law: we can only increase the efficiency of the scope we are looking at. Cheryl Langdon-Orr (CLO): thanks Trang Rubens Kuhl: .frogans was also something a bit different. Anne Aikman-Scalese (IPC): I believe that proposed new services are part of evaluation. We should have dual simultaneous tracks - not just delay all new services to later contracting. avri doria: yes, exception processing, of all sorts, was a time sink. Rubens Kuhl: TM+50 also caused a delay. Sarah L Verisign: Speaking of the new CEO (at the time) I remember when Fadi Chehade stood up at the time and said that the program wasn’t ready, in his opinion, but he was being told by the community to push ahead regardless (paraphrase) and that is what happened. I think there is a concern that when we put expediency ahead of efficiency and general readiness there are going to be delays – things don’t go as expected for any number of reasons which is why it’s so important to get it closer to general readiness this time. Cheryl Langdon-Orr (CLO): thanks Sarah, Jeff Neuman: @Sarah - Fadi claimed it wasnt ready because he believed that there should be a unilateral right to amend registry contracts and a way to incorporate "public interest commitments". I do not believe he claimed it was because ICANN staff and third party providers were not ready to accept applications and evaluate them Jeff Neuman: @Sarah - and developing a predictability framework as we discussed on Monday is key to ensuring there is a process to handle the new things when they do arise Sarah L Verisign: What he said was... . "Honestly, if it was up to me, I would delay the whole release of new gTLDs by at least a year." 2. "… a lot of the foundations that I would be comfortable with, as someone who has built businesses before, are just not yet there." 3. "We have people who took six years to write the [new gTLD Applicant] Guidebook and we're asking engineers and software people and third-party vendors and hundreds of people to get that whole program running in six months." Anne Aikman-Scalese (IPC): PROPOSAL - ICANN Should have two sections for processing applications: one would process applications that contain no new services proposals. The other would handle applications which contain proposals for new services. In this manner, they would proceed in parallel so that processing of applications with new services proceeds apace and is not disadvantaged by being considered later at the contracting phase. The other problem with this is that applicants will come in with basic services in order to get approval and then raise new services later in contracting that may not be part of evaluation but maybe should have been part of evaluation. Donna Austin, Neustar: Agree with Jeff, that its important that context is taken into account particularly when quoting Fadi, also important to understand who is audience was. Sarah L Verisign: @Donna and @Jeff, I do agree that his comments should be considered in context are important but it isnt correct just to say they were contractual or framework related. Anne Aikman-Scalese (IPC): Thanks Sarah - I think that if you have two ramps up front - you have a much better "middle ground". That way extra services are part of evaluation phase (not just contracting.) and these proceed as quickly as possible. avri doria: or an option to get an RSEP-like preeval before needing to pay for any other exception processing. (exception = objection, contentions, &c.) Sarah L Verisign: I like Anne's suggestion that there should be an "off-ramp" for applications that have exceptional requirements so as not to delay more standard applications Phil Buckingham: @ Anne , I agree the need for two sections . Perhaps there should be an inbuilt time factor. Applicant have to wait 2 years ( say) post launch before new proposals for new services can be proposed . That would require a full re-evaluation of the new business model. Jeff Neuman: @sarah and @Anne - if there is an off ramp, to the extent that we do rounds, that will be an off ramp for all applications in that contention set Technical Questions -- Security Policy (slide 8) Straw-person: -- Keep Q30a (summary of security policy) -- Remove Q30b (full security policy) Draft Language (slide 9) Discussion: -- Flag that WT4 feedback on the technical evaluation criteria. Some of the responses did touch on this. Touch on some time of an RSP Program. Also suggested some additional enhancements on certification of security practices.

1 0

Attendance, Recording, AC recording, & AC Chat from New gTLD Subsequent Procedures Sub Team Track 4 IDNs/Technical & Operations call on Thursday, 31 August 2017 15:00 UTC
by Julie Bisland Aug. 31, 2017

Aug. 31, 2017

Dear All, Please find the attendance and recording of the call attached to this email. The Adobe Connect recording and AC Chat are below for the New gTLD Subsequent Procedures Sub Team – Track 4 – IDNs/Technical & Operations held on Thursday, 31 August 2017 at 15:00 UTC. Adobe Connect recording: https://participate.icann.org/p1wevfyk9rr/<https://participate.icann.org/p1wevfyk9rr/?OWASP_CSRFTOKEN=f0f4dcd59786ab91…> The recordings of the calls are posted on the GNSO Master Calendar page: http://gnso.icann.org/en/group-activities/calendar ** Please let me know if your name has been left off the list ** Mailing list archives: http://mm.icann.org/pipermail/gnso-newgtld-wg-wt4 Agenda Wiki page: https://community.icann.org/x/NAEhB Thank you. Kind regards, Julie ------------------------------- Adobe Connect chat transcript for 31 August 2017 Julie Bisland:Welcome to the New gTLD Subsequent Procedures Sub Team – Track 4 – IDNs/Technical & Operations will take place on Thursday, 31 August 2017 at 15:00 Julie Bisland:Agenda wiki page: https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_x_… Cheryl Langdon-Orr (CLO):hi there Cheryl Langdon-Orr (CLO):hi Rubens Trang Nguyen:Note that Q18, although not scored, is used by the Tech/Fin panel as context for those evals. Cheryl Langdon-Orr (CLO):oops I neglected to ask you all if there were any changes to your SOIs to report to the meeting, sorry ð... I blame the hour here (0105)... PLEASE note here if you need to update your SOI, and we will come back to that at end of the call. Cheryl Langdon-Orr (CLO):Noted, thanks Trang Jeff Neuman:@Anne - do you have a proposal? Jeff Neuman:@Rubens - I am not sure that was what I understood. If you have contention resolution prior to evaluating the new services, then in theory if there are auctions, the participant of the auction that proposed the new ancillary service will be assuming that the service will be approved in determining how much it wants to bid. IF the service is refused, that could be a huge hit on the winner Anne Aikman-Scalese (IPC):@Jeff - I am very concerned about streamlining and granting early contracting to applicants that are not offering new services. Agree with Alan we are looking for innovation and new ideas. This proposal does not support that direction. Phil Buckingham:@ Trang I agree.. The question is whether to drop Q18 . What happens if an applicant wishes to change their mission statement ( Q18 ) post acheiving a financial / technical evaluation pass . Should the evaluations need to be redone based on the new mission statement . Jeff Neuman:@Anne - To take the other side, speed of approval does encourage innovation. Anne Aikman-Scalese (IPC):It almost sounds as though we are concerned about a contracting logjam. What is the concern we are trying to address for applicants? Is it earlier contracting and earlier launch? Jeff Neuman:I should say, can encourage innovation Anne Aikman-Scalese (IPC):Jeff - not if speed dictates sameness of servie. It will in fact discourage innovation, i.e. do what has already been done and you will launch and sell names very qucikly. Jeff Neuman:Because the last process took years for applications to be evaluated, approved, contracted, etc.....those that did want to innovate either had huge staff turnover, lost budget, lost staff, lost resources, etc. between the application submission in 2012 and when they were finally approved/contracted in 2015/2016 Jeff Neuman:@Anne - you are assuming a limited 3rd party registration model Jeff Neuman:you need to think bigger than that Jeff Neuman:One of the biggest reasons I have found that brands have not launched or have not launched as big as we all throught they would, is the time lage between app submission and approval Jeff Neuman:all of the delays took its toll Anne Aikman-Scalese (IPC):Odd refference to my type of thinking Jeff - please be more specific - it doesn't help to just say my thinking is somehow not big enought for you. Cheryl Langdon-Orr (CLO):indeed Jeff Jeff Neuman:So I would argue that the slowness discouraged innovation greatly Anne Aikman-Scalese (IPC):@Jeff - so the problem is how quickly we process applications - it may be about not having enough qualified conttractting staff that is temporary. The root cause could be something other than you say. Cheryl Langdon-Orr (CLO):yes Alan Rubens Kuhl:Personal opinion: brands are wating for Google to use non-legacy TLDs. ;-) Alan Greenberg:@Jeff, that is exactly the type of registry that may NEED a special service. Jeff Neuman:There were a lot of factors they caused the delays. There was not just one root cause Jeff Neuman:@Anne - I disagree that that is the root cause avri doria:i would probably arrgue that there are several contenders for root cause. Rubens Kuhl:Amdahl's law: we can only increase the efficiency of the scope we are looking at. Cheryl Langdon-Orr (CLO):thanks Trang Rubens Kuhl:.frogans was also something a bit different. Anne Aikman-Scalese (IPC):I believe that proposed new services are part of evaluation. We should have dual simultaneous tracks - not just delay all new services to later contracting. avri doria:yes, exception processing, of all sorts, was a time sink. Rubens Kuhl:TM+50 also caused a delay. Sarah L Verisign:Speaking of the new CEO (at the time) I remember when Fadi Chehade stood up at the time and said that the program wasn’t ready, in his opinion, but he was being told by the community to push ahead regardless (paraphrase) and that is what happened. I think there is a concern that when we put expediency ahead of efficiency and general readiness there are going to be delays – things don’t go as expected for any number of reasons which is why it’s so important to get it closer to general readiness this time. Cheryl Langdon-Orr (CLO):thanks Sarah, Jeff Neuman:@Sarah - Fadi claimed it wasnt ready because he believed that there should be a unilateral right to amend registry contracts and a way to incorporate "public interest commitments". I do not believe he claimed it was because ICANN staff and third party providers were not ready to accept applications and evaluate them Jeff Neuman:@Sarah - and developing a predictability framework as we discussed on Monday is key to ensuring there is a process to handle the new things when they do arise Sarah L Verisign:What he said was... . "Honestly, if it was up to me, I would delay the whole release of new gTLDs by at least a year." 2. "… a lot of the foundations that I would be comfortable with, as someone who has built businesses before, are just not yet there." 3. "We have people who took six years to write the [new gTLD Applicant] Guidebook and we're asking engineers and software people and third-party vendors and hundreds of people to get that whole program running in six months." Sarah L Verisign:etc Alan Greenberg:@Rubens First time I have heard Gene Amdahl or his law mentioned in a very long time. Jeff Neuman:[Note that when he said this it was after his meeting in Davos with governments which raised his profile in the governmental community....something he was very interested in doing. Things need to be viewed in complete context Alan Greenberg:He died just 2 years ago. Anne Aikman-Scalese (IPC):PROPOSAL - ICANN Should have two sections for processing applications: one would process applications that contain no new services proposals. The other would handle applications which contain proposals for new services. In this manner, they would proceed in parallel so that processing of applications with new services proceeds apace and is not disadvantaged by being considered later at the contracting phase. The other problem with this is that applicants will come in with basic services in order to get approval and then raise new services later in contracting that may not be part of evaluation but maybe should have been part of evaluation. Donna Austin, Neustar:Agree with Jeff, that its important that context is taken into account particularly when quoting Fadi, also important to understand who is audience was. Sarah L Verisign:@Donna and @Jeff, I do agree that his commments should be considered in context are important but it isnt correct just to say they were contractual or framework related. Cheryl Langdon-Orr (CLO):ok Julie Bisland:The next New gTLD Subsequent Procedures Sub Team – Track 4 – IDNs/Technical & Operations will take place on Thursday, 14 September 2017 at 20:00 UTC for 60 minutes. avri doria:are variants to the strawproposal still possible? Sarah L Verisign:I like Anne's suggestion that there should be an "off-ramp" for applications that have exceptional requirements so as not to delay more standard applications Steve Chan:20:00 UTC Rubens Kuhl:Avri, sure. I will send one to the list. Anne Aikman-Scalese (IPC):Thanks Sarah - I think that if you have two ramps up front - you have a much better "middle ground". That way extra services are part of evaluation phase (not just contracting.) and these proceed as quickly as possible. avri doria:or an option to get an RSEP-like preeval before needing to pay for any other exception processing. (exception = objection, contentions, &c.) Phil Buckingham:@ Anne , I agree the need for two sections . Perhaps there should be an inbuilt time factor. Applicant have to wait 2 years ( say) post launch before new proposals for new services can be proposed . That would require a full re-evaluation of the new business model. Jeff Neuman:@sarah and @Anne - if there is an off ramp, to the extent that we do rounds, that will be an off ramp for all applications in that contention set Jeff Neuman:I would encourage that we tie this all to the predictability framework as well Anne Aikman-Scalese (IPC):thanks everyone Phil Buckingham:thanks

1 0

WT4 call - September 14 2000 UTC
by Rubens Kuhl Aug. 31, 2017

Aug. 31, 2017

Dear WT4 members, Next call for the New gTLD Subsequent Procedures Sub Team – Track 4 - IDNs/Technical & Operations will take place on September 14, 2000 UTC. The proposed agenda is as follows, continuing themes related to Application Evaluation: 1. Welcome 2. SOIs 3. Financial Evaluation 4. Clarifying Questions 5. AOB Thanks, CLO & Rubens

1 0

Actions/Discussion Notes: Work Track 4 Sub Team Meeting 31 August
by Julie Hedlund Aug. 31, 2017

Aug. 31, 2017

Dear Sub Team Members, Please see below the action items and discussion notes captured by staff from the meeting on 31 August. These high-level notes are designed to help Work Track Sub Team members navigate through the content of the call and are not meant to be a substitute for the recording. Please also see the recording on the meetings page at: https://community.icann.org/display/NGSPP/Work+Track+4+Meetings. Note also that the referenced slides for today’s meeting are attached and excerpts from the chat room are included below. Best regards, Julie Julie Hedlund, Policy Director Action Items/Discussion Notes 31 August Application Evaluation (continued) Non-scored questions (slide 5) -- Is that a theme for WT4: -- Apparent consensus: Forward to Q18 to WT2 (incorporation into agreement) and WT3 (objections and advices) -- Keep Q23 with WT4 (Registry Services) >From the chat: Trang Nguyen: Note that Q18, although not scored, is used by the Tech/Fin panel as context for those evals. Registry Services (slide 6) -- Mainly used as a means to collection information to build "Exhibit A" (Approved Services in registry contracts -- Probably less useful when technical evaluation is done in bulk or not done at all (RSP Program) -- Undergooing discussions might streamline registry service adoption Registry Services -- Straw-person (slide 7) -- Applicants allowed but not required to specify additional registry services [reference slide for details] -- Services evaluated through RSEP -- If no additional services, RSEP will be used after contract signing Discussion: -- Good middle ground. Only concern is with the technical streamlining: how this affects the order of processing of applications. Could it somehow affect how we evaluate applications for the same string? Have we thought about how this middle ground would affect identical strings but with different services? -- All possible applicants to the same strings will follow the same path. Doesn't change the order of processing even if one applicant has proposed different services for one string. -- So, the description of the additional services will be described in the application so that would be transparent. There would an award before the services are approved? -- Two issues: First, it is not clear that an applicant will be able to answer the questions associated with RSEP at the time of application. It may not be practical at that time. If this is really an ancillary service that the registry can do or not depending on how the RSEP is treated that could be find. But if this is a service that the registry has to provide because of its business model, then that is problematic. Also, in the normal RSEP process ICANN gives a quick decision, then there is a public comment process, and then maybe a panel. Not clear that it is feasible for the registry to wait to go through that process. I think they need a heads up earlier. -- If you want the fast track to contractual delegation then don't propose any additional services, but some applicants might want those services evaluated before contention sets. -- We are looking for innovation. There could be a case where if we are looking for new ideas I'm not sure this supports that direction. That is an issue that needs to be considered. -- An applicant can describe additional services, but is not obliged to. Maybe move to an RSEP light. -- In the 2012 round there was a separate registry services evaluation. That evaluation had a set of criteria that was used. What happened was at contracting time for the purpose of pulling together exhibit A of the contract we went through the process again, which was not very efficient. The registry services were provided in question 23 of the application. That was not written in a way that it could be used as exhibit A. There are some improvements that could be made there. If you waited until you signed a contact and then applied for a new service it went through the RSEP process. Doesn't make sense for it to go through a different process before and after the contract is signed. -- Nothing wrong with doing a segmented process on new applications, but the process described above is reasonable because it is fair because if something should fail the applicant should know early. Perhaps we should ask if this is a service that is necessary and would they withdraw the application if it is not approved. I don't think we gave the public an opportunity to comment on these registry services. -- Devil's advocate: The slowness of the process discouraged innovation. Speeding up the process could encourage innovation. -- Could be the failure to identify and address the root causes of the delays. When you are working on remedies for that you have different types of remedies. One could be not enough qualified staff to process applications. If you want to encourage innovation you will find a way to train and hire qualified people and you will address the issue of how contract evaluations get done without disfavoring those who provide these additional services. -- Is there a different way we could look at this. Not just speed (fast or slow) but about efficiency. If the process is more efficient it will benefit everyone. Instead of doing things twice let's figure out if we can do the process once and then figure out where that would happen -- before contention resolution or after. -- In 2012 the majority were services that were already being offered so having them go through an additional evaluation is not very efficient. -- Agree: more about efficiency than speed. One of the problems was that every time someone suggested something new or different members of the community objected. The fact that things need to go back to an IRT that can result in incredible delays. The fact that some brands proposed closed models the community said we hadn't thought about that. Name collision issue also caused delays. There is no one root cause as to why there were delays. If we could try to address those by creating a more efficient application and evaluation process, and having a more solid predictability framework that doesn't rely on having long community discussions and processes. But if we have and RFP program to approve them and a predictability framework these will help. I think we need to not think about each thing in its own silo. -- Proposal that there are departments in ICANN one that processes contracts that don't have new services and one that processes contracts that do. From the chat: [Anne Aikman-Scalese (IPC): PROPOSAL - ICANN Should have two sections for processing applications: one would process applications that contain no new services proposals. The other would handle applications which contain proposals for new services. In this manner, they would proceed in parallel so that processing of applications with new services proceeds apace and is not disadvantaged by being considered later at the contracting phase. The other problem with this is that applicants will come in with basic services in order to get approval and then raise new services later in contracting that may not be part of evaluation but maybe should have been part of evaluation.] [Move this discussion to the list. Note that if we cannot come up with a consensus for change then the process will stay as it is.] >From the chat: Jeff Neuman: @Rubens - I am not sure that was what I understood. If you have contention resolution prior to evaluating the new services, then in theory if there are auctions, the participant of the auction that proposed the new ancillary service will be assuming that the service will be approved in determining how much it wants to bid. IF the service is refused, that could be a huge hit on the winner Anne Aikman-Scalese (IPC): @Jeff - I am very concerned about streamlining and granting early contracting to applicants that are not offering new services. Agree with Alan we are looking for innovation and new ideas. This proposal does not support that direction. hil Buckingham: @ Trang I agree.. The question is whether to drop Q18 . What happens if an applicant wishes to change their mission statement ( Q18 ) post acheiving a financial / technical evaluation pass . Should the evaluations need to be redone based on the new mission statement . Jeff Neuman: Because the last process took years for applications to be evaluated, approved, contracted, etc.....those that did want to innovate either had huge staff turnover, lost budget, lost staff, lost resources, etc. between the application submission in 2012 and when they were finally approved/contracted in 2015/2016 Jeff Neuman: @Anne - you are assuming a limited 3rd party registration model Jeff Neuman: you need to think bigger than that Jeff Neuman: One of the biggest reasons I have found that brands have not launched or have not launched as big as we all throught they would, is the time lage between app submission and approval Jeff Neuman: all of the delays took its toll Anne Aikman-Scalese (IPC): Odd refference to my type of thinking Jeff - please be more specific - it doesn't help to just say my thinking is somehow not big enought for you. Cheryl Langdon-Orr (CLO): indeed Jeff Jeff Neuman: So I would argue that the slowness discouraged innovation greatly Anne Aikman-Scalese (IPC): @Jeff - so the problem is how quickly we process applications - it may be about not having enough qualified conttractting staff that is temporary. The root cause could be something other than you say. Cheryl Langdon-Orr (CLO): yes Alan Rubens Kuhl: Personal opinion: brands are wating for Google to use non-legacy TLDs. ;-) bens Kuhl: Personal opinion: brands are wating for Google to use non-legacy TLDs. ;-) Alan Greenberg: @Jeff, that is exactly the type of registry that may NEED a special service. Jeff Neuman: There were a lot of factors they caused the delays. There was not just one root cause Jeff Neuman: @Anne - I disagree that that is the root cause avri doria: i would probably arrgue that there are several contenders for root cause. Rubens Kuhl: Amdahl's law: we can only increase the efficiency of the scope we are looking at. Cheryl Langdon-Orr (CLO): thanks Trang Rubens Kuhl: .frogans was also something a bit different. Anne Aikman-Scalese (IPC): I believe that proposed new services are part of evaluation. We should have dual simultaneous tracks - not just delay all new services to later contracting. avri doria: yes, exception processing, of all sorts, was a time sink. Rubens Kuhl: TM+50 also caused a delay. Sarah L Verisign: Speaking of the new CEO (at the time) I remember when Fadi Chehade stood up at the time and said that the program wasn’t ready, in his opinion, but he was being told by the community to push ahead regardless (paraphrase) and that is what happened. I think there is a concern that when we put expediency ahead of efficiency and general readiness there are going to be delays – things don’t go as expected for any number of reasons which is why it’s so important to get it closer to general readiness this time. Cheryl Langdon-Orr (CLO): thanks Sarah, Jeff Neuman: @Sarah - Fadi claimed it wasnt ready because he believed that there should be a unilateral right to amend registry contracts and a way to incorporate "public interest commitments". I do not believe he claimed it was because ICANN staff and third party providers were not ready to accept applications and evaluate them Jeff Neuman: @Sarah - and developing a predictability framework as we discussed on Monday is key to ensuring there is a process to handle the new things when they do arise Sarah L Verisign: What he said was... . "Honestly, if it was up to me, I would delay the whole release of new gTLDs by at least a year." 2. "… a lot of the foundations that I would be comfortable with, as someone who has built businesses before, are just not yet there." 3. "We have people who took six years to write the [new gTLD Applicant] Guidebook and we're asking engineers and software people and third-party vendors and hundreds of people to get that whole program running in six months." Anne Aikman-Scalese (IPC): PROPOSAL - ICANN Should have two sections for processing applications: one would process applications that contain no new services proposals. The other would handle applications which contain proposals for new services. In this manner, they would proceed in parallel so that processing of applications with new services proceeds apace and is not disadvantaged by being considered later at the contracting phase. The other problem with this is that applicants will come in with basic services in order to get approval and then raise new services later in contracting that may not be part of evaluation but maybe should have been part of evaluation. Donna Austin, Neustar: Agree with Jeff, that its important that context is taken into account particularly when quoting Fadi, also important to understand who is audience was. Sarah L Verisign: @Donna and @Jeff, I do agree that his comments should be considered in context are important but it isnt correct just to say they were contractual or framework related. Anne Aikman-Scalese (IPC): Thanks Sarah - I think that if you have two ramps up front - you have a much better "middle ground". That way extra services are part of evaluation phase (not just contracting.) and these proceed as quickly as possible. avri doria: or an option to get an RSEP-like preeval before needing to pay for any other exception processing. (exception = objection, contentions, &c.) Sarah L Verisign: I like Anne's suggestion that there should be an "off-ramp" for applications that have exceptional requirements so as not to delay more standard applications Phil Buckingham: @ Anne , I agree the need for two sections . Perhaps there should be an inbuilt time factor. Applicant have to wait 2 years ( say) post launch before new proposals for new services can be proposed . That would require a full re-evaluation of the new business model. Jeff Neuman: @sarah and @Anne - if there is an off ramp, to the extent that we do rounds, that will be an off ramp for all applications in that contention set Technical Questions -- Security Policy (slide 8) Straw-person: -- Keep Q30a (summary of security policy) -- Remove Q30b (full security policy) Draft Language (slide 9) Discussion: -- Flag that WT4 feedback on the technical evaluation criteria. Some of the responses did touch on this. Touch on some time of an RSP Program. Also suggested some additional enhancements on certification of security practices.

1 0

WT4 Agenda for August 31
by Rubens Kuhl Aug. 29, 2017

Aug. 29, 2017

Dear WT4 members, This week's call for the New gTLD Subsequent Procedures Sub Team – Track 4 - IDNs/Technical & Operations will take place in August 31, 1500 UTC. The proposed agenda is as follows, continuing themes related to Application Evaluation: 1. Welcome 2. SOIs 3. Application Evaluation (continued) Non-scored questions Registry Services Security Policy Financial Questions Measurable Criteria 4. AOB Adobe Connect room: https://participate.icann.org/newgtldsubteams/ You can connect your audio by following instructions in the pop up in the AC room, or use the Connect Me option that was sent in the calendar invitation. Best, CLO & Rubens

1 0

Technical mailing lists outreach
by Rubens Kuhl Aug. 19, 2017

Aug. 19, 2017

Hi there. One of the suggestions we've got for progressing the discussion on name collisions was to do outreach to groups focusing on DNS technology, such DNS-OARC's DNS-Operations, IETF DNS-Op and RIPE DNS-WG. I've just did this as can be seen in the mailing list archives for those lists: https://www.ripe.net/ripe/mail/archives/dns-wg/2017-August/003448.html <https://www.ripe.net/ripe/mail/archives/dns-wg/2017-August/003448.html> https://www.ietf.org/mail-archive/web/dnsop/current/msg20872.html <https://www.ietf.org/mail-archive/web/dnsop/current/msg20872.html> https://lists.dns-oarc.net/pipermail/dns-operations/2017-August/016589.html <https://lists.dns-oarc.net/pipermail/dns-operations/2017-August/016589.html> I will get back to WT4 with the responses when they seem to converge, but anyone interested in the original responses we get can look at the mailing list archives. Rubens

1 0

Actions/Discussion Notes: Work Track 4 Sub Team Meeting 17 August
by Julie Hedlund Aug. 17, 2017

Aug. 17, 2017

Dear Sub Team Members, Please see below the action items and discussion notes captured by staff from the meeting on 17 August. These high-level notes are designed to help Work Track Sub Team members navigate through the content of the call and are not meant to be a substitute for the recording. Please also see the recording on the meetings page at: https://community.icann.org/display/NGSPP/Work+Track+4+Meetings. Note also that the referenced document and slides for today’s meeting are attached and excerpts from the chat room are included below. Best regards, Julie Julie Hedlund, Policy Director Action Items/Discussion Notes 17 August Action: Match the notes/transcript/recording with slides 9. Start with side 9 at next meeting. 1. Plenary: Topics that were discussed: -- Rounds -- Predictability Framework -- Geographic Names and the Top Level 2. Application Evaluation: Slide 5: Where we are: -- Concluded on some principles. -- Re: financial aggregation to be done by RO not to put an applicant over another applicant in the pool. Question: What was the consensus in the order of applications? Response: Not in scope for Work Track 4. Being discussed in other work tracks. discuss how is should be done. Could be subject to evaluation in Work Track 1. -- Need to note that is subject to consideration by the plenary. Not only the plenary, -- Overhaul of the financial questions: Think about developing a strawpersons considering the CC2 comments. -- Root scaling has to be considered. -- Asked ICANN staff for answers to the classification question. Still need to provide questions and answers. Slide 6: Non-Scored Questions: -- Question: Are we asking whether an applicant can change the purpose of a TLD? Is it within the scope of Work Track 4? Or is it a question on merits? Response: We can say what it shouldn't be. The topic of the representation of applicants. It is captured under contractual compliance in Work Track 2 -- seems to make sense to forward it. RSP Program: -- Strawperson couldn't specify. -- How to streamline the process but not get in the way of innovation. Slide 8: Registry Services: -- Does such planned evaluation need to be evaluated? -- What if a registry wants to offer a service of a registry of famous marks? Someone may want to mount an objection to that. -- What prevents someone from doing what you fear? Adding this as a new registry service? -- Proposal strawman language that applications wouldn't be allowed to specify registry services. >From the chat room: Steve Chan: @Anne, the order of evaluation is being discussed in WT1 Anne Aikman-Scalese (IPC): @Staff re notes - Cheryl just noted the addition of "subject to considerations of order of evaluation being addressed in Work Track 1" as fine. Julie Hedlund: @Anne: Noted in the chat as the notes are not comprehensive. We have the recording for that. Steve Chan: There are some thoughts from GDD staff in the Program Implementation Review, starting on page 82 here: https://www.icann.org/en/system/files/files/program-review-29jan16-en.pdf Steve Chan: Regarding the Financial Evaluation and the possible benefit of alternative approaches Cheryl Langdon-Orr (CLO): yes 18 Cheryl Langdon-Orr (CLO): it is of course in scope of other WT's though so we could shift it from us Cheryl Langdon-Orr (CLO): :-) all yours as to why Steve :-) Cheryl Langdon-Orr (CLO): Yep where it belongs IMO WT2 Cheryl Langdon-Orr (CLO): as I said above (personal opinion of course) Cheryl Langdon-Orr (CLO): Fob it off YES please :-) Rubens Kuhl: I don't remember. I should, but I don't. Steve Chan: You can see in section 4.3.4.4 here about the Q18 integration into the RA: https://community.icann.org/download/attachments/58735939/Section%204.3.4.p… Cheryl Langdon-Orr (CLO): That can be a LT call then Anne WT2 or 2/3 but not ours ;-) Steve Chan: And Objectiosn are indeed in WT3 :) Anne Aikman-Scalese (IPC): Thanks Steve. I agree re Work Track 2 being the best fit. Steve Chan: The feedback from GDD has re: changes to the technical evaluation, as well as the response about the CQs, have been added to the Wiki here: https://community.icann.org/x/YT2AAw Cheryl Langdon-Orr (CLO): Thx Steve and we will need to focus on these in the WT in the near future Cheryl Langdon-Orr (CLO): slide 7 Cheryl Langdon-Orr (CLO): 8 Cheryl Langdon-Orr (CLO): hmmm I have a delay in my AC chat turning up... Sorry Cheryl Langdon-Orr (CLO): Slide 9 Quoc Pham: is there a typo on point 4? GPML = DPML? Quoc Pham: I would also want to point out that if point 4 is supposed to be DPML, the DPML is a Dounuts product which is not a universal/generic product or service (e.g. offering IDNs), we should avoid pointing out Registry specific products perhaps? Rubens Kuhl: DPML is a registry-specific product. GPML is a general term for PMLs. Quoc Pham: ah ok Quoc Pham: sorry Cheryl Langdon-Orr (CLO): Time check 15 mins eft on this call Cheryl Langdon-Orr (CLO): I tend to agree Anne In my personal capacity but does such innovation *need* to be evaluated at application is the key as Rubens is pointin out now Anne Aikman-Scalese (IPC): re straw-person on registry services - strongly disagree re limiting services described in application.

1 0

FW: ICANNOrganization Response to WT4 Request for Clarifying Questions Information
by Steve Chan Aug. 10, 2017

Aug. 10, 2017

Dear WT4 Members, You may recall that WT4 requested information related to clarifying questions from ICANN’s Global Domains Division (GDD). Below, please see the response that GDD has prepared. As you’ll note at the end of the message, Christine Willett and team are available to respond to questions or for participation during a WT4 call to discuss further. Best, Steve ========================= Steve, Please forward the email below to the appropriate members of the GNSO Subsequent Procedures PDP Working Group and Work Track 4 members as appropriate. Best, Christine ========================= Dear All, I am writing in response to a request from Work Track 4 (WT4) of the New gTLD Subsequent Procedures PDP WG. Members of the WT4 team have requested the Global Domains Division (GDD) of the ICANN Organization to provide: 1. Full text of clarification questions asked and answers for questions 24, 25, 26, 27, 28, 29, 30a 2. Identification of applications and per-application number of clarification questions asked and number of responses for questions 30b, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49 The ICANN Organization is committed to supporting the efforts of WT4 and is actively working to fulfill these requests. The sections below include our response to Request #2 and additional considerations and information about timing for Request #1. Number of Clarifying Questions We note that WT4 requested (Request #2 above): “Identification of applications and per-application number of clarification questions asked and number of responses for questions 30b, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49.” We understand this to mean that WT4 requests that for each of the 1,930 applications, ICANN should identify if the application received a CQ for each application question, and the number of CQs issued. The table below provides the total number of CQs issued for individual questions 24 - 44, which was published in ICANN's Program Implementation Review Report (https://www.icann.org/en/system/files/files/program-review-29jan16-en.pdf) Note that only one CQ per application per question was possible. As Q30b – Q49 were confidential portions of the application, it would not be appropriate for the ICANN Organization to publicly share which applications received CQs on specific questions. QuestionQuestion Description# Applications with CQ Issued Q24Shared Registration System (SRS) Performance54 Q25EPP919 Q26Whois142 Q27Registration Life Cycle181 Q28Abuse Prevention & Mitigation72 Q29Rights Protection Mechanisms594 Q30Security170 Q31Technical Overview of Proposed Registry412 Q32Architecture65 Q33Database Capabilities18 Q34Geographic Diversity24 Q35DNS Service Compliance264 Q36IPV6 Reachability41 Q37Data Backup Policies and Procedures27 Q38Escrow30 Q39Registry Continuity57 Q40Registry Transition121 Q41Failover Testing42 Q42Monitoring and Fault Escalation Processes13 Q43DNSSEC334 Q44IDNs (Optional)170 Q45Financial Statements587 Q46Projections Template: Costs and Funding126 Q47Costs: Setup and Operating986 Q48Funding and Revenue857 Q49Contingency Planning: Barriers, Funds, Volumes292 Clarifying Questions & Responses for Public Questions We note that WT4 requested, "Full text of clarification questions asked and answers for questions 24, 25, 26, 27, 28, 29, and 30a." As you are aware, Questions 24 through 30a are the public questions of the Technical and Operational Capability section of the New gTLD application as per the 2012 Applicant Guidebook. The initial responses to these questions were published before the evaluation period began. However, neither the Clarifying Questions (CQs) nor applicant responses to CQs were published. As displayed in the table above, for question 24 - 30a, nearly 2,000 CQs were issued. Many of the approximately 2,000 responses include one or more attachments. It will take a significant amount of effort to extract, compile, and publish this volume of information. As it was not foreseen that this information would be published as part of the application process, there may be sensitive data included in the CQ responses or attachments. To address this, we are planning to inform applicants that these materials will be published and shared with WT4, and we will take their feedback into account before publishing the responses. We anticipate this communication going out in the next week. Depending on the feedback received, we are considering publishing the CQs first and then publishing the CQ responses at a later date. The CQs are less likely to contain sensitive information than the responses, but may still include sensitive information, so ICANN will review the content of the CQs prior to publication. We expect to be able to publish the CQs in the next 45 - 60 days, barring technical challenges or confidentiality concerns. The responses may take 90 days or longer to publish, due to the effort required to extract, review, and publish the responses and associated attachments. We hope this information is helpful to the efforts of WT4. Please do not hesitate to reach out to us with additional questions or comments. If WT4 would like to discuss these requests or the Organization’s approach to these responses, I would be happy to attend a WT4 meeting to discuss. Sincerely, Christine A. Willett Vice President, Operations Global Domains Division ICANN

1 0