Re: [Banana] Updated Charter

[Florin Baboescu <[e-mail]>]

Hi Margaret,



I share similar opinion with the comments posted by Praveen and Sri below,
so I’m not going to go through the same comments again. However, I cannot
avoid coming back to the same comment/suggestion I had last week.

As you may remember, I expressed my concerns that the IETF is trying to
step into proposing one or more solutions that has already been covered by
both 3GPP and BBF. Unfortunately, in the case of IETF, I somehow miss
seeing proper requirements or problem statement(s), for which a consensus
can be achieved. Furthermore, a solution that introduces an aggregation
point in the 3GPP architecture, requires some more discussion and
understanding. But again, this is a discussion we may get into only if we
get an agreement first on what are we actually trying to solve!



Therefore, as I suggested earlier, if progress is to be made, let’s start
with the basics, which is to work on a set of requirements and a problem
statement that we all can agree. This should be the only scope of  the
conversation at least in the next IETF meeting.



Thank you.

-Florin







*From:* Banana [mailto:[e-mail]] *On Behalf Of *Sri
Gundavelli (sgundave)
*Sent:* Friday, September 29, 2017 6:48 AM
*To:* Margaret Wasserman <[e-mail]>
*Cc:* [e-mail]; [e-mail];
[e-mail]; [e-mail]; [e-mail];
[e-mail]
*Subject:* Re: [Banana] Updated Charter



Hi Margaret,



There is a value to having a standard, even if multiple proprietary
approaches continue to exist, IMO.



Various enterprises use various type of VPN solutions. Some are based on
IPsec, some on SSL and some on SSH.. etc. Those are non-interoperable
across solutions, but some are interoperable within a solution, when using
the same protocol.



To address this issue, IETF did not go create a "VPN working group" and
argued that all are proprietary solutions and so we need a single
interoperable solution, based on the protocol we choose.  So, what you have
been asking for three years is some thing new  We probably should bring
this Banana discussion in IETF plenary and ask IETF to change their work
scope.



Sri






On Sep 29, 2017, at 6:31 AM, Margaret Wasserman <[e-mail]>
wrote:

Hi Sri,



BANANA is the name of a proposed WG, not a protocol.  The candidates have
multiple different names.  What the final protocols, extensions or options
would be called is unknown, especially if they result from the merger of
multiple proposals, but I doubt any of them would be called "BANANA"...



There is a value to having a standard, even if multiple proprietary
approaches continue to exist, IMO.



Margaret



Sent from my iPhone


On Sep 29, 2017, at 9:04 AM, Sri Gundavelli (sgundave) <[e-mail]>
wrote:

Hi Nic,


On Sep 29, 2017, at 3:06 AM, "[e-mail]" <[e-mail]>
wrote:

I see here the risk that every WG comes up with a specific solution (e.g.
for QUIC, MPTCP, …). The might use different control mechanisms and

even different policies (e.g. QUIC might prefer WLAN over LTE, MPTCP LTE
over WLAN).



There will never be one God protocol which is the protocol for a solution.
QUIC/MPTCP/MobIKE/MIP/SSL/GTP are all candidate protocols that will be
enhanced and deployed for multipath related solutions. We cannot stop them
from extending those protocols.



We are mixing interoperability within a protocol, with interoperability
across solutions.

IETF is not in the business of mandating a specific protocol for a
solution, or strive for a single solution across internet. A vendor/SDO may
use "n" of protocols of his choice for a solution. We only ensure
interoperability within a protocol and not interoperability across
solutions. Again, IETF has not standardized "the routing protocol", or "the
IPv6 transitioning protocol" and there will never be, "The Banana
protocol".



Sri