Hi David, Thanks for the read-through. Some responses inline!
Best, Tommy > On Jul 2, 2018, at 7:48 AM, David Bird <[email protected]> > wrote: > > Some comments (will not be at meeting) > > Section 1. The introduction states the purpose of the API as: > > o The state of captivity (whether or not the host has access to the > Internet) > > o A URI that a host's browser can present to a user to get out of > captivity > > o An encrypted connection (TLS for both the API and portal URI) > > The state of captivity is not all or nothing and being detailed about > "captivity" (e.g. listing walled garden resources up front, down to protocol, > port, hostnames, etc) will be complex and error prone. The URI for the > captive portal can be gotten by RFC 7710. Captivity signaling should be > granular; because we can, and it includes more use-cases. Agreed. The fundamental thing about this API draft is that it is not the exhaustive set of information that the portal may want to communicate to the UE. The example of the state being captive or not is a very simple case, and there can certainly be more values to pass down. > > Section 2. The workflow is stated as: > > 1. Provisioning, in which a host discovers that a network has a > captive portal, and learns the URI of the API server > > 2. API Server interaction, in which a host queries the state of the > captive portal and retrieves the necessary information to get out > of captivity > > 3. Enforcement, in which the enforcement device in the network > blocks disallowed traffic, and sends ICMP messages to let hosts > know they are blocked by the captive portal > > My issue is with the ordering... At step 2, we have Capport compliant devices > enforcing themselves.. while non-Capport devices wait for the network > enforcement. We have the (likely) scenarios of API server saying one thing > (implying "self enforcement"), while the network "Enforcement" is telling the > UE something else... who is right? Answer: always the network. This workflow is the summary of of the CAPPORT architecture document. I completely agree that the enforcement is handled by the network, which is why this is all in the third step. The API server does not imply enforcement—It's the way for the portal that is doing enforcement to communicate information to the UE. Non-CAPPORT devices currently do: 1. Provisioning, without knowing about captivity - 3. Enforcement via blocking and redirects, in which UE's need to guess what happened The enforcement is always the network, but the UE can provide a better user experience with 2. > > Section 3.2. I think the JSON keys represent a too narrow view of walled > gardens, and while simplicity is good, here it artificially and severely > limits use-cases. > > Obviously, the "permitted" field is a boolean, not reflecting the fact the > location very likely has freely available resources in the walled garden. > > The "expire-date" and "bytes-remaining" will be hard to synchronize with > network enforcement... the enforcement function might not be counting *all* > bytes (some might be "free"), session expiry could happen because of time > and/or data limits - possibly being consumed by multiple concurrent > devices/sessions - but also things like Idle Time or software restart (NAS / > AP / etc) or a number of reasons. As mentioned above, this is just the basic set of minimal keys. It is intended to be extendable as we flesh out the use cases. > > What would be useful in the API, in my opinion, is for the API to provide a > sort of validation, authentication, and additional information for and about > network notifications. Yes, I agree! This was partly discussed at the last meeting; when we had the HMAC key to validate network notifications, we decided to remove that until we had further specified the use cases for validating the network notifications. > > On Sun, Jul 1, 2018 at 10:35 AM <[email protected] > <mailto:[email protected]>> wrote: > > 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 : Captive Portal API > Authors : Tommy Pauly > Darshak Thakore > Filename : draft-ietf-capport-api-01.txt > Pages : 7 > Date : 2018-07-01 > > Abstract: > This document describes an HTTP API that allows hosts to interact > with a Captive Portal system. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-capport-api/ > <https://datatracker.ietf.org/doc/draft-ietf-capport-api/> > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-capport-api-01 > <https://tools.ietf.org/html/draft-ietf-capport-api-01> > https://datatracker.ietf.org/doc/html/draft-ietf-capport-api-01 > <https://datatracker.ietf.org/doc/html/draft-ietf-capport-api-01> > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-capport-api-01 > <https://www.ietf.org/rfcdiff?url2=draft-ietf-capport-api-01> > > > 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 > <http://tools.ietf.org/>. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/> > > _______________________________________________ > Captive-portals mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/captive-portals > <https://www.ietf.org/mailman/listinfo/captive-portals> > _______________________________________________ > Captive-portals mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/captive-portals
_______________________________________________ Captive-portals mailing list [email protected] https://www.ietf.org/mailman/listinfo/captive-portals
