--On Saturday, 20 July, 2019 10:17 -0400 Warren Kumari <warren@xxxxxxxxxx> wrote: > On Sat, Jul 20, 2019 at 9:00 AM Christopher Morrow > <morrowc.lists@xxxxxxxxx> wrote: >> >> On Sat, Jul 20, 2019 at 8:51 AM Keith Moore >> <moore@xxxxxxxxxxxxxxxxxxxx> wrote: >> > I believe your statement of intent. But I think it's fair >> > to realize that there is already tremendous pressure to >> > deploy implementations before they've been formally >> > approved, and there's a danger that any kind of >> > distinguished "mark" will have the (unintended) effect of >> > promoting deployment of the marked version of a protocol. >> >> regardless of 'published or not' folk will always push for >> the early implementation of FOO before it has been 'ratified'. >> it's pretty clear that this happens, and that nothing about >> this discussion is going to change that. >> > > *I* think that we really want early implementations of FOO > before it has been ratified - without this we don't have the > "running code" part of "rough consensus and running code. > I think the trouble comes in when there are *deployments* of > FOO before it has been ratified.... Exactly. And, at the risk of singing an old song, that was exactly what Proposed Standard was supposed to be about. So, with the understanding that I'm not optimistic about this for the reasons I gave earlier and a quarter-century of history, consider an alternate proposal: Return Proposed Standard to its original intended status. Try to make it clear that anyone deploying a new specification at Proposed Standard is a fool and deliberately misleading customers about stability and the future. Make it lots easier and faster to get one through the system, e.g., by forbidding or ignoring editorial nit-picking during IETF LC and, as BCP9 clearly allowed, simply documenting known omissions and areas of uncertainty and moving on. Let Proposed Standards be close enough to preliminary engineering specifications that there are real incentives to advance (and carefully finish end edit) documents after implementation and implementability have been proven. The main review should be "is this clear and precise enough to implement for test purposes, with or without judicious application of the robustness principle" (one thing we should learn from implementation, interoperability testing, and running code more generally is a list of things that need to be documented more precisely but that, again, was part of the original idea). Increase RFC Production Center staffing and resources for editorial cleanups to make documents clear, but use different criteria for deciding whether a document is "good enough" to publication to Proposed Standards and Internet Standards. Narrow AUTH48 for Proposed Standards to a "speak now; explain to the RFC Editor, IESG, and the community why you need more time; or just hold your piece"... and, if you are the one author who has not signed off where others have, note that you will be dropped to a Contributor by editorial action if you don't respond within that window. Identify ADs who are holding things up and where to the community and future nomcoms, even explicitly considering it grounds for recall if any one AD is consistently out of line. Would it work? I obviously have my doubts. Would it have chances of working at least as good as trying to devise an entirely new system and convincing people to understand exactly what it is about? IMO, probably yes or at least sooner. Would it be equally fast as a WG simply attaching a stamp of approval to one of its documents? Probably not quite, but keep in mind that, once a WG decides a document is ready for publication, nothing in BCP 9 requires shepherd reports, extensive IESG )or even AD) review and evaluation, more than two weeks of IETF LC for WG documents, and then an extensive IESG review and debate afterwards. If a document takes more than a month between when the WG decides it is ready for community review before it is the hands of the RFC Editor, there is either something substantively wrong with it, the WG didn't do its job (reflecting badly on WG leadership and the responsible AD), or we are dealing with impediments that the community and/or the IESG set up, presumably in the name of closer attempts at perfection. If we think that is a problem, let's fix it, rather than looking for new terminology that just kicks assorted cans down the road or that avoids timely review outside the developing WG (again, IETF LC on WG documents is nominally only two weeks -- that is not where the problem lies). And, if all of that means we have too many WGs and two many work efforts going to be consistent with quality, let's do some serious prioritizing and change that. best, john
