Re: IETF areas re-organisation steps

Jari Arkko <jari.arkko@piuha.net> Thu, 15 January 2015 16:41 UTC

Return-Path: <jari.arkko@piuha.net>
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 6A6821B2D84; Thu, 15 Jan 2015 08:41:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 f-Wnd2iunpOY; Thu, 15 Jan 2015 08:41:44 -0800 (PST)
Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id C68811B2DB1; Thu, 15 Jan 2015 08:41:43 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 702222CC5D; Thu, 15 Jan 2015 18:41:42 +0200 (EET) (envelope-from jari.arkko@piuha.net)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-khx322wXO9; Thu, 15 Jan 2015 18:41:41 +0200 (EET)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id B648B2CC4D; Thu, 15 Jan 2015 18:41:41 +0200 (EET) (envelope-from jari.arkko@piuha.net)
Content-Type: multipart/signed; boundary="Apple-Mail=_E3122328-5BE5-428D-930B-E085C1393336"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: Re: IETF areas re-organisation steps
From: Jari Arkko <jari.arkko@piuha.net>
In-Reply-To: <D68B9223-0A90-4FCD-B1B1-0CBD6B82F054@ietf.org>
Date: Thu, 15 Jan 2015 18:41:39 +0200
Message-Id: <6137365A-A47C-4D6B-BA5D-6EEF4C985CF7@piuha.net>
References: <5614C286-0CD2-4DAD-A846-510EE38D1B9A@ietf.org> <D68B9223-0A90-4FCD-B1B1-0CBD6B82F054@ietf.org>
To: ietf <ietf@ietf.org>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/YoE3Y7tL3J3pTkBISiAt_2Pu_bU>
Cc: IETF WG Chairs <wgchairs@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: Thu, 15 Jan 2015 16:41:47 -0000

I wanted to provide a brief summary of various comments made in the discussion. Note that each of these has had some discussion, and there are responses in those threads. I have attempted to provide some answers below for the most clear cases. These answers are my personal view, and more IESG thoughts will be forthcoming.


PRINCIPLES

Is the order significant? (Ted H) Answer: no.


THREE STEPS

Will the proposal change time commitment for the ADs? I think the IESG might get more bang for its re-organizational buck if it focused on areas where its tasks could be handed over to new bodies. (Ted, etc) Answer: No, this is largely about having the right subdivisions within the IETF. The IESG recognises the need to push more work from the ADs to the working groups, but that is considered as a separate change. We will probably need both the right areas/flexibility, and handing off tasks to working groups and other entities.

A counter-proposal is to flatten the hiearchy. Lose the concept of areas, and consider the IESG as a group of people, each one assigned to the most appropriate task. (Nico) Answer: there is some value in the areas for both management and participants.

We should try reducing structure rather than adding to it, particularly if we are experimenting. (Nico)

The IESG proposal has the downsides of both Nico's proposal and the existing rigid system. (Andrew)

There is a too big overall workload in the IETF, would raising the bar for accepting work be useful? (Brian C) Answer: The IETF should do the work that needs to be done and is suitable for our experience base. If scalability is a problem, it would be better to find more scalable organisational models.

This should be an experiment, and there will be no shame in unwinding the change in a few months or a couple of years if it fails. (Brian C)


FURTHER SHIFTING RESPONSIBILITIES TO OUT-OF-AREA ADS

If we have a system of ADs managing WGs that are not in their area, it means that the assignment of areas is incorrect. (Brian C) Answer: Depends on whether you consider the areas to be primarily a feature for the IESG or the participants. For the participants, an area can make sense, even if it happens to be that the AD in charge of a WG is from another area, but just has the necessary knowledge to deal with this WG.

Does cross-area work need to be more explicitly noted in the descriptions (Dave)? Answer: yes.

IESG member assignments might become matters of IETF debate. (Nico)


ADDING A THIRD RTG AD

What is the term for 3rd RTG AD: shall this be 1, 2, or 3 years, and how do we ensure that on the average, we balance the requirement to select approximately half of the IESG every year? (Brian C, Michael R, etc.)

What are the qualifications expected from the 3rd RTG AD (Michael)? Answer: we have a proposal, and it will be close to what the current descriptions are.


MERGING OF UPPER LAYER PROTOCOL AREAS

How do the job descriptions change (Eliot, Ted H)? Answer: we have a proposal for the 3rd RG AD case, but the rest clearly needs work. New descriptions would be needed for the NAPP, even if much of the material can come from the existing ones.

The three area combination is too large and complex, and TSV is not a good match to the others; what benefit you expect to gain from creating a mega-area that offsets the resulting issues of focus, scheduling, and increased inter-AD communication required? How long would it take for the ADs in the big around to agree, or to communicate? (Brian C, Robert, Ted H, etc.) Answer: For at least a partial answer, see the mail from Alissa.

It is important the congestion control back-stop review still happens, even if TSV is combined into applications areas. (Brian T) Answer: Yes. The point about directorates and review teams focusing on transport issues is a good one.

How will the Dispatch WG be handled after the merging of RAI and other areas? Is there a conflict to what RFC 5727 defines for the DISPATCH process? (Olle, Robert) 

NAPP name is not good. (Robert) Answer: This is obviously a detail, but the name could be changed of course.

What does it mean for an area to be an area? (Yoav). Answer: Multiple things, it is a collection of work around a technology area or a topic. But it is also a set of working groups managed by the same area directors. Finally, areas are considered in scheduling sessions to avoid too much overlap within the same area.