ICANN ICANN Email List Archives


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

Comments on Transition to Delegation

  • To: gtld-transition@xxxxxxxxx
  • Subject: Comments on Transition to Delegation
  • From: Eric Brunner-Williams <ebw@xxxxxxxxxxxxxxxxxxxx>
  • Date: Sat, 06 Dec 2008 17:23:04 -0500

Module 5 Transition to Delegation

Sec. 5.1 Registry Agreement

Sec. 5.2 Pre-Delegation Testing

Q1.    "Following completion of the Board review, ..."

Is the word "Board" correct in the initial sentence of this section?

Sec 5.2.1 Technical Testing

Q2.    "operate the gTLD in a stable and secure manner."

None of the nine questions address the stability of the registry operation, thought the system monitoring question (#7) does address existence of data necessary to measure variation.

None of the nine questions address the security of the registry operation, though the escrow question (#6) does address existance of data necessary to recover in the event of operational failure.

Provisioning (#3) and performance (#9) do not necessarily provide system stability or system integrity.

Is "stable and secure" ment in the usual sense for complex, distributed systems designers and users, or is it a rhetorical nod to the language of the JPA?

Q3.    IDN (variant) tables (Question #1)

I'll defer this question to a subsequent comment.

Q4.    DNSSEC (Question #2)

"If DNSSEC is offered as part of registry services at time of application, can applicant comply with requirements?"

This appears to significantly understate the complexity of any meaningful provisioning of DNSSEC as a regsitry service, though it is consistent with the minimal act of signing a zone.

Is "signing the zone" a "registry service"? If so, are similar acts of the zone administrators "registry services"? Will the operational activities of key generation, key storage, key rollover and related policies be considered distinct "registry services", and subject to cumbersome negotiation?

Q5.    Architecture load requirements (Question #3)

"... aspects of this self-certification documentation can be audited on-site at the services delivery point of the registry."

First, are the documentation the target of the audit? This seems unlikely, and at odds with the same phrase occuring in Questions #7 and #9.

Second, and common to this and Questions #7 and #9, what is the "services delivery point of the registry"?

Q6.    IPv6 provisioning (Question #4)

While I applaud the general sense of anticipating a transition from a pure IPv4 address service model for A and other records, it is not the case that IPv4 is "going away", and it is quite reasonable for registries to restrict, and not necessarily on a v4 or v6 or both granularity, the addresses they allow to be associated with the registry.

This is a good "pro forma" test of regsitry technical ability but it is not a good policy to confuse v4 address exhaustion for general allocation with v4 address availablity for resolved network resources.

Finally, what justification can be offered for asking question #4 in the first place? Do we care if names in .foo can only be on v4 addresses? Is there anything wrong with that as a business model? Is there anything right with the converse, if names in .bar can only be on v6 addresses? (There's lots of things wrong with that.)

Q7.    IPv6 publication (Question #5)

Again, good general sentiment, but is v4-only service a bad thing for all registries? Suppose only v4 addresses are available to a bounded region, and the entire community served by a registry was within that v4-only region, what is the point of asking for v6 on the publication side?

Finally, for both Q6 and Q7, the use of IPv6 is somewhere between 0.1% and 0.2% of the global access address space, with a high of less than three fourths of a percent in Russia and two thirds of a percent in France.

Q8.    Escrow

Comments provided separately.

Q9.    Continuity

Comments provided separately.

Sec 5.4 Ongoing Operations

Q10. Given the number of applicants who have no prior experience with either ICANN's gTLD registry liaison (or even the regsitrar liaison), an enumeration of the "assistance" available to present applicants as future operators would be a useful clarification. The "assistance" can't (usefully) mean compliance auditing.

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

Privacy Policy | Terms of Service | Cookies Policy