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

From: David Bird <[email-masked]>
Date: Fri, 14 Apr 2017 05:37:17 -0700

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?

---

From: Erik Kline <[email-masked]>
Date: Sat, 15 Apr 2017 22:15:46 +0900

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 <[email-masked]> wrote:

> _______________________________________________
> Captive-portals mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/captive-portals
>
>

---

From: David Bird <[email-masked]>
Date: Sat, 15 Apr 2017 07:47:57 -0700

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 <[email-masked]> wrote:

> 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.
>

---

From: Kyle Larose <[email-masked]>
Date: Mon, 17 Apr 2017 22:52:01 +0000

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 [[email-masked]] on behalf of David Bird [[email-masked]]
Sent: Saturday, April 15, 2017 10:47 AM
To: Erik Kline
Cc: [email-masked]
Subject: Re: [Captive-portals] Improve the user experience of captive portals as they're commonly understood and currently deployed

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:

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 <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> 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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/captive-portals