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 >
- Re: IETF areas re-organisation steps Ted Lemon
- IETF areas re-organisation steps Jari Arkko
- Re: IETF areas re-organisation steps Huub van Helvoort
- Re: IETF areas re-organisation steps Robert Sparks
- Re: IETF areas re-organisation steps Dave Crocker
- Re: IETF areas re-organisation steps Paul Hoffman
- Re: IETF areas re-organisation steps Steve Crocker
- Re: IETF areas re-organisation steps Ted Lemon
- Re: IETF areas re-organisation steps Michael Richardson
- Re: IETF areas re-organisation steps Michael Richardson
- Re: IETF areas re-organisation steps Scott Brim
- Re: IETF areas re-organisation steps Ole Jacobsen
- Re: IETF areas re-organisation steps Dave Crocker
- Re: IETF areas re-organisation steps Alia Atlas
- WGs/AD [IETF areas re-organisation steps] Brian E Carpenter
- Re: WGs/AD [IETF areas re-organisation steps] Stephen Farrell
- Re: WGs/AD [IETF areas re-organisation steps] Alia Atlas
- Re: IETF areas re-organisation steps Phillip Hallam-Baker
- Re: WGs/AD [IETF areas re-organisation steps] Brian E Carpenter
- Re: IETF areas re-organisation steps Ted Hardie
- Re: WGs/AD [IETF areas re-organisation steps] Jari Arkko
- Re: WGs/AD [IETF areas re-organisation steps] Alia Atlas
- Re: WGs/AD [IETF areas re-organisation steps] Melinda Shore
- Re: IETF areas re-organisation steps Eggert, Lars
- Re: IETF areas re-organisation steps Nico Williams
- Re: IETF areas re-organisation steps Robert Sparks
- Re: IETF areas re-organisation steps Spencer Dawkins at IETF
- Re: IETF areas re-organisation steps Alissa Cooper
- Re: IETF areas re-organisation steps Ted Hardie
- Re: IETF areas re-organisation steps Robert Sparks
- Re: IETF areas re-organisation steps Eggert, Lars
- Re: IETF areas re-organisation steps Jari Arkko
- Re: IETF areas re-organisation steps Dave Crocker
- Re: IETF areas re-organisation steps Brian Trammell
- Re: IETF areas re-organisation steps Mary Barnes
- Re: IETF areas re-organisation steps Dave Crocker
- Re: IETF areas re-organisation steps Ben Campbell
- Re: IETF areas re-organisation steps Benoit Claise
- RE: IETF areas re-organisation steps Larry Masinter
- Re: IETF areas re-organisation steps Yoav Nir
- RE: IETF areas re-organisation steps Larry Masinter
- Re: IETF areas re-organisation steps Kathleen Moriarty
- Re: IETF areas re-organisation steps Phillip Hallam-Baker
- Re: IETF areas re-organisation steps joel jaeggli
- RE: IETF areas re-organisation steps Larry Masinter
- Re: IETF areas re-organisation steps Julian Reschke
- Re: IETF areas re-organisation steps Phillip Hallam-Baker
- Re: IETF areas re-organisation steps Brian E Carpenter
- Re: IETF areas re-organisation steps t.p.