Subject: RE: way out of the DNS problems? (former Re: delegation mechanism, Re: Trees have one root)

From: "Sean Jones" <[email-masked]>
Date: Thu, 1 Aug 2002 17:22:15 +0100

Hi

This is my first posting to the IETF mailing lists, so please forgive me if I do something wrong.

<snipped to get to the crux>

> Solution 3. we keep going but we rebuild anew. This seems to be the 
> impossible ICANN policy in building their Intercontract system. It 
> obviously does not work and leads to strong oppositions.

> The reason why I join the IETF debate is that I think 
> technology may be the 
> response. The same as the namespace agreement has aged, the same the 
> technology has aged. We are endlessly arguing on old stuff. Aftyer 20 
> years, we need a clean sheet review of the DNS, based on 
> today and future 
> users' needs. IMHO this goes into two directions: a new DNS 
> core system 
> analysis (DNS.2) and an extended DNS services (DNS+) logic. 
> IMHO in going 
> ahead in that two directions (as the iDNs show the path) we will soon 
> discover that the ICANN preoccupations and solutions are 
> totally outdated 
> by what we will uncover and specify.

> Obviously we will meet the same kind of oppositions to 
> DNS.2/DNS+ than was 
> met for IPv6. The question is then to know if this effort 
> will be carried 
> within the IETF or not. I think DNS.2 cannot be specified 
> outside of the 
> IETF but a DNS.1.B can. Most of DNS+, which comes before / 
> aside / on top 
> of the DNS, can be privately developped, but without proper 
> integration. 
> This would lead to a large number of proprietary solutions 
> and to large 
> splits in the usage of the network.

> So the question is not to know if we have to make that effort 
> or not, but 
> if it will be a clean move or not. To take a comparison, 
> situation in the 
> DNS today is like if IPv8 was the only option.
> Sorry to have been long. This all I had to say.
> jfc

IMHO Networking and Internetworking has changed in many ways since it was first introduced.

I am fully aware of the history if the Internet and of how basic networks work. *BUT*

The fundamentals of networking have not dramatically changed in all the time that we have used networks.

Another, *BUT* and it's a big but, there is no way the original designers of networks could have any conception of just how much they have grown and expanded into the Corporate networks and the Internet that we have today. 

Since the underlying DNS structure was basic and simple it still works today, but (as many more technically qualified people could/will point out), only just! and it's limitations are showing.

In practical reality it is simply not possible to "rip it out and start again". IPv4 needs to be replaced, however since NAT and a few other "temporary fixes" have given it extra life people have not moved onto IPv6 as much they should have(?)

So solution 4 needs to be designed, IMHO we need a solution that can take what we have today and "evolve" into tomorrow's solution, which will actually be solution 5, and what we should have if we "ripped it out and started again" 

BUT (sorry I have to keep using this word atm) where to start.....

Regards

Sean Jones

---

From: Bob Braden <[email-masked]>
Date: Thu, 1 Aug 2002 22:34:59 GMT

*> 
  *> > On Thu, 1 Aug 2002, JFC (Jefsey) Morfin wrote:
  *> > 
  *> >> I am sorry to repeat it (and I will try not to say it too
  *> >> many times again): the terms of the ".arpa" sub global
  *> >> namespace delegation are described in RFC 920 by Jon Postel
  *> >> himself.
  *> > 
  *> > Request For Comment number 920 is simply a now historic record
  *> > of a policy statement between the IAB and the DARPA in 1984
  *> > regarding establishment of Top Level Domains, and had a focus
  *> > predominately on USA-based organisations.
  *> >...
  *> 
  *> Two additions to Bruce's comments...
  *> 
  *> (i) While I was not involved in the discussions leading up to,
  *> or surrounding, RFC 920, I do have some recollections from
  *> earlier and subsequent periods.  Given those recollections, and
  *> what 920 actually says, I find it fairly difficult to believe
  *> that any part of that RFC was motivated by a name-space-division
  *> agreement between Jon and/or the ICCB/IAB and a collection of
  *> operators of systems based on OSI or other protocols.

Indeed.  We have a serious case of fabricated history here.  You may be
very sure that Jon's choices were not influenced by OSI or any other
standards entity.  If indeed he was even aware of OSI or ITU
considerations at the time, he certainly would not have cared (but he
might have been amused) .  Nor did any agency of the US government play
any role at all.

Bob Braden

---

From: Einar Stefferud <[email-masked]>
Date: Fri, 2 Aug 2002 01:02:09 -0700

[SNIP]... [SNIP]... [SNIP]... [SNIP]... [SNIP]... [SNIP]... [SNIP]... [SNIP]...

>May I remind you that this is the Internet _Engineering_ Task Force.  The
>IETF's task is to propose and implement technical solutions for the
>Internet.  Political arguments on meta designs such as who should control
>the Top Level Domain(s) or why some organisation with an amusing acronym
>should not be in control, whilst an amusing and non-productive way to
>wile away an afternoon, should not be part of the IETF discussions.
>
>Alternative Roots are just that, Alternatives, or more accurately, amusing
>Non-Portable Fragmented Extensions of the Current Root.
>
>- --
>   Bruce Campbell.                                 My opinions are my own.

[SNIP]... [SNIP]... [SNIP]... [SNIP]... [SNIP]... [SNIP]... [SNIP]... [SNIP]...

I think it is time for a little adjustment of the semantics of this discussion.

There are no "Alternate" roots, in spite of many who persist in using
the term as a wedge issue to prevent meaningful discussion.

ORSC is not an alternative in the normal sense of that word, which is that
one must choose A, or B, but not both.

To the contrary, ORSC is Inclusive, by careful policy design.

Users of ORSC root servers have access to ICANN TLDs Plus ORSC TLDs.
So, your choice is between an Exclusive root (ICANN), or an Inclusive
Root (ORSC).

In fact, every computer system user with root privileges  has the
power to select in the privacy of his or her own bedroom, which root
service to use.  This is in the DNS standards specifications, and is
going to be very hard to either remove, or unilaterally  override, or
to simply ignore.

Of course, ORSC, will be called an "alternative" root by those who do
not want conflict problems resolved, for reasons that we can only
speculate about, and speculation is no longer useful here, so I will
not speculate.  The fact of being stalled is clear enough without
speculating about why or how we got here.  Obfuscation is not going
to lead to any useful results!  We must clean up our use of our
language if any progress is to be made.

In an ideal world, the inclusive root would not have any collisions
because the root service operators and the TLD applicants would talk
with each other to sort out the issues and resolve all the conflicts.

But, in the real world, if the Exclusive Root Service has no
incentives to talk to the Inclusive Root service, then the Inclusive
Root service has no way to deal with cases where the Exclusive Root
Service simply barges into a collision without affording any way to
resolve the injuries and damages thus caused, either before or after
the colliding TLD is/was actually mounted.

It is exactly like trying to sleep with an Elephant.  The elephant
might not be malevolent, but it is going to be really hard to get any
sleep.

Such is the case for the relationship between ICANN and ORSC at this point.

The Exclusive Root Service refuses to accept that there is anything
to discuss with anyone when they decide to award a new franchise to
any new TLD registry bidder, when the new Exclusive Root TLD
conflicts with an existing Inclusive Root Service TLD.  This is the
case even after due notice has been given in advance to the Exclusive
Root Service Board of Directors.  In fact, in the .BIZ case in hand,
the already operating (since 1996) .BIZ TLD registry also submitted
an application at a non-refundable cost of $50,000, just to be
considered, so it is very hard to see how this collision could have
been an accident.  I will not speculate about any motives.

So, here we are, stuck in a situation where there is no way out short
of the two parties actually discussing the issues and seeking some
kind of mutually acceptable resolution.  This process is normally
called "Coordination"; without which it is going to be exceedingly
difficult to coordinate future TLD delegations by the Exclusive Root
Service.  By proceeding with blinders on (i.e., DWB: Driving While
Blind), the Exclusive Root Service is in fact destabilizing the net
when its given mission is supposedly to stabilize the net.

In the midst of all the hoopla surrounding these issues, this case is
the only really serious unresolvable conflict collision problem to
have arisen since 1996.

So, the (ORSC) Inclusive Root Service's primary request of the
Exclusive Root Service, is to be fairly considered and to be allowed
to sit down and have a rational discussion about how to resolve the
difficulties with conflicts, and resolve this (.BIZ) conflict in
particular.

In short, the ORSC request it to engage is some useful coordination.

Why coordination is not allowed is left as an exercise for the readers;-)...

ORSC (the Inclusive Root Service) has done a very good job over the
last 4-5 years of coordinating the Inclusive Root Zone and resolving
conflicts, until the Exclusive Root Zone control agency unilaterally
created a collision and refuses to acknowledge the fact of it.

Our policy is simple and clear.  ORSC will not admit any new TLD
registry if there is any outstanding claim by another party to the
same TLD name.  This policy derives from clear text in RFC-1591,
under which the disputed TLD was granted permission to proceed to
mount .BIZ in 1996.  It has survived until now.

So, the Inclusive Root Service (ORSC), which has honored that first
deployment of .BIZ from its establishment, considers that the .BIZ
rights have been trespassed, and that there exist solid grounds for
at least engaging in discussions.

.BIZ was established next after .WEB, which was given due
consideration for it's existence, but was denied entry into the
Exclusive Root Service.

I, and ORSC, make no claims as to how the .BIZ situation might be
resolved.  Our only claim is for the right to a fair and honest
discussion of the facts and an honest effort to find a resolution.

When completed, we will have seriously tried to find an acceptable
resolution to all the outstanding issues in the conflicted situation.

There are no technical issues involved in this situation, other than
the technical fact that a collision with two .BIZ TLD registries with
colliding SLD entries causes trouble for the current DNS operations
of both root services and both .BIZ registries and all .BIZ
registrants, and the appropriate way to resolve the collision cause
is to discuss it among the contending parties.

The ORSC policy rule (ala RFC 1591) would be that without the two
contending TLD Registry operators agreeing to a settlement that
reduces the conflict to a single contender, neither can be entered in
either (or any) root service.  The details of this need to be
resolved by the two contending TLD registry applicants.  Melding the
two registries is a problem that they two registries should figure
out.  Any form of accepted mutual resolution should be acceptable.

If ICANN had set this rule in place when approving their .BIZ
candidate, I am certain that a settlement would have been found post
haste.  And still could be found post haste if ICANN will agree to
proceed with coordinative discussions.

So far ICANN denies all knowledge of any of the facts;  While ORSC
stands ready to engage in finding a resolution between the contending
registry applicants.  Without ICANN engagement, the ICANN delegate
has no incentive to settle any differences.

Tennis anyone;-)...\Stef