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

Next WT4 call
by Rubens Kuhl Jan. 19, 2017

Jan. 19, 2017

Dear WT4 members, The call for the New gTLD Subsequent Procedures Sub Team – Track 4 - IDNs/Technical & Operations will take place on Thursday, 19 January 2016 at 15:00 UTC, 07:00 PST, 10:00 EST, 15:00 London, 16:00 CET. For other times: http://migre.me/vTJup The proposed agenda is as follows: 1. Welcome 2. SOIs 3. Full WG update 4. CC2 questions 5. WT4 schedule and planning until ICANN 58 6. List of ongoing consensus calls and discussion themes 7. 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, Rubens

4 3

Recording, Attendance & AC Chat from New gTLD Subsequent Procedures Sub Team Track 4 IDNs/Technical & Operations call
by Terri Agnew Jan. 19, 2017

Jan. 19, 2017

Dear All, Please find the attendance and recording of the call attached to this email and the AC Chat below for the New gTLD Subsequent Procedures Sub Team – Track 4 – IDNs/Technical & Operations held on Thursday, 19 January 2017 at 15:00 UTC. 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/wLPDAw Thank you. Kind regards, Terri ------------------------------- Adobe Connect chat transcript for 19 January 2017 Terri Agnew:Welcome to the New gTLD Subsequent Procedures Sub Team – Track 4 – IDNs/Technical & Operations onThursday, 19 January 2017 at 15:00 UTC. Terri Agnew:agenda wiki page: https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_x_… Dietmar Lenden - Valideus Ltd:Thanks Terri Terri Agnew:@Jeff audio quality is good at this time Terri Agnew:30 January New gTLD Subsequent Procedures Working Group 15:00 UTC Terri Agnew:All hands have been cleared Jeff Neuman:Not sure how to phrase this, but I would love to hear about experiences from those that have launched IDN TLDs Jeff Neuman:What challenges they have had Jeff Neuman:what can be done for improvement Alan Greenberg:I am not seeing anything in the centre pod. Alan Greenberg:oops - now back! Martin Sutton:need to amend the financial question to quote financial Martin Sutton:its done Martin Sutton:thx Jeff Neuman:For technical evaluation: Should the number of TLDs applied for, plus ones they currently run, be taken into consideration in the evaluation. If so, how Trang Nguyen:@Jeff, you are correct. Applications were evaluated on a standalone basis in the 2012 round. Jeff Neuman:Question for ICANN/Evaluators:Did the evaluators/panelists submit performance improvement reports or other comments on what improvements could be made for subsequent procedures? Jeff Neuman:Was there any post mordem process? Jeff Neuman:If so, can we see those? Trang Nguyen:We had debriefs with the evaluation panels and they provided comments and suggestions, which we took into account when drafting the PIRR. Jeff Neuman:PIRR? Trang Nguyen:Program Implementation Review Report Jeff Neuman:Is it possible to see the original comments? Trang Nguyen:They were provided to ICANN as confidential documents, not for external consumption. Jeff Neuman:Why confidential? Trang Nguyen:We could check with them to see if they would have any issues with releasing them. Jeff Neuman:I can understand redacted portions related to individual applications......but it would be great to see their comments. It may help us to revise questions that were asked of applicants Trang Nguyen:Their comments/suggestions were largely consistent with ICANN's observations as reflected in the PIRR, but we could take an action to ask them whether we can share their reports. avri doria:Trang, that would be good to check if you could. Thanks Phil Buckingham:which bullets points do you wish to discuss . Phil Buckingham:Q should there be a separate financial template for each "type" of business model . Jeff Neuman:@Trang. That makes total sense.....We should document that formally and put it into the guidebook Martin Sutton:That would be helpful to have more detail Trang - can that be shared? Martin Sutton:Should there also be some differentiation between self-funded registries where they are the only registrant, i.e. impact on registrants is not relevant? Phil Buckingham:@ Trang , does ICANN have the points scored for each question by application by type of business model ( ie closed / open / IDNs ) . Then possibly we can start to identify the problem questions Martin Sutton:@Trang - good point, but that could be built in to a transition process where checks have to be completed before they switch over Phil Buckingham:@ trang- when an applicant reaches a set number of DUMs ? I thought it was 50K that would trigger a change from closed model to an open one ? Jeff Neuman:@Trang - good questions Jeff Neuman:@Avri - correct. That is being implemented by some TLDs now Jeff Neuman:@Avri - Changes are right now through RSEP process and that is currently beyond the scope of this PDP Phil Buckingham:Exactly Avri - does a change of application status mean new financial evaluation / due diligence Cheryl Langdon-Orr (CLO):I am not aware of any of our WT s looking at that either Avri so yes we need to catch them Jeff Neuman:Other than accounting for changes in the contracting process, I am not sure we should be delving into how future changes are done. We can recommend a separate PDP for that, but if we go down that path now, we will never finish. Steve Chan:I think it has been discussed in the context of other topics (e.g., different TLD types), but there is not a dedicated topic related to the subject. Jeff Neuman:Plus, that has applicability to existing registries as well as for those for future ones Phil Buckingham:+1 Steve Cheryl Langdon-Orr (CLO):re change of mode Phil Buckingham:Agree Jeff- cant backtrack . Martin Sutton:Agree with Jeff - recommendation for separate PDP to progress this, as it is a post-application change Cheryl Langdon-Orr (CLO):mode=model yes Jeff agree Terri Agnew:next call: New gTLD Subsequent Procedures Sub Team – Track 4 – IDNs/Technical & Operations will take place on Thursday, 09 February 2017 at 20:00 UTC. Trang Nguyen:Sorry, i will try to provide answers to questions aked in the chat via the mail list. Dietmar Lenden - Valideus Ltd:thanks Ruben and the rest avri doria:thanks Trang Nguyen:Thanks, all!

1 0

Re: [Gnso-newgtld-wg-wt4] Consensus Call 1: Technical Capability to be evaluated after application, before contract signing
by Roger D Carney Dec. 16, 2016

Dec. 16, 2016

Good Morning, Just following along with a few of the questions/ideas Jeff raised. Are we trying to create an application process that does not take technical considerations into account until the TLD has been basically “awarded” to a single applicant? I think that would create a situation where many applicants would not understand the technical expertise and/or true costs needed to run a registry until after contention sets have been resolved and they will get to that spot and say “oh that is too hard” or “oh that is too expensive.” I think the technical questions and the discussions with the registry service providers are needed for Registry Operators to understand the true complexities and costs of running a TLD and realistically should be done prior to applying. And it seems like waiting to do this until after contention set resolution could be costly to the applicants and process. Thanks Roger From: gnso-newgtld-wg-wt4-bounces(a)icann.org [mailto:gnso-newgtld-wg-wt4-bounces@icann.org] On Behalf Of Rubens Kuhl Sent: Friday, December 16, 2016 6:20 AM To: Jeff Neuman <jeff.neuman(a)comlaude.com> Cc: gnso-newgtld-wg-wt4(a)icann.org Subject: Re: [Gnso-newgtld-wg-wt4] Consensus Call 1: Technical Capability to be evaluated after application, before contract signing On Dec 16, 2016, at 9:23 AM, Jeff Neuman <jeff.neuman(a)comlaude.com<mailto:jeff.neuman@comlaude.com>> wrote: The other question I have on the language is on the interaction with contention resolution (assuming there is one or more application windows or rounds). With your change, in theory we could have a situation where a prevailing registry in contention resolution may not pass a technical evaluation. Should there be a time limit on demonstrating its capabilities? It's already specified by ICANN that there is a time limit between being approved and signing a contract. It would fall within that time limit to either secure an approved RSP or get technical evaluation approval, or request an extension to ICANN to get such approval. If it is unable to demonstrate that, what do you do? Can get kind of messy? That's why there was also a question in Hyderabad, reflected in the slides, of what should happen in the case, but people seemed not interested in discussing it. We also have some similar situations right now like applicants not passing background screening, failing to pay the auction bid or simply failing to send the signed agreement to ICANN. I prefer thinking what happens even in corner cases such as this, but in this case the existing mechanism of allowing some time to sign and possibly grant an extension to that seems enough to handle it. Should we state that in the case of contention resolution it needs to be prior to the completion of such contention resolution? . The feedback in Hyderabad was the opposite of that: that only after contention resolution should the quest for technical capability begin, because it was only at that point that the applicant would be sure of having secured the TLD. Otherwise, many applicants have to secure contracts while only one will become a registry. That's exactly the issue this is trying to address. Rubens Jeffrey J. Neuman Senior Vice President |Valideus USA | Com Laude USA 1751 Pinnacle Drive, Suite 600 Mclean, VA 22102, United States E: jeff.neuman(a)valideus.com<mailto:jeff.neuman@valideus.com> or jeff.neuman(a)comlaude.com<mailto:jeff.neuman@comlaude.com> T: +1.703.635.7514 M: +1.202.549.5079 @Jintlaw From: Rubens Kuhl [mailto:rubensk@nic.br] Sent: Friday, December 16, 2016 10:47 AM To: Jeff Neuman <jeff.neuman(a)comlaude.com<mailto:jeff.neuman@comlaude.com>> Cc: gnso-newgtld-wg-wt4(a)icann.org<mailto:gnso-newgtld-wg-wt4@icann.org> Subject: Re: [Gnso-newgtld-wg-wt4] Consensus Call 1: Technical Capability to be evaluated after application, before contract signing Jeff, It would speed-up the process to reach both milestones of contract signing and TLD delegation, since the technical infrastructure won't have to be evaluated and delegation readiness will already be known. It will also allow applicants to choose a Registry Services Provider when they see fit; if they prefer selecting it before applying it would be their choice, if they prefer shopping for a provider after securing the TLD, they could too. It still keeps the freedom to use a completely new infrastructure and have it evaluated, a liberty that can be useful now that there is one open-source gTLD registry system available: http://domainincite.com/21147-google-could-shake-up-the-registry-market-wit… . (Previously, CoCCA had sources available but was not license-free to gTLD registries, only to ccTLD registries). But anticipating something from the implementation phase, I think it will make sense to have technical evaluation charged as a separate cost item for applicants, in order to benefit most of the applicants with the cost reduction potential of the RSP program. But that's a definition not in the table for now, just a side note for us to get back within the IRT for this policy. Rubens On Dec 16, 2016, at 7:25 AM, Jeff Neuman <jeff.neuman(a)comlaude.com<mailto:jeff.neuman@comlaude.com>> wrote: Rubens, If we had a Registry Services Provider pre-approval process, how would that process interact with the policy you have stated below? Jeffrey J. Neuman Senior Vice President |Valideus USA | Com Laude USA 1751 Pinnacle Drive, Suite 600 Mclean, VA 22102, United States E: jeff.neuman(a)valideus.com<mailto:jeff.neuman@valideus.com> or jeff.neuman(a)comlaude.com<mailto:jeff.neuman@comlaude.com> T: +1.703.635.7514 M: +1.202.549.5079 @Jintlaw -----Original Message----- From: gnso-newgtld-wg-wt4-bounces(a)icann.org<mailto:gnso-newgtld-wg-wt4-bounces@icann.org> [mailto:gnso-newgtld-wg-wt4-bounces@icann.org] On Behalf Of Rubens Kuhl Sent: Thursday, December 15, 2016 8:32 PM To: gnso-newgtld-wg-wt4(a)icann.org<mailto:gnso-newgtld-wg-wt4@icann.org> Subject: [Gnso-newgtld-wg-wt4] Consensus Call 1: Technical Capability to be evaluated after application, before contract signing Hi All. For those on our call, you know we issued our first consensus call, based on an sensation of consensus on this during the full WG F2F meeting in Hyderabad. No consensus calls are final since they can be changed if new information arises or when it goes to the full WG, but we would like those to be strong guidances for other WTs and the full WG of where are we headed to. Consensus calls will go for at least two readings; considering the non-optimal attendance we will refrain from issuing the 2nd reading for this item for a while so further discussion can arise. The idea is to change one specific recommendation from the original policy, which was Recommendation 7: “Applicants must be able to demonstrate their technical capability to run a registry operation for the purpose that the applicant sets out. “ Possible changed language: “Applicants must be able demonstrate their technical capability to run a registry operation for the purpose that the applicant sets out, but will only be required to do so at contract-signing time, after passing other criteria and/or approvals and prevailing in contention set(s), if any.” Rationale: In the 2012-rounds applicants were required to contract, or internally develop, technical capability prior to applying. This was a burden for applicants that were required to pay a one-time or recurring fee to get access to such technical capability and in most cases made applicants stick to their originally contracted back-end provider due to time-to-market concerns. 2012-round showed that technical capabilities are somewhat easily contracted in the market for affordable prices. What changed from 2007 that supports the change: It was not foreseen that the registry service provider market would achieve the level of maturity and commoditization that is now seen; only a small percentage (that we can gather and publish in the final version) of applicants used their own internal back-end infrastructure. Portfolio applicants were not really thought of. Possible alternatives: - Keeping the original recommendation as it was - Moving the technical evaluation to some other point in the application lifecycle For discussion, comments, opposition... I will note that a rough consensus doesn't require unanimity, but even a single opposition with a compelling rationale can change a consensus call, so please don't take popularity of lack of thereof as criteria. We want to achieve the best possible result in adding the combined expertise of the group, which includes listening to every opinion. Best, Rubens _______________________________________________ Gnso-newgtld-wg-wt4 mailing list Gnso-newgtld-wg-wt4(a)icann.org<mailto:Gnso-newgtld-wg-wt4@icann.org> https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg-wt4

2 1

Consensus Call 1: Technical Capability to be evaluated after application, before contract signing
by Rubens Kuhl Dec. 16, 2016

Dec. 16, 2016

Hi All. For those on our call, you know we issued our first consensus call, based on an sensation of consensus on this during the full WG F2F meeting in Hyderabad. No consensus calls are final since they can be changed if new information arises or when it goes to the full WG, but we would like those to be strong guidances for other WTs and the full WG of where are we headed to. Consensus calls will go for at least two readings; considering the non-optimal attendance we will refrain from issuing the 2nd reading for this item for a while so further discussion can arise. The idea is to change one specific recommendation from the original policy, which was Recommendation 7: “Applicants must be able to demonstrate their technical capability to run a registry operation for the purpose that the applicant sets out. “ Possible changed language: “Applicants must be able demonstrate their technical capability to run a registry operation for the purpose that the applicant sets out, but will only be required to do so at contract-signing time, after passing other criteria and/or approvals and prevailing in contention set(s), if any.” Rationale: In the 2012-rounds applicants were required to contract, or internally develop, technical capability prior to applying. This was a burden for applicants that were required to pay a one-time or recurring fee to get access to such technical capability and in most cases made applicants stick to their originally contracted back-end provider due to time-to-market concerns. 2012-round showed that technical capabilities are somewhat easily contracted in the market for affordable prices. What changed from 2007 that supports the change: It was not foreseen that the registry service provider market would achieve the level of maturity and commoditization that is now seen; only a small percentage (that we can gather and publish in the final version) of applicants used their own internal back-end infrastructure. Portfolio applicants were not really thought of. Possible alternatives: - Keeping the original recommendation as it was - Moving the technical evaluation to some other point in the application lifecycle For discussion, comments, opposition... I will note that a rough consensus doesn't require unanimity, but even a single opposition with a compelling rationale can change a consensus call, so please don't take popularity of lack of thereof as criteria. We want to achieve the best possible result in adding the combined expertise of the group, which includes listening to every opinion. Best, Rubens

2 4

Discussion theme: sequence and method for financial evaluation
by Rubens Kuhl Dec. 15, 2016

Dec. 15, 2016

• AGB clearly overlooked different business models in 2012-round • Revenue-generating or self-sustainable registry (profit or non-profit) • Cost-center registry (typical of brands, possibly causes) • Besides different financial goals, single-application evaluation overlooked the possibility of an applicant winning so many TLDs to the point of not being able to run them (gaming the system) • Rec. 8: “Applicants must be able to demonstrate their financial and organisational operational capability.” • Possible Language: “Applicants must be able to demonstrate their financial and organisational operational capability in tandem for all currently-owned and applied-for TLDs that would be part of a single registry family.” • Financial Evaluation would still be gating and be done prior to contention set resolution

1 0

Discussion theme: Technical Evaluation to be performed as aggregated / consolidated as feasible
by Rubens Kuhl Dec. 15, 2016

Dec. 15, 2016

Hi All, Besides the consensus call I have already posted, we discussed two themes in the last WT4 call. I'll post them in different messages for easier ongoing discussion. Technical Evaluation to be performed as aggregated / consolidated as feasible • Consolidation is not fully tied with back-end certification, could apply to applications from the same applicant, but can be an enabler • Possible Language: “Technical Evaluation may be aggregated and/or consolidated to the maximum extent possible that generate process efficiencies, including both different applications from the same applicant and different applications sharing a common technical infrastructure” Ideas ? This is a discussion that will likely have some overlap with WT1, but that can be reconciliated by the full WG. The idea is to also explore possibilities that may or may not fall into some kind of registry service provider program (previously known as accreditation or certification). Rubens

1 0

Next WT4 meeting
by Rubens Kuhl Dec. 15, 2016

Dec. 15, 2016

(sorry for the incomplete message sent before) Hi there. We had yesterday a WT4 call where even though it was postponed from last week, we still had a somewhat low attendance. Considering next week this could be even harder due to holidays, if you plan to be at the next call please answer the following Doodle poll: http://doodle.com/poll/kdqibbhv74b264bb If you are not attending we will be glad to know that too. Thanks, Rubens WT4 co-chair

1 0

Next WT4 meeting
by Rubens Kuhl Dec. 15, 2016

Dec. 15, 2016

Hi there. We had yesterday

1 0

Recording, Attendance & AC Chat from New gTLD Subsequent Procedures Sub Team Track 4 IDNs/Technical & Operations call
by Michelle DeSmyter Dec. 15, 2016

Dec. 15, 2016

Dear All, Please find the attendance and recording of the call attached to this email and the AC Chat below for the New gTLD Subsequent Procedures Sub Team – Track 4 – IDNs/Technical & Operations held on Wednesday, 14 December 2016 at 20:00 UTC. The recordings of the calls are posted on the GNSO Master Calendar page: http://gnso.icann.org/en/group-activities/calendar<http://gnso.icann.org/en/group-activities/calendar#nov> ** 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 Wiki page: https://community.icann.org/x/K6HDAw Thank you. Kind regards, Michelle ------------------------------- Adobe Connect chat transcript for 14 December 2016 Michelle DeSmyter:Dear All, Welcome to the New gTLD Subsequent Procedures Sub Team – Track 4 – IDNs/Technical & Operations call on Wednesday, 14 December 2016 at 20:00 UTC. Michelle DeSmyter:Meeting page: https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_x_… Julie Hedlund:That sounds fine -- thanks! Phil Buckingham:rubens - you are very faint . Could you speak up avri doria:idoegraphic cs. non ideographic avri doria:? Phil Buckingham:me too - re headphones . but still faint avri doria:might want to consider adding ", if any" at the end of the stmt. Cheryl Langdon-Orr (CLO):good point Avri avri doria:i think we need two reading, both on calls to close a consensus call. Cheryl Langdon-Orr (CLO):yes the rationale is important on this proposed recommendation Phil Buckingham:this is a catch 22 , since the technical costs/ so contractual relationship with the backend provider will need be incurred and the costs put in the financial model for evaluation . Cheryl Langdon-Orr (CLO):thx Avri Phil Buckingham:no audio Phil Buckingham:thanks Cheryl avri doria:wee have to learn to speak again on AC. hard to do i know, i almost forgot how. Steve Chan:@Phil, we are happy to provide a dial out if you'd care to join! Phil Buckingham:point taken , Avri Steve Chan:If I recall, part of why every application was considered indivudually overall was related to principles of fairness? Kurt would probably be able to fact check that statement. Kurt Pritz:I have a bad connection. and did not hear the question Kurt Pritz:can you repeat. ? or skip me? Phil Buckingham:Totally agree Kurt. and nobody knew who was going to apply , how many portfolio players would submit multiple applications using the same model Rubens Kuhl:Kurt, that was Steve question from the chat above. Cheryl Langdon-Orr (CLO):chat above from Steve Phil Buckingham:the financial model was templated / standardised . It wont work for Round 2 . Each applicant's financial model needs to treat separately , evaluated , due diligence accordingly Phil Buckingham:Agreed Alan . Alot more . Steve Chan:@Rubens, I tried to note that the report acknowledges those challenges to some degree, but apparently i made that point ineffectively Steve Chan:So not just about inefficiency... ************************************************************************************************************************************************** Action Items/Discussion Notes 14 December 1. Hyderabad recap [slide 5 of the slide deck] -- Support for IDN 1-character was pictogram (Japanese or Korean), but opposition was not to Latin and Cyrillic, but use a more generic term. -- Probably would be good to use generic terms for all of them. -- Only those that represent 1 word. -- On support for IDN Variant TLDS -- Staff have had preliminary discussions with Sarmad Hussain on staff. He could provide background or a status update on the program. >From the Chat: avri doria: idoegraphic cs. non ideographic 2. Consensus call 1: Technical capability to be assessed at contract signing time [slide 7 in the slide deck] Possible language: "Applicants must be able to demonstrate their technical capability to run a registry operation for the purpose that the applicant sets out, but will only be required to do so at contract-signing time, after passing other criteria and/or approvals and prevailing in contention set(s), [if any]." -- If we do a consensus call over email should have the full story documented and presented to be taken into account. -- Today's discussion is just a temperature taking, not a consensus call. -- Explaining why the change is being made is important. Good to lay out those conditions, which will help this make sense. -- The financial model and testing the technical model are two different things. >From the chat: avri doria: might want to consider adding ", if any" at the end of the stmt. Cheryl Langdon-Orr (CLO): good point Avri avri doria: i think we need two reading, both on calls to close a consensus call. Cheryl Langdon-Orr (CLO): yes the rationale is important on this proposed recommendation Phil Buckingham: this is a catch 22 , since the technical costs/ so contractual relationship with the backend provider will need be incurred and the costs put in the financial model for evaluation. Cheryl Langdon-Orr (CLO): thx Avri 3. Discussion: Technical evaluation of applications to be performed as aggregated as feasible [slide 9 from the slide deck] -- During the evaluation process there wasn't a realization of how the market would evolve with respect to backend providers . -- It was thought at the outset that individual applications needed to be evaluated in the absense of knowing that the backend marketplace would be established. Things didn't work out as predicted. >From the Chat: Steve Chan: If I recall, part of why every application was considered indivudually overall was related to principles of fairness? Kurt would probably be able to fact check that statement. Phil Buckingham: Totally agree Kurt. and nobody knew who was going to apply , how many portfolio players would submit multiple applications using the same model 4. Discussion: Timing and method for Financial Evaluation [slide 10 from the slide deck] -- Could have speculative applications. The financial models are going to vary even more if the price goes down. -- Look at the program implementation report that staff produced. There were inefficiencies from treating every application individually. >From the chat: Phil Buckingham: the financial model was templated / standardised . It wont work for Round 2 . Each applicant's financial model needs to treat separately , evaluated , due diligence accordingly Agreed Alan . Alot more . Steve Chan: @Rubens, I tried to note that the report acknowledges those challenges to some degree, but apparently i made that point ineffectively. So not just about inefficiency...

1 0

Meeting starts in 7 minutes
by Rubens Kuhl Dec. 14, 2016

Dec. 14, 2016

Hi All, Just a reminder that meeting #5 of this work track is starting in 7 minutes, at 2000 UTC. Rubens

3 2