Original text:
generated using the latest Appraisal Policy for Evidence. Freshness is assessed based on the Appraisal Policy for Evidence or <del> Attestation Results, that compares the estimated epoch against an </del>  "expiry" threshold defined locally to that policy.  There is, however, always a race condition possible in that the state of the Attester, and the appraisal policies might change immediately after the Evidence or Attestation Result was generated.  The goal is merely to narrow their recentness to something the Verifier (for Evidence) or Relying Party (for Attestation Result) is willing to accept.  Some <del> flexibility on the freshness requirement, however, is a key component for enabling caching and reuse of both Evidence and Attestation Results, which is especially valuable in cases where their computation uses a substantial part of the resource budget (e.g., energy in constrained devices). </del>  <del> There are two common approaches for determining the epoch of an Evidence or Attestation Result. </del>  The first approach is to rely on synchronized and trustworthy clocks, and include a signed timestamp (see I-D.birkholz-rats-tuda) along with the Claims in the Evidence or Attestation Result.  Timestamps <del> can be added on a per-Claim basis, to distinguish the time of </del>  creation of Evidence or Attestation Result from the time that a specific Claim was generated.  The clock's trustworthiness typically requires additional Claims about the signer's time synchronization mechanism.  A second approach places the onus of timekeeping solely on the <del> Verifier (for Evidence), or the Relying Party (for Attestation </del>  Results), and might be suitable, for example, in case the Attester does not have a reliable clock or time synchronization is otherwise impaired.  In this approach, a non-predictable nonce is sent by the The time between the creation of Claims and the collection of Claims is indistinguishable.  Implicit and explicit timekeeping can be combined into hybrid mechanisms.  For example, if clocks exist and are considered trustworthy but are not synchronized, a nonce-based exchange may be used to determine the (relative) time offset between the involved <del> peers, followed by any number of timestamp based exchanges.  In another setup where all Roles (Attesters, Verifiers and Relying Parties) share the same broadcast channel, the nonce-based approach may be used to anchor all parties to the same (relative) timeline, without requiring synchronized clocks, by having a central entity emit nonces at regular intervals and have the "current" nonce included in the produced Evidence or Attestation Result. </del>  It is important to note that the actual values in Claims might have been generated long before the Claims are signed.  If so, it is the 16.3. <del> Handles are a third option to establish time-keeping next to nonces or timestamps.  Handles are opaque data intended to be available to all RATS roles that interact with each other, such as the Attester or Verifier, in specified intervals.  To enable this availability, handles are distributed centrally by the Handle Distributor role over the network.  As any other role, the Handle Distributor role can be taken on by a dedicated entity or collapsed with other roles, such as a Verifier.  The use of handles can compensate for a lack of clocks or other sources of time on entities taking on RATS roles.  The only entity that requires access to a source of time is the entity taking on the role of Handle Distributor. Handles are different from nonces as they can be used more than once and can be used by more than one entity at the same time.  Handles are different from timestamps as they do not have to convey information about a point in time, but their reception creates that information.  The reception of a handle is similar to the event that increments a relative tickcounter.  Receipt of a new handle invalidates a previously received handle. In this example, Evidence generation based on received handles always uses the current (most recent) handle.  As handles are distributed over the network, all involved entities receive a fresh handle at roughly the same time.  Due to distribution over the network, there is some jitter with respect to the time the Handle is received, time(HR), for each involved entity.  To compensate for this jitter, there is a small period of overlap (a specified offset) in which both a current handle and corresponding former handle are valid in Evidence appraisal: "validity-duration = time(HR'_v) + offset - time(HR_v)".  The offset is typically based on a network's round trip time.  Analogously, the generation of valid Evidence is only possible, if the age of the handle used is lower than the validity- duration: "time(HR_v) - time(EG_a) < validity-duration". </del>  From the point of view of a Verifier, the generation of valid Evidence is only possible, if the age of the handle used in the

Reviewer comments:
Per last week's design team discussion. Signed-off-by: Dave Thaler
In general, I like the re-introduction of the "timekeeping" subsections a lot. +1

Revised text:
generated using the latest Appraisal Policy for Evidence. Freshness is assessed based on the Appraisal Policy for Evidence or  <ins> Attestation Results that compares the estimated epoch against an </ins> "expiry" threshold defined locally to that policy.  There is, however, always a race condition possible in that the state of the Attester, and the appraisal policies might change immediately after the Evidence or Attestation Result was generated.  The goal is merely to narrow their recentness to something the Verifier (for Evidence) or Relying Party (for Attestation Result) is willing to accept.  Some  <ins> flexibility on the freshness requirement is a key component for enabling caching and reuse of both Evidence and Attestation Results, which is especially valuable in cases where their computation uses a substantial part of the resource budget (e.g., energy in constrained devices). </ins>  <ins> There are three common approaches for determining the epoch of Evidence or an Attestation Result. 10.1. </ins> The first approach is to rely on synchronized and trustworthy clocks, and include a signed timestamp (see I-D.birkholz-rats-tuda) along with the Claims in the Evidence or Attestation Result.  Timestamps  <ins> can also be added on a per-Claim basis to distinguish the time of </ins> creation of Evidence or Attestation Result from the time that a specific Claim was generated.  The clock's trustworthiness typically requires additional Claims about the signer's time synchronization mechanism. <ins> 10.2. </ins> A second approach places the onus of timekeeping solely on the  <ins> Verifier (for Evidence) or the Relying Party (for Attestation </ins> Results), and might be suitable, for example, in case the Attester does not have a reliable clock or time synchronization is otherwise impaired.  In this approach, a non-predictable nonce is sent by the The time between the creation of Claims and the collection of Claims is indistinguishable. <ins> 10.3. A third approach relies on having epoch "handles" periodically sent to both the sender and receiver of Evidence or Attestation Results by some "Handle Distributor". Handles are different from nonces as they can be used more than once and can even be used by more than one entity at the same time. Handles are different from timestamps as they do not have to convey information about a point in time, i.e., they are not necessarily monotonically increasing integers. Like the nonce approach, this allows associating a "rough" epoch without requiring a reliable clock or time synchronization in order to generate or appraise the freshness of Evidence or Attestation Results.  Only the Handle Distributor requires access to a clock so it can periodically send new epoch handles. The most recent handle is included in the produced Evidence or Attestation Results, and the appraising entity can compare the handle in received Evidence or Attestation Results against the latest handle it received from the Handle Distributor to determine if it is within the current epoch.  An actual solution also needs to take into account race conditions when transitioning to a new epoch, such as by using a counter signed by the Handle Distributor as the handle, or by including both the current and previous handles in messages and/or checks, by requiring retries in case of mismatching handles, or by buffering incoming messages that might be associated with a handle that the receiver has not yet obtained. Whereas the nonce approach typically requires the appraising entity to keep state for each nonce generated, the handle approach minimizes the state kept to be independent of the number of Attesters or Verifiers from which it expects to receive Evidence or Attestation Results, as long as all use the same Handle Distributor. 10.4. </ins> Implicit and explicit timekeeping can be combined into hybrid mechanisms.  For example, if clocks exist and are considered trustworthy but are not synchronized, a nonce-based exchange may be used to determine the (relative) time offset between the involved  <ins> peers, followed by any number of timestamp based exchanges. </ins> It is important to note that the actual values in Claims might have been generated long before the Claims are signed.  If so, it is the 16.3.  <ins> The following example illustrates a hypothetical Passport Model solution that uses handles instead of nonces or timestamps.  In this example, Evidence generation based on received handles always uses the current (most recent) handle.  As handles are distributed over the network, all involved entities receive a fresh handle at roughly the same time.  Due to distribution over the network, there is some jitter with respect to the time the Handle is received, time(HR), for each involved entity.  To compensate for this jitter, there is a small period of overlap (a specified offset) in which both a current handle and corresponding former handle are valid in Evidence appraisal: "validity-duration = time(HR'_v) + offset - time(HR_v)". The offset is typically based on a network's round trip time. Analogously, the generation of valid Evidence is only possible, if the age of the handle used is lower than the validity-duration: "time(HR_v) - time(EG_a) < validity-duration". </ins> From the point of view of a Verifier, the generation of valid Evidence is only possible, if the age of the handle used in the