Reviewer: Tim Chown Review result: Has Nits Hi, I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes IPv4 DHCP, IPv6 DHCP and IPv6 RA options to indicate to hosts that they are behind some form of captive portal, and to convey the associated API endpoint with which they can communicate to establish wider network access. It updates RFC7110, which turned out to be using a DHCP codepoint that was already in use). The draft is part of the capport WG’s initiative to provide a more consistent and robust mechanism for hosts, such as those in WiFi hotspots, to determine when a captive portal is in place, and how they might negotiate / authenticate with that portal. The text is well-written and describes the IPv4 DHCP, IPv6 DHCP and RA option formats clearly. I would say that the draft is Ready with Nits. General comments: The security considerations (Section 5) talk of potential spoofed DHCP or RA captive portal option messages; equally an attacker could use a rogue RA or DHCP message to convey (for example) a bad DNS server option, which could direct a client to a bad captive portal endpoint. So the document should probably state that there is an assumption of RFC 6105 (RA Guard) or equivalent measures being in place; whether such a capability is realistic in a coffee shop scenario is another question. I also wonder how commonly multiple provisioning domain scenarios will arise for school network access, where a client may see multiple captive portals. I note that draft-ietf-intarea-provisioning-domains-04 seems to have expired, so I’m not clear whether that initiative has been dropped; it seemed to have good potential. Nits: Abstract: * Clarify that the document describes and DHCPv4 and DHCPv6 option. * Remove the parantheses from the RA option text; these are “equal” options. * Perhaps rewrite “it is designed to be used in larger solutions“ to “it is designed to be one component of a standardised approach for hosts to interact with such portals.“ * And perhaps rewrite “The method of authenticating to, and interacting with the captive portal is out of scope of this document.” to “While this document defines how the network operator may convey the captive portal API endpoint to hosts, the specific methods of authenticating to, and interacting with the captive portal are out of scope of this document.” Section 1: * This cites RFC 2131 for DHCP; I’d suggest citing RFC 3315 and RFC 8415 and emphasising that there are options for DHCP for IPv4 and DHCPv6. * It also says “how to contact an API”; probably better to say “the API endpoint that the host can contact” as the “how” is out of scope for this document. Section 2: “Implement the interception” -> “implement interception” Section 3: Second paragraph, is that a “should be logged” or “SHOULD be logged”? -- Tim -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
