I suspect that any approach that was chosen was the result of negotiations and discussions among those who took part in the discussion at that time. Any solution would raise questions in a societal setting, since unanimity is not the norm in a democratic process. The RFC process has extended so deep and so far that change may be difficult, though not impossible.
You are right and Fred's and John's comments below show it. The RFC system is part of the legacy technology, is defined by an RFC and will die with TCP/IP, or kill it.
Is this a reason to come back and stay in 1983 (I would then chose another technology :-). The same reasons are given here as to keep the DNS as it is: 800.000 nameservers out there - yet IDNA came. The same reason as about LHS, yet John wants to go ahead. Experience does not mean fossilization.
At 21:02 09/01/04, Fred Baker wrote:
May I suggest you become familiar with the IETF process before commenting on it? The RFCs on the standards track are generally field tested before deployment at Proposed Standard, and the various standardization levels specifically address the issue you raise.
Read RFC 2026.
Unnecessary comment. "generally field tested" is not a QA definition of what I call serious experimentation and not of what I call global user approbation. Even a braod user acceptance is not the proof of valid proposition. The current e-mail is universally accepted but it is not a good solution as spam shows it every day.
I spent time enough on a DNS experimentation test bed project these past two tyears to know that real life technical, societal and governantal experimentation is a concept foreign to the internet community.
At 21:45 08/01/04, John C Klensin wrote:But we do things in a particular way that mostly works (although it should probably be more effectively and accessibly documented), and, while we might tune things differently or use different terminology if we were starting over today, what purpose would it serve to develop redundant mechanisms that would require extra volunteer or staff effort to make work and keep working and that would leave people uncertain as to where to go for information? And what purpose is served by proposing such an action?
Let just consider the standard path, not the reducing exceptions. The RFC system suffers from being mainly a mental exercise between two realities it does not relate very well with (the demand and the operational supply). When I rise the question "what to do to restore a situation where RFC are not respested" the only response I get is "stick to the RFC". When someone says "I have two hours to work I want to know the IETF state of art/mind on a matter", the response is "spend months reading every elucubration in a old WG mailing list".
Up to now users are absent in the IAB/IETF process. Operations, R&D, deployement etc. calls for more. I did not say a change.
On 16:13 09/01/04, Valdis.Kletnieks@xxxxxx said:
On Fri, 09 Jan 2004 07:03:19 +0100, jfcm said: > is validated. A market standard is the desciption of what works and is > adopted. We might find this way a fortunate compromise?
Unfortunately, "market standards" often include borken things that are adopted via forced-feeding. More than one vendor has done this, and some research would probably find at least one example at each of the 7 OSI layers.
True. This is why I talk of compromise. To take the beast from both.
What I see is that WGs lack serious market/user demand studies. They replace that with their own evaluation of their reasonable proposition. This permits evolution, not innovation, no break through.
IMHO, there should be two documents/prcess added to an RFC (not replacing it):
1. Up stream: a Users Needs Summary. Including what WG may propose, market studies, visionnaries suggestions, etc.
2. down he stream: a List of Comments by authors, implementers,users; etc. The LOC will comment how the RFC addresses the UNS.
The authors/mainteners of such documents should be professionals. There are tools to help.
Closing a WG maens that the RFC porcess is closed. This is whan RFC support is to take over.
jfc