Re: Thought experiment [Re: Quality of Directorate reviews]

[Keith Moore <[e-mail]>]

On 11/6/19 9:25 PM, Brian E Carpenter wrote:

> Two WG chairs is almost the norm these days. But yes, the essence of
> the experiment is to reduce the number of people in the decision
> process - and intentionally lower the bar for Proposed Standard closer
> to how it's defined in RFC2026:

But 2026 criteria assumed a three-stage standards track.   Now we're 
down to two stages in theory, and still usually just one stage in 
practice.   As far as I can tell, getting rid of Draft Standard hasn't 
done anything to make Proposed Standard less of a terminal state and 
more of a stepping-stone.

>     A Proposed Standard specification is generally stable, has resolved
>     known design choices, is believed to be well-understood, has received
>     significant community review, and appears to enjoy enough community
>     interest to be considered valuable.  However, further experience
>     might result in a change or even retraction of the specification
>     before it advances.
RFC2026 also says:

    Implementors should treat Proposed Standards as immature
    specifications.  It is desirable to implement them in order to gain
    experience and to validate, test, and clarify the specification.
    However, since the content of Proposed Standards may be changed if
    problems are found or better solutions are identified,/*deploying implementations of such standards into a 
disruption-sensitive environment is not recommended.*/

(emphasis mine)

This is where the biggest disconnect between 2026 and reality is.   If 
the reality is that industry is going to deploy implementations at 
Proposed Standard or sooner (and as far as I can tell, that's been 
reality for as long as there's been an Internet "industry"), it makes 
sense for IETF to recognize that and react accordingly.

If we want there to be a prototype "just for testing" status, it should 
probably be called something other than Proposed - the name has come to 
mean something else in IETF context.   And we should deliberately change 
one or more protocol elements to make the standard incompatible with 
already-deployed implementations.   The trick would be to keep that 
information from leaking out beforehand.    Maybe give the RSE /N/ 
options for things to change that are selected at random, similarly to 
the way nomcoms are selected.

Also, the WG completion, IESG approval and RFC publication dates of a 
new standard should be determined well in advance so that vendors can 
tailor their product development schedules to those dates.   This would 
mean holding WGs, IESG, and the RSE to a schedule (gasp!) once there was 
confidence that the document would be standardized (another argument for 
broad review well prior to Last Call.)  I'm not saying that there could 
absolutely be no slippage, but reality should be close enough that 
developers can plan by it.

But my guess is that the only way to get buy-in for Prototype 
specifications would be to convincingly promise faster development.

Keith