It is still unclear to me what the proposed course of action is.
The current situation is not acceptable. HTTP is by any rational definition a
standard. Yet according to the process document it is merely a draft standard.
I therefore declare the process document to be a silly thing which is clearly
at odds with reality and is being ignored.
There are only two paths forward that I consider sustainable
1) The IESG catches up on the backlog of declaring draft standards to be
standards.
2) The IESG proposes a process for doing this.
At present the IESG is approving an average of less than one protocol a year as
a standard. And of the recent choices only the URI spec is of first rank
significance.
At the moment the IESG is simultaneously failing to do its function under the
present process and refusing to allow its function to be changed under a new
process.
Empirically we have a two stage process. The fact that IP over NetBios is a
'standard' and HTTP 1.1 is not demonstrates the lack of a correlation between
the standards status and the deployment status.
If you look at what is actually accepted as a standard it is quite interesting.
Most are protocols that are functionally obsolete such as IP over OSI, or
irrelevant (Echo, chargen, quote of the day. FTP, Telnet). FTP and Telnet both
lack an acceptable security layer and should be considered HISTORIC.
The obsolete version of SMTP is considered 'standard'.
-----Original Message-----
From: Brian E Carpenter [mailto:brc(_at_)zurich(_dot_)ibm(_dot_)com]
Sent: Friday, August 25, 2006 7:17 AM
To: IETF discussion list
Subject: [Fwd: IETF Process discussions - next steps]
I was quite surprised to discover that this message is not in
the mailing list archive, so I am repeating it.
A copy certainly reached the newtrk WG prior to its closure.
-------- Original Message --------
Subject: IETF Process discussions - next steps
Date: Thu, 10 Aug 2006 11:41:47 +0200
From: Brian E Carpenter <brc(_at_)zurich(_dot_)ibm(_dot_)com>
Organization: IBM
To: IETF discussion list <ietf(_at_)ietf(_dot_)org>
Here are my conclusions from the plenary discussion and the
General Area open meeting at IETF 66.
1. Conclusions from plenary discussion on Newtrk issues
(draft-carpenter-newtrk-questions-00.txt)
A clear theme in the plenary discussion in Montreal was
"declare victory."
Unfortunately, in reading the notes and listening to the
audio recording, and reading subsequent emails, it is also
clear that different speakers meant different things by this
phrase - anywhere from clarifying today's standards track,
through reducing it to two or one stages, to simply sitting
down and shutting up. Although on the order of 40 people out
of several hundred in the plenary appeared to believe that
formal changes to the standards process should be made, and
some people are ready to do work (thanks!) there was no firm
consensus for a given direction (as there never has been in
the Newtrk WG).
One useful observation was that there is nothing in present
rules and procedures to prevent the writing and publication
of overview standards documents ("ISDs" in Newtrk parlance),
as long as they fit into RFC 2026 rules as Applicability Statements.
A need was observed for lightweight documentation of the real
world deployment status of individual standards, as concrete
feedback from running code. Again, no rule prevents this
today, but neither do we have guidelines as to the format,
status and indexing of such documents.
My conclusions are that:
1.1. There is insufficient pressure and energy in the
community to justify the effort of reaching consensus on
formal changes to the standards process at this time.
1.2. For complex standards where a normative or informative
overview document would be beneficial, nothing in today's
rules and procedures prevents interested parties from writing
and submitting such documents within the rules set by RFC
2026, and such efforts should be welcomed.
1.3. The community should be encouraged to produce
documentation of deployment and interoperability of
individual IETF standards, even if there is no proposal to
advance them on the standards track.
Such documents should be directed towards efforts to update
IETF standards and/or to document errata and operational issues.
A more systematic framework than today's implementation
reports would be beneficial.
1.4. The newtrk WG should be closed.
2. Conclusion from GenArea mini-BOF on IESG structure and charter.
It seemed clear in the room that people felt there was not a
serious enough problem with RFC 3710 to justify a significant effort.
There was some support for undertaking at least the first step:
* List Tasks that Currently Gate on the IESG in order to
document whether there is in fact a problem worth solving.
My conclusion is to ask John Leslie to lead a small team to
carry out this very specific task for the information of the
community.
3. Conclusion from GenArea mini-BOF on WG Procedures (RFC 2418)
It seems there is some feeling that the RFC is beginning to
show its age, and would be worth updating.
My conclusion is that the best first step is to ask Margaret
Wasserman to lead a small team to survey participants and
build a list of issues that need updating. Of course, any
actual update to RFC 2418 would then have to follow normal
IETF consensus process.
3. Conclusion from GenArea mini-BOF on mailing list
management procedures.
(draft-galvin-maillists-00.txt)
It seems clear from recent experience with RFC 3683 that
something needs to happen in this area and that feelings run
deep on this issue.
However, the energy to work on this in the community is
limited despite some support in the mini-BOF for doing so.
My conclusion is, as experiments under
draft-hartman-mailinglist-experiment
are possible immediately, there is no urgency to start an
organized effort right now - but it should be considered over
the coming months. Meanhwile I would like to ask Jim Galvin
to update his draft according to the discussion, for future reference.
A suggestion was made during the meeting to rapidly declare
RFC 3683 obsolete.
Brian Carpenter
General Area Director
_______________________________________________
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