Original text:
15.  The table below defines a number of relevant events, with an ID that is used in subsequent diagrams.  The times of said events might be defined in terms of an absolute clock time such as Coordinated How and if clocks are synchronized depends upon the model. <del> 15.1. </del>  The following example illustrates a hypothetical Passport Model solution that uses timestamps and requires roughly synchronized However, if the Attestation Result contains an expiry time time(RX_v) then it could explicitly check "time(OP_r) < time(RX_v)". <del> 15.2. </del>  The following example illustrates a hypothetical Passport Model solution that uses nonces and thus does not require that any clocks Relying Party can check "time(OP_r)-time(NS_r) < time(RX_v)- time(RG_v)". <del> 15.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 Model solution that uses handles and requires a trustworthy time source available to the Handle Distributor role. <del> 15.4. </del>  The following example illustrates a hypothetical Background-Check Model solution that uses timestamps and requires roughly synchronized The time considerations in this example are equivalent to those discussed under Example 1 above. <del> 15.5. </del>  The following example illustrates a hypothetical Background-Check Model solution that uses nonces and thus does not require that any

Reviewer comments:
this is not complete and does not pass xml2rfc yet. Please add/fix your name/email. Or remove your email. Or foo at example dot com it.

Revised text:
15. <ins> Thomas Hardjono created older versions of the terminology section in collaboration with Ned Smith.  Eric Voit provided the conceptual separation between Attestation Provision Flows and Attestation Evidence Flows.  Monty Wisemen created the content structure of the first three architecture drafts.  Carsten Bormann provided many of the motivational building blocks with respect to the Internet Threat Model. 16. </ins> The table below defines a number of relevant events, with an ID that is used in subsequent diagrams.  The times of said events might be defined in terms of an absolute clock time such as Coordinated How and if clocks are synchronized depends upon the model.  <ins> 16.1. </ins> The following example illustrates a hypothetical Passport Model solution that uses timestamps and requires roughly synchronized However, if the Attestation Result contains an expiry time time(RX_v) then it could explicitly check "time(OP_r) < time(RX_v)".  <ins> 16.2. </ins> The following example illustrates a hypothetical Passport Model solution that uses nonces and thus does not require that any clocks Relying Party can check "time(OP_r)-time(NS_r) < time(RX_v)- time(RG_v)".  <ins> 16.3. </ins> Handles are a third option to establish time-keeping next to nonces or timestamps.  Handles are opaque data intended to be available to Model solution that uses handles and requires a trustworthy time source available to the Handle Distributor role.  <ins> 16.4. </ins> The following example illustrates a hypothetical Background-Check Model solution that uses timestamps and requires roughly synchronized The time considerations in this example are equivalent to those discussed under Example 1 above.  <ins> 16.5. </ins> The following example illustrates a hypothetical Background-Check Model solution that uses nonces and thus does not require that any