Draft: draft-ietf-rats-architecture

Commentary: only the most essential items : three more timestamp types based on TUDA , trying to generalize it a bit a few periods to text that seems to express sentences
Paragraph (version A):
We now walk through a number of hypothetical examples of how a
solution might be built.  This list is not intended to be complete,
but is just representative enough to highlight various timing
considerations.
Paragraph (version B):
Using the table above, a number of hypothetical examples of how a
solution might be built are illustrated below.  a solution might be
built.  This list is not intended to be complete, but is just
representative enough to highlight various timing considerations.
Paragraph (version A):
The following example illustrates a hypothetical Background-Check
Model solution that uses timestamps and requires roughly synchronized
clocks between the Attester, Verifier, and Relying Party.
Paragraph (version A):
The time considerations in this example are equivalent to those
discussed under Example 1 above.
Paragraph (version B):
The following example illustrates a hypothetical Background-Check
Model solution that uses centrally generated identifiers for explicit
time-keeping (referred to as "handle" in this example).  Handles can
be qualifying data, such as nonces or signed timestamps.  In this
example, centrally generated signed timestamps and - and synchronized
clocks between all entities - are distributed in periodic intervals
as handles.  If the Attester lacks a source of time based on an
absolute timescale, a relative source of time, such as a tick counter
can be used, alternatively.  In this example, evidence generation is
not triggered at value generation, but at events at which the
Attesting Environment becomes of changes to the Target Environment.
Paragraph (version B):
In comparison with example 1, the time considerations in this example
go into more detail with respect to the life-cycle of Claims and
Evidence.  While the goal is to create up-to-date and recent Evidence
as soon as possible, typically there is a latency between value
generation and Attester awareness.
Paragraph (version B):
At time(AA) the Attesting Environment is able to trigger an event
(e.g. based on an Event-Condition-Action model) to create attestation
Evidence that is as recent as possible.  In essence, at time(AA) the
Attesting Environment is aware of new values that where generated at
time(VG) and corresponding Claim values are collected immediately.
Consecutively, Evidence based on relevant "old" Claims and the just
collected "new" Claims is generated at time(EG).  In essence, the
Claims used to generate the Evidence are generated at various
time(VG) before time(AA).
Paragraph (version B):
In order to create attestation Evidence at at time(AA), the Attester
requires a fresh (i.e. not expired) centrally generated handle that
has been distributed to all involved entities.
Paragraph (version B):
In general, The duration a handle remains fresh depends on the
content-type of the handle.  If it is a (relative or absolute)
timestamp, clocks synchronized with a shared and trustworthy source
of time are required.  If another value type is used as a handle, the
reception time of the handle time(HD) provides an epoch (relative
time of zero) for measuring the duration of validity (similar to a
heart-beat timeout).  From the point of view of a Verifier, validity
of Evidence is only given if the handle used in Evidence satisfies
delta(time(HD),time(EG))distribution-interval.
Paragraph (version B):
In this usage scenario, time(VG), time(AA), and time(EG) are tightly
coupled.  Also, the absolute point in time at which a handle is
received by all three entities is assumed to be close to identical.