Original text:
request. In order to support multiple "classes" of clients (e.g.  IPv4 only, <del> IPv6 only with DHCPv6 (RFC3315), and IPv6 only with RA) the captive </del>  network can provision the client with the URI via multiple methods (IPv4 DHCP, IPv6 DHCP, and IPv6 RA).  The captive portal operator SHOULD ensure that the URIs provisioned by each method are equivalent to reduce the chance of operational problems.  The maximum length of the URI that can be carried in IPv4 DHCP is 255 bytes, so URIs longer <del> than 255 bytes should not be provisioned via IPv6 DHCP or IPv6 RA either. </del>  In all variants of this option, the URI MUST be that of the captive portal API endpoint, conforming to the recommendations for such URIs Code: The Captive-Portal DHCPv4 Option (TBD) (one octet) <del> Len: The length, in octets of the URI. </del>  URI: The URI for the captive portal API endpoint to which the user should connect (encoded following the rules in RFC3986).  Note that the URI parameter is not null terminated. 2.2. option-code: The Captive-Portal DHCPv6Option (103) (two octets) <del> option-len: The length, in octets of the URI. </del>  URI: The URI for the captive portal API endpoint to which the user should connect (encoded following the rules in RFC3986). See RFC7227, Section 5.7 for more examples of DHCP Options with URIs.  Note that the URI parameter is not null terminated.

Reviewer comments:
Additionally: Update DHCPv6 reference from RFC 3315 to RFC 8415. Include reference to DHCPv6 option format text. Include reference to DHCPv4 option format text in RFC 2132. The DHCPv4 and v6 diagrams are not harmonized in this change. Each option format has sever documents using the style currently depicted. Issue:
""" — Sections 2.1 and 2.2 — Why aren’t the diagrams for the two in the same format? And neither explicitly says what the length of the “len” field is. In the v4 version, one has to guess that it’s the same size as the “code” field, 1 byte. In the v6 version, one can look at the diagram. I suggest making the diagrams the same format (calibrated with bit/byte markings) and explicitly specifying in the text the size of the “len” field. """ I rather suspect this goes back to whichever source documents from which the option format text was copied. Nevertheless, harmonizing them seems reasonable.
Additionally: we should restate the 255 byte limit from DHCPv4 in each option's description.

Revised text:
request. In order to support multiple "classes" of clients (e.g.  IPv4 only,  <ins> IPv6 only with DHCPv6 (RFC8415), and IPv6 only with RA) the captive </ins> network can provision the client with the URI via multiple methods (IPv4 DHCP, IPv6 DHCP, and IPv6 RA).  The captive portal operator SHOULD ensure that the URIs provisioned by each method are equivalent to reduce the chance of operational problems.  The maximum length of the URI that can be carried in IPv4 DHCP is 255 bytes, so URIs longer  <ins> than 255 bytes should not be provisioned via IPv6 DHCP nor IPv6 RA options. </ins> In all variants of this option, the URI MUST be that of the captive portal API endpoint, conforming to the recommendations for such URIs Code: The Captive-Portal DHCPv4 Option (TBD) (one octet)  <ins> Len: The length (one octet), in octets of the URI. </ins> URI: The URI for the captive portal API endpoint to which the user should connect (encoded following the rules in RFC3986). <ins> See RFC2132, Section 2 for more on the format of IPv4 DHCP options. </ins> Note that the URI parameter is not null terminated. 2.2. option-code: The Captive-Portal DHCPv6Option (103) (two octets)  <ins> option-len: The unsigned 16-bit length, in octets, of the URI. </ins> URI: The URI for the captive portal API endpoint to which the user should connect (encoded following the rules in RFC3986). See RFC7227, Section 5.7 for more examples of DHCP Options with URIs. <ins> See RFC8415, Section 21.1 for more on the format of IPv6 DHCP options. </ins> Note that the URI parameter is not null terminated.