Re: RFC 2434 term "IESG approval" (Re: IANA Action: Assignment of an IPV6 Hop-by-hop Option)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]