Original text:
Captive Portal Conditions: site-specific requirements that a user or device must satisfy in order to gain access to the wider network. <del> Captive Portal Enforcement: The network equipment which enforces the traffic restriction. </del>  Captive Portal User Equipment: Also known as User Equipment.  A device which has voluntarily joined a network for purposes of The User Equipment is the device that a user desires to be attached to a network with full access to all hosts on the network (e.g., to have Internet access).  The User Equipment communication is typically <del> restricted by the Captive Portal Enforcement, described in </del>  section_capport_enforcement, until site-specific requirements have been met. If User Equipment supports the Captive Portal API, it MUST validate the API server's TLS certificate (see RFC2818).  An Enforcement <del> device SHOULD allow access to any services that User Equipment could </del>  need to contact to perform 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, 2.4. <del> The Captive Portal Enforcement component restricts the network access of User Equipment according to site-specific policy.  Typically User </del>  Equipment is permitted access to a small number of services and is denied general network access until it satisfies the Captive Portal Conditions. <del> The Captive Portal Enforcement component: </del>  2.5. information about the source physical interface (e.g.  a tunnel). The API Server faces a similar problem, implying that it should co- <del> exist with the Enforcement Device, or that the enforcement device </del>  should extend requests to it with the identifying information. 3.4.2. addresses, while still satisfying all of the recommended properties. This raises some challenges to the components of the network.  For example, if the User Equipment tries to access the network with <del> multiple IP addresses, should the enforcement device and API Server </del>  treat each IP address as a unique User Equipment, or should it tie the multiple addresses together into one view of the subscriber?  An implementation MAY do either.  Attention should be paid to IPv6 and

Reviewer comments:
We were using "Captive Portal Enforcement", "Captive Portal Enforcement Device" and "Enforcement Device", with varying capitilisation, inconsistently throughout the document. Address that by defining the component as "Captive Portal Enforcement Device", and using that term in section headings, and "Enforcement Device" everywhere else. Fixes issue
Looks good to me
Used in different ways: Captive Portal Enforcement, enforcement device, etc.
I think keeping it shorter is likely better. ? Caps to make it clear it's a first class component in the architecture?

Revised text:
Captive Portal Conditions: site-specific requirements that a user or device must satisfy in order to gain access to the wider network.  <ins> Captive Portal Enforcement Device: The network equipment which enforces the traffic restriction.  Also known as Enforcement Device. </ins> Captive Portal User Equipment: Also known as User Equipment.  A device which has voluntarily joined a network for purposes of The User Equipment is the device that a user desires to be attached to a network with full access to all hosts on the network (e.g., to have Internet access).  The User Equipment communication is typically  <ins> restricted by the Enforcement Device, described in </ins> section_capport_enforcement, until site-specific requirements have been met. If User Equipment supports the Captive Portal API, it MUST validate the API server's TLS certificate (see RFC2818).  An Enforcement  <ins> Device SHOULD allow access to any services that User Equipment could </ins> need to contact to perform 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, 2.4.  <ins> The Enforcement Device component restricts 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 denied general network access until it satisfies the Captive Portal Conditions.  <ins> The Enforcement Device component: </ins> 2.5. information about the source physical interface (e.g.  a tunnel). The API Server faces a similar problem, implying that it should co-  <ins> exist with the Enforcement Device, or that the Enforcement Device </ins> should extend requests to it with the identifying information. 3.4.2. addresses, while still satisfying all of the recommended properties. This raises some challenges to the components of the network.  For example, if the User Equipment tries to access the network with  <ins> multiple IP addresses, should the Enforcement Device and API Server </ins> treat each IP address as a unique User Equipment, or should it tie the multiple addresses together into one view of the subscriber?  An implementation MAY do either.  Attention should be paid to IPv6 and