[NA-Discuss] On the cost of application, and Joint Application Support related
ebw at abenaki.wabanaki.net
Mon Apr 4 13:14:53 UTC 2011
On 4/4/11 4:10 AM, Patrick Vande Walle wrote:
> imposing DNSSEC from day one on new gTLDs is *also* a competition issue
Of course it is a competition policy issue.
Synchronous mass creation can only be accomplished where one or more
critical resources have limited allocation regimes, but significant
reserve capacity in one or a few actors, through monopoly, or oligopoly.
Employer independent DNSSEC experience is limited. Verisign, Afilias,
NeuStar and CORE have DNSSEC experience and excess capacity.
In the 2000 round, all but one of .aero, .biz, .coop, .info, .museum,
.name and .pro arose from separate capitalizations, separate technical
capacities, and separate staffs. Only .name has been acquired by the
incumbent monopoly operator, a competition policy error on ICANN's part.
Each requirement in excess of the 2000 and 2004 requirements has the
effect, individually in the case of the empty zone signing requirement
with key management cost prior to first production resolution, and in
the aggregate in other cases, of restricting the structural choices of
The imposition of synchronous mass requirements can only result in
significantly distinct outcome, much more likely to favor incumbents
with reserve capacity over new entrants lacking that capacity, than
the iterative imposition of the same requirements, where capacity is
not some neutral condition or consequence of merit, but the likely
consequence of mere possession of a prior grant of franchise.
The impossibility of the ALAC advancing a coherent position which
advances the public interest is demonstrated by individuals who are
overtly destructive to applicants those individuals deem lacking the
capacity to meet a requirement which they advocate and cannot justify
except through appeal to externalities, and by individuals who are
covertly destructive to applicants through the advocacy of regimes of
> I hope this answers your concerns.
Only in part. The indifference to applicant cost, and to operational
utility, of a At Large RO contributor, and the non-responsiveness of
that contributor, as a contributor to an At Large consensus based
activity, raise both substance and process issues.
Make no mistake, when I observed cache poisoning demonstrated in a
small meeting of DNS people at the Dublin IETF meeting in under 3
seconds, I fully understood that the economics of attack had changed.
However, attack has not become "free" and therefore not pervasive, and
rational attackers rationally target, and zones for which less
financial, or political benefit exists have less risk.
Zones which exist for the purposes of sustained financial transaction
are worth signing. Zones which exist for the purposes of Pay Per Click
advertizing inventory disposal are not worth signing. Signing .mil may
have some operational utility. The operational utility of signing
.museum, other than the benefit to the community of a first gTLD
implementer experience(*) is far more conjectural.
It is less than sufficient to comment, when the DAG has "DNSSEC is
mandatory to implement", that "operators are encouraged to deploy
DNSSEC from day one". The correct comment is "advised only when the
utility of zone signing and key management justifies the cost, as with
all other engineering choices".
The star above is intended to draw attention to another inherent
failure of synchronous mass requirements. The operational experience
of each registry informs not only its participants, but informs any
successors. As one wag put it, "time is nature's way of ensuring that
everything doesn't happen at once". The model Staff has chosen, and
several At Large participants advocate as well, a large cohort of
simultaneous events, to prevent a "first in market" effect, ensures
that no experience, including experience resulting in failure, can be
known to any members of the cohort.
Finding "no first in market" to be a greater public interest than the
public interest in empirical decision making is peculiar.
More information about the NA-Discuss