Change:
some other mechanism. See messages for further discussion of the conceptual messages shown <del> in dataflow. </del> <ins> in dataflow.  Section terminology provides a more complete definition of all RATS roles. </ins> 3.1. As shown in twotypes-env, an Attester consists of at least one <del> 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.  All compositions of Attesting and Target Environments discussed in this architecture can be combined into more complex implementations. </del> <ins> Attesting Environment and at least one Target Environment co-located in one entity.  In some implementations, the Attesting and Target Environments might be combined into one environment.  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. All compositions of Attesting and Target Environments discussed in this architecture can be combined into more complex implementations. </ins> Claims are collected from Target Environments.  That is, Attesting Environments collect the values and the information to be represented

Discussion:
The word 'device' is used dozens of times throughout the document. However, it often doesn't imply 'device' but rather a component of the device. RFC4949 defines 'system component' as: system component (I) A collection of system resources that (a) forms a physical or logical part of the system, (b) has specified functions and interfaces, and (c) is treated (e.g., by policies or specifications) as existing independently of other parts of the system. (See: subsystem.) (O) /ITSEC/ An identifiable and self-contained part of a TOE. Usage: Component is a relative term because components may be nested; i.e., one component of a system may be a part of another component of that system. Tutorial: Components can be characterized as follows: A "physical component" has mass and takes up space. A "logical component" is an abstraction used to manage and coordinate aspects of the physical environment, and typically represents a set of states or capabilities of the system. This definition seems appropriate for most of the places where 'device' is used. Alternatively, 'system' could be used if 'system component' would be to narrow.
I think that we struggled a lot to arrive at the compromise of saying "device". I agree with you that there are composite devices which contain "system components". But, if we do the direction of using that term, we will lose readers and lose comprehension. I do not agree with this proposal. If it is unclear that "device" is a role, then I guess we could add that to the Terminology.
If I were to be pedantic about what a device is using capital letter names, it is both, it's an entity (that performs the role). The Architecture is a description while normative drafts are more precise / formal descriptions or definitions. I don't feel strongly about it. But some people seem to feel strongly that device is used too much. Does it make sense to talk about how we use 'device' and refer to 4949 system component as being roughly equivalent?
We could say one time early in the text that we mean "system component" when we mean device, but for the sake of simplicity use device as a representative concept throughout the document.
Makes sense.