Original text:
or compromised 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 provides device identity and protected storage for </del>  measurements.  The system components perform a series of measurements <del> that may be signed by the Root of Trust, considered as Evidence about </del>  the hardware, firmware, BIOS, software, etc. that is running. A device desiring access to a network By definition, the Attester role creates Evidence.  An Attester may consist of one or more nested or staged environments, adding complexity to the architectural structure.  The unifying component is <del> the Root of Trust and the nested, staged, or chained attestation </del>  Evidence produced.  The nested or chained structure includes Claims, collected by the Attester to aid in the assurance or believability of the attestation Evidence. security comes when information can be vouched for by hardware or by ROM code, especially if such hardware is physically resistant to hardware tampering.  The component that is implicitly trusted is <del> often referred to as a Root of Trust. </del>  A conveyance protocol that provides authentication and integrity protection can be used to convey unprotected Evidence, assuming the 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 </del>  material and the Attesting Environment with equivalent strength protections. architecture to protect against replay attacks. To assess the security provided by a particular Appraisal Policy, it <del> is important to understand the strength of the Root of Trust, e.g., </del>  whether it is mutable software, or firmware that is read-only after boot, or immutable hardware/ROM.

Reviewer comments:
Per design team meeting today Signed-off-by: Dave Thaler
I think it should be root of trust because it is not a defined term like Attester or Verifier.
Lower case is fine, I think. Any objections?

Revised text:
or compromised devices from getting access to the network and potentially harming others.  <ins> Typically, solutions start with a specific component (called a "root of trust") that provides device identity and protected storage for </ins> measurements.  The system components perform a series of measurements  <ins> that may be signed by the root of trust, considered as Evidence about </ins> the hardware, firmware, BIOS, software, etc. that is running. A device desiring access to a network By definition, the Attester role creates Evidence.  An Attester may consist of one or more nested or staged environments, adding complexity to the architectural structure.  The unifying component is  <ins> the root of trust and the nested, staged, or chained attestation </ins> Evidence produced.  The nested or chained structure includes Claims, collected by the Attester to aid in the assurance or believability of the attestation Evidence. security comes when information can be vouched for by hardware or by ROM code, especially if such hardware is physically resistant to hardware tampering.  The component that is implicitly trusted is  <ins> often referred to as a root of trust. </ins> A conveyance protocol that provides authentication and integrity protection can be used to convey unprotected Evidence, assuming the by the Attesting Environment that has the key material that protects the conveyance channel  <ins> The root of trust protects both the conveyance channel key </ins> material and the Attesting Environment with equivalent strength protections. architecture to protect against replay attacks. To assess the security provided by a particular Appraisal Policy, it  <ins> is important to understand the strength of the root of trust, e.g., </ins> whether it is mutable software, or firmware that is read-only after boot, or immutable hardware/ROM.