gnu@sun.uucp (John Gilmore) (05/24/84)
Message-Id: <8405210501.AA10448@UCB-VAX.ARPA>
Date: 20 May 1984 21:46:49 PDT
From: POSTEL@USC-ISIF.ARPA
Subject: re: comments on Domain Requirements
To: namedroppers@SRI-NIC.ARPA
< INC-PROJECT, Q-AND-A-DOMAINS.NLS.3, >, 20-May-84 21:43-PDT JBP ;;;;
Hi:
I will attempt to comment on some of the discussion of the last week.
Opening Remarks:
It certainly is interesting to find that there is a lot more
discussion about what a name looks like and what it means than there
is about the details of how the system is built.
It really would be nice if when people start using the language of
the actual specifications or discussing details described there, that
they took the trouble to review the specifications.
1) Name-to-Address Lookup vs Directory Assistance
One concept that seems to have been widely misunderstood is that this
is a naming system, not a general directory assistance system.
This is supposed to be a system for finding specific types of
information about exactly named things (with a few careful
generalizations in the name search). This is not intended to be a
system for finding partially described things. The NIC WHOIS service
and the CSNET Mailbox Name Service are example of more generalized
searching systems based on partial information. The current IFIP WG
6.5 work on directory assistance is different from the domain names
system in this respect, too, it aims to find things based on partial
information (this also makes it much harder to implement).
The notion that you don't want to worry about SRI being in EDU or GOV
or COR, is like saying that you don't want to worry about Los Angeles
being in California or Texas or Oregon.
SRI will choose to be in some domain and will advertise its
address.
When you call me on the phone you have to know my phone number, you
don't get to guess an area code, and some how expect all numbers to
be known in all area codes.
I tell my number to people i expect to call me, and i have my
number listed in directories. I don't expect people to be able to
guess it.
With the current mailboxes and host name the same applies. I tell
people my mailbox name (POSTEL@USC-ISIF.ARPA), and i list it in
directories (NIC WHOIS). I expect the same practice to continue with
domains. It is possible that some time in the future things will
change and my mailbox might be "POSTEL@ISI.USC.EDU". I wouldn't
expect anyone to guess that that was my mailbox, i would tell some
people and get the directory entry updated.
2) Unique Names
While it is possible for a host to have several (even many) names in
the domain name system, that is not the general intent, and i don't
think it is a good idea.
Think about the hosts names we have now, would you want your host to
have several names? If it did, what would your mailbox be? How many
more duplicate messages would you receive?
Suppose my host was known as both USC-ISIF.ARPA and LA-47.ARPA.
Then i could have mailboxes POSTEL@USC-ISIF.ARPA and
POSTEL@LA-47.ARPA. How is someone at another host supposed to
know that these two mailbox addresses are the same person? In
general, they can't, and so i will get more duplicate mail than i
do now (which is already too much).
Also think about the other side of it. If my host has more than one
name, which one should it fill in for me on the FROM line when i send
a message? If there is some default that is used, that is the
"preferred" name for the host. Given that the host has a preferred
name, why not use that name all the time?
It was suggested that since a host can be connected to more than one
network and thereby can have more than one hardware address, it
follows that it should have more than one name. This is like saying
that a city ought to be allowed different names for each type of
transportation system (roads, rail, ship, air) that it is connected
to.
It is certainly allowed for a host to have multiple names, and it if
a host did have multiple names they could be associated with the
networks the host was connected to. I don't see any advantage in
doing it.
Names have to be unique only with respect to their siblings. There
may be names like:
XYZ.PQR.ABC
WUV.PQR.ABC
XYZ.IJK.ABC
WUV.IJK.ABC
to name four different hosts.
Many people seemed to think the example in the DRAFT RFC was either
confusing in itself or would lead to a confusing result.
For example, a host "XYZ" at MIT might possible be considered as a
candidate for becoming any of XYZ.ARPA, XYZ.CSNET.EDU, or
XYZ.MIT.EDU.
The owner of host XYZ may choose which domain to join,
depending on which domain administrators are willing to have
him.
Some people seem to be upset that this could possibly result in a
range of host names like:
APIARY-1.MIT.ARPA
DASH.MIT.CSNET.EDU
MULTICS.MIT.EDU
First, i doubt that MIT would let this happen, but one can't be sure.
Second, i am not sure what to be upset about. The notion seems to be
that somehow i know that this MULTICS is an MIT computer but can't
guess if it is in ARPA or EDU. This is the kind of problem the IFIP
system is supposed to solve, but the domain name system does not. I
think the real question here is more like "I want to send a message
to Dave Clark of MIT, and i think his mailbox is on the Multics
computer there, what is the exact string i should enter to send mail
to him?". This is a question for the NIC WHOIS service, not the
domain name server.
The notion that "an organization name should be unique within the
community that is likely to want to talk to it" is a bit strange.
How is this uniqueness to be preserved? What happens when some
previously separate communities discover some common interests? The
whole point of domains is to subdivide the name assignment problem.
To try to preserve some higher level uniqueness would require the
very central coordination we are trying to eliminate! It should be
clear that there is no hope of such uniqueness in the long run, so
let's not make any plans based on such a false hope.
3) Syntax vs. Semantics
It has been suggest that semantics to too political for us to deal
with and that we ought to stick with syntax.
I agree that semantics seems to get more people with more points of
view saying more outrageous things than one would expect or wish to
cope with.
It would be nice to stick to syntax, except that we actually want to
put this system into service, and to do that we have to have some
real names to use. It seems to me that we have to deal with the
semantics now.
If we don't have the savy or clout to sort this out, we ought to
forward the problem to those who do. Any nominations?
4) The Top Level Domains
There is a great deal of discussion of these top level domain names.
The general tone seems to be that it is a good idea to have only a
few top level names but these are "too abstract".
I have not heard many suggestions for other top level names except
for currently existing things. I think that would lead to a lot of
top level domains.
It was suggested that there be a standard top level name for use by
isolated systems. I am not sure that would be the best approach. I
would favor registering the names of isolated systems in some way.
Experience shows that isolated systems tend to get connected.
5) Countries as Domains
Where does the UK domain go? Good question. We probably should
allow countries to be top level domains. I don't think this means
that we should have only countries as top level domains. There are
quite a number of international entities that would be difficult to
divide up into countries.
6) ARPA and DDN Domains
ARPA and DDN probably in an ideal world should not be top level
domains.
At best they probably ought to be: ARPA.DOD.GOV.USA and
DDN.DOD.GOV.USA.
And the computer i use would be: F.ISI.USC.ARPA.DOD.GOV.USA
However, for a while (probably a long while), they will be top level
names. This is a system that has to evolve into use. We are not
operating with a blank slate. Right now we have all the hosts in the
ARPA & DDN Internets operating with domain style host names in the
ARPA domain.
There have also been some comments about the requirements being
designed to favor the DDN and DARPA communities, or to prevent groups
not working for DARPA or other military agencies from qualifying.
This is not the case. We are perfectly happy if this naming system
is widely used. This is clearly to DARPA's and DDN's advantage.
Because of the history and the sponsorship of this effort DARPA and
DDN will get some special treatment. However the attempt here is to
set a policy for using domain style names that is fair for everyone.
7) Top Level Administrators
It was noted that it is strange that all the top level domains are
administrated by the NIC. The NIC is the agent of the the DDN and of
DARPA for the administration of those two domains, as for the other
domains the NIC does not want the job! If we can find some
reasonable alternatives for getting these domains administered we
will gladly explore the possibilities. Any volunteers?
It was suggested (in jest, i think) that the Corporate domain be run
by the U.S. Chamber of Commerce. It is not such a bad idea. I would
like to see the administration of these domains move to appropriate
responsible entities. I would not push to get some organization to
administer a domain until there was some indication that they knew
what it was, though.
Actually, while right now it may look hopeless for ever finding
appropriate administrations to take over the management of some of
these domains, i expect there will in the not too distant future be
several volunteers for each of these domains.
The NIC is not a "administration" in the sense used here. The NIC is
the agent of both DDN and DARPA. It would be inappropriate for there
to be a top level NIC domain. The NIC is acting as DDN's or DARPA's
agent when it registers and assigns host names.
One can be the administrator of a domain, or be the agent of the
administrator of a domain without being in the domain. For example,
the NIC might be NIC.DDN even though it is the administrative agent
for other domains as well.
8) Second Level Domains
100 Hosts. Perhaps the most often voiced issue is that 100 hosts may
not be the right criteria for being big enough to be a second level
domain.
We are open for suggestions for other criteria.
It was suggested that with this kind of criteria someone will count
every PC as a host. I think we should expect that in any case. So
the criteria should probably be different. Maybe it should be in
dollars of computer hardware (say $5,000,000 ?). Or, maybe it should
be user accounts or mailboxes (say 25,000 ?). Or, some formula
combining several factors? Any suggestions?
Try thinking of two cases: one you think should be a second level
domain and one you think should not. Try to make up a decision rule
that separates them. If you find some thing that works try it on
some other cases. If it still works tell me about it.
There was a suggestion to limit the operation of a name server to a
large organization but allow any one to be a second level domain.
This is just the opposite of the intent. The requirement that a
second level domain be some at least some threshold size is intended
to it limit the number of such domains in some way. If a much
smaller organization can operate a name service (reliably and
robustly) that is fine with me. I encourage it.
There was a question about hosts at the second level. If a top level
administration decides to it may allow hosts as second level names.
This is now the case in the initial ARPA domain. This is discouraged
in the future, but it is allowed.
The notion that a host is just that special case of a domain which
has no subdomains and is a single machine still applies. That is, a
host is a leaf of the domain name tree.
An organization with a small number of hosts (or even just one) will
probably be able to find some second level domain administrator will
to take it in as a third level domain.
9) Number of Levels
Some feel that the current plan will result in too many levels. I
think that it is not actually a problem of how many levels but how
long (in characters) names become. I think user pressure will keep
things reasonable.
There is some suggestion that the top level names do not add anything
significant while making the names longer. I think the top level
names are important because of their semantic neutrality. I think it
is important to getting some agreement on how we are going to use
this system, and i think it is so important to get this system into
service that i am willing to pay the cost of an "extra" level.
Another concern expressed was that some organizations will create
many levels with essentially no content. For example, A.B.C.D.E,
where B and C have no siblings. I don't think that this will happen,
but i am prepared to let it.
10) Name Length
There were three types of comments on this: 1) 12 characters too
short, 2) 12 characters too long, and 3) 12 characters just right.
One should note that this was said in the context of one segment of a
domain style name (what the implementation specification calls a
"label").
The implementation specification allows each label to be up to 63
characters long. Anyone writing a program to implement anything
dealing with domain style names should plan for the possibility of 63
character labels.
11) Aliases
While it is possible to set up aliases in the database (using the
CNAME RRs), i don't think this should be used widely on a long term
basis. It may be a useful feature to use for a short time (a few
months) when a host changes its domain style name.
I think that many hosts will want to establish private files of
aliases for commonly used other hosts. And i think that users would
like to have private files of commonly used other mailboxes. Such
files should be easily coupled to applications programs (e.g., the
users mail program).
12) Names Servers
The information a name server can supply about a name is everything
that is in the database. There is no implication from the name that
limits the information that can be returned. The details of the
query determine the information returned.
For example, if one looked up UDEL.CSNET.EDU one could get back
(depending on the details of the query) both the ARPA-Internet 32-bit
address and the MMDF phone number.
Please recall that name servers do not have to be one to one with
domain names. That is, several domains may go together to provide
the robust and reliable name service.
There was some talk about "sanctioned" name servers. It is true that
when a domain is set up some name servers must be registered so that
information about this new domain can be accessed. These name
servers must have up to date information about the domain. There can
easily be additional name servers set up for the domain. I don't see
that these additional servers need be though of as second class
citizens in any way. There was also some concern about keeping the
data consistent between these servers. By using the data base zone
and master file procedures defined in the specification there should
be no problems with inconsistent data (except possibly very briefly
when the master file is updated).
13) Database by Zones
The name servers implement the protocol to answer questions about
data they hold. The data is organized in to sections called zones.
A zone may conveniently correspond to a low level domain.
For example, ISI might become a third level domain. The information
about the hosts at ISI might be a zone of the database. This zone
could be updated at ISI and provided to several name servers operated
by other organizations.
The part of the database that describes a top level domain and its
second level domains (but not the third and lower level domains)
might also be a zone. This information might not change very often,
and might be distributed to many name servers.
14) Brick Wall
I don't respond well to being shouted at.
Try a calm and well reasoned presentation.
Summary:
I think the main point i want to make is that i want the mechanism to be
general and capable of supporting a reasonably large and appropriately
structured naming system, and i want to start using it as soon as
possible. This may result in the initial structure of names and
administrators being somewhat distorted from what we might have in an
ideal world. Let's get on with the experiment and evolve toward that
ideal world.
--jon.
-------