Technical Comments on Transition to Delegation

[Eric Brunner-Williams <ebw@xxxxxxxxxxxxxxxxxxxx>]

CORE welcomes the additions made to the Draft gTLD Agreement to take 
into account the specifics of transition to delegation.
Module 5: Transition to Delegation

5.1 Registry Agreement

1. In 5.1 there is "... it is important to note that the agreement 
referred to above does not constitute a formal position by ICANN and 
has not been approved by the ICANN Board of Directors. The agreement 
is set out in draft form for review and community discussion purposes 
and as a means to improve the effectiveness of the agreement ..."
CORE urges the development of agreements that address the specific 
variations of current application types (Community-based, Standard), 
and future application types.
One size fits all is more likely to adversely affect applicants 
submitting Community-based type applications than applicants 
submitting Standard type applications.
One size fits all is more likely to adversely affect applications made 
by non-profit entities than applications made by for-profit entities.
One size fits all is more likely to adversely affect applications for 
strings, with the associated registration policies, in non-Latin 
Scripts, and decorated Latin Scripts than applications for strings in 
Latin Scripts, with the associated absence of registration policy.
2. The reference in 5.1 (page 186 of 312) to the applicants ability to 
fund continued operations (continued operations instrument, defined in 
Attachment to Module 2 at A-2 (page 92 of 312), and further referenced 
in the Registry Agreement at page 2 (page 200 or 312), is improved by 
the insertion of "critical" and the substitution of "functions" for 
"operations".
This allows us to discuss what functions of the registry are critical, 
in the context of a priori demonstrations of funding, and so in the 
possible event of revenue shortfall, or outright failure.
CORE offers a minimum definition for those critical functions:

1. continued generation and publication of the zone file, sufficient 
to prevent expiry.
2. continued existence of authoritative resolvers for the zone, 
sufficient to meet reasonable best-effort resolution by registrants 
and third-party resolvers.
3. continued ability to perform add/mod/del operations, sufficient to 
meet the reasonable best-effort needs of registrants, and third-party 
rights holders under the DRP/URS or other means of rights enforcement 
applicable.
4. continued generation and deposit of registry escrow data.

CORE points out that for each one thousand domains registered, the 
requirement for renewal is three transactions per day, and a 
reasonable upper bound for all add/mod/del activity is ten 
transactions for thousand domains per day. A registry in need of 
continued function of size 40,000 domains could safely be served by a 
platform capable of one complete database transaction per minute, 
assuming an 8 hour work day. Commodity server quality systems offer 
orders of magnitude performance.
In sum, the continuity activity is a minimal capital reserve element 
and care should be taken to ensure that unnecessary cost is created by 
assuming that applicants targeting six figures or less in their first 
contract period should offer capital reserves sufficient to meet the 
continuity activity of applicants targeting seven figures or more in 
their first contract period.
CORE has determined that the continuity activity cost is sufficiently 
minimal that it is cheaper for CORE to assume the cost for applicants 
using its Registry Services Platform, than to itemize this cost.
CORE suggests that where applicants are making use of shared services 
or pre-existing registry services providers (and here we point out 
that the Registry Services Provider Certification program, announced 
[1] and abandoned for undisclosed "business reasons" [2] by Staff last 
year, provides a useful vehicle for resolving just this, and related 
issues), the same analysis is likely to hold.
Finally, turning to the distinction between "operations" and 
"function", this beneficial change allows the function to be operated 
by parties other than the hypothetically fail(ing,ed) Registry 
Operator, e.g., by the Registry Service Provider, if one is in place 
prior to the point where continuity function is necessary, or by one 
that accepts the liability for the benefit of the registrants, and ICANN.
CORE recommends to ICANN that it simply make commercially reasonable 
estimates of the reasonable minimal function cost, in the existing 
environment where authoritative name service is often operated at no 
cost, and other "disaster" services may be offered at actual cost, 
particularly in the non-commercial community, and publish that number 
for further comment.
[1] http://www.icann.org/en/announcements/announcement-2-31jan08.htm
[2] http://www.icann.org/en/announcements/announcement-08aug08-en.htm


Module 5.2 Pre-Delegation Testing

Introduced in this version of the DAG is a discretionary right for 
ICANN to conduct audit of an applicant's self-certifiation, at the 
services delivery point (new text) or elsewhere as determined by ICANN.
Auditing of self-certification is desirable, however it probably isn't 
very helpful to the applicant, or reasonable, to specify that the 
audit will be performed in Low Earth Orbit. For applicants who's 
services delivery point is in Africa, Asia, South America, and even 
Europe, participating in the conduct of an audit function in North 
America is only slightly less onerous than participating in the 
conduct of an audit function in Low Earth Orbit.
CORE recommends that ICANN identify regional venues for off-site audit 
function, and commit to something less arbitrary that "at ICANN's 
discretion".
At 5-3 (page 188 of 312) there is a blanket requirement that all zones 
be signed at test time.
The subject has been discussed on the 
dnssec-deployment@xxxxxxxxxxxxxxxxxxxxx mailing list.
Where the admission control policy to a name space is equivalent to 
the admission control policies we have a decade of experience with, 
implemented by .aero, .coop, .museum, and since 2004, .cat, and where 
there is little "economic activity" by the zone's registrants, but 
rather cultural and linguistic activities, the value proposition of 
making a proof assertion about the existence or correctness of any 
entry in the zone is absent.
The uniformity of this requirement presents several issues which harm 
the general proposition that DNSSEC is both necessary and correct:
1. It is imposed while existing gTLD registries have no affirmative 
duty to sign their zones, though several have,
2. It is imposed while the overwhelming majority of the IANA anchored 
name spaces are not, and are not known to be even planning, signing 
their respective zones,
3. It fails, ab initio, to distinguish between the value of signing a 
zone operated as a platform for financial services, e.g., the hoary 
old example of a ".bank" TLD, from the value of signing a zone 
operated as a platform for non-financial services, e.g., the equally 
hoary old example of a ".vanity" TLD.
In the limit, assume an application with no registrants (the subject 
of the ".brand" discussion, elsewhere), and no registrars (ditto), for 
which only the names in the name space arise from a reserved names 
list, which may in theory be of size zero, is the invariance of the 
claim credible?
CORE observes that DNSSEC is important to the stability and security 
of the DNS, but its utility for a leaf zone ten levels down a 
delegation tree is distinguishable from its utility for the IANA root. 
Similarly, the utility of signing a zone is not an invariant, just as 
the utility of the zone, signed or unsigned, is not an invariant.
CORE recommends that this requirement be removed and ICANN's approach 
to zone managers participation in zone signing be reviewed as an 
optional activity, and should a High Security TLD program arise from 
the activities of the HSTLD AG, that zone signing mandates be located 
there, rather than in the general requirement for every applicant, 
without exception.
CORE also recommends that ICANN demonstrate that this is not a 
recurring annual cost to the applicant comparable to the one-time cost 
of submitting an application, when all skills acquisition and key 
management staffing costs are correctly accounted.

At 5-3 (page 188 of 312) there is the new discretionary "ICANN may 
request the applicant to complete load tests considering an aggregated 
load where a single entity is performing registry services for 
multiple TLDs."
This is not necessarily incorrect, and in other fora CORE has made 
just this point, that applications may share registry services 
providers, and that absent any other mechanism for the provider, and 
the applicants, and ICANN, to know if the provider is capable of 
offering shared services, aggregated realistic testing is appropriate.
However, the realism of the load is one area where details would be 
helpful, as applicants attempting to serve six figures of registrants 
have distinct projected realistic load profiles than applicants 
attempting to serve seven and eight figures of registrants.
CORE recommends that ICANN posit one or more shared registry capacity 
profiles for shared operator capacity planning profiles, and point to 
the add/mod/del and info/check statistics for the .cat registry for 
June, 2010 as a starting point for Community-based applicants.
CORE also takes this opportunity to point to another area of 
application evaluation management that could be simplified if the 
Backend Registry Certification is available in the first round, and 
offers that a program to create a Backend Registry Certification (BRC) 
could be accomplished in less time than both the projected lead time 
to application availability, and consume less resources than its 
absence during the evaluation period.
CORE appreciates the clarification that upon successful completion of 
all tests, the request for delegation need not be approved by the 
ICANN Board of Directors. We think this will help retain the technical 
capabilities focus of the post-contract, pre-delegation work by the 
applicant, its providers, if any, and Staff.

5.2.2 Test Elements: DNS Infrastructure

We appreciate the protocol independence clarification, and the 
additional clarity of language relating to UDP and TCP tests and the 
test harness, e.g., "within the applicant's DNS infrastructure ... 
from a network topology point of view".
CORE vigorously applauds the removal of IPv6 as a requirement. The 
requirement is generally good, but in specific instances, quite bad.
The removal of this "apple pie" requirement is a tremendous 
improvement in ICANN's conception of what services really are 
fundamental, and what are desirable. Please reconsider also the 
unscoped requirement for DNSSEC as another uncritical "apple pie" 
requirement, which is generally good, but in specific instances, quite 
bad.
5.2.3 Test Elements: Registry Systems

WHOIS support - at 5-7 (page 191 of 312) there is a surviving 
reference to IPv6. This could be cleaned up, and I note in passing 
that the port 80 for whois via HTTP should be specified. It shouldn't 
be applicant picks the port and everyone else guesses the secret.
There appears to be another error in the method of testing WHOIS 
provisioning, as the points at which ICANN will remotely test this are 
unspecified. Compare this with the discussion of DNS testing 
methodology in 5.2.2, e.g., the phrasing "within the applicant's DNS 
infrastructure ... from a network topology point of view".
EPP support - CORE applauds the size 0 (empty) to the expected size 
after one year of operation, as determined by applicant, as a model 
for similar attempts to characterize capacity planning and provisioning.
IPv6 support - this could be conditional in sentence 1, rather than in 
in sentence 2, for clarity of the actual requirement.
DNSSEC support - this section should be removed, as urged earlier in 
this comment. The proposed test is a good one, but its unconditional 
application to all applicants for all types of registries and all 
business models is problematic.
Escrow deposit - this section offers some interesting new ideas, in 
particular the 24 hour reconstruction from escrow data of a registry.
CORE recommends, particularly in light of what was actually necessary 
to maintain the .ht zone six months ago, that ICANN identify the 
registry functions and the time horizons for each to create 
transparent registry fail-over, as 24 hours is not the correct answer.
5.4 Ongoing Operations

5.4.1 What is Expected of a Registry Operator

CORE applauds ICANN mentioning RFC 1591, however, we urge ICANN to 
make reference not merely to Section 3, The Administration of 
Delegated Domains, part 5, but also the language in Sections 1, 2, 3 
and 4. The obligations of a registry operator go beyond doing a 
satisfactory job.
At 5-11 (page 195 of 318) is significant new text. CORE favors rights 
protection mechanisms present at launch, and during post-launch 
operations. The mechanisms ICANN proposes should not prevent the 
applicant from forming Community-based registration eligibility 
criteria which obviate the necessity of either the launch, or 
post-launch mechanisms ICANN proposes.
At 5-13 (page 197 of 318) the subject of continuity is revisited. 
CORE's suggestions on the subject are contained elsewhere in this comment.
At 5-14 (page 198 of 318) the subject of DNSSEC is evisited. CORE's 
suggestions on the subject are contained elsewhere in this comment.

5.4.2 What is Expected of ICANN

This section is quite remarkable for how little is actually in it.


Eric Brunner-Williams
CORE Internet Council of Registrars