Re: [Spud] questions on the BoF outcome

[G Fairhurst <[e-mail]>]

I'm also hoping this proceeds. We need a framining like this to allow us 
to continue transport inovation.

Being able to see, but also protect (MAC) certain protocol fields in the 
transport header seems a positive step towards ensuring end-to-end 
semantics as we look at new protocols. From this perspective, it is sooo 
much better than using a TCP header field, RTP option, or IPv6 header.

Gorry

On 22/07/2016, 16:57, Toerless Eckert wrote:
> Whats actually the official process for asking for support - only
> Hum i the WG, or is there going to be a call here or whatever other
> mailing list ?
>
> If anyone is counting, here's one in favor of Plus WG.
>
> Use-case: Controlled network edge to Internet firewalls wanting to have similar
> flow recognition to TCP for UDP flows with replay-safe intent to receive
> indication.
>
> Cheers
>      Toerless
>
> On Fri, Jul 22, 2016 at 10:48:47AM -0400, Ian Swett wrote:
>> I hummed no largely because I felt I didn't clearly understand the work of
>> the group, and hence couldn't evaluate whether it was possible and
>> desirable.
>>
>> I personally would have preferred a clearly scoped set of initial use
>> cases, with other use cases of potential future interest requiring a
>> re-charter.
>>
>> I believe there are a lot of people interested in something along these
>> lines, so my no hum was not an expression they should stop trying to move
>> forward with a WG.  I also want to continue having the conversation about
>> what the path needs at the IETF, because it comes up fairly often, but I
>> feel there's currently no coherent forum for the conversation.
>>
>> It would be great to see some amount of running code as well, with some
>> clearly improved metrics for that particular use case.  I would hope small
>> scale experiments would inform the WG on what topics may warrant a
>> re-charter.
>>
>> On Fri, Jul 22, 2016 at 6:29 AM, Szilveszter Nadas<
>> [e-mail]>  wrote:
>>
>>> Hi,
>>>
>>> Some other argument was e.g. overhead. There was a significant amount of
>>> "NO" hums for the first question, the rest of the questions was not even
>>> asked.
>>>
>>> It is also not clear to me, is there still hope, or is it hat eating time?
>>> :)
>>>
>>> Cheers,
>>> Sz.
>>>
>>>> -----Original Message-----
>>>> From: Spud [mailto:[e-mail]] On Behalf Of Fossati, Thomas
>>>> (Nokia - GB)
>>>> Sent: Friday, July 22, 2016 12:26
>>>> To: [e-mail]
>>>> Subject: [Spud] questions on the BoF outcome
>>>>
>>>> Hi,
>>>>
>>>> Unfortunately I could not attend the PLUS BoF.  So, I've just gone
>>> through the
>>>> minutes [1] (thanks a lot, scribes) and got the feeling that this work
>>> is pushed
>>>> back due to the perception that it'd weaken users' privacy?
>>>>
>>>> I hear these arguments:
>>>> - "potential to compel clients to send metadata or packets will dropped"
>>>>
>>>> But that could have happened already if the network wanted to (just drop
>>> any
>>>> TCP payload that starts with 0x16 and allow only clear-text traffic!).
>>>>   Access networks that you pay for do not have that incentive though, so
>>> I'm
>>>> very skeptical this could now happen *because of* PLUS.
>>>>
>>>> - "possibility for abuse"
>>>>
>>>> Well, that depends on the metadata that *users* decide to leak (which is
>>> a
>>>> separate discussion on the vocabulary), but in general Brian's framework
>>> looks
>>>> pretty well designed to bias control towards the endpoints which can act
>>> as
>>>> circuit-breakers at any point in time.
>>>>
>>>> - "giving more power to the network";
>>>>
>>>> This is actually true, but in a good way: the network will have power to
>>> send
>>>> useful information to the endpoints -- if it's asked to -- while being
>>> empowered
>>>> by the signalling coming from the endpoints (e.g., for DDoS prevention).
>>>>
>>>> So, sorry but this looks a lot like FUD to me.
>>>>
>>>> Is the working group not formed on these grounds?  Or have more
>>> substantial
>>>> weaknesses been highlighted during the discussion that have not been
>>>> captured in the minutes?
>>>>
>>>> Cheers, thanks,
>>>> t
>>>>
>>>> [1] http://etherpad.tools.ietf.org:9000/p/notes-ietf-96-plus
>>>>
>>>> _______________________________________________
>>>> Spud mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/spud
>>> _______________________________________________
>>> Spud mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/spud
>>>
>> _______________________________________________
>> Spud mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/spud
>