|
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. RFC2026 also says: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. 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
|
