Diff: rfc9675.original.xml

	rfc9675.original.xml	rfc9675.xml

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

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

	<!DOCTYPE rfc [	<!DOCTYPE rfc [

	<!ENTITY nbsp " ">	<!ENTITY nbsp " ">
	<!ENTITY zwsp "">	<!ENTITY zwsp "">
	<!ENTITY nbhy "‑">	<!ENTITY nbhy "‑">
	<!ENTITY wj "⁠">	<!ENTITY wj "⁠">
	]>	]>

	<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
	<?rfc strict="yes" ?>	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" ipr="trust200902
	<?rfc toc="yes"?>	" docName="draft-ietf-dtn-dtnma-14" number="9675" consensus="true" submissionTyp
	<!-- generate a ToC -->	e="IETF" xml:lang="en" obsoletes="" updates="" tocInclude="true" symRefs="true"
	<?rfc symrefs="yes"?>	sortRefs="true" version="3">
	<!-- 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" submissionType="IETF" xml:lang="en" obsolete
	s="" updates="" tocInclude="true" symRefs="true" sortRefs="true" version="3">
	<!-- xml2rfc v2v3 conversion 3.13.0 -->
	<!-- *** FRONT MATTER *** -->

	<front>	<front>

	<!-- The abbreviated title is used in the page header - it is only necessary	<title abbrev="DTNMA">Delay-Tolerant Networking Management Architecture (DTNM
	if the	A)</title>
	full title is longer than 39 characters -->
	<title abbrev="DTNMA">DTN Management Architecture</title>	<seriesInfo name="RFC" value="9675"/>
	<seriesInfo name="Internet-Draft" value="draft-ietf-dtn-dtnma-14"/>	<author fullname="Edward J. Birrane, III" initials="E." surname="Birrane, III
	<author fullname="Edward J. Birrane" initials="E.J." surname="Birrane">	">
	<organization>Johns Hopkins Applied Physics Laboratory</organization>	<organization abbrev="JHU/APL">The Johns Hopkins University Applied Physic
		s Laboratory</organization>
	<address>	<address>
	<email>Edward.Birrane@jhuapl.edu</email>	<email>Edward.Birrane@jhuapl.edu</email>
	</address>	</address>
	</author>	</author>


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

	<author fullname="Emery Annis" initials="E." surname="Annis">	<author fullname="Emery Annis" initials="E." surname="Annis">

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


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

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


	<!-- Meta-data Declarations -->
	<area>General</area>
	<workgroup>Delay-Tolerant Networking</workgroup>
	<keyword>DTN</keyword>	<keyword>DTN</keyword>
	<keyword>Network Management</keyword>	<keyword>Network Management</keyword>

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

	<t>	<t>

	This document describes a DTN management architecture (DTNMA) suitable	This document describes a DTN Management Architecture (DTNMA) suitable
	for managing devices in any challenged environment but, in	for managing devices in any challenged environment but, in
	particular, those communicating using the DTN Bundle Protocol (BP).	particular, those communicating using the DTN Bundle Protocol (BP).
	Operating over BP requires an architecture that neither presumes	Operating over BP requires an architecture that neither presumes
	synchronized transport behavior nor relies on query-response mechanisms.	synchronized transport behavior nor relies on query-response mechanisms.
	Implementations compliant with this DTNMA should expect to successfully	Implementations compliant with this DTNMA should expect to successfully

	operate in extremely challenging conditions, such as over uni-directiona l	operate in extremely challenging conditions, such as over unidirectional
	links and other places where BP is the preferred transport.	links and other places where BP is the preferred transport.
	</t>	</t>
	</abstract>	</abstract>
	</front>	</front>

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

	<t>	<t>

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

	<t>	<t>
	Challenged networks have certain properties that differentiate them	Challenged networks have certain properties that differentiate them
	from other kinds of networks. These properties, outlined in	from other kinds of networks. These properties, outlined in

	Section 2.2.1 of <xref target="RFC7228"/>, include lacking	<xref target="RFC7228" sectionFormat="of" section="2.2.1"/>,
		include lacking
	end-to-end IP connectivity, having "serious interruptions"	end-to-end IP connectivity, having "serious interruptions"
	to end-to-end connectivity, and exhibiting delays longer than can be	to end-to-end connectivity, and exhibiting delays longer than can be
	tolerated by end-to-end synchronization mechanisms (such as TCP).	tolerated by end-to-end synchronization mechanisms (such as TCP).
	</t>	</t>

	<t>	<t>

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

	<t>	<t>

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

	<section numbered="true">	<section numbered="true">
	<name>Purpose</name>	<name>Purpose</name>
	<t>	<t>
	This document describes how challenged network properties	This document describes how challenged network properties

	affect the operation of devices in those networks. This	affect the operation of devices in such networks. This
	description is presented as a logical architecture	description is presented as a logical architecture
	formed from a union of best practices for operating	formed from a union of best practices for operating
	devices deployed in challenged environments.	devices deployed in challenged environments.
	</t>	</t>

	<t>	<t>
	One important practice captured in this document is the concept of sel f-operation. Self-operation involves operating	One important practice captured in this document is the concept of sel f-operation. Self-operation involves operating
	a device without human interactivity, without system-in-the-loop	a device without human interactivity, without system-in-the-loop

	synchronous function, and without a synchronous underlying	synchronous functions, and without a synchronous underlying
	transport layer. This means that devices determine	transport layer. This means that devices determine

	their own schedules for data reporting, their own	their own schedules for data reporting, determine their own
	operational configuration, and perform their own error	operational configuration, and perform their own error
	discovery and mitigation.	discovery and mitigation.
	</t>	</t>
	</section>	</section>

	<section numbered="true">	<section numbered="true">
	<name>Scope</name>	<name>Scope</name>
	<t>	<t>
	This document includes the information necessary to document	This document includes the information necessary to document
	existing practices for operating devices in a challenged network in	existing practices for operating devices in a challenged network in

	skipping to change at line 164 ¶	skipping to change at line 154 ¶
	<t>	<t>
	Logical architectures are not functional architectures. Therefore,	Logical architectures are not functional architectures. Therefore,
	any functional design for achieving desired behaviors is out of	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.	scope for this document. The set of architectural principles presented here is not meant to completely specify interfaces between components.
	</t>	</t>

	<t>	<t>
	The selection of any particular transport or network layer is outside	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	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	any specific protocol such as IP, BP, TCP, or UDP. In particular, the

	DTNMA design does not presume the use of BPv7, IPv4 or IPv6.	DTNMA design does not presume the use of BPv7, IPv4, or IPv6.
	</t>	</t>

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

	<t>	<t>
	Network features such as naming, addressing, routing, and	Network features such as naming, addressing, routing, and

	communications security are out of scope of the DTNMA. It is	communications security are out of scope for the DTNMA. It is
	presumed that any operational network communicating DTNMA	presumed that any operational network communicating DTNMA
	messages would implement these services for any payloads carried	messages would implement these services for any payloads carried
	by that network.	by that network.
	</t>	</t>

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

	<section numbered="true">	<section numbered="true">
	<name>Organization</name>	<name>Organization</name>
	<t>	<t>

	The remainder of this document is organized into the following	The following nine sections provide details regarding the DTNMA.
	nine sections, described as follows.
	</t>	</t>
	<dl>	<dl>
	<dt>Terminology:</dt>	<dt>Terminology:</dt>
	<dd>	<dd>

	This section identifies terms fundamental to	<xref target="terms"/> identifies terms fundamental to
	understanding DTNMA concepts. Whenever possible, these terms	understanding DTNMA concepts. Whenever possible, these terms
	align in both word selection and meaning with their use in	align in both word selection and meaning with their use in
	other management protocols.	other management protocols.
	</dd>	</dd>
	<dt>Challenged Network Overview:</dt>	<dt>Challenged Network Overview:</dt>
	<dd>	<dd>

	This section describes important	<xref target="challenged-net-overview"/> describes important
	aspects of challenged networks and necessary approaches for their	aspects of challenged networks and necessary approaches for their
	management.	management.
	</dd>	</dd>
	<dt>Desirable Design Properties:</dt>	<dt>Desirable Design Properties:</dt>
	<dd>	<dd>

	This section defines those properties of the DTNMA needed to opera te within the constraints	<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	of a challenged network. These properties are similar to the
	specification of system-level requirements of a DTN management	specification of system-level requirements of a DTN management
	solution.	solution.
	</dd>	</dd>
	<dt>Current Remote Management Approaches:</dt>	<dt>Current Remote Management Approaches:</dt>
	<dd>	<dd>

	This section provides a brief	<xref target="current-remote-mgmt"/> provides a brief
	overview of existing remote management approaches. Where possible,	overview of existing remote management approaches. Where possible,
	the DTNMA adopts concepts from these approaches.	the DTNMA adopts concepts from these approaches.
	</dd>	</dd>
	<dt>Motivation for New Features:</dt>	<dt>Motivation for New Features:</dt>
	<dd>	<dd>

	This section provides an overall	<xref target="motivation-for-new-features"/> provides an overall
	motivation for this work, to include explaining why a management	motivation for this work. It also explains why a management
	architecture for challenged networks is useful and necessary.	architecture for challenged networks is useful and necessary.
	</dd>	</dd>
	<dt>Reference Model:</dt>	<dt>Reference Model:</dt>
	<dd>	<dd>

	This section defines a reference model that can	<xref target="reference-model"/> defines a reference model that ca
	be used to reason about the DTNMA independent of an	n
		be used to analyze the DTNMA independently of an
	implementation or implementation architecture.	implementation or implementation architecture.
	This model identifies the logical components of the system and	This model identifies the logical components of the system and
	the high-level relationships and behaviors amongst those	the high-level relationships and behaviors amongst those
	components.	components.
	</dd>	</dd>
	<dt>Desired Services:</dt>	<dt>Desired Services:</dt>
	<dd>	<dd>

	This section identifies and defines the	<xref target="desired-services"/> identifies and defines the
	DTNMA services provided to network and mission operators.	DTNMA services provided to network and mission operators.
	</dd>	</dd>
	<dt>Logical Autonomy Model:</dt>	<dt>Logical Autonomy Model:</dt>
	<dd>	<dd>

	This section provides an exemplar data	<xref target="autonomy_model"/> provides an example data
	model that can be used to reason about DTNMA control and data flow	model that can be used to analyze DTNMA control and data flows.
	s.
	This model is based on the DTNMA reference model.	This model is based on the DTNMA reference model.
	</dd>	</dd>
	<dt>Use Cases:</dt>	<dt>Use Cases:</dt>
	<dd>	<dd>

	This section presents multiple use cases accommodated	<xref target="use-cases"/> presents multiple use cases accommodate
	by the DTNMA architecture. Each use case is presented as a	d
		by the DTNMA. Each use case is presented as a
	set of control and data flows referencing the DTNMA reference mode l	set of control and data flows referencing the DTNMA reference mode l
	and logical autonomy model.	and logical autonomy model.
	</dd>	</dd>
	</dl>	</dl>
	</section>	</section>
	</section>	</section>


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

	<t>	<t>

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

	<dl>	<dl>
	<dt>Timely Data Exchange:</dt>	<dt>Timely Data Exchange:</dt>
	<dd>	<dd>
	The ability to communicate information between two (or more)	The ability to communicate information between two (or more)
	entities within a required period of time. In some cases, a 1-second e xchange may not	entities within a required period of time. In some cases, a 1-second e xchange may not

	be timely and in other cases 1-hour exchange may be timely.	be timely; in other cases, a 1-hour exchange may be timely.
	</dd>	</dd>

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

	<dt>Remote Operation:</dt>	<dt>Remote Operation:</dt>
	<dd>	<dd>
	The operation of a device by an application running on a separate	The operation of a device by an application running on a separate
	device. Remote operators communicate with operated devices over a netw ork.	device. Remote operators communicate with operated devices over a netw ork.

	Remote operators are not always expected to be availabe to the devices they	Remote operators are not always expected to be available to the device s they
	operate.	operate.
	</dd>	</dd>

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

	<dt>DTNMA Agent (DA):</dt>	<dt>DTNMA Agent (DA):</dt>
	<dd>	<dd>

	A role associated with a managed device,	A role associated with a managed device
	responsible for reporting performance data, accepting policy	responsible for reporting performance data, accepting policy

	directives, performing autonomous local control, error-handling, and	directives, performing autonomous local control, error handling, and
	data validation. DAs exchange information with DMs operating either	data validation. DAs exchange information with DTNMA Managers (DMs) op
		erating
	on the same device and/or on remote devices in the network. A DA is	on the same device and/or on remote devices in the network. A DA is
	a type of local operator.	a type of local operator.
	</dd>	</dd>

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

	<dt>Controls:</dt>	<dt>Controls:</dt>
	<dd>	<dd>
	Procedures run by a DA to change the behavior,	Procedures run by a DA to change the behavior,
	configuration, or state of an application or protocol managed by	configuration, or state of an application or protocol managed by

	that DA. This includes procedures to manage the DA itself, such as	that DA. These include procedures to manage the DA itself, such as
	to have the DA produce performance reports or to apply new	having the DA produce performance reports or applying new
	management policies.	management policies.
	</dd>	</dd>

	<dt>Externally Defined Data (EDD):</dt>	<dt>Externally Defined Data (EDD):</dt>
	<dd>	<dd>
	Typed information made available to a	Typed information made available to a

	DA by its hosting device, but not computed directly by the	DA by its hosting device but not computed directly by the
	DA itself.	DA itself.
	</dd>	</dd>


	<dt>Data Reports:</dt>	<dt>Data Report:</dt>
	<dd>	<dd>

	Typed, ordered collections of data values gathered	A typed, ordered collection of data values gathered
	by one or more DAs and provided to one or more DMs. Reports comply	by one or more DAs and provided to one or more DMs. Reports comply

	to the format of a given Data Report Schema.	with the format of a given data report schema.
	</dd>	</dd>


	<dt>Data Report Schemas:</dt>	<dt>Data Report Schema:</dt>
	<dd>	<dd>

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


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


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

	<t>	<t>

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

	<section>	<section>
	<name>Challenged Network Constraints</name>	<name>Challenged Network Constraints</name>


	<t>	<t>
	Constrained networks are defined as networks where "some of the	Constrained networks are defined as networks where "some of the
	characteristics pretty much taken for granted with link layers in	characteristics pretty much taken for granted with link layers in

	common use in the Internet at the time of writing are not attainable."	common use in the Internet at the time of writing are not attainable"
	<xref target="RFC7228"/>. This broad definition captures a variety of	<xref target="RFC7228"/>. This broad definition captures a variety of
	potential issues relating to physical, technical, and regulatory	potential issues relating to physical, technical, and regulatory
	constraints on message transmission. Constrained networks	constraints on message transmission. Constrained networks
	typically include nodes that regularly reboot or are otherwise turned	typically include nodes that regularly reboot or are otherwise turned
	off for long periods of time, transmit at low or asynchronous bitrates ,	off for long periods of time, transmit at low or asynchronous bitrates ,
	and/or have very limited computational resources.	and/or have very limited computational resources.
	</t>	</t>

	<t>	<t>
	Separately, a challenged network is defined as one that "has serious	Separately, a challenged network is defined as one that "has serious

	skipping to change at line 406 ¶	skipping to change at line 395 ¶
	networking stacks associated with the end-to-end IP model. This	networking stacks associated with the end-to-end IP model. This
	means that devices might not include support for certain	means that devices might not include support for certain
	transport protocols (TCP/QUIC/UDP), web protocols (HTTP), or	transport protocols (TCP/QUIC/UDP), web protocols (HTTP), or
	internetworking protocols (IPv4/IPv6).	internetworking protocols (IPv4/IPv6).
	</t>	</t>
	</aside>	</aside>

	<t>	<t>
	By these definitions, a "challenged" network is a special type of	By these definitions, a "challenged" network is a special type of
	"constrained" network, where constraints prevent timely end-to-end	"constrained" network, where constraints prevent timely end-to-end

	data exchange. As such, "all challenged networks are	data exchange. As such, "All challenged networks are
	constrained networks ... but not all constrained networks are	constrained networks ... but not all constrained networks are

	challenged networks ... Delay-Tolerant Networking (DTN) has been	challenged networks ... Delay-Tolerant Networking (DTN) has been
	designed to cope with challenged networks" <xref target="RFC7228"/>.	designed to cope with challenged networks" <xref target="RFC7228"/>.
	</t>	</t>

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

	<ul spacing="normal">	<ul spacing="normal">
	<li>	<li>
	Timely end-to-end data exchange cannot be guaranteed to exist at any given time	Timely end-to-end data exchange cannot be guaranteed to exist at any given time
	between any two nodes.	between any two nodes.
	</li>	</li>
	<li>	<li>
	Latencies on the order of seconds, hours, or days must be tolerated.	Latencies on the order of seconds, hours, or days must be tolerated.
	</li>	</li>
	<li>	<li>

	Managed devices cannot be guaranteed to always be powered so as to r eceive ad-hoc management requests (even requests with artificially extended time out values).	Managed devices cannot be guaranteed to always be powered so as to r eceive ad hoc management requests (even requests with artificially extended time out values).
	</li>	</li>
	<li>	<li>

	Individual links may be uni-directional.	Individual links may be unidirectional.
	</li>	</li>
	<li>	<li>

	Bi-directional links may have asymmetric data rates.	Bidirectional links may have asymmetric data rates.
	</li>	</li>
	<li>	<li>
	The existence of external infrastructure, services, systems,	The existence of external infrastructure, services, systems,

	or processes such as a Domain Name Service (DNS) or a Certificate	or processes such as a Domain Name System (DNS) or a Certificate
	Authority (CA) cannot be guaranteed.	Authority (CA) cannot be guaranteed.
	</li>	</li>
	</ul>	</ul>
	</section>	</section>

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

	<t>	<t>
	The set of constraints that might be present in a challenged network	The set of constraints that might be present in a challenged network

	impact both the topology of the network and the services active	impacts both the topology of the network and the services active
	within that network.	within that network.
	</t>	</t>

	<t>	<t>
	Operational networks handle cases where nodes join and leave the	Operational networks handle cases where nodes join and leave the
	network over time. These topology changes may or may not be planned, t hey	network over time. These topology changes may or may not be planned, t hey
	may or may not represent errors, and they may or may not impact networ k	may or may not represent errors, and they may or may not impact networ k
	services. Challenged networks differ from other networks not in	services. Challenged networks differ from other networks not in

	the presence of topological change, but in the likelihood that impacts	the presence of topological change but in the likelihood that impacts
	to topology result in impacts to network services.	to topology result in impacts to network services.
	</t>	</t>

	<t>	<t>
	The difference between topology impacts and service impacts can be	The difference between topology impacts and service impacts can be
	expressed in terms of connectivity. Topological connectivity usually	expressed in terms of connectivity. Topological connectivity usually
	refers to the existence of a path between an application message	refers to the existence of a path between an application message
	source and destination. Service connectivity, alternatively, refers	source and destination. Service connectivity, alternatively, refers
	to the existence of a path between a node and one or more services	to the existence of a path between a node and one or more services

	needed to process (often just-in-time) application messaging.	needed to process -- often just in time -- application messaging.
	Examples of service connectivity include access to infrastructure	Examples of service connectivity include access to infrastructure

	services such as a Domain Name System (DNS) or a Certificate	services such as a Domain Name System (DNS) or a CA.
	Authority (CA).
	</t>	</t>

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

	<aside>	<aside>
	<t>	<t>
	NOTE: One example of rethinking services in a challenged network	NOTE: One example of rethinking services in a challenged network

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

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

	<t>	<t>

	skipping to change at line 531 ¶	skipping to change at line 519 ¶
	first tier is the management of the local operator configuration	first tier is the management of the local operator configuration
	using any one of a variety of standard mechanisms, models, and	using any one of a variety of standard mechanisms, models, and
	protocols. The second tier is the operation of the local device	protocols. The second tier is the operation of the local device
	through the local operator.	through the local operator.
	</t>	</t>

	<t>	<t>
	The DTNMA defines the DTNMA Manager (DM) as a remote operator applic ation and the	The DTNMA defines the DTNMA Manager (DM) as a remote operator applic ation and the
	DTNMA Agent (DA) as an agent acting as a local operator application.	DTNMA Agent (DA) as an agent acting as a local operator application.
	In this model, which is illustrated in <xref target="two_tiered_mode l"/>, the	In this model, which is illustrated in <xref target="two_tiered_mode l"/>, the

	DM and DA can be viewed as applications with the DM producing new co nfigurations	DM and DA can be viewed as applications, with the DM producing new c onfigurations
	and the DA receiving those configurations from an underlying managem ent mechanism.	and the DA receiving those configurations from an underlying managem ent mechanism.
	</t>	</t>


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

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

	]]></artwork>	]]></artwork>
	</figure>	</figure>

	<t>	<t>
	In this approach, the configurations produced by the DM are	In this approach, the configurations produced by the DM are
	based on the DA features and associated data model. How those	based on the DA features and associated data model. How those
	configurations are transported between the DM and the DA, and	configurations are transported between the DM and the DA, and
	how results are communicated back from the DA to the DM, can	how results are communicated back from the DA to the DM, can
	be accomplished using whatever mechanism is most appropriate	be accomplished using whatever mechanism is most appropriate

	for the network and the device platforms. For example, the	for the network and the device platforms -- for example, the
	use of a NETCONF, RESTCONF, or SNMP server on the managed device	use of a Network Configuration Protocol (NETCONF), RESTCONF, or Sim
		ple Network Management Protocol (SNMP) server on the managed device
	to provide configurations to a DA.	to provide configurations to a DA.
	</t>	</t>

	</section>	</section>

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

	<t>	<t>
	In addition to disconnectivity, topological change can alter the	In addition to disconnectivity, topological change can alter the

	skipping to change at line 585 ¶	skipping to change at line 573 ¶
	devices might be active in a network at different times or in	devices might be active in a network at different times or in
	different partitions. Managed devices might communicate with some, a ll,	different partitions. Managed devices might communicate with some, a ll,
	or none of these managing devices as a function of their own local	or none of these managing devices as a function of their own local
	configuration and policy.	configuration and policy.
	</t>	</t>

	<aside>	<aside>
	<t>	<t>
	NOTE: These concepts relate to practices in conventional networks.	NOTE: These concepts relate to practices in conventional networks.
	For example, supporting multiple managing devices is similar to	For example, supporting multiple managing devices is similar to

	deploying multiple instances of a network service -- such as a DNS	deploying multiple instances of a network service such as a DNS
	server or CA node. Selecting from a set of managing devices is	server or CA node. Selecting from a set of managing devices is

	similar to a sensor node practice of electing cluster heads to act	similar to a sensor node's practice of electing cluster heads to a ct
	as privileged nodes for data storage and exfiltration.	as privileged nodes for data storage and exfiltration.
	</t>	</t>
	</aside>	</aside>

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

	<ol>	<ol>
	<li>	<li>
	Support a many-to-many association amongst managing and managed	Support a many-to-many association amongst managing and managed
	devices, and	devices, and
	</li>	</li>
	<li>	<li>
	Allow "control from" and "reporting to" managing devices to functi on	Allow "control from" and "reporting to" managing devices to functi on

	independent of one another.	independently of one another.
	</li>	</li>
	</ol>	</ol>
	</section>	</section>
	</section>	</section>

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

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

	<dl>	<dl>
	<dt>One-Way Management:</dt>	<dt>One-Way Management:</dt>
	<dd>	<dd>
	A managed device can only be accessed via a	A managed device can only be accessed via a

	uni-directional link, or a via a link whose duration is shorter	unidirectional link or via a link whose duration is shorter
	than a single round-trip propagation time. Results of this managemen t may come back at a different time, over a	than a single round-trip propagation time. Results of this managemen t may come back at a different time, over a
	different path, and/or as observable from out-of-band changes to	different path, and/or as observable from out-of-band changes to
	device behavior.	device behavior.
	</dd>	</dd>

	<dt>Summary Data:</dt>	<dt>Summary Data:</dt>
	<dd>	<dd>

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

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


	<dt>Multiple Managers</dt>	<dt>Multiple Managers:</dt>
	<dd>	<dd>
	A managed device tracks multiple managers in	A managed device tracks multiple managers in
	the network and communicates with them as a function of time,	the network and communicates with them as a function of time,

	local state, or network topology. This includes challenged	local state, or network topology. This scenario would also apply to challenged
	networks that interconnect two or more unchallenged networks such	networks that interconnect two or more unchallenged networks such
	that managed and managing devices exist in different networks.	that managed and managing devices exist in different networks.
	</dd>	</dd>
	</dl>	</dl>
	<t>	<t>
	These special cases highlight the need for managed devices to operate	These special cases highlight the need for managed devices to operate
	without presupposing a dedicated connection to a single managing	without presupposing a dedicated connection to a single managing
	device. Managing devices in a challenged	device. Managing devices in a challenged
	network might never expect a reply to a command, and communications fr om	network might never expect a reply to a command, and communications fr om
	managed devices may be delivered much later than the events being repo rted.	managed devices may be delivered much later than the events being repo rted.
	</t>	</t>

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


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

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

	<aside>	<aside>
	<t>	<t>
	NOTE: These properties may influence the design, construction, and	NOTE: These properties may influence the design, construction, and
	adaptation of existing management tools for use in challenged	adaptation of existing management tools for use in challenged
	networks. For example, the properties of the DTN architecture	networks. For example, the properties of the DTN architecture
	<xref target="RFC4838"/> resulted in the development of BPv7	<xref target="RFC4838"/> resulted in the development of BPv7

	<xref target="RFC9171"/> and BPSec <xref target="RFC9172"/>. The	<xref target="RFC9171"/> and BPSec <xref target="RFC9172"/>.
	DTNMA may result in the construction of new management data models,	Implementing the DTNMA model may result in the construction of new man
		agement data models,
	policy expressions, and/or protocols.	policy expressions, and/or protocols.
	</t>	</t>
	</aside>	</aside>

	<section numbered="true">	<section numbered="true">
	<name>Dynamic Architectures</name>	<name>Dynamic Architectures</name>
	<t>	<t>

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

	<t>	<t>
	The DTNMA should not prescribe any association between a	The DTNMA should not prescribe any association between a
	DM and a DA other than those defined in this document.	DM and a DA other than those defined in this document.

	There should be no logical limitation to the number of DMs	There should be no logical limitation on the number of DMs
	that can control a DA, the number of DMs that a DA should report to,	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 a pair.	or any requirement that a DM and DA relationship imply a pair.
	</t>	</t>

	<aside>	<aside>
	<t>	<t>
	NOTE: Practical limitations on the relationships between and	NOTE: Practical limitations on the relationships between and
	amongst DMs and DAs will exist as a function of the capabilities of	amongst DMs and DAs will exist as a function of the capabilities of
	networked devices. These limitations derive from processing and stor age	networked devices. These limitations derive from processing and stor age
	constraints, performance requirements, and other engineering factors .	constraints, performance requirements, and other engineering factors .

	While this information is vital to the proper engineering of a manag	Implementors of managed and managing devices must account for these
	ed	limitations in their device designs.
	and managing device, they are implementation considerations, and not
	otherwise design constraints on the DTNMA.
	</t>	</t>
	</aside>	</aside>
	</section>	</section>

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

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

	<aside>	<aside>
	<t>	<t>

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

	<t>	<t>
	Many network management solutions use data models to specify the	Many network management solutions use data models to specify the
	semantic and syntactic representation of data exchanged between	semantic and syntactic representation of data exchanged between
	managed and managing devices. The DTNMA is not different in	managed and managing devices. The DTNMA is not different in

	this regard - information exchanged between DAs and DMs should	this regard; information exchanged between DAs and DMs should
	conform to one or more pre-defined, normative data models.	conform to one or more predefined, normative data models.
	</t>	</t>

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

	skipping to change at line 769 ¶	skipping to change at line 757 ¶
	from another data model. This ability to include a data model avoids	from another data model. This ability to include a data model avoids
	repeating information in different data models. When one data	repeating information in different data models. When one data
	model includes information from another data model, there is an	model includes information from another data model, there is an
	implied model hierarchy.	implied model hierarchy.
	</t>	</t>

	<t>	<t>
	Data models in the DTNMA should allow for the construction of both	Data models in the DTNMA should allow for the construction of both
	cohesive models and hierarchically related models. These data models	cohesive models and hierarchically related models. These data models
	should be used to define all sources of information that can	should be used to define all sources of information that can

	be retrieved, configured, or executed in the DTNMA. This includes	be retrieved, configured, or executed in the DTNMA. These actions woul d include
	supporting DA autonomy functions such as parameterization,	supporting DA autonomy functions such as parameterization,

	filtering, and event driven behaviors. These models will be used to bo th	filtering, and event-driven behaviors. These models will be used to bo th
	implement interoperable autonomy engines on DAs and define	implement interoperable autonomy engines on DAs and define
	interoperable report parsing mechanisms on DMs.	interoperable report parsing mechanisms on DMs.
	</t>	</t>

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

	</section>	</section>

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

	<t>	<t>

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

	<t>	<t>

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

	<t>	<t>

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

	information might still be queued pending connectivity of the DA	information might still be queued, pending connectivity of the DA
	to the network.	to the network.
	</t>	</t>


	<aside>
	<t>	<t>

	NOTE: Even in cases where a round-trip exchange can occur, pull	Even in cases where a round-trip exchange can occur, pull
	mechanisms increase the overall amount of traffic in the network	mechanisms increase the overall amount of traffic in the network

	and preclude the use of autonomy at managed devices. So even when	and preclude the use of autonomy at managed devices. So, even when
	pull mechanisms are feasible they should not be considered a	pull mechanisms are feasible, they should not be considered a
	pragmatic alternative to push mechanisms.	pragmatic alternative to push mechanisms.
	</t>	</t>

	</aside>

	</section>	</section>

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

	<t>	<t>
	There is a relationship between message encoding and message	There is a relationship between message encoding and message

	processing time at a node. Messages with little or no encodings may	processing time at a node. Messages with few or no encodings may
	simplify node processing whereas more compact encodings may require	simplify node processing, whereas more compact encodings may require
	additional activities to generate/parse encoded messages. Generally,	additional activities to generate/parse encoded messages. Generally,
	compressing a message takes processing time at the sender and	compressing a message takes processing time at the sender and
	decompressing a message takes processing time at a receiver.	decompressing a message takes processing time at a receiver.

	Therefore, there is a design tradeoff between minimizing message	Therefore, there is a design trade-off between minimizing message
	sizes and minimizing node processing.	sizes and minimizing node processing.
	</t>	</t>

	<t>	<t>
	There is a significant advantage to smaller DTNMA message sizes	There is a significant advantage to smaller DTNMA message sizes

	in a challenged network. Smaller messages require smaller periods of	in a challenged network. Smaller messages require shorter periods of
	viable transmission for communication, they incur less	viable transmission for communication, they incur less

	re-transmission cost, and they consume less resources when	retransmission cost, and they consume fewer resources when
	persistently stored en-route in the network.	persistently stored en route in the network.
	</t>	</t>

	<aside>	<aside>
	<t>	<t>

	NOTE: Naive approaches to minimizing message size through general	NOTE: Naive approaches to minimizing message size through
	purpose compression algorithms do not produce minimal encodings.	general-purpose compression algorithms do not produce minimal encodi
		ngs.
	Data models can, and should, be designed for compact encoding from	Data models can, and should, be designed for compact encoding from
	the beginning. Design strategies for compact encodings involve	the beginning. Design strategies for compact encodings involve
	using structured data, hierarchical data models, and common	using structured data, hierarchical data models, and common

	sub-structures within data models. These strategies allow for	substructures within data models. These strategies allow for
	compressibility beyond what would otherwise be achieved by	compressibility beyond what would otherwise be achieved by
	computing large hash values over generalized data structures.	computing large hash values over generalized data structures.

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

	</section>	</section>

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

	<t>	<t>
	Data elements within the DTNMA should be uniquely identifiable so that	Data elements within the DTNMA should be uniquely identifiable so that
	they can be individually manipulated. Further, these identifiers	they can be individually manipulated. Further, these identifiers

	should be universal - the identifier for a data element should be the	should be universal -- the identifier for a data element should be the
	same regardless of role, implementation, or network instance.	same, regardless of role, implementation, or network instance.
	</t>	</t>

	<t>	<t>
	Identification schemes that would be relative to a specific DA or	Identification schemes that would be relative to a specific DA or

	specific system configuration might change over time and should be avo ided. Relying on relative identification schemes would require resynchronizing r elative state when nodes in a challenge network reconnect after periods of parti tion. This type of resynchronization should be avoided whenever possible.	specific system configuration might change over time and should be avo ided. Relying on relative identification schemes would require resynchronizing r elative state when nodes in a challenged network reconnect after periods of part ition. This type of resynchronization should be avoided whenever possible.
	</t>	</t>

	<aside>	<aside>
	<t>	<t>
	NOTE: Consider a common management technique for approximating an	NOTE: Consider a common management technique for approximating an
	associative array lookup. If a managed device	associative array lookup. If a managed device
	tracks the number of bytes passed by multiple named interfaces,	tracks the number of bytes passed by multiple named interfaces,
	then the number of bytes through a specific named interface	then the number of bytes through a specific named interface

	("int_foo"), would be retrieved in the following way:	("int_foo") would be retrieved in the following way:
	</t>	</t>

	<ol>	<ol>
	<li>	<li>
	Query a list of ordered interface names from an agent.	Query a list of ordered interface names from an agent.
	</li>	</li>
	<li>	<li>

	Find the name that matches "int_foo" and infer the agent's ind	Find the name that matches "int_foo", and infer the agent's in
	ex of "int_foo" from the ordered interface list. In	dex of "int_foo" from the ordered interface list. In
	this instance, assume "int_foo" is the 4th interface in the li	this instance, assume that "int_foo" is the fourth interface i
	st.	n the list.
	</li>	</li>
	<li>	<li>

	Query the agent (again) to now return the number of bytes pass ed through the 4th interface.	Query the agent (again) to now return the number of bytes pass ed through the fourth interface.
	</li>	</li>
	</ol>	</ol>

	<t>	<t>
	Ignoring the inefficiency of two round-trip exchanges, this	Ignoring the inefficiency of two round-trip exchanges, this
	mechanism will fail if an agent implementation changes its index	mechanism will fail if an agent implementation changes its index

	mapping between the first and second query.	mapping between the first and second queries.
	</t>	</t>
	<t>	<t>

	The desired data being queried, "number of bytes through int_foo"	The desired data being queried, "number of bytes through 'int_foo'",
	should be uniquely and universally identifiable and independent	should be uniquely and universally identifiable and independent
	of how that data exists in any agent's custom implementation.	of how that data exists in any agent's custom implementation.
	</t>	</t>
	</aside>	</aside>

	</section>	</section>

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

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

	<t>	<t>

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

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

	<aside>	<aside>
	<t>	<t>
	NOTE: A DM could, for example, define a custom data report that	NOTE: A DM could, for example, define a custom data report that

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

	<t>	<t>
	Custom data elements should be calculated and used both as	Custom data elements should be calculated and used both as
	parameters for DA autonomy and for more efficient reporting	parameters for DA autonomy and for more efficient reporting
	to DMs. Defining new data elements allows for DAs to perform	to DMs. Defining new data elements allows for DAs to perform

	local data fusion and defining new reporting templates allows	local data fusion, and defining new reporting templates allows
	for DMs to specify desired formats and generally save on link	for DMs to specify desired formats and generally save on link
	capacity, storage, and processing time.	capacity, storage, and processing time.
	</t>	</t>
	</section>	</section>

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

	<t>	<t>
	The management of applications by a DA should be achievable using	The management of applications by a DA should be achievable using

	skipping to change at line 987 ¶	skipping to change at line 973 ¶
	or to support semi-autonomous behavior in determining when to run	or to support semi-autonomous behavior in determining when to run
	tasks and how to configure or parameterize tasks when they are run.	tasks and how to configure or parameterize tasks when they are run.
	</t>	</t>
	<t>	<t>
	Important features provided by the DA are listed below. These	Important features provided by the DA are listed below. These
	features work together to accomplish tasks. As such, there is	features work together to accomplish tasks. As such, there is
	commonality amongst their definitions and nature of their benefits.	commonality amongst their definitions and nature of their benefits.
	</t>	</t>

	<dl>	<dl>

	<dt>Stand-alone Operation:</dt>	<dt>Standalone Operation:</dt>
	<dd>	<dd>

	Pre-configuration allows DAs to operate	Preconfiguration allows DAs to operate
	without regular contact with other nodes in the network. Updates	without regular contact with other nodes in the network. Updates

	for configurations remain difficult in a challenged network, but t	for configurations remain difficult in a challenged network, but t
	his approach removes the requirement that a DM be in-the-loop during regular ope	his approach removes the requirement that a DM be in the loop during regular ope
	rations.	rations.
	Preconfiguring stimuli-and-responses on a DA during periods of	Preconfiguring stimuli and responses on a DA during periods of
	connectivity allows DAs to self-manage during periods of	connectivity allows DAs to self-manage during periods of
	disconnectivity.	disconnectivity.
	</dd>	</dd>

	<dt>Deterministic Behavior:</dt>	<dt>Deterministic Behavior:</dt>
	<dd>	<dd>
	Operational systems might need to act	Operational systems might need to act

	in a deterministic way even in the absence of an operator	in a deterministic way, even in the absence of an operator
	in-the-loop. Deterministic behavior allows an out-of-contact DM to	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	predict the state of a DA and to determine how a DA got into
	a particular state.	a particular state.
	</dd>	</dd>
	<dt>Engine-Based Behavior:</dt>	<dt>Engine-Based Behavior:</dt>
	<dd>	<dd>
	Operational systems might not be able to	Operational systems might not be able to

	deploy "mobile code" <xref target="RFC4949" format="default"/>	deploy "mobile code" solutions
	solutions due to network bandwidth, memory or processor loading,	<xref target="RFC4949" format="default"/> due to network bandwidth
		, memory or processor loading,
	or security concerns. Engine-based approaches provide configurable	or security concerns. Engine-based approaches provide configurable
	behavior without incurring these concerns.	behavior without incurring these concerns.
	</dd>	</dd>
	<dt>Authorization and Accounting:</dt>	<dt>Authorization and Accounting:</dt>
	<dd>	<dd>
	The DTNMA does not	The DTNMA does not

	require a specific underlying transport protocol, network	require a specific underlying transport protocol, a specific netwo
	infrastructure, or network services. Therefore, mechanisms for	rk
		infrastructure, or specific network services. Therefore, mechanism
		s for
	authorization and accounting need to be present in	authorization and accounting need to be present in
	a standard way at DAs and DMs to provide these functions if the	a standard way at DAs and DMs to provide these functions if the
	underlying network does not. This is particularly true in cases	underlying network does not. This is particularly true in cases
	where multiple DMs may be active concurrently in the network.	where multiple DMs may be active concurrently in the network.
	</dd>	</dd>
	</dl>	</dl>

	<t>	<t>

	To understand the contributions of these features to a common	To understand the contributions of these features to a common type of
	behavior, consider the example of a managed device coming online	behavior, consider the example of a managed device coming online

	with a set of pre-installed configuration. In this case,	with a set of preinstalled configurations. In this case,
	the device's stand-alone operation comes from the pre-configuration	the device's standalone operation comes from the preconfiguration
	of its local autonomy engine. This engine-based behavior allows	of its local autonomy engine. This engine-based behavior allows

	the system to behave in a deterministic way and any new configuration s	the system to behave in a deterministic way, and any new configuratio ns
	will need to be authorized before being adopted.	will need to be authorized before being adopted.
	</t>	</t>

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


	<section numbered="true">	<section anchor="current-remote-mgmt" numbered="true">
	<name>Current Remote Management Approaches</name>	<name>Current Remote Management Approaches</name>
	<t>	<t>

	Several remote management solutions have been developed for both local-a	Several remote management solutions have been developed for both local a
	rea and wide-area networks. Their capabilities range from simple configuration a	rea networks and wide area networks. Their capabilities range from simple config
	nd report generation to complex modeling of device settings, state, and behavior	uration and report generation to complex modeling of device settings, state, and
	.	behavior.
	Each of these approaches are successful in the domains for which they ha	All of these approaches are successful in the domains for which they hav
	ve been built, but are not all equally functional when deployed in a challenged	e been built but are not all equally functional when deployed in a challenged ne
	network.	twork.
	</t>	</t>
	<t>	<t>
	This section describes some of the well-known protocols for remote manag ement and contrasts their purposes with the desirable properties of the DTNMA.	This section describes some of the well-known protocols for remote manag ement and contrasts their purposes with the desirable properties of the DTNMA.

	The purpose of this comparison is to identify parts of existing approach es that can be adopted or adapted for use in challenged networks and where new c apabilities should be created specifically for this environment.	The purpose of this comparison is to identify parts of existing approach es that can be adopted or adapted for use in challenged networks and where new c apabilities should be created specifically for such environments.
	</t>	</t>
	<section>	<section>
	<name>SNMP and SMI Models</name>	<name>SNMP and SMI Models</name>
	<t>	<t>

	An early and widely used example of a remote management protocol is the Simple N	An early and widely used example of a remote management protocol is SNMP, which
	etwork Management Protocol (SNMP) currently at Version 3 <xref target="RFC3410"/	is currently at version 3 <xref target="RFC3410"/>.
	>.	SNMP utilizes a request-response model to get and set data values within an arbi
	The SNMP utilizes a request/response model to get and set data values within an	trarily deep object hierarchy.
	arbitrarily deep object hierarchy.
	Objects are used to identify data such as host identifiers, link utilization met rics, error rates, and counters between application software on managing and man aged devices <xref target="RFC3411"/>.	Objects are used to identify data such as host identifiers, link utilization met rics, error rates, and counters between application software on managing and man aged devices <xref target="RFC3411"/>.
	Additionally, SNMP supports a model for unidirectional push messages, called eve nt notifications, based on agent-defined triggering events.	Additionally, SNMP supports a model for unidirectional push messages, called eve nt notifications, based on agent-defined triggering events.
	</t>	</t>
	<t>	<t>

	SNMP relies on logical sessions with predictable round-trip latency to support i ts "pull" mechanism but a single activity is likely to require many round-trip e xchanges.	SNMP relies on logical sessions with predictable round-trip latency to support i ts pull mechanism, but a single activity is likely to require many round-trip ex changes.
	Complex management can be achieved, but only through careful orchestration of re al-time, end-to-end, managing-device-generated query-and-response logic.	Complex management can be achieved, but only through careful orchestration of re al-time, end-to-end, managing-device-generated query-and-response logic.
	</t>	</t>
	<t>	<t>
	There is existing work that uses the SNMP data model to support	There is existing work that uses the SNMP data model to support

	some low-fidelity Agent-side processing, to include the Distributed	some low-fidelity agent-side processing; this work includes using
	Management Expression MIB <xref target="RFC2982"/> and Definitions	"<xref target="RFC2982" format="title"/>" <xref target="RFC2982" format="default
	of Managed Objects for the Delegation of Management Scripts	"/> and
	<xref target="RFC3165"/>. However, Agent autonomy is not an SNMP	"<xref target="RFC3165" format="title"/>" <xref target="RFC3165" format="default
		"/>.
		However, agent autonomy is not an SNMP
	mechanism, so support for a local agent response to an initiating	mechanism, so support for a local agent response to an initiating
	event is limited. In a challenged network where the delay between	event is limited. In a challenged network where the delay between
	a managing device receiving an alert and sending a response can be	a managing device receiving an alert and sending a response can be
	significant, SNMP is insufficient for autonomous event handling.	significant, SNMP is insufficient for autonomous event handling.
	</t>	</t>
	<section anchor="sec-mgmt-snmp-smi">	<section anchor="sec-mgmt-snmp-smi">
	<name>The SMI Modeling Language</name>	<name>The SMI Modeling Language</name>
	<t>	<t>

	SNMP separates the representations for managed data models from Manager--Agent m	SNMP separates the representations for managed data models from messaging, seque
	essaging, sequencing and encoding.	ncing, and encoding between managers and agents.
	Each data model is termed a Management Information Base (MIB) <xref target="RFC3	Each data model is termed a "Management Information Base" (or "MIB") <xref targe
	418"/> and uses the Structure of Management Information (SMI) modeling language	t="RFC3418"/> and uses the Structure of Management Information (SMI) modeling la
	<xref target="RFC2578"/>.	nguage <xref target="RFC2578"/>.
	Additionally, the SMI itself is based on the ASN.1 Syntax <xref target="ASN.1"/>	Additionally, the SMI itself is based on the ASN.1 syntax <xref target="ASN.1"/>
	which is used not just for SMI but for other, unrelated data structure specific	, which is used not just for SMI but for other, unrelated data structure specifi
	ation such as the Cryptographic Message Syntax (CMS) <xref target="RFC5652"/>.	cations 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.	Separating data models from messaging and encoding is a best practice in remote management protocols and is also necessary for the DTNMA.
	</t>	</t>
	<t>	<t>

	Each SNMP MIB is composed of managed object definitions each of which is associa	Each SNMP MIB is composed of managed object definitions, each of which is associ
	ted with a hierarchical Object Identifier (OID).	ated with a hierarchical Object Identifier (OID).
	Because of the arbitrarily deep nature of MIB object trees, the size of OIDs is	Because of the arbitrarily deep nature of MIB object trees, the size of OIDs is
	not strictly bounded by the protocol (though may be bounded by implementations).	not strictly bounded by the protocol (though it may be bounded by implementation
		s).
	</t>	</t>
	</section>	</section>
	<section>	<section>

	<name>SNMP Protocol and Transport</name>	<name>SNMP and Transport</name>
	<t>	<t>

	The SNMP protocol itself, which is at version 2 <xref target="RFC3416"/>, can op erate over a variety of transports, including plaintext UDP/IP <xref target="RFC 3417"/>, SSH/TCP/IP <xref target="RFC5592"/>, and DTLS/UDP/IP or TLS/TCP/IP <xre f target="RFC6353"/>.	SNMPv2 <xref target="RFC3416"/> <xref target="RFC3417"/> and SNMPv3 <xref target ="RFC3414"/> can operate over a variety of transports, including plaintext UDP/I P <xref target="RFC3417"/>, SSH/TCP/IP <xref target="RFC5592"/>, and DTLS/UDP/IP or TLS/TCP/IP <xref target="RFC6353"/>.
	</t>	</t>
	<t>	<t>
	SNMP uses an abstracted security model to provide authentication, integrity, and confidentiality.	SNMP uses an abstracted security model to provide authentication, integrity, and confidentiality.

	There are options for user-based security model (USM) of <xref target="RFC3414"/ >, which uses in-message security, and transport security model (TSM) <xref targ et="RFC5591"/>, which relies on the transport to provide security functions and interfaces.	There are options for the User-based Security Model (USM) <xref target="RFC3414" />, which uses in-message security, and the Transport Security Model (TSM) <xref target="RFC5591"/>, which relies on the transport to provide security functions and interfaces.
	</t>	</t>
	</section>	</section>
	</section>	</section>
	<section>	<section>

	<name>XML-Infoset-Based Protocols and YANG Models</name>	<name>XML-Infoset-Based Protocols and YANG Data Models</name>

	<t>	<t>

	Several network management protocols, including NETCONF <xref target="RFC6241"/> , RESTCONF <xref target="RFC8040"/>, and CORECONF <xref target="I-D.ietf-core-co mi"/>, share the same XML information set <xref target="xml-infoset"/> for its h ierarchical managed information and <xref target="XPath"/> expressions to identi fy nodes of that information model.	Several network management protocols, including NETCONF <xref target="RFC6241"/> , RESTCONF <xref target="RFC8040"/>, and the Constrained Application Protocol (C oAP) Management Interface (CORECONF) <xref target="CORE-COMI"/>, share the same XML Information Set <xref target="xml-infoset"/> for the information set's hiera rchical managed information and XPath expressions <xref target="XPath"/> to iden tify nodes of that information model.
	Since they share the same information model and the same data manipulation opera tions, together they will be referred to as "*CONF" protocols.	Since they share the same information model and the same data manipulation opera tions, together they will be referred to as "*CONF" protocols.
	Each protocol, however, provides a different encoding of that information set an d its related operation-specific data.	Each protocol, however, provides a different encoding of that information set an d its related operation-specific data.
	</t>	</t>
	<t>	<t>

	The YANG modeling language of <xref target="RFC7950"/> is used to define the dat a model for these management protocols.	The YANG modeling language as defined in <xref target="RFC7950"/> is used to def ine the data model for these management protocols.
	Currently, YANG represents the IETF standard for defining managed information mo dels.	Currently, YANG represents the IETF standard for defining managed information mo dels.
	</t>	</t>
	<section>	<section>
	<name>The YANG Modeling Language</name>	<name>The YANG Modeling Language</name>
	<t>	<t>
	The YANG modeling language defines a syntax and modular semantics for organizing and accessing a device's configuration or operational information.	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 de fined by separate YANG modules.	YANG allows subdividing a full managed configuration into separate namespaces de fined by separate YANG modules.
	Once a module is developed, it is used (directly or indirectly) on both the clie nt and server to serve as a contract between the two.	Once a module is developed, it is used (directly or indirectly) on both the clie nt and server to serve as a contract between the two.

	A YANG module can be complex, describing a deeply nested and inter-related set o f data nodes, actions, and notifications.	A YANG module can be complex, describing a deeply nested and interrelated set of data nodes, actions, and notifications.
	</t>	</t>
	<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, YANG defines b oth a text syntax and module semantics together with data model semantics.	Unlike the separation between ASN.1 syntax and module semantics from higher-leve l SMI data model semantics as discussed in <xref target="sec-mgmt-snmp-smi"/>, Y ANG defines both a text syntax and module semantics together with data model sem antics.
	</t>	</t>
	<t>	<t>

	The YANG language provides flexibility in the organization of model objects to t	The YANG modeling language provides flexibility in the organization of model obj
	he model developer.	ects to the model developer.
	The YANG supports a broad range of data types noted in <xref target="RFC6991"/>.	YANG supports a broad range of data types as noted in <xref target="RFC6991"/>.
	YANG supports the definition of parameterized Remote Procedure Calls (RPCs) and	YANG also supports the definition of parameterized Remote Procedure Calls (RPCs)
	actions to be executed on managed devices as well as the definition of event not	and actions to be executed on managed devices as well as the definition of even
	ifications within the model.	t notifications within the model.
	</t>	</t>

	<aside><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 a periodic or
	"on change" basis <xref target="RFC8641"/>.
	These notification events can be filtered according to XPath <xref target="XPath
	"/> or subtree <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, some	Current *CONF notification logic allows a client to subscribe to the delivery of
	of which are described here.	specific containers or data nodes defined in the model, on either a periodic or
		"on-change" basis <xref target="RFC8641"/>.
		These notification events can be filtered according to XPath or subtree filterin
		g <xref target="XPath"/> <xref target="RFC6241"/> as described in <xref section=
		"2.2" target="RFC8639"/>.
		</t>
		<t>
		The use of YANG for data modeling necessarily comes with some side effects, some
		of which are described here.
	</t>	</t>
	<dl>	<dl>
	<dt>Text Naming:</dt>	<dt>Text Naming:</dt>
	<dd>	<dd>
	<t>	<t>

	Data nodes, RPCs, and notifications within a YANG model are named by a namespace -qualified, text-based path of the module, sub-module, container, and any data n odes such as lists, leaf-lists, or leaves, without any explicit hierarchical org anization based on data or object type.	Data nodes, RPCs, and notifications within a YANG data model are named by a name space-qualified, text-based path of the module, submodule, container, and any da ta nodes such as lists, leaf-lists, or leaves, without any explicit hierarchical organization based on data or object type.
	</t>	</t>
	<t>	<t>

	Existing efforts to make compressed names for YANG objects, such as the YANG Sch	Existing efforts to make compressed names for YANG objects, such as the YANG Sch
	ema Item iDentifiers (SID) from <xref section="3.2" target="RFC9254"/>, allow a	ema Item iDentifiers (SIDs) as discussed in <xref section="3.2" target="RFC9254"
	node to be named by an globally unique integer value but are still relatively ve	/>, allow a node to be named by a globally unique integer value but are still re
	rbose (up to 8 bytes per item) and still must be translated into text form for t	latively verbose (up to 8 bytes per item) and still must be translated into text
	hings like instance identification (see below).	form for things like instance identification (see below).
	Additionally, when representing a tree of named instances the child elements can	Additionally, when representing a tree of named instances, the child elements ca
	use differential encoding of SID integer values as "delta" integers.	n use differential encoding of SID integer values as "delta" integers.
	The mechanisms for assigning SIDs and the lifecycle of those SIDs are still in d	The mechanisms for assigning SIDs and the lifecycle of those SIDs are discussed
	evelopment <xref target="I-D.ietf-core-sid"/>.	in <xref target="RFC9595"/>.
	</t>	</t>
	</dd>	</dd>
	<dt>Text Values and Built-In Types:</dt>	<dt>Text Values and Built-In Types:</dt>
	<dd>	<dd>
	<t>	<t>

	Because the original use of YANG with NETCONF was to model XML information sets,	Because the original use of YANG with NETCONF was to model XML Information Sets,
	the values and built-in types are necessarily text based.	the values and built-in types are necessarily text based.
	The JSON encoding of YANG data <xref target="RFC7951"/> allows for optimized rep	JSON encoding of YANG data <xref target="RFC7951"/> allows for optimized represe
	resentations of many built-in types, and similarly the CBOR encoding <xref targe	ntations of many built-in types; similarly, Concise Binary Object Representation
	t="RFC9254"/> allows for different optimized representations.	(CBOR) encoding <xref target="RFC9254"/> allows for different optimized represe
		ntations.
	</t>	</t>
	<t>	<t>

	In particular, the YANG built-in types natively support a fixed range of decimal	In particular, the YANG built-in types support a fixed range of decimal fraction
	fractions (<xref section="9.3" target="RFC7950"/>) but purposefully do not supp	s (<xref section="9.3" target="RFC7950"/>) but purposefully do not support float
	ort floating point numbers.	ing-point numbers.
	There are alternatives, such as the type <tt>bandwidth-ieee-float32</tt> from <x	There are alternatives, such as the type <tt>bandwidth-ieee-float32</tt> <xref t
	ref target="RFC8294"/> or using the "binary" type with one of the IEEE-754 encod	arget="RFC8294"/> or using the "binary" type with one of the IEEE-754 encodings.
	ings.
	</t>	</t>
	</dd>	</dd>
	<dt>Deep Hierarchy:</dt>	<dt>Deep Hierarchy:</dt>
	<dd>	<dd>
	YANG allows for, and current YANG modules take advantage of, the ability to deep ly nest a model hierarchy to represent complex combinations and compositions of data nodes.	YANG allows for, and current YANG modules take advantage of, the ability to deep ly nest a model hierarchy to represent complex combinations and compositions of data nodes.

	When a model uses a deep hierarchy of nodes this necessarily means that the qual ified paths to name those nodes and instances is longer than a flat hierarchy wo uld be.	When a model uses a deep hierarchy of nodes, this necessarily means that the qua lified paths to name those nodes and instances are longer than they would be in a flat namespace.
	</dd>	</dd>
	<dt>Instance Identification:</dt>	<dt>Instance Identification:</dt>
	<dd>	<dd>
	The node instances in a YANG module necessarily use XPath expressions for identi fication.	The node instances in a YANG module necessarily use XPath expressions for identi fication.

	Some identification is constrained to be strictly within the YANG domain, such a	Some identification is constrained to be strictly within the YANG domain, such a
	s "must" "when", "augment", or "deviation" statements.	s "must", "when", "augment", or "deviation" statements.
	Other identification needs to be processed by a managed device, such as in "inst	Other identification needs to be processed by a managed device -- for example, v
	ance-identifier" built-in type.	ia
	This means any implementation of a managed device must include XPath processing	the "instance-identifier" built-in type.
	and related information model handling of <xref section="6.4" target="RFC7950"/>	This means that any implementation of a managed device must include XPath proces
	and its referenced documents.	sing and related information model handling per <xref section="6.4" target="RFC7
		950"/> and its referenced documents.
	</dd>	</dd>
	<dt>Protocol Coupling:</dt>	<dt>Protocol Coupling:</dt>
	<dd>	<dd>
	<t>	<t>
	A significant amount of existing YANG tooling or modeling presumes the use of YA NG data within a management protocol with specific operations available.	A significant amount of existing YANG tooling or modeling presumes the use of YA NG data within a management protocol with specific operations available.

	For example, the access control model of <xref target="RFC8341"/> relies on thos e operations specific to the *CONF protocols for proper behavior.	For example, the access control model defined in <xref target="RFC8341"/> relies on those operations specific to the *CONF protocols for proper behavior.
	</t>	</t>
	<t>	<t>
	The emergence of multiple NETCONF-derived protocols may make these presumptions less problematic in the future.	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 ta rget="RFC8199"/>.	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 ta rget="RFC8199"/>.
	</t>	</t>
	</dd>	</dd>
	<dt>Manager-Side Control:</dt>	<dt>Manager-Side Control:</dt>
	<dd>	<dd>
	YANG RPCs and actions execute on a managed device and generate an expected, stru ctured response.	YANG RPCs and actions execute on a managed device and generate an expected, stru ctured response.
	RPC execution is strictly limited to those issued by the manager.	RPC execution is strictly limited to those issued by the manager.

	skipping to change at line 1197 ¶	skipping to change at line 1186 ¶
	</dl>	</dl>
	<t>	<t>
	The YANG modeling language continues to evolve as new features are needed by ado pting management protocols.	The YANG modeling language continues to evolve as new features are needed by ado pting management protocols.
	</t>	</t>
	</section>	</section>
	<section>	<section>
	<name>NETCONF Protocol and Transport</name>	<name>NETCONF Protocol and Transport</name>
	<t>	<t>
	NETCONF is a stateful, XML-encoding-based protocol that provides a syntax to ret rieve, edit, copy, or delete any data nodes or exposed functionality on a server .	NETCONF is a stateful, XML-encoding-based protocol that provides a syntax to ret rieve, edit, copy, or delete any data nodes or exposed functionality on a server .
	It requires that underlying transport protocols support long-lived, reliable, lo w-latency, sequenced data delivery sessions.	It requires that underlying transport protocols support long-lived, reliable, lo w-latency, sequenced data delivery sessions.

	A bi-directional NETCONF session needs to be established before any data transfe r (or notification) can occur.	A bidirectional NETCONF session needs to be established before any data transfer (or notification) can occur.
	</t>	</t>
	<t>	<t>

	The XML exchanged within NETCONF messages is structured according to YANG module s supported by the NETCONF agent, and the data nodes reside within one of possib ly many datastores in accordance with the Network Management Datastore Architect ure (NMDA) of <xref target="RFC8342"/>.	The XML exchanged within NETCONF messages is structured according to YANG module s supported by the NETCONF agent, and the data nodes reside within one of possib ly many datastores in accordance with the Network Management Datastore Architect ure (NMDA) <xref target="RFC8342"/>.
	</t>	</t>
	<t>	<t>
	NETCONF transports are required to provide authentication, data integrity, confi dentiality, and replay protection.	NETCONF transports are required to provide authentication, data integrity, confi dentiality, and replay protection.
	Currently, NETCONF can operate over SSH/TCP/IP <xref target="RFC6242"/> or TLS/T CP/IP <xref target="RFC7589"/>.	Currently, NETCONF can operate over SSH/TCP/IP <xref target="RFC6242"/> or TLS/T CP/IP <xref target="RFC7589"/>.
	</t>	</t>
	</section>	</section>
	<section>	<section>
	<name>RESTCONF Protocol and Transport</name>	<name>RESTCONF Protocol and Transport</name>
	<t>	<t>

	RESTCONF is a stateless, JSON-encoding-based protocol that provides the same ope	RESTCONF is a stateless, JSON-encoding-based protocol that provides the same ope
	rations as NETCONF, using the same YANG modules for structure and same NMDA data	rations as NETCONF, using the same YANG modules for structure and the same NMDA
	stores, but using RESTful exchanges over HTTP.	datastores, but using RESTful exchanges over HTTP.
	It uses HTTP-native methods to express its allowed operations: GET, POST, PUT, P	It uses HTTP methods to express its allowed operations: GET, POST, PUT, PATCH, o
	ATCH, or DELETE data nodes within a datastore.	r DELETE data nodes within a datastore.
	</t>	</t>
	<t>	<t>
	Although RESTCONF is a logically stateless protocol, it does rely on state withi n its transport protocol to achieve behaviors such as authentication and securit y sessions.	Although RESTCONF is a logically stateless protocol, it does rely on state withi n its transport protocol to achieve behaviors such as authentication and securit y sessions.

	Because RESTCONF uses the same data node semantics of NETCONF, a typical activit y can involve the use of several sequential round-trips of exchanges to first di scover managed device state and then act upon it.	Because RESTCONF uses the same data node semantics as NETCONF, a typical activit y can involve the use of several sequential round trips of exchanges to first di scover managed device state and then act upon it.
	</t>	</t>
	</section>	</section>
	<section>	<section>
	<name>CORECONF Protocol and Transport</name>	<name>CORECONF Protocol and Transport</name>
	<t>	<t>

	CORECONF is an emerging stateless protocol built atop the Constrai	CORECONF is an emerging stateless protocol built atop CoAP <xref t
	ned	arget="RFC7252"/> that
	Application Protocol (CoAP) <xref target="RFC7252"/> that
	defines a messaging construct developed to operate specifically	defines a messaging construct developed to operate specifically
	on constrained devices and networks by limiting message size and	on constrained devices and networks by limiting message size and

	fragmentation. CoAP also implements a request/response system and	fragmentation. CoAP also implements a request-response system and
	methods for GET, POST, PUT, and DELETE.	methods for GET, POST, PUT, and DELETE.
	</t>	</t>
	</section>	</section>
	</section>	</section>
	<section>	<section>
	<name>gRPC Network Management Interface (gNMI)</name>	<name>gRPC Network Management Interface (gNMI)</name>
	<t>	<t>

	Another emerging but not-IETF-affiliated management protocol is the gRPC Network Management Interface (gNMI) <xref target="gNMI"/> which is based on gRPC messag ing and uses Protobuf data modeling.	Another emerging, but not IETF-affiliated, management protocol is the gRPC Netwo rk Management Interface (gNMI) <xref target="gNMI"/>, which is based on gRPC mes saging and uses Google protobuf data modeling.
	</t>	</t>
	<t>	<t>

	The same limitations of RESTCONF listed above apply to gNMI because of its relia	The same limitations as those listed above for RESTCONF apply to gNMI because of
	nce on synchronous HTTP exchanges and TLS security for normal operations, as wel	its reliance on synchronous HTTP exchanges and TLS for normal operations, as we
	l as the likely deep nesting of data schemas.	ll as the likely deep nesting of data schemas.  gNMI is capable of transpor
	There is a capability for gNMI to transport JSON-encoded YANG-modeled data, but	ting JSON-encoded YANG-modeled data, but how to compose such data is not yet ful
	this composing is not fully standardized and relies on specific tool integration	ly standardized.
	s to operate.
	</t>	</t>
	<section>	<section>
	<name>The Protobuf Modeling Language</name>	<name>The Protobuf Modeling Language</name>
	<t>	<t>

	The data managed and exchanged via gNMI is encoded and modeled using Google Prot obuf, 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 "/>).	The data managed and exchanged via gNMI is encoded and modeled using Google prot obuf, an encoding and modeling syntax not affiliated with the IETF (although an attempt has been made and abandoned <xref target="PROTOCOL-BUFFERS"/>).
	</t>	</t>
	<t>	<t>

	Because the Protobuf modeling syntax is relatively low-level (around the same as ASN.1 or CBOR), there are some efforts as part of the OpenConfig work <xref tar get="gNMI"/> to translate YANG modules into Protobuf schemas (similar to transla tion to XML or JSON schemas for NETCONF and RESTCONF respectively) but there is no required interoperabilty between management via gRPC or any of the *CONF prot ocols.	Because the protobuf modeling syntax is a relatively low-level 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 schemas (similar to translation to XML or JSON schemas for NETCONF and RESTCONF, respectively), but there is no required interoperability between management via gRPC or any of the *CONF protocols.
	</t>	</t>
	</section>	</section>
	<section>	<section>
	<name>gRPC Protocol and Transport</name>	<name>gRPC Protocol and Transport</name>
	<t>	<t>

	The message encoding and exchange for gNMI, as the name implies, is gRPC protoco	The message encoding and exchange for gNMI, as the name implies, is the gRPC pro
	l <xref target="gRPC"/>.	tocol <xref target="gRPC"/>.  gRPC exclusively uses HTTP/2 <xref target="RF
	gRPC exclusively uses HTTP/2 <xref target="RFC9113"/> for transport and relies o	C9113"/> for transport and relies on some aspects specific to HTTP/2 for its ope
	n some aspects specific to HTTP/2 for its operations (such as HTTP trailer field	rations (such as HTTP trailer fields).
	s).	While not mandated by gRPC, when used to transport gNMI data, TLS is required fo
	While not mandated by gRPC, when used to transport gNMI data TLS is required for	r transport security.
	transport security.
	</t>	</t>
	</section>	</section>
	</section>	</section>
	<section>	<section>
	<name>Intelligent Platform Management Interface (IPMI)</name>	<name>Intelligent Platform Management Interface (IPMI)</name>
	<t>	<t>

	A lower-level remote management protocol, intended to be used to manage hardware	A lower-level remote management protocol, intended to be used to manage hardware
	devices and network appliances below the operating system (OS), is the Intellig	devices and network appliances below the operating system (OS), is the Intellig
	ent Platform Management Interface (IPMI) standardized in <xref target="IPMI"/>.	ent Platform Management Interface (IPMI), standardized in <xref target="IPMI"/>.
	The IPMI is focused on health monitoring, event logging, firmware management, an	The IPMI is focused on health monitoring, event logging, firmware management, an
	d serial-over-LAN (SOL) remote console access in a "pre-OS or OS-absent" host en	d Serial over LAN (SOL) remote console access in a "pre-OS or OS-absent" host en
	vironment.	vironment.
	The IPMI operates over a companion Remote Management Control Protocol (RMCP) for messaging, which itself can use UDP for transport.	The IPMI operates over a companion Remote Management Control Protocol (RMCP) for messaging, which itself can use UDP for transport.
	</t>	</t>
	<t>	<t>

	Because the IPMI and RCMP are tailored to low-level and well-connected devices w ithin a datacenter, with typical workflows requiring many messaging round trips or low-latency interactive sessions, they are not suitable for operation over a challenged network.	Because the IPMI and RCMP are tailored to low-level and well-connected devices w ithin a 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>	</t>
	</section>	</section>
	<section>	<section>
	<name>Autonomic Networking</name>	<name>Autonomic Networking</name>
	<t>	<t>

	The future of network operations requires more autonomous behavior	The future of network operations requires more autonomous behavior,
	including self-configuration, self-management, self-healing, and	including self-configuration, self-management, self-healing, and

	self-optimization. One approach to support this is termed Autonomic	self-optimization. One approach to support this is termed "Autonomic
	Networking <xref target="RFC7575"/>.	Networking" <xref target="RFC7575"/>.
	</t>	</t>
	<t>	<t>
	There is a large and growing set of work within the IETF	There is a large and growing set of work within the IETF
	focused on developing an Autonomic Networking Integrated Model and	focused on developing an Autonomic Networking Integrated Model and
	Approach (ANIMA). The ANIMA work has developed a comprehensive	Approach (ANIMA). The ANIMA work has developed a comprehensive
	reference model for distributing autonomic functions across multiple	reference model for distributing autonomic functions across multiple

	nodes in an autonomic networking infrastructure <xref target="RFC8993" />.	nodes in an Autonomic Networking infrastructure <xref target="RFC8993" />.
	</t>	</t>
	<t>	<t>
	This work, focused on learning the behavior of distributed systems to	This work, focused on learning the behavior of distributed systems to
	predict future events, is an emerging network management	predict future events, is an emerging network management

	capability. This includes the development of signalling protocols	capability. This includes the development of signaling protocols
	such as GRASP <xref target="RFC8990"/> and the autonomic control plane	such as the GeneRic Autonomic Signaling Protocol (GRASP) <xref target=
	(ACP)	"RFC8990"/> and the Autonomic Control Plane (ACP)
	<xref target="RFC8368"/>.	<xref target="RFC8368"/>.
	</t>	</t>
	<t>	<t>
	Both autonomic and challenged networks require similar degrees of	Both autonomic and challenged networks require similar degrees of
	autonomy. However, challenged networks cannot provide the complex	autonomy. However, challenged networks cannot provide the complex
	coordination between nodes and distributed supporting infrastructure	coordination between nodes and distributed supporting infrastructure
	necessary for the frequent data exchanges for negotiation, learning,	necessary for the frequent data exchanges for negotiation, learning,
	and bootstrapping associated with the above capabilities.	and bootstrapping associated with the above capabilities.
	</t>	</t>
	<t>	<t>
	There is some emerging work in ANIMA as to how disconnected	There is some emerging work in ANIMA as to how disconnected

	devices might join and leave the autonomic control plane over time.	devices might join and leave the ACP over time.
	However, this work is addressing a different problem	However, this work is addressing a different problem
	than that encountered by challenged networks.	than that encountered by challenged networks.
	</t>	</t>
	</section>	</section>
	<section>	<section>
	<name>Deep Space Autonomy</name>	<name>Deep Space Autonomy</name>
	<t>	<t>
	Outside of the terrestrial networking community, there are existing and establis hed remote management systems used for deep space mission operations.	Outside of the terrestrial networking community, there are existing and establis hed remote management systems used for deep space mission operations.

	Examples of two of these are for the New Horizons mission to Pluto <xref target= "NEW-HORIZONS"/> and the DART mission to the asteroid Dimorphos <xref target="DA RT"/>.	Two examples of such systems are the New Horizons mission to Pluto <xref target= "NEW-HORIZONS"/> and the Double Asteroid Redirection Test (DART) mission to the asteroid Dimorphos <xref target="DART"/>.
	</t>	</t>
	<t>	<t>

	The DTNMA has some heritage in the concepts of deep space autonomy, but each of those mission instantiations use mission-specific data encoding, messaging, and transport as well as mission-specific (or heavily mission-tailored) modeling con cepts and languages.	The DTNMA has some heritage in the concepts of deep space autonomy, but each of those mission instantiations uses mission-specific data encoding, messaging, and transport as well as mission-specific (or heavily mission-tailored) modeling co ncepts 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.	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>	</t>
	</section>	</section>
	</section>	</section>


	<section numbered="true">	<section anchor="motivation-for-new-features" numbered="true">
	<name>Motivation for New Features</name>	<name>Motivation for New Features</name>
	<t>	<t>
	Management mechanisms that provide the complete set of DTNMA desirable	Management mechanisms that provide the complete set of DTNMA desirable

	properties do not currently exist. This is not surprising since	properties do not currently exist. This is not surprising, since
	autonomous management in the context of a challenged networking	autonomous management in the context of a challenged networking
	environment is a new and emerging use case.	environment is a new and emerging use case.
	</t>	</t>

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

	<dl>	<dl>

	<dt>Open Loop Control:</dt>	<dt>Open-Loop Control:</dt>
	<dd>	<dd>
	Freedom from a request-response architecture,	Freedom from a request-response architecture,
	API, or other presumption of timely round-trip communications. This	API, or other presumption of timely round-trip communications. This
	is particularly important when managing networks that are not built	is particularly important when managing networks that are not built
	over an HTTP or TCP/TLS infrastructure.	over an HTTP or TCP/TLS infrastructure.
	</dd>	</dd>
	<dt>Standard Autonomy Model:</dt>	<dt>Standard Autonomy Model:</dt>
	<dd>	<dd>
	An autonomy model that allows for standard	An autonomy model that allows for standard
	expressions of policy to guarantee deterministic behavior across	expressions of policy to guarantee deterministic behavior across

	skipping to change at line 1354 ¶	skipping to change at line 1340 ¶
	</dd>	</dd>
	<dt>Compressible Model Structure:</dt>	<dt>Compressible Model Structure:</dt>
	<dd>	<dd>
	A data model that allows for very	A data model that allows for very
	compact encodings by defining and exploiting common structures for	compact encodings by defining and exploiting common structures for
	data schemas.	data schemas.
	</dd>	</dd>
	</dl>	</dl>
	<t>	<t>
	Combining these new features with existing mechanisms for message data	Combining these new features with existing mechanisms for message data

	exchange (such as BP), data representations (such as CBOR) and data	exchange (such as BP), data representations (such as CBOR), and data
	modeling languages (such as YANG) will form a pragmatic approach to	modeling languages (such as YANG) will form a pragmatic approach to
	defining challenged network management.	defining challenged network management.
	</t>	</t>
	</section>	</section>


	<section numbered="true">	<section anchor="reference-model" numbered="true">
	<name>Reference Model</name>	<name>Reference Model</name>
	<t>	<t>

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

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

	<t>	<t>

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


	<aside>
	<t>	<t>

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

	</aside>

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

	<dl>	<dl>

	<dt>Pre-shared Definitions:</dt>	<dt>Pre-Shared Definitions:</dt>
	<dd>	<dd>
	Managing and managed devices should operate	Managing and managed devices should operate
	using pre-shared data definitions and models. This implies that	using pre-shared data definitions and models. This implies that
	static definitions should be standardized whenever possible and	static definitions should be standardized whenever possible and
	that managing and managed devices may need to negotiate definitions	that managing and managed devices may need to negotiate definitions
	during periods of connectivity.	during periods of connectivity.
	</dd>	</dd>
	<dt>Agent Self-Management:</dt>	<dt>Agent Self-Management:</dt>
	<dd>	<dd>
	A managed device may find itself	A managed device may find itself

	skipping to change at line 1420 ¶	skipping to change at line 1404 ¶
	a regular connection to a managing device. In these cases, DAs manag e	a regular connection to a managing device. In these cases, DAs manag e
	themselves by applying pre-shared policies received from managing	themselves by applying pre-shared policies received from managing
	devices.	devices.
	</dd>	</dd>
	<dt>Command-Based Interface:</dt>	<dt>Command-Based Interface:</dt>
	<dd>	<dd>
	Managing devices communicate with managed	Managing devices communicate with managed
	devices through a command-based interface. Instead of exchanging	devices through a command-based interface. Instead of exchanging
	variables, objects, or documents, a managing device issues commands	variables, objects, or documents, a managing device issues commands
	to be run by a managed device. These commands may create or update	to be run by a managed device. These commands may create or update

	variables, change data stores, or impact the managed device in ways	variables, change datastores, or impact the managed device in ways
	similar to other network management approaches. The use of commands	similar to other network management approaches. The use of commands
	is, in part, driven by the need for DAs to receive updates from	is, in part, driven by the need for DAs to receive updates from

	both remote management devices and local autonomy. The use of contro ls for the implementation of commands is discussed in more detail in <xref targe t="ctrl_exec"/>.	both remote management devices and local autonomy. The use of Contro ls for the implementation of commands is discussed in more detail in <xref targe t="ctrl_exec"/>.
	</dd>	</dd>
	</dl>	</dl>
	</section>	</section>

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

	<t>	<t>
	A DTNMA reference model is provided in <xref target="dtnma_ref_model"/>	A DTNMA reference model is provided in <xref target="dtnma_ref_model"/>
	below. In this reference model, applications and services on a managing	below. In this reference model, applications and services on a managing

	device communicate with a DM which uses pre-shared definitions to create	device communicate with a DM that uses pre-shared definitions to create
	a set of policy directives that can be sent to a managed device's DA via	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	a command-based interface. The DA provides local monitoring and control
	(commanding) of the applications and services resident on the managed	(commanding) of the applications and services resident on the managed
	device. The DA also performs local data fusion as necessary to synthesiz e data products (such as	device. The DA also performs local data fusion as necessary to synthesiz e data products (such as
	reports) that can be sent back to the DM when appropriate.	reports) that can be sent back to the DM when appropriate.
	</t>	</t>


	<t keepWithNext="true">DTNMA Reference Model</t>
	<figure anchor="dtnma_ref_model">	<figure anchor="dtnma_ref_model">

		<name>DTNMA Reference Model</name>
	<artwork align="center" name="" type="" alt=""><![CDATA[	<artwork align="center" name="" type="" alt=""><![CDATA[
	Managed Device Managing Device	Managed Device Managing Device
	+----------------------------+ +-----------------------------+	+----------------------------+ +-----------------------------+
	\| +------------------------+ \| \| +-------------------------+ \|	\| +------------------------+ \| \| +-------------------------+ \|
	\| \|Applications & Services \| \| \| \| Applications & Services \| \|	\| \|Applications & Services \| \| \| \| Applications & Services \| \|
	\| +----------^-------------+ \| \| +-----------^-------------+ \|	\| +----------^-------------+ \| \| +-----------^-------------+ \|
	\| \| \| \| \| \|	\| \| \| \| \| \|
	\| +----------v-------------+ \| \| +-----------v-------------+ \|	\| +----------v-------------+ \| \| +-----------v-------------+ \|
	\| \| DTNMA +-------------+ \| \| \| \| +-----------+ DTNMA \| \|	\| \| DTNMA +-------------+ \| \| \| \| +-----------+ DTNMA \| \|
	\| \| AGENT \| Monitor and \| \| \|Commanding \| \| \| Policy \| MANAGER \| \|	\| \| AGENT \| Monitor and \| \| \|Commanding \| \| \| Policy \| MANAGER \| \|

	skipping to change at line 1465 ¶	skipping to change at line 1449 ¶
	\| \| +------+-------------+ \| \| \| \| +-----------+-------+ \| \|	\| \| +------+-------------+ \| \| \| \| +-----------+-------+ \| \|
	\| \| \|Admin \| Data Fusion \| \| \|==========>\| \| \| Reporting \| Admin \| \| \|	\| \| \|Admin \| Data Fusion \| \| \|==========>\| \| \| Reporting \| Admin \| \| \|
	\| \| +------+-------------+ \| \| Reporting \| \| +-----------+-------+ \| \|	\| \| +------+-------------+ \| \| Reporting \| \| +-----------+-------+ \| \|
	\| +------------------------+ \| \| +-------------------------+ \|	\| +------------------------+ \| \| +-------------------------+ \|
	+----------------------------+ +-----------------------------+	+----------------------------+ +-----------------------------+
	^ ^	^ ^
	\| Pre-Shared Definitions \|	\| Pre-Shared Definitions \|
	\| +---------------------------+ \|	\| +---------------------------+ \|
	+--------\| - Autonomy Model \|--------+	+--------\| - Autonomy Model \|--------+
	\| - Application Data Models \|	\| - Application Data Models \|

	\| - Runtime Data Stores \|	\| - Runtime Datastores \|
	+---------------------------+	+---------------------------+

	]]></artwork>	]]></artwork>
	</figure>	</figure>

	<t>	<t>
	This model preserves the familiar concept of "managers" resident on	This model preserves the familiar concept of "managers" resident on
	managing devices and "agents" resident on managed devices. However,	managing devices and "agents" resident on managed devices. However,
	the DTNMA model is unique in how the DM and DA operate. The DM is	the DTNMA model is unique in how the DM and DA operate. The DM is

	used to pre-configure DAs in the network with management policies.	used to preconfigure DAs in the network with management policies.
	it is expected that the DAs, themselves, perform monitoring and	It is expected that the DAs, themselves, perform monitoring and
	control functions on their own. In this way, a properly configured	control functions on their own. In this way, a properly configured
	DA may operate without a reliable connection back to a DM.	DA may operate without a reliable connection back to a DM.
	</t>	</t>
	</section>	</section>

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

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

	<section numbered="true">	<section numbered="true">
	<name>Managed Applications and Services</name>	<name>Managed Applications and Services</name>
	<t>	<t>
	By definition, managed applications and services reside on a	By definition, managed applications and services reside on a
	managed device. These software entities can be controlled through	managed device. These software entities can be controlled through

	some interface by the DA and their state can be sampled as part of	some interface by the DA, and their state can be sampled as part of
	periodic monitoring. It is presumed that the DA on the managed	periodic monitoring. It is presumed that the DA on the managed
	device has the proper data model, control interface, and	device has the proper data model, control interface, and
	permissions to alter the configuration and behavior of these	permissions to alter the configuration and behavior of these
	software applications.	software applications.
	</t>	</t>
	</section>	</section>

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

	<t>	<t>
	A DA resides on a managed device. As is the case	A DA resides on a managed device. As is the case
	with other network management approaches, this agent is responsible	with other network management approaches, this agent is responsible
	for the monitoring and control of the applications local to that	for the monitoring and control of the applications local to that
	device. Unlike other network management approaches, the agent	device. Unlike other network management approaches, the agent

	accomplishes this task without a regular connection to a DTNMA	accomplishes this task without a regular connection to a DM.
	Manager.
	</t>	</t>

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

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

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


	<dl newline="true" spacing="normal" indent="8">	<dl newline="true" spacing="normal">
	<dt>Rules Database:</dt>	<dt>Rule Database:</dt>
	<dd>	<dd>
	Each DA maintains a database of policy expressions that form	Each DA maintains a database of policy expressions that form

	rules of behavior of the managed device. Within this database,	rules regarding the behavior of the managed device. Within this
	each rule of behavior is a tuple of a stimulus and a response.	database,
		each rule regarding behavior is a tuple of a stimulus and a resp
		onse.
	Within the DTNMA, these rules are the embodiment of	Within the DTNMA, these rules are the embodiment of
	policy expressions received from DMs and evaluated at	policy expressions received from DMs and evaluated at

	regular intervals by the autonomy engine. The rules database is	regular intervals by the autonomy engine. The rule database is
	the collection of active rules known to the DA.	the collection of active rules known to the DA.
	</dd>	</dd>

	<dt>Autonomy Engine:</dt>	<dt>Autonomy Engine:</dt>
	<dd>	<dd>

	The DA autonomy engine monitors the state of the managed device	The DA autonomy engine monitors the state of the managed device,
	looking for pre-defined stimuli and, when encountered, issuing a	looking for predefined stimuli and, when such stimuli are encoun
	pre-defined response. To the extent that this function is driven	tered, issuing a
	by the rules database, this engine acts as a policy execution	predefined response. To the extent that this function is driven
		by the rule database, this engine acts as a policy execution
	engine. This engine may also be directly configured by	engine. This engine may also be directly configured by
	managers during periods of connectivity for actions separate	managers during periods of connectivity for actions separate

	from those in the rules database (such as enabling or disabling	from those in the rule database (such as enabling or disabling
	sets of rules). Once configured, the engine may function	sets of rules). Once configured, the engine may function
	without other access to any managing device. This engine may	without other access to any managing device. This engine may
	also reconfigure itself as a function of policy.	also reconfigure itself as a function of policy.
	</dd>	</dd>

	<dt>Application Control Interfaces:</dt>	<dt>Application Control Interfaces:</dt>
	<dd>	<dd>
	DAs support control interfaces for all	DAs support control interfaces for all
	managed applications. Control interfaces are used to alter	managed applications. Control interfaces are used to alter
	the configuration and behavior of an application. These	the configuration and behavior of an application. These

	interfaces may be custom for each application, or as provided	interfaces may be custom for each application or as provided
	through a common framework such as provided by an operating	through a common framework, protocol, or OS.
	system.
	</dd>	</dd>
	</dl>	</dl>
	</section>	</section>

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

	<t>	<t>
	DAs generate new data elements as a function of the	DAs generate new data elements as a function of the
	current state of the managed device and its applications. These	current state of the managed device and its applications. These

	new data products may take the form of individual data values,	new data products may take the form of individual data values
	or new collections of data used for reporting. The logical	or of new collections of data used for reporting. The logical
	components responsible for these behaviors are as follows.	components responsible for these behaviors are as follows.
	</t>	</t>


	<dl newline="true" spacing="normal" indent="8">	<dl newline="true" spacing="normal">
	<dt>Application Data Interfaces:</dt>	<dt>Application Data Interfaces:</dt>
	<dd>	<dd>
	DAs support mechanisms by which important state is	DAs support mechanisms by which important state is
	retrieved from various applications resident on the managed	retrieved from various applications resident on the managed
	device. These data interfaces may be custom for each	device. These data interfaces may be custom for each

	application, or as provided through a common framework such	application or as provided through a common framework,
	as provided by an operating system.	protocol, or OS.
	</dd>	</dd>

	<dt>Data Value Generators:</dt>	<dt>Data Value Generators:</dt>
	<dd>	<dd>
	DAs may support the generation of new data values as a	DAs may support the generation of new data values as a
	function of other values collected from the managed device.	function of other values collected from the managed device.
	These data generators may be configured with descriptions of	These data generators may be configured with descriptions of

	data values and the data values they generate may be included	data values, and the data values they generate may be included
	in the overall monitoring and reporting associated with the	in the overall monitoring and reporting associated with the
	managed device.	managed device.
	</dd>	</dd>

	<dt>Report Generators:</dt>	<dt>Report Generators:</dt>
	<dd>	<dd>
	DAs may, as appropriate, generate collections of data values	DAs may, as appropriate, generate collections of data values
	and provide them to whatever local mechanism takes	and provide them to whatever local mechanism takes
	responsibility for their eventual transmission (or expiration	responsibility for their eventual transmission (or expiration
	and removal). Reports can be generated as a matter of policy	and removal). Reports can be generated as a matter of policy
	or in response to the handling of critical events (such as	or in response to the handling of critical events (such as

	errors), or other logging needs. The generation of a report is	errors) or other logging needs. The generation of a report is
	independent of whether there exists any connectivity between a	independent of whether there exists any connectivity between a
	DA and a DM.	DA and a DM.
	</dd>	</dd>
	</dl>	</dl>
	</section>	</section>

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

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


	<dl newline="true" spacing="normal" indent="8">	<dl newline="true" spacing="normal">
	<dt>Manager Mapping:</dt>	<dt>Manager Mapping:</dt>
	<dd>	<dd>
	<t>	<t>

	The DTNMA allows for a many-to-many relationship amongst DTNMA	The DTNMA allows for a many-to-many relationship amongst DAs
	Agents and Managers. A single DM may configure multiple	and DMs. A single DM may configure multiple
	DAs, and a single DA may be configured by multiple	DAs, and a single DA may be configured by multiple
	DMs. Multiple managers may exist in a network for at least	DMs. Multiple managers may exist in a network for at least

	two reasons. First, different managers may exist to control	the following two reasons. First, different managers may exist to control
	different applications on a device. Second, multiple managers	different applications on a device. Second, multiple managers
	increase the likelihood of an agent encountering a manager whe n	increase the likelihood of an agent encountering a manager whe n
	operating in a sparse or challenged environment.	operating in a sparse or challenged environment.
	</t>	</t>

	<t>	<t>

	While the need for multiple managers is required for operating	While multiple managers are needed for proper operation in
	in a dynamically partitioned network, this situation allows fo	a dynamically partitioned network, conflicting information from
	r	different managers can result.
	the possibility of conflicting information from different mana
	gers.
	Implementations of the DTNMA should consider conflict resoluti on	Implementations of the DTNMA should consider conflict resoluti on
	mechanisms. Such mechanisms might include analyzing managed co ntent,	mechanisms. Such mechanisms might include analyzing managed co ntent,
	time, agent location, or other relevant information to select	time, agent location, or other relevant information to select
	one manager input over other manager inputs.	one manager input over other manager inputs.
	</t>	</t>
	</dd>	</dd>
	<dt>Data Verifiers:</dt>	<dt>Data Verifiers:</dt>
	<dd>	<dd>
	DAs might handle large amounts of data produced by various	DAs might handle large amounts of data produced by various
	sources, to include data from local managed applications,	sources, to include data from local managed applications,

	skipping to change at line 1673 ¶	skipping to change at line 1655 ¶

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

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

	<t>	<t>
	Managing applications and services reside on a managing device an d	Managing applications and services reside on a managing device an d

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

	<aside>	<aside>
	<t>	<t>
	NOTE: Closed-loop control in this context refers to the	NOTE: Closed-loop control in this context refers to the
	practice of waiting for a response from a managed device prior	practice of waiting for a response from a managed device prior
	to issuing new commands to that device. These "loops" may be	to issuing new commands to that device. These "loops" may be

	closed quickly (in milliseconds) or over much longer periods (	closed quickly (in milliseconds) or over much longer periods
	hours, days, years). The alternative to closed-loop control is	(hours, days, years). The alternative to closed-loop control is
	open-loop control, where the issuance of new commands is not	open-loop control, where the issuance of new commands is not
	dependent on receiving responses to previous commands.	dependent on receiving responses to previous commands.

	Additionally, there might not be a 1-1 mapping between commands	Additionally, there might not be a one-to-one mapping between co mmands
	and responses. A DA may, for example, produce a single response	and responses. A DA may, for example, produce a single response

	that captures the end state from applying multiple commands.	that represents the end state of applying multiple commands.
	</t>	</t>
	</aside>	</aside>

	</section>	</section>

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

	<t>	<t>
	A DM resides on a managing device. This manager	A DM resides on a managing device. This manager
	provides an interface between various managing applications and	provides an interface between various managing applications and
	services and the DAs that enforce their policies. In	services and the DAs that enforce their policies. In
	providing this interface, DMs translate between whatever	providing this interface, DMs translate between whatever

	native interface exists to various managing applications and the	innate interface exists to various managing applications and the
	autonomy models used to encode management policy.	autonomy models used to encode management policy.
	</t>	</t>
	<t>	<t>
	The DM performs three major functions on a managing	The DM performs three major functions on a managing
	device: policy encoding, reporting, and administration.	device: policy encoding, reporting, and administration.
	</t>	</t>

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

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


	<dl newline="true" spacing="normal" indent="8">	<dl newline="true" spacing="normal">
	<dt>Application Control Interfaces:</dt>	<dt>Application Control Interfaces:</dt>
	<dd>	<dd>
	DMs support control interfaces for managing	DMs support control interfaces for managing
	applications. These control interfaces are used to receive	applications. These control interfaces are used to receive
	desired policy statements from applications. These interfaces	desired policy statements from applications. These interfaces

	may be custom for each application, or provided through	may be custom for each application or as provided through
	a common framework, protocol, or operating system.	a common framework, protocol, or OS.
	</dd>	</dd>

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

	skipping to change at line 1769 ¶	skipping to change at line 1751 ¶
	<section numbered="true">	<section numbered="true">
	<name>Reporting</name>	<name>Reporting</name>

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


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


	skipping to change at line 1793 ¶	skipping to change at line 1775 ¶
	extracting relevant data to communicate with managing	extracting relevant data to communicate with managing
	applications. This may include simple data extraction or may	applications. This may include simple data extraction or may
	include more complex processing such as data conversion, data	include more complex processing such as data conversion, data
	fusion, and appropriate data analytics.	fusion, and appropriate data analytics.
	</dd>	</dd>

	<dt>Application Data Interfaces:</dt>	<dt>Application Data Interfaces:</dt>
	<dd>	<dd>
	DMs support mechanisms by which data retrieved	DMs support mechanisms by which data retrieved
	from DAs may be provided back to managing devices. These	from DAs may be provided back to managing devices. These

	interfaces may be custom for each application, or as	interfaces may be custom for each application or as
	provided through a common framework, protocol, or operating	provided through a common framework, protocol, or OS.
	system.
	</dd>	</dd>
	</dl>	</dl>
	</section>	</section>

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

	<t>	<t>

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


	<dl newline="true" spacing="normal" indent="8">	<dl newline="true" spacing="normal">
	<dt>Agent Mappings:</dt>	<dt>Agent Mappings:</dt>
	<dd>	<dd>
	The DTNMA allows DMs to communicate with multiple	The DTNMA allows DMs to communicate with multiple
	DAs. However, not every agent in a network is expected	DAs. However, not every agent in a network is expected

	to support the same set of Application Data Models or	to support the same set of application data models or
	otherwise have the same set of managed applications running.	otherwise have the same set of managed applications running.
	For this reason, DMs determine individual DA	For this reason, DMs determine individual DA
	capabilities to ensure that only appropriate Controls are	capabilities to ensure that only appropriate Controls are
	sent to a DA.	sent to a DA.
	</dd>	</dd>

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

	<dt>Access Controllers:</dt>	<dt>Access Controllers:</dt>
	<dd>	<dd>

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

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

	<t>	<t>
	A consequence of operating in a challenged environment is the	A consequence of operating in a challenged environment is the

	potential inability to negotiate information in real-time. For	potential inability to negotiate information in real time. For
	this reason, the DTNMA requires that managed and managing devices	this reason, the DTNMA requires that managed and managing devices
	operate using pre-shared definitions rather than relying on data	operate using pre-shared definitions rather than relying on data
	definition negotiation.	definition negotiation.
	</t>	</t>

		<t>
	<t>
	The three types of pre-shared definitions in the DTNMA are the	The three types of pre-shared definitions in the DTNMA are the
	DA autonomy model, managed application data models,	DA autonomy model, managed application data models,
	and any runtime data shared by managers and agents.	and any runtime data shared by managers and agents.
	</t>	</t>


	<dl newline="true" spacing="normal" indent="8">	<dl newline="true" spacing="normal">
	<dt>Autonomy Model:</dt>	<dt>Autonomy Model:</dt>
	<dd>	<dd>
	<t>	<t>
	A DTNMA autonomy model represents the data elements and	A DTNMA autonomy model represents the data elements and
	associated autonomy structures that define the behavior of	associated autonomy structures that define the behavior of
	the agent autonomy engine. A standardized autonomy	the agent autonomy engine. A standardized autonomy

	model allows for individual implementations of DAs, and DMs	model allows for individual implementations of DAs and DMs
	to interoperate. A standardized model also	to interoperate. A standardized model also
	provides guidance to the design and implementation of both	provides guidance to the design and implementation of both
	managed and managing applications.	managed and managing applications.
	</t>	</t>
	</dd>	</dd>

	<dt>Application Data Models:</dt>	<dt>Application Data Models:</dt>
	<dd>	<dd>
	As with other network management architectures, the DTNMA	As with other network management architectures, the DTNMA

	pre-supposes that managed applications (and services) define	presupposes that managed applications (and services) define
	their own data models. These data models include the data	their own data models. These data models include the data
	produced by, and Controls implemented by, the application.	produced by, and Controls implemented by, the application.
	These models are expected to be static for individual	These models are expected to be static for individual
	applications and standardized for applications implementing	applications and standardized for applications implementing
	standard protocols.	standard protocols.
	</dd>	</dd>


	<dt>Runtime Data Stores:</dt>	<dt>Runtime Datastores:</dt>
	<dd>	<dd>

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

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


	<section numbered="true">	<section anchor="desired-services" numbered="true">
	<name>Desired Services</name>	<name>Desired Services</name>
	<t>	<t>
	This section describes the services provided by DTNMA	This section describes the services provided by DTNMA

	components on both managing and managed devices. Many	components on both managing and managed devices. Most
	of the services discussed in this section attempt to provide	of the services discussed in this section attempt to provide
	continuous operation of a managed device through periods of	continuous operation of a managed device through periods of
	no connectivity with a managing device.	no connectivity with a managing device.
	</t>	</t>

	<section numbered="true">	<section numbered="true">
	<name>Local Monitoring and Control</name>	<name>Local Monitoring and Control</name>
	<t>	<t>
	DTNMA monitoring is associated with some DA autonomy engine. The	DTNMA monitoring is associated with some DA autonomy engine. The

	term monitoring implies regular access to information such that	term "monitoring" implies regular access to information such that
	state changes may be acted upon within some response time period.	state changes may be acted upon within some response time period.
	</t>	</t>

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

	<t>	<t>

	Similar to monitoring, DTNMA control results in actions by the	Like monitoring, DTNMA control results in actions by the
	agent to change the state or behavior of the managed	agent to change the state or behavior of the managed
	device. All control in the DTNMA is local control. In cases where	device. All control in the DTNMA is local control. In cases where

	there exists a timely connection to a manager, received Controls	there exists a timely connection to a DM, received Controls
	are still evaluated and run locally as part of local autonomy. In	are still evaluated and run locally as part of local autonomy. In

	this case, the autonomy stimulus is the receipt of the Control and	this case, the autonomy stimulus is the receipt of the Control, and
	the response is to immediately run the Control. In this way, there	the response is to immediately run the Control. In this way, there
	is never a dependency on a session or other stateful exchange with	is never a dependency on a session or other stateful exchange with
	any remote entity.	any remote entity.
	</t>	</t>
	</section>	</section>

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

	DTNMA Fusion services produce new data products from existing	DTNMA fusion services produce new data products from existing
	state on the managed device. These fusion products can be anything	state on the managed device. These fusion products can be anything
	from simple summations of sampled counters to complex calculations	from simple summations of sampled counters to complex calculations
	of behavior over time.	of behavior over time.
	</t>	</t>
	<t>	<t>
	Fusion is an important service in the DTNMA because fusion	Fusion is an important service in the DTNMA because fusion
	products are part of the overall state of a managed device.	products are part of the overall state of a managed device.
	Complete knowledge of this overall state is important for the	Complete knowledge of this overall state is important for the

	management of the device and the predicates of rules on a DA may	management of the device, and the predicates of rules on a DA may
	refer to fused data.	refer to fused data.
	</t>	</t>

	<t>	<t>

	In-situ data fusion is an important function as it allows	In situ data fusion is an important function, as it allows
	for the construction of intermediate summary data, the reduction	for the construction of intermediate summary data, the reduction

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

	skipping to change at line 1984 ¶	skipping to change at line 1964 ¶
	and/or better outcomes.	and/or better outcomes.
	</t>	</t>
	</aside>	</aside>

	</section>	</section>

	<section numbered="true">	<section numbered="true">
	<name>Remote Configuration</name>	<name>Remote Configuration</name>
	<t>	<t>
	DTNMA configuration services update the local configuration	DTNMA configuration services update the local configuration

	of a managed device with the intent to impact the behavior and	of a managed device with the intent of impacting the behavior and
	capabilities of that device.	capabilities of that device.
	</t>	</t>

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


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

	</aside>

	<t>	<t>
	When detecting stimuli, the agent autonomy engine supports	When detecting stimuli, the agent autonomy engine supports
	a mechanism for evaluating whether application monitoring data	a mechanism for evaluating whether application monitoring data
	or runtime data values are recent enough to indicate a change of	or runtime data values are recent enough to indicate a change of
	state. In cases where data has not been updated recently, it may	state. In cases where data has not been updated recently, it may

	be considered stale and not used to reliably indicate that some	be considered stale and therefore not used to reliably indicate that s ome
	stimulus has occurred.	stimulus has occurred.
	</t>	</t>
	</section>	</section>

	<section numbered="true">	<section numbered="true">
	<name>Remote Reporting</name>	<name>Remote Reporting</name>
	<t>	<t>
	DTNMA reporting services collect information known to the managed	DTNMA reporting services collect information known to the managed
	device and prepare it for eventual transmission to one or more	device and prepare it for eventual transmission to one or more
	managing devices. The contents of these reports, and the frequency at	managing devices. The contents of these reports, and the frequency at

	which they are generated, occurs as a function of the state of the	which they are generated, occur as a function of the state of the
	managed device, independent of the managing device.	managed device, independent of the managing device.
	</t>	</t>

	<t>	<t>

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

	<aside>	<aside>
	<t>	<t>
	NOTE: When reports are queued pending transmission, the overall	NOTE: When reports are queued pending transmission, the overall
	storage capacity at the queuing device needs to be considered.	storage capacity at the queuing device needs to be considered.
	There may be cases where queued reports can be considered expired	There may be cases where queued reports can be considered expired

	either because they have been queued for too long, or because	because they have been either queued for too long or
	they have been replaced by a newer report. When a report is	replaced by a newer report. When a report is
	considered expired, it may be considered for removal and, thus,	considered expired, it may be considered for removal and, thus,
	never transmitted. This consideration is expected to be part of	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.	the implementation of the queuing device and not the responsibility of the reporting function within the DTNMA.
	</t>	</t>
	</aside>	</aside>

	<t>	<t>
	When reports are sent to a managing device over a challenged	When reports are sent to a managing device over a challenged
	network, they may arrive out of order due to taking different paths	network, they may arrive out of order due to taking different paths
	through the network or being delayed due to retransmissions. A	through the network or being delayed due to retransmissions. A

	skipping to change at line 2077 ¶	skipping to change at line 2055 ¶

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

	<t>	<t>

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


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

	<t>	<t>
	This section describes a logical autonomy model in terms of the	This section describes a logical autonomy model in terms of the

	skipping to change at line 2119 ¶	skipping to change at line 2097 ¶
	allows for the model to be configured for a wide range of future	allows for the model to be configured for a wide range of future
	situations. Determinism allows for the forensic reconstruction of	situations. Determinism allows for the forensic reconstruction of
	device behavior as part of debugging or recovery efforts. It	device behavior as part of debugging or recovery efforts. It
	also is necessary to ensure predictable behavior.	also is necessary to ensure predictable behavior.
	</t>	</t>

	<aside>	<aside>
	<t>	<t>
	NOTE: The use of predicate logic and a stimulus-response	NOTE: The use of predicate logic and a stimulus-response
	system does not conflict with the use of higher-level	system does not conflict with the use of higher-level

	autonomous function or the incorporation of machine learning.	autonomous functions or the incorporation of Machine Learning (ML) .
	Specifically, the DTNMA deterministic autonomy model can	Specifically, the DTNMA deterministic autonomy model can
	coexist with other autonomous functions managing applications	coexist with other autonomous functions managing applications
	and network services.	and network services.
	</t>	</t>
	<t>	<t>

	An example of such co-existence is the use of the DTNMA model	An example of such coexistence is the use of the DTNMA model
	to ensure a device stays within safe operating parameters while	to ensure that a device stays within safe operating parameters whi
	a less deterministic machine learning model directs smaller	le
		a less deterministic ML model directs other
	behaviors for the device.	behaviors for the device.
	</t>	</t>
	</aside>	</aside>

	<t>	<t>
	The DTNMA autonomy model is a rule-based model in which individual	The DTNMA autonomy model is a rule-based model in which individual
	rules associate a pre-identified stimulus	rules associate a pre-identified stimulus

	with a pre-configured response to that stimulus.	with a preconfigured response to that stimulus.
	</t>	</t>

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

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


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

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


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

	]]></artwork>	]]></sourcecode>

	<aside>	<aside>
	<t>	<t>
	NOTE: The DTNMA model remains a stimulus-response system, regardle ss	NOTE: The DTNMA model remains a stimulus-response system, regardle ss
	of whether a common condition is part of the stimulus. However,	of whether a common condition is part of the stimulus. However,
	it is recommended that implementations incorporate a common	it is recommended that implementations incorporate a common
	condition because of the efficiency provided by such a bulk	condition because of the efficiency provided by such a bulk
	evaluation.	evaluation.
	</t>	</t>
	<t>	<t>

	NOTE: One use of a stimulus "common condition" is to associated th	NOTE: One use of a stimulus "common condition" is to associate the
	e	condition with an onboard event such as the expiring of a timer or
	condition with an on-board event such as the expiring of a timer o
	r
	the changing of a monitored value.	the changing of a monitored value.
	</t>	</t>

		</aside>

	<t>	<t>

	NOTE: The DTNMA does not prescribe when to evaluate rule stimuli.	The DTNMA does not prescribe when to evaluate rule stimuli.
	Implementations may choose to evaluate rule stimuli at periodic	Implementations may choose to evaluate rule stimuli at periodic

	intervals (such as 1Hz or 100Hz). When stimuli include on-board	intervals (such as 1 Hz or 100 Hz). When stimuli include onboard
	events, implementations may choose to perform an immediate	events, implementations may choose to perform an immediate
	evaluation at the time of the event rather than waiting for a	evaluation at the time of the event rather than waiting for a
	periodic evaluation.	periodic evaluation.
	</t>	</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">	<figure anchor="dtnma_aut_model">

		<name>DTNMA Autonomy Model</name>
	<artwork align="center" name="" type="" alt=""><![CDATA[	<artwork align="center" name="" type="" alt=""><![CDATA[


	Managed Applications \| DTNMA Agent \| DTNMA Manager	Managed Applications \| DTNMA Agent \| DTNMA Manager
	+---------------------+--------------------------------+--------------+	+---------------------+--------------------------------+--------------+
	\| +---------+ \|	\| +---------+ \|
	\| \| Local \| \| Encoded	\| \| Local \| \| Encoded
	\| \| Rule DB \|<-------------------- Policy	\| \| Rule DB \|<-------------------- Policy
	\| +---------+ \| Expressions	\| +---------+ \| Expressions
	\| ^ \|	\| ^ \|
	\| \| \|	\| \| \|
	\| v \|	\| v \|
	\| +----------+ +---------+ \|	\| +----------+ +---------+ \|
	Monitoring Data------>\| Agent \| \| Runtime \| \|	Monitoring Data------>\| Agent \| \| Runtime \| \|

	\| \| Autonomy \|<-->\| Data \|<---- Definitions	\| \| Autonomy \|<-->\| Data- \|<---- Definitions
	Application Control<------\| Engine \| \| Store \| \|	Application Control<------\| Engine \| \| store \| \|
	\| +----------+ +---------+ \|	\| +----------+ +---------+ \|
	\| \| \|	\| \| \|
	\| +-------------------------> Reports	\| +-------------------------> Reports
	\| \|	\| \|

	]]></artwork>	]]></artwork>
	</figure>	</figure>

	<t>	<t>

	The flow of data into and out of the agent autonomy engine is	In the model shown in <xref target="dtnma_aut_model"/>,
	illustrated in <xref target="dtnma_aut_model"/>. In this model,
	the autonomy engine stores the combination of stimulus	the autonomy engine stores the combination of stimulus
	conditions and associated responses as a set of "rules" in a	conditions and associated responses as a set of "rules" in a

	rules database. This database is updated through the execution of	rule database. This database is updated through the execution of
	the autonomy engine and as configured from policy statements	the autonomy engine and as configured from policy statements

	received by managers.	received by DMs.
	</t>	</t>
	<t>	<t>
	Stimuli are detected by examining the state of applications as	Stimuli are detected by examining the state of applications as
	reported through application monitoring interfaces and through	reported through application monitoring interfaces and through

	any locally-derived data. Local data is calculated in accordance	any locally derived data. Local data is calculated in accordance
	with definitions also provided by managers as part of the runtime	with definitions also provided by DMs as part of the runtime
	data store.	datastore.
	</t>	</t>
	<t>	<t>

	Responses to stimuli may include updates to the rules database,	Responses to stimuli may include updates to the rule database,
	updates to the runtime data store, Controls sent to applications,	updates to the runtime datastore, Controls sent to applications,
	and the generation of reports.	and the generation of reports.
	</t>	</t>

	</section>	</section>

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

	<t>	<t>
	There are several practical challenges to the implementation of a	There are several practical challenges to the implementation of a

	skipping to change at line 2261 ¶	skipping to change at line 2238 ¶
	data logging and reporting for deterministic offline analysis. Rule differences	data logging and reporting for deterministic offline analysis. Rule differences
	across managed devices may lead to oscillating effects. This section	across managed devices may lead to oscillating effects. This section
	identifies those characteristics of an autonomy model that might	identifies those characteristics of an autonomy model that might
	help implementations mitigate some of these challenges.	help implementations mitigate some of these challenges.
	</t>	</t>

	<t>	<t>
	There are a number of ways to represent data values, and many	There are a number of ways to represent data values, and many
	data modeling languages exist for this purpose. When	data modeling languages exist for this purpose. When
	considering how to model data in the context of the DTNMA	considering how to model data in the context of the DTNMA

	autonomy model there are some modeling features that should be	autonomy model, there are some modeling features that should be
	present to enable functionality. There are also some modeling	present to enable functionality. There are also some modeling
	features that should be prevented to avoid ambiguity.	features that should be prevented to avoid ambiguity.
	</t>	</t>
	<t>	<t>

	Traditional network management approaches favor flexibility in	Conventional network management approaches favor flexibility in
	their data models. The DTNMA stresses deterministic behavior	their data models. The DTNMA stresses deterministic behavior
	that supports forensic analysis of agent activities "after the	that supports forensic analysis of agent activities "after the
	fact". As such, the following statements should be true of all	fact". As such, the following statements should be true of all
	data representations relating to DTNMA autonomy.	data representations relating to DTNMA autonomy.
	</t>	</t>

	<dl>	<dl>
	<dt>Strong Typing:</dt>	<dt>Strong Typing:</dt>
	<dd>	<dd>
	The predicates and expressions that comprise	The predicates and expressions that comprise
	the autonomy services in the DTNMA should require strict data	the autonomy services in the DTNMA should require strict data
	typing. This avoids errors associated with implicit data	typing. This avoids errors associated with implicit data

	conversions and helps detect misconfiguration.	conversions and helps detect misconfigurations.
	</dd>	</dd>
	<dt>Acyclic Dependency:</dt>	<dt>Acyclic Dependency:</dt>
	<dd>	<dd>
	Many dependencies exist in an autonomy model,	Many dependencies exist in an autonomy model,
	particularly when combining individual expressions or	particularly when combining individual expressions or
	results to create complex behaviors. Implementations that	results to create complex behaviors. Implementations that
	conform to the DTNMA need to prevent circular dependencies.	conform to the DTNMA need to prevent circular dependencies.
	</dd>	</dd>
	<dt>Fresh Data:</dt>	<dt>Fresh Data:</dt>
	<dd>	<dd>
	Autonomy models operating on data values	Autonomy models operating on data values
	presume that their data inputs represent the actionable state	presume that their data inputs represent the actionable state
	of the managed device. If a data value has failed to be	of the managed device. If a data value has failed to be
	refreshed within a time period, autonomy might incorrectly	refreshed within a time period, autonomy might incorrectly
	infer an operational state. Regardless of whether a data	infer an operational state. Regardless of whether a data
	value has changed, DTNMA implementations should provide some	value has changed, DTNMA implementations should provide some

	indicator of whether the data value is "fresh" meaning that	indicator of whether the data value is "fresh", i.e., meaning that
	it still represents the current state of the device.	it still represents the current state of the device.
	</dd>	</dd>
	<dt>Pervasive Parameterization:</dt>	<dt>Pervasive Parameterization:</dt>
	<dd>	<dd>
	Where possible, autonomy	Where possible, autonomy
	model objects should support parameterization to allow for	model objects should support parameterization to allow for
	flexibility in the specification. Parameterization allows for	flexibility in the specification. Parameterization allows for
	the definition of fewer unique model objects and also can	the definition of fewer unique model objects and also can
	support the substitution of local device state when	support the substitution of local device state when
	exercising device control or data reporting.	exercising device control or data reporting.
	</dd>	</dd>
	<dt>Configurable Cardinality:</dt>	<dt>Configurable Cardinality:</dt>
	<dd>	<dd>
	The number of data values that can	The number of data values that can
	be supported in a given implementation is finite. For devices	be supported in a given implementation is finite. For devices
	operating in challenged environments, the number of supported	operating in challenged environments, the number of supported

	objects may be far fewer than that which can be supported by	objects may be far fewer than the number of objects that can be su pported by
	devices in well-resourced environments. DTNMA implementations	devices in well-resourced environments. DTNMA implementations
	should define limits to the number of supported objects that	should define limits to the number of supported objects that
	can be active in a system at one time, as a function of the	can be active in a system at one time, as a function of the
	resources available to the implementation.	resources available to the implementation.
	</dd>	</dd>
	<dt>Control-Based Updates:</dt>	<dt>Control-Based Updates:</dt>
	<dd>	<dd>
	The agent autonomy engine changes the	The agent autonomy engine changes the
	state of the managed device by running Controls on the device.	state of the managed device by running Controls on the device.
	This is different from approaches where the behavior of	This is different from approaches where the behavior of
	a managed device is influenced by updating configuration	a managed device is influenced by updating configuration
	values, such as in a table or datastore. Altering behavior via	values, such as in a table or datastore. Altering behavior via

	one or more Controls allows checking all pre-conditions before	one or more Controls allows checking all preconditions before
	making changes as well as providing more granularity in the	making changes as well as providing more granularity in the
	way in which the device is updated. Where necessary, Controls	way in which the device is updated. Where necessary, Controls
	can be defined to perform bulk updates of configuration data	can be defined to perform bulk updates of configuration data
	so as not to lose that update modality. One important	so as not to lose that update modality. One important

	update pre-condition is that the system is not	update precondition is that the system is not
	performing an action that would prevent the update (such as	performing an action that would prevent the update (such as
	currently applying a competing update).	currently applying a competing update).
	</dd>	</dd>
	</dl>	</dl>
	</section>	</section>

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

	and whether values are generated internal or external to the	and whether values are generated in a way that is internal or extern al to the
	autonomy model.	autonomy model.
	</t>	</t>

	<t>	<t>
	A DTNMA data value should combine a base type	A DTNMA data value should combine a base type
	(e.g., integer, real, string) representation with relevant semantic	(e.g., integer, real, string) representation with relevant semantic
	information. Base types are used for proper storage and encoding.	information. Base types are used for proper storage and encoding.
	Semantic information allows for additional typing, constraint defini tions,	Semantic information allows for additional typing, constraint defini tions,
	and mnemonic naming. This expanded	and mnemonic naming. This expanded

	definition of data value allows for better predicate construction	definition of data values allows for better predicate construction,
	and evaluation and early type checking.	better evaluation, and early type checking.
	</t>	</t>

	<t>	<t>
	Data values may further be annotated based on whether their value	Data values may further be annotated based on whether their value
	is the result of a DA calculation or the result of some external	is the result of a DA calculation or the result of some external

	process on the managed device. For example, operators may with to	process on the managed device. For example, operators may wish to
	know which values can be updated by actions on the DA versus which	know which values can be updated by actions on the DA versus which
	values (such as sensor readings) cannot be reliably changed because	values (such as sensor readings) cannot be reliably changed because

	they are calculated external to the DA.	they are calculated in a way that is external to the DA.
	</t>	</t>
	</section>	</section>

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

	later forensic analysis of device behavior, which is a	later forensic analysis of device behavior; this feature is a
	desirable property of DTNMA management.	desirable property of DTNMA management.
	</t>	</t>

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


	<aside>
	<t>	<t>

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

	sending bulk data stores off-platform for analysis.	sending bulk datastores off-platform for analysis.
	</t>	</t>


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

	</section>	</section>


	skipping to change at line 2427 ¶	skipping to change at line 2405 ¶

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

	<t>	<t>
	Controls are conceptually similar to RPCs in	Controls are conceptually similar to RPCs in
	that they represent parameterized functions run on the managed	that they represent parameterized functions run on the managed

	device. However, they are conceptually dissimilar from RPCs in that	device. However, they are conceptually dissimilar to RPCs in that
	they do not have a concept of a return code because they operate	they do not have a concept of a return code because they operate

	over an asynchronous transport. The concept of return code in an RPC	over an asynchronous transport. The concept of a return code in an RPC
	implies a synchronous relationship between the caller of the	implies a synchronous relationship between the caller of the
	procedure and the procedure being called, which might not be	procedure and the procedure being called, which might not be
	possible within the DTNMA.	possible within the DTNMA.
	</t>	</t>

	<t>	<t>
	The success or failure of a Control may be handled locally by the	The success or failure of a Control may be handled locally by the
	agent autonomy engine. Local error handling is particularly important	agent autonomy engine. Local error handling is particularly important

	in this architecture given the potential for long periods of	in this architecture, given the potential for long periods of
	disconnectivity between a DA and a DM. The failure	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.	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>

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

	<t>	<t>
	The failure of certain Controls might leave a managed device in an	The failure of certain Controls might leave a managed device in an

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

	<aside>	<aside>
	<t>	<t>

	NOTE: The use of the term Control in the DTNMA is derived in	NOTE: The use of the term "Control" in the DTNMA is derived in
	part from the concept of Command and Control (C2) where control	part from the concept of Command and Control (C2), where control
	implies the operational instructions undertaken to	implies the operational instructions undertaken to
	implement (or maintain) a commanded objective. The DA	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.	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>

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

	</section>	</section>

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

	<t>	<t>
	As discussed in <xref target="aut_mod_overview"/>, the DTNMA	As discussed in <xref target="aut_mod_overview"/>, the DTNMA
	rule-based stimulus-response system associates stimulus detection with a	rule-based stimulus-response system associates stimulus detection with a

	predetermined response. Rules may be categorized based on whether thei	predetermined response. Rules may be categorized based on whether
	r	(1) their
	stimuli include generic statements of managed device state or whether	stimuli include generic statements of managed device state or
	they	(2) they
	are optimized to only consider the passage of time on the device.	are optimized to only consider the passage of time on the device.
	</t>	</t>

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


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

	control, multiple manager support, and data fusion.	control, support for multiple DMs, and data fusion.
	</t>	</t>

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

	of autonomy model components defined in <xref target="autonomy_model "/>.	of the autonomy model components defined in <xref target="autonomy_m odel"/>.
	</t>	</t>

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

	<tr>	<tr>
	<td align="center">EDD#</td>	<td align="center">EDD#</td>

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

	<tr>	<tr>
	<td align="center">V#</td>	<td align="center">V#</td>

	<td align="center">Variable - a data value defined internal t o the DA.</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>	<td align="center">V1 = EDD1 + 7</td>
	</tr>	</tr>

	<tr>	<tr>
	<td align="center">EXPR</td>	<td align="center">EXPR</td>

	<td align="center">Predicate expression - used to define a ru le stimulus.</td>	<td align="center">Predicate expression -- used to define a r ule stimulus.</td>
	<td align="center">V1 > 5</td>	<td align="center">V1 > 5</td>
	</tr>	</tr>

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

	<tr>	<tr>
	<td align="center">ACL#</td>	<td align="center">ACL#</td>
	<td align="center">Enumerated Access Control List.</td>	<td align="center">Enumerated Access Control List.</td>
	<td align="center">ACL1</td>	<td align="center">ACL1</td>
	</tr>	</tr>
	<tr>	<tr>

	<td align="center">DEF(ACL,ID,EXPR)</td>	<td align="center">DEF(ACL, ID, EXPR)</td>
	<td align="center">Define ID from expression. Allow managers	<td align="center">Define "ID" from expression. Allow DMs in
	in ACL to see this ID.</td>	ACL to see this ID.</td>
	<td align="center">DEF(ACL1, V1, EDD1 + EDD2)</td>	<td align="center">DEF(ACL1, V1, EDD1 + EDD2)</td>
	</tr>	</tr>
	<tr>	<tr>

	<td align="center">PROD(P,ID)</td>	<td align="center">PROD(P, ID)</td>
	<td align="center">Produce ID according to predicate	<td align="center">Produce "ID" according to predicate
	P. P may be a time period (1s) or an expression (EDD1 > 10	P. P may be a time period (1 second, or 1s) or an expression
	).</td>	(EDD1 > 10).</td>
	<td align="center">PROD(1s, EDD1)</td>	<td align="center">PROD(1s, EDD1)</td>
	</tr>	</tr>
	<tr>	<tr>
	<td align="center">RPT(ID)</td>	<td align="center">RPT(ID)</td>

	<td align="center">A report instance containing data named ID .</td>	<td align="center">A report instance containing data named "I D".</td>
	<td align="center">RPT(EDD1)</td>	<td align="center">RPT(EDD1)</td>
	</tr>	</tr>
	</tbody>	</tbody>
	</table>	</table>

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

	<section anchor="serial_mgmt" numbered="true">	<section anchor="serial_mgmt" numbered="true">
	<name>Serialized Management</name>	<name>Serialized Management</name>
	<t>	<t>
	This nominal configuration shows a single DM interacting with mult iple	This nominal configuration shows a single DM interacting with mult iple

	DAs. The control flows for this scenario are outlined in	DAs. The control flow for this scenario is outlined in
	<xref target="serial_mgmt_ctrl_flow"/>.	<xref target="serial_mgmt_ctrl_flow"/>.
	</t>	</t>


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

	<artwork align="center" name="" type="" alt=""><![CDATA[	<name>Serialized Management Control Flow</name>
	+-----------+ +---------+ +---------+	<artwork align="center" name="" type="" alt=""><![CDATA[+----------
		-+ +---------+ +---------+
	\| DTNMA \| \| DTNMA \| \| DTNMA \|	\| DTNMA \| \| DTNMA \| \| DTNMA \|
	\| Manager A \| \| Agent A \| \| Agent B \|	\| Manager A \| \| Agent A \| \| Agent B \|
	+----+------+ +----+----+ +----+----+	+----+------+ +----+----+ +----+----+
	\| \| \|	\| \| \|
	\|-----PROD(1s, EDD1)--->\| \| (1)	\|-----PROD(1s, EDD1)--->\| \| (1)
	\|----------------------------PROD(1s, EDD1)-->\|	\|----------------------------PROD(1s, EDD1)-->\|
	\| \| \|	\| \| \|
	\| \| \|	\| \| \|
	\|<-------RPT(EDD1)------\| \| (2)	\|<-------RPT(EDD1)------\| \| (2)
	\|<----------------------------RPT(EDD1)-------\|	\|<----------------------------RPT(EDD1)-------\|
	\| \| \|	\| \| \|
	\| \| \|	\| \| \|
	\|<-------RPT(EDD1)------\| \|	\|<-------RPT(EDD1)------\| \|
	\|<----------------------------RPT(EDD1)-------\|	\|<----------------------------RPT(EDD1)-------\|
	\| \| \|	\| \| \|
	\| \| \|	\| \| \|
	\|<-------RPT(EDD1)------\| \|	\|<-------RPT(EDD1)------\| \|
	\|<----------------------------RPT(EDD1)-------\|	\|<----------------------------RPT(EDD1)-------\|
	\| \| \|	\| \| \|

	]]></artwork>	]]></artwork>
	</figure>	</figure>
	<t keepWithPrevious="true">	<t keepWithPrevious="true">
	In a serialized management scenario, a single DM interacts with mul tiple DAs.	In a serialized management scenario, a single DM interacts with mul tiple DAs.
	</t>	</t>

	<t>	<t>

	In this figure, the DTNMA Manager A sends a policy to DTNMA Agents	In this figure, DM A sends a policy to DAs
	A and B to report the value of an EDD (EDD1) every second in (step 1	A and B to report the value of an EDD (EDD1) every second (step 1).
	).
	Each DA receives this policy and configures their respective	Each DA receives this policy and configures their respective

	autonomy engines for this production. Thereafter, (step 2) each	autonomy engines for this production. Thereafter (step 2), each
	DA produces a report containing data element EDD1 and sends	DA produces a report containing data element EDD1; each such report
	those reports back to the DM.	is
		then sent back to the DM.
	</t>	</t>
	<t>	<t>
	This behavior continues without any additional communications	This behavior continues without any additional communications
	from the DM.	from the DM.
	</t>	</t>
	</section>	</section>

	<section numbered="true">	<section numbered="true">
	<name>Intermittent Connectivity</name>	<name>Intermittent Connectivity</name>
	<t>	<t>

	Building from the nominal configuration in <xref target="serial_mgmt"/ >,	Building on the nominal configuration discussed in <xref target="seria l_mgmt"/>,
	this scenario shows a challenged network in which connectivity between	this scenario shows a challenged network in which connectivity between

	DTNMA Agent B and the DM is temporarily lost. Control flows for this c	DA B and the DM is temporarily lost. The control flow for this case
	ase	is outlined in <xref target="challenged_serial_mgmt_ctrl_flow"/>.
	are outlined in <xref target="challenged_serial_mgmt_ctrl_flow"/>.
	</t>	</t>


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

	<artwork align="center" name="" type="" alt=""><![CDATA[	<name>Challenged Management Control Flow</name>
	+-----------+ +---------+ +---------+	<artwork align="center" name="" type="" alt=""><![CDATA[+----------
		-+ +---------+ +---------+
	\| DTNMA \| \| DTNMA \| \| DTNMA \|	\| DTNMA \| \| DTNMA \| \| DTNMA \|
	\| Manager A \| \| Agent A \| \| Agent B \|	\| Manager A \| \| Agent A \| \| Agent B \|
	+----+------+ +----+----+ +----+----+	+----+------+ +----+----+ +----+----+
	\| \| \|	\| \| \|
	\|-----PROD(1s, EDD1)--->\| \| (1)	\|-----PROD(1s, EDD1)--->\| \| (1)
	\|----------------------------PROD(1s, EDD1)-->\|	\|----------------------------PROD(1s, EDD1)-->\|
	\| \| \|	\| \| \|
	\| \| \|	\| \| \|
	\|<-------RPT(EDD1)------\| \| (2)	\|<-------RPT(EDD1)------\| \| (2)
	\|<----------------------------RPT(EDD1)-------\|	\|<----------------------------RPT(EDD1)-------\|

	skipping to change at line 2672 ¶	skipping to change at line 2650 ¶
	\| \| RPT(EDD1)\| (3)	\| \| RPT(EDD1)\| (3)
	\| \| \|	\| \| \|
	\| \| \|	\| \| \|
	\|<-------RPT(EDD1)------\| \|	\|<-------RPT(EDD1)------\| \|
	\| \| RPT(EDD1)\| (4)	\| \| RPT(EDD1)\| (4)
	\| \| \|	\| \| \|
	\| \| \|	\| \| \|
	\|<-------RPT(EDD1)------\| \|	\|<-------RPT(EDD1)------\| \|
	\|<----------------RPT(EDD1), RPT(EDD1)--------\| (5)	\|<----------------RPT(EDD1), RPT(EDD1)--------\| (5)
	\| \| \|	\| \| \|

	]]></artwork>	]]></artwork>
	</figure>	</figure>
	<t keepWithPrevious="true">	<t keepWithPrevious="true">

	In a challenged network, DAs store reports pending a transmit opport unity.	In a challenged network, DAs store reports, pending a transmit oppor tunity.
	</t>	</t>
	<t>	<t>

	In this figure, DTNMA Manager A sends a policy to DTNMA Agents A	In this figure, DM A sends a policy to DAs A
	and B to produce an EDD (EDD1) every second in (step 1). Each DA	and B to produce an EDD (EDD1) every second (step 1). Each DA
	receives this policy and configures their respective autonomy	receives this policy and configures their respective autonomy
	engines for this production. Produced reports are transmitted when	engines for this production. Produced reports are transmitted when
	there is connectivity between the DA and DM (step 2).	there is connectivity between the DA and DM (step 2).
	</t>	</t>
	<t>	<t>

	At some point, DTNMA Agent B loses the ability to transmit in the	At some point, DA B loses the ability to transmit in the
	network (steps 3 and 4). During this time period, DA B continues	network (steps 3 and 4). During this time period, DA B continues
	to produce reports, but they are queued for transmission. This	to produce reports, but they are queued for transmission. This
	queuing might be done by the DA itself or by a supporting	queuing might be done by the DA itself or by a supporting
	transport such as BP. Eventually (and before the next scheduled	transport such as BP. Eventually (and before the next scheduled

	production of EDD1), DTNMA Agent B is able to transmit in the	production of EDD1), DA B is able to transmit in the
	network again (step 5) and all queued reports are sent at that	network again (step 5), and all queued reports are sent at that
	time. DTNMA Agent A maintains connectivity with the DM during	time. DA A maintains connectivity with the DM during
	steps 3-5, and continues to send reports as they are generated.	steps 3-5 and continues to send reports as they are generated.
	</t>	</t>
	</section>	</section>

	<section numbered="true">	<section numbered="true">
	<name>Open-Loop Reporting</name>	<name>Open-Loop Reporting</name>
	<t>	<t>
	This scenario illustrates the DTNMA open-loop control paradigm, where DAs	This scenario illustrates the DTNMA open-loop control paradigm, where DAs

	manage themselves in accordance with policies provided by DMs, and pro vide	manage themselves in accordance with policies provided by DMs and prov ide
	reports to DMs based on these policies.	reports to DMs based on these policies.
	</t>	</t>
	<t>	<t>

	The control flow shown in <xref target="consolidated_mgmt_ctrl_flow"/> ,	The control flow shown in <xref target="consolidated_mgmt_ctrl_flow"/>
	includes an example of data fusion, where multiple policies configured by a	includes an example of data fusion, where multiple policies configured by a
	DM result in a single report from a DA.	DM result in a single report from a DA.
	</t>	</t>


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

	<artwork align="center" name="" type="" alt=""><![CDATA[	<name>Consolidated Management Control Flow</name>
	+-----------+ +---------+ +---------+	<artwork align="center" name="" type="" alt=""><![CDATA[+-----------+
		+---------+ +---------+
	\| DTNMA \| \| DTNMA \| \| DTNMA \|	\| DTNMA \| \| DTNMA \| \| DTNMA \|
	\| Manager A \| \| Agent A \| \| Agent B \|	\| Manager A \| \| Agent A \| \| Agent B \|
	+----+------+ +----+----+ +----+----+	+----+------+ +----+----+ +----+----+
	\| \| \|	\| \| \|
	\|-----PROD(1s, EDD1)--->\| \| (1)	\|-----PROD(1s, EDD1)--->\| \| (1)
	\|----------------------------PROD(1s, EDD1)-->\|	\|----------------------------PROD(1s, EDD1)-->\|
	\| \| \|	\| \| \|
	\| \| \|	\| \| \|
	\|<-------RPT(EDD1)------\| \| (2)	\|<-------RPT(EDD1)------\| \| (2)
	\|<----------------------------RPT(EDD1)-------\|	\|<----------------------------RPT(EDD1)-------\|
	\| \| \|	\| \| \|
	\| \| \|	\| \| \|
	\|----------------------------PROD(1s, EDD2)-->\| (3)	\|----------------------------PROD(1s, EDD2)-->\| (3)
	\| \| \|	\| \| \|
	\| \| \|	\| \| \|
	\|<-------RPT(EDD1)------\| \|	\|<-------RPT(EDD1)------\| \|

	\|<--------------------------RPT(EDD1,EDD2)----\| (4)	\|<-------------------------RPT(EDD1, EDD2)----\| (4)
	\| \| \|	\| \| \|
	\| \| \|	\| \| \|
	\|<-------RPT(EDD1)------\| \|	\|<-------RPT(EDD1)------\| \|

	\|<--------------------------RPT(EDD1,EDD2)----\|	\|<-------------------------RPT(EDD1, EDD2)----\|
	\| \| \|	\| \| \|

	]]></artwork>	]]></artwork>
	</figure>	</figure>
	<t keepWithPrevious="true">	<t keepWithPrevious="true">
	A many-to-one mapping between management policy and device state repor ting	A many-to-one mapping between management policy and device state repor ting
	is supported by the DTNMA.	is supported by the DTNMA.
	</t>	</t>
	<t>	<t>

	In this figure, DTNMA Manager A sends a policy statement in the form o	In this figure, DM A sends a policy statement in the form of a
	f a	rule to DAs A and B, which instructs the DAs to produce a report
	rule to DTNMA Agents A and B, which instructs the DAs to produce a rep	for EDD1 every second (step 1). Each DA receives this policy, which is
	ort	stored in its respective rule database, and configures its autonomy en
	with EDD1 every second (step 1). Each DA receives this policy, which i	gine.
	s
	stored in its respective Rule Database, and configures its Autonomy En
	gine.
	Reports are transmitted by each DA when produced (step 2).	Reports are transmitted by each DA when produced (step 2).
	</t>	</t>
	<t>	<t>

	At a later time, DTNMA Manager A sends an additional policy to	At a later time, DM A sends an additional policy to
	DTNMA Agent B, requesting the production of a report for EDD2 every se	DA B, requesting the production of a report for EDD2 every second
	cond	(step 3). This policy is added to DA B's rule database.
	(step 3). This policy is added to DTNMA Agent B's Rule Database.
	</t>	</t>
	<t>	<t>

	Following this policy update, DTNMA Agent A will continue to produce E	Following this policy update, DA A will continue to produce EDD1,
	DD1	and DA B will produce both EDD1 and EDD2 (step 4). However,
	and DTNMA Agent B will produce both EDD1 and EDD2 (step 4). However, D	DA B may provide these values to the DM in a single report rather than
	TNMA	as
	Agent B may provide these values to the DM in a single report rather t	two independent reports. In this way, there is no direct mapping betwe
	han as	en the
	2 independent reports. In this way, there is no direct mapping between	consolidated reports sent by DA B (from step 4 onwards) and the two
	the	different policies sent to DA B (steps 1 and 3) that produce the infor
	single consolidated report sent by DTNMA Agent B (step 4) and the two	mation included in those consolidated reports.
	different policies sent to DTNMA Agent B that caused that report to be
	generated (steps 1 and 3).
	</t>	</t>
	</section>	</section>

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

	<aside>
	<t>	<t>

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

	</aside>

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

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


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

		<name>Multiplexed Management Control Flow</name>
	<artwork align="center" name="" type="" alt=""><![CDATA[	<artwork align="center" name="" type="" alt=""><![CDATA[
	+-----------+ +---------+ +-----------+	+-----------+ +---------+ +-----------+
	\| DTNMA \| \| DTNMA \| \| DTNMA \|	\| DTNMA \| \| DTNMA \| \| DTNMA \|
	\| Manager A \| \| Agent A \| \| Manager B \|	\| Manager A \| \| Agent A \| \| Manager B \|
	+-----+-----+ +----+----+ +-----+-----+	+-----+-----+ +----+----+ +-----+-----+

	\| \| \|	\| \| \|
	\|---DEF(ACL1,V1,EDD12)--->\|<---DEF(ACL2, V2, EDD22)---\| (1)	\|--DEF(ACL1, V1, EDD12)-->\|<---DEF(ACL2, V2, EDD22)---\| (1)
	\| \| \|	\| \| \|
	\|---PROD(1s, V1)---------->\|<---PROD(1s, V2)------------\| (2)	\|---PROD(1s, V1)---------->\|<---PROD(1s, V2)------------\| (2)
	\| \| \|	\| \| \|
	\|<--------RPT(V1)----------\| \| (3)	\|<--------RPT(V1)----------\| \| (3)
	\| \|--------RPT(V2)------------>\|	\| \|--------RPT(V2)------------>\|
	\|<--------RPT(V1)----------\| \|	\|<--------RPT(V1)----------\| \|
	\| \|--------RPT(V2)------------>\|	\| \|--------RPT(V2)------------>\|
	\| \| \|	\| \| \|
	\| \|<---PROD(1s, V1)------------\| (4)	\| \|<---PROD(1s, V1)------------\| (4)
	\| \| \|	\| \| \|
	\| \|----ERR(V1 no perm.)------->\|	\| \|---ERR(V1 not permitted)--->\|
	\| \| \|	\| \| \|
	\|--DEF(NULL,V3,EDD3*3)---->\| \| (5)	\|--DEF(NULL, V3, EDD3*3)-->\| \| (5)
	\| \| \|	\| \| \|
	\|---PROD(1s, V3)---------->\| \| (6)	\|---PROD(1s, V3)---------->\| \| (6)
	\| \| \|	\| \| \|
	\| \|<----PROD(1s, V3)-----------\|	\| \|<----PROD(1s, V3)-----------\|
	\| \| \|	\| \| \|
	\|<--------RPT(V3)----------\|--------RPT(V3)------------>\| (7)	\|<--------RPT(V3)----------\|--------RPT(V3)------------>\| (7)
	\|<--------RPT(V1)----------\| \|	\|<--------RPT(V1)----------\| \|
	\| \|--------RPT(V2)------------>\|	\| \|--------RPT(V2)------------>\|
	\|<-------RPT(V3)-----------\|--------RPT(V3)------------>\|	\|<-------RPT(V3)-----------\|--------RPT(V3)------------>\|
	\|<-------RPT(V1)-----------\| \|	\|<-------RPT(V1)-----------\| \|
	\| \|--------RPT(V2)------------>\|	\| \|--------RPT(V2)------------>\|
	]]></artwork>	]]></artwork>
	</figure>	</figure>


	<t keepWithPrevious="true">	<t keepWithPrevious="true">
	Multiple DMs may interface with a single DA, particularly in comple x	Multiple DMs may interface with a single DA, particularly in comple x
	networks.	networks.
	</t>	</t>
	<t>	<t>

	In this figure, both DTNMA Managers A and B send policies to DTNMA	In this figure, both DM A and DM B send policies to
	Agent A (step 1). DM A defines a variable (V1) whose value is given	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	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	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	defines a variable (V2) whose value is given by the mathematical

	expression (EDD2 * 2) and associated with an ACL (ACL2) that restric ts	expression (EDD2 * 2) and is associated with an ACL (ACL2) that rest ricts
	access to V2 to DM B only.	access to V2 to DM B only.
	</t>	</t>
	<t>	<t>

	Both DTNMA Managers A and B also send policies to DTNMA Agent A to	Both DM A and DM B also send policies to DA A to
	report on the values of their variables at 1 second intervals (step	report on the values of their variables at 1-second intervals (step
	2).	2).
	Since DM A can access V1 and DM B can access V2, there is	Since DM A can access V1 and DM B can access V2, there is

	no authorization issue with these policies and they are both	no authorization issue with these policies, and they are both
	accepted by the autonomy engine on Agent A. Agent A produces	accepted by the autonomy engine on DA A. DA A produces
	reports as expected, sending them to their respective managers	reports as expected, sending them to their respective managers
	(step 3).	(step 3).
	</t>	</t>
	<t>	<t>

	Later (step 4) DM B attempts to configure DA A to also	Later (step 4), DM B attempts to configure DA A to also
	report to it the value of V1. Since DM B does not have	report to it the value of V1. Since DM B does not have
	authorization to view this variable, DA A does not include this	authorization to view this variable, DA A does not include this

	in the configuration of its autonomy engine and, instead, some	in the configuration of its autonomy engine; instead, some
	indication of permission error is included in any regular	indication of a permission error is included in any regular
	reporting back to DM B.	reporting back to DM B.
	</t>	</t>
	<t>	<t>

	DM A also sends a policy to Agent A (step 5) that defines a	DM A also sends a policy to DA A (step 5) that defines a
	variable (V3) whose value is given by the mathematical expression	variable (V3) whose value is given by the mathematical expression
	(EDD3 * 3) and is not associated with an ACL, indicating that any	(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	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).	then send policies to DA A to report the value of V3 (step 6).
	Since there is no authorization restriction on V3, these policies	Since there is no authorization restriction on V3, these policies

	are accepted by the autonomy engine on Agent A and reports are	are accepted by the autonomy engine on DA A, and reports are
	sent to both DM A and B over time (step 7).	sent to both DM A and DM B over time (step 7).
	</t>	</t>
	</section>	</section>

	<section numbered="true">	<section numbered="true">
	<name>Cascading Management</name>	<name>Cascading Management</name>
	<t>	<t>

	There are times where a single network device may serve as both	There are times when a single network device may serve as both
	a DM for other DAs in the network and, itself, as a	a DM for other DAs in the network and, itself, as a
	device managed by someone else. This may be the case on nodes	device managed by someone else. This may be the case on nodes
	serving as gateways or proxies. The DTNMA accommodates this case by	serving as gateways or proxies. The DTNMA accommodates this case by

	allowing a single device to run both a DA and DM.	allowing a single device to run both a DA and a DM.
	</t>	</t>
	<t>	<t>
	An example of this configuration is illustrated in	An example of this configuration is illustrated in
	<xref target="fusion_ctrl_flow"/>.	<xref target="fusion_ctrl_flow"/>.
	</t>	</t>


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

		<name>Cascading Management Control Flow</name>
	<artwork align="center" name="" type="" alt=""><![CDATA[	<artwork align="center" name="" type="" alt=""><![CDATA[
	---------------------------------------	---------------------------------------
	\| Node B \|	\| Node B \|
	\| \|	\| \|
	+-----------+ \| +-----------+ +---------+ \| +---------+	+-----------+ \| +-----------+ +---------+ \| +---------+
	\| DTNMA \| \| \| DTNMA \| \| DTNMA \| \| \| DTNMA \|	\| DTNMA \| \| \| DTNMA \| \| DTNMA \| \| \| DTNMA \|
	\| Manager A \| \| \| Manager B \| \| Agent B \| \| \| Agent C \|	\| Manager A \| \| \| Manager B \| \| Agent B \| \| \| Agent C \|
	+---+-------+ \| +-----+-----+ +----+----+ \| +----+----+	+---+-------+ \| +-----+-----+ +----+----+ \| +----+----+
	\| \| \| \| \| \|	\| \| \| \| \| \|

	\|--------------DEF(NULL,V0,EDD1+EDD2)-->\| \| \| (1)	\|----------DEF(NULL, V0, EDD1 + EDD2)-->\| \| \| (1)
	\|--------------PROD(1s,V0)------------->\| \| \|	\|-------------PROD(1s, V0)------------->\| \| \|
	\| \| \| \| \| \|	\| \| \| \| \| \|

	\| \| \|--PROD(1s,EDD1)-->\| \| \| (2)	\| \| \|-PROD(1s, EDD1)-->\| \| \| (2)
	\| \| \|---------------------PROD(1s,EDD2)-->\| (2)	\| \| \|--------------------PROD(1s, EDD2)-->\| (2)
	\| \| \| \| \| \|	\| \| \| \| \| \|
	\| \| \| \| \| \|	\| \| \| \| \| \|
	\| \| \|<----RPT(EDD1)----\| \| \| (3)	\| \| \|<----RPT(EDD1)----\| \| \| (3)
	\| \| \|<--------------------RPT(EDD2)-------\| (3)	\| \| \|<--------------------RPT(EDD2)-------\| (3)
	\| \| \| \| \| \|	\| \| \| \| \| \|
	\|<-------------RPT(V0)------------------\| \| \| (4)	\|<-------------RPT(V0)------------------\| \| \| (4)
	\| \| \| \| \| \|	\| \| \| \| \| \|
	\| \| \| \| \| \|	\| \| \| \| \| \|
	\| \|	\| \|
	\| \|	\| \|
	---------------------------------------	---------------------------------------

	]]></artwork>	]]></artwork>
	</figure>	</figure>


	<t keepWithPrevious="true">	<t keepWithPrevious="true">

	A device can operate as both a DTNMA Manager and an Agent.	A device can operate as both a DM and a DA.
	</t>	</t>
	<t>	<t>
	In this example, we presume that DA B is able to sample a	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	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	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	(which is controlled by DM A). DM A must periodically receive
	some new value that is calculated as a function of both EDD1	some new value that is calculated as a function of both EDD1
	and EDD2.	and EDD2.
	</t>	</t>

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

	<t>	<t>

	DA B needs the ability to monitor both EDD1 and EDD2.	DA B needs the ability to monitor both EDD1 and 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	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	reported back to Node B by DA C and included in the Node B

	runtime data stores. Therefore, DM B sends a policy to DA C to	runtime datastores. Therefore, DM B also sends a policy to DA C to
	report on the value of EDD2 (step 2).	report on the value of EDD2 (step 2).
	</t>	</t>
	<t>	<t>

	DA C receives the policy in its autonomy engine and produces	DA B receives the policy in its autonomy engine and produces
	reports on the value of EDD2 every second (step 3).	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>
	<t>	<t>
	DA B may locally sample EDD1 and EDD2 and uses that to compute	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	values of V0 and report on those values at regular intervals to DM A
	(step 4).	(step 4).
	</t>	</t>
	<t>	<t>
	While a trivial example, the mechanism of associating fusion with	While a trivial example, the mechanism of associating fusion with

	the Agent function rather than the Manager function scales with	the DA function rather than the DM function scales with
	fusion complexity. Within the DTNMA, DAs and DMs are not required to	fusion complexity. Within the DTNMA, DAs and DMs are not required to
	be separate software implementations. There may be a single software	be separate software implementations. There may be a single software
	application running on Node B implementing both DM B and DA B roles.	application running on Node B implementing both DM B and DA B roles.
	</t>	</t>
	</section>	</section>
	</section>	</section>

	<section anchor="IANA" numbered="true">	<section anchor="IANA" numbered="true">
	<name>IANA Considerations</name>	<name>IANA Considerations</name>
	<t>	<t>

	This document requires no IANA actions.	This document has no IANA actions.
	</t>	</t>
	</section>	</section>

	<section anchor="Security" numbered="true">	<section anchor="Security" numbered="true">
	<name>Security Considerations</name>	<name>Security Considerations</name>
	<t>	<t>

	Security within a DTNMA exists in at least two layers: security	Security within a DTNMA exists in at least the following two layers: sec urity
	in the data model and security in the messaging and encoding of the	in the data model and security in the messaging and encoding of the
	data model.	data model.
	</t>	</t>

	<t>	<t>
	Data model security refers to the validity and accessibility of data	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 o r DMs. Both verification and authorization mechanisms	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 o r DMs. Both verification and authorization mechanisms
	at DAs and DMs are important to achieve this type of security.	at DAs and DMs are important to achieve this type of security.
	</t>	</t>

	<aside>	<aside>
	<t>	<t>
	NOTE: One way to provide finer-grained application security is	NOTE: One way to provide finer-grained application security is

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

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


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

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

	</references> -->

	<references>	<references>
	<name>Informative References</name>	<name>Informative References</name>

	<xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.	<xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.257
	2578.xml'/>	8.xml'/>
	<xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.	<xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.316
	3165.xml'/>	5.xml'/>
	<xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.	<xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.298
	2982.xml'/>	2.xml'/>
	<xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.	<xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.341
	3410.xml'/>	0.xml'/>
	<xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.	<xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.341
	3411.xml'/>	1.xml'/>
	<xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.	<xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.341
	3414.xml'/>	4.xml'/>
	<xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.	<xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.341
	3416.xml'/>	6.xml'/>
	<xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.	<xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.341
	3417.xml'/>	7.xml'/>
	<xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.	<xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.341
	3418.xml'/>	8.xml'/>
	<xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.	<xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.483
	4838.xml'/>	8.xml'/>
	<xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.	<xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.494
	4949.xml'/>	9.xml'/>
	<xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.	<xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.635
	6353.xml'/>	3.xml'/>
	<xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.	<xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.559
	5591.xml'/>	1.xml'/>
	<xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.	<xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.559
	5592.xml'/>	2.xml'/>
	<xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.	<xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.565
	5652.xml'/>	2.xml'/>
	<xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.	<xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.624
	6241.xml'/>	1.xml'/>
	<xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.	<xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.624
	6242.xml'/>	2.xml'/>
	<xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.	<xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.699
	6991.xml'/>	1.xml'/>
	<xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.	<xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.722
	7228.xml'/>	8.xml'/>
	<xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.	<xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.725
	7252.xml'/>	2.xml'/>
	<xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.	<xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.911
	9113.xml'/>	3.xml'/>
	<xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.	<xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.757
	7575.xml'/>	5.xml'/>
	<xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.	<xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.758
	7589.xml'/>	9.xml'/>
	<xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.	<xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.795
	7950.xml'/>	0.xml'/>
	<xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.	<xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.795
	7951.xml'/>	1.xml'/>
	<xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.	<xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.804
	8040.xml'/>	0.xml'/>
	<xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.	<xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.819
	8199.xml'/>	9.xml'/>
	<xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.	<xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.829
	8294.xml'/>	4.xml'/>
	<xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.	<xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.834
	8341.xml'/>	1.xml'/>
	<xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.	<xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.836
	8368.xml'/>	8.xml'/>
	<xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.	<xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.834
	8342.xml'/>	2.xml'/>
	<xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.	<xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.863
	8639.xml'/>	9.xml'/>
	<xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.	<xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.864
	8641.xml'/>	1.xml'/>
	<xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.	<xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.899
	8990.xml'/>	0.xml'/>
	<xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.	<xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.899
	8993.xml'/>	3.xml'/>
	<xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.	<xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.917
	9171.xml'/>	1.xml'/>
	<xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.	<xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.917
	9172.xml'/>	2.xml'/>
	<xi:include href='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.	<xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.925
	9254.xml'/>	4.xml'/>
	<xi:include href='http://xml2rfc.tools.ietf.org/public/rfc/bibxml-ids/refe
	rence.I-D.rfernando-protocol-buffers.xml'/>	<!-- draft-rfernando-protocol-buffers (Expired)
	<xi:include href='http://xml2rfc.tools.ietf.org/public/rfc/bibxml-ids/refe	"Long way" to fix date -->
	rence.I-D.ietf-core-sid.xml'/>	<reference anchor="PROTOCOL-BUFFERS">
	<xi:include href='http://xml2rfc.tools.ietf.org/public/rfc/bibxml-ids/refe	<front>
	rence.I-D.ietf-core-comi.xml'/>	<title>Encoding rules and MIME type for Protocol Buffers</title>
	<reference anchor="ASN.1">	<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='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.959
		5.xml'/>

		<!-- draft-ietf-core-comi (I-D Exists)
		"Long way" to fix one surname and add four "editor" entries -->
		<reference anchor="CORE-COMI">
		<front>
		<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="edi
		tor">
		<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="e
		ditor">
		<organization>Universität Bremen TZI</organization>
		</author>
		<date month="November" day="3" year="2024" />
		</front>
		<seriesInfo name="Internet-Draft" value="draft-ietf-core-comi-19" />
		</reference>

		<reference anchor="ASN.1" target="https://www.itu.int/rec/T-REC-X.680">
	<front>	<front>

	<title>	<title>Information technology - Abstract Syntax Notation One (ASN.1):
	Information processing systems - Open Systems Interconnection -	Specification of basic notation</title>
	Specification of Abstract Syntax Notation One (ASN.1)
	</title>
	<seriesInfo name="International Standard" value="8824"/>
	<author>	<author>

	<organization>International Organization for Standardization</organi zation>	<organization>ITU-T</organization>
	</author>	</author>

	<date month="December" year="1987"/>	<date month="February" year="2021"/>
	</front>	</front>

		<seriesInfo name="ITU-T Recommendation" value="X.680"/>
		<seriesInfo name="ISO/IEC" value="8824-1:2021"/>
	</reference>	</reference>


	<reference anchor="DART" target="https://ieeexplore.ieee.org/abstract/docu ment/10207457">	<reference anchor="DART" target="https://ieeexplore.ieee.org/abstract/docu ment/10207457">
	<front>	<front>

	<title>	<title>The DART Autonomy System</title>
	The DART Autonomy System
	</title>
	<author fullname="B. Teresa Tropf">	<author fullname="B. Teresa Tropf">
	<organization>The Johns Hopkins Applied Physics Laboratory</organiza tion>	<organization>The Johns Hopkins Applied Physics Laboratory</organiza tion>
	</author>	</author>
	<author fullname="Musad Haque">	<author fullname="Musad Haque">
	<organization>The Johns Hopkins Applied Physics Laboratory</organiza tion>	<organization>The Johns Hopkins Applied Physics Laboratory</organiza tion>
	</author>	</author>
	<author fullname="Neda Behrooz">	<author fullname="Neda Behrooz">
	<organization>The Johns Hopkins Applied Physics Laboratory</organiza tion>	<organization>The Johns Hopkins Applied Physics Laboratory</organiza tion>
	</author>	</author>
	<author fullname="Christopher Krupiarz">	<author fullname="Christopher Krupiarz">
	<organization>The Johns Hopkins Applied Physics Laboratory</organiza tion>	<organization>The Johns Hopkins Applied Physics Laboratory</organiza tion>
	</author>	</author>

	<date year="2023"/>	<date month="August" year="2023"/>
	</front>	</front>

		<seriesInfo name="DOI" value="10.1109/SMC-IT56444.2023.00020"/>
	</reference>	</reference>


	<reference anchor="NEW-HORIZONS" target="https://www.sciencedirect.com/sci ence/article/pii/S0094576507000604">	<reference anchor="NEW-HORIZONS" target="https://www.sciencedirect.com/sci ence/article/pii/S0094576507000604">
	<front>	<front>
	<title>	<title>
	Autonomous safeing and fault protection for the New Horizons mission to Pluto	Autonomous safeing and fault protection for the New Horizons mission to Pluto
	</title>	</title>
	<author fullname="Robert C. Moore">	<author fullname="Robert C. Moore">
	<organization>The Johns Hopkins Applied Physics Laboratory</organiza tion>	<organization>The Johns Hopkins Applied Physics Laboratory</organiza tion>
	<address>	<address>
	<email>Robert.Moore@jhuapl.edu</email>	<email>Robert.Moore@jhuapl.edu</email>
	</address>	</address>
	</author>	</author>

	<date month="March" year="2007"/>	<date month="August" year="2007"/>
	</front>	</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>


	<reference anchor="gNMI" target="https://www.openconfig.net/docs/gnmi/gnmi -specification/">	<reference anchor="gNMI" target="https://www.openconfig.net/docs/gnmi/gnmi -specification/">
	<front>	<front>

	<title>	<title>gRPC Network Management Interface (gNMI)</title>
	gRPC Network Management Interface (gNMI)	<author initials="P." surname="Borman" fullname="Paul Borman">
	</title>	<organization/>
	<author>	</author>
	<organization>OpenConfig</organization>	<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>	</author>
	<date month="May" year="2023"/>	<date month="May" year="2023"/>
	</front>	</front>

		<refcontent>Version 10.0</refcontent>
	</reference>	</reference>


	<reference anchor="gRPC" target="https://grpc.io/docs/">	<reference anchor="gRPC" target="https://grpc.io/docs/">
	<front>	<front>

	<title>	<title>gRPC Documentation</title>
	gRPC Documentation
	</title>
	<author>	<author>
	<organization>gRPC Authors</organization>	<organization>gRPC Authors</organization>
	</author>	</author>
	<date year="2024"/>	<date year="2024"/>
	</front>	</front>
	</reference>	</reference>


	<reference anchor="IPMI" target="https://www.intel.la/content/dam/www/publ ic/us/en/documents/specification-updates/ipmi-intelligent-platform-mgt-interface -spec-2nd-gen-v2-0-spec-update.pdf">	<reference anchor="IPMI" target="https://www.intel.la/content/dam/www/publ ic/us/en/documents/specification-updates/ipmi-intelligent-platform-mgt-interface -spec-2nd-gen-v2-0-spec-update.pdf">
	<front>	<front>

	<title>	<title>Intelligent Platform Management Interface Specification, Second
	Intelligent Platform Management Interface Specification, Second Generation	Generation</title>
	</title>
	<author>	<author>
	<organization>Intel</organization>	<organization>Intel</organization>
	</author>	</author>
	<author>	<author>
	<organization>Hewlett-Packard</organization>	<organization>Hewlett-Packard</organization>
	</author>	</author>
	<author>	<author>
	<organization>NEC</organization>	<organization>NEC</organization>
	</author>	</author>
	<author>	<author>
	<organization>Dell</organization>	<organization>Dell</organization>
	</author>	</author>
	<date month="October" year="2013"/>	<date month="October" year="2013"/>
	</front>	</front>

		<refcontent>Version 2.0</refcontent>
	</reference>	</reference>

	<reference anchor="XPath" target="http://www.w3.org/TR/1999/REC-xpath-1999
	1116">	<reference anchor="XPath" target="https://www.w3.org/TR/2017/REC-xpath-31-
		20170321/">
	<front>	<front>

	<title>	<title>XML Path Language (XPath) 3.1 </title>
	XML Path Language (XPath) Version 1.0	<author initials="J." surname="Robie" fullname="Jonathan Robie" role
	</title>	="editor">
	<author>	<organization/>
	<organization>World Wide Web Consortium</organization>	</author>
	</author>	<author initials="M." surname="Dyck" fullname="Michael Dyck" role="e
	<date month="November" year="1999"/>	ditor">
		<organization/>
		</author>
		<author initials="J." surname="Spiegel" fullname="Josh Spiegel" role
		="editor">
		<organization/>
		</author>
		<date month="March" year="2017"/>
	</front>	</front>

		<annotation>Latest version available at <eref target="https://www.w3.org/ TR/xpath-31/" brackets="angle"/>.</annotation>
	</reference>	</reference>

	<reference anchor="xml-infoset" target= "https://www.w3.org/TR/2004/REC-xm
	l-infoset-20040204/">	<reference anchor="xml-infoset"
		target="https://www.w3.org/TR/2004/REC-xml-infoset-20040204/">
	<front>	<front>

	<title>	<title>XML Information Set (Second Edition)</title>
	XML Information Set (Second Edition)	<author fullname="John Cowan" initials="J." surname="Cowan" role="edi
	</title>	tor">
	<author>	<organization></organization>
	<organization>World Wide Web Consortium</organization>	</author>
		<author fullname="Richard Tobin" initials="R." surname="Tobin" role="
		editor">
		<organization></organization>
	</author>	</author>
	<date month="February" year="2004"/>	<date month="February" year="2004"/>
	</front>	</front>

		<refcontent>W3C Recommendation REC-xml-infoset-20040204</refcontent>
	</reference>	</reference>

	</references>	</references>

	<section numbered="false">	<section numbered="false">
	<name>Acknowledgements</name>	<name>Acknowledgements</name>
	<t>	<t>

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


	</back>	</back>
	</rfc>	</rfc>

End of changes. 374 change blocks.
	731 lines changed or deleted	803 lines changed or added
This html diff was produced by rfcdiff 1.48.