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

[David Bird <[e-mail]>]

On Mon, Feb 5, 2018 at 4:54 PM, Martin Thomson <[e-mail]>
wrote:

> On Tue, Feb 6, 2018 at 8:41 AM, David Bird <[e-mail]> wrote:
> >> I have heard UE vendors express a strong desire to be able to know
> >> about status before they attempt to use the network.
> >>
> >
> > Hm, but (assuming you are using the provided network for DNS, CRL checks,
> > and the API itself), the UE is *already* using the network.
>
> Not really.  The way I understand it, the UE alters routing tables so
> that only applications that explicitly opt in to using the interface
> to the network can do so.  That state exists until the network is
> given an "all clear".
>

I understand that. But, *really*, the application(s) that opt-in, as it
were, are using the  network... DNS, HTTPS (to the API), etc.

I'm not overly comfortable designing network protocols around, basically,
UE limitations and easy of programming... The  UE *could* be more
flexible...



>
> > I believe this desire on the UE vendor part is a case of 'be careful what
> > you wish for' ... Having an API telling you it is "all clear" vs "do
> > internal (often sandboxed for various reasons browser) captive portal
> > dialog" amounts to making this a configuration of the network
> administrator
> > -- Remember the (current) arms race concerning captive  portal detection?
> > Well, the network operator wins with this API (!).
>
> Remember we already concluded that if the network wants to lie about
> status, we aren't planning to stop them.  There are still some
> discussions to be had about providing incentives to be truthful, but
> it's possible that we could never really plumb the depths of that
> issue productively, so we've been deferring it.
>
>
My point is... that the reason for the "arms race" is user expectations and
the UE trying to determine possible issues in the network... My prediction
remains that the UE vendors will *still* opt to test the network even with
the API -- because they still have users, with expectations...


> > 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'd say that the amount of information provided here is rich enough
> that you want to talk to a human.  Very few networks permit sending of
> arbitrary packets to arbitrary hosts and the receipt of similar.  The
> point is to ensure that you are managing expectations.  If I
> understand the expression of requirements, the idea is that a UE can
> use the boolean signal, but this other stuff is better presented on
> the web page.  If the network starts off in a captive state, then that
> page will be seen (if there is a human), and maybe not used (if there
> isn't).
>
>
I'm not sure I follow that statement...



> > Clients that go idle typically have their session terminated - so, yes,
> it
> > does save the user time (depending on "time" is billed - real time vs
> > metered, etc).
>
> Right.  Though this is relatively rare in my experience.  In those
> cases, I think that the idea is that the client can check with the API
> before its time comes due and notice the resulting extension and so go
> back to sleep.



What's rare, metered time based access??