Comments on Transition to Delegation

[Eric Brunner-Williams <ebw@xxxxxxxxxxxxxxxxxxxx>]

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.