Original text:
richer set of Claims about the Attester, against which the Relying Party applies its Appraisal Policy for Attestation Results. <del> The quality of the Attestation Results depend upon the ability of the Verifier to evaluate the Attester.  Different Attesters have a </del>  different _Strength of Function_ strengthoffunction, which results in the Attestation Results being qualitatively different in strength. By default, the Relying Party does not believe the Attester to be compliant.  Upon receipt of an authentic Attestation Result and given <del> the Appraisal Policy for Attestation Results is satisfied, then the </del>  Attester is allowed to perform the prescribed actions or access.  The <del> simplest such Appraisal Policy might authorize granting the Attester </del>  full access or control over the resources guarded by the Relying <del> Party.  A more complex Appraisal Policy might involve using the </del>  information provided in the Attestation Result to compare against expected values, or to apply complex analysis of other information contained in the Attestation Result. about the Attester, for use by Relying Parties, much like physical passports and drivers licenses include personal information such as name and date of birth.  Unlike Evidence, which is often very device- <del> and vendor-specific, Attestation Results can be vendor-neutral if the Verifier has a way to generate vendor-agnostic information based on the appraisal of vendor-specific information in Evidence.  This </del>  allows a Relying Party's appraisal policy to be simpler, potentially based on standard ways of expressing the information, while still allowing interoperability with heterogeneous devices. In all cases, attestation key provisioning must ensure that only attestation key material that is generated by a valid Endorser is <del> established in Attesters. </del>  12.2.

Reviewer comments:
This is the portion of the complete review that contains minor/editorial changes aggregated in a single PR and various commits as discussed in the last editor meeting.
Are you sure that making Composite Device a term isn't a better idea?
I agree with that. There are also some other terms that I would capitalize. But this is the editorial part of the changes so I stuck with the groups consensus. Could you open an issue on "terms you want to capitalize"?
When I ask github to render the diff, it says that it can not. ("Oh my") it says. I wonder if there is an error in the markdown?

Revised text:
richer set of Claims about the Attester, against which the Relying Party applies its Appraisal Policy for Attestation Results.  <ins> The quality of the Attestation Results depends upon the ability of the Verifier to evaluate the Attester.  Different Attesters have a </ins> different _Strength of Function_ strengthoffunction, which results in the Attestation Results being qualitatively different in strength. By default, the Relying Party does not believe the Attester to be compliant.  Upon receipt of an authentic Attestation Result and given  <ins> the Appraisal Policy for Attestation Results is satisfied, the </ins> Attester is allowed to perform the prescribed actions or access.  The  <ins> simplest such appraisal policy might authorize granting the Attester </ins> full access or control over the resources guarded by the Relying  <ins> Party.  A more complex appraisal policy might involve using the </ins> information provided in the Attestation Result to compare against expected values, or to apply complex analysis of other information contained in the Attestation Result. about the Attester, for use by Relying Parties, much like physical passports and drivers licenses include personal information such as name and date of birth.  Unlike Evidence, which is often very device-  <ins> and vendor-specific, Attestation Results can be vendor-neutral, if the Verifier has a way to generate vendor-agnostic information based on the appraisal of vendor-specific information in Evidence.  This </ins> allows a Relying Party's appraisal policy to be simpler, potentially based on standard ways of expressing the information, while still allowing interoperability with heterogeneous devices. In all cases, attestation key provisioning must ensure that only attestation key material that is generated by a valid Endorser is  <ins> established in Attesters.  For many use cases, this will involve physical security at the facility, to prevent unauthorized devices from being manufactured that may be counterfeit or incorrectly configured. </ins> 12.2.