<?xml version="1.0" encoding="us-ascii"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.0.30 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3635 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3635.xml">
<!ENTITY RFC2863 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2863.xml">
<!ENTITY RFC7632 SYSTEM
"http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7632.xml">
<!ENTITY I-D.ietf-sacm-requirements SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-sacm-requirements.xml">
]>

<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc comments="yes"?>

<rfc ipr="trust200902" docName="draft-camwinget-sacm-information-model-00" category="std">

  <front>
    <title>SACM Information Model</title>

    <author initials="H." surname="Birkholz" fullname="Henk Birkholz">
      <organization abbrev="Fraunhofer SIT">Fraunhofer SIT</organization>
      <address>
        <postal>
          <street>Rheinstrasse 75</street>
          <city>Darmstadt</city>
          <code>64295</code>
          <country>Germany</country>
        </postal>
        <email>henk.birkholz@sit.fraunhofer.de</email>
      </address>
    </author>
    <author initials="N." surname="Cam-Winget" fullname="Nancy Cam-Winget">
      <organization>Cisco Systems</organization>
      <address>
        <postal>
          <street>3550 Cisco Way</street>
          <city>San Jose</city>
          <region>CA</region>
          <code>95134</code>
          <country>USA</country>
        </postal>
        <email>ncamwing@cisco.com</email>
      </address>
    </author>

    <date year="2016" month="April" day="8"/>

    <area>security</area>
    <workgroup>SACM Working Group</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>***replaces abstract in WG IM*** This document defines the information model for Security Automation and Continuous Monitoring (SACM). This includes the definition of information elements transported between SACM components (data in motion) and how to express their relationships. This information model is maintained as the IANA &ldquo;SACM Information Elements&rdquo; registry.  The information model captures the information needs described in the use cases defined by SACM.</t>

    </abstract>


  </front>

  <middle>


<section anchor="introduction" title="Introduction">

<t>***replaces Introduction in the WG IM*** The purpose of the SACM Information Model (IM) is to ensure
interoperability between SACM data models that are used as transport
encoding and to provide a base set of information elements
that may be exposed or shared between SACM components in a scalable and extensible fashion.  A
complete set of requirements imposed on the IM can be found in
<xref target="I-D.ietf-sacm-requirements"/>. The SACM IM defines information elements that are required to carry out the tasks conducted by SACM components.
The SACM IM itself is intended to be used for data exchange between SACM
components (data in motion). Nevertheless, the information elements defined in
this document can be leveraged to create and align corresponding data
models for data at rest.</t>

<t>The information model expresses, for example, target endpoint (TE) attributes, guidance or evaluation results. The corresponding information elements (IE) are consumed and produced by SACM components as they carry out tasks.</t>

<t>The primary tasks that this information model supports (on data, control and management plane) are:<list
   style="symbols">
   <t>TE Discovery</t>
   <t>TE Characterization</t>
   <t>TE Classification</t>
   <t>Collection</t>
   <t>Evaluation</t>
   <t>Information Sharing</t>
   <t>SACM Component Discovery</t>
   <t>SACM component Authentication</t>
   <t>SACM component Authorization</t>
   <t>SACM component Registration</t>
</list></t>


</section>

<section anchor="requirements-notation" title="Requirements notation">
    
    <t>The key words &ldquo;MUST&rdquo;, &ldquo;MUST NOT&rdquo;, &ldquo;REQUIRED&rdquo;, &ldquo;SHALL&rdquo;, &ldquo;SHALL NOT&rdquo;,
        &ldquo;SHOULD&rdquo;, &ldquo;SHOULD NOT&rdquo;, &ldquo;RECOMMENDED&rdquo;, &ldquo;NOT RECOMMENDED&rdquo;, &ldquo;MAY&rdquo;, and
        &ldquo;OPTIONAL&rdquo; in this document are to be interpreted as described in RFC
        2119, BCP 14 <xref target="RFC2119"/>.</t>
    
</section>

<section anchor="information-elements-ie" title="Information Elements (IE)">

<t>**to be inserted between section 2 and section 3** Every type or group of information, e.g. the information elements,
defined in this document represent subjects transported (data in motion) between 
SACM components and are associated with a unique label in the information model: their name.
This document defines a set of information elements standardized by SACM.</t>

<section anchor="information-elements-context" title="Context of Information Elements">

<t>The IE in this information model represent information related to the following areas (based on the use cases described in <xref target="RFC7632"/>):

  <list style="symbols">
                      <t>Endpoint Management</t>
                      <t>Software Inventory Management</t>
                      <t>Hardware Inventory Management</t>
                      <t>Configuration Management</t>
                      <t>Vulnerability Management</t>
                  </list>
</t>
</section>

<section anchor="information-elements-ext" title="Extensibility of Information Elements">

<t> A SACM 
data model based on this information model MAY include additional information elements that are not defined here.
The labels of additional information elements included in different SACM
data models MUST NOT conflict with the labels of the information elements defined by
this information model, and the names of additional information elements MUST NOT
conflict with each other or across multiple data models.  In order to
avoid naming conflicts, the labels of additional IEs SHOULD be
prefixed to avoid collision across extensions.  The prefix MUST
include an organizational identifier and therefore, for example, MAY
be an IANA enterprise number, a (partial) name space URI or an
organization name abbreviation.</t>

</section>

</section>
<section anchor="structure-of-information-elements" title="Structure of Information Elements">

<t>**replaces beginning text of Information Model Framework and 3.1-3.4, will move syntax 3.1.1 and 3.2.1 to aggregated sub-section, will also privacy sub-section 3.5 and label sub-section 3.6** The IEs defined in this document are differentiated into two basic types of Information Elements:</t>

<t><list style="symbols">
  <t>Attributes: an attribute is the simplest IE structure comprised of a unique attribute name and an attribute value (attributes are listed in <xref target="AIE"/>).</t>
  
  <t>Subjects: a subject is a richer structure that has a unique subject name and one or more attributes or subjects (subjects are listed in <xref target="CIE"/>). In essence, the instance of a subject is defined by the attribute values associated with it.</t>
</list></t>

<t>Metadata is constructed as a subject and is associated with attributes or subjects to provide additional information about them. The IM explicitly defines two specific kinds of metadata: metadata about the data origin and metadata about the data source. Metadata can include relationships that refer to other attributes or subjects by referencing labels included in their corresponding metadata.</t>

<section anchor="atomic-information-elements-aie" title="Atomic Information Elements (AIE)">

<t>**to be salvaged an then removed** Atomic IEs represent the smallest building blocks for SACM content,
including, for example, a SACM endpoint attribute, a policy entry, a
configuration item, an expected states, or a threshold value.  AIE
can be bundled into composite IE.  The set of AIEs defined by the
SACM IM is described in section <xref target="AIE"/>.</t>

<t>In essence, AIEs are attribute value pairs that constitute the
&ldquo;leaves&rdquo; in a SACM semantic structure.  While the SACM IM sometimes
does elaborate on the structure of values (e.g. an IPv6 address is an
octet string with a maximum length of 16 that my be collapsed in
certain conditions), it does not prescribe specific types used in the
data model representation (e.g. an unbounded character string).</t>

<t>Every AIE is registered as an corresponding entry at the IANA registry.
The Integer Index of the IANA SMI number tables can be used by SACM data models.</t>

</section>
<section anchor="composite-information-elements-cie" title="Composite Information Elements (CIE)">

<t>**to be salvaged an then removed** Composite IEs constitute bundles of atomic AIEs and/or composite IEs.
A CIE represents a specific set of related information that share a
semantic relationship, e.g. a SACM statement metadata or state
information about a network interface. The set of CIEs defined by the
SACM IM is described in section <xref target="CIE"/>. In essence, CIEs are a &ldquo;named
container&rdquo; construct that can be used to compose additional CIEs that
go beyond the ones standardized by the SACM information model.</t>

<t>The SACM IM allows for recursive or circular nesting of composite
IEs.  A SACM data Model (DM) MUST include the &ldquo;default-depth&rdquo; base
AIE that is part of the SACM content metadata.</t>

</section>
<section anchor="sacm-statements" title="SACM Statements">

<t>**to be salvaged an then removed** The data exchanged between SACM components is always embedded in a
SACM statement.  SACM Statements contain one or more CIEs and/or
AIEs.  A SACM statement functions as an &ldquo;envelope&rdquo; type that is
associated with metadata about the providing SACM component.  The
SACM statement metadata can be used to resolve conflicting
information, retrace the provenance of information or to locate
archived information in data repositories.</t>

<t>Examples of SACM statement metadata information elements:</t>

<t><list style="symbols">
  <t>SACM Domain Identifier: a globally unique identifier that enables
the differentiation of SACM statements across SACM domains.</t>
  <t>Data Origin: the SACM domain unique identifier associated with a SACM component.</t>
  <t>Statement Identifier: an identifier that enables to uniquely reference this specific statement.</t>
</list></t>

<t>SACM statements are comprised of one or more CIEs; <xref target="example-composition-of-sacm-statements"/> provides examples for constructing SACM statements.</t>

</section>
<section anchor="sacm-content-elements" title="SACM Content Elements">

<t>**to be salvaged an then removed** SACM Content Elements are categorized CIEs.  The content elements can
be composed of one or more AIEs and/or CIEs or it can be another
representation that is embedded in the statement, for example, an
IPFIX Template Record.  Each SACM content element has its own Content
Metadata associated with it (analogously to the way that each SACM
statement has metadata associated to it).  Content element metadata
include information about its type, data source (the result produced
by a collector) or data origin (the result produced by most other
SACM components).</t>

<t>Examples of SACM content element metadata information elements:</t>

<t><list style="symbols">
  <t>Target Endpoint Label: an identifier that enables to distinctly
identify a target endpoint as a SACM content element.</t>
  <t>Relationship Identifier(s): a set of semantic relationships that
associate this SACM content element with other SACM content
elements via their content element identifier.</t>
  <t>Content Element Identifier: an identifier that enables to uniquely
reference this specific content element.</t>
</list></t>

<t>SACM content elements are described in section FIXME.</t>

</section>
<section anchor="relationship-types" title="Relationship Types">

<t>**to be salvaged an then removed** Relationships are expressed via AIE contained within a CIE. There are two ways SACM content elements are associated with each other. &ldquo;A Flow&rdquo; associated with &ldquo;A User&rdquo;, for example, would be a typical case, in which two separate SACM content elements could be associated with each other.</t>

<t>One way is to include the Relationships AIE in the content element metadata that preludes the actual content (in this example, the content element metadata of the flow record). Relationship Types are uni-directional. For example, the &ldquo;is-associated-with-user&rdquo; Relationship AIE included in the content element metadata points to a specific user via a corresponding content element identifier.</t>

<t>The alternative way is to include the reference of associated information directly into the content of the content element. A session CIE, for instance, could refer to a specific user by including identifying attributes about that user. While this is a valid way of creating a relationship between different kinds of content, it requires careful matching or the introduction of another appropriate identifier mechanism (that does not conflict with other SACM statements and SACM content element identifiers).
If a SACM data model allows for transport of other representations as payload of a content element (e.g. a pcap fragment containing suspicious packets, for example), there might be no alternative as to use the content element metadata to include relationships to other content elements.</t>

</section>
<section anchor="events" title="Events">

<t>**to be salvaged an then removed** Events are a specific type of CIE that are always associated with a
time stamp and represent a change of state or configuration that can
be expressed as a SACM content.  The time an event was published by a
SACM component is recorded in its corresponding SACM statement
metadata, the time it was created (or initially observed) is recorded
in its content element metadata.  It is also recorded in the CIE
itself, which is somewhat redundant but can improve performance in
some scenarios.  Event CIE can also include the past state or
configuration before the change occurred, or &ndash; if applicable &ndash; a
threshold or trigger condition that lead to the creation of the
event.</t>

</section>
</section>
<section anchor="information-element-vocabulary" title="Information Element Vocabulary">

<t>**to be inserted in section 5 as candidates** The vocabulary of Information Element names standardized by the SACM IM does not prescribe the use of these exact same names in every SACM data model. If terms diverge, a mapping has to be provided in the corresponding SACM data model document.</t>

<t>A subset of the names of the information elements defined in this document are appended with &ldquo;-type&rdquo;. This indicates that the IM defines a set of values for these information elements (e.g. the interface types defined by the IANA registry or the relationship types).</t>

<section anchor="vocabulary-of-categories" title="Vocabulary of Categories">

<t>Categories are special Information Elements that enable to refer to multiple types of IEs via just one name. Therefore, they are similar to a type-choice. A prominent example of a category is network-address. Network-address is a category that every kind of network address is associated with, e.g. mac-address, ipv4-address, ipv6-address, or typed-network-address. If a CIE includes network-address as one of its components, any of that categories members is valid to be used in its stead.</t>

<t>Another prominent example is EndpointIdentifier. Some IEs can be used to identify (and over time re-recognize) target endpoints - those are associated with the category endpoint-identifier.</t>

<t><list style="hanging">
  <t hangText='content:'>
  this is a very broad category. Content is the payload of a content element in a SACM statement. Formally, metadata is the complement to content and everything that is not part of SACM statement metadata or content element metadata is therefore considered to be content. Every IE can be content (although the same type of IE can be used in the metadata at the same time - and those would not be content as described before). Annotating every IE with this category would be highly redundant and is therefore omitted for brevity.</t>
  <t hangText='network-address: (work-in-progress)'>
  </t><t>ipv4-address</t>
  <t>ipv6-address</t>
  <t>mac-address</t>
</list></t>

<t>endpoint-identifier: (work-in-progress)</t>

<t>software-component: (work-in-progress)</t>

<t>software-label: (work-in-progress)</t>

</section>
<section anchor="AIE" title="Vocabulary of Atomic Information Elements">

<t>**to be inserted in section 5 as candidates** The content of every Atomic Information Element is expressed in a single value. Note that while this section lists AIEs, some of them may also be represented as a CIE (especially if metadata is used).</t>

<t><list style="hanging">
  <t hangText='access-privilege-type:'>
  a set of types that represents access privileges (e.g. read, write, none)</t>
  <t>References: none</t>
  <t hangText='account-name:'>
  a label that uniquely identifies an account that can require some form of (user) authentication to access</t>
  <t>References: none</t>
  <t hangText='administrative-domain:'>
  a label the is supposed to uniquely identify an administrative domain</t>
  <t>References <xref target="IFMAP"/></t>
  <t hangText='address-association-type:'>
  a set of types that defines the type of address associations (e.g. broadcast-domain-member-list, ip-subnet-member-list, ip-mac, shared-backhaul-interface, etc.)</t>
  <t>References: none</t>
  <t hangText='address-mask-value:'>
  a value that expresses a generic address subnetting bitmask</t>
  <t hangText='address-type:'>
  a set of types that specifies the type of address that is expressed in an address CIE (e.g. ethernet, modbus, zigbee)</t>
  <t>References: none</t>
  <t hangText='address-value:'>
  a value that expresses a generic network address</t>
  <t>References: none</t>
  <t>Category: network-address</t>
  <t hangText='application-component:'>
  a label that references a &ldquo;sub&rdquo;-application that is part of the application (e.g. an add-on, a cipher-suite, a library)</t>
  <t>References: <xref target="SWID"/></t>
  <t>Category: software-component</t>
  <t hangText='application-label:'>
  a label that is supposed to uniquely reference an application</t>
  <t>References: <xref target="SWID"/></t>
  <t>Category: software-label</t>
  <t hangText='application-type:'>
  a set of types (FIXME maybe a finite set is not realistic here - value not enumerator?) that identifies the type of (user-space) application (e.g. text-editor, policy-editor, service-client, service-server, calendar, rouge-like RPG)</t>
  <t>References: <xref target="SWID"/></t>
  <t>Category: software-type</t>
  <t hangText='application-manufacturer:'>
  the name of the vendor that created the application</t>
  <t>References: <xref target="SWID"/></t>
  <t>Category: software-manufacturer</t>
  <t hangText='application-name:'>
  a value that represents the name of an application given by the manufacturer</t>
  <t>References: <xref target="SWID"/></t>
  <t hangText='application-version:'>
  a version string that identifies a specific version of an application</t>
  <t>References: <xref target="SWID"/></t>
  <t>Category: software-version</t>
  <t hangText='authenticator:'>
  a label that references a SACM component that can authenticate target endpoints (can be used in a target-endpoint CIE to express that the target endpoint was authenticated by that SACM component)</t>
  <t>References: none</t>
  <t hangText='attribute-name:'>
  a value that can express the attribute name of generic Attribute-Value-Pair CIE</t>
  <t>References: none</t>
  <t hangText='attribute-value:'>
  a value that can express the attribute value of generic Attribute-Value-Pair CIE</t>
  <t>References: none</t>
  <t hangText='authentication-type:'>
  a set of types that expresses which type of authentication was used to enable a network interaction/connection</t>
  <t>References: <xref target="PXGRID"/></t>
  <t hangText='birthdate:'>
  a label for the registered day of birth of a natural person (e.g. the date of birth of a person as an ISO date string http://rs.tdwg.org/ontology/voc/Person#birthdate)</t>
  <t>References: <xref target="SCAP-AI"/></t>
  <t hangText='bytes-received:'>
  a value that represents a number of octets received on a network interface</t>
  <t>Reference : <xref target="PXGRID"/></t>
  <t hangText='bytes-sent:'>
  a value that represents a number of octets sent on a network interface</t>
  <t>Reference : <xref target="PXGRID"/></t>
  <t hangText='certificate:'>
  a value that expresses a certificate that can be collected from a target endpoint</t>
  <t>References: none</t>
  <t>Category: endpoint-identifier</t>
  <t hangText='collection-task-type:'>
  a set of types that defines how collected SACM content was acquired (e.g. network-observation, remote-acquisition, self-reported)</t>
  <t>Reference: none</t>
  <t hangText='confidence:'>
  a representation of the subjective probability that the assessed value is correct.  If no confidence value is given it is assumed that the confidence is 1 (limits confidence values to the range between zero and one)</t>
  <t>References: <xref target="ARF"/></t>
  <t hangText='content-action:'>
  a set of types that expresses a type of action (e.g. add, delete, update). Can be associated, for instance, with an event CIE or with an network observation</t>
  <t>References: <xref target="ARF"/></t>
  <t hangText='content-elements:'>
  a value that represents the number of content-elements included in a SACM statement</t>
  <t>References: none</t>
  <t hangText='content-topic:'>
  a set of types that defines what kind of concept the information is included in a content element (e.g. Session, User, Interface, PostureProfile, Flow, PostureAssessment, TargetEndpoint)</t>
  <t>References: none</t>
  <t hangText='content-type:'>
  a set of types that defines what kind of information is included in a content element (e.g. EndpointConfiguration, EndpointState, DirectoryEntry, Event, Incident)</t>
  <t>References: none</t>
  <t hangText='country-code:'>
  a set of types according to ISO 3166-1 trigraphic codes of countries</t>
  <t>References: FIXME</t>
  <t hangText='data-origin:'>
  a label that uniquely identifies a SACM component in and across SACM domains</t>
  <t>References: none</t>
  <t>Aliases: sacm-component-id</t>
  <t hangText='data-source:'>
  a label that is supposed to uniquely identify the data source (e.g. a target endpoint or sensor) that provided an initial endpoint attribute record</t>
  <t>References: <xref target="ARF"/></t>
  <t>Aliases: te-id (work-in-progress)</t>
  <t hangText='decimal-fraction-denominator:'>
  a denominator value to express a decimal fraction time stamp (e.g. in timestamp)</t>
  <t>References: none</t>
  <t hangText='decimal-fraction-numerator:'>
  a numerator value to express a decimal fraction time stamp (e.g. in timestamp)</t>
  <t hangText='default-depth:'>
  a value that expresses how often a circular reference of CIE is allowed to repeat, or how deep a recursive nesting may occur, respectively.</t>
  <t>References: none</t>
  <t hangText='discoverer:'>
  a label that refers to the SACM component that discovered a target endpoint (can be used in a target-endpoint CIE to express, for example, that the target endpoint was authenticated by that SACM component)</t>
  <t>References: none</t>
  <t hangText='email-address:'>
  a value that expresses an email-address</t>
  <t>References: none</t>
  <t hangText='event-type:'>
  a set of types that define the categories of an event (e.g. access-level-change, change-of-privilege, change-of-authorization, environmental-event, or provisioning-event)</t>
  <t>Reference: none</t>
  <t hangText='event-threshold:'>
  if applicable, a value that can be included in an event CIE to indicate what numeric threshold value was crossed to trigger that event</t>
  <t>Reference: none</t>
  <t hangText='event-threshold-name:'>
  if an event is created due to a crossed threshold, the threshold might have a name associated with it that can be expressed via this value</t>
  <t>References: none</t>
  <t hangText='event-trigger:'>
  this value is used to express more complex trigger conditions that may cause the creation of an event.</t>
  <t hangText='firmware-id:'>
  a label that represents the BIOS or firmware ID of a specific target endpoint</t>
  <t>Reference: none</t>
  <t>Category: endpoint-identifier</t>
  <t hangText='hardware-serial-number:'>
  a value that identifies a piece of hardware that is a component of a composite target endpoint (in essence, every target endpoint is a composite) and can be acquired from a target endpoint by a collection task</t>
  <t>Reference: none</t>
  <t>Category: endpoint-identifier</t>
  <t hangText='host-name:'>
  a label typically associated with an endpoint but not always intended to be unique in a given scope</t>
  <t>References <xref target="ARF"/>, <xref target="SCAP-AI"/></t>
  <t>Category: endpoint-identifier</t>
  <t hangText='interface-label:'>
  a unique label a network interface can be referenced with</t>
  <t>Reference: none</t>
  <t hangText='ipv6-address-subnet-mask-cidrnot:'>
  an IPv6 subnet bit mask in CIDR notation</t>
  <t>References: TBD</t>
  <t hangText='ipv6-address-value:'>
  an IPv4 address value</t>
  <t>References: TBD</t>
  <t>Category: endpoint-identifier, network-address</t>
  <t hangText='ipv4-address-subnet-mask-cidrnot:'>
  an IPv4 subnet bit mask in CIDR notation</t>
  <t>References: TBD</t>
  <t hangText='ipv4-address-subnet-mask:'>
  an IPv4 subnet mask</t>
  <t>References: TBD</t>
  <t hangText='ipv4-address-value:'>
  an IPv4 address value</t>
  <t>References: TBD</t>
  <t>Category: endpoint-identifier, network-address</t>
  <t hangText='layer2-interface-type:'>
  a set of types referenced by IANA ifType</t>
  <t>References: <xref target="RFC3635"/>, <xref target="RFC2863"/></t>
  <t hangText='layer4-port-address:'>
  a layer 4 port address (typically used, for example, with TCP and UDP)</t>
  <t>References: none</t>
  <t>Category: network-address</t>
  <t hangText='layer4-protocol:'>
  a set of types that express a layer 4 protocol (e.g. UDP or TCP)</t>
  <t hangText='location-name:'>
  a value that represents a named region of space FIXME</t>
  <t>References: <xref target="IFMAP"/>, <xref target="ARF"/>, <xref target="SCAP-AI"/></t>
  <t hangText='mac-address:'>
  a value that expresses an Ethernet address</t>
  <t>References: <xref target="IFMAP"/>, <xref target="ARF"/>, <xref target="SCAP-AI"/></t>
  <t>Category: endpoint-identifier, network-address</t>
  <t hangText='method-label:'>
  a label that references a specific method registered and used in a SACM domain (e.g. method to match and re-identify target endpoints via identifying attributes)</t>
  <t>References: none</t>
  <t hangText='method-repository:'>
  a label that references a SACM component methods can be registered at and that can provide guidance in the form of registered methods to other SACM components</t>
  <t>References: none</t>
  <t hangText='network-access-level-type:'>
  a set of types that expresses categories of network  access-levels (e.g. block, quarantine, etc.)</t>
  <t>References: <xref target="IFMAP"/></t>
  <t hangText='network-id:'>
  most networks, such as AS, an OSBF domains, or vlans, can have an ID that is represented via this AIE</t>
  <t>References: none</t>
  <t hangText='network-interface-name:'>
  a label that uniquely identifies an interface associated with a distinguishable endpoint</t>
  <t>References: FIXME</t>
  <t hangText='network-layer:'>
  a set of layers that express the specific network layer an interface operate on (typically layer 2-4)</t>
  <t>References: FIXME</t>
  <t hangText='network-name:'>
  a label that is associated with a network. Some networks, for example effective layer2-broadcast-domains, are difficult to &ldquo;grasp&rdquo; and therefore quite complicated to name</t>
  <t>References: none</t>
  <t hangText='organization-id:'>
  a label that is supposed to uniquely identify an organization</t>
  <t>References: <xref target="ARF"/></t>
  <t hangText='organization-name:'>
  a value that represents the name of an organization</t>
  <t>References: <xref target="ARF"/></t>
  <t hangText='os-component:'>
  a label that references a &ldquo;sub-component&rdquo; that is part of the operating system (e.g. a kernel module, microcode, or ACPI table)</t>
  <t>References: <xref target="SWID"/></t>
  <t>Category: software-component</t>
  <t hangText='os-label:'>
  a label that references a specific version of an operating system, including patches and hotfixes</t>
  <t>References: <xref target="SWID"/></t>
  <t>Category: software-label</t>
  <t hangText='os-manufacturer:'>
  the name of the manufacturer of an operating system</t>
  <t>References: <xref target="IFMAP"/></t>
  <t>Category: software-manufacturer</t>
  <t hangText='os-name:'>
  the name of an operating system</t>
  <t>References: <xref target="IFMAP"/></t>
  <t>Category: software-name</t>
  <t hangText='os-type:'>
  a set of types that identifies the type of an operating system (e.g. real-time, security-enhanced, consumer, server)</t>
  <t>References: none</t>
  <t>Category: software-type</t>
  <t hangText='os-version:'>
  a value that represents the version of an operating-system</t>
  <t>Category: software-version</t>
  <t hangText='patch-id:'>
  a label the uniquely identifies a specific software patch</t>
  <t>References: <xref target="ARF"/></t>
  <t hangText='patch-name:'>
  the vendor&rsquo;s name of a software patch</t>
  <t>References: <xref target="ARF"/>, <xref target="SWID"/></t>
  <t hangText='person-first-name:'>
  the first name of a natural person</t>
  <t>References: <xref target="ARF"/>, <xref target="SCAP-AI"/></t>
  <t hangText='person-last-name:'>
  the last name of a natural person</t>
  <t>References: <xref target="ARF"/>, <xref target="SCAP-AI"/></t>
  <t hangText='person-middle-name:'>
  the first name of a natural person</t>
  <t>References: <xref target="ARF"/>, <xref target="SCAP-AI"/></t>
  <t hangText='phone-number:'>
  a label that expresses the u.s. national phone number (e.g. pattern value=&rdquo;((\d{3}) )?\d{3}-\d{4}&rdquo;)</t>
  <t>References: <xref target="ARF"/>, <xref target="SCAP-AI"/></t>
  <t hangText='phone-number-type:'>
  a set of types that express the type of a phone number (e.g. DSN, Fax, Home, Mobile, Pager, Secure, Unsecure, Work, Other)</t>
  <t>References: <xref target="ARF"/></t>
  <t hangText='privilege-name:'>
  the attribute-name of the privilege represented as an AVP</t>
  <t>References: none</t>
  <t hangText='privilege-value:'>
  the value-content of the privilege represented as an AVP</t>
  <t>References: none</t>
  <t hangText='protocol:'>
  a set of types that defines specific protocols above layer 4 (e.g. http, https, dns, ipp, or unknown)</t>
  <t>References: none</t>
  <t hangText='public-key:'>
  the value of a public key (regardless of its method of creation, crypto-system, or signature scheme) that can be collected from a target endpoint</t>
  <t>Reference: none</t>
  <t>Category: endpoint-identifier</t>
  <t hangText='relationship-content-element-guid:'>
  a reference to a specific content element used in a relationship CIE</t>
  <t>References: none</t>
  <t hangText='relationship-statement-guid:'>
  a reference to a specific SACM statement used in a relationship CIE</t>
  <t>References: none</t>
  <t hangText='relationship-object-label:'>
  a reference to a specific label used in content (e.g. a te-label or a user-id). This reference is typically used if matching content AIE can be done efficiently and can also be included in addition to a relationship-content-element-guid reference.</t>
  <t>References: none</t>
  <t hangText='relationship-type:'>
  a set of types that is in every instance of a relationship CIE to highlight what kind of relationship exists between the CIE the relationship is included in (e.g. associated_with_user, applies_to_session, seen_on_interface, associated_with_flow, contains_virtual_device)</t>
  <t>References: none</t>
  <t hangText='role-name:'>
  a label that references a collection of privileges assigned to a specific entity (identity? FIXME)</t>
  <t>References: FIXME</t>
  <t hangText='session-state-type:'>
  a set of types a discernible session (an ongoing network interaction) can be in (e.g. Authenticating, Authenticated, Postured, Started, Disconnected)</t>
  <t>References: <xref target="PXGRID"/></t>
  <t hangText='statement-guid:'>
  a label that expresses a global unique ID referencing a specific SACM statement that was produced by a SACM component</t>
  <t>References: none</t>
  <t hangText='statement-type:'>
  a set of types that define the type of content that is included in a SACM statement (e.g. Observation, DirectoryContent, Correlation, Assessment, Guidance)</t>
  <t>References: none</t>
  <t hangText='status:'>
  a set of types that defines possible result values for a finding in general (e.g. true, false, error, unknown, not applicable, not evaluated)</t>
  <t>References: <xref target="ARF"/></t>
  <t hangText='sub-administrative-domain:'>
  a label for related child domains an administrative domain can be composed of (used in the CIE administrative-domain)</t>
  <t>References: none</t>
  <t hangText='sub-interface-label:'>
  a unique label a sub network interface (e.g. a tagged vlan on a trunk) can be referenced with</t>
  <t>References: none</t>
  <t hangText='super-administrative-domain:'>
  a label for related parent domains an administrative domain is part of (used in the CIE administrative-domain)</t>
  <t>References: none</t>
  <t hangText='super-interface-label:'>
  a unique label a super network interface (e.g. a physical interface a tunnel interface terminates on) can be referenced with</t>
  <t>References: none</t>
  <t hangText='te-assessment-state:'>
  a set of types that defines the state of assessment of a target-endpoint (e.g. in-discovery, discovered, in-classification, classified, in-assessment, assessed)</t>
  <t>References: <xref target="ARF"/></t>
  <t hangText='te-label:'>
  an identifying label created from a set of identifying attributes used to reference a specific target endpoint</t>
  <t>References: none</t>
  <t hangText='te-id:'>
  an identifying label that is created randomly, is supposed to be unique, and used to reference a specific target endpoint</t>
  <t>References: <xref target="ARF"/>, <xref target="SWID"/></t>
  <t>Aliases: data-source</t>
  <t hangText='timestamp:'>
  a timestamp the expresses a specific point in time</t>
  <t>References: <xref target="IFMAP"/>, <xref target="ARF"/></t>
  <t hangText='timestamp-type:'>
  a set of types that express what type of action or event happened at that point of time (e.g. discovered, classified, collected, published). Can be included in a generic timestamp CIE</t>
  <t>References: none</t>
  <t hangText='units-received:'>
  a value that represents a number of units (e.g. frames, packets, cells or segments) received on a network interface</t>
  <t>Reference : <xref target="PXGRID"/></t>
  <t hangText='units-sent:'>
  a value that represents a number of units (e.g. frames, packets, cells or segments) sent on a network interface</t>
  <t>Reference : <xref target="PXGRID"/></t>
  <t hangText='username:'>
  a part of the credentials required to access an account that can be collected from a target endpoint</t>
  <t>References: none</t>
  <t>Category: endpoint-identifier</t>
  <t hangText='user-directory:'>
  a label that identifies a specific type of user-directory (e.g. ldap, active-directory, local-user)</t>
  <t>Reference: <xref target="PXGRID"/></t>
  <t hangText='user-id:'>
  a label that references a specific user known in a SACM domain</t>
  <t>References: <xref target="PXGRID"/></t>
  <t hangText='web-site:'>
  a URI that references a web-site</t>
  <t>References: <xref target="ARF"/></t>
  <t hangText='WGS84-longitude:'>
  a label that represents WGS 84 rev 2004 longitude</t>
  <t>References: <xref target="SCAP-AI"/></t>
  <t hangText='WGS84-latitude:'>
  a label that represents WGS 84 rev 2004 latitude</t>
  <t>References: <xref target="SCAP-AI"/></t>
  <t hangText='WGS84-altitude:'>
  a label that represents WGS 84 rev 2004 altitude</t>
  <t>References: <xref target="SCAP-AI"/></t>
</list></t>

</section>
<section anchor="CIE" title="Vocabulary of Composite Information Elements">

<t>**to be inserted in section 5 as candidates** The content of every Composite Information Element is expressed by the mandatory and optional IE it can be composed of. The components of an CIE can have a cardinality associated with them:</t>

<t><list style="symbols">
  <t>(*): zero to unbounded occurrences</t>
  <t>(+): one to unbounded occurrences</t>
  <t>(?): zero or one occurrence</t>
  <t>(n*m): between n and m occurrences</t>
  <t>no cardinality: one occurrence</t>
</list></t>

<t>If there is no cardinality highlighted or the cardinality (+) or (n*m) is used, including this IE in the CIE is mandatory. In contrast, optional IE are expressed via the cardinality (?) or (*).
An CIE can prescribe a strict sequence to the component IE it contains. This in indicated by an (s).
</t>

<t><list style="hanging">
  <t hangText='address-association (s):'>
  some addresses are associated with each other, e.g. a mac-address can be associated with a number of IP addresses or a sensor address can be associated with the external address of its two redundant IP gateways. The first address is the address a number of addresses with the same type is associated with. An address type SHOULD be included and the addresses associated with the first address entry MUST be of the same type. NANCY FIXME</t>
  <t>address</t>
  <t>address-type (?)</t>
  <t>address (+)</t>
  <t>address-type (?)</t>
  <t hangText='administrative-domain:'>
  this CIE is intended to express more complex setups of interconnected administrative domains</t>
  <t>administrative-domain</t>
  <t>sub-administrative-domain (*)</t>
  <t>super-administrative-domain (?)</t>
  <t>location (?)</t>
  <t hangText='application:'>
  an application is software that is not part of the kernel space (therefore typically runs in the user space. An application can depend on specific running party of an operating system.</t>
  <t>application-label (?)</t>
  <t>application-name</t>
  <t>application-type (*)</t>
  <t>application-component (*)</t>
  <t>application-manufacturer (?)</t>
  <t>application-version (?)</t>
  <t hangText='application-instance:'>
  a specific instance of an application that is installed on an endpoint. The application-label is used to refer to corresponding information stored in an application CIE</t>
  <t>application-label</t>
  <t>target-endpoint</t>
  <t hangText='attribute-value-pair:'>
  a generic CIE that is used to express various AVP (e.g. Radius Attributes)</t>
  <t>attribute-name</t>
  <t>attribute-value</t>
  <t hangText='content-creation-timestamp:'>
  a decimal fraction timestamp that specifies the point in time the content element was created by a SACM component</t>
  <t>decimal-fraction-denominator</t>
  <t>decimal-fraction-numerator</t>
  <t hangText='content-element:'>
  content produced by a SACM component is encapsulated in content-elements that also include content-metadata regarding that content</t>
  <t>content-metadata (+)</t>
  <t>content (+)</t>
  <t hangText='content-metadata:'>
  metadata regarding the content included in a specific content-element. The content the metadata annotates can be initially collected content - in this case a data-source has to be included in the metadata. Content can also be the product of a SACM component (e.g. an evaluator), which requires a data-origin IE instead that references the producer of information.</t>
  <t>content-element-guid</t>
  <t>content-creation-timestamp</t>
  <t>content-topic</t>
  <t>content-type</t>
  <t>data-source (?)</t>
  <t>data-origin (?)</t>
  <t>relationship (*)</t>
  <t hangText='data-source:'>
  a CIE that refers to a target endpoint that is the source of SACM content - either via a label (data-source, which could also be used without this CIE), or via a list of endpoint-identifiers (category). Both can be included at the same time but MUST NOT conflict.</t>
  <t>data-source (?)</t>
  <t>endpoint-identifier (*)</t>
  <t hangText='dst-flow-element:'>
  identifies the destination of a flow. The port number SHOULD be included if the network-address is an IP-address.</t>
  <t>network-address</t>
  <t>layer4-port-address (?)</t>
  <t hangText='ethernet-interface:'>
  the only two mandatory component of this CIE is the mac-address and the generated label (to distinguish non-unique addresses). This acknowledges the fact that in many cases this is the only information available about an Ethernet interface. If there is more detail information available it MUST be included to avoid ambiguity and to increase the usefulness for consumer of information. The exception are sub-interface-labels and super-interface-labels, which SHOULD be included.</t>
  <t>interface-label</t>
  <t>network-interface-name (?)</t>
  <t>mac-address</t>
  <t>network-name (?)</t>
  <t>network-id (?)</t>
  <t>layer2-interface-type (?)</t>
  <t>sub-interface-label (*)</t>
  <t>super-interface-label (*)</t>
  <t hangText='event (s):'>
  this a special purpose CIE that represents the change of content. As with content-elements basically every content can be included in the two content entries. The mandatory content entry represents the &ldquo;after&rdquo; state of the content and the optional content entry can represent the &ldquo;before&rdquo; state if available or required.</t>
  <t>event-type (?)</t>
  <t>event-threshold (?)</t>
  <t>event-threshold-name (?)</t>
  <t>event-trigger (?)</t>
  <t>typed-timestamp</t>
  <t>content</t>
  <t>content (?)</t>
  <t hangText='flow-record:'>
  a composite that expresses a single flow and its statistics. If applicable, protocol and layer4-protocol SHOULD be included</t>
  <t>src-flow-element</t>
  <t>dst-flow-element</t>
  <t>protocol (?)</t>
  <t>layer4-protocol (?)</t>
  <t>flow-statistics</t>
  <t hangText='flow-statistics:'>
  this CIE aggregates bytes and units send and received</t>
  <t>bytes-received</t>
  <t>bytes-sent</t>
  <t>units-received</t>
  <t>units-sent</t>
  <t hangText='group:'>
  insert text here (work in progress)</t>
  <t hangText='ipv4-address:'>
  an IPv4 address is always associated with a subnet. This CIE combines these both tightly nit values. Either a subnet mask or a CIDR notation bitmask SHOULD be included.</t>
  <t>ipv4-address-value</t>
  <t>ipv4-address-subnet-mask-cidrnot (?)</t>
  <t>ipv4-address-subnet-mask (?)</t>
  <t hangText='ipv6-address:'>
  an IPv6 address is always associated with a subnet. This CIE combines these both tightly nit values. A CIDR notation bitmask SHOULD be included.</t>
  <t>ipv6-address-value</t>
  <t>ipv6-address-subnet-mask-cidrnot (?)</t>
  <t hangText='location:'>
  a CIE that aggregates potential details about a location</t>
  <t>location-name</t>
  <t>WGS84-longitude</t>
  <t>WGS84-latitude</t>
  <t>WGS84-altitude</t>
  <t hangText='operation-system:'>
  an operation-system is software that is directly interacting with the hardware, provides the runtime environment for the user-space and corresponding interfaces to hardware functions.</t>
  <t>os-label (?)</t>
  <t>os-name</t>
  <t>os-type (*)</t>
  <t>os-component (*)</t>
  <t>os-manufacturer (?)</t>
  <t>os-version (?)</t>
  <t hangText='organization:'>
  this CIE aggregates information about an organization and can be references via its id</t>
  <t>organization-id</t>
  <t>organization-name</t>
  <t>location (?)</t>
  <t hangText='person:'>
  a CIE that aggregates the details about a person and combines it with a identifier unique to SACM domains</t>
  <t>person-first-name</t>
  <t>person-last-name</t>
  <t>person-middle-name (*)</t>
  <t>phone-contact (*)</t>
  <t>email-address (*)</t>
  <t hangText='phone-contact:'>
  this CIE can be used to reference a phone number and how it functions as a contact</t>
  <t>phone-number</t>
  <t>phone-number-type (?)</t>
  <t hangText='privilege:'>
  a CIE to express privileges via a specific name/value pair</t>
  <t>privilege-name</t>
  <t>privilege-value</t>
  <t hangText='relationship:'>
  the relationship CIE enables to associate the CIE it is included in with other CIE if they contain a unique identifier or label - providing an alternative to including attributes of other content CIE as a means to map them (which remains a valid alternative, though). The relationship CIE MUST at least reference one relationship object (either a SACM statement iden</t>
  <t>relationship-type</t>
  <t>relationship-content-element-guid (*)</t>
  <t>relationship-statement-guid (*)</t>
  <t>relationship-object-label (*)</t>
  <t hangText='sacm-statement:'>
  every SACM components produces information in this format. This CIE can be considered the root IE for every SACM message generated. There MUST be at least one content element included in a SACM statement and if there are more than one, they are ordered in a sequence.</t>
  <t>statement-metadata</t>
  <t>content-element (+)(s)</t>
  <t hangText='session:'>
  represents an ongoing network interaction that can be in various states of authentication or assessement</t>
  <t>session-state-type</t>
  <t>(work-in-progress)</t>
  <t hangText='src-flow-element:'>
  identifies the source of a flow. The port number SHOULD be included if the network-address is an IP-address.</t>
  <t>network-address</t>
  <t>layer4-port-address (?)</t>
  <t hangText='statement-creation-timestamp:'>
  a decimal fraction timestamp that specifies the point in time the SACM statement was created by a SACM component</t>
  <t>decimal-fraction-denominator</t>
  <t>decimal-fraction-numerator</t>
  <t hangText='statement-publish-timestamp:'>
  a decimal fraction timestamp that specifies the point in time the SACM component attempted to publish the SACM statement (if successful, this will result in the publish-timestamp send with the SACM statement).</t>
  <t>decimal-fraction-denominator</t>
  <t>decimal-fraction-numerator</t>
  <t hangText='statement-metadata:'>
  every SACM statement includes statement metadata about the SACM component it was produced by and a general category that indicates what this statement is about</t>
  <t>statement-guid</t>
  <t>data-origin</t>
  <t>statement-creation-timestamp (?)</t>
  <t>statement-publish-timestamp</t>
  <t>statement-type</t>
  <t>content-elements</t>
  <t hangText='target-endpoint:'>
  this is a central CIE used in the process chains a SACM domain can compose. Theoretically every kind of information can be associated with a target endpoint CIE via its corresponding content element. A few select IE can be stored in the CIE itself to reduce the overhead of following references that would occur in most scenarios. If the hostname is unknown the value has to be set as an equivalent to &ldquo;not available&rdquo; (e.g. NULL). Comment from the authors: This is &ldquo;work in progress&rdquo; an a good basis for discussion</t>
  <t>host-name</t>
  <t>te-label</t>
  <t>administrative-domain (?)</t>
  <t>application-instance (*)</t>
  <t>ethernet-interface (*)</t>
  <t>address-association (*)</t>
  <t>data-source (?)</t>
  <t>operation-system (?)</t>
  <t hangText='te-profile:'>
  a set of expected states, policies and pieces of guidance that can be matched to a target endpoint (or a class of target endpoints &ldquo;work in progress&rdquo;)</t>
  <t hangText='typed-timestamp:'>
  a flexible timestamp CIE that can express the specific type of timestamp via its content. This is an alternative to the &ldquo;named&rdquo; timestamps that do not include a timestamp-type</t>
  <t>decimal-fraction-denominator</t>
  <t>decimal-fraction-numerator</t>
  <t>timestamp-type</t>
  <t hangText='user:'>
  a CIE that references details of a specific user known in a SACM domain active on a specific target endpoint</t>
  <t>user-id</t>
  <t>username (?)</t>
  <t>data-source (?)</t>
  <t>user-directory (?)</t>
</list></t>

</section>
</section>
<section anchor="example-composition-of-sacm-statements" title="Example composition of SACM statements">

<t>This section illustrates how SACM statements can be composed of content information elements, how relationship CIEs can be used in content metadata, and how the categories statement-type, content-topic and content-type are intended to be used.</t>

<t>The SACM statements instances are written in pseudo code. AIE end with a colon. Some AIE include exemplary values to, for example, present how references to guid and labels can be used. For the sake of brevity, not all mandatory IE that are part of a CIE are always included (e.g. as it is the case with target-endpoint).</t>

<t>The example shows three SACM statements that were produced by three different SACM components that overall include four related content elements.</t>

<t>This is (work in progress).</t>

<figure><artwork><![CDATA[
sacm statement
  statement-metadata
    statement-guid: example-sguid-one
    data-origin: SACM-component-label-one
    statement-publish-timestamp: exmample-TS-one
    statement-type: Observation
  content-element
    content-metadata
      content-element-guid: example-cguid-one
      content-creation-timestamp:
      content-topic: Flow
      content-type: EndpointState
      relationship
        relationship-type: is-associated-with-user
        relationship-content-object: example-cguid-three
      relationship
        relationship-type: is-associated-with-te
        relationship-content-object: example-cguid-two
      relationship
        relationship-type: is-associated-with-te
        relationship-content-object: example-te-label      
    flow-record
      src-flow-element
        network-address (ipv4-address)
          ipv4-address-value:
          ipv4-address-subnet-mask-cidrnot:
        layer4-port-address: 23111
      dst-flow-element
        network-address (IPv4-address)
          ipv4-address-value:
          ipv4-address-subnet-mask-cidrnot:
        layer4-port-address: 22
      protocol: ssh
      layer4-protocol: tcp
      flow-statistics
        bytes-received:
        bytes-sent:
        units-received:
        units-sent:
  content-element
    content-metadata
      content-element-guid: example-cguid-two
      content-creation-timestamp:
      content-topic: TargetEndpoint
      content-type: EndpointConfiguration
    target-endpoint
      te-label: example-te-label
      host-name: example-host-name
      ethernet-interface: example-interface

sacm statement
  statement-metadata
    statement-guid: example-sguid-two
    data-origin: SACM-component-label-two
    statement-publish-timestamp: exmample-TS-two
    statement-type: DirectoryContent
  content-element
    content-metadata
      content-element-guid: example-cguid-three
      content-creation-timestamp:
      content-topic: User
      content-type: DirectoryEntry
    user
      user-name: example-username
      user-directory: component-id

sacm statement
  statement-metadata
    statement-guid: example-sguid-three
    data-origin: SACM-component-label-three
    statement-publish-timestamp: exmample-TS-three
    statement-type: Observation
  content-element
    content-metadata
      content-element-guid: example-cguid-four
      content-creation-timestamp:
      content-topic: Privileges
      content-type: Event
      relationship
        relationship-type: is-associated-with-user
        relationship-content-object: example-cguid-three 
    event
      event-type: change-of-privilege
      typed-timestamp
        decimal-fraction-denominator:
        decimal-fraction-numerator:
        timestamp-type: time-of-observation
      privilege
        privilege-name: super-user-escalation
        privilege-value: true
      privilege
        privilege-name: super-user-escalation
        privilege-value: false

]]></artwork></figure>

</section>
<section anchor="iana-considerations" title="IANA considerations">

<t>This document includes requests to IANA.</t>

</section>
<section anchor="security-considerations" title="Security Considerations">

</section>
<section anchor="acknowledgements" title="Acknowledgements">

</section>
<section anchor="change-log" title="Change Log">

<t>First revision -00</t>
<t>Second revision -00.  Rename to Camwinget (removed -) to make submissions happier. Demonstrate how to integrate with WG draft.</t>

</section>
<section anchor="contributors" title="Contributors">

</section>


  </middle>

  <back>

    <references title='Normative References'>
&RFC2119;
&RFC3635;
&RFC2863;
<reference anchor="SWID" >
    <front>
        <title>Information technology - Software asset management - Part 2: Software identification tag'</title>
        <author >
            <organization></organization>
        </author>
        <date year="2015" month="October" day="01"/>
    </front>
    <seriesInfo name="ISO/IEC" value="19770-2:2015"/>
</reference>
<reference anchor="IFMAP" >
    <front>
        <title>TCG Trusted Network Communications - TNC IF-MAP Metadata for Network Security Specification Version 1.1r9</title>
        <author >
            <organization></organization>
        </author>
        <date year="2012" month="May" day="07"/>
    </front>
</reference>
<reference anchor="ARF" >
    <front>
        <title>Assessment Results Format</title>
        <author initials="T.M." surname="Corporation." fullname="The MITRE Corporation.">
            <organization></organization>
        </author>
        <date year="2010"/>
    </front>
</reference>
<reference anchor="SCAP-AI" >
    <front>
        <title>Specification for Asset Identification 1.1</title>
        <author initials="J." surname="Wunder" fullname="John Wunder">
            <organization></organization>
        </author>
        <author initials="A." surname="Halbardier" fullname="Adam Halbardier">
            <organization></organization>
        </author>
        <author initials="D." surname="Waltermire" fullname="David Waltermire">
            <organization></organization>
        </author>
        <date year="2011"/>
    </front>
    <seriesInfo name="NIST Interagency Report 7693" value=""/>
</reference>
<reference anchor="PXGRID" >
    <front>
        <title>An Actionable Threat Intelligence system using a Publish-Subscribe communications model</title>
        <author initials="S." surname="Appala" fullname="Syam Appala">
            <organization></organization>
        </author>
        <author initials="N." surname="Cam-Winget" fullname="Nancy Cam-Winget">
            <organization></organization>
        </author>
        <author initials="D." surname="McGrew" fullname="David McGrew">
            <organization></organization>
        </author>
        <author initials="J." surname="Verma" fullname="Jyoti Verma">
            <organization></organization>
        </author>
        <date />
    </front>
    <seriesInfo name="ACM" value="Proceedings of the 2nd ACM Workshop on Information Sharing and Collaborative Security"/>
    <seriesInfo name="page" value="61-70"/>
    <seriesInfo name="DOI" value="10.1145/2808128.2808131"/>
    <seriesInfo name="ISBN" value="978-1-4503-3822-6"/>
</reference>


    </references>

<references title='Informative References'>
    
    &I-D.ietf-sacm-requirements; &RFC7632;
    
</references>


  </back>
</rfc>

