Re: [Banana] Charter

Margaret Cullen <mrcullen42@gmail.com> Mon, 18 September 2017 20:50 UTC

Return-Path: <mrcullen42@gmail.com>
X-Original-To: banana@ietfa.amsl.com
Delivered-To: banana@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 019D6133048 for <banana@ietfa.amsl.com>; Mon, 18 Sep 2017 13:50:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level:
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 4-_cxMQgLneH for <banana@ietfa.amsl.com>; Mon, 18 Sep 2017 13:50:32 -0700 (PDT)
Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E96D132026 for <banana@ietf.org>; Mon, 18 Sep 2017 13:50:32 -0700 (PDT)
Received: by mail-qt0-x234.google.com with SMTP id q8so1891854qtb.5 for <banana@ietf.org>; Mon, 18 Sep 2017 13:50:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=O1Vzg4q9muRUdxY1H+wawGajvOh4TOTNyquoqcL97Uo=; b=pSl0GuV0BE5RmMzxc+hnOaEtY/0k1hvjoZf8L8LAiVa6B93fJIniX9di68Rl673LZ7 29YHm4q1v8m8n17gFMZN+WHp9O3XMJWlA/dmYnou6MiYXOAIeijFPUZywwNVb77LUx/f ufChHN9YoIgJmTFWBJdSlkPFEJa3N8tcWWy8JhGm5ZaH3eTL5XNYtA6vZLiPZouhAQ2w Q++YIi504jNY9qgOSnwtd8uVmXukhA/AcXY0W3madqY/OT1ptzwhkLfyhs21qHwN1K1v 6AcmxRcCzrqTUDi1lp9YEY6tm9tBw3pV2S4CfalkNy8v9H0XdnaQWyMnQZoPn5XaD/2K OLcw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=O1Vzg4q9muRUdxY1H+wawGajvOh4TOTNyquoqcL97Uo=; b=LIJFFRHPbbf2pcyqzU4XUquGSAAMchCgnnMYKddHhcctoc76Y6sQLdzo89J1jguCEx dzV8yCziuESq6g7pNGwQHpntLAAIxSFb8wfzLcylvLC4NFbGmpdYeCA59AC1CkbF0y8d jgtwrrfzvc4k4wYBKdkyFx18UDd5bYM5rMd7X5JJuYPyahIMp+q+lK/buGuOBPQ73tri pwldc+NBh9sCkWrQdoW6rksHCJuqm8b9Xi+8j33ase7OORFxg75hkFa0ig+UGeuF521c kNVM7vY8hHApZxMYs2dJLTD9wxc2OqhdhMpHCeX7+Y/nlX4tZjCKXRuZAaMj9CGu8DRd 43VQ==
X-Gm-Message-State: AHPjjUhAALO+MEGy1//Ng8T2XJg0vfPZATk5BTi5YtydH/OPr3OdXoSc qLnylszIXlPmXsveMJ8=
X-Google-Smtp-Source: AOwi7QDVEwJL2xSi+FOE8TtJ+iIgO68dIY0q3U3ZKxw4xF9R6IOmv2ko2xwmtbIPP4kpAQDUDcAsqQ==
X-Received: by 10.200.44.123 with SMTP id e56mr50855641qta.308.1505767830957; Mon, 18 Sep 2017 13:50:30 -0700 (PDT)
Received: from ?IPv6:2601:18c:503:a54a:f47b:5bf6:c24c:20c5? ([2601:18c:503:a54a:f47b:5bf6:c24c:20c5]) by smtp.gmail.com with ESMTPSA id g132sm5670108qke.11.2017.09.18.13.50.29 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 18 Sep 2017 13:50:30 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_BF1D1C26-A956-495D-B55F-CD0B530E7B90"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Margaret Cullen <mrcullen42@gmail.com>
In-Reply-To: <D5E56BEA.28AE8D%sgundave@cisco.com>
Date: Mon, 18 Sep 2017 16:50:29 -0400
Cc: "Henderickx, Wim (Nokia - BE/Antwerp)" <wim.henderickx@nokia.com>, "Zhangmingui (Martin)" <zhangmingui@huawei.com>, Alexandre Petrescu <alexandre.petrescu@gmail.com>, "banana@ietf.org" <banana@ietf.org>
Message-Id: <9CD725AF-B9FE-4E81-BFD6-21A812DF48CF@gmail.com>
References: <96A7BC33-FB64-487A-A60D-7AB8504C9DDF@gmail.com> <a1df884a51f246a7969c0057ff78d807@BTWP000357.corp.ads> <C3A4BFB9-EAD7-4B32-90C1-248D6D74ECD1@gmail.com> <9A767D1D-C6CA-4C7D-A281-7150E259881D@gmail.com> <DB5PR07MB13998EE07C5B5D5DBACED79C9B1A0@DB5PR07MB1399.eurprd07.prod.outlook.com> <7ED94797-5E72-4191-B861-4CD2F410BBD5@gmail.com> <7i60gox0c8.wl-jch@irif.fr> <DB5PR07MB1399FEDB262E0205457EA8AB9BFC0@DB5PR07MB1399.eurprd07.prod.outlook.com> <87bmqgov69.wl-jch@irif.fr> <DB5PR07MB1399977AFFE9FA7D19A2D34D9BFC0@DB5PR07MB1399.eurprd07.prod.outlook.com> <0d8ce583860345b89020113f1239be5d@BTWP000357.corp.ads> <21BD0F20-9CE5-466B-992E-93F6D84DB7D4@gmail.com> <95788B92-E8C1-4FE6-9B0C-7F29361D9297@trammell.ch> <d3759d89-9f6e-bcf4-8c44-32f3f435d784@gmail.com> <01e83ac6-0bd0-e7c7-01e4-0ffb7af73034@gmail.com> <4B6D7CF5-E6BC-4ECA-9299-7458A624320B@nokia.com> <B31BA5EB-7369-4B49-B240-AA6C3E653231@gmail.com> <2F216DBC-43EE-45AC-AAB8-68C81A14AD73@nokia.com> <4552F0907735844E9204A62BBDD325E7A65EC703@NKGEML515-MBX.china.huawei.com> <260086DD-D245-46EF-89E2-308D5A58AAFB@nokia.com> <5FECB6A6-41B7-41D1-A8B8-B7BCE8474F90@gmail.com> <2CD45C9D-41FB-425F-946E-D3AE47C9B000@nokia.com> <6A618A1C-92FB-467F-8F7D-6A9B40FC191E@gmail.com> <D5E56BEA.28AE8D%sgundave@cisco.com>
To: "Sri Gundavelli (sgundave)" <sgundave@cisco.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/banana/PN7UGbcaDiE1R3j5JbyjMa0hdCU>
Subject: Re: [Banana] Charter
X-BeenThere: banana@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Bandwidth Aggregation for interNet Access: Discussion of bandwidth aggregation solutions based on IETF technologies." <banana.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/banana>, <mailto:banana-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/banana/>
List-Post: <mailto:banana@ietf.org>
List-Help: <mailto:banana-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/banana>, <mailto:banana-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Sep 2017 20:50:34 -0000

Hi Sri,

> On Sep 18, 2017, at 3:43 PM, Sri Gundavelli (sgundave) <sgundave@cisco.com> wrote:
> It is not just the question of counting hands in the room, I do not think
> that¹s the criteria for ³consensus² determination. We all have been in
> IETF long enough and we know that does not mean any thing. Sure, there may
> be few excited researchers/students who have no skin in the game to
> express interest in the work, but Standardization should have a product
> path. Are the key network vendors who have skin in the game have expressed
> interest for this work? Is there SDO interest from 3GPP, Wireless or
> Broadband guys? Clearly, I do not see that and there is no support for
> this work.

The IETF WG formation process focuses on making sure that there is an actual community of people who want to do a well-understood set of work, that those people have the skills and knowledge to do the work successfully, and that they represent enough segments of the industry to have a wide-enough perspective to do the work in a way that will be widely applicable.  The IETF is set up to attract competent groups of people who want to do interesting work within the IETF’s scope, and offer them an environment and support that will allow them to do a good job.  There have even been some WGs formed by the IESG with no BOF or consensus call in the community at all.  My statements about the number of people who said that they understand the work and want to do it in the IETF, were not meant to say “we have consensus”, but were more meant to say “We have sufficient people who understand this, who want to do it, and who can do a good job”.  If you personally don’t want to work on this, then you don’t have to work on it.

> Also, many folks asked why there is a need for a new signaling protocol.
> When I asked this question, some explicit text was added to say something
> along the lines, ³WG will not define a new signaling protocol, unless the
> existing protocols do not meet the requirement². I remember Mirja
> commenting on that and the chairs editing the text (Mirja can comment if I
> am wrong here). But, the below charter text conveniently removed that
> entire text and now shows a milestone for the signaling work. So, the work
> is getting steered not based on consensus, but on a pre-determined path.

I also remember that discussion.  There was objection to the wording you suggested, and it was reworded.  Then, people pointed out that it didn’t apply only to the signaling protocol.  After the discussion ended, we ended up with the following sentence:  

"The BANANA WG will consider existing IETF protocols, where applicable, as the basis for the work items listed above.”

That sentence appears in the charter, just below the list of the three protocols that are needed as part of a solution.

Even if we use an existing protocol, we would probably need to document how that protocol would be used to enable the BANANA functionality, as there are no IETF protocols that are currently being used for this purpose, as is.
> 
> Bottomline, this work has no support. There is no vendor, SDO or operator
> interest; we need to have additional discussions. This is a classic case
> for IESG Appeal.

I don’t believe you are correct about this.  We have proposals authored by multiple vendors and operators, we have consistently had people from a dozen or more companies show up at BANANA Bar BOFs and other meetings, including vendors, operators, and researchers.  There are at least three groups that have shown up who are actively working on developing solutions in this space, including at least one group that has actively deployed a solution.  We have researchers who are doing general research in the area, as well as one group of researchers who are doing very interesting research on the performance of potential BANANA solutions, specifically.  

Margaret