Original text:
by the network operator, such as reading advertisements, accepting an acceptable-use policy, or providing some form of credentials. <del> Implementations generally require a web server, some method to allow/ block traffic, and some method to alert the user.  Common methods of alerting the user involve modifying HTTP or DNS traffic. </del>  This document describes an architecture for implementing captive portals while addressing most of the problems arising for current certificate validation, such as OCSP responders, CRLs, and NTP servers; see Section 4.1 of I-D.ietf-capport-api for more information.  If certificate validation fails, User Equipment MUST <del> NOT proceed with any of the behavior described above. </del>  2.2. Here we discuss candidate mechanisms for provisioning the User <del> Equipment with the URI of the API to query captive portal state and navigate the portal. </del>  2.2.1. <del> A standard for providing a portal URI using DHCP or Router Advertisements is described in RFC7710bis.  The captive portal </del>  architecture expects this URI to indicate the API described in section_api. Although still a work in progress, I-D.pfister-capport-pvd proposes a mechanism for User Equipment to be provided with PvD Bootstrap <del> Information containing the URI for the JSON-based API described in section_api. </del>  2.3. 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 User Equipment 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). protocol. When User Equipment receives Captive Portal Signals, the User <del> Equipment MAY query the API to check the state.  The User Equipment SHOULD rate-limit these API queries in the event of the signal being flooded.  (See Security.) </del>  The API MUST be extensible to support future use-cases by allowing extensible information elements. no time should it be simple or straightforward for one User Equipment to pretend to be another User Equipment, regardless of whether both are active at the same time.  This property is particularly important <del> when the User Equipment is extended externally to devices such as billing systems, or where the identity of the User Equipment could imply liability. </del>  3.2.3. A different Captive Portal API URI could be returned in the following cases: <del> Whenever a new Portal URI is received by end User Equipment, it SHOULD discard the old URI and use the new one for future requests to the API. </del>  5.

Reviewer comments:
One of the reviewers had a bunch of nits. This addresses all of them in one commit. See The issue for the list of nits.
Benjamin writes: Clarify to implementations of captive portals -> "huge variety of preexisting portals and ..." Take the suggestion. Is it sufficient to just say "SHOULD have a non-spoofable mechanism..."? How about "... the operating system could avoid updating the default route to a device on the captive WiFi network until ..." Note: We're changing MAY to could here to address Alvaro's review comment. This is a bit ambiguous. It's meant to basically say: "Stop interacting with the API". We canprobably rephrase to "If certificate validation fails, the User Equipment MUST NOT make any calls tothe API Server". Remove HTTP Do it Do it The identifier. Will update. Fix it. Do it. Do it.
Working on this. Will have a PR up tomorrow.
LGTM. Some small tweaks suggested.

Revised text:
by the network operator, such as reading advertisements, accepting an acceptable-use policy, or providing some form of credentials.  <ins> Implementations of captive portals generally require a web server, some method to allow/block traffic, and some method to alert the user.  Common methods of alerting the user in implementations prior to this work involve modifying HTTP or DNS traffic. </ins> This document describes an architecture for implementing captive portals while addressing most of the problems arising for current certificate validation, such as OCSP responders, CRLs, and NTP servers; see Section 4.1 of I-D.ietf-capport-api for more information.  If certificate validation fails, User Equipment MUST  <ins> NOT make any calls to the API server. </ins> 2.2. Here we discuss candidate mechanisms for provisioning the User  <ins> Equipment with the Captive Portal API URI to query captive portal state and navigate the portal. </ins> 2.2.1.  <ins> A standard for providing a Captive Portal API URI using DHCP or Router Advertisements is described in RFC7710bis.  The captive portal </ins> architecture expects this URI to indicate the API described in section_api. Although still a work in progress, I-D.pfister-capport-pvd proposes a mechanism for User Equipment to be provided with PvD Bootstrap  <ins> Information containing the URI for the API described in section_api. </ins> 2.3. 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" (see app- additional) queries to check for response tampering. </ins> The URI of this API will have been provisioned to the User Equipment. (Refer to section_provisioning). protocol. When User Equipment receives Captive Portal Signals, the User  <ins> Equipment MAY query the API to check its state of captivity.  The User Equipment SHOULD rate-limit these API queries in the event of the signal being flooded.  (See Security.) </ins> The API MUST be extensible to support future use-cases by allowing extensible information elements. no time should it be simple or straightforward for one User Equipment to pretend to be another User Equipment, regardless of whether both are active at the same time.  This property is particularly important  <ins> when the User Equipment identifier is referenced externally by devices such as billing systems, or where the identity of the User Equipment could imply liability. </ins> 3.2.3. A different Captive Portal API URI could be returned in the following cases:  <ins> Whenever a new Captive Portal API URI is received by end User Equipment, it SHOULD discard the old URI and use the new one for future requests to the API. </ins> 5.