Original text:
3.3. <del> An Attester consists of at least one Attesting Environment and at least one Target Environment.  In some implementations, the Attesting and Target Environments might be combined.  Other implementations might have multiple Attesting and Target Environments, such as in the examples described in more detail in layered-attestation and compositedevice.  Other examples may exist.  Besides, the examples discussed could be combined into even more complex implementations. Claims are collected from Target Environments, as shown in twotypes- env.  That is, Attesting Environments collect the values and the information to be represented in Claims, by reading system registers and variables, calling into subsystems, taking measurements on code, memory, or other security related assets of the Target Environment. Attesting Environments then format the claims appropriately, and typically use key material and cryptographic functions, such as signing or cipher algorithms, to create Evidence.  There is no limit to or requirement on the types of hardware or software environments that can be used to implement an Attesting Environment, for example: Trusted Execution Environments (TEEs), embedded Secure Elements (eSEs), Trusted Platform Modules (TPMs), or BIOS firmware.  An arbitrary execution environment may not, by default, be capable of claims collection for a given Target Environment.  Execution environments that are designed specifically to be capable of claims collection are referred to in this document as Attesting Environments. </del>  3.4.

Reviewer comments:
` Can you say what these are? I don’t think they need to be in the glossary, but some clue as to how you tell one from another might help see why there’s a distinction
My opinion is that the 2nd paragraph of the section (the paragraph after the sentence quoted) already defines them. I don't know how to make that clearer.
fixed by .

Revised text:
3.3.  <ins> As shown in twotypes-env, an Attester consists of at least one Attesting Environment and at least one Target Environment.  In some implementations, the Attesting and Target Environments might be combined.  Other implementations might have multiple Attesting and Target Environments, such as in the examples described in more detail in layered-attestation and compositedevice.  Other examples may exist.  Besides, the examples discussed could be combined into even more complex implementations. Claims are collected from Target Environments.  That is, Attesting Environments collect the values and the information to be represented in Claims, by reading system registers and variables, calling into subsystems, taking measurements on code, memory, or other security related assets of the Target Environment.  Attesting Environments then format the claims appropriately, and typically use key material and cryptographic functions, such as signing or cipher algorithms, to create Evidence.  There is no limit to or requirement on the types of hardware or software environments that can be used to implement an Attesting Environment, for example: Trusted Execution Environments (TEEs), embedded Secure Elements (eSEs), Trusted Platform Modules (TPMs), or BIOS firmware.  An arbitrary execution environment may not, by default, be capable of claims collection for a given Target Environment.  Execution environments that are designed specifically to be capable of claims collection are referred to in this document as Attesting Environments. </ins> 3.4.