Draft: draft-ietf-sacm-terminology

Commentary: Brought back Hardware Component and various expositional texts . 
 As presently defined : This definition feels very similar to process or workflow ( the latter is defined in our terminology as " A workflow is a modular composition of tasks that can contain loops , conditionals , multiple starting points and multiple endpoints " ) . I move to strike this term from the terminology unless there is some compelling reason to keep it . 
 The requirements on control plane functions imply certain interaction models ( e.g. component registration , capability authentication , or content authorization ) . The same is true with the way how SACM content is conveyed : Request / Response schemes ( e.g. REST ) , Repository Subscriptions ( e.g. YANG Push ) , Brokered Pub / Sub Topics ( e.g. xmpp - grid ) , or Deployment ( e.g. dynamic Call - Home ) make use of certain interaction models . As the SACM architecture intends not to prescribe certain solutions , it has to elaborate about the required functions on a more abstract level . The term Interaction Model supports the definition of appropriate non - prescriptive sets of functions in the architecture , I think . Maybe this is a flawed assumption ? If so , we can remove the term . 
 In UML , interaction diagrams are a subset of behavior diagrams . Interaction diagrams describe the flow of data and control among the entities being modeled . For example , a sequence diagram shows how different entities communicate with each other using a sequence of messages . Things like BPMN expand the ( limited ) concepts in a UML sequence diagram to include a rich set of control constructs . Hence , I think we need this term . More importantly , we need user stories that use interaction and behavior diagrams to illustrate how SACM ( can ) work . regards ,   If we 're keeping it , do we mind segregating the definition from the exposition ? An interaction model , for example , can be used to define operations , such as registration or discovery , on the control plane . A composition of data models for data in motion and a corresponding interaction model is a protocol . 
 Addressed in branch " no - label - issues " .
Is a system resource, as defined in RFC4949, that may be composed
of other assets.
Examples of Assets include: Endpoints, Software, Guidance, or
X.509 public key certificates.  An asset is not necessarily owned
by an organization.
In the context of SACM, an assertion is the output of a SACM
component in the form of a statement (including metadata about the
data source and data origin, e.g. timestamps).  While the validity of
an assertion cannot be verified without, for example, an additional
attestation protocol, an assertion (and therefore a statement,
respectively) can be accomplished by evidence of the validity of its
metadata provided by a SACM component.
An assessment is a specific workflow that incorporates the SACM
tasks discovery, collection and evaluation.  A prominent instance
of the assessment workflow is illustrated in the Vulnerability
Assessment Scenario I-D.ietf-sacm-vuln-scenario.
The description of the distinctive nature of an endpoint, that is
based on its characteristics.
Sets of expected endpoint attribute states are transported as
declarative guidance in target endpoint profiles via the
management plane.  This, for example, can be a policy, but also a
recorded past state.  An expected state is represented by an
Attribute or a Subject that represents a set of multiple attribute
value pairs.
Examples of such processes/tasks include automated device
management, remediation, collection, evaluation.  Guidance
influences the behavior of a SACM Component and is considered
content of the management plane.  In the context of SACM, guidance
is machine-readable and can be manually or automatically generated
or provided.  Typically, the tasks that provide guidance to SACM
components have a low-frequency and tend to be sporadic.
A distinguishable physical component used to compose an endpoint.
The composition of an endpoint can be changed over time by adding
or removing hardware components.  In essence, every physical
endpoint is potentially a composite of multiple hardware
components, typically resulting in a hierarchical composition of
hardware components.  The composition of hardware components is
based on interconnects provided by specific hardware types (e.g. a
mainboard is a hardware type that provides local busses as an
interconnect or an FRU is a hardware type that is itself connected
via an interconnect to a chassis and can provide further
interconnects for additional hardware components, such as
interfaces modules).  In general, a hardware component can be
distinguished by its serial number.  Occasionally, hardware
components are referred to as power sucking aliens.
The definition of specific sequences regarding the exchange of
messages (data in motion), including, for example, conditional
branching, thresholds and timers.  An interaction model, for
example, can be used to define operations, such as registration or
discovery, on the control plane.  A composition of data models for
data in motion and a corresponding interaction model is a
protocol.
Internal Collector: a collector that runs on a target endpoint to
acquire information from that target endpoint.
The definition of specific sequences regarding the exchange of
messages (data in motion), including, for example, conditional
branching, thresholds and timers.
An interaction model, for example, can be used to define
operations, such as registration or discovery, on the control
plane.  A composition of data models for data in motion and a
corresponding interaction model is a protocol.
A collector that runs on a target endpoint to acquire information
from that target endpoint.
The task of brokering appropriate SACM components according to
their capabilities or roles on request.
The task of discovering the capabilities provided by SACM
components within a SACM domain.
This is likely to be performed via an appropriate set of control
plane functions.
Is SACM component output that represents an assertion.
Is an assertion that is made by a SACM Component.
The description of the distinctive nature of a target endpoint,
that is based on its characteristics.
A specific endpoint label that refers to a target endpoint
identifier used to identify a specific target endpoint (also
referred to as TE label).  In content-metadata, this label is
called data source.
An endpoint label that identifies a specific target endpoint.
A target endpoint can be composed entirely of logical system
entities (see RFC4949.
The most common example is a virtual machine/host running on a
target endpoint.
Effectively, target endpoints can be nested and at the time of
this writing the most common example of target endpoint
characteristics about virtual components is the EntLogicalEntry in
RFC6933.
An endpoint composed entirely of logical system components (see
RFC4949).
The most common example is a virtual machine/host running on a
target endpoint.  Effectively, target endpoints can be nested and
at the time of this writing the most common example of target
endpoint characteristics about virtual components is the
EntLogicalEntry in RFC6933.