Draft: draft-ietf-rats-architecture

Commentary: The word ' device ' is used dozens of times throughout the document . However , it often does n'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 do n'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 .
Paragraph (version A):
The text below summarizes the activities conducted by the roles
illustrated in dataflow.
Paragraph (version A):
An Attester creates Evidence that is conveyed to a Verifier.
Paragraph (version A):
A Verifier uses the Evidence, any Reference Values from Reference
Value Providers, and any Endorsements from Endorsers, by applying an
Appraisal Policy for Evidence to assess the trustworthiness of the
Attester.  This procedure is called the appraisal of Evidence.
Paragraph (version A):
Subsequently, the Verifier generates Attestation Results for use by
Relying Parties.
Paragraph (version A):
A Relying Party uses Attestation Results by applying its own
appraisal policy to make application-specific decisions, such as
authorization decisions.  This procedure is called the appraisal of
Attestation Results.
Paragraph (version B):
The text below summarizes the activities conducted by the roles
illustrated in dataflow.  Roles are assigned to entities.  Entities
are often system components RFC4949, such as devices.  As the term
device is typically more intuitive than the term entity or system
component, device is often used as a illustrative synonym throughout
this document.
Paragraph (version B):
The Attester role is assigned to entities that create Evidence that
is conveyed to a Verifier.
Paragraph (version B):
The Verifier role is assigned to entities that use the Evidence, any
Reference Values from Reference Value Providers, and any Endorsements
from Endorsers, by applying an Appraisal Policy for Evidence to
assess the trustworthiness of the Attester.  This procedure is called
the appraisal of Evidence.
Paragraph (version B):
Subsequently, the Verifier role generates Attestation Results for use
by Relying Parties.
Paragraph (version B):
The Relying Party role is assigned to entities that uses Attestation
Results by applying its own appraisal policy to make application-
specific decisions, such as authorization decisions.  This procedure
is called the appraisal of Attestation Results.
Paragraph (version A):
See messages for further discussion of the conceptual messages shown
in dataflow.
Paragraph (version A):
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.  All compositions of Attesting and Target Environments
discussed in this architecture can be combined into more complex
implementations.
Paragraph (version B):
See messages for further discussion of the conceptual messages shown
in dataflow.  Section terminology provides a more complete definition
of all RATS roles.
Paragraph (version B):
As shown in twotypes-env, an Attester consists of at least one
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.