Original text:
In many environments offering short-term or temporary Internet access (such as coffee shops), it is common to start new connections in a captive portal mode.  This highly restricts what the user can do <del> until the user has satified the Captive Portal conditions. </del>  This document describes a DHCPv4 and DHCPv6 option and a Router Advertisement (RA) option to inform clients that they are behind some <del> sort of captive-portal enforcement device, and that they will need to </del>  satify the Captive Portal conditions to get Internet access.  It is not a full solution to address all of the issues that clients may have with captive portals; it is designed to be one component of a 1. <del> In many environments, users need to connect to a captive-portal </del>  device and agree to an Acceptable Use Policy (AUP) and / or provide billing information before they can access the Internet.  Regardless of how that mechanism operates, this document provides functionality how to contact it. In order to present users with the payment or AUP pages, presently a <del> captive-portal enforcement device has to intercept the user's </del>  connections and redirect the user to a captive portal server, using methods that are very similar to man-in-the-middle (MITM) attacks. As increasing focus is placed on security, and end nodes adopt a more This document describes a DHCPv4 RFC2131 and DHCPv6 RFC8415 option (Captive-Portal) and an IPv6 Router Advertisement (RA) RFC4861 option <del> that informs clients that they are behind a captive-portal </del>  enforcement device and the API endpoint that the host can contact for more information. 2. <del> The Captive Portal DHCP / RA Option informs the client that it may be </del>  behind a captive portal and provides the URI to access an API as defined by [draft-ietf-capport-api].  This is primarily intended to improve the user experience by showing the user the captive portal attack. However, as the operating systems and application(s) that make use of <del> this information know that they are connecting to a captive-portal </del>  device (as opposed to intercepted connections where the OS/ application may not know that they are connecting to a captive portal or hostile device) they can render the page in a sandboxed

Reviewer comments:
2 typos, and normalize the usage of hyphens (captive-portal vs captive portal). We use no hyphen (to match arch doc), except when referring to the option (to match the registry...) [Gahforthe_hyphens a87eb8d] 2 typos, and normalize the usage of hyphens (captive-portal vs captive portal). We use no hyphen (to match arch doc), except when referring to the option (to match the registry...)

Revised text:
In many environments offering short-term or temporary Internet access (such as coffee shops), it is common to start new connections in a captive portal mode.  This highly restricts what the user can do  <ins> until the user has satisfied the captive portal conditions. </ins> This document describes a DHCPv4 and DHCPv6 option and a Router Advertisement (RA) option to inform clients that they are behind some  <ins> sort of captive portal enforcement device, and that they will need to </ins> satify the Captive Portal conditions to get Internet access.  It is not a full solution to address all of the issues that clients may have with captive portals; it is designed to be one component of a 1.  <ins> In many environments, users need to connect to a captive portal </ins> device and agree to an Acceptable Use Policy (AUP) and / or provide billing information before they can access the Internet.  Regardless of how that mechanism operates, this document provides functionality how to contact it. In order to present users with the payment or AUP pages, presently a  <ins> captive portal enforcement device has to intercept the user's </ins> connections and redirect the user to a captive portal server, using methods that are very similar to man-in-the-middle (MITM) attacks. As increasing focus is placed on security, and end nodes adopt a more This document describes a DHCPv4 RFC2131 and DHCPv6 RFC8415 option (Captive-Portal) and an IPv6 Router Advertisement (RA) RFC4861 option  <ins> that informs clients that they are behind a captive portal </ins> enforcement device and the API endpoint that the host can contact for more information. 2.  <ins> The Captive-Portal DHCP / RA Option informs the client that it may be </ins> behind a captive portal and provides the URI to access an API as defined by [draft-ietf-capport-api].  This is primarily intended to improve the user experience by showing the user the captive portal attack. However, as the operating systems and application(s) that make use of  <ins> this information know that they are connecting to a captive portal </ins> device (as opposed to intercepted connections where the OS/ application may not know that they are connecting to a captive portal or hostile device) they can render the page in a sandboxed