Subject: Beyond China's independent root-servers -- Expanding and Fixing Domain Notation

From: Mohsen BANAN <[email-masked]>
Date: Thu, 02 Mar 2006 00:26:23 -0800

More than 5 years ago I predicted what the Chinese
government announced today.

What happened today:

http://english.people.com.cn/200602/28/eng20060228_246712.html
http://www.interfax.cn/showfeature.asp?aid=10411&slug=INTERNET-POLICY-MII-DOMAIN%20NAME-DNS
http://www.domainesinfo.fr/vie_extensions.php?vde_id=859
http://politics.slashdot.org/politics/06/02/28/1610242.shtml
http://news.com.com/China+creates+own+Internet+domains/2100-1028_3-6044629.html

was obvious and quite easy to foresee.

Addressing the requirements of a very real
international multi-root environment is also not
all that hard and will likely naturally evolve.

But there is more that can be done. The Internet
technical community is now given a unique
opportunity to expand the domain notation and even
address past mistakes and fix the domain
backwardness problem.

About 4 years ago, in a note with the subject of:

 Revisiting - Re: Now: Next Generation Domains and DNS -- Was: Re: No More Central Authority: Not NSI/ICAN! Not ORSC!

I re-sent the write up (dated Jan 1999) for what
needs to be done to move things forward. It is
included here again below.

Obviously, IETF is not fit to move this forward.

If anybody translates this plan into Chinese,
please email me a copy.

-- Mohsen BANAN

To: Internet Technical Community <ietf at ietf.org>
Subject: Revisiting - Re: Now: Next Generation Domains and DNS -- Was: Re: No More Central Authority: Not NSI/ICAN! Not ORSC!
From: public at mohsen.banan.1.byname.net
Date: 06 Aug 2002 06:42:23 -0700
Sender: owner-ietf at ietf.org

Good!

After many years, the Internet technical
community (save ICANN and IETF cult's chiefs)
has now arrived to the general recognition
that the concept of parallel root server clusters
are in fact practical, workable, stable and democratic.

It may now be a good time to re-visit other DNS problems
and recognize that they can also be solved.

Most notably, The DNS Notation Backwardsness.

Parallel root server clusters and the fixing of the
DNS Notation Backwardsness problem are very related and
can be done at the same time.

I explained all of this in reasonable detail more than
3.5 years ago. It is comforting to see that parts of
the solution that I proposed is now in place.

Below is the main email from the thread that I introduced
in 1998/1999.

At that time, with hope, I said:
   I believe it is only now that we have an opportunity to
   plant the right seeds so that the "problem" can
   be fixed over time.

>>From a historic perspective it is worthwhile noting that
shortly after Bob Allisat suggested that the IETF build
on the concepts that I had introduced, he was banned from
the IETF mailing list by the then IETF Chair,
Fred Baker.

While I address this message to the
Internet technical community,
if in fact IETF does not stand for
Innovation Extermination Task Force,
then perhaps even IETF can get involved
in cultivation of these concepts.

--- 1999 Original Message Follows ---

To: IETF Mailing List <ietf at ietf.org>
Subject: Re: Now: Next Generation Domains and DNS -- Was: Re: No More Central Authority: Not NSI/ICAN! Not ORSC!
Date: Tue, 26 Jan 1999 00:41:34 -0800 (PST)

[This is a summary response which covers comments
 which were in reply to my:
     <199901220641.WAA11066 at rostam.neda.com>
 message with the subject of:
 Re: Now: Next Generation Domains and DNS -- Was: Re: No More Central Authority: Not NSI/ICAN! Not ORSC!
 dated Thu, 21 Jan 1999 22:41:13 -0800 (PST).]

I ended my previous note, by saying:

>>>>> On Thu, 21 Jan 1999 22:41:13 -0800 (PST), Mohsen BANAN <mohsen at neda.com> said:

  Mohsen> ...

  Mohsen> Now, after all of this if there was to be an
  Mohsen> acknowledgment that there is an architectural
  Mohsen> problem here and that this is not a "strings
  Mohsen> parsing" issue which can go either way, then
  Mohsen> may be we can work on solutions ....

Many got the point -- that there is a "notation backwardness" problem.

For example:

>>>>> On Fri, 22 Jan 1999 08:42:32 -0000, "mark.paton" <mark.paton at btinternet.com> said:

  mark> I hate to admit it but he has a point!

and:

>>>>> On Fri, 22 Jan 1999 14:50:41 +0400, Peter Dawson <peterdd at gto.net.om> said:

  Peter> ...

  Peter> How come  the folks don't admit the mistakes and just
  Peter> keepcontinuing..  ?? we all understand it is human to err..  !!

and:

....

Now, we just have got to leave behind those who
after all of this, still don't get it and can't
(or don't want to) follow.

I -- and many others -- have known about this
notation backwardness for more than 10 years.
Prior to last week, I had never brought up this
issue publicly.

There is a good reason why I chose 1999 as the
time to bring it up. That is because, I believe
it is only now that we have an opportunity to
plant the right seeds so that the "problem" can
be fixed over time.

Taking advantage of this opportunity to fix it
is a lot more reasonable than "living" with it.

>>>>> On Fri, 22 Jan 1999 04:14:55 -0500 (EST), "Theodore Y. Ts'o" <tytso at MIT.EDU> said:

  Theodore> ...

  Theodore> 	Whether or not you call this a "Problem" depends on your point
  Theodore> of view.  But this is reality.  Live with it.

Ted, you live with it. If you want to.

I am an engineer. I try to fix problems when
the opportunity presents itself.

Please consider what I refer to as the
"opportunity to plant the right seeds", with an
open mind for a moment.

May be it is workable.
May be it is not.

Worstcase, we live with it.

I want to try.

Yes. This problem has widespread roots.

>>>>> On Fri, 22 Jan 1999 10:09:02 -0800 (PST), Ned Freed <Ned.Freed at innosoft.com> said:

  Ned> I am in complete agreement with Ted here. I also have issues with the way
  Ned> things work and the way things were done, but I recognize that this stuff is
  Ned> far too widely deployed at far too many levels to change now.

Ned, I understand (and respect) the
significance of the installed base as much as
the next guy.

That is why I don't refer to this as a "quick fix"
but as a "planting of the seeds" type of an
approach.

In order to understand what I am proposing we
have to consider it in the larger context of
Domains and DNS ambiance of 1999.

Let's put everything on the table and take a
quick look.

 - We have a DNS-mess grid-lock.

   At least according to some (me
   included). The idea of
   expanding top level domains have gone
   nowhere. Introducing competition at the
   root-server and registration level has gone nowhere.
   General confidence in progress is low ...

 - Updates to DNS Software (both client and
   server) for beyond IPv4 addresses are needed.

 - Updates to DNS Software (both client and
   server) for security, public keys, certificates,
   ... are needed.

 - As phone numbers and Domains keep coming
   together, the domain notation's backwardness
   is becoming more visible and significant.

 - ...

Since it appears that we have to go through a
global DNS client software update, it makes
sense to address all of the above issues more
or less in one shot.

Now, I am suggesting that as we consider
updates to DNS Software (particularly client),
it is reasonable and good to plant the seeds
for a forward domain notation as well.

I am also suggesting that we loosely link the
new notation to the concepts of completely
independent and seperate Top Level Registries
and independent root-server clusters. [Note
that these two concepts (notation and multiple
independent root-server cluster) are not
necessarily connected to each other.]

Let me explain what I consider a workable
approach that will address a number of current
DNS challenges.

First, I need to introduce some names for the
needed concepts.

Let's call:

Plain Old Domain Notation (PODN):
---------------------------------
   today's domain notation.
   For example:
        www.ietf.org

Forward Domain Notation (FDN):
------------------------------
   The new forward notation for domains.
   This notation includes a
     "Name Resolution Selector (NRS)"
   For example:
	r1:org.ietf.www

Backward Domain Notation (BDN):
------------------------------
   The new backward notation for domains.
   This notation includes a
     "Name Resolution Selector (NRS)"
   For example:
	www.ietf.org.r1

   BDN is same as PODN but has the
   the Name Resolution Selector on top of what
   used to be the TLD.

Name Resolution Selector (NRS):
-------------------------------
   An identifier which says which root-server
   cluster should be used.
   For example:
     r1:org.ietf.www (or www.ietf.org.r1)
     says use "r1" root-server cluster
     to resolve www.ietf.org (PODN).

   Note that the NRS is capable of identifying
   the method (i.e., protocol) in addition to
   the root-server cluster.

Forward Bind:
-------------
  Updates to the bind (or its equivalent)
  package which includes the
  Forward Domain Notation as its canonical
  notation and which supports name resolution
  based on multiple co-existing but separate
  root-server clusters.

I am claiming that the above ingredients can
break the DNS-mess grid-lock and can position
us to address the backwardness of the Notation
over time.

To look at how this all is supposed to fit
together we need to consider at least the
following dimensions:

	- The Protocols
	- The Resolver Software
	- Operation of Root-Server Clusters

Then, we also need to consider the "Motivations" and
"Transition".

The Protocol
============

Initially, DNS requires no protocol changes.

This needs to be verified by a quick
proto-type or ....

The Resolver Software
=====================

What I call "Forward-Bind" needs to have the
following key characteristics:

 - Support access and use of multiple
   root-server clusters.

   Presently a single
     /etc/named/named.ca
   file is used by Bind.

   Forward-Bind can use multiple root-server
   clusters and therefore multiple root cluster
   information is needed. For example
	r1.named.ca
	r2.named.ca
	...

 - Support the explicit
   Name Resolution Selector (NRS) notation.

   When FDN or BDN are used, the use of the specified
   root-server cluster is explicit.

 - Support implicit name resolution selection.
   This is essentail for the transition period.

   When PODN is used, selection of the root-swerver
   cluster to use is determined by a somewhat static
   map of TLDs to root-server cluster.

   The assumption is that through agreement amongst
   root-server cluster operators there will be no
   duplicate TLDs across root-server clusters.

   If there is a problem, still the user gets to
   choose.

 - The software supports all three notations --
    PODN, FDN, BDN -- from the very beginning

The key attribute of this software is that by
supporting choice in selection of root-server
clusters, it empowers the user.

Operation of Root-Server Clusters
=================================

Each Root-Server Cluster runs its root serves and
has its own independent registration policy.

There is little, if any co-ordination that is
required amongst the Root-Server Clusters.

These Root-Server Clusters compete to provide the
cheapest and the most reliable domain registration
capabilities to their users.

Something like part of ICANN can be considered the
consortium of Root-Server Cluster operators which
can accommodate distribution of the generally static
information needed for smooth operation of what I
like to call Next Generation DNS.

In the interim, while use of FDN and BDN is not
widespread, uniqness of TLDs and the distribution
of TLD to NRS map is another thing that the
consortium of Root-Server Cluster operators needs
to do.

Having covered what it takes to make this happen,
let's see Why people may want to do this.

*MOTIVATIONS*
-------------

The likes of Bob Allisat want to empower the user.

All kinds of people want to compete with NSI ...

And, the Network must remain stable and reliable.

What I am suggesting here involves no changes to the
current operation. It just allows for peer universes
to co-exist with the current established one.

Because this idea centers around selection of the
root-server by user's software, creation of these
peer universes is outside of any particular
authority.

It is in the collective user community's interest
that the Network remains stable. Therfore, we are
likely not to end up with anarchy.

To make this happen, no particular permission is
needed from anyone. Just make what I have been
calling Forward-Bind widespread and set up the
parallel root-server clusters.

As an example, let's say that the
AOL, Netscape, Sun, ... combo wanted to mass
register domains without going through NSI.

They can easily make Forward-Bind widespread.  Then,
they can set-up their own root-server cluster.  Then
mass register domains (say under r2:nom such as
john.smith.nom) for their users and everybody else.

Now NSI has competition and the user has choice.

*TRANSITION*
------------

Using the above example, initially the root-server
selector map will look something like:

  org, net, com            :r1  # Current (NSI, ...)
  nom, web                 :r2  # Example: AOL, Netscape, Sun, ..
  store, www               :r3  # somebody else

This is likely to be quite a static map which gets
distributed with the software. I don't consider
occasional updates to this map or addition of
r4.named.ca a difficulty.

Initially there can be no conflict between TLDs
across root-server clusters.

Once Forward-Bind is widespread, then addresses of
the form acme.com.r1 and acme.com.r2 can even be
used and the "no same TLD across root-server
clusters" limitation goes away.

Next step is to gradually transition to FDN.

FDN and BDN can easily co-exist for a long time.

Because FDN was planted in the Forward-Bind from the
beginning, transition to FDN is a matter of its
support in application protocols. This requires
Architectural Leadership. But, where is that going to
come from? IAB? :-)

Once FDN is inside of Forward-Bind, it is possible
for us to define new network object identifiers such
as:
     r2:net.ByNumber.1.888.555.2222:voiceOverIp:"collect"

for new protocols and at least move forward with
FDN.

At a component level, may be there is not all that
much that is new in what I am suggesting. But, may
be the combination of:

  - Enhancing the desktop software to provide for
    choice and selection amongst root-server
    clusters.

  - The creation of multiple indpendent root-server
    clusters.

  - Enhancements to the notation which makes the
    traditional TLDs not absolute and breaks the
    current monopoly.

  - Providing the user the ultimate control and
    selection.

is new.

I think there is enough detail in this message to
let people decide if this idea is workable or not.

Because I think this (or some variation of it) is
workable, I needed to get this out.

Those who feel this is worthy of exposure in
various DNS-mess related forums are welcome to
forward it to other relevant mailing lists.

For now I consider my part done.

I know that something like this is likely to be
controversial.

I am likely not to further participate in this
thread. You don't need to insult me on that
account. Questions and comments that are expressed
politely have a better chance of tempting me to
respond.

...Mohsen

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Joe Baptista <[email-masked]>
Date: Thu, 02 Mar 2006 08:42:08 -0500

>government announced today.
This action by the chinese was done three years ago.  This is not a new 
event.

regards
joe

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 2 Mar 2006 22:26:59 +0800

On Thu, Mar 02, 2006 at 12:26:23AM -0800,
 Jefsey Morfin, disguised as Mohsen BANAN
<[email-masked]> wrote
 a message of 551 lines which said:

> The Internet technical community is now given a unique opportunity

There is nothing to do for the IETF or the "Internet technical
community" (whatever it is). The problem is 100 % political and should
be addressed in ICANN / WSIS / IGF / whatever but not in the IETF.

> Forward Domain Notation (FDN):

You simply have a new root, the one which will decide who gets r1, who
gets r2, etc. This is simply playing with words, like the ITU when
they claim the telephone has no root (simply because the equivalent of
the root zone file is hardwired in the international exchanges).

And you break a nice property of the DNS, the consistency of naming
(the separator is the same, whatever the level, or the zone you're
in).

>  - Support implicit name resolution selection.  This is essentail
>  for the transition period.

This is simply a default, hardwired in the name server. Every Web
browser has it (try typing "ibm", without the ".com" in your
browser). You will not get a Nobel prize for this.

> Each Root-Server Cluster runs its root serves 
                                         ^^^^^^
                                         Nice typo

> I am likely not to further participate in this thread.

What a relief!

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Fri, 03 Mar 2006 04:51:07 +0100

>  a message of 551 lines which said:

Mohsen,
it seems that Stephane tested the Chinese open root too much and 
meets some naming problems.
Or that Stephane wants you, and others may-be, to be PR-defamacted 
one shot with me.
jfc

PS. I note his technical evaluation that "The problem is 100 % 
political and should be addressed in ICANN / WSIS / IGF / whatever 
but not in the IETF." I suppose this means that the Chinese Domain 
Names are seen as a "problem" (Chinese people and other linguistic 
communities members may see them another way) and that the related 
technical issues either do not exist or are no part of the IETF concerns.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 03 Mar 2006 15:36:39 +1100

> technical issues either do not exist or are no part of the IETF concerns.

	They are still a problem whether you think they should exist
	or not.  The problem is that they are added unilaterally
	and people using them expect everyone else to be able to
	resolve them as well.  The method of adding them was wrong
	as it does not scale.  If every language added the equivalent
	you would have hundreds of sets of nameservers that you
	would have to track down and add to your own configuration.

	The whole point of the DNS was that you didn't need to do
	that because it provide a *single* namespace from a *single*
	set of servers and you didn't have to graft on hundreds of
	TLDs.

	Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "Mohsen BANAN"@mail.intra, [email-masked]
Date: Fri, 03 Mar 2006 01:47:01 -0800

>>>>> On Thu, 2 Mar 2006 22:26:59 +0800, Stephane Bortzmeyer <[email-masked]> said:

  Stephane> On Thu, Mar 02, 2006 at 12:26:23AM -0800,
  Stephane>  Jefsey Morfin, disguised as Mohsen BANAN
  Stephane> <[email-masked]> wrote
  Stephane>  a message of 551 lines which said:

Hello Stephane Bortzmeyer.

I have no reason to believe that you are not
Stephane Bortzmeyer.

Why are you publicly accusing Jefsey Morfin of
masquerading as me, Mohsen Banan?

That is bad form, you know.

I can assure that I am me, and he is he, and we
are not the same. 

I think you should publicly apologize for wrongly and
baselessly accusing him of pretending to be
someone else.

I wrote the email that you have quoted. Had you
put "Mohsen Banan" in the google box and clicked
on "I'm Feeling Lucky," you would have landed on:

  http://mohsen.banan.1.byname.net/ProfessionalBio/

You could also grep for my name in the RFC series ...

If Jefsey (Jean-Francois C. MORFIN) were really
masquerading as someone else, he would surely
choose an unknown, a nonentity, a cipher. But I am
none of those things. I have a history.

I do not recall having ever met Mr. Morfin and
don't know him other than from his participation
on this list. Based on his writings, I consider
him far more reasonable than the typical IETF cult
leader or your typical IETF groupie.

His notes I do not ignore. Outside of this
clarification, the rest of your remarks I can
comfortably ignore.

Regards,

...Mohsen

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Fri, 03 Mar 2006 15:24:53 +0100

>         would have to track down and add to your own configuration.

This does not express a problem in itself. This expresses a 22 years 
old need. The IETF problem should be to address that need. But it 
seems this is not a problem.

>         set of servers and you didn't have to graft on hundreds of

This is not a DNS feature. This is a result of the unique space of 
the prototype network. This is precisely because the Internet 
technology cannot (yet) support multiple spaces that the Chinese 
solution is not off the shelves. But documenting this solution 
(permitting externets consistency, continuity and interoperability) 
seems not to be the IETF's cup of tea. I approached the problem in 
different ways (open roots, network architecture parameters, ICANN's 
ICP-3 call for a test-bed in that domain, liaison with ccTLDs, 
multilingualism, multilateralism, IPv6, ethic, etc). The IETF 
consensus is consistent: no real interest, predetermined doctrine, 
some active confusion serving commercial interests (as documented by 
IAB in RFC 3869) and cultural hysteresis (as documented by RFC 3744).

I conclude this is now to be docFrom [email-masked] Fri Mar 03 09:27:17 2006
Date: Fri, 03 Mar 2006 15:24:53 +0100
To: Mark Andrews <[email-masked]>
From: "JFC (Jefsey) Morfin" <[email-masked]>
Cc: [email-masked], IETF <[email-masked]>
Subject: Re: Beyond China's independent root-servers -- Expanding and
 Fixing Domain Notation 

>         would have to track down and add to your own configuration.

This does not express a problem in itself. This expresses a 22 years 
old need. The IETF problem should be to address that need. But it 
seems this is not a problem.

>         set of servers and you didn't have to graft on hundreds of

This is not a DNS feature. This is a result of the unique space of 
the prototype network. This is precisely because the Internet 
technology cannot (yet) support multiple spaces that the Chinese 
solution is not off the shelves. But documenting this solution 
(permitting externets consistency, continuity and interoperability) 
seems not to be the IETF's cup of tea. I approached the problem in 
different ways (open roots, network architecture parameters, ICANN's 
ICP-3 call for a test-bed in that domain, liaison with ccTLDs, 
multilingualism, multilateralism, IPv6, ethic, etc). The IETF 
consensus is consistent: no real interest, predetermined doctrine, 
some active confusion serving commercial interests (as documented by 
IAB in RFC 3869) and cultural hysteresis (as documented by RFC 3744).

I conclude this is now to be documented by a TF specialising in 
International Network architecture and transnetwork/transtechnology 
solutions. This calls for a generalised vision wich will probably 
better develop within the IGF. In the increasing number of people I 
know sharing that evaluation I am currently alone (and opposed on 
both sides) actively supporting that interoperability with IETF 
propositions should be maintained as much as possible. Or the lack of 
interoperability to be limited (this is what I succeded to do with 
RFC 3066 Bis). A solution is to keep informing the IETF through IETF 
Drafts and IESG appeals when interoperability/interintelligibility 
seem compromised. Another is to organise a structure assuming liaison 
as part of the Internet standard process. I documented that project 
as the IGFTF in my positive (on other grounds) appeal to IAB. I 
however delayed it to permit Brian to possibly update RFC 2026 such a 
project should strictly respect.

jfc

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Fri, 3 Mar 2006 05:10:32 +0100

> all that hard and will likely naturally evolve.

To best of my knowledge, that there are no new Chinese root-servers -  
despite what the press says. And at least we have not seen a drop in  
queries to our anycast instance in Beijing yet so there even seems to  
be data to support that...

But what do I know...

- kurtis -

---

From: Peter Dambier <[email-masked]>
Date: Fri, 03 Mar 2006 17:58:19 +0100

> be data to support that...

Hi Curtis,

at least we can see these domains. Can you see them too, on the
nameservers you are using?

; <<>> DiG 9.1.3 <<>> -t any XN--55QX5D. @hawk2.cnnic.net.cn.
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46417
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 3

;; QUESTION SECTION:
;XN--55QX5D.                    IN      ANY

;; ANSWER SECTION:
XN--55QX5D.             3600    IN      SOA     hawk2.cnnic.net.cn. root.cnnic.cn. \
                                                 2006030104 3600 900 604800 3600
XN--55QX5D.             3600    IN      NS      hawk2.cnnic.net.cn.
XN--55QX5D.             3600    IN      NS      cdns3.cnnic.net.cn.
XN--55QX5D.             3600    IN      NS      cdns4.cnnic.net.cn.
XN--55QX5D.             3600    IN      NS      cdns5.cnnic.net.cn.

;; ADDITIONAL SECTION:
cdns3.cnnic.net.cn.     38      IN      A       210.52.214.86
cdns4.cnnic.net.cn.     518     IN      A       61.145.114.120
cdns5.cnnic.net.cn.     518     IN      A       61.139.76.55

;; Query time: 410 msec
;; SERVER: 159.226.6.185#53(hawk2.cnnic.net.cn.)
;; WHEN: Fri Mar  3 17:53:18 2006
;; MSG SIZE  rcvd: 215

; <<>> DiG 9.1.3 <<>> -t any XN--FIQS8S. @hawk2.cnnic.net.cn.
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61182
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 3

;; QUESTION SECTION:
;XN--FIQS8S.                    IN      ANY

;; ANSWER SECTION:
XN--FIQS8S.             3600    IN      SOA     hawk2.cnnic.net.cn. root.cnnic.cn. \
                                                 2006030104 3600 900 604800 3600
XN--FIQS8S.             3600    IN      NS      hawk2.cnnic.net.cn.
XN--FIQS8S.             3600    IN      NS      cdns3.cnnic.net.cn.
XN--FIQS8S.             3600    IN      NS      cdns4.cnnic.net.cn.
XN--FIQS8S.             3600    IN      NS      cdns5.cnnic.net.cn.

;; ADDITIONAL SECTION:
cdns3.cnnic.net.cn.     574     IN      A       210.52.214.86
cdns4.cnnic.net.cn.     451     IN      A       61.145.114.120
cdns5.cnnic.net.cn.     451     IN      A       61.139.76.55

;; Query time: 399 msec
;; SERVER: 159.226.6.185#53(hawk2.cnnic.net.cn.)
;; WHEN: Fri Mar  3 17:54:25 2006
;; MSG SIZE  rcvd: 215

; <<>> DiG 9.1.3 <<>> -t any XN--IO0A7I. @hawk2.cnnic.net.cn.
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35342
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 3

;; QUESTION SECTION:
;XN--IO0A7I.                    IN      ANY

;; ANSWER SECTION:
XN--IO0A7I.             3600    IN      SOA     hawk2.cnnic.net.cn. root.cnnic.cn. \
                                                 2006030104 3600 900 604800 3600
XN--IO0A7I.             3600    IN      NS      hawk2.cnnic.net.cn.
XN--IO0A7I.             3600    IN      NS      cdns3.cnnic.net.cn.
XN--IO0A7I.             3600    IN      NS      cdns4.cnnic.net.cn.
XN--IO0A7I.             3600    IN      NS      cdns5.cnnic.net.cn.

;; ADDITIONAL SECTION:
cdns3.cnnic.net.cn.     493     IN      A       210.52.214.86
cdns4.cnnic.net.cn.     370     IN      A       61.145.114.120
cdns5.cnnic.net.cn.     370     IN      A       61.139.76.55

;; Query time: 400 msec
;; SERVER: 159.226.6.185#53(hawk2.cnnic.net.cn.)
;; WHEN: Fri Mar  3 17:55:46 2006
;; MSG SIZE  rcvd: 215

regards
Peter and Karin

-- 
Peter and Karin Dambier
The Public-Root Consortium
Graeffstrasse 14
D-64646 Heppenheim
+49(6252)671-788 (Telekom)
+49(179)108-3978 (O2 Genion)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [email-masked]
mail: [email-masked]
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/

---

From: Joe Baptista <[email-masked]>
Date: Fri, 03 Mar 2006 12:15:57 -0500

> be data to support that...

There are. Check Peter Dambiers messages for details.

As for you claims of data to support this - show us.

First - you won't notice any drop in queries because the china roots 
refers all queries concerning NON-CHINESE TLDs back to IANA.

Second - you will notice an increase in what you guys at the roots call 
I think illegal or erroneous TLDs - which see

http://www.theregister.co.uk/2003/02/05/dud_queries_swamp_us_internet/

Incidentally - since my article was written I have not seen any further 
studies concerning root traffic from CAIDA or anyone else.  In fact root 
operators don't really share much with the world - do they?

cheers
joe baptista

---

From: Joe Baptista <[email-masked]>
Date: Fri, 03 Mar 2006 12:32:58 -0500

>	would have to track down and add to your own configuration.
I agree with you - it does not scale well - over time root which fail to 
carry the chinese TLD labels will get swamped with quereis.  However -  
I completely disagree with your view that the method used to add them 
was wrong.  It was very right for the chinese to act unilaterally.  The 
alterative, open, or public set the standards for TLD holders and root 
system to act unilaterrally.

The chinese approached ICANN some five years ago to have their TLDs 
included in the IANA root.  ICANN gave them the finger and they much 
like the open root TLD operators gave ICANN the boot.  Now mind you the 
chinese have a much bigger boot then the open roots - so I anticipate 
this is a much more painful experience.

Give my luv to Paul
Joe Baptista

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Fri, 03 Mar 2006 18:36:20 +0100

Peter,
you can call them root servers, but actually they are servers listed 
in the NTIA root. So they are TLD servers used as by the ISP as root 
servers. This only seem to mean that the concept of root is not used. 
This is a TLD forest. Experimentation we carried with dot-root made 
us to understand that this can be very complex but to work well. This 
is why we called this TLD forest description the "authoritative root 
matrix". But this may be only a concept that many people 
automatically build and mutually cross-check. The important 
information are not the actual IP addresses, but the way to obtain them.

This is what the Chinese say. Users do not navigate anymore under the 
ICANN root. But they do not create a root. They just do not use a 
root anymore. This closes the dispute between authoritative and 
alternative roots.
jfc

---

From: Joe Baptista <[email-masked]>
Date: Fri, 03 Mar 2006 20:02:01 -0500

>be addressed in ICANN / WSIS / IGF / whatever but not in the IETF.
Good Lord - your spewing the crapola far and wide today.  Like I told 
you in the governance conference.  Protocols are not political.  Least 
you forget what I told you in the governance - here is my message to you 
----- enjoy it - again.

Stephane Bortzmeyer wrote:

> There are two different sorts of political problems on the
> Internet. Those where a central governance is *mandatory* or things
> simply stop to work. DNS root management and IP address allocation are
>  
>
Where do you come up with this trash.  You either do not understand the 
issues or your playing games.  Technical protocols are not political.  
Technical protocols can not be mandated or their administration made 
mandatory.  I can see it now - protocol police everywhere.

You can't mandate this - and you can't politicize it.  This whole issue 
is about names and numbers.  And how do we manage names and numbers? 
Answer - we use a database.

The only thing you require is a few simple rules to avoid conflicts - 
and those rules have been written - I give you RFC 1591.  All one needs 
to do is translate this from domains to TLDs.  Enjoy the light reading.

Network Working Group                                          J. Postel
Request for Comments: 1591                                           ISI
Category: Informational                                       March 1994

             Domain Name System Structure and Delegation

Status of this Memo

  This memo provides information for the Internet community.  This memo
  does not specify an Internet standard of any kind.  Distribution of
  this memo is unlimited.

1. Introduction

  This memo provides some information on the structure of the names in
  the Domain Name System (DNS), specifically the top-level domain
  names; and on the administration of domains.  The Internet Assigned
  Numbers Authority (IANA) is the overall authority for the IP
  Addresses, the Domain Names, and many other parameters, used in the
  Internet.  The day-to-day responsibility for the assignment of IP
  Addresses, Autonomous System Numbers, and most top and second level
  Domain Names are handled by the Internet Registry (IR) and regional
  registries.

2.  The Top Level Structure of the Domain Names

  In the Domain Name System (DNS) naming of computers there is a
  hierarchy of names.  The root of system is unnamed.  There are a set
  of what are called "top-level domain names" (TLDs).  These are the
  generic TLDs (EDU, COM, NET, ORG, GOV, MIL, and INT), and the two
  letter country codes from ISO-3166.  It is extremely unlikely that
  any other TLDs will be created.

  Under each TLD may be created a hierarchy of names.  Generally, under
  the generic TLDs the structure is very flat.  That is, many
  organizations are registered directly under the TLD, and any further
  structure is up to the individual organizations.

  In the country TLDs, there is a wide variation in the structure, in
  some countries the structure is very flat, in others there is
  substantial structural organization.  In some country domains the
  second levels are generic categories (such as, AC, CO, GO, and RE),
  in others they are based on political geography, and in still others,
  organization names are listed directly under the country code.  The
  organization for the US country domain is described in RFC 1480 [1].

Postel                                                          [Page 1]

RFC 1591      Domain Name System Structure and Delegation     March 1994

  Each of the generic TLDs was created for a general category of
  organizations.  The country code domains (for example, FR, NL, KR,
  US) are each organized by an administrator for that country.  These
  administrators may further delegate the management of portions of the
  naming tree.  These administrators are performing a public service on
  behalf of the Internet community.  Descriptions of the generic
  domains and the US country domain follow.

  Of these generic domains, five are international in nature, and two
  are restricted to use by entities in the United States.

  World Wide Generic Domains:

  COM - This domain is intended for commercial entities, that is
        companies.  This domain has grown very large and there is
        concern about the administrative load and system performance if
        the current growth pattern is continued.  Consideration is
        being taken to subdivide the COM domain and only allow future
        commercial registrations in the subdomains.

  EDU - This domain was originally intended for all educational
        institutions.  Many Universities, colleges, schools,
        educational service organizations, and educational consortia
        have registered here.  More recently a decision has been taken
        to limit further registrations to 4 year colleges and
        universities.  Schools and 2-year colleges will be registered
        in the country domains (see US Domain, especially K12 and CC,
        below).

  NET - This domain is intended to hold only the computers of network
        providers, that is the NIC and NOC computers, the
        administrative computers, and the network node computers.  The
        customers of the network provider would have domain names of
        their own (not in the NET TLD).

  ORG - This domain is intended as the miscellaneous TLD for
        organizations that didn't fit anywhere else.  Some non-
        government organizations may fit here.

  INT - This domain is for organizations established by international
        treaties, or international databases.

  United States Only Generic Domains:

  GOV - This domain was originally intended for any kind of government
        office or agency.  More recently a decision was taken to
        register only agencies of the US Federal government in this
        domain.  State and local agencies are registered in the country

Postel                                                          [Page 2]

RFC 1591      Domain Name System Structure and Delegation     March 1994

        domains (see US Domain, below).

  MIL - This domain is used by the US military.

  Example country code Domain:

  US - As an example of a country domain, the US domain provides for
       the registration of all kinds of entities in the United States
       on the basis of political geography, that is, a hierarchy of
       <entity-name>.<locality>.<state-code>.US.  For example,
       "IBM.Armonk.NY.US".  In addition, branches of the US domain are
       provided within each state for schools (K12), community colleges
       (CC), technical schools (TEC), state government agencies
       (STATE), councils of governments (COG),libraries (LIB), museums
       (MUS), and several other generic types of entities (see RFC 1480
       for details [1]).

  To find a contact for a TLD use the "whois" program to access the
  database on the host rs.internic.net.  Append "-dom" to the name of
  TLD you are interested in.  For example:

                      whois -h rs.internic.net us-dom
     or
                      whois -h rs.internic.net edu-dom

3.  The Administration of Delegated Domains

  The Internet Assigned Numbers Authority (IANA) is responsible for the
  overall coordination and management of the Domain Name System (DNS),
  and especially the delegation of portions of the name space called
  top-level domains.  Most of these top-level domains are two-letter
  country codes taken from the ISO standard 3166.

  A central Internet Registry (IR) has been selected and designated to
  handled the bulk of the day-to-day administration of the Domain Name
  System.  Applications for new top-level domains (for example, country
  code domains) are handled by the IR with consultation with the IANA.
  The central IR is INTERNIC.NET.  Second level domains in COM, EDU,
  ORG, NET, and GOV are registered by the Internet Registry at the
  InterNIC.  The second level domains in the MIL are registered by the
  DDN registry at NIC.DDN.MIL.  Second level names in INT are
  registered by the PVM at ISI.EDU.

  While all requests for new top-level domains must be sent to the
  Internic (at [email-masked]), the regional registries are
  often enlisted to assist in the administration of the DNS, especially
  in solving problems with a country administration.  Currently, the
  RIPE NCC is the regional registry for Europe and the APNIC is the

Postel                                                          [Page 3]

RFC 1591      Domain Name System Structure and Delegation     March 1994

  regional registry for the Asia-Pacific region, while the INTERNIC
  administers the North America region, and all the as yet undelegated
  regions.

     The contact mailboxes for these regional registries are:

        INTERNIC        [email-masked]
        APNIC           [email-masked]
        RIPE NCC        [email-masked]

  The policy concerns involved when a new top-level domain is
  established are described in the following.  Also mentioned are
  concerns raised when it is necessary to change the delegation of an
  established domain from one party to another.

  A new top-level domain is usually created and its management
  delegated to a "designated manager" all at once.

  Most of these same concerns are relevant when a sub-domain is
  delegated and in general the principles described here apply
  recursively to all delegations of the Internet DNS name space.

  The major concern in selecting a designated manager for a domain is
  that it be able to carry out the necessary responsibilities, and have
  the ability to do a equitable, just, honest, and competent job.

  1) The key requirement is that for each domain there be a designated
     manager for supervising that domain's name space.  In the case of
     top-level domains that are country codes this means that there is
     a manager that supervises the domain names and operates the domain
     name system in that country.

     The manager must, of course, be on the Internet.  There must be
     Internet Protocol (IP) connectivity to the nameservers and email
     connectivity to the management and staff of the manager.

     There must be an administrative contact and a technical contact
     for each domain.  For top-level domains that are country codes at
     least the administrative contact must reside in the country
     involved.

  2) These designated authorities are trustees for the delegated
     domain, and have a duty to serve the community.

     The designated manager is the trustee of the top-level domain for
     both the nation, in the case of a country code, and the global
     Internet community.

Postel                                                          [Page 4]

RFC 1591      Domain Name System Structure and Delegation     March 1994

     Concerns about "rights" and "ownership" of domains are
     inappropriate.  It is appropriate to be concerned about
     "responsibilities" and "service" to the community.

  3) The designated manager must be equitable to all groups in the
     domain that request domain names.

     This means that the same rules are applied to all requests, all
     requests must be processed in a non-discriminatory fashion, and
     academic and commercial (and other) users are treated on an equal
     basis.  No bias shall be shown regarding requests that may come
     from customers of some other business related to the manager --
     e.g., no preferential service for customers of a particular data
     network provider.  There can be no requirement that a particular
     mail system (or other application), protocol, or product be used.

     There are no requirements on subdomains of top-level domains
     beyond the requirements on higher-level domains themselves.  That
     is, the requirements in this memo are applied recursively.  In
     particular, all subdomains shall be allowed to operate their own
     domain name servers, providing in them whatever information the
     subdomain manager sees fit (as long as it is true and correct).

  4) Significantly interested parties in the domain should agree that
     the designated manager is the appropriate party.

     The IANA tries to have any contending parties reach agreement
     among themselves, and generally takes no action to change things
     unless all the contending parties agree; only in cases where the
     designated manager has substantially mis-behaved would the IANA
     step in.

     However, it is also appropriate for interested parties to have
     some voice in selecting the designated manager.

     There are two cases where the IANA and the central IR may
     establish a new top-level domain and delegate only a portion of
     it: (1) there are contending parties that cannot agree, or (2) the
     applying party may not be able to represent or serve the whole
     country.  The later case sometimes arises when a party outside a
     country is trying to be helpful in getting networking started in a
     country -- this is sometimes called a "proxy" DNS service.

     The Internet DNS Names Review Board (IDNB), a committee
     established by the IANA, will act as a review panel for cases in
     which the parties can not reach agreement among themselves.  The
     IDNB's decisions will be binding.

Postel                                                          [Page 5]

RFC 1591      Domain Name System Structure and Delegation     March 1994

  5) The designated manager must do a satisfactory job of operating the
     DNS service for the domain.

     That is, the actual management of the assigning of domain names,
     delegating subdomains and operating nameservers must be done with
     technical competence.  This includes keeping the central IR (in
     the case of top-level domains) or other higher-level domain
     manager advised of the status of the domain, responding to
     requests in a timely manner, and operating the database with
     accuracy, robustness, and resilience.

     There must be a primary and a secondary nameserver that have IP
     connectivity to the Internet and can be easily checked for
     operational status and database accuracy by the IR and the IANA.

     In cases when there are persistent problems with the proper
     operation of a domain, the delegation may be revoked, and possibly
     delegated to another designated manager.

  6) For any transfer of the designated manager trusteeship from one
     organization to another, the higher-level domain manager (the IANA
     in the case of top-level domains) must receive communications from
     both the old organization and the new organization that assure the
     IANA that the transfer in mutually agreed, and that the new
     organization understands its responsibilities.

     It is also very helpful for the IANA to receive communications
     from other parties that may be concerned or affected by the
     transfer.

4. Rights to Names

  1) Names and Trademarks

     In case of a dispute between domain name registrants as to the
     rights to a particular name, the registration authority shall have
     no role or responsibility other than to provide the contact
     information to both parties.

     The registration of a domain name does not have any Trademark
     status.  It is up to the requestor to be sure he is not violating
     anyone else's Trademark.

  2) Country Codes

     The IANA is not in the business of deciding what is and what is
     not a country.

Postel                                                          [Page 6]

RFC 1591      Domain Name System Structure and Delegation     March 1994

     The selection of the ISO 3166 list as a basis for country code
     top-level domain names was made with the knowledge that ISO has a
     procedure for determining which entities should be and should not
     be on that list.

5. Security Considerations

  Security issues are not discussed in this memo.

6. Acknowledgements

  Many people have made comments on draft version of these descriptions
  and procedures.  Steve Goldstein and John Klensin have been
  particularly helpful.

7. Author's Address

  Jon Postel
  USC/Information Sciences Institute
  4676 Admiralty Way
  Marina del Rey, CA  90292

  Phone: 310-822-1511
  Fax:   310-823-6714
  EMail: [email-masked]

7. References

  [1] Cooper, A., and J. Postel, "The US Domain", RFC 1480,
      USC/Information Sciences Institute, June 1993.

  [2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
      USC/Information Sciences Institute, July 1992.

  [3] Mockapetris, P., "Domain Names - Concepts and Facilities", STD
      13, RFC 1034, USC/Information Sciences Institute, November 1987.

  [4] Mockapetris, P., "Domain Names - Implementation and
      Specification", STD 13, RFC 1035, USC/Information Sciences
      Institute, November 1987.

  [6] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
      974, CSNET CIC BBN, January 1986.

  [7] Braden, R., Editor, "Requirements for Internet Hosts --
      Application and Support", STD 3, RFC 1123, Internet Engineering
      Task Force, October 1989.

Postel                                                          [Page 7]

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Sun, 5 Mar 2006 09:15:24 +0100

On 3 mar 2006, at 17.58, Peter Dambier wrote:

>> To best of my knowledge, that there are no new Chinese root- 
>> servers -  despite what the press says. And at least we have not  
>> seen a drop in  queries to our anycast instance in Beijing yet so  
>> there even seems to  be data to support that...
>> But what do I know...
>> - kurtis -
>
> Hi Curtis,
>

Which does not show that there is a new root-server in China...it  
merly shows that you have found a server inside china that happens to  
have a IDN TLD configured. This would be analogue to the testbed that  
NIC-SE (Swedish registry) was running for DNSSEC until they put this  
into their production system.

- kurtis -

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Sun, 5 Mar 2006 09:25:14 +0100

> There are. Check Peter Dambiers messages for details.

Exactly what does he prove there? Please explain....

> Second - you will notice an increase in what you guys at the roots  
> call I think illegal or erroneous TLDs - which see
>

I see no increase in these, but we do see a lot of them in general...

>
> Incidentally - since my article was written I have not seen any  
> further studies concerning root traffic from CAIDA or anyone else.   
> In fact root operators don't really share much with the world - do  
> they?

Of query data? No and this a complex issue, at least for us that  
involves local laws regarding privacy and personal integrity. As for  
qps data, sharing that in real-time is at least by us considered a  
security issue. That said, we will as of the end of this quarter  
start publishing a quarterly newsletter that among other things will  
include some data over the past quarter.

- kurtis -

---

From: Peter Dambier <[email-masked]>
Date: Sun, 05 Mar 2006 11:11:14 +0100

Kurt Erik Lindqvist wrote:
>>> To best of my knowledge, that there are no new Chinese root- servers 
>>> -  despite what the press says. And at least we have not  seen a drop 
>>> in  queries to our anycast instance in Beijing yet so  there even 
>>> seems to  be data to support that...
>>
>>
>>

Take this one

; <<>> DiG 9.1.3 <<>> -t any xn--8pru44h.xn--55qx5d @ns5.ce.net.cn.
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11465
;; flags: qr aa rd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;xn--8pru44h.xn--55qx5d.                IN      ANY

;; ANSWER SECTION:
xn--8pru44h.xn--55qx5d. 1800    IN      SOA     ns5.ce.net.cn. tech.ce.net.cn. 2004072009 3600 900 1209600 1800
xn--8pru44h.xn--55qx5d. 1800    IN      A       210.51.169.151
xn--8pru44h.xn--55qx5d. 1800    IN      MX      10 mail.xn--8pRu44H.xn--55Qx5D.
xn--8pru44h.xn--55qx5d. 1800    IN      NS      ns5.ce.net.cn.

;; ADDITIONAL SECTION:
mail.xn--8pRu44H.xn--55Qx5D. 1800 IN    A       210.51.171.29

;; Query time: 460 msec
;; SERVER: 210.51.171.200#53(ns5.ce.net.cn.)
;; WHEN: Sun Mar  5 10:52:41 2006
;; MSG SIZE  rcvd: 205

They obviously have got email and they use it.
And they have got a homepage too.

http://xn--8pru44h.xn--55qx5d/

Every shoemaker in the Netherlands can see them and order
their soles from them. Look at your soles (the inside :)

Maybe the root has changed and you are on the wrong server.

Chinese students do use these domains to communicate home.

Tiscali have updated their nameservers to be able to cope
with those emails.

Maybe anycast has played a trick on you and you cannot see
the right nameservers :)

>> In fact root operators don't really share much with the world - do  they?
> 
> 
> 
> security issue. That said, we will as of the end of this quarter  start 
> publishing a quarterly newsletter that among other things will  include 
> some data over the past quarter.
> 
> - kurtis -
>

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Sun, 5 Mar 2006 15:40:26 +0100

On 5 mar 2006, at 11.11, Peter Dambier wrote:

>>>> servers -  despite what the press says. And at least we have  
>>>> not  seen a drop in  queries to our anycast instance in Beijing  
>>>> yet so  there even seems to  be data to support that...
>>>
>>>
>>>
[...]

So by analogy this

; <<>> DiG 9.2.2 <<>> @mariehamn.kurtis.pp.se kurtis.fi any
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32651
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 6

;; QUESTION SECTION:
;kurtis.fi.                     IN      ANY

;; ANSWER SECTION:
kurtis.fi.              86400   IN      SOA      
mariehamn.kurtis.pp.se. hostmaster.kurtis.pp.se. 2006030201 28800  
7200 604800 86400
kurtis.fi.              86400   IN      NS      vovve.besserwisser.org.
kurtis.fi.              86400   IN      NS      casper.besserwisser.org.
kurtis.fi.              86400   IN      NS      tankgirl.kurtis.pp.se.
kurtis.fi.              86400   IN      NS      mariehamn.kurtis.pp.se.
kurtis.fi.              86400   IN      MX      50  
mariehamn.kurtis.pp.se.
kurtis.fi.              86400   IN      MX      100  
casper.besserwisser.org.
kurtis.fi.              86400   IN      MX      10 lemland.kurtis.pp.se.

proves there is an alternative .fi registry then? Sigh..

> Maybe the root has changed and you are on the wrong server.

What is the right and what is the wrong server?

> Tiscali have updated their nameservers to be able to cope

Good for them!

> Maybe anycast has played a trick on you and you cannot see

Oh please...anycast have nothing to do with content.

I think that you are pretty mixed up with what a root-server is and  
what an authoritative server is. But again, that is just me. I will  
now go back into lurk mode on this list...

- kurtis -

---

From: John C Klensin <[email-masked]>
Date: Sun, 05 Mar 2006 11:35:41 -0500

In the hope of closing a loop, I trust that everyone who has
tried to turn this into a big deal and a huge international
crisis, or has otherwise gotten worked up about it, has seen the
statement in Friday's _People's Daily_.  For those who have not,
I recommend a quick reading of 
http://english.people.com.cn/200603/03/eng20060303_247684.html

It is mercifully short (only four paragraphs) and extremely
clear: the previous report was wrong, '...the content of the
report is severely inconsistent with the facts', 'The only
difference is to add a second level domain ".MIL.CN" in .CN
ccTLD', etc.

There are no "independent root-servers" in China, or at least
none that anyone official is willing to claim.

Next?

     john

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Mon, 06 Mar 2006 00:59:59 +0100

Dear John,
thank you to make the point.

>none that anyone official is willing to claim.

This IS the point. There is no independent root-servers. The other 
point is: there is no change for two years. And yet there are tens of 
thousands of registrants and millions of users. This means there is a 
new - non IETF documented - way to manage the namespace. And 
therefore a new form of Governance.

>Next?

If China can do it for several years, without anyone even noticing or 
feeling or wanting being concerned, it means there is no problem 
organising externets. Good. This means that others can (and will) 
copy them. Your "next?" is their IETF blessing. The ICP-3 test bed is 
completed. The ICP-3 criteria are met. What Chinese did is no 
problem. The "problem" is with the next one: or is that what you mean?.

jfc

---

From: Mark Andrews <[email-masked]>
Date: Mon, 06 Mar 2006 13:15:52 +1100

> therefore a new form of Governance.

	No there isn't.  It there was they would be visible to all
	machines that believe they have Internet access without
	having to manually wire them in.

> problem. The "problem" is with the next one: or is that what you mean?.

	Lots of people graft all sorts of names onto the DNS for
	their internal namespaces often at the top level.  This is
	of itself no problem so long as the top level namespace is
	stable.  The moment the top level namespace becomes unstable
	you run the risk of name space clashes.  You force people
	to rename their internal machines.

	And before you say they should get there own domain paid
	for domain name.  Do you really expect every home user with
	a home network that doesn't need to be addressable by name
	from the internet to pony up the fees just to prevent a
	name clash.
	
	Try picking a semi-meaningful unused name under COM for
	your internal namespace and see how long it is before you
	are forced to rename:-)

	Dot should be kept small.  It should be small enough to be
	transfered to embedded boxes along with IP6.ARPA, IN-ADDR.ARPA
	and ARPA with all of these zones signed.

	If this was being done by all iterative resolvers when Sri
	Lanka went off the air internal communications within Sri
	Lanka would have had a much better chance of just continuing
	to work for the time it took to fix the cables.  It wouldn't
	have been perfect but it would have helped.
	
	Mark

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 06 Mar 2006 08:46:06 +0100

Hi all,

I will like to ask all to keep the spirit and wording of this thread (an of
course in general the IETF mail exploder) within an adequate tone and
respect towards the rest.

All the opinions should be respected also, but they should come with an
adequate "envelope" instead of abusive wording, that definitively will be
read as an insult by others and could generate and endless discussion.

So please, refrain of making any new "excess" in this list.

Thanks for your understanding !

IETF Sergeant at arms

> De: Joe Baptista <[email-masked]>
> Organización: Planet Communications & Computing Facility
> Responder a: <[email-masked]>
> Fecha: Fri, 03 Mar 2006 20:02:01 -0500
> Para: Stephane Bortzmeyer <[email-masked]>
> CC: IETF <[email-masked]>
> Asunto: Re: Beyond China's independent root-servers -- Expanding and Fixing
> Domain Notation
> 

**********************************************
The IPv6 Portal: http://www.ipv6tf.org

Barcelona 2005 Global IPv6 Summit
Slides available at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 06 Mar 2006 09:21:44 +0100

All,

One more request on this.

In general if we just avoid replying to anyone who abuses the list, I guess
will make easier for all to silently discard those postings instead of
giving them extra lifetime.

Thanks for your understanding.

IETF Sergeant at arms

> De: JORDI PALET MARTINEZ <[email-masked]>
> Responder a: <[email-masked]>
> Fecha: Mon, 06 Mar 2006 08:46:06 +0100
> Para: "[email-masked]" <[email-masked]>
> Conversación: Beyond China's independent root-servers -- Expanding and Fixing
> Domain Notation
> This electronic message contains information which may be privileged or
> confidential. The information is intended to be for the use of the
> individual(s) named above. If you are not the intended recipient be aware that
> any disclosure, copying, distribution or use of the contents of this
> information, including attached files, is prohibited.
> 
> 
> 
> 
> This electronic message contains information which may be privileged or
> confidential. The information is intended to be for the use of the
> individual(s) named above. If you are not the intended recipient be aware that
> any disclosure, copying, distribution or use of the contents of this
> information, including attached files, is prohibited.
> 
>