Eliot Lear wrote: > > On 1/25/13 4:27 PM, John C Klensin wrote: > >>> a WG can skip WG LC if they think its not needed. > >> > >> When was the last time that happened? > >> Did it require a consensus call to determine? > > > Chair discretion [... and five of paragraphs of text] > > None of which answered my above questions. When was the last time > chairs USED that discretion?! I don't know about the last time it happened, but I know about one time in Nov-2009 in the TLS WG (now rfc5746). The WG chair *did* a WG consensus call before AD & WG chair short-cutted to IETF LC. IMHO, at the very minimum, a WG consensus call with a specific question or choice is necessary to gauge consensus in a WG. WG Consensus call (20-Nov-2009): http://www.ietf.org/mail-archive/web/tls/current/msg04571.html AD taking over (27-Nov-2009): http://www.ietf.org/mail-archive/web/tls/current/msg04928.html IETF LC (30-Nov-2009): http://www.ietf.org/mail-archive/web/tls/current/msg04962.html While I was OK with skipping the WGLC, I really didn't like some of the AD's shortcut, in particular with respect to standardizing two methods for signaling, and his refusal to perform a consensus call for mandating the simpler version of the signaling, which would have significantly facilitated the creation of fixes for the installed base. http://www.ietf.org/mail-archive/web/tls/current/msg05287.html There is a REAL issue with rushing a document pointing to implementations, when it turns out pretty quickly that what has been implemented is really just half of a solution. I'm actually afraid that rushing things on the process side is going to worsen problems. What I was slighly missing in that process was (a) leadership, in recognizing that mandating one signaling scheme will simplify the spec, implementations and interop effort and (b) true consensus calls on issues that are obviously contentious. Even running a consensus call during / in parallel to an IETF LC is better than blaming time-constraints and the AD infering his "desired" outcome from prior discussions of *MUCH* broader topics. Process-wise, we need to be extra careful about collision of interest, each time when short-cutting processes. -Martin