Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!utcsri!utegc!rayan
From: rayan@utegc.UUCP
Newsgroups: can.general
Subject: Re: Status of Canadian domain (very long)
Message-ID: <8708210714.AA14449@ephemeral.ai.toronto.edu>
Date: Fri, 21-Aug-87 03:14:20 EDT
Article-I.D.: ephemera.8708210714.AA14449
Posted: Fri Aug 21 03:14:20 1987
Date-Received: Sat, 22-Aug-87 15:53:23 EDT
References: <8708190102.AA05431@ephemeral.ai.toronto.edu>
Distribution: can
Organization: University of Toronto, AI group
Lines: 212
Checksum: 28456

To clarify a few points that have been mentioned here and in private mail:

Registration inside .CA is 100% independent of the NIC. As long as they
know who to point a finger at if something goes wrong, they don't care
what the subdomains inside .CA are.

If you register under .CA (which isn't yet possible, but hopefully will be),
before you can start to use your shiny new domain name in mail you send out
and in addresses you tell people about, the following must hold:

First of all, other sites inside .CA must know how to get to your domain.
Some sites will do as they do now, punt to a smarter neighbour. But most of
the sites with multiple network links (i.e. non-leaf UUCP or NetNorth nodes
for example), will need to know specific information about how to route to
your domain. This means that routing information has to be distributed in
some manner. We do this already with the UUCP map, but there is no mechanism
(and for that matter, no standard software) available to deal with that within
NetNorth or CDNNET, yet. If you are willing to accept inefficiencies in how
mail gets from various sites to yours, the minimal requirement is that the
gateways that contain authoritative information for CA must know about your
domain. These gateways do not necessarily have any connection with the ARPA
Internet nameservers, or the mail exchanger hosts referred to in them.

The reason you probably want to get an MX record for your domain into a
nameserver, is so that mail to you will take the 'best' route. It is possible
for the entire country to be served by one MX record which directs all mail
through a single gateway. However, that is not robust or efficient, and
therefore isn't desirable. Right now, there are supposedly two MX records:
one that sends UBC.CA via CSNET, and one that sends everything else (*.CA)
to McGill. With two domains under .CA, this is ok. With 1000, McGill would
get swamped.

Back to what happens when you register. The registration process for .CA
should take care of getting the right data into the right routing tables,
and distributing it correctly. On your registration form, you may be
required to list the various gateways you have links to, that have agreed
to accept mail for your domain. It may be your responsibility to ensure
these gateways know what to do with 'yourorg.CA', but I expect the global
routing information to be maintained through the registration process.
For example, if you are hooked up to uunet, you would ask them to send
yourorg.CA mail your way, and then list UUNET.UU.NET as the MX host for
your domain on the Internet. A mailer on NetNorth wanting to get to yourorg.CA
should send the message to whatever gateway you have designated, that
has agreed to handle your mail.

The UUCP Zone doesn't enter the picture, except that you may be able to
do the site registration by going through a "Canadian UUCP Zone" instead
of dealing directly with the .CA registrar (similar to people going through
"The UUCP Project" which manage a UUCP Zone, instead of dealing directly
with the SRI-NIC).

So, you ask, this is all well and good, but I'm not really interested in
good connections with NetNorth or CDNNET since I never talk to anyone there.
I am interested in efficient delivery from the Internet. What prevents me
from setting this up right now?

Before registration for .CA can start up in earnest, all NetNorth/BITNET/EARN,
CDNNET, and UUCP hosts (that care), have to know about .CA and know at least one
gateway. This means waiting for various routing data to get decided on and
to propagate on the various networks (which will take 1-2 months...). Once
that infrastructure is set up, sites can start using their registered domain
name with impunity, if they ensure good connectivity and routing information
for the portion of the world they are most interested in talking to.

Incidentally, just because your network neighbours know how to send mail to
'yoursite' right now, doesn't mean they know what to do with 'yourorg.CA'.
This is something each site will have to work out with its chosen mail
forwarders.

The NIC likes a (all too limited) set of functional domains (EDU,GOV,etc.).
Each organization is a subdomain under one of these. What the NIC chose to
do there has little relevance (by itself) to what is done in Canada.

There is a .US domain reserved. Noone has registered in it yet (no-one has
shown any interest). The tentative thought of the registrar for .US was that
there would be a geographical subdivision (per-state e.g.).

Many other countries have registered toplevel domains. Many of them use a
functional division at the second level. Examples include Britain, Israel,
Australia, Belgium, and Korea. Other countries have a flat namespace, e.g.:
Sweden, Holland, Finland, Switzerland.

The BITNET policy (which NetNorth asserts has nothing to do with them) is
to strongly discourage a flat namespace within a country.

Based on experience in UUCP-land, a flat namespace is easily manageable
with a hundred hosts. It starts creaking at about 1000 hosts, and becomes
impossible with 10000 or so *hosts*. Hosts have the luxury that they can have
cryptic names without too many disadvantages. Domain names for sites should
not be cryptic. In a flat namespace, domain names will start to look like
Ham handles after a while. How'd you like to be foo@torcorp42.ca ?

A functional namespace decreases this problem N-fold by inserting an
intermediate subdomain level. In the ARPA Internet scheme, not much is gained
because of the limited set of functional domains (6 or so, but 4 big ones --
GOV, MIL, EDU, and COM). That obviously doesn't help too much. In order to
do any good, there needs to be dozens or even hundreds of these functional
domains. Personally, I think this is the way to go. It will allow expansion
of the namespace to cover (order of magnitude) 100000 sites. I think this
is adequate in Canada for the foreseeable future (a couple of decades).

When you get into the mega-site size, there's probably only one scheme which
will survive -- geographically based domains. The phone and postal systems
are good examples of these.

That was the scale issue. The other is one of heterogeneity.

You will note that CDNNET and NetNorth are both academic/research networks.
As far as I can tell, they are being influenced by addressing ideas developed
by people in other academic/research networks (in Germany & France). The
members of these nets live in a very homogeneous world, where there are no
businesses, no lawyers, no dental firms, no condominiums, no hospitals, etc.,
hooked up to their net. UUCP is at the other end of the spectrum, having
probably the most heterogeneous population of any of the large networks.
Birds of a feather tend to connect together -- this fact of network topology
again indicates 'functional' domains are more natural. The members of the
academic nets naturally fall into their own 'functional' domain.

Secondly, the horizon of some of these networks is very short. When I talk
about this domain issue as an important long term decision, I mean that we
will have to live with the decisions we make today, 20-30 years down the road.
Partly, that's because UUCP and the Internet has been around for an awful
long time compared to e.g. NetNorth and CDNNET. To members of those nets,
"long term" may mean 2 years down the road. In 2 years, a flat namespace
probably won't be taxed too hardly, in 20 years it certainly will.

I just got a piece of mail asking what the arguments against functional
domains are, so I'll continue a bit longer.

The arguments against functional domains are:

1. It has no place in the CCITT model of the world. X.DS, a vapourware
directory service standard, will (according to present preliminary proposals)
require a printable domain-name-like representation of X.400 addresses, that
map more or less directly into the X.400 addressing model.
I.e. <organization>.<location>.<country>. The <country> field must
be the ISO Alpha-2(*) code for the country, <location> is a geographical
qualifyer, and <organization> is a unique organization within that location.

2. It is not clear how to determine an authority for a functional domain.
Suppose one sets up HOSPITALS.CA for hospitals, who will be responsible for it?
There seems to be a notion of "legal" responsibility as a requirement, in
the same sense that organizations have a clearly identifiable board, CEO, etc.

3. It is what the bad U.S. Military network uses.

(I think that's it; someone correct me if I forgot something.)

My rebuttals:

1. X.DS is not a standard yet (and probably won't be for a couple of years).
It is also of little relevance. What *is* relevant is that there be a method
of gatewaying mail between the X.400 world and the RFC world, and
correspondingly a way of translating addresses from user@foo.bar.CA format
to /C=CA/ADMD=CDNNET/PRMD=BAR/OU=FOO/ID=USER/ or similar X.400 semantics.
Indeed, such a standard exists, it is called RFC987, and part of it states
that the translation from domain name to X.400 address, and vice versa, is
done by *table lookup*, in two *separate*, possibly assymmetrical, tables.
I think that pretty much takes care of any compatibility issue.
Two other small points. Even though X.400 is a standard, it isn't written
in stone. It will evolve. If someone thinks there is something wrong with
the standard, they can work to change it. X.DS isn't ratified yet (far
from it), yet a description of a preliminary proposal for it was enough to
make CDNNET change 180 degrees from a UUCP-like outlook to their present
stance. I think they should instead have become active in the standards
efforts and guided things in a more proper direction.

2. Authority in that sense is not important. The real authority lies with
the registrar(s) of .CA who are in charge of distributing routing information
to the various gateways. If some subdomain misbehaves, all external
communication with that subdomain can be very effectively cut off at the
gateways by purging the routes for that subdomain. That will be more than
enough to solve the problem, either way. An orthogonal argument is: the
same problem exists for geographical subdomains. Who will be the authority
for BANFF.CA (for example). Do you go down to your local police station or
public library to register a domain name?

3. To put it kindly, this is unfounded phobia.

(*) about ISO Alpha-2 while I'm at it:
The reasons for wanting .CA instead of .CAN are as follows:

1. The Internet domain name specification says country-level domains should be
the ISO Alpha-2 code for the country. Of course, Britain, whose code is GB,
are using UK instead. When the NIC was asked about this for Canada, they
stated that they could see the reasons for not wanting CA, and would accept
CAN if we wanted it (even though in retrospect they thought the UK decision
was wrong).

2. X.400's internal address representation has two possible encodings for
the country name; either the numeric country code (124 for Canada), or the
printable ISO Alpha-2 (2-letter) code for the country. Note two things:
RFC987 which specifies mapping between RFC822 and X.400, says that gateways
translating into X.400 should use the numeric country code. Also, this is
an internal, binary-coded, representation of an address. This says nothing
about how people are going to see these things in a user interface. That is
partly what X.DS is supposed to address, but I think country names will be
spelled out in full in the local language anyway... it's the least you could
expect if non-english-speaking natives are supposed to read these things.

3. CA is standard, and won't be confused with California.
Many people think it will.

Anyway, I'll give someone else the opportunity to talk. I know some CDNNET
people read this group; I wish they would participate a bit more (at all,
actually), perhaps give their point of view on things.

rayan
(rayan@utai.uucp, rayan@ai.toronto.edu)
-- 
Rayan Zachariassen
AI group, University of Toronto