Roman Danyliw has entered the following ballot position for draft-ietf-capport-rfc7710bis-07: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-capport-rfc7710bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 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? _______________________________________________ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
