Subject: [Captive-portals] Fwd: [tsvwg] Network tokens draft

From: Kyle Larose <[email-masked]>
Date: Fri, 10 Jul 2020 12:01:05 -0400

I have only skimmed this, so it may not be appropriate, but I wonder if
this could be a starting point for the captive portal signal. Could this
address some of the concerns we had with ICMP?

---------- Forwarded message ---------
From: Tom Herbert <[email-masked]>
Date: Fri, Jul 10, 2020 at 11:52 AM
Subject: [tsvwg] Network tokens draft
To: tsvwg <[email-masked]>
Cc: Yiannis Yiakoumis <[email-masked]>

Hello,

This is a draft on "Network Tokens" which is a form of host-to-network
signaling for the purposes of providing a highly granular network
services and QoS to applications.

https://tools.ietf.org/html/draft-yiakoumis-network-tokens-01

There is also a mailing list in
https://www.ietf.org/mailman/listinfo/network-tokens

We are planning to present in tsvwg and app aware networking and
possibly have a side meeting on this topic in IETF108.

Thanks,
Tom

---

From: Erik Kline <[email-masked]>
Date: Sat, 11 Jul 2020 21:47:47 -0700

<no hats>

I fail to see how this is good for general purpose nodes/user devices.
This seems like another way to do the "self-DPI" work that was
shopping around for a home a little while ago.  I mean, it all just
seems like something that in the end can be abused to limit client
behaviour, dressed up as giving users new services and options ("you
don't implement tokens/have any tokens in your packets? too bad for
you").

On Fri, Jul 10, 2020 at 9:01 AM Kyle Larose <[email-masked]> wrote:
>
> I have only skimmed this, so it may not be appropriate, but I wonder if this could be a starting point for the captive portal signal. Could this address some of the concerns we had with ICMP?
>
> _______________________________________________
> Captive-portals mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/captive-portals