Note: This ballot was opened for revision 07 and is now closed.
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?
Thank you for addressing my Discuss (and Comment) points!
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.
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." ?
Thanks for addressing my issue.
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