Integrated @gmandyam's comments/review on streaming remote attestation.

* [x] **a)** Evidence verification failures & unsubscribe:
  * @gmandyam's concern:
    * What happens when Evidence (or delta Evidence) fails verification?
    * Should the Verifier be able to unsubscribe?
* A description of how unsubscribe works might be useful in
streaming mode.
  * @henkbirkholz's reply:
* Unsubscribe is out of scope of this doc, since it is already
covered by standards track work (e.g.,
[draft-ietf-rats-network-device-subscription](https://datatracker.ietf.org/doc/draft-ietf-rats-network-device-subscription/)).
    * It's a protocol detail, not part of the reference model.
  * ➡️ Added clarifying sentence at the end of Section 7.3.

* [x] **b)** Definition of delta evidence:
  * @gmandyam's concern:
* Current definition (“only changed claims and new event logs”) is
too narrow.
* Example: Attester goes to sleep, detects a change and reversion,
and should still report that sequence, even if the final state looks
unchanged.
  * @henkbirkholz's reply:
    * Agree, propose adding text to cover this.
  * ➡️ Improved definition of delta evidence in Section 7.2.1.
  * ➡️ Referenced this definition in 7.3 (Streaming).

Signed-off-by: Michael Eckel <michael.eckel@sit.fraunhofer.de>

Author: eckelmeckel

draft-ietf-rats-reference-interaction-models.md

@@ -121,6 +121,7 @@ informative:
       name: Butler Lampson
     date: 2006
   I-D.ietf-rats-endorsements: rats-endorsements
+  I-D.ietf-rats-network-device-subscription: rats-network-device-subscription
 ...
 
 --- abstract
@@ -616,7 +617,7 @@ This binding provides a proof of synchronization that MUST be included in all pr
 This model provides proof that Evidence generation happened after the Handle generation phase.
 The Verifier can always determine whether the received Evidence includes a fresh Handle, i.e., one corresponding to the current Epoch.
 
-### Handle Lifecycle and Propagation Delays
+### Handle Lifecycle and Propagation Delays {#handle-lifecycle-and-propagation-delays}
 
 The lifecycle of a handle is a critical aspect of ensuring the freshness and validity of attestation Evidence.
 When a new handle is generated by the Handle Distributor, it effectively supersedes the previous handle.
@@ -639,8 +640,10 @@ To manage this complexity, it is essential to define a clear policy for handle v
 Implementing these measures will help mitigate the risks associated with the handle lifecycle, particularly in environments where propagation delays are significant.
 This careful management ensures that the integrity and trustworthiness of the attestation process are maintained.
 
-While periodically pushing Evidence to the Verifier, the Attester only needs to generate and convey evidence generated from Claim values that have changed and new Event Log entries since the previous conveyance.
-These updates reflecting the differences are called "delta" in the sequence diagram above.
+While periodically pushing Evidence to the Verifier, the Attester only needs to generate and convey updates since the previous conveyance.
+These updates, referred to as "delta" in the sequence diagrams, are not limited to net changes of Claim values.
+They MUST include all state changes detected since the previous conveyance, even if values later revert to their prior state.
+For example, if an Attester goes through a sleep or hibernation cycle and a Claim value changes and then reverts, both transitions MUST be reported to the Verifier as soon as possible after resuming operation.
 
 Effectively, the Uni-Directional model allows for a series of Evidence to be pushed to multiple Verifiers simultaneously.
 Methods to detect excessive time drift that would mandate a fresh Handle to be received by the Handle Distributor as well as timing of Handle distribution are out-of-scope of this document.
@@ -734,6 +737,9 @@ Handles provided by a specific subscribing Verifier MUST be used in Evidence gen
 The streaming model without a Broker uses the same information elements as the Challenge/Response and the Uni-Directional model.
 Methods to detect excessive time drift that would render Handles stale and mandate a fresh Handles to be conveyed via another subscribe operation are out-of-scope of this document.
 
+If Evidence or delta Evidence repeatedly fails to verify, a Verifier may terminate the subscription.
+The detailed mechanisms for unsubscribe and re-subscribe are protocol-specific and out of scope for this document; for example, subscription lifecycle management is defined in {{rats-network-device-subscription}}.
+
 ### Streaming Remote Attestation with a Broker {#streaming-with-broker}
 
 This model includes a Broker to facilitate the distribution of messages between RATS roles, such as Attesters and Verifiers.
@@ -877,6 +883,7 @@ Exactly as in the Challenge/Response and Uni-Directional interaction models, the
 In the Publish-Subscribe model above, the Attester publishes Evidence to the topic "AttEv" (= Attestation Evidence) on the PubSub server, to which a Verifier subscribed before.
 The PubSub server notifies Verifiers, accordingly, by forwarding the attestation Evidence.
 Although the above diagram depicts only full attestation Evidence and Event Logs, later attestations may use "deltas' for Evidence and Event Logs.
+The definition of delta Evidence is provided in {{handle-lifecycle-and-propagation-delays}}.
 Verifiers appraise the Evidence and publish the Attestation Result to topic "AttRes" (= Attestation Result) on the PubSub server.
 
 #### Attestation Result Generation