Message-Id: <6.2.1.2.2.20050630141128.03f5a430@mail.jefsey.com>
Date: Thu, 30 Jun 2005 14:16:47 +0200
To: ietf@ietf.org
From: "JFC (Jefsey) Morfin" <jefsey@jefsey.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable
Subject: Re: RFC 2434 term "IESG approval" (Re: IANA Action: Assignment
 of an IPV6 Hop-by-hop Option)
Precedence: list
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Dear John,
the subject is of importance and cannot be dealt with an individual's dra=
ft=20
in Franglish. "Qui va piano va sano", "doucment, doucement nous sommes=20
press=E9s" (Talleyrand).

As a liaison to ICANN BoD you know that the criteria I quote are those=20
(reviewed by a two years experiment) of the ICANN call to the Internet=20
Community (IETF being the only one namely quoted) for experimentation, as=
=20
the necessary element for Internet innovation. IETF has never wanted to=20
consider the call (ICP-3 Part 5) because this is not its charter, and I=20
believe this is true.

On 09:05 30/06/2005, John C Klensin said:
>Jefsey,
>Many of us await, with great interest, the appearance of an
>Internet Draft from you that explains how, with a field with a
>finite (and fairly small) number of bits available, once can
>carry out an arbitrary number of properly-identified
>experiments.  Even a discussion about how one might make an
>allocation reversible --in terms of recovering or slicing up
>bits that carry, well, only one bit of information-- within a
>non-private network or enforce the end of an experiment so that
>another could begin would be extremely interesting.

As you put up yourself the problem is not with the need but with the=20
technology to answer it. The first problem is to identify the way to=20
describe the needs to experiment. Then how to translate them into technic=
al=20
specifications. Then to find the solution. Then how to carry the=20
experimentation and report on it. Then to qualify the results and update=20
the current documentation and train the users.

>Of course, one might argue that protocols should contain,
>instead of fixed-width option fields, fields of arbitrary
>variable lengths, thereby eliminating the difficulties implied
>above.

This is a very particular detail. The first thing is to identify that the=
=20
need is accepted as a priority. The same as for security. Security protec=
ts=20
the current internet, experimentation protects the future of the internet=
.=20
I will comment this at the end. It will be clearer.

>  If that is the model you would like to propose, the
>Internet Draft that explains how to do it without significantly
>reducing the performance of IP would be of even more interest
>(several previous proposals in that area have required faster
>light, which no one has yet managed to arrange).

The response probably lies in at least three changes.
- an ad-experimendam section in RFCs to explain if and how the documented=
=20
protocol is subject to experimentation
- a considerable change in the Internet standard process culture: that th=
e=20
IETF final deliverables are no more the RFCs but an updated Internet=20
Docummentation Book. A Gentoo like approach.
- a major change in the Internet structure I already discussed which is a=
=20
granular, extended and customisable distributed IANA: the Common Referenc=
e=20
Centers I documented last week. This will be helped by the urgency of a=20
response to PADs (Private Alias Directory) the day they start.

>But, either way, please put it into an Internet Draft that we
>can study and, if necessary reference and preserve, rather than
>continuing with email.

These are important things. They call for serious mutual reviews. For=20
example your Draft on IANA is important to work on and ponder. Brian said=
=20
he had something in the oven too. They also must be introduced in a way=20
they can politically be supported. Hence my priority to answer Brian's=20
remarks about liaising with ccTLDs.

>The posting deadline is a week from next Monday.

You may have observed that lately I have been busy avoiding that a=20
detrimental to all Layer-8/9 Draft could be submitted by that date and ha=
rm=20
an ISO process which can significantly help us all. All this is tied. We=20
need a major change in the Internet. However it will not come as a=20
revolution, but as an evolution. I do not think it can come from the IETF=
=20
but it needs to come through it.

Now, to address the principle of your question. I do not think that=20
existing protocols or even that further protocols should necessarily=20
include an experimentation field. There are many other ways to organise=20
experimentation (we experimented that for two years, with some falls back=
).=20
This is, as most of what is demanded today, difficult in a non partitionn=
ed=20
internet. But the risk is that a wrong partitioning results from=20
uncordinated governmental or grassroots processes leading to balkanisatio=
n=20
or pulverisation. This would result into a dominance reaction to stabilis=
e=20
the network, itself opposed. In other words, once an experimentation=20
possibility has been identified as a priority, the question is the  test=20
bed. In the test bed the first thing to test will be a coordinated=20
partitionning system - which will also concerns risks containments,=20
regalian services demands, cultural empowerment, community support, kids=20
protection, etc.

I will finish with an example. In your draft you constantly speak of=20
registries "namespaces". Why "namespace" (non multilingual, problem of=20
script, lack of scalability etc.) for what should be "codespace"? Code=20
spaces are much more versatile to experimentation. Another example is a=20
serious work on hexatridecimal support as a possible way-out to address=20
ASCII strings in new environments. Another is ISO 11179 to explore and=20
understand if some aspects can be simulated (you take a model as data and=
=20
decrease the complexity by one order of magnitude? Is it possible, of=20
significant interest? I am an "I don't know" person with many "I know=20
better" people around). An important issue to consider is to understand=20
where the CRC concept fits when compared with Databases, XML and LDAP, an=
d=20
the shuttle protocol they need, the local respository they can support.

All this cannot be documented in a Franglish draft. But I think it can be=
=20
documented through multinational/multicultural experimentation benefittin=
g=20
from the equal lingustic opportunty declaration we circulate. Because the=
y=20
started from one Internet in 69, acknowledged and supported 250 local=20
Intenet communities in 84, face 20.000 languages in 2005. This is a good=20
experimentation path towards a 7 billion small/standalone networks/home=20
networks. Adding a few test-beds should not be a problem, but is a=20
significant and slow task at human scale. But I think worth it. Hence my=20
disapproval of those further delaying the process.

jfc

NB. I worked two months on a Draft on a Multilingual Internet last summer=
.=20
This has been delayed by others....

>--On Thursday, 30 June, 2005 00:43 +0200 "JFC (Jefsey) Morfin"
><jefsey@jefsey.com> wrote:
>
> > Dear Scott,
> > RFCs are made to be adapted to needs. The question should be
> > "what do we want?". I think the response is "to experiment".
> > This means that every registry should include an
> > ad-experimendam area. If the experimentation is OK it will
> > permit to document the allocation of a code point without
> > interrupting the experimentation. If the experimenation fails,
> > then who cares? 200 mails on "IESG approval" saved each time.
> >
> > The main characteristics of an experimentation should be:
> > community oriented (not private), reversible, not affecting
> > non participants operations, no acquired rights without
> > community approval, limited scope in time and space.
> > Documentation is of no interest until it succeeds. This should
> > not be confused with a private area: private usage is to be
> > protected/separated from experimentation.
> > jfc
> >
> >
> > At 00:03 30/06/2005, Scott Bradner wrote:
> >> > I agree that this would be a reasonable process, but
> >> > wouldn't that be "IETF Consensus" (an entirely separate
> >> > choice in RFC 2434 from IESG Approval)?
> >
> >
> > _______________________________________________
> > Ietf mailing list
> > Ietf@ietf.org
> > https://www1.ietf.org/mailman/listinfo/ietf


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf