On Wed, Nov 06, 2019 at 09:50:23PM -0500, Keith Moore wrote: > 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.. > > [...] > > 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. +1 > 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 We have it: it's Experimental. But it's essentially seen as a negative, thus underused. > 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. Are you proposing that there be a required backwards-incompatible change so as to force... what exactly? That the old thing does not get deployed? I assume it will mostly discourage use of the new track. The risk with deploying prototypes is that a backwards-incompatible change will be needed, so perhaps early reviews should focus only on identifying features at risk of such changes and requiring that the experimental protocol cover upgrades or reduce the risk. > 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. Maybe, yeah, for high-profile protocols (e.g., TLS). > But my guess is that the only way to get buy-in for Prototype specifications > would be to convincingly promise faster development. Yes. That includes faster RFC-Editor turnarounds. If we remove the other bottlenecs, then RFC-Editor queue time will become the next bottleneck to address. Nico --
