ICANN ICANN Email List Archives


<<< Chronological Index >>>    <<< Thread Index >>>

Technical Comments on Transition to Delegation

  • To: 4gtld-base@xxxxxxxxx
  • Subject: Technical Comments on Transition to Delegation
  • From: Eric Brunner-Williams <ebw@xxxxxxxxxxxxxxxxxxxx>
  • Date: Wed, 21 Jul 2010 17:03:42 -0400

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

<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy