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

[Eric Brunner-Williams <ebw@xxxxxxxxxxxxxxxxxxxx>]

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