3-stage std model [Re: Killing old/slow groups - transition thinking]

[Pekka Savola]

It seems to me that we may need to try to make Experimental mentally a 
part of the 3-stage model.

The difference betweeen Exp and PS seems big enough to warrant folks 
pushing out Exp documents (instead of them sitting as I-D's) to revisit 
them -- relatively soon, less than a year after first publication.

On Wed, 11 Dec 2002, Scott Bradner wrote:
> I'm generally in favor of this
> but when I've made teh argument in the iesg that 'this is only a PS'
> I do not generally get much support, maybe because of the fact that
> so few things move up teh process -
> 
> I do like teh multi-stage process & think it has served the IETF well
> over teh years buit may need a kick to make it work
> 
> Scott
> 
> ---
> >From john-ietf@jck.com  Wed Dec 11 16:40:42 2002
> Date: Wed, 11 Dec 2002 16:42:00 -0500
> From: John C Klensin <john-ietf@jck.com>
> To: Scott Bradner <sob@harvard.edu>, "mrw@windriver.com" <mrw@windriver.com>
> cc: "problem-statement@alvestrand.no" <problem-statement@alvestrand.no>
> Subject: Re: Killing old/slow groups - transition thinking
> In-Reply-To: <200212111533.gBBFXBhc013736@newdev.harvard.edu>
> References:  <200212111533.gBBFXBhc013736@newdev.harvard.edu>
> X-Mailer: Mulberry/3.0.0 (Win32)
> MIME-Version: 1.0
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> 
> 
> --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.
> 

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords