I, for one, think "Document that the signaling protocol does not provide mechanisms for non-binary blocking." is where IETF tries to become a some sort of legal authority...
Hypothetically, what if a non-free captive portal network is legally requires to *allow* certain resources for free (in the walled garden, so to speak), but to comply with the IETF spec, networks indicate *nothing* available (except the captive portal)... Networks *can already* enforce captivity based on destination... limiting signaling only makes it impossible to be transparent about it!! At this point, I think you might as well remove the entire signaling section... It reads like propaganda against signaling as a concept.. then later has a entire section on the Nuisance factor of signaling, where it is suggested "it may be possible for any user on the Internet to send signals"... Hmm.. The section titled "Risk of Nuisance Captive Portal" should really be talking about networks that USE the API and have NO network integration (e.g. Captive by API only, not by any network enforcement function). Happy Holidays! Cheers, David On Thu, Dec 27, 2018 at 9:34 AM Kyle Larose <k...@agilicus.com> wrote: > This update is mostly a refresh until I can spend a bit more time on > it. Either way, it addresses some of the issues we raised in Montreal. > > Changes > ------------ > > Major Changes: > - Reduce the scope of the signaling protocol: > - Changed many SHOULDs to MAYs > - Clarified that the signal is a simple indication that traffic is > restricted. > - Document that the signaling protocol does not provide mechanisms for > non-binary blocking. > > Minor Changes: > - Some small changes to the diagrams > - Mention that the identity depends on the network attachment point > - Fixed spelling/grammar mistakes > - Fixed up some ambiguous phrasing > - Changed an example workflow to when conditions are about to expire, > rather than when they have already expired. > > > ---------- Forwarded message --------- > From: <internet-dra...@ietf.org> > Date: Thu, 27 Dec 2018 at 12:32 > Subject: [Captive-portals] I-D Action: > draft-ietf-capport-architecture-03.txt > To: <i-d-annou...@ietf.org> > Cc: <captive-portals@ietf.org> > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Captive Portal Interaction WG of the IETF. > > Title : CAPPORT Architecture > Authors : Kyle Larose > David Dolson > Filename : draft-ietf-capport-architecture-03.txt > Pages : 17 > Date : 2018-12-27 > > Abstract: > This document aims to document consensus on the CAPPORT architecture. > DHCP or Router Advertisements, an optional signaling protocol, and an > HTTP API are used to provide the solution. The role of Provisioning > Domains (PvDs) is described. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-capport-architecture/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-capport-architecture-03 > https://datatracker.ietf.org/doc/html/draft-ietf-capport-architecture-03 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-capport-architecture-03 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > 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 >
_______________________________________________ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
