Draft: draft-ietf-rats-architecture

Commentary: Reworded sections containing root of trust leaving a single parenthetical that associates the term loosely with an attesting environment that is implicitly trusted . 
 It makes sense to remove the term ' root of trust ' since the document does n't define it . It might make sense to reference other industry specs that have relevant definitions such as NISTIR 8320A. 
 apparently , this taks has no assignees . Do you want to do that ? 
 OK , assign it to me .
Paragraph (version A):
Typically, solutions start with a specific component (called a root
of trust) that is intended to provide trustworthy device identity and
protected storage for measurements.  The system components perform a
series of measurements that may be signed via functions provided by a
root of trust, considered as Evidence about present system
components, such as hardware, firmware, BIOS, software, etc.
Paragraph (version B):
Typically, a trustworthy solution starts with a specific component
(sometimes referred to as a root of trust) that often provides
trustworthy device identity, and performs a series of operations that
enables trustworthiness appraisals for other components.  Such
components perform operations that help determine the trustworthiness
of yet other components, by collecting, protecting or signing
measurements.  Measurements that have been signed by such components
comprise Evidence that when evaluated either supports or refutes a
claim of trustworthiness.  Measurements can describe a variety of
attributes of system components, such as hardware, firmware, BIOS,
software, etc.
Paragraph (version A):
By definition, the Attester role generates Evidence.  An Attester may
consist of one or more nested environments (layers).  The root layer
of an Attester includes at least one root of trust.  In order to
appraise Evidence generated by an Attester, the Verifier needs to
trust the Attester's root of trust.  Trust in the Attester's root of
trust can be established in various ways as discussed in verifier.
Paragraph (version A):
In layered attestation, a root of trust is the initial Attesting
Environment.  Claims can be collected from or about each layer.  The
corresponding Claims can be structured in a nested fashion that
reflects the nesting of the Attester's layers.  Normally, Claims are
not self-asserted, rather a previous layer acts as the Attesting
Environment for the next layer.  Claims about a root of trust
typically are asserted by an Endorser.
Paragraph (version B):
By definition, the Attester role generates Evidence.  An Attester may
consist of one or more nested environments (layers).  The bottom
layer of an Attester has an Attesting Environment that is typically
designed to be immutable or difficult to modify by malicious code.
In order to appraise Evidence generated by an Attester, the Verifier
needs to trust various layers, including the bottom Attesting
Environment.  Trust in the Attester's layers, including the bottom
layer, can be established in various ways as discussed in verifier.
Paragraph (version B):
In layered attestation, Claims can be collected from or about each
layer beginning with an initial layer.  The corresponding Claims can
be structured in a nested fashion that reflects the nesting of the
Attester's layers.  Normally, Claims are not self-asserted, rather a
previous layer acts as the Attesting Environment for the next layer.
Claims about an initial layer typically are asserted by an Endorser.
Paragraph (version A):
The root of trust protects both the conveyance channel key
material and the Attesting Environment with equivalent strength
protections.
Paragraph (version B):
A trusted environment protects the conveyance channel's key
material which may depend on other Attesting Environments with
equivalent strength protections.