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

[Lorenzo Colitti <[e-mail]>]

On Tue, Feb 6, 2018 at 6:41 AM, David Bird <[e-mail]> 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.