Subject: [Captive-portals] Proposals to discover Provisioning Domains (& Captive Portals)

From: Tommy Pauly <[email-masked]>
Date: Sun, 12 Mar 2017 12:34:12 -0700

Hello,

I wanted to give the CAPPORT group a heads up about some related work in the explicit discovery of Provisioning Domains (PvDs), that provides one way of discovering and interacting with Captive Portals and other features of a network:

Proposals to discover Provisioning Domains
https://datatracker.ietf.org/doc/draft-bruneau-pvd/

PvDs are a concept from MIF, and before that group closed, one of the open questions was how to discover and communicate explicit information about networks and prefix ranges to a device. We've been working on this with Cisco, Apple, and Google contributors, and we think that there is a lot of potential synergy with the captive portal discovery.

The document also goes into various tradeoffs of approaches to getting this information, which is a relevant conversation for how we discover and contact captive portals as well.

Please take a read through and let us know your thoughts!

Thanks,
Tommy Pauly
Apple

---

From: David Bird <[email-masked]>
Date: Sun, 12 Mar 2017 13:14:27 -0700

HI Tommy,

I agree, there is synergy, particularly as it relates to our desire to have
a HTTP API like the one in your I-D.

A few high-level comments:

- Could RFC 7710 be used to identify the PvD?

- Do you envision this API being implemented in NAS devices (by vendors) or
portals (by hotspot web/portal developers)?

- In section 5.3 Reachability, would the client be learning all the
available resources (e.g. the walled garden)? As a hotspot operator, I
would probably prefer only giving this information on a need-to-know basis
and not expose all my partners (advertisers, roaming partners, etc) to
every visitor upon arrival.

- I believe we could improve (real-time) signaling with capport ICMP
<https://github.com/wlanmac/draft-wkumari-capport-icmp-unreach/blob/master/README.md>
(and the overall capport architecture
<https://tools.ietf.org/html/draft-larose-capport-architecture-00>)

On Sun, Mar 12, 2017 at 12:34 PM, Tommy Pauly <[email-masked]> wrote:

> Hello,
>
> I wanted to give the CAPPORT group a heads up about some related work in
> the explicit discovery of Provisioning Domains (PvDs), that provides one
> way of discovering and interacting with Captive Portals and other features
> of a network:
>
> PvDs are a concept from MIF, and before that group closed, one of the open
> questions was how to discover and communicate explicit information about
> networks and prefix ranges to a device. We've been working on this with
> Cisco, Apple, and Google contributors, and we think that there is a lot of
> potential synergy with the captive portal discovery.
>
> The document also goes into various tradeoffs of approaches to getting
> this information, which is a relevant conversation for how we discover and
> contact captive portals as well.
>
> _______________________________________________
> Captive-portals mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/captive-portals
>

---

From: Martin Thomson <[email-masked]>
Date: Mon, 13 Mar 2017 11:39:18 +1100

There's also this terrible idea from an age ago, which like 7710 uses
DHCP: https://datatracker.ietf.org/doc/rfc5986/  Unlike 7710, it
produces a name.

On 13 March 2017 at 07:14, David Bird <[email-masked]> wrote:
> available resources (e.g. the walled garden)? As a hotspot operator, I would
> probably prefer only giving this information on a need-to-know basis and not
> expose all my partners (advertisers, roaming partners, etc) to every visitor
> upon arrival.
>
> - I believe we could improve (real-time) signaling with capport ICMP (and
> the overall capport architecture)
>
>
>> the explicit discovery of Provisioning Domains (PvDs), that provides one way
>> of discovering and interacting with Captive Portals and other features of a
>> network:
>>