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

[Steve DelBianco <sdelbianco@xxxxxxxxxxxxx>]

Very thoughtful comments, Ron.   Though you go well beyond the scope of this 
public comment, which is to assess the alternative method proposed by the 
registries.    Given the shortened review time, I don't think we can ask our 
members to assess and approve your more extensive remarks.

Suggestion:  In your own capacity, why don't you submit the comments you've 
drafted below.

The BC draft comments are supportive of you in so far as we are not endorsing 
the alternative method.

Jon Nevett: can you extract anything from Ron and Phil's remarks (below) that 
is within the scope of evaluating the registry alternative for a CO Fund?   
You'd need to circulate a draft 2 by Wednesday, please.

Thanks to all for your contributions!

--Steve



From: Ronald Andruff <randruff@xxxxxxxxxxxxxxx<mailto:randruff@xxxxxxxxxxxxxxx>>
Organization: RNA Partners
Date: Mon, 28 Nov 2011 09:01:14 -0500
To: 'Phil Corwin' <psc@xxxxxxxxxxx<mailto:psc@xxxxxxxxxxx>>, Marilyn Cade 
<marilynscade@xxxxxxxxxxx<mailto:marilynscade@xxxxxxxxxxx>>, Steve DelBianco 
<sdelbianco@xxxxxxxxxxxxx<mailto:sdelbianco@xxxxxxxxxxxxx>>, 'Bc GNSO list ' 
<bc-gnso@xxxxxxxxx<mailto:bc-gnso@xxxxxxxxx>>
Subject: RE: [bc-gnso] for expedited review: draft BC comment on registry 
proposal for Continuity Operations Instrument (COI)


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 
publiccomment 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 
thatbackend 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 thereal 
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 
thehighly 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<mailto: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 
extendoperations 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 onwhen 
the COI fund size should be revealed -- but what I am wondering is howwill it 
be set, and will it be adjusted at regular intervals post-launch toaccount 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 
minimumthat'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> 
[mailto:owner-bc-gnso@xxxxxxxxx] On Behalf Of Marilyn Cade

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

To: Ron Andruff ; sdelbianco@xxxxxxxxxxxxx<mailto: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 - 
ifthey 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<mailto:randruff@xxxxxxxxxxxxxxx>>

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

To: <sdelbianco@xxxxxxxxxxxxx<mailto:sdelbianco@xxxxxxxxxxxxx>>; 
<bc-gnso@xxxxxxxxx<mailto: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 
forEstablishment 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 
newregistry, 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 
modelensure 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 
moneywill 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> 
[mailto:owner-bc-gnso@xxxxxxxxx] On Behalf Of Steve DelBianco

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

To: 'bc-GNSO@xxxxxxxxx<mailto:'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 aproposed alternative to the for Continuity Operations 
Instrument in the newgTLD 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