ietf
[Top] [All Lists]

Re: Idea for a process experiment to reward running code...

2012-12-01 16:22:29
[1] http://tools.ietf.org/id/draft-farrell-ft

I have a serious problem with the premise of the proposal.

The short version is that if the process we're talking about is
useful, we should not shortcut it as a "reward" for anything.  And if
it's not useful, we should not be doing it, regardless of whether we
want to provide incentives or not.

In particular:

   1.  Working group last call (WGLC), IETF last call (IETF-LC) and Area
       Director (AD) review all run in parallel over the same two-week
       period.

Note that WGLC is not a part of our formal process, and that AD
Evaluation can take as little time as it takes for the responsible AD
to click the "Go directly to Last Call Requested" button in the
datatracker.  Therefore, making this step happen today is entirely up
to the working group chairs and the responsible AD.  Any chair who
thinks that a document has had enough review in the WG already can
send the document to the AD directly.  That chair can also ask the AD
to expedite her review and get Last Call started ASAP, and it's up to
the AD to decide whether that's appropriate.  We don't need a process
experiment for that.

That said, AD Evaluation often (VERY often) turns up things that would
otherwise come up in Last Call comments, including in directorate and
review team reviews.  It often corrects problems or gaps in the
protocol specification, issues with IANA requests, security issues,
and so on... which would take up a lot of other people's time as the
Last Call review goes on.  An AD who has been following the document
already might be happy going directly to Last Call Requested with just
a quick glance at the document (as I have with some documents), but
might have extensive comments about other documents, regardless of
whether there are implementations or not.

Kicking off Last Call is something that requires AD judgment, not some
sort of "reward" system.

   2.  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.

I'm puzzled by this.  First, a lot of things fall under the DISCUSS
criteria, but ADs decide not to give them DISCUSS status, depending
upon the situation.  I guess in item 3 you cover who decides this, but
as it's specified here it seems entirely too fluffy.  And it appears
to devalue the non-blocking comments more than they already are.
Again, if our process of making comments *of all sorts* has value,
then we shouldn't short-cut it.  It's already the case that the
responsible AD and the IESG as a whole get to decide which Last Call
comments "need to be handled" and which don't, so this really isn't a
process change either.  But I wouldn't want to say outright that
last-call comments that don't meet DISCUSS criterial will likely be
ignored in some "fast path" process that "rewards" a protocol for
having implementations.

   3.  After fast-track last-call, the document must either be returned
       to the WG, or else enter IESG review as soon as any changes
       required are made.  The relevant AD makes the decision as to
       whether changes are required and when those are completed
       sufficiently to move to the next stage.

This is no different to what we normally do: after Last Call ends, the
document goes into "Waiting for AD Go-Ahead" state, and the
responsible AD decides whether it's ready for IESG Evaluation or not.

I very strongly dislike the idea of saying that we'll "reward"
something by trimming (by a mere two or three weeks; what real value
does that have?) a process that we consider as adding value to our
documents.  And, again, if we think it doesn't add value, then let's
just do this as standard procedure, as we already can today, with no
process experiment at all.

Just tell all your WGCs that they can skip WGLC, and you'll send their
docs straight into Last Call as soon as you get them.

Barry

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