Re: [wg-c] CONSENSUS CALL -- selecting the gTLDs in the initial rollout

["Milton Mueller" <mueller@syr.edu>]

----- Original Message -----
From: "Kent Crispin" <kent@songbird.com>

> Why? It would be perfectly reasonable for ICANN to say "Yes, we think
> that your idea for the '.foo' TLD is excellent, but we understand quite
> well why you wouldn't want to run it, and accept your suggestion to put
> it out for bid.  In the extremely unlikely case that there are no
> acceptable bids, then of course we won't use it."

Kent is saying that groups could propose, and ICANN accept, TLDs WITHOUT the
proposer having arranged for specific contracts or operational arrangements
to actually register names. That position seems unworkable, and antithetical
to the emerging consensus.

Under Kent's alternative, some group could be designated "policy authority"
over a TLD without having any demonstrated ability to actually provide a
service on the Internet. The relationship between its policy authority and
the implementation of the policy via the registry operation would not be
specified. On what basis, then would the delegation of a TLD be made? On the
grounds that ICANN "liked the idea"? Not good enough. On what basis would
ICANN give a "good idea" to one proposer rather than another proposer with a
similar idea wanting the same TLD string?

All business firms involved in complex operations "put things out to bid" as
part of the process of assembling their service. If I win a contract to run
a restaurant concession on the NY Thruway, I may contract with another firm
to supply the food, the labor, etc. But I am still the concessionaire and I
take responsibility for assembling the package.

> Note that I am not in any way restricting a registry from making a
> proposal for a TLD -- I am simply saying that there is no good reason to
> restrict proposers to registries only, and many good reasons not to make
> such a restriction.

Both you and Brunner seemed to be equating "registry" with "existing
registries."
This is a logically unnecessary equation.

Anyone who proposes to run a tld is a registry.

Thus, any group that wants "policy authority" has to team up with a viable
operations entity when making its proposal, or do the job itself. Whether
the actual "nuts and bolts" are outsourced or not, is not relevant to our
task. What is relevant is that the proposal be complete. ICANN is delegating
the right to run a registry, to maintain a zone file under a TLD. If a group
hasn't figured out how to do that yet, it shouldn't get a delegation.

> "be WILLING to operate or take responsibility for" [a registry] is, I
think, in most
> people's mind, different than "be a registry".

This is where we part ways. There is no difference. For ICANN's purposes, an
organization that gets a TLD delegation is a registry. This is true
regardless of whether they outsource the computer operations part of it or
not. Really, your point seems to be purely semantic at this point. You are
choosing to call a company a "registry" only if they do the computer
operations and help desk stuff. I find this distinction to be idiosyncratic
to Kent Crispin -- all extant models of things that we call "registries"
involve "policy authority," whether it is NSI or your typical ccTLD.

> Nope.  A perfectly reasonable model is that they are the policy
> authority for the registry, but don't have anything to do with the
> day-to-day operation.

"Don't have anything to do with" are strong words. Do you mean that ICANN
would select an operational partner for them? They could not change the
operational contract when they wanted?

Give me one real-world, actually existing example of such a thing. Certainly
Jamie Love's CPT would manage and select the operational partner, and impose
conditions and procedures regulating who could or could not register in
.union or .sucks. The nuts and bolts operations are simply managerial
responsibilities of the delegatee. Love's organization is the "registry."

> Which is easier:
> 1) Given an approved TLD string, find a qualified registry to operate it
> 2) Given a registry, find an approved TLD string to operate.

You don't seem to have thought this through carefully.
If registries are willing to "pound down the door" to operate a TLD string
AFTER it has been approved, they would also be willing to make arrangements
with proposers BEFOREHAND, in the hope that it will be approved. The only
difference is that in the second case, the policy authority and the operator
have to work together BEFORE they get a delegation. Which is, I think,
better.

What you don't explain is on what basis ICANN would make a delegation
(approve a TLD string) in the absence of any specifics about operational
details.

Also, Your thinking about this is limited by the fact that you think of a
"registry" as a generic function with no differentiation. But in fact many
of the most interesting new TLD proposals are precisely those which use DNS
to create some new functionality, such as a privacy-enhanced name space, or
a voice over IP number mapping space, etc. In these cases the operator and
the service/policy authority must be tightly integrated.