Dear David,
Let me first tease you a bit in my turn (you started it) :-). Then, I will be very serious.

On 17:04 23/10/2013, David Conrad said:
Those who chose the labels of the INTLFILE (now the root): Never heard of "INTLFILE". How surprising of Postel, Su, Mockapetris, et al., to not credit you and your compatriots with the design of the DNS. Oddly, when I do a google search on "INTLFILE" with those names, I get "Your search - INTLFILE Bob Trehin Joe Rinde Mike Rude Cees De Witt Jim McDonald Neil Sullivan - did not match any documents."

I agree with you: I gather our educations were different.
This was well before your time!
Why do you want them to credit us? Who do you credit for "US" or "China"?
BTW, are you not American? Cees is Dutch, Bob and I are French, but all the others are US citizens. I accept that most were distant foreigners to you (offices in Bub Road, Cupertino), but Neil lived in Los Altos.
In addition, I was sure that you made a difference between labels and DNS?

Vint Cerf added others in the ICANN/NTIA root in 2000+
You have an interesting view of history.

I gather our auditions were also different that day?

The dot-root is a reality, while the root-files are a concept.
Again, you have it exactly reversed.  The root of the DNS is a concept, representing the "universal reference point" that ensures naming uniqueness within the context of a single namespace.  It can be instantiated in numerous ways. The way the IETF chose to implement that "universal reference point" was via a single file managed by a single administrative entity. There are obviously other ways of bringing the "universal reference point" into "reality", some more useful than others. The advantage of the approach the IETF took is simplicity, with the obvious downside that it creates a single point of interest that attracts politicians like moths to a flame (for good or ill).

I know that I am as stupid as an internet wire, and that you enjoy contradicting, but I would have bet that:
- there was a single universal reference point in the universe, including the internet, politicians or not.
- the single file was for Jon Postel a way to manage the NIC more simply, in order to control the bills of external use, and further on to ensure scarcity when he had to charge for the names.

A splitDNS is not the DNS.
If it walks like a duck...  I'm sure DNS administrators around the world running split DNS environments will be fascinated to know they aren't running the DNS.

You are like me: I always thought that in an environment in which some participants may not be that comfortable with some technical issues that it is best to not ask for words to be overly accurate.

(an horrendous portmanteau word, would you think of something better :-)?)
No thank you. I was always

You were always … ???

demonstrate one's vast erudition.

This is why I do suggest we just keep talking about what we did, know, checked, and work on, that could help in identifying and finding a solution to our current problem.
 
BTW, “Erudition” means no divagation :-)

----

Break.

----

There are three post-Davis (and his packet) approaches of the network technology: Pouzin with the datagram/Després and X.25, etc. and Norman Hardy with his agorics, etc.

The historical staging and reciprocal ignorance/oppositions of these three approaches and teams is quite interesting. It could actually pay back forty years later on, especially in the Post-Snowden context.

I happened to:
- belong to the (historically, commercially, and politically) "first one" (Tymnet) that evaporated in the mid-1980s after being poorly acquired.
- have developed my own business' QNX based real-time interoperations system for X.25.
- stay/become friends with the French historic pioneers of the currently "leading one" (I interconnected the Internet and X.75 to the IRC/PTT international network). At that time, TCP/IP was technically supported by BBN and Telenet (Larry Roberts and Barry Wessler). As the two companies were IRCs (International Record Carriers) and domestically competing VANs, we were not initially allowed to work together except through third party operators (we interconnected Telenet in 84). This gave us an interesting point of view on the other architectures (and on operators and customers likes/dislikes).

My belief is that the solution to the present situation that we face is to be found in taking advantage from the best of these three approaches. This was demonstrated by the consensus we eventually reached at the IETF/WG-IDNAbis chaired by Vint Cerf, concerning IDNA, and exemplified by RFC 5895. Today, the target should be a concerted lowest cost transition scenario (it will probably take ten years) while avoiding technical, societal, political, and most probably economic layer violations during that period.

Since I take that we are going to bet on the existing Internet (at least initially), there two main types of problems that lie ahead.


1. Those on my side of the history because they are related to layers (Services and Intelligent Use [IUse]) that were familiar or approached by Tymnet and my department, and outside of the end to end scope. They are defined and located by RFC 1958: "Everything else should be done at the fringes." This is why I embarked into the IUCG@IETF once the Unicode semantic layer-violations issue was correctly addressed.

Experience on both sides seems to have shown that things had to be revamped:
- cf. RFC 3869 on the end to end side;
- cf. my practical inability in a foreign language (English, Internet) and presentation (RFC working format) with no budget to raise a grassroots interest on the fringe to fringe side.

However, if we want to interoperate,
- it must be in a multi-stakeholder manner, which is something that has been partly addressed in Montevideo. Good.
- it must be adapted to the 2013 Internet, something that RFC 6852 should permit. However, it also prevents the multi-stakeholder approach. Something that my ongoing appeal to ISOC should help address. Pending.

The task on the fringe to fringe IUCG side is:
- to express our IUse needs through a robust model in Internet and 2013 terms;
- to relate them to the Internet layers and to all of what has been achieved by the IETF (network) and W3C (application). For example: works such as OPES, DDDS, JSON, etc. might help a lot.

After considering the whole thing, I feel that the best is to start again from the beginning, starting from/with the initial pioneers, considering all of what was learned in the last 35 years. The target is:
- to focus on the common architectonical roots and lessons of the three (and possibly more) architectures,
- to look at the alternative or additional options that could emerge
- to word all of this as a transition from and based upon what does exist and how end-users behave today.
I just started this, chasing old documents. It will be located at http://iucg.org/wiki/TCP/IP:_origins (everyone is welcome to help).


2. The main and key problem, however, falls on your personal lap. It concerns the IANA globalization.

The ICANN/IANA globalization is demanded by some. You certainly are the person who can best help here, as a former and performing IANA manager within the ICANN structure. Your experience and guidance are of major interest to the Civil Society, OpenUse, FLOSS people, and all the stakeholders. 

--- what does such an ICANN/IANA globalization mean for you (I have no real idea, and the reasonable responses I get eventually look flawed)
--- what is the technical target? What are the procedures? Would you be in charge (as the Civil Society should consider to propose) what would you do?
--- how to practically manage it? Who would be in charge?

There are two (separate?) ways of considering the IANA:
- as a presentation of the Internet as it is and operates (current IANA)
- as a guide to best use the Internet.

Do you think they should be kept separate or united? If they are kept separate, the guide to best use the Internet will engulf the current IANA and will most probably circumvent it in the long term (single customized windows effect). What do you think from that probable evolution?

NB. My reading of the current situation is that they cannot be united, since RFC 6852 implies the possibility of other standard sets, hence other compatible IANA tables that ICANN would be allowed to support (RFC 2860).

jfc