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