At 02:30 10/01/04, Wawa Ngenge wrote:
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(_dot_)Kletnieks(_at_)vt(_dot_)edu 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