Draft: draft-ietf-rats-architecture

Commentary: ` Can you say what these are ? I do n’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 do n't know how to make that clearer . 
 fixed by .
Paragraph (version A):
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.
Paragraph (version A):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.