<?xml version="1.0" encoding="us-ascii"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"[
<!ENTITY RFC6256 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6256.xml">
<!ENTITY RFC4838 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4838.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC5050 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5050.xml">
<!ENTITY RFC6257 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6257.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
    please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
    (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdep"4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
    (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="no" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="exp" ipr="trust200902" docName="draft-irtf-dtnrg-dtnmp-01" obsoletes="" updates="" submissionType="IETF" xml:lang="en">
  <!-- category values: std, bcp, info, exp, and historic
    ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902,
       or pre5378Trust200902
    you can add the attributes updates="NNNN" and obsoletes="NNNN"
    they will automatically be output with "(if approved)" -->
  <!-- ***** FRONT MATTER ***** -->
  <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the
        full title is longer than 39 characters -->
    <title abbrev="DTNMP">Delay Tolerant Network Management Protocol</title>
    <author fullname="Edward J. Birrane" initials="E.B." surname="Birrane">
      <organization>Johns Hopkins Applied Physics
      Laboratory</organization>
      <address>
        <email>Edward.Birrane@jhuapl.edu</email>
      </address>
    </author>
    <author fullname="Vignesh Ramachandran" initials="V.R." surname="Ramachandran">
      <organization>Johns Hopkins Applied Physics
      Laboratory</organization>
      <address>
        <email>Vinny.Ramachandran@jhuapl.edu</email>
      </address>
    </author>
    <date year="2014" />
    <!-- If the month and year are both specified and are the current ones, xml2rfc will fill
        in the current day for you. If only the current year is specified, xml2rfc will fill
   in the current day and month for you. If the year is not the current one, it is
   necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
   purpose of calculating the expiry date).  With drafts it is normally sufficient to
   specify just the year. -->
    <!-- Meta-data Declarations -->
    <area>General</area>
    <workgroup>Delay-Tolerant Networking Research Group</workgroup>
    <keyword>DTN</keyword>
    <keyword>Network Management</keyword>
    <!-- Keywords will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff
         output. If you submit your draft to the RFC Editor, the
         keywords will be used for the search engine. -->
    <abstract>
      <t>This draft describes the Delay/Disruption Tolerant Network Management Protocol
      (DTNMP). The DTNMP provides monitoring and configuration services
      between managing devices and managed devices, some of which may operate on the far
      side of high-delay or high-disruption links. The protocol is designed to
      minimize the number of transmitted bytes, to operate without sessions or
      (concurrent) two-way links, and to function autonomously when there is no
      timely contact with a network operator. </t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction" toc="default">
      <t>This document presents the Delay/Disruption Tolerant Network Management Protocol
      (DTNMP) providing application-layer network management services over links
      where propagation delays or link disruptions prevent timely communications
      between a network operator and a managed device.<xref target="RFC4838" pageno="false" format="default" />. </t>
      <section title="Overview" toc="default">
        <t>A network management protocol defines the messages that implement
        management functions amongst managed and managing devices in a 
        network. Management functions include the definition, production, and
        reporting of performance data, the application of administrative and
        security policy, and the configuration of behavior based on local 
        time and state measurements.</t>
        <t>DTNs contain nodes whose communication links are characterized by
        signal propagation delays and/or transmission disruptions that make
        timely data exchange difficult or impossible. Management protocols that rely on
        timely data exchange, such as those that rely on negotiated sessions
        or other synchronized acknowledgment, do not function in the DTN 
        environment. For example, the Internet approach of network
        management via closed-loop, synchronous messaging does not work when 
        network disruptions increase in frequency and severity. While no protocol 
        delivers data in the absence of a networking link, protocols that eliminate or 
        drastically reduce overhead and end-point coordination require smaller transmission
        windows and continue to function when confronted with scaling delays and
        disruptions in the network.</t>
        <t>DTNMP accomplishes the network management function using open-loop,
        intelligent-push, asynchronous mechanisms that better scale as link
        challenges scale. The protocol is designed to support five desirable
        properties: 
        	
        	<list style="hanging"><t hangText="Intelligent Push of Information"><vspace blankLines="0" /> The
            intelligent push of information eliminates the need for round-trip
            data exchange in the management protocol. This is a necessary
            consequence of operating in open-loop systems where reliable
            round-trip communication may not exist. DTNMP is designed to
            operate even in uni-directional networks.</t><t hangText="Small Message Sizes"><vspace blankLines="0" /> Smaller messages
            require smaller periods of viable transmission for communication,
            incur less re-transmission cost, and consume less resources when
            persistently stored en-route in the network. DTNMP minimizes the
            size of a message whenever practical, to include packing and
            unpacking binary data, variable-length fields, and pre-configured
            data definitions.</t><t hangText="Fine-grained, Flexible Data Identification"><vspace blankLines="0" />
            Fine-grained identification allows data in the system to be
            explicitly addressed while flexible data identification allows
            users to define their own customized, addressed data collections.
            In both cases, the ability to define precisely the data required
            removes the need to query and transmit large data sets only to
            filter/downselect desired data at a receiving device.</t><t hangText="Asynchronous Operation"><vspace blankLines="0" /> DTNMP does not rely
            on session establishment or round-trip data exchange to perform
            network management functions. Wherever possible, the DTNMP is 
            designed to be stateless.  Where state is required, the DTNMP
            provides mechanisms to support transactions and graceful degredation
            when nodes in the network fail to synchronize on common definitions. 
            </t><t hangText="Compatibility with Low-Latency Network Management Protocols"><vspace blankLines="0" />
            DTNMP adopts an identifier approach compatible with the Managed
            Information Base (MIB) format used by Internet management
            protocols such as the Simple Network Management Protocol (SNMP),
            thus enabling management interfaces between DTNs and other types
            of networks.</t></list></t>
      </section>
      <section title="Technical Notes" toc="default">
        <t>All multi-byte values are assumed to be communicated in
        network-byte order. Bit-fields 
        are specified in Little-Endian format with bit position 0 holding
        the least-significant bit (LSB). When illustrated in this manuscript,
        the LSB appears on the right. </t>
      </section>
      <section title="Scope" toc="default">
        <section title="Protocol Scope" toc="default">
          <t> The DTNMP provides data monitoring, administration, and
          configuration for applications operating above the data link 
          layer of the OSI networking model. While the DTNMP may be configured
          to support the management of network layer protocols (such as the
          Internet Protocol and Bundle Protocol) it also uses these protocols
          stacks to encapsulate and communicate its own DTNMP messages. 
          </t>
          <t>It is assumed that the protocols used to carry DTNMP messages provide
          addressing, confidentiality, integrity, security, fragmentation support
          and other network/session layer functions. Therefore, these items are not
          discussed in the scope of this document.
          </t>
        </section>
        <section title="Specification Scope" toc="default">
          <t>This document describes the format of the DTNMP messages exchanged
           amongst managing and managed devices in a DTN.
           This document further describes the rationale behind key design
           decisions to the extent that such a description informs the
           operational deployment and configuration of DTNMP implementations.
           This document does not address specific data configurations of
           DTNMP-enabled devices, nor does it discuss the interface between DTNMP
           and other management protocols, such as SNMP. </t>
        </section>
      </section>
      <section title="Requirements Language" toc="default">
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
        document are to be interpreted as described in <xref target="RFC2119" pageno="false" format="default">RFC 2119</xref>.</t>
      </section>
    </section>
    <section title="Terminology" toc="default">
      <t>This section identifies those terms critical to understanding the
      proper operation of the DTNMP. Whenever possible, these terms align in
      both word selection and meaning with their analogs from other management
      protocols. <list hangIndent="8" style="hanging"><t hangText="Actor"><vspace blankLines="0" /> A software service running on either
          managed or managing devices implementing an end-point in the DTNMP.
          Actors may implement the "Manager" role, "Agent" role, or both.
          </t><t hangText="Agent Role"><vspace blankLines="0" /> A role within the DTNMP, associated
          with a managed device, responsible for reporting performance data,
          enforcing administrative policies, and accepting/performing actions.
          Agents exchange information with DTNMP managers operating either on
          the same device or on a remote managing device.</t><t hangText="Application Data Model (ADM)"><vspace blankLines="0" /> The set of
          predefined data definitions, reports, literals, operations, and
          controls given to a DTNMP actor to manage a particular application 
          or protocol. DTNMP actors support multiple ADMs, one for each
          application/protocol being managed.  
          </t><t hangText="Atomic Data"><vspace blankLines="0" /> Globally unique, managed data
          definitions, similar to those defined in a Management Information Base
          (MIB), whose definition does not change based on the configuration
          of a DTNMP actor. Atomic data comprise the "lingua franca" within
          the DTNMP. All messages in the protocol operate either directly on
          atomic data or on data derived from atomic data.</t><t hangText="Computed Data"><vspace blankLines="0" /> Data items that are computed
          dynamically by a DTNMP actor from some
          combination of Atomic Data and other Computed Data.</t><t hangText="Controls"><vspace blankLines="0" /> Operations that may be undertaken
          by a DTNMP actor to change the behavior, configuration, or state of
          an application managed by the DTNMP.</t><t hangText="Macros"><vspace blankLines="0" /> A named, ordered collection of
          controls.</t><t hangText="Managed Item Definition (MID)"><vspace blankLines="0" /> A
          parameterized structure used to uniquely identify all data and
          control definitions within the DTNMP. MIDs are a super-set of Object
          Identifiers (OIDs) and the mechanism by which the DTNMP maintains
          data compatibility with other management protocols.</t><t hangText="Manager"><vspace blankLines="0" /> A role within the DTNMP associated
          with a managing device responsible for configuring the behavior of,
          and receiving/processing/visualizing information from, DTNMP agents.
          DTNMP managers also provide gateways to non-DTNMP management
          protocols as part of conditioning the data returned from agents.
          Managers interact with one or more agents located on the same device
          and/or on remote devices in the network.</t><t hangText="Report"><vspace blankLines="0" /> A named, ordered collection of data
          items gathered by one or more DTNMP agents and provided to one or
          more DTNMP managers. Reports may contain atomic data, computed data,
          and other reports. Individual data within a report are not named;
          the report itself is named to reduce the size of the report
          message.</t></list></t>
    </section>
    <section title="System Model" toc="default">
      <section title="Overview" toc="default">
        <t>DTNMP performs the core network management functions of
        configuration, performance reporting, control, and administration, as
        follows. <list hangIndent="8" style="hanging"><t hangText="Configuration"><vspace blankLines="0" /> The configuration function
            synchronizes definitions amongst DTNMP actors
            in the DTN. Managers and Agents must agree on what ADMs are supported
            by what nodes. Further, these Actors must agree on the definitions
            of customized information, such as data production schedules, report
            definitions, and state-based autonomous actions. </t><t hangText="Performance Reporting"><vspace blankLines="0" /> Since DTNMP operates
            asynchronously, performance *monitoring* is replaced by
            performance *reporting*. As there is no expectation of
            closed-loop control of a managed device across a delayed/disrupted
            link, the best action that a managing device can
            undertake is to collect and operate on whatever data is received by
            managed devices. <vspace blankLines="0" /> Reporting the performance
            of a managed device involves the local collection of reports and
            the communication of those reports to appropriate managing
            devices. </t><t hangText="Control"><vspace blankLines="0" /> Part of the ADM for a supported
            application/protocol includes a list of controls/commands that may
            be run by a DTNMP actor based on local time or local state. Controls
            comprise the basic autonomy mechanism within the DTNMP. </t><t hangText="Administration"><vspace blankLines="0" /> The mappings amongst agents
            and managers within a network may be complex, especially in
            networks comprising multiple administrative domains. The
            administrative management function defines what managers may control what
            agents, for what types of information.</t></list></t>
      </section>
      <section title="Roles and Responsibilities" toc="default">
        <t>By definition, DTNMP agents reside on managed devices and DTNMP
        managers reside on managing devices. These roles naturally map to the
        transmit and receipt of various DTNMP messages. This section describes
        how each of these roles participate in the network management
        functions outlined in the prior section. <list hangIndent="8" style="hanging"><t hangText="Agent Responsibilities"><list hangIndent="8" style="hanging"><t hangText="Local Data Collection"><vspace blankLines="0" />Agents MUST
                collect and report the data defined in all ADMs for which they
                have been configured for the local managed device. Agents MAY
                also collect data for network nodes that do not have their own
                DTNMP agents.  In this scenario, the DTNMP agent acts as a proxy
                agent.</t><t hangText="Autonomous Control"><vspace blankLines="0" />Agents MUST determine, 
                without manager intervention, whether a configured control 
                should be invoked. Agents MUST
                periodically evaluate the conditions associated with
                configured controls and invoke those controls based on local
                state. Agents MAY also invoke controls on other devices within
                a regional, low-latency network.</t><t hangText="Data Conditioning"><vspace blankLines="0" />DTNMP agents MUST
                accept computed data definitions that specify how a single
                data value may be constructed from the transformation of one
                or more other data values in the system, using the expression
                syntax specified in this manuscript. Further, agents MUST produce
                this data when requested by Managers with the appropriate
                security persmissions. Agents MUST produce the list of
                computer data definitions when requested by a Manager. Agents
                MUST detect when a computed data definition references other
                data definitions that are unknown to the agent and respond in
                a way consistent with the logging/error-handling configuration
                of the agent.</t><t hangText="Report Definition"><vspace blankLines="0" /> Agents MUST support
                the ability to accept and store definitions for custom report
                definitions. Agents MUST conform to the security policies
                associated with custom reports when determining if a Manager
                may request a report defined by a different Manager in the
                network. Agents MUST provide a listing of custom report
                definitions to appropriate managing devices when requested.
                Agents MUST detect requests for custom reports that are not
                configured on the agent, or are not appropriate for the
                requesting Manager, and respond in a way consistent with the
                logging/error-handling configuration of the agent.</t><t hangText="Consolidate Messages"><vspace blankLines="0" />Agents SHOULD
                produce as few messages as possible when sending information.
                For example, rather than sending multiple report messages to a
                manager, an agent SHOULD prefer to send a single message
                containing multiple reports.</t><t hangText="Regional Proxy"><vspace blankLines="0" />Agents MAY perform any
                of their responsibilities on behalf of other network nodes
                that, themselves, do not have a DTNMP agent.  In such a
                configuration, the DTNMP agent acts as a proxy agent for these
                other network nodes.</t></list></t><t hangText="Manager Responsibilities"><list hangIndent="8" style="hanging"><t hangText="Agent/ADM Mapping"><vspace blankLines="0" />Managers MUST
                understand what ADMs are supported by the various agents with
                which they communicate. Managers SHOULD NOT attempt to
                request, invoke, or refer to ADM information for ADMs
                unsupported by an agent.</t><t hangText="Data Collection"><vspace blankLines="0" />Managers MUST receive
                information from agents by asynchronously configuring the
                production of data reports and then waiting for, and
                collecting, responses from agents over time. Managers SHOULD
                implement internal time-outs to detect conditions where agent
                information has not been received within network-specific
                timespans.</t><t hangText="Custom Definitions"><vspace blankLines="0" /> Managers SHOULD
                provide the ability to define custom data and report
                definitions. Any defined custom definitions MUST be
                transmitted to appropriate agents and these definitions MUST
                be remembered to interpret the reporting of these custom
                values from an agent in the future.</t><t hangText="Data Translation"><vspace blankLines="0" /> Managers SHOULD
                provide some interface to other network management
                protocols, such as the SNMP. Managers MAY accomplish this by
                accumulating a repository of push-data from high-latency parts
                of the network from which data may be pulled by low-latency
                parts of the network.</t><t hangText="Data Fusion"><vspace blankLines="0" /> Managers MAY support the
                fusion of data from multiple agents with the purpose of
                transmitting fused data results to other managers within the
                network. Managers MAY receive fused reports from other
                managers pursuant to appropriate security and administrative
                configurations.</t></list></t></list></t>
      </section>
      <section title="Data Flows" toc="default">
        <t>We identify three significant data flows within the DTNMP: control
        flows from managers to agents, reports flows from agents to managers,
        and fusion reports from managers to other managers. These data flows
        are illustrated in <xref target="system_overview" pageno="false" format="default" />.</t>
        <figure align="center" anchor="system_overview" title="" suppress-title="false" alt="" width="" height="">
          <preamble>DTNMP Data Flows</preamble>
          <artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">    
 +---------+       +------------------------+      +---------+        
 | Node A  |       |         Node B         |      |  Node C |
 |         |       |                        |      |         |
 |+-------+|       |+-------+      +-------+|      |+-------+|
 ||       ||=====&gt;&gt;|| DTNMP |====&gt;&gt;| DTNMP ||====&gt;&gt;||       ||
 ||       ||&lt;&lt;=====|| Mgr B |&lt;&lt;====|Agent B||&lt;&lt;====||       ||
 || DTNMP ||       |+--++---+      +-------+|      || DTNMP ||
 || Agent ||       +---||-------------------+      || Mgr C ||              
 ||   A   ||           ||                          ||       ||
 ||       ||&lt;&lt;=========||==========================||       ||
 ||       ||===========++========================&gt;&gt;||       ||
 |+-------+|                                       |+-------+|
 +---------+                                       +---------+
             </artwork>
        </figure>
        <t>
        In this data flow, the agent on node A receives
        configurations from managers on nodes B and C, and replies with
        reports back to these managers. Similarly, the agent on node B
        interacts with the local manager on node B and the remote manager on
        node C. Finally, the manager on node B may fuse data reports received
        from agents at nodes A and B and send these fused reports back to the
        manager on node C.
        <vspace blankLines="0" />
        From this figure, we see many-to-many relationships amongst
        managers, amongst agents, and between agents and managers. Note that
        agents and managers are roles, not necessarily differing software
        applications. Node A may represent a single software application
        fulfilling only the agent role, whereas node B may have a single
        software application fulfilling both the agent and manager roles. The
        specifics of how these roles are realized is an implementation matter.
        </t>
      </section>
      <section title="Control Flow by Role" toc="default">
        <t>This section describes three common configurations of DTNMP agents
        and managers and the flow of messages between them. These
        configurations involve local and remote management and data fusion.</t>
        <section title="Notation" toc="default">
          <t> The notation outlined in <xref target="ctrl_macros" pageno="false" format="default" /> 
          describes the types of control messages exchanged 
          between DTNMP agents and managers.</t>
          <texttable anchor="ctrl_macros" title="Terminology" suppress-title="false" align="center" style="full">
            <ttcol align="center" width="20%">Term</ttcol>
            <ttcol align="center" width="80%">Definition</ttcol>
            <ttcol align="center" width="20%">Example</ttcol>
            <c>AD#</c>
            <c>Atomic data definition, from ADM.</c>
            <c>AD1</c>
            <c>CD#</c>
            <c>Custom data definition.</c>
            <c>CD1 = AD1 + CD0.</c>
            <c>DEF([ACL], ID,EXPR)</c>
            <c>Define id from expression. Allow managers
            in access control list (ACL) to request this id.</c>
            <c>DEF([*], CD1, AD1 + AD2)</c>
            <c>PROD(P,ID)</c>
            <c>Produce ID according to predicate 
            P. P may be a time period (1s) or an expression (AD1 &gt; 10).</c>
            <c>PROD(1s, AD1)</c>
            <c>RPT(ID)</c>
            <c>A report identified by ID.</c>
            <c>RPT(AD1)</c>
          </texttable>
        </section>
        <section title="Serialized Management" toc="default">
          <t>This is a nominal configuration of network management where a
          managing device interacts with a set of managed devices, with a
          DTNMP manager installed on the managing device and a DTNMP agent
          installed on each managed device. The control flows for this are
          outlined in <xref target="serial_mgmt_ctrl_flow" pageno="false" format="default" />.</t>
          <figure align="center" anchor="serial_mgmt_ctrl_flow" title="" suppress-title="false" alt="" width="" height="">
            <preamble>Serialized Management Control Flow</preamble>
            <artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">    
 +----------+            +---------+           +---------+              
 |  Manager |            | Agent A |           | Agent B |
 +----+-----+            +----+----+           +----+----+
      |                       |                     |
      |-----PROD(1s, AD1)----&gt;|                     |(Step 1)
      |----------------------------PROD(1s, AD1)---&gt;|                    
      |                       |                     |
      |                       |                     |
      |&lt;-------RPT(AD1)-------|                     |(Step 2)
      |&lt;-----------------------------RPT(AD1)-------|
      |                       |                     |
      |                       |                     |
      |&lt;-------RPT(AD1)-------|                     |
      |&lt;-----------------------------RPT(AD1)-------|
      |                       |                     |
      |                       |                     |
      |&lt;-------RPT(AD1)-------|                     |
      |&lt;-----------------------------RPT(AD1)-------|
      |                       |                     |
                 </artwork>
            <postamble>In a simple network, a manager interacts with multiple
            agents.</postamble>
          </figure>
          <t>In this figure, the manager configures agents A and B to produce
          atomic data AD1 every second in (Step 1). At some point in the future,
          upon receiving and configuring this message, agents A and B then
          build a report containing AD1 and send those reports back to the
          manager in (Step 2).</t>
        </section>
        <section title="Multiplexed Management" toc="default">
          <t>Networks spanning multiple administrative domains may require
          multiple managing devices (for example, one per domain). When a
          manager defines custom reports/data to an agent, that definition may
          be tagged with an access control list (ACL) to limit what other
          managers will be privy to this information. Managers in such
          networks SHOULD synchronize with those other managers granted access
          to their custom data definitions. When agents generate messages,
          they MUST only send messages to managers according to these ACLs, if
          present. The control flows in this scenario are outlined in <xref target="multi_mgmt_ctrl_flow" pageno="false" format="default" />.</t>
          <figure align="center" anchor="multi_mgmt_ctrl_flow" title="" suppress-title="false" alt="" width="" height="">
            <preamble>Multiplexed Management Control Flow</preamble>
            <artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">    
 +-----------+            +-------+            +-----------+              
 | Manager A |            | Agent |            | Manager B |
 +-----+-----+            +---+---+            +-----+-----+
       |                      |                      |
       |--DEF(A,CD1,AD1*2)---&gt;|&lt;--DEF(B, CD2, AD2*2)-|(Step 1)
       |                      |                      |
       |---PROD(1s, CD1)-----&gt;|&lt;---PROD(1s, CD2)-----|(Step 2)
       |                      |                      |
       |&lt;-------RPT(CD1)------|                      |(Step 3)
       |                      |--------RPT(CD2)-----&gt;|
       |&lt;-------RPT(CD1)------|                      |
       |                      |--------RPT(CD2)-----&gt;|
       |                      |                      |
       |                      |&lt;---PROD(1s, CD1)-----|(Step 4)
       |                      |                      |
       |                      |--ERR(CD1 no perm.)--&gt;|   
       |                      |                      |
       |--DEF(*,CD3,AD3*3)---&gt;|                      |(Step 5)
       |                      |                      |
       |---PROD(1s, CD3)-----&gt;|                      |(Step 6)
       |                      |                      |
       |                      |&lt;---PROD(1s, CD3)-----|
       |                      |                      |
       |&lt;-------RPT(CD3)------|--------RPT(CD3)-----&gt;|(Step 7)
       |&lt;-------RPT(CD1)------|                      |
       |                      |--------RPT(CD2)-----&gt;|
       |&lt;-------RPT(CD3)------|--------RPT(CD3)-----&gt;|
       |&lt;-------RPT(CD1)------|                      |
       |                      |--------RPT(CD2)-----&gt;|
                 </artwork>
            <postamble>Complex networks require multiple managers interfacing
            with agents.</postamble>
          </figure>
          <t>In more complex networks, managers may choose to define custom
          reports and data definitions, and agents may need to accept such
          definitions from multiple managers. Custom data
          definitions may include an ACL that describes who may query and
          otherwise understand the custom definition. In (Step 1), Manager A
          defines CD1 only for A while Manager B defines CD2 only for B.
          Managers may, then, request the production of reports containing
          these custom definitions, as shown in (Step 2). Agents produce 
          different data for different managers in accordance
          with configured production rules, as shown in (Step 3). If a manager
          requests an operation, such as a production rule, for a custom data
          definition for which the manager has no permissions, a response
          consistent with the configured logging policy on the agent should be
          implemented, as shown in (Step 4). Alternatively, as shown in (Step 5), a
          manager may define custom data with no restrictions allowing all
          other managers to request and use this definition. This allows all
          managers to request the production of reports containing this
          definition, shown in (Step 6) and have all managers receive this and
          other data going forward, as shown in (Step 7).</t>
        </section>
        <section title="Data Fusion" toc="default">
          <t>In many networks, agents do not want to individually transmit
          their data to a manager, preferring instead to fuse reporting data
          with local nodes prior to transmission. This approach reduces the
          number and size of messages in the network and reduces overall
          transmission energy expenditure. DTNMP supports fusion of NM reports
          by co-locating agents and managers on managed devices and offloading
          fusion activities to the manager. This process is illustrated in
          <xref target="fusion_ctrl_flow" pageno="false" format="default" />.</t>
          <figure align="center" anchor="fusion_ctrl_flow" title="" suppress-title="false" alt="" width="" height="">
            <preamble>Data Fusion Control Flow</preamble>
            <artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">    
 +-----------+        +-----------+      +---------+      +---------+               
 | Manager A |        | Manager B |      | Agent B |      | Agent C |
 +---+-------+        +-----+-----+      +----+----+      +----+----+
     |                      |                 |                |
     |--DEF(A,CD0,AD1+AD2)-&gt;|                 |                |(Step 1)
     |--PROD(AD1&amp;AD2, CD0)-&gt;|                 |                |
     |                      |                 |                |
     |                      |--PROD(1s,AD1)--&gt;|                |(Step 2)
     |                      |-------------------PROD(1s, AD2)-&gt;|
     |                      |                 |                |
     |                      |&lt;---RPT(AD1)-----|                |(Step 3)
     |                      |&lt;-------------------RPT(AD2)------|
     |                      |                 |                |
     |&lt;-----RPT(A,CD0)------|                 |                |(Step 4)
     |                      |                 |                |
                 </artwork>
            <postamble>Data fusion in DTNMP accours amongst managers in the
            network.</postamble>
          </figure>
          <t>In this example, Manager A requires the production of a computed
          data set, CD0, from node B, as shown in (Step 1). The manager role
          understands what data is available from what agents in the subnetwork
          local to B, understanding that AD1 is available locally and AD2 is
          available remotely. Production messages are produced in (Step 2) and data
          collected in (Step 3). This allows the manager at node B to fuse the
          collected data reports into CD0 and return it in (Step 4). While a
          trivial example, the mechanism of associating fusion with the
          manager function rather than the agent function scales with fusion
          complexity, though it is important to reiterate that agent and
          manager designations are roles, not individual software components.
          There may be a single software application running on node B
          implementing both Manager B and Agent B roles.</t>
        </section>
      </section>
    </section>
    <section title="Component Model" toc="default">
      <t>This section identifies the components that comprise the data
      communicated within the DTNMP, the way in which these components are
      named, and those special types associated with DTNMP messages.</t>
      <section title="Data Representation" toc="default">
        <section title="Types" toc="default">
          <t>Components within the DTNMP are represented as one of four basic
          data types: Data, Controls, Literals, and Operators: <list hangIndent="8" style="hanging"><t hangText="Data">Data consist of values collected by an agent
              and reported to managers within the DTNMP. This includes
              definitions from an ADM, derived
              data as configured from managers, and reports which are
              collections of data elements.</t><t hangText="Controls">Controls consist of actions that may be
              invoked on agents and managers to change behavior in
              response to some external event (such as local state changes or
              time). Controls include application-specific functions
              specified as part of an ADM and macros which are collections of
              these controls. </t><t hangText="Literals">Literals are constant numerical values
              that may be used in the evaluation of expressions and predicates.</t><t hangText="Operator">Operators are those mathematical
              functions that operate on series of Data and Literals, such as
              addition, subtraction, multiplication, and division.</t></list></t>
        </section>
        <section title="Categories" toc="default">
          <t>Components within the DTNMP can be categorized as Atomic,
          Computed, or Collection. <list hangIndent="8" style="hanging"><t hangText="Atomic"><vspace blankLines="0" />Atomic components are those components
              that are directly implemented by the underlying software/firmware
              of a network node. Atomic components may also refer to components
              whose definitions may not be changed. Examples of atomic components 
              are Data, Controls, Literals, and Operators specified by an ADM.  
              Atomic component identifiers MUST be unique and SHOULD be managed by a 
              registration authority, similar to the mechanisms used to
              assign Object Identifiers (OIDs). Atomic components must be
              understood by both DTNMP managers and agents in a network. </t><t hangText="Computed"><vspace blankLines="0" />Computed components are those
              components that are not directly implemented by the underlying
              software/firmware of a network node. The definition of a computed
              component MAY be dynamically defined by DTNMP managers and
              communicated to one or more DTNMP agents in a network. The 
              definition of a computed component may include other computed
              components or other atomic components. The identifier of a 
              computed component is not guaranteed to be universally unique
              but SHOULD be unique within the context of a particular network
              or internetwork.</t><t hangText="Collection"><vspace blankLines="0" />A collection component is a set
              of other components (to include other collection components). DTNMP
              implementations MUST prevent circular definitions when implementing
              collections that include other collections.</t></list></t>
        </section>
        <section title="Data Model" toc="default">
          <t>Each component of the DTNMP data model can be identified as a
          combination of type and category, as illustrated in <xref target="model_ref" pageno="false" format="default" />. In this table type/catgory combinations that
          are unsupported are listed as N/A. Specifically, DTNMP does not
          support user-defined controls, constants, or operations; any value
          that specifies action on an agent MUST be pre-configured as part of
          an ADM.</t>
          <texttable anchor="model_ref" title="" suppress-title="false" align="center" style="full">
            <ttcol align="center" />
            <ttcol align="center">Data</ttcol>
            <ttcol align="center">Controls</ttcol>
            <ttcol align="center">Literals</ttcol>
            <ttcol align="center">Operator</ttcol>
            <c>Atomic</c>
            <c>Measured Value</c>
            <c>Control</c>
            <c>Constant</c>
            <c>Operator</c>
            <c>Computed</c>
            <c>Calculated Value</c>
            <c>N/A</c>
            <c>N/A</c>
            <c>N/A</c>
            <c>Collection</c>
            <c>Report</c>
            <c>Macro</c>
            <c>N/A</c>
            <c>N/A</c>
          </texttable>
        </section>
      </section>
      <section title="Primitive Types" toc="default">
        <section title="Self-Delimiting Numeric Value (SDNV)" toc="default">
          <t> The data type "SDNV" refers to a Self-Delimiting Numerical Value 
          (SDNV) described in <xref target="RFC6256" pageno="false" format="default" />. SDNVs are used in the
          DTNMP to capture any data items that are expected to be 8 bytes
          or less in total length.  DTNMP actors MAY reject any SDNV value
          that is greater than 8 bytes in length.</t>
        </section>
        <section title="Timestamp (TS)" toc="default">
          <t>For compatibility with a variety of protocols, the use of UTC
          time is selected to represent all time values in the DTNMP. However,
          timestamps in DTNMP may represent either absolute or relative time
          based on the associated epoch. DTNMP uses September 9th, 2012 as the
          timestamp epoch (UTC time 1348025776). Values less than this value
          MUST be considered as relative times. Values greater than or equal
          to this epoch MUST be considered as absolute times. In all cases,
          the DTNMP timestamp is encoded as an SDNV. </t>
        </section>
        <section title="Data Collections (DC)" toc="default">
          <t>A Data collection is comprised of a value identifiying the number
          of bytes in the collection, followed by each byte, as illustrated in
          <xref target="data_list" pageno="false" format="default" />. Data collections are used in the DTNMP
          to capture variable data sets that are too large to place in an
          SDNV. <figure align="center" anchor="data_list" title="" suppress-title="false" alt="" width="" height=""><preamble>Data Collection</preamble><artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">
+---------+--------+--------+     +--------+
| # Bytes | BYTE 1 | BYTE 2 | ... | BYTE N |
|  [SDNV] | [BYTE] | [BYTE] |     | [BYTE] |
+---------+--------+--------+     +--------+
              </artwork></figure></t>
        </section>
      </section>
      <section title="Naming and Identification" toc="default">
     
      	<t>
      		While all components within the DTNMP can be uniquely identified by an
      		Object Identifier (OID), several annotations exist to assist with the
      		filtering and access control associated with components beyond what is 
      		efficiently represented in the OID structure. These annotations include
      		the type and category of the component, an optional identifier naming
      		the issuer of the component, and an optional tag value holding
      		issuer-specific information about the component.
      	</t>
      	<t>
      		The DTNMP Managed Identifier (MID) provides a single, variable length
      		structure that encapsulates all of the information necessary to identify
      		a DTNMP component and its useful annotations. 
      	</t>
      	<t>
        	The MID structure, illustrated in <xref target="mid" pageno="false" format="default" />, is comprised of up to four fields.  In this illustration,
        each field is named, the type of each field is given in []'s, and the
        string "(opt.)" indicates that the field is optional, pending on the
        values found in the flags byte.</t>
        <figure align="center" anchor="mid" title="" suppress-title="false" alt="" width="" height="">
          <preamble>MID format</preamble>
          <artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">
+--------+--------+--------+--------+
| Flags  | Issuer |   OID  |   Tag  |
| [BYTE] | [SDNV] |[VARIED]| [SDNV] |
|        | (opt.) |        | (opt.) |
+--------+--------+--------+--------+
             </artwork>
        </figure>
        <t>The MID fields are defined as follows.
          <list hangIndent="8" style="hanging"><t hangText="Flags"><vspace blankLines="0" /> Flags are used to describe the type of
            component identified by the MID, identify which optional fields
            in the MID are present, and the encoding used to capture the
            component's OID. The layout of the flag byte is illustrated in <xref target="mid_flag" pageno="false" format="default" />.
              <figure align="center" anchor="mid_flag" title="" suppress-title="false" alt="" width="" height=""><preamble>MID Flag Format</preamble><artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">
+-----+---+---+-----+------+
| OID |TAG|ISS| CAT | TYPE |
+-----+---+---+-----+------+
| 7 6 | 5 | 4 | 3 2 | 1  0 |
+-----+---+---+-----+------+
 MSB                    LSB                       
                </artwork></figure><list hangIndent="8" style="hanging"><t hangText="MID Type (TYPE)"><vspace blankLines="0" /> The type of the component 
                encapsulated by the MID, enumerated as data (0), control (1),
                literal (2), or operator (3).</t><t hangText="MID Category (CAT)"><vspace blankLines="0" />The category of the 
                component encapsulated by the MID, enumerated as atomic (0), 
                computed (1), and collection (2). </t><t hangText="Issuer Present (ISS)"><vspace blankLines="0" /> Whether the
                issuer field is present (1) or not (0) for this MID. If this
                flag has a value of 1 then the issuer field MUST be present
                in the MID. Otherwise, the issuer field MUST NOT be present
                in the MID.</t><t hangText="Tag Present (TAG)"><vspace blankLines="0" /> Whether the tag
                field is present (1) or not (0) for this MID. If this flag has
                a value of 1 then the tag field MUST be present in the MID.
                Otherwise, the tag field MUST NOT be present.</t><t hangText="OID Type (OID)"><vspace blankLines="0" /> Whether the contained
                OID field represents an full OID (0), a parameterized OID (1),
                a compressed full OID (2), or a compressed, parameterized OID
                (3).</t></list>
              
              For example, a MID flag byte of 0x00 indicates an atomic data
            value with no issuer or tag field encapsulating a full
            OID. A MID flag byte of 0x94 indicates a computed data value with an
            issuer field, but no tag field encapsulating a
            compressed OID.</t><t hangText="Issuer"><vspace blankLines="0" /> This is a binary
            identifier representing a predetermined issuer name. The DTNMP
            protocol does not parse or validate this identifier, using it only
            as a distinguishing bit pattern to assure MID uniqueness. This
            value, for example, may come from a global registry of
            organizations, an issuing node address, or some other
            network-unique marking.</t><t hangText="OID"><vspace blankLines="0" /> The core of a MID is its encapsulated
            Object Identifier (OID). Aside from the flag byte, this is the
            only other mandatory element within a MID. The DTNMP defines four types
            of OID references for this part of the MID structure: Full OIDs,
            Parameterized OIDs, Compressed Full OIDs, and Compressed
            Parameterized OIDs. <list hangIndent="8" style="hanging"><t hangText="Full OID"><vspace blankLines="0" />This is a binary
                representation of the full OID associated with the named
                value. The OID is encoded using a modified form of the ASN.1 
                Basic Encoding Rules (BER) for Object Identifiers (type value of 
                0x06). In the standard ASN.1 encoding, four octet sets are
                defined: identifier octets, length octets, contents octets, and
                end-of-contents octets.  A DTNMP Full OID does not use the
                identifier, length, or end-of-contents octets. Instead, a
                DTNMP Full OID is comprised of two fields: the length in
                bytes of the encoded OID captured in an SDNV followed by the
                OID contents octets, as illustrated in <xref target="full_oid_fmt" pageno="false" format="default" />.
                
                  <figure align="center" anchor="full_oid_fmt" title="" suppress-title="false" alt="" width="" height=""><preamble>Full OID Format</preamble><artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">
+------------+--------------------+ 
| OID Length | OID Content Octets |
|   [SDNV]   |    [ASN.1 BER]     | 
+------------+--------------------+
                  </artwork></figure></t><t hangText="Parameterized OID"><vspace blankLines="0" />The parameterized OID
                is represented as the non-parameterized portions of the OID
                followed by one or more parameters. Parameterized OIDs are
                used to templatize the specification of data items and
                otherwise provide parameters to controls without requiring
                potentially unmanagable growth of a Full OID namespace. The
                format of a parameterized OID is given in <xref target="parm_oid_fmt" pageno="false" format="default" />. <figure align="center" anchor="parm_oid_fmt" title="" suppress-title="false" alt="" width="" height=""><preamble>Parameterized OID Format</preamble><artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">
+----------+---------+--------+     +--------+
| Base OID | # Parms | Parm 1 | ... | Parm N |
|   [VAR]  |  [SDNV] |  [DC]  |     |  [DC]  |
+----------+---------+--------+     +--------+
                     </artwork></figure></t><t hangText="Compressed Full OID"><vspace blankLines="0" />Since many related
                OIDs share a common and lengthy hierarchy there is opportunity
                for significant message size savings by defining a shorthand
                for commonly-used portions of the OID tree. A partial OID is a
                tuple consisting of a nickname for a pre-defined portion of
                the OID tree (as an SDNV), followed by a relative OID.</t><t hangText="Compressed Parameterized OID"><vspace blankLines="0" />A
                compressed, parameterized OID is similar to a compressed OID.
                In this instance, the tuple contained in this field is the
                nickname for the pre-defined portion of the OID tree (as an
                SDNV) followed by a parameterized OID whose hierarchy begins
                at the place identified by the nickname.</t></list></t><t hangText="Tag"><vspace blankLines="0" /> A value used to disambiguate multiple
            MIDs with the same OID/Issuer combination. The definition of the
            tag is left to the discretion of the MID issuer. Proper name
            objects do not require a tag as their OIDs are guaranteed to be
            globally unique. Options for tag values include an issuer-known
            version number or a hashing of the data associated with a
            non-proper-name MIDs. The tag field MUST NOT be present for the
            atomic category.</t></list></t>
      </section>
      <section title="Special Types" toc="default">
        <t>In addition to the primitive data types already mentioned, the
        following special data types are also defined.</t>
        <section title="MID Collections (MC)" toc="default">
          <t>A MID collection is comprised of a value identifiying the number
          of MIDs in the collection, followed by each MID, as illustrated in
          <xref target="mid_list" pageno="false" format="default" />. <figure align="center" anchor="mid_list" title="" suppress-title="false" alt="" width="" height=""><preamble>MID Collection</preamble><artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">
+--------+-------+     +-------+
| # MIDs | MID 1 | ... | MID N |
| [SDNV] | [MID] |     | [MID] |
+--------+-------+     +-------+
                     </artwork></figure></t>
        </section>
        <section title="Expressions (EXPR)" toc="default">
          <t>Expressions apply operations to data and literal values to
          generate new data values. The expression type in DTNMP is a
          collection of MIDs that represent a postfix notation stack of Data,
          Literal, and Operation types. For example, the infix expression A *
          (B * C) is represented as the sequence A B C * *. The format of an
          expression is illustrated in  <xref target="expr_fmt" pageno="false" format="default" />. <figure align="center" anchor="expr_fmt" title="" suppress-title="false" alt="" width="" height=""><preamble>Expression Format</preamble><artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">
+----------+------------+
| Priority | Expression |
|  [SDNV]  |    [MC]    |
+----------+------------+
                     </artwork></figure><list hangIndent="8" style="hanging"><t hangText="Priority"><vspace blankLines="0" /> The priority of this expression
            relative to any other expression configured on the DTNMP actor. Priorities
            are used when one expression MUST be evaluated before some other expression
            is evaluated. This field represents an unsigned integer value with 
            larger values indicating higher priority. Unless otherwise specified,
            a default priority value of 0 SHALL be used for any defined expression.</t><t hangText="Expression"><vspace blankLines="0" />An expression is represented in 
            the DTNMP as a MID collection,
          where each MID in the ordered collection represents the data,
          literals, and operations that comprise the expression. </t></list></t>
        </section>
        <section title="Predicate (PRED)" toc="default">
          <t>Predicates are expressions whose values are interpretted as a
          Boolean. The value of zero MUST be considered "false" and all other
          values MUST be considered "true". Similar to an expression, a
          predicate is represented as a MID collection. </t>
        </section>
      </section>
    </section>
    <section title="Functional Specification" toc="default">
      <t>This section describes the format of the messages that comprise the
      DTNMP protocol. When discussing the format/types of data that comprise
      message fields, the following conventions are used.</t>
      <texttable title="" suppress-title="false" align="center" style="full">
        <ttcol align="left">Type Name</ttcol>
        <ttcol align="left">Description</ttcol>
        <c>BYTE</c>
        <c>Unsigned, 8-bit byte.</c>
        <c>DC</c>
        <c>Data Collection</c>
        <c>EXPR</c>
        <c>Expression</c>
        <c>MC</c>
        <c>MID Collection</c>
        <c>MID</c>
        <c>Managed Identifier</c>
        <c>PRED</c>
        <c>Predicate</c>
        <c>SDNV</c>
        <c>Self-Delimiting Numerical Value</c>
        <c>TS</c>
        <c>Timestamp</c>
        <c>VAR</c>
        <c>Variable field.</c>
      </texttable>
      <section title="Message Group Format" toc="default">
        <t>Individual messages within the DTNMP are combined into a single 
        group for communication with another DTNMP actor. Messages within
        a group MUST be received and applied as an atomic unit. The format
        of a message group is illustrated in <xref target="msg_grp" pageno="false" format="default" />. 
        
        These message groups are
        assumed communicated amongst agents and managers as the payloads of
        encapsulating protocols, such as the Bundle Protocol or Internet Protocol, 
        which MAY provide additional security and data integrity features.

          <figure align="center" anchor="msg_grp" title="" suppress-title="false" alt="" width="" height=""><preamble>DTNMP Message Group Format</preamble><artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">
+--------+-----------+-----------+     +-----------+
| # Msgs | Timestamp | Message 1 | ... | Message N |
| [SDNV] |    [TS]   |   [VAR]   |     |   [VAR]   |
+--------+-----------+-----------+     +-----------+
            </artwork></figure><list hangIndent="8" style="hanging"><t hangText="# Msgs"><vspace blankLines="0" /> The number of messages that
            are together in this message group.</t><t hangText="Timestamp"><vspace blankLines="0" />The creation time for this
            messaging group.  This timestamp MUST be an absolute time. 
            Individual messages may have their own creation timestamps
            based on their type, but the group timestamp also serves
            as the default creation timestamp for every message in the
            group. </t><t hangText="Message N"><vspace blankLines="0" /> The Nth message in the group.</t></list></t>
      </section>
      <section title="Message Format" toc="default">
        <t> Each message identified in the DTNMP specification adheres to a
        common message format, illustrated in <xref target="msg_fmt" pageno="false" format="default" />, consisting
        of a message header, a message body, and an optional trailer.
          <figure align="center" anchor="msg_fmt" title="" suppress-title="false" alt="" width="" height=""><preamble>DTNMP Message Format</preamble><artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">
+--------+-------+---------+
| Header | Body  | Trailer |
| [BYTE] | [VAR] |  [VAR]  |
|        |       |  (opt.) |
+--------+-------+---------+
            </artwork></figure></t>

            
        <t>
          <list hangIndent="8" style="hanging">
            <t hangText="Header">
              <vspace blankLines="0" /> The message header byte is shown 
            in <xref target="cmn_hdr" pageno="false" format="default" />. The header identifies a message 
            context and opcode as well as flags that control whether a report 
            should be generated on message success (Ack) and whether a report 
            should be generated on message failure (Nack).
              <figure align="center" anchor="cmn_hdr" title="" suppress-title="false" alt="" width="" height=""><preamble>DTNMP Common Message Header</preamble><artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">
+--------+----+---+---------+-------+
|ACL Used|Nack|Ack| Context |Opcode |
+--------+----+---+---------+-------+
|    7   |  6 | 5 |   4  3  | 2 1 0 |
+--------+----+---+---------+-------+
 MSB                             LSB
                </artwork></figure><list hangIndent="8" style="hanging"><t hangText="Opcode"><vspace blankLines="0" /> The opcode field identifies the
                opcode of the message, within the associated message context.</t><t hangText="ACK Flag"><vspace blankLines="0" /> The ACK flag describes whether
                successfull application of the message must generate an
                ackowledgement back to the message sender. If this flag is set (1)
                then the receiving actor MUST generate a report communicating this
                status. Otherwise, the actor MAY generate such a report based on
                other criteria.</t><t hangText="NACK Flag"><vspace blankLines="0" /> The NACK flag describes whether
                a failure applying the message must generate an error notice back
                to the message sender. If this flag is set (1) then the receiving
                actor MUST generate a report communicating this status. Otherwise,
                the actor MAY generate such a report based on other criteria.</t><t hangText="ACL Used Flag"><vspace blankLines="0" /> The ACL used flag indicates
                whether the message has a trailer associated with it that
                specifies the list of DTNMP actors that may participate in the
                actions or definitions associated with the message. This area is
                still under development.</t></list></t>
            <t hangText="Body">
              <vspace blankLines="0" />
The message body contains the information associated with the given
        message. </t>
            <t hangText="Trailer">
              <vspace blankLines="0" /> An OPTIONAL access control list (ACL) may be
        appended as a trailer to a message. When present, the ACL for a
        message identifiers the agents and managers that can be affected by
        the definitions and actions contained within the message. The explicit
        impact of an ACL is described in the context of each message below.
        When an ACL trailer is not present, the message results may be visible
        to any DTNMP actor in the network, pursuant to other security protocol
        implementations.</t>
          </list>
        </t>
      </section>
      
      
        <section title="Register Agent (0x00)" toc="default">
          <t>The Register Agent message is used to inform a DTNMP manager of
          the presence of another agent in the network. <figure align="center" anchor="register_agent_msg" title="Register Agent Message Body" suppress-title="false" alt="" width="" height=""><artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">
+----------+
| Agent ID |
| [SDNV]   |
+----------+
                     </artwork></figure><list hangIndent="8" style="hanging"><t hangText="Agent ID"><vspace blankLines="0" /> The Agent ID MUST represent the
              unique address of the agent in whatever protocol is used to
              communicate with the agent. For example, when DTNMP is run over
              Bundle Protocol, the Agent ID should be the Endpoint Identifier
              (EID) of the agent being added.</t></list></t>
        </section>
        
        
        <section title="Data Report (0x12)" toc="default">
          <t>Data reports include a listing of one or more data items
          collected from a managed device. These reports may include atomic
          data, computed data, or any report definition known to the
          generating device. Each message is a concatenation of ID/Data
          definitions with the overall message length assumed to be captured
          in the underlying transport container. 
          	<figure align="center" anchor="data_rpt_msg" title="" suppress-title="false" alt="" width="" height="">
          		<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">
+------+------+-------+--------+   +-------+--------+
| Time | Num  | ID 1  | Data 1 |   | ID N  | Data N |
| [TS] |[SDNV]| [MID] |  [DC]  |...| [MID] |  [DC]  |
+------+------+-------+--------+   +-------+--------+                
          		</artwork>
          	</figure>

			<list hangIndent="8" style="hanging">
				<t hangText="Time">
					<vspace blankLines="0" /> The time at which the report was
              		generated by the DTNMP actor.</t>
              <t hangText="Num">
              		<vspace blankLines="0" /> The number of reports in the data
              		report message.</t>
              <t hangText="ID N">
              		<vspace blankLines="0" /> The MID identifying the Nth report.</t>
              <t hangText="Data N"><vspace blankLines="0" /> The contents of the Nth report.</t>
            </list>
          </t>
        </section>

        
        <section title="Perform Control (0x20)" toc="default">
          <t>The perform control method causes the receiving DTNMP actor to
          apply one or more pre-configured controls.</t>
          <figure align="center" anchor="run_ctlr_msg" title="" suppress-title="false" alt="" width="" height="">
            <preamble>Predicate Production Message</preamble>
            <artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">+-------+-----------+
| Start |  Controls |
|  [TS] |    [MC]   |
+-------+-----------+
                 </artwork>
          </figure>
          <t>
            <list hangIndent="8" style="hanging">
              <t hangText="Start">
                <vspace blankLines="0" /> The time at which the control
              should be run.</t>
              <t hangText="Controls">
                <vspace blankLines="0" /> The collection of controls to
              be applied by the DTNMP actor. The MID identifying a control will contain the
                	parameters for the control (if any) through the use of a parameterized OID
                	captured within the MID.</t>
            </list>
          </t>
        </section>
      
        
    </section>
    
    <section anchor="AGENT_TMPL" title="Appliation Data Model Template" toc="default">
    	
    	<section anchor="ADM_OVERVIEW" title="Overview" toc="default">
    		<t>
    			An application data model (ADM) specifies the set of DTNMP components associated with
    			a particular application/protocol. The purpose of the
    			ADM is to provide a guaranteed interface for the management of an application or protocol
    			over DTNMP that is independent of the nuances of its software implementation. In this 
    			respect, the ADM is conceptually similar to the Managed Information Base (MIB) used by SNMP, 
    			but contains additional information relating to command opcodes and more expressive syntax for
    			automated behavior.
    		</t>	
    		<t>
    			Currently, the ADM is an organizing document and not used to automatically generate software. 
    			As such, the ADM template lists the kind of information that must be present in an ADM
    			definition but does not address mechanisms for automating implementations.
    		</t>
    		<t>
    			Each ADM specifies the globally unique identifiers and descriptions for all data, controls,
    			literals, and operators associated with the application or protocol maanged by the ADM. Any
    			implementation claiming compliance with a given ADM must compute all identified data, 
    			perform identified controls, and understand identified literals and operators. 
    		</t>
    		
    	</section>

    	<section title="ADM Types">
    		<t>
				ADMs must specify data types when defining data items and parameters. In addition to the standard DTNMP Types
    			(SDNV, TS, DC, MID, OID, P_OID, MC, EXPR, and PRED) ADMs support the following additional data types.  
      		</t>
    			
    		 <texttable anchor="adm_datatype" title="ADM Data Types" suppress-title="false" align="center" style="full">
           		<ttcol align="center" width="20%">Data Type</ttcol>
           		<ttcol align="center" width="10%">ID</ttcol>
           		<ttcol align="center" width="60%">Description</ttcol>
           		<ttcol align="center" width="10%">Encapsulating DTNMP Type</ttcol>
            		
           		
           		<c>Integer</c>
           		<c>INT</c>
           		<c>A signed or unsigned integer up to 64 bits in width encoded using Google Protocol Buffer VARINT rules. 
           			Booleans, enumerations, and all integer values are captured using this data type.</c>
				<c> SDNV </c>
	           			
           		<c>Float</c>
           		<c>FLOAT</c>
           		<c>A 32-bit fixed-width number stored according to the IEEE-754 float standard. </c>
				<c> SDNV </c>
           		
           		<c>Double</c>
           		<c>DOUBLE</c>
           		<c>A 64-bit fixed-width number stored according to the IEEE-754 double standard. </c>
           		<c> SDNV </c>
           		            		
				<c>STRING</c>
           		<c>STR</c>
           		<c>An array of characters preceeded by the character count. Strings are not required to be NULL-terminated. </c>
				<c> DC </c>
           		
				<c>Binary Large Object</c>
           		<c>BLOB</c>
           		<c>An undefined series of user-defined bytes preceeded by the length of the binary object. This
           			data type is captured . </c>
           		<c> DC </c>            		
	         </texttable>
          
   		</section>
    	
    	    		
    	<section anchor="ADM_TMPL_DEF" title="Template" toc="default">
    		<t>
				ADM definitions specify the metadata, data, controls, literals, and operators associated with
    			a managed application or protocol.
    		</t>

    		    		
    		<section title="ADM Metadata">
    			<t>
    				ADM metadata consist of the items necessary to uniquely identify the ADM itself. The
    				required metadata items include the following.
    			</t>
    			
    			 <texttable anchor="adm_metadata" title="ADM Terminology" suppress-title="false" align="center" style="full">
            		<ttcol align="center" width="20%">Item</ttcol>
            		<ttcol align="center" width="10%">Type</ttcol>
            		<ttcol align="center" width="65%">Description</ttcol>
            		<ttcol align="center" width="5%">Req.</ttcol>
            		

            		<c>Name</c>
            		<c>STR</c>
            		<c>The human-readible name of the ADM. </c>
					<c>Y</c>

					<c>Version</c>
            		<c>STR</c>
            		<c>Version of the ADM encoded as a string. </c>
					<c>Y</c>

					<c>OID Nickname N</c>
            		<c>OID</c>
            		<c> ADMs provide an ordered list of nicknames that can be used by other MIDs in the ADM definition
            			to defined compressed OIDs. There can an arbitratry number of nicknames defined for an ADM. </c>
					<c>N</c>
		         </texttable>
          
    		</section>
    		
    		<section title="ADM Information Capture">
    			<t>
    				The ADM Data Section consist of all components in the "data" category associated with the
    				managed application or protocol. The information that must be provided for each of these
    				items is as follows.
    				
    				<list style="hanging">
    					<t hangText="Name"><vspace blankLines="0" /> Every component in an ADM MUST be given
    						a human-readable, consistent name that unqiuely identifies the component in the
    						context of the application or protocol. These names will be used by human-computer
    						interfaces for manipulating components.</t>
    						
    					<t hangText="MID"><vspace blankLines="0" /> The managed identifier that describes this
    						data item. MIDs in components identified by an ADM MUST NOT contain an issuer or
    						a tag value. In cases where a partial OID is specified, the ADM OID prefix is presumed
    						as the base. In cases where the OID is parameterized, the parameter values are not included
    						in the MID definition in the ADM as parameters are provided at runtime by implementations.</t>

    				    <t hangText="OID"><vspace blankLines="0" /> A human-readible version of the OID encapsulated
    				    	in the MID for the component (e.g., 1.2.3.4). When a nickname is used to represent an 
    				    	compressed OID, the nickname enumeration is included in this field enclosed by square brackets.
    				    	For example, if OID nickname 0 refers to the OID prefix 1.2.3.4.5, then the OID 1.2.3.4.5.6 may be
    				    	listed more compactly as [0].6</t>
    						
    				    <t hangText="Description"><vspace blankLines="0" /> Every component in an ADM MUST be given a
    				    	human-readable, consistent description that provides a potential user with a compact, 
    				    	effective summary of the component.</t>

    				    <t hangText="Type"><vspace blankLines="0" /> For components that evaluate to a data value, the
    				    	data type for that value must be represented.</t>
    				    	
    				    <t hangText="# Parameters"><vspace blankLines="0" /> For components with a parameterized OID, the
    				    	ADM MUST provide the expected number of parameters. A value of 0 indicates that the OID has no
    				    	parameters and MUST NOT be used for any MID which has a parameterized OID. When ommitted,
    				    	the number of parameters is considered 0.</t>
    				    	
    				    <t hangText="Parameter N Name"><vspace blankLines="0" /> Each parameter of a parameterized component
    				    	must be given a name.</t>
    				    	
    				    <t hangText="Parameter N Description"><vspace blankLines="0" /> Each parameter of a parameterized 
    				    	component must be given a summary that describes how the parameter will be used by the 
    				    	application or protocol.</t>
    				    	    				    	
    				    <t hangText="Parameter N Type"><vspace blankLines="0" /> Each parameter of a parameterized component
    				    	must be given a type that describes the structre capturing the parameter value. Notably, while
    				    	parameters in the OID form something similar to a function prototype, there is no sense of 
    				    	function call or stack and therefore all parameters should be considered as pass-by-value.</t>    				    		    						    						    						
					</list>
    			</t>
    			
    		</section>
    	</section>	
    </section>
    
    <section anchor="AGENT_ADM" title="DTNMP Agent Application Data Model" toc="default">
    
    	<section anchor="AGENT_ADM_OVERVIEW" title="Data Definitions" toc="default">
    		<t>
    			This section provides the ADM for a DTNMP Agent. This ADM may eventually be removed from the
    			DTNMP specification into its own standards document. All DTNMP agents MUST support the 
    			items described in this section.
    		</t>
    	</section>
    	    	
    	<section anchor="AGENT_ADM_META" title="Metadata Definitions" toc="default">
    		 <texttable anchor="agent_adm_metadata" title="DTNMP Agent Metadata" suppress-title="false" align="center" style="full">
            		<ttcol align="center" width="20%">Item</ttcol>
            		<ttcol align="center" width="10%">Type</ttcol>
            		<ttcol align="center" width="10%">Value</ttcol>
            		<ttcol align="center" width="60%">Comment</ttcol>
            		
            		
            		<c>Name</c>
            		<c>STR</c>
            		<c>DTNMP Agent ADM</c>
            		<c></c>
	
					<c>Version</c>
            		<c>STR</c>
            		<c>2014-12-31</c>
					<c></c>
					
					<c>OID Nickname 0</c>
            		<c>OID</c>
            		<c>1.1</c>
            		<c>1.1 is currently used only as a non-operational example of an ADM base.</c>

     		        </texttable>
    	</section>
    	    	
    	<section anchor="ADM_DATA" title="Data Definitions" toc="default">
    		<t>
    			The DTNMP Agent ADM defines the following atomic data definitions that represent the
    			set of data that MUST be collected by any DTNMP agent implementation.
    		</t>
    		<section title="Atomic Data">
    			<texttable anchor="agent_adm_atomicdata" title="DTNMP Agent Atomic Data" suppress-title="false" align="center" style="full">
            		<ttcol align="center" width="20%">Name</ttcol>
            		<ttcol align="center" width="10%">MID</ttcol>
            		<ttcol align="center" width="10%">OID</ttcol>            		
            		<ttcol align="center" width="60%">Description</ttcol>
            		<ttcol align="center" width="60%">Type</ttcol>
            		
            		
            		<c>DefinedReports</c>
            		<c>0x800200</c>
            		<c>[0].0.0</c>
            		<c># Reports Defined</c>
            		<c>INT</c>

            		<c>SentReports</c>
            		<c>0x800201</c>
            		<c>[0].0.1</c>
            		<c># Reports Sent</c>
            		<c>INT</c>
            			
            		<c>DefinedTimeRules</c>
            		<c>0x800202</c>
            		<c>[0].0.2</c>
            		<c># Active Time-Based Production Rules</c>
            		<c>INT</c>

            		<c>RunTimeRules</c>
            		<c>0x800203</c>
            		<c>[0].0.3</c>
            		<c># Run Time-Based Production Rules</c>
            		<c>INT</c>
            							
            		<c>DefinedConsts</c>
            		<c>0x800204</c>
            		<c>[0].0.4</c>
            		<c># Constants Defined</c>
            		<c>INT</c>
            		
            		<c>DefinedCustom</c>
            		<c>0x800205</c>
            		<c>[0].0.5</c>
            		<c># Computed Data Definitions</c>
            		<c>INT</c>

            		<c>DefinedMacros</c>
            		<c>0x800206</c>
            		<c>[0].0.6</c>
            		<c># Macros Defined</c>
            		<c>INT</c>
            							
            		<c>RunMacros</c>
            		<c>0x800207</c>
            		<c>[0].0.7</c>
            		<c># Macros Run</c>
            		<c>INT</c>
            		
            		<c>DefinedCtrls</c>
            		<c>0x800208</c>
            		<c>[0].0.8</c>
            		<c># Controls Defined</c>
            		<c>INT</c>

            		<c>RunCtrls</c>
            		<c>0x800209</c>
            		<c>[0].0.9</c>
            		<c># Controls Defined</c>
            		<c>INT</c>
            		            		            		            		
		         </texttable>
			</section>
			
			<section title="Computed Data">
				<t>
					The DTNMP Agent ADM does not define any computed data items.
				</t>
			</section>
			
			<section title="Reports">
		         <texttable anchor="agent_adm_reports" title="DTNMP Agent Reports" suppress-title="false" align="center" style="full">
            		<ttcol align="center" width="20%">Name</ttcol>
            		<ttcol align="center" width="10%">MID</ttcol>
            		<ttcol align="center" width="10%">OID</ttcol>            		
            		<ttcol align="center" width="60%">Description</ttcol>
            		<ttcol align="center" width="60%">Type</ttcol>
            		
            		
            		<c>FullReport</c>
            		<c>0x880220</c>
            		<c>[0].2.0</c>
            		<c>Report of all atomic data items</c>
            		<c>DC</c>
		         </texttable>
			</section>
		</section>
    	
		<section title="Operators">
			<t>
				This section describes the standard set of operators available to all DTNMP agents. Applications and 
				protocols do not need to redefine these operators, as they may be used in any expressions evaluated
				by any agent. 
			</t>
			
			<texttable anchor="agent_adm_op" title="DTNMP Agent Atomic Data" suppress-title="false" align="center" style="full">
           		<ttcol align="center" width="20%">Name</ttcol>
           		<ttcol align="center" width="10%">MID</ttcol>
           		<ttcol align="center" width="10%">OID</ttcol>            		
           		<ttcol align="center" width="60%">Description</ttcol>           		
            		
           		<c>+</c>
           		<c>0x830260</c>
           		<c>[0].6.0</c>
           		<c>Addition</c>

           		<c>-</c>
           		<c>0x830261</c>
           		<c>[0].6.1</c>
           		<c>Subtraction</c>
           		           		
           		<c>*</c>
           		<c>0x830262</c>
           		<c>[0].6.2</c>
           		<c>Multiplication</c>
           		
           		<c>/</c>
           		<c>0x830263</c>
           		<c>[0].6.3</c>
           		<c>Division</c>
           		
           		<c>%</c>
           		<c>0x830264</c>
           		<c>[0].6.4</c>
           		<c>Modulo</c>
           		         
           		<c>^</c>
           		<c>0x830265</c>
           		<c>[0].6.5</c>
           		<c>Exponentiation</c>
           		  		
           		<c>&amp;</c>
           		<c>0x830266</c>
           		<c>[0].6.6</c>
           		<c>Bitwise AND</c>
           		
           		<c>|</c>
           		<c>0x830267</c>
           		<c>[0].6.7</c>
           		<c>Bitwise OR</c>
           		
           		<c>#</c>
           		<c>0x830268</c>
           		<c>[0].6.8</c>
           		<c>Bitwise XOR</c>
           		
           		<c>~</c>
           		<c>0x830269</c>
           		<c>[0].6.9</c>
           		<c>Bitwise NOT</c>
           		
           		<c>&amp;&amp;</c>
           		<c>0x83026A</c>
           		<c>[0].6.A</c>
           		<c>Logical AND</c>
           		
           		<c>||</c>
           		<c>0x83026B</c>
           		<c>[0].6.B</c>
           		<c>Logical OR</c>
           		
           		<c>##</c>
           		<c>0x83026C</c>
           		<c>[0].6.C</c>
           		<c>Logical XOR</c>
           		
           		<c>!</c>
           		<c>0x83026D</c>
           		<c>[0].6.D</c>
           		<c>Logical NOT</c>
           		
           		<c>abs</c>
           		<c>0x83026E</c>
           		<c>[0].6.E</c>
           		<c>Absolute Value</c>
           		
           		<c>&lt;</c>
           		<c>0x83026F</c>
           		<c>[0].6.F</c>
           		<c>Less than</c>
           		
           		<c>&gt;</c>
           		<c>0x8303610</c>
           		<c>[0].6.10</c>
           		<c>Greater than</c>
           		
           		<c>&lt;=</c>
           		<c>0x8303611</c>
           		<c>[0].6.11</c>
           		<c>Less than or equal to</c>
           		
           		<c>&gt;=</c>
           		<c>0x8303612</c>
           		<c>[0].6.12</c>
           		<c>Greater than or equal to</c>
           		
           		<c>!=</c>
           		<c>0x8303613</c>
           		<c>[0].6.13</c>
           		<c>Not equal</c>
           		
           		<c>==</c>
           		<c>0x8303614</c>
           		<c>[0].6.14</c>
           		<c>Equal to</c>
           		          		
           	</texttable>
		</section>
		
		<section title="Controls">
			<t>
				This section describes the controls available for use on any DTNMP agent. Since this
				section essentially provides a functional specification for the DTNMP agent, it is presented
				in two sections. First, a summary section provides a quick reference for the controls 
				available on a DTNMP agent. Second, a full control specification provides detailed information
				on each individual DTNMP agent control. 
			</t>
			
			<section title="Control Summary">
				<texttable anchor="agent_adm_ctrls" title="DTNMP Agent Controls Summary" suppress-title="false" align="center" style="full">
				<ttcol align="center" width="20%">Name</ttcol>
            	<ttcol align="center" width="10%">MID</ttcol>
            	<ttcol align="center" width="10%">OID</ttcol>            		
            	<ttcol align="center" width="50%">Description</ttcol>
            	            
	            <c>ListADMs</c>
            	<c>0x810230</c>
            	<c>[0].3.0</c>
            	<c>List all ADMs known to the agent.</c>
            	
	            <c>ListAtomicIDs</c>
            	<c>0x810231</c>
            	<c>[0].3.1</c>
            	<c>List all Atomic MIDs known to the agent.</c>
            	  
	            <c>DescAtomicData</c>
            	<c>0xC10232</c>
            	<c>[0].3.2</c>
            	<c>Dump information for given Atomic MIDs.</c>

            	<c>AddCompData</c>
            	<c>0xC10233</c>
            	<c>[0].3.3</c>
            	<c>Define a computed data definition on the agent.</c>

            	<c>DelCompData</c>
            	<c>0xC10234</c>
            	<c>[0].3.4</c>
            	<c>Remove a computed data definition from the agent.</c>
            	
            	<c>ListCompData</c>
            	<c>0x810235</c>
            	<c>[0].3.5</c>
            	<c>List known computed data MIDs.</c>
            	            	            	       
            	<c>DescCompData</c>
            	<c>0xC10236</c>
            	<c>[0].3.6</c>
            	<c>Dump information for given computed data MIDs.</c>
            	            	   	
            	<c>AddRptDef</c>
            	<c>0xC10237</c>
            	<c>[0].3.7</c>
            	<c>Define a custom report.</c>

            	<c>DelRptDef</c>
            	<c>0xC10238</c>
            	<c>[0].3.8</c>
            	<c>Forget a custom report.</c>
            	
            	<c>ListRpts</c>
            	<c>0x810239</c>
            	<c>[0].3.9</c>
            	<c>List known custom report MIDs.</c>
            	            	            	       
            	<c>DescRpts</c>
            	<c>0xC1023A</c>
            	<c>[0].3.A</c>
            	<c>Dump information for given custom report MIDs.</c>
            	            	
            	<c>ListOps</c>
            	<c>0x81023B</c>
            	<c>[0].3.B</c>
            	<c>List known operator IDs.</c>
            	            	            	       
            	<c>DescOps</c>
            	<c>0xC1023C</c>
            	<c>[0].3.C</c>
            	<c>Dump information for given operator MIDs.</c>
            	           	
                <c>ListCtrls</c>
            	<c>0x81023D</c>
            	<c>[0].3.D</c>
            	<c>List known custom control MIDs.</c>
            	            	            	       
            	<c>DescCtrls</c>
            	<c>0xC1023E</c>
            	<c>[0].3.E</c>
            	<c>Dump information for given controls MIDs.</c>
            	
            	<c>AddMacroDef</c>
            	<c>0xC1023F</c>
            	<c>[0].3.F</c>
            	<c>Define a custom macro.</c>

            	<c>DelMacroDef</c>
            	<c>0xC103310</c>
            	<c>[0].3.10</c>
            	<c>Forget a custom macro.</c>
            	
            	<c>ListMacros</c>
            	<c>0x8103311</c>
            	<c>[0].3.11</c>
            	<c>List known custom macro MIDs.</c>
            	            	            	       
            	<c>DescMacros</c>
            	<c>0xC103312</c>
            	<c>[0].3.12</c>
            	<c>Dump information for given custom macro MIDs.</c>

            	<c>AddTimeRule</c>
            	<c>0xC103313</c>
            	<c>[0].3.13</c>
            	<c>Define a time-based prod rule.</c>

            	<c>DelTimeRule</c>
            	<c>0xC103314</c>
            	<c>[0].3.14</c>
            	<c>Forget a time-based prod rule.</c>
            	
            	<c>ListTimeRules</c>
            	<c>0x8103315</c>
            	<c>[0].3.15</c>
            	<c>List known time-based rules.</c>
            	            	            	       
            	<c>DescTimeRules</c>
            	<c>0xC103316</c>
            	<c>[0].3.16</c>
            	<c>Dump information for given time-based rules.</c>
            	            	
            	<c>AddStateRule</c>
            	<c>0xC103317</c>
            	<c>[0].3.17</c>
            	<c>Define a state-based prod rule.</c>

            	<c>DelStateRule</c>
            	<c>0xC103318</c>
            	<c>[0].3.18</c>
            	<c>Forget a state-based prod rule.</c>
            	
            	<c>ListStateRules</c>
            	<c>0x8103319</c>
            	<c>[0].3.19</c>
            	<c>List known state-based rules.</c>
            	            	            	       
            	<c>DescStateRules</c>
            	<c>0xC10331A</c>
            	<c>[0].3.1A</c>
            	<c>Dump information for given state-based rules.</c>
            	            	
				</texttable>
			</section>
			
			<section title="Control Specification">
				
				<section title="ListADMs" toc="default">
          			<t> This control causes the agent to produce a report detailing the list of all ADMs
          				configured on the agent and available for use. 
          			</t>

          			<t> This control takes no parameters. </t>
          			
          			<t> This control causes a report to be generated with the following format.</t>          			
            		
                    <figure align="center" anchor="list_adm_fig" title="" suppress-title="false" alt="" width="" height="">
            		<preamble>ListADMs Report Format</preamble>
            		<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">+--------+------------+     +------------+
| # ADMs | ADM 1 Name | ... | ADM N Name |
| [SDNV] |    [STR]   |     |    [STR]   |
+--------+------------+     +------------+
                 	</artwork>
          			</figure>
          			
          			<t>
            			<list hangIndent="8" style="hanging">
              				<t hangText="# ADMs">
                				<vspace blankLines="0" /> The number of ADMs known to the agent.
                			</t>
              				<t hangText="ADM [x] Name">
                				<vspace blankLines="0" /> For each ADM, it's human readable name.
                			</t>
            			</list>
          			</t>
          			
          			
        		</section>
        
				<section title="ListAtomicIDs" toc="default">
          			<t> This control causes the agent to produce a list containing the MID of every
          				atomic data item understood by the agent. 
          			</t>

          			<t> This control takes no parameters. </t>
          			
          			<t> This control causes a report to be generated with the following format.</t>          			
            		
                    <figure align="center" anchor="list_atomic_fig" title="" suppress-title="false" alt="" width="" height="">
            		<preamble>ListAtomicIDs Report Format</preamble>
            		<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">+------------+
| Atomic IDs |
|    [MC]    |
+------------+
                 	</artwork>
          			</figure>
          			
          			<t>
            			<list hangIndent="8" style="hanging">
              				<t hangText="Atomic IDs">
                				<vspace blankLines="0" /> A MID Collection of the MIDs of each atomic data definition known to the agent.
                			</t>
            			</list>
          			</t>          			
        		</section>
        		                

				<section title="DescAtomicData" toc="default">
          			<t> This control causes the agent to produce a detailed description of the requested atomic data definitions.
          			</t>

          			<t> This control takes 1 parameter in the following format. </t>
                    <figure align="center" anchor="desc_atomic_data_fig" title="" suppress-title="false" alt="" width="" height="">
            		<preamble>DescAtomicData Parameters</preamble>
            		<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">+------------+
| Atomic IDs |
|    [MC]    |
+------------+
                 	</artwork>
          			</figure>
          			<t>
            			<list hangIndent="8" style="hanging">
              				<t hangText="Atomic IDs">
                				<vspace blankLines="0" /> The list of MIDs identifying the atomic IDs to be described.
                			</t>
            			</list>
          			</t>
          			          			
          			          			
          			<t> This control causes a report to be generated with the following format.</t>          			
            		
                    <figure align="center" anchor="desc_atomic_fig" title="" suppress-title="false" alt="" width="" height="">
            		<preamble>DescAtomicData Report Format</preamble>
            		<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">
+--------+----------+----------+    +----------+----------+
| # IDs  | ID1 Name | ID1 Type |... | IDn Name | IDn Type |
| [SDNV] |  [STR]   |  [SDNV]  |    |   [STR]  |  [SDNV]  |
+--------+----------+----------+    +----------+----------+
                 	</artwork>
          			</figure>
          			<t>
            			<list hangIndent="8" style="hanging">
              				<t hangText="# IDs">
                				<vspace blankLines="0" /> The number of atomic data descriptions returned.
                			</t>
              				<t hangText="ID[n] Name">
                				<vspace blankLines="0" /> The name of the nth returned atomic data item.
                			</t>
              				<t hangText="ID[n] Type">
                				<vspace blankLines="0" /> Type enumeration for the nth atomic data item.
                			</t>
            			</list>
          			</t>
          			
        		</section>
        		        		
        	        		
        		<section title="AddCompData" toc="default">
          			<t> This control configures a new computed data definition on the agent. A computed data item uses an expression to assign a data value.
          			</t>

          			<t> This control takes 3 parameters in the following format. </t>
                    <figure align="center" anchor="add_comp_data_parm_fig" title="" suppress-title="false" alt="" width="" height="">
            		<preamble>AddCompData Parameters</preamble>
            		<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">+--------+--------+--------+
| Def ID |  Def   |  Type  |
| [MID]  | [EXPR] | [SDNV] |
+--------+--------+--------+
                 	</artwork>
          			</figure>
          			<t>
            			<list hangIndent="8" style="hanging">
              				<t hangText="Def ID">
                				<vspace blankLines="0" /> The MID value identifying the new computed data definition.
                			</t>
              				<t hangText="Def">
                				<vspace blankLines="0" /> The expression used to calculate the value for the new computed data item.
                			</t>
              				<t hangText="Type">
                				<vspace blankLines="0" /> The data type for the resultant computed data value.
                			</t>
            			</list>
          			</t>
          			          			
          			
          			<t> This control causes no report to be produced.</t>          			
            		
        		</section>

        		
        		<section title="DelCompData" toc="default">
          			<t> This control removes a computed data definition from the agent.
          			</t>

          			<t> This control takes 1 parameter in the following format. </t>
                    <figure align="center" anchor="del_comp_data_parm_fig" title="" suppress-title="false" alt="" width="" height="">
            		<preamble>DelCompData Parameters</preamble>
            		<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">+---------------+
| IDs To Remove |
|      [MC]     |
+---------------+
                 	</artwork>
          			</figure>
                    <t>
            			<list hangIndent="8" style="hanging">
              				<t hangText="IDs To Remove">
                				<vspace blankLines="0" /> The list of computed data items to be removed from the agent.
                			</t>
            			</list>
          			</t>
          			  			          			
          			          			
          			<t> This control causes no report to be produced.</t>          			
            		
        		</section>
        		        		        			            	  
        		
        		<section title="ListCompData" toc="default">
          			<t> This control causes the agent to produce a list containing the MID of every
          				computed data definition understood by the agent. 
          			</t>

          			<t> This control takes no parameters. </t>
          			
          			<t> This control causes a report to be generated with the following format.</t>          			
            		
                    <figure align="center" anchor="list_cust_fig" title="" suppress-title="false" alt="" width="" height="">
            		<preamble>ListCompData Report Format</preamble>
            		<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">+------------+
| Custom IDs |
|    [MC]    |
+------------+
                 	</artwork>
          			</figure>
                    <t>
            			<list hangIndent="8" style="hanging">
              				<t hangText="Custom IDs">
                				<vspace blankLines="0" /> The collection of identifiers for those computed data definitions known to the agent.
                			</t>
            			</list>
          			</t>
          						
        		</section>
        		        		

				<section title="DescCompData" toc="default">
          			<t> This control causes the agent to produce a detailed description of the requested computed data definitions.
          			</t>

          			<t> This control takes 1 parameter in the following format. </t>
                    <figure align="center" anchor="desc_comp_data_parm_fig" title="" suppress-title="false" alt="" width="" height="">
            		<preamble>DescCompData Parameters</preamble>
            		<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">+----------+
| Comp IDs |
|   [MC]   |
+----------+
                 	</artwork>
          			</figure>
          			<t>
            			<list hangIndent="8" style="hanging">
              				<t hangText="Comp IDs">
                				<vspace blankLines="0" /> The MID collection identifying the computed data items to be described.
                			</t>
            			</list>
          			</t>          			
          			          			
          			<t> This control causes a report to be generated with the following format.</t>          			
            		
                    <figure align="center" anchor="desc_comp_data_fig" title="" suppress-title="false" alt="" width="" height="">
            		<preamble>DescCompData Report Format</preamble>
            		<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">+------+-------+--------+---------+    +-------+--------+--------+
|# IDs | C1 ID | C1 Def | C1 Type |... | Cn ID | Cn Def | Cn Type|
|[SDNV]| [MID] | [EXPR] | [SDNV]  |    | [MID] | [EXPR] | [SDNV] |
+------+-------+--------+---------+    +-------+--------+--------+
                 	</artwork>
          			</figure>
          			<t>
            			<list hangIndent="8" style="hanging">
              				<t hangText="# IDs">
                				<vspace blankLines="0" /> The number of computed data definitions in the report.
                			</t>
              				<t hangText="C[n] ID">
                				<vspace blankLines="0" /> The MID of the nth computed data definition.
                			</t>
              				<t hangText="C[n] Def">
                				<vspace blankLines="0" /> The expression used to calculate the value of the Nth computed data item.
                			</t>
              				<t hangText="C[n] Type">
                				<vspace blankLines="0" /> The data type of the value of the Nth computed data item.
                			</t>
                		</list>
          			</t>
        		</section>
        		        		
        	   
        		<section title="AddRptDef" toc="default">
          			<t> This control configures a new custom report definition on the agent. A custom 
          				report assigns a single MID value to represent an ordered collection of other 
          				MID values, with some administrative information that identifies what other 
          				nodes in the network may request and process this report.
          			</t>

          			<t> This control takes 2 parameters in the following format. </t>
                    <figure align="center" anchor="add_rpt_fig" title="" suppress-title="false" alt="" width="" height="">
            		<preamble>AddRptDef Parameters</preamble>
            		<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">+--------+------------+
| RPT ID | Definition |
| [MID]  |    [MC]    |
+--------+------------+
                 	</artwork>
          			</figure>
          			<t>
            			<list hangIndent="8" style="hanging">
              				<t hangText="Rpt ID">
                				<vspace blankLines="0" /> The MID for the new report.
                			</t>
              				<t hangText="Definition">
                				<vspace blankLines="0" /> The ordered set of MIDs representing the contents of the report.
                			</t>
                		</list>
          			</t>          			
          			          			
          			<t> This control causes no report to be produced.</t>          			
            		
        		</section>

        		
        		<section title="DelRptDef" toc="default">
          			<t> This control removes a custom report definition from the agent.
          			</t>

          			<t> This control takes 1 parameters in the following format. </t>
                    <figure align="center" anchor="del_rpt_fig" title="" suppress-title="false" alt="" width="" height="">
            		<preamble>DelRptDef Parameters</preamble>
            		<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">
+---------------+
| IDs To Remove |
|      [MC]     |
+---------------+
                 	</artwork>
          			</figure>
          			<t>
            			<list hangIndent="8" style="hanging">
              				<t hangText="IDs to Remove">
                				<vspace blankLines="0" /> The collection of MIDs identifying the report definitions to remove from the agent.
                			</t>
                		</list>
          			</t>          			
          			          			
          			<t> This control causes no report to be produced.</t>          			
            		
        		</section>
        		        		        			            	  
        		
        		<section title="ListRpts" toc="default">
          			<t> This control causes the agent to produce a list containing the MID of every
          				report definition understood by the agent. 
          			</t>

          			<t> This control takes no parameters. </t>
          			
          			<t> This control causes a report to be generated with the following format.</t>          			
            		
                    <figure align="center" anchor="list_rpt_fig" title="" suppress-title="false" alt="" width="" height="">
            		<preamble>ListRpts Report Format</preamble>
            		<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">+---------+
| Reports |
|   [MC]  |
+---------+
                 	</artwork>
          			</figure>
          			<t>
            			<list hangIndent="8" style="hanging">
              				<t hangText="Reports">
                				<vspace blankLines="0" /> The collection of MIDs representing custom report IDs known to the agent.
                			</t>
                		</list>
          			</t>
        		</section>
        		        		

				<section title="DescRpts" toc="default">
          			<t> This control causes the agent to produce a detailed description of the requested report definitions.
          			</t>

          			<t> This control takes 1 parameter in the following format. </t>
                    <figure align="center" anchor="desc_rpt_parm_fig" title="" suppress-title="false" alt="" width="" height="">
            		<preamble>DescRpts Parameters</preamble>
            		<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">+------------+
| Report IDs |
|    [MC]    |
+------------+
                 	</artwork>
          			</figure>
          			<t>
            			<list hangIndent="8" style="hanging">
              				<t hangText="Report IDs">
                				<vspace blankLines="0" /> The collection of MIDs identifying the report definitions to be described.
                			</t>
                		</list>
          			</t>          			
          			          			
          			<t> This control causes a report to be generated with the following format.</t>          			
            		
                    <figure align="center" anchor="desc_rpt_fig" title="" suppress-title="false" alt="" width="" height="">
            		<preamble>DescRpts Report Format</preamble>
            		<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">+--------+----------+-----------+     +----------+-----------+
| # IDs  | RPT 1 ID | RPT 1 Def | ... | RPT N ID | RPT N Def |
| [SDNV] | [MID]    |    [MC]   |     |   [MID]  |   [MC]    |
+--------+----------+-----------+     +----------+-----------+
                 	</artwork>
          			</figure>
          			<t>
            			<list hangIndent="8" style="hanging">
              				<t hangText="# IDs">
                				<vspace blankLines="0" /> The number of report definitions in this report.
                			</t>
              				<t hangText="RPT[n] ID">
                				<vspace blankLines="0" /> The MID of the nth report definition.
                			</t>
              				<t hangText="RPT[n] Def">
                				<vspace blankLines="0" /> The ordered collection of IDs comprising the Nth report definition.
                			</t>
                		</list>
          			</t>
        		</section>
        		
        		
        		<section title="ListOps" toc="default">
          			<t> This control causes the agent to produce a list containing the MID of every
          				operator understood by the agent. 
          			</t>

          			<t> This control takes no parameters. </t>
          			
          			<t> This control causes a report to be generated with the following format.</t>          			
            		
                    <figure align="center" anchor="list_ops_fig" title="" suppress-title="false" alt="" width="" height="">
            		<preamble>ListOps Report Format</preamble>
            		<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">+------+
| OPS  |
| [MC] |
+------+
                 	</artwork>
          			</figure>
          			<t>
            			<list hangIndent="8" style="hanging">
              				<t hangText="OPS">
                				<vspace blankLines="0" /> The collection of MIDs for every op known by the agent.
                			</t>
                		</list>
          			</t>
        		</section>
        		        		

				<section title="DescOps" toc="default">
          			<t> This control causes the agent to produce a detailed listing of the requested operator definitions.
          			</t>

          			<t> This control takes 1 parameter in the following format. </t>
                    <figure align="center" anchor="desc_op_parm_fig" title="" suppress-title="false" alt="" width="" height="">
            		<preamble>DescOps Parameters</preamble>
            		<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">+--------+
| OP IDs |
|  [MC]  |
+--------+
                 	</artwork>
          			</figure>
          			<t>
            			<list hangIndent="8" style="hanging">
              				<t hangText="OP IDs">
                				<vspace blankLines="0" /> The set of operators to be described.
                			</t>
                		</list>
          			</t>
          			          			
          			          			
          			<t> This control causes a report to be generated with the following format.</t>          			
            		
                    <figure align="center" anchor="desc_op_fig" title="" suppress-title="false" alt="" width="" height="">
            		<preamble>DescOps Report Format</preamble>
            		<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">
+--------+---------+-----------+     +---------+-----------+
| # OPs  | OP 1 ID | OP 1 Desc | ... | OP N ID | OP N Desc |
| [SDNV] | [MID]   |   [STR]   |     |  [MID]  |   [STR]   |
+--------+---------+-----------+     +---------+-----------+
                 	</artwork>
          			</figure>
          			<t>
            			<list hangIndent="8" style="hanging">
              				<t hangText="# OPs">
                				<vspace blankLines="0" /> The number of operator definitions in the report.
                			</t>
              				<t hangText="OP[n] ID">
                				<vspace blankLines="0" /> The MID of the nth operator definition.
                			</t>
              				<t hangText="OP[n] Def">
                				<vspace blankLines="0" /> The description of the nth operator.
                			</t>
                		</list>
          			</t>
        		</section>
        		            	            	

        		
        		<section title="ListCtrls" toc="default">
          			<t> This control causes the agent to produce a list containing the MID of every
          				control understood by the agent. 
          			</t>

          			<t> This control takes no parameters. </t>
          			
          			<t> This control causes a report to be generated with the following format.</t>          			
            		
                    <figure align="center" anchor="list_ctrls_fig" title="" suppress-title="false" alt="" width="" height="">
            		<preamble>ListCtrls Report Format</preamble>
            		<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">+-------+
| CTRLs |
| [MC]  |
+-------+
                 	</artwork>
          			</figure>
          			<t>
            			<list hangIndent="8" style="hanging">
              				<t hangText="CTRLs">
                				<vspace blankLines="0" /> The collection of MIDs of controls known to the agent.
                			</t>
                		</list>
          			</t>
        		</section>
        		        		

				<section title="DescCtrls" toc="default">
          			<t> This control causes the agent to produce a detailed listing of the requested control definitions.
          			</t>

          			<t> This control takes 1 parameter in the following format. </t>
                    <figure align="center" anchor="desc_ctrl_parm_fig" title="" suppress-title="false" alt="" width="" height="">
            		<preamble>DescCtrls Parameters</preamble>
            		<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">+----------+
| CTRL IDs |
|   [MC]   |
+----------+
                 	</artwork>
          			</figure>
          			<t>
            			<list hangIndent="8" style="hanging">
              				<t hangText="CTRL IDs">
                				<vspace blankLines="0" /> The set of controls to be described.
                			</t>
                		</list>
          			</t>          			
          			          			
          			<t> This control causes a report to be generated with the following format.</t>          			
            		
                    <figure align="center" anchor="desc_ctrl_fig" title="" suppress-title="false" alt="" width="" height="">
            		<preamble>DescCtrls Report Format</preamble>
            		<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">+---------+----------+------------+     +----------+------------+
| # CTRLs | CTRL1 ID | CTRL1 Desc | ... | CTRLN ID | CTRLN Desc |
| [SDNV]  |  [MID]   |    [STR]   |     |  [MID]   |   [STR]    |
+---------+----------+------------+     +----------+------------+
                 	</artwork>
          			</figure>
          			<t>
            			<list hangIndent="8" style="hanging">
              				<t hangText="# CTRLs">
                				<vspace blankLines="0" /> The number of control definitions in the report.
                			</t>
              				<t hangText="CTRL[n] ID">
                				<vspace blankLines="0" /> The MID of the nth control definition.
                			</t>
              				<t hangText="CTRL[n] Desc">
                				<vspace blankLines="0" /> The description of the Nth control definition, to include information on parameters.
                			</t>
                		</list>
          			</t>
        		</section>
        		            	                   		
        		        	        		
        		<section title="AddMacroDef" toc="default">
          			<t> This control configures a new custom macro definition on the agent. A macro is a 
          				series of controls that should be run in sequence.
          			</t>

          			<t> This control takes 3 parameters in the following format. </t>
                    <figure align="center" anchor="add_macro_def_parm_fig" title="" suppress-title="false" alt="" width="" height="">
            		<preamble>AddMacroDef Parameters</preamble>
            		<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">+------------+----------+------+
| Macro Name | Macro ID |  Def |
|    [STR]   |   [MID]  | [MC] |
+------------+----------+------+
                 	</artwork>
          			</figure>
          			<t>
            			<list hangIndent="8" style="hanging">
              				<t hangText="Macro Name">
                				<vspace blankLines="0" /> The descriptive name for the macro.
                			</t>
              				<t hangText="Macro ID">
                				<vspace blankLines="0" /> The MID value identifying the new macro.
                			</t>
              				<t hangText="Def">
                				<vspace blankLines="0" /> The ordered set of controls/macros that are run sequentially during macro execution.
                			</t>
                		</list>
          			</t>          			
          			          		
          				
          			<t> This control causes no report to be produced.</t>          			
            		
        		</section>

        		
        		<section title="DelMacroDef" toc="default">
          			<t> This control removes a custom macro definition from the agent.
          			</t>

          			<t> This control takes 1 parameters in the following format. </t>
                    <figure align="center" anchor="del_macro_def_parm_fig" title="" suppress-title="false" alt="" width="" height="">
            		<preamble>DelMacroDef Parameters</preamble>
            		<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">
+---------------+
| IDs To Remove |
|      [MC]     |
+---------------+
                 	</artwork>
          			</figure>
          			<t>
            			<list hangIndent="8" style="hanging">
              				<t hangText="IDs To Remove">
                				<vspace blankLines="0" /> The collection of MIDs identifying the macros to be removed from the agent.
                			</t>
                		</list>
          			</t>          			
          			          			
          			<t> This control causes no report to be produced.</t>          			
            		
        		</section>
        		        		        			            	  
        		
        		<section title="ListMacros" toc="default">
          			<t> This control causes the agent to produce a list containing the MID of every
          				custom macro definition understood by the agent. 
          			</t>

          			<t> This control takes no parameters. </t>
          			
          			<t> This control causes a report to be generated with the following format.</t>          			
            		
                    <figure align="center" anchor="list_macro_fig" title="" suppress-title="false" alt="" width="" height="">
            		<preamble>ListMacros Report Format</preamble>
            		<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">+-----------+
| Macro IDs |
|    [MC]   |
+-----------+
                 	</artwork>
          			</figure>
          			
          			<t>
            			<list hangIndent="8" style="hanging">
              				<t hangText="Macro IDs">
                				<vspace blankLines="0" /> The list of macro definitions known to the agent.
                			</t>
                		</list>
          			</t>
          			
        		</section>
        		        		

				<section title="DescMacros" toc="default">
          			<t> This control causes the agent to produce a detailed listing of the requested macro definitions.
          			</t>

          			<t> This control takes 1 parameter in the following format. </t>
                    <figure align="center" anchor="desc_macro_parm_fig" title="" suppress-title="false" alt="" width="" height="">
            		<preamble>DescMacros Parameters</preamble>
            		<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">+-----------+
| Macro IDs |
|    [MC]   |
+-----------+
                 	</artwork>
          			</figure>
          			<t>
            			<list hangIndent="8" style="hanging">
              				<t hangText="Macro IDs">
                				<vspace blankLines="0" /> The collection of MIDs identifying the macros to be described.
                			</t>
                		</list>
          			</t>          			
          			          			
          			<t> This control causes a report to be generated with the following format.</t>          			
            		
                    <figure align="center" anchor="desc_macro_fig" title="" suppress-title="false" alt="" width="" height="">
            		<preamble>DescMacros Report Format</preamble>
            		<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">
+--------+-------+-----+------+     +-------+-----+------+
|# Macros|M1 Name|M1 ID|M1 Def| ... |Mn Name|Mn ID|Mn Def|
| [SDNV] | [STR] |[MID]| [MC] |     | [STR] |[MID]| [MC] |
+--------+-------+-----+------+     +-------+-----+------+
                 	</artwork>
          			</figure>
          			
          			<t>
            			<list hangIndent="8" style="hanging">
              				<t hangText="# Macros">
                				<vspace blankLines="0" /> The number of macro definitions in the report.
                			</t>
               				<t hangText="M[n] Name">
                				<vspace blankLines="0" /> The name of the nth macro definition.
                			</t>             			
              				<t hangText="M[n] ID">
                				<vspace blankLines="0" /> The MID of the nth macro definition.
v                			</t>
              				<t hangText="M[n] Def">
                				<vspace blankLines="0" /> The expression used to calculate the value of the Nth computed data item.
                			</t>
                		</list>
          			</t>
        		</section>

        		          		      	        		
        		<section title="AddTimeRule" toc="default">
          			<t> This control configures a new time-based production rule on the agent.
          				A time-based production rule instructs the agent to produce a report comprising
          				a fixed set of component values periodically over time. The component values may 
          				represent any type of data value, including atomic data, computed data, or reports.
          			</t>

          			<t> This control takes 4 parameters in the following format. </t>
          			<figure align="center" anchor="add_time_rule_parm" title="" suppress-title="false" alt="" width="" height="">
            		<preamble>AddTimeRule Parameters</preamble>
            <artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">+--------+------------+--------+---------+
| Start  | Period (s) | Count  | Results |
| [TS]   | [SDNV]     | [SDNV] |  [MC]  |
+--------+------------+--------+---------+          </artwork>
          			</figure>
          			<t>
            			<list hangIndent="8" style="hanging">
              				<t hangText="Start">
                				<vspace blankLines="0" /> The time at which the production should commence.
                			</t>
              				<t hangText="Period">
                				<vspace blankLines="0" /> The number of seconds to wait between report message generation.
                			</t>
              				<t hangText="Count">
                				<vspace blankLines="0" /> The number of reports to be generated 
                				by this configuration. The special value of 0 indicates 
                				production should continue indefinitely.
                			</t>
              				<t hangText="Results">
                				<vspace blankLines="0" /> The collection of MIDs to be included in the report.
                			</t>
            			</list>
          			</t>
          			                              			
          			          			
          			<t> No report is produced in response to this individual command. THe configured reports
          				will be produced in accordance to the configured time period. </t>          			
            		
        		</section>

        		       		
        		<section title="DelTimeRule" toc="default">
          			<t> This control removes a time-based production rule from the agent.
          			</t>

          			<t> This control takes 1 parameters in the following format. </t>
                    <figure align="center" anchor="del_time_rule_parm" title="" suppress-title="false" alt="" width="" height="">
            		<preamble>DelTimeRule Parameters</preamble>
            		<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">+----------+
| Rule IDs |
|   [MC]   |
+----------+
                 	</artwork>
          			</figure>
          			<t>
            			<list hangIndent="8" style="hanging">
              				<t hangText="Rule IDs">
                				<vspace blankLines="0" /> The collection of MIDs identifying the rules to be removed from the agent.
                			</t>
                		</list>
          			</t>
          			          			          			
          			          			
          			<t> This control causes no report to be produced.</t>          			
            		
        		</section>
        		        		        			            	  
        		
        		<section title="ListTimeRules" toc="default">
          			<t> This control causes the agent to produce a list containing the MID of every
          				time-based production rule understood by the agent. 
          			</t>

          			<t> This control takes no parameters. </t>
          			
          			<t> This control causes a report to be generated with the following format.</t>          			
            		
                    <figure align="center" anchor="list_time_rules_fig" title="" suppress-title="false" alt="" width="" height="">
            		<preamble>ListTimeRules Report Format</preamble>
            		<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">+----------+
| Rule IDs |
|   [MC]   |
+----------+
                 	</artwork>
          			</figure>
          			<t>
            			<list hangIndent="8" style="hanging">
              				<t hangText="Rule IDs">
                				<vspace blankLines="0" /> The collection of MIDs identifying the time-based rules known to the agent.
                			</t>
                		</list>
          			</t>
          			
        		</section>
        		        		

				<section title="DescTimeRules" toc="default">
          			<t> This control causes the agent to produce a detailed listing of the requested time-based production rules.
          			</t>

          			<t> This control takes 1 parameter in the following format. </t>
                    <figure align="center" anchor="desc_time_rule_parm_fig" title="" suppress-title="false" alt="" width="" height="">
            		<preamble>DescTimeRules Parameters</preamble>
            		<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">+----------+
| Rule IDs |
|   [MC]   |
+----------+
                 	</artwork>
          			</figure>
          			<t>
            			<list hangIndent="8" style="hanging">
              				<t hangText="Rule IDs">
                				<vspace blankLines="0" /> The collection of MIDs identifying the time-based rules to be described.
                			</t>
                		</list>
          			</t>
          			
          			          			          			          			
          			<t> This control causes a report to be generated with the following format.</t>          			
            		
                    <figure align="center" anchor="desc_time_rule_fig" title="" suppress-title="false" alt="" width="" height="">
            		<preamble>DescTimeRules Report Format</preamble>
            		<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">
+--------+-------+----------+-----------+----------+-----------+     
|# Rules | R1 ID | R1 START | R1 PERIOD | R1 Count | R1 Result | ... 
| [SDNV] | [MID] |   [TS]   |   [SDNV]  | [SDNV]   |    [MC]   |     
+--------+-------+----------+-----------+----------+-----------+ 
                 	</artwork>
          			</figure>
          			<t>
            			<list hangIndent="8" style="hanging">
              				<t hangText="# Rules">
                				<vspace blankLines="0" /> The number of time-based rule definitions in the report.
                			</t>
               				<t hangText="R[n] ID">
                				<vspace blankLines="0" /> The MID identifier for the nth time-based rule definition.
                			</t>             			
              				<t hangText="R[n] Start">
                				<vspace blankLines="0" /> The time at which the nth time-based rule production should commence.
                			</t>
              				<t hangText="R[n] Period">
                				<vspace blankLines="0" /> The number of seconds to wait between running the nth time-based rule.
                			</t>
              				<t hangText="R[n] Count">
                				<vspace blankLines="0" /> The number of reports to be generated 
                				by the nth time-based report. The special value of 0 indicates 
                				production should continue indefinitely.
                			</t>
              				<t hangText="R[n] Results">
                				<vspace blankLines="0" /> The collection of MIDs to be included in the report generated by the nth time-based rule.
                			</t>
                		</list>
          			</t>
          			
        		</section>
        		        		        		        		

        		        		          
        		        		      	        		
        		<section title="AddStateRule" toc="default">
          			<t> This control configures a new state-based production rule on the agent.
          				A state-based production rule instructs the agent to produce a report comprising
          				a fixed set of component values periodically whenever the expression evaluates to true. 
          				The component values may represent any type of data value, including atomic data, 
          				computed data, or reports.
          			</t>

          			<t> This control takes 4 parameters in the following format. </t>
          			<figure align="center" anchor="add_state_rule_parm" title="" suppress-title="false" alt="" width="" height="">
            		<preamble>AddStateRule Parameters</preamble>
            <artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">+--------+--------+--------+---------+
| Start  | State  | Count  | Results |
| [TS]   | [PRED] | [SDNV] |  [MC]   |
+--------+--------+--------+---------+          </artwork>
          			</figure>
          			<t>
            			<list hangIndent="8" style="hanging">
              				<t hangText="Start">
                				<vspace blankLines="0" /> The time at which the production should commence.
                			</t>
              				<t hangText="State">
                				<vspace blankLines="0" /> The expression which, when non-zero, causes the report to be generated.
                			</t>
              				<t hangText="Count">
                				<vspace blankLines="0" /> The number of reports to be generated 
                				by this configuration. The special value of 0 indicates 
                				production should continue indefinitely.
                			</t>
              				<t hangText="Results">
                				<vspace blankLines="0" /> The collection of MIDs to be included in the report.
                			</t>
            			</list>
          			</t>
          			                              			
          			          			
          			<t> No report is produced in response to this individual command. </t>          			
            		
        		</section>

        		       		
        		<section title="DelStateRule" toc="default">
          			<t> This control removes a state-based production rule from the agent.
          			</t>

          			<t> This control takes 1 parameters in the following format. </t>
                    <figure align="center" anchor="del_state_rule_parm" title="" suppress-title="false" alt="" width="" height="">
            		<preamble>DelStateRule Parameters</preamble>
            		<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">+----------+
| Rule IDs |
|   [MC]   |
+----------+
                 	</artwork>
          			</figure>
          			<t>
            			<list hangIndent="8" style="hanging">
              				<t hangText="Rule IDs">
                				<vspace blankLines="0" /> The collection of MIDs identifying the rules to be removed from the agent.
                			</t>
                		</list>
          			</t>
          			          			          			
          			          			
          			<t> This control causes no report to be produced.</t>          			
            		
        		</section>
        		        		        			            	  
        		
        		<section title="ListStateRules" toc="default">
          			<t> This control causes the agent to produce a list containing the MID of every
          				state-based production rule understood by the agent. 
          			</t>

          			<t> This control takes no parameters. </t>
          			
          			<t> This control causes a report to be generated with the following format.</t>          			
            		
                    <figure align="center" anchor="list_state_rules_fig" title="" suppress-title="false" alt="" width="" height="">
            		<preamble>ListStateRules Report Format</preamble>
            		<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">+----------+
| Rule IDs |
|   [MC]   |
+----------+
                 	</artwork>
          			</figure>
          			<t>
            			<list hangIndent="8" style="hanging">
              				<t hangText="Rule IDs">
                				<vspace blankLines="0" /> The collection of MIDs identifying the state-based rules known to the agent.
                			</t>
                		</list>
          			</t>
          			
        		</section>
        		        		

				<section title="DescStateRules" toc="default">
          			<t> This control causes the agent to produce a detailed listing of the requested state-based production rules.
          			</t>

          			<t> This control takes 1 parameter in the following format. </t>
                    <figure align="center" anchor="desc_state_rule_parm_fig" title="" suppress-title="false" alt="" width="" height="">
            		<preamble>DescStateRules Parameters</preamble>
            		<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">+----------+
| Rule IDs |
|   [MC]   |
+----------+
                 	</artwork>
          			</figure>
          			<t>
            			<list hangIndent="8" style="hanging">
              				<t hangText="Rule IDs">
                				<vspace blankLines="0" /> The collection of MIDs identifying the state-based rules to be described.
                			</t>
                		</list>
          			</t>
          			
          			          			          			          			
          			<t> This control causes a report to be generated with the following format.</t>          			
            		
                    <figure align="center" anchor="desc_state_rule_fig" title="" suppress-title="false" alt="" width="" height="">
            		<preamble>DescStateRules Report Format</preamble>
            		<artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">
+--------+-------+----------+-----------+----------+-----------+     
|# Rules | R1 ID | R1 START | R1 PERIOD | R1 Count | R1 Result | ... 
| [SDNV] | [MID] |   [TS]   |   [SDNV]  | [SDNV]   |    [MC]   |     
+--------+-------+----------+-----------+----------+-----------+ 
                 	</artwork>
          			</figure>
          			<t>
            			<list hangIndent="8" style="hanging">
              				<t hangText="# Rules">
                				<vspace blankLines="0" /> The number of state-based rule definitions in the report.
                			</t>
               				<t hangText="R[n] ID">
                				<vspace blankLines="0" /> The MID identifier for the nth state-based rule definition.
                			</t>             			
              				<t hangText="R[n] Start">
                				<vspace blankLines="0" /> The time at which the nth state-based rule production should commence.
                			</t>
              				<t hangText="R[n] Period">
                				<vspace blankLines="0" /> The number of seconds to wait between running the nth state-based rule.
                			</t>
              				<t hangText="R[n] Count">
                				<vspace blankLines="0" /> The number of reports to be generated 
                				by the nth state-based report. The special value of 0 indicates 
                				production should continue indefinitely.
                			</t>
              				<t hangText="R[n] Results">
                				<vspace blankLines="0" /> The collection of MIDs to be included in the report generated by the nth state-based rule.
                			</t>
                		</list>
          			</t>
          			
        		</section>
        		
        		            	            	
			</section>
		</section>
    </section>
    
    <section anchor="IANA" title="IANA Considerations" toc="default">
      <t>
		At this time, this protocol has no fields registered by IANA.
	  </t>
    </section>
    <section anchor="Security" title="Security Considerations" toc="default">
      <t>Transport security is handled by the transport layer, for example the
      <xref target="RFC6257" pageno="false" format="default">Bundle Security Protocol</xref> when using the
      <xref target="RFC5050" pageno="false" format="default">Bundle Protocol</xref>.</t>
      <t>Finer grain application security is done via ACLs which are defined
      via configuration messages and implementation specific.</t>
    </section>
  </middle>
  <!--  *****BACK MATTER ***** -->
  <back>
    <references title="Normative References">
      <reference anchor="RFC4838">
        <front>
          <title>Delay-Tolerant Networking Architecture</title>
          <author initials="V." surname="Cerf" fullname="V. Cerf">
            <organization />
          </author>
          <author initials="S." surname="Burleigh" fullname="S. Burleigh">
            <organization />
          </author>
          <author initials="A." surname="Hooke" fullname="A. Hooke">
            <organization />
          </author>
          <author initials="L." surname="Torgerson" fullname="L. Torgerson">
            <organization />
          </author>
          <author initials="R." surname="Durst" fullname="R. Durst">
            <organization />
          </author>
          <author initials="K." surname="Scott" fullname="K. Scott">
            <organization />
          </author>
          <author initials="K." surname="Fall" fullname="K. Fall">
            <organization />
          </author>
          <author initials="H." surname="Weiss" fullname="H. Weiss">
            <organization />
          </author>
          <date year="2007" month="April" />
          <abstract>
            <t>This document describes an architecture for delay-tolerant and disruption-tolerant networks, and is an evolution of the architecture originally designed for the Interplanetary Internet, a communication system envisioned to provide Internet-like services across interplanetary distances in support of deep space exploration.  This document describes an architecture that addresses a variety of problems with internetworks having operational and performance characteristics that make conventional (Internet-like) networking approaches either unworkable or impractical.  We define a message- oriented overlay that exists above the transport (or other) layers of the networks it interconnects.  The document presents a motivation for the architecture, an architectural overview, review of state management required for its operation, and a discussion of application design issues.  This document represents the consensus of the IRTF DTN research group and has been widely reviewed by that group.  This memo provides information for the Internet community.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="4838" />
        <format type="TXT" octets="89265" target="http://www.rfc-editor.org/rfc/rfc4838.txt" />
      </reference>
      <reference anchor="RFC6256">
        <front>
          <title>Using Self-Delimiting Numeric Values in Protocols</title>
          <author initials="W." surname="Eddy" fullname="W. Eddy">
            <organization />
          </author>
          <author initials="E." surname="Davies" fullname="E. Davies">
            <organization />
          </author>
          <date year="2011" month="May" />
          <abstract>
            <t>Self-Delimiting Numeric Values (SDNVs) have recently been introduced as a field type in proposed Delay-Tolerant Networking protocols.  SDNVs encode an arbitrary-length non-negative integer or arbitrary- length bitstring with minimum overhead.  They are intended to provide protocol flexibility without sacrificing economy and to assist in future-proofing protocols under development.  This document describes formats and algorithms for SDNV encoding and decoding, along with notes on implementation and usage.  This document is a product of the Delay-Tolerant Networking Research Group and has been reviewed by that group.  No objections to its publication as an RFC were raised.  This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="6256" />
        <format type="TXT" octets="40765" target="http://www.rfc-editor.org/rfc/rfc6256.txt" />
      </reference>
      <reference anchor="RFC2119">
        <front>
          <title abbrev="RFC Key Words">Key words for use in RFCs to Indicate Requirement Levels</title>
          <author initials="S." surname="Bradner" fullname="Scott Bradner">
            <organization>Harvard University</organization>
            <address>
              <postal>
                <street>1350 Mass. Ave.</street>
                <street>Cambridge</street>
                <street>MA 02138</street>
              </postal>
              <phone>- +1 617 495 3864</phone>
              <email>sob@harvard.edu</email>
            </address>
          </author>
          <date year="1997" month="March" />
          <area>General</area>
          <keyword>keyword</keyword>
          <abstract>
            <t>
   In many standards track documents several words are used to signify
   the requirements in the specification.  These words are often
   capitalized.  This document defines these words as they should be
   interpreted in IETF documents.  Authors who follow these guidelines
   should incorporate this phrase near the beginning of their document:

<list><t>
      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
      "OPTIONAL" in this document are to be interpreted as described in
      RFC 2119.
</t></list></t>
            <t>
   Note that the force of these words is modified by the requirement
   level of the document in which they are used.
</t>
          </abstract>
        </front>
        <seriesInfo name="BCP" value="14" />
        <seriesInfo name="RFC" value="2119" />
        <format type="TXT" octets="4723" target="http://www.rfc-editor.org/rfc/rfc2119.txt" />
        <format type="HTML" octets="17970" target="http://xml.resource.org/public/rfc/html/rfc2119.html" />
        <format type="XML" octets="5777" target="http://xml.resource.org/public/rfc/xml/rfc2119.xml" />
      </reference>
      <reference anchor="RFC5050">
        <front>
          <title>Bundle Protocol Specification</title>
          <author initials="K." surname="Scott" fullname="K. Scott">
            <organization />
          </author>
          <author initials="S." surname="Burleigh" fullname="S. Burleigh">
            <organization />
          </author>
          <date year="2007" month="November" />
          <abstract>
            <t>This document describes the end-to-end protocol, block formats, and abstract service description for the exchange of messages (bundles) in Delay Tolerant Networking (DTN).&lt;/t&gt;&lt;t&gt; This document was produced within the IRTF's Delay Tolerant Networking Research Group (DTNRG) and represents the consensus of all of the active contributors to this group. See http://www.dtnrg.org for more information. This memo defines an Experimental Protocol for the Internet community.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="5050" />
        <format type="TXT" octets="120435" target="http://www.rfc-editor.org/rfc/rfc5050.txt" />
      </reference>
      <reference anchor="RFC6257">
        <front>
          <title>Bundle Security Protocol Specification</title>
          <author initials="S." surname="Symington" fullname="S. Symington">
            <organization />
          </author>
          <author initials="S." surname="Farrell" fullname="S. Farrell">
            <organization />
          </author>
          <author initials="H." surname="Weiss" fullname="H. Weiss">
            <organization />
          </author>
          <author initials="P." surname="Lovell" fullname="P. Lovell">
            <organization />
          </author>
          <date year="2011" month="May" />
          <abstract>
            <t>This document defines the bundle security protocol, which provides data integrity and confidentiality services for the Bundle Protocol. Separate capabilities are provided to protect the bundle payload and additional data that may be included within the bundle. We also describe various security considerations including some policy options.&lt;/t&gt;&lt;t&gt; This document is a product of the Delay-Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. This document defines an Experimental Protocol for the Internet community.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="6257" />
        <format type="TXT" octets="142509" target="http://www.rfc-editor.org/rfc/rfc6257.txt" />
      </reference>
      <reference anchor="tolerance">
        <front>
          <title>Defining Tolerance: Impacts of Delay and Didruption when
          Managing Challenged Networks</title>
          <author initials="E.B." surname="Birrane">
            <organization />
          </author>
          <author initials="S.B." surname="Burleigh">
            <organization />
          </author>
          <author initials="V.C." surname="Cerf">
            <organization />
          </author>
          <date year="2001" />
        </front>
      </reference>
      <reference anchor="DTNM">
        <front>
          <title>DTN Network management: The Definition and Exchange of
          Infrastructure Information in High Delay Environments</title>
          <author initials="E.B." surname="Birrane">
            <organization />
          </author>
          <author initials="H.K." surname="Kruse">
            <organization />
          </author>
          <date month="" year="" />
        </front>
      </reference>
    </references>
    <!--
  <references title="Informative References">
    &RFC5050;
  </references>
  -->
  </back>
</rfc>