Draft: draft-ietf-rats-architecture

Commentary: 4.4 " Roles and Entities " , also removed the last occurrence of the artifact " role composition " , and retained section 4.3 as is and the usage scenario from issue 
 The introduction section uses the phrase " role compositions and data flows " then mentions " Passport Model " as an example of a role composition . In section 4.3 on Composite Device the second to last section describes " combinations of roles " using an example involving a Composite Device . I think the architecture should have crisper understanding of two concepts a ) " topological models " ( as defined by the section 5 heading that describes Passport , BKC and Hybrid ; b ) " role composition " which ought to refer to the " combining of roles " by a given entity . The terms " role composition " and " combining of roles " are too similar for them to have different meanings and " role composition " as an alias for " topological models " is unnecessary . I suggest pulling the second to the last paragraph in section 4.3 into a new section 4.4 titled " Role Composition " that has a paragraph defining role composition conceptually followed by the paragraph taken from section 4.3 . Suggested Text for section 4.4 : RATS roles are implemented by entities ( e.g. , devices ) . A simple realization of the architecture associates a single role to a single entity ; for example , the topological models described in section 5.1 and 5.2 follow this convention . However , entities may host multiple roles as a way to accommodate more sophisticated use cases and deployment scenarios . An entity that both connects to a wide - area network and to a system bus may play both  and Verifier roles . As a system bus entity , a Verifier consumes Evidence from other devices connected to the system bus that implement an Attester role . As a wide - area network connected entity , it may implement an Attester role . The entity , as a system bus Verifier , may choose to fully isolate its role as a wide - area network Attester . Alternatively , attestation results might reflect an aggregation of system bus operational state claims in the form of Evidence . For example , in the Composite Device scenario , the lead Attester ... < paste remainder of paragraph from section 4.3Additionally , the introduction section should change " role composition " terminology to " topological models " as it references Passport . 
 " Role Composition " will be worked out of document . 
 Also addressed in Issue55 . I recommend closing this issue . 
 " role composition " no longer appears in the doc . I agree this can be closed . 
 Taking into account the recent trends in terminology used in draft text & PR , I am proposing to add Entity and Sub - Entity to the terminology section . We do not need to over - specify here . Hence , only mentioning Composite Device and Components as an examplew for each of the terms in the definition text could be enough . Are there any objections to this proposal ? If not , we could create a PR and address it in next week 's meeting . 
 Agree so long as it is understood that other words can be used in place of entity when they add context for readability such as component , sub - component , device , environment and so forth . 
 This now relates to the comments on
Paragraph (version A):
This documents defines a flexible architecture with corresponding
roles and their interaction via conceptual messages.  Additionally,
this document defines a universal set of terms that can be mapped to
various existing and emerging Remote Attestation Procedures.  Common
role compositions and data flows, such as the "Passport Model" and
the "Background-Check Model" are illustrated to enable readers of
this document to map their current and emerging solutions to the
architecture provided and the corresponding terminology defined.  A
common terminology that provides a well-understood semantic meaning
to the concepts, roles, and models in this document is vital to
create semantic interoperability between solutions and across
different platforms.
Paragraph (version B):
This documents defines a flexible architecture with corresponding
roles and their interaction via conceptual messages.  Additionally,
this document defines a universal set of terms that can be mapped to
various existing and emerging Remote Attestation Procedures.  Common
topological models and the data flows associated with them, such as
the "Passport Model" and the "Background-Check Model" are
illustrated.  The purpose is to enable readers of this document to
map their current and emerging solutions to the architecture provided
and the corresponding terminology defined.  A common terminology that
provides a well-understood semantic meaning to the concepts, roles,
and models in this document is vital to create semantic
interoperability between solutions and across different platforms.
Paragraph (version B):
An entity in the RATS architecture includes at least one of the roles
defined in this document.  As a result, the entity can participate as
a constituent of the RATS architecture.  Additionally, an entity can
aggregate more than one role into itself.  These collapsed roles
combine the duties of multiple roles.  In these cases, interaction
between these roles do not necessarily use the Internet Protocol.
They can be using a loopback device or other IP-based communication
between separate environments, but they do not have to.  Alternative
channels to convey conceptual messages include function calls,
sockets, GPIO interfaces, local busses, or hypervisor calls.  This
type of conveyance is typically found in Composite Devices.  Most
importantly, these conveyance methods are out-of-scope of RATS, but
they are presumed to exist in order to convey conceptual messages
appropriately between roles.
Paragraph (version B):
For example, an entity that both connects to a wide-area network and
to a system bus is taking on both the Attester and Verifier roles.
As a system bus entity, a Verifier consumes Evidence from other
devices connected to the system bus that implement Attester roles.
As a wide-area network connected entity, it may implement an Attester
role.  The entity, as a system bus Verifier, may choose to fully
isolate its role as a wide-area network Attester.
Paragraph (version B):
In essence, an entity that combines more than one role also creates
and consumes the corresponding conceptual messages as defined in this
document.