Re: [Captive-portals] time-based walled gardens

Mark Nottingham <mnot@mnot.net> Mon, 10 April 2017 23:46 UTC

Return-Path: <mnot@mnot.net>
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 8CCB9128B93 for <captive-portals@ietfa.amsl.com>; Mon, 10 Apr 2017 16:46:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level:
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 oAFKCc4ChLqk for <captive-portals@ietfa.amsl.com>; Mon, 10 Apr 2017 16:46:37 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3A24124C27 for <captive-portals@ietf.org>; Mon, 10 Apr 2017 16:46:36 -0700 (PDT)
Received: from [192.168.3.104] (unknown [124.189.98.244]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id BA02622E256; Mon, 10 Apr 2017 19:46:19 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <alpine.DEB.2.02.1704101753350.27978@uplift.swm.pp.se>
Date: Tue, 11 Apr 2017 09:46:17 +1000
Cc: captive-portals@ietf.org, Erik Kline <ek@google.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <6C4A44B4-8FA9-4696-969C-2749888CED08@mnot.net>
References: <CADo9JyU2wiEBB4L7ADSybt9se7jCN764JSEoHuGTcuiU_jDscQ@mail.gmail.com> <CAAedzxqR5bWTP_gou+hC5cgQ99tV275nX_ijm7iUok4-h+3wMQ@mail.gmail.com> <CADo9JyVfmhir8YtOR2mzzaaPL_9mBKgFmht6-SA50SfPmh9z6w@mail.gmail.com> <CAAedzxrck9+TBpEp-x8_tG-oxxKh4MQ4-x+iuGNGd6JsG=poQQ@mail.gmail.com> <CADo9JyUKb_c6SPigjUqngUyPvDsbN10TLZX0+B9r92xm6XGgAA@mail.gmail.com> <27524.1491594871@dooku.sandelman.ca> <CAAedzxo3Gp9ZhLeujZBC0vn9GO=+xHxkAstisoUAX1BCTEtYvQ@mail.gmail.com> <CADo9JyUr2rpZBjz5zMrrUmi8+gR9VGxBFhMLGVqFGYiWsOic6w@mail.gmail.com> <23307.1491830383@obiwan.sandelman.ca> <alpine.DEB.2.02.1704101549180.27978@uplift.swm.pp.se> <CADo9JyX6CzoxyxnGWq+sP+PM20DQUxYxvyqpHkDTJCWYUi99dg@mail.gmail.com> <alpine.DEB.2.02.1704101654550.27978@uplift.swm.pp.se> <CADo9JyW+PZEmSVg6oS5Pw2zPOr7rAeKAVy6QUtvVbgTkdVPqQg@mail.gmail.com> <alpine.DEB.2.02.1704101753350.27978@uplift.swm.pp.se>
To: Mikael Abrahamsson <swmike@swm.pp.se>, Martin Thomson <martin.thomson@gmail.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/captive-portals/vVDKoO6DvRwh-7-NyipCGzzRmq0>
Subject: Re: [Captive-portals] time-based walled gardens
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: Mon, 10 Apr 2017 23:46:40 -0000

> On 11 Apr 2017, at 1:57 am, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
> 
> CAPPORT doesn't have to just solve its own problems, perhaps it'd be good to try to come up with a slightly more generic solution and send it for review in INT-AREA for instance?

If I follow the discussion here and on the issues list correctly, I'm concerned.

My understanding when this WG was chartered was that we didn't really *like* captive portals, but people thought there was some benefit to at least making their operation smoother; we had lots of examples of interop problems and bad user outcomes in the discussion leading up to it. In that manner, the goal here AIUI is to codify current practice and incrementally improve it.

As I said in the BoF, even mitigating those problems might not lead to a great outcome, as it will encourage the deployment of more captive portals (as many networks are rolling them back, at least in my experience).

There is one use case defined in our charter:

"""
Some networks require interaction from users prior to authorizing
network access. Before that authorization is granted, network access
might be limited in some fashion. Frequently, this authorization process
requires human interaction to arrange for payment or to accept some
legal terms.
"""

Expanding the scope of this work to allow networks to further control their users' experience after authorisation to use the network (even if that is just giving a better user experience of that control) is not a small change. Allowing networks to interpose themselves in communication after authorisation is not a small change. 

AFAICT addressing these use cases would require re-chartering, and that's something I would argue vigorously against. I'd like to hear a clear statement from the Chairs about what they think the scope of work is here.

Regards,

--
Mark Nottingham   https://www.mnot.net/