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

To: Tommy Pauly <[email protected]>

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

From: David Bird <[email protected]>

Date: Sun, 12 Mar 2017 13:14:27 -0700

Archived-at: <https://mailarchive.ietf.org/arch/msg/captive-portals/nPnA72jmj7Y0aR7yKKRbT3eNwIg>

Authentication-results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com

Cc: "[email protected]" <[email protected]>, [email protected]

Delivered-to: [email protected]

Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=aXBRhP/CHMIaWF0el9/tSQVqyGniVZIvCsrKpwU7IZg=; b=WWSPENEhVTcENYM3cZsJvnxO+qxyv+6W4TkBryvR315cXMwJrITyIpxYJe1tWFuoRx sl3fucMqDjge5MXgbW1G3jSetHqZ/Gv2Aih4vtPzQzqVbqpwFgJUGBYfZEPo2+ltd7ln xBTA2R3PbvoUN5Y1WpcIpJyLIwWVoSTF/btFv4DgWuk8ICZ6OmIpVSnF8w+23pjAMa4C KJS408XoSFtwdMcC7UVZVsfR1Hz/y1bmIzeDhqTTEkFdWqHdp0oQ1/H5wkVLB4i2TwVI o/f+uQR633xWmcGNKzfT+H+4x1BKaz7eRkvUBTgUNMQ/ZwSM14Ju+jX0M0/h7jS3peqv UutA==

In-reply-to: <[email protected]>

List-archive: <https://mailarchive.ietf.org/arch/browse/captive-portals/>

List-help: <mailto:[email protected]?subject=help>

List-id: Discussion of issues related to captive portals <captive-portals.ietf.org>

List-post: <mailto:[email protected]>

List-subscribe: <https://www.ietf.org/mailman/listinfo/captive-portals>, <mailto:[email protected]?subject=subscribe>

List-unsubscribe: <https://www.ietf.org/mailman/options/captive-portals>, <mailto:[email protected]?subject=unsubscribe>

References: <[email protected]>

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 (and the overall capport architecture)

On Sun, Mar 12, 2017 at 12:34 PM, Tommy Pauly <[email protected]> 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:

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

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