Subject: Re:

From: Richard Sexton <[email-masked]>
Date: Fri, 26 Jul 2002 03:02:10 -0400

Keith Moore <[email-masked]>:
>"alternate DNS roots" aren't part of DNS.  if someone wants to propose
>a URN based on a DNS-like system with its own root zone, they're free
>to do so and see if they can get support for it.   For that matter if
>someone wants to propose a URN based on some other naming system that
>doesn't look like DNS they're free to do that also.
>
>But trying to make "alternate DNS roots" fit into a DNS URI scheme is
>like trying to make OIDs or some other naming scheme fit into a DNS
>URI scheme.   We don't need to do that - there's a separate scheme for
>OIDs.  And trying to do so would make DNS URIs far more complex than
>they need to be -  for no real benefit.  For instance, how do you
>assign names to the alternate roots?

By specifying the root name as a prefix?

I agree that alternate roots are not part of DNS as long as you
contrain your universe to be the ICANN/USG published set of DNS
names, but there are other things floating around the net that
do use the DNS protocols and do resolve names for people who
choose to use them.

So, if your universe is legacy DNS then you really have two
choices: consider expaning your universe to include everything
or ratify some scheme to provice some named calculus to the
DNS multiverse that exists today, comtemporary political
views to the contrary.

>And what happens if people want
>to set up their own registries of names for roots and assign separate
>names to the alternate roots which c...

You can't force people to interoperate. But those who do are
at an advatage. So be it.

---

From: Dave Crocker <[email-masked]>
Date: Fri, 26 Jul 2002 10:06:18 -0700

>By specifying the root name as a prefix?

That does nothing more than define a (new) single root, on top of the set 
of alternate DNS naming systems.

Hence, it violates the model that the alternate root efforts claim to 
support, namely one of independence.

>contrain your universe to be the ICANN/USG published set of DNS

That is like saying that mars is not part of earth, as long as you 
constrain your reference to this planet.

The DNS has some definitions associated with it.  One of them is a single 
root and administration of that root has been handled by IANA/ICANN since 
its inception.

The alternate root activities chose to work independently of the 
established DNS.  They were free to do that and are free to continue to do 
that.

What they are NOT free to do is claim that, somehow, there is any 
obligation to impose a coordination effort between them and the IANA/ICANN 
DNS.  Laying a naming and registration system on top of the set of 
different DNS-like services would constitute such an imposition.  It would, 
in reality, be defining a new root.  One that brings the set of alternate 
roots under a single, coordinated naming and registration scheme.

Independence of naming is independence of naming.  If they want a URI, they 
should define one.  For themselves.  They should not insist on post hoc 
integration with the IANA/ICANN root.

d/

----------
Dave Crocker <mailto:[email-masked]>
TribalWise, Inc. <http://www.tribalwise.com>
tel +1.408.246.8253; fax +1.408.850.1850

---

From: Keith Moore <[email-masked]>
Date: Fri, 26 Jul 2002 13:41:40 -0400

> By specifying the root name as a prefix?

great.  then people can start arguing about who gets to maintain the
set of names for ... er...  what were formally known as roots.   
most of us have better things to do with our time.

> do use the DNS protocols and do resolve names for people who

there are other protocols on the net than those defined by IETF
standards, too.  the fact that they exist does not compel IETF to
endorse them.

Keith

---

From: Caitlin Bestler <[email-masked]>
Date: Fri, 26 Jul 2002 16:49:48 -0500

On 7/26/02, Keith Moore wrote:

>> >"alternate DNS roots" aren't part of DNS.  if someone
>> >wants to propose a URN based on a DNS-like system with
>> >its own root zone, they're free to do so and see if
>> >they can get support for it.   For that matter if
>> >someone wants to propose a URN based on some other
>> >naming system that doesn't look like DNS they're free
>> >to do that also.
>> >
>> >But trying to make "alternate DNS roots" fit into a DNS
>> >URI scheme is like trying to make OIDs or some other
>> >naming scheme fit into a DNS URI scheme.   We don't
>> >need to do that - there's a separate scheme for OIDs. 
>> >And trying to do so would make DNS URIs far more
>> >complex than they need to be -  for no real benefit. 
>> >For instance, how do you assign names to the alternate
>> >roots?
>> 
>great.  then people can start arguing about who gets to
>maintain the set of names for ... er...  what were
>formally known as roots. most of us have better things to
>do with our time.
>

Or you could avoid the entire mess, by simply placing any
alternate "root" that you want to use inside the scope of
a DNS domain.

You have to register the name, and all of the references
are ever so slightly longer.

But it sure is a lot simpler for everyone else.

In particular,  why should names that *are* part of the DNS
hierarchy be made longer?

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 29 Jul 2002 08:50:37 +0200

> standards, too.  the fact that they exist does not compel IETF to

Amusingly, Richard has, by suggesting that we should name the 
"alternate roots", just discovered why the whole "alternate root"
story is nonsense.

Since the DNS is a hierarchical namespace, and since trees have one
root, if you add "alternate roots", you then discover that you have 
to uniquely name them, i.e. insert a new unique root "above" the various 
"alternate roots". 

Or to put it another way, if we need several naming authorities, one for
each "alternate root", we're going to need a naming authority to uniquely
name those naming authorities.

Funny how you can't change mathematical facts, isn't it?

However, back in the real world, the existing unique root works just fine.

   Brian

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Mon, 29 Jul 2002 11:54:20 +0200

Truly common trees have one single root, but how many roots the forest?
(BTW some trees have more than a single root. Some even have no root).

The forest is the international data network name space, de facto created 
in 1977 at FCC's initiative, and then under FCC and States controlled or 
direct monopoly interconnect agreements, within the frame of ITU (CCITT at 
the time), ie the "Intlnet" as sometimes nicknamed.

That "forest" delegated the ARPANET sub-namespace ".arpa" in 1983/84 with 
provisions for the ccTLD support, possibility to extend to new 
sub-namespaces (multiorganization TLDs),  then current root "bouquet" 
interconnect (com, net..) plus its own ones (edu, gov, mil..), resulting 
into the difference between internal sub-namespaces administration (legacy) 
and related sub-namespace registration (ccTLDs and foreign nets) to avoid 
conflicts.

This led to the reversed order, right to left on dot separated labels, and 
to the need of the final dot, as a reversal indicator (also understood as 
the global root indicator), to avoid confusion with the ITU X121 and E.164 
namespaces.

The resulting constraints and possibilities for the Internet have been 
fully documented by Jon Postel in the RFC 920 (Oct 1984). This insured a 
clean and secure management of the ".arpa" sub-namespace with no conflicts 
with its neighbors during 18 years - until ".biz" and the ENUM eventual 
support (it was an Internet non directly supported part of the 1984 deal). 
An exegesis of RFC 920 is a must for a namespace understanding.

It is true that those who were no part to that "delegation" process (then 
perceived as a standard private network gateway tuning) only see the 
result. All the more than the Intlnet system went X121 permitting less 
developed technologies to digitally support numeric names (X.25/75/E.164). 
A confusion is also the wrong use of the "alternate roots" wording for 
extended copies of the ".arpa" sub-namespace root which focuses the debate 
on side cross-root possible conflicts instead of the considering the whole 
namespace issue.

A root name - as coined at the CCC (common carrier club) in 1977 - is the 
mutually registered name of a sub-namespace into the global namespace 
(creation) and the other sub-namespaces (interconnect): ex. ".arpa", E.164, 
".fra", ".com", ".net", etc.. The confusion we often meet is that the 
".arpa" tree hides us the forest. And we confuse the interconnect roots 
with the main root. Let think to water trees species with multiple roots.

The problem we face today is that many people, organizations, states have 
legitimate rights and,more importantly, have needs for their own 
sub-namespace with the importance the technology development permitting to 
evade from digital oriented addressing restrictions, and the importance 
taken by the brainware (ways the users use a system), the enlarged common 
use of the IP networks all over the planet and the availability of a common 
shared IP network infrastructure.

The DNS is a good candidate to assume a global namespace unified 
"supervision". But the DNS has important architectural/operational lacks 
(management, backup, security, stability, inter network technologies 
support, capacity, lack of extended services hooks, etc.).

IMHO the question are:

1. is the DNS to be the universal global root (forest) URI resolver? Or a 
new "real names" by MS?
2. if yes what are the DNS+ and DNS.2 specifications to be?
3. iteratively what are to be the utilization architecture specifications 
to fully take advantage from them?
4. what is the impact on the URI semantic?
5. as the URI is the network (and our entire world) command line, what are 
iteratively the impact on software/brainware, technical opportunities, 
specifications for open network wide distributed processing?

IMHO these are questions worth to investigate and to work on?
Sorry to have been long on this.
jfc

---

From: Einar Stefferud <[email-masked]>
Date: Mon, 29 Jul 2002 02:11:57 -0700

Hello Brian E Carpenter -- and all ...

There is a very simple solution (which ORSC has employed now for
several years) to your phantom problem (see your message below).  It
is part of our primary purpose to solve this problem, rather than
intensify conflicts in some kind of power grab, or fight over who is
rightly designated to be in control of the use of the Internet.  In
our view, the Internet users are and should be in control of their
use, and should accordingly have a choice in the matter.

So, it should be no surprise that all Internet users do have a
choice, in that their choice of root service provider is lodged in
the root service IP address that they, in their free individual
wisdom, choose to put in their own password controlled "root server
entry field" in their own computer's TCP/IP tables.

They exercise this choice by "voting early and often" every time they
use their chosen root service to resolve a DNS name.

There is no law, and no contract with Internet users, that might
force them to only use the ICANN root servers.  In fact, if you look
around the Internet, you will see that every Intra-Lan and Extra-Lan
has its own private root servers with subsets of the total set of
available TLDs.  This is all part and parcel of the design of the
Internet and the DNS service.  The users of the Internet are free to
decide these issues for themselves, with no global design or control
scheme in place to control individual user's choices in this matter.
That is why every attached computer or Local Area Network with a NAT
box has total control over this matter of choice.
Go read your copy of the Internet DNS Standards.

That some uninformed users believe that the ICANN root is the only
root, is a myth propagated by those who are interested in denying
access to the rest of the net to those users who are ill informed.
That ORSC does not have the marketing resources to overcome this
ignorance may or may not be unfortunate, but this fact does not
change the fact that the ORSC root service exists and is used without
causing any problems for those who are unaware of it, as many on this
list seem to be unaware.

We simply do not deny the existence of ICANN, and strive mightily to
avoid all possible conflicts among the names of honored TLDs so as to
avoid conflicts among the combined ICANN and ORSC root's TLDs.  ORSC
has resolved a large number of conflicts in the past, and stands
ready to help resolve any new conflicts, and also, of course, strives
to discourage new conflicts from arising.  We cannot say the same for
ICANN.  (And neither can ICANN;-)...

ORSC was highly successful in this effort, until ICANN chose to
collide with one of our ORSC pre-existing TLDs, and the refusal of
ICANN (and others such as IETF, IAB and ISOC) to recognize this
reality and to act responsibly to resolve the conflict has led to its
continued existence, which diminishes the value of the conflicted TLD
name to all parties to the conflict.  Conflicted names simply have
lesser value, for what I assume are obvious reasons.

So, in spite of the ICANN Mission to avoid conflicts among TLD names
in the Internet DNS root system, ICANN is the only party that has
deliberately chosen to knowingly create a conflict in the aggregated
collective root.

ORSC has worked hard to avoid all such conflicts by negotiation and
coordination, and has been successful with all instances except with
ICANN, while ICANN denies our existence and the existence of all our
other TLDs which may well exceed in number all the TLD names in the
ICANN root.  This, in our ORSC view, violates all aspects of the
concept of mutual coordination and conflict avoidance.

ORSC accepts the concepts of "a single composite root" which is
possible if the involved parties will all recognize each other and
deal with each other fairly and openly, but ORSC does not accept the
arbitrary and capricious central control and conflict generation
policies of ICANN, which installs in the Internet a Single Point of
Failure, in place of coordinated stability with distributed
architectures such as the original Internet, which was intentionally
designed to be free of any single points of failure.

ICANN (and apparently IAB and IETF) appear to be dedicated to having
some kind of central control and accompanying single point of
failure.  ORSC is dedicated to maintaining a coordinated conflict
free DNS ROOT, and expects that in due course, ICANN, IAB, IETF and
ISOC might see the light and find ways to negotiate a resolution of
the only existing TLD name conflict in the present situation.

In our ORSC view, the responsibility for negotiating a resolution
lies directly with the two conflicting registries, or with their
superior organizations.  ORSC does not directly control the
registries that it recognizes, and so expects them to directly seek
resolution of any conflicts that might arise.  ICANN TLDs exist in a
top down control structure and we must so assume that the lack of
interest of the ICANN sponsored conflicting registry is directed by
ICANN, which casts a blind eye on the entire problem, pretending that
the conflict does not exist.

If you don't know what this conflict is, you need to do a bit of
research, and also take note that if you are unaware of the single
existing TLD name conflict, then you have no grounds to claim that it
causes any harm to anyone you know.  In the ORSC view, the conflict
harms the conflictees more than anyone else, and in our ORSC view it
is the ICANN Board of Directors that has asserted itself in a
deliberate act to knowingly create the only existing conflict.

The BoD was clearly informed of the impending conflict, but chose to
ignore the notice without any response there-to.  In the face of such
denial, ORSC has chosen to take no action to resolve the conflict
until ICANN (and IETF, IAB, and ISOC) take public notice of the fact
of their conflict creation.

It is my personal opinion that the ICANN sponsored conflicting TLD
registry would and should have a strong interest in resolving the
conflict, but that ICANN has instructed it to avoid any form of
recognition and thus to avoid any activities that might lead to
resolution of the conflict.

So, at this point, the ball is in the ICANN court, since ORSC has
always been available and ready to help work on finding an equitable
resolution any time that ICANN and its chosen conflicting registry
might seek to operate in some honorable way to seek a resolution.

I am certain that the cost of resolution will be vastly smaller than
the wasted value caused by pretending that the conflict does not
exist.

In the meantime, the ORSC root is in use by a vast number of Internet
Users, with equal or better stability than the ICANN root, and ORSC
users can see the entire Internet because we include all ICANN TLDs
in our collective ORSC root servers.

After all, all TLDs should be visible to all Internet Users who wish
to see them.
ORSC fulfills this desire in the marketplace, and ICANN does not.

So who do you suspect does the better job?

Cheers...\Stef

---

From: Einar Stefferud <[email-masked]>
Date: Mon, 29 Jul 2002 02:11:57 -0700

Cheers...\Stef

---

From: Einar Stefferud <[email-masked]>
Date: Mon, 29 Jul 2002 02:11:57 -0700

Cheers...\Stef

---

From: Einar Stefferud <[email-masked]>
Date: Mon, 29 Jul 2002 02:11:57 -0700

Cheers...\Stef

---

From: Einar Stefferud <[email-masked]>
Date: Mon, 29 Jul 2002 02:11:57 -0700

Cheers...\Stef

---

From: [email-masked]
Date: Mon, 29 Jul 2002 12:18:06 -0400

> ICANN (and others such as IETF, IAB and ISOC) to recognize this

So what you're saying is that if there's no coordination, there's a problem.

Unfortunately, if you assume the existance of such coordination, what you
have is *one root with multiple registrars*.  We already know THAT model
more-or-less works in the ICANN root.
-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech

---

From: Peter Deutsch <[email-masked]>
Date: Mon, 29 Jul 2002 19:15:28 -0700

g'day,

> more-or-less works in the ICANN root.

Works? Yeah, maybe for some definition of "works", in that
people can give money to more than one entity to get a
string into .COM, but is that really solving the problem
ordinary users actually want solved? Last time I went to get
a new domain name, I was down to either choosing words from
an Old English dictionary (I went with "gydig", which means
I think I'm either "insane, or touched by the Gods" :-) or
explaining to folks "No, that really is a domain name, even
if it doesn't end in .COM". When I read "works" it sort of
reminds me of that old saw about "the operation was a
success, but the patient died".

I've long suspected that when this debate flares up
periodically and folks get all hot under the collar about
DNS it's to a large degree because the camps are tossing
"apples and hand grenades" over each other's shoulders.
There is much heat and light and fruit salad flying about,
with much impunging of motives and declarations of technical
incompetence, but not much acknowledgement that there might
be an alternate type of oblate spheroid that might be worth
thinking about other than the one you're currently tossing
around. 

The traditional IETF view is that the DNS is a stable
mechanism for providing an all-important layer of
indirection between names and IP addresses. In this view,
the DNS is a critical infrastructure component of the
Internet, so providing a single, stable root (and thus a
homogenous, consistent view of the world from anywhere on
the net) is essential. To those who argue for improving the
utility of the DNS as a "directory service", the reply is is
that the DNS is *not* a directory service, so it doesn't
matter that it isn't searchable, or that in particular,
users can't ask for and expect to get any name string they
might want. Fracturing the DNS into multiple services would
clearly degrade its usefulness for its original, intended
purpose, so it should be enough to say "look, the DNS isn't
the service you want it to be, because it's not the service
you think it is. You want a user-friendly directory service?
Go build one, but keep your mits off the DNS, since breaking
it will have consequences you wont acknoweldge or can't
forsee".

I have a lot of sympathy for this point of view. I want my
email to resolve as much as the next person. And I would add
that I certainly don't think anyone is entitled to reap a
.COM-like fortune just because they can set up a couple of
DNS servers and hijack a few million TLD registrations. And
yeah, there are a few folks selling snakeoil involved in
this debate.

But...

An alternative bite of the apple (which obviously gets short
shift in this community) is that like it or not the DNS is
currently being used as a de facto directory service by many
of its users and they expect certain things from it that the
DNS technical community is not providing. In particular and
most critically, believers in this point of view feel
strongly that users should have far more choice in terms of
available names than they currently have, due in large part
to "artificial" scarcity in TLDs.

In this world view, the current state of the DNS namespace -
in which the majority of TLD users live in .COM, and the
vast majority of English (and French and a few other
languages) dictionary strings are already taken - is a
terrible disservice to users and thus is something to be
"repaired". The prevailing view here is that "If it can't be
fixed with the current ICANN-controlled structure then it's
time to fracture the root and open things up to a little
healthy competition".

Now, note that I didn't say that this view is right and the
IETF is wrong, so please holster your weapons for a moment.
I'm also happy to agree, if anyone wants me to, that these
are "political", not technical considerations, although I
don't agree with the coda, which runs something like "and is
thus out of scope for the IETF". I happen to think we're
collectively acting a bit like the guy who allegedly killed
his parents and then argued for leniency because he was an
orphan.  We've argued for a while now that the political
issues surrounding DNS should be taken up with ICANN, and
this position has left us with a mess. The IETF has punted
such questions as "how many more TLDs?" and "When?" as out
of scope, and now wonder why those morons don't realize the
harm they might do to DNS in the name of more user choice.
Well, I personally don't like to complain about my users
hammering in screws with a hammer if I can't offer them some
form of screwdriver in its place. 

Maybe there really *are* two different debates here. We seem
to be guilty of simultaneously complaining about the threat
inherent in attempts at building multiple roots, while
telling folks to keep their mits off the current root. Now,
this position makes sense only if there's really a single
possible outcome here (keep the current DNS name resolution
functionality with no extensions), but what if what those
other folks are doing really doesn't belong in the current
DNS tree anyways, but is useful to some folks? Shouldn't we
be *encouraging* them to take their work off out of the DNS
tree?

If we agree that the DNS works eminently fine for its
intended purpose, but would be threatened by instability if
we were to allow the sort of
innovation/experimentation/fooling around that some folks
would like to see, then let's pack 'em off to "directory
service land", where people operate additional services to
serve communities of size n, for n less than the whole
Internet. Now, if they did that couldn't we even let them
talk about what hooks might be useful to allow communication
from such services back on planet Internet? This would seem
to bring this debate back to something like "how do we tie
together multiple, sometimes disparate services using a
single communications system"? Hopefully, we can agree that
such a question is in scope for this community, whereas
"when do we get more TLDs" is clearly so far out that it
just makes us tired yelling about it....

				- peterd

-- 

---------------------------------------------------------------------
    Peter Deutsch                       [email-masked]
    Gydig Software

   That's it for now. Remember to read chapter 11 on the
   implications of quantum mechanic theory for time travel
   and be prepared to have been here last week to discuss.

---------------------------------------------------------------------

---

From: John C Klensin <[email-masked]>
Date: Mon, 29 Jul 2002 23:44:52 -0400

Peter,

IMO, a good summary of some of the real issues.   Let me add one
more piece of the story, which I'm surprised you didn't comment
on.  Several of us have made, and are making, significant
efforts to get directory-like "above DNS" services in place to
address the clear user need for more and better naming.  Those
efforts have gotten good responses from some parts of the
community.  

But, from others, including (apparently) most of the "alternate
root", "multiple root", and "superroot", crowds, the response is
"more TLDs" or "more root choices, but ICANN is expected to
cooperate and accept whatever names we come up with first", or
things that are semantically indistinguishable from "the only
problem with a single root is that I should be in charge, not
ICANN".  And that leads some of us to start wondering what
species of snake is being used to produce all of that fragrant,
multipurpose, oil.

regards,
     john

--On Monday, 29 July, 2002 19:15 -0700 Peter Deutsch
<[email-masked]> wrote:

>> > ORSC was highly successful in this effort, until ICANN
>> > chose to collide with one of our ORSC pre-existing TLDs,
>> > and the refusal of ICANN (and others such as IETF, IAB and
>> > ISOC) to recognize this
>> 
>>...
 
>...

---

From: Peter Deutsch <[email-masked]>
Date: Mon, 29 Jul 2002 21:09:16 -0700

Hey John,

John C Klensin wrote:
> on....

Well, I *was* trying to keep it short, since I've an
undeserved reputation for *long* postings... ;-)

> ...  Several of us have made, and are making, significant

Hmm, do you have a pointer for this? 

> species of snake is being used to produce all of that fragrant,

I was actually making a conscious effort not to get into
this aspect of the debate, since I believe that it's been
too emotionally charged and in such an atmosphere it's too
easy to paint everyone with the same brush. There are
certainly a few folks in the alternative root movement that
I would not want to share a cabin with on a long sea voyage,
but I also like and respect a number of folks who happen to
think multiple roots are an eminently fine idea. Frankly, I
don't have any problem with the concept myself, but I can
justify this to myself now I've concluded that it's an
"apples and hand grenades" issue. I don't want to break the
legacy DNS, I just happen to want to do stuff that the
legacy DNS folks don't want in their root.

I know this idea makes a lot of folks spit coffee all over
their keyboards, but all it really means is that the
fundamentals of DNS are more useful than the basic service
people are using it for right now. So maybe we need to be
talking about extending the protocol, maybe even asking for
a new port number, but in any event I believe it's time the
IETF recognizes that it's time to move beyond what are
really the politics of ICANN and focus on the technical
issues surrounding extending the current technologies to
make them more useful. If we do that without touching the
legacy systems for now, fine but this would imply the need
to set up some alternative roots for experimentation and
proof of concept. Pity that such a notion has become *so*
overloaded with political implications but it's time to look
beyond that, or sit back and tell our users that Google is
as good as it's going to get....  ;-)

				- peterd

--

---

From: Randy Bush <[email-masked]>
Date: Mon, 29 Jul 2002 21:45:27 -0700

you're right.  there are working alternat roots.  e.g. 1:105/42 in fidonet.
and even fidonet learned the lesson of broken namespaces.

but, as an experiment, do us all a favor, and send and receive your email
from/to an alternate and disjoint namespace and see how it works.

randy

---

From: [email-masked]
Date: Tue, 30 Jul 2002 00:46:15 -0400

> a new domain name, I was down to either choosing words from

The problem here is that .COM is a single level, and over-full
with stuff that shouldn't be there.  There's no way you can pile
21 million (or whatever it is) names under one thing and avoid that.

That's a different issue than how many roots there are.
-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech

---

From: "Ole J. Jacobsen" <[email-masked]>
Date: Mon, 29 Jul 2002 22:08:16 -0700 (PDT)

Uncle Stef,

What is this "choice" crap???

Internet users, like my father and your daughter, for example, have no
idea what the DNS is and even less of an idea of how to hack their
computer to accept "alternative roots" for the sake of offering choice.
My Mac has this nice thing called a "Setup Assistant". The PC probably has
something similar. But it never asks me if I want to use non-official
domain names. (nor should it).

This is a fantasy you guys have invented in the name of policical choice,
technically it's completely silly, flakey and just plain dumb.

Get real! Please.

Ole

Ole J. Jacobsen
Editor and Publisher
The Internet Protocol Journal
Office of the CTO, Cisco Systems
Tel: +1 408-527-8972
GSM: +1 415-370-4628
E-mail: [email-masked]
URL: http://www.cisco.com/ipj

---

From: Joe Touch <[email-masked]>
Date: Mon, 29 Jul 2002 22:45:15 -0700

> What is this "choice" crap???

Not that I think it's a good idea, but see new.net, e.g.

There's a button which people - like your father - can click and do 
damage to their own DNS configuration. :-)

Internet users may have no idea what the DNS is, but their 
configurations are being hacked already, perhaps without their 
knowledge, to consult these alternate roots.

It happens when you use DHCP with an ISP that uses one of these 
alternate trees - unless you run your own server, any request that you 
delegate can get shunted.

It also happens when you run software for configuration, ala 
'install-me' CDs from Juno, or clicking as above.

Joe

---

From: Einar Stefferud <[email-masked]>
Date: Tue, 30 Jul 2002 01:38:33 -0700

Yes,  Valdis, we (or ORSC) clearly observe that we can create a 
conflict free composite DNS root by using coordination tools to 
assure that conflicts are resolved for the benefit of the users of 
the whole internet.

We are waiting very patiently for ICANN and IETF to figure this out.

So, we are waiting;-)...\Stef

At 12:18 PM -0400 7/29/02, [email-masked] wrote:
>Content-Type: application/pgp-signature
>
>Attachment converted: Viking5:Untitled 1 (????/----) (00004192)

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Tue, 30 Jul 2002 10:50:29 +0200

At 05:44 30/07/02, John C Klensin wrote:
>Several of us have made, and are making, significant efforts to get 
>directory-like "above DNS" services in place to address the clear user 
>need for more and better naming.

Dear John,
from this effort don't you think it could be time to review what should be 
DNS+ specs, I mean all the functions we should investigate and specify to 
be added "above DNS"? IMHO the "root" of that anlysis is to be what the 
user may expect/be confronted to, and this is to start with the URI (but I 
feel you dislike the idea?).

>"the only problem with a single root is that I should be in charge, not 
>ICANN".

I think this is a good summary, while my reading is more real and user 
oriented than your teasing:-). The DNS has been designed to be the 
Internet's namespace management tool, not the global namespace management 
tool it is used as a substitute for - hence the problems for field 
operators. Without going back to the ".arpa" delegation etc. just look at 
the continuity issue with real facts of today: China, EU,  OSRC, New.net, 
E.164, X.121, nomenclatures, etc..

Dont't you think, folks, that time has come to review the golbal 
architecture of the DNS and to extend it to the consistent support of a 
reliable global namespace DNS.2?  After 20 years is that necessarily 
stupid? Does proposing investigating it makes necessarily me a fool?

But, please every sides, this should be totally clean sheet. jfc

---

From: John C Klensin <[email-masked]>
Date: Tue, 30 Jul 2002 04:56:59 -0400

Peter,

--On Monday, 29 July, 2002 21:09 -0700 Peter Deutsch
<[email-masked]> wrote:

>> IMO, a good summary of some of the real issues.   Let me add
>> one more piece of the story, which I'm surprised you didn't
>> comment on....
> 

The two of us in combination... :-)  But I won't even claim my
reputation in that area is undeserved.

> Hmm, do you have a pointer for this? 

In no particular order, and at the risk of turning this into a
technical discussion (horrors)...

  draft-klensin-dns-role-03.txt
  draft-klensin-dns-search-04.txt
  draft-mealling-sls-02.txt
  draft-xdlee-cnnamestr-00.txt

And you might have a look at the minutes of a Salt Lake City BOF
called "IRNSS".  Your comments would be very welcome on any of
this.

>> But, from others, including (apparently) most of the
>> "alternate root", "multiple root", and "superroot", crowds,
>> the response is "more TLDs" or "more root choices, but ICANN
>> is expected to cooperate and accept whatever names we come up
>> with first", or things that are semantically
>> indistinguishable from "the only problem with a single root
>> is that I should be in charge, not ICANN".  And that leads
>> some of us to start wondering what species of snake is being
>> used to produce all of that fragrant, multipurpose, oil.
> 
> easy to paint everyone with the same brush. 

That is reasonable, and I was trying to be careful to not do so.

> There are

I think that both the legacy DNS and virtually anything built on
the DNS protocols (fundamentals) is unsuitable for most of that
stuff (which is what the first doc cited above is about), but I
could be wrong, especially if I am focusing on the wrong set of
problems/ requirements.

> proof of concept. 

Back when I believed that the implementations and practices were
the problem, I did a piece trying to explore moving toward a
new, replacement, DNS Class with less legacy baggage.  Such a
Class could, at least as I understood it at the time, imply a
completely different root, tree structure, and administration.
If you want a pointer to a recently-updated version of that one,
see draft-klensin-i18n-newclass-02.txt.  But I no longer believe
a useful solution to the problems I was interested in lie in
that direction.

> Pity that such a notion has become *so*

Agreed.
regards,
    john

---

From: Einar Stefferud <[email-masked]>
Date: Tue, 30 Jul 2002 02:01:24 -0700

Hi John, Sorry to say, you also ware quoting ORSC folk as saying 
things that they have not and will not say.

You opinions are very welcome, but inaccurate quote reporting is 
beyond the pale.

So, I here clearly state that your implied quotes are not correct.

Cheers...\Stef

---

From: Einar Stefferud <[email-masked]>
Date: Tue, 30 Jul 2002 02:04:58 -0700

I agree that the "directory services" field is not what ORSC is working on.

I also agree that if someone wants to solve "the directory service 
problem", they are not going to get any opposition from me.

Just please do not convert the DNS into a directory!   Cheers...\Stef

---

From: Einar Stefferud <[email-masked]>
Date: Tue, 30 Jul 2002 02:11:48 -0700

I do, but too many of my corespondents cannot be reached via ORSC 
rooted domains, so I carefully locate my mail services such that I 
can reach and be reached via The Whole Internet.  It can be tricky, 
and only a few mail servers are so far able to make it work, but that 
is because so many choose not to make it work, for their own reasons.

Please note that ORSC has no aspirations to control the Internet, and 
so ORSC is willing to continue in this state as long as it lasts.

Cheers...\Stef

---

From: Einar Stefferud <[email-masked]>
Date: Tue, 30 Jul 2002 02:16:44 -0700

ORSC does not support what NEW.NET is doing either, but please note 
that this has nothing to do the lack of cooperation that ICANN exudes.

NEW.NET is just as hard to deal with as is ICANN;-)...

NEW.NET is just following the lead of ICANN, along with a cast of millions.

Enjoy;-)...\Stef

At 10:45 PM -0700 7/29/02, Joe Touch wrote:
>alternate trees - unless you run your own server, any request that 
>you delegate can get shunted.
>

---

From: John C Klensin <[email-masked]>
Date: Tue, 30 Jul 2002 05:29:31 -0400

--On Tuesday, 30 July, 2002 02:01 -0700 Einar Stefferud
<[email-masked]> wrote:

> Hi John, Sorry to say, you also ware quoting ORSC folk as
> saying things that they have not and will not say.

I was not quoting ORSC folk, or anyone else specific.  I think I
made that fairly clear, and certainly intended to do so.  I was
quoting and referring to various remarks I have heard from time
to time from various individuals and groups who have advocated
alternate or independent roots.

Please do not assume I am saying anything I did not say.
 
> You opinions are very welcome, but inaccurate quote reporting
> is beyond the pale.
> 

If they don't apply to the ORSC, then they don't apply to the
ORSC.   If you believe that all of the folks who have advocated
alternate roots are part of the ORSC,...   But such a belief
would be objectively false, given your other statements: I
believe you have also claimed, several times, that the only
conflict --with ICANN or anyone else-- in the ORSC root space is
over one domain.  Unless things have changed dramatically in the
months since I last studied the situation, there were a number
of alternative claims on the name "sex", more on the name "xxx",
and so on.  I have no knowledge or opinion as to whether ORSC is
involved in any of those alternate claims, or whether it has
made a choice.  But there are certainly multiple claims for TLD
ownership in those, and I believe, other, areas.

And that is another piece of the problem with consolidated or
superroots:  They depend on a level of cooperation about the
choice of TLD names that you, I think, assume but that has not
been demonstrated in practice.  As soon as there is more than
one claimant to a particular TLD name, some process is needed to
determine who gets it.  Is ICANN the only possible process for
doing that?  Certainly not.  But the proof that some other one,
even ORSC, is socially or morally better eludes me.

Lest I be accused of more misquotation, I want to examine one
statement you did make.   You said, in part, "...just happen to
include all of the ICANNic TLDs, plus our ORSC TLDs, (except for
one small TLD which was created deliberately by ICANN to create
a conflict..." and then, in the same paragraph, "They simply act
as though we do not exist".  I do not speak for ICANN, and have
not been involved in their internal decision-making on this
subject, but I believe that one of these statements is true and
that both, strictly speaking, cannot be.   I suspect ICANN has
acted as if ORSC does not exist, at least partially because they
have no way to recognize your efforts in favor of any other
"alternate root" claimant (see above).  But, if they are acting
as if you don't exist, then the notion that they would somehow
create a conflictly TLD "deliberately", presumably to make your
existence more difficult, would seem inconsistent at best.  And,
independent of that logical argument, what I think I did see at
ICANN was a (logically-necessary) decision to ignore any
individual claims for prior rights to particular names.  To have
done otherwise, given their theory of operation, would have led
to madness.

regards,
     john

---

From: vint cerf <[email-masked]>
Date: Tue, 30 Jul 2002 08:04:07 -0400

Stef,

how do you propose to resolve a dispute between two parties who want to operate identical TLDs?
Suppose neither party is willing to give in to the other?

v

At 01:38 AM 7/30/2002 -0700, Einar Stefferud wrote:
>Yes,  Valdis, we (or ORSC) clearly observe that we can create a conflict free composite DNS root by using coordination tools to assure that conflicts are resolved for the benefit of the users of the whole intern

---

From: vint cerf <[email-masked]>
Date: Tue, 30 Jul 2002 07:51:25 -0400

At 09:09 PM 7/29/2002 -0700, Peter Deutsch wrote:
>I believe it's time the

peter,

I would suggest that exploration need not require an
"alternate root" if the extension is within the framework
of DNS (new class of object for example). John Klensin
and others have expressed themselves on the merits and
weaknesses of that approach. What is important, I think,
is to avoid the creation of conflicting naming schemes
within a given framework. However, if we begin by asking
the question, "what objects need identifiers that we do
not or cannot now identify?" we might indeed discover 
alternative identifier mechanisms. It would be helpful
for a variety of operational and probably technical reasons
for any such new scheme not to conflict syntactically with
existing ones, I believe. 

The Directory-service notion is one dimension in which
to explore. Keywords are another although thus far they
have understandably required a context in which to be
interpreted since they all appear to have a common and
simply syntax (cf: AOL keywords, Real-Names keywords,
etc). 

The DNS provides a method for associating a relatively
simple syntactic construct with a host on the Internet
(or an internet). These names can be embedded within
the larger construct of URLs to refer to objects and
processes that exist on (in?) those hosts. 

One might want a richer vocabulary for referencing 
objects (cf. Bob Kahn's Handle System) in which the
identifier is associated not only with an object but
also with a variable amount of meta-data about the
object's ownership, accessibility, etc. 

It strikes me as a useful principle to try not to
make things like DNS more complex in seeking to explore
and invent these new concepts if only to avoid making
existing and relatively simple things more complex. 
Domain names seem to work pretty well for hosts and
WWW URLs, but in the latter case, a broken link caused
by the disappearance of an object at a host or even the
host itself makes the longevity of the binding less than
satisfactory. Perhaps other methods of expressing and
implementing the binding of name to object would be
useful, but I would argue against making DNS more complex
to accommodate, if this extension also made the pre-existing
use of DNS more complicated. 

The experience with the notion of Internationalized Domain
Names has made clear how dependent DNS is on the simplicity
of the USASCII encoding and how hard it is to make what one
might have thought would be a simple extension to a richer
range of character encodings. 

So to reiterate, I believe it would be a very useful exercise
to catalog the various name/thing binding notions and to try
to articulate what additional functionality we might wish to
achieve, then examine options for achieving them without 
breaking or making unnecessarily more complex our existing
binding tools. That view suggests that "alternate root" may
not be the right starting point, if by that term one means
alternate root of the same DNS mechanism we already have. 
The syntactic and potential semantic confusion (e.g. using
an identifier in the wrong context) does not seem worth the
price. However, a new identifier space whose context can be
clearly placed through syntactic clues, might provide a 
platform for exploration without or at least with less disruption.

Vint

---

From: Lloyd Wood <[email-masked]>
Date: Tue, 30 Jul 2002 14:34:09 +0100 (BST)

> I think this is a good summary,

the only problem with a single root is that anyone but ICANN should be
in charge, surely?

L.

go Karl!

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 30 Jul 2002 08:53:31 -0500

on 7/29/2002 9:15 PM Peter Deutsch wrote:
> ordinary users actually want solved?

> "repaired".

There is no question that the best way to silence the bulk of the valid
criticism would be to make ICANN an administrative function instead of a
policy function. IOW, they should be handing out TLDs, rather than
deciding which TLDs are handed out.

However, a quick review of the first-round delegations has shown that
there are still a significant number of policy issues that have to be
resolved first -- issues such as sunrise, delegation escrow and recovery
are still not resolved. I'm willing to give them a bit more time to
resolve these issues, but at some point they need to make the cut. Another
of my personal disappointments is that they have not established a
timeline or even a schedule for this, to my knowledge.

I do not believe that any other organization -- neither the alternate root
providers nor the alternate TLDs -- has these interests at heart. Anybody
that wants to perform the administrative role would also have to deal with
these issues, regardless of whether they admit it or not. None of them
have even admitted it yet, and therefore lack essential credibility.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: "Stephen Sprunk" <[email-masked]>
Date: Tue, 30 Jul 2002 09:56:39 -0500

Thus spake "Einar Stefferud" <[email-masked]>
> In fact, if you look around the Internet, you will see that every
> Intra-Lan and Extra-Lan has its own private root servers with
> subsets of the total set of available TLDs.

Very few corporations (and no ISPs, AFAIK) run their own roots.  Those that do
usually simply replicate the ICANN root for availability purposes.  Even if
there were a proliferation of root servers, that wouldn't help end users since
end users need recursive servers (which roots can't be by definition).

I'm hardly a DNS expert, but I am not going to point *my* servers at a root run
by people who can't even use the terminology properly.

> access to the rest of the net to those users who are ill informed.

If by "some" you mean "all but about fifty kooks", sure.  I'm willing to bet
over 95% of Internet users can't even tell you what the IETF or ICANN *do*, much
less any reason they should be unsatisfied with them.

> causing any problems for those who are unaware of it, as many on this

If your alternate existence does not cause problems, it's only because nobody
uses your service.

> This, in our ORSC view, violates all aspects of the

ICANN's job is to provide the single authoritative root; this root has no
conflicts, and it is therefore not subject to mutual coordination or conflict
avoidance.  You're arguing a moot point.

> So who do you suspect does the better job?

In life, the best technical solution does not always win.  It's entirely
possible that ORSC may be more reliable, more user-friendly, more democratic,
and more cost-effective -- that's irrelevant.  Whoever controls
A.ROOT-SERVERS.NET is the root.

S

---

From: [email-masked]
Date: Tue, 30 Jul 2002 11:01:35 -0400

> assure that conflicts are resolved for the benefit of the users of 

Explain how that's "multiple roots" rather than "one root with multiple
registrars"?

(For the record - I have no problems with "one root with multiple registrars",
and think it's an idea that perhaps should be pursued.  It's even a solved
problem on the technical side - we've been doing it for .COM for a while now).

---

From: Keith Moore <[email-masked]>
Date: Tue, 30 Jul 2002 11:59:57 -0400

> deciding which TLDs are handed out.

in general, the more popular TLDs you have, the more load you get on the 
root servers from cache misses on the NS records for those TLDs.  
(seldom-used TLDs don't count because hardly anybody every queries them...)

and *someone* has to decide which TLDs are "handed out".  otherwise anyone 
could have a vanity TLD, the DNS would collapse to a flat space, and the
root servers would have to handle all queries.  

Keith

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 30 Jul 2002 11:19:05 -0500

> (seldom-used TLDs don't count because hardly anybody every queries them...)

OTOH, TLDs that are popular get cached and stay that way.

The real mitigating factor is the number of agents and queries-per-second,
and that doesn't seem to be at risk of exponential growth anytime soon.

In general you are right, but in practical terms, there isn't much
difference between 20, 200 or 2000 TLDs, as long as they don't also
introduce, say, a billion phones to the service network.

> and *someone* has to decide which TLDs are "handed out".

Pull-side economics can make this decision. If people think there are
sustainable markets for .auto and .car then there's no reason not to let
them both out of the bag.

The really hard policy matters are things like deciding how delegations
should be preserved if one or both of those go under.

> otherwise anyone 

That assumes obtaining a TLD would be simple and cheap, which it shouldn't
be. High fees, escrow, etc., should keep that from happening.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 30 Jul 2002 09:27:09 -0700

>deciding which TLDs are handed out.

ICANN has managed to limit itself to policy issues that are essential for 
doing that administration.  (Whether the specific choices of policy have 
been the right one is not my point.  Scope is my point.)  All of those 
policy topics have derived from real and pressing issues that directly 
effect stability and utility of the DNS.

So if ICANN does not do that policy work, who does?  And why is it somehow 
better to have that work done elsewhere?

The challenge, here, is to move beyond a rhetoric of theories and pay 
attention to the pragmatics.

d/

----------

---

From: Keith Moore <[email-masked]>
Date: Tue, 30 Jul 2002 12:35:15 -0400

> OTOH, TLDs that are popular get cached and stay that way.

no they don't - things don't stay in the cache forever, and there are various
reasons why cache entries can go away before the TTL has expired.

> introduce, say, a billion phones to the service network.

no.  a few hundred million hosts using (on average) two dozen popular TLDs 
will generate twice the load on the roots as the same number of hosts using 
(on average) a dozen popular TLDs.

> them both out of the bag.

read the statement again.  *someone* has to decide whch TLDs are "handed out".
we can argue about the criteria that should be used to influence such
decisions, but there are still decisions that have to be made.  

> be. High fees, escrow, etc., should keep that from happening.

and *someone* has to decide how high those fees should be, and what the 
criteria are, etc.  and *someone* has to spend that money.  such decisions are 
inherently controversial as they exert a fair amount of effect on the ability 
of various parties to make money from, and/or control, the Internet.

Keith

---

From: John Stracke <[email-masked]>
Date: Tue, 30 Jul 2002 09:52:56 -0400

Peter Deutsch wrote:

>So maybe we need to be
>a new port number,
You could probably avoid the need for a new port number by saying "all
our experimental registrations will be rooted under
experiment.gydig.com" (or whatever).  Then a MumbleService resolver
looking up "foo.bar" would do a DNS lookup on
"foo.bar.experiment.gydig.com".  In effect, you'd get a root for
MumbleService names without having to introduce an extra set of root
servers for people to configure.

A multivalued keyword service could be done this way, for example: to
resolve the keyword "nutcase", you would do a lookup on
"nutcase.keywords.experiment.gydig.com", and return all the records
found.  You could even set things up so that multiple keyword registries
could coexist: the keyword resolver does an NS lookup on
"keywords.experiment.gydig.com", and then consults all the servers it
finds and combines the results.  (This design is too simplistic--it
wouldn't permit load balancing across multiple servers for the same
registrar--but you get the idea.)

-- 
/===========================================================\
|John Stracke      [email-masked]                  |
|Principal Engineer|http://www.centivinc.com                |
|Centiv            |My opinions are my own.                 |
|===========================================================|
|We must be devious, cunning, inventive... too bad we're us.|
\===========================================================/

---

From: John Stracke <[email-masked]>
Date: Tue, 30 Jul 2002 11:46:37 -0400

Stephen Sprunk wrote:

>Very few corporations (and no ISPs, AFAIK) run their own roots.
>
Enh...there is a sense in which internal DNS servers may be considered
roots.  For example, I name the hosts on my home LAN out of
"local.thibault.org", which is not visible from the outside.  This sort
of split DNS is easier than lumping all my names under "thibault.org"
and maintaining two separate copies of the zone files.

It does mean, though, that, conceptually, my DNS server is like an
alternate root server, in that it handles queries for a domain that
can't be found if you start at the root.  The fact that my server
performs recursion, and an alternate root server does not, is a
performance decision, not a fundamental difference.

(On the other hand, Einar's wrong in saying that *every* LAN has a
private root server--for example, some universities don't impose any
inside/outside division at all.)

---

From: Joe Touch <[email-masked]>
Date: Tue, 30 Jul 2002 09:51:40 -0700

Einar Stefferud wrote:
> ORSC does not support what NEW.NET is doing either, but please note that 
> this has nothing to do the lack of cooperation that ICANN exudes.

Agreed. I was addressing Ole's point _only_, in two ways:

	1) it's not so hard to modify a naive user's DNS at
	the browser or endhost configuration

	2) your ISP may already be doing it by at the DNS
	layer

How big an issue this is is distinct from how complex it is to achieve.

Joe

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 30 Jul 2002 11:57:21 -0500

on 7/30/2002 11:27 AM Dave Crocker wrote:

> So if ICANN does not do that policy work, who does?  And why is it
> somehow  better to have that work done elsewhere?

I agree, and I believe that I said as much. The alternate providers policy
is essentially "why can't we all just get along," which is workable for a
voluntary consortium, but not for the real root.

---

From: Randy Bush <[email-masked]>
Date: Tue, 30 Jul 2002 10:10:30 -0700

to paraphrase your good friend john klensin,

  jon postel consciously pushed problems back to the locale and
  attempted to not involve the iana in controversy and argument.

  the icann seems to be willing to take on any task, and will
  invent controversy and argument is none is immediately available
  to hand.

it is the latter approach which has led to the need for a staff
of dozens to perform the wortk that used to be done better and
far less controversially by one computer scientist in part time.

randy

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 30 Jul 2002 12:35:33 -0500

> reasons why cache entries can go away before the TTL has expired.

To the degree that this is true (which it is), it is also true for the
existing ~250 TLDs.

> (on average) a dozen popular TLDs.

That only holds true if the number of queries also doubles. EG, people
would have to visit sites in .foo plus .bar, and not just .foo. Moreover,
they would have to continue visiting .foo at the same overall rate. We are
talking about percentage increments not factors.

> decisions, but there are still decisions that have to be made.  

There are policy decisions which have to be made which control how the
process goes, certainly. But there is absolutely no reason that ICANN
needs to decide on which specific TLDs are created.

> criteria are, etc.  and *someone* has to spend that money. 

No argument here.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 30 Jul 2002 10:31:05 -0700

>   invent controversy and argument is none is immediately available

One of the consistent characteristics of criticism of ICANN is the use of 
sweeping hyperbole, such as the above.

What is interesting about it is how easily it is disproved, when the person 
making the claim is required to list specifics.

Feel free to (try to) prove me wrong.

d/

----------

---

From: Keith Moore <[email-masked]>
Date: Tue, 30 Jul 2002 13:49:32 -0400

> > things don't stay in the cache forever, and there are various

yes.

> That only holds true if the number of queries also doubles. 

no, all that is necessary is that there be a single query for each
of the "popular" TLDs at each resolver for every time the cached NS 
record for that TLD at that resolver goes away.  (that's what I mean
by "popular"). so an increase in TLDs can cause the load on the root 
servers to increase drastically without the number of end-system 
queries increasing at all - all that is needed is for those queries
to exhibit less locality of reference than before.

> needs to decide on which specific TLDs are created.

*somebody* has to do it, and that *somebody* is inherently going
to be under a lot of pressure from conflicting and often powerful
interests - and hence that *somebody* is going to be controversial -
whether or not that *somebody* is ICANN.

Keith

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 30 Jul 2002 12:56:16 -0500

> to exhibit less locality of reference than before.

If the overall number of lookups has not increased, there will be fewer
overall lookups for *existing* TLDs as well. This means that the number of
stale cache hits for existing TLDs goes down at the same time as the
number of stale cache hits for new TLDs goes up (although not necessarily
the same rate). In order to significantly threaten the root load, you
would have to significantly increase the number of queries.

A certain amount of incremental increase is to be expected, but frankly,
if that percentage increase is a threat of any order then we have bigger
problems than ICANN politics.

> whether or not that *somebody* is ICANN.

Do you think I am arguing with you on this point?

My point is that ICANN only needs to design policies which allow for the
creation of TLDs such as .auto and .car, but they do not need to decide
that specifically .auto gets in while .car does not.

---

From: Keith Moore <[email-masked]>
Date: Tue, 30 Jul 2002 14:08:15 -0400

> overall lookups for *existing* TLDs as well. 

not from the resolvers to the roots.  they'll each contribute one hit per 
NS record that has timed out of their cache for the root zone, regardless 
of how many queries they handle (>= 1 per zone).

> This means that the number of

that's simply incorrect.

> that specifically .auto gets in while .car does not.

Sure, but such decisions still have to be made due to various considerations
including but not limited to root server load, and moving that decision away 
from ICANN to another controversial organization isn't likely to solve any 
problems that I can see.  

Ketih

---

From: Lloyd Wood <[email-masked]>
Date: Tue, 30 Jul 2002 19:23:36 +0100 (BST)

Am I the only person who thinks that the title of this thread should
be 'A tree has one root'?

L.

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 30 Jul 2002 13:36:03 -0500

on 7/30/2002 1:08 PM Keith Moore wrote:

>> If the overall number of lookups has not increased, there will be
>> fewer overall lookups for *existing* TLDs as well.
>
> not from the resolvers to the roots.  they'll each contribute one hit
> per NS record that has timed out of their cache for the root zone,
> regardless of how many queries they handle (>= 1 per zone).

50,000 stale cache hits for .foo today, with .bar gaining equal status
tomorrow -- but without an overall increase in user activity -- means that
there will not be 50,000 stale cache hits for .foo tomorrow. I'm not
saying that it will drop to 25k, but it would be less than 50k.

Realistically, there would have to be a significant number of *active*
properties at delegations under .bar for there to be parity between them,
and this is the least likely scenario given the current climate. Over a
ten+ year period this will certainly change, but the technology used to
process the root queries will also change.

Simply put, the act of adding new zones has no practical effect. Adding
additional queries through the use of application-specific data (eg, phone
numbers, certificates, and so forth) and adding additional agents that can
cause the overall number of queries to go up, those are the real threats.

I'm not going to continue this argument.

> Sure, but such decisions still have to be made due to various
> considerations including but not limited to root server load, and
> moving that decision away from ICANN to another controversial
> organization isn't likely to solve any problems that I can see.

I don't know why you think I am disagreeing with you about this.

---

From: "Michael Froomkin - U.Miami School of Law" <[email-masked]>
Date: Tue, 30 Jul 2002 14:38:42 -0400 (EDT)

Does anyone have pointers to data on what sort of sever load the root
servers currently face?  And, especially, how this compares to what they
can stand?  (Not to mention how we calculate the latter...)

And while I'm wishing, how about data showing how this compares to the
load on the name servers that serve, say, .com?

Thanks!

On Tue, 30 Jul 2002, Keith Moore wrote:
[...]

-- 
		Please visit http://www.icannwatch.org
A. Michael Froomkin   |    Professor of Law    |   [email-masked]
U. Miami School of Law, P.O. Box 248087, Coral Gables, FL 33124 USA
+1 (305) 284-4285  |  +1 (305) 284-6506 (fax)  |  http://www.law.tm
                        -->It's hot here.<--

---

From: John Stracke <[email-masked]>
Date: Tue, 30 Jul 2002 14:10:38 -0400

>That only holds true if the number of queries also doubles.
False.  The caching system means that the roots don't pay per query;
they pay per cache miss--and the number of cache misses is going to be
roughly proportional to the number of TLDs.

---

From: Bill Manning <[email-masked]>
Date: Tue, 30 Jul 2002 11:57:12 -0700 (PDT)

You might find:  http://www.rssac.org/stats.html  interesting

% Does anyone have pointers to data on what sort of sever load the root
% servers currently face?  And, especially, how this compares to what they
% can stand?  (Not to mention how we calculate the latter...)
% 
% And while I'm wishing, how about data showing how this compares to the
% load on the name servers that serve, say, .com?
% 
% Thanks!
% 
% On Tue, 30 Jul 2002, Keith Moore wrote:
% [...]
% > > This means that the number of
% > > stale cache hits for existing TLDs goes down at the same time as the
% > > number of stale cache hits for new TLDs goes up (although not necessarily
% > > the same rate). In order to significantly threaten the root load, you
% > > would have to significantly increase the number of queries.
% > 
% > that's simply incorrect.
% > 
% > > My point is that ICANN only needs to design policies which allow for the
% > > creation of TLDs such as .auto and .car, but they do not need to decide
% > > that specifically .auto gets in while .car does not.
% > 
% > Sure, but such decisions still have to be made due to various considerations
% > including but not limited to root server load, and moving that decision away 
% > from ICANN to another controversial organization isn't likely to solve any 
% > problems that I can see.  
% > 
% > Ketih
% > 
% > 
% 
% -- 
% 		Please visit http://www.icannwatch.org
% A. Michael Froomkin   |    Professor of Law    |   [email-masked]
% U. Miami School of Law, P.O. Box 248087, Coral Gables, FL 33124 USA
% +1 (305) 284-4285  |  +1 (305) 284-6506 (fax)  |  http://www.law.tm
%                         -->It's hot here.<--
% 

-- 
--bill

---

From: Keith Moore <[email-masked]>
Date: Tue, 30 Jul 2002 16:04:33 -0400

> saying that it will drop to 25k, but it would be less than 50k.

you're simply wrong.  until you can understand the math, I don't see
any point in continuing this discussion.

Keith

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 30 Jul 2002 15:41:50 -0500

> any point in continuing this discussion.

Do you honestly believe that the root servers get the same number of cache
hits per day for (say) .re as they do for .com?

You are somehow trying to argue that .bar will raise to the same size as
.foo but that the overall number of queries will be static. With that
restriction, .foo and .bar can only reach parity if half of the
delegations migrate into .bar from .foo, or from some other zone(s). Once
those zones shrink, they will get less queries (cf, .re).

The only way out of the hole you have dug for yourself is to increase the
overall number of queries.

---

From: "Ole J. Jacobsen" <[email-masked]>
Date: Tue, 30 Jul 2002 14:46:53 -0700 (PDT)

But when the "navive user" has his or her config altered in this way, it
is likely to cause confusion and frustration when Joe can reach .STEF,
but Mary can't.

Choice is a fine thing, incompatibility is not.

Having one Internet is a good thing.

Ole

Ole J. Jacobsen
Editor and Publisher

---

From: John C Klensin <[email-masked]>
Date: Tue, 30 Jul 2002 17:56:00 -0400

--On Tuesday, 30 July, 2002 15:41 -0500 "Eric A. Hall"
<[email-masked]> wrote:

>> you're simply wrong.  until you can understand the math, I
>> don't see any point in continuing this discussion.
> 
> Do you honestly believe that the root servers get the same
> number of cache hits per day for (say) .re as they do for .com?
> 
> You are somehow trying to argue that .bar will raise to the
> same size as .foo but that the overall number of queries will
> be static. With that restriction, .foo and .bar can only reach
> parity if half of the delegations migrate into .bar from .foo,
> or from some other zone(s). Once those zones shrink, they will
> get less queries (cf, .re).
> 
> The only way out of the hole you have dug for yourself is to
> increase the overall number of queries.

Eric,

Let me see if I can explain the math I think Keith is using, on
the assumption that maybe Keith and I (and others) can pass the
"patience" baton around.

Assume that neither COM (or FOO) nor BAR rotates out of a given
cache during a TTL interval.  If it does (they do), it makes the
explanation below a tad more complex, but doesn't fundamentally
change anything.  Also assume that most or all of the DNS
resolver and server software on the network conforms to the
specs (that is known to be false, but is a separate problem).

For a given user or, more often, a given forwarding-target
server with a cache, the number of inquiries about, say, COM
that is needed to keep the local cache full for a TTL interval
is one.  How often the user/ server queries for COM during that
TTL interval doesn't count, the only thing that is important is
whether or not one such query occurs.  Now, to pick a perfectly
arbitrary number, assume that the root servers see 50
kiloqueries per TTL for ".FOO" before ".BAR" in introduced.
While the number of subdomains of FOO most likely influence the
odds of getting to 50 kiloqueries, that number ultimately
represents the number of servers that need to find out about the
location of the nameservers for FOO, and not the number of
entities in FOO or how often _they_ are queried.   If each of
those servers sees 50% fewer requests involving FOO, or even 90%
fewer, the 50 kiloquery number for the root servers will be
unchanged.

Now, we introduce BAR and BAR's existence does just exactly what
you posit -- it reduced the number of subdomains of FOO that are 
queried by some number, and produces some numbers for BAR.  But,
unless it is sufficiently successful to cause some of the
servers  to lose interest in FOO entirely, it won't impact the
root load due to FOO at all.  It will, however, increase the
root load due to the introduction of BAR.  From the root
standpoint, the worst case is that the introduction of BAR
reduces the number of queries for FOO to each forwarding server
by 50 or 75%, while getting each of them at least one query for
a subdomain of BAR.  That means 50 kiloqueries on the root for
FOO and 50 kiloqueries on the root for BAR.

And what happens to ".re" relative to ".com" has nothing to do
with the story.

At least that is the theory.

      john

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Wed, 31 Jul 2002 00:20:44 +0200

>   attempted to not involve the iana in controversy and argument.

Randy,
Jon Postel managed the ".arpa" system for which the DNS was designed with 
"other systems" interconnect in mind (cf. RFC 921) and their own roots.

>   invent controversy and argument is none is immediately available

ICANN manages the world.
ICANN is not interested in network inftrastucture but in building 
structural relations.
Just search the ERC propositions for "root", "DNS" ...

>far less controversially by one computer scientist in part time.

This only says why lawyers are paid so much, in proportion to their 
inneffiency when compared with a computer scientists :-)

As indicated IMHO the conlusion of this "forests have one tree" thread is 
the need for a clean sheet analysis of the requirements for the DNS.2 
specs. With a cross namespace, cross technology, real life universal URL 
support service in mind.

jfc

>randy
>
>
>
>
>
>---
>Incoming mail is certified Virus Free.
>Checked by AVG anti-virus system (http://www.grisoft.com).
>Version: 6.0.380 / Virus Database: 213 - Release Date: 24/07/02

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Wed, 31 Jul 2002 00:30:38 +0200

>be 'A tree has one root'?

I do not know if you ever looked at the roots of a tree ....
Anyway, when you consider that the root here is on top of the top of the 
tree ...

---

From: Ed Gerck <[email-masked]>
Date: Tue, 30 Jul 2002 15:51:11 -0700

> is likely to cause confusion and frustration when Joe can reach .STEF,

Ole,

Your misspelling above seems to betray the highly-emotional tones
that this discussion, as well as anything that is DNS/ICANN related,
touches off.  BTW, the "naive" user would not alter her/is config and
so would not see any problem.

> Having one Internet is a good thing.

These slogans seem to point the same way.  Can we please go back (or
begin) a technical discussion?    As Editor and Publisher of a technical
journal, I would expect you to help make the difference -- not blur the
difference with things like "Uncle" and emotional tones.

And I am waiting to hear some substantive technical arguments why a
name query cannot have more than one answer and still be resolvable,
when everything else we ask in life has more than one answer and yet
we are able to resolve them. To set the groundwork for an attempt to such
answer, let me recall that the DNS seems to be the only logical system that
tries to  be both complete and resolvable, when we know for a mathematical
fact that these two qualities do not go together for a system with a complexity
larger than arithmetics.

Cheers,
Ed Gerck
Not an Editor and Publisher ;-)

> -
> This message was passed through [email-masked], which
> is a sublist of [email-masked]. Not all messages are passed.
> Decisions on what to pass are made solely by Raffaele D'Albenzio.

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 30 Jul 2002 17:54:41 -0500

on 7/30/2002 4:56 PM John C Klensin wrote:

> whether or not one such query occurs.

I'm perfectly aware, thankyouverymuch.

> And what happens to ".re" relative to ".com" has nothing to do

.edu versus .com then, or .au versus .com, or anything you want. There are
millions of organizations that don't issue queries for those zones either.
Perhaps somebody will be kind enough to post some actual per-TLD
statistics for those zones.

If something like .pr0n (being sensitive to mail filters) starts taking
out a massive number of .com sites, there will be fewer queries for .com.
No question about it. Saying that there will be no more queries for .com
is fairly ludicrous, but it can be sustainably argued that some networks
will timeout their internal caches for longer periods, resulting in a
slight lowering of .com lookups. Meanwhile, there will be lots of networks
that NEVER lookup any domain in the .pr0n TLD. Furthermore, domains which
had been operating under .kr, .ru, .uk and so forth will also move,
resulting in those tertiary zones getting fewer root queries. So even
though there may be an equal number of domains under the .com and .pr0n
titan TLDs, the overall load will likely have only gone up by a few
percentage points. This is especially true if the overall number of
resolver-side queries is consistent.

---

From: Peter Deutsch <[email-masked]>
Date: Tue, 30 Jul 2002 16:04:39 -0700

g'day,

> Having one Internet is a good thing.

I dunno, Ole, you seem to be underestimating the abilities
of Ed and Edna Everage consumer here. In the very early days
of the telephone, folks didn't have to worry about country
codes, area codes or directory services, they could just
pick up the phone and ask for "Mary". Once switch gear came
into use folks had to know about short strings of digits,
but didn't have to worry about whether the folks down in
Australia had scarffed up all the desireable (ie. "short")
digit strings. As the service grew, and the number of folks
to be reached went into the millions, everyone learned about
additional ways to make cost-effective contact and nobody
expects there to be a single way to find somebody's phone
number.

Today, I live in a place where there are multiple providers
of yellow pages directories (err, business directories
printed on yellow coloured paper, if you will). If somebody
is told something is "in the yellow pages" and they can't
find it, they don't abandon the concept of directories or
stop using the telephone. The *might* conclude that their
current "yellow pages" provider is letting them down and
might contemplate switching to an alternative, or might even
resort to additional mechanisms to find what they're looking
for, but folks have learned to do this out in the "real
world" and still get along. 

To extend my previous thought a bit, there are two roles
being served by the DNS. One is the service provider's need
for an automatic, stable, reliable indirection service for
such things as email delivery. The other is the de facto
role people have assigned DNS as a directory service for the
Internet. Sure, a single namespace is needed if everyone is
to see the same view of the world, but out there in the
"real" world folks can today register local trademarks, hand
around local six or seven digit phone numbers and otherwise
live their lives without thinking too much about what the
Australians are up to (although frankly, their recent foray
into Scramjet technology is worrying, to say the least...
:-)

When there were a few hundred thousand computers on the net,
the loss of "locality of reference" didn't seem like such a
big deal. Heck, folks even thought it was liberating. Today,
the top of the DNS tree is looking pretty crowded, to say
the least, causing its own fair measure of confusion and
frustration. As somebody once wrote in a previous context
"you can perform pain transformations all you want, but
grief is preserved..."

			- peterd

--

---

From: "Ole J. Jacobsen" <[email-masked]>
Date: Tue, 30 Jul 2002 16:14:30 -0700 (PDT)

Peter,

I am happy to have your e-mail address depend on your provider. I am far
less happy to have to figure out how to address you depending on what my
provider is. Been there, done that. Have a book about it. It's all gone
now and we use "[email-masked]"  The "tld" part is known and can be
resolved from a set of carefully operated and synchronized root servers.
I really don't think having to worry about other roots should be imposed
on the users now. Bad idea.

Thanks

Ole

Ole J. Jacobsen
Editor and Publisher

---

From: Dave Crocker <[email-masked]>
Date: Tue, 30 Jul 2002 16:32:40 -0700

>Your misspelling above seems to betray the highly-emotional tones

Ed, discussion is usually not facilitated by such silliness.

Claiming that one extra character belies emotional state is really 
impressive. It belies so much insecurity and defensiveness on your part as 
to make further discussion useless.

And lest you take exception to my using such a basis for making such an 
assessment of your internal workings, think a bit about geese and ganders 
and what is good for them.

d/

----------

---

From: "vinton g. cerf" <[email-masked]>
Date: Tue, 30 Jul 2002 19:47:08 -0400

ed, how would you suggest to resolve an email address if it returns ambiguous results?

v

>fact that these two qualities do not go together for a system with a complexity

Vint Cerf
SVP Architecture & Technology
WorldCom
22001 Loudoun County Parkway, F2-4115
Ashburn, VA 20147
703 886 1690 (v806 1690)
703 886 0047 fax

---

From: Dave Crocker <[email-masked]>
Date: Tue, 30 Jul 2002 16:56:15 -0700

At 04:04 PM 7/30/2002 -0700, Peter Deutsch wrote:
>of Ed and Edna Everage consumer here.

One of the major problems with computer-related tools, today, is not that 
they under-estimate the user's ability but that they over-demand the user's 
effort.

Long ago, we got away from automobiles with hand-cranks to start the 
engine, spark arrestors, and other assorted controls over internals.  Most 
people simply want a car to work; they do not want to be automobile mechanics.

By contrast, today's PCs require that each user be a system administrator.

Given an industry that is at least 20 years old, this is a situation that 
all of us in the field should be deeply embarrassed about.

d/

----------

---

From: Ed Gerck <[email-masked]>
Date: Tue, 30 Jul 2002 17:09:17 -0700

> ed, how would you suggest to resolve an email address if it returns ambiguous results?

Vint:

1. Short answer -- For example, by embedding a resolution rule and referring
decidability to the end point, as done in this real case:
-----------actual message-----------------------------------------

---

From: Peter Deutsch <[email-masked]>
Date: Tue, 30 Jul 2002 18:17:38 -0700

g'day Vint,

> ed, how would you suggest to resolve an email address if it returns ambiguous results?

Maybe it's because I've spent part of the last week poking
around with synchronous serial protocols (I2C, anyone?) but
I think I may have a useful analogy here.

You can divide serial communication protocols into two
classes, those which included embedded clocking and those
which rely on external clocking. One technique isn't
naturally superior to the other, and in fact there are times
you want to use one or the other, depending upon design
goals, circumstances, etc.

We can think of the DNS service as commonly used today as
having "embedded clocking", in that the knowledge of where
to go to resolve a query is assumed as part of the query.
This is less flexible than having this knowledge outside the
query but it's simpler and does lead to a simpler system. It
also ties everyone together in ways that, because of
admittedly non-technical decisions made outside the scope of
this list, the resulting service is running up against
constraints a lot earlier than might be expected absent such
decisions. Sadly, now that "steampowered.com" is gone I can
wail all I want, but I'm not getting it as long as we all
use the same resolvers (ie. the same "embedded clock"). This
is the only way to guarantee universality of response.

The DNS doesn't *have* to be operated this way. The system
could be implemented to provide different responses to
queries depending upon external factors, such as your
location, load on servers, what you're trying to do, etc. In
such a model queries are still resolved, and with greater
flexibility, for those who can sacrifice universality.

Is this an outrageous idea? Maybe, but this is a technique
that's being used today, for example  in CDN systems to
provide DNS-based query resolution. Users don't even know
it's going on and the world didn't grind to a halt once the
universality of name to address bindings was destroyed. You
ask for a URL, and the server you get to is determined for
you, and yes it may well differ from the one the guy in
Australia gets for the same URL (Personally, I suspect his
includes details of the secret Aussie scramjet technology
which we outside the motherland aren't privy to, but I
digress...  ;-)

This is really a form of "external clocking" of the query
resolution service, and it's done today more than folks seem
to want to admit, both at the level of DNS and at the level
of content filtering (I know a number of folks who have told
me "I couldn't forward that post from work because the
company's mail filter thinks 'shitake mushrooms' are a
scatalogical reference on the disallowed list so wait until
I get home tonight and I'll send it on from the other
machine").

Sure, if you need universality of reference you need a
universal namespace, but I guess I'm starting to believe
that the number of times I could do without, or actively
don't want, such universality is growing enough that I might
want my *next* name resolution service to give me a bit more
flexibility and choice. Hide the nerd knobs behind flipup
panels, but the lack of flexibility in the current system is
getting in the way and I suspect will need to be revamped to
get it ready for the next 100 million users...

				- peterd

---

From: "vinton g. cerf" <[email-masked]>
Date: Tue, 30 Jul 2002 21:29:44 -0400

ed,

sorry I asked an ambiguous question!

your answer worked for the case that harris.com was unambiguous.

I was trying to ask what if the "harris.com" part of "[email-masked]" produced ambiguous results?

Vint

Vint Cerf

---

From: "vinton g. cerf" <[email-masked]>
Date: Tue, 30 Jul 2002 21:48:23 -0400

Peter,

I think the only aspect of your remarks that would be of
concern to me is trying to change the current DNS to operate
with "external clocking" rather than devising something new.
I don't think you were advocating that, since you made
reference to the "next DNS" which I took to be something
new and different that might indeed operate as you suggest.

I certainly agree that the CDN/redirect mechanisms do some
pretty complex things behind the DNS scenes. However, enough other
applications assume the the resolution is equivalent no matter
where the query is made (e.g. for email) that I would be concerned
about making a radical change to the current system. 

We've already seen how complicated IDN is proving to be
(as another attempt to extend the functionality of present-day
DNS).

Vint

Vint Cerf

---

From: Ed Gerck <[email-masked]>
Date: Tue, 30 Jul 2002 19:07:47 -0700

> your answer worked for the case that harris.com was unambiguous.

As below, the answer works when an  email address returns ambiguous results
-- whatever the cause of that ambiguity.

> I was trying to ask what if the "harris.com" part of "[email-masked]" produced ambiguous results?

In the same way, where both my short and long answers apply.  Please note
that you just moved the same problem to a higher node.  To exemplify, the short
answer could be something like:
-----
This is an automatic reply to your request for:

Harris.COM

2 different domain names are named Harris.COM

Please choose which one of the following domain names you
would like to reach, by clicking on the link shown on the right.

Harris Motor Company at Harris.COM

Harris Models at Harris.COM
--------------------------

Cheers,
Ed Gerck

---

From: Carl Malamud <[email-masked]>
Date: Tue, 30 Jul 2002 19:17:13 -0700 (PDT)

Hmmm ... seems like the telephone system has a similar system.  You dial 411
and ask for "Malamud@StewartsPoint" and a human/humanoid answers "Please choose".
There's certainly room for systems like RealNames and certainly rooms for
other namespaces that handle ambiguity, but the DNS serves a pretty useful purpose
of resolving domain names to various resource records.  Rather than
muck with it, I like Peter's approach of trying to build new services and
keeping the existing one in place.

Regards,

Carl

---

From: Caitlin Bestler <[email-masked]>
Date: Tue, 30 Jul 2002 22:00:40 -0500

On 7/30/02, Peter Deutsch wrote:

>g'day Vint,
>
>"vinton g. cerf" wrote:
>> 
>> ed, how would you suggest to resolve an email address if
it returns ambiguous 
>results?
>naturally superior to the other, and in fact there are
>times you want to use one or the other, depending upon
>design goals, circumstances, etc.
>
>This is less flexible than having this knowledge outside
>the query but it's simpler and does lead to a simpler
>system. It also ties everyone together in ways that,
>because of admittedly non-technical decisions made outside
>the scope of this list, the resulting service is running
>up against constraints a lot earlier than might be
>expected absent such decisions. Sadly, now that
>"steampowered.com" is gone I can wail all I want, but I'm
>not getting it as long as we all use the same resolvers
>(ie. the same "embedded clock"). This is the only way to
>guarantee universality of response.
>

A clock, whether embedded or external, is only useful if it
is used by both the sender and all the recepients. Given the
goal of having a single clock, there are indeed many
different ways to achieve the same result.

You cannot, however, have two of the devices on an I2C bus
decide that the clock the rest of the bus is using is
defective, and just decide to use a better clock on their
own.

Additionally, I think it is also important to recognize that
domain names are now an integral part of trademarks and have
meaning far beyond translating a name to an IP address.

Suppose the IETF were to somehow get the crazy idea to
radically change the entire domain registration system, and
as a result Disney no longer owned "disney.com"?

Does anyone really think the courts would back the IETF?

---

From: [email-masked]
Date: Tue, 30 Jul 2002 23:39:03 -0400

> Harris Models at Harris.COM

1) You find out about the "other" domain *how*?

2) Explain how to deal with the case of "[email-masked]" being a valid
destination for more than one site?

3) Do you intend that this would work like multiple A records for one
name, where you basically get luck-of-the draw, or would you have an MX-style
scheme were there are preferences, so if you've figure out which "fred@"
you mean, it will keep going to that one rather than the OTHER one?  What
happens if harris.COM changes registrars while I'm not looking - does my
mail bounce because it's pointing at some OTHER harris.com now?

4) Tell me what my Listserv system should do with a subscription request
from an ambiguous address - I already get <*censored*> enough bounce messages
from bogus hostnames, 

5) Tell me what my CGI script should do when it prompts the user for a
e-mail address or URL.

6) "2 matches found:

Harris Motor Company at Harris.COM
Harris Motor Company at Harris.COM"

Which one's the typosquatter?  Or are they the SAME company, similar to
companies that register foo.com and foo.net? (you didn't actually expect
them to list "Harris Typosquatters" as the organization, did you? ;)

And now repeat your explanation so my mother the Hotmail user can follow it.

---

From: Peter Deutsch <[email-masked]>
Date: Tue, 30 Jul 2002 21:04:22 -0700

g'day,

I'm surprised nobody shouted "get out of here, this is a
technical forum!", but hey there's still time... :-)

> On 7/30/02, Peter Deutsch wrote:
. . . 
> different ways to achieve the same result.

Actually, I think one of the subtext threads here is that we
need to stop thinking in terms of a single clock for the
system as being one of the goals...

> defective, and just decide to use a better clock on their

Actually, in the cited example, you most certainly *can*.
I2C permits multimastering on a bus (that is, more than one
device can act as a master, although only one can do so at a
time). To continue to thrash this poor analogy a bit
further, I think it's time to consider that in addition to
permitting multiple clocks on a bus, it time to consider the
possibility that not every device needs to be on the same
bus. All that you need is that the set of devices that need
to communicate together have a mechanism to negotiate and
agree upon a common protocol. Anyone not affected by this
newly defined relationship are then free to ignore it
without harm...

> meaning far beyond translating a name to an IP address.

Actually, this observation is relevant for the operators of
commercial resource location services based upon deployed
technology but is irrelevant for the purposes of a
*technical* discussion about how to best design next
generation directory service technologies. This is clearly
one to take over to the ICANN side of the house. We don't
want to upset out new-found enthusiasm for technical
issues...  ;-)

> Does anyone really think the courts would back the IETF?

Errrr, to be a little more precise Disney might own the
trademark rights to "disney.com" in the context of Internet
resource naming in certain jurisdictions. This might be
somehow relevant to operators of global resource discovery
services but what exactly does that have to do with this
discussion? As has been pointed out many, many times the
IETF doesn't operate a resource discovery service. What it
is supposed to do is promote activity to develop
Internet-based technologies. Are you saying that somebody
might sue the IETF to stop development of a technology
because they might be misused to infringe upon their
trademark rights once deployed? Wow, giving in to *that*
kind of self-censorship would surely shut down the IETF
pretty fast.

Remember, protocols don't violate trademarks, people violate
trademarks. When they do so, they can be sued. Meanwhile, I
don't think we're here just to make sure Disney has a good
week on the Internet...

					- peterd

--

---

From: Ed Gerck <[email-masked]>
Date: Tue, 30 Jul 2002 21:20:42 -0700

> keeping the existing one in place.

Please note that the "harris" solutions were presented as meta-systems.
My comments implied no changes whatosever to the DNS. Actually,
my comments denied any changes in the DNS in order to be applied.

If it was otherwise intepreted by anyone, may this msg eliminate the
ambiguity ;-)

BTW, they can also be automated as I commented before.

Cheers,
Ed Gerck

---

From: [email-masked]
Date: Wed, 31 Jul 2002 14:25:07 +0000

> don't think we're here just to make sure Disney has a good
 
Nah, thats the job of the IRTF...  :-)

-George

--
George Michaelson       |  APNIC
Email: [email-masked]    |  PO Box 2131 Milton QLD 4064
Phone: +61 7 3858 3100  |  Australia
  Fax: +61 7 3858 3199  |  http://www.apnic.net

---

From: Ed Gerck <[email-masked]>
Date: Tue, 30 Jul 2002 21:37:06 -0700

> And now repeat your explanation so my mother the Hotmail user can follow it.

That is actually easier, so I'll take the bait ;-)

Hotmail would show to their users a screen similar to that one which I just
mentioned here, for automating the process and leveraging previous
choices (if you so wish and as you so wish).  Everything else (including
your items 1-6 above) would be handled by Hotmail and is transparent to
the user, but following the user's decision rules.

BTW, please note that your case #6 just leads to an upper level, where
it can again become decidable. For example, if two companies are named
"Harris Motor Company" (which may legally happen, for 50 "Harris Motor
Company" in all 50 States), then you would have:

-------------------

Harris.COM

Harris Motor Company, "The Best Car at Any Price" at Harris.COM

Harris Motor Company, "Built Like a Rock" at Harris.COM
-------------------

BTW, this would be a neat -- and correct -- use for trademarks.
To provide for unique business identifiers that have a legally restricted
jurisdiction.  Not to provide for unique domain names that by force
have a planetary jurisdiction.

Cheers,
Ed Gerck

---

From: Keith Moore <[email-masked]>
Date: Wed, 31 Jul 2002 01:02:07 -0400

actually returning multiple results doesn't work very well for
either email addresses or domains.  

it might look like it works for email addresses - and if the first
time you send to an email address, you get back a "sorry that was 
ambiguous" response and a list of possible alternatives, you might 
think this was acceptable.  on the other hand, if you're used to 
sending mail to a particular address or if mail is sent to that 
address via an automatic process, and suddenly the address becomes 
ambiguous, this does not make a good interface.

similarly, multiple responses for a domain lookup can work fairly well 
when there's a human in the feedback loop who can respond in real time 
and who knows enough about the nature of his request to be able to 
supply enough information to narrow down the choices to one.  but 
it doesn't solve the problem in general.

Keith

---

From: Ed Gerck <[email-masked]>
Date: Tue, 30 Jul 2002 22:11:41 -0700

> either email addresses or domains.

Please note that email systems today already return mutiple results:

1 - failed delivery, host unknown
2 - failed delivery, recipient does not like sender
3 - failed delivery, quota exceeded
4- delayed delivery
5- "out of office" bot reply
6 - "out of the company" bot reply
...

without actually connecting anyone. So, would having multiple results,
that may allow you to get connected, be a definite advantage over
the current situation?

Fault-tolerance is a useful by-product of redundancy.  If you have a list
of two email addresses to contact me, this may allow you to choose
one that works in spite of a sudden "out of quota" condition.

And, all of this can be automated.

Cheers,
Ed Gerck

---

From: Keith Moore <[email-masked]>
Date: Wed, 31 Jul 2002 01:28:38 -0400

> that may allow you to get connected, be a definite advantage over

you're missing the point.  having meaningful error messages can be 
useful, of course.  but expecting meaningful error messages to
solve the problems associated with ambiguous names/addresses is
naive.

(note that the same problems are starting to exist at layer 3 due
to the introduction of ambiguous addresses at the IP layer - 
and they're causing problems there also.)
 
Keith

---

From: [email-masked]
Date: Wed, 31 Jul 2002 03:08:32 -0400

> it can again become decidable. For example, if two companies are named

OK.. I'll bite - WHICH upper level do you go to, if you're arguing for
multiple roots?  And how do you find all candidate roots *without* positing
a central repository of roots (since such a central repository would itself
be a root, no?)

> Harris Motor Company, "Built Like a Rock" at Harris.COM

All you're making a case for here is that a lot of stuff should be registered
under FOO.BIZ.town.state.US rather than FOO.COM, and that DNS is a white
pages and we need a yellow pages to match.

Also, you're side-stepping the fact that quite often, there *IS* no option
for "automatic reply to your request for" - remember that gethostbyname()
isn't called *ONLY* in web browsers and MUAs - it's called a lot from
within automated software as well...

Hmm.. I wonder how many systems will refuse to boot if I register a TLD
called 'localhost' in The Other Root, and watch everything hang on the
way up with "automatic reply to your request". Anybody who thinks that
this is Just Silly should consider that BGP announcements of RFC1918
space into the public Internet are a daily occurrence, once in a while
somebody announces default, and there's always AS7007 ;)

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 31 Jul 2002 09:39:46 -0500

> roughly proportional to the number of TLDs.

The number of cache misses will be in relation to the frequency at which
queries arrive versus the TTL for the TLD's authoritative servers. The
number of TLDs is completely irrelevant.

---

From: Ed Gerck <[email-masked]>
Date: Wed, 31 Jul 2002 08:18:00 -0700

> and they're causing problems there also.)

Keith,

And there will be more. Maybe it will take people still a while to realize
that the problem is the current mindset, that posits a decidability that
simply cannot coexist with completness.  You need to choose -- which
one do you want to have? You cannot have both from the same system.

And, yes, of course I'd expect meaningful error messages to provide
an automatic solution as much as possible, and as much as I desire.

Cheers,
Ed Gerck

---

From: Keith Moore <[email-masked]>
Date: Wed, 31 Jul 2002 11:23:15 -0400

> number of TLDs is completely irrelevant.

the latter statement is false, because the more TLDs there are, the more
potential cache misses for some TLD (thus requiring a query to a root server)
at any resolver.

---

From: Keith Moore <[email-masked]>
Date: Wed, 31 Jul 2002 11:24:15 -0400

> Maybe it will take people still a while to realize
> that the problem is the current mindset, 

Indeed, there are lots of people who need to realize that.

---

From: "Michael Froomkin - U.Miami School of Law" <[email-masked]>
Date: Wed, 31 Jul 2002 11:33:46 -0400 (EDT)

> meaning far beyond translating a name to an IP address.

This is not an accurate statement of the law in the US or any other
country I know of.

> Does anyone really think the courts would back the IETF?

The IETF wouldn't be involved.  The user of the other "disney.com" would
be.  And if it were

- their union
- people who think Disney is evil and have a non-commercial site saying so
- someone named Disney
- lots of other possibilities

it would be legal, too.

---

From: Aashish Kumar <[email-masked]>
Date: Tue, 30 Jul 2002 20:29:58 -0700 (PDT)

> Does anyone really think the courts would back the

__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

---

From: Einar Stefferud <[email-masked]>
Date: Wed, 31 Jul 2002 02:44:47 -0700

Dear Nephew Ole;-)...

You are showing great ignorance of how the ORSC (not alternate) root
service works.

If you want to discuss these issues with me, you will have to get
yourself lined up to use the ORSC root service, and then you can tell
me how it does not work for you.

But all this idle speculation is simply silly and not the least productive.

You have no basis to compare or determine what may or may not be
true, so either get real or stop making a fool of yourself.

And, take note, I do not tolerate the use of D'Crock's tools of EMail attack.
I suggest that to remain in good standing as a nephew, you will
refrain from such silly public attacks.

You don't need to stop being friends with D'Crock.

Just don't use his logic on me;-)...

It is your choice to make, not mine;-)...\Stef

---

From: John Stracke <[email-masked]>
Date: Wed, 31 Jul 2002 09:38:18 -0400

Ed Gerck wrote:

>the DNS seems to be the only logical system that
But name resolution is not larger than arithmetic; it's a simple 1-1
mapping.

-- 
/===========================================\
|John Stracke      [email-masked]  |
|Principal Engineer|http://www.centivinc.com|
|Centiv            |My opinions are my own. |
|===========================================|
|Earth: love it or leave it.                |
\===========================================/

---

From: John Stracke <[email-masked]>
Date: Wed, 31 Jul 2002 09:43:18 -0400

Peter Deutsch wrote:

>To continue to thrash this poor analogy a bit
>bus.
But that's the situation that the Internet displaced: islands of
connectivity, where you couldn't even send email from one island to
another.  (Sometimes you couldn't even send to other people on the same
island: Minitel had multiple email services that couldn't connect to
each other.)

---

From: John Stracke <[email-masked]>
Date: Wed, 31 Jul 2002 09:43:30 -0400

>This is an automatic reply to your request for:
And what happens if someone whose address is [email-masked] wants to
subscribe to a mailing list? How is majordomo going to know which Harris
to pick?

Or what if Fred sends mail to George and Barney; George wants to reply
to all, but doesn't know which of the potential Barneys is the one that
got the original message?

More to the point, why should someone who sends dozens of messages per
day have to pick the right recipient for each one? It can be done, sure,
but what benefit does it bring anybody?

---

From: John Stracke <[email-masked]>
Date: Wed, 31 Jul 2002 09:48:29 -0400

>one that works in spite of a sudden "out of quota" condition.
But you're not talking about multiple ways to contact you; you're
talking about one way to contact multiple people.  That's not fault
tolerance; that's a security hole.

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 31 Jul 2002 10:42:15 -0500

> potential cache misses for some TLD (thus requiring a query to a root server)

First of all, the statement is not false in the context of the original
comment (that the number of TLDs is a factor of cache misses).

As to your point, I will simply reiterate that the function remains to be
bound by frequency, and thus the quantity of queries over time. The number
of cache misses will not double unless and until you double the number of
out-of-window queries. A TLD which never gets queried has no misses.

---

From: Ed Gerck <[email-masked]>
Date: Wed, 31 Jul 2002 08:48:30 -0700

> Indeed, there are lots of people who need to realize that.

It's certainly going to take me a good while more to realize the
more profound implications offered by this paradigm change.
Perhaps others will be able to move faster, and help.

Cheers,
Ed Gerck

---

From: Keith Moore <[email-masked]>
Date: Wed, 31 Jul 2002 11:53:00 -0400

> comment (that the number of TLDs is a factor of cache misses).

nobody is claiming that TLDs that don't get used will increase cache misses.
OTOH, even a moderately-used TLD will increase cache misses.  

so the claim that adding TLDs doesn't increase the load on the roots only
holds if none of those new TLDs enjoy significant use.

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 31 Jul 2002 11:54:09 -0400

> more profound implications offered by this paradigm change.

it might take you even longer to realize that it's foolish.
don't expect everyone else to wait for you to figure that out though.

Keith

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 31 Jul 2002 11:11:38 -0500

> OTOH, even a moderately-used TLD will increase cache misses.  

That is true, but you have to substantially increase the overall number of
queries before you increase the frequency of cache misses across all TLDs.
IOW, if the number of queries per day stays static, then the introduction
of a TLD simply means that the average frequency per-TLD per-originator
declines.

In some cases this will result in more misses due to TLDs expiring from
non-use. The off-set is that popular TLDs get and stay cached due to
refreshes from multiple queries. Overall usage won't increase significantly.

The logical conclusion of your argument is that we should stick everything
into one big zone, with no hierarchy whatsoever.

---

From: John Stracke <[email-masked]>
Date: Wed, 31 Jul 2002 11:57:22 -0400

>holds if none of those new TLDs enjoy significant use.
In which case they're not needed.

|Anyone who has a conditioned response immediately thinks of|
|Pavlov.                                                    |

---

From: John Stracke <[email-masked]>
Date: Wed, 31 Jul 2002 12:14:44 -0400

Eric A. Hall wrote:

>The off-set is that popular TLDs get and stay cached due to
>refreshes from multiple queries.
>
>
But they can't stay cached indefinitely; they time out.  This isn't a
RAM cache we're talking about.

---

From: Keith Moore <[email-masked]>
Date: Wed, 31 Jul 2002 12:21:18 -0400

> queries before you increase the frequency of cache misses across all TLDs.

wrong.  you only have to add a single popular TLD to substantially
increase the frequency of cache misses.

> of a TLD simply means that the average frequency per-TLD per-originator

wrong.

> refreshes from multiple queries. Overall usage won't increase significantly.

wrong. 

> into one big zone, with no hierarchy whatsoever.

wrong.

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 31 Jul 2002 13:49:12 -0400

> In which case they're not needed.

I'm not sure I would go that far - I can imagine that one or two TLDs might 
be useful overall even if they are rarely queried.  e.g. .INT is useful
even though there aren't many domain names under .INT, and probably not
many queries for .INT.

But I wouldn't want to have too many little-used TLDs, for reasons having
nothing to do with root server load.

Keith

---

From: Dave Crocker <[email-masked]>
Date: Wed, 31 Jul 2002 11:17:37 -0700

Perhaps some folks see progress in this protracted thread, but I certainly 
do not.

If someone can summarize where the discussions stands, and demonstrate that 
it is both relevant and productive to the general IETF community, it is 
probably worth continuing the thread.

If no one can offer that summary, perhaps the participants will consider 
taking the exchange private?

d/

----------

---

From: Alex Audu <[email-masked]>
Date: Wed, 31 Jul 2002 13:19:54 -0500

Ed,

I think Keith has a point here. Manual intervention to resolve ambiguous
names is not ideal
for automated operation. You can argue that such intervention need not be
manual, but
automating your proposal will be convoluted at best.  But it is a
possible solution.

Regards,
Alex.

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Wed, 31 Jul 2002 13:29:39 -0700

Ed and Stef are smart enough to know that the IETF won't seriously 
consider their "proposals" without an Internet Draft; the fact that 
one doesn't exist should tell us all something.

Ed and Stef are also smart enough to know that for every response 
they give, someone else will keep up the conversation. Is this really 
the best use of the IETF mailing list?

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Ed Gerck <[email-masked]>
Date: Wed, 31 Jul 2002 15:29:09 -0700

Paul:

IMO, this thread is just an example of a need to find a logical way to describe
the DNS problems and the solutions. Part of the problem in the DNS discussions,
IMO, is that there is not even a "language" to describe the problem -- which, then,
tends to frustrate the participants in a dialogue, and we get postings like yours.

Public discussions, however, should also help develop such language, and that is
why we need to use them not for troll feeding but to serve the higher purpose of
communication -- while the postings that may serve the purpose of stopping
communication should be tappered off.  Then, from this improved language,
an Internet Draft will flow most naturally and be most naturally received.

Thus, I would invite you, either off- or on-list, to present your technical
viewpoint -- which I am sure is very valuable. My observation is simple to describe.
If a name query returns two answers (and today's malconfigured systems
may do just that, too) but we have a meta-system that is able to automatically
(or, manually if we so wish) disambiguate them for us so, then we are fine. The
point is that rather than trying to be always decidable and complete (which
attempt WILL fail), we have a system that is as complete as possible and leaves
the decidability issue to a meta-system. Different meta-systems may decide in
different ways, but this is good too -- because you can choose which meta-system
to  use.

Note that I always mention "meta-system" -- I would not suggest changes
to the DNS, in the same that I was not in favor of changing the DNS in
order to accomodate PKI.

Finally, my thought is that if we are willing to use public discussions to mine the
gold of truth, then we should be open and receptive to those discussions, as well
as when to end them and digest what was said.

Thanks for your input.
Ed Gerck