ka@hou3c.UUCP (Kenneth Almquist) (05/24/84)
This is the ARPANET domain names discussion, reproduced here because
a gateway has not yet been established. The last four messages deal
explicitly with the UUCP domain.
--------------------------------------------------------------------
Date: Mon, 14 May 84 09:53 EDT
From: "Benson I. Margulies" <Margulies@CISL-SERVICE-MULTICS.ARPA>
Subject: Domain Names
To: namedroppers@SRI-NIC.ARPA
I think that an important characteristic of the Domain system is somehow
overlooked here.
I thought that any mail agent worthy of the name would use caches and
server requests to avoid, in the vast majority of cases, the need to
type the fully qualified name.
In fact, if I were faced with the proposal as written, I would make it
my local mailsystem's business go and make a map of all the interesting
(to people on my host) names, thus producing the illusion of a flat (or
semi-flat) name space.
I think that like the X.400 folks, we could benefit from some work
defining what those agents might be like. It is clear that you should
only have to type d.osg.cbo.btt.att.cor ONCE, and after that its cbosgd
(except for conflicts).
No naming system is ever going to be both
a) ABSOLUTE
b) easy to use
there are just too many names out there, and the qualification needed to
specify is large.
A smart agent, (an "expert"), though, armed with the domain servers and
a good deal of local storage, can make this look reasonable.
---------------------------------
Date: Mon, 14 May 84 16:46:08 edt
From: cbosgd!mark (Mark Horton)
To: Margulies@CISL-SERVICE-MULTICS.ARPA, namedroppers@SRI-NIC.ARPA
Subject: Re: Domain Names
I thought that any mail agent worthy of the name would use caches and
server requests to avoid, in the vast majority of cases, the need to
type the fully qualified name.
Well, you can't assume this. There are lots of people out in the world
building personal computers and dumb nodes that figure "I don't have to
know anything, I'll just pass it upstream to my smarter neighbor". Unless
the standards explicitly state a minimum amount of intelligence required
by all agents (or by all above a certain point in the tree) somebody is
going to build dumb ones.
In fact, if I were faced with the proposal as written, I would make it
my local mailsystem's business go and make a map of all the interesting
(to people on my host) names, thus producing the illusion of a flat (or
semi-flat) name space.
I think that like the X.400 folks, we could benefit from some work
defining what those agents might be like. It is clear that you should
only have to type d.osg.cbo.btt.att.cor ONCE, and after that its cbosgd
(except for conflicts).
The problem here is that cbosgd may work locally, but if it creeps into the
headers and goes out, nobody else will know what to do with it. Given the
nature of user interfaces and transfer agents, this isn't easy to handle
without more header munging than anyone wants to do.
No naming system is ever going to be both
a) ABSOLUTE
b) easy to use
there are just too many names out there, and the qualification needed to
specify is large.
Hmm, seems to me the US Postal Service meets both these requirements.
The difference is that people sending paper mail are used to typing a
3 or 4 line address, and we electronic mail people are used to typing
a 15 character address and we've gotten lazy. Someone who is used to
paper mail and has never used a computer before probably will think
that d.osg.cb.btl.att.cor is very convenient, since he's used to the 4
line paper address or a phone number consisting of a string of 10
digits that are impossible to memorize.
A smart agent, (an "expert"), though, armed with the domain servers and
a good deal of local storage, can make this look reasonable.
The smart agent must also have a high performance network (like an
Internet) to access the name servers. If you have to use phone lines
with delays potentially of days, it's a whole different ball game.
You know, one thing that would help us tremendously would be a simple
way to tell for sure if an address is legal or a typo, without having
to consult a name server. It could use local files, assuming the files
don't have to be updated more often than every few months. One way to
do this would be as follows:
Any domain with no dots in it is assumed to be either (1) in the local
domain (this means you get a legal address by appending the string
LOCALDOMAIN to it, where LOCALDOMAIN is an almost never changed
configuration parameter, like ".ATT.UUCP"), (2) a local alias, which
means that you can look it up in a table in a disk file and replace it
with a fully qualified domain name, or (3) a top level domain (I can
picture an address like Mark.Horton@ATT being a fully qualified address
if ATT does become a top level domain). In the former case, some
program is going to have to append LOCALDOMAIN to the headers before it
goes out.
So the checker would first check for a top level domain on the right
(from a known, static list of legal top level domains), and if the given
address is not on the list, and it has no dots in it, first check for a
list of local aliases, and if that fails, append LOCALDOMAIN and try again.
The key to this working is that the number of top level domains has to be
small and static enough that people can have a disk file listing them that
is a few months out of date and still get very few rejections of valid mail.
Mark Horton
---------------------------------
Date: Mon, 14 May 84 10:02 EDT
From: "Benson I. Margulies" <Margulies@CISL-SERVICE-MULTICS.ARPA>
Subject: Proposed top level names
To: namedroppers@SRI-NIC.ARPA
I think that some wires are crossed here.
It seems to me that all of these top-level names are really just ARPA,
or sometimes DDN, with an admixture of PUBLIC.
There is no such administrative entity as CORPORATE. Who runs it, the
US Chamber of Commerce?
If the NIC, as administrator for DDN/ARPA wishes to organize the hosts
for which it assign names, that is fine. But NIC is still doing the
administering.
THis suggests a much shorter list of initial domains:
ARPA (under the grandparent clause)
NIC all hosts assigned names via the NIC
DDN (if any) all hosts assigned names under the authority of the DDN
(assuming an administrative entity other than the NIC)
Now, the question is, should there be NIC.EDU, NIC.COR, etc?
I sort of doubt it. the NIC is still the server, here.
Administratively, there are clearly different categories of hosts to
which the NIC hands out names. Can anyone argue that we gain anything
by making the names reflect?
--benson
---------------------------------
Date: 14 May 84 11:39:11 EDT (Mon)
From: Liudvikas Bukys <bukys@rochester.arpa>
Subject: 100 hosts
To: NAMEDROPPERS@SRI-NIC.ARPA
I am uncomfortable with the 100-host minimum for the establishment of a
second-level domain.
Prospective domains with less than 100 hosts will be forced to accept
something they don't want (many hosts in someone else's domain) until
the big day when they can have what they want (domain names), but at
the enormous expense of change of address for every resource (e.g.,
mailbox) on 100 hosts.
Of course, it is painful to contemplate the large number of domain
servers which would need to interact if the threshold was only 1.
--> As a compromise, I suggest that there be two thresholds: 100-host
minimum for running domain name servers; 1-host minimum for having a
domain. Small-to-medium organizations will have to find somebody else
to provide their domain name service. <--
This will help ensure that all the domain name server providers are big
enough to really care. It will prevent cataclysms as 50-host
organizations grow to 200-host organizations. It will prevent the
"register every IBM PC and Apple Macintosh to get around the rules"
syndrome.
hoping that "ur-seneca.arpa" will become "seneca.rochester.arpa"....
Liudvikas Bukys
bukys@rochester.arpa
P.S. 12 characters is a fine discouragement to silliness.
---------------------------------
Date: Mon 14 May 84 10:13:50-PDT
From: Peter Karp <KARP@SUMEX-AIM.ARPA>
Subject: "What's all this talk about Romaine servers?"
To: namedroppers@SRI-NIC.ARPA
Cc: KARP@SUMEX-AIM.ARPA
It almost seems like Emily Litella could help us make sense out of all
of this...
Seriously though:
1) A 100 host minimum for establishing second-level domains does seem
a bit high assuming (a) we would want most universities, corporations,
and other agencies to be named at the second level, and (b) by "host"
we mean something more than a PC, and hence most of the above
institutions do not have anything like 100 of them.
2) Initially the EDU, COR, etc domains do not seem like a bad idea. The
real question is: are we going to take advantage of the ability of
CNAME RRs to let us define reasonable aliases? E.G., even if IBM.CSNET
and STANFORD.ARPA are the official names, is it reasonable to define
IBM.COR and STANFORD.EDU as aliases? This question seems worthwhile
to ask since (a) the recent discussion seems to ignore this feature of
the naming scheme, and (b) the way the specification reads suggests
that these aliases are only meant to serve as host nicknames within
one subdomain, as opposed to defining aliases in subtrees of the name
space which are quite seperate from each other.
3) Finally, consider that it might even be simpler to drop the ARPA
top-level domain to begin with. After all, what entity in ARPA does
not belong in one of COR, PUB, EDU, GOV ? Obviously this may be
politically unacceptable.
Peter
-------
---------------------------------
Date: 14 May 84 13:31:24 EDT
From: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Subject: Re: 100 hosts
To: bukys@ROCHESTER.ARPA
Cc: NAMEDROPPERS@SRI-NIC.ARPA
In-Reply-To: Message from "Liudvikas Bukys <bukys@rochester.arpa>" of 14 May 84 11:39:11 EDT
I strongly support Bukys's proposal to enforce limits only on the size
of domain servers, but not on domains themselves. I believe his arguments
are so self-evidently correct that there is no point in my saying any
more on that subject.
However I am not yet satisfied with the discussion involving the number
of levels. Everyone seems to agree that no user will actually want to
type foo.rutgers.csnet.edu. Several people have said that caching will
solve that problem. But only if we can be fairly sure that RUTGERS is
unique. At the very least we seem to need a rule that says that an
organization's name should be unique within the network community that
is likely to want to talk to it. This may involve more than one domain.
(E.g. it seems clear that we should not have two different organizations
with the same name in ARPA and DDN.) Next, we seem to need to make it
explicit that the same organization can be a member of two different
domains. There are two reasons for this:
- some current domains are based on network structure, not
organizational lines. Apparently ARPA and DDN are not going to
go away (probably they should). Certainly UUCP is not going to
go away. It is clear that the same organization may be part of
ARPA, EDU, and UUCP.
- even if we change the domain names, there are likely to be
ambiguities as to where a given organization should be put.
Since the purpose of computers is to serve people, we should opt
for the design that makes it easiest for our users: namely
letting them find the organization everywhere that it fits. This
will mean that its name will have to be unique in all of those
domains, but that is a good thing anyway.
If these changes were made, I could probably live with the current set
of proposed domains. The advantage of the domains like EDU is that they
are based on obvious characteristics of the organizations, and so it is
fairly easy to tell in advance that a given organization should be part
of EDU or GOV, etc. (though one would need a rule about where to put
State universities). ARPA, DDN, CSNET, and UUCP then become
conveniences. I would be inclined to call them "secondary domains".
They would contain duplicate listings of organizations that are likely
to be interesting to their particular network, but which are also
listed in EDU, etc.
You might also consider specifying a canonical illegal top-level domain,
for use by isolated systems, in case some of their mail ever finds it
into the internet. E.g. LOCAL.
Any scheme that is adopted must allow for the UUCP domain. It will
not go away. At the moment we are hiding the inadequacies of the
current RFC's behind %'s. You know: foo%bar.uucp@berkeley.arpa.
Or something equivalent. There is a limit to how long this is going
to be possible. Our system must be able to tolerate creation of
new secondary domains by hackers.
-------
---------------------------------
Date: Mon, 14 May 84 11:48:35 PDT
From: Rich Wales <v.wales@UCLA-LOCUS.ARPA>
To: namedroppers@SRI-NIC.ARPA
Subject: Re: 100-host minimum on name servers?
I thought that one of the (medium- to long-term) goals of the domain
system was to allow servers to keep information all the way down to the
mailbox-name (user-name) level if they wanted to. (See "Domain Support
for Mail", on pages 52-55 of RFC833.)
It seems clear to me that the only reasonable way for an organization to
put mailbox-name info into the domain data base -- and keep said info up
to date -- is for that organization to run its own name server. This
data can change far too rapidly for a remote-storage scheme to be truly
satisfactory.
This would seem to conflict with the view that an organization needs a
certain (fairly large) minimum number of hosts in order to run a name
server. Am I missing some important point here?
-- Rich <wales@UCLA-LOCUS.ARPA>
---------------------------------
From: Larry Peterson <llp@Purdue.ARPA>
Date: 14 May 1984 1600-EST (Monday)
To: Rich Wales <v.wales@UCLA-LOCUS.ARPA>
Cc: namedroppers@SRI-NIC.ARPA
Subject: Re: 100-host minimum on name servers?
In-Reply-To: Your message of Mon, 14 May 84 11:48:35 PDT.
I believe it is a mistake to do "mailbox binding" with
domain names. Mailbox addresses of the form user@domain should
imply that the 'domain' part allows the mail system to locate
a "mail server" to deliver a message to the mailbox object
identified by the 'user' part of the address.
Being able to name "mail forwarding machines" in addition to "regular old
hosts" is a good idea, but taking that one step further to mailbox binding
means that we are supporting a logically centralized nameserver
that is merely physically distributed, rather than having a logically
distributed system --> the way mail is now viewed.
The tasks of locating a server to do something for us (e.g. deliver
a message), and having that server do its job based on an identifier
that IT is able to understand ('user'), should not be merged. The discussion
to this point suggests that such a merger will only cause problems,
and I don't see a single functional advantage to be gained --> the
local mailer can do all the same things withoug being restricted to
the domain name style. In addition, there are other questions of efficiency
that could be raised.
Centralized nameservers like "Clearinghouse" serve a useful purpose
in environments where the authority is already centralized,
(a local distributed operating system perhaps.) Computer
mail is not such an environment.
Larry Peterson
---------------------------------
Date: Mon, 14 May 84 16:01:48 cdt
From: jsq@ut-sally.ARPA (John Quarterman)
To: namedroppers@sri-nic.ARPA
Subject: Re: 100-host minimum on name servers?
Here at U. Texas, we could easily arrange to have two gateways to the Internet
running separate nameservers, and we already have an informal UTEXAS domain
as far as mail, at least, yet we have nowhere near 100 hosts. Many other
schools are probably in a similar position. I suspect no single fixed
limit like a specific number of hosts will be adequate to decide who should
have a domain or what domains should have their own nameservers. Shouldn't
the capability to run a nameserver, for instance, enter in?
It's not clear to me how limiting a host to having only one completely
qualified domain name can be conducive to making the domain naming scheme
easy to use. UTEXAS is affiliated with all of ARPA, CSNET, and UUCP;
why should we have to pick just one, especially when the nameserver
mechanisms already specified appear to be capable of handling multiple
names. If we were to have to choose only one domain to be a subdomain of,
and we chose ARPA (or EDU, or whatever), would the CSNET nameservers really
be expected to either list us only as UTEXAS.ARPA or not at all?
---------------------------------
Date: Mon, 14 May 84 19:58:19 edt
From: watmath!bstempleton (Brad Templeton)
To: namedroppers@sri-nic.ARPA
Subject: subdomain sizes
Surely limits (like 100) should ONLY apply to top level domains.
Otherwise anybody who wants to be a subdomain should be one. After all,
A host is a subdomain. Even mark's "d.osg.cb" is not so bad. It's
only two characters more than cbosgd and much more clear in meaning.
Especially when there are machines "a.osg.cb" etc.
In fact, I would suggest that any organization with more than ONE machine
be encouraged to make a subdomain. After all, what's better?
watmath, wateng, watcgl .... (as we have now)
or
math.wat, eng.wat, cgl.wat .... (as we should have) or even
math.waterloo, eng.waterloo
These are much clearer, and they let local users refer to their local
machines as just "math" and "eng" etc. provided the local name server
is a good one. I think this is exactly what we want.
---------------------------------
Date: 15 May 1984 23:40-EDT
From: Robert Elton Maas <REM@MIT-MC>
Subject: Domain requirements / must country be toplevel domain?
To: namedroppers@SRI-NIC
In-reply-to:ESTEFFERUD@USC-ECL
I don't see any reason why several countries can't get together and
form a consortium for the purpose of naming authority. For example,
several small nations in a compact geographic area (Caribbean islands,
or west African republics) might not be able to afford a toplevel
naming authority in each nation and a nameserver, so might want to
pool their resources. Or several nations allowing open trans-national
data flow (USA & Canada & England for example) might establish a joint
naming authority to allow multi-national companies in those countries
to conduct internal business without regard to national borders and to
allow names within the single company to avoid the pain of having to
factor all names according to country of location (which would
prohibit any subdomain such as a company-department from being in more
than one country).
Thus perhaps the default should be that each nation is granted a
toplevel domain which it is solely responsible for, but consortiums of
nations may merge their name domains into new consortium-toplevel
domains if they all agree to it.
---------------------------------
Date: Wed 16 May 84 09:58:40-PDT
From: Peter Karp <KARP@SUMEX-AIM.ARPA>
Subject: Implementation status and thoughts on server distribution
To: namedroppers@SRI-NIC.ARPA
Cc: KARP@SUMEX-AIM.ARPA
I have a Unix implementation working on small databases. This
afternoon I hope to get it to read in a significant part of the
entire NIC database and start testing the servers robustness.
I offer the following thoughts on the recent topic of how many sites
should actually be running name servers. Consider that:
(a) All sites will have to run some subset of the name server software
anyway because they will need resolvers and a cache system. For my
implementation this would essentially mean that they will run my entire
system but simply without authoritative entries in the database.
(b) Will it really be acceptable to various small organizations to have
another larger organization running a name server for them? People tend
to dislike relying on other people to provide essential services for
them. System administrators might like to have tight control over their
local host tables so they can experiment with different network
configurations. And in general it seems unlikely that people will want
to be in the situation where they are unable to talk to a new machine
they've just installed because another organization has not enterred
them in their name server which is authoritative for the first
organizations hosts. Of course there are ways to hack around this, but
my suggestion is that we look upon running a name server as being a bit
less of a big deal, and that most sites will be running a significant
subset of most name server software anyway. (After all if a site provides
unreliable name service this should affect their local users as well).
Peter
-------
---------------------------------
Date: 16 May 84 14:36:25 EDT
From: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Subject: Re: Implementation status and thoughts on server distribution
To: KARP@SUMEX-AIM.ARPA
Cc: namedroppers@SRI-NIC.ARPA
In-Reply-To: Message from "Peter Karp <KARP@SUMEX-AIM.ARPA>" of 16 May 84 12:58:40 EDT
Yikes! You are certainly right. But let me try to point out some
implications of your message that just struck me. They are so obvious
that I am sure others must have thought about them. But this should
still be said:
It seems fairly clear that every site with a local area network will run
a local name server. It is clearly impractical (and probably a
violation of DCA guidelines) for our local hosts to send packets to NIC
when they want to address another local host on our local area network.
Given that situation, the protocol designers might want to think very
carefully about the requirements necessary to run a domain server. While
I have supported the idea that there should be a minimum size to have a
domain server, I now see that such a requirement poses obvious dangers.
Suppose I am in the position of being a small organization, so that I
don't have an Arpanet-sanctioned domain server. Presumably NIC acts as
my server, or I commission someone else to do it for me. However I still
have my own domain server, which I use on my local area network. Unless
I do something unusual, this server will also respond to packets coming
in from the Arpanet. Here are the dangers:
- there are now two different authoritative lists of my hosts: the one
in the sanctioned Arpanet domain server, and the one in my local
domain server. Anybody who thinks those two lists will always
be the same is dreaming.
- anyone who communicates with my site a significant amount will be
very tempted to put a special entry in his database to cause
him to access my "real" domain server, rather than the
sanctioned one. This will happen the first time one of his
users wants to talk to one of my hosts that is not yet listed
by the sanctioned domain server.
- even if this doesn't happen, local mail will be generated using the
local name server.
So it seems inevitable that there will be "skew" between the name
servers, and that headers in messages on the Arpanet will be generated
using both servers. If we are careful, we will attempt to update the
sanctioned name server and the local name server at the same time, and
this skew will be minimal. However the point of establishing size
bounds on sanctioned name servers was because we were afraid that some
sites would not be able to provide sufficient reliability. It seems
that managing the coordination of two name servers under different
management is in fact a more serious problem than just trying to keep my
own reliable.
-------
---------------------------------
Date: Wed, 16 May 84 15:25 EDT
From: "Benson I. Margulies" <Margulies@CISL-SERVICE-MULTICS.ARPA>
Subject: What can we expect people to type?
To: namedroppers@SRI-NIC.ARPA
The most strilking difference between the Postal service and the domain
names is ambiguity. There are 47 3/4 different valid ways to type any
given postal address.
Could it be that small, dumb, nodes are just not practical?
The whole thrust of the Domain system is to deal with a name space that
is big, decentralized, and volatile. To offer service as a user agent
in such an environment you are going to have to communicate quickly, or
risk being out of date.
Perhaps we should make two seperate optimizations: one for people in
the fast lane, and one for everyone else. I confes that I don't see
what a dumb node is going to do except to demand that its users type a
lot of characters, quite precisely.
As for 12 characters: Sillyness, eh? Like R2D2? Forcing people so use
procrustean techniques to stuff a real-world name into a computer name
is a recipe for sillyness and confusion.
---------------------------------
Date: Thursday, 17 May 1984 08:53-PDT
To: namedroppers@SRI-NIC
Subject: Re: Multiple names, short names, simplicity
From: imagen!geof
Postal-Address: IMAGEN, 2660 Marine Way, Mountain View, CA 94043
Sorry for the delay, I've been letting mail batch up for a week or so. I
believe this message is still current, though.
Title: A plea for simplicity
Let us not lose sight of the original goals of domain names, which were very
simple: some new way was needed of mapping host names to addresses, because
the Internet was getting too big and the NIC overloaded. Domain names
suggest a way to decentralize the administrative and day-to-day aspects of
the NIC's HOST.TXT file. It has been suggested that they might do much
more:
<me>.CA.westUS.US.NAmer.Whemi.Terra.InnerSol.Sol.Spiral2.MWay.....
=
<me>.94043....
=
<me>.CompSci.ACMMember....
=
<me>.<socsec#>.male.human....
I don't see what this has to do with making the NIC's tables more
manageable. I do see what the idea is (so don't try to convince me of it),
and I like the idea, but I don't think that this is the forum or time for it
to be worked out. There is an IFIP committee working on this, and they have
good ideas. Let them worry about the semantics of names, while we figure out
how to get an Internet address from a string (because that's what we need
today).
UUCP is not going to go away, but they aren't going to use RFCXXX name
servers either. If standard relay machines exist, one could envision a top
or lower level UUCP domain. I haven't heard anyone say there would never be
such a thing. Obviously politics are involved. But the UUCP connections,
such as they exist do not appear to be in jeapordy.
The domain name scheme is based on globally unique names for hosts. Host
managers are given more latitude in choosing the end part of this name,
because the beginning part decreases the subset of the name space into which
they must fit. Multiple paths are not really manageable:
[1] you can't ask a host at an internet address what its name is
because it doesn't necessarily know all its names (there is no
clear administrative function for it to use to find them out).
[2] when you choose a host name you have to make it as unique as
possible, so that it can be added to many subdomains.
you're not going to see something like UNIX.IMAGEN.COR, even
if there is only one machine at imagen that fits the more
specified description. And how does the host manager know
when his name is unique enough? By making it be imagen-unix?
The 12-character limit: it is silly, and limiting. It is also probably a
good idea as an administrative technique for making domain names shorter.
Look at Multics and Unix - the top level of the hierarchy is usually given
as short a name as possible to limit the length of the entire path. I would
prefer to see this limit more clearly stated as an administrative limit,
rather than a technical limit on the length of all components of domain
names, to avoid things like "char name[13]" in code.
If a top level domain really has 1000 hosts in it, then there shouldn't be
too many of them, and a short abbreviation shouldn't be too hard to
remember. Example: Give me the USP abbrevs for California, Massachusetts,
New York, and Texas. For Arkansas? well, it's a small table to look it up in.
- Geof Cooper
Imagen
---------------------------------
From: Christopher A Kent <cak@Purdue.ARPA>
Date: 18 May 1984 1516-EST (Friday)
To: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Cc: namedroppers@SRI-NIC.ARPA, KARP@SUMEX-AIM.ARPA
Subject: Re: Domain servers for local nets
In-Reply-To: Your message of 16 May 84 14:36:25 EDT.
<8405161852.AA08446>
By the same token, we have a number of hosts that are not registered
with the NIC, though they have Arpa access. While our conversation has
dealt largely with mail, we must also consider the other services that
we use that require name to address translation, e.g. TELNET and FTP. I
have always been under the impression that these services will also
need to use the domain based naming to resolve host addresses, since
there will no longer be centrally administered host tables.
I certainly don't want to have to register my print/file/graphics
servers with the NIC -- I don't want someone from MIT printing on my
printer, just as I'm sure they don't want me printing on their Dover,
besides the fact that this information is only of local interest, and
presents nothing but overhead if someone outside the organization must
maintain it. Yet local users need to be able to find out those
addresses; hence I need my own server. Recent experiences with high
delays in getting the NIC to do host table updates lead me to react
strongly against something that takes local information out of my
control.
Cheers,
chris
----------
---------------------------------
Date: Mon, 21 May 84 15:40 EDT
From: Barry Margolin <Margolin@MIT-MULTICS.ARPA>
Subject: Aliases
To: namedroppers@SRI-NIC.ARPA
Thank you, Jon, for a very complete response to all the recent issues.
I have only one bone to pick, regarding section 11 on Aliases.
I feel that local names for systems are a bad idea. While names in
headers and user interfaces can always be canonicalized, these are tno
the only places where domain names exist. People often include host
names in the text of messages. Users don't know which names are local
nicknames, so they will tell someone across the country something like
"my friend's address is jones@e" where "e" is a local alias.
barmar
---------------------------------
Date: Mon, 21 May 84 12:10:11 EDT
From: John R Ellis <Ellis@YALE.ARPA>
Subject: re: comments on Domain Requirements
To: namedroppers@SRI-NIC.ARPA
In-Reply-To: POSTEL@USC-ISIF.ARPA, 20 May 1984 21:46:49 PDT
8) Second Level Domains
100 Hosts. ... We are open for suggestions for other criteria.
A naive proposal:
Why not allow any legitimate higher-educational institution as a
second-level domain under EDU? The only requirements should be that the
institution actually has access to the domain system (i.e. it has it's
own computers) and that it has a responsible administrator. For exmaple:
MIT.EDU
YALE.EDU
RUTGERS.EDU
CMU.EDU
This will put a reasonable limit on the number of subdomains under EDU.
How many universities could possibly want to register in the next 5 years?
A thousand? Two thousand? Given the generally unique names of
universities, that seems entirely resonable. And the EDU domain will
be fairly stable: universities don't change their names very often.
Each institution will still be required to provide name service for its
subdomain. The larger institutions (MIT, CMU) will probably run their
own name servers. The smaller ones will have to find someone else willing
to service their small domains.
How does this not meet Postel's general requirments for subdomains?
The disadvantage of any EDU requirement proposal based on domain size
is that it will produce an artificial asymmetry in naming universities.
Some will be second-level domains:
MIT.EDU
and some will be third-level:
YALE.SMALL.EDU
This asymmetry in addressing universities is just as bad as naming hosts
by network or route.
-------
---------------------------------
Date: Mon, 21 May 84 23:16:21 EDT
From: Mike Muuss <mike@BRL-TGR.ARPA>
To: NameDroppers@sri-nic.ARPA
Cc: Steve@BRL-TGR.ARPA, PHD@BRL-TGR.ARPA
Subject: Offer: .UUCP Domain Server
Benson Margulies writes:
"An administration has to administer. For UUCP to be a domain, someone
someplace has to be responsable for handing out reasonable names.
Somehow, this all reminds me of Xerox and Ethernet Numbers. Won't
anyone stand up and volunteer to be a UUCP name coordinator?"
The U. S. Army Ballistic Research Laboratory will (when we get a domain
server running) take on the task of being a UUCP name coordinator for the
InterNet, and would be willing to keep appropriate entries for a .UUCP
domain in the domain server. BRL will *not* actually forward any
mail for a .UUCP domain, but we will gladly resolve names to addresses
if some other site(s) will do the forwarding (I know who they are).
There are several reasons we are willing to do this (in no particular order):
1) We have to do it already. Our mail system will already accept
mail of the form <user%uucphost.uucp @ brl-bmd.arpa> and re-route
it correctly.
2) Doing it with a domain server will give us a somewhat heavy loading
for the domain server, so it will break early, and become reliable.
3) Being the Army's "lead lab" for computer research, it is consistent
with our mission. (Actually forwarding all the UUCP traffic, on the other
hand, is NOT).
4) BRL has a heavy committment to UNIX, and wishes to help bring the UNIX
community into the network world (kicking and screaming, if necessary).
5) As DARPA's ADDCOMP program is taking the InterNet into the battlefield,
it is important that Army elements have the opportunity to become
well acquainted with this technology, rather than getting taken by
surprise. BRL offers a testbed for such technology.
I believe that we will be well qualified to operate such a domain,
on all except the 100-count metric. (We go for moderate numbers of
substantial hosts, rather than hordes of shrimps). (Of course,
if we get to count all the UUCP hosts, we certainly made it!).
*) We presently operate 2 InterNet gateways, in separate buildings, on
separate power supplies. The primary gateway is in Room 100, as will be one
of the domain servers. (Room 100 is a computer room in a bomb shelter,
located in a restricted access area.) Our first 2 gateways share a single
MILNET IMP as the only common point.
*) We have in place a 56 Kbps microwave link to another part of
our facility (20 miles away), where we will be installing another
InterNet gateway. A MILNET IMP will also be located there,
pushing the common point of failure back to C&P Telephone's
DDS trunking.
*) Being physically well located, our MILNET IMP is well trunked
(currently 5 circuits operating).
If somebody else (Berkeley, perhaps?) has a burning desire to operate
the domain server for UUCP, they may do so with my gratitude.
Best,
-Mike Muuss
Leader, Advanced Computer Systems Team
U. S. Army BRL
---------------------------------
Date: Wed, 23 May 84 02:20:26 edt
From: cbosgd!mark (Mark Horton)
To: mike@BRL-TGR.ARPA
Subject: Re: Offer: .UUCP Domain Server
Cc: ksh@Berkeley, namedroppers@sri-nic.ARPA
We appreciate the offer for BRL to manage the UUCP domain.
There is already an organization formed to administer this
domain. It's called the UUCP Project, and it's being
funded by Usenix. The administrative contact is Karen Summers-Horton,
cbosgd!ksh@Berkeley.ARPA (actually ksh@cbosgd.UUCP).
If BRL would like to join with us and help out, their cooperation
would be very much appreciaated.
Mark Horton
---------------------------------
Date: Wed 23 May 84 11:46:14-PDT
From: Peter Karp <KARP@SUMEX-AIM.ARPA>
Subject: The UUCP domain
To: namedroppers@SRI-NIC.ARPA
Cc: KARP@SUMEX-AIM.ARPA
I think it's great that we have volunteers to administer the UUCP
domain, however it's not clear to me what information the UUCP
domain will actually contain.
a) Will it contain an A (address) RR for each host? For a UUCP
host this would consist of a phone number. However, this would
make little sense since (1) this information would be totally
useless to a non-Unix host (2) this information would be largely
useless to most Unix hosts because the phone number would probably
be long distance. Also, presumably sites do not wish to give out
the passwords of their UUCP directories (or is this in fact common
practice?)
b) Will it contain MF (mail forwarding) RRs? This would also make
little sense since it takes more than one hop to reach a given UUCP
site. But presumably the relay, being one hop closer to the site,
would be able to figure out how to reach the site itself. So it
would be conceivable to include a routing specification to each
host. But in fact this also makes little sense since the route
TO a given destination host depends on where the SOURCE host is.
The point I am making is that to properly administer the UUCP
world one must know the topology of the UUCP network. The domain
name system is not designed to represent network topology. Thus
unless the administrators plan to hack a representation of the
topology of the UUCP netork into a domain server, or have some
other clever idea about how to provide information about UUCP
hosts, I'm confused about what their plans are.
Peter
-------
---------------------------------
From: (Mike O'Dell[x-csam]) mo@lbl-csam
Date: 23 May 1984 1228-PDT (Wednesday)
To: Peter Karp <KARP@SUMEX-AIM.ARPA>
Cc: namedroppers@SRI-NIC.ARPA
Subject: Re: The UUCP domain
In-Reply-To: Your message of Wed 23 May 84 11:46:14-PDT.
Nope, the name server will do what is required, ie, provide an Internet-
palitable address for UUCP hosts to Internet clients. The address will
probably be a forwarder since you cannot directly contact a UUCP host
from a TCP host. How the UUCP domain in managed internally is not and
should not be visible from the outside.
Yours for less nosey software,
-Mike