Re: [Banana] Charter

"Sri Gundavelli (sgundave)" <sgundave@cisco.com> Fri, 15 September 2017 02:30 UTC

Return-Path: <sgundave@cisco.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 0744B13219A for <banana@ietfa.amsl.com>; Thu, 14 Sep 2017 19:30:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level:
X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 FgrXzFBNTjx7 for <banana@ietfa.amsl.com>; Thu, 14 Sep 2017 19:30:19 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 303EF126B6D for <banana@ietf.org>; Thu, 14 Sep 2017 19:30:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5637; q=dns/txt; s=iport; t=1505442619; x=1506652219; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=9BW2Fbvyz3uCH1v9FCuw+shBiSGiiBG0Qw8B/H4rIys=; b=JRgeHDCq6QlxZeMRow19gzGljvn9Cy9nKyneOtE52nsc+XGMRS3fbPSX eGHBOwBTNrggVEe22lYdONu3MAaGLs941oudiADRPs9aDaZcTq9THtq/w Ehsh5i8W5A3JHXAwfaM/6H4LqtD3e9zVy9iS/uDOU+9nV4iLEl73zcBAV k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CPAQD6ObtZ/4YNJK1dGQEBAQEBAQEBAQEBBwEBAQEBg1qBUicHn3V5h0KNbYISCoU8AoQkQBcBAgEBAQEBAQFrKIUZAQQBbgsFCwIBCEYhESUCBA4FG4l/Aw0Irg6HNQ2DbgEBAQEBAQEBAQEBAQEBAQEBIYMrggKBUIFjgnM1gliBbDSFcwWHP5B+iAk8Ao8KT4R3ghOFaIp7hxOFRYU3gnUCERkBgTgBIAE2gQ13FUqFGRyBZ3aHXoEPAQEB
X-IronPort-AV: E=Sophos;i="5.42,395,1500940800"; d="scan'208";a="77632699"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Sep 2017 02:30:17 +0000
Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v8F2UHhR023501 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 15 Sep 2017 02:30:17 GMT
Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 14 Sep 2017 21:30:16 -0500
Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1263.000; Thu, 14 Sep 2017 21:30:16 -0500
From: "Sri Gundavelli (sgundave)" <sgundave@cisco.com>
To: Margaret Cullen <margaretw42@gmail.com>
CC: "Muley, Praveen (Nokia - US/Mountain View)" <praveen.muley@nokia.com>, Alexandre Petrescu <alexandre.petrescu@gmail.com>, "Henderickx, Wim (Nokia - BE/Antwerp)" <wim.henderickx@nokia.com>, "banana@ietf.org" <banana@ietf.org>
Thread-Topic: [Banana] Charter
Thread-Index: AQHS/w5lhWOFLy/yHEWQ/Po5rcE+YqJYdBGAgERGvoCAFlpQAIACeiYA///miQA=
Date: Fri, 15 Sep 2017 02:30:16 +0000
Message-ID: <D5E08340.28A98B%sgundave@cisco.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> <HE1PR0701MB21884F35D61DDA53426CDCBEEA9C0@HE1PR0701MB2188.eurprd07.prod.outlook.com> <D5DE884A.28A3E7%sgundave@cisco.com> <ABACEE0C-8ED6-468B-9746-923321CCCCBB@gmail.com>
In-Reply-To: <ABACEE0C-8ED6-468B-9746-923321CCCCBB@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.7.1.161129
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.20.188.62]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <E09245BEA450EC498FBF2DAB6AC10335@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/banana/cB3p2H6T5qo5Ip0BkCSsnHOmntE>
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: Fri, 15 Sep 2017 02:30:21 -0000

Hi Margaret,

Thank you for your response.

Sure; it was non-WG BOF in IETF 97 which closed with no agreements, then
the BAR BOF in IETF 98 which was not supervised by any AD, or covered
under any IETF process and so does not mean any thing. But, we met in IETF
99 for a WG-forming BOF and straight tweaked the charter text. I tend to
think we missed some important steps in between and those are discussions
on 1.) problem statement,  2.) currently known art, 3.) efforts in other
WG groups, 4.) the gaps 5.) more interestingly SDO/Vendor interest.  I
wonder, why we missed those steps. If the argument is that we have
established consensus in the ML, I looked at all the emails from November
2016 and I did not conclude that there was agreement on this work.


> I am sure that Suresh can be trusted to review things carefully before
>he puts our charter on the IESG agenda.  If there are any particular
>notes or discussion that you would like him to review, please feel free
>to draw his attention to them.

Absolutely! I trust each and every AD/IESG member and I am absolutely sure
they will do their job. They know the process better than me. But, that is
not the point of this discussion. I strongly believe there is no agreement
on the PS and so we need to go back to PS discussion and not randomly
start charter text discussion. That is my feedback to the AD and to the
entire IESG. I hope that will be the conclusion of the IESG review as
well. 


Regards
Sri


 




On 9/14/17, 2:02 PM, "Margaret Cullen" <margaretw42@gmail.com> wrote:

>
>Hi Sri,
>
>> I have the same comment. It is not clear to me either on what exactly
>>this
>> WG intends to do. In the BOF (WG-forming) meeting, there was no
>> opportunity given to raise any questions on the problem statement.  The
>> entire focus of the meeting was on some charter text without any
>> discussions on 1.) problem statement, 2.) currently known art, 3.)
>>efforts
>> in other WG groups,4.) the gaps.  There was no agreement on IETF 98 BOF
>> meeting (non-WG forming) either on the problem statement.
>
>Actually, the non-WG forming BOF was held at IETF-97, and it is true that
>we did not yet have agreement on a clear and well-understood problem
>statement at that time. We didn¹t hold a BOF at IETF-98.  Instead, about
>30 of us met for a publicly-scheduled "Bar BOF" and discussed the problem
>statement and possible charter text. There was also _considerable_
>discussion of the problem statement on the mailing list between IETF-97
>and IETF-99, and we reached general agreement on our problem statement on
>the mailing list.
>
>At IETF-99, we reviewed the charter text, which included our agreed
>problem statement as the first few paragraphs.  To wit:
>
>"The BANdwidth Aggregation for Network Access (BANANA) Working Group is
>chartered to develop solution(s) to support dynamic path selection on a
>per-packet basis in networks that have more than one point of attachment
>to the Internet.
>
>Bandwidth Aggregation consists of splitting local traffic across multiple
>Internet links on a per-packet basis, including the ability to split a
>single flow across multiple links when necessary.
>
>It is the goal of this WG to produce a Bandwidth Aggregation solution
>that will provide the following benefits:
>
>	€ Higher Per-Flow Bandwidth: Many Internet links available to homes and
>small offices (DSL, Cable, LTE, Satellite, VPNs, etc.) have relatively
>low bandwidth. Users may wish to run applications (such as streaming
>video, or content up/downloads) that require (or could benefit from) more
>bandwidth for a single traffic flow than is available on any of the local
>links. A Bandwidth Aggregation solution could supply the needed bandwidth
>by splitting a single traffic flow across multiple Internet links.
>	€ Reduced Cost: Traffic sharing on a per-packet basis allows the full
>bandwidth of the lowest-cost link to be used first, only using a
>higher-cost link when the lowest-cost link is full.
>	€ Increased Reliability: When one Internet link goes down, ongoing
>application flows can be moved to another link, preventing service
>disruption.²
>
>We went through the charter text, sentence by sentence, at the BOF and
>the only change we made to the problem statement portion of the charter
>was to add VPNs to the list of low bandwidth Internet links.  There was
>an opportunity to discuss every sentence in this section, but people
>didn¹t have much to say about it, probably because we had already spent
>months discussing it on the list and in a Bar BOF.
>
>During the question period at the end of the BOF, we asked whether the
>problem was clear and well-understood.  The large majority of  the people
>who responded said ³yes².  This was recorded in the minutes as a ³decent
>hum² for yes, and a ³low murmur² for no.
>
>> So, I do not
>> understand why we are jumping on charter text discussion without clear
>> agreements on the problem statement.
>
>Based on the agreement on the mailing list and in the room in Prague, I
>would say that we _do_ have agreement on a clear and understandable
>problem statement.  What makes you think we don¹t?
>
>> I really hope IESG will review all the notes/discussions carefully.
>
>I am sure that Suresh can be trusted to review things carefully before he
>puts our charter on the IESG agenda.  If there are any particular notes
>or discussion that you would like him to review, please feel free to draw
>his attention to them.
>
>Margaret
>
>