ietf
[Top] [All Lists]

Re: Last Call: <draft-farrell-ft-03.txt> (A Fast-Track way to RFC with Running Code) to Experimental RFC

2013-01-14 07:06:06
The IESG <iesg-secretary(_at_)ietf(_dot_)org> wrote:

The IESG has received a request from an individual submitter to consider
the following document:
- 'A Fast-Track way to RFC with Running Code'
  <draft-farrell-ft-03.txt> as Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.

   I'm pretty darn uncomfortable _ever_ picking a fight with any
sitting AD, But I feel obligated to say this seems like a terrible
idea to me.

   As a background, I'm a long-time believer in "rough consensus" for
Proposed Standard and "running code" for advancement along the
standards track. I do not believe the two mix well.

   A standard needs to be as simple as possible (but no simpler);
running code needs to be complex.

   Stephen Farrell wants to "speed up" our process by adding an
incentive for "having" running code. Specifically:
] 
] This memo describes a way to fast-track some final stage reviews for
] a working group draft when the working group management and area
] directors believe that the existence of one or more implementations
] serve as a practical review of the engineering choices made by the
] working group.

   Actually, now that I read that carefully, it doesn't even need to be
"running" code. :^(

] This experiment needs an implementation that matches the specification
] contained in the draft.

   (Verifying that has proven to be surprisingly hard. One guesses
that the "match" may not be rigidly enforced...)

   Understand, IMHO there is much to be gained by testing the
interoperability of independent implementations of a specification;
but that is a long-winded process, hardly anything which could be
done during the "fast-track" Stephen is proposing.

] It is up to the WG chairs and responsible AD to satisfy themselves
] on this point within the normal bounds of trust

   "Normal bounds of trust" isn't particularly compatible with our
paradigm of transparency of process...

   I don't even think it means the same thing to the rather limited
set of people named here.

] and without any implication about the licensing related to an
] open- or closed-source implementation.

   Any mention of licensing seems out of place here.

] Note that the existence of an implementation is not sufficient to
] ensure that the draft will automatically pass working group or IETF
] last call, nor that it will receive IESG approval.

   Nor should it be, of course...

   Getting to the devil-in-the-details:
] 
] 1. Any Working Group Last Call (WGLC) or Area Director (AD) review
]    ... will run in parallel with the two-week IETF Last Call

] 2. The IETF last call announcement message must say that the draft
]    in question is following the fast-track process...

] 3. The draft itself should note (e.g. in the introduction) that it
]    has been fast-track processed and reference this RFC.

] 4. Only comments that would be "DISCUSS-worthy" according to the
]    IESG Discuss Criteria [DCRIT] need be handled during last call.
]    Other comments can be handled or not, at the authors/editors
]    discretion.

   This is actually normal for IETF-wide LastCall (though it leads
to raised tempers when seemingly valid comments are ignored).

   It is not normal for WG LastCall; nor is it even compatible with
"rough consensus" -- by which we mean that any new questions raised
have been considered to the satisfaction of a substantial majority
of the participants.

] 5. The responsible AD for the WG concerned makes the decision as to
]    whether changes are required as a result of review comments, and
]    determines whether or not those have been completed.  If
]    significant change or extended discussion is required, or if
]    changes are not complete within two weeks after the end of fast-
]    track last call, then the draft is returned to the WG by the
]    responsible AD and the document is withdrawn from the experiment.

   This is not an easy read. :^(

   First, it centralizes the decision in one person (whereas normal
WGLC process has two or more WG Chairs judging consensus of the group).

   Second, it centralizes the decision in one person whether changes
in the document properly address any WG or IETF-wide comments. This
kind-of matches current practice in the IESG for Area Director
comments; but does not match the theory -- and we could on very short
notice regress from the level of trust which allows this to happen
now.

   Third, the two-week drop-dead time limit is unworkable. Not just
IMHO; in practice it hardly ever happens that everything resolves
itself that quickly. AD DISCUSS comments tend to bunch up in the
hours before the telechat, and frequently need to be clarified
_after_ the telechat.

   Fourth, it's not really clear what happens after "the document is
withdrawn from the experiment." It would appear at first blush that
it must now start a separate WGLC, followed by a new IETF LastCall.
I would never consent to this process for a document _I_ cared about.

] 6. As soon as the responsible AD has confirmed that the authors/
]    editors have made any changes required as a result of fast-track
]    last-call, then the document should enter IESG review and be
]    placed on the next IESG telechat agenda that is more than one
]    week in the future.

   Oh... Stephen wasn't talking about the IESG process at all!

   I'm even more confused now.

   I guess this means that one person (the responsible AD) takes a
look at any and all comments during the "combined" LastCall and
responsible-AD-review and makes a unilateral decision of what
changes the authors/editors should make (on short notice); then
things open for IESG-member DISCUSS comments.

   This would seem to preclude the current practice of putting
drafts on the IESG agenda _before_ the end of IETF LastCall. I'm
only getting more confused as to how this speeds up our process.

] 7. Given the reduced time associated with fast-track processing, the
]    responsible AD may not have time to carry out sufficient review
]    prior to IESG evaluation to be confident in balloting "Yes" for
]    the document.  Draft progression during and after IESG review is
]    otherwise unaffected, so a "Yes" ballot is needed from some AD.

   I _do_ understand that part, thought it's a bit obscure to those
who haven't been IESG members: no document gets approved by the
IESG without at least one "Yes" ballot-position; and Stephen wants
to be able to decline to ballot "Yes" on a document he (as
responsible-AD) has almost unilaterally re-written. (This would
be a really-bad idea, IMHO.)

] 8. If at any point in the fast-track process the responsbile AD does
]    not act in a timely fashion then the IESG Secretary should ensure
]    that the draft enters IESG evaluation and is scheduled for the
]    the soonest IESG telechat that is more than one week after the
]    end of the two-week post-IETF LC period.  That is, if the
]    responsible AD does not act, then the default action applies
]    which is that the draft enters IESG evaluation and is placed on
]    the earliest IESG telechat.

   (This is too complicated for me to try to explain in this email.)

====

   There's a lot more I could review, but I won't in this post.

   Were I an AD responsible to ballot on this, I'd ballot "abstain".
"Abstain" means "There's no point trying to satisfy me," and is
the way an IESG member essentially votes "No."

   I don't believe "running code" is even particularly helpful in
run-of-the-mill Proposed Standards. I've seen it _seriously_ harm
the documents in cases where the "running code" has shipped and
there is reticence to change it: no matter how many weaknesses are
pointed out, you can't get WG consensus to change the spec.

   In cases where "running code" has proven helpful, it's my
honest opinion that the spec has become way too complicated (and
thus the "running code" has proven which parts are unworkable).

   I don't believe it's possible to "fast-track" "runnng code";
nor do I believe it would be desirable were it possible. Code
needs to deal with complex cases that, for the most part, don't
need to be standardized in the first place. But code which
doesn't deal with these is useless in the marketplace.

   IMHO, we designed a separate "Proposed Standard" step to get
a specification published quickly without delving into the many
questions that arise when writing actual code. There are plenty
of Standards-Development Organizations that start from "code".
We don't need to become one of them.

--
John Leslie <john(_at_)jlc(_dot_)net>

<Prev in Thread] Current Thread [Next in Thread>