Subject: [Captive-portals] Roman Danyliw's No Objection on draft-ietf-capport-rfc7710bis-07: (with COMMENT)

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Tue, 09 Jun 2020 20:12:09 -0700

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?