Draft: draft-ietf-sacm-requirements

Commentary: Revision 12 addresses issues through Jan 18 . 
 Version  In reading the list in section 2 , there is a problem with how the list is presented . When I read item 1 , I expect this to be presented as " 1 . Define an asset : " So that there is a short term followed by an expansion of what that short term means . As you go down the list , each of the steps gets longer and longer in the first sentence . Using a short pithy short description followed by a longer description with details is I think a much clearer . The short description corresponds to the " task " - i.e. a task name . 
 Hi  , Hopefully the updates in version -05 should reflect better consistancy as the tasks have been shortened now ( followed by longer explanations ) . If it is not satisfactory , please feel free to keep this issue opened . Thanks ,  
 Version -05 Keeping open on a purely editorial issue . You need to be consistent on the use of period vs colon at the end of the pity paragraph title . Otherwise this issue is addressed . 
 fixed in -07
Today's environment of rapidly-evolving security threats highlights
the need to automate the sharing of such information while protecting
user information as well as the systems that store, process, and
transmit this information.  Security threats can be detected in a
number of ways.  SACM's charter focuses on how to collect and share
this information based on use cases that involve posture assessment
of endpoints.
Today's environment of rapidly-evolving security threats highlights
the need to automate the sharing of security information (such as
posture information) while protecting user information as well as the
systems that store, process, and transmit this information.  Security
threats can be detected in a number of ways.  SACM's charter focuses
on how to collect and share this information based on use cases that
involve posture assessment of endpoints.
This document focuses on describing the requirements for facilitating
the exchange of posture assessment information in the enterprise, in
particular, for the use cases as exemplified in I-D.ietf-sacm-use-
cases.  Also, this document uses terminology defined in I-D.ietf-
sacm-terminology.
This document focuses on describing the requirements for facilitating
the exchange of posture assessment information in the enterprise, in
particular, for the use cases as exemplified in RFC7632.  Also, this
document uses terminology defined in I-D.ietf-sacm-terminology.
This document defines requirements based on the SACM use cases
defined in I-D.ietf-sacm-use-cases.  This section describes the
requirements used by SACM to assess and compare candidate data
models, interfaces, and protocols, to suit the SACM architecture.
These requirements express characteristics or features that a
candidate protocol or data model must be capable of offering to
ensure security and interoperability.
This document defines requirements based on the SACM use cases
defined in RFC7632.  This section describes the requirements used by
SACM to assess and compare candidate data models, interfaces, and
protocols, to suit the SACM architecture.  These requirements express
characteristics or features that a candidate protocol, information
model, or data model must be capable of offering to ensure security
and interoperability.
Asset Classification: Map the assets on the target endpoints to
asset classes.  This enables identification of the attributes
needed to exchange information pertaining to the target endpoint.
Attribute Definition: Define the attributes desired to be
collected from each target endpoint.  This is what we want to know
about a target endpoint.  For instance, organizations will want to
know what software is installed and its many critical security
attributes such as patch level.
Asset Classification: Map the target endpoint and/or the assets on
the target endpoints to asset classes.  This enables
identification of the attributes needed to exchange information
pertaining to the target endpoint.
Attribute Definition: Define the attributes desired to be
collected from each target endpoint.  This is what we want to know
about a target endpoint.  For instance, organizations will want to
know what software is installed and its critical security
attributes such as patch level.
The information model and interfaces MUST support the ability
to add new operations while maintaining backwards
compatibility.  SACM-defined transport protocols MUST have
extensibility to allow them to transport operations that are
defined in the future.
The information model and device interfaces (see G-012) MUST
support the ability to add new operations while maintaining
backwards compatibility.  SACM-defined transport protocols MUST
have extensibility to allow them to transport operations that
are defined in the future.
Agility: The data model, protocols, and transports MUST be
suitably specified to enable implementations to fit into different
deployment models and scenarios, including considerations for
implementations of data models and transports operating in
constrained environments.
Versatility: The data model, protocols, and transports MUST be
suitably specified to enable implementations to fit into different
deployment models and scenarios, including considerations for
implementations of data models and transports operating in
constrained environments.
Information Extensibility: Non-standard (implementation-specific)
attributes MUST be supported.  A method SHOULD be defined for
preventing collisions from occurring in the naming of all
attributes independent of their source.  For interoperability and
scope boundary, the information model MUST define the mandatory
set of attributes.  The set of attributes defined by the
information model MUST be well defined.
Information Extensibility: Non-standard (implementation-specific)
attributes MUST be supported.  A method SHOULD be defined for
preventing collisions from occurring in the naming of all
attributes independent of their source.  For interoperability and
scope boundary, the information model MUST define the mandatory
set of attributes.
Versioning and Backward Compatibility: Announcement and
negotiation of versions, inclusive of existing capabilities (such
as transport protocols, data models, specific attributes within
data models, standard attribute expression sets, etc.)  MUST be
supported.  Negotiation for both versioning and capability is
needed to accommodate future growth and ecosystems with mixed
capabilities.
Versioning and Backward Compatibility: Announcement and
negotiation of versions, inclusive of existing capabilities (such
as transport protocols, data models, specific attributes within
data models, standard attribute expression sets, etc.)  MUST be
supported.  Negotiation for both versioning and capabilities is
needed to accommodate future growth and ecosystems with mixed
capabilities.
Push and Pull Access: Three methods of data access MUST be
supported: the standard Pull model as well as solicited and
unsolicited Push models.  All of the methods of data access MUST
support the ability for the initiator to filter the set of posture
assessment information to be delivered.  Additionally, the
provider of the information MUST be able to filter the set of
posture assessment information based on the permissions of the
recipient.  This requirement is driven by use cases 2.1.3, 2.1.4
and 2.1.5.
Push and Pull Access: Three methods of data access MUST be
supported: a Pull model, a solicited Push model, and an
unsolicited Push models.  All of the methods of data access MUST
support the ability for the initiator to filter the set of posture
assessment information to be delivered.  Additionally, the
provider of the information MUST be able to filter the set of
posture assessment information based on the permissions of the
recipient.  This requirement is driven by use cases 2.1.3, 2.1.4
and 2.1.5.
Device Interface: The interfaces by which SACM components
communicate to share endpoint posture information MUST be well
defined.  That is, the interface defines the data model, SACM
transport protocols, and network transport protocols to enable
SACM components to communicate.
Capability Negotiation: Announcement and negotiation of functional
capabilities (such as authentication protocols, authorization
schemes, data models, transport protocols, etc.) must be
supported, enabling a SACM component to make inquiries about the
capabilities of other components in the SACM ecosystem.
Capability Negotiation: Announcement and negotiation of functional
capabilities (such as authentication protocols, authorization
schemes, data models, transport protocols, etc.)  MUST be
supported, enabling a SACM component to make inquiries about the
capabilities of other components in the SACM ecosystem.
Posture Data Publication: The information model MUST allow for the
data to be provided by a SACM component either solicited or
unsolicited.  No aspect of the information model should be
dependent upon or assume a push (unsolicited) or pull (solicited)
model of publication.
Data Model Negotiation: SACM's information model MUST allow
support for different data models, data model versions, and
different versions of the operations (and network layer
transport).  The SACM information model MUST include the ability
to discover and negotiate the use of a particular data model or
any data model.
Posture Data Publication: The information model MUST allow for the
data to be provided by a SACM component either solicited or
unsolicited.  No aspect of the information model should be
dependent upon or assume a push or pull model of publication.
Data Model Negotiation: SACM's information model MUST allow
support for different data models, data model versions, and
different versions of the operations on the data models and
transport protocols.  The SACM information model MUST include the
ability to discover and negotiate the use of a particular data
model or any data model.
Data Source: The data model MUST allow the provider to include
attributes defining the data source (target endpoint from which
the data was collected) - e.g. hostname, domain (DNS) name or
application name.
Data Source: The data model MUST allow the provider to include
attributes identifying the data source (target endpoint from which
the data was collected) - e.g. hostname, domain (DNS) name or
application name.
Attribute Extensibility: Use Cases in the whole of Section 2
describe the need for an attribute dictionary.  With SACM's scope
focused on posture assessment, the data model attribute collection
and aggregation MUST have a well-understood set of attributes
inclusive of their meaning or usage intent.  The data model MUST
include all attributes defined in the information model and MAY
include additional attributes beyond those found in the
information model.  Additional attributes MUST be defined in
accordance with the extensibility framework provided in the
information model.
Attribute Extensibility: Use Cases in the whole of Section 2
describe the need for an attribute dictionary.  With SACM's scope
focused on posture assessment, the data model attribute collection
and aggregation MUST have a well-understood set of attributes
inclusive of their meaning or usage intent.  The data model MUST
include all attributes defined in the information model and MAY
include additional attributes beyond those found in the
information model.  Additional attributes MUST be defined in
accordance with the extensibility framework provided in the
information model (see IM-001).
Data Model Scalability: The operation resulting from a query
operation MUST be able to handle the return and receipt of large
amounts of data.  Use Cases 2.1.4 and 2.1.5 describes the need for
the data model to support scalability.  For example, the query
operation may result in a very large set of attributes, as well as
a large set of targets.
Operation Scalability: The operation resulting from a query
operation MUST be able to handle the return and receipt of large
amounts of data.  Use Cases 2.1.4 and 2.1.5 describe the need for
the data model to support scalability.  For example, the query
operation may result in a very large set of attributes, as well as
a large set of targets.
Data Abstraction: The data model MUST allow a SACM component to
communicate what data was used to construct the target endpoint's
identity, so other SACM components can determine whether they are
constructing an equivalent target endpoint (and their identity)
and whether they have confidence in that identity.  SACM
components SHOULD have interfaces defined to transmit this data
directly or to refer to where the information can be retrieved.
Data Abstraction: The data model MUST allow a SACM component to
communicate what data was used to construct the target endpoint's
identity, so other SACM components can determine whether they are
constructing an equivalent target endpoint (and its identity) and
whether they have confidence in that identity.  SACM components
SHOULD have interfaces defined to transmit this data directly or
to refer to where the information can be retrieved.
Data Confidentiality: SACM transport protocols MUST be able to
support data confidentiality.  SACM transport protocols MUST
ensure data protection for data in transit (e.g. by encryption) to
provide confidentiality, integrity, and robustness against
protocol-based attacks.  Note that while the transport MUST be
able to support data confidentiality, implementations MAY choose
to make confidentiality optional.  Protection for data at rest is
not in scope for transport protocols.  Data protection MAY be used
for both privacy and non-privacy scenarios.
Data Confidentiality: SACM transport protocols MUST be able to
support data confidentiality.  SACM transport protocols MUST
ensure data protection for data in transit (e.g. by encryption) to
provide confidentiality, integrity, and robustness against
protocol-based attacks.  Note that while the transport MUST be
able to support data confidentiality, implementations MAY provide
a configuration option that enables and disables confidentiality
in deployments.  Protection for data at rest is not in scope for
transport protocols.  Data protection MAY be used for both privacy
and non-privacy scenarios.
SACM's charter focuses on the sharing of posture information for
improving efficacy of security applications such as compliance,
configuration, assurance and other threat and vulnerability reporting
and remediation systems.  While the goal is to facilitate the flow of
information securely, it is important to note that participating
endpoints may not be cooperative or trustworthy.
SACM's charter focuses on the workflow orchestration and the sharing
of posture information for improving efficacy of security
applications such as compliance, configuration, assurance and other
threat and vulnerability reporting and remediation systems.  While
the goal is to facilitate the flow of information securely, it is
important to note that participating endpoints may not be cooperative
or trustworthy.
It is also important to note that endpoint assessment reports,
especially as they may be provided by the target endpoint may pose
untrustworthy information.  The considerations for this is described
in Section 8 of RFC5209.
It is also important to note that endpoint assessment reports,
especially as they may be provided by the target endpoint may pose
untrustworthy information.  The considerations for this are described
in Section 8 of RFC5209.