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

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

David Bird <[email protected]> wrote:
    > 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

Requires MIF and provisioning domains and lots of other magic goo.
(I personally don't believe MIF's provisioning domains solved the problem,
except for providing job security to marketing people at Telcos)

    > 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

To make your point, many airport WIFIs will let you see gate info without
logging in.  If that ever became an portable API, it would be very useful to
have an APP that watched that info for you.  And any restaurant or coffee
shop that didn't let you see the menu/price list without friction is being dumb.

    > 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 :-)

So, what we need to do is not get in the way of other solutions.
I believe that IPv6 provides a number of solutions which are impossible in
IPv4, but there are chicken and egg problems with getting them deployed.

    > [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).]

Sounds reasonable.

Michael Richardson <[email protected]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

Attachment: signature.asc
Description: PGP signature