Re: call for ideas: tail-heavy IETF process

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

 



Similarly, AFAICS the 'IESG time' includes IETF last call and the
inevitable delay caused by the quantized nature of IESG teleconferenes.

On the average, this will be somewhere around 28-30 days (2 or 4 weeks
in Last call according to document type plus an average of 1 week until
the earliest possible teleconference and a fudge factor for weekends)
which is an irreducible minimum imposed by our processes.   There is not
much the IESG can do to help on that.

/Elwyn

On Fri, 2013-05-10 at 08:09 +1200, Brian E Carpenter wrote:
> On 10/05/2013 01:13, John C Klensin wrote:
> > 
> > --On Thursday, May 09, 2013 03:32 -0500 Spencer Dawkins
> > <spencer@xxxxxxxxxxxxxxxxx> wrote:
> > 
> >> So in this case, we're looking at "RFC Editor state" =
> >> "Heather, please do something" + "some working group, please
> >> do something" + "author(s), please do something", and we can't
> >> tell how much time to attribute to each of these ...
> > 
> > You could further add to that list "RFC Production Center,
> > please do something" (different from an RSE wait, which is, or
> > at least ought to be, more significant) and "IESG or appropriate
> > AD, please do something", which does happen.
> > 
> > But the RFC Editor's numbers try (almost always successfully) to
> > separate the two "waiting on the RFC Editor Function to do
> > something" (Heather plus Production Center plus, in principle,
> > Publisher) from the other states.  Those other states could,
> > from their point of view, be aggregated into "stuck, someone
> > else's problem".   If we are looking for issues with IETF
> > end-game process, we need to parse those, but that is a
> > different sort of question in terms of data-gathering and
> > reporting.
> 
> All of which suggests that, ideally, the tracker would include
> a variable "onTheHook" for each draft, containing at all times
> the person or role responsible for the next step. That isn't
> necessarily implied by the state machine. For example,
> AUTH48 doesn't always imply that the author is on the hook -
> it may be that the author has asked the WG Chair to ask the
> WG for a quick review of a proposed last-minute change. At
> that point, the WG as a whole is on the hook.
> 
>     Brian





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