Change:
2.4. <del> In this use case, potentially dangerous physical equipment (e.g., power grid, traffic control, hazardous chemical processing, etc.) is </del> <ins> In this use case, potentially harmful physical equipment (e.g., power grid, traffic control, hazardous chemical processing, etc.) is </ins> connected to a network.  The organization managing such infrastructure needs to ensure that only authorized code and users <del> can control such processes, and they are protected from malware or other threats.  When a protocol operation can affect some critical system, the device attached to the critical equipment thus wants some assurance that the requester has not been compromised.  As such, remote attestation can be used to only accept commands from requesters that are within policy. </del> <ins> can control such processes, and that these processes are protected from unauthorized manipulation or other threats.  When a protocol operation can affect a component of a critical system, the device attached to the critical equipment requires some assurances depending on the security context, including that: the requesting device or application has not been compromised, and the requesters and actors act on applicable policies, As such, remote attestation can be used to only accept commands from requesters that are within policy. </ins> A device or application wishing to control physical equipment

Discussion:
Guy says: This section seems to say that the Connected IoT valve is going attest the cloud-based industrial control system before accepting an Open or Close command? I’d guess what you mean is that the control system should check that the valve it’s about to open is the right one, and is probably sane, no?
... and even more importantly that the sensor that provides critical input into the controller needs to give evidence of its trustworthiness before the controller can comfortably act upon its stimulus (e.g., opening the valve.)
For context, this is now: https://ietf-rats-URL While trying to address both MCR's and Thomas' comments, I realized that Michael's "valve is the right one" seems already to be subsumed by "are within policy". I felt that adding an explicit example here added more words then content. To address Thomas' comment it now says "the requester and the triggering sensor have not been compromised". After including a few editorial changes, the resulting proposal does not look vastly different: "In this use case, potentially harmful physical equipment (e.g., power grid, traffic control, hazardous chemical processing, etc.) is connected to a network. The organization managing such infrastructure needs to ensure that only authorized code and users can control such processes, and that these processes are protected from unauthorized manipulation or other threats. When a protocol operation can affect a component of a critical system, the device attached to the critical equipment requires some assurances depending on the security context, including that: the requester and the triggering sensor have not been compromised, and the requesters and actors act on applicable policies, As such, remote attestation can be used to only accept commands from requesters that are within policy."