Thank you, Kurt, for taking the time to put this together.  I’ve found a place for it in the google doc so that others can easily review comment on it along with a few other items that need further discussion.

Thanks again and have a great weekend.

Sara

sara bockey

sr. policy manager | GoDaddy^™

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.

From: Gnso-newgtld-wg-wt1 <gnso-newgtld-wg-wt1-bounces@icann.org> on behalf of Kurt Pritz <kurt@kjpritz.com>
Date: Thursday, February 8, 2018 at 4:44 PM
To: "gnso-newgtld-wg-wt1@icann.org" <gnso-newgtld-wg-wt1@icann.org>
Subject: [Gnso-newgtld-wg-wt1] RSP Program Implementation Aspects

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