Re: [Captive-portals] Opsdir last call review of draft-ietf-capport-api-07

Hi Linda,

Thanks for reviewing the document.

For background on how the architecture defined by the CAPPORT WG is preferable to the non-standard mechanisms in deployment today, I’d like to point you to one of the documents referenced by the API document, draft-ietf-capport-architecture (https://tools.ietf.org/html/draft-ietf-capport-architecture).

There are several benefits, grouping roughly as follows:

- Security: Generally, solutions today require interception of DNS and redirecting HTTP responses, and incompatibility with TLS or attempts to man-in-the-middle TLS.
- Privacy: Captive networks usually rely on intercepting “user” traffic, which means a device may try to send traffic with user-sensitive names on a network and only later realize it is captive and the results are bogus.
- Functionality: Solutions today do not have a way to communicate time remaining to devices or how to extend a session, so association is often cut off abruptly.
- Consistency and early detection: There isn’t any standard way for a client device to detect that it is captive today, and there is a large variety in the way networks implement this, leading to inconsistency in user experience and timing.

Best,
Tommy

> On May 9, 2020, at 3:06 PM, Linda Dunbar via Datatracker <noreply@ietf.org> wrote:
> 
> Reviewer: Linda Dunbar
> Review result: Has Nits
> 
> I have reviewed this document as part of the Ops area directorate's ongoing
> effort to review all IETF documents being processed by the IESG.  These
> comments were written primarily for the benefit of the Ops area directors.
> Document editors and WG chairs should treat these comments just like any other
> last call comments.
> 
> This document provides examples of the API structure between client and captive
> server. The document is well written. I just have a question:
> 
> What improvement does the proposed API have over today's existing communication
> between clients and  Captive Server(s)? Captive servers have been deployed
> everywhere, like airport or restaurants trying to access free WIFI. What
> problems does the existing method have to justify this newly proposed APIs?
> 
> Cheers,
> Linda Dunbar
> 
> 
> _______________________________________________
> Captive-portals mailing list
> Captive-portals@ietf.org
> https://www.ietf.org/mailman/listinfo/captive-portals