Re: IETF areas re-organisation steps

Robert Sparks <rjsparks@nostrum.com> Tue, 06 January 2015 21:15 UTC

Return-Path: <rjsparks@nostrum.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 07AB51A86DE for <ietf@ietfa.amsl.com>; Tue, 6 Jan 2015 13:15:18 -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 nPyhfEOMdjir for <ietf@ietfa.amsl.com>; Tue, 6 Jan 2015 13:15:13 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A4051A854A for <ietf@ietf.org>; Tue, 6 Jan 2015 13:15:13 -0800 (PST)
Received: from unnumerable.local (pool-71-96-107-228.dllstx.fios.verizon.net [71.96.107.228]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id t06LFC8O023395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <ietf@ietf.org>; Tue, 6 Jan 2015 15:15:12 -0600 (CST) (envelope-from rjsparks@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host pool-71-96-107-228.dllstx.fios.verizon.net [71.96.107.228] claimed to be unnumerable.local
Message-ID: <54AC505B.8090802@nostrum.com>
Date: Tue, 06 Jan 2015 15:15:07 -0600
From: Robert Sparks <rjsparks@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: ietf@ietf.org
Subject: Re: IETF areas re-organisation steps
References: <ED473823-2B1E-4431-8B42-393D20BA72DF@piuha.net>
In-Reply-To: <ED473823-2B1E-4431-8B42-393D20BA72DF@piuha.net>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/txsECVW98801b1wlwU5kmzR7vj8
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: Tue, 06 Jan 2015 21:15:20 -0000

I'd like to focus for a moment on another part of Jari's original message.

On 12/25/14 1:16 PM, Jari Arkko wrote:
> Dear Community:
>
> In October, we let you know that we would be coming up with some proposals
<trim/>
>
>
> III.  MERGING OF UPPER LAYER PROTOCOL AREAS
>
<trim/>
> DISPATCH, TSVWG, and APPSAWG
> would continue to function much as they currently do.
>
>
I see this as problematic.

RAI is currently operating following RFC 5727, where dispatch is 
defined. It is a consensus document describing how the area decided to 
behave. It does not seem right to say _parts_ of the new combined area 
will follow that consensus. How are you planning to avoid "well, that's 
the APPs part of <newareaname> and we do things like this over there"? 
If you're not planning to avoid that, then it's not really clear what 
problem the organization is really going to solve - the resulting ADs 
will have to behave the same regardless of their label.

The arguments in the past about whether a group belonged in transport or 
RAI, while occasionally silly, were _usually_ helpful in clarifying the 
problem that the proposed group was starting to circle around. Some of 
the comments from active TSV members have touched on aspects of this 
already. As proposed, we will lose that tension, and I think we'll end 
up with muddier charters as a result. (There are other ways to preserve 
that tension, of course, but we would need to explicitly put them in place).

If the thought of developing something like dispatch-related parts of 
RFC 5727 to describe how a new combined area (whatever its ingredients) 
plans to operate seems onerous, or too heavyweight, I'd take it as a 
warning that we're headed for something unpleasant, or that has no real 
effect on organization, improving the efficiency of making standards, 
making recruiting ADs easier, or reducing AD load.

Rather than that, I hope we could fairly quickly come up with a good 
description of how such a combined area would behave, and I hope that's 
not "just like the pieces do now".

RjS