IETF Logo Mail Archive

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

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 07 February 2018 21:19 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: captive-portals@ietfa.amsl.com
Delivered-To: captive-portals@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE08A127698 for <captive-portals@ietfa.amsl.com>; Wed, 7 Feb 2018 13:19:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bHsbo3hHJOmJ for <captive-portals@ietfa.amsl.com>; Wed, 7 Feb 2018 13:19:05 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E27AF12711D for <captive-portals@ietf.org>; Wed, 7 Feb 2018 13:19:04 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 17584200A3 for <captive-portals@ietf.org>; Wed, 7 Feb 2018 16:25:38 -0500 (EST)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 946F280E6E for <captive-portals@ietf.org>; Wed, 7 Feb 2018 16:19:03 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: captive-portals@ietf.org
In-Reply-To: <CADo9JyWD3K7R1FahFNuCXT1MVKAF9iL1OiGzM4haBygBy=13Hg@mail.gmail.com>
References: <151778535115.5816.386541967960931391@ietfa.amsl.com> <CADo9JyV2Rz2B9H_h9JMne7XLtMeVb2OajheZ86i5g8nsPmmFOw@mail.gmail.com> <CABkgnnW_x6sokdEo-yyzk0DKFqom6b7aHpoLgRnBHOW_cGB6yA@mail.gmail.com> <CADo9JyXRtyuzoWJKA+aASGh-bEJ8hi323VRdBeyqsgXwNxSkbw@mail.gmail.com> <CADo9JyVtKMCwcXsZgfNSJ8VshjaTxSPS7YWro71Z4Y7K4UWFxA@mail.gmail.com> <CABkgnnX2iQwDR_zgk15OQSCWh1pJBrJRvTwmEHbvsecaoQOuow@mail.gmail.com> <CADo9JyWyv=d9osYiRRAG4cav6zGbS4imstV0TJcP4fbTaYamUg@mail.gmail.com> <CAKD1Yr39abK5U18tz-B2c3qyaTdHLU3QiFF9r1Lzqap1nsvJiw@mail.gmail.com> <CADo9JyWD3K7R1FahFNuCXT1MVKAF9iL1OiGzM4haBygBy=13Hg@mail.gmail.com>
X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Wed, 07 Feb 2018 16:19:03 -0500
Message-ID: <10008.1518038343@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/captive-portals/73LCFetW29hXZcFCkcArGSbOmYk>
Subject: Re: [Captive-portals] I-D Action: draft-ietf-capport-api-00.txt
X-BeenThere: captive-portals@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Discussion of issues related to captive portals <captive-portals.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/captive-portals>, <mailto:captive-portals-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/captive-portals/>
List-Post: <mailto:captive-portals@ietf.org>
List-Help: <mailto:captive-portals-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/captive-portals>, <mailto:captive-portals-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Feb 2018 21:19:06 -0000

David Bird <dbird@google.com> 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 <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

v2.23.0 | Report a Bug | By Email