- Gnso-newgtld-wg-wt4 - lists.icann.org

ICANN Compliance x Name Collisions
by Rubens Kuhl Sept. 14, 2017

Sept. 14, 2017

https://www.icann.org/en/system/files/files/compliance-update-jun17-en.pdf <https://www.icann.org/en/system/files/files/compliance-update-jun17-en.pdf> At the end of page 3: "This quarter, the ICANN Contractual Compliance team also processed referrals from ICANN Technical Services regarding controlled interruption wildcard record violations. Approximately 45 TLDs were found to have activated names (other than nic.tld) in the DNS, while controlled interruption wildcard records continued to exist in their zone file." It seems a high number of TLDs are still having issues with the 2012-round Name Collision Framework, long after delegation. This specific data point suggests that one of the suggested modifications, having ICANN or an ICANN contractor run the process before the TLD is delegated to the approved applicant, would not only address the time-to-market problem seen by registries but also improve compliance with the framework as designed. We should note though that this report doesn't mention distribution by registry service provider; all 45 TLDs could share a single back-end for all we know. Rubens

3 4

Financial evaluation failures
by Rubens Kuhl Sept. 1, 2017

Sept. 1, 2017

25 applications failed financial evaluation criteria; of those 25, 3 also failed technical evaluation. Of those 3, 2 were multiple questions failures (3 questions in one application, 5 questions in another). Even removing those 2 that are more like generalized issues, there were: - 18 applications that failed Q45 (Financial statements) - 3, 2 being open TLDs from the same applicant and 1 brand TLD, applications that failed Q50 (Contingency planning) - 1 GeoTLD application that failed Q48 (Funding and revenue) Comments on those: Q45: Clearly the worst offender of financial evaluation. Something to be discussed in more detail in our next call. Q48: Possibly just an applicant that refrained from providing wild guesses on financials. That GeoTLD currently has 14k registrations with no history of giving domains for free/cheap, so it's probably better than a good number of other TLDs that are still losing money. Q50: The Brand TLD that is already a cost center instead of a revenue line probably failed it in a way similar to Q45 (lack of declaration from officers committing X amount of money). The Open TLD applicant is a curious issue; I'll try asking that applicant if he is willing to provide the full text of the answer. Rubens

1 0

Re: [Gnso-newgtld-wg-wt4] Registry Services panel evaluation failures
by Rubens Kuhl Sept. 1, 2017

Sept. 1, 2017

> Em 1 de set de 2017, à(s) 16:36:000, John R. Levine <johnl(a)iecc.com> escreveu: > >> Comment: this is was an overreach from the panel. Such stability measures that prevent domain registrants from changing to configurations that will make their domains inaccessible are in use in a bunch of TLDs, including TLDs with millions of registrations like .cz and .br. The full text that led to failure is from a non-public response on DNSSEC, and many other applications from the same back-end passed evaluation. This both indicates the panel looking in duplicity questions that were evaluated by the technical panel, and lack of consistent evaluation. > > Remember what I said about cut and paste errors? Fair enough about my last sentence. Consistency failures could come from applicants not doing ctrl+c ctrl+v correctly and from evaluation. But the reason for the failure is still pretty clear as an overreach, and also goes to disenfranchising innovation: since most TLDs don't care about registrant DNS configurations, the ones that do are bullied into not doing it. > >> 1-1155-50524 >> >> "The Registry Services Evaluation Panel was not able to determine whether your proposal to offer Internationalized Domain Name (IDN) registrations would raise significant Security and Stability issues as described in Section 2.2.3.1 of the Applicant Guidebook (AGB). Yourapplication (including Clarifying Question and Outreach responses) did not provide sufficient information concerning IDN registration policies, variant management policies, and resourcing plans in accordance with the criteria of Question 44 in the AGB. Yourapplication is eligible foran Extended Evaluation as described in Section 2.3.3 of the AGB." >> >> Comment: IDN question was an optional question, and by answering to it, the panel failed an application for a question that was not required. Considering we already made good progress in IDN evaluation, by incorporating LGRs (Label Generation Rules), whether this could occur or not again is yet to be seen. > > There were a lot of screwed up IDN profiles. I don't remember the details. That's why ICANN required all IDN info again at contract signing... but this one was curious that an optional feature made it fail. If an optional feature is not adequately implemented, just that feature should be removed... the only case where I see IDN services as mandatory are in IDN TLDs. We could add that to the IDN proposed language. Anyway, since IDN evaluation will be totally different, perhaps one future program review could look into whether the planned change was successful or not. Rubens

1 0

Technical evaluation failures
by Rubens Kuhl Sept. 1, 2017

Sept. 1, 2017

Of the 8 applications that failed initial evaluation in technical section, 4 failed due to multiple technical evaluation questions, and 3 of those 4 also failed financial evaluation. In these 4 multiple-questions failure there are some brand TLDs who didn't grasp the concept of operating a registry instead of operating DNS services for a domain and one applicant that just didn't respond to CQs in time. Of the 4 that failed due to a single question, there were: Q28 (Abuse prevention and mitigation): Applicant submitted a change request, but Q28 was not updated in line with that change request. Q31 (Technical overview of the registry): Not disclosed in the report what was the failure Q35 (DNS service): Not disclosed in the report what was the failure Q40 (Registry Transition): Insufficient information in response to CQs Questions 31, 35 and 40 and the applications that failed multiple questions are likely addressed by RSP program; the only question that from the IE reports could deserve some attention is about abuse prevention and mitigation. At the time AGB was create there were no PICs; abuse measurement were after the fact included as Spec 11 3b. We have two paths we can go here: 1) Considering Spec 11 3b and Spec 6 item 4 (Abuse Mitigation) as superseding what was meant to be obtained by Q28 2) Considering that Q28 is still relevant Preferences between those two ? Note that even outsourced registries do not have to outsource abuse mitigation to the same provider; that could be a different provider. Rubens

1 0

Registry Services panel evaluation failures
by Rubens Kuhl Sept. 1, 2017

Sept. 1, 2017

Two applications failed initial evaluation due to registry services panel: 1-1155-50524 and 1-2090-26288. These are the evaluation results for them: 1-2090-26288 "Registry Services Eligible for Extended Evaluation Yourapplication (including Clarifying Question and Outreach responses) did not provide sufficient information concerning DNSSEC policies for the Registry Services Evaluation Panel to determine whether or not your proposal to disallow the prepublication of registrant DS records with no matching DNSKEY on the child would raise significant Security and Stability issues as described in Section 2.2.3.1 of the Applicant Guidebook (AGB). Yourapplication is eligible foran Extended Evaluation as described in Section 2.3.3 of the AGB." Comment: this is was an overreach from the panel. Such stability measures that prevent domain registrants from changing to configurations that will make their domains inaccessible are in use in a bunch of TLDs, including TLDs with millions of registrations like .cz and .br. The full text that led to failure is from a non-public response on DNSSEC, and many other applications from the same back-end passed evaluation. This both indicates the panel looking in duplicity questions that were evaluated by the technical panel, and lack of consistent evaluation. 1-1155-50524 "The Registry Services Evaluation Panel was not able to determine whether your proposal to offer Internationalized Domain Name (IDN) registrations would raise significant Security and Stability issues as described in Section 2.2.3.1 of the Applicant Guidebook (AGB). Yourapplication (including Clarifying Question and Outreach responses) did not provide sufficient information concerning IDN registration policies, variant management policies, and resourcing plans in accordance with the criteria of Question 44 in the AGB. Yourapplication is eligible foran Extended Evaluation as described in Section 2.3.3 of the AGB." Comment: IDN question was an optional question, and by answering to it, the panel failed an application for a question that was not required. Considering we already made good progress in IDN evaluation, by incorporating LGRs (Label Generation Rules), whether this could occur or not again is yet to be seen. What is clear to me that lack of a concrete line between the registry services panel and the technical evaluation panel is likely an issue. Registry services are the "what" and technical infrastructure is the "how", and mangling the two is something to be avoided. Rubens

1 0

Initial Evaluation Reports
by Rubens Kuhl Sept. 1, 2017

Sept. 1, 2017

Hi there. Policy staff provide a nice tool for us to understand what led to initial evaluation failure on the 35 applicants that did; the attached spreadsheet contains that information. Summary: - 2 failures due to registry services panel - 3 failures due to geographic names panel (and so it's not in our plate) - 8 failures in technical evaluation - 23 failures in financial evaluation I'll be dissecting each of the 3 in our scope (registry services, technical, financial) in later messages. Rubens

1 0

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