Re: [Banana] Charter

[Suresh Krishnan <[e-mail]>]

Hi Margaret,

> On Sep 21, 2017, at 11:54 AM, Margaret Cullen <[e-mail]> wrote:
> 
> Hi Dave,
> 
> It is not our intent to overlap with work in the BBF or the 3GPP.  It is also quite explicitly our intention to develop a multi-provider, “over-the-top” solution.  If that is unclear in the charter, we should make it clearer.
> 
> You wrote:
>> Over the course of the BANANA charter creation this positioning (i.e., BANANA = multi provider, OTT, not in conflict with the BBF) seems to have been increasingly diluted, resulting in the existing charter which, as noted below, gives license to deal with the entire space and seemingly casts aside the previous scope positioning and concerns.  
> 
> I’m not sure how this message has been “diluted", so I will need your help in un-diluting it.  Is there something in particular that was included in previous descriptions of this work that has been (perhaps unintentionally) removed from the current charter?  This is essentially the same charter text we have been discussing for 6+ months, and the same work we have been discussing for multiple years.
> 
> To break down your two points:  
> (1) The charter is unclear that this is intended to be a multi-provider solution.  The charter says:
> 
> "The Bandwidth Aggregation solutions developed in this group will be designed to work in multi-provider scenarios (i.e. they will not depend on all of the aggregated links being provided by a single Internet access provider)."
> 
> How would you change that sentence to make it clearer that these solutions will be multi-provider?  Would it help to say something about the BANANA solutions not requiring explicit cooperation between providers?  I think it would be acceptable to the group to add that wording, as we have been talking about solutions that would work with any set of providers, not just with a single provider or a cooperating set of providers.
> 
> (2) The charter does not say that this will be an OTT solution.
> 
> It is true that the charter does not explicitly say that we will develop an “over-the-top” solution. It is, however, the scope of the IETF to do IP-based, link-layer-independent work (except in unusual cases), and this work is no exception.  We don’t usually use the term OTT in the IETF, but I wouldn’t object to explicitly saying that this work will be an IP-based and link-layer-independent, if it would make things clearer for people who are not familiar with the usual scope of IETF work.  If there is some other property of OTT solutions that you think is important here, please let me know what it is.
> 
> Putting these together, along with the NAT change discussed earlier, I think we would end up with the following text:
> 
> "The Bandwidth Aggregation solutions developed in this group will work in true multi-provider scenarios (i.e. they will not depend on all of the aggregated links being provided by a single Internet access provider nor by a group of cooperating providers).  Any protocols defined by this group will be IP-based, link-layer-independent solutions, and they will be designed to work across NATs and other middle boxes, as needed."
> 
> Would this change address your concerns?  If so, I will post it in another thread for feedback from the list.  If not, could you suggest a specific change that would address your concerns?
> 
>> You also wrote:
>> Subsequent to the concerns noted above, the BBF has embarked on a project in cooperation with 3GPP to converge fixed access and the 5G core which would include hybrid access scenarios and fixed wireless access.  BBF and 3GPP currently have work underway and are looking to produce documents in the 3GPP Rel 16 timeframe.  
> 
> 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)”.

>  
> 
> Now, the BBF is starting a _new_ standardization effort (started _much later_ than the BANANA work), and you would like the IETF to further block or limit the BANANA work to avoid conflicting with this new effort.   It seems to me that the BBF is the one expanding the scope of their work, not the BANANA group.  
> 
> 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? 

> 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.

Thanks
Suresh