Subject: [Spud] questions on the BoF outcome

From: "Fossati, Thomas (Nokia - GB)" <[email-masked]>
Date: Fri, 22 Jul 2016 10:25:49 +0000

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

---

From: Szilveszter Nadas <[email-masked]>
Date: Fri, 22 Jul 2016 10:29:12 +0000

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:[email-masked]] On Behalf Of Fossati, Thomas
> (Nokia - GB)
> Sent: Friday, July 22, 2016 12:26
> To: [email-masked]
> 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:
> 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.
> 
> 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.
> 
> 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).
> 
> 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
> 
> _______________________________________________
> Spud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spud

---

From: Ian Swett <[email-masked]>
Date: Fri, 22 Jul 2016 10:48:47 -0400

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 <
[email-masked]> 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.
>
> any
> I'm
> looks
> send
> substantial

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 22 Jul 2016 07:57:11 -0700

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

-- 
---
Toerless Eckert, [email-masked]

---

From: G Fairhurst <[email-masked]>
Date: Fri, 22 Jul 2016 18:44:17 +0200

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:
>> On Fri, Jul 22, 2016 at 6:29 AM, Szilveszter Nadas<

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Sat, 23 Jul 2016 01:34:23 +0200

Hi, Toerless,

> Hum i the WG, or is there going to be a call here or whatever other

Thanks for asking.

I met with the BOF proponents for at least a couple of hours today/tonight,
and talked with them about next steps.

I don't plan to ask for opinions about the charter as proposed at this
time, in order to give the proponents and chairs time to take those next
steps (they have two and a half hours of opinions from about 250 people to
absorb now).

If PLUS moves forward, the complete process would be something like

   - proponents absorb feedback to date
   - proponents take steps based on that feedback
   - proponents hand Spencer a revised charter, a more formal problem
   statement, and whatever else seems appropriate
   - Spencer asks the IESG and IAB for comments ("internal review")
   - Spencer absorbs comments received from internal review
   - Spencer takes steps based on those comments
   - The IESG asks the community for comments ("external review"). This
   includes both the IETF community and other SDOs

(This is where you come in :-)

   - The IESG absorbs feedback we receive from external review
   - Spencer takes steps based on that feedback
   - Spencer places the resulting charter on an IESG telechat agenda for
   approval of WG creation

I hope that's helpful! And thanks for asking.

Spencer

> > > It is also not clear to me, is there still hope, or is it hat eating
> time?
> > > :)
> > >
> > > Cheers,
> > > Sz.
> > >
> > > > minutes [1] (thanks a lot, scribes) and got the feeling that this
> work
> > > is pushed
> > > > Well, that depends on the metadata that *users* decide to leak
> (which is
> > > a
> > > > pretty well designed to bias control towards the endpoints which can
> act
> > > as
> > > > useful information to the endpoints -- if it's asked to -- while
> being
> > > empowered