Re: IETF areas re-organisation steps

Ben Campbell <> Thu, 15 January 2015 22:56 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1E6BA1A908E for <>; Thu, 15 Jan 2015 14:56:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FJ5fNtt35eA3 for <>; Thu, 15 Jan 2015 14:56:11 -0800 (PST)
Received: from ( [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 81FA21A908D for <>; Thu, 15 Jan 2015 14:56:11 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.14.9/8.14.7) with ESMTP id t0FMu7WD061864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Jan 2015 16:56:07 -0600 (CST) (envelope-from
X-Authentication-Warning: Host [] claimed to be []
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
Subject: Re: IETF areas re-organisation steps
From: Ben Campbell <>
In-Reply-To: <>
Date: Thu, 15 Jan 2015 16:56:06 -0600
X-Mao-Original-Outgoing-Id: 443055366.781358-1a919e4af9ba7e9aa783774a2b7c1316
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <>
To: Mary Barnes <>
X-Mailer: Apple Mail (2.1993)
Archived-At: <>
Cc: "<>" <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 15 Jan 2015 22:56:13 -0000

> On Jan 15, 2015, at 10:36 AM, Mary Barnes <> wrote:
> FWIW, I totally agree with Robert as well as the concerns Ted has raised.   In particular, I totally share Robert's concern about the confusion to the community as to where new work should go.   One of the huge advantages we achieved with the formation of the DISPATCH WG was that unless it was crystal clear what WG the work was most relevant to, individuals (for the most part) came to the DISPATCH WG/chairs.  Prior to that, we would have people WG shopping and there was one situation where the same draft was presented in 3 different WGs.

I also agree with Robert, Ted, and I guess now Mary :-)

I see an advantage merging APPS and RAI. I don't see the advantage of adding TSV to the mix.

As it happens, and I think mainly due to the luck of the draw, I've chaired multiple "frontier" working groups, that is, groups that had significant cross-area participation and dependencies. SIMPLE started in APPS, then moved into RAI when that area was formed. XMPP has major dependencies on APPS work, and its participants have as much (or more) APPS experience as RAI experience. I agree with Ted's statements that the divide between APPS and RAI is rather artificial. (They both even have "applications" in their names.)

The other working group that I chaired was DART, which was a cross-area effort between RAI and TSV. I think this was important work, and needed to happen. That need will reoccur from time to time, and should probably be easier to make that sort of work happen.  But DART also made it clear that these two groups do not have nearly as much in common technically as do RAI and APPS. If the goal of such a merger is to bridge that technical divide, then there might be value in doing this. But if the goal is to lighten the workload of the responsible ADs, I think merging TSV with RAI might actually make things worse, at least for the near future.

> IMHO, the workload issue could be much more effectively handled by taking better advantage of directorates.  The RAI area directorate is not at all been utilized as it could be. 

I agree on both points. There might be value in also making more use of technical advisors to working groups.

> Regards,
> Mary.