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

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



On Mon, Feb 5, 2018 at 8:40 PM, Lorenzo Colitti <[email protected]> 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).]