<?xml version='1.0' encoding='utf-8'?> encoding='UTF-8'?>

<!-- pre-edited by ST 04/30/24 -->

<!DOCTYPE rfc [
 <!ENTITY nbsp    "&#160;">
 <!ENTITY zwsp   "&#8203;">
 <!ENTITY nbhy   "&#8209;">
 <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<?rfc compact="no" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" ipr="trust200902" docName="draft-ietf-dtn-dtnma-14" number="9675" consensus="true" submissionType="IETF" xml:lang="en" obsoletes="" updates="" tocInclude="true" symRefs="true" sortRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.13.0 -->
  <!-- ***** 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="DTNMA">DTN abbrev="DTNMA">Delay-Tolerant Networking Management Architecture</title> Architecture (DTNMA)</title>

   <seriesInfo name="Internet-Draft" value="draft-ietf-dtn-dtnma-14"/> name="RFC" value="9675"/>
   <author fullname="Edward J. Birrane" initials="E.J." surname="Birrane">
      <organization>Johns Birrane, III" initials="E." surname="Birrane, III">
      <organization abbrev="JHU/APL">The Johns Hopkins University Applied Physics Laboratory</organization>
      <address>
        <email>Edward.Birrane@jhuapl.edu</email>
      </address>
   </author>

   <author fullname="Sarah E. Heiner" initials="S.E." initials="S." surname="Heiner">
      <organization>Johns
      <organization abbrev="JHU/APL">The Johns Hopkins University Applied Physics Laboratory</organization>
      <address>
        <email>Sarah.Heiner@jhuapl.edu</email>
      </address>
   </author>

   <author fullname="Emery Annis" initials="E." surname="Annis">
      <organization>Johns
      <organization abbrev="JHU/APL">The Johns Hopkins University Applied Physics Laboratory</organization>
      <address>
        <email>Emery.Annis@jhuapl.edu</email>
      </address>
   </author>

   <date/>

   <!-- Meta-data Declarations -->
   <area>General</area>
   <workgroup>Delay-Tolerant Networking</workgroup>

   <date month="October" year="2024"/>

   <area>INT</area>
   <workgroup>dtn</workgroup>

   <keyword>DTN</keyword>
   <keyword>Network Management</keyword>

   <abstract>
      <t>
        The Delay-Tolerant Networking (DTN) architecture describes a type of
        challenged network in which communications may be significantly
        affected by long signal propagation delays, frequent link disruptions,
        or both. The unique characteristics of this environment require a
        unique approach to network management that supports asynchronous
        transport, autonomous local control, and a small footprint (in both
        resources and dependencies) so as to deploy on constrained devices.
      </t>

      <t>
        This document describes a DTN management architecture Management Architecture (DTNMA) suitable
        for managing devices in any challenged environment but, in
        particular, those communicating using the DTN Bundle Protocol (BP).
        Operating over BP requires an architecture that neither presumes
        synchronized transport behavior nor relies on query-response mechanisms.
        Implementations compliant with this DTNMA should expect to successfully
        operate in extremely challenging conditions, such as over uni-directional unidirectional
        links and other places where BP is the preferred transport.
      </t>
   </abstract>
</front>

<middle>
   <section numbered="true">
      <name>Introduction</name>

      <t>
        This document describes a logical, informational DTN management
        architecture Delay-Tolerant Networking Management Architecture (DTNMA) suitable for operating devices in a
        challenged architecture - architecture, such as those communicating
        using the DTN Bundle Protocol version 7 (BPv7) <xref target="RFC9171"/>.
      </t>

      <t>
        Challenged networks have certain properties that differentiate them
        from other kinds of networks. These properties, outlined in
        Section 2.2.1 of
        <xref target="RFC7228"/>, target="RFC7228" sectionFormat="of" section="2.2.1"/>,
        include lacking
        end-to-end IP connectivity, having "serious interruptions"
        to end-to-end connectivity, and exhibiting delays longer than can be
        tolerated by end-to-end synchronization mechanisms (such as TCP).
      </t>

      <t>
        These challenged network properties can be caused by a variety of factors
        such as physical constraints (e.g., long signal propagation delays
        and frequent link disruptions), administrative policies (e.g.,
        quality-of-service prioritization, service-level agreements, and
        traffic management and scheduling), and off-nominal behaviors
        (e.g., active attackers and misconfigurations). Since these
        challenges are not solely caused by sparseness, instances of
        challenged networks will persist even in increasingly connected
        environments.
      </t>

      <t>
        The Delay-Tolerant Networking (DTN) DTN architecture, described in
        <xref target="RFC4838"/>, has been designed for data exchange
        in challenged networks. Just as the DTN architecture requires new
        capabilities for transport and transport security, special consideration
        is needed for the operation of devices in a challenged network.
      </t>

      <section numbered="true">
        <name>Purpose</name>
        <t>
          This document describes how challenged network properties
          affect the operation of devices in those such networks. This
          description is presented as a logical architecture
          formed from a union of best practices for operating
          devices deployed in challenged environments.
        </t>

        <t>
          One important practice captured in this document is the concept of self-operation.  Self-operation involves operating
          a device without human interactivity, without system-in-the-loop
          synchronous function, functions, and without a synchronous underlying
          transport layer. This means that devices determine
          their own schedules for data reporting, determine their own
          operational configuration, and perform their own error
          discovery and mitigation.
        </t>
      </section>

      <section numbered="true">
        <name>Scope</name>
        <t>
          This document includes the information necessary to document
          existing practices for operating devices in a challenged network in
          the context of a logical architecture. A logical architecture
          describes the logical operation of a system by identifying
          components of the system (such as in a reference model),
          the behaviors they enable, and use cases describing how
          those behaviors result in the desired operation of the system.
        </t>

        <t>
          Logical architectures are not functional architectures. Therefore,
          any functional design for achieving desired behaviors is out of
          scope for this document. The set of architectural principles presented here is not meant to completely specify interfaces between components.
        </t>

        <t>
          The selection of any particular transport or network layer is outside
          of the scope of this document. The DTNMA does not require the use of
          any specific protocol such as IP, BP, TCP, or UDP. In particular, the
          DTNMA design does not presume the use of BPv7, IPv4 IPv4, or IPv6.
        </t>

        <aside>
          <t>
            NOTE: As BPv7 is the preferred transport for networks conforming to the DTN architecture, the DTNMA should be considered for any BPv7 network deployment. However, the DTNMA may also be used in other networks that have similar needs for this particular style of self-operation. For this reason, the DTNMA does not require the use of BPv7 to transport management information.
          </t>
        </aside>

        <t>
          Network features such as naming, addressing, routing, and
          communications security are out of scope of for the DTNMA. It is
          presumed that any operational network communicating DTNMA
          messages would implement these services for any payloads carried
          by that network.
        </t>

       <t>
          The interactions between and amongst the DTNMA and other management
          approaches are outside of the scope of this document.
       </t>
      </section>

      <section numbered="true">
         <name>Organization</name>
         <t>
            The remainder of this document is organized into the following nine sections, described as follows. sections provide details regarding the DTNMA.

         </t>
         <dl>
            <dt>Terminology:</dt>
            <dd>
              This section
              <xref target="terms"/> identifies terms fundamental to
              understanding DTNMA concepts. Whenever possible, these terms
              align in both word selection and meaning with their use in
              other management protocols.
            </dd>
            <dt>Challenged Network Overview:</dt>
            <dd>
              This section
              <xref target="challenged-net-overview"/> describes important
              aspects of challenged networks and necessary approaches for their
              management.
            </dd>
            <dt>Desirable Design Properties:</dt>
            <dd>
              This section
              <xref target="desired-name-properties"/> defines those properties of the DTNMA needed to operate within the constraints
              of a challenged network. These properties are similar to the
              specification of system-level requirements of a DTN management
              solution.
            </dd>
            <dt>Current Remote Management Approaches:</dt>
            <dd>
              This section
              <xref target="current-remote-mgmt"/> provides a brief
              overview of existing remote management approaches. Where possible,
              the DTNMA adopts concepts from these approaches.
            </dd>
            <dt>Motivation for New Features:</dt>
            <dd>
              This section
              <xref target="motivation-for-new-features"/> provides an overall
              motivation for this work, to include explaining work. It also explains why a management
              architecture for challenged networks is useful and necessary.
            </dd>
            <dt>Reference Model:</dt>
            <dd>
              This section
              <xref target="reference-model"/> defines a reference model that can
              be used to reason about analyze the DTNMA independent independently of an
              implementation or implementation architecture.
              This model identifies the logical components of the system and
              the high-level relationships and behaviors amongst those
              components.
            </dd>
            <dt>Desired Services:</dt>
            <dd>
              This section
              <xref target="desired-services"/> identifies and defines the
              DTNMA services provided to network and mission operators.
            </dd>
            <dt>Logical Autonomy Model:</dt>
            <dd>
              This section
              <xref target="autonomy_model"/> provides an exemplar example data
              model that can be used to reason about analyze DTNMA control and data flows.
              This model is based on the DTNMA reference model.
            </dd>
            <dt>Use Cases:</dt>
            <dd>
              This section
              <xref target="use-cases"/> presents multiple use cases accommodated
              by the DTNMA architecture. DTNMA. Each use case is presented as a
              set of control and data flows referencing the DTNMA reference model
              and logical autonomy model.
           </dd>
          </dl>
      </section>
   </section>

   <section anchor="terms" numbered="true">
      <name>Terminology</name>

      <t>
        This section defines terminology that either is either unique to the DTNMA or
        is
        necessary for understanding the concepts defined in this specification.
      </t>

      <dl>
        <dt>Timely Data Exchange:</dt>
        <dd>
          The ability to communicate information between two (or more)
          entities within a required period of time. In some cases, a 1-second exchange may not
          be timely and timely; in other cases cases, a 1-hour exchange may be timely.
        </dd>

        <dt>Local Operation:</dt>
        <dd>
          The operation of a device by an application co-resident on that device.
          Local operators are applications running on a device, and there
          might be one or more of these applications working independently or as one
          to perform the local operations function. Absent error conditions, local
          operators are always expected to be available to the devices they manage.
        </dd>

        <dt>Remote Operation:</dt>
        <dd>
          The operation of a device by an application running on a separate
          device. Remote operators communicate with operated devices over a network.
          Remote operators are not always expected to be availabe available to the devices they
          operate.
        </dd>

        <dt>DTN Management:</dt>
        <dd>
          The management, monitoring, and control of a device that does not depend on stateful connections, timely data exchange of management messages,
          or system-in-the-loop synchronous functions. DTN management is accomplished as
          a fusion of local operation and remote operation techniques; remote operators manage the configuration of local operators who
          provide monitoring and control of their co-resident devices.
        </dd>

        <dt>DTNMA Agent (DA):</dt>
        <dd>
          A role associated with a managed device, device
          responsible for reporting performance data, accepting policy
          directives, performing autonomous local control, error-handling, error handling, and
          data validation. DAs exchange information with DMs DTNMA Managers (DMs) operating either
          on the same device and/or on remote devices in the network. A DA is
          a type of local operator.
        </dd>

        <dt>DTNMA Manager (DM):</dt>
        <dd>
          A role associated with a managing device
          responsible for configuring the behavior of, and eventually receiving
          information from, DAs. DMs interact with one or more DAs located on
          the same device and/or on remote devices in the network. A DM is a
          type of remote operator.
        </dd>

        <dt>Controls:</dt>
        <dd>
          Procedures run by a DA to change the behavior,
          configuration, or state of an application or protocol managed by
          that DA. This includes These include procedures to manage the DA itself, such as
          to have
          having the DA produce performance reports or to apply applying new
          management policies.
        </dd>

        <dt>Externally Defined Data (EDD):</dt>
        <dd>
          Typed information made available to a
          DA by its hosting device, device but not computed directly by the
          DA itself.
        </dd>

        <dt>Data Reports:</dt> Report:</dt>
        <dd>
          Typed,
          A typed, ordered collections collection of data values gathered
          by one or more DAs and provided to one or more DMs. Reports comply
          to
          with the format of a given Data Report Schema. data report schema.
        </dd>

        <dt>Data Report Schemas:</dt> Schema:</dt>
        <dd>
          Named,
          A named, ordered collection of data elements
          that represent the schema of a Data Report. data report.
        </dd>

        <dt>Rules:</dt>

        <dt>Rule:</dt>
        <dd>
          Unit of autonomous specification that provides a
          stimulus-response relationship between time or state on a DA
          and the actions or operations to be run as a result of that time or
          state.
        </dd>
      </dl>
   </section>

   <section anchor="challenged-net-overview" numbered="true">
      <name>Challenged Network Overview</name>

      <t>
        The DTNMA provides network management services able to operate in a
        challenged network environment, such as envisioned by environments for which the DTN
        architecture.
        architecture was created. This section describes what is meant by the term
        "challenged network", the important properties of such a network, and
        observations on impacts to management approaches.
      </t>

      <section>
        <name>Challenged Network Constraints</name>
<!-- DNE; verified -->
        <t>
          Constrained networks are defined as networks where "some of the
          characteristics pretty much taken for granted with link layers in
          common use in the Internet at the time of writing are not attainable." attainable"
          <xref target="RFC7228"/>. This broad definition captures a variety of
          potential issues relating to physical, technical, and regulatory
          constraints on message transmission. Constrained networks
          typically include nodes that regularly reboot or are otherwise turned
          off for long periods of time, transmit at low or asynchronous bitrates,
          and/or have very limited computational resources.
        </t>

<!-- DNE; verified -->
        <t>
          Separately, a challenged network is defined as one that "has serious
          trouble maintaining what an application would today expect of the
          end-to-end IP model" <xref target="RFC7228"/>. Links in such networks may
          be impacted by attenuation, propagation delays, mobility,
          occultation, and other limitations imposed by energy and
          mass considerations. Therefore, systems relying on such links cannot
          guarantee timely end-to-end data exchange.
        </t>

        <aside>
          <t>
            NOTE: Because challenged networks might not provide services expected of
            the end-to-end IP model, devices in such networks might not implement
            networking stacks associated with the end-to-end IP model. This
            means that devices might not include support for certain
            transport protocols (TCP/QUIC/UDP), web protocols (HTTP), or
            internetworking protocols (IPv4/IPv6).
          </t>
        </aside>

<!-- DNE; verified (changed the first "all" to "All" per RFC 7228) -->
        <t>
          By these definitions, a "challenged" network is a special type of
          "constrained" network, where constraints prevent timely end-to-end
          data exchange. As such, "all "All challenged networks are
          constrained networks ... but not all constrained networks are
          challenged networks ... Delay-Tolerant Networking (DTN) has been
          designed to cope with challenged networks" <xref target="RFC7228"/>.
        </t>

        <t>
          Solutions that work in constrained networks might not be solutions
          that work in challenged networks. In particular, challenged networks
          exhibit the following properties that impact the way in which the
          function of network management is considered.
        </t>

        <ul spacing="normal">
          <li>
            Timely end-to-end data exchange cannot be guaranteed to exist at any given time
            between any two nodes.
          </li>
          <li>
            Latencies on the order of seconds, hours, or days must be tolerated.
          </li>
          <li>
            Managed devices cannot be guaranteed to always be powered so as to receive ad-hoc ad hoc management requests (even requests with artificially extended timeout values).
          </li>
          <li>
            Individual links may be uni-directional. unidirectional.
          </li>
          <li>
            Bi-directional
            Bidirectional links may have asymmetric data rates.
          </li>
          <li>
            The existence of external infrastructure, services, systems,
            or processes such as a Domain Name Service System (DNS) or a Certificate
            Authority (CA) cannot be guaranteed.
          </li>
        </ul>
      </section>

      <section numbered="true">
        <name>Topology and Service Implications</name>

        <t>
          The set of constraints that might be present in a challenged network
          impact
          impacts both the topology of the network and the services active
          within that network.
        </t>

        <t>
          Operational networks handle cases where nodes join and leave the
          network over time. These topology changes may or may not be planned, they
          may or may not represent errors, and they may or may not impact network
          services. Challenged networks differ from other networks not in
          the presence of topological change, change but in the likelihood that impacts
          to topology result in impacts to network services.
        </t>

        <t>
          The difference between topology impacts and service impacts can be
          expressed in terms of connectivity. Topological connectivity usually
          refers to the existence of a path between an application message
          source and destination. Service connectivity, alternatively, refers
          to the existence of a path between a node and one or more services
          needed to process (often just-in-time) -- often just in time -- application messaging.
          Examples of service connectivity include access to infrastructure
          services such as a Domain Name System (DNS) or a Certificate
          Authority (CA). CA.
        </t>

        <t>
          In networks that might be partitioned most of the time, it is less
          likely that a node would concurrently access both an application
          endpoint and one or more network service endpoints. For this reason,
          network services in a challenged network should be designed to allow
          for asynchronous operation. Accommodating this use case often
          involves the use of local caching, pre-placing information, and
          not hard-coding message information at a source that might change when a
          message reaches its destination.
        </t>

        <aside>
          <t>
            NOTE: One example of rethinking services in a challenged network
            is the securing of BPv7 bundles. The BPSec Bundle Protocol Security (BPSec) <xref target="RFC9172"/> security extensions to BPv7
            do not encode security destinations when
            applying security. Instead, BPSec requires nodes in a network to
            identify themselves as security verifiers or acceptors when receiving
            and processing secured messages.
          </t>
        </aside>

        <section numbered="true">
          <name>Tiered Management</name>

          <t>
            Network operations and management approaches need to adapt to the
            topology and service impacts encountered in challenged networks.
            In particular, the roles and responsibilities of "managers" and
            "agents" need to be different than what would be expected of
            unchallenged networks.
          </t>

          <t>
            When connectivity to a manager cannot be guaranteed, agents will need to rely
            on locally available information and local autonomy to react to
            changes at the node. When an agent uses local autonomy for self-operation,
            it acts as a local operator serving as a proxy for an absent remote operator.
          </t>

          <t>
            Therefore, the role of a "manager" must become one of a remote operator generating configurations and other essential updates for
            the local operator "agents" that are co-resident on a managed device.
          </t>

          <t>
            This approach creates a two-tiered management architecture. The
            first tier is the management of the local operator configuration
            using any one of a variety of standard mechanisms, models, and
            protocols. The second tier is the operation of the local device
            through the local operator.
          </t>

          <t>
            The DTNMA defines the DTNMA Manager (DM) as a remote operator application and the
            DTNMA Agent (DA) as an agent acting as a local operator application.
            In this model, which is illustrated in <xref target="two_tiered_model"/>, the
            DM and DA can be viewed as applications applications, with the DM producing new configurations
            and the DA receiving those configurations from an underlying management mechanism.
          </t>

      <t keepWithNext="true">Two-Tiered Management Architecture</t>

      <figure anchor="two_tiered_model">
       <name>Two-Tiered Management Architecture</name>
        <artwork align="center" name="" type="" alt=""><![CDATA[
        _
       /
      / +------------+           +-----------+    Local    +---------+
TIER /  | DM (Remote |           | DA (Local |  Operation  | Managed |
 2   \  |  Operator) |           | Operator) | <---------> |   Apps  |
MGMT  \ +------------+           +-----------+             +---------+
       \_      ^                        ^
               | configs                | configs
        _      |                        |
       /       V                        V
      / +------------+    Remote    +------------+
TIER /  | Management |  Management  | Management |
 1   \  |   Client   | <----------> |   Server   |
MGMT  \ +------------+              +------------+
       \_
]]></artwork>
      </figure>

          <t>
            In this approach, the configurations produced by the DM are
            based on the DA features and associated data model.  How those
            configurations are transported between the DM and the DA, and
            how results are communicated back from the DA to the DM, can
            be accomplished using whatever mechanism is most appropriate
            for the network and the device platforms. For platforms -- for example, the
            use of a NETCONF,  Network Configuration Protocol (NETCONF), RESTCONF, or SNMP Simple Network Management Protocol (SNMP) server on the managed device
            to provide configurations to a DA.
          </t>

        </section>

        <section numbered="true">
          <name>Remote and Local Manager Associations</name>

          <t>
            In addition to disconnectivity, topological change can alter the
            associations amongst managed and managing devices. Different managing
            devices might be active in a network at different times or in
            different partitions. Managed devices might communicate with some, all,
            or none of these managing devices as a function of their own local
            configuration and policy.
          </t>

          <aside>
            <t>
              NOTE: These concepts relate to practices in conventional networks.
              For example, supporting multiple managing devices is similar to
              deploying multiple instances of a network service -- such as a DNS
              server or CA node. Selecting from a set of managing devices is
              similar to a sensor node node's practice of electing cluster heads to act
              as privileged nodes for data storage and exfiltration.
            </t>
          </aside>

          <t>
            Therefore, a network management architecture for challenged networks
            should:
          </t>

          <ol>
            <li>
              Support a many-to-many association amongst managing and managed
              devices, and
            </li>
            <li>
              Allow "control from" and "reporting to" managing devices to function
              independent
              independently of one another.
            </li>
          </ol>
        </section>
      </section>

      <section numbered="true">
        <name>Management Special Cases</name>

        <t>
          The following special cases illustrate some of the operational
          situations that can be encountered in the management of devices in
          a challenged network.
        </t>

        <dl>
          <dt>One-Way Management:</dt>
          <dd>
            A managed device can only be accessed via a
            uni-directional link,
            unidirectional link or a via a link whose duration is shorter
            than a single round-trip propagation time. Results of this management may come back at a different time, over a
            different path, and/or as observable from out-of-band changes to
            device behavior.
          </dd>

          <dt>Summary Data:</dt>
          <dd>
            A managing device might only receive summary data of regarding
            a managed device's state because a link or path is constrained by
            capacity or reliability.
          </dd>

          <dt>Bulk Historical Reporting:</dt>
          <dd>
            A managing device receives a large volume
            of historical report data for a managed device. This can occur when
            a managed device rejoins a network or has temporary access to a high
            capacity
            high-capacity link (or path) to between itself and the managed managing device.
          </dd>

          <dt>Multiple Managers</dt> Managers:</dt>
          <dd>
            A managed device tracks multiple managers in
            the network and communicates with them as a function of time,
            local state, or network topology. This includes scenario would also apply to challenged
            networks that interconnect two or more unchallenged networks such
            that managed and managing devices exist in different networks.
          </dd>
        </dl>
        <t>
          These special cases highlight the need for managed devices to operate
          without presupposing a dedicated connection to a single managing
          device. Managing devices in a challenged
          network might never expect a reply to a command, and communications from
          managed devices may be delivered much later than the events being reported.
        </t>

      </section>
    </section>

    <section>

    <section anchor="desired-name-properties">
      <name>Desirable Design Properties</name>

      <t>
        This section describes those design properties that are desirable when
        defining a management architecture operating across challenged
        links in a network. These properties ensure that network management
        capabilities are retained even as delays and disruptions in the
        network scale. Ultimately, these properties are the driving design
        principles for the DTNMA.
      </t>

      <aside>
        <t>
          NOTE: These properties may influence the design, construction, and
          adaptation of existing management tools for use in challenged
          networks. For example, the properties of the DTN architecture
          <xref target="RFC4838"/> resulted in the development of BPv7
          <xref target="RFC9171"/> and BPSec <xref target="RFC9172"/>. The
          Implementing the DTNMA model may result in the construction of new management data models,
          policy expressions, and/or protocols.
        </t>
      </aside>

      <section numbered="true">
        <name>Dynamic Architectures</name>
        <t>
          The DTNMA should be agnostic of to the underlying physical topology,
          transport protocols, security solutions, and supporting infrastructure
          of a given network. Due to the likelihood of operating in a frequently
          partitioned environment, the topology of a network may change
          over time. Attempts to stabilize an architecture around individual
          nodes can result in a brittle management framework and the creation
          of congestion points during periods of connectivity.
        </t>

        <t>
          The DTNMA should not prescribe any association between a
          DM and a DA other than those defined in this document.
          There should be no logical limitation to on the number of DMs
          that can control a DA, the number of DMs that a DA should report to,
          or any requirement that a DM and DA relationship implies imply a pair.
        </t>

        <aside>
          <t>
            NOTE: Practical limitations on the relationships between and
            amongst DMs and DAs will exist as a function of the capabilities of
            networked devices. These limitations derive from processing and storage
            constraints, performance requirements, and other engineering factors.
            While this information is vital to the proper engineering
            Implementors of a managed and managing device, they are implementation considerations, and not
            otherwise design constraints on the DTNMA. devices must account for these
            limitations in their device designs.

          </t>
        </aside>
      </section>

      <section numbered="true">
        <name> Hierarchically Modeled Information</name>

        <t>
          The DTNMA should use data models to define the syntactic and
          semantic contracts for data exchange between a DA and a DM. A given
          model should have the ability to "inherit" the contents of other
          models to form hierarchical data relationships.
        </t>

        <aside>
          <t>
            NOTE: The term data model "data model" in this context refers to a schema that
            defines a contract between a DA and a DM for regarding how information is
            represented and validated.
          </t>
        </aside>

        <t>
          Many network management solutions use data models to specify the
          semantic and syntactic representation of data exchanged between
          managed and managing devices. The DTNMA is not different in
          this regard - regard; information exchanged between DAs and DMs should
          conform to one or more pre-defined, predefined, normative data models.
        </t>

        <t>
          A common best practice when defining a data model is to make it cohesive.
          A cohesive model is one that includes information related to a single
          purpose such as managing a single application or protocol. When
          applying this practice, it is not uncommon to develop a large number
          of small data models that, together, describe the information needed
          to manage a device.
        </t>

        <t>
          Another best practice for data model development is the use of
          inclusion mechanisms to allow one data model to include information
          from another data model. This ability to include a data model avoids
          repeating information in different data models. When one data
          model includes information from another data model, there is an
          implied model hierarchy.
        </t>

        <t>
          Data models in the DTNMA should allow for the construction of both
          cohesive models and hierarchically related models. These data models
          should be used to define all sources of information that can
          be retrieved, configured, or executed in the DTNMA. This includes These actions would include
          supporting DA autonomy functions such as parameterization,
          filtering, and event driven event-driven behaviors. These models will be used to both
          implement interoperable autonomy engines on DAs and define
          interoperable report parsing mechanisms on DMs.
        </t>

        <aside>
          <t>
            NOTE: While data model hierarchies can result in a more concise
            data model, arbitrarily complex nesting schemes can also result in
            very verbose encodings. Where possible, data identification
            schemes should be constructed that allow for both hierarchical
            data and highly compressible data identification.
          </t>
        </aside>

      </section>

      <section numbered="true">
        <name>Adaptive Push of Information</name>

        <t>
          DAs in the DTNMA architecture should determine when to push
          information to DMs as a function of their local state.
        </t>

        <t>
          Pull
          "Pull" management mechanisms require a managing device to send a query
          to a managed device and then wait for a response to that specific
          query. This practice implies some knowledge synchronization between
          entities (which may be as simple as knowing when a managed device might be powered). However, challenged networks
          cannot guarantee timely round-trip data exchange. For this reason,
          pull mechanisms should be avoided in the DTNMA.
        </t>

        <t>
          Push
          "Push" mechanisms, in this context, refer to indicate the ability of DAs to
          leverage local autonomy to determine when and what information
          should be sent to which DMs. The push is considered adaptive
          because a DA determines what information to push (and when) as
          an adaptation to changes to the DA's internal state. Once pushed,
          information might still be queued queued, pending connectivity of the DA
          to the network.
        </t>

        <aside>

          <t>
            NOTE:
            Even in cases where a round-trip exchange can occur, pull
            mechanisms increase the overall amount of traffic in the network
            and preclude the use of autonomy at managed devices. So So, even when
            pull mechanisms are feasible feasible, they should not be considered a
            pragmatic alternative to push mechanisms.
          </t>
        </aside>

      </section>

      <section numbered="true">
        <name>Efficient Data Encoding</name>
        <t>
          Messages exchanged between a DA and a DM in the DTNMA should be
          defined in a way that allows for efficient on-the-wire encoding.
          DTNMA design decisions that result in smaller message sizes
          should be preferred over those that result in larger message sizes.
        </t>

        <t>
          There is a relationship between message encoding and message
          processing time at a node. Messages with little few or no encodings may
          simplify node processing processing, whereas more compact encodings may require
          additional activities to generate/parse encoded messages. Generally,
          compressing a message takes processing time at the sender and
          decompressing a message takes processing time at a receiver.
          Therefore, there is a design tradeoff trade-off between minimizing message
          sizes and minimizing node processing.
        </t>

        <t>
          There is a significant advantage to smaller DTNMA message sizes
          in a challenged network. Smaller messages require smaller shorter periods of
          viable transmission for communication, they incur less
          re-transmission
          retransmission cost, and they consume less fewer resources when
          persistently stored en-route en route in the network.
        </t>

        <aside>
          <t>
            NOTE: Naive approaches to minimizing message size through general
            purpose
            general-purpose compression algorithms do not produce minimal encodings.
            Data models can, and should, be designed for compact encoding from
            the beginning. Design strategies for compact encodings involve
            using structured data, hierarchical data models, and common
            sub-structures
            substructures within data models. These strategies allow for
            compressibility beyond what would otherwise be achieved by
            computing large hash values over generalized data structures.

          </t>
        </aside>

      </section>

      <section numbered="true">
        <name>Universal, Unique Data Identification</name>

        <t>
          Data elements within the DTNMA should be uniquely identifiable so that
          they can be individually manipulated. Further, these identifiers
          should be universal - -- the identifier for a data element should be the
          same
          same, regardless of role, implementation, or network instance.
        </t>

        <t>
          Identification schemes that would be relative to a specific DA or
          specific system configuration might change over time and should be avoided. Relying on relative identification schemes would require resynchronizing relative state when nodes in a challenge challenged network reconnect after periods of partition. This type of resynchronization should be avoided whenever possible.
        </t>

        <aside>
          <t>
            NOTE: Consider a common management technique for approximating an
            associative array lookup. If a managed device
            tracks the number of bytes passed by multiple named interfaces,
            then the number of bytes through a specific named interface
            ("int_foo"),
            ("int_foo") would be retrieved in the following way:
          </t>

          <ol>
              <li>
                  Query a list of ordered interface names from an agent.
              </li>
              <li>
                  Find the name that matches "int_foo" "int_foo", and infer the agent's index of "int_foo" from the ordered interface list. In
                  this instance, assume that "int_foo" is the 4th fourth interface in the list.
              </li>
              <li>
                  Query the agent (again) to now return the number of bytes passed through the 4th fourth interface.
              </li>
          </ol>

          <t>
            Ignoring the inefficiency of two round-trip exchanges, this
            mechanism will fail if an agent implementation changes its index
            mapping between the first and second query. queries.
          </t>
          <t>
            The desired data being queried, "number of bytes through int_foo" 'int_foo'",
            should be uniquely and universally identifiable and independent
            of how that data exists in any agent's custom implementation.
          </t>
        </aside>

      </section>

      <section numbered="true">
        <name>Runtime Data Definitions</name>

        <t>
          The DTNMA allows for the addition of new data elements to a
          data model as part of the runtime operation of the management system.
          These definitions may represent custom data definitions that are
          applicable only for a particular device or network. Custom
          definitions should also be able to be removed from the system during
          runtime.
        </t>

        <t>
          The goal of this approach is to dynamically add or remove data elements to the local runtime schemas as needed - needed, such as the definition of new counters, new reports, or new rules.
        </t>

        <t>
          The custom definition of new data from existing data (such as through
          data fusion, averaging, sampling, or other mechanisms) provides the
          ability to communicate desired information in as compact a form as
          possible.
        </t>

        <aside>
          <t>
             NOTE: A DM could, for example, define a custom data report that
             includes only summary information around about a specific operational
             event or as part of specific debugging. DAs could then produce
             this smaller report until it is no longer necessary, at which
             point the custom report could be removed from the management
             system.
          </t>
        </aside>

        <t>
          Custom data elements should be calculated and used both as
          parameters for DA autonomy and for more efficient reporting
          to DMs. Defining new data elements allows for DAs to perform
          local data fusion fusion, and defining new reporting templates allows
          for DMs to specify desired formats and generally save on link
          capacity, storage, and processing time.
        </t>
      </section>

      <section numbered="true">
        <name>Autonomous Operation</name>

        <t>
            The management of applications by a DA should be achievable using
            only knowledge local to the DA because DAs might need to operate
            during times when they are disconnected from a DM.
        </t>

        <t>
            DA autonomy may be used for simple automation of predefined tasks
            or to support semi-autonomous behavior in determining when to run
            tasks and how to configure or parameterize tasks when they are run.
	      </t>
	      <t>
            Important features provided by the DA are listed below. These
            features work together to accomplish tasks. As such, there is
            commonality amongst their definitions and nature of their benefits.
         </t>

          <dl>
            <dt>Stand-alone
            <dt>Standalone Operation:</dt>
            <dd>
              Pre-configuration
              Preconfiguration allows DAs to operate
              without regular contact with other nodes in the network. Updates
              for configurations remain difficult in a challenged network, but this approach removes the requirement that a DM be in-the-loop in the loop during regular operations.
              Preconfiguring stimuli-and-responses stimuli and responses on a DA during periods of
              connectivity allows DAs to self-manage during periods of
              disconnectivity.
            </dd>

            <dt>Deterministic Behavior:</dt>
            <dd>
              Operational systems might need to act
              in a deterministic way way, even in the absence of an operator
              in-the-loop.
              in the loop. Deterministic behavior allows an out-of-contact DM to
              predict the state of a DA and to determine how a DA got into
              a particular state.
            </dd>
            <dt>Engine-Based Behavior:</dt>
            <dd>
              Operational systems might not be able to
              deploy "mobile code" solutions
              <xref target="RFC4949" format="default"/>
              solutions due to network bandwidth, memory or processor loading,
              or security concerns. Engine-based approaches provide configurable
              behavior without incurring these concerns.
            </dd>
            <dt>Authorization and Accounting:</dt>
            <dd>
              The DTNMA does not
              require a specific underlying transport protocol, a specific network
              infrastructure, or specific network services. Therefore, mechanisms for
              authorization and accounting need to be present in
              a standard way at DAs and DMs to provide these functions if the
              underlying network does not. This is particularly true in cases
              where multiple DMs may be active concurrently in the network.
            </dd>
          </dl>

         <t>
           To understand the contributions of these features to a common type of
           behavior, consider the example of a managed device coming online
           with a set of pre-installed configuration. preinstalled configurations. In this case,
           the device's stand-alone standalone operation comes from the pre-configuration preconfiguration
           of its local autonomy engine. This engine-based behavior allows
           the system to behave in a deterministic way way, and any new configurations
           will need to be authorized before being adopted.
         </t>

          <t>
            Features such as deterministic processing and engine-based
            behavior are separate from (but do not preclude the use of) other
            Artificial Intelligence (AI) and Machine Learning (ML) approaches
            for device management.
          </t>
      </section>
   </section>

   <section anchor="current-remote-mgmt" numbered="true">
      <name>Current Remote Management Approaches</name>
      <t>
        Several remote management solutions have been developed for both local-area local area networks and wide-area wide area networks. Their capabilities range from simple configuration and report generation to complex modeling of device settings, state, and behavior.
        Each
        All of these approaches are successful in the domains for which they have been built, built but are not all equally functional when deployed in a challenged network.
      </t>
      <t>
        This section describes some of the well-known protocols for remote management and contrasts their purposes with the desirable properties of the DTNMA.
        The purpose of this comparison is to identify parts of existing approaches that can be adopted or adapted for use in challenged networks and where new capabilities should be created specifically for this environment. such environments.
      </t>
      <section>
        <name>SNMP and SMI Models</name>
        <t>
An early and widely used example of a remote management protocol is the Simple Network Management Protocol (SNMP) SNMP, which is currently at Version version 3 <xref target="RFC3410"/>.
The
SNMP utilizes a request/response request-response model to get and set data values within an arbitrarily deep object hierarchy.
Objects are used to identify data such as host identifiers, link utilization metrics, error rates, and counters between application software on managing and managed devices <xref target="RFC3411"/>.
Additionally, SNMP supports a model for unidirectional push messages, called event notifications, based on agent-defined triggering events.
        </t>
        <t>
SNMP relies on logical sessions with predictable round-trip latency to support its "pull" mechanism pull mechanism, but a single activity is likely to require many round-trip exchanges.
Complex management can be achieved, but only through careful orchestration of real-time, end-to-end, managing-device-generated query-and-response logic.
        </t>
        <t>
          There is existing work that uses the SNMP data model to support
          some low-fidelity Agent-side processing, to include the Distributed
          Management Expression MIB agent-side processing; this work includes using
"<xref target="RFC2982" format="title"/>" <xref target="RFC2982"/> target="RFC2982" format="default"/> and Definitions
          of Managed Objects for the Delegation of Management Scripts
"<xref target="RFC3165" format="title"/>" <xref target="RFC3165"/>. target="RFC3165" format="default"/>.
          However, Agent agent autonomy is not an SNMP
          mechanism, so support for a local agent response to an initiating
          event is limited. In a challenged network where the delay between
          a managing device receiving an alert and sending a response can be
          significant, SNMP is insufficient for autonomous event handling.
        </t>
        <section anchor="sec-mgmt-snmp-smi">
          <name>The SMI Modeling Language</name>
          <t>
SNMP separates the representations for managed data models from Manager--Agent messaging, sequencing sequencing, and encoding. encoding between managers and agents.
Each data model is termed a Management "Management Information Base (MIB) Base" (or "MIB") <xref target="RFC3418"/> and uses the Structure of Management Information (SMI) modeling language <xref target="RFC2578"/>.
Additionally, the SMI itself is based on the ASN.1 Syntax syntax <xref target="ASN.1"/> target="ASN.1"/>, which is used not just for SMI but for other, unrelated data structure specification specifications such as the Cryptographic Message Syntax (CMS) <xref target="RFC5652"/>.
Separating data models from messaging and encoding is a best practice in remote management protocols and is also necessary for the DTNMA.
          </t>
          <t>
Each SNMP MIB is composed of managed object definitions definitions, each of which is associated with a hierarchical Object Identifier (OID).
Because of the arbitrarily deep nature of MIB object trees, the size of OIDs is not strictly bounded by the protocol (though it may be bounded by implementations).
          </t>
        </section>
        <section>
          <name>SNMP Protocol and Transport</name>
          <t>
The SNMP protocol itself, which is at version 2
SNMPv2 <xref target="RFC3416"/> <xref target="RFC3416"/>, target="RFC3417"/> and SNMPv3 <xref target="RFC3414"/> can operate over a variety of transports, including plaintext UDP/IP <xref target="RFC3417"/>, SSH/TCP/IP <xref target="RFC5592"/>, and DTLS/UDP/IP or TLS/TCP/IP <xref target="RFC6353"/>.
          </t>
          <t>
SNMP uses an abstracted security model to provide authentication, integrity, and confidentiality.
There are options for user-based security model the User-based Security Model (USM) of <xref target="RFC3414"/>, which uses in-message security, and transport security model the Transport Security Model (TSM) <xref target="RFC5591"/>, which relies on the transport to provide security functions and interfaces.
          </t>
        </section>
      </section>
      <section>
        <name>XML-Infoset-Based Protocols and YANG Data Models</name>

        <t>
Several network management protocols, including NETCONF <xref target="RFC6241"/>, RESTCONF <xref target="RFC8040"/>, and CORECONF the Constrained Application Protocol (CoAP) Management Interface (CORECONF) <xref target="I-D.ietf-core-comi"/>, target="CORE-COMI"/>, share the same XML information set Information Set <xref target="xml-infoset"/> for its the information set's hierarchical managed information and XPath expressions <xref target="XPath"/> expressions to identify nodes of that information model.
Since they share the same information model and the same data manipulation operations, together they will be referred to as "*CONF" protocols.
Each protocol, however, provides a different encoding of that information set and its related operation-specific data.
        </t>
        <t>
The YANG modeling language of as defined in <xref target="RFC7950"/> is used to define the data model for these management protocols.
Currently, YANG represents the IETF standard for defining managed information models.
        </t>
        <section>
          <name>The YANG Modeling Language</name>
          <t>
The YANG modeling language defines a syntax and modular semantics for organizing and accessing a device's configuration or operational information.
YANG allows subdividing a full managed configuration into separate namespaces defined by separate YANG modules.
Once a module is developed, it is used (directly or indirectly) on both the client and server to serve as a contract between the two.
A YANG module can be complex, describing a deeply nested and inter-related interrelated set of data nodes, actions, and notifications.
          </t>
          <t>
Unlike the separation in <xref target="sec-mgmt-snmp-smi"/> between ASN.1 syntax and module semantics from higher-level SMI data model semantics, semantics as discussed in <xref target="sec-mgmt-snmp-smi"/>, YANG defines both a text syntax and module semantics together with data model semantics.
          </t>
          <t>
The YANG modeling language provides flexibility in the organization of model objects to the model developer.
The
YANG supports a broad range of data types as noted in <xref target="RFC6991"/>.
YANG also supports the definition of parameterized Remote Procedure Calls (RPCs) and actions to be executed on managed devices as well as the definition of event notifications within the model.
          </t>
          <aside><t>
          <t>
Current *CONF notification logic allows a client to subscribe to the delivery of specific containers or data nodes defined in the model, either on either a periodic or "on change"
"on-change" basis <xref target="RFC8641"/>.
These notification events can be filtered according to XPath <xref target="XPath"/> or subtree filtering <xref target="XPath"/> <xref target="RFC6241"/> filtering as described in <xref section="2.2" target="RFC8639"/>.
          </t></aside>
          </t>
          <t>
The use of YANG for data modeling necessarily comes with some side-effects, side effects, some of which are described here.
          </t>
          <dl>
            <dt>Text Naming:</dt>
            <dd>
              <t>
Data nodes, RPCs, and notifications within a YANG data model are named by a namespace-qualified, text-based path of the module, sub-module, submodule, container, and any data nodes such as lists, leaf-lists, or leaves, without any explicit hierarchical organization based on data or object type.
              </t>
              <t>
Existing efforts to make compressed names for YANG objects, such as the YANG Schema Item iDentifiers (SID) from (SIDs) as discussed in <xref section="3.2" target="RFC9254"/>, allow a node to be named by an a globally unique integer value but are still relatively verbose (up to 8 bytes per item) and still must be translated into text form for things like instance identification (see below).
Additionally, when representing a tree of named instances instances, the child elements can use differential encoding of SID integer values as "delta" integers.
The mechanisms for assigning SIDs and the lifecycle of those SIDs are still discussed in development <xref target="I-D.ietf-core-sid"/>. target="RFC9595"/>.
              </t>
            </dd>
            <dt>Text Values and Built-In Types:</dt>
            <dd>
              <t>
Because the original use of YANG with NETCONF was to model XML information sets, Information Sets, the values and built-in types are necessarily text based.
The
JSON encoding of YANG data <xref target="RFC7951"/> allows for optimized representations of many built-in types, and similarly the CBOR types; similarly, Concise Binary Object Representation (CBOR) encoding <xref target="RFC9254"/> allows for different optimized representations.
              </t>
              <t>
In particular, the YANG built-in types natively support a fixed range of decimal fractions (<xref section="9.3" target="RFC7950"/>) but purposefully do not support floating point floating-point numbers.
There are alternatives, such as the type <tt>bandwidth-ieee-float32</tt> from <xref target="RFC8294"/> or using the "binary" type with one of the IEEE-754 encodings.
              </t>
            </dd>
            <dt>Deep Hierarchy:</dt>
            <dd>
YANG allows for, and current YANG modules take advantage of, the ability to deeply nest a model hierarchy to represent complex combinations and compositions of data nodes.
When a model uses a deep hierarchy of nodes nodes, this necessarily means that the qualified paths to name those nodes and instances is are longer than they would be in a flat hierarchy would be. namespace.
            </dd>
            <dt>Instance Identification:</dt>
            <dd>
The node instances in a YANG module necessarily use XPath expressions for identification.
Some identification is constrained to be strictly within the YANG domain, such as "must" "must", "when", "augment", or "deviation" statements.
Other identification needs to be processed by a managed device, such as in device -- for example, via
the "instance-identifier" built-in type.
This means that any implementation of a managed device must include XPath processing and related information model handling of per <xref section="6.4" target="RFC7950"/> and its referenced documents.
            </dd>
            <dt>Protocol Coupling:</dt>
            <dd>
              <t>
A significant amount of existing YANG tooling or modeling presumes the use of YANG data within a management protocol with specific operations available.
For example, the access control model of defined in <xref target="RFC8341"/> relies on those operations specific to the *CONF protocols for proper behavior.
              </t>
              <t>
The emergence of multiple NETCONF-derived protocols may make these presumptions less problematic in the future.
Work to more consistently identify different types of YANG modules and their use has been undertaken to disambiguate how YANG modules should be treated <xref target="RFC8199"/>.
              </t>
            </dd>
            <dt>Manager-Side Control:</dt>
            <dd>
YANG RPCs and actions execute on a managed device and generate an expected, structured response.
RPC execution is strictly limited to those issued by the manager.
Commands are executed immediately and sequentially as they are received by the managed device, and there is no method to autonomously execute RPCs triggered by specific events or conditions.
            </dd>
          </dl>
          <t>
The YANG modeling language continues to evolve as new features are needed by adopting management protocols.
          </t>
        </section>
          <section>
            <name>NETCONF Protocol and Transport</name>
            <t>
NETCONF is a stateful, XML-encoding-based protocol that provides a syntax to retrieve, edit, copy, or delete any data nodes or exposed functionality on a server.
It requires that underlying transport protocols support long-lived, reliable, low-latency, sequenced data delivery sessions.
A bi-directional bidirectional NETCONF session needs to be established before any data transfer (or notification) can occur.
            </t>
            <t>
The XML exchanged within NETCONF messages is structured according to YANG modules supported by the NETCONF agent, and the data nodes reside within one of possibly many datastores in accordance with the Network Management Datastore Architecture (NMDA) of <xref target="RFC8342"/>.
            </t>
            <t>
NETCONF transports are required to provide authentication, data integrity, confidentiality, and replay protection.
Currently, NETCONF can operate over SSH/TCP/IP <xref target="RFC6242"/> or TLS/TCP/IP <xref target="RFC7589"/>.
            </t>
          </section>
          <section>
            <name>RESTCONF Protocol and Transport</name>
            <t>
RESTCONF is a stateless, JSON-encoding-based protocol that provides the same operations as NETCONF, using the same YANG modules for structure and the same NMDA datastores, but using RESTful exchanges over HTTP.
It uses HTTP-native HTTP methods to express its allowed operations: GET, POST, PUT, PATCH, or DELETE data nodes within a datastore.
            </t>
            <t>
Although RESTCONF is a logically stateless protocol, it does rely on state within its transport protocol to achieve behaviors such as authentication and security sessions.
Because RESTCONF uses the same data node semantics of as NETCONF, a typical activity can involve the use of several sequential round-trips round trips of exchanges to first discover managed device state and then act upon it.
            </t>
          </section>
          <section>
            <name>CORECONF Protocol and Transport</name>
            <t>
              CORECONF is an emerging stateless protocol built atop the Constrained
              Application Protocol (CoAP) CoAP <xref target="RFC7252"/> that
              defines a messaging construct developed to operate specifically
              on constrained devices and networks by limiting message size and
              fragmentation. CoAP also implements a request/response request-response system and
              methods for GET, POST, PUT, and DELETE.
            </t>
          </section>
      </section>
      <section>
        <name>gRPC Network Management Interface (gNMI)</name>
        <t>
Another emerging emerging, but not-IETF-affiliated not IETF-affiliated, management protocol is the gRPC Network Management Interface (gNMI) <xref target="gNMI"/> target="gNMI"/>, which is based on gRPC messaging and uses Protobuf Google protobuf data modeling.
        </t>
        <t>
The same limitations of RESTCONF as those listed above for RESTCONF apply to gNMI because of its reliance on synchronous HTTP exchanges and TLS security for normal operations, as well as the likely deep nesting of data schemas.
There &nbsp;gNMI is a capability for gNMI to transport capable of transporting JSON-encoded YANG-modeled data, but this composing how to compose such data is not yet fully standardized and relies on specific tool integrations to operate. standardized.
        </t>
        <section>
          <name>The Protobuf Modeling Language</name>
          <t>
The data managed and exchanged via gNMI is encoded and modeled using Google Protobuf, protobuf, an encoding and modeling syntax not affiliated with the IETF (although an attempt has been made and abandoned <xref target="I-D.rfernando-protocol-buffers"/>). target="PROTOCOL-BUFFERS"/>).
          </t>
          <t>
Because the Protobuf protobuf modeling syntax is a relatively low-level (around syntax (about the same as ASN.1 or CBOR), there are some efforts as part of the OpenConfig work <xref target="gNMI"/> to translate YANG modules into Protobuf protobuf schemas (similar to translation to XML or JSON schemas for NETCONF and RESTCONF respectively) RESTCONF, respectively), but there is no required interoperabilty interoperability between management via gRPC or any of the *CONF protocols.
          </t>
        </section>
        <section>
          <name>gRPC Protocol and Transport</name>
          <t>
The message encoding and exchange for gNMI, as the name implies, is the gRPC protocol <xref target="gRPC"/>.
gRPC &nbsp;gRPC exclusively uses HTTP/2 <xref target="RFC9113"/> for transport and relies on some aspects specific to HTTP/2 for its operations (such as HTTP trailer fields).
While not mandated by gRPC, when used to transport gNMI data data, TLS is required for transport security.
          </t>
        </section>
      </section>
      <section>
        <name>Intelligent Platform Management Interface (IPMI)</name>
        <t>
A lower-level remote management protocol, intended to be used to manage hardware devices and network appliances below the operating system (OS), is the Intelligent Platform Management Interface (IPMI) (IPMI), standardized in <xref target="IPMI"/>.
The IPMI is focused on health monitoring, event logging, firmware management, and serial-over-LAN Serial over LAN (SOL) remote console access in a "pre-OS or OS-absent" host environment.
The IPMI operates over a companion Remote Management Control Protocol (RMCP) for messaging, which itself can use UDP for transport.
        </t>
        <t>
Because the IPMI and RCMP are tailored to low-level and well-connected devices within a datacenter, data center, with typical workflows requiring many messaging round trips or low-latency interactive sessions, they are not suitable for operation over a challenged network.
        </t>
      </section>
      <section>
        <name>Autonomic Networking</name>
        <t>
          The future of network operations requires more autonomous behavior behavior,
          including self-configuration, self-management, self-healing, and
          self-optimization. One approach to support this is termed Autonomic
          Networking "Autonomic
          Networking" <xref target="RFC7575"/>.
        </t>
        <t>
          There is a large and growing set of work within the IETF
          focused on developing an Autonomic Networking Integrated Model and
          Approach (ANIMA). The ANIMA work has developed a comprehensive
          reference model for distributing autonomic functions across multiple
          nodes in an autonomic networking Autonomic Networking infrastructure <xref target="RFC8993"/>.
        </t>
        <t>
          This work, focused on learning the behavior of distributed systems to
          predict future events, is an emerging network management
          capability. This includes the development of signalling signaling protocols
          such as GRASP the GeneRic Autonomic Signaling Protocol (GRASP) <xref target="RFC8990"/> and the autonomic control plane Autonomic Control Plane (ACP)
          <xref target="RFC8368"/>.
        </t>
        <t>
          Both autonomic and challenged networks require similar degrees of
          autonomy. However, challenged networks cannot provide the complex
          coordination between nodes and distributed supporting infrastructure
          necessary for the frequent data exchanges for negotiation, learning,
          and bootstrapping associated with the above capabilities.
        </t>
        <t>
          There is some emerging work in ANIMA as to how disconnected
          devices might join and leave the autonomic control plane ACP over time.
          However, this work is addressing a different problem
          than that encountered by challenged networks.
        </t>
      </section>
      <section>
        <name>Deep Space Autonomy</name>
        <t>
Outside of the terrestrial networking community, there are existing and established remote management systems used for deep space mission operations.
Examples of two
Two examples of these such systems are for the New Horizons mission to Pluto <xref target="NEW-HORIZONS"/> and the DART Double Asteroid Redirection Test (DART) mission to the asteroid Dimorphos <xref target="DART"/>.
        </t>
        <t>
The DTNMA has some heritage in the concepts of deep space autonomy, but each of those mission instantiations use uses mission-specific data encoding, messaging, and transport as well as mission-specific (or heavily mission-tailored) modeling concepts and languages.
Part of the goal of the DTNMA is to take the proven concepts from these missions and standardize a messaging syntax as well as a modular data modeling method.
        </t>
      </section>
    </section>

    <section anchor="motivation-for-new-features" numbered="true">
      <name>Motivation for New Features</name>
      <t>
        Management mechanisms that provide the complete set of DTNMA desirable
        properties do not currently exist. This is not surprising surprising, since
        autonomous management in the context of a challenged networking
        environment is a new and emerging use case.
      </t>

      <t>
        In particular, a management architecture is needed that integrates
        the following motivating features.
      </t>

      <dl>
        <dt>Open Loop
        <dt>Open-Loop Control:</dt>
        <dd>
          Freedom from a request-response architecture,
          API, or other presumption of timely round-trip communications. This
          is particularly important when managing networks that are not built
          over an HTTP or TCP/TLS infrastructure.
        </dd>
        <dt>Standard Autonomy Model:</dt>
        <dd>
          An autonomy model that allows for standard
          expressions of policy to guarantee deterministic behavior across
          devices and vendor implementations.
        </dd>
        <dt>Compressible Model Structure:</dt>
        <dd>
          A data model that allows for very
          compact encodings by defining and exploiting common structures for
          data schemas.
        </dd>
      </dl>
      <t>
        Combining these new features with existing mechanisms for message data
        exchange (such as BP), data representations (such as CBOR) CBOR), and data
        modeling languages (such as YANG) will form a pragmatic approach to
        defining challenged network management.
      </t>
    </section>

    <section anchor="reference-model" numbered="true">
      <name>Reference Model</name>
        <t>
          This section describes a reference model for reasoning about analyzing
          network management concepts for challenged networks (generally) and
          those conforming to the DTN architecture (in particular). The goal
          of this section is to describe how DTNMA services provide DTNMA
          desirable properties.
        </t>

      <section numbered="true">
        <name>Important Concepts</name>

        <t>
          Similar to
          Like other network management architectures, the DTNMA draws
          a logical distinction between a managed device and a managing
          device. Managed devices use a DA to manage resident applications.
          Managing devices use a DM to both monitor and control DAs.
        </t>

        <aside>

          <t>
            NOTE:
            The terms "managing" and "managed" represent logical
            characteristics of a device and are not, themselves, mutually
            exclusive. For example, a managed device might, itself, also manage
            some other device in the network. Therefore, a device may support
            either or both of these characteristics.
         </t>
        </aside>

        <t>
          The DTNMA differs from some other management architectures in
          three significant ways, all related to the need for a device to
          self-manage when disconnected from a managing device.
        </t>

        <dl>
          <dt>Pre-shared
          <dt>Pre-Shared Definitions:</dt>
          <dd>
            Managing and managed devices should operate
            using pre-shared data definitions and models. This implies that
            static definitions should be standardized whenever possible and
            that managing and managed devices may need to negotiate definitions
            during periods of connectivity.
          </dd>
          <dt>Agent Self-Management:</dt>
          <dd>
            A managed device may find itself
            disconnected from its managing device. In many challenged networking
            scenarios, a managed device may spend the majority of its time without
            a regular connection to a managing device. In these cases, DAs manage
            themselves by applying pre-shared policies received from managing
            devices.
          </dd>
          <dt>Command-Based Interface:</dt>
          <dd>
            Managing devices communicate with managed
            devices through a command-based interface.  Instead of exchanging
            variables, objects, or documents, a managing device issues commands
            to be run by a managed device. These commands may create or update
            variables, change data stores, datastores, or impact the managed device in ways
            similar to other network management approaches. The use of commands
            is, in part, driven by the need for DAs to receive updates from
            both remote management devices and local autonomy. The use of controls Controls for the implementation of commands is discussed in more detail in <xref target="ctrl_exec"/>.
          </dd>
        </dl>
      </section>

      <section numbered="true">
        <name>Model Overview</name>

      <t>
        A DTNMA reference model is provided in <xref target="dtnma_ref_model"/>
        below. In this reference model, applications and services on a managing
        device communicate with a DM which that uses pre-shared definitions to create
        a set of policy directives that can be sent to a managed device's DA via
        a command-based interface. The DA provides local monitoring and control
        (commanding) of the applications and services resident on the managed
        device. The DA also performs local data fusion as necessary to synthesize data products (such as
        reports) that can be sent back to the DM when appropriate.
      </t>

      <t keepWithNext="true">DTNMA Reference Model</t>

      <figure anchor="dtnma_ref_model">
       <name>DTNMA Reference Model</name>
        <artwork align="center" name="" type="" alt=""><![CDATA[
       Managed Device                            Managing Device
+----------------------------+           +-----------------------------+
| +------------------------+ |           | +-------------------------+ |
| |Applications & Services | |           | | Applications & Services | |
| +----------^-------------+ |           | +-----------^-------------+ |
|            |               |           |             |               |
| +----------v-------------+ |           | +-----------v-------------+ |
| | DTNMA  +-------------+ | |           | | +-----------+   DTNMA   | |
| | AGENT  | Monitor and | | |Commanding | | |  Policy   |  MANAGER  | |
| |        |   Control   | | |<==========| | | Encoding  |           | |
| | +------+-------------+ | |           | | +-----------+-------+   | |
| | |Admin | Data Fusion | | |==========>| | | Reporting | Admin |   | |
| | +------+-------------+ | | Reporting | | +-----------+-------+   | |
| +------------------------+ |           | +-------------------------+ |
+----------------------------+           +-----------------------------+
           ^                                             ^
           |            Pre-Shared Definitions           |
           |        +---------------------------+        |
           +--------| - Autonomy Model          |--------+
                    | - Application Data Models |
                    | - Runtime Data Stores Datastores      |
                    +---------------------------+
]]></artwork>
      </figure>

      <t>
        This model preserves the familiar concept of "managers" resident on
        managing devices and "agents" resident on managed devices. However,
        the DTNMA model is unique in how the DM and DA operate. The DM is
        used to pre-configure preconfigure DAs in the network with management policies.
        it
        It is expected that the DAs, themselves, perform monitoring and
        control functions on their own. In this way, a properly configured
        DA may operate without a reliable connection back to a DM.
      </t>
    </section>

      <section numbered="true">
        <name>Functional Elements</name>

        <t>
          The reference model illustrated in <xref target="dtnma_ref_model"/>
          implies the existence of certain logical components whose roles and
          responsibilities are discussed in this section.
        </t>

        <section numbered="true">
          <name>Managed Applications and Services</name>
          <t>
            By definition, managed applications and services reside on a
            managed device. These software entities can be controlled through
            some interface by the DA DA, and their state can be sampled as part of
            periodic monitoring. It is presumed that the DA on the managed
            device has the proper data model, control interface, and
            permissions to alter the configuration and behavior of these
            software applications.
          </t>
        </section>

        <section numbered="true">
          <name>DTNMA Agent (DA)</name>

          <t>
            A DA resides on a managed device. As is the case
            with other network management approaches, this agent is responsible
            for the monitoring and control of the applications local to that
            device. Unlike other network management approaches, the agent
            accomplishes this task without a regular connection to a DTNMA
            Manager. DM.
          </t>

          <t>
            The DA performs three major functions on a managed
            device: the monitoring and control of local applications,
            production of data analytics, and the administrative
            control of the agent itself.
          </t>

          <section numbered="true">
            <name>Monitoring and Control</name>

            <t>
              DAs monitor the status of applications running on their
              managed device and selectively control those applications as a
              function of that monitoring. The following components are used to
              perform monitoring and control on an agent.
            </t>

            <dl newline="true" spacing="normal" indent="8">
              <dt>Rules spacing="normal">
              <dt>Rule Database:</dt>
              <dd>
                Each DA maintains a database of policy expressions that form
                rules of regarding the behavior of the managed device. Within this database,
                each rule of regarding behavior is a tuple of a stimulus and a response.
                Within the DTNMA, these rules are the embodiment of
                policy expressions received from DMs and evaluated at
                regular intervals by the autonomy engine. The rules rule database is
                the collection of active rules known to the DA.
              </dd>

              <dt>Autonomy Engine:</dt>
              <dd>
                The DA autonomy engine monitors the state of the managed device device,
                looking for pre-defined predefined stimuli and, when such stimuli are encountered, issuing a
                pre-defined
                predefined response. To the extent that this function is driven
                by the rules rule database, this engine acts as a policy execution
                engine. This engine may also be directly configured by
                managers during periods of connectivity for actions separate
                from those in the rules rule database (such as enabling or disabling
                sets of rules). Once configured, the engine may function
                without other access to any managing device. This engine may
                also reconfigure itself as a function of policy.
              </dd>

              <dt>Application Control Interfaces:</dt>
              <dd>
                DAs support control interfaces for all
                managed applications.  Control interfaces are used to alter
                the configuration and behavior of an application. These
                interfaces may be custom for each application, application or as provided
                through a common framework such as provided by an operating
                system. framework, protocol, or OS.
              </dd>
            </dl>
          </section>

          <section numbered="true">
            <name>Data Fusion</name>

            <t>
              DAs generate new data elements as a function of the
              current state of the managed device and its applications. These
              new data products may take the form of individual data values, values
              or of new collections of data used for reporting. The logical
              components responsible for these behaviors are as follows.
            </t>

            <dl newline="true" spacing="normal" indent="8"> spacing="normal">
              <dt>Application Data Interfaces:</dt>
              <dd>
                DAs support mechanisms by which important state is
                retrieved from various applications resident on the managed
                device. These data interfaces may be custom for each
                application,
                application or as provided through a common framework such
                as provided by an operating system. framework,
                protocol, or OS.
              </dd>

              <dt>Data Value Generators:</dt>
              <dd>
                DAs may support the generation of new data values as a
                function of other values collected from the managed device.
                These data generators may be configured with descriptions of
                data values values, and the data values they generate may be included
                in the overall monitoring and reporting associated with the
                managed device.
              </dd>

              <dt>Report Generators:</dt>
              <dd>
                DAs may, as appropriate, generate collections of data values
                and provide them to whatever local mechanism takes
                responsibility for their eventual transmission (or expiration
                and removal).  Reports can be generated as a matter of policy
                or in response to the handling of critical events (such as
                errors),
                errors) or other logging needs. The generation of a report is
                independent of whether there exists any connectivity between a
                DA and a DM.
              </dd>
            </dl>
          </section>

          <section numbered="true">
            <name>Administration</name>

            <t>
              DAs perform a variety of administrative services in support of
              their configuration, such as the following.
            </t>

            <dl newline="true" spacing="normal" indent="8"> spacing="normal">
              <dt>Manager Mapping:</dt>
              <dd>
                <t>
                  The DTNMA allows for a many-to-many relationship amongst DTNMA
                  Agents DAs
                  and Managers. DMs. A single DM may configure multiple
                  DAs, and a single DA may be configured by multiple
                  DMs. Multiple managers may exist in a network for at least
                  the following two reasons. First, different managers may exist to control
                  different applications on a device. Second, multiple managers
                  increase the likelihood of an agent encountering a manager when
                  operating in a sparse or challenged environment.
                </t>

                <t>
 While the need for multiple managers is required are needed for operating proper operation in
 a dynamically partitioned network, this situation allows for
                  the possibility of conflicting information from
 different managers. managers can result.
                  Implementations of the DTNMA should consider conflict resolution
                  mechanisms. Such mechanisms might include analyzing managed content,
                  time, agent location, or other relevant information to select
                  one manager input over other manager inputs.
                </t>
              </dd>
              <dt>Data Verifiers:</dt>
              <dd>
                DAs might handle large amounts of data produced by various
                sources, to include data from local managed applications,
                remote managers, and self-calculated values. DAs should
                ensure, when possible, that externally generated data values
                have the proper syntax and semantic constraints (e.g., data type and ranges) and any required authorization.
              </dd>
              <dt>Access Controllers:</dt>
              <dd>
                DAs support authorized access to the management of
                individual applications, to include the administrative
                management of the agent itself. This means that a manager may
                only set policy on the agent pursuant to verifying that the
                manager is authorized to do so.
              </dd>

            </dl>
          </section>
         </section>

         <section numbered="true">
            <name>Managing Applications and Services</name>

            <t>
               Managing applications and services reside on a managing device and
               serve as the both the source of DA policy statements and the target
               of DA reporting. They may operate with or without an operator in the
               loop.
            </t>
            <t>
               Unlike management applications in unchallenged networks, these
               applications cannot exert closed-loop control over any managed
               device application. Instead, they exercise open-loop control by
               producing policies that can be configured and enforced on
               managed devices by DAs.
            </t>

            <aside>
              <t>
                NOTE: Closed-loop control in this context refers to the
                practice of waiting for a response from a managed device prior
                to issuing new commands to that device. These "loops" may be
                closed quickly (in milliseconds) or over much longer periods (
                hours,
                (hours, days, years). The alternative to closed-loop control is
                open-loop control, where the issuance of new commands is not
                dependent on receiving responses to previous commands.
                Additionally, there might not be a 1-1 one-to-one mapping between commands
                and responses. A DA may, for example, produce a single response
                that captures represents the end state from of applying multiple commands.
              </t>
            </aside>

         </section>

         <section numbered="true">
            <name>DTNMA Manager (DM)</name>

            <t>
              A DM resides on a managing device. This manager
              provides an interface between various managing applications and
              services and the DAs that enforce their policies. In
              providing this interface, DMs translate between whatever
              native
              innate interface exists to various managing applications and the
              autonomy models used to encode management policy.
            </t>
            <t>
              The DM performs three major functions on a managing
              device: policy encoding, reporting, and administration.
            </t>

            <section numbered="true">
              <name>Policy Encoding</name>

              <t>
                DMs translate policy directives from managing
                applications and services into standardized policy expressions
                that can be recognized by DAs. The following logical
                components are used to perform this policy encoding.
              </t>

              <dl newline="true" spacing="normal" indent="8"> spacing="normal">
                <dt>Application Control Interfaces:</dt>
                <dd>
                  DMs support control interfaces for managing
                  applications. These control interfaces are used to receive
                  desired policy statements from applications. These interfaces
                  may be custom for each application, application or as provided through
                  a common framework, protocol, or operating system. OS.
                </dd>

                <dt>Policy Encoders:</dt>
                <dd>
                  DAs implement a standardized autonomy model
                  comprising standardized data elements. This allows
                  the open-loop control structures provided by managing
                  applications to be represented in a common language. Policy
                  encoders perform this encoding function.
                </dd>

                <dt>Policy Aggregators:</dt>
                <dd>
                  DMs collect multiple encoded policies into messages that can be
                  sent to DAs over the network. This implies the proper addressing
                  of agents and the creation of messages that support
                  store-and-forward operations. It is recommended that control
                  messages be packaged using BP bundles when there may be
                  intermittent connectivity between DMs and DAs.
                </dd>
              </dl>
            </section>

            <section numbered="true">
              <name>Reporting</name>

              <t>
                DMs receive reports on the status of managed devices
                during periods of connectivity with the DAs on those
                devices. The following logical components are needed to
                implement reporting capabilities on a DM.
              </t>

              <dl newline="true" spacing="normal" indent="8"> spacing="normal">
                <dt>Report Collectors:</dt>
                <dd>
                  DMs receive reports from DAs in an asynchronous manner. This
                  means that reports may be received out of chronological order
                  and in ways that are difficult or impossible to associate with
                  a specific policy from a managing application. DMs collect
                  these reports and extract their data in support of subsequent
                  data analytics.
                </dd>

                <dt>Data Analyzers:</dt>
                <dd>
                  DMs review sets of data reports from DAs with the purpose of
                  extracting relevant data to communicate with managing
                  applications. This may include simple data extraction or may
                  include more complex processing such as data conversion, data
                  fusion, and appropriate data analytics.
                </dd>

                <dt>Application Data Interfaces:</dt>
                <dd>
                  DMs support mechanisms by which data retrieved
                  from DAs may be provided back to managing devices. These
                  interfaces may be custom for each application, application or as
                  provided through a common framework, protocol, or operating
                  system. OS.
                </dd>
              </dl>
            </section>

            <section numbered="true">
              <name>Administration</name>

              <t>
                Managers
                DMs in the DTNMA perform a variety of administrative
                services, such as the following.
              </t>

              <dl newline="true" spacing="normal" indent="8"> spacing="normal">
                <dt>Agent Mappings:</dt>
                <dd>
                  The DTNMA allows DMs to communicate with multiple
                  DAs. However, not every agent in a network is expected
                  to support the same set of Application Data Models application data models or
                  otherwise have the same set of managed applications running.
                  For this reason, DMs determine individual DA
                  capabilities to ensure that only appropriate Controls are
                  sent to a DA.
                </dd>

                <dt>Data Verifiers:</dt>
                <dd>
                  DMs handle large amounts of data produced by various
                  sources, to include data from managing applications and
                  DAs. DMs should ensure, when possible, that data values
                  received from DAs over a network have the proper
                  syntax and semantic constraints (e.g., data type and ranges) and any required authorization.
                </dd>

                <dt>Access Controllers:</dt>
                <dd>
                  DMs should only send Controls to agents DAs when the manager
                  is configured with appropriate access to both the agent and
                  the applications being managed.
                </dd>
              </dl>
            </section>
          </section>

          <section numbered="true">
            <name>Pre-Shared Definitions</name>

            <t>
              A consequence of operating in a challenged environment is the
              potential inability to negotiate information in real-time. real time. For
              this reason, the DTNMA requires that managed and managing devices
              operate using pre-shared definitions rather than relying on data
              definition negotiation.
            </t>
                       <t>
              The three types of pre-shared definitions in the DTNMA are the
              DA autonomy model, managed application data models,
              and any runtime data shared by managers and agents.
            </t>

            <dl newline="true" spacing="normal" indent="8"> spacing="normal">
              <dt>Autonomy Model:</dt>
              <dd>
                <t>
                  A DTNMA autonomy model represents the data elements and
                  associated autonomy structures that define the behavior of
                  the agent autonomy engine. A standardized autonomy
                  model allows for individual implementations of DAs, DAs and DMs
                  to interoperate. A standardized model also
                  provides guidance to the design and implementation of both
                  managed and managing applications.
                </t>
              </dd>

               <dt>Application Data Models:</dt>
               <dd>
                  As with other network management architectures, the DTNMA
                  pre-supposes
                  presupposes that managed applications (and services) define
                  their own data models. These data models include the data
                  produced by, and Controls implemented by, the application.
                  These models are expected to be static for individual
                  applications and standardized for applications implementing
                  standard protocols.
               </dd>

               <dt>Runtime Data Stores:</dt> Datastores:</dt>
               <dd>
                  Runtime data stores, datastores, by definition, include data that is
                  defined at runtime. As such, the data is not pre-shared prior
                  to the deployment of DMs and DAs. Pre-sharing in this
                  context means that DMs and DAs are able to define and
                  synchronize data elements prior to their operational use in
                  the system. This synchronization happens during periods of
                  connectivity between DMs and DAs.
               </dd>
            </dl>

         </section>
      </section>
    </section>

    <section anchor="desired-services" numbered="true">
      <name>Desired Services</name>
      <t>
        This section describes the services provided by DTNMA
        components on both managing and managed devices. Many Most
        of the services discussed in this section attempt to provide
        continuous operation of a managed device through periods of
        no connectivity with a managing device.
      </t>

      <section numbered="true">
        <name>Local Monitoring and Control</name>
        <t>
          DTNMA monitoring is associated with some DA autonomy engine. The
          term monitoring "monitoring" implies regular access to information such that
          state changes may be acted upon within some response time period.
        </t>

        <t>
          Predicate autonomy on a managed device should collect state
          associated with the device at regular intervals and evaluate that
          collected state for any changes that require a preventative or
          corrective action. Similarly, this monitoring may cause the device
          to generate one or more reports destined to a managing device.
        </t>

        <t>
          Similar to
          Like monitoring, DTNMA control results in actions by the
          agent to change the state or behavior of the managed
          device. All control in the DTNMA is local control. In cases where
          there exists a timely connection to a manager, DM, received Controls
          are still evaluated and run locally as part of local autonomy. In
          this case, the autonomy stimulus is the receipt of the Control Control, and
          the response is to immediately run the Control. In this way, there
          is never a dependency on a session or other stateful exchange with
          any remote entity.
        </t>
      </section>

      <section numbered="true">
        <name>Local Data Fusion</name>
        <t>
          DTNMA Fusion fusion services produce new data products from existing
          state on the managed device. These fusion products can be anything
          from simple summations of sampled counters to complex calculations
          of behavior over time.
        </t>
        <t>
          Fusion is an important service in the DTNMA because fusion
          products are part of the overall state of a managed device.
          Complete knowledge of this overall state is important for the
          management of the device device, and the predicates of rules on a DA may
          refer to fused data.
        </t>

        <t>
          In-situ
          In situ data fusion is an important function function, as it allows
          for the construction of intermediate summary data, the reduction
          of stored and transmitted raw data, and possibly fewer predicates in rule
          definitions, and otherwise
          definitions; this type of data fusion insulates the data source from
          conclusions drawn from that data.
        </t>
        <t>
          The DTNMA requires fusion to occur on the managed device itself. If
          the network is partitioned such that no connection to a managing
          device is available, then fusion needs to happen locally. Similarly,
          connections to a managing device might not remain active long enough
          for round-trip data exchange or may not have the bandwidth to send
          all sampled data.
        </t>

          <aside>
            <t>
              NOTE: The DTNMA does not restrict the storage and transmission
              of raw (pre-fused) data. Such raw data can be useful for
              debugging managed devices, understanding complex interactions
              and underlying conditions, and tuning for better performance
              and/or better outcomes.
            </t>
          </aside>

      </section>

      <section numbered="true">
        <name>Remote Configuration</name>
        <t>
          DTNMA configuration services update the local configuration
          of a managed device with the intent to impact of impacting the behavior and
          capabilities of that device.
        </t>

        <t>
          The DTNMA configuration service is unique in that the selection of
          managed device configurations occurs as a function of
          the state of the device. This implies that management proxies on
          the device store multiple configuration functions that can be
          applied as needed without consultation from a managing device.
        </t>

        <aside>

          <t>
            This approach differs from other management concepts of selecting
            from multiple datastores. DTNMA configuration functions
            can target individual data elements and can calculate new values
            from local device state.
          </t>
        </aside>

        <t>
          When detecting stimuli, the agent autonomy engine supports
          a mechanism for evaluating whether application monitoring data
          or runtime data values are recent enough to indicate a change of
          state. In cases where data has not been updated recently, it may
          be considered stale and therefore not used to reliably indicate that some
          stimulus has occurred.
        </t>
      </section>

      <section numbered="true">
        <name>Remote Reporting</name>
        <t>
          DTNMA reporting services collect information known to the managed
          device and prepare it for eventual transmission to one or more
          managing devices. The contents of these reports, and the frequency at
          which they are generated, occurs occur as a function of the state of the
          managed device, independent of the managing device.
        </t>

        <t>
          Once generated, it is expected that reports might be queued queued, pending
          a connection back to a managing device. Therefore, reports need to be
          differentiable as a function of the time they were generated.
        </t>

        <aside>
          <t>
            NOTE: When reports are queued pending transmission, the overall
            storage capacity at the queuing device needs to be considered.
            There may be cases where queued reports can be considered expired
            either
            because they have been either queued for too long, long or because
            they have been
            replaced by a newer report. When a report is
            considered expired, it may be considered for removal and, thus,
            never transmitted. This consideration is expected to be part of
            the implementation of the queuing device and not the responsibility of the reporting function within the DTNMA.
          </t>
        </aside>

        <t>
          When reports are sent to a managing device over a challenged
          network, they may arrive out of order due to taking different paths
          through the network or being delayed due to retransmissions. A
          managing device should not infer meaning from the order in which
          reports are received.
        </t>
        <t>
          Reports may or may not be associated with a specific Control. Some
          reports may be annotated with the Control that caused the report to
          be generated. Sometimes, a single report will represent the end
          state of applying multiple Controls.
        </t>

      </section>

      <section numbered="true">
        <name>Authorization</name>
        <t>
          Both local and remote services provided by the DTNMA affect the
          behavior of multiple applications on a managed device and may
          interface with multiple managing devices.
        </t>

        <t>
          Authorization services enforce the potentially complex mapping of
          other DTNMA services amongst managed and managing devices in the
          network. For example, fine-grained access control can determine
          which managing devices receive which reports, and what Controls can
          be used to alter which managed applications.
        </t>

        <t>
          This is particularly beneficial in networks that either deal with either
          multiple administrative entities or overlay networks that cross
          administrative boundaries. Allowlists, blocklists, key-based
          infrastructures, or other schemes may be used for this purpose.
        </t>
      </section>
    </section>

    <section anchor="autonomy_model" numbered="true">
       <name>Logical Autonomy Model</name>
       <t>
          An important characteristic of the DTNMA is the shift in the role
          of a managing device. One way to describe the behavior of the agent
          autonomy engine is to describe the characteristics of the autonomy
          model it implements.
        </t>

        <t>
          This section describes a logical autonomy model in terms of the
          abstract data elements that would comprise the model. Defining
          abstract data elements allows for an unambiguous discussion of
          the behavior of an autonomy model without mandating a particular
          design, encoding, or transport associated with that model.
        </t>

        <section anchor="aut_mod_overview" numbered="true">
          <name>Overview</name>

          <t>
            A managing autonomy capability on a potentially disconnected
            device needs to behave in both an expressive and deterministic way.
            Expressivity
            allows for the model to be configured for a wide range of future
            situations. Determinism allows for the forensic reconstruction of
            device behavior as part of debugging or recovery efforts. It
            also is necessary to ensure predictable behavior.
          </t>

          <aside>
            <t>
              NOTE: The use of predicate logic and a stimulus-response
              system does not conflict with the use of higher-level
              autonomous function functions or the incorporation of machine learning. Machine Learning (ML).
              Specifically, the DTNMA deterministic autonomy model can
              coexist with other autonomous functions managing applications
              and network services.
            </t>
            <t>
              An example of such co-existence coexistence is the use of the DTNMA model
              to ensure that a device stays within safe operating parameters while
              a less deterministic machine learning ML model directs smaller other
              behaviors for the device.
            </t>
          </aside>

          <t>
            The DTNMA autonomy model is a rule-based model in which individual
            rules associate a pre-identified stimulus
            with a pre-configured preconfigured response to that stimulus.
          </t>

          <t>
            Stimuli are identified using one or more predicate logic expressions
            that examine aspects of the state of the managed device. Responses
            are implemented by running one or more procedures on the managed
            device.
          </t>

          <t>
            In its simplest form, a stimulus is a single predicate expression
            of a condition that examines some aspect of the state of the
            managed device. When the condition is met, a predetermined response is
            applied. This behavior can be captured using the construct:
          </t>

          <artwork align="left"><![CDATA[

          <sourcecode name="" type="pseudocode"><![CDATA[            IF <condition 1> THEN <response 1>;
          ]]></artwork> 1>
]]></sourcecode>

          <t>
            In more complex forms, a stimulus may include both a common condition
            shared by multiple rules and a specific condition for each individual rule.
            If the common condition is not met, the evaluation of the specific
            condition of each rule sharing the common condition can be skipped. In
            this way, the total number of predicate evaluations can be reduced.
            This behavior can be captured using the construct:
          </t>

          <artwork align="left"><![CDATA[

          <sourcecode name="" type="pseudocode"><![CDATA[            IF <common condition> THEN
              IF <specific condition 1> THEN <response 1>
              IF <specific condition 2> THEN <response 2>
              IF <specific condition 3> THEN <response 3>
          ]]></artwork>
]]></sourcecode>

          <aside>
            <t>
              NOTE: The DTNMA model remains a stimulus-response system, regardless
              of whether a common condition is part of the stimulus. However,
              it is recommended that implementations incorporate a common
              condition because of the efficiency provided by such a bulk
              evaluation.
            </t>
            <t>
              NOTE: One use of a stimulus "common condition" is to associated associate the
              condition with an on-board onboard event such as the expiring of a timer or
              the changing of a monitored value.
            </t>
          </aside>

            <t>
              NOTE:
              The DTNMA does not prescribe when to evaluate rule stimuli.
              Implementations may choose to evaluate rule stimuli at periodic
              intervals (such as 1Hz 1 Hz or 100Hz). 100 Hz). When stimuli include on-board onboard
              events, implementations may choose to perform an immediate
              evaluation at the time of the event rather than waiting for a
              periodic evaluation.
            </t>
          </aside>

          <t keepWithNext="true">DTNMA Autonomy Model</t>

          <t>The flow of data into and out of the agent autonomy engine is
            illustrated in <xref target="dtnma_aut_model"/>.</t>
          <figure anchor="dtnma_aut_model">
           <name>DTNMA Autonomy Model</name>
            <artwork align="center" name="" type="" alt=""><![CDATA[
 Managed Applications |           DTNMA Agent          | DTNMA Manager
+---------------------+--------------------------------+--------------+
                      |   +---------+                  |
                      |   |  Local  |                  |   Encoded
                      |   | Rule DB |<-------------------- Policy
                      |   +---------+                  |   Expressions
                      |        ^                       |
                      |        |                       |
                      |        v                       |
                      |   +----------+    +---------+  |
    Monitoring Data------>|   Agent  |    | Runtime |  |
                      |   | Autonomy |<-->|  Data  Data-  |<---- Definitions
Application Control<------|  Engine  |    |  Store  store  |  |
                      |   +----------+    +---------+  |
                      |         |                      |
                      |         +-------------------------> Reports
                      |                                |
]]></artwork>
          </figure>

          <t>
            The flow of data into and out of
            In the agent autonomy engine is
            illustrated model shown in <xref target="dtnma_aut_model"/>. In this model, target="dtnma_aut_model"/>,
            the autonomy engine stores the combination of stimulus
            conditions and associated responses as a set of "rules" in a
            rules
            rule database. This database is updated through the execution of
            the autonomy engine and as configured from policy statements
            received by managers. DMs.
          </t>
          <t>
            Stimuli are detected by examining the state of applications as
            reported through application monitoring interfaces and through
            any locally-derived locally derived data. Local data is calculated in accordance
            with definitions also provided by managers DMs as part of the runtime
            data store.
            datastore.
          </t>
          <t>
            Responses to stimuli may include updates to the rules rule database,
            updates to the runtime data store, datastore, Controls sent to applications,
            and the generation of reports.
          </t>

        </section>

        <section numbered="true">
          <name>Model Characteristics</name>

          <t>
            There are several practical challenges to the implementation of a
            distributed rule-based system.  Large numbers of rules may be
            difficult to understand, deconflict, and debug. Rules whose
            conditions are given by fused or other dynamic data may require
            data logging and reporting for deterministic offline analysis. Rule differences
            across managed devices may lead to oscillating effects. This section
            identifies those characteristics of an autonomy model that might
            help implementations mitigate some of these challenges.
          </t>

          <t>
            There are a number of ways to represent data values, and many
            data modeling languages exist for this purpose. When
            considering how to model data in the context of the DTNMA
            autonomy model model, there are some modeling features that should be
            present to enable functionality. There are also some modeling
            features that should be prevented to avoid ambiguity.
          </t>
          <t>
            Traditional
            Conventional network management approaches favor flexibility in
            their data models. The DTNMA stresses deterministic behavior
            that supports forensic analysis of agent activities "after the
            fact". As such, the following statements should be true of all
            data representations relating to DTNMA autonomy.
          </t>

          <dl>
            <dt>Strong Typing:</dt>
            <dd>
              The predicates and expressions that comprise
              the autonomy services in the DTNMA should require strict data
              typing. This avoids errors associated with implicit data
              conversions and helps detect misconfiguration. misconfigurations.
            </dd>
            <dt>Acyclic Dependency:</dt>
            <dd>
              Many dependencies exist in an autonomy model,
              particularly when combining individual expressions or
              results to create complex behaviors. Implementations that
              conform to the DTNMA need to prevent circular dependencies.
            </dd>
            <dt>Fresh Data:</dt>
            <dd>
              Autonomy models operating on data values
              presume that their data inputs represent the actionable state
              of the managed device. If a data value has failed to be
              refreshed within a time period, autonomy might incorrectly
              infer an operational state. Regardless of whether a data
              value has changed, DTNMA implementations should provide some
              indicator of whether the data value is "fresh" "fresh", i.e., meaning that
              it still represents the current state of the device.
            </dd>
            <dt>Pervasive Parameterization:</dt>
            <dd>
              Where possible, autonomy
              model objects should support parameterization to allow for
              flexibility in the specification. Parameterization allows for
              the definition of fewer unique model objects and also can
              support the substitution of local device state when
              exercising device control or data reporting.
            </dd>
            <dt>Configurable Cardinality:</dt>
            <dd>
              The number of data values that can
              be supported in a given implementation is finite. For devices
              operating in challenged environments, the number of supported
              objects may be far fewer than the number of objects that which can be supported by
              devices in well-resourced environments. DTNMA implementations
              should define limits to the number of supported objects that
              can be active in a system at one time, as a function of the
              resources available to the implementation.
            </dd>
            <dt>Control-Based Updates:</dt>
            <dd>
              The agent autonomy engine changes the
              state of the managed device by running Controls on the device.
              This is different from approaches where the behavior of
              a managed device is influenced by updating configuration
              values, such as in a table or datastore. Altering behavior via
              one or more Controls allows checking all pre-conditions preconditions before
              making changes as well as providing more granularity in the
              way in which the device is updated. Where necessary, Controls
              can be defined to perform bulk updates of configuration data
              so as not to lose that update modality. One important
              update pre-condition precondition is that the system is not
              performing an action that would prevent the update (such as
              currently applying a competing update).
            </dd>
          </dl>
        </section>

        <section numbered="true">
          <name>Data Value Representation</name>
          <t>
            The expressive representation of simple data values is fundamental to
            the successful construction and evaluation of predicates in the
            DTNMA autonomy model. When defining such values, there are
            useful distinctions regarding how values are identified
            and whether values are generated in a way that is internal or external to the
            autonomy model.
          </t>

          <t>
            A DTNMA data value should combine a base type
            (e.g., integer, real, string) representation with relevant semantic
            information. Base types are used for proper storage and encoding.
            Semantic information allows for additional typing, constraint definitions,
            and mnemonic naming. This expanded
            definition of data value values allows for better predicate construction
            and evaluation construction,
            better evaluation, and early type checking.
          </t>

          <t>
            Data values may further be annotated based on whether their value
            is the result of a DA calculation or the result of some external
            process on the managed device. For example, operators may with wish to
            know which values can be updated by actions on the DA versus which
            values (such as sensor readings) cannot be reliably changed because
            they are calculated in a way that is external to the DA.
          </t>
      </section>

      <section numbered="true">
        <name>Data Reporting</name>
        <t>
          The DTNMA autonomy model should, as required, report on the
          state of its managed device (to include the state of the
          model itself). This reporting should be done as a function of
          the changing state of the managed device, independent of the
          connection to any managing device. Queuing reports allows for
          later forensic analysis of device behavior, which behavior; this feature is a
          desirable property of DTNMA management.
        </t>

        <t>
          DTNMA data reporting consists of the production of some
          data report instance conforming to a data report schema. The use
          of schemas allows a report instance to identify the schema to which
          it conforms instead of carrying the structure in the report itself.
          This approach can significantly reduce the size of generated reports.
        </t>

        <aside>

          <t>
            NOTE:
            The DTNMA data reporting concept is intentionally distinct
            from the concept of exchanging data stores datastores across a network. It is
            envisioned that a DA might generate a data report instance of a
            data report schema at regular intervals or in response to local
            events. In this model, many report schemas may be defined to capture
            unique, relevant combinations of known data values rather than
            sending bulk data stores datastores off-platform for analysis.
          </t>

        <aside>
          <t>
            NOTE: It is not required that data report schemas be tabular in
            nature. Individual implementations might define tabular
            schemas for table-like data and other report schemas for more
            heterogeneous reporting.
          </t>
        </aside>

      </section>

      <section numbered="true" anchor="ctrl_exec">
        <name>Command Execution</name>
        <t>
          The agent autonomy engine requires that managed devices issue
          commands on themselves as if they were otherwise being controlled
          by a managing device. The DTNMA implements commanding through the
          use of Controls and macros.
        </t>

        <t>
          Controls represent parameterized, predefined procedures run by the DA
          either as directed by the DM or as part of a rule response from the
          DA autonomy engine. Macros represent ordered sequences of Controls.
        </t>

        <t>
          Controls are conceptually similar to RPCs in
          that they represent parameterized functions run on the managed
          device. However, they are conceptually dissimilar from to RPCs in that
          they do not have a concept of a return code because they operate
          over an asynchronous transport. The concept of a return code in an RPC
          implies a synchronous relationship between the caller of the
          procedure and the procedure being called, which might not be
          possible within the DTNMA.
        </t>

        <t>
          The success or failure of a Control may be handled locally by the
          agent autonomy engine. Local error handling is particularly important
          in this architecture architecture, given the potential for long periods of
          disconnectivity between a DA and a DM. The failure
          of one or more Controls is part of the state of the DA and can be used to trigger rules within the DA autonomy engine.
        </t>

        <t>
          The impact of a Control is externally observable via the generation
          and eventual examination of data reports produced by the managed device.
        </t>

        <t>
          The failure of certain Controls might leave a managed device in an
          undesired
          undesirable state. Therefore, it is important
          that there be consideration for Control-specific recovery
          mechanisms (such as a rollback or safing mechanism). When a
          Control that is part of a macro (such as in an autonomy response)
          fails, there may be a need to implement a safe state for the
          managed device based on the nature of the failure.
        </t>

        <aside>
          <t>
            NOTE: The use of the term Control "Control" in the DTNMA is derived in
            part from the concept of Command and Control (C2) (C2), where control
            implies the operational instructions undertaken to
            implement (or maintain) a commanded objective. The DA
            autonomy engine implements controls on a managed device to allow it to fulfill some commanded objective known by a (possibly disconnected) managing device.
          </t>

          <t>
            For example, a device might be commanded to maintain a safe internal thermal environment. Actions taken by a DA to manage heaters, louvers, and other temperature-effecting temperature-affecting components are controls taken in service of that commanded objective.
          </t>
        </aside>

      </section>

      <section numbered="true">
        <name>Predicate Autonomy Rules</name>

        <t>
          As discussed in <xref target="aut_mod_overview"/>, the DTNMA
          rule-based stimulus-response system associates stimulus detection with a
          predetermined response. Rules may be categorized based on whether their
          (1)&nbsp;their
          stimuli include generic statements of managed device state or whether they
          (2)&nbsp;they
          are optimized to only consider the passage of time on the device.
        </t>

        <t>
          State-based rules are those whose stimulus is based on the evaluated
          state of the managed device. Time-based rules are a unique subset of
          state-based rules whose stimulus is given only by a time-based event.
          Implementations might create different structures and evaluation
          mechanisms for these two different types of rules to achieve more
          efficient processing on a platform.
        </t>
      </section>
    </section>

    <section anchor="use-cases" numbered="true">
      <name>Use Cases</name>
      <t>
        Using the autonomy model defined in <xref target="autonomy_model"/>,
        this section describes flows through sample configurations conforming to the
        DTNMA. These use cases illustrate remote configuration, local monitoring and
        control, support for multiple manager support, DMs, and data fusion.
      </t>

      <section numbered="true">
        <name>Notation</name>
          <t>
            The use cases presented in this section are documented with a
            shorthand notation to describe the types of data sent between
            managers and agents. This notation, outlined in
            <xref target="uc_notation"/>, leverages the definitions
            of the autonomy model components defined in <xref target="autonomy_model"/>.
          </t>

          <table anchor="uc_notation" align="center">
             <name>Terminology</name>
             <thead>
                <tr>
                   <th align="center">Term</th>
                   <th align="center">Definition</th>
                   <th align="center">Example</th>
                </tr>
             </thead>
             <tbody>

                <tr>
                   <td align="center">EDD#</td>
                   <td align="center">Externally Defined Data - -- a data value defined in a way that is external to the DA. </td>
                   <td align="center">EDD1, EDD2</td>
                </tr>

                <tr>
                   <td align="center">V#</td>
                   <td align="center">Variable - -- a data value defined in a way that is internal to the DA.</td>
                   <td align="center">V1 = EDD1 + 7</td>
                </tr>

                <tr>
                   <td align="center">EXPR</td>
                   <td align="center">Predicate expression - -- used to define a rule stimulus.</td>
                   <td align="center">V1 &gt; 5</td>
                </tr>

                <tr>
                    <td align="center">ID</td>
                    <td align="center">DTNMA Object Identifier.</td>
                    <td align="center">V1, EDD2</td>
                </tr>

                <tr>
                   <td align="center">ACL#</td>
                   <td align="center">Enumerated Access Control List.</td>
                   <td align="center">ACL1</td>
                </tr>
                <tr>
                   <td align="center">DEF(ACL,ID,EXPR)</td> align="center">DEF(ACL,&nbsp;ID, EXPR)</td>
                   <td align="center">Define ID "ID" from expression. Allow managers DMs in ACL to see this ID.</td>
                   <td align="center">DEF(ACL1, V1, EDD1 + EDD2)</td>
                </tr>
                <tr>
                   <td align="center">PROD(P,ID)</td> align="center">PROD(P, ID)</td>
                   <td align="center">Produce ID "ID" according to predicate
                   P. P may be a time period (1s) (1 second, or 1s) or an expression (EDD1 &gt; 10).</td>
                   <td align="center">PROD(1s, EDD1)</td>
                </tr>
                <tr>
                   <td align="center">RPT(ID)</td>
                   <td align="center">A report instance containing data named ID.</td> "ID".</td>
                   <td align="center">RPT(EDD1)</td>
                </tr>
             </tbody>
          </table>

          <t>
            These notations do not imply any implementation approach. They
            only provide a succinct syntax for expressing the data flows in
            the use case diagrams in the remainder of this section.
          </t>
        </section>

        <section anchor="serial_mgmt" numbered="true">
          <name>Serialized Management</name>
          <t>
              This nominal configuration shows a single DM interacting with multiple
              DAs. The control flows flow for this scenario are is outlined in
              <xref target="serial_mgmt_ctrl_flow"/>.
          </t>

          <t keepWithNext="true">Serialized Management Control Flow</t>

          <figure anchor="serial_mgmt_ctrl_flow">
           <name>Serialized Management Control Flow</name>
             <artwork align="center" name="" type="" alt=""><![CDATA[
+-----------+ alt=""><![CDATA[+-----------+           +---------+           +---------+
|   DTNMA   |           |  DTNMA  |           |  DTNMA  |
| Manager A |           | Agent A |           | Agent B |
+----+------+           +----+----+           +----+----+
    |                       |                     |
    |-----PROD(1s, EDD1)--->|                     | (1)
    |----------------------------PROD(1s, EDD1)-->|
    |                       |                     |
    |                       |                     |
    |<-------RPT(EDD1)------|                     | (2)
    |<----------------------------RPT(EDD1)-------|
    |                       |                     |
    |                       |                     |
    |<-------RPT(EDD1)------|                     |
    |<----------------------------RPT(EDD1)-------|
    |                       |                     |
    |                       |                     |
    |<-------RPT(EDD1)------|                     |
    |<----------------------------RPT(EDD1)-------|
    |                       |                     |
]]></artwork>
          </figure>
          <t keepWithPrevious="true">
             In a serialized management scenario, a single DM interacts with multiple DAs.
          </t>

          <t>
            In this figure, the DTNMA Manager DM A sends a policy to DTNMA Agents DAs
            A and B to report the value of an EDD (EDD1) every second in (step 1).
            Each DA receives this policy and configures their respective
            autonomy engines for this production. Thereafter, Thereafter (step 2) 2), each
            DA produces a report containing data element EDD1 and sends
            those reports EDD1; each such report is
            then sent back to the DM.
          </t>
          <t>
            This behavior continues without any additional communications
            from the DM.
          </t>
       </section>

       <section numbered="true">
        <name>Intermittent Connectivity</name>
        <t>
          Building from on the nominal configuration discussed in <xref target="serial_mgmt"/>,
          this scenario shows a challenged network in which connectivity between
          DTNMA Agent
          DA B and the DM is temporarily lost. Control flows The control flow for this case
          are
          is outlined in <xref target="challenged_serial_mgmt_ctrl_flow"/>.
          </t>

          <t keepWithNext="true">Challenged Management Control Flow</t>

          <figure anchor="challenged_serial_mgmt_ctrl_flow">
           <name>Challenged Management Control Flow</name>
             <artwork align="center" name="" type="" alt=""><![CDATA[
+-----------+ alt=""><![CDATA[+-----------+           +---------+           +---------+
|   DTNMA   |           |  DTNMA  |           |  DTNMA  |
| Manager A |           | Agent A |           | Agent B |
+----+------+           +----+----+           +----+----+
    |                       |                     |
    |-----PROD(1s, EDD1)--->|                     | (1)
    |----------------------------PROD(1s, EDD1)-->|
    |                       |                     |
    |                       |                     |
    |<-------RPT(EDD1)------|                     | (2)
    |<----------------------------RPT(EDD1)-------|
    |                       |                     |
    |                       |                     |
    |<-------RPT(EDD1)------|                     |
    |<----------------------------RPT(EDD1)-------|
    |                       |                     |
    |                       |                     |
    |<-------RPT(EDD1)------|                     |
    |                       |            RPT(EDD1)| (3)
    |                       |                     |
    |                       |                     |
    |<-------RPT(EDD1)------|                     |
    |                       |            RPT(EDD1)| (4)
    |                       |                     |
    |                       |                     |
    |<-------RPT(EDD1)------|                     |
    |<----------------RPT(EDD1), RPT(EDD1)--------| (5)
    |                       |                     |
]]></artwork>
          </figure>
          <t keepWithPrevious="true">
            In a challenged network, DAs store reports reports, pending a transmit opportunity.
          </t>
          <t>
            In this figure, DTNMA Manager DM A sends a policy to DTNMA Agents DAs A
            and B to produce an EDD (EDD1) every second in (step 1). Each DA
            receives this policy and configures their respective autonomy
            engines for this production. Produced reports are transmitted when
            there is connectivity between the DA and DM (step 2).
          </t>
          <t>
            At some point, DTNMA Agent DA B loses the ability to transmit in the
            network (steps 3 and 4). During this time period, DA B continues
            to produce reports, but they are queued for transmission. This
            queuing might be done by the DA itself or by a supporting
            transport such as BP. Eventually (and before the next scheduled
            production of EDD1), DTNMA Agent DA B is able to transmit in the
            network again (step 5) 5), and all queued reports are sent at that
            time. DTNMA Agent DA A maintains connectivity with the DM during
            steps 3-5, 3-5 and continues to send reports as they are generated.
          </t>
       </section>

       <section numbered="true">
        <name>Open-Loop Reporting</name>
        <t>
          This scenario illustrates the DTNMA open-loop control paradigm, where DAs
          manage themselves in accordance with policies provided by DMs, DMs and provide
          reports to DMs based on these policies.
        </t>
        <t>
          The control flow shown in <xref target="consolidated_mgmt_ctrl_flow"/>, target="consolidated_mgmt_ctrl_flow"/>
          includes an example of data fusion, where multiple policies configured by a
          DM result in a single report from a DA.
        </t>

        <t keepWithNext="true">Consolidated Management Control Flow</t>

        <figure anchor="consolidated_mgmt_ctrl_flow">
         <name>Consolidated Management Control Flow</name>
           <artwork align="center" name="" type="" alt=""><![CDATA[
+-----------+ alt=""><![CDATA[+-----------+           +---------+           +---------+
|   DTNMA   |           |  DTNMA  |           |  DTNMA  |
| Manager A |           | Agent A |           | Agent B |
+----+------+           +----+----+           +----+----+
    |                       |                     |
    |-----PROD(1s, EDD1)--->|                     | (1)
    |----------------------------PROD(1s, EDD1)-->|
    |                       |                     |
    |                       |                     |
    |<-------RPT(EDD1)------|                     | (2)
    |<----------------------------RPT(EDD1)-------|
    |                       |                     |
    |                       |                     |
    |----------------------------PROD(1s, EDD2)-->| (3)
    |                       |                     |
    |                       |                     |
    |<-------RPT(EDD1)------|                     |
    |<--------------------------RPT(EDD1,EDD2)----|
    |<-------------------------RPT(EDD1, EDD2)----| (4)
    |                       |                     |
    |                       |                     |
    |<-------RPT(EDD1)------|                     |
    |<--------------------------RPT(EDD1,EDD2)----|
    |<-------------------------RPT(EDD1, EDD2)----|
    |                       |                     |
]]></artwork>
        </figure>
        <t keepWithPrevious="true">
          A many-to-one mapping between management policy and device state reporting
          is supported by the DTNMA.
        </t>
        <t>
          In this figure, DTNMA Manager DM A sends a policy statement in the form of a
          rule to DTNMA Agents DAs A and B, which instructs the DAs to produce a report
          with
          for EDD1 every second (step 1). Each DA receives this policy, which is
          stored in its respective Rule Database, rule database, and configures its Autonomy Engine. autonomy engine.
          Reports are transmitted by each DA when produced (step 2).
        </t>
        <t>
          At a later time, DTNMA Manager DM A sends an additional policy to
          DTNMA Agent
          DA B, requesting the production of a report for EDD2 every second
          (step 3). This policy is added to DTNMA Agent DA B's Rule Database. rule database.
        </t>
        <t>
          Following this policy update, DTNMA Agent DA A will continue to produce EDD1 EDD1,
          and DTNMA Agent DA B will produce both EDD1 and EDD2 (step 4). However, DTNMA
          Agent
          DA B may provide these values to the DM in a single report rather than as
          2
          two independent reports. In this way, there is no direct mapping between the
          single
          consolidated report reports sent by DTNMA Agent DA B (step 4) and the two
          different policies sent to DTNMA Agent DA B that caused that report to be
          generated (steps 1 and 3).
        </t>
      </section>

      <section numbered="true">
        <name>Multiple Administrative Domains</name>
        <t>
          The managed applications on a DA may be controlled by different
          administrative entities in a network. The DTNMA allows DAs to
          communicate with multiple DMs in the network, such as in cases
          where there is one DM per administrative domain.
        </t>
        <t>
          Whenever a DM sends a policy expression to a DA, that policy
          expression may be associated with authorization information. One
          method of representing this is an ACL.
        </t>
        <aside>

          <t>
            The use of an ACL in this use case does not imply that the DTNMA
            requires ACLs to annotate policy expressions. ACLs and their
            representation in this context are for example purposes only.
          </t>
        </aside>

        <t>
          The ability of one DM to access the results of policy
          expressions configured by some other DM will be limited to the
          authorization annotations of those policy expressions.
        </t>

        <t>
          An example of multi-manager authorization is illustrated in
          <xref target="multi_mgmt_ctrl_flow"/>.
        </t>

        <t keepWithNext="true">Multiplexed Management Control Flow</t>

          <figure anchor="multi_mgmt_ctrl_flow">
           <name>Multiplexed Management Control Flow</name>
            <artwork align="center" name="" type="" alt=""><![CDATA[
+-----------+               +---------+                 +-----------+
|   DTNMA   |               |  DTNMA  |                 |   DTNMA   |
| Manager A |               | Agent A |                 | Manager B |
+-----+-----+               +----+----+                 +-----+-----+
    |                          |                            |
     |---DEF(ACL1,V1,EDD1*2)--->|<---DEF(ACL2,
    |--DEF(ACL1, V1, EDD1*2)-->|<---DEF(ACL2, V2, EDD2*2)---| (1)
    |                          |                            |
    |---PROD(1s, V1)---------->|<---PROD(1s, V2)------------| (2)
    |                          |                            |
    |<--------RPT(V1)----------|                            | (3)
    |                          |--------RPT(V2)------------>|
    |<--------RPT(V1)----------|                            |
    |                          |--------RPT(V2)------------>|
    |                          |                            |
    |                          |<---PROD(1s, V1)------------| (4)
    |                          |                            |
    |                          |----ERR(V1 no perm.)------->|                          |---ERR(V1 not permitted)--->|
    |                          |                            |
     |--DEF(NULL,V3,EDD3*3)---->|
    |--DEF(NULL, V3, EDD3*3)-->|                            | (5)
    |                          |                            |
    |---PROD(1s, V3)---------->|                            | (6)
    |                          |                            |
    |                          |<----PROD(1s, V3)-----------|
    |                          |                            |
    |<--------RPT(V3)----------|--------RPT(V3)------------>| (7)
    |<--------RPT(V1)----------|                            |
    |                          |--------RPT(V2)------------>|
    |<-------RPT(V3)-----------|--------RPT(V3)------------>|
    |<-------RPT(V1)-----------|                            |
    |                          |--------RPT(V2)------------>|
]]></artwork>
          </figure>

          <t keepWithPrevious="true">
             Multiple DMs may interface with a single DA, particularly in complex
             networks.
          </t>
          <t>
            In this figure, both DTNMA Managers DM A and DM B send policies to DTNMA
            Agent
            DA A (step 1). DM A defines a variable (V1) whose value is given
            by the mathematical expression (EDD1 * 2) and is associated with an
            ACL (ACL1) that restricts access to V1 to DM A only. Similarly, DM B
            defines a variable (V2) whose value is given by the mathematical
            expression (EDD2 * 2) and is associated with an ACL (ACL2) that restricts
            access to V2 to DM B only.
          </t>
          <t>
            Both DTNMA Managers DM A and DM B also send policies to DTNMA Agent DA A to
            report on the values of their variables at 1 second 1-second intervals (step 2).
            Since DM A can access V1 and DM B can access V2, there is
            no authorization issue with these policies policies, and they are both
            accepted by the autonomy engine on Agent DA A. Agent DA A produces
            reports as expected, sending them to their respective managers
            (step 3).
          </t>
          <t>
            Later (step 4) 4), DM B attempts to configure DA A to also
            report to it the value of V1. Since DM B does not have
            authorization to view this variable, DA A does not include this
            in the configuration of its autonomy engine and, engine; instead, some
            indication of a permission error is included in any regular
            reporting back to DM B.
          </t>
          <t>
            DM A also sends a policy to Agent DA A (step 5) that defines a
            variable (V3) whose value is given by the mathematical expression
            (EDD3 * 3) and is not associated with an ACL, indicating that any
            DM can access V3. In this instance, both DM A and DM B can
            then send policies to DA A to report the value of V3 (step 6).
            Since there is no authorization restriction on V3, these policies
            are accepted by the autonomy engine on Agent A DA A, and reports are
            sent to both DM A and DM B over time (step 7).
          </t>
       </section>

       <section numbered="true">
        <name>Cascading Management</name>
        <t>
          There are times where when a single network device may serve as both
          a DM for other DAs in the network and, itself, as a
          device managed by someone else. This may be the case on nodes
          serving as gateways or proxies. The DTNMA accommodates this case by
          allowing a single device to run both a DA and a DM.
        </t>
        <t>
          An example of this configuration is illustrated in
          <xref target="fusion_ctrl_flow"/>.
        </t>

        <t keepWithNext="true">Cascading Management Control Flow</t>

        <figure anchor="fusion_ctrl_flow">
         <name>Cascading Management Control Flow</name>
          <artwork align="center" name="" type="" alt=""><![CDATA[
               ---------------------------------------
               |                Node B               |
               |                                     |
+-----------+  |   +-----------+       +---------+   |    +---------+
|   DTNMA   |  |   |   DTNMA   |       |  DTNMA  |   |    |  DTNMA  |
| Manager A |  |   | Manager B |       | Agent B |   |    | Agent C |
+---+-------+  |   +-----+-----+       +----+----+   |    +----+----+
    |          |         |                  |        |         |
    |--------------DEF(NULL,V0,EDD1+EDD2)-->|
    |----------DEF(NULL, V0, EDD1 + EDD2)-->|        |         | (1)
    |--------------PROD(1s,V0)------------->|
    |-------------PROD(1s, V0)------------->|        |         |
    |          |         |                  |        |         |
    |          |         |--PROD(1s,EDD1)-->|         |-PROD(1s, EDD1)-->|        |         | (2)
    |          |         |---------------------PROD(1s,EDD2)-->|         |--------------------PROD(1s, EDD2)-->| (2)
    |          |         |                  |        |         |
    |          |         |                  |        |         |
    |          |         |<----RPT(EDD1)----|        |         | (3)
    |          |         |<--------------------RPT(EDD2)-------| (3)
    |          |         |                  |        |         |
    |<-------------RPT(V0)------------------|        |         | (4)
    |          |         |                  |        |         |
    |          |         |                  |        |         |
               |                                     |
               |                                     |
               ---------------------------------------
]]></artwork>
        </figure>

        <t keepWithPrevious="true">
          A device can operate as both a DTNMA Manager DM and an Agent. a DA.
        </t>
        <t>
          In this example, we presume that DA B is able to sample a
          given EDD (EDD1) and that DA C is able to sample a different
          EDD (EDD2). Node B houses DM B (which controls DA C) and DA B
          (which is controlled by DM A). DM A must periodically receive
          some new value that is calculated as a function of both EDD1
          and EDD2.
        </t>

        <t>
          First, DM A sends a policy to DA B to define a variable (V0) whose value
          is given by the mathematical expression (EDD1 + EDD2) without a
          restricting ACL. Further, DM A sends a policy to DA B to report on
          the value of V0 every second (step 1).
        </t>

        <t>
          DA B needs the ability to monitor both EDD1 and EDD2. EDD2 to produce V0.
          DA B is able to sample EDD1, so DM B sends a policy to DA B to report on
          the value of EDD1.
          However, the only way to receive EDD2 values is to have them
          reported back to Node B by DA C and included in the Node B
          runtime data stores. datastores. Therefore, DM B also sends a policy to DA C to
          report on the value of EDD2 (step 2).
        </t>
        <t>
          DA B receives the policy in its autonomy engine and produces
          reports on the value of EDD2 every second.  Similarly, DA C
          receives the policy in its autonomy engine and produces reports on the
          value of EDD2 every second (step 3).
        </t>
        <t>
          DA B may locally sample EDD1 and EDD2 and uses that to compute
          values of V0 and report on those values at regular intervals to DM A
          (step 4).
        </t>
        <t>
          While a trivial example, the mechanism of associating fusion with
          the Agent DA function rather than the Manager DM function scales with
          fusion complexity. Within the DTNMA, DAs and DMs are not required to
          be separate software implementations. There may be a single software
          application running on Node B implementing both DM B and DA B roles.
        </t>
      </section>
    </section>

   <section anchor="IANA"  numbered="true">
      <name>IANA Considerations</name>
      <t>
        This document requires has no IANA actions.
      </t>
   </section>

   <section anchor="Security"  numbered="true">
      <name>Security Considerations</name>
      <t>
        Security within a DTNMA exists in at least the following two layers: security
        in the data model and security in the messaging and encoding of the
        data model.
      </t>

      <t>
        Data model security refers to the validity and accessibility of data
        elements. For example, a data element might be available to certain DAs or DMs in a system, whereas the same data element may be hidden from other DAs or DMs. Both verification and authorization mechanisms
        at DAs and DMs are important to achieve this type of security.
      </t>

      <aside>
        <t>
          NOTE: One way to provide finer-grained application security is
          through the use of Access Control Lists (ACLs) ACLs that would be defined
          as part of the configuration of DAs and DMs. It is expected that
          many common data model tools provide mechanisms for the definition
          of ACLs and best practices for their operational use.
        </t>
      </aside>

      <t>
         The exchange of information between and amongst DAs and DMs in the
         DTNMA is expected to be accomplished through some secured messaging
         transport.
      </t>
   </section>
</middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <!-- -<references title="Normative References">

    </references> -->
  <references>
      <name>Informative References</name>
      <xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2578.xml'/> href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2578.xml'/>
      <xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3165.xml'/> href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3165.xml'/>
      <xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2982.xml'/> href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2982.xml'/>
      <xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3410.xml'/> href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3410.xml'/>
      <xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3411.xml'/> href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3411.xml'/>
      <xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3414.xml'/> href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3414.xml'/>
      <xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3416.xml'/> href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3416.xml'/>
      <xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3417.xml'/> href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3417.xml'/>
      <xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3418.xml'/> href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3418.xml'/>
      <xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4838.xml'/> href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4838.xml'/>
      <xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4949.xml'/> href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4949.xml'/>
      <xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6353.xml'/> href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6353.xml'/>
      <xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5591.xml'/> href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5591.xml'/>
      <xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5592.xml'/> href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5592.xml'/>
      <xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5652.xml'/> href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5652.xml'/>
      <xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6241.xml'/> href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6241.xml'/>
      <xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6242.xml'/> href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6242.xml'/>
      <xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6991.xml'/> href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6991.xml'/>
      <xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7228.xml'/> href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7228.xml'/>
      <xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7252.xml'/> href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7252.xml'/>
      <xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9113.xml'/> href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9113.xml'/>
      <xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7575.xml'/> href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7575.xml'/>
      <xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7589.xml'/> href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7589.xml'/>
      <xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7950.xml'/> href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7950.xml'/>
      <xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7951.xml'/> href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7951.xml'/>
      <xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8040.xml'/> href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8040.xml'/>
      <xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8199.xml'/> href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8199.xml'/>
      <xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8294.xml'/> href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8294.xml'/>
      <xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8341.xml'/> href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8341.xml'/>
      <xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8368.xml'/> href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8368.xml'/>
      <xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8342.xml'/> href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8342.xml'/>
      <xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8639.xml'/> href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8639.xml'/>
      <xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8641.xml'/> href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8641.xml'/>
      <xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8990.xml'/> href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8990.xml'/>
      <xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8993.xml'/> href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8993.xml'/>
      <xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9171.xml'/> href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9171.xml'/>
      <xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9172.xml'/> href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9172.xml'/>
      <xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9254.xml'/>
      <xi:include href='http://xml2rfc.tools.ietf.org/public/rfc/bibxml-ids/reference.I-D.rfernando-protocol-buffers.xml'/>
      <xi:include href='http://xml2rfc.tools.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-core-sid.xml'/> href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9254.xml'/>

<!-- draft-rfernando-protocol-buffers (Expired)
     "Long way" to fix date -->
<reference anchor="PROTOCOL-BUFFERS">
   <front>
      <title>Encoding rules and MIME type for Protocol Buffers</title>
      <author initials="S." surname="Stuart" fullname="Stephen Stuart">
         <organization>Google</organization>
      </author>
      <author initials="R." surname="Fernando" fullname="Rex Fernando">
         <organization>Cisco</organization>
      </author>
      <date month="October" day="8" year="2012" />
   </front>
   <seriesInfo name="Internet-Draft" value="draft-rfernando-protocol-buffers-00" />
</reference>

<!-- draft-ietf-core-sid / RFC 9595 (published) -->
      <xi:include href='http://xml2rfc.tools.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-core-comi.xml'/> href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9595.xml'/>

<!-- draft-ietf-core-comi (I-D Exists)
     "Long way" to fix one surname and add four "editor" entries -->
<reference anchor="ASN.1"> anchor="CORE-COMI">
   <front>
          <title>
Information processing systems - Open Systems Interconnection
      <title>CoAP Management Interface (CORECONF)</title>
      <author initials="M." surname="Veillette" fullname="Michel Veillette" role="editor">
         <organization>Trilliant Networks Inc.</organization>
      </author>
      <author initials="P." surname="van der Stok" fullname="Peter van der Stok" role="editor">
         <organization>consultant</organization>
      </author>
      <author initials="A." surname="Pelov" fullname="Alexander Pelov" role="editor">
         <organization>IMT Atlantique</organization>
      </author>
      <author initials="A." surname="Bierman" fullname="Andy Bierman">
         <organization>YumaWorks</organization>
      </author>
      <author initials="C." surname="Bormann" fullname="Carsten Bormann" role="editor">
         <organization>Universität Bremen TZI</organization>
      </author>
      <date month="July" day="23" year="2024" />
   </front>
   <seriesInfo name="Internet-Draft" value="draft-ietf-core-comi-18" />
</reference>

      <reference anchor="ASN.1" target="https://www.itu.int/rec/T-REC-X.680">
        <front>
          <title>Information technology -
Specification of Abstract Syntax Notation One (ASN.1)
          </title>
          <seriesInfo name="International Standard" value="8824"/> (ASN.1): Specification of basic notation</title>
          <author>
            <organization>International Organization for Standardization</organization>
            <organization>ITU-T</organization>
          </author>
          <date month="December" year="1987"/> month="February" year="2021"/>
        </front>
          <seriesInfo name="ITU-T Recommendation" value="X.680"/>
          <seriesInfo name="ISO/IEC" value="8824-1:2021"/>
      </reference>

      <reference anchor="DART" target="https://ieeexplore.ieee.org/abstract/document/10207457">
        <front>
          <title>
The
          <title>The DART Autonomy System
          </title> System</title>
          <author fullname="B. Teresa Tropf">
            <organization>The Johns Hopkins Applied Physics Laboratory</organization>
          </author>
          <author fullname="Musad Haque">
            <organization>The Johns Hopkins Applied Physics Laboratory</organization>
          </author>
          <author fullname="Neda Behrooz">
            <organization>The Johns Hopkins Applied Physics Laboratory</organization>
          </author>
          <author fullname="Christopher Krupiarz">
            <organization>The Johns Hopkins Applied Physics Laboratory</organization>
          </author>
          <date month="August" year="2023"/>
        </front>
      <seriesInfo name="DOI" value="10.1109/SMC-IT56444.2023.00020"/>
      </reference>

      <reference anchor="NEW-HORIZONS" target="https://www.sciencedirect.com/science/article/pii/S0094576507000604">
        <front>
          <title>
Autonomous safeing and fault protection for the New Horizons mission to Pluto
          </title>
          <author fullname="Robert C. Moore">
            <organization>The Johns Hopkins Applied Physics Laboratory</organization>
            <address>
              <email>Robert.Moore@jhuapl.edu</email>
            </address>
          </author>
          <date month="March" month="August" year="2007"/>
        </front>
        <refcontent>Acta Astronautica, Volume 61, Issues 1-6, June-August 2007, Pages 398-405</refcontent>
        <seriesInfo name="DOI" value="10.1016/j.actaastro.2007.01.009"/>
      </reference>

      <reference anchor="gNMI" target="https://www.openconfig.net/docs/gnmi/gnmi-specification/">
        <front>
          <title>
gRPC
          <title>gRPC Network Management Interface (gNMI)
          </title>
          <author>
            <organization>OpenConfig</organization> (gNMI)</title>
          <author initials="P." surname="Borman" fullname="Paul Borman">
           <organization/>
	  </author>
          <author initials="M." surname="Hines" fullname="Marcus Hines">
           <organization/>
	  </author>
          <author initials="C." surname="Lebsack" fullname="Carl Lebsack">
           <organization/>
	  </author>
          <author initials="C." surname="Morrow" fullname="Chris Morrow">
           <organization/>
	  </author>
          <author initials="A." surname="Shaikh" fullname="Anees Shaikh">
           <organization/>
	  </author>
          <author initials="R." surname="Shakir" fullname="Rob Shakir">
           <organization/>
          </author>
          <author initials="W." surname="Li" fullname="Wen Bo Li,">
           <organization/>
          </author>
          <author initials="D." surname="Loher" fullname="Darren Loher">
           <organization/>
          </author>
          <date month="May" year="2023"/>
        </front>
	<refcontent>Version 10.0</refcontent>
      </reference>

      <reference anchor="gRPC" target="https://grpc.io/docs/">
        <front>
          <title>
gRPC Documentation
          </title>
          <title>gRPC Documentation</title>
          <author>
            <organization>gRPC Authors</organization>
          </author>
          <date year="2024"/>
        </front>
      </reference>

      <reference anchor="IPMI" target="https://www.intel.la/content/dam/www/public/us/en/documents/specification-updates/ipmi-intelligent-platform-mgt-interface-spec-2nd-gen-v2-0-spec-update.pdf">
        <front>
          <title>
Intelligent
          <title>Intelligent Platform Management Interface Specification, Second Generation
          </title> Generation</title>
          <author>
            <organization>Intel</organization>
          </author>
          <author>
            <organization>Hewlett-Packard</organization>
          </author>
          <author>
            <organization>NEC</organization>
          </author>
          <author>
            <organization>Dell</organization>
          </author>
          <date month="October" year="2013"/>
        </front>
	<refcontent>Version 2.0</refcontent>
      </reference>

      <reference anchor="XPath" target="http://www.w3.org/TR/1999/REC-xpath-19991116"> target="https://www.w3.org/TR/1999/REC-xpath-19991116">
        <front>
          <title>
XML
          <title>XML Path Language (XPath) Version 1.0 </title>
           <author>
             <organization>World Wide Web Consortium</organization>
           <author fullname="James Clark" initials="J." surname="Clark" role="editor">
             <organization></organization>
           </author>
           <author fullname="Steve DeRose" initials="S." surname="DeRose" role="editor">
             <organization></organization>
           </author>
          <date month="November" year="1999"/>
        </front>
       <refcontent>W3C Recommendation REC-xpath-19991116</refcontent>
      </reference>

      <reference anchor="xml-infoset" target= "https://www.w3.org/TR/2004/REC-xml-infoset-20040204/">
target="https://www.w3.org/TR/2004/REC-xml-infoset-20040204/">
        <front>
          <title>
               XML
          <title>XML Information Set (Second Edition)
          </title>
           <author>
             <organization>World Wide Web Consortium</organization> Edition)</title>
           <author fullname="John Cowan" initials="J." surname="Cowan" role="editor">
             <organization></organization>
           </author>
           <author fullname="Richard Tobin" initials="R." surname="Tobin" role="editor">
             <organization></organization>
           </author>
          <date month="February" year="2004"/>
        </front>
        <refcontent>W3C Recommendation REC-xml-infoset-20040204</refcontent>
      </reference>

    </references>

    <section numbered="false">
      <name>Acknowledgements</name>
      <t>
        Brian Sipos
        <contact fullname="Brian Sipos"/> of the Johns Hopkins University Applied Physics Laboratory
        (JHU/APL) provided excellent technical review of the DTNMA concepts
        presented in this document and additional information related to
        existing network management techniques.
      </t>
    </section>
  </back>
</rfc>