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

[David Bird <[e-mail]>]

On Mon, Feb 5, 2018 at 8:40 PM, Lorenzo Colitti <[e-mail]> wrote:
>
> You're splitting hairs here. The UE does not ban applications from using
> the captive network in the sense that applications can choose to use it if
> they wish to. One notable use case is applications whose goal is to log
> into captive portals automatically by leveraging existing credentials. So
> Martin's original statement could be worded as "UE vendors express a strong
> desire to be able to know about status before they inflict the network on
> apps that want Internet access".
>

Just a quick reminder that not only multi-network mobile phones use WiFi
hotspots...

My question is... how does an App know if it wants to use the network or
not? Even if there is a captive portal, maybe the App in question will work
just fine within the walled garden. Indeed, maybe the system OS might use
the walled garden (*free!*) resources for an OS upgrade download. I don't
see how the UE or App can really know if any network is suitable for any
application, in the general sense, irrespective of captive portals. What we
(generally) need is some magic in multi-homed devices that helps Apps find
the best (cheapest/fasted) network for them to run in -- but that is for
another working group. I know this is rather idealistic :-)

What I am concerned about is forming the protocols for capport around the
current design / implementation limitations for multi-homed networked
devices..

[Hypothetical UE design: When the user opt into a network, the default
route is moved over. As apps use the network, they may generate ICMP
notifications which prompt API queries and the App(s) in question being
restarted pinned to the existing known good network (perhaps with a captive
portal dialog in there somewhere). The same could  be done for App(s)
otherwise not getting network responses (e.g. routing or capacity problems,
etc).]