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

[David Bird <[e-mail]>]

I don't follow... Yes, the signaling *would* be actionable...

- In the case of the school / library -- certain networks and / or
hostnames get you a captive portal notification (even if not HTTP) tell you
about your limitations

- In the case of the network that doesn't allow HTTP and SMTP (or other
protocols) you get a captive portal notification (even if not using HTTP)

- In the case of the lowered tier network ... The point here is that
network doesn't NEED to have everyone go through the portal (or even both
everyone with the portal before using the network)... The notification can
come later, for instance, when the network starts dropping pkts because of
the user's usage. How does a user change their mind, move to a new location
and start over?




On Mon, Feb 5, 2018 at 9:12 PM, Lorenzo Colitti <[e-mail]> wrote:

> 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.
>