[Banana] Use of Existing IETF Protocols

Margaret Cullen <mrcullen42@gmail.com> Tue, 19 September 2017 12:44 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 642FC1342ED for <banana@ietfa.amsl.com>; Tue, 19 Sep 2017 05:44:53 -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 20T8erNiSmJW for <banana@ietfa.amsl.com>; Tue, 19 Sep 2017 05:44:52 -0700 (PDT)
Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (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 B1DF513431E for <banana@ietf.org>; Tue, 19 Sep 2017 05:44:17 -0700 (PDT)
Received: by mail-qt0-x230.google.com with SMTP id t46so3526513qtj.2 for <banana@ietf.org>; Tue, 19 Sep 2017 05:44:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=3s6BKzTjsEmPwJH5vDVHYkBnpHwjuC9xN0wKz3NWDAc=; b=LKOb7esNrzwFCD6yY8Ht6tLww6j2f7Nxslz0upYuuyRlHxg1hshfRF8p0D+ooU5OFp sARaOFkE1NFoQH1LX4UHYuBPqghEc9IXdm4azKGU+NTIIrLbmNBasgTMT8h+34DTR9j/ NGKzB1piQ/duZkt0BGuGKRhd1mZ6Fza97UWU+wAFRdGWHc2geEfgPKVU6Jy711Aovmhj p09CATLnZ54wiUoEvdBDUdjLsTvs093Vb98c1uTGAtsBx+cRzgVxqgyPBbms25wDdz8r bp9Yef3IK7WkY5rmjDI/EeuIkV6VTSSwTmq5eOOFsvJwQr+D0S4b6DH24P/hCG4MKSRJ J6EA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=3s6BKzTjsEmPwJH5vDVHYkBnpHwjuC9xN0wKz3NWDAc=; b=Mvrq5/EY6PcsfXBd1nM8Pyw6YQ9RQtYeNQLypgbDekcFAiP7Tu5YF+Yf/F3bKuC4Zn S+c2ebP3DqoY9hQbVl3TyDnSNJcY1UOh/rWPiGT8UyIcGLwzHWTbWyUxD/TkwNsHe+9r Dxgs9yl/2bJ9Bmi2iUkqlzjvZ4Cf486MxMVPtHa66cSfjVGxXTFCb85/5/34PZlBsqIH LAdOeMPPhPUqDIhLrlIUJmZcTXMHv/XN0jM4mMSamexx0i1GgTfNih9mvlmYg7d5IzTl GWeO7tzHyEL6bIuf2pQLBD1wCM3xqfY9ywpy5kUaNRd2bp1TtLcUfCS4i0XO334Yd6Ov JlNg==
X-Gm-Message-State: AHPjjUgs8PZJo2B/kDF7pRf9NepzPiFaaUBB+WqtciYGdBR8rGXcBRNj fbifLZnK+vLQqj7KimPimTzZslJv
X-Google-Smtp-Source: AOwi7QD96b9cP781QyJL+E2FnXQhYSQUjNGh04WqcTvDkBjXA8ytr9s+wb66t/jX7WLiWl1btyahCg==
X-Received: by 10.200.50.218 with SMTP id a26mr1775467qtb.211.1505825056478; Tue, 19 Sep 2017 05:44:16 -0700 (PDT)
Received: from ?IPv6:2601:18c:503:a54a:803d:78b:1b05:c51b? ([2601:18c:503:a54a:803d:78b:1b05:c51b]) by smtp.gmail.com with ESMTPSA id h40sm6741728qte.73.2017.09.19.05.44.14 for <banana@ietf.org> (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 19 Sep 2017 05:44:15 -0700 (PDT)
From: Margaret Cullen <mrcullen42@gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <DEC78849-1E63-470D-89F5-683CCA115C6F@gmail.com>
Date: Tue, 19 Sep 2017 08:44:13 -0400
To: banana@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/banana/EXXEOU9jeSqffnwYVpDYgFOkh_0>
Subject: [Banana] Use of Existing IETF Protocols
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: Tue, 19 Sep 2017 12:44:53 -0000

The current text in the charter can be interpreted to say that we intend to produce three new “BANANA protocols" for provisioning, signaling and encapsulation, even if there are existing IETF protocols that would work for that purpose.  I don’t think that was anyone’s intention.  For instance, I think we would all expect to produce a DHCP option or RA record, or something similar, for provisioning, rather than inventing a new provisioning protocol.  To make this more clear in the charter, I would propose the following change:

OLD:

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

NEW:

The BANANA WG will consider existing IETF protocols, or extensions to existing IETF protocols, as the basis for the work items listed above.  If an existing protocol is used, the WG deliverable could be a document describing the use of that protocol for Bandwidth Aggregation and/or a set of options or extensions to an existing IETF protocol to make it useful for Bandwidth Aggregation.

Thoughts?

Sri, would this address your concern about the WG intending to produce three new protocols, even if suitable IETF protocols already exist?

Margaret