Re: [Captive-portals] I-D Action: draft-ietf-capport-api-00.txt

[Lorenzo Colitti <lorenzo@google.com>]

On Tue, Feb 6, 2018 at 6:41 AM, David Bird <dbird@google.com> wrote:

Over the years on this list we have seen many use-cases come through, I recall:

-  A school/library network that allows most of the Internet, but captures and redirects for certain networks / sites

-  A network allows all sorts of protocols - IMAP, HTTPS, for example - but not others - like HTTP, SMTP - and want to redirect / signal portal

-  A network that allows all Internet traffic, but just at a low QoS tier. No "captive" portal, but a portal is  yet available for upgrading tier

-  Any network that allows a large walled garden, or even a *very large* garden, but otherwise has a captive portal

-  A network that will 99.99% of the time allow all traffic, but will (perhaps because of virus detection) interrupts sessions  into captive state [technically, this is a "boolean" use-case, but one where polling would just be huge noise]

I don't see why you would want to signal any of these to the UE, because they're not really actionable. Even if the UE distinguishes between these categories, application developers are likely not going to want to do so and in the main are going to do whatever the UE decides to do. As Martin says, the human using the UE might be interested (e.g., in the upgrading case), but that's not hard to do by simply declaring a captive portal that goes away if said human decides to dismiss the upsell opportunity or read whatever message it is is that the operator would like them to read.