[Gnso-newgtld-wg-wt1] Actions/Discussion Notes: Work Track 1 Sub Team Meeting 16 May 2017

Tue May 16 17:04:37 UTC 2017

Dear Sub Team Members,

Please see below the action items and discussion notes captured by staff from the meeting on 16 May.  These high-level notes are designed to help Work Track Sub Team members navigate through the content of the call and are not a substitute for the recording.  Please also see the recording on the meetings page at: https://community.icann.org/display/NGSPP/Work+Track+1+Meetings.

Please note also that the slides referenced below are attached and for ease of reference chat excerpts are included below.  Please also see the link to the reference Google doc at: https://docs.google.com/document/d/1nWljRzRgDQgmSlSxyf7G6f2Dv7XDoD01D30KfWhoHNw/edit. 

Best,

Julie

Julie Hedlund, Policy Director

Actions/Discussion Notes:

RSP Program

See: https://docs.google.com/document/d/1nWljRzRgDQgmSlSxyf7G6f2Dv7XDoD01D30KfWhoHNw/edit and the attached slides.

-- General Comment: RSP work is going on in several places, such as Registry Stakeholder Group preparing a letter.  The PDP WG should take into consideration other work.  RySG is scheduled to meet on 17 May.

Document Purpose:

-- Include the question, "If not an RSP program are there other remedies that could address the problem?"

-- Question: Was the repetitive resource intensive technical evaluation and pre-delegation testing an interpretation of the rules -- a form of application rather than the fault with the rules themselves?

-- Perspective of a swap-out of an RSP discussion in RySG: Process developed by ICANN -- started a discussion on what could be done to improve the process.  Realized early on that the process was repetitive, but wasn't anticipated.

1. Security and stability of gTLDs must not be negatively impacted and preferable, improved.

-- There has been information released by ICANN that even existing registry providers are struggling.  Shouldn't assume that anyone who met the 2012 threshold should be grandfathered or pre-approved.

-- Helpful to understand why ICANN has not pulled the EBERO on those registries that haven't met SLAs.   Need to understand the level of the problem that has been identifed.

-- ICANN made a decision on its own that evoking EBERO may make more issues rather than less.  The presentation this past weekend was from the OCTO in Madrid -- slides on how many incidents there have been -- 32 of 37 registry operators have had an SLA breach.  See the slides at: https://www.icann.org/en/system/files/files/presentation-slam-13may17-en.pdf

-- This does raise the prospect of setting a minimum threshold as part of a form of accreditation.  Recommendations should seek to address the problems.  What are the current problems and what is being solved?  Is it performance issues?  Also linked to item number 5.

5. RSPs must be able to innovate and differentiate themselves

-- Speaks to the issue of a race to the bottom.

-- Comment that the base agreement that applies sets the core standard.

2. Efficiency in evaluation and pre-delegation for ICANN, applicants, and RSPs must be improved.

-- Re: "Coordination between ICANN and RSPs should be improved" assume this refers to communications?  Would ICANN only communicate with RSPs?  If RSP is not responding that would have an overall impact on the application and the applicant would be responsible.

-- We are looking at this based on what happened in the past and how can we improve it in the future.  RSPs would have an opportunity to become pre-approved prior to the opening of an application window -- something akin to addressing technical questions and pre-delegation testing.

-- In terms of coordination between ICANN and RSPs being improved -- that is happening in the context of the current situation.  ICANN had the relationship with the contracted party and the contracted had the relationship with the RSP.  No formal mechanism for ICANN to reach out directly to an RSP.

3. Evaluation and pre-delegation testing must be consistent, predictable, and to the extent possible, objective.

-- Understanding that there were three different technical advisers with JAS coordination with an attempt to ensure results were consistent.

4. The costs associated with the evaluation and testing of an RSP should be borne by the RSP as opposed to the Applicant where the Applicant and the RSP are not the same entity.

-- Add comments about grandfathering registries from 2012.

-- Standards are being discussed in Work Track 4.  We don't want to create barriers to entry.  Could have existing and new operators be held to a higher standard, but to not create additional barriers to entry that don't exist today.  These are two different discussions -- how the process is conducted versus what are the standards (discussed in Work Track 4).

-- Expressed in the original purpose.  Mitigate the duplicative work at the outset.  Important that we don't drift into a discussion of standards as these are being discussed in Work Track 4.

8. Pre-approval of RSPs could be done in such a way as to take into account the capacity of such RSPs, the type of TLDs they support and the services they provide.

-- Conversations about whether it's possible to do this -- the ability of a registry to scale without actually doing it.  Whether it's possible to assess whether a registry could manage X number of names, or if there is a distinction between types of TLDs.  Premise is that this may not be easy to do in a preparatory stage.  There are various elements that could result in an answer to this question.

-- Create some sort of formula or predicted number of names in the future, or methodology to consider that.  Expand that idea.

6. An RSP Program should be designed in such a manner so it does not increase ICANN's liability.

7. Applicants must have access to a list of Registry Service Providers and a list of the functional areas they have been pre-approved for through the RSP Program.

-- What do we mean by "functional areas" is that the different services registries provide?  Yes.

9. Applicants must not be required to select a "pre-approved" RSP, but shall be able to either propose providing its own registry services or selection a new RSP.  If that occurs, such new RSP must be evaluated prior to the ultimate selection of the Applicant to manage one or more specific TLDs.

10. How do we solve the issues of changing from one service provider to another service provider?

-- Need to add more to deal with this issue.

-- That is something that the RySG is looking at now and will hopefully be able to provide some guidance.  We are working with ICANN to understand how the process can be improved.

11. If an RSP Program is the agreed upon solution, do we have different categories of providers?

>From the chat:

Steve Chan: WT2 had asked questions about the EBERO in relation to registrant protections. Here is the response from GDD.

Steve Chan: Section 6 of Specification 10 of the Registry Agreement for new gTLDs provides emergency thresholds for the 5 critical registry functions. Per the Registry Agreement, reaching any one of these thresholds could trigger an EBERO event.

Steve Chan: ICANN monitors registries’ performance of these critical registry functions, and regularly engages with Registry Operators and Registry Service Providers when service outages occur. Not all services outages reach emergency thresholds. If emergency thresholds are reached, ICANN evaluates each individual case and make decisions regarding whether to trigger an EBERO event based on the unique circumstances.

Ashley Roberts: slides are here: https://www.icann.org/en/system/files/files/presentation-slam-13may17-en.pdf

Jessica Hooper (Verisign): Agree. This could lead to a race to the bottom by setting minimum standards rather than having providers strive for excellence in service. (third bullet point)

Jeff Neuman: @Jessica - How is setting SLAs in the agreements now any different than setting them in a pre-approval process? I am not sure why this would become a race to the bottom.  Can someone clarify that?

Kurt Pritz: @ Jeff. SLAs are sort of backward looking. Some registries will cut costs until there is a failure. Then it is too late. A pre-approved RSP might have forward-looking criteria that are intended to avoid failures such as statistical process controls and new threat identification and remediation.

Jeff Neuman: @kurt - then this is a problem with existing registries and RSPs already.  Its not something that is new.  Nor is it something that would be worse with a Pre-approval process.

VANDA SCARTEZINI: @kurt, looks you have a point  - agree with you comment

Jonathan Robinson (Afilias): Pre-approval to meet a minimum standard which seems to be demonstrably inadequate doesn't sound like it's moving in the direction of future security and stability.

VANDA SCARTEZINI: + 1 Jonathan

Trang Nguyen: @Jeff, there were 3 firms providing technical evaluation.

Donna Austin, Neustar: @Trang, but PDT is done by the same provider?

Sarah L Verisign: @Jeff I thought the RSP accreditation process was intended to make improvements to what we have today rather haan not make something that already exists without it "worse" - I dont see how that plays into security and stablity.  Sorry for beeing late to the meeting I only just joinned.

Trang Nguyen: @Donna, correct, PDT is performed by 1 vendor.

Jeff Neuman: @sarah = Sure, standards can be approved for future as well and apply retroactively to all providers.  If we think the standards are too low now (which I am not saying), then we can always through a policy that starts today amend the existing agreements to increase the SLAs for all.....and then apply that to the future applications

Jeff Neuman: I guess what I am saying is that there should not be additional barriers to entry in the future that do not exist today.

Ashley Roberts: Jonathan, if we think the standards in the current RA are insufficient then that is a different conversation. I believe that topic comes under the remit of WT4 (please correcct me if I'm wrong).. All we are talking about is at what stage and how many times we evaluate whether the RSP meets the required standards (whether they be the current standards or some otherwise agreed standards).

Cheryl Langdon-Orr (CLO): indeed it does not Jonathan, and an issue to be delt with,  no doubt... but it's an issue not a new issue with any proposed pre approval,  what is to me an opportunity is to possibly explore and enact mitigation or risk management of heading to a failure point,  to be tethered to any such recommendations, and that also could help avoid the same risk in existing standards...

Cheryl Langdon-Orr (CLO): yes Ashley far more clearly said...  sorry 🙏 not fully operational atm

VANDA SCARTEZINI: Ok got it Ashley. tks

Kurt Pritz: I think #4 is kind of irrelevant. If an RSP bears costs associated with its certification, those costs have to be passed on to registry operators somehow, either through a one-time charge or some rate. I think it is up to the RSP what they want to charge and then up to their customers if they want to pay that charge

Jeff Neuman: Kurt - I disagree.  This is costs to pay ICANN.  Not costs paid by Registry to RSP

Cheryl Langdon-Orr (CLO): Staff can we make sure we capture this standards issue,  chat extracts etc., and send it to our WT4 

Kurt Pritz: @ Jeff - lemme think about that. Maybe the Proposal should be edited a little.

Alan Greenberg: @Kurt, if testing is done ahead of time, there are no applicants at that point, only RSPs. If an RSP does not end up being used by any applicants, RSP is only entitty to bear costs.

  Jeff Neuman:ICANN collected approx $61,667 from each application (paid for by Registry Operators) to pay for evaluations.  A substantial portion of that was paid for technical evaluation.  That can be eliminated from the Registry Operator's application for the TLD with a pre-approval program

  Kurt Pritz:@Alan - but it passes those costs along at some point. If an RSP makes an initial investment, it has to recoup that investment

  Jeff Neuman:It can then charge RSPs to get "pre-approved" one time.

  Jeff Neuman:@Kurt - There is a big difference to pass through an evaluation cost incurred once divided by all its customers, then to be charged that evaluation costs 300 times (in the case of some RSPs) and pass those on to the ROs

  Emily Barabas:@Cheryl, notes, chat transcripts, and recordings for this call will be available here: https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_display_NGSPP_2017-2D05-2D16-2BNew-2BgTLD-2BSubsequent-2BProcedures-2BPDP-2BWork-2BTrack-2B1&d=DwIFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=QiF-05YzARosRvTYd84AB_UYInlydmFcjNmBM5XgySw&m=KT9yZegfV_4Os1sfXC6WRsBgN6zfUqk7Ifi2Lu7kbhU&s=suOciiSRhnh0225UI1AYC7e8QsdXu402U5rh5CQTXHU&e= . Once all documents are posted, we can share this link with WT4.

  Jeff Neuman:For example, if RSP Approval costs $50,000 (hypothetically), then dividing that one time charge amongst 300 registry operators is much different than passing through $50,000 to each of its ROs to be evaluated 300 times.

  Cheryl Langdon-Orr (CLO):thanks Emily,  I don't want any nexus points overlooked... 

  VANDA SCARTEZINI:donna's points in the doc cover up the point

Kurt Pritz:@Jeff : Won't the market deal with that? 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg-wt1/attachments/20170516/aa0b53b0/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Sub Pro Track 1 20170516v1.pdf
Type: application/pdf
Size: 201581 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg-wt1/attachments/20170516/aa0b53b0/SubProTrack120170516v1-0001.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4630 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg-wt1/attachments/20170516/aa0b53b0/smime-0001.p7s>