I have reviewed this document as part of the security directorate's effort to review all IETF documents being processed by the IESG.




These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comment.




 




This document communicates the presence of a captive portal in a WiFi network using DHCP and RAs.





 




Recommendation:  Ready




 




The motivation of the document makes sense, namely to avoid interception of traffic, and the document is an easy extension to already available mechanisms (RA/DHCP). I was expecting to see a reference to Hotspot 2.0, which aims to make the interaction between hotspot providers and end devices more intelligent (but covers a much larger scope). 




 




Minor nit: 




 




In Section 4 you write: 




 




“This document defines two DHCP Captive-Portal options, one for IPv6




   and one for IPv6.”




 




It should of course read “…, one for IPv4 and one for IPv6.”




 




Ciao




Hannes




 










-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents
 to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.





ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590


ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782