Re: RFC 2434 term "IESG approval" (Re: IANA Action: Assignment of an IPV

Dear John,
the subject is of importance and cannot be dealt with an individual's draft 
in Franglish. "Qui va piano va sano", "doucment, doucement nous sommes 
pressés" (Talleyrand).
As a liaison to ICANN BoD you know that the criteria I quote are those 
(reviewed by a two years experiment) of the ICANN call to the Internet 
Community (IETF being the only one namely quoted) for experimentation, as 
the necessary element for Internet innovation. IETF has never wanted to 
consider the call (ICP-3 Part 5) because this is not its charter, and I 
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 
technology to answer it. The first problem is to identify the way to 
describe the needs to experiment. Then how to translate them into technical 
specifications. Then to find the solution. Then how to carry the 
experimentation and report on it. Then to qualify the results and update 
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 
need is accepted as a priority. The same as for security. Security protects 
the current internet, experimentation protects the future of the internet. 
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 
protocol is subject to experimentation
- a considerable change in the Internet standard process culture: that the 
IETF final deliverables are no more the RFCs but an updated Internet 
Docummentation Book. A Gentoo like approach.
- a major change in the Internet structure I already discussed which is a 
granular, extended and customisable distributed IANA: the Common Reference 
Centers I documented last week. This will be helped by the urgency of a 
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 
example your Draft on IANA is important to work on and ponder. Brian said 
he had something in the oven too. They also must be introduced in a way 
they can politically be supported. Hence my priority to answer Brian's 
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 
detrimental to all Layer-8/9 Draft could be submitted by that date and harm 
an ISO process which can significantly help us all. All this is tied. We 
need a major change in the Internet. However it will not come as a 
revolution, but as an evolution. I do not think it can come from the IETF 
but it needs to come through it.
Now, to address the principle of your question. I do not think that 
existing protocols or even that further protocols should necessarily 
include an experimentation field. There are many other ways to organise 
experimentation (we experimented that for two years, with some falls back). 
This is, as most of what is demanded today, difficult in a non partitionned 
internet. But the risk is that a wrong partitioning results from 
uncordinated governmental or grassroots processes leading to balkanisation 
or pulverisation. This would result into a dominance reaction to stabilise 
the network, itself opposed. In other words, once an experimentation 
possibility has been identified as a priority, the question is the  test 
bed. In the test bed the first thing to test will be a coordinated 
partitionning system - which will also concerns risks containments, 
regalian services demands, cultural empowerment, community support, kids 
protection, etc.
I will finish with an example. In your draft you constantly speak of 
registries "namespaces". Why "namespace" (non multilingual, problem of 
script, lack of scalability etc.) for what should be "codespace"? Code 
spaces are much more versatile to experimentation. Another example is a 
serious work on hexatridecimal support as a possible way-out to address 
ASCII strings in new environments. Another is ISO 11179 to explore and 
understand if some aspects can be simulated (you take a model as data and 
decrease the complexity by one order of magnitude? Is it possible, of 
significant interest? I am an "I don't know" person with many "I know 
better" people around). An important issue to consider is to understand 
where the CRC concept fits when compared with Databases, XML and LDAP, and 
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 
documented through multinational/multicultural experimentation benefitting 
from the equal lingustic opportunty declaration we circulate. Because they 
started from one Internet in 69, acknowledged and supported 250 local 
Intenet communities in 84, face 20.000 languages in 2005. This is a good 
experimentation path towards a 7 billion small/standalone networks/home 
networks. Adding a few test-beds should not be a problem, but is a 
significant and slow task at human scale. But I think worth it. Hence my 
disapproval of those further delaying the process.
jfc

NB. I worked two months on a Draft on a Multilingual Internet last summer. 
This has been delayed by others....
> --On Thursday, 30 June, 2005 00:43 +0200 "JFC (Jefsey) Morfin"
> <jefsey(_at_)jefsey(_dot_)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(_at_)ietf(_dot_)org
> > https://www1.ietf.org/mailman/listinfo/ietf

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf