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@xxxxxxxx> 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@xxxxxxxx > https://www.ietf.org/mailman/listinfo/captive-portals -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
