[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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