A Model for IETF Process Experiments
draft-klensin-process-july14-02

Discussion of the IESG's proposed RFC Editor note on the solutions@alvestrand.no mailing list produced a clear view that getting the abstract to say the right thing is HARD.

I have changed the RFC Editor's note to suggest an abstract suggested by John Klensin as a grammatical cleanup of the original version.

[Ballot comment]
>    an ongoing basis, rather that replacing those tools with a single

s/that/than/

>    We note that, if the procedures the IESG has adopted (and procedural
>    exceptions it has made) over the last decade are legitimate, then the
>    IESG has the authority to institute the changes proposed here by
>    bootstrapping the proposed process.

Don't understand what this comment is trying to say. Is it even needed?

References need splitting.

[Ballot comment]
Does anyone else have a sense that the following text is unnecessary?

  We note that, if the procedures the IESG has adopted (and procedural
  exceptions it has made) over the last decade are legitimate, then the
  IESG has the authority to institute the changes proposed here by
  bootstrapping the proposed process.

If the community by a BCP has put the July 14 process into place (we're approving,
but the community supported the Last Call), why does
the bootstrapping authority and the IESG's past have to be invoked?  This "if"
hanging over the process may relate to a later challenge.

[Ballot comment]
Delete "(if it is adopted)" from the text in Section 1.

  I find the Abstract difficult to comprehend.  I propose an alternative:

    The IETF has designed process changes over the last ten years in one
    of two ways: announcement by the IESG and working group consensus.
    IESG announcements are sometimes based on informal agreements with
    limited community involvement and awareness.  Working groups use the
    same formal mechanism as is used for protocol specification. IESG
    announcements have often proven to be too lightweight, and the
    working group consensus process too heavyweight. There is a middle
    ground.

    This document proposes a middle-ground approach to the system of
    making changes to IETF process, one that employs three steps.  First,
    propose and carry out an experiment.  Second, evaluate the experiment.
    Finally, establish permanent procedures based on operational experience.

[Ballot comment]
I note that the sunset period is set at the beginning, and I don't see any easy way to revise
it, short of publishing a new document.  As we work through this, I think it would be
useful to keep an eye for situations where this was a problem; it may be that there are
none, and it may be that folks are overly optimistic about the amount of time it takes
to try something out.

I note, for example, that we have had a number of recent turnovers in IESG membership
out of normal nomcom cycles.  In a situation where that occurred again and there were
ongoing process experiments, updates to either the experiments or the deadlines
might be in order.  If it is only the latter, revving the document seems heavyweight.