Q1: In the introduction of new TLDs, what steps should
be taken to coordinate with the Internet Engineering Task Force, the Internet Architecture
Board, and other organizations dealing with Internet protocols and standards?[Chad]
A formal policy and definition of responsibility should be defined for the process.
Formal actions for approval or rebuttal of a TLD should be set forth to allow these
organizations to participate and affect the final decisions.
Q2: What stability
concerns are associated with the initial phases of registration within the TLD?
[Chad]
Can the DNS servers handle the new diversity? Will the server hardware suffice?
Can the network handle the traffic? IMHO, I don't believe adding a TLD will
change the load to the Root and subsequent servers.
Q3: What can be done to eliminate
or reduce these stability concerns?
[Chad] If you're seriously worried about it.
Perhaps institute a test plan where registrars are not allowed to implement domain
name resolution to the new TLD's beyond the scope of pre-designated test domains.
Place artificial client requests to these domains via test software and determine
if there are any stability concerns with the test data. Then allow registrars
to roll out a small number of new legitimate domains per day. Add this to the
test pool on your clients. Once you're satisfied the network can handle it,
open it up.
Note, however, the second part of my suggestion may not fly, as it
could create an artificial "value" to those domains that get released "first."
You cannot enforce business policies of the individual commercial entities past standard
protocol implementation, and that may be more than they can handle as far as regulation.
Q4:
Would these stability concerns be magnified by introducing a large number of TLDs
at once?
[Chad] If your root servers fall out of sync, yes, you could see problems.
If everyone is allowed to add their "very own" TLDs, synchronization could be a large
problem. The best solution is always the simplest, good ol' Hakem's Razor (spelling?),
and lots of TLDs is certainly not the simplest.
Q5: Are there any practical means
of reversing the introduction of a significant new TLD once it goes into operation?
[Chad]
Not really. You'd simply have to ride out the wave. You must ask yourself
this question. Exactly how much power do you have? Answering that, how
much do you want to push your weight around? The best solution here, of course,
is to maintain a light touch on the controls and guide the public where you wish
them to go, while having them believe that your guidance is the right decision.
Q6:
Is it feasible to introduce a TLD on a "trial basis," giving clear notice that the
TLD might be discontinued after the trial is completed?
[Chad] Perhaps. If
you have well defined timelines and can strictly enforce cutoffs, then perhaps.
With BIND, you can specify TTL (time to live) with regards to record caches.
If you keep this TTL very small, once you've taken the TLD offline, the cache would
die out w/o a whimper. The records in web site caching engines would be harder
to ignore, but broken links are nothing new to Internet users.
[Chad] IMHO, you
should not really consider "trial" periods. Make a decision and stick to it.
If you have to "roll-back", then you've probably made a bad decision.
Q7: To ensure
continued stability, what characteristics should be sought in a proposed TLD and
in the organization(s) proposing to sponsor and/or operate it?
[Chad] A general
set of minimum hardware, network, and administrative guidelines should suffice.
A committment or contract to legalize their responsibility to the TLD and its maintenance.
Etc...(legal mumbojumbo). And a general understanding that if they mess up,
they can loose their privaleges (and obviously, customers).