Re: FW: Last Call: <draft-farrell-ft-03.txt> (A Fast-Track way to RFC with Running Code) to Experimental RFC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]