Message-Id: <6.2.1.2.2.20050627180242.05b68350@pop.online.fr>
Date: Mon, 27 Jun 2005 18:03:51 +0200
To: John C Klensin <john-ietf@jck.com>
From: Jefsey Morfin <jefsey@online.fr>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable
Cc: Thomas Narten <narten@us.ibm.com>, jkrey@isi.edu,
	Sam Hartman <hartmans-ietf@mit.edu>, IESG <iesg@ietf.org>,
	IETF list <ietf@ietf.org>
Subject: IANA evolution - was IANA Action
Precedence: list
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

At 12:32 27/06/2005, John C Klensin wrote:
> > (The IETF is here for engineering the protocols, after all).
>
>Allison, I'm generally supportive of that view.  I've actually
>been responsible for writing some of those IANA considerations
>sections that require standards-track actions.   In the light of
>this situation and a few recent other ones, I have modified my
>historical view somewhat and would encourage the IESG to do some
>similar rethinking.

Dear John,
I am impressed by this rethinking. I can provide more elements here. We=20
created AFRAC (http://afrac.org) to focus on CRC issues (common reference=
=20
center, i.e. granular IANA distribution/extension) at national level.

 From what I gather IANA (NIC) was the "second" networking main concept=20
historically introduced. Larry Roberts built the transport network in usi=
ng=20
Robert Khan's systems and Doug Engelbart proposed a repository, building=20
the infrastructure of the relational layer of the network where he stored=
=20
Steve Crocker's documents and their parameters. Then later on Louis Pouzi=
n=20
proposed catenet. All was the cimented by TCP/IP and supported later on b=
y=20
the DNS, which is a formidable example of a IANA registry granular=20
extension and co-management. We are here therefore at the very core.

The "transport" layers were in line with other works of the time and have=
=20
been worked on a lot since then. I do not see similar work on the NIC=20
layers other than naming (but no new concept since the RFC 920 consensus)=
=20
and Doug Engelbart providing additional tools in mid-80s. I was intereste=
d=20
using them for the documentation/repository I started in 1978 for the=20
International Network, as we were both in the same group and woking on ne=
w=20
machines which could have welcomed his solutions in that context.

Doug accompanied them with a philosophy named "augmentation": the=20
collective IQ of a "bootstrap" (http://bootstrap.org) is augmented by its=
=20
networking. The Internet bootstrap was the NIC/IANA managerial group, ie=20
the IESG now. This opposed our observation of the real international usag=
e,=20
which could be named "extension": human's reach and relations are extende=
d=20
by the network. This extension of productivity obeys a network value law=20
(n.log(n)-=B5.n^2) which shows how the network may also represent a less =
in=20
productivty if architectural filtering is too high (this is the immediate=
=20
risk with spam or shown by IESG in the HBH code point denial).

These two visions resulted from history. Doug started a documentation=20
center in 1970 (?) to accompany the development of a new project (ARPANET=
)=20
which grown by "catenisation" ("the network of the networks"). I started =
a=20
documentation center to prevent the balkanisation of an existing network=20
(Tymnet International) having to be partitionned (acknowldegment of=20
national monopolies rights to "stand-alone systems", or "externets" as we=
=20
now name these "internal 'external networks' look alikes"). I would say=20
"the networks in the network".

What is fun is that my problem at that time was ... Dr. Larry Roberts. He=
=20
had created Telenet and we were in competiton, under FCC license, so I=20
could not legally ally his international team. This made me to create the=
=20
Intlnet ad-hoc structure in 1978 to carry that common documentation work,=
=20
supporting Telenet and Uninet as well as every other operator (cf.=20
http://intlnet.org/eintl.htm - "history" part). As Telenet teamed with BB=
N=20
(hence, I suppose Bob Hinden was already involved?)

Today we face the same problem: who is the standardiser? Is it the design=
er=20
(IESG)? the developper (Dr. Roberts) or the user (everyone can chose)? We=
=20
face everywhere that question. As for the Tymnet network 28 years ago, th=
is=20
is the demand for a network granularity where the current Internet defaul=
ts=20
to "one": one numbering scheme, one namespace, one IANA, one ASCII script=
,=20
one English language, one IETF/IAB/IESG, one ICANN, one legacy, one State=
=20
sponsor (RFC 3869), one experience, etc.

This was not the case in the world network we known with Dr. Roberts. So,=
 I=20
fully understand and support the nature of his request and the obligation=
=20
the community has to positively respond. But I also understand the=20
principle of the IESG "bootstrap" reponse. We have to find a a way to=20
transform all these "one" into parameter able to match the values chosen =
by=20
the users. This means customising the Internet. Tymnet already had=20
responses(reliable technology, classes and groups) that Internet has not=20
yet. When in the mid-80s OSI was deployed it internationnaly deployed ove=
r=20
Tymnet and was a juxtaposition of network (X.75). So the response was=20
simple, rigid, manual (interconnect agreements), limited (CUGs) but built=
-in.

A problem is that we are very late. This is not something we can discuss=20
over the next ten years. This is something which will be definitly settle=
d=20
by December at the WSIS. We must accept that if the Internet is not broke=
n,=20
it is already split (DNS), divided (funding, policy, access to content),=20
threatened (internationalisation vs. multinationalisation), pulverised=20
(PADs: private alias directory, as many name spaces as users). I think no=
=20
one expect much of the Tunis meeting (who knows, they may be enlighted?)=20
more than a confirmation of the granularity/subsidiarity principles in=20
governance and usage. This is however revolutionnary for the Internet: it=
=20
started as a centralised experimentation, it continued as an IETF=20
standardisation documented decentralisation. It will become a user define=
d=20
distrubution. This means a user centric utilisation architecture is=20
self-imposing over a network centric (decentalised) bootstrap conducted=20
system architecture. The dispute over HBH, langtags, mail-ID, NAT, IPv6=20
etc. etc. will be peaceful stories when compared to the resulting=20
transition if it is made by force rather than IETF documented and accompa=
nied.

There may be other solutions, but I know and accept that the Internet can=
=20
address this in being urgently partitionned in a concerted way, preservin=
g=20
its end to end interoperability and extending it to person to person=20
interintelligility, in doing the same as Robert Tr=E9hin in 1977 with the=
=20
technical support of Joe Rinde. This is why we must engage into a concert=
ed=20
well thought partitionning strategy. IMHO the easiest approach is the=20
distribution of the IANA. This is the one we observed as successful in th=
e=20
late 70s and early 80s, then in a different way (printed standards, mutua=
l=20
agreements) with the rigid OSI. Centralised NIC, decentralised OSI: now w=
e=20
have to come back to a distributed approach. But we have to remember that=
=20
Tymnet and OSI were reliable technologies, while TCP/IP is an unreliable=20
one. IMHO this gives more possibilities and less stability right now. It=20
will lead to an hybrid vision of the intergovernance (co-existance of=20
trusted and non trusted spaces of exchanges) and possibly to an hybdrid=20
technology further on (for example supporting NASA/ESA type of protocols,=
=20
including FEC).

We have the experience of ICP-3 where ICANN called in vain IETF to=20
experiment (we did and learned: AFRAC and NICSO result from it). Then the=
=20
experience of the root server distribution demanded by the WSIS. It was=20
only addressed by the distribution of the content: this does not change=20
anything to the system's global vulnerability which is in content - as th=
e=20
recent AFNIC/IANA/Versign incident shows it - nor to the intelligence=20
issues. Then we have the experience of the langtags, where the IANA is=20
perceived by those opposing the current twice failed proposition, as a wa=
y=20
to impose a commercial grid of languages and a competition rather than a=20
cooperation with ISO spheres. Now, we have the HBH case.

If one analyses carefully all these issues we see that:
- stability of the network calls for a unique or concerted content in=20
registries
- when the content of the registries is different its versions must be=20
signed. We must switch from an IETF filtering to an advised and=20
possibly  multi-labelled registration.
- surety of the networks calls for speed in updates - far better than the=
=20
current IANA 3 to 6 months. I am sure there are more than 30 versions of=20
different dates IANA root files currently in use on the Internet.=20
Collectors must give back the authority of content to authors.
- security calls on correlative cross checking procedures and tools. This=
=20
starts by a standardisation of the registries and of their tools, formats=
,=20
methods of access, update, retrieval, etc. Scalability demands that this =
is=20
studied in relation with ISO 11179 work, IETF should enrich and simlify (=
as=20
LDAP vs. X.500).
- the resulting necessary intergovernance processes must be studied,=20
documented and technically supported.
- more generally, we need to switch from a philosophy of global trust to =
a=20
philosophy of global distrust with local spaces of trust, exchanges and=20
services.

All this can be more easily put together at CRC level than anywhere else,=
=20
but it must eventually consistently expand everywhere and be the basis of=
=20
the whole standardisation docntrine and model. We cannot continue to trus=
t=20
the breakers and then try to catch them. We must distrust everyone who ha=
s=20
not proven to be a friend. Do you invite home, lend your wallet and leave=
=20
your kids to everyone you meet in the street? e-life is no different from=
=20
real life.

etc.

This mail will probably be disregarded by most, opposed as a troll by som=
e.=20
Nevertheless, this is what is to happen, this is the way we should work o=
n=20
it, this what is happening. Obviously, this is a change in the meaning of=
=20
"Internet" into "International Network" where "International" is an image=
=20
of the granularity and of the diversity in shape, governance, requirement=
s,=20
modes, protocols, etc. of the world digital ecosystem digital management=20
and convergence.

I am not sure the IETF is ready for it: in addition to the architectural=20
expansion, it means for example the end of the international, multilingua=
l,=20
and vernacular layer violation permitted by the ASCII default, and=20
therefore a probable IETF nexus shift at the end of the day. But this is=20
going to happen, with or without the IETF. I hope it is with it.
jfc =20


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf