|
At the last meeting, I think we heard, “PvDs can help solve this problem.” (This seems to me to be true.) Are the PvD authors backing away from this assertion? I think there are two aspects: 1.
The PvD data structures on the end-user device, which track captivity state per PvD. (RFC 7556 discusses connectivity tests per PvD.) 2.
Whether the PvD protocol explicitly conveys the captive-portal concept. If I understand correctly, (1) could be achieved even if capport information is conveyed in DHCP or RAs (vs. in the PvD protocol). However, that points to yet another API to query. I think that draft-bruneau-intarea-provisioning-domains has addressed a problem more generic than the CAPPORT API problem. And therefore I’m feeling it is still worth pursuing. I think Tommy makes a great point that there is value in explicitly indicating, “this is not a captive portal”. This ought to speed up network association. -Dave From: [email protected] [mailto:[email protected]]
On Jun 27, 2017, at 12:46 PM, Dave Dolson <[email protected]> wrote: Eric, Do I understand correctly from https://tools.ietf.org/html/draft-bruneau-intarea-provisioning-domains-00#section-5.5 that the intention is for the JSON key “captivePortal” to indicate that the specified URL is to be visited by the browser to navigate
the requirements for exiting captivity? If so, would you say this URL should be used in place of performing a capport detection strategy (e.g., canary HTTP request)? The idea with explicit PvD discovery is that it would, as a step, replace a separate captive portal detection strategy. My overall concern with discovery mechanisms that are specific to only captive portals is that this is an extra step that is performed potentially on every network association, that may have limited extensibility for non-captive use cases.
Since the explicit PvD design promises a way to discover many properties beyond captivity, and is bootstrapped very early on in the network association, it should hopefully allow clients to avoid the extra probe.
Note: the same “captivePortal” key is also defined in section 5.3 as a Boolean. Should I consider this to be a defect in the draft,
or am I missing something? The updated version of the draft (https://tools.ietf.org/html/draft-bruneau-intarea-provisioning-domains-01) leaves out the specific keys for captive
portals, and discusses it more abstractly. That would be a good thing to nail down at the Prague meeting. If PvD detection is done generically on network association, then a boolean or some way to indicate that this is *not* a captive portal will allow the
device to not perform extra probing. If there is a captive network, we should be able to get the page or instructions on how to get beyond captivity. Thanks, Tommy -Dave From: Eric
Vyncke (evyncke) [mailto:[email protected]] At least Erik Kline and myself are following the captive-portal list :-) And the more we think about it, PvD could really be useful and we, the PvD I-D authors, would be pleased to present at your WG -éric
_______________________________________________ |