Original text:
Another consideration related to uniqueness of the User Equipment is that if the attached User Equipment changes, both the API Server and <del> the Enforcement Device must invalidate their state related to the </del>  User Equipment. The Enforcement Device needs to be aware of the physical interface, However, it may be possible to spoof the IP address, particularly for malicious reasons where proper functioning of the network is not necessary for the malicious actor.  Consequently, any solution using <del> the IP address should proactively try to prevent spoofing of the IP </del>  address.  Similarly, if the mapping of IP address to User Equipment <del> is changed, the components of the architecture must remove or update </del>  their mapping to prevent spoofing.  Demonstrations of return routeability, such as that required for TCP connection establishment, might be sufficient defense against spoofing, though this might not The solution described here requires that the API be secured using TLS.  This is required to allow the user equipment and API Server to exchange secrets which can be used to validate future interactions. <del> The API must ensure the integrity of this information, as well as its </del>  confidentiality. 7.4.

Reviewer comments:
Does this also need to update the boilerplate text that defines SHOULD, MUST, etc?
forgot to mention that, but the draft is already updated to use 8174 boilerplate
In the paragraph starting at line 633, we say: In particular, " Consequently, any solution using the IP address should proactively" and "the components of the architecture must remove or update their" I think we should either capitalize these two or rephrase them.
Aside from my one comment, lgtm. I don't think the intention of the issue was to rephrase everything that used lowercase, but to make sure that we capitalized everything we needed to.
changed the 2 to capital case
lgtm, thanks.
A scrub for these to determine which are really requirements is a good idea. Also, update SS1.1 to use RFC 8174 boilerplate.
looks OK to me

Revised text:
Another consideration related to uniqueness of the User Equipment is that if the attached User Equipment changes, both the API Server and  <ins> the Enforcement Device MUST invalidate their state related to the </ins> User Equipment. The Enforcement Device needs to be aware of the physical interface, However, it may be possible to spoof the IP address, particularly for malicious reasons where proper functioning of the network is not necessary for the malicious actor.  Consequently, any solution using  <ins> the IP address SHOULD proactively try to prevent spoofing of the IP </ins> address.  Similarly, if the mapping of IP address to User Equipment  <ins> is changed, the components of the architecture MUST remove or update </ins> their mapping to prevent spoofing.  Demonstrations of return routeability, such as that required for TCP connection establishment, might be sufficient defense against spoofing, though this might not The solution described here requires that the API be secured using TLS.  This is required to allow the user equipment and API Server to exchange secrets which can be used to validate future interactions.  <ins> The API MUST ensure the integrity of this information, as well as its </ins> confidentiality. 7.4.