[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
dee3 comments on IAHC 19 dec draft
- Date: Sun, 19 Jan 1997 23:48:25 -0500 (EST)
- From: "Donald E. Eastlake 3rd" <dee@cybercash.com>
- Subject: dee3 comments on IAHC 19 dec draft
So much for my typing skills...
=====================================================================
Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com
318 Acton Street +1 508-371-7148(fax) dee@world.std.com
Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA)
http://www.cybercash.com http://www.eff.org/blueribbon.html
---------- Forwarded message ----------
Return-Path: <Mailer-Daemon>
Received: from callandor.cybercash.com (callandor1.cybercash.com) by cybercash.com (4.1/SMI-4.1)
id AA06163; Fri, 17 Jan 97 23:49:56 EST
Received: by callandor.cybercash.com; id XAA12549; Fri, 17 Jan 1997 23:46:07 -0500
Date: Fri, 17 Jan 1997 23:46:07 -0500
From: Mail Delivery Subsystem <MAILER-DAEMON@callandor.cybercash.com>
Subject: Returned mail: User unknown
Message-Id: <199701180446.XAA12549@callandor.cybercash.com>
To: <dee@cybercash.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="XAA12549.853562767/callandor.cybercash.com"
The original message was received at Fri, 17 Jan 1997 23:45:36 -0500
from uucp@localhost
----- The following addresses had delivery problems -----
<iahc-disucss@iahc.org> (unrecoverable error)
----- Transcript of session follows -----
... while talking to mail.proper.com.:
>>> RCPT To:<iahc-disucss@iahc.org>
<<< 550 <iahc-disucss@iahc.org>... User unknown
550 <iahc-disucss@iahc.org>... User unknown
----- Original message follows -----
[ Part 2.2: "Included Message" ]
Date: Fri, 17 Jan 1997 23:49:22 -0500
From: "Donald E. Eastlake 3rd" <dee@cybercash.com>
To: iahc-disucss@iahc.org
Subject: dee3 comments on the 19 dec draft
Well, here are most of my thoughts on the IAHC draft and related
matters. I'm not sure how well organized they are but hope they
are helpful:
PRINCIPLES
There is almost nothing in the draft about overall principles. The
important thing about DNS names is that they are (1) stable and (2)
mnemonic or systematic. (It is also important that the DNS system
is distributed, reliable, etc., but this has almost nothing to do
with the questions at hand.) Systematic parts of the domain name
space are things like *.in-addr.arpa and aren't really a conern in
the gTLDs.
The hierarchial nature of DNS makes stability of a zone effect all
delegated zone. So greater care needs to be takes the closer you
are to root and it is reasonable to take extra care when disturbing
the root zone by adding names. To the first approximation, names
with any significant amount of use can never be eliminated from the
IETF root zone once they get in it.
The importance of name stability affects many details which have not
yet been decided. For example, it means it is better to charge more
up front and less per year for subsidiary name registration and to hold
off on deleting a name if any renewal fee hasn't been paid for a while.
Stability is advanced as the reason for the 60 day wait and I can
see that point. And people can always get third level or whatever
names. But the Internet moves fast and I think that 45 days should
really be enough most of the time. Perhaps when a TLD is first
going to be created, there should be a longer 60 or 90 day hold
after applications for SLDs start being accepted before the zone
goes live to sort out the initial flood and any conflicts therein.
SHARED TLDS
This whole thing with shared TLDs needs to be recognized for what it
is: an experiment. Making *all* the new gTLDs shared turns it into
a radical experiment. If you make *all* the gTLDs shared with a
single entity managing the (gDB) central database, as implied by
some parts of the IAHC draft, would make it, in my opinion, a
foolhardy radical experiment saved only by the fact that NSI will
continue to manage the old gTLDs for some time so there is an
alternative available if it collapses. If there are 7 new gTLDs,
no more than 4 or 5 should be shared and the others should be
"regulated monopoly" zones run by single entities.
I don't doubt that the technical problems can be solved eventually
but there are also enormous administrative difficulties to be
worked out. Shared TLDs mean that data quality will be that of the
worst of the registrars. The devil is in the details here and I
remain very sceptical.
DNS was designed for monopoly control of zones. At some level it
just takes the original single central file and breaks it up into a
hierarchy of zones each of which is still driven off a single text
file. The Postel draft, I think, follows the function of IANA, to
register and allocate the names/numbers used in the IETF
standardized protocols, not to come up with new protocols or the
like. DNS is set up to require a root so, in the absense of
specification by standards activity by the IESG, IANA gets to
direct what is in the IETF recommended root (a few entries such as
in-addr.arpa and ipv6.int have been decided by standards actions).
People generally see the current problems as the crowded .com zone
and the monopoly nature of the zones for which NSI is registrar, so
IANA proposed creating a moderately large number of new exclusively
controlled zones. The IAHC is going well beyond that and proposing
radical new operational procedures that approach those that should
be designed through the standards process.
However, I'm not advocating any unconstrained monopolies. The best
model, I think, would be a public utility comission that could
control the TLD managers price, terms, and conditions of service.
TRADEMARKS
In most cases, phrases like "trademark concerns" in the draft should
be replaced by "name conflict concerns" or the like. Entities gain
rights to names in many ways, such as incorporating and operating
widely under a business name, being born with or adopting a
personal name, etc. There seems to me to be a vast overemphasis on
trademarks in the draft.
TLD "CHARTERS"
I think TLDs should be of different "flavors" to spread out
registrations and decrease people registering multiply. .edu seems
to work quite well. I like .org being uncrowded. Sure, things to
try to spread out .com by overlapping it are good but a tepid
pablum of all indistinguishable TLDs isn't.
The idea of a TLD that only permitted two level registrations in it
is great. That would really be different. I'm not sure how popular
it would be but it is at least a chance of attracting different
registrations. I don't even remember off hand who has been
advocating it but the idea is that you can only register in this
TLD at the third level and the second level names can be most
anything that it is likely more than one entity would want there.
For example, airlines and tv would be good second level names in
this TLD. It think this is such a good idea that, to make it more
attractive and the names shorter, it should have a short nifty TLD
name like "1". So you could have united.airlines.1 and
delta.airlines.1 and abc.tv.1 and nbc.tv.1.
TLD NAMES
Except for a few special cases, all remaining 3 letter combinations
should be reserved. Some are country codes. Then there is the ISO
3 letter standard for languages and a separate ISO 3 letter
standard for currencies and the world wide standard (don't know if
it's ISO or ICAO or what) 3 character standard for airports, etc.
It is a particularly bad idea to give out three letter country
codes without that the permission of that country. However, there
may be some special cases where three leters would be OK. For
example, xx as a country code is, I believe, "reserved for local
use" under the ISO standard so it will "never" be assigned to a
country. No doubt there are similar three letter codes, probably
including xxx. And you could make exceptions for the 3 letter codes
that have already been applied for if it looks like they won't cause
problems.
SLD APPLICATIONs
With the continuing rise in network abuse, most of the requirements
for SLD applications are very good. But I don't see any reason for
"intended use" except in the most general sense. And you want good
contact info in connection with a wide variety of abuse and name
conflict, certainly not just because of trademarks.
PREVIOUS APPLICANTS / LOTTERY
The number of prior applicants/claimants seems pretty small and is
certainly a fixed population. The number who would qualify under
reasonable and objective criterion is even smaller. I have no
problem giving them some priority or even giving some of them a
regulated monopoly position for some time.
I think the lottery is a cop out. The IAHC should be able to define
criterion and wighting a select the best applicants. A lottery
should only be a matter of last resort.
.ARPA, .INT, .EDU, .INFRA
Should mention the arpa TLD. As an infrastructure TLD, it is directly
controlled by IANA. "int" being for international treaty
organization and possibly being run by the ITU is fine, but if so
it should not be also used for intrastructure. If "int" is
not to be controlled by IANA, then all the infrastrucutre stuff in
it should be moved elsewhere. (For that purpose, I would favor just
continuing to use arpa or, if that is politically unacceptable,
added an "infra" TLD or the like for exclusive use of systematic
infrastructure stuff like the IPv6 inverse mapping.)
The draft claims that .edu is a US-specific zone. This is not the
case since their are a number of non-us educational institutions in
.edu. This seems like a nice limited purpose TLD that works. If the US
government decides to stop subsidizing registration in it,
the thing to do would be to get the educational institutions in it
to manage the zone cooperatively.
OUT OF SCOPE & MINOR STUFF
The description on DNS as just doing "name <-> IP address" mapping
is a very impoverished view of the DNS. It doesn't even hint at
such other wide spread uses as MX records. In reality, the DNS is
pretty general and there is no telling what it might get used for
in the future. For example, DNS security makes is possible to use
the DNS for general secure public key distribution.
No mention is made of DNS security. I don't think it has a big
impact but secure zones tend to have a lot more bits in them due to
the size of digital signatures. As .com continues to grow or there
are other zones that big, securing them is going to be a nontrivial
problem. We are talking at least millions of digital signatures and
at least hundreds of megabytes of data.
. is a global trust but lower level zones that are restrictive are a
trust only within that restriction. .edu is a trust only across
qualifying educational institutions. A country zone is only a
trust for that country. Governments are presumed to act in trust
for their country. If a country code zone is being run by a
government agency or a private entity with the blessing or
endorsement of that government, someone who doesn't like the
situation should consider (1) registring elsewhere (there have been
flags of convenience for a long time) or (2) revolution, as their
primary paths. You can always complain to IANA and that probably
won't hurt but if you think IANA can or should try very hard to
push around a government or a government's designated private
agent, you are deluding yourself. This reality isn't affected by
any RFC, no matter what it says. I long ago leared that while
little squiggles of ink on paper may have influence, they don't
actually bind the real world. In any case, RFCs by IANA on IANAs
policies and procedures are only snapshots and do not bind IANA
indefinitely. True, they should be updated if they are no longer
accurate, but not everything that should happen does happen in a
timely fashion.
Great care should be taken in creating regional geographic i/gTLDs.
The only case I can think of right now that seems appropriate is
that if the Council of Europe, which is really close to a
functioning multi-country government, wanted to run a TLD, it
should get .europe or maybe .eur. Probably the way to handle this
is just with a sufficiently restrictive policy that gives these
only to multinational governmental associations that have covered
at least x countries for x years (maybe 8 countries for 8 years?)
and that don't overlap any other TLD endowed multinational
association and where a majority of the member nations specifically
request that a regional domain name be created. Then the
multinational association would control the TLD. I would not
object to a .africa, etc., under such a policy. But I think it is
out of scope for the gTLD question.
Final rules should be careful to say the CORE or the like have
open books and strong requirements to report to the community.
For some matters, it may be useful to define what countries have an
Internet presence and what don't. Something like having at least n
hosts and m routers. I don't think, for example, that a registered
trademark in some random country with no network presence should be
considered the basis for a traemark domain name.