Re: [Captive-portals] Improve the user experience of captive portals as they're commonly understood and currently deployed

I also agree that the only new component is the API server. We have extended the responsibilities of the others, or maybe, to put it differently, tried to solidify them (since as David pointed out, many devices were already doing many of these things).

It looks like most of the discussion recently has been centered around the responsibilities of the Captive Portal Enforcement device and the CAPPORT API server.

How can we go about coming to a consensus on these? Should we propose a few options, along with their pros and cons, then vote on them? Once we've done that, the architecture could capture the results, and the drafts that discuss implementations/protocols/standards/etc to satisfy those components can expand further.

Does that make sense?
________________________________
From: Captive-portals [captive-portals-bounces@ietf.org] on behalf of David Bird [dbird@google.com]
Sent: Saturday, April 15, 2017 10:47 AM
To: Erik Kline
Cc: captive-portals@ietf.org
Subject: Re: [Captive-portals] Improve the user experience of captive portals as they're commonly understood and currently deployed

The only new element is the CAPPORT API Server.

Though, similar things do exists in proprietary environments (e.g. Walled garden entry plus proprietary Apps).

Even though I started the thread 'Arguments against (any) CAPPORT API', I would like to take back the "(any)" part. I just wanted to make a point that we should NOT make the API the enforcer, or otherwise give the API the opportunity to give us wrong, misleading, or misconfigured information about what the network will enforce. I don't think the goal of the API should be to get rid of the portal in all cases. But, there could be other useful information and interaction (like WISPr demonstrates, plus minimally more). For instance, the API could advertise 'access methods' like:

wispr { realm: "abc", login: "https://...", logout: "https://..." }
wispr { realm: "xyz", login: "https://...", logout: "https://..." }
mime-type { name: "application/my-hotspot-app" }
mime-type { name: "application/roaming-partner-foo" }

It can replace WISPr XML, even abilities by allowing the advertising of multiple roaming aggregators. It can also indicate to the UE what apps might assist- or auto- login. If this information is wrong, the Smartclient or App will figure it out (because they are likely doing their own proprietary API in the walled garden).

On Sat, Apr 15, 2017 at 6:15 AM, Erik Kline <ek@google.com<mailto:ek@google.com>> wrote:
Do the architectural elements in the capport-architecture draft accurately capture "captive portals as they're commonly understood and currently deployed"?

I have no experience with which to easily distinguish between elements that are present and common in existing implementations and those that exist in the draft solely for the purpose of meeting the proposed solution behaviour outlined in section 3.

On 14 April 2017 at 21:37, David Bird <dbird@google.com<mailto:dbird@google.com>> wrote:
Can we get back on track and focus on our goal of improving the user experience of captive portals as they're commonly understood and currently deployed?

_______________________________________________
Captive-portals mailing list
Captive-portals@ietf.org<mailto:Captive-portals@ietf.org>
https://www.ietf.org/mailman/listinfo/captive-portals