From: "J. Patrick Narkinsky" <firstname.lastname@example.org>
Date: 8/22/98 8:50am
Subject: Response to US Domain Request for Comments
As is made clear from the fact that you are gathering comments on this
issue, there are many problems with the current .us domain structure.
In this comment, I propose to identify some of the perceived problems
and to detail the solutions that I would suggest for them. My standing
in this matter is as a long time user of the Internet (I've been on the
net in one form or another since the late 1980's.) I have also
consulted with many firms attempting to move onto the net.
The biggest single problem with the .us domain is the excessive length
of domain names in this domain. For example, if I wished to get a
'nominative' domain for use at my home, my domain name would be
something similar to the following:
If I wanted to follow the customary 'www' prefix to web servers, it
This is completely unacceptable, especially for email addresses which
often have to be typed. Even worse, if I have only a vague recollection
of someone's email address, I could just as easily choose:
narkinsky.nn.va.us (Which would make a lot more sense)
Just as bad, if I move less than one mile to Hampton, my domain should
really change. To this end, I would suggest that the structure of the
.us domain be updated to offer more options. Most other 'country' TLD's
use a structure somewhat similar to the following:
where organization is the name of the organization, type is the type,
and country is obviously the 2 digit ISO country code.
Hence, my first recommendation: I think we should move to a structure
where it is possible to have an address of the form:
For example, I could then have an address of 'narkinsky.nom.va.us'. I
would suggest that the following be valid types:
com: For companies
nom: Nominative -- for individuals and families.
gov: State government
org: Non-Profit organizations
net: For network entities and ISP's
Ideally, there should be a fairly streamlined way to add to the above
types. Really and truly, the overhead of maintaining additional
subdomains is not much.
Secondly, we need to accept the fact that many companies are truly
national in scope. It is absolutely inane to insist that, for example
IBM, register as 'ibm.armonk.nj.us'. Far more reasonable, intuitive,
and usable would be to have the above categories available directly
under the .us domain. So, for example, one could have
ibm.com.us -- IBM
sbc.org.us -- The Southern Baptist Coalition
However, I do think that there needs to be a clear requirement for
registering under these domains. Otherwise, we will end up
'bobs-garage.com.us', which is not appropriate.
Thirdly, I think that a careful look needs to be taken at how the .us
domain is distributed. For example, if I want to create an entry in the
.newport-news.va.us subdomain, I have to go through the Network
Administrator at NASA Langley. While the gentleman in question is a
hard-working and extremely competent engineer, he is extremely busy with
other duties. This makes the turn around on new domains in excess of a
week. To be manually entering new entries is ridiculous: that's why we
have Web based forms and email. So, my third recommendation: I think
that .us domain needs to have a central registry, similar to InterNIC,
and that all domain registrations happen centrally. Then, appropriate
domain files can be propagated out as necessary. However, the important
thing is that this should happen totally electronically without
requiring human intervention except in extreme cases. This kind of
system has been done many times before, and should be extremely simple
to setup. I have setup similar systems in the past in less than a
couple of days.
Finally, I think that a careful examination needs to be made of whom you
are delegating authority over localities to. Furthermore, I think that
the number of delegations needs to be reduced. Many of the delegated
authorities are not as conscientious as my friend at Langley, and many
of them charge what seem to be exhorbitant rates.
All of the recommendations mentioned above are additions to the current
domain structure. Hence, they could be setup while not affecting current
.us registrants at all.
Thanks for you attention, and if I can be of any assistance, please feel
free to contact me.
J. Patrick Narkinsky
224 Piez Ave
Newport News, VA 23601
From: Andy Bradford <email@example.com>
Date: 8/22/98 4:24pm
Subject: The .us domain space.
For what my opinion is worth, I think that the organizational management
of domains by adding the .us toplevel domain. I feel that it is an
infringement of the freedom that already exists on the internet. Where I
note that there are certain benefits and I realize that a lot of the
development of the internet structure has come through the government, I
don't feel that it is necessary to include this expansion.
From: Bill Clark <firstname.lastname@example.org>
Date: 8/22/98 10:58pm
Subject: Comments re Enhancement of the .us Domain Space
I most fervently urge that you reconsider any further
semantic enhancement of the Domain Name System.
Instead, the use of meaningful second-level names should
be eliminated entirely as soon as is practical.
For resolution of meaningful names, site locations,
site types, etc., we should rely not on the DNS but on
third-party LDAP-enabled portals and directory caches.
Suppose, e.g., we were to:
1. establish a new TLD .g and fund its name registrars;
2. allocate to every existing and future generic-nameholder
a randomly-chosen, durable, alphameric name axxxxx.g;
3. require that issuers of .g names elaborate their
whois databases with links to nameholders' directories,
should nameholders choose to provide them;
4. require that domestic .g issuers make their whois
databases available to all at reasonable fees;
4. ensure that DNS performance via domestic generic TLD
servers begins to suffer in 2002.
Would you not agree that we would see a multiplicity of
independent directory services who compete on quality and
offer free or inexpensive resolution of .g names and/or
protocol addresses by name, location, classification of
entity and other useful criteria? Would we not see
directory caches at interchanges and within intranets?
Relatively simple direct hardware implementations of .g
servers will be possible. And foremost: We will be absolved
of most of the concerns of this RFC as well as the legal,
political, architectural and financial consequences we have
suffered under our system of meaningful second-level names.
The existing system served us well until a two or three
years ago. But now that meaningful names have become scarce
and a needless source of argument, their use should be
discouraged rather than embellished. They cannot be enhanced.