The IETF process

Shel said:

>Which leads me to a question.  It's not really clear to me how these
>proposals do or don't find their way into the specs.  Is there some
>kind of charter or statement of the mode of operation of this "group"?
>Or is it just (like me) a collection of self-selected people
>interested in these issues blabbing away, hoping to indirectly
>influence the spec writers, who make the decisions as to what goes in?
>I'm not quite complaining, I just have a somewhat queazy feeling that
>those ideas generated here that are good enough may not actually be
>picked up and used.  The part that could be improved is that there
>could be a better process for coming to decisions in an unambiguous
>way, and knowing when decisions have been taken.  I wish there were a
>little more feedback from the actual spec authors here.  Just seeking
>some clarification.

I have delayed in answering these questions because I am tired of
answering IETF process questions.  Sorry, but you can learn all about
the IETF through their web site at <http://www.ietf.cnri.ton.va.us/home.html>.

Here are *my* interpretations of the process.

IETF working groups exist to provide rigorous peer review and testing
of specifications, particularly when those specifications are intended
for eventual standards-track status.  The working group structure is not
intended to design the systems being specified, though their input is
usually considered by the designers.

As a spec author and protocol designer, I want to listen to the issues
"blabbing away" in hopes of improving future designs of the system. 
However, I am not required to put any new proposals into the design,
and must not make the specification different than what the design
actually is when the spec is finished.

When reading the spec, you (as WG members) may point out any errors or
deficiencies in the spec.  I may choose to accept them as is, tell you
to provide a more specific version, or reject them out-of-hand.
If any WG member disagrees with my decision, they should say so.  If the
disagreement is sufficient, I or the WG chair will call for consensus
on the issue.  Once rough consensus is reached, I will include in the
spec whatever change was required (if any) by the rough consensus.
If I don't [and this will never happen on purpose in my case], then
the IETF standards process includes a set of procedures for handling
conflict.

However, except for Informational RFCs, "errors or deficiencies" are
always defined by current implementations (whether they be "common practice"
or just "prototypes").  In particular, I cannot be compelled to include
anything which has never been implemented anywhere, or for which no
documentation of how it was implemented is available.  This is a
double-edged sword -- before I can say a standards-track spec is finished,
I must be sure each of the features is implemented somewhere in accord
with the specification.  This means that in order for me to accept a
proposal, even when I like it, someone must implement it and verify
that their implementation works according to their proposed change.
Henrik (libwww), my libwww-perl project, and the Apache server are
my personal sources for implementation testing.  Other features have
been implemented first by NCSA, Spyglass, Netscape, etc., and they have
provided me with testable implementation descriptions.

Also, proposed changes to the spec may be ignored if they do not include
the exact wording for the change (in practice, this is only necessary
if I refuse or forget to make the right change).  If rough consensus is
reached on something without exact changes, then I am free to interpret
the correct change.  Naturally, since it is a pain in the ass to generate
a new draft, I prefer to make the right change the first time.

This means that your "hoping to indirectly influence the spec writers"
is misplaced.  You are instead hoping to influence the implementation
writers, which will then result in changes to the specification.
When two or more implementations conflict, we will have a bake-off
to decide which specification is better for all parties, and hopefully
rough consensus will imply a better design.

Feedback from the spec authors is another issue.  I have decided to make
an informal rule in only giving feedback when the issue has first been
clarified by others.  There are three reasons for this:

   1) People on this list (and the other Application-area WGs)
      tend to "blab" a little too much and "make concrete proposals"
      too infrequently.

   2) People often interpret my opinion as being "the decision",
      which is false.  My "decision" is always and only reflected
      in a new draft, and is based on my knowledge of current
      implemenatations available at that time *and* my immediate
      perception of the WG rough consensus.  I may state my opinion
      in hope of changing (or consolidating) consensus, but that
      is different.  I may include things in each draft which are
      not yet implemented, but will remove them as soon as I think
      they won't be implemented before the spec is finished.

   3) There is just too much damn mail to read, and I'll never get
      any work done if I am always commenting on other people's
      comments.

As the author of the specification, I have the right to make changes
to the specification drafts.  As WG members, you have the right to
require changes be made to the current draft before it can be forwarded to
the IESG.  Since I eventually want it forwarded to the IESG 
(and because I believe in the IETF process and am generally a nice guy),
things will work out just fine in the end.  Naturally, the devil is
in the details.


 ....Roy T. Fielding  Department of ICS, University of California, Irvine USA
                      Visiting Scholar, MIT/LCS + World-Wide Web Consortium
                      (fielding@w3.org)                (fielding@ics.uci.edu)

Received on Wednesday, 13 September 1995 16:23:42 UTC