[Gnso-newgtld-wg-wt1] RSP Program Implementation Aspects

Fri Feb 9 01:34:09 UTC 2018

Kurt,

Many thanks for putting all this down for the group to mull on.

I haven't had time to catch up on the last WT1 call recording yet but I'd
say better to flesh out a lot, if not everything, then work to shorten,
remove redundancies etc., if any.

Justine

On 9 Feb 2018 7:44 am, "Kurt Pritz" <kurt at kjpritz.com> wrote:

> 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
>
>
> _______________________________________________
> Gnso-newgtld-wg-wt1 mailing list
> Gnso-newgtld-wg-wt1 at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg-wt1
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg-wt1/attachments/20180209/25b3c1c6/attachment-0001.html>