Sigh.
These multiple threads are, IMO, a wonderful exposition of how
the IETF can waste a tremendous amount of collective time and
energy fine-tuning a document and/or procedures by a very large
committee. If nothing else, the process often leads to victory
by exhaustion as people just give up, leaving the discussion who
have the energy (or, as a colleague would put it, "too much time
on their hands". I plead somewhat guilty for getting sucked
back in, but I want to make a few suggestions:
(1) Can we figure out a way to converge on whether we are
editing an RFC-to-be by committee or planning something web-ish
(not distinguishing between "web page" and "wiki" for the
moment? If the former, then there are several irrelevant
threads. If the latter, then there are a lot of useful comments
that should be handled in a different way.
(2) At one time, one of the key differences between the IETF and
other bodies in more or less the same business was that we
allowed ourselves considerable flexibility to match how we did
things to the situation and our needs while those other bodies
had to spend huge amounts of energy getting agreement on the
exact way that something should be done before attempting to do
it. If we are going down the "web-ish" path and haven't lost
that sense of flexibility entirely, I would like to recommend
that we perform a "let's try this, see how it works, and then
work out specific procedures for the future" experimental
engineering process rather than trying to get the details right
by committee. In particular, I suggest that, for the initial
round of turning the current I-D into something web-ish and
establishing a model for handling suggestions and changes, we:
Ii) We appoint an Editor (or Editor-in-chief).
(ii) Based on precedent, history, a much-better-than-decent job,
authorship of the I-D, and an orderly transition from one
publication model to the other, we should appoint Paul by
acclamation. By that I mean that someone, ideally Russ, gets on
the list and says "is there really any objection to appointing
Paul... if not, done". That skips, for the present, wasting
more time figuring out who makes the appointment, whose approval
is needed, whether we need a whole process (e.g., of volunteers,
lists and comments) similar to how we handle IAOC and ISOC BoT
appointments, and a whole series of other ways in which we could
waste a lot of time and then get the same result.
(iii) Let's give the Editor six or nine months of discretion and
experimental time about formats (let's at least start with a
controlled list of people who can make changes until we have a
document in place and a bit of experience -- I see no
substantive difference between a controlled-authorship Wiki and
a controlled-authorship web page other than the tools used
although we could spend lots of time debating the
non-substantive differences), editorial board composition, how
to solicit and receive input, etc. We encourage the editor to
consult with the IESG to the extent to which the IESG (or some
IESG-chosen subcommittee) is inclined to be involved.
(iv) At the end of that period, we see if we can find an
efficient way to examine the experience, draw ideas together,
and figure out what we really want to do for the long term and
what procedures are needed to do it. I think I just said "BOF
in Atlanta or Orlando" rather than "mail storm on the IETF
list", but, if we need to do a mail storm, let's at least have
some experience and a web-based document on which to focus,
rather than trying to have editorial, procedural,
organizational, and format suggestions all mixed up with each
other.
If we all really have this many spare cycles, perhaps many of
them would be better spent getting the document (page, wiki,...)
right rather than tuning procedures. Perhaps some of them might
even be better invested in protocol specification. And, on
that note, I'm going to go try to spend a little time on a
neglected WG.
best,
john