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@xxxxxxxxxx> 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@xxxxxxxx
> https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf