ICANN ICANN Email List Archives

[soac-newgtldapsup-wg]


<<< Chronological Index >>>    <<< Thread Index >>>

[soac-newgtldapsup-wg] Re: [Tdg-legal] Estimating the cost of continuity capacity

  • To: Michael Young <michael@xxxxxxxxxx>, "tdg-legal@xxxxxxxxx" <tdg-legal@xxxxxxxxx>, "soac-newgtldapsup-wg@xxxxxxxxx" <SOAC-newgtldapsup-wg@xxxxxxxxx>
  • Subject: [soac-newgtldapsup-wg] Re: [Tdg-legal] Estimating the cost of continuity capacity
  • From: Eric Brunner-Williams <ebw@xxxxxxxxxxxxxxxxxxxx>
  • Date: Wed, 09 Mar 2011 09:58:16 -0500


Again, thank you for your note.

As there are two application types, one of which, if its authors anticipate string contention, has a restrictive registration policy, I suspect that a common definition will result in a model of continuity cost which is less predictive than a per-type definition.

After all, the "statistically valid sample", to borrow from your prior note, must consist only of .com, and the continuity instrument cost for .com is irrelevant to new registry operations over at least the first decade, as the market share of our not very effective attempt at creating competition over the last decade painfully makes abundantly clear.

Assuming continuity entails allowing registrars to update DNS and contact data, 
a must to support domain abuse control activities and registrant's regular 
operations

This is an assumption, one which entry into "continuity" and the recent VI outcome challenge, as all registrar function can be accomplished by the registry's registrar function (a requirement for which could be added to the evaluation, replacing #28 or #35 are my picks o' the day).

But this assumption does bring up yet another issue.

Much of the informed VI discussion focused upon the "orphan" registry, the registry without registrars. What registrars are going to maintain a registry "in continuity" on their registrant facing properties? What could induce {GoDaddy, Enom, Tucows, NetSol} (GETN), with 50% of the gTLD registrar market share, to keep .pro or .aero?

One thing comes to mind. Bundles. The registrars will maintain those out-sourced-to-Platform-Operator-A inventories, as a group, where Platform Operator A offers inducements.

So is "continuity" ever going to occur where the registry function is outsourced to a multi-registry operator? It seems unlikely, and the trajectory from contracted-service-to-failure-to-owned of .name is a likely outcome, one which preserves a string in the IANA root, purchased at a cost of at least $185,000, for an ongoing operational cost of $25,000 recurring fee to ICANN, and an operational cost to Platform Operator A it has already completely sunk, and has no recurring cost component.

Returning to Jeff Neuman's request to bundle, he's far to timid. He could point out to ICANN Legal that "continuity" is not possible for NeuStar's stable of contractual and owned applications, when operationalized as registries using NeuStar's registry services platform, and so the proper dollar amount for all applications answering questions 23 to 44 with "See Platform Operator A through Z's statement of capabilties" is zero, and independent of Legal's take on the observation, the LOC / CAE funds will never cease to be the applicant's or its financing partner's asset.

[Restated, "continuity" is a cost imposed only upon independent applicants.]

Argue as we may, either ICANN Legal comes up with an unambiguous definition of the functional elements of "continuity" which the applicants must responsibly cost, or the applicants specify what "continuity" they propose, and the means to achieve that, and the evaluation process must responsibly evaluate the applicant's offer.

Eric

On 3/8/11 9:57 PM, Michael Young wrote:
Hi Eric, I think you are completely right about variability in defining 
continuing core operations. I am sure others have even further views of what 
that entails. My natural inclination is to try and derive a common definition, 
but as you pointed out there are some variations in even today's registry 
models. I expect there will be more extensive variations with NTLDs.

I see your point in trying to separate out the added cost of business logic and 
policy enforcement. My experience cost modeling concurs that's where most of 
the startup expense lies. Operating expense though is another calculation. 
Assuming continuity entails allowing registrars to update DNS and contact data, 
a must to support domain abuse control activities and registrant's regular 
operations, I am thinking you will still need some of the business logic and 
policy enforcement. A good example would be IDN enabled registries supporting 
resolving variants.

This is clearly a large topic and really could benefit from some focused 
discussion and clarification on certain points from staff.



Michael Young

M:647-289-1220

On 2011-03-08, at 20:38, Eric Brunner-Williams<ebw@xxxxxxxxxxxxxxxxxxxx>  wrote:

Thank you for your note.

While at CORE a problem I looked into was the incremental cost of
adding a namespace. While this issue was the cause of heartburn for
some, I looked at the incremental cost of another schema, even if
implemented on a separate instance of the database, and the
incremental cost of the whois/zonefile publication paths pushing a
separate feed, and the incremental cost of ...

I came up with bupkis. The dominant cost item is the namespace
specific features (or warts, depending on one's point of view) on the
business logic, and the EPP processing logic. Which, if ICANN Legal
(ICANN Legal, pick up the White Courtesy Phone) defines "continuity"
as the reasonable minimal functionality necessary to keep resolution,
whois, bulk access, ... running, BUT NOT new registrations, is a set
of functions, and costs, that can be ignored.

To this I add the cost of monthly reports. I know what the cost of
monthlies is, and my estimate of the cost of adding another monthly to
the workload of any platform supporting organization doing monthlies
is ... again, close to bupkis. The Staff presumption that it costs
$25k/yr to read registry monthlies is a conceit that could be
challenged for surrealism or ... but I don't care. I'm happy enough
that we got that number down from $75k/yr.

However, for a registry "in continuity", it is generous to allocate
$2k/mo to review the monthly report for February (available now) that
differs only in its expires (and perhaps a UDRP delete) from the same
report published 31 days previously. This is equivalent to saying that
one average West LA office admin hire is only capable of diffing two,
perhaps three, continuity reports, in the 160 hours of the average month.

My sole concern is correctly identifying the probable continuity costs
for linguistic and cultural registries like .cat, which started with
only a 2,000 euro marketing budget. I assume that if "continuity" is
triggered, the number of objects in the registry database is a small
multiple of 10 to the 5th.

I think it likely that you and I are solving different problems.

Eric


On 2/17/11 4:24 PM, Michael Young wrote:
Eric while I find this truly interesting, I feel it is based on a large
degree of dangerous assumptions.


1) It assumes, .CAT is by itself a statistically valid sample of the domain
registry space.  I believe using just .CAT fails the random requirement of
valid sample data.
2) It assumes that reads are not part of essential registry services, I
can't agree with that and I doubt any operator would.
3) It assumes that costs scale in a linear fashion, they do not.  Per unit
costs by service providers consistently drop in larger volumes.
4) It assumes common costs for different business models - again not the
case.

There are several other problems with doing this type of modelling in that
you are looking at a cost to carry versus a true breakeven.

In a full cost to carry model:

You have to do a projection of domains that will remain in the registry for
three years following the business failure point. To do so accurately means
you have to consider projected registration growth rates until the point of
failure and then project subsequent renewal rates following that. So in
effect you end up with a rolling conditional model. You will also want to
calculate a Net Present Value for the contingency fund - it only makes sense
to invest it in risk-free securities, since it can go forward for a full 6
years.  6 years comes from the fact the contingency must be in place for the
first three years of operation, and then if you fail just before the end of
three years, the funds have to cover cost for the next three years - 6 years
).

In short, each bidder will need to present their own contingency model that
is integrated with their financial section of their bid.

I also find renewals during the emergency transition period an interesting
problem.  So do you suspend expirations until regular registry (billing)
operations recommence?  Do you allow renewals and charge for them? Who
collects and keeps the renewal fees if the cost to carry the domain is
already paid for the next three year? If a new operator takes over the
failed NTLD within say, 12 months, does the remaining contingency fund
return to the bankruptcy officer for pay out the debtors?

While financial modeling is something I can speak to, I have other related
questions for the lawyers on this list,......

How viable is it that you can even set up a contingency fund that is truly
untouchable by creditors in the event of bankruptcy?

I would think, the order of priority it terms of claims would go something
like this (again I defer to the lawyers here):

1)Secured Debt Holders
2) Registrars (as the retailer) would have first claim on prepaid funds and
any applicable rebates amounts.
3) Service Providers for work completed.
4) Service Providers for contracts work not yet completed (Emergency
Registry Provider costs I would think fit into this point)
5) Shareholders

The more I think about this, the more and more like it seems like the
contingency fund  be a common insurance instrument, operated by a neutral
third party - versus 500 different contingency fund setups.

Michael Young

M:+1-647-289-1220


-----Original Message-----
From: Eric Brunner-Williams [mailto:ebw@xxxxxxxxxxxxxxxxxxxx]
Sent: February-17-11 2:47 PM
To: tdg-legal@xxxxxxxxx
Cc: soac-newgtldapsup-wg@xxxxxxxxx
Subject: [Tdg-legal] Estimating the cost of continuity capacity

TDG-Legal Colleagues,

I just looked over the January 2011 numbers for .cat.

The sum of all add, modify, or delete operations on all objects for the
month was 48012, slightly greater than the number of domains.

The definition of "object" in this registry includes domain objects, contact
object, and host objects.

I propose that we agree that as a estimating tool, that the sum of all
operations on all objects, is equal to the number of domain objects in the
registry.

This means that we ignore the (check + info) operations, .cat had
1,361,398 of these, the (check only) operations, .cat had an additional
1,147,927 of these, and the (info only) operations, .cat had an additional
213,471 of these. The reason we ignore these 2.7m transactions is that they
are non-essential to continuity operations.

These are also read-only operations, and on average complete in half the
time as add, modify and delete operations.

The reason we need not ignore the add operations is two part. First, we know
registry's growth rate and can factor out the add operations to a first
order. In the case of .cat the growth rate is 10k/year, or 1k/month with an
80% renewal rate. Second, the add, modify and delete operations are reported
as an aggregate, and the contribution of the add operations is less than a
quarter of all transactions.

I further propose that we agree that the operations are not highly clustered
in time, that they occur during 2000 hours of a 8760 hour year corresponding
to a 5 day work week of 8 hour days, and with uniform distribution within
those 2000 hours.

If you agree to these two proposals, we may define a continuity
transactional load in units of 10k domain registrations at the point of
transition to continuity.

(10k domain objects) x (12 months) = 120,000 transactions/year

120,000 / 2000 = 60 transactions/hour

I propose therefore a continuity transactional capacity definition of one
transaction/minute for a standard "unit" of 10k domain objects.

It is possible that registries with unlimited admission policies have
radically different transactional properties. Not wanting to apply data from
the application of a community-based ("sponsored" in the
2004 contractual form) admission policy to applications lacking that, or any
restriction on admission, I propose the 1t/min/unit apply to applications
designated as "community-based" in the pending evaluation.

If this is not an acceptable definition for continuity transactional
capacity, please let me know. Again "unit" here is 10k domains.

If we can agree to this, and if we assume that the transactions should be
completed in 3 seconds or less, for nearly all transactions, then the
continuity transactional capacity cost can be defined by the cost for
systems capable of completion of all i/o and computation associated with a
standard database and read/write operation in 3 seconds.

I will offer estimates on the cost of zone file generation, and name server
capacity following the same methodology, modulo the caveat above on
acceptable definition for continuity transactional capacity.

Eric
_______________________________________________
TDG-legal mailing list
TDG-legal@xxxxxxxxx
https://mm.icann.org/mailman/listinfo/tdg-legal




_______________________________________________
TDG-legal mailing list
TDG-legal@xxxxxxxxx
https://mm.icann.org/mailman/listinfo/tdg-legal







<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy