Captive-Portal Identification in DHCP and Router Advertisements (RAs)
RFC 8910
Yes
No Objection
Recuse
Note: This ballot was opened for revision 07 and is now closed.
Alvaro Retana No Objection
Martin Duke No Objection
Murray Kucherawy No Objection
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.
Robert Wilton No Objection
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
Roman Danyliw No Objection
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?
Éric Vyncke No Objection
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." ?
Erik Kline Recuse
Warren Kumari Recuse
'norther.
(Barry Leiba; former steering group member) Yes
(Benjamin Kaduk; former steering group member) (was Discuss) No Objection
Thank you for addressing my Discuss (and Comment) points!
(Deborah Brungard; former steering group member) No Objection
(Magnus Westerlund; former steering group member) (was Discuss) No Objection
Thanks for addressing my issue.
(Martin Vigoureux; former steering group member) No Objection