Re: IETF areas re-organisation steps

Alia Atlas <akatlas@gmail.com> Fri, 26 December 2014 17:46 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 45E241A911A for <ietf@ietfa.amsl.com>; Fri, 26 Dec 2014 09:46:59 -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 k1HAHGRTpUfM for <ietf@ietfa.amsl.com>; Fri, 26 Dec 2014 09:46:56 -0800 (PST)
Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 378B31A1A2E for <ietf@ietf.org>; Fri, 26 Dec 2014 09:46:56 -0800 (PST)
Received: by mail-yk0-f182.google.com with SMTP id 131so5127311ykp.41 for <ietf@ietf.org>; Fri, 26 Dec 2014 09:46:54 -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=uusPQjNvF6yiDbtlefZsd/TitYpT0HdII5m+7qos5Tc=; b=FvdgVGMBx8XKQBPBB3ImjCA1v7SrcPLIO8bGAdokbZEqh2H90obVVLCxhKdrHqIwnJ wyczi/SudU5drNFp6MOvhyxIzXlm8yIEMw9a28l8iqiiPB03eXnXHzOhFD16ge/huieC wm9KJdaiRajNMIxM93KioagQnkmC7Iymdy1doQbAqdqxWQJM4Pns/O496VDe32RMxRK1 AjtCnAFqF92WBdkyd96kFKFmT6hrs4/9puQpAAM+4D3cozK6a8/gt9/eZ5ltALWmzTSR 98+AOudupW1ispEVcOQz6Yi5TUqFhkMJk+Zmc4szejn8LbPsI+Q7NdthVAfwjfV9JN1R tGqA==
MIME-Version: 1.0
X-Received: by 10.236.26.116 with SMTP id b80mr31924473yha.60.1419616014387; Fri, 26 Dec 2014 09:46:54 -0800 (PST)
Received: by 10.170.133.18 with HTTP; Fri, 26 Dec 2014 09:46:54 -0800 (PST)
In-Reply-To: <7973.1419613616@sandelman.ca>
References: <ED473823-2B1E-4431-8B42-393D20BA72DF@piuha.net> <7973.1419613616@sandelman.ca>
Date: Fri, 26 Dec 2014 12:46:54 -0500
Message-ID: <CAG4d1rcXa10moh7-V2oteV+3o8y0s+QwCTXaCWt5aBeRdPKv=A@mail.gmail.com>
Subject: Re: IETF areas re-organisation steps
From: Alia Atlas <akatlas@gmail.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Content-Type: multipart/alternative; boundary=047d7b5d99a341525a050b221ceb
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/P1GS_PyWCI0VC7obZ4n_6cvoJ_c
Cc: 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: Fri, 26 Dec 2014 17:46:59 -0000

Hi Michael,

On Fri, Dec 26, 2014 at 12:06 PM, Michael Richardson <mcr+ietf@sandelman.ca>
wrote:

>
> [I guess maybe future discussion might call this the "Xmas IESG Reorg"?]
>
> Jari Arkko <jari.arkko@piuha.net> wrote:
>     > 1) Agility: The IESG should be able to adapt as Internet engineering
>     > evolves.  When work focus shifts and new technologies emerge, it is
>     > critical that the the IESG can follow the shift and effectively
> manage
>     > the new work.
>
> I think that this is good.
> ...
>
>     > 4) Sustainability: The Area Director role should be a position that
>     > accomplished engineers aspire to and that employers want to support.
> We
>     > should emphasize the "steering" and "director" aspects, supporting
> and
>     > guiding the technical work in the working groups.
>
> Good...
>
>     > I.  FURTHER SHIFTING OF WG RESPONSIBILITY TO OUT-OF-AREA ADS
>
>     > The ability to react to changes in the industry, for example the IESG
>     > YANG Model Work Redistribution [3], requires flexibility within the
>     > IETF leadership positions. There are numerous instances where the
>     > constituency of a WG exists in a particular IETF area, but the most
>     > appropriate AD for that work happens to be in a different area, or
>     > where the ADs in the area are simply overloaded and an AD outside of
>     > the area is perfectly capable of managing the work. To address these
>     > possibilities, the IESG is moving towards a model where a WG can
> exist
>     > in one area, but its shepherding AD comes from another area. This
>
> I think that this is perhaps the most important result.
>
>     > II.  ADDING A THIRD RTG AD
>
>     > The IESG is considering requesting that the currently seated nomcom
>     > select an additional routing AD, such that two new routing ADs,
> rather
>     > than one, would be seated for two-year terms in spring 2015. The
>     > reasoning behind this request is that the load in the RTG area is
>     > currently unsustainably high. The placement of a third AD will have
> the
>     > effect of spreading that load such that the time requirement may now
> be
>     > more consistent with the work loads of ADs in other areas. The total
>     > number of ADs on the IESG would not change if the APP seat remains
>     > vacant.
>
> 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.

Of course, in the next two years, it is likely that at least a couple WGs
will close.
The load from YANG work may decrease and regardless, the structure being
well established should reduce the work.

Between these three factors, a third routing AD would be quite useful in
making
the load more reasonable - possibly down to a theoretical 80%.


> <nomcom hat>
> I want to note to the community that the list of RTG AD candidates is large
> and highly qualified. Will the desired qualifications change in any way?
> Will the community need a chance to provide further feedback on this?
> When will the IESG make this decision?
> </nomcom hat>
>

Obviously, the IESG is soliciting feedback from the community now; I expect
that process to continue until mid-January.

I am quite aware that we have lots of excellent routing AD candidates this
time.
I personally do not see a reason to change the desired qualifications.

Regards,
Alia


>
>     > III.  MERGING OF UPPER LAYER PROTOCOL AREAS
>
>     > As previously noted [1], a significant amount of the work that is
> going
>     > on in the APP area pertains to the web protocols, but that has a good
>     > deal of crossover with work in RAI. There is also some crossover work
>     > between the APP and TSV areas. To accommodate these overlaps and
>     > provide better WG management across these three areas, the IESG is
>     > proposing to merge the APP, RAI, and TSV areas into one combined
>     > Network Applications (NAPP) area. From March 2015-March 2016, this
>
> Oh, please can we call it the "Network Working Group" :-)
>
> seriously: I think that this is a great idea.
> I'm curious if over time the four/five ADs would wind up specializing
> (SIP things, email things, web-things, congestion-related things), or
> if the Home AD for would be intentionally mixed up so as keep silos from
> forming.
>
> I imagine the various directorates will remain.
> I suggest that the WGs remain "affliated" to directorates, and we may want
> to
> create more of them, and that perhaps, in general, that WGs will affliate
> to
> areas identified by directorates rather than by ADs.
>
> THIS AFFLIATION might be prove useful and important when doing meeting
> scheduling.
>
>     > starting in March 2016. If possible, we could reduce down to 4 NAPP
> ADs
>     > prior to that time and re-assign the fifth AD’s duties to further
> help
>     > balance IESG load.
>
> I would raise the possibility that the fifth ADs' role could be that of
> either "IETF Chair-in-training" or "past-IETF Chair", and that the process
> of
> succession planning for IETF Chair could perhaps be made more explicit.
>
> --
> ]               Never tell me the odds!                 | ipv6 mesh
> networks [
> ]   Michael Richardson, Sandelman Software Works        | network
> architect  [
> ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on
> rails    [
>
>