Original text:
Abstract <del> This document aims to document consensus on the CAPPORT architecture. DHCP or Router Advertisements, an optional signaling protocol, and an HTTP API are used to provide the solution.  The role of Provisioning Domains (PvDs) is described. </del>  1. The architecture uses the following mechanisms: <del> The architecture attempts to provide privacy, authentication, and safety mechanisms to the extent possible. </del>  1.1. At this time we consider only devices with web browsers, with web applications being the means of satisfying Captive Portal Conditions.  None of the above requirements are mandatory because (a) we do not wish to say users or devices must seek full access to the captive The purpose of a Captive Portal API is to permit a query of Captive Portal state without interrupting the user.  This API thereby removes <del> the need for a device to perform clear-text "canary" HTTP queries to check for response tampering. </del>  The URI of this API will have been provisioned to the User Equipment. (Refer to section_provisioning). This architecture expects the User Equipment to query the API when the User Equipment attaches to the network and multiple times thereafter.  Therefore the API MUST support multiple repeated queries <del> from the same User Equipment, returning the current state of captivity for the equipment. </del>  <del> At minimum the API MUST provide: (1) the state of captivity and (2) a URI for a browser to present the portal application to the user.  The API SHOULD provide evidence to the caller that it supports the present architecture. </del>  When user equipment receives Captive Portal Signals, the user equipment MAY query the API to check the state.  The User Equipment The API MUST be extensible to support future use-cases by allowing extensible information elements. <del> The API MUST use TLS for privacy and server authentication.  The implementation of the API MUST ensure both privacy and integrity of any information provided by or required by it. </del>  This document does not specify the details of the API. 2.4. <del> The Captive Portal Enforcement component restricts network access to User Equipment according to site-specific policy.  Typically User </del>  Equipment is permitted access to a small number of services and is <del> denied general network access until it has performed some action. </del>  The Captive Portal Enforcement component: User Equipment may send traffic to hosts blocked by the captive network prior to the Enforcement device granting it access.  The Enforcement Device rightly blocks or resets these requests.  However, <del> lacking a signal from the Enforcement Device or interaction with the API server, the User Equipment can only guess at whether it is captive.  Consequently, allowing the Enforcement Device to explicitly signal to the User Equipment that the traffic is being blocked may improve the user's experience. </del>  <del> An Enforcement Device may also want to inform the User Equipment of a </del>  pending expiry of its access to the external network, so providing the Enforcement Device the ability to preemptively signal may be desirable. which it points to communicate local network policies. The Captive Portal Enforcement function MAY send Captive Portal <del> Signals when disallowed User Equipment attempts to send to the network.  These signals MUST be rate-limited to a configurable rate. </del>  The signals MUST NOT be sent to the destinations/peers that the User Equipment is restricted from accessing.  The indications are only to

Reviewer comments:
Happy to elaborate on them if the motivation is not clear from the changes, let me know!
Thanks NAME b1dc7ba4e26ab17ed12d8a5a2408fe8063b1177a accepts the suggestion. 509d855e5ddba7dd1c5db58646c85516d0b40987 corrects the mistake I had made, which your question was about.
Looks great. Thanks for the PR!

Revised text:
Abstract  <ins> This document describes a CAPPORT architecture.  DHCP or Router Advertisements, an optional signaling protocol, and an HTTP API are used to provide the solution.  The role of Provisioning Domains (PvDs) is described. </ins> 1. The architecture uses the following mechanisms:  <ins> The architecture attempts to provide confidentiality, authentication, and safety mechanisms to the extent possible. </ins> 1.1. At this time we consider only devices with web browsers, with web applications being the means of satisfying Captive Portal Conditions. <ins> An example interactive User Equipment is a smart phone. The User Equipment: </ins> None of the above requirements are mandatory because (a) we do not wish to say users or devices must seek full access to the captive The purpose of a Captive Portal API is to permit a query of Captive Portal state without interrupting the user.  This API thereby removes  <ins> the need for User Equipment to perform clear-text "canary" HTTP queries to check for response tampering. </ins> The URI of this API will have been provisioned to the User Equipment. (Refer to section_provisioning). This architecture expects the User Equipment to query the API when the User Equipment attaches to the network and multiple times thereafter.  Therefore the API MUST support multiple repeated queries  <ins> from the same User Equipment and return the state of captivity for the equipment. </ins>  <ins> At minimum, the API MUST provide: (1) the state of captivity and (2) a URI for the Captive Portal Server.  The API SHOULD provide evidence to the caller that it supports the present architecture. </ins> When user equipment receives Captive Portal Signals, the user equipment MAY query the API to check the state.  The User Equipment The API MUST be extensible to support future use-cases by allowing extensible information elements.  <ins> The API MUST use TLS to ensure server authentication.  The implementation of the API MUST ensure both confidentiality and integrity of any information provided by or required by it. </ins> This document does not specify the details of the API. 2.4.  <ins> The Captive Portal Enforcement component restrict the network access of User Equipment according to site-specific policy.  Typically User </ins> Equipment is permitted access to a small number of services and is  <ins> denied general network access until it satisfies the Captive Portal Conditions. </ins> The Captive Portal Enforcement component: User Equipment may send traffic to hosts blocked by the captive network prior to the Enforcement device granting it access.  The Enforcement Device rightly blocks or resets these requests.  However,  <ins> in the absence of a signal from the Enforcement Device or interaction with the API server, the User Equipment can only guess at whether it is captive.  Consequently, allowing the Enforcement Device to explicitly signal to the User Equipment that the traffic is being blocked may improve the user's experience. </ins>  <ins> An Enforcement Device may also want to notify the User Equipment of a </ins> pending expiry of its access to the external network, so providing the Enforcement Device the ability to preemptively signal may be desirable. which it points to communicate local network policies. The Captive Portal Enforcement function MAY send Captive Portal  <ins> Signals when User Equipment that has not satisfied the Captive Portal Conditions attempts to send traffic to the network.  These signals MUST be rate-limited to a configurable rate. </ins> The signals MUST NOT be sent to the destinations/peers that the User Equipment is restricted from accessing.  The indications are only to