Re: [Banana] Charter

[Margaret Cullen <[e-mail]>]

Hi Dave,

I am still trying to find a charter or other description of the BBF/5G protocol work, so that we can potentially reference it in our charter, and so that I can make a recommendation to the IESG regarding what group(s) should be apprised of this work.

As I mentioned, I am not a member of the BBF, but I have asked some members to help me find a pointer to this charter, and they couldn’t find it either.  They only found the charter for the requirements work.  They were also under the impression that the BBF doesn’t do this sort of protocol work?  Has the protocol work actually been chartered in the 3GPP?  If so, do you have a pointer to that charter or a description of that work?

I could use some help understanding the scope and state of the protocol work you have referenced.

Thanks,
Margaret


> On Sep 22, 2017, at 1:23 PM, David Sinicrope <[e-mail]> wrote:
> 
> Margaret,
> Please let me address a few of your points. 
> 
> First let me address the accusation of “using the threatening tone”. This is a serious accusation and one I believe to be unfounded. At no point is the language I am using making threats. I am simply stating the potential negative impact of overlap to the BBF-IETF relationship and suggest a corrective course of action.        
> 
> I do not understand your statement/accusations about me or the BBF blocking work or the BBF releasing objection to the BANANA work. All work in the IETF is done according to the IETF process and I’m not aware of any part of the IETF process that lets another organization or individual block or release work. 
> 
> As far as being willing to help and the “hats” I wear, I believe I have made it clear that I have been participating in my role as the IETF Liaison Manager to the Broadband Forum.  At each BANANA BoF I have attended (all but Yokohama), I have tried to help the work progress by advising that the work scope not overlap with the BBF.    Scoping the work to avoid overlap will provide clearer direction, and in turn avoid debate and lead to faster progression of the work. 
> 
> As for the proposed alternative wording, I appreciate your attempt to accommodate the concerns I raised and avoid the scope overlap I highlighted.  I think the changed text is a marked improvement toward avoiding overlap.  I stand by the suggestions I have made in my previous email, including liaising a draft of the charter, once stable, to the BBF and requesting their input.  I cannot advise what the BBF position would be on a charter they have not seen.  I believe liaising the draft charter would not only provide BANANA with important feedback, but also would be seen as a gesture of goodwill helping foster a cooperative IETF-BBF relationship on this topic.
> 
> I look forward to finalizing the BANANA charter and a cooperative and productive work relationship between the IETF and BBF on this topic.
> 
> Regards,
> Dave Sinicrope
> BBF/IETF Liaison Manager 
> 
> 
> On 9/21/17, 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.  
> 
>    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 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. 
> 
>    Dave, what hat were you wearing when you wrote this message?  Ordinarily if the BBF’s liaison to the IETF wrote to a WG or BOF mailing list that I was chairing claiming some sort of conflict with the BBF’s work and using the threatening tone you have assumed here, I would talk to the IETF’s liaison to the BBF and  get their help in resolving the situation.  In this case, though, the IETF’s liaison to the BBF is also you.  So, I guess I have no recourse but to ask you to help us figure out how to position the BANANA work so that the BBF will understand that we are intending to do a true multi-provider, OTT solution, that this work is in scope for the IETF, and that it does not conflict with the BBF’s work.  Do you think you will be willing and able to do that?  
> 
>    Margaret
> 
> 
> 
> 
> 
> _______________________________________________
> Banana mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/banana