Original text:
1.2. <del> Captive Network: A network which limits communication of attached </del>  devices to restricted hosts until the user has satisfied Captive Portal Conditions, after which access is permitted to a wider set of hosts (typically the Internet). The User Equipment can store the last response it received from the Captive Portal API as a cached view of its state within the Captive <del> Network.  This state can be used to determine whether its Captive </del>  Portal Session is near expiry.  For example, the User Equipment might compare a timestamp indicating when the session expires to the current time.  Storing state in this way can reduce the need for Captive Portal API URI to the User Equipment when it connects to the network, and later if the URI changes.  The provisioning service could also be the same service which is responsible for provisioning <del> the User Equipment for access to the Captive Network (e.g., by </del>  providing it with an IP address).  This section discusses two mechanisms which may be used to provide the Captive Portal API URI to the User Equipment. 2.6. The following diagram shows the communication between each component <del> in the case where the Captive Network has a User Portal, and the User </del>  Equipment chooses to visit the User Portal in response to discovering and interacting with the API Server. 3.2.1. <del> The Captive Network MUST associate the User Equipment with an </del>  identifier that is unique among the User Equipment that are <del> interacting with the Captive Network at that time. </del>  Over time, the User Equipment assigned to an identifier value MAY change.  Allowing the identified device to change over time ensures 4.1. This section describes a possible workflow when User Equipment <del> initially joins a Captive Network. </del>  4.2.

Reviewer comments:
A reviewer pointed out that Captive Portal and Captive Network were used interchangeably in the document. While we used Captive Network more frequently, Captive Portal aligns more closely with familiar use of the term. Further, other documents such as the API draft refer to the system as a whole as a Captive Portal, which makes this change more aligned with them.
Tirupachur Comerica, Subash writes: I think that this is clear: one is a network and the other a server. Review to see if the right choice is used throughout. URL point out that we assume a degree of mutual control over both.

Revised text:
1.2.  <ins> Captive Portal: A network which limits communication of attached </ins> devices to restricted hosts until the user has satisfied Captive Portal Conditions, after which access is permitted to a wider set of hosts (typically the Internet). The User Equipment can store the last response it received from the Captive Portal API as a cached view of its state within the Captive  <ins> Portal.  This state can be used to determine whether its Captive </ins> Portal Session is near expiry.  For example, the User Equipment might compare a timestamp indicating when the session expires to the current time.  Storing state in this way can reduce the need for Captive Portal API URI to the User Equipment when it connects to the network, and later if the URI changes.  The provisioning service could also be the same service which is responsible for provisioning  <ins> the User Equipment for access to the Captive Portal (e.g., by </ins> providing it with an IP address).  This section discusses two mechanisms which may be used to provide the Captive Portal API URI to the User Equipment. 2.6. The following diagram shows the communication between each component  <ins> in the case where the Captive Portal has a User Portal, and the User </ins> Equipment chooses to visit the User Portal in response to discovering and interacting with the API Server. 3.2.1.  <ins> The Captive Portal MUST associate the User Equipment with an </ins> identifier that is unique among the User Equipment that are  <ins> interacting with the Captive Portal at that time. </ins> Over time, the User Equipment assigned to an identifier value MAY change.  Allowing the identified device to change over time ensures 4.1. This section describes a possible workflow when User Equipment  <ins> initially joins a Captive Portal. </ins> 4.2.