Re: Summary of the Impact of Root Zone Scaling

[Eric Brunner-Williams <ebw@xxxxxxxxxxxxxxxxxxxx>]

Karla,

I've commented during the public comments periods for prior iterations 
of the root scaling studies. Here I'm just dealing with the text as-is.
1. There is some boosterism that detracts from the report.

It is not true, or at least not "safe to say" that "more change has 
occurred in the last 5 or 6 years than has occurred since the DNS was 
first deployed."
1032 introduced iso3166 and expanded the root zone significantly.
The entire NIC contract was moved from SRI to the precursor of NSI 
(which didn't work as well as expected for the better part of a year). 
The operational .org registry was redelgated. The operational .net 
registry was not, unfortunately. Rapid update was introduced. Other 
changes before v6 and/or DNSSEC have taken place.
2. The boosterism is not limited to how important the rate of change 
of the DNS is, and by implication, how important ICANN is, but extends 
to the repeated use of the phrase "senior ICANN staff". We all know 
that ICANN has little depth in its technical staff, and there is very 
little technical staff left once "senior" or "junior" staff is 
subtracted from the whole.
The "senoiritis" pops up in several places in pages 3, 4 and 5, and 
with the exception of David, now Elise, and Barbara and Richard, and 
recently Joe, the comings and goings of "senior ICANN staff" are 
irrelevant to the issue, as the issue is the scaling properties of the 
root server system, and outside of those few individuals, no one at 
ICANN, senior or junior, has the competency to contribute to this 
specific issue.
3. At the middle of page 6, at February 2008, the 1k/yr number is 
introduced "derived from estimates of gTLD processing times." The 
readers who were not involved in the prior work may not grasp that the 
"processing" referred to, the "bandwidth" of the root change 
management system, is the number of contracts Corporate Counsel 
estimates that it can process, using a single standard contract and 
significant augmentation of the legal department's work capacity 
through outsourcing.
This is an important detail that informs the rest of the study. We are 
describing the time rate of change of a system, not of change 
management software acting in a continuous process of editing the IANA 
root zone file, with or without human review of root-altering change, 
but of the projected contract review rate. This figure has no other 
basis for being an tool for estimation of the scaling properties of, 
or limitations on the root change management system.
I suggest spelling that out so that readers new to the issue will know 
where the 1k/yr boggie comes from.
4. At page 7 and subsequent there is an important observation that the 
"... less robust IPv6 network infrastructure ... IPv6 queries and/or 
responses may be lost more frequently than with IPv4 ..."
Yet we still have IPv6 as mandatory to implement (even if regionally 
useless or even negatively useful) for all applicants in the current DAG.
We know it doesn't work as well for the A-M.root-servers.net 
operators, who sit on more than adequately provisioned L2 and raised 
floor infrastructures, as IPv4, and we know that it really doesn't 
work as well for just about everywhere else. Yet we're making it 
mandatory.
Worse, we know the metrics will suck, yet the numbers in the DAG don't 
reflect that certain knowledge.
I suggest making v6 optional rather than mandatory, for new gTLD 
applicants, as it is for root-servers.net operators, and all current 
TLD operators. Getting to v6 is so important that ICANN should not 
compromise the future by making it mandatory prematurely.
5. The discussion of IDNs should end at the end of para 1 on page 8. 
The display difficulties, at ICANN or at some unprepared registrars 
are simply irrelevant to the scaling issue. There is no room for the 
covert insertion of "LEOs and trademark portfolio managers can't parse 
IDNs in WHOIS data, oh joy to the criminal classes" in a report on 
scaling.
6. Also on page 8, in the para before the section on IDNs, there is an 
unfortunate comparison of ICANN root management processes and systems 
and Verisign root management processes and systems, in the discussion 
of quad-A resource records. The reason this comparison or likening is 
unfortunate is because it suggests a parity or equivalence between the 
two that simply doesn't exist. ICANN does some bookkeeping and makes 
requests, Verisign operationalizes every change requested, generates 
the signed zones, and publishes the signed zones. ICANN is not the 
author of changes, nor the implementor of changes to the IANA root, 
the resources and responsibilities are not so similar as to make the 
implied comparison meaningful.
As the para concludes, there is no operational or scaling issue in 
quad-A resource records, so the para could be removed, and the 
gratuitous adjacent-therefore-alike error removed as well.
What is missing from the paper has been missing all along, as I've 
commented previously. We are not simply concerned with an automated 
editing system which may monotonically increase the size of the IANA 
root through an endless sequence of textual deltas, but with one or 
more sets of independent, highly sophisticated, authorized to halt the 
process and delete deltas human beings. It really doesn't matter if 
Corporate Counsel or the outsourced legal service bureau has a bad day 
doing contract approval, there are no time critical consequences. 
There are time critical consequences when an incorrect change set to 
the IANA root is published.
Additionally, we know since the .C varient of Conficker that name 
spaces are a resource for the authors of distributed systems needing 
rendezvous points, and the "call the IANA contacts list" came very 
close to failure in March, 2009, when the "all hands" problem was 
o(100). Fundamentally, this study proposes that future "all hands", 
waking up o(1000) times the number of years since 2012, requires no 
operational change or preparedness.
I think those two are significant defects in the RZS.

Eric Brunner-Williams
In a personal capacity