Captive-Portal Identification in DHCP and Router Advertisements (RAs)
Note: This ballot was opened for revision 07 and is now closed.
Barry Leiba Yes
Deborah Brungard No Objection
Roman Danyliw No Objection
Comment (2020-06-09 for -07)
Thanks for this updated document. ** I support Ben's Discuss position ** (Editorially) Is there a reason that this draft doesn’t reference draft-ietf-capport-architecture-08 and use the notional architecture and terminology it defines? It would be clearer if it did. ** Section 2.2 and 2.3. Per “The maximum length of the URI that can be carried in IPv4 DHCP is 255 bytes, so URIs longer than 255 bytes should not be provisioned via IPv6 DHCP options.” -- should this be a normative SHOULD? -- recommend stating when this length can be ignored (e.g., IPv6 only environment) ** Section 5. Per “In the absence of security measures like RA Guard ([RFC6105], [RFC7113]) or DHCP Shield [RFC7610] …”, are these recommended for operators to use in the Captive Portal System?
Martin Duke No Objection
Benjamin Kaduk (was Discuss) No Objection
Comment (2020-06-30 for -09)
Thank you for addressing my Discuss (and Comment) points!
Murray Kucherawy No Objection
Comment (2020-05-31 for -07)
Nice work. A couple of minor things: In Section 2, paragraph 2, it says the operator "SHOULD ensure that the URIs provisioned by each method are equivalent". Does "equivalent" here mean "identical", or just "synonymous"? In Sections 2.1 and 2.2, the lists are bulleted and the names being described are delimited by colons. I suggest the same be done for 2.3. > Thanks IANA! RFC8126 should've required this of all documents.
Alvaro Retana No Objection
Martin Vigoureux No Objection
Éric Vyncke No Objection
Comment (2020-06-11 for -07)
Thank you for the work put into this document. The document is easy to read. I really like the signaling of 'no captive portal'. Please find below one non-blocking COMMENT (but you know the story) and 2 nits. Please also address all Suresh's comments in his IoT review: https://datatracker.ietf.org/doc/review-ietf-capport-rfc7710bis-07-iotdir-telechat-krishnan-2020-06-11/ I hope that this helps to improve the document, Regards, -éric == COMMENTS == -- Section 2.2 == In "should not be provisioned", I would suggest to use the normative "SHOULD". == NITS == -- Abstract -- Not all users of a captive portal are 'customers', they can be guests, students, employees, ... suggest to use 'users' (and even in the world of IoT). -- Section 2 -- Authors, being English natives, are probably correct but " should not be provisioned via IPv6 DHCP nor IPv6 RA options." looks weird to m; why not " should be provisioned via neither IPv6 DHCP nor IPv6 RA options." ?
Magnus Westerlund (was Discuss) No Objection
Comment (2020-06-25 for -09)
Thanks for addressing my issue.
Robert Wilton No Objection
Comment (2020-06-11 for -07)
Just one minor nit: I would have preferred if the packet diagram for "IPv4 DHCP Option" looked a lot more like the one in section 2.3 for "IPv6 RA", but perhaps there is a reason why the v4 DHCP represents the URL as two separate fields. Regards, Rob
Erik Kline Recuse
Warren Kumari Recuse
Comment (2020-05-25 for -07)