Re: WGs/AD [IETF areas re-organisation steps]

Alia Atlas <akatlas@gmail.com> Sat, 27 December 2014 05:52 UTC

Return-Path: <akatlas@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A82A1AD473 for <ietf@ietfa.amsl.com>; Fri, 26 Dec 2014 21:52:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mS5FHkJzvFDe for <ietf@ietfa.amsl.com>; Fri, 26 Dec 2014 21:52:21 -0800 (PST)
Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85FF11AD45F for <ietf@ietf.org>; Fri, 26 Dec 2014 21:52:21 -0800 (PST)
Received: by mail-yk0-f169.google.com with SMTP id 79so5426010ykr.0 for <ietf@ietf.org>; Fri, 26 Dec 2014 21:52:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SsgL50LziIwsrGkF8k1Uq2PnZovV+WtsVk8lLpYagN8=; b=x9KJSxpsNuv9MtQgSSnolzQbpOdaV5ZYxqW3lWFMidV+xippNR+0X+oOnXUf49rABR JwXq4GPyKHQMIxfzepKeIAF6TeBEI+8sRjkvqkcPR5VAtVNl3SdrvYD6UNhCfS+am/0j 2jw8LeaQB4qCkW1yjRgIN4MVuwaqSVsA1UM6I8mjmwThIpd/5NJ7spMqbh0YYkrr+Uwp hnOY7AUC+W9PMgNz/d8PLd+13r5ar+P6GbfurBBfLMDrCoQOEXkFOQg8Ool+FjBc0Xgn 1v6ORzWoE/ZR6eRJ1RPML7687DxHmI8teOthuoC9PrwZ9fTkXeIGlGJkEylBq+i80bMz hGAA==
MIME-Version: 1.0
X-Received: by 10.236.15.103 with SMTP id e67mr740842yhe.3.1419659540728; Fri, 26 Dec 2014 21:52:20 -0800 (PST)
Received: by 10.170.133.18 with HTTP; Fri, 26 Dec 2014 21:52:20 -0800 (PST)
In-Reply-To: <549DDF98.1060802@gmail.com>
References: <ED473823-2B1E-4431-8B42-393D20BA72DF@piuha.net> <7973.1419613616@sandelman.ca> <CAG4d1rcXa10moh7-V2oteV+3o8y0s+QwCTXaCWt5aBeRdPKv=A@mail.gmail.com> <549DB9A6.4050506@gmail.com> <CAG4d1rc3vB693OAW8KrzVaZ3hkdL1OuD=4dByVVW7yuD0+Otvg@mail.gmail.com> <549DDF98.1060802@gmail.com>
Date: Sat, 27 Dec 2014 00:52:20 -0500
Message-ID: <CAG4d1rdE_=Hu4m9TXiVKZ712=eUpaQ3ak07zp6enhYkAHKoRJA@mail.gmail.com>
Subject: Re: WGs/AD [IETF areas re-organisation steps]
From: Alia Atlas <akatlas@gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Content-Type: multipart/alternative; boundary=089e0122a476a091c8050b2c3eb2
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/nDHaCYDyOIGpjsjhWvt0GYQ7Px4
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, IETF-Discussion list <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 27 Dec 2014 05:52:25 -0000

Hi Brian,

On Fri, Dec 26, 2014 at 5:22 PM, Brian E Carpenter <
brian.e.carpenter@gmail.com> wrote:

> Hi Alia,
>
> On 27/12/2014 08:59, Alia Atlas wrote:
> > Hi Brian,
> >
> > On Fri, Dec 26, 2014 at 2:40 PM, Brian E Carpenter <
> > brian.e.carpenter@gmail.com> wrote:
> >
> >> On 27/12/2014 06:46, Alia Atlas wrote: ...
> >>>> I'm a little bit surprised that the RTG area load has gone up
> >>>> like this, and so quickly.  Is it the various SDN things that
> >>>> are pushing this, or is it
> >>>> that the RTG area currently has the most enthusiasm for YANG
> >>>> work?
> >>>>
> >>>
> >>> It's a mixture of things combined with RTG already being at the
> >>> very top edge of workload.  In RTG we have/will have about 21
> >>> active WGs; if we add a third routing AD, then RTG will absorb 3
> >>> WGs from INT. Granted that one is not active and may be merged
> >>> in, we are still looking at about 23 WGs for RTG with a more
> >>> average load being about 8 WGs/AD.
> >>
> >> So let's be frank about this. Today (excluding the General Area AD
> >> with his crippling load of 1 WG) we have 129 WGs for 14 Ads,
> >> which is 9.2 WGs/AD. That is clearly too many, so should there be
> >> a target ratio and a plan for reaching it?
> >>
> >
> > No, as you well know, it depends on the size and business of the
> > WGs, the management load, etc., as well as the number.  Clearly we
> > don't want to not create new WGs when appropriate nor to discourage
> > existing useful work.
>
> Of course, an average is only an average, but the point is: we've
> had about 125 WGs for at least ten years now, and we've had
> over-burdened ADs for all that time. That seems to be a fundamental
> problem, regardless of the sort of adjustments the IESG is currently
> proposing.
>

Absolutely - and in that regard, this reorganization is just working on
better
balancing the existing load among the IESG.  We are also trying out some
ideas, such as the cross-area shepherding AD, to see how well they can
work for better balancing between ADs while leaving areas intact.  Areas
have impact for whom participates, what WGs are seen as relevant or
connected to another, and generally lots of the community and people
aspects.  It's the document reviewers, authors,editors, WG chairs,
directorates, and all those who volunteer to do work who make the IETF
work - and to ignore those dynamics to make the IESG's job easier would
be a mistake.

There are two words in your second sentence above implying a value
> judgment: "appropriate" and "useful". Unfortunately, as far as I can
> tell, the only way to truly manage the IESG workload is by raising
> the bar for "appropriate" and "useful". (The same applies to
> the bar for a WG to adopt a particular work item.)
>

There are a few things we can do.  Some things that I've been trying to
do in Routing include:
  a) discouragement of progressing many use-case and requirements drafts.
      We had drifted towards having WGs producing some to help articulate
what
      needed to be done - but then more and more appear and only some
      actually provide more useful feedback to the architecture or
protocol.  I
      would rather see WGs produce things that can be implemented with the
      necessary context than spend years working on use-cases and
requirements.
      I'm past the waterfall model of software development.

  b) Encourage WG chairs to think about the need for ACTIVE consensus rather
      than passive.  If there isn't the enthusiasm to review and improve a
draft or
      implement it, then does it really need to be an RFC?

  c) Better and early cross-WG review once a draft is adopted as a WG draft.
      Well-written drafts without serious issues are much faster to manage,
review,
      and progress.

  d) Be willing to let WGs fail - by also letting them just get on with
doing solutions.

I don't know how much those are raising the bar and how much those are
pushing
better process and more work back into the WGs.  I do think that (a) and
(b) may raise the bar in a way that I personally am comfortable with.  I'm
certainly
willing to listen and happy to hear other ideas.

It is tempting to think that poorly written and poorly reviewed drafts may
not
fall into the 'useful" camp, but that can vary based upon a WG and editors
losing
their energy and enthusiasm.  One of the worst parts there is really the
time it
takes when people don't consciously put in time to do the standardization
work;
an unstaffed project rarely completes quickly, after all.


> > This is a question of balancing load and there is a surge of
> > YANG-related work which does require more focused management.  Is it
> > better to have 2 ADs at 100%-120% and others with less load when the
> > size of the IESG would be otherwise reduced.  Are you suggesting
> > that suggesting another routing AD to take load from RTG and INT is a
> > bad idea compared to dropping the IESG to 14 & eventually 13?
>
> No, I was specifically trying to avoid being specific. I think we have a
> general long-term problem.
>

Yes - but which part of the elephant are you describing?  This load
rebalancing
may not be the only thing that the IESG considers - it is merely clear steps
to handle the immediate problem of workload re-balancing.

As one of those who was willing to admit that I could really do a better
job with
3/4 of the current workload, I'm a bit sensitive to considering the
generalities.

It's entirely appropriate for the IESG to propose workload re-balancing
> to deal with the current workload. I may have some quibbles, but it's the
> IESG's decision.
>
> > Are you simply concerned with the dynamics of how many ADs have the
> > various perspectives on the IESG?
> >
> > Obviously, we are looking for feedback and opinions and ideas.  Do
> > you have other well thought out suggestions?
>
> In terms of the long-term problem, unless I am mistaken, neither the IESG
> nor the community has ever said much about how to make the judgment calls
> that new work is useful and appropriate for the IETF. We've got a very
> good document to help BOF proponents (RFC 5434) but I don't think we've
> ever tackled the next bit: deciding whether this work should be chartered?
>

Not that I know of, but so far, I'm not convinced that it would be feasible
to
clearly articulate and avoid unfortunate gaming.

One result of that is that proponents who have what they think is a
> successful BOF are sometimes very puzzled and frustrated by their
> failure to form a WG. Another result is that it's a bit harder for
> the IESG to say "no" than it would be if the decision criteria were
> a bit more transparent. A third aspect is that every new IESG member
> has to discover for herself how this vital bit of the process works
> on the inside.
>
> I think my suggestion is that to have any serious hope of controlling
> the workload *in the long term*, we need to have something (it could be
> an IESG statement, it could be an RFC) the stakes out a position on
> what it means for a WG or work item to be judged appropriate and useful.
>

Interesting - I was expecting to hear more about multi-level IESG or
off-loading
more work towards the directorate or WG chairs.

Thanks for the suggestion.  I'll certainly think about it more.

Regards,
Alia

P.S.  I'm another of those who is checking email sporadically during
vacation.
There's plenty of time for discussion in January too.


> Regards
>    Brian
>