Killing old/slow groups - transition thinking

John C Klensin john-ietf@jck.com
Wed, 11 Dec 2002 16:42:00 -0500


--On Wednesday, 11 December, 2002 10:33 -0500 Scott Bradner
<sob@harvard.edu> wrote:

>> Perhaps we could have a light-weight review/approval process
>> for PS
> 
> a factor to take into account - most of the Internet runs on
> proposed stds not all that many people bother to move
> documents along the standards process after they have been
> proven successful in the market, there is just not enough
> return on investment in doing the work

Scott, Margaret, and others,

It seems to me that there are interactions with this, with the
three-step model and its justification, and with the
expectations we set.  I don't know that this is something I'd
recommend --think of it more as thought exercise than as a
proposal-- but suppose we adopted a lighter weight review
process for PS.  In doing so, we made it very clear to the
community (and vendors, etc.) that, while we would _document_
known loose ends and exercise reasonable care to avoid putting
things out that would cause serious damage, we rather expected
PS documents to have bugs, incomplete sections, and things that
could not be implemented interoperably from the spec.  I.e., no
sane company would ship product based on a PS document.  That
is, of course, fairly close to our official position, but it
certainly is not how we have been behaving.

If Marshall, Geoff, et al believe that almost all WGs should be
able to get PS documents out in 18 months under our current
models, these lighter weight PS efforts should be good for no
more than 12.  For example, I'd assume we would have no
repetitive document massaging or nit-picking beyond that needed
to get clarity for people of good intent and understanding of
where we did and did not have agreement.

Then, the moment that one of these PS documents clears the IESG
and at least one implementation exists (or is public and well
underway), we start work on Draft.  Draft would have exactly the
requirements outlined in 2026 wrt passage of time and
implementation quality, but most of the document-refinement,
loose-ends-tying, nit picking about fine points of specification
and presentation, etc., would occur between PS and Draft, not
before PS.

If implementation experience and a few months thought indicated
that the thing was useless, stupid, or unimplementable, it goes
to historic and does so quickly (again, fairly consistent with
what the procedures say, but not what we do in practice).
Recycling at PS for things that clearly need another loop would,
of course, be possible. but we would expect to permit a _lot_ of
refinement between PS and Draft.

If one thinks that there is a continuum between Experimental,
Proposed, and Draft (for untried ideas, there is supposed to be,
but we mostly use I-Ds in lieu of Experimental), this notion
would move Proposed closer to Experimental, while now it is
closer to Draft.

Now, would the portions of the Internet that runs on Proposed
adjust expectations and start looking to Draft as a base for
implementations that would be broadly deployed to users who are
intolerant of change and who insist on version-to-version
compatibility?   I don't know, but I think it might be worth
thinking about when we ask questions about PS and the
three-level model.

Of course, the key to doing this would be deep commitment to it
among IESG members and, to some extent, by the RFC Editor: any
significant nit-picking or insistence on document polishing
would kill the whole idea.

    john

p.s. I'd anticipate we would want to rename levels (just to make
it extra-clear that something different was going on) and look
carefully at whether we wanted/needed full standard for anything
but mandatory protocols if we did this.