Change:
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 doesn't define it. It might make sense to reference other industry specs that have relevant definitions such as NISTIR 8320A.
NAME apparently, this taks has no assignees. Do you want to do that?
OK, assign it to me.

Discussion:
devices from getting access to the network and potentially harming others. <del> 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. </del> <ins> 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. </ins> A device desiring access to a network.

3.2. By definition, the Attester role generates Evidence.  An Attester may <del> 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. 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. </del> <ins> 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. 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. </ins> The example device illustrated in layered includes (A) a BIOS stored in read-only memory, (B) a bootloader, and (C) an operating system

by the Attesting Environment that has the key material that protects the conveyance channel <del> The root of trust protects both the conveyance channel key material and the Attesting Environment with equivalent strength protections. </del> <ins> A trusted environment protects the conveyance channel's key material which may depend on other Attesting Environments with equivalent strength protections. </ins> As illustrated in I-D.birkholz-rats-uccs, an entity that receives unprotected Evidence via a trusted conveyance channel always takes on