Limiting the number of registrars and gTLDs

[Dave Crocker <dcrocker@imc.org>]

At 12:08 PM -0800 12/22/96, Jeff Williams wrote:
>  I agree with Chris's statment here.  I think that if there are reasons
>to limit the nucmer, than those reasons must be discussed, established,

	There are some concerns which pertain to trademark protection. I'm
neither a trademark attorney nor trained in the topic, so I can't comment
on those issues.

	The other concerns are operational.  These I DO know something about:

	The Internet has quite a bit of experience designing, building,
deploying and using large-scale systems.  One might debate whether it's
history is the longest or largest, for multi-organization data
communications, but whatever its ranking, the experience *is* considerable.


	Some people approach the task of designing a large-scale, long-term
system as one of extremely careful design, ironing out on paper ever
concern that appears.  There are times that this approach is necessary.  A
mission to Mars has limited ability to make system corrections after the
rockets fire.  And I am not too thrilled at the idea of having a pacemaker
need debugging after it's installed.

	But in the world of Internet technology and service, the usual
approach is to consider large-scale, long-term issues as best one can, but
design for near-term use and deliver something useful sooner, not later.
Large scale and long term factor into the design, but it is not expected
that all those issues will be resolved in the initial design.  The reason
is that few such designs ever work.  In reality, we learn from our use of
systems and we then have to modify them.  No matter how good our initial
design efforts, we need to make changes as we use the system.

	That leads to keeping designs simple and deploying them quickly.
As we gain experience, we splice in enhancements.  It has happened to
pretty much every portion of Internet technology and service.  Recent
examples include SNMP bulk data transfer, HTTP and SMTP streaming
(different mechanisms but both are performance-related), MIME content-type
name partitioning (vnd. & prs.).  Older examples include IP addresses,
which went from flat, to 3 types of network field length (Class A/B/C) to
arbitrary lengths with sub-fields (CIDR), and TCP transmission timeouts and
backoffs, which went through massive improvement after TEN YEARS of use,
due to learning more about the dynamics of large-network variances.

	Well, guess what.  The current topic also involves issues in
scaling.  How do we implement large-scale, multi-administration management
of gTLDs?  The answer is that we design the best scheme we think
appropriate for the long term, but we deploy it slowly, in this case
limiting the number of gTLDs and the number of registrars, and then we
watch how things go.  Increases occur as experience is gained.  Changes
occur as experience is gained.  This, I'm afraid, is the only responsible
approach.

	Anything else would be irresponsible.  To assume that things will
work perfectly from the start is not reasonable.  To assume that it is easy
to change large numbers of operations quickly is not reasonable.  The
larger the number of players, the longer it takes to make changes.  It's
that simple.

d/


(read the last line, please)
----------------------------
Dave Crocker, Director                                       +1 408 246 8253
Internet Mail Consortium                                 (f) +1 408 249 6205
127 Segré Place                                             dcrocker@imc.org
Santa Cruz, CA  95060 USA                                 http://www.imc.org

Also:  IAHC member, expressing strictly (or loosely) personal opinions