Re: [bc-gnso] for expedited review: draft BC comment on registry proposal for Continuity Operations Instrument (COI)

["Mike O'Connor" <mike@xxxxxxxxxx>]

this line of reasoning makes me uncomfortable -- coming from the BC.

i can see why a prospective registry-operator would want to minimize the 
capital cost of getting into the game -- but i don't see where the Business 
Constituency would have much motivation along that line.  

our credo tends to hew more towards security, stability, predictability, 
long-term viability.  i would think that good insurance/assurance programs like 
the alternatives Phil describes (thanks Phil) would be something that we'd want 
to applaud rather than fight… 

i think there's also a distinction to be made between the technical fail-over 
systems of a registry back-end provider and the *business* continuity of the 
registry that is contracting with them.  again, i would think we would tend to 
favor high standards -- to reduce the risks that come from marginal registry 
operators making imprudent decisions in the struggle to survive.   

just my 2 cents…

mikey

  


On Nov 28, 2011, at 8:01 AM, Ron Andruff wrote:

> Thanks for your input, Phil.  As always informed and measured. 
>  
> However, the issues that I am having difficulty with – in both the COI and 
> the COF – are:
>  
> ·                    both require an inordinate amount of capital be 
> ‘parked’; money that could otherwise by more usefully deployed by new gTLD 
> managers in developing and marketing their string to their potential 
> registrants; 
> ·                    tying up financial resources for a period of 3 years is 
> an inordinate amount of time considering that a failing registry can be 
> switched over to failover system in less than 24-48 hours, if appropriate 
> technical provisions are in place (i.e. prior to the new registry being 
> ‘turned on’ in the root); 
>  
> The key question, in our view, is the one ICANN notes in its request for 
> public comment post: Who should determine how much reserve must be set aside? 
> In my view, it should be the new registry applicant in conjunction with whom 
> they choose as their backend provider.  If an applicant selects an incumbent 
> backend provider, Verisign as an example, that applicant should be able to 
> choose the same failover system that Verisign has in place as its failover.  
> In such case, the user protection that ICANN is looking for is clearly 
> already in place and operational instantaneously; and the marginal cost, if 
> any at all, would be determined between the applicant and its provider.
>  
> If an applicant selects a non-incumbent provider, ICANN need only mandate 
> that backend provider to meet the same failover standards as incumbent 
> registries have in place.  ICANN should NOT be looking to new registry 
> applicants – which are effectively ‘marketing organizations’ that within 
> ICANN nomenclature are called ‘registry operators’ – but rather to those 
> entities that will, in point of fact, be managing the technological part of 
> the registry business, i.e., said third part backend operators.
>  
> As for winding down a failed registry in a controlled manner – which the real 
> issue ICANN should be addressing here – applicants should be responsible for 
> establishing such a plan with their backend registry operator under 
> to-be-established ICANN policy guidelines.
>  
> Finally, in this discussion one must also consider the fact that not one of 
> the registries that ‘run’ the Internet today have ever failed in the history 
> of ICANN.  And should a failure have occurred, the incumbent registry 
> operator’s own failover redundancy systems would have kicked in.  I 
> underscore that the word ‘registry’ should be understood as ‘backend registry 
> provider’.
>  
> In our view, it appears that ICANN is simply looking for another way:
>  
> ·                    to raise the capital investment required for new TLD 
> operators to yet a higher threshold to exclude large numbers of new potential 
> registries that do not have deep- pocket, brand TLD financial backing; or
> ·                    to develop yet another pool of applicant money that 
> ICANN will have sole discretion over spending when, and if, a registry 
> operator fails in their mission to market their product.
>  
> Neither case is acceptable, particularly when viewed in light of the fact 
> that ICANN has already earmarked USD 25,000 from each application fee to 
> cover sunk costs on the new TLD program. (Note that ICANN is a not-for-profit 
> organization that by legal structure must spend its full budget each year and 
> start the next year with a fresh slate as opposed to a for-profit corporation 
> whose shareholders would expect such investment recovery.)  In addition to 
> that recovery cost, an additional USD 60,000 is earmarked to a ‘risk fund’ 
> (read: law suit fund) to enable ICANN to fight battles such as the current 
> .XXX lawsuit.  Very few applicants will end up in ICANN related law suits, 
> but all pay to defend those few that do.  This is seriously flawed. 
>  
> So in summary, on top of USD 25,000 and USD 65,000, ICANN has created a COI 
> whereby each applicant will have to pony up USD1 million + (according to the 
> slides deck presented in Dakar), which ICANN will spend as it wishes in the 
> highly unlikely situation that a registry operator (‘marketing organization’) 
> ‘fails’ despite the fact that said registry’s end-users’ domain names will 
> continue to resolve without issue.
>  
> I am not a technical person, nor a lawyer, but I struggle to understand why 
> complicated instruments such as the COI or the COF are even being 
> contemplated when all backend service providers already have their own 
> redundancy systems in place and operational. 
>  
> For these reasons I propose the BC push back on both and replace them with an 
> insistence that every backend service provider meet a particular standard to 
> ensure that there is no impact on end-users irrespective of which domain name 
> they register and whether or not the front-end of those registries remain 
> operational.
>  
> In the interest of full disclosure, dotSport LLC, a company for which I am 
> president and CEO, is considering an application for a new TLD.
>  
> Kind regards,
>  
> RA
>  
> Ronald N. Andruff
> RNA Partners, Inc.
>  
>  
>  
>  
> -----Original Message-----
> From: Phil Corwin [mailto:psc@xxxxxxxxxxx]
> Sent: Friday, November 25, 2011 1:54 PM
> To: Marilyn Cade ; Ron Andruff ; sdelbianco@xxxxxxxxxxxxx ; Bc GNSO list
> Subject: RE: [bc-gnso] for expedited review: draft BC comment on registry 
> proposal for Continuity Operations Instrument (COI)
>  
> I appreciate the work that Jon has done on this draft and hope that these 
> additional comments are useful.
>  
> The COF proposal reminds me of deposit insurance for banks (pre-funded) as 
> well as state insurance funds (generally post-insolvency funded) -- but the 
> difference is that both are accompanied by rather substantial regulatory 
> regimes to manage the risk to the common fund, far beyond anything ICANN has 
> ever engaged in vis-à-vis registries, much less desirable in the DNS context. 
> A COF model basically has all registries paying into a common fund to be used 
> to extend operations for at least 3 years of a registry which either has a 
> flawed business model or is operated incompetently (and that is always 
> accompanied by moral hazard), while a COI model has each individual registry 
> purchasing a financial guarantee tailored to its own scope of operation (I am 
> neutral on when the COI fund size should be revealed -- but what I am 
> wondering is how will it be set, and will it be adjusted at regular intervals 
> post-launch to account for variations in domain registrations and other 
> profit/loss factors?).
>  
> Also, who is operating the failed registry for the 3-year minimum period (the 
> same management that steered it into the rocks), and is it wise to set a 
> minimum that's so long if annual losses are considerable? And what is the end 
> game for the registry at the end of the 3 years? In the bank and insurance 
> world, any regulatory intervention that triggers a hit on the insurance fund 
> is generally accompanied by very rapid takeover and merger of the failed 
> entity into a solvent and well-managed one.
>  
> So overall, while open to counter-arguments, I think I am leaning toward the 
> COI approach because it places the fiscal responsibility on each registry, 
> and that requires much less regulatory oversight than a pooled funds COF 
> approach -- but certainly agree that the COI instrument amount should be 
> flexible at the inception based on business model and anticipated 
> registrations, and then reviewed regularly post-launch for adequacy. COI also 
> seems preferable because, as the draft notes, it provides more registrant 
> protection, which is the main point of the exercise.
>  
> Philip S. Corwin, Founding Principal
> Virtualaw LLC
> 1155 F Street, NW
> Suite 1050
> Washington, DC 20004
> 202-559-8597/Direct
> 202-559-8750/Fax
> 202-255-6172/cell
>  
> "Luck is the residue of design" -- Branch Rickey
>  
>  
> -----Original Message-----
> From: owner-bc-gnso@xxxxxxxxx [mailto:owner-bc-gnso@xxxxxxxxx] On Behalf Of 
> Marilyn Cade
> Sent: Friday, November 25, 2011 12:50 PM
> To: Ron Andruff ; sdelbianco@xxxxxxxxxxxxx ; Bc GNSO list
> Subject: Re: [bc-gnso] for expedited review: draft BC comment on registry 
> proposal for Continuity Operations Instrument (COI)
>  
>  
> Will read this. I am having some trouble with how this wprks, but also think 
> that this may be an opportunity for our BC request for improvements for IPR - 
> if they can consider such a big change in this, why not still in ITR 
> mechanisms.
> Sent via BlackBerry by AT&T
>  
> -----Original Message-----
> From: Ron Andruff <randruff@xxxxxxxxxxxxxxx>
> Date: Fri, 25 Nov 2011 10:32:40
> To: <sdelbianco@xxxxxxxxxxxxx>; <bc-gnso@xxxxxxxxx>
> Subject: RE: [bc-gnso] for expedited review: draft BC comment on registry  
> proposal for Continuity Operations Instrument (COI)
>  
> Thanks to Steve and Jon for this first cut.  It is a shame that time is so 
> short because a considerable amount of work still needs to be done on this 
> topic over the coming few days.  I will bring some thoughts to this 
> discussion in a later post, but thought that the excerpt that Steve linked 
> out to would be a helpful start and have thus posted them below for member's 
> consideration.
> Public comment is requested concerning the recently received from the 
> proposal for Establishment of a Continued Operations Fund. This proposal 
> comes from the Registries Stakeholder Group (RySG) and is accompanied by an 
> addendum (Proposed Continuity Operations Instrument) produced by the Afilias 
> and PIR, supported by some other registries, registry applicants and other 
> interested parties.
> The RySG proposal offers an alternative approach to the existing Continuing 
> Operations Instrument that is part of the New gTLD Program. Here are some 
> questions that public comment respondents could consider regarding the RySG 
> alternative proposal as well as the existing continuing instrument model 
> offered by ICANN.
> 1. Considering ICANN's Mission, what is the appropriate role for ICANN to 
> create a fund or act as an insurer? Under which circumstances?
>   * Can the same end be accomplished through a third party?
>   * Will an insurance company underwrite this?
> 2. The current COI model outlined on the Applicant Guidebook (see: 
> http://newgtlds.icann.org/applicants/agb) is designed to provide some 
> safeguards regardless of the number of gTLD registries that fail.
>  
> For the existing COI model:
>   * There will be an incentive to underestimate the projected size of the new 
> registry, and therefore lower the cost of the COI to below what it should be 
> to protect registrants. How could this be addressed?
>  
> For the COF model:
>   * Who should determine how much reserve must be set aside?
>   * What criteria should be used to ensure sufficient funding and a mechanism 
> to provide registrant protections? 
> 1. In the estimates shown in the addendum (Proposed Continuity Operations 
> Instrument), what are the assumptions can be made in creating the basis for 
> the proposed fund?
> 2. How should the both the existing COI model and the newly proposed COF 
> model ensure that it appropriately meets the needs of multiple registries 
> sizes from small to large?
> 3. Will the allocation of costs need to be adjusted over time if new 
> registries enter the pool after the target balance is achieved? How can this 
> account for some level of predictability and fairness for all registries?
> 4. What appropriate level of internal resources should ICANN have for 
> collections, tracking of deposits and outlays from the fund?
> 5. What are the foreseeable challenges to move funds in timely manner to 
> various parties as required responding to emergency situations?
>  
> One comment I would leave with you all is that it should be well-noted that 
> ICANN already extracts USD 60,000 from each applicant as a risk fee without 
> detailed explanation as to its use.  Most applicants understand that this 
> money will be used by ICANN legal to fight lawsuits that may arise from the 
> new gTLD program, but find it an uncomfortable "tax" which will probably be 
> used to fight battles that are not of their making.  Food for thought.
>  
> Kind regards,
>  
> RA
>  
>  
> Ronald N. Andruff
> President
>  
> RNA Partners, Inc.
> 220 Fifth Avenue
> New York, New York 10001
> + 1 212 481 2820 ext. 11
>  
>  
>  
> ----------------
>  
> From: owner-bc-gnso@xxxxxxxxx [mailto:owner-bc-gnso@xxxxxxxxx] On Behalf Of 
> Steve DelBianco
> Sent: Tuesday, November 22, 2011 7:06 PM
> To: 'bc-GNSO@xxxxxxxxx GNSO list'
> Subject: [bc-gnso] for expedited review: draft BC comment on registry 
> proposal for Continuity Operations Instrument (COI)
>  
>  
>  
>  
>  
> Per discussion in Dakar and on our 10-Nov member call, here is a draft of BC 
> comments on the a proposed alternative to the for Continuity Operations 
> Instrument in the new gTLD Program.
>  
>  
>  
> Jon Nevett prepared this draft. 
>  
>  
>  
>  
>  
> This comment period and docs are described here 
> <https://www.icann.org/en/public-comment/rysg-proposal-cof-17oct11-en.htm> . 
>  
>  
>  
> These comments are due 2-Dec, giving us 10 days for review and approval.   
> This is less than the 14-day period required in our charter, so I am 
> requesting an expedited review period.  If any member has substantive 
> objections to the expedited review, we can go to 14 days and submit our 
> comments after the ICANN due date.
>  
>  
>  
> All BC members are invited to suggest edits.     Please use track changes and 
> circulate to BC list.   
>  
>  
>  
> Thanks again to Jon for taking the lead on this.
>  
>  
>  
>  
>  
> Steve DelBianco
>  
> vice chair for policy coordination, BC
>  
>  
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1411 / Virus Database: 2092/4038 - Release Date: 11/25/11

- - - - - - - - -
phone   651-647-6109  
fax             866-280-2356  
web     http://www.haven2.com
handle  OConnorStP (ID for public places like Twitter, Facebook, Google, etc.)