Re: Summary of the Impact of Root Zone Scaling
- To: root-zone-scaling-impact@xxxxxxxxx
- Subject: Re: Summary of the Impact of Root Zone Scaling
- From: Eric Brunner-Williams <ebw@xxxxxxxxxxxxxxxxxxxx>
- Date: Fri, 05 Nov 2010 20:40:52 -0400
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
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
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
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
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
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.
In a personal capacity