From: hooper@ccs.QueensU.CA (Andy Hooper)
Subject: (large) Re: Q: organizational subdomains?
Organization: Queen's University, Kingston
Distribution: can
Date: Thu, 7 Jan 1993 12:08:04 GMT

In article <C0Gtvq.7AL@wimsey.bc.ca>, sl@wimsey.bc.ca (Stuart Lynne) writes:
| Please share these difficulties with the rest of us. I know I don't read as
| much news as I should :-) But I havn't seen much mention of an imminent 
| meltdown in .com or elsewhere (except rumours in this group).

From the 'namedroppers' mailing list archives:

Date:	Mon, 3 Aug 1992 19:35:00 -0400
From:	treese@crl.dec.com
To:	namedroppers@nic.ddn.mil
Cc:	mdavies@nri.reston.va.us
Message-Id: <9208032205.AA07443@cirocco.crl.dec.com>
Subject: Boston IETF: DNS Working Group minutes


Minutes of the DNS Working Group Meeting
Internet Engineering Task Force Meeting
Boston, MA
13 July 1992

Minutes by: Win Treese, Digital Equipment Corp.

Win Treese (Digital Equipment Corporation) chaired the meeting, as the
regualar chair, Mike Reilly (Digital Equipment Corporation), could not
attend.

The agenda for the meeting consisted of discussion about:
	- the proposed DNS MIB (Jon Saperia, DEC)
	- the NSAP resource record proposal (RFC-XXXX, ???)
	- possible guidelines for the assignment of names in top-level domains
		(Mike St. Johns, Dept. of Defense)

DNS MIB
-------

Jon Saperia handed out copies of the Internet Draft DNS MIB, which had
previously been sent to the namedroppers mailing list.  Jon had made
several changes based on comments from the meeting in San Diego.
There were a few minor comments, whihch Jon agreed to incorporate.

There was some discussion of whether or not SNMP should be used to
update authoritative date in a server.  Jon Saperia and Rob Austein
pointed out that this is a hard problem.  Adding a new host, for
example, involves adding new address and pointer records, and possibly
HINFO and MX records.  Should the server store the updated information
in its permanent database?  How are all replicas updated?  Is the
update protocol atomic for all replicas? Is it atomic at a single
replica? How are changes authenticated and authorized?

The group awaits a proposal on updates; the MIB will be moved forward
as it is now.

NSAP Resource Records
---------------------

Bill Manning presented RFC1348, which proposes new resource records
for NSAPs to support RFC1348 (the TUBA proposal).  There were some
minor suggestions for modifications to the proposal. We also discussed
having a wildcard address query for any type of addresses.  The group
concluded that it was best not to create a new class for extended
addresses of any type, since the class mechanisms are not
well-understood in practice.

Naming Guidelines
----------------

Mike St. Johns proposed establishing some naming guidelines for the
top-level domains (e.g., COM, EDU), because they are growing quite
rapidly, and may eventually overwhelm the capabilities of both human
and computer to use them.  There was quite a bit of discussion on this
issue, but very little was resolved.  A detailed proposal of
guidelines is probably needed to further the discussion.



Win Treese						Cambridge Research Lab
treese@crl.dec.com					Digital Equipment Corp.

Date:	Sun, 22 Nov 1992 13:51:00 -0500
From:	bmanning@is.rice.edu
To:	namedroppers@nic.ddn.mil
Message-Id: <9211221659.AA09824@is.rice.edu>
Subject: ietf25 notes

>X-Mailer: ELM [version 2.3 PL11]

I will send these notes off to Megan for inclusion in the proceedings
with any corrections/additions that are sent to me before the 25th.
			------------------------


The working group had the following adgenda:

	review proposed changes to RFC1348
	shuffle & load averaging RR support
	large zones problems & policy
	IDPR
	DNS values set from SNMP

RFC1348 changes:  the draft clears up the reverse lookup method and adds the
	inclusion of Network Entity Titles.  NSAP prefix storage appears to
	be unworkable without a seperate RR type.  If this feature is desired,
	then a new RR may be added. The label NSAP-PTR needs to be corrected,
	since it is not a pointer.
	Bill will post the revised draft shortly after the IETF.
IDPR: they need a RR to lable an administrative domain or AD. The plan is to
	use a 32bit number. 
        Rob will follow up and make sure this happens.
Shuffle & Load. Mimi described a problem that needs to query for load average
	of a logical cluster of machines. Mel and Walter both came back with
	two distinct ways to try and address this problem.  Mimi will write up
	a draft that better covers the problem space.
Large zones:  Mike pointed out the problem with the com and edu zones.  EDU
	We should recommend to the new NIC that following rule of thumb be
	used for new assignments in the EDU zone:
		xxxx.edu  - 4 year schools that issue masters/phd degrees or
			equivalent.
		xxxx.state.country  - 2 year schools or those that issue 
			associate or bachelor degrees.
		xxxx.k12.state.country  - pre-collage
	The COM domain is still a problem. We might recommend the second level
	be assigned an industry type.  The prblem would also be helped by 
	distributing the servers off root platforms.
MIB: ISEG to decide on propsed standard this week. The discussion regarding
	setting values via SNMP will be discussed on the list. Scott will
	lead the charge here.


-- 
Regards,
Bill Manning         bmanning@rice.edu        PO Box 1892
 713-285-5415         713-527-6099	       Houston, Texas
   R.U. (o-kome)       			        77251-1892

Date:	Mon, 23 Nov 1992 22:28:00 -0500
From:	Marshall Rose <mrose@dbc.mtview.ca.us>
To:	bmanning@is.rice.edu
Cc:	namedroppers@nic.ddn.mil
Reply-To: namedroppers@nic.ddn.mil
Message-Id: <24075.722568940@dbc.mtview.ca.us>
Subject: Re: ietf25 notes 

>Mime-Version: 1.0
>Content-Type: text/plain; charset="us-ascii"

In regards to the large zone problem:

First, appologies in advance for not being present at the meeting--too
many things were conflicting.

Second, if this topic is a tar-baby, sorry for re-opening it.

However, I'd like to point out that the .COM problem can be viewed in a
fashion similar to the .EDU problem.  The solution is to start using
geography-based naming.  It is often easier for people to identify the
geographical location associated with an organization than its "industry
type".

In general, I would like to see a move away from .COM, .EDU, and .ORG
and a move towards putting US stuff under .US (for big orgs), under
.*.US (for regional orgs), and under .*.*.US (for local orgs).

Comments?

/mtr

Date:	Mon, 23 Nov 1992 23:26:00 -0500
From:	bmanning@is.rice.edu
To:	namedroppers@nic.ddn.mil
Cc:	mrose@dbc.mtview.ca.us
Message-Id: <9211240215.AA08299@is.rice.edu>
Subject: Re: ietf25 notes - large zones

>X-Mailer: ELM [version 2.3 PL11]


Makes lots of sense to me, but the problem has something to do with
the fact that at least some businesses grow.  Very often, geographic
tags lose their significance. The same is true for industry segment,
particularly with the (US) mania for mergers.  We just don't have a 
good general model...  In the interim, geographic tags for "small"
business, industry tags for "medium" business, and .com registration 
for the international & pan galactic folks might be a way to go.
The parameters used to constrain these catagories is the hard part.
Any ideas that could be used to create a mo'better model will be 
pounced on.

-- 
Regards,
Bill Manning         bmanning@rice.edu        PO Box 1892
 713-285-5415         713-527-6099	       Houston, Texas
   R.U. (o-kome)       			        77251-1892

Date:	Tue, 24 Nov 1992 01:20:00 -0500
From:	John Demco <demco@cs.ubc.ca>
To:	<namedroppers@nic.ddn.mil>
Cc:	<bmanning@is.rice.edu>, <namedroppers@nic.ddn.mil>
Message-Id: <22911*demco@cs.ubc.ca>
Subject: Re: ietf25 notes 

>In general, I would like to see a move away from .COM, .EDU, and .ORG
>and a move towards putting US stuff under .US (for big orgs), under
>.*.US (for regional orgs), and under .*.*.US (for local orgs).

This is basically what we did for the Canada (CA) domain.  One of the issues
for us was finding suitable guidelines for "big", "regional", and "local". 
We also have a committee which reviews by e-mail each subdomain application. 
The scheme works fine, although I know of a number of Canadian organizations
which have opted for subdomains under .COM, .EDU, and .ORG because they
didn't like the geographical .CA structuring.

John Demco
CA registrar


Date:	Tue, 24 Nov 1992 02:18:00 -0500
From:	Rob Austein <sra@epilogue.com>
To:	namedroppers@nic.ddn.mil
Message-Id: <9211240100.aa10359@quern.epilogue.com>
Subject: ietf25 notes 

Marshall,

Yup, it's a tar-baby, but it's probably time we discussed it on the
mailing list, so don't apologize.

Before I get into this I'd like to point out that Paul Mockapetris has
outlined a scheme for "incremental zone transfer" (there was some
debate on the name at the "DNS II" BOF on Wednesday night).  If
implemented, this scheme could greatly reduce some of the problems
associated with huge zones.  It's not a cure-all, but it might buy us
a few more years before we have to make hard choices.

This was the third IETF in a row at which the working group discussed
the "big top-level zones" issue without reaching consensus.  Some
people feel as you appear to, that this is a simple matter that can be
solved geographically.  Others, myself among them, feel that it's
complicated:

* Lots of small companies span geographic borders.  What do you do
  with a company that has fewer than ten people but offices in more
  than one country?

* What happens when a company moves its home office?  Does that imply
  that it must automatically change its DNS names?

* Who pays for the nameservers in the state of Delaware, given that
  half the big companies in the USA are (in theory) based there?

* One of the guiding principles behind the DNS was to avoid putting
  topological information into the names; some of us feel that this
  applies to geographic topology as well as network topology.  Think
  hard about this one: mobile hosts are likely to become a serious
  issue in the next few years.

* Some people feel that the protocol police should force geographic
  names to be meaningful.  Some people don't.

There's also the issue of who decides who "merits" a second level name
(foo.COM) and who gets a lower-level name (foo.city.state.COM.US).  No
matter what guidelines you pick, you're going to offend somebody.  I
went through this nightmare years ago at a big university, I have no
desire to go through it again on an Internet-wide scale.  I have no
objection to companies (or schools or whatever) that *volunteer* to
receive a lower-level name, but that's not what we're discussing.

The "industry type" idea came up as one way of avoiding some of the
problems listed above.

We could try splitting the big zones on a purely mechanical basis.
For example, split on the first three lettersof the company name, so
"engulf-and-devour.com" becomes "engulf-and-devour.e.n.g.com".  The
ordering of the initials probably doesn't matter so long as we agree
on what it is.  Ok, the names are ugly, but so are SNMP OIDs, that's
why we have user interfaces.  But Mike St Johns points out that even
if we could agree on this scheme we'd have a hard time finding servers
for all the 26**3 (or 36**3 or whatever) zones.

If people are willing to forget about the significance of the names
and just treat them as UIDs, we can just say that you get your name
where you first register it (based on geography) and you keep it for
as long as you want it.  People who chose to believe that the names
are meaningful object to this.

In summary, I don't know of a good answer.  I'd propose it if I did.
I don't think the issues are as simple as geography fans claim it is.

--Rob Austein <sra@epilogue.com>

Date:	Tue, 24 Nov 1992 10:48:00 -0500
From:	lazear@outrigger.mitre.org
To:	bmanning@is.rice.edu
Cc:	namedroppers@nic.ddn.mil, mrose@dbc.mtview.ca.us
Message-Id: <9211241347.AA02133@outrigger.mitre.org>
Subject: Re: ietf25 notes - large zones 

It strikes me that the static case is not really an issue.
That is, pick a place to put your company and it shouldn't
matter whether it's .com or .xxx.com for a level.  (I'll
ignore the problem of people perceiving that your company 
isn't important if it's not in the .com domain, a faulty
perception at best).  My guess is that the static case is
the 90% solution.

The problem is with mergers.  Now, how dynamic an area is
this really?  10% or 20% of all domain level names change
during a year?  That seems high, but even if it were at
that level, should a solution be geared for the minority?
It doesn't matter what basis you choose, if you're going
to turn Sperry and Burroughs into Unisys.  You've changed
the entire name, dropped the old name (not even a division
name anymore [sperry.unisys.com]), and no matter what you
started with, it's now drastically different.

Bill mentioned constraining the categories, but I'm not sure
that hard categories are required.  What if 10% of the companies
registered in the wrong place?  Who cares!  They have to
publish their domain name anyway, so it's not like we have
to guess where they registered and need a roadmap for
searching.  Some loose characterization is fine for defining
categories, but I wouldn't worry about whether 99% gets
put in the right category.

	Walt  



Newsgroups: can.domain