Subject: AW: IETF58 - Network Facts

From: "Hans Peter Dittler" <[email-masked]>
Date: Tue, 25 Nov 2003 08:52:58 +0100

Hi,

I had no problems during the whole week. My IPSEC-connection through
wireless only dropped one or two times for seconds. Even in my room (12th
floor) conections were possible with sufficent radio coverage. For me this
was an excellent wireless usage pattern, one among the best during the last
15 meetings attended.....
This was done using an old CISCO-card with actual drivers under XP.

So many thanks again to all who made this possible, it is a tremendous lot
of work, I run the network 97 in Munich and know about the problems.....

H.P. Dittler

---

From: jfcm <[email-masked]>
Date: Thu, 27 Nov 2003 23:20:00 +0100

While parallel issues start being discussed and better understood at WSIS, 
we have next week a meeting on Internet national security, sovereignty and 
innovation capacity.

The interest is not sites nor network protection layers, but nations 
protection from what happens on or with the networks. This is in line with 
the White House document http://whitehouse.gov/pcipb with the addition of 
the risks created by the US (and every other national) cyber security 
effort, and from not mastering the root. In most of the cases the 
identified risks root come from a centralized which has to be made distributed.

The target is to analyze if there is an urgent duty of precaution,  in 
considering various scenarios  and the way a nation may address them. They 
range from open conflict with "nsicanntiab" to catastrophic weather 
situation on the East Coast and black out due to Internet, terrorist attack 
on the USA, dramatic increase of the spam, war, etc.

Next step will be to identify and to work on a catalog of actions and 
project to reduce the risks and to protect the users and critical usages of 
the network in periods of emergency. Some propositions have no technical or 
remote technical impact. They are mostly the ones aiming at preventing 
human rooted risks in organizing a stable concerted (European meaning) 
governance.They range from a web information and services providers and a 
user network support organizations, the creation of an ITU-I to welcome the 
higher layers issues for the information society, a universal name system 
(uninames) and its generalization across network technologies [this would 
impact on the vernacularisation of e-mail names, IDNA, cultural areas in 
UDRP, etc.), a co-management of the international parts of the IANA and 
root file by the ccTLDs, etc.

Some others have technical implications. I would like to quote some 
suggestions listed in the  preparatory document, to get advices I could 
quote at the meeting or in its report. Also to list the alternative and 
additional suggestions some might do.

1. a ".dir" emergency virtual TLD. (Directory of direct accesses). This 
would be a per country Host.txt file documenting critical sites and 
services. For example "cnn.dir" would route to the IP address of CNN. This 
file could be easily retrieved at a known IP. Quoting main commercial sites 
(while permitting its immediate use) would finance its organization.

2. a menu server system permitting to access sites though their IP address 
only. This would be a good promotion for IPv6 due to the easiness to 
support IP virtual hosts addresses. As a security oriented alternative to 
the NSI network unstabilization.

3. national mirrors of http://ns.internic.net . ISPs and corporations would 
be advised to load the root from these mirrors. In case of collapse of the 
US Internet, local authorities could patch an updated root in hours, 
keeping with the current situation. TTL histeresys is probably to be 
carefully considered.

4. national IANA files, from TLD Managers direct information collection. 
With a constant mutual consistency check among national copies and ICANN 
(to avoid the KP&Quest situation).

5. the possibility of a redundant DNS system. Today the Internet has two 
root files (the same file but presented on two main systems - DNS and FTP). 
If one is hacked there is not reference. A redundant system would consist 
in two or more root masters refereeing to different sets of TLD name 
servers (all of them carrying the same files, but possibly of different 
origins for security reasons).

6. an evolution towards an international root matrix supporting proximity 
root servers and proximity TLDs for abbreviated addressing through local 
TLDs. The organization and the procedure of the common authoritative root 
matrix should be internationally approved and subject to the ICP-3 proposed 
testing rules. A quoted example documents the target as "hart.sos" of 
pacemakers always resolving to the nearest hospital (as decided by local 
authorities). Local root servers would support teleurbanism and domotic 
usage. They could be installed at mobile and wi-fi stations.

7. the development of a GPL resolver for every operating systems. It will 
support both a private root and private TLDs. Private TLDs would be 
consistent with the RFC 920 and current consensus on schemes. gTLD use 3 
letters and above. ccTLD are national and use 2 letters. Private TLD would 
local and use 1 letter. This would be consistent with the schemes. One 
letter schemes describe the private local disk space. One letter TLDs 
describe, at the other end of the URL, the private net space. This will 
permit everyone to use a family, a local or a community part of the 
Host.txt existing solution. Example ".h" could be commonly used for home, 
".s" for school, ".c" for church and charity help, ".b" for business, ".d" 
for defense and protection, ".w" for local web and welfare.

8. an IPv6.010 second numbering plan conforming with RFC 2373. This plan 
will be nationally  organized by network types. It would concatenate:
-  national ID and network technology ID (internet, telephone, radio, TV, 
teletex, etc. ) permitting an immediate access to all the available means 
of communicating of the future NGN.
- a national part numerating the network operators and gateways. This would 
provide stable routing support as each country might adapt it to geography, 
administrative security organizations etc.
- a national host numbering scheme. With an immediate identification of any 
host on any network whatever the location change or connection organized.
This second would also protect IPv6 technology and equipment from a K2 like 
syndrome when a new plan could be discussed, as it would have permitted to 
validate the multiple plan possibility.

Thank you for your comments.
jfc

---

From: jfcm <[email-masked]>
Date: Fri, 28 Nov 2003 00:37:10 +0100

Sorry for the typo - I miss my glasses :-) - http://rs.internic.net (not 
ns.internic.net as I typed).
jfc

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 28 Nov 2003 11:50:42 +0100

On 27-nov-03, at 23:20, jfcm wrote:

> suggestions listed in the  preparatory document, to get advices I 
> could quote at the meeting or in its report. Also to list the 
> alternative and additional suggestions some might do.

Ok, I'm not going to quote all the details...

This looks like a big old bag of DNS tricks. Obviously the virtue of 
each can be discussed individually, but wouldn't it make more sense to 
start thinking about a more structured approach to arrive at the 
intended benefits?

For instance, one issue seems to be the ability to continue to reach 
systems using domain names when there is a problem with the DNS 
infrastructure. This could be addressed by modifying the caching 
mechanisms in DNS resolvers. The way things are done now is throw away 
the old shoes (cached information) and then see if new ones can be 
found. Rather bizarre if you think about it.

> 2. a menu server system permitting to access sites though their IP 
> address only. This would be a good promotion for IPv6 due to the 
> easiness to support IP virtual hosts addresses. As a security oriented 
> alternative to the NSI network unstabilization.

This could lead to pressure to make IP addresses more portable, which 
isn't a good thing.

> 6. an evolution towards an international root matrix supporting 
> proximity root servers and proximity TLDs for abbreviated addressing 
> through local TLDs. The organization and the procedure of the common 
> authoritative root matrix should be internationally approved and 
> subject to the ICP-3 proposed testing rules. A quoted example 
> documents the target as "hart.sos" of pacemakers always resolving to 
> the nearest hospital (as decided by local authorities).

This isn't something you can do with simple (or even not so simple) 
n-faced DNS. For instance, here in the Netherlands many service 
providers backhaul all their traffic to Amsterdam over the phone 
infrastructure (dial-up) or ATM (DSL). Those customers then share IP 
address space and DNS resolvers. Getting the location info back in 
there would be almost impossible.

However, it could be useful to create mechanisms that make it easier 
for hosts to discover location information. For instance, through a 
DHCP option. This information can then be used when searching 
directories or search engines. (This would have interesting commercial 
possibilities as well.)

> - a national host numbering scheme. With an immediate identification 
> of any host on any network whatever the location change or connection 
> organized.
> This second would also protect IPv6 technology and equipment from a K2 
> like syndrome when a new plan could be discussed, as it would have 
> permitted to validate the multiple plan possibility.

In the multi6 (multihoming in IPv6) working group, as one of many 
proposals, we've been looking at putting a 64 bit host identifier in 
the bottom 64 bits of an IPv6 address. If such a host identifier is 
crypto-based (ie, a hash of a public key) then it is possible to 
authenticate a host at any time regardless of where the host connects 
to the network at that particular time and without the need for a PKI 
or prior communication.

(I have no idea what "K2 syndrome" means by the way, and it looks like 
Google doesn't either.)

---

From: "Anthony G. Atkielski" <[email-masked]>
Date: Fri, 28 Nov 2003 13:04:19 +0100

> to the network at that particular time and without the need for a PKI 

This is precisely the kind of mistake that will exhaust the entire IPv6
address space just as quickly as the IPv4 address space.  Don't
engineers ever learn from the past?

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 28 Nov 2003 13:53:22 +0100

> engineers ever learn from the past?

I guess not because I have no idea what you're talking about.

---

From: Jari Arkko <[email-masked]>
Date: Fri, 28 Nov 2003 15:28:47 +0200

Anthony,

> engineers ever learn from the past?

I can't claim to know too much about the specific details in the
multi6 proposal, but there has been other efforts that use cryptographic
identifiers as parts of addresses. However, I do not believe these
proposals consume any more address space than, say, manual or EUI-64
based address assignment. There's still just one address consumed per
node. Perhaps you were thinking that the address contains a MAC field?
This isn't strictly speaking the case, at least not in the way that
the MAC value would change from one packet to another.

Anyway, back to the subject of "national security"... I have a
question. The main goal appears to be the reduction of dependencies
between network parts, in order to prepare for catastrophic situations.
This is useful goal, though I'm not sure I agree with all the listed
specific items. Are any of the issues that have been talked about being
addressed in the IEPREP WG, or is that group mainly focused on the SIP/
telecom type of issues only?

--Jari

---

From: "Anthony G. Atkielski" <[email-masked]>
Date: Fri, 28 Nov 2003 14:47:41 +0100

> I guess not because I have no idea what you're talking about.

There is a natural tendency to think that by dividing a 128-bit address
field into two 64-bit fields, the address space is cut in half (or
perhaps not diminished at all).  However, in reality, dividing the field
in this way may reduce the address space by a factor of as much as
nineteen orders of magnitude.  Again and again, engineers make this
mistake, and render large parts of an address space unusable through
careless, bit-wise allocation of addresses in advance.

For example, if you assign addresses sequentially, you can address up to
2^128 hosts with a 128-bit address.  If you divide the address field
into two 64-bit fields--one for the country and one for those within the
country, say--intuitively you might think that you've only slightly
reduced the total number of available addresses.  In fact, however,
you've dramatically diminished the size of the address space.  Unless
you have exactly 2^64 countries in the world, each of which contains
exactly 2^64 hosts, very large segments of the address space will be
wasted.  The effective address space may be many trillions of times
smaller than you expect.  And you may find yourself exhausting that
address space far more quickly than you ever thought possible.

When you divided an address field into bit-wise fields, you encode
information into the address.  This introduces redundancy, which reduces
the usable address space.  If you allocate a country code to one country
in the example above, for instance, and that country has only 1000
computers, you've just wasted roughly 18,446,744,073,700,000,000 machine
addresses.   Do this for multiple countries, and you could easily waste
almost all your address space simply due to this extremely foolish
division of the address field.  It's unlikely you'll have 2^64 countries
to accommodate; and it's equally unlikely that each of these countries
will have exactly 2^64 hosts (no more, no less) to address, so you are
wasting many bits of the address field.  And the wasted space increases
exponentially with the number of wasted bits.  Wasting ten bits instead
of five bits doesn't waste twice the space, it wastes _32 times_ the
space.

I've often felt that the most common mistake made by engineers in
designing systems, especially computer systems, is underestimation of
capacity, and wastage of existing capacity.  Dividing address fields
into preallocated zones is the most common example of this.  They just
never learn, and they cannot be told.  They are always convinced that
there's more space than anyone will ever need in their address field,
and by the time they find out otherwise, it's too late.  It happened
with IPv4, 16-bit addresses, and 32-bit addresses; it will soon happen
with 64-bit addresses and with IPv6.  I don't understand how engineers
can be so stupid in this one specific domain.

---

From: "Anthony G. Atkielski" <[email-masked]>
Date: Fri, 28 Nov 2003 14:52:11 +0100

Jari Arkko writes:

> However, I do not believe these proposals consume any
> more address space than, say, manual or EUI-64
> based address assignment.

In order to use the full potential address space, you must devise a
scheme that allocates every single combination of bits.  The simplest
scheme of this kind is sequential allocation of addresses.

> There's still just one address consumed per
> node.

It's not the number consumed; it's the number excluded from availability
by the encoding of information into the address field.  You might easily
waste 99% of the address space in this way.

> Perhaps you were thinking that the address contains a MAC field?

No.  I'm thinking that the address field is being divided into zones,
thus wasting a tremendous amount of space.

A 128-bit field contains 2^128 addresses.  If you divide that into two
64-bit fields, you may get as few as 2^64*2 addresses; that's 18
million trillion times smaller than the 128-bit field.

---

From: Jaap Akkerhuis <[email-masked]>
Date: Fri, 28 Nov 2003 15:20:56 +0100

Who is "we" in above paragraph?

	jaap

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 28 Nov 2003 08:24:39 -0600

From: "Anthony G. Atkielski" <[email-masked]>
To: "IETF Discussion" <[email-masked]>
Sent: Friday, November 28, 2003 7:52 AM
Subject: Re[2]: national security
> scheme of this kind is sequential allocation of addresses.

Well, sure. And then you do routing aggregation how?

I also deplore the waste of bits, and would love to hear
alternatives...

Spencer

---

From: Donald Eastlake 3rd <[email-masked]>
Date: Fri, 28 Nov 2003 10:28:37 -0500 (EST)

See RFC 1715, November 1994, and the endless discussions that appeared
on a variety of mailing list about IPv6 addresses.

Thanks,
Donald
======================================================================
 Donald E. Eastlake 3rd                       [email-masked]
 155 Beaver Street              +1-508-634-2066(h) +1-508-786-7554(w)
 Milford, MA 01757 USA                   [email-masked]

On Fri, 28 Nov 2003, Anthony G. Atkielski wrote:

> Date: Fri, 28 Nov 2003 14:47:41 +0100
> From: Anthony G. Atkielski <[email-masked]>
> To: IETF Discussion <[email-masked]>
> Subject: Re[4]: national security
>
> ...

---

From: John Kristoff <[email-masked]>
Date: Fri, 28 Nov 2003 10:05:10 -0600

On Fri, 28 Nov 2003 14:47:41 +0100
"Anthony G. Atkielski" <[email-masked]> wrote:

> (or perhaps not diminished at all).  However, in reality, dividing the
> field in this way may reduce the address space by a factor of as much
> as nineteen orders of magnitude.  Again and again, engineers make this

The 48-bit addresses in IEEE/L2 protocols are divided in half as
well as have a couple bits set aside to denote local/global scope and
unicast/multicast addresses.  It seems to have worked out pretty well.

John

---

From: [email-masked]
Date: Fri, 28 Nov 2003 11:28:18 -0500

> million trillion times smaller than the 128-bit field.

Exactly.  And the *reason* why IPv6 has 128 bit addresses is because
the designers realized that such losses happen, and ruled out 64-bit
addresses because of that effect.  I suggest you figure out just how
much bigger 2^65 is than the current 2^32, and factor in the current
burn rate on the unused IPv4 addresses, and from there figure out if
there's really a problem there at all....

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 28 Nov 2003 18:40:53 +0100

> perhaps not diminished at all).

Ah, I see what you mean now. However, the devision is a done deal as 
RFC 3513 mandates that all unicast IPv6 addresses except the ones 
starting with the bits 000 must have a 64-bit interface identifier in 
the lower 64 bits. This has some important advantages, most notably it 
allows stateless autoconfiguration. (However, this could have been done 
with 48 bits too.) But it does have the downside you mention by only 
leaving 64 bits for numbering subnets. The practice of giving all sites 
a /48 further deminishes the available bits. The situation is most 
notable in the case of a home user, who would get a single IPv4 address 
but gets a /48 in IPv6. So we've quadrupled our address space (in bits) 
for a 50% gain... (Obviously the situation is much better when looking 
at a university that has a /16 now and also gets a /48 as well.)

Putting a 64-bit crypto-based host identifier in the bottom 64 bits of 
IPv6 addresses shouldn't get in the way of regular IPv6 addressing 
mechanisms and/or operation. There is even a trick to make sure there 
is no overlap with either MAC addresses/EUI-64s on the one hand and 
most manually configured addresses and RFC 3041 on the other hand by 
only using EUI-64 compatible values with the universal/local bit set to 
globally unique, but with the group bit set.

> It's unlikely you'll have 2^64 countries
> wasting many bits of the address field.

The plan isn't to encode a country in the first 64 bits. However, 
together with someone else I came up with an unrelated proposal a while 
ago that does encode a country in the IPv6 address. (You can find it at 
http://www.muada.com/drafts/ under the name "gapi".) In this proposal 
we use 16 bits to allocate a /32 to regions with 250 - 500 thousand 
inhabitants, so there is no fixed boundary for the country number.

---

From: "Anthony G. Atkielski" <[email-masked]>
Date: Fri, 28 Nov 2003 19:59:51 +0100

> Well, sure. And then you do routing aggregation how?

I was describing the simplest scheme that ensures use of the entire
address space, nothing more.

> I also deplore the waste of bits, and would love to hear

I've described alternatives before, but nobody was interested.

---

From: "Anthony G. Atkielski" <[email-masked]>
Date: Fri, 28 Nov 2003 20:00:36 +0100

> on a variety of mailing list about IPv6 addresses.

I guess the endless discussions didn't help, but that doesn't surprise
me.

---

From: "Anthony G. Atkielski" <[email-masked]>
Date: Fri, 28 Nov 2003 20:06:15 +0100

[email-masked] writes:

> the designers realized that such losses happen ...

Such losses don't just happen.  They are the result of incompetent
engineering.

---

From: "Anthony G. Atkielski" <[email-masked]>
Date: Fri, 28 Nov 2003 20:10:31 +0100

Iljitsch van Beijnum writes:

> a /48 further deminishes the available bits.

Wow ... it's even worse than I thought!  Why bother even going to IPv6?

> So we've quadrupled our address space (in bits) for a 50% gain ...

A 50% gain in what?

Has it occurred to anyone that allocating entire bit ranges in advance
is a bit presumptuous, since nobody really has any idea how addresses
will be used decades from now?

> In this proposal we use 16 bits to allocate a /32 to regions
> with 250 - 500 thousand inhabitants, so there is no fixed boundary
> for the country number.

See above.  It's a mistake, and time will prove this.

---

From: [email-masked]
Date: Fri, 28 Nov 2003 15:16:06 -0500

> at a university that has a /16 now and also gets a /48 as well.)

OK, so a /48 has 50% more bits than a /32.  On the other hand,
I've heard no *major* problems with end users getting their /32 from
their provider, and there's 65,536 more /48s.  Also, remember that many
end users are getting *multiple* IP's from their provider for SOHO use,
and they'll only need one /48.

---

From: "Anthony G. Atkielski" <[email-masked]>
Date: Fri, 28 Nov 2003 22:08:04 +0100

> and they'll only need one /48.

A problem with this reasoning is that it makes a lot of questionable
assumptions about who needs how many addresses ... assumptions that will
have consequences for many decades to come, even though they will almost
certainly be wrong.

Isn't /48 far too much for one end user? Then again, isn't it far too
little? Who really knows either way? What will the requirements be 30
years from now? Why not resist the engineer's temptation to try to make
all these decisions immediately?

I've always been surprised by how few software engineers are willing to
mark anything "reserved for future use."  They feel a compulsion to find
a purpose and allocation for every single bit right now, no matter how
foolish or ill-conceived that might turn out to be twenty years from
now.  It's as if leaving a fudge factor for the unknown were some sort
of admission of weakness.

---

From: jfcm <[email-masked]>
Date: Fri, 28 Nov 2003 19:12:26 +0100

>Who is "we" in above paragraph?

Hi! Jaap,
"we" is a public open follow-up of the "dot-root" study. If you have French 
and want to participate you are welcome. It will be held in Paris on Dec. 
3rd 14:30 PM. I can mail you the perparatory document if you want. It is 
reserved to decision makers in potential subsequent actions.
jfc

---

From: jfcm <[email-masked]>
Date: Fri, 28 Nov 2003 19:24:57 +0100

Dear Anthony,
RFC 2373 permits 6 plans. The best would be to organize them by purpose. 
Not them all to do the same thing. Here we talk about national security not 
about intellectual elegance.

When you are at war, you want your network to continue operating, not to 
depend on a numeration optimisation by your ennemy. If, due to that, you 
must lose some fancy facilities you probably find that acceptable. To 
evaluate what you lose is the purpose of my question, to permit 
governements to decide what they want - not to be imposed by the nsicanntiab.

I am sure that many security officers or generals would feel unatease if 
they known their HQ IPv6 address can be just one unknown bit different from 
the IPv6 address of a ennemy computer. Makes security very complex. What 
they want is an address mask, if possible manual, telling them where they 
are and where the call comes from. This is also the need of commercial 
international sites, who want to indentify the country of origin to speak 
in the proper language. As well as VOiP users.

And please do not tell me that this is a breach on the calling party's 
privacy. The breach is the call by nature.
jfc

At 14:52 28/11/03, Anthony G. Atkielski wrote:
>Content-Transfer-Encoding: 7bit
>
>Jari Arkko writes:
>

---

From: "Anthony G. Atkielski" <[email-masked]>
Date: Fri, 28 Nov 2003 23:20:20 +0100

jfcm writes:

> the IPv6 address of a ennemy computer.

Nah ... security officers and generals--if they are competent--don't put
their HQ computers on an open network in the first place. That only
happens in the movies.

---

From: [email-masked]
Date: Fri, 28 Nov 2003 18:49:08 -0500

> their HQ computers on an open network in the first place. That only

OK.. change "HQ computer" to "www.ANYTHINGBIG.com", and change "enemy" to
"random hacker in another country".  There's boxes that *have* to be visible
to the world because they provide service and connectivity to the outside
world - and you can't even hand-wave "put them in a DMZ" because then you
still need that address mask to tell if the other end of the connection is
coming from outside, another DMZ machine, or an internal machine.

---

From: jfcm <[email-masked]>
Date: Sat, 29 Nov 2003 02:04:06 +0100

>their HQ computers on an open network in the first place. That only 

hmm... competence in this area is to accept that what happens in movies is 
just a small part of the real life.

This being said, I note that this thread is only oriented to prospective 
numbering issues. May I take from that that none of the suggested 
propositions rises any concern ?

In particular, that there is no problem with two parallel roots file if 
they want to be identical? What would happen if one was hacked? (I note 
that this is the current situation of the Internet where two deliveries of 
the same file are proposed).

The same, no one comments on secondary source for the root, meaning that 
the ICANN unicity is  not an intrisic need, provided the different root 
files collectors strive to collect the real data from the TLD Managers (who 
are authoritative, while the root file is not).  Not a problem to anyone?

No one either comment on private TLDs, or the creation of a virtual TLD 
used through Host.txt only. No one objects to the generalization of users 
resolvers, the possible resulting dissemination of the root file to all the 
users and their resulting ability to fight an ICANN redelegation what is a 
major issue at WSIS.

If there are no major objection I will suggest that a "Nations Security 
propositions" dratf be written as Best Practices, based upon the introduced 
suggestions and the one the participants may want to add. This will be 
introduced at the comming WSIS december 5/6th final preparatory meeting and 
will help addressing concerns expressed by several countries.
jfc

---

From: jfcm <[email-masked]>
Date: Sat, 29 Nov 2003 03:26:01 +0100

>coming from outside, another DMZ machine, or an internal machine.

Yes. but more than that. We talk of the internet itself. The US strategy 
may amount to an US DMZ or a chain of DMZ. I do not think there are any 
objection to that. Except that it underlines that we are not in an open 
worldwide network anymore, or at least not at the same layer.

This has a first direct implication which is the impossibility to accept 
anything unique and common to systems which wants to be unique by 
themselves. One has to find other solutions. No master / slave, not peer to 
peer.

One good example is the DNS. TTLD Managers are authoritative (like running 
their own DMZ). Yet ICANN wants to be authoritative (hence the problems it 
faces). Question: is there a way to make authoritative indepedent systems 
to share into an unique common system?

This leads to an anlyze of the authority and shows that the American 
language misses the word (hence the commonly shared images and 
understanding, capacity to discuss it) we found in Europe as "conceration" 
(French/Eurospeak). This means that authority is not delegated (as DNS 
says), nor shared (as in a democracy) but retained by each participant 
(making consensus the only decision process - as at the IETF, ITU, do ). 
One may name this polycracy. Currently the European problem in accepting 10 
new countries is to regress from polycratic decision process to democratic 
votes. This creates sngle point of failures: the group or the unique 
country (on 25) making the majority and rises the difficulty (polycratic 
consensus had solved): the quality of the voter. Some times Luxembourg has 
not the same weight than Germany or France.

This is the same with networks. Most of the propositions I hear here are 
not acceptable on the long range because they are ideas to develop 
something, not to better serve a group. Engineers see a network as 
connected machines. Developpers as communicating applications. Users see 
them as groups of people.

When you think about reducing risks to the people (not only haked machined 
or DoSed network),  you must thnk global (in the Engilsh/French 
meaning:  i.e. all the parts of the concerned whole - not as a 
single/simpliistic whole - as "put the militaries behind a DMZ"). So you 
must look as the point of failure of each element (hardware, software and 
brainware) and then of the  system.

To take your example or mine. The hacker is going to intrude the computer. 
The foreigners are going to intrude the networks. All this is going to make 
the nation (its computers through its networks) unstablized. If you take 
the barycenter of all the single points of failure, you will discover that 
in most of the cases:

- in Peace time it is the Parliament. Because major decisions are taken 
there. Example the anti spam law, right now, in the USA which is a major 
threat on many countries economomy in legalizing bandwith consuming 
mailing. And you use a Police to protect the Parliament.This is not the 
case we consider.

- in time of crisis, it is one single person (too fast to ask for a law). 
And the real decision maker is the person next to him. This is why military 
HQs are potentially everywhere. They are where a decision is required, in 
front of a weakness, at a critical time. Army is the tool to land the 
decision make at the single point of failure to reduce it.

jfc

---

From: John C Klensin <[email-masked]>
Date: Sat, 29 Nov 2003 11:47:57 -0500

Jefsey,

You should also entertain the hypothesis that no one has
commented on those issues/suggestions because they are have been
discussed too many times before and are inconsistent with the
visions that drive the Internet.   Some of them have even been
the subject of fairly careful evaluation and associated
statements, e.g., RFC 2826 on the unique DNS root issue (often
summarized as "which part of 'unique' are you having trouble
understanding?").

I think, as we have discussed in the past, that your vision of
the Internet and its future differs from mine and that of many,
probably most, of the people on this list.  I would characterize
your picture, I hope not too inaccurately, as one in which
connectivity and the flow of information are driven (not unlike
the PSTN) by bilateral agreements between countries.  In that
sort of world, different countries may reasonably establish
different views of the DNS and different address spaces, with
inter-country communications occurring through gateways that,
among other things, can keep those views and address spaces
separate.   

In my world, direct, end-to-end global connectivity,
interoperability, and integrity of DNS and URI references are
very important -- for interpersonal communication, for commerce,
for intellectual development and dissemination, and perhaps even
as a religious principle.  That belief has caused me to spend
most of my time in the last few years on internationalization
issues, not to empower governments, but to permit better
communication among people (and, indeed, to reduce the belief by
governments that they need to "solve" the problem, probably in
some xenophobic way).

With regard to ICANN and its processes, I don't much like the
way a good deal of that has turned out, even while I believe
that things are gradually getting better.  I lament the set of
decisions that led to the US Govt deciding that it needed to be
actively involved and to some of the risks, delays, and socially
undesirable statements that situation has created.  At the same
time, all of the alternatives continue to strike me as much
worse, including moving the technical/administrative issues into
forums in which variations on the theme of "we don't like
reality, so we will vote it to be different, regardless of what
they might do to the Internet or human communications in
general".  So, while ICANN, IMO, continues to need careful
watching -- most importantly to be sure that it does not expand
into "governance" issues that are outside its rational scope-- I
don't see "give it to XXX" or "everyone runs off in his own
direction" as viable alternatives.

On the other hand, one of the nice things about the network as
it is now constituted is that anyone has the option of
opting-out: disconnecting, setting up a private DNS and a
private addressing system, and communicating, if at all, through
a restrictive, address-and-protocol-translating gateway.  We
even know how to run IP over X.25 and X.75, and that option is
available as well.   The question of who will miss anyone who
takes that opt-out option is an interesting one sociologically,
but the Internet has sufficient critical mass at this point, and
is sufficiently important commercially in most of the world,
that "opportunity to shoot yourself in the foot" might figure
into such an analysis.  If you are convinced of the viability of
your ideas, by all means go off and try them: just be sure that
your namespaces and addresses don't leak into the real network.

regards,
     john

--On Saturday, November 29, 2003 02:04 +0100 jfcm
<[email-masked]> wrote:

>> > I am sure that many security officers or generals would
>> > feel unatease if they known their HQ IPv6 address can be
>> > just one unknown bit different from the IPv6 address of a
>> > ennemy computer.
>> 
>> Nah ... security officers and generals--if they are
>> competent--don't put  their HQ computers on an open network
>> in the first place. That only  happens in the movies.
> 
> hmm... competence in this area is to accept that what happens
> in movies is just a small part of the real life.
> 
> 
> This being said, I note that this thread is only oriented to
> prospective numbering issues. May I take from that that none
> of the suggested propositions rises any concern ?
> 
> In particular, that there is no problem with two parallel
> roots file if they want to be identical? What would happen if
> one was hacked? (I note that this is the current situation of
> the Internet where two deliveries of the same file are
> proposed).
> 
> The same, no one comments on secondary source for the root,
> meaning that the ICANN unicity is  not an intrisic need,
> provided the different root files collectors strive to collect
> the real data from the TLD Managers (who are authoritative,
> while the root file is not).  Not a problem to anyone?
> 
> No one either comment on private TLDs, or the creation of a
> virtual TLD used through Host.txt only. No one objects to the
> generalization of users resolvers, the possible resulting
> dissemination of the root file to all the users and their
> resulting ability to fight an ICANN redelegation what is a
> major issue at WSIS.
> 
> If there are no major objection I will suggest that a "Nations
> Security propositions" dratf be written as Best Practices,
> based upon the introduced suggestions and the one the
> participants may want to add. This will be introduced at the
> coming WSIS dDecember5/6th final preparatory meeting and will
> help addressing concerns expressed by several countries.
> jfc

---

From: Paul Robinson <[email-masked]>
Date: Sat, 29 Nov 2003 17:49:41 +0000

John C Klensin wrote:

>undesirable statements that situation has created.  
>

OK, the big issue for those countries that want ICANN to be disbanded 
and for the Internet to be handed over to the ITU is quite simple: ICANN 
is a US-government controlled entity subject to US/Californian law. 
That's great if you're the US government and even semi-reasonable if 
you're an American. Absolutely awful if you're Chinese or Korean. The 
IETF is about as close as we've got as an "authority" on the Internet 
that is not bounded by geographic boundaries, governmental control or 
commercial contract. You can make a reasonable argument that we should 
be running the show here, not ICANN.

The UNITC meeting needed to happen several years ago, but now we're 
there, realistically there is only one option left for a single, 
cohesive Internet to remain whilst taking into account ALL the World's 
population: ICANN needs to become a UN body.

>direction" as viable alternatives.

Neither do I, but ICANN have clearly demonstrated:

1. They don't listen to us, or those parties who have a genuine vested 
interest in the Internet, UNLESS that party is a US Commercial or 
Governmental entity.

2. Their incompetence at politcal levels has actually caused a delay in 
making the Internet available to those countries that need access to 
affordable communications infrastructures the most.

3. Putting Computer Scientists in charge of anything is fundamentally a 
bad idea. In fact, they have shown they are worse at being in charge 
than politicians and lawyers... they will never get another chance after 
this god-awful mess.

In ICANN's support, the alternative - the "ITU idea" - is *horrible*. 
The ITU is not about open communications infrastrucutres - it's about 
*closed* infrastructures with contracts and licensing and costs and the 
other paraphenalia we want to limit the effect of in the context of the 
Internet.

>a restrictive, address-and-protocol-translating gateway.  We

No, no, no, NO. To allow this would to happen would be a genuine shame. 
How popular is Internet2? Why? I rest my case...

-- 
Paul Robinson

---

From: "vinton g. cerf" <[email-masked]>
Date: Sat, 29 Nov 2003 13:54:08 -0500

At 05:49 PM 11/29/2003 +0000, Paul Robinson wrote:
>OK, the big issue for those countries that want ICANN to be disbanded and for the Internet to be handed over to the ITU is quite simple: ICANN is a US-government controlled entity subject to US/Californian law. 

Please read the most recent MOU. The US Department of Commerce has gone to considerable effort to outline the path by which ICANN becomes the party responsible for the updating of the DNS root. The control you assert is quite limited even today.

Any formal body has to have some jurisdiction in which it is constituted. One can argue whether California non-profit law is better or worse than being a UN entity. I believe there are arguments against the latter as much as there may arguments against the former. 

>That's great if you're the US government and even semi-reasonable if you're an American. Absolutely awful if you're Chinese or Korean. 

that's not at all clear. ICANN has tried to promote the adoption of IDN, for example, in a responsible way. John Klensin's efforts, and others, to promote international compatibility to enhance the ability for parties to communicate is commendable. What do you think is awful?

>The IETF is about as close as we've got as an "authority" on the Internet that is not bounded by geographic boundaries, governmental control or commercial contract. You can make a reasonable argument that we should be running the show here, not ICANN.

Not unless you want to take on the full burden of Internet Governance written large. Not even ICANN wishes to do that. In fact, ICANN's role is very limited compared to the full scope of Internet Governance. Issues such as fraud, taxation, intellectual property protection, dispute resolution, illegal actions are governmental matters and not even UN has the appropriate jurisdiction. It will take cooperation among governments and thoughtful domestic legislation to deal with many of these matters. ICANN has high regard for IETF and IAB and for that reason there is an IAB liaison appointed to the Board of Directors. 

>The UNITC meeting needed to happen several years ago, but now we're there, realistically there is only one option left for a single, cohesive Internet to remain whilst taking into account ALL the World's population: ICANN needs to become a UN body.

nonsense - as constituted today, ICANN is a better forum for interested constituencies to debate policy FOR THOSE AREAS THAT ARE IN ICANN'S PURVIEW (not shouting, just emphasis on limited purview of ICANN). 

The problem with the arguments I have heard, including yours, is that you may be thinking of Internet Governance in the large while ICANN's role is small and should stay that way. We need other venues in which to deal with the larger problems and perhaps UN or some of its constituents have a role to play. Probably WIPO and WTO do as well. 

>1. They don't listen to us, or those parties who have a genuine vested interest in the Internet, UNLESS that party is a US Commercial or Governmental entity.

I disagree - please consider the last ICANN meeting in which the Board went some distance to making changes in its policies in response to international constituency inputs.

>2. Their incompetence at politcal levels has actually caused a delay in making the Internet available to those countries that need access to affordable communications infrastructures the most.

Sorry, it is a lot more complex than you seem to think - the question of who should have responsibility for a CCTLD is often very complex - it is sometimes not even clear who the government of country X is.

>3. Putting Computer Scientists in charge of anything is fundamentally a bad idea. In fact, they have shown they are worse at being in charge than politicians and lawyers... they will never get another chance after this god-awful mess.

The Board is not made up of computer scientists alone; nor is the staff of ICANN. By your assertion, IETF should not be in charge of anything either. I disagree with that, too. 

>In ICANN's support, the alternative - the "ITU idea" - is *horrible*. The ITU is not about open communications infrastrucutres - it's about *closed* infrastructures with contracts and licensing and costs and the other paraphenalia we want to limit the effect of in the context of the Internet.
>
>No, no, no, NO. To allow this would to happen would be a genuine shame. How popular is Internet2? Why? I rest my case...'

there are any number of virtual private networks, some of them running on top of the public Internet - that's fine as long as we also keep a fully connected, public Internet in operation. Moreover, the creation of new name spaces such as instant messaging handles has created new and useful infrastructure - what's wrong with that? 

vint cerf

Vint Cerf
SVP Technology Strategy
MCI
22001 Loudoun County Parkway, F2-4115
Ashburn, VA 20147
703 886 1690 (v806 1690)
703 886 0047 fax
[email-masked]
www.mci.com/cerfsup

---

From: Karl Auerbach <[email-masked]>
Date: Sat, 29 Nov 2003 13:14:49 -0800 (PST)

On Sat, 29 Nov 2003, Paul Robinson wrote:

> ... realistically there is only one option left for a single, 

If you look at what ICANN really and truly does you will see that it has
little, if any, real role relating to internet technology.  Rather it is
an organization that, for the most part, imposes the business goals of a
selected and limited set of priviliged "stakeholders" onto the operation
of businesses that sell domain names.

Moving ICANN from the blind-oversight of the US Deparment of Commerce to
the UN or ITU ill only widen the stage for those privileged
"stakeholders".  A move to the UN or ITU, by itself, will not improve the
security of the net or or any nation.

Without major structural reforms (such as I suggest at
http://www.cavebear.com/rw/apfi.htm ) ICANN will remain a non-technical
body that regulates and governs internet business practices.

As for this thread - national security - One has to remember that ICANN's
reaction to 9/11 was to create a committee.  That committee is filled with
intelligent and skilled worthies, many of whom have deep IETF roots.  
However that committee, with respect to the matter of security, was
essentially stillborn and silent.  It has only come to life recently as a
vehicle to rebut Verisign's "Sitefinder".  As an institutional matter,
ICANN has demonstrated that it really is not suited to deal with the
technical issues of security, much less the intricate balancing of public
policy in which security choices must necessarily be made.

Moving ICANN to the UN will not, without major structural changes in 
ICANN, improve this.

Some of those changes have occurred already:

ICANN has abandoned the actual operation of the dns root servers to those
who are actually doing that job.  This is a very good thing because the
latter group are not merely extremely competent, but they are also clearly
focused on the job of running root servers and have shown that they do not
care to use their role to enforce someone's idea of intellectual property
protection.

And ICANN has abandoned the allocation of IP addresses to the regional IP
address registries.  Again this is a good thing because there are few
within ICANN who remember that this was one of ICANN's three original
purposes, much less understand the technical and economic impact of
address allocation policies.  The RIRs, on the otherhand *do* understand
this.

Personally I do not care whether ICANN is under the US Department of 
Commerce or becomes a branch of the ITU.  Both are imperfect.  As a US 
Citizen I can (and have) gone to the DoC and argued my side.  I'd probably 
have a smaller voice where things to move to the ITU.  On the other hand, 
most of the people in the world are not US citizens and thus could find 
the ITU more open to them.

For me the core issue is not under what banner ICANN exists.  For me the
issue is restructuring ICANN-like vehicles of internet governance into
things that really have a synoptic view, that are not captured by a few
selected commercial "stakeholders", and that need not be brought before a
judge (as I had to do with ICANN) in order to compel them to be open,
transparent, and accountable.

> bad idea....

Let's dispell a big chunk of that myth - ICANN has never been controlled
by computer scientists.  The board has a always had a few people with rich
knowledge of the internet, but they were always a very tiny minority.  

Let us not forget that one of ICANN's first acts was to dismantle the job
of "Chief Technology Officer".

The myth that ICANN is run by network experts has caused great damage.  
First of all, there is no reason to believe that those versed in computer
science are more capable of making public policy decisions than others.  
That myth of the Golden Age of Technical Kings died at the end of the
1930's.  [Take a look at the H.G.  Wells movie "Things To Come" to see
that myth in full flower.]

Second, the myth has created a screen of deference that hides the acts of
those privileged "stakeholders" who have proven to be very skilled at
using ICANN to promote certain intellectual property agendas to the
exclusion of nearly everything else.

> In fact, they have shown they are worse at being in charge than
> politicians and lawyers...

Most of the people involved in all of this affair are good, smart, and
well intended.  There are few Iagos.  ICANN is a glimpse of the future
that occurs when groups with different values and different uses of a
common language don't spend the time to really work down to fundamental
issues and goals.  I blame much of this on e-mail.  E-mail impedes the
development of those personal contacts that are necessary to build the
trust needed to bridge the differences of opinion and find the common
grounds.

The UN won't cause that to be fixed.

Marshall Rose came up with the notion of "doers" and "goers".  Bodies such
as ICANN are always going to be heavy with "goers".  Without structural
reform, dragging ICANN to the UN won't fix that.

> >opting-out...
 
> How popular is Internet2? Why? I rest my case...

Internet-2 is as reachible as any other part of the net.  It shares the 
common address space, it shares the common space of dns names.  To a great 
extent one can think of I-2 as a wonderfully overprovisioned part of the 
net as a whole.

There are various pressures that are building - spam, content control,
"DRM", nationalistic goals, etc - that are pushing to fragment the net in
far more serious ways.  See my short (and flawed) essay on this point at
http://www.cavebear.com/cbblog-archives/000051.html

		--karl--

---

From: "vinton g. cerf" <[email-masked]>
Date: Sat, 29 Nov 2003 17:04:00 -0500

Karl,

I strongly object to your characterization of ICANN as "abandoning"
the operation of roots and IP address allocation. These matters have
been the subject of discussion for some time. ICANN absolutely 
recognizes the critical role of the RIRs and the voluntary root
servers as part of the complex that makes up the operation Internet.
There is still need for coordination of policy among these groups
and the other interested constituents and that is the role that
ICANN will play. 

At the completion of the MOU period, ICANN will also be responsible
for the primary root zone file and the server that supplies it to 
the rest of the root server operators.

Vint Cerf
SVP Technology Strategy
MCI

---

From: Karl Auerbach <[email-masked]>
Date: Sat, 29 Nov 2003 15:39:16 -0800 (PST)

On Sat, 29 Nov 2003, vinton g. cerf wrote:

> been the subject of discussion for some time.

I can't seem to recall during my 2 1/2 years on ICANN's board that there
ever was any non-trivial discussion, even in the secrecy of the Board's
private e-mail list or phone calls, on the matters of IP address
allocation or operation of the DNS root servers.  Because I was the person
who repeatedly tried to raise these issues, only to be repeatedly met with
silence, I am keenly aware of the absence of any substantive effort, much
less results, by ICANN in these areas.

So, based on my source of information, which is a primary source - my own
experience as a Director of ICANN, I must disagree that ICANN has actually
faced either the issue of DNS root server operations or of IP address
allocation.  And ICANN's "enhanced architecture for root server security"  
was so devoid of content as to be embarrassing - See my note at
http://www.cavebear.com/cbblog-archives/000007.html

The DNS root server operators have not shown any willingness to let ICANN
impose requirements on the way they run their computers.  Indeed, the
deployment of anycast-based root servers without even telling ICANN in
advance, much less asking for permission, is indicative of the distance
between the operations of the root servers and ICANN.

[I believe that the anycast change was a good one.  However, there is no 
way to deny that that change was made independently of ICANN.]

Sure, ICANN prepares, or rather, Verisign prepares and ICANN someday hopes
to prepare, the root zone file that the DNS root servers download.  But to
say that preparation of a small, relatively static, text file is the same
as overseeing the root servers is inaccurate.

In addition, the root server operators have shown that they are very able 
to coordinate among themselves without ICANN's assistance.

> ICANN absolutely recognizes the critical role of the RIRs

Again, recognizing the RIRs is an admission that ICANN has abandoned its
role as the forum in which public needs for IP addresses and technical
demands for space and controled growth of routing information are
discussed and balanced.  Fortunately the RIRs have matured and are
themselves the IP address policy forums that ICANN was supposed to have
been.  Moreover, the RIRs have shown that they are more than capable of 
doing a quite good job of coordinating among themselves.

> and the other interested constituents and that is the role that

Again, ICANN can not demonstrate that it has engaged, because it has not
engaged, in the "coordination" of IP address "policy".  Sure, ICANN has
facilitated the creation of a couple of new RIRs.  But again, there is
vast distance between that and ICANN being the vehicle for policy
formulation or oversight to ensure that those policies are in the interest
of the public and technically rational.

I have serious doubts that ICANN will be able to meet its obligations
under the most recent terms of the oft-amended Memorandum of Understanding
between ICANN and the Department of Commerce.  I see no sign that the DNS
root server operators or the RIRs are going to allow themselves to become
dependencies of ICANN and to allow their decisions to be superseded by
decisions of ICANN's Board of Directors.

		--karl--

---

From: "vinton g. cerf" <[email-masked]>
Date: Sat, 29 Nov 2003 18:50:05 -0500

>less results, by ICANN in these areas.

The fact that there were few board discussions does not mean that staff
was not involved in these matters. Discussions with RIRs have been lengthy
and have involved a number of board members. 

>between the operations of the root servers and ICANN.

Sorry, anycast has been out there for quite a while; I am surprised you
didn't know that. We had discussions about anycast with the SECSAC and
the RSSAC and confirmed that there were few risks. The GAC requested and
received a briefing on this as well.

>way to deny that that change was made independently of ICANN.]

Anycast may even have preceded the creation of ICANN - perhaps an IETF
source or one of the root server operators can say when the first ANYCAST
deployments were done.

>doing a quite good job of coordinating among themselves.

The RIRs have agreed to use the ASO as the mechanism for conducting
global policy discussions -  you seem to think that unless ICANN is
dictating everything it is doing nothing. Sorry, I don't buy it.

>decisions of ICANN's Board of Directors.

they don't need to become "dependencies" for this process to work - you are
setting up a strawman that I don't buy into, karl. What we are looking for
is coordination of policy development in such a way that affected parties
have an opportunity to raise issues. That's what the reform of the ICANN
process was all about. 

I am not interested in having the decision of the Board of Directors supersede
RIR or Root Server recommendations. I am interested in assuring that any 
policies developed have input from affected constituencies and that these
are factored into the policies developed. 

vint cerf

Vint Cerf
SVP Technology Strategy
MCI

---

From: jfcm <[email-masked]>
Date: Sat, 29 Nov 2003 21:59:04 +0100

Dear John,
thank you for your comment even if it does not discuss the "internet 
national survival kit". I am afraid it continues a qui pro quo where we 
often say the same thing but from different points of view (not vision). 
Where you look from inside your technology, and me from a user's point of 
view, from outside and global (English/French meaning) putting Internet in 
competition with other alternatives (existing or possible).

I respond here. Because some who read could keep a strange idea of my 
positions (I did not even alluded to). Also because John is always 
interesting. Even when wrong about me, the topics are of interest. I will 
try to keep it technical, but it responds John who did not addressed the 
thread.
jfc

<- John and interested Members only - Thx ->

Dear John,
I appreciate much that you know to stay technical while caring about 
societal and political aspects (this is why you were IMHO a very good 
choice for the BoD).

But this is NOT the matter here.

At 17:47 29/11/03, John C Klensin wrote:
>You should also entertain the hypothesis that no one has commented on 
>those issues/suggestions because they are have been discussed too many 
>times before and are inconsistent with the visions that drive the 
>Internet.   Some of them have even been the subject of fairly careful 
>evaluation and associated statements, e.g., RFC 2826 on the unique DNS 
>root issue (often summarized as "which part of 'unique' are you having 
>trouble understanding?").

Please ... this is not the matter but I will respond as usual "the part you 
make it to play wrong". BTW your unique root is two different accesses 
which can be hacked differently. First risk.

The question is not the suggestions but "are there better reponses? would 
they they reduce or increase the death toll". In the cases described by the 
White House, the comparable cases in other countries contexts, the cases 
created by the White House strategy and the cases created by the other 
countries comparable strategies?

I understand no one wants to commit. We are not discussing development, 
architecture, etc. But technical aspects of Best Practices for national 
survival (economy, administration, transport, health, schools, banks, 
airlines, power, etc. etc.) in front of a large Internet failure resulting 
from an internal collapse, a international situation, an external 
catastrophe. Real - not intellectual - world stuff.

>among other things, can keep those views and address spaces

This description is totally inaccurate. Even opposite (even it should 
support that scheme as a possible scheme and that I accept every consistent 
scheme). As you know my model is a cylinder where the Internet 4 layers are 
just a slice, as the OSI is and others.

You quote the DNS, please refer to the Universal Naming System 
(uniname/universal name). That is information society, computers, IP 
rights, culture, dictionaries, automatic translation, etc.). This is where 
national/religious/community, etc. etc. cultures belong and are to be 
defended. Not the IETF cup of tea.

As part of the UNS, the brainware (people) and the software (applications, 
encryption, etc.) identify network related names. This is the GNS 
(egenalized) which must eventually permit a harmonized communication 
support. When I send a fax or an MMS or a mail or access a web site I want 
the name to be and behave the same. Even IPv6 wants that (HIP)! I give the 
example of local root ".sos". It will become the unique referent for all 
the alarms, on all the systems, in all the languages - even it may 
translate in many different vernacular ways of scripting (uninames), sounds 
or icons.

As part of the GNS there is the Internet related restriction named the 
"legacy DNS" from the root names allocated in 84 and added in 2000.

All these are different layers and in each layers/languages, ways of 
use/systems. What the user wants is to see them to look the same. The part 
of unique you do not understand is that the world is NOT uniquely Internet. 
If you want to keep thinking hierarchical (which is very restrictive way), 
you should think http://domain.name.dns.gns.uns . If name in "dns.gns.uns" 
are the same and permit DNS usages to look unique (what IPC fights for as 
famous names). But that does not prevent that many other uninames to 
related to a dns name. This is what Keith Moore and Paul Hoffmann are 
actually trying to word out at imaa, from an Internet technology perspective.

I said hierarchy was a very very restrictive way. You must support local 
occurrences, you must support abbreviations. Do you put "USA" at the of 
each letter you send to US people. Do you put your street address on the 
envelope when you drop a letter in the room of your kids. When you write to 
your "beloved wife" do you confuse her with mine because we both use the 
same subscription? All these are however very precise designations of 
unique entities we happen to have used for millenaries. We do not want to 
create confusion in being forced into an "EITF voted reality" to comply 
with a 20 years old program.

It is not simple. But who said life was simple :-)

>governments that they need to "solve" the problem, probably in

Spent much time, pains and 100s of thousands of miles at the begining, 
explaining Govs it would be nice that they put they network data and 
information in my unique file. Took years but eventually worked and was 
copied. The part about that uniqueness is it can be copied and stay unique.

What you fail to see right now is that the system you support is Babel. 
Please reread the Babel tower story. What men were confronted to was to 
build the tower with stones of sand and tar. What figured they were 
prisonners from a unique language and thinking. God never punished them !! 
He freed them - through many languages - and like sand of the sea, the sand 
of the people could flow. Read Church Fathers about that. Very interesting 
to understand the DNS and networks. I am sure that you are one of those who 
may really be interested.

Communication among people is NOT to make them use an unique language, with 
a unique thinking and an unique vision and an unique gov. It is to find 
acceptable ways to bridge there differences (languages, cultures, 
history...) without reducing them for them to inter-relate. Far, far more 
complex.

A reasonable accepted way is to use numbers. For years I support that we 
may use numbers from 0 to Z and "-" is a convenient thing. We added "@" 
recently. I suppose we should also use "#". And this is what is being done 
in many technologies now (and in URLs). But (see above) this is DNS or GNS. 
Some acceptable common trade-off to be able to relate together.

>general".

This is not technical. But I am in partial agreement.

Partial because the nature of ICANN as a de facto US agency and an 
international coordinating  body will never permit to be a multinational 
concertation (documented that in a previous mail) hub it has to be.

>   So, while ICANN, IMO, continues to need careful

Fundamental difference in our use of the word "governance". In my local 
idiom "governance" (since XIIIth century) means more or less what - you - 
you would like it to be. But the ICANN people are tied by their common 
native understanding of the word, which is much more directive. This is 
technical. Nothing political. Human languages are like computer languages. 
You depend on the language you use to think and work together. If your 
common references are not what you think they should be you meet problems. 
A brainware bug.

>a restrictive, address-and-protocol-translating gateway.

This is absurd. Only ICANN does that. Voting its own reality. What is 
unique is reality. Also what is unique is the incredible way ICANN wants to 
decide about reality. I had for long a slogan for ICANN Esther used for a 
lecture or a book "let get real".

>  We
>available as well.

Happily, in here the Customs and part of the Army runs X.25 under IP. 
Protects us.

>The question of who will miss anyone who takes that opt-out option is an 
>interesting one sociologically, but the Internet has sufficient critical 
>mass at this point, and is sufficiently important commercially in most of 
>the world, that "opportunity to shoot yourself in the foot" might figure 
>into such an analysis.

This is an incredible thing to say when we are precisely confronted to Govs 
representing 3/4 of the humanity saying "No! you will not appropriate our 
common network!". Or have you already opted-out 80 of the mankind?

Anyway, this NOT the matter, John. The mater is to help these 80% survive 
the Internet until the world fixes a new generation network fulfilling your 
hopes better, more securely, etc.

>If you are convinced of the viability of your ideas, by all means go off 
>and try them: just be sure that your namespaces and addresses don't leak 
>into the real network.

Which ideas???

I have listed a survival kit. From different propositions. By different 
groups. For different purposes. That I certainly find acceptable and 
coherent. And I say "please say what is wrong with them before having them 
enforced or describe a replacement". I doubt that this was discussed beofre 
orplase povide the URL.

This follows a study of an ICP-3 conformant test bed. BTW I note there is 
only one thing I disagree with your ICANN there, is when it says this may 
lead to the unique authoritative root concept to be deprecacted. Absurd, as 
saying that in the future there could be several colors to the sun . But 
which sun are we talking about.

Take care.
jfc

---

From: jfcm <[email-masked]>
Date: Sat, 29 Nov 2003 23:51:55 +0100

Dear Vint,
thank you for commenting on the Internet national survival kit issue this 
way (we are one week before the last Geneva prepcom, where ICANN is 
disputed in a way the survival kit may affect).
Our common goal is to help consensus, not to increase tensions.

At 19:54 29/11/03, vinton g. cerf wrote:
>Please read the most recent MOU. The US Department of Commerce has gone to 
>considerable effort to outline the path by which ICANN becomes the party 
>responsible for the updating of the DNS root. The control you assert is 
>quite limited even today.

Objection is not that you are the root registry, but the USA and you are 
the registrant. RFC 1591 says IANA is not in the business of defining a 
country. Why to intrefere with countries? What is the intrinsic difference 
between root and TLD updates? The post KP&Quest updates are a good example 
of what Govs do not want anymore.

>Any formal body has to have some jurisdiction in which it is constituted. 
>One can argue whether California non-profit law is better or worse than 
>being a UN entity. I believe there are arguments against the latter as 
>much as there may arguments against the former.

The complexity is that ICANN wants to be two conflicting things (American 
and International) and to organize something multinational.

>that's not at all clear. ICANN has tried to promote the adoption of IDN, 
>for example, in a responsible way. John Klensin's efforts, and others, to 
>promote international compatibility to enhance the ability for parties to 
>communicate is commendable. What do you think is awful?

The IDN solution! :-)
it was doomed when ICANN refused it to be multilingual. Let not dispute on 
that. Vernacularization may come from a true internationalization (0 to Z) 
on the LHS. May be Keith Moore will find a reasonable way.

> >The IETF is about as close as we've got as an "authority" on the 
> Internet that is not bounded by geographic boundaries, governmental 
> control or commercial contract. You can make a reasonable argument that 
> we should be running the show here, not ICANN.
>
>Not unless you want to take on the full burden of Internet Governance 
>written large. Not even ICANN wishes to do that. In fact, ICANN's role is 
>very limited compared to the full scope of Internet Governance.

Four language problems in here I doubt we can reduce. ICANN understands its 
governance role as global coordination of the network. Our respective 
cultures have opposite understandings for governance, global, coordination 
(we will accept concertation), network. I suppose other cultures and 
languages have others. You probably stay in the middle. Hence your need to 
explain again and again "we are not what you believe we are". Should this 
not be plain obvious for now.

Consider the French (original) meaning of "gouvernance". For networks it 
would be "net keeping". Many ICANN relational problem would disappear.

>  Issues such as fraud, taxation, intellectual property protection, 
> dispute resolution, illegal actions are governmental matters and not even 
> UN has the appropriate jurisdiction. It will take cooperation among 
> governments and thoughtful domestic legislation to deal with many of 
> these matters. ICANN has high regard for IETF and IAB and for that reason 
> there is an IAB liaison appointed to the Board of Directors.
>
> there, realistically there is only one option left for a single, cohesive 
> Internet to remain whilst taking into account ALL the World's population: 
> ICANN needs to become a UN body.
>
>nonsense - as constituted today, ICANN is a better forum for interested 
>constituencies to debate policy FOR THOSE AREAS THAT ARE IN ICANN'S 
>PURVIEW (not shouting, just emphasis on limited purview of ICANN).

We all will accept the word "forum". The role I assign to ICANN is to guest 
forums and to cross polenize among them.

Why then to force participants to abide by your by-laws to come (ccTLDs). 
Paul Twomey's Nov. 19th paper is a contention point. It is seen as a bold 
ICANN move before the 5/6th meeting. And your own response about ccTLDs.

What would be the difference if the ccNSO resulted from an MoU? It would 
permit to help/join with ccTLDs, and RIRs, over a far more interesting 
ITU-I preparation. I suppose RIRs would not be afraid an ITU-I would not be 
here 2 years from now.

>The problem with the arguments I have heard, including yours, is that you 
>may be thinking of Internet Governance in the large while ICANN's role is 
>small and should stay that way. We need other venues in which to deal with 
>the larger problems and perhaps UN or some of its constituents have a role 
>to play. Probably WIPO and WTO do as well.

Agreement. Then why to have built a big machine to be the IANA + a forums 
guest. Until mid-run ERC was a good thing. IANA/ICANN is by nature a single 
point of failure (because unique with some some responsibility). Initial 
agreement (RFC 920) and update (RFC 1591) were technical. They could go for 
ever. NIC/IANA is just a registering secretariat. Intlnet was 3 hours of my 
time a week from 78 to 86 to carry the job of listing technical and 
commercial data of the word. Plus support of the international meetings and 
some PRs. No more than 1/4 of my time and asstants. ISO 3166 is managed by 
one single person. Why is ICANN needing so much more?

>I disagree - please consider the last ICANN meeting in which the Board 
>went some distance to making changes in its policies in response to 
>international constituency inputs.

Vint, you will never change that IANA is part of the Internet and Internet 
is the current solution of the world for its datacommunications. So IANA 
must be involved. ITU is the way govs cooperate in communications (data, 
telephone, TV, radio) and where they have so many mixed interests that they 
must be cautious (this is what protects us, the consumers). So ITU must be 
involved.

If you are serious about becoming multinational, you must disengage from 
the US Gov. But IANA will never lose its US Flag without ITU. ITU will 
never develop an acceptable higher layers capacity (ITU-I) before long, 
without ICANN, ccTLD etc.

So, how long will we have to wait for you to ally (and not to try to 
swallow) with ccTLDs and to sit down with Mr. Zao, stop WSIS worrying and 
permits jointly care about fostering development and innovation.

>Sorry, it is a lot more complex than you seem to think - the question of 
>who should have responsibility for a CCTLD is often very complex - it is 
>sometimes not even clear who the government of country X is.

Is that not contradiction? Is ICANN in the business to decide about 
domestic issues. Does the UN or the Union Postale chose the Head of the 
National Post Offices? You perfectly know what Brazil's position is. What 
is technical there?

A net keeper, trying to help patching difficulties? No more? This is he 
only thing which can work. We were quite helped understanding that because 
of the monopolies. Today you are confronted to sovereignty which is in this 
area the same.

> bad idea. In fact, they have shown they are worse at being in charge than 
> politicians and lawyers... they will never get another chance after this 
> god-awful mess.
>
>The Board is not made up of computer scientists alone; nor is the staff of 
>ICANN. By your assertion, IETF should not be in charge of anything either. 
>I disagree with that, too.

IETF is to deliver technical solutions. IANA is to deliver a registry 
service. What is ICANN up to? Except what we agree: "to guest forums" to 
help consensus there.

BTW is that very different from ITU? Just that Paul Twomey's Nov 19th 
document would have resulted from a painstakingly g/sTLD consensus and 
would not have worried ccTLDs.

>there are any number of virtual private networks, some of them running on 
>top of the public Internet - that's fine as long as we also keep a fully 
>connected, public Internet in operation. Moreover, the creation of new 
>name spaces such as instant messaging handles has created new and useful 
>infrastructure - what's wrong with that?

The lack of users networks. Multiorganization TLDs Jerry made introduced as 
a reality we started experiencing. Just consider that the large user 
networks (SWIFT, SITA, VISA, Amadeus, Mnitel, etc.) started before 85. OSI 
brought X.400. CERN brought the Web. But ICANN - and unreliable technology 
- blocks ULDs (User Level Domains).

I just note that you never cared about Consumers organizationsn, while a 
world e-consumer council would have given you the legitimacy of billions 
and the weight to keep Gov partly at large, and satisfied. A National 
Security Kit would then be one of the ICANN raisons d'être, keeping Govs happy.

Best regards.
jfc

---

From: Bill Manning <[email-masked]>
Date: Sun, 30 Nov 2003 03:27:02 -0800 (PST)

% Anycast may even have preceded the creation of ICANN - perhaps an IETF
% source or one of the root server operators can say when the first ANYCAST
% deployments were done.

	Not an IETF source. In discussions on the earliest anycast
	instance, there was general agreement that "M" was anycast
	from the time it moved from LA to Tokyo, roughly 1997.

--bill
Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).

---

From: Paul Vixie <[email-masked]>
Date: 30 Nov 2003 18:47:10 +0000

i'm going to bend my own policy a bit and reply to a role account:

[email-masked] (jfcm) writes:

> ...  The interest is not sites nor network protection layers, but nations
> protection from what happens on or with the networks. This is in line
> with the White House document http://whitehouse.gov/pcipb with the
> addition of the risks created by the US (and every other national) cyber
> security effort, and from not mastering the root. In most of the cases
> the identified risks come from a centralized [root] which has to be made
> distributed.

this statement is akin to many others made in ignorance of what dns is.  you
are treating it as a mapping service.  perhaps you have been successful at
treating dns as a mapping service in some local context, and this may have
led you to the impossible conclusion that dns itself is a mapping service.

dns is a coherent, distributed, autonomous, reliable database.  "distributing
the root" as you claim to believe is necessary would create multiple domain
name systems, not *a* domain name system with a distributed root.  there is no
way to have *a* domain name system with a distributed root unless we (ietf
or other similar agencies) first defined what that meant.  when you're ready
to commission a multiyear study which would yield documents of the same size
and scope as rfcs 1033+1034+1035+2181, then you'll have demonstrated that
you have some understanding of what you're asking for here.  and note that
you would then have to "sell" the resulting system to the internet populance
which includes end users, domain holders, registrars, registries, ISPs, and
as you point out, nations.  lots of luck, but "that ship already sailed."

in no particular order, i'll address a couple of your other comments.

> origins for security reasons).

there is a reference.  several references, actually.  there is no possibility
of a "hack" going undetected or uncorrected.  but more important, if you had
several "root files" which indicated different servers for some TLD's, you
would have (by definition) several domain name systems, not a domain name
system with high redundancy.  until you demonstrate some understanding of
that fundamental and definitional aspect of dns, you won't be taken seriously
among the community who does understand those things.

> Thank you for your comments.

please learn the basics before you come in here and start making proposals.
-- 
Paul Vixie

---

From: jfcm <[email-masked]>
Date: Sun, 30 Nov 2003 20:44:42 +0100

At 17:35 30/11/03, Michael H. Lambert wrote:
>Dear jfc,
>As far as I can tell, you have gone only by your initials on this 
>thread.  To help some of us weigh this discussion, could you please 
>identify yourself by name and affiliation?

Sorry for this. The question was asked and replied to, but I did not note 
the list was not in copy.

I am used to do this for long because I think what is debated is important, 
not the persons (when I want to know the competences of someone I go to the 
person's site).

This is precisely a part of the concern: will IETF practically be able to 
understand and treat equally needs/inputs from Pittsburgh and from every 
other place and culture. What to suggest if not? Analysing and working 
together world and technical cultures wide is not that easy (look at my 
exchanges even with John Klensin). If you follow the WSIS you know that 
this type of concern is the crux of the current negociation.

So who I am should not impact on the responses to what is a documented call 
for warning, advice or aternatives on vital issues. Or a specialized body 
must be created.

I am JFC Morfin. You will find my professionnal site at http://utel.net. I 
created in 1978 the SIAT/Intlnet ( http://intlnet.org ) which assumed until 
1986 the role of very very lean ICANN the international public packet 
switch network needs. After 9/11 I called a study group at the  DNSO/BC to 
propose the writing of an ICP-4 ICANN Document over Global Security. The 
limited interest of the next MdR meeting on Security, the annoucements of 
M$ and Richard Clarke's mission led to launch a project and a study named 
dot-root (http://dot-root.com). It strictly abode by ICANN ICP-3 to 
organize a DNS double test bed with an unique and a parallel root systems. 
The study (French) was presented earlier this year to people in charge. As 
part of the follow up there is a meeting on national vulnerabilities to the 
DNS/IPv6 as identified by the study and readers feed-backs. This does not 
directly concern sites nor network protection, but lives, economy, culture, 
way of life, e-government, development, sovereignty, etc protection - not 
theoretical but right-now.

jfc

---

From: Dean Anderson <[email-masked]>
Date: Sun, 30 Nov 2003 20:42:18 -0500 (EST)

> would not have worried ccTLDs.

This doesn't completely cover it. For example, the IETF delivers
standards.  The ITU also delivers standards.  The ITU has issued competing
standards such as IS-IS, X.400, X.500 etc, etc, etc.  The IANA and ICANN
functions are also similarly performed by the ITU. For example, the
allocation of Radio frequences, and radio call sign prefixes.  Obviously,
the functions of the IETF, IANA, and ICANN could be done by the ITU, and
the ITU has considerable experience in these areas.

I think there is very little credence to any legal benefits of being
incorporated in Switzerland versus the US.  Indeed, generally, one must
incorporate in any country in which one has permanent employees. If the
ITU were to take over the IETF/IANA/ICANN and their US employees, it would
still be incorporated in the US, as well as in other countries.
Organizations can be sued in any country they do business in whether they
are incorporated there or not, so it doesn't matter too much where they
are incorporated.  There are variations in the fees to maintain a
corporation, but these are minimal. For example, it costs about $300/yr in
Massachussets, versus about $125/yr in Delaware.  Delaware also has
extensive support by the state department of corporations for finding the
necessary corporate agents, who charge nominal fees to be the corporate
agent.  This causes most corporations to be incorporated in Delaware.
Other than minor issues like that, there is little benefit.  While
different countries have different tax structures, these are likely to be
of little to no consequence to a standards organization.

The real issues with moving the IETF/IANA/ICANN functions under the ITU
are questions of economics and democratic constituencies.  It is these
questions that really need to be addressed:

Quite obviously, duplication of the administration efforts results in
wasted money.  The only reason to keep them separate is to perform this
job better.  As has been often pointed out, the IETF is fairly sloppy in
its administration. Clearly, moving the administration of IETF activities
and standards to the ITU would be a benefit for all in terms of savings
and in terms of improved administration.

The main criticism of the IETF/IANA/ICANN by the rest of the world seems
to fall under the democratic constituencies issue.  People outside the US
seem to distrust the US, and feel that their voices are not being heard,
and that they aren't being represented properly.  I don't know whether
there is a truly genuine failing in this respect, but there is clearly a
widespread concern.  The perception is just as serious as an actual
impropriety.

Given that the enconomics seems to point to consolidation with the ITU,
and the fact that many seem to place more trust in the ITU, I think we
ought to seriously consider this option.  I've been though the merger of
standards groups incorporated in different countries, as a technical
consultant, and the results have been very positive.  The benefits are
similar to the benefits gained by the merger of companies.  The main
difference being that the "users" have much more say in the direction of a
standards group than the customers of two private companies.

Of course, the ITU also needs to agree to sign on to take over this
responsibility, and it will require additional funding for the ITU, and it
is unclear the that the funding for ICANN/IANA/IETF will be transferred to
the ITU if such a change is made.  Essentially, this means that the rest
of the world will have to put more money into ITU funding.

Dean Anderson
CEO
Av8 Internet, Inc

---

From: [email-masked]
Date: Sun, 30 Nov 2003 21:30:11 -0500

> widespread concern.  The perception is just as serious as an actual

I've not followed the innards of the ITU process - have they fixed the
balloting/veto setup that resulted in such "all options for everybody"
elephantine standards like X.[45]00?  Democratic constituencies aren't
always a good idea.....

---

From: Karl Auerbach <[email-masked]>
Date: Sun, 30 Nov 2003 18:29:59 -0800 (PST)

> and have involved a number of board members. 

Discussions "with staff" hardly constitutes responsible oversight by ICANN
as a body responsible to the internet public.  All you have said is that
ICANN has not merely abandoned its oversight of DNS and IP addresses to
the root server operators and the RIRs but also that the only elements
within ICANN that even bother to observe are the occassional board member
and some perhaps some unnamed staff members.

I raised the anycast issue several times to the board.  "Staff" received 
those e-mails.  I do not except as valid an after fact explaination that 
says "Even though nobody bothered to answer Karl's inquiries, ICANN's 
staff was really making informed decisions, in secret, about anycast."

ICANN's job is not to make decisions in secret, by unknown members of
"staff", based on unknown criteria and using unknown assumptions.  To do 
so, which is what you are saying has been done, is simply yet another 
abandonment of ICANN's obligations.

The switch to anycast for root servers is a good thing.  But it was hardly
without risks.  For example, do we really fully comprehend the dynamics of
anycast should there be a large scale disturbance to routing on the order
of 9/11?  Could the machinery that damps rapid swings of routes turn out 
to create blacked out areas of the net in which some portion of the root 
servers become invisible for several hours?  Could one introduce bogus 
routing information into the net and drag some portion of resolvers to 
bogus root servers?

I'm pretty sure that the root server operators have answers to these
questions.  However, it is incumbent on ICANN not to simply accept that
these people know what they are doing; ICANN must document it, ICANN must
inquire whether some of the decisions are made on public-policy
assumptions (in which case "the public" needs to become a party to those
decisions).

Considering that we know that there would be no ill effects to adding even
a hundred new top level domains, one has to wonder at the degree of
automatic deference (deference amounting to an institutional decision to
be blind) to the deployment of anycast as compared to the hyper detailed
inquiry into matters even as irrelevant as the pronouncability in English
of a few proposed new top level domains.

In addition, an argument could well be made that anycast violates the
end-to-end principle.  For instance, it's hard, or impossible, to maintain
a TCP connection that spans a routing change that sunsets one anycast
partner and sunrises another.

Given that one of the strongest arguments against Verisign's Sitefinder is
that it breaks things, and that it violates the end-to-end principle,
Verisign lawyers must be very pleased that they can so easily demonstrate
that ICANN is willing to act with overt bias, to let slide, without
inquiry, those things proposed by ICANN "friends".

> didn't know that.

No need for sarcasm.  As you must be well aware, was the one who explained
to ICANN's Board how anycast works.  Indeed, I was the one who brought the
deployment of anycast roots to the Board's attention.  I know that the
ICANN Board considers its communications secret.  However if I am required
to defend myself from what I consider to be an unwarranted and
unsupportable assertion regarding my professional knowledge I would have
to consider it my right to defend myself and publish any and all relevant
materials from the archives of the Board's e-mail.

But you miss the point - the deployment of anycast for root servers was a
bold operational decision.  It was a decision made by the root server
operators alone, without ICANN.

ICANN's obligation is to guarantee to the public the stability of DNS at
the root layer.  ICANN's failure to engage in the issue of anycast
deployment was simply and clearly and abandonment of ICANN's
responsibilities.

> Anycast may even have preceded the creation of ICANN

Yes, anycast has been around for a long time.  Multicast, NATs, and OSI
all also preceded the creation of ICANN.  But does that mean that ICANN
should freely and and without question allow the deployment of those
technologies for DNS root servers?

> dictating everything it is doing nothing. Sorry, I don't buy it.

So, I take it that you consider that ICANN's role is to rent meeting halls 
in which groups may meet and make decisions?

ICANN, in order to guarantee the public that the DNS and IP allocation 
systems of the net are stable is obligated to have a final veto power.  As 
it stands ICANN has abandoned that power to the RIRs.

These are not idle issues.  The issue of NATs has filled several IETF 
threads.  Most of us considers NATs to be ill-starred creations.  But they 
are quite popular.  And why are they popular?  Partially because of the 
policies of the RIRs that restrict IP address allocations.  Yes, the RIRs 
have many and good reasons for their policies.  But those policies are one 
of the forces that are inducing more and more NATs.  It is easy to 
conceive of ICANN disagreeing with the RIRs over an allocation policy that 
would further drive NATs.  ICANN, in its present role, has abandoned the 
final authority over that question to the RIRs and in so doing has 
abandoned ICANN's responsibility to the public.

ICANN has left operational issues of the DNS roots to the root server 
operators.  ICANN has left the final authority for IP address decisions to 
the RIRs.  I personally have no major objection to that.  But it is a 
situation that makes ICANN superflous except for the protection of 
trademarks and the granting of top level domain franchises.

> they don't need to become "dependencies" for this process to work

Either ICANN has the final authority to dictate decisions to the root
server operators and RIRs or it does not.  If ICANN does not then ICANN 
has simply abandoned its responsibilities to the root server operators and 
the RIRs.

"Coordination" is a weasel word.  Either ICANN has the authority to 
make a guarantee of internet stability to the community of internet users 
or it does not.  As I read your comments you seem to be saying that ICANN 
does not have that authority.  If that is the case, I can only ask, why 
should be have an ICANN if it is simply a toothless bureaucracy whose job 
is simply to stand by and let other more competent bodies made final 
decisions.
 
> RIR or Root Server recommendations.

Which is simply to say that you are not interested in an ICANN that is
able to make a guarantee to the public that the root of the DNS and the IP
address systems are being operated responsibily and in the best interests
of the stability of the community of internet users.

ICANN can be merely a "coordinator" if it wants.  But to do so it needs to 
stop trying to deceive the public that it is a player and start being 
truthful that its role is merely that of a cheerleader.

Harry Truman was famous for his desk plaque that said "The buck stops
here."  But in the land of ICANN it is clear that the ultimate
responsibility is not ledged in ICANN; it is in the hands, good will, and
expertise of the root server operators and the RIRs.  At the present time
those hands are competent, the will is good, and the expertise great.  
But in the absence of clear ultimate authority in ICANN, things could
change leaving the internet community vulnerable and without protection.

		--karl--

---

From: Paul Vixie <[email-masked]>
Date: 01 Dec 2003 04:34:44 +0000

karl wrote:

> "staff", based on unknown criteria and using unknown assumptions.  ...

that sentence is punctuated incorrectly.  there's a period after "decisions."

> ... so, which is what you are saying has been done, is simply yet another 

i think there's a tense problem here.  icann cannot abandon that which it
never had.  perhaps a pretense was abandoned, but not an actual obligation.

> The switch to anycast for root servers is a good thing.

again there's a tense problem.  there was no "switch to" anycast.  the last
time those thirteen (or eight) ip addresses were each served by a single host
in a single location was some time in the early 1990's.

>                                                         But it was hardly
> of 9/11?

yes, actually, we do.  (or at least the f-root operator does.)

>           Could the machinery that damps rapid swings of routes turn out 
> servers become invisible for several hours?

nope.  or at least, that risk is unchanged from the multihomed servers that
have actual backhaul between their points of presense.  (those of you who
are bgp-aware all know that there is no way to tell the difference between
a robustly multihomed network and a robustly anycasted network.)  if karl
is going to start worrying about flapdamping, he's late to the party, and
the things to worry about aren't all or even mostly anycasted.

>                                              Could one introduce bogus 

of course!  but then that was always true and will always be true.  the only
fix to it is some form of secure BGP which i guess means route-signing and
route-verification and oh my what a mess that turns into very quickly.  and
the affected ("at risk") elements are, again, overwhelmingly NOT anycasted.

> assumptions (in which case "the public" needs to become a party to those

that's an interesting view.  i'm not sure i don't share it!  but that's not
how things work now, or how things have ever worked, and i'm shocked that
karl of all people would want to see ICANN's mission "creep" in this way.

> Considering that we know that there would be no ill effects to adding
> even a hundred new top level domains, one has to wonder at the degree of

well, in my role as a root operator i don't care about content either way,
and even as an internet citizen i don't have strong views about adding TLDs
(beyond what i wrote in http://sa.vix.com/~vixie/bad-dns-paper.pdf that is).

but i can tell the difference between a user-visible change that will affect
the internet's financial and information economy, such as adding TLD's, as
opposied to an operator-visible change that users won't even notice and
which creates no new business opportunities.

one of those, and i really do mean only one of them, is in ICANN's ballywick.

> end-to-end principle.  For instance, it's hard, or impossible, to
> maintain a TCP connection that spans a routing change that sunsets one
> anycast partner and sunrises another.

i suspect that concerns of this kind were the main reason why the rootops
waited to see several years of results from nominum's and ultradns's use of
dns anycast before doing widescale anycast.  in fact, one concern learned
by watching nominum and ultradns led to the namespace piracy known as either
HOSTNAME.BIND or ID.SERVER (depending on the age of the software).  all of
this was in class CHAOS of course.  but widescale anycast would have been
impractical without this extension.

as to karl's end-to-end argument, anyone using a hash-based load balancer,
including Stupid OSPF Tricks, for local load balancing would be subject to
the same issues.  it is therefore very notable that DNS TCP sessions are
short-lived, and that the "end" can change identities with radically high
frequencies, and there is no observed impact on network load or likelihood
of retrieving a correct and useful answer.

> operators alone, without ICANN.

the implied social contract for ISC as a "volunteer" rootop is that we will
serve the data, the whole data, and only the data provided to us by IANA,
and that we will use our (considerable) best efforts to serve it to the
greatest possible number of DNS initiators with the lowest latency and
lowest error rate we can arrange.  this is all the original IANA asked of
us, and the current IANA has not (yet?) complained about our performance.

whether it's done with anycast, or with smoke signals, or with one's
complement vs. two's complement arithmetic, is a purely local affair.

> the root layer.

i disagree...

>                  ICANN's failure to engage in the issue of anycast

...which makes this statement, to me, a nonsequitur.

> technologies for DNS root servers?

use of anycast for root name service did indeed predate ICANN's existence.

> > they don't need to become "dependencies" for this process to work

indeed not.

> has simply abandoned its responsibilities to the root server operators
> and the RIRs.

this kind of black-and-white analysis is too truncative of information to
give us any insight.  if ICANN could not get what it wanted from a rootop
then it would have recourse, called "redelegation".  this would be a last
resort and very expensive for all parties concerned.  but there's recourse,
even if it's probably not what you mean by "final authority."  there is no
final authority in the sense that i think you mean, and can never be.  (does
karl think anyone outside china has final authority over what Google will
show as its results to chinese web users when taiwan is involved?  and
that's just for starters..)

> "Coordination" is a weasel word.  

coordination is as good as it gets, and anyone who has a god ought to pray
that we can get it and keep on getting more of it.

>                                  Either ICANN has the authority to 
> or it does not.

that is a false dichotomy.  on the internet there can be no dictatorship
since anyone who wants to dig their own sandbox can just go out and do that.
therefore coordination and voluntary participation is really all we can ever
hope for, and i sit here right now, hoping for it, and hoping for more of it.

>                  As I read your comments you seem to be saying that ICANN 

"tooth" is a contextual term.  there is much good that ICANN can do, but it
will never be the "authority" karl seems to be envisioning here.

> truthful that its role is merely that of a cheerleader.

that's a straw man argument.  coordination is not a definitionally toothless
activity.  consider the IEEE802 48-bit address space.  i don't think the
coordinating body would sue a manufacturer who started minting their own
prefixes, and in that sense there is no "final authority."  however, the
coordinator's will would reign supreme in the long run, even without the
"authority" karl seems to be questing for.

> change leaving the internet community vulnerable and without protection.

i guess what karl has shown here is that on the internet there is no buck
or that it doesn't stop anywhere or some combination thereof.
-- 
Paul Vixie