From: jmm@elegant.com (John Macdonald)
Subject: Re: Domain naming conventions
Date: Sat, 9 Jan 1993 01:03:36 GMT
Organization: Elegant Communications Inc.

In article <C0Iu73.1I9@uunet.ca> smd@uunet.ca (Sean Doran) writes:

[ ... ]

|On the other hand, one could find oneself wanting to do nameservice
|for parts of CA on one machine at UBC, for examble, and other parts on
|another machine at UBC, likely because of computer horsepower issues.
|Not having everything in the top-level makes this possible, but does
|not necessarily imply the need for geographical subdivisions.  It also
|isn't even necessary while the size of CA-DOM zone and the number of
|queries the nameservers handle both remain manageable.  The size/work
|issue is really not much of a problem, given the speed and size of
|computers these days.  

In fact, this sort of distributed processing within a single
"nameserver" does not really require extra domains in the
current situation where the "top-level" nameservers are best
placed at the international gateways.

Just take the proposal somebody made earlier of using the
first few letters of the second (or n'th) level sub-domain.

However, I disagree with the details of that proposal - there
is no reason what-so-ever for the nameservers desire to spread
its database across some number of internal processing nodes
should be reflect in the formal domain name actually assigned.
So, instead of the originally proposed xxx@foobar.f.o.o.ca, it
would be just as good to use xxx@foobar.ca as the domain name,
and the nameserver looks at characters instead of subdomains
when it decides which of its sub-processors should actually do
the lookup.  (This allows the nameserver to scale invisibly
from using one processor, as I expect most do at present, to
using 1000 processors in a few years when every business down
to the corner convenience store has a domain name.)

Having the ability to move to a larger number of separately
managed nameservers in the future (when the cross-border lookup
points are not such a significant portion of the total amount
of lookup activity within this country) is an important feature
to prepare for and to maintain.  How the sub-domains should be
laid out to support such a capability is not really clear, though.

It may turn out that just using an invisible, internally adjusted
scheme for distributing the nameserver nationally is perfectly
adequate.  This would be nice - it would let the naming function
be allocated on grounds that depended solely upon "good" names
and be independent of what was necessary for acceptable implementation.

By the way, when we come to the stage where every corner store
has it own domain name, one facet of a workable sub-domain scheme
might be to use the section titles from the Yellow Pages.  That
way acme.plumbing-supplies.toronto.on.ca and acme.computers.toronto.on.ca
could both exist without arguments about who "deserves" to "own"
the domain name "acme.toronto.on.ca".  This would actually work
well with the current geographical scheme as long as these sub-domain
specifiers were permitted at each level.  Of course, there could still
be disagreements between organizations with the same name and
sub-domain that operated in greater than one city areas in different
parts of a province.  Thus, acme.computers.on.ca (Toronto, Hamilton,
and London) might argue with acme.computers.on.ca (Kingston, Smiths
Falls, Brockville, and Ottawa) over who should get the provincial level
name.
Newsgroups: can.domain