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@vlaw-dc.com]
Sent:
Friday, November 25, 2011 1:54 PM
To:
Marilyn Cade ; Ron Andruff ; sdelbianco@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
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@icann.org [mailto:owner-bc-gnso@icann.org] On Behalf Of Marilyn
Cade
Sent:
Friday, November 25, 2011 12:50 PM
To:
Ron Andruff ; sdelbianco@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 mechanisms.
Sent
via BlackBerry by AT&T
-----Original
Message-----
From:
Ron Andruff <randruff@rnapartners.com>
Date:
Fri, 25 Nov 2011 10:32:40
To:
<sdelbianco@netchoice.org>; <bc-gnso@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 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
* 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
+
1 212 481 2820 ext. 11
----------------
From:
owner-bc-gnso@icann.org [mailto:owner-bc-gnso@icann.org] On Behalf Of Steve
DelBianco
Sent:
Tuesday, November 22, 2011 7:06 PM
To:
'bc-GNSO@icann.org GNSO list'
Subject:
[bc-gnso] for expedited review: draft BC comment on registry proposal for
Continuity Operations Instrument (COI)
Per
discussion in
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