Re: [Banana] Use of Existing IETF Protocols

Tommy Pauly <tpauly@apple.com> Tue, 19 September 2017 23:16 UTC

Return-Path: <tpauly@apple.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 0ADAF13307F for <banana@ietfa.amsl.com>; Tue, 19 Sep 2017 16:16:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 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_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 mDzFXkkzzQuE for <banana@ietfa.amsl.com>; Tue, 19 Sep 2017 16:16:11 -0700 (PDT)
Received: from mail-in22.apple.com (mail-out22.apple.com [17.171.2.32]) (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 AFB5E13303B for <banana@ietf.org>; Tue, 19 Sep 2017 16:16:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1505862970; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=zseuNP3Va2SBD6+wPkvYNvJO/8GBNztiAMS7d1o+DRQ=; b=Fc0SZUxOeHWDfxltXSyHkzABGxo8hUnd5exjasDHBlQbRx0vmKt33Kg4AevmTEWv RZFGv8DWWOJUF1VYkv7WKU+cb7CLiU8UXdl6PwMYE2Te3rU3x0/51/mE5vqbHMZK eObrP961mBvvnGZ0nbXbiWcx7rbfT1l2xHWX9OTJwdzIGFAJvb5OXMUDybU0/elk 64qtYIlwbUNJf0PQ47tlQQ2ihP34//x/RpBVY8eclPuvxC8B9eBvgRP1281qWbnN tPkXHSf1w4OcdLGYTg0hSbHYrT/CCNEruBg5ajsamPFfpYdlB+EMWvsWBD2AWYpq gOvRLGt8XpoDwodnUYca/Q==;
Received: from relay3.apple.com (relay3.apple.com [17.128.113.83]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in22.apple.com (Apple Secure Mail Relay) with SMTP id 48.5D.14095.A35A1C95; Tue, 19 Sep 2017 16:16:10 -0700 (PDT)
X-AuditID: 11ab0216-7144d9c00000370f-6e-59c1a53a0b17
Received: from nwk-mmpp-sz11.apple.com (nwk-mmpp-sz11.apple.com [17.128.115.155]) by relay3.apple.com (Apple SCV relay) with SMTP id 7F.86.09863.A35A1C95; Tue, 19 Sep 2017 16:16:10 -0700 (PDT)
MIME-version: 1.0
Content-type: text/plain; charset="utf-8"
Received: from [17.234.123.233] by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.1.3.20170825 64bit (built Aug 25 2017)) with ESMTPSA id <0OWJ009X5VAEGW70@nwk-mmpp-sz11.apple.com>; Tue, 19 Sep 2017 16:16:10 -0700 (PDT)
Sender: tpauly@apple.com
From: Tommy Pauly <tpauly@apple.com>
In-reply-to: <DEC78849-1E63-470D-89F5-683CCA115C6F@gmail.com>
Date: Tue, 19 Sep 2017 16:15:48 -0700
Cc: banana@ietf.org
Content-transfer-encoding: quoted-printable
Message-id: <3FE47F52-C651-4E88-B25D-153102462402@apple.com>
References: <DEC78849-1E63-470D-89F5-683CCA115C6F@gmail.com>
To: Margaret Cullen <mrcullen42@gmail.com>
X-Mailer: Apple Mail (2.3439)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOLMWRmVeSWpSXmKPExsUi2FAYrGu19GCkwbRec4uHJ3awWFz+sIPN gclj56y77B5LlvxkCmCK4rJJSc3JLEst0rdL4MpY9esSa0GPUMXWmxtZGhhP8HUxcnJICJhI dEzeydTFyMUhJLCGSWLDrzusMIm313+wQiQOMUp8P7+ZESTBKyAo8WPyPZYuRg4OZgF1iSlT ciFqvjFKrNi5gx0kLiwgIbF5TyJIuTDQnPnbHjGD2GwCKhLHv21gBinhFLCVuL3YGyTMIqAq MenrZ7C1zALCEu9WTmWBsLUlnry7wAqx1UZiZstMsOlCQHbnZ14QU0RAS2LmEWMQU0JAVmLp nxCQWyQE/rJK9P17xDaBUXgWkpNnIZw8C8n8BYzMqxiFcxMzc3Qz84yM9BILCnJS9ZLzczcx gkJ6NZPYDsZ7rw0PMQpwMCrx8AZYHYwUYk0sK67MPcQozcGiJM7rOAMoJJCeWJKanZpakFoU X1Sak1p8iJGJg1OqgVF6+l/+5fPXC8hautls4pvcf8HhYhuX0nEhpv3d2w4mbfOV/9a2v+7N 8j0TZ564IXIu7uK9Mr73EWqvg9Z5eD/e3jcv0mlllfi0oF2bK6dqOH99de6DcNK1ADveiJeu E6RiWt7JyJwRXKeVltff06XYXvxsydWf/3+t9Jjtb8Avek1PiMmj3lmJpTgj0VCLuag4EQAs 3v7zSgIAAA==
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJLMWRmVeSWpSXmKPExsUi2FA8W9dq6cFIg8ft8hYPT+xgsbj8YQeb A5PHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJWx6tcl1oIeoYqtNzeyNDCe4Oti5OSQEDCR eHv9B2sXIxeHkMAhRonv5zczgiR4BQQlfky+x9LFyMHBLKAuMWVKLkTNN0aJFTt3sIPEhQUk JDbvSQQpFwaaM3/bI2YQm01AReL4tw3MICWcArYStxd7g4RZBFQlJn39zApiMwsIS7xbOZUF wtaWePLuAivEVhuJmS0zwaYLAdmdn3lBTBEBLYmZR4xBTAkBWYmlf0ImMArMQnLlLIQrZyEZ uYCReRWjQFFqTmKlsV5iQUFOql5yfu4mRnAAFgbvYPyzzOoQowAHoxIPb4DVwUgh1sSy4spc YDBwMCuJ8BrkAIV4UxIrq1KL8uOLSnNSiw8xSnOwKInz5s4ASgmkJ5akZqemFqQWwWSZODil GhgZTsteXsfkqvsoYuOefdF8AbtmX7K4PDnsj9eDzuT8gnj/SzIGBad1BVM/xPeyztysWPn2 agHL4q/9kx1UXUL8M6fof49P498YUBW0ueG0xKQJsp3KtubivZFCK07yrtsZ6LZ1/5rN2+Im vP66/yNr25QHPW6ZUX/WmzMmvb+rsOYv5yqP39pKLMUZiYZazEXFiQA5jLVoPAIAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/banana/Q-tEgvHtjTUxO1VUKpDxywtN4Ak>
Subject: Re: [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 23:16:14 -0000

This approach looks good to me. I think we could be still more explicit that the intention is to use existing protocols, if we'd like to err on that side.

"When applicable, the BANANA WG will use existing IETF protocols, or extensions to existing IETF protocols, as the basis for the work items listed above.  Whenever an existing protocol is used, the WG deliverable will 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."

This is just a more extreme version; your proposed text would work quite well as-is.

Thanks,
Tommy

> On Sep 19, 2017, at 5:44 AM, Margaret Cullen <mrcullen42@gmail.com> wrote:
> 
> 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
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Banana mailing list
> Banana@ietf.org
> https://www.ietf.org/mailman/listinfo/banana