Original text:
built.  This list is not intended to be complete, but is just representative enough to highlight various timing considerations.  15.1. The following example illustrates a hypothetical Passport Model can directly compare it to its own clock and timestamps. The Verifier can check whether the Evidence is fresh when appraising <del> it at time(RG) by checking "time(RG) - time(EG) < Threshold", where the Verifier's threshold is large enough to account for the maximum permitted clock skew between the Verifier and the Attester. </del>  <del> If time(VG) is also included in the Evidence along with the claim </del>  value generated at that time, and the Verifier decides that it can <del> trust the time(VG) value, the Verifier can also determine whether the claim value is recent by checking "time(RG) - time(VG) < Threshold", again where the threshold is large enough to account for the maximum permitted clock skew between the Verifier and the Attester. </del>  The Relying Party can check whether the Attestation Result is fresh <del> when appraising it at time(RA) by checking "time(RA) - time(RG) < Threshold", where the Relying Party's threshold is large enough to </del>  account for the maximum permitted clock skew between the Relying Party and the Verifier.  The result might then be used for some time (e.g., throughout the lifetime of a connection established at <del> time(RA)).  The Relying Party must be careful, however, to not allow continued use beyond the period for which it deems the Attestation Result to remain fresh enough.  Thus, it might allow use (at time(OP)) as long as "time(OP) - time(RG) < Threshold".  However, if the Attestation Result contains an expiry time time(RX) then it could explicitly check "time(OP) < time(RX)". </del>  15.2. As a result, the receiver of a conceptual message containing a timestamp cannot directly compare it to its own clock or timestamps. <del> Thus we use a suffix (a for Attester, v for verifier, and r for </del>  Relying Party) on the IDs below indicating which clock generated them, since times from different clocks cannot be compared.  Only the delta between two events from the sender can be used by the receiver. 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 <del> roughly the same time.  The time that represents this event is named Handle received: time(HR).  Due to distribution over the network, there is some jitter with respect to 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') + offset - time(HR)".  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) - time(EG) < 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 Evidence generation is younger than the duration of the distribution <del> interval - "(time(HD')-time(HD)) - (time(HR)-time(EG)) < validity- duration". </del>  Due to the validity-duration of handles, multiple different pieces of Evidence can be generated based on the same handle.  The resulting

Reviewer comments:
This pull request puts _X on all time points. Please review for accuracy.
I am neutral/okay with consistently adding suffixes to every event label

Revised text:
built.  This list is not intended to be complete, but is just representative enough to highlight various timing considerations. <ins> All times are relative to the local clocks, indicated by an "a" (Attester), "v" (Verifier), or "r" (Relying Party) suffix. How and if clocks are synchronized depends upon the model. </ins> 15.1. The following example illustrates a hypothetical Passport Model can directly compare it to its own clock and timestamps. The Verifier can check whether the Evidence is fresh when appraising  <ins> it at time(RG_v) by checking "time(RG_v) - time(EG_a) < Threshold", where the Verifier's threshold is large enough to account for the maximum permitted clock skew between the Verifier and the Attester. </ins>  <ins> If time(VG_a) is also included in the Evidence along with the claim </ins> value generated at that time, and the Verifier decides that it can  <ins> trust the time(VG_a) value, the Verifier can also determine whether the claim value is recent by checking "time(RG_v) - time(VG_a) < Threshold", again where the threshold is large enough to account for the maximum permitted clock skew between the Verifier and the Attester. </ins> The Relying Party can check whether the Attestation Result is fresh  <ins> when appraising it at time(RA_r) by checking "time(RA_r) - time(RG_v) < Threshold", where the Relying Party's threshold is large enough to </ins> account for the maximum permitted clock skew between the Relying Party and the Verifier.  The result might then be used for some time (e.g., throughout the lifetime of a connection established at  <ins> time(RA_r)).  The Relying Party must be careful, however, to not allow continued use beyond the period for which it deems the Attestation Result to remain fresh enough.  Thus, it might allow use (at time(OP_r)) as long as "time(OP_r) - time(RG_v) < Threshold". However, if the Attestation Result contains an expiry time time(RX_v) then it could explicitly check "time(OP_r) < time(RX_v)". </ins> 15.2. As a result, the receiver of a conceptual message containing a timestamp cannot directly compare it to its own clock or timestamps.  <ins> Thus we use a suffix ("a" for Attester, "v" for Verifier, and "r" for </ins> Relying Party) on the IDs below indicating which clock generated them, since times from different clocks cannot be compared.  Only the delta between two events from the sender can be used by the receiver. 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  <ins> 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 Evidence generation is younger than the duration of the distribution  <ins> interval - "(time(HR'_v)-time(HR_v)) - (time(HR_a)-time(EG_a)) < validity-duration". </ins> Due to the validity-duration of handles, multiple different pieces of Evidence can be generated based on the same handle.  The resulting