<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 <eomerea...@gmail.com> 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?
>
> ---------- Forwarded message ---------
> From: Tom Herbert <t...@herbertland.com>
> Date: Fri, Jul 10, 2020 at 11:52 AM
> Subject: [tsvwg] Network tokens draft
> To: tsvwg <ts...@ietf.org>
> Cc: Yiannis Yiakoumis <yian...@selfienetworks.com>
>
>
> 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
>
> _______________________________________________
> Captive-portals mailing list
> Captive-portals@ietf.org
> https://www.ietf.org/mailman/listinfo/captive-portals
_______________________________________________
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals
