February 2018 - Gnso-newgtld-wg-wt1

Recordings, attendance & AC Chat New gTLD Subsequent Procedures Sub Team Track 1 Overall Process/Support/Outreach Issue call on Tuesday, 09 January 2018
by Michelle DeSmyter April 5, 2018

April 5, 2018

Dear All, Please find the attendance and AC Chat of the call are attached to this email. The AC recording and Mp3 are listed below for the New gTLD Subsequent Procedures Sub Team - Track 1 - Overall Process/Support/Outreach Issue held on Tuesday, 09 January 2018 at 03:00 UTC. Mp3: https://audio.icann.org/gnso/gnso-new-gtld-subsequent-track1-09jan18-en.mp3 Adobe Connect recording: https://participate.icann.org/p1l2j2tbun2/ The recordings of the calls are posted on the GNSO Master Calendar page: http://gnso.icann.org/en/group-activities/calendar[gnso.icann.org]<https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_en_group…> ** Please let me know if your name has been left off the list ** Mailing list archives: http://mm.icann.org/pipermail/gnso-newgtld-wg-wt1 Agenda Wiki page: https://community.icann.org/x/Sx1yB Thank you. Kind regards, Michelle -------------------------------

4 3

Recordings, attendance & AC Chat from New gTLD Subsequent Procedures Sub Team Track 1 Overall Process/Support/Outreach Issue call on Tuesday, 20 February 2018 20:00 UTC
by Julie Bisland Feb. 20, 2018

Feb. 20, 2018

Dear All, Please find the mp3 recording, attendance and AC Chat of the call attached to this email, and the AC recording below for the New gTLD Subsequent Procedures Sub Team – Track 1 – Overall Process/Support/Outreach Issue call held on Tuesday, 20 February 2018 at 20:00 UTC. Adobe Connect recording: https://participate.icann.org/p8ozxe4oanh/<https://participate.icann.org/p8ozxe4oanh/?OWASP_CSRFTOKEN=9b19dba8ccfaa74a…> 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-wt1 Agenda Wiki page: https://community.icann.org/x/3gSfB Thank you. Kind regards, Julie

1 0

Notes and Action Items Work Track 1 Sub Team Meeting 20 February 2018
by Julie Hedlund Feb. 20, 2018

Feb. 20, 2018

Dear Work Track members, Please see below the notes from the meeting today. These high-level notes are designed to help WG members navigate through the content of the call and are not a substitute for the recording or transcript. See the chat transcript and recording at: https://community.icann.org/display/NGSPP/2018+Work+Track+1+Meetings. See the referenced document at: https://docs.google.com/document/d/1guiX3L0FQAd7ZpwYIJI4FdY3pv09u0EnHMAark8…. Kind regards, Julie Julie Hedlund, Policy Director Notes/Action Items from Work Track 1 Sub Team Meeting 20 February 2018: 1. SOI Updates: No updates. 2. Review of potential recommendations for Support for Applicants from Developing Countries (4.2.14) See: https://docs.google.com/document/d/1guiX3L0FQAd7ZpwYIJI4FdY3pv09u0EnHMAark8… Implementation Recommendation -- Improve Promotional Efforts (page 12): Implementation Recommendation -- Utilize partnerships to maximize outreach (page 13) Recommendation -- support beyond reduced application fees Recommendation -- understand obstacles and provide assistance accordingly General Agreements (page 14) Aspects for Further Discussion (page 14) -- Metrics -- Evaluation criteria -- Other elements -- did we provide the right tools? -- Objectives of the ASP define -- How to provide locally available consulting resources -- How to improve the learning curve -- Making the business case -- How do we penalize applicants for gaming -- String contention resolution auction considerations -- any? Discussion: -- Not as much support for penalizing -- but do they get their deposit back? -- The way the process that we ended up with was interesting (in the JAS Group). Sometimes there wasn't close coordination between the recommendations of the JAS and what the Board did: the punishment of having the application cancelled was rather scary to people. While gaming does need to be looked at that may be too strong. -- One issue we never quite got settled is how to do financial evaluation based on local economics? Keeping that cultural awareness. -- Good to look at the whole disadvantage community, not just the region. -- Do we have enough on the financial understanding? -- What do we need for metrics? -- Don't know how effective it was and whether it met the meetings of the community. How do we get the right information to say that we did get it right this time? Draft report should ask the questions. -- Add to document: perhaps a request /required post process interview or survey for all applicants under this process? >From the chat: Maxim Alzoba (FAITID): who will decide if the attempt of gaming was undertaken? avri doria: the review process was arduous. so yeah, they would notice. avri doria: yeah, i co-chaired a group in ALAC that tried to pin it down, and we couldn't. seems to have been a panoply of reasons. Vanda Scartezini: @ avri- yes. not one answers fits all. depend on the country/ region.. Cheryl Langdon-Orr (CLO): perhaps a request /required post process interview or survey for all applicants under this process? 3. Review of potential recommendations for Accreditation Programs (RSP Program) (4.2.8) Aspects for Further Discussion/Not Yet Agreed Upon Ideas (page 23) 1. Grandfathering clause? -- Establish what we mean by the SLA. -- Under what circumstance would grandfathering not be allowed? -- One thing that makes a draft report engaging is if there are areas where questions are asked. No bad thing to have elements partially unresolved. -- Not sure we can fully trust the current implementation of SLAs. 2. PDT on RSP and the capacity of all of hte TLDs supported by the TLD. Re-approval on some time period based on the number of RSPs. Abbreviated pre-approval (standard set of services). 3. Process Controls (page 24) -- Re: process controls -- there may be more sophisticated ways of monitoring for future performance as well as past. -- Can we detect small signs of degradation? -- Could just say that the concept of process controls looking at future performance degradation were also discussed in addition to looking at past peformance, but didn't feel that this was an approach that could be used. 4. Transfer Process -- Re: Transfer process -- There should be a warning sign if fees are not met. Something needs to be added to the first paragraph: "Conditional on financial obligations being met." There also should be a security and stability qualifier, but not sure who would do that -- ICANN, others? 5. RSPs as EBEROs (page 25) -- Need some kind of performance or timing aspect. -- Key point that is missing: ICANN had an obligation under the 2012 program to set in place and manage and operate an EBERO program for a 5-year term, with the idea that at the end of the 5-year period that program would end. This section is predicated on the assumption that ICANN no longer operates an EBERO program. Need a preamble: "On the understanding that in the subsequent round ICANN will cease to provide an EBERO program for cost savings or other reasons..." Might also address this by moving some text around. -- It might be reasonable for new entrants to be required for a period of time to have a financial instrument in place to guarantee ongoing operations, but that doesn't speak to the removal of the EBERO program. Rationale for adding above (page 26) -- COI as a pain point. -- Opportunity for the RSPs to pool the risk and furnish EBERO services for all their clients at a relatively low cost. -- Whether the EBERO service "insurance" should be provided to all the RSP clients and provided at no addtional charge is complex and merits more discussion. -- This system should work because there is no "single point of failure". Areas of Non-Agreement (page 27) For public comment (page 27) >From the chat: Jim Prendergast: what is meant by "meets SLA"? is that 100% of the time? Maxim Alzoba (FAITID): SLA are in RA Maxim Alzoba (FAITID): s Maxim Alzoba (FAITID): and it is defined there Cheryl Langdon-Orr (CLO): agree on the benefits of including questions for community response Maxim Alzoba (FAITID): I was talking about .wed Maxim Alzoba (FAITID): where EBERO was reached due to not paying for backend services Maxim Alzoba (FAITID): that is why I was talking about the backends who were not the reason for EBERO Maxim Alzoba (FAITID): https://www.icann.org/news/announcement-2017-12-08-en Jonathan Robinson: So. Looks like process controls are a good idea but perhaps a little too ambiotous for now Vanda Scartezini: + 1 Jonathan Cheryl Langdon-Orr (CLO): security and stability must always be overriding principles Maxim Alzoba (FAITID): Have we seen yet EBERO costs for .WED? Jonathan Robinson: Thanks. I am not wedded to the preamble or formatting of the text. But, keen to ensure we don't add another layer of cost / overhead onto the industry. Maxim Alzoba (FAITID): NOTE: EBERO can be triggered without RSP's failure (for example not paying ICANN bills)

1 0

WT1 Agenda for Tuesday, February 20th -- 20:00 UTC
by Christa Taylor Feb. 19, 2018

Feb. 19, 2018

Dear All, The next call for the New gTLD Subsequent Procedures Sub Team – Track 1 - Overall Process/Support/Outreach Issue will take place on Tuesday, February 20th, 2018 at 20:00 UTC. The proposed agenda is as follows: 1. Welcome & Agenda Overview 2. SOIs 3. Review of potential recommendations for Support for Applicants from Developing Countries (4.2.14) 4. Review of potential recommendations for Accreditation Programs (RSP Program) (4.2.8) 5. Next Meeting 6. AOB We encourage and appreciate all members to review and comment on WT1’s deliberations and preliminary agreement working document: <https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_docume…> https://docs.google.com/document/d/1guiX3L0FQAd7ZpwYIJI4FdY3pv09u0EnHMAark8…. Cheers, Christa Christa Taylor, B. Tech, CPA, CMA, MBA Skype: christat13 <mailto:christa@dottba.com> christa(a)dottba.com <http://www.dottba.com/> www.dottba.com

1 0

RSP Program Implementation Aspects
by Kurt Pritz Feb. 13, 2018

Feb. 13, 2018

Hi Everyone: During the recent RSP discussion I made a comment that included three suggestions. After seeing the comments to some them, I am fleshing them out a bit in this email. I chose email because I did know exactly where or how to appropriately stick them into the document that Christa and Sara are shepherding. I think Jeff N’s idea that we have a section for “not-yet agreed-upon ideas” is where these might go. Of course, these are just my ideas with plenty of room for discussion. I. Process Controls a) The paragraph in the document could say: "In addition to demonstrated adequate past performance, the RSP will implement: internal process controls that monitor operations and indicate whether processes are degrading before SLAs are breached a rapid response mechanism in order to respond to new threats that are identified by reliable sources (where the RSPs could agree upon those sources and establish communications with them). "These measure would assure others that RSPs had measures in place to ensure ongoing competent performance.” b) Rationale for adding such a paragraph: The selection of RSPs should as much about ensuring future performance as it is about past performance. The terms “proven provider” or “pre-approved provider” sound a little like, “haven’t failed - yet.” Process controls detect process variances before SLAs are broken. The current plan to monitor TLDs against the SLAs will detect failures only after SLAs are broken, i.e., once their has been a failure already. That is too late. RSPs can avoid this scenario by putting their own process controls in place. Statistical process controls came into the forefront in the post-World War II industrial boom, first in the Japan (where they were introduced by an American, Edward Deming), and later the United States and elsewhere. This invention later gave rise to the 3-sigma, 6-sigma and black belt quality assurance designations. They were created to detect variances in a process before bad parts were made - so one could make corrections before having to throw out poor quality parts. II. Transfer Process a) The paragraph in the document could say: "The RSP Program must include a smoothly running transfer process. A Registry Operator must be able to freely transfer from one RSP to another (subject to the terms of the agreement signed) where both the gaining and losing RSP must cooperate fully in order to ensure a smooth and timely transition. RSPs that hinder transitions intentionally or not, should be excluded from the Program. “RSPs should combine to create a at least a set of principles, if not a transfer process, and present it to Registry Operators for advise.” b) Rationale for adding such a paragraph: During the policy discussions, one reason for creating an RSP Program was to ease the cost of transfer from RSP to another. Implicit in that is the need for the RSPs involved to cooperate in a way that does not create stability and security risks, nor risks to the Registry Operator business model. There are obvious parallels to be drawn with the Inter-Registrar Transfer Policy. In this case, I think the RSPs can develop a set of principles without undertaking a policy process, which can come later if need be. III. RSPs as EBEROs a) the paragraph in the document could say: “In addition to providing traditional technical services, RSPs joining the RSP Program will also provide Emergency Backend Registry Operator (EBERO) services for their Registry Operators. Significant aspects of this service are: Registry Operators using an RSP Program participant, will not be required to furnish a Continuing Operations Instrument. RSP Program members will provide this service to all Registry Operators at no additional charge, i.e., the costs are included into the standard RSP pricing model. Vertically integrated RSPs (i.e., RSPs that are also Registry Operators) will contract with another RSP to become an EBERO in the event that the RSP-Registry Operator entity fails.” b). Rationale for adding such a paragraph: The Continuing Operations Instrument is a demonstrable pain point and there s nearly universal agreement that an alternate should be found. The Continuing Operations Instrument does not translate well across different regions, creating difficulties for many Registry Operators. The Continuing Operations Instrument has turned out to be a significant drain on resources, impacting many business models. With the market developing the way it has, with relatively few RSPs serving nearly all the Registry Operators, there is the opportunity for the RSPs to pool the risk and furnish EBERO services for all their clients at relatively low cost. By participating in the Program, RSPs have demonstrated the capacity to easily provide EBERO services for a random failure. It seems that, if there s a failure, the RSP workload would actually decrease as the EBERO provides only five registry functions and, generally, the RSP would provide a Registry Operator with more functionality than required of the EBERO. Whether the EBERO Service “insurance” should be provided to all the RSP clients and provided at no additional charge is a complex issue and merits more discussion. Here is my thinking. Less risk, more affordable, more reliable: One policy reason for requiring all Registry Operators in an RSP to join in the EBERO service is that greater numbers create a greater risk pool, evening out the risk, making the program more affordable, and more reliable Lower RSP cost: If every RSP customer is in the EBERO program that will lower the RSPs cost per Registry Operator for maintaining the program Keep it simple and stable: If RSPs charge an additional fee for the EBERO service, Registry Operators will forum shop, creating a complex eco-system where Registry Operators are moving between EBERO providers and RSPs. This will create compliance tasks for ICANN - with increase ICANN costs for registries. If every Registry Operator is automatically signed on with their RSP for EBERO services, there is no compliance oversight required. Disadvantages to smaller players: In a market where vertically integrated RSPs can serve themselves without transfer cost and can offer lower pricing to larger Registry Operators, small Registry Operators might find themselves with a choice of high EBERO price or retaining the Continuing Operations Instrument. The EBERO is probably more important for smaller entities so we should not invent a pricing structure that could be bent to their disadvantage. Finally this system should work because there is no “single point of failure.” If the Registry Operator fails, the RSP EBERO takes over. If the RSP fails, the Registry Operators go find another RSP. One issue arises where the RSP is vertically integrated, i.e., operating one or more Registries. In that case there might be a simultaneous RSP / Registry Operator failure. I think (but am not sure) that RSPs might contract with one another or with an ICANN EBERO to provide back up. If you made it this far, I apologize. Way too long and pedantic. Thanks and best regards, Kurt

5 6

Recordings, attendance & AC chat from New gTLD Subsequent Procedures Sub Team Track 1 Overall Process/Support/Outreach Issue call on Tuesday, 06 February 2018
by Michelle DeSmyter Feb. 7, 2018

Feb. 7, 2018

Dear All, Please find the attendance and AC Chat of the call are attached to this email. The AC recording and Mp3 are listed below for the New gTLD Subsequent Procedures Sub Team - Track 1 - Overall Process/Support/Outreach Issue held on Tuesday, 06 February 2018 at 20:00 UTC. Mp3: https://audio.icann.org/gnso/gnso-new-gtld-subsequent-track1-06feb18-en.mp3 Adobe Connect recording: https://participate.icann.org/p7v80apu4e4/ The recordings of the calls are posted on the GNSO Master Calendar page: http://gnso.icann.org/en/group-activities/calendar[gnso.icann.org]<https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_en_group…> ** Please let me know if your name has been left off the list ** Mailing list archives: http://mm.icann.org/pipermail/gnso-newgtld-wg-wt1 Agenda Wiki page: https://community.icann.org/x/3ASfB Thank you. Kind regards, Michelle -------------------------------

1 0

Notes and Action Items Work Track 1 Sub Team Meeting 06 February2018
by Julie Hedlund Feb. 6, 2018

Feb. 6, 2018

Dear Work Track members, Please see below the notes from the meeting today. These high-level notes are designed to help WG members navigate through the content of the call and are not a substitute for the recording or transcript. See the chat transcript and recording at: https://community.icann.org/x/VAtyB. See the referenced document at: https://docs.google.com/document/d/1guiX3L0FQAd7ZpwYIJI4FdY3pv09u0EnHMAark8…. Kind regards, Julie Julie Hedlund, Policy Director Notes/Action Items from Work Track 1 Sub Team Meeting 06 February 2018: 1. SOI Updates: No Updates. 2. Review of potential recommendations for Accreditation Programs (RSP Program) (4.2.8) See the document at: https://docs.google.com/document/d/1guiX3L0FQAd7ZpwYIJI4FdY3pv09u0EnHMAark8…, page 19 -- Considered the policy question: was the repetitive, resource intentive technical evaluation and pre-delegation testing an interpretation of the rules -- a form of application rather than the fault with the rules themselves? -- General Agreements: More detail will be needed in this section. Discussion: -- Footnote on accreditation - why we moved away from this term in favor of RSP Pre-Approval. -- Pre-approval process: Said it would be largely consistent with pre-delegation testing, and only do that testing once. -- Add the areas where we don't have agreement, i.e., intent was to say that whatever testing we apply in the next round should be those requirements that are tested and evaluated as part of this pre-approval process. -- Discussion about grandfathering, but don't think we have agreement on that approach. Describe the concept. -- How does pre-approval work when you have one registry service provider with multiple applicants and multiple schedule A filing -- do they go through multiple pre-delegation testing. Good to get public input on this. -- Could be registries that have been pre-approved for a set of services. -- Beside pre-approval, there should be some requirement for monitoring or statistical process control before registries reach an SLA, and a rapid response to threats. -- There might be some assurances to registry operators when the want to transition from one back-end provider they goes smoothly, that there is a process in place where the losing RSP participates in the process. -- One service RSPs could be required to provide is EBERO. -- If an RSP has shown experience and meets SLA they should be given the presumption that they are capable of provide the service. -- If there are new requirements in the next round there may be a need for approval. >From the chat: Jim Prendergast: Im still not clear what the difference between accrediation and pre-approval are. An RSP still submits to testing by ICANN (or their designated 3rd party) in exchange for a designation (certified or pre-approved) How are they different? Jeff Neuman: Everyone felt that the terms accreditation implied signing up to a separate agreement Kurt Pritz: I dont like this footnote: “In the original charter, the term ”accreditation” was used as opposed to pre-approval. However, for the reasons discussed in the discussion section below, the terms “Accreditation” or “certification” were considered to be too politically charged and to many implied a number of elements which were unintended. After considerable debate, the terms “RSP Pre-Approval” or “RSP Program” were deemed less incendiary“ We should not turn away from an accreditation program for political reasons or because it is incendiary. We should state sound business / technical reasons for going away from accreditation and toward something else. Use of "political" and "incendiary" make s our reasoning sound less than sound. Jeff Neuman: This does not envision a new agreement Jim Prendergast: so the difference is a contract with ICANN? Jeff Neuman: @Kurt - I agree we should give other reasons. It was one of the things I wanted to add to the General Agreements section Jeff Neuman: Namely what the term accreditation implies (an agreement) Vanda Scartezini: Kurt, I beleive you right Kurt Pritz: Stop reading - just stick it in the record Jim Prendergast: not everyone is in adobe Christa Taylor: There was concern on the term 'accreditation' due to the implied certification/implications and the legalities around the diff parties Cheryl Langdon-Orr (CLO): lengthy discussion on the nomenclature indeed Jonathan Robinson: Agree with Jeff. We discussed this extensively Jonathan Robinson: @Jeff. That is an interesting point. Will there be added or different technical requirements? If so, these may reflect real-world experience from the current 2012 round Jeff Neuman: @Jonathan - I dont know Donna Austin, Neustar: I agree, that we have not reached any agreement on grandfathering. Jonathan Robinson: Not a question per se. More a recognition of the question to be determined. Jeff Neuman: I am just accounting for the possibility that there may be Jeff Neuman: That's why I dont want to just use the 2012 round as the base Jeff Neuman: @Jim - That is a great question to solicit public input on Jeff Neuman: in the initial report Jim Prendergast: I dont have ideas - thats sort of why I asked the question Jeff Neuman: @Jim - Neither do I (Thats why I punted back to you) :) Phil Buckingham: a technical audit each year going forward ? Jeff Neuman: I will note that the RySG has a document that has been going around but because it has not been approved by the SG it has not been submitted here yet. But some registries have made the point that if there are SLA breaches that those may be used against the pre-approval process. Again that is NOT a position of the SG, but an idea that was floated Jonathan Robinson: @Kurt. Current experience does appear to show that ongoing monitoring is important Jeff Neuman: @Kurt - Interesting - A pre-approved provider must agree to be an EBERO for any TLD that it supports Maxim Alzoba (FAITID): if the RO fails, TLD goes to an EBERO Ken Stubbs - Afilias: yes Maxim Alzoba (FAITID): and I am not sure there is a process for EBERO to be non-operational Kurt Pritz: If RO fails, the RSP is the EBERO 3. Review of potential recommendations for Support for Applicants from Developing Countries (4.2.14): Working Group members should review the document and provide feedback on the mailing list.

1 0

WT1 Agenda for Tuesday, 06 February at 20:00 UTC
by Sara Bockey Feb. 6, 2018

Feb. 6, 2018

Dear All, The next call for the New gTLD Subsequent Procedures Sub Team – Track 1 - Overall Process/Support/Outreach Issue will take place on Tuesday, 06 February 2018 at 20:00 UTC. The proposed agenda is as follows: 1. Welcome & Agenda Overview 2. SOIs 3. Review of potential recommendations for Accreditation Programs (RSP Program) (4.2.8) 4. Review of potential recommendations for Support for Applicants from Developing Countries (4.2.14) 5. Next Meeting 6. AOB Best regards, Sara sara bockey sr. policy manager | GoDaddy™ sbockey(a)godaddy.com<mailto:sbockey@godaddy.com> 480-366-3616 skype: sbockey This email message and any attachments hereto is intended for use only by the addressee(s) named herein and may contain confidential information. If you have received this email in error, please immediately notify the sender and permanently delete the original and any copy of this message and its attachments.

3 3