Re: [Banana] Charter

Margaret Cullen <margaretw42@gmail.com> Fri, 22 September 2017 12:57 UTC

Return-Path: <margaretw42@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 7FF47134330 for <banana@ietfa.amsl.com>; Fri, 22 Sep 2017 05:57:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level:
X-Spam-Status: No, score=-2.449 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 B_JcjxSqLMyW for <banana@ietfa.amsl.com>; Fri, 22 Sep 2017 05:57:27 -0700 (PDT)
Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (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 D8264132F76 for <banana@ietf.org>; Fri, 22 Sep 2017 05:57:26 -0700 (PDT)
Received: by mail-qk0-x232.google.com with SMTP id c69so905139qke.8 for <banana@ietf.org>; Fri, 22 Sep 2017 05:57:26 -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=LHgCFCC3aEffTAY2osbttmugVj/lA+5ihOX3ai1MnZM=; b=qqUEzK142H/RbZdZMKUIYErOXO6gv4b4JVnBmJpf8RkObRQMi2DiyY83hqpR7F0k4Y Mk6X13S/V2CQHaxrd/otyqmsgbAk9Abc1LYzpnzyTq1b4zKPDO1+UImgMvBvjgMKwnUF 89Un5Zl6wCLwsS+ovM3/Kjj8sR05MWDvTjFtBWyjSZjRpUkZ3Qea30RGTq+DlMnicFB/ ixeXhcxn4SQRqPI4v/oquJC8YWrGRj5v0JcV+mwdduaG7qs0abodUS0n+FAlbmZz6UGq Wy2n7518qNc5a0e6XBNJf36biNr9c7+gBzd/Pn0UdYZfRfqYgO2EJSNyUqKeWF6JLYLG 52lA==
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=LHgCFCC3aEffTAY2osbttmugVj/lA+5ihOX3ai1MnZM=; b=riwUCXrNo9uJfPip5EbcniM78nHZfqXfZm+tNasgaP1bIsbQ/IWlUNPLMlbYLOXCRY T35coUU/2ECuBdkPCW71wVBKtsD3zwJy4lJ6oRzuctavPiO2lqwbMX4+NcLNKY0qYq0A gdxyFWo97XhU255PHPLaxQoHKZmX3PY+PzeciFBJVy59DjDzzH09cPmBO8hJNXBgLfls YIJkYLFaZKMK93Wktoi64KwB/bI8WvPEobfCNwZ3hDo+Yvsdnp4UyIkIbyoAMpSO9H8l eIWGivNQ1yqvKNfPbLQgtIrrWs9Co1rFhk3gyFZiRm6dt0wzm6fakNXRsrutKzubi/GO 48UA==
X-Gm-Message-State: AHPjjUjywLQyy7zKyhp/GK6oOXYXYkfWQhTsHBx1hqaB6FM+T5XboHNC quTvdQbIsHgDN0CGSKLlJqg=
X-Google-Smtp-Source: AOwi7QAKIdmT+3JaPoIYAs9E1jhPD//QZIwKKCeDGtvFmrGujjT2gQ+6hB4tZ1eD5cfqnRF52DIq8A==
X-Received: by 10.55.150.199 with SMTP id y190mr8152440qkd.180.1506085045814; Fri, 22 Sep 2017 05:57:25 -0700 (PDT)
Received: from ?IPv6:2601:18c:503:a54a:a5ca:96f5:38c5:54dd? ([2601:18c:503:a54a:a5ca:96f5:38c5:54dd]) by smtp.gmail.com with ESMTPSA id z192sm2633532qka.91.2017.09.22.05.57.24 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 22 Sep 2017 05:57:24 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_25337CF8-30F3-46E8-97BB-F378B4A9D44E"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Margaret Cullen <margaretw42@gmail.com>
In-Reply-To: <AA18EE02-CC24-46FB-B3F7-3865387BD178@gmail.com>
Date: Fri, 22 Sep 2017 08:57:23 -0400
Cc: David Allan I <david.i.allan@ericsson.com>, "Muley, Praveen (Nokia - US/Mountain View)" <praveen.muley@nokia.com>, "Sri Gundavelli (sgundave)" <sgundave@cisco.com>, Alexandre Petrescu <alexandre.petrescu@gmail.com>, David Sinicrope <david.sinicrope@ericsson.com>, "Henderickx, Wim (Nokia - BE/Antwerp)" <wim.henderickx@nokia.com>, "banana@ietf.org" <banana@ietf.org>
Message-Id: <BA189AE8-07ED-4D8A-94FF-DCB0555F1196@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> <HE1PR0701MB21884F35D61DDA53426CDCBEEA9C0@HE1PR0701MB2188.eurprd07.prod.outlook.com> <D5DE884A.28A3E7%sgundave@cisco.com> <ABACEE0C-8ED6-468B-9746-923321CCCCBB@gmail.com> <E6C17D2345AC7A45B7D054D407AA205C68F5500E@eusaamb105.ericsson.se> <A9F6ED60-98F7-4014-91C1-F7634E51DB2B@ericsson.com> <B6ED8E95-B68C-4EC9-934C-B28AA1CB3587@gmail.com> <AA18EE02-CC24-46FB-B3F7-3865387BD178@gmail.com>
To: Suresh Krishnan <suresh.krishnan@gmail.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/banana/q1vyT0zkSbTrAJXcuIoFraHOsnU>
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, 22 Sep 2017 12:57:29 -0000

Hi Suresh,

>> Prior to the announcement of the 5G work, it had been stated openly that the BBF planned to produce a requirements document for “hybrid access”, and then the BBF would look at protocols from other standards bodies, such as the IETF, to determine how to meet those requirements.  The BANANA effort was blocked (for over a year, with no discussion on the BANANA list or even a statement on the list explaining why) until the BBF’s requirements were published, so that our work would not interfere (in some unspecified way) with the BBF requirements effort.  After the BBF requirements document was published, the BBF withdrew its objection to the BANANA work proceeding in the IETF.
> 
> Can you please elaborate on the things you mention in this paragraph? Specifically "The BANANA effort was blocked (for over a year, with no discussion on the BANANA list or even a statement on the list explaining why)”.

I don’t know a lot more about this than I said, but I can give you a bit more of the history, I guess…  A couple of years ago, when Brian Haberman was still an Internet AD, we first approached him about bringing the BANANA work into the IETF.  We were told at the time that we couldn’t bring this work into the IETF because of a conflict with the BBF.  Since it was my understanding that the BBF was doing requirements work, and we were planning to do solutions work, I didn’t understand why there was a conflict.  Brian set up a meeting between me and Dave Sincrope that Brian did not attend.  I think David Allan was there, too?  At that meeting, I was told that the IETF and BBF had agreed that the IETF would not do work in this area until the BBF had completed their requirements work, after which the BBF would be looking to the IETF and others to provide solutions in this space, and our work would be unblocked.  I wasn’t very happy with that agreement, but it was clear that I was being informed of the decision not being asked what I thought of it.  I don’t know what group of people made that decision or where it was documented, if anywhere.  The bottom line was that our AD had told us we couldn’t charter this work in the IETF until the BBF finished their requirements document, so we waited.  After the requirements work was published, the work seemed to be unblocked and we have been working with you, Suresh, to charter this work in the IETF.

[Somewhat tangentially, I was also working on an Independent Stream RFC documenting Huawei’s deployed solution in this space, and that document was also blocked until the BBF completed it’s requirements work.  Once the requirements work was completed, that work was unblocked, and the document has been published as RFC 8157.]

I know that the IAB and IESG have advised us to focus the BANANA work on multi-provider solutions in response to our initial BOF request, and the group has agreed with that advice.  I personally think that the multi-provider case is a much more interesting problem space, and more central to the IETF’s scope.  Our charter currently states (as it has for the past 6+ months) the our solutions will be designed for multi-provider scenarios.  So, it is not that I object, at all, to that scope.  I have suggested text to Dave to make the scope of the work clearer, and if he says that it will address his concerns, I will call it out in a separate thread to see if the rest of the group has any comments.

In Dave Sincrope’s recent message, though, it seemed to me that he was claiming that we have a new agreement with the BBF to only do multi-provider, OTT work in this space that does not overlap with the new BBF/5G work?  Am I misunderstanding something there?  If there is such an agreement, when and how was that agreement made, who was involved in making it, and where was it recorded?  

Dave is also clearly suggesting that we should seek BBF review and acceptance of the BANANA charter before we charter this work in the IETF.  Was the IETF asked to review and accept the charter for the BBF/5G cooperation before that work was officially started in the BBF?  If so, where was that discussed, and what was our reply?

>> 
>> Personally, I object strongly to the notion that the IETF should block or reject work on end-user-controlled, multi-provider, IP-based, link-layer-independent solutions
> 
> I think this is a strawman. Is there anybody suggesting this? 

Sorry, this was probably an overreaction on my part.  While I still agree with what I said, please allow me to withdraw the implication that anyone might be trying to do otherwise.  
> 
>> because they “conflict" with provider-controlled (single-provider or cooperating-provider) solutions, or with solutions that are only applicable to specific link layer technologies (i.e. BBF/5G) thus only serving a subset of Internet users. 
> 
> In my view the conflict is about whether the the "provider-controlled (single-provider or cooperating-provider)" part is in scope of the charter or not. I don’t think we can have a meaningful conversation unless we state this in the charter one way or another.

The charter currently says that we will work on solutions for multi-provider scenarios, and it has said that for the past 6+ months.  I have proposed some wording to make that clearer and stronger, and I am waiting to see if that wording addresses Dave’s concern before asking for feedback on that change from the entire BANANA group.  If this is really all that is necessary to resolve a possible conflict with the BBF, then there should be no problem, at all.

Margaret