Captive Portal Architecture
Draft of message to be sent after approval:
From: The IESG <firstname.lastname@example.org> To: IETF-Announce <email@example.com> Cc: firstname.lastname@example.org, The IESG <email@example.com>, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, Martin Thomson <email@example.com>, firstname.lastname@example.org, email@example.com Subject: Document Action: 'Captive Portal Architecture' to Informational RFC (draft-ietf-capport-architecture-10.txt) The IESG has approved the following document: - 'Captive Portal Architecture' (draft-ietf-capport-architecture-10.txt) as Informational RFC This document is the product of the Captive Portal Interaction Working Group. The IESG contact persons are Murray Kucherawy and Barry Leiba. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-capport-architecture/
Technical Summary: This document defines terminology related to the operation of a captive portal. Using those terms, it then defines how a network that deploys a captive portal should work. Working Group Summary: This document was difficult to reach consensus on. The complexity of the architecture here is reflective of a far greater complexity in practice of deployment. More contentious in discussion was the question of what signals from the network would be provided and what clients might do in response to those signals. The hard reality of the situation is that clients will be forced to use the existing heuristics they use, likely indefinitely, even when the mechanisms we define are in relatively wide deployment. A particularly difficult discussion was the option for a network to signal that conditions have changed. There was considerable discussion about the security properties of unsolicited signals from the network, how that related to the identification of endpoints (or User Equipment to use the terminology here), and how these signals might be turned to malicious ends. In the end, we decided to document requirements for how User Equipment is identified and how to avoid identifier spoofing. A high-level design and security requirements for a signal from the network about changed conditions was also documented, but no mechanism that met these requirements was proposed and the working group decided to proceed to publication without a specific mechanism. Document Quality: This document has not had a whole lot of attention from editors over time, and editors have changed. This shows in some editorial aspects of the document, but aside from a few areas in which things like terminology are inconsistently capitalized, the document is in good shape. The current editors have made some significant improvements. Personnel: Martin Thomson is document shepherd. Barry Leiba is the responsible Area Director.