<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