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

Ron Andruff randruff at rnapartners.com
Mon Nov 28 14:01:14 UTC 2011

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

*                    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


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,




Ronald N. Andruff

RNA Partners, Inc.





-----Original Message-----

From: Phil Corwin [mailto:psc at vlaw-dc.com] 

Sent: Friday, November 25, 2011 1:54 PM

To: Marilyn Cade ; Ron Andruff ; sdelbianco at netchoice.org ; 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





"Luck is the residue of design" -- Branch Rickey



-----Original Message-----

From: owner-bc-gnso at icann.org [mailto:owner-bc-gnso at icann.org] On Behalf Of
Marilyn Cade 

Sent: Friday, November 25, 2011 12:50 PM

To: Ron Andruff ; sdelbianco at netchoice.org ; 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

Sent via BlackBerry by AT&T


-----Original Message-----

From: Ron Andruff <randruff at rnapartners.com>

Date: Fri, 25 Nov 2011 10:32:40

To: <sdelbianco at netchoice.org>; <bc-gnso at icann.org>

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

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, 





Ronald N. Andruff



RNA Partners, Inc. 

220 Fifth Avenue

New York, New York 10001 

+ 1 212 481 2820 ext. 11






From: owner-bc-gnso at icann.org [mailto:owner-bc-gnso at icann.org] On Behalf Of
Steve DelBianco

Sent: Tuesday, November 22, 2011 7:06 PM

To: 'bc-GNSO at icann.org 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/bc-gnso/attachments/20111128/dc1dee76/attachment.html>

More information about the Bc-gnso mailing list