Re: [Banana] Final(?) BANANA Charter Text

Margaret Cullen <mrcullen42@gmail.com> Wed, 20 September 2017 20:04 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 05667134326 for <banana@ietfa.amsl.com>; Wed, 20 Sep 2017 13:04:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level:
X-Spam-Status: No, score=-1.75 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, 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 7icGHkRJZk2n for <banana@ietfa.amsl.com>; Wed, 20 Sep 2017 13:04:37 -0700 (PDT)
Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (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 E49AD134303 for <banana@ietf.org>; Wed, 20 Sep 2017 13:04:36 -0700 (PDT)
Received: by mail-qt0-x231.google.com with SMTP id s18so4006488qta.3 for <banana@ietf.org>; Wed, 20 Sep 2017 13:04:36 -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 :content-transfer-encoding:message-id:references:to; bh=+mI+whrTr0qlkkUfbeF3KJtOFVlg8fm0DRijb1nlrsA=; b=lmzKAh+15ZuyIZMa/G8bqcxy4988Zv81NkNNzzOo6yvF7DFKvcBrlcGnhRUPu6Q6Mu DLc1FiUL66kVX6RF4K13eodq9ZZ7FlSrLutEodRvQ2JU5Gu6lZRV6MbTmJKeTjozsWwO cGplEjSGeQWlsCsX+eMp5AxumXtyP9XO+3exgcBWeJsJhT/3W4kVopgR2zWv5kIhDGB8 uhClR+u0XJIqiyUaUlt7vKJlmIrggJkBf/HAs3aBBdG2W0e7MwfCWwg3loCm2Gh2rKEX 1o2AM56qrcqRYcQkLBhdAtXn3WqWpqqJMvLci7HlpKxkb5y+j3oSah89apf4m0s8MmWD Jo0g==
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 :content-transfer-encoding:message-id:references:to; bh=+mI+whrTr0qlkkUfbeF3KJtOFVlg8fm0DRijb1nlrsA=; b=Oz+OK+2RdQ/xdnrwoa+rDPBxmakBCnxtVZ+ueF3433z+LGT7Y61A8V5304nQAQNy4B jAZjRXZLICL4veSAzoxuq8GH8qzLM6gUWiAeTWnHuKlPrJp1x6SlXA1/n31JtaxS/inR G1h0anxO2Mg5PMv9zF8MrFy4vjtf/91SrB4ZfCg9qAxNdyz8F2YYYrCFFvb2RlH0gL81 13WgaqDUVGfu4ojjsW4iOckyZOThIvqMQV0nBhst6kI/hWLwayQqNWQt06grLdhOisO7 d4HRjmQyOW5HXUTEVAGk9syIiAm8FfwOLSAS12eS7939pxwp3kNQCY/oBfL2ZLm7Pv8s lgNA==
X-Gm-Message-State: AHPjjUjSG4NH3IwK1kAwm6y2eWFlDrjJd79JEw7m54Nh4Gac8IsvG9Nl x2QR5XrGA9QUML9nXhmDzmvlorMp
X-Google-Smtp-Source: AOwi7QCWqg4dd5v1fzFVD7w0YU4Evpq6mkm9L0mW8Ca3pwhlRROzP9o8xUjwpQZeSCaC5fHyt4R93g==
X-Received: by 10.200.48.185 with SMTP id v54mr9065314qta.245.1505937876074; Wed, 20 Sep 2017 13:04:36 -0700 (PDT)
Received: from ?IPv6:2603:3005:2409:8400:70c7:d017:6cf2:e3f1? ([2603:3005:2409:8400:70c7:d017:6cf2:e3f1]) by smtp.gmail.com with ESMTPSA id s37sm1894495qts.27.2017.09.20.13.04.34 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 20 Sep 2017 13:04:34 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Margaret Cullen <mrcullen42@gmail.com>
In-Reply-To: <684675c57ad7497b9b7d498f853f6aa7@rew09926dag03b.domain1.systemhost.net>
Date: Wed, 20 Sep 2017 16:04:33 -0400
Cc: banana@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <A4CDAF19-4EF3-4454-B8DB-409F1E7071BE@gmail.com>
References: <5C26C1CC-DD97-4329-8ED0-6FF69F29AD2E@gmail.com> <684675c57ad7497b9b7d498f853f6aa7@rew09926dag03b.domain1.systemhost.net>
To: philip.eardley@bt.com
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/banana/7hndW7FXlda3TFzt5YEj_f2j82o>
Subject: Re: [Banana] Final(?) BANANA Charter Text
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: Wed, 20 Sep 2017 20:04:39 -0000

Hi Phil,

> On Sep 20, 2017, at 4:59 AM, <philip.eardley@bt.com> <philip.eardley@bt.com> wrote:
> What I want to make sure is that the protocols developed in work items 2 & 3 don’t assume or depend on the solution used for work item 4 (the "encapsulation"). Since there's work elsewhere in IETF on MPTCP and other possibilities. 
> I'm not sure the current wording is quite right ("additional" encapsulations" may give the wrong impression?).  
> maybe some wording on the lines:  
> it is assumed that there may be several alternative Banana encapsulation solutions, hence it is the aim of the WG that the protocols developed in work items 2 & 3 can work with different encapsulations / don’t restrict the encapsulation used / or something like this…

This is a good point.  I think there is general agreement about this, which is _why_ we split the signaling protocol off from the “encapsulations”, but it probably would make sense to make this more explicit.  I will try to come up with full wording for a proposed change and request feedback on it in another thread.
> 
> I also think that the term "encapsulations" will be confusing in the future when the caveat doesn’t appear in close proximity (ie when your warning "the use of the term “Encapsulation” does not mean that all BANANA Encapsulations will add an explicit encapsulation header" isnt in an adjacent sentence). Sorry, I don’t have alternative wording at this moment. 

I think we would all like a better word for “encapsulations”, but it is not clear what that word would be.  For a while, we were saying “transports”, but then the tunnel-based approaches didn’t fit in.  I am not sure what better wording would be, either…

> Margaret said:
> << I have proposed three changes to the charter to address issues that have been discussed on the list.  They can be found in three separate threads under the following subjects:
> 
> - Add mention of NAT/remove GRE
> - Problem Statement
> - Use of Existing IETF Protocols
>>> 
> For me, the changes improve the charter.

Thanks for the feedback!

Margaret