DTNMA Application Management Model (AMM) and Data Models
draft-birrane-dtn-adm-05
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Edward J. Birrane , David Linko , Brian Sipos | ||
| Last updated | 2023-10-06 (Latest revision 2023-07-10) | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-birrane-dtn-adm-05
Delay-Tolerant Networking E.J. Birrane
Internet-Draft D. Linko
Intended status: Standards Track B. Sipos
Expires: 8 April 2024 JHU/APL
6 October 2023
DTNMA Application Management Model (AMM) and Data Models
draft-birrane-dtn-adm-05
Abstract
This document defines a data model that captures the information
necessary to asynchronously manage applications within the Delay-
Tolerant Networking Management Architecture (DTNMA). This model
provides a set of common type definitions, data structures, and a
template for publishing standardized representations of model
elements.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 8 April 2024.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
Birrane, et al. Expires 8 April 2024 [Page 1]
Internet-Draft DTNMA AMM/ADM October 2023
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Data Modeling Concept of Operations . . . . . . . . . . . . . 6
2.1. Values and Value-Producing Objects . . . . . . . . . . . 8
2.2. Agent Processing . . . . . . . . . . . . . . . . . . . . 9
2.3. Agent-Manager Messaging . . . . . . . . . . . . . . . . . 10
3. Application Management Model (AMM) . . . . . . . . . . . . . 11
3.1. AMM Values . . . . . . . . . . . . . . . . . . . . . . . 11
3.1.1. Literal (LIT) . . . . . . . . . . . . . . . . . . . . 11
3.1.2. Object Reference (OBJ-REF) . . . . . . . . . . . . . 12
3.1.3. The Application Resource Identifier (ARI) . . . . . . 14
3.2. Literal Types . . . . . . . . . . . . . . . . . . . . . . 14
3.2.1. Simple Types . . . . . . . . . . . . . . . . . . . . 15
3.2.2. Collections . . . . . . . . . . . . . . . . . . . . . 17
3.2.3. Custom Literal Types . . . . . . . . . . . . . . . . 17
3.3. Semantic Types . . . . . . . . . . . . . . . . . . . . . 18
3.4. AMM Objects . . . . . . . . . . . . . . . . . . . . . . . 18
3.4.1. Common Object Fields . . . . . . . . . . . . . . . . 18
3.4.2. Semantic Type Definition (TYPEDEF) . . . . . . . . . 20
3.4.3. Externally Defined Data (EDD) . . . . . . . . . . . . 20
3.4.4. Constant (CONST) . . . . . . . . . . . . . . . . . . 21
3.4.5. Control (CTRL) . . . . . . . . . . . . . . . . . . . 22
3.4.6. Operator (OPER) . . . . . . . . . . . . . . . . . . . 22
3.4.7. State-Based Rule (SBR) . . . . . . . . . . . . . . . 23
3.4.8. Time-Based Rule (TBR) . . . . . . . . . . . . . . . . 25
3.4.9. Variable (VAR) . . . . . . . . . . . . . . . . . . . 26
4. Application Data Models (ADMs) . . . . . . . . . . . . . . . 27
4.1. ADM Definitions . . . . . . . . . . . . . . . . . . . . . 27
4.1.1. ADM Metadata . . . . . . . . . . . . . . . . . . . . 27
4.1.2. Features and Conformance . . . . . . . . . . . . . . 28
4.2. Contents of an DTNMA ADM . . . . . . . . . . . . . . . . 28
4.2.1. Simple Semantic Types . . . . . . . . . . . . . . . . 29
4.2.2. Type Unions . . . . . . . . . . . . . . . . . . . . . 29
4.2.3. Expression (EXPR) . . . . . . . . . . . . . . . . . . 30
4.2.4. Macro (MAC) . . . . . . . . . . . . . . . . . . . . . 30
4.2.5. Report Template (RPTT) . . . . . . . . . . . . . . . 31
Birrane, et al. Expires 8 April 2024 [Page 2]
Internet-Draft DTNMA AMM/ADM October 2023
4.2.6. Report (RPT) . . . . . . . . . . . . . . . . . . . . 31
4.2.7. Tabular Report (TBL) . . . . . . . . . . . . . . . . 32
4.3. Contents of an Agent ADM . . . . . . . . . . . . . . . . 33
4.3.1. Agent State Introspection . . . . . . . . . . . . . . 33
4.3.2. Basic Operators . . . . . . . . . . . . . . . . . . . 33
5. Operational Data Models (ODMs) . . . . . . . . . . . . . . . 33
6. Processing Activities . . . . . . . . . . . . . . . . . . . . 34
6.1. Agent Initialization . . . . . . . . . . . . . . . . . . 34
6.2. ARI Resolving . . . . . . . . . . . . . . . . . . . . . . 35
6.3. Dereferencing . . . . . . . . . . . . . . . . . . . . . . 35
6.4. Parameter Handling . . . . . . . . . . . . . . . . . . . 36
6.5. Value Production . . . . . . . . . . . . . . . . . . . . 36
6.5.1. CONST and VAR References . . . . . . . . . . . . . . 37
6.5.2. EDD References . . . . . . . . . . . . . . . . . . . 37
6.6. Execution . . . . . . . . . . . . . . . . . . . . . . . . 38
6.6.1. Value-Producing Object References . . . . . . . . . . 38
6.6.2. CTRL References . . . . . . . . . . . . . . . . . . . 39
6.6.3. MAC Values . . . . . . . . . . . . . . . . . . . . . 39
6.7. Evaluation . . . . . . . . . . . . . . . . . . . . . . . 40
6.7.1. Value-Producing Object References . . . . . . . . . . 40
6.7.2. OPER References . . . . . . . . . . . . . . . . . . . 41
6.7.3. TYPEDEF References . . . . . . . . . . . . . . . . . 41
6.7.4. EXPR Values . . . . . . . . . . . . . . . . . . . . . 42
6.8. Reporting . . . . . . . . . . . . . . . . . . . . . . . . 43
6.8.1. Value-Producing Object References . . . . . . . . . . 43
6.8.2. RPTT Values . . . . . . . . . . . . . . . . . . . . . 43
6.9. Type Casting . . . . . . . . . . . . . . . . . . . . . . 44
6.9.1. BOOL Type . . . . . . . . . . . . . . . . . . . . . . 44
6.9.2. NUMERIC Types . . . . . . . . . . . . . . . . . . . . 44
6.9.3. Semantic Types . . . . . . . . . . . . . . . . . . . 46
6.10. Translating ARIs and Semantic Types . . . . . . . . . . . 47
7. ADM Module Syntax . . . . . . . . . . . . . . . . . . . . . . 48
7.1. Inherited YANG Module Processing . . . . . . . . . . . . 49
7.1.1. Direct Reuse . . . . . . . . . . . . . . . . . . . . 49
7.1.2. Restrictions and Exclusions . . . . . . . . . . . . . 50
7.2. AMM Types, Typedefs, and Type Uses . . . . . . . . . . . 52
7.2.1. Built-In AMM Types . . . . . . . . . . . . . . . . . 52
7.2.2. Type Uses . . . . . . . . . . . . . . . . . . . . . . 52
7.2.3. Type Definitions . . . . . . . . . . . . . . . . . . 53
7.3. ADM Module Extensions . . . . . . . . . . . . . . . . . . 53
7.3.1. The amm:enum Statement . . . . . . . . . . . . . . . 53
7.3.2. Type Use Statements . . . . . . . . . . . . . . . . . 54
7.3.3. The amm:parameter Statement . . . . . . . . . . . . . 58
7.3.4. The amm:typedef Statement . . . . . . . . . . . . . . 60
7.3.5. The amm:const Statement . . . . . . . . . . . . . . . 62
7.3.6. The amm:ctrl Statement . . . . . . . . . . . . . . . 64
7.3.7. The amm:edd Statement . . . . . . . . . . . . . . . . 66
7.3.8. The amm:oper Statement . . . . . . . . . . . . . . . 67
Birrane, et al. Expires 8 April 2024 [Page 3]
Internet-Draft DTNMA AMM/ADM October 2023
7.3.9. The amm:sbr Statement . . . . . . . . . . . . . . . . 69
7.3.10. The amm:tbr Statement . . . . . . . . . . . . . . . . 71
7.3.11. The amm:var Statement . . . . . . . . . . . . . . . . 72
7.4. ADM Module Contents . . . . . . . . . . . . . . . . . . . 74
8. ADM Author Considerations . . . . . . . . . . . . . . . . . . 75
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 76
9.1. DTN Management Architecture Parameters . . . . . . . . . 76
10. Security Considerations . . . . . . . . . . . . . . . . . . . 77
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 77
11.1. Normative References . . . . . . . . . . . . . . . . . . 77
11.2. Informative References . . . . . . . . . . . . . . . . . 78
Appendix A. ADM Module for AMM Definitions . . . . . . . . . . . 79
Appendix B. ADM Module for DTNMA Agents . . . . . . . . . . . . 89
Appendix C. Examples . . . . . . . . . . . . . . . . . . . . . . 96
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 97
1. Introduction
The Delay-Tolerant Networking Management Architecture (DTNMA)
[I-D.ietf-dtn-dtnma] defines a concept for the open-loop control of
applications (and protocols) in situations where timely, highly-
available connections cannot exist among managing and managed nodes
in a network. While the DTNMA provides a conceptual information
model, it does not include details necessary to produce interoperable
data models.
1.1. Scope
This document defines a two-level data model suitable for managing
applications in accordance with the DTNMA. The two levels of model
are:
1. A meta-model for the DTNMA, called the Application Management
Model (AMM), which defines the object structures and literal-
value types used in the DTNMA in a concrete way.
2. An object model, based on the AMM meta-model, which is used in
static Application Data Models (ADMs) and dynamic Operational
Data Models (ODMs) as instances of the AMM within an Agent.
This document also defines a text representation of an ADM using the
types and structures defined by the AMM combined with the syntax and
processing semantics of YANG modules [RFC7950], while using AMM-
specific extensions for object and data modeling. With this
representation, individual applications can capture their static
management information in module files.
Birrane, et al. Expires 8 April 2024 [Page 4]
Internet-Draft DTNMA AMM/ADM October 2023
Although this document defines a representation for the ADM, it does
not define a representation for the objects and literal values
modeled by the ADM/ODM. In order to communicate values between DTNMA
Agents and Managers in a network, the model must be encoded for
transmission. Any such encoding scheme is outside of the scope of
this document. Generally, the encoding of the model is a separate
concern from the specification of data within the model.
Because different networks may use different encodings for data,
mandating an encoding format would require incompatible networks to
encapsulate data in ways that could introduce inefficiency and
obfuscation. It is envisioned that different networks would be able
to encode values in their native encodings such that the translation
of ADM data from one encoding to another can be completed using
mechanical action taken at network borders.
Since the specification does not mandate an encoding format, the AMM
and ADM must provide enough information to make encoding (and
translating from one encoding to another) an unambiguous process.
Therefore, where necessary, this document provides identification,
enumeration and other schemes that ensure ADMs contain enough
information to prevent ambiguities caused by different encoding
schemes.
1.2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
The terms "Actor", "Agent", "Externally Defined Data", "Variable",
"Constant", Control", "Literal", "Macro", "Manager", "Operator",
"Report", "Report Template", "Rule", "State-Based Rule", "Table",
"Table Template", and "Time-Based Rule" are used without modification
from the definitions provided in [I-D.ietf-dtn-dtnma].
Additional terms defined in this document are as follows.
Application: A software implementation running on an Agent and being
managed by a Manager. This includes software that implements
protocol processing on an Agent.
Application Management Model (AMM): The object and literal-value
model defined by this document in Section 3 and implemented as
instances in ADMs and ODMs.
Application Resource Identifier (ARI): A unique identifier for any
Birrane, et al. Expires 8 April 2024 [Page 5]
Internet-Draft DTNMA AMM/ADM October 2023
AMM object and literal value, syntactically conformant to the
Uniform Resource Identifier (URI) syntax documented in [RFC3986]
and using the scheme name "ari".
Application Data Model (ADM): The set of statically-defined objects
necessary to manage an application asynchronously. This is also
the name for the text-based syntax used to express the contents of
that ADM, as defined in Section 7.
Operational Data Model (ODM): The set of dynamically-defined objects
created and controlled by Managers in the network.
Namespace: Each ADM and ODM has a universally unique identifier and
acts as a namespace for a set of AMM objects.
2. Data Modeling Concept of Operations
In order to asynchronously manage an application in accordance with
the [I-D.ietf-dtn-dtnma], an application-specific data model must be
created containing static structure for that application. This model
is termed the Application Data Model (ADM) and forms the core set of
information for that application in whichever network it is deployed.
ADM structure and base ADMs are discussed in detail in Section 4.
The objects codified in the ADM represents static configurations and
definitions that apply to any deployment of the application,
regardless of the network in which it is operating. Within any given
network, Managers supplement the information provided by ADMs with
dynamic objects. Each namespace of dynamic objects is termed an
Operational Data Model (ODM) and is discussed in detail in Section 5.
Both the ADMs and ODMs rely on a common meta-model, the Application
Management Model of Section 3, which defines the basic structure of
what kinds of types and objects are available to use within the
DTNMA. The relationships among the AMM, ADM, and ODM are illustrated
in Figure 1. Together, the set of objects in the union of all
supported ADMs with dynamic ODM objects forms the data model used to
manage an Agent.
While an agent hosts the actual object instances, each manager must
contain the corresponding ADM and ODM definitions in order to
identify and interact with those objects. Those interactions are
performed using Application Resource Identifiers (ARIs) as depicted
in Figure 2.
Birrane, et al. Expires 8 April 2024 [Page 6]
Internet-Draft DTNMA AMM/ADM October 2023
+---------------+
| AMM |
| (object types)|
+-------^-------+
|
+-------+-------+
| |
+-----+-----+ +-----+-----+
| ADM | | ODM |
|(instances)| |(instances)|
+-----------+ +-----------+
Figure 1: Data Model Relationships
+------------------------------------------+
| |
| +-------+ +-------+ +-------+ |
| | ADM 1 | | ADM 2 | | ODM 1 | |
| | def'n | | def'n | | def'n | |'
| +-------+ +-------+ +-------+ |
| ... ... |
| +-------+ +-------+ |
| | ADM N | | ODM M | |
| | def'n | | def'n | |
| +-------+ +-------+ |
| Manager instance |
+------------------------------------------+
^^
||
ARI values
||
vv
+------------------------------------------+
| |
| +-------+ +-------+ +-------+ |
| | ADM 1 | | ADM 2 | | ODM 1 | |
| | objs | | objs | | objs | |
| +-------+ +-------+ +-------+ |
| ... ... |
| +-------+ +-------+ |
| | ADM N | | ODM M | |
| | objs | | objs | |
| +-------+ +-------+ |
| Agent instance |
+------------------------------------------+
Figure 2: Agent and Manager Interaction
Birrane, et al. Expires 8 April 2024 [Page 7]
Internet-Draft DTNMA AMM/ADM October 2023
2.1. Values and Value-Producing Objects
The ARI of [I-D.birrane-dtn-ari] is used as the basis for the values
used internally for Agent Processing activities and for the basis of
Agent-Manager Messaging contents.
Of the value-producing object types discussed in Section 3.4 and
Section 6.5, the functions of these objects are summarized and
compared with literals in Table 1 and the following list. In that
table, "internal" means values are managed by the Agent itself and
"external" means the source of values is outside the Agent.
Literal (LIT): ARI literals are, by definition, immutable and fully
self-contained values.
For example, the number 4 is a literal value. The name "4" and
the value 4 represent the same thing and are inseparable. Literal
values cannot change ("4" could not be used to mean 5) and they
are defined external to the autonomy model (the autonomy model is
not expected to redefine what 4 means).
Constant (CONST): These objects are named values which are defined
in specific revisions of an ADM and produced directly by the Agent
implementing the ADM. Both the name and the value of the constant
are fixed and cannot be changed (within a revision).
An example of a constant would be defining the numerical value
_pi_ to some predetermined precision.
Variable (VAR): These objects are named value storage entities which
are defined in ADMs or ODMs and managed by the Agent implementing
the ADM or ODM. While the name is constant the value can change
over time due to controls acting upon the Agent. One standard
interface is an ADM-defined initial state expression with a
control available to reset to that initial state (which can itself
reference other value producing objects and operators). Another
standard interface is a control to set a variable to a specific
value.
An example of a variable using just its initial expression would
be an accumulator summing together a list of counter values
produced by other objects. An example of a manager-controlled
variable would be a threshold value used to compare against a
sensor value in a rule predicate.
Externally Defined Data (EDD): These objects are named entities
Birrane, et al. Expires 8 April 2024 [Page 8]
Internet-Draft DTNMA AMM/ADM October 2023
which are defined in an ADM but produce values based on data
provided to an Agent from its environment. These values are the
foundation of state-based autonomy as they capture the state of
the managed device. The autonomy model treats these values as
read-only state. It is an implementation matter to determine how
external data is transformed into values of the specific type
specified for an EDD.
Examples of externally defined values include temperature sensor
readings and the instantaneous data rate from a modem or radio.
+==========+===========+=========+
| | Immutable | Mutable |
+==========+===========+=========+
| Internal | CONST | VAR |
+==========+-----------+---------+
| External | LIT | EDD |
+==========+-----------+---------+
Table 1: Value-Producing
Object Types
2.2. Agent Processing
Based on the reasoning described in [I-D.ietf-dtn-dtnma], much of the
closed-loop processing of the state of the DTNMA Agent is performed
on the Agent itself using rule objects. The different types of
processing performed on the Agent are separated into Execution,
Evaluation, and Reporting with corresponding AMM object types related
to each of these as indicated in Table 2 (_e.g._, execution relates
to CTRL objects but not OPER objects). Some of the objects defined
in the Agent ADM (Section 4.3) combine the use of these processing
activities, but they are still independent of each other. There is
no mixing of activities such as executing a control within an
expression; although the execution of a control can result in an
expression being evaluated they are independent activities.
Within the runtime of an Agent any input, output, and intermediate
values can use the concept of a semantic type (Section 3.3) to do
things like restrict the valid numeric range of a value or allow a
union of disjoint types to be present (_e.g._, a certain value can be
a boolean or an unsigned integer). This is combined with the literal
types available from the ARI to allow complex type information to be
present in an ADM or ODM without requiring additional over-the-wire
encoding size. A Type Casting activity is defined for when implicit
or explicit type conversion is needed.
Birrane, et al. Expires 8 April 2024 [Page 9]
Internet-Draft DTNMA AMM/ADM October 2023
+==================+=================+========+
| Activity | Objects | Values |
+==================+=================+========+
| Execution | CTRL | MAC |
+------------------+-----------------+--------+
| Evaluation | OPER, TYPEDEF | EXPR |
+------------------+-----------------+--------+
| Reporting | _N/A_ | RPTT |
+------------------+-----------------+--------+
| Value Production | CONST, EDD, VAR | _N/A_ |
+------------------+-----------------+--------+
| Type Casting | TYPEDEF | _N/A_ |
+------------------+-----------------+--------+
| Rule Autonomy | SBR, TBR | _N/A_ |
+------------------+-----------------+--------+
Table 2: Processing Activities and Object Types
2.3. Agent-Manager Messaging
This document does not define a messaging protocol between agents and
managers but full functioning of this data model behavior does rely
on the following types of messages being available:
Execution: This message causes an Execution of a referenced
parameterized CTRL object (Section 3.4.5) or produced MAC value
(Section 4.2.4). This type of message is only sent from Manager
to Agent. An optional field of this message is an opaque
correlator "nonce" which can be used to indicate that the result
of the corresponding CTRL execution is desired to be reported back
to the Manager. Each message can reference multiple execution
sources (CTRL and MAC) and, unlike the MAC execution itself, can
be handled by executing multiple items in parallel. It is an
implementation detail whether a Manager sends fewer messages with
more sources or more timely messages with fewer sources.
Reporting: This message carries the RPT values (Section 4.2.6)
generated by Reporting activities and as the result of Execution
when the Manager provides a correlator nonce. This type of
message is only sent from Agent to Manager. One field of the
report message is a correlator nonce which is used to associate
report items with specific Execute messages which caused the
reports to be generated. Each message can contain multiple RPT
values but all must be associated with the same nonce, although it
is an implementation detail whether an Agent sends fewer report
messages with more report values or more timely messages with
fewer values.
Birrane, et al. Expires 8 April 2024 [Page 10]
Internet-Draft DTNMA AMM/ADM October 2023
The contents of these messages, individual fields, are representable
by ARI values so require only small additional message-type
identifying and framing overhead to bind to whatever transport is
being used (_e.g._ the Bundle Protocol).
3. Application Management Model (AMM)
This section describes the Application Management Model, which is the
meta-model used to implement the DTNMA. This section also provides
additional information necessary to work with this model, such as:
literal value types, object structure, naming conventions, and
processing semantics.
The overall AMM is decomposed into two categories:
Objects: These are the structural and behavioral elements of the
AMM, present in ADMs and ODMs. Objects implement the actual
purpose of the applications being managed; they extract values
from the Agent's environment, operate on expressions, store
variables, and execute controls to affect the Agent's environment.
Because objects are behavioral they have no complete static
representation, objects are only ever described and identified.
AMM object types are defined in Section 3.4 and objects are
instantiated as part of an ADM or ODM.
Values: These are the runtime state and intermediates of the AMM,
present in the Agent's state but not directly in ADMs or ODMs.
Objects produce, operate on, and store or consume values and these
values are what are present in messaging between Managers and
Agents. AMM values are explained in more detail in Section 3.1.
3.1. AMM Values
Values within the AMM have two top-level classes: literal values, and
object references. Each of these is discussed more detail in the
following subsections. Both classes of AMM values are related to
what can be represented externally as an ARI, as described in
Section 3.1.3.
3.1.1. Literal (LIT)
As defined in the DTNMA, Literal (LIT) values are those whose value
and identifier are equivalent. These are the most simple values in
the AMM. For example, the literal "4" serves as both an identifier
and a value.
Birrane, et al. Expires 8 April 2024 [Page 11]
Internet-Draft DTNMA AMM/ADM October 2023
Because the value of a Literal object serves as its identifier, there
is no concept of a parent namespace or parameters. A literal can be
completely identified by its data type and data value.
Literals have two layers of typing:
Literal Type: This is the lower layer which defines the syntax of
the literal value and bounds the domain of the value (_e.g._ a
BOOL has two possible values, while an INT has a large domain of
integers). There are a small number of literal types and they are
managed with an IANA registry defined in Section 9.3 of
[I-D.birrane-dtn-ari].
Semantic Type: This is the higher layer which defines additional
semantics to a value, such as a restricted domain of values or a
human-friendly text unit or limits on the items of an ARI
collection. Semantic types are defined within ADMs (see
Section 3.3 and Section 3.4.2), so there can be an arbitrary
number of them and they are managed outside of a central
authority.
All literal values have a concrete and stand-alone representation
independent of any ADM or ODM behavior in the form of an ARI
(Section 3.1.3), but when represented as an ARI a value loses its
semantic type.
3.1.2. Object Reference (OBJ-REF)
Every object in the AMM is uniquely identifiable, regardless of
whether the item is defined statically in an ADM or dynamically in an
ODM. Object reference values are composed of four parts: a
namespace, an object type, an object name, and object-specific
optional parameters.
AMM objects are identified within unique namespaces to prevent
conflicting names within network deployments, particularly in cases
where network operators are allowed to define their own object names.
In this capacity, namespaces exists to eliminate the chance of a
conflicting object name. They MUST NOT be used as a security
mechanism. An Agent or Manager MUST NOT infer security information
or access control based solely on namespace information.
Two categories of namespaces available within the OBJ-REF and the ARI
syntax:
ADM Namespace: These are defined, with text-name and enumeration, in
Birrane, et al. Expires 8 April 2024 [Page 12]
Internet-Draft DTNMA AMM/ADM October 2023
an IANA registry of ADMs in Section 9.3 of [I-D.birrane-dtn-ari].
There is also a reservation of private-use code points for domain-
and mission-specific ADMs. In ARI form, ADM namespaces are
present as either their name or enumeration directly.
ODM Namespace: These are defined, with text-name and enumeration, in
an IANA registry of ODMs in Section 9.3 of [I-D.birrane-dtn-ari].
It is expected that most ODM use will be domain- and mission-
specific. In ARI form, ODM namespaces are present as a "!"
prefixed name or as a negative-value enumeration.
Object types, each with a text-name and enumeration, are defined in
an IANA registry by Section 9.3 of [I-D.birrane-dtn-ari].
Object names are text strings and enumerations whose value is
determined by the creator of the object. For those objects defined
in an ADM, the structure of the object name is given in
Section 3.4.1.
3.1.2.1. Parameters
Parameterization is used in the AMM to enable expressive autonomous
function and reduce the amount of traffic communicated between
Managers and Agents. In the AMM, most objects can be parameterized
and the meaning of parameterization for each object type is defined
in Section 3.4 with behaviors related to parameters defined in
Section 6.
There are two notions of parameters defined in the AMM, which take
their name from computer programming vernacular used for discussing
function declarations and function calls, those are: formal
parameters and actual parameters. Formal parameters are discussed in
Section 3.4.1 and actual parameters are discussed here in relation to
the object reference.
Actual parameters represent the data values passed to a parameterized
AMM Object at runtime. They "fulfill" the parameter requirements
defined by the formal parameters for that object. Each object type
can have a slightly different notion of how its parameters affect its
processing activities.
An actual parameter MUST specify a value and MAY specify a type. If
a type is provided it MUST match the type provided by the formal
parameter.
There are two ways in which the value of an actual parameter can be
used:
Birrane, et al. Expires 8 April 2024 [Page 13]
Internet-Draft DTNMA AMM/ADM October 2023
Parameter by Value: This method involves directly supplying the
value as part of the actual parameter. It is the most direct
method for supplying values.
Parameter by Label: This method involves supplying the LABEL of some
other processing-context-specific value and substituting, at
runtime, that named value as the value of this parameter. This
method is useful when a parameterized AMM Object contains a value
that references another parameterized AMM Object. The contained
object's actual parameter can be given as the LABEL of the
containing object's parameter. In this way, a containing object's
parameters can "flow down" to all of the objects it references.
In cases where a formal parameter contains a default value, the
associated actual parameter may be omitted. Default values in formal
parameters (and, thus, optional actual parameters) are encouraged as
they reduce the size of data items communicated between Managers and
Agents in a network.
3.1.3. The Application Resource Identifier (ARI)
The Application Resource Identifier (ARI) is used to represent AMM
values outside of an Agent or Manager (_i.e._ in messaging between
them) and is defined in [I-D.birrane-dtn-ari]. Another function of
the ARI is for diagnostic or configuration purposes within either
Managers or Agents. It is important to make the distinction that
within an AMM entity (Agent or Manager) the semantic type of a value
is kept, but when exchanged via ARI the semantic type is lost. The
AMM defines type compression and reconstruction rules in Section 6.10
to handle this.
3.2. Literal Types
This section describes the literal type definitions used by the AMM.
By definition, literal values are self-contained and literal types
restrict the form and function of those values.
All literal types within the AMM exit within a flat namespace, but
some types have complex relationships with other types beyond the "is
a" concept of type inheritance. Types are defined within an IANA
registry by Section 9.3 of [I-D.birrane-dtn-ari] and explained in
this section. The following subsections divide the types into groups
to simplify their explanation, not because of an intrinsic
relationship within each group.
Birrane, et al. Expires 8 April 2024 [Page 14]
Internet-Draft DTNMA AMM/ADM October 2023
3.2.1. Simple Types
Simple types are those which cannot be subdivided and represent an
"atomic" value within the AMM type system. They correspond roughly
with the CBOR primitive types Section 3.3 of [RFC8610]. The simple
types are summarized in Table 3.
+=========+==================================================+
| Type | Description |
+=========+==================================================+
| NULL | The singleton null value. |
+---------+--------------------------------------------------+
| BOOL | A native boolean true or false value. |
+---------+--------------------------------------------------+
| BYTE | An 8-bit unsigned integer. |
+---------+--------------------------------------------------+
| INT | A 32-bit signed integer. |
+---------+--------------------------------------------------+
| UINT | A 32-bit unsigned integer. |
+---------+--------------------------------------------------+
| VAST | A 64-bit signed integer. |
+---------+--------------------------------------------------+
| UVAST | A 64-bit unsigned integer. |
+---------+--------------------------------------------------+
| REAL32 | A 32-bit [IEEE.754-2019] floating point number. |
+---------+--------------------------------------------------+
| REAL64 | A 64-bit [IEEE.754-2019] floating point number. |
+---------+--------------------------------------------------+
| TEXTSTR | A text string composed of (unicode) characters. |
+---------+--------------------------------------------------+
| BYTESTR | A byte string composed of 8-bit values. |
+---------+--------------------------------------------------+
| TP | An absolute time point (TP). |
+---------+--------------------------------------------------+
| TD | A relative time difference (TD) with a sign. |
+---------+--------------------------------------------------+
| LABEL | A text label of a parent object parameter. This |
| | is only valid in a nested parameterized ARI. |
+---------+--------------------------------------------------+
| CBOR | A byte string containing an encoded CBOR item. |
| | The structure is opaque to the Agent but |
| | guaranteed well-formed for the ADM using it. |
+---------+--------------------------------------------------+
| LITTYPE | An integer value representing one of the code |
| | points in this Literal Types table. |
+---------+--------------------------------------------------+
Table 3: Simple Literal Types
Birrane, et al. Expires 8 April 2024 [Page 15]
Internet-Draft DTNMA AMM/ADM October 2023
The following subsections discuss nuances in sub-groups of these
simple types.
3.2.1.1. Discrete Value Types
The NULL and BOOL types are used to limit to specific discrete
values. Because there are CBOR primitive types corresponding exactly
with these AMM types, generators of ARIs with these types can always
be compressed by eliding the literal type as defined in Section 6.10.
The NULL type has only a single value, null, which is not useful for
expressions or type casting but is useful for defining union types
which have "optional value" semantics where the null value is used to
indicate the absence of a normal value.
The BOOL type is useful for type casting (Section 6.9.1) where an
arbitrary value is treated as "truthy" or "falsey" in a context such
as a State-Based Rule (SBR) condition.
3.2.1.2. Numeric Types
All of the numeric types (BYTE, UINT, INT, UVAST, VAST, REAL32, and
REAL64) exist within a domain where values can be cast between types
(Section 6.9.1). Some cases of implicit casting is done for type
promotion as necessary for arithmetic operations.
3.2.1.3. Absolute (TP) and Relative (TD) Time Types
The TP type represents an instant in time in the UTC datum. When in
text form it is formatted in accordance with the date-time symbol of
Appendix A of [RFC3339] and always in the "Z" time-offset.
The TD type represents an offset in time from a relative epoch
instant, either later than (a positive offset) or earlier than (a
negative offset). When in text form it is formatted in accordance
with the duration symbol of Appendix A of [RFC3339] with a positive
or negative sign prefix. The epoch instant of a relative time MUST
be unambiguously defined in the context using the time value.
| In cases where a type signature contains an union of TP and TD
| (i.e. an option for either type), relative times have some
| advantages over absolute times: they do not require time to be
| synchronized across Agents and Managers, and they are more
| compact in their representation. For example, expressing the
| semantics "run control_one 10 seconds after receiving it" or
| "run control_two 20 seconds after running control_one" is more
| appropriate using relative times than absolute times.
Birrane, et al. Expires 8 April 2024 [Page 16]
Internet-Draft DTNMA AMM/ADM October 2023
3.2.2. Collections
AMM objects, or parameters associated with those objects, often need
to represent groups of related data or more complex nesting of data.
These are the literal types for collections, which can only be
present in a typed-literal ARI form.
The AMM defines two collection literal types, AC and AM, and allows
ADMs to combine these literal types with a complex pattern syntax to
create semantic types constraining their contents (_e.g._, for macros
and expressions in Section 4.2.3).
3.2.2.1. ARI Collection (AC)
An ARI Collection (AC) is an ordered list of ARIs.
ACs are used when there exists a need to refer to multiple AMM
objects as a single unit. For example, when defining a Report
Template, the definition has an AC that defines the ordered ARIs
whose values constitute that report.
3.2.2.2. ARI Map (AM)
An ARI Map (AM) is a mapping from a set of literal-value "key" ARI to
arbitrary-valued "value" ARI.
// TBD
3.2.3. Custom Literal Types
When an application requires a more complex or specialized literal
type than one already available the preferred design procedure is as
follows:
1. If an existing ADM already defines a semantic typedef (see
Section 3.4.2) it is RECOMMENDED to import that ADM and use its
typedef.
2. Otherwise, when it is possible to use an ADM-defined semantic
typedef to achieve the desired goals it is RECOMMENDED to do so.
3. Otherwise, when the desired behavior cannot be accomplished by a
semantic typedef, it is RECOMMENDED to use the opaque CBOR type
with interface documentation to explain the syntax of the encoded
CBOR item.
4. Otherwise, the application MAY make use of the private-use block
of literal type code points.
Birrane, et al. Expires 8 April 2024 [Page 17]
Internet-Draft DTNMA AMM/ADM October 2023
Implementing a custom literal type requires implementation effort on
both an Agent and its associated Manager(s) as well as being more
opaque to diagnostic tools and middleboxes.
3.3. Semantic Types
While literal types control the basic syntax and domain of AMM
values, the concept of semantic type is to provide a means to augment
literal types by expanding (via union), narrowing (via restrictions),
and adding human-friendly attributes.
Semantic types can be defined in two ways: a named Semantic Type
Definition (TYPEDEF) or an anonymous type. The specific syntax used
to define semantic types within an ADM are defined and explained in
Section 7.
When a "type" is needed for an AMM value in an object definition it
SHALL be either one of the literal types, a namespace-qualified
semantic type, or an anonymous semantic type just for that value.
3.4. AMM Objects
This section identifies the types of objects that make up the AMM and
which are instantiated within each ADM and ODM. Each object type is
defined by its logical structure and its behavior in "execution" and
"evaluation" contexts within Agents. Each type can allow or disallow
parameters within objects and, due to processing behaviors, can
either allow or disallow use within an ADM or ODM.
Unless explicitly specified in the object type subsection, an object
SHALL NOT be parameterized.
3.4.1. Common Object Fields
Every object type in the AMM includes a set of fields providing
annotative or otherwise user-friendly descriptive information for the
object. This information may be used as documentation (for example,
only present in ADMs and on operator consoles) and/or encoded and
transmitted over the wire as part of a management protocol.
The metadata supported by the AMM for all objects is as follows:
Name:
An object name is a text string associated with the object, but
does not constitute the sole identifier for the object. Names
provide human-readable and/or user-friendly ways to refer to
objects with the text form of an ARI. Each object definition
SHALL contain a name field. An object's name SHALL NOT change
Birrane, et al. Expires 8 April 2024 [Page 18]
Internet-Draft DTNMA AMM/ADM October 2023
between ADM revisions. Each name SHALL conform to the id-text
ABNF symbol of Section 4 of [I-D.birrane-dtn-ari]. Within each
namespace and object type, the name of an object SHALL be unique.
Enumeration:
An object enumeration is an integer associated with the object,
which identifies the object just like its name. Object
enumerations provide a stable and concise identifier for the
binary encoded form of an ARI. Each object definition SHOULD
contain an enumeration field. An object's enumeration SHALL NOT
change between ADM revisions. When present, each enumeration
SHALL be an unsigned integer value. Within each namespace and
object type, the enumeration of an object SHALL be unique.
Status:
Each object definition MAY contain a status field. The valid
status values of an object are the same as the valid status values
for an ADM in Section 4.1.1. In the absence of a status field,
the status of the object SHALL be considered the same as the
status of the ADM which contains it.
Reference:
Each object definition MAY contain a reference field. A reference
is a text string referring to a specification or other document
which details the source or purpose of the object.
Description:
Each object definition MAY contain a description field. A
description is a text string explaining the purpose or usage of
the object in a human-readable format. There is no minimum or
maximum size of description text for an object. The description
serves as documentation for the object and SHOULD be the same
regardless of how the object might be parameterized. For example,
the description of a CTRL object should document the purpose of
the CTRL in a way that is independent of the value of any
particular parameter value passed to that CTRL.
Formal parameters define a method to customize an AMM object. When
used by an object definition, it's formal Parameters SHALL be an
ordered list of individual formal parameter definitions. Each formal
parameter SHALL include type and name. Each formal parameter MAY
include an optional default value. The application of default
parameters and relationship of actual parameters (Section 3.1.2.1) to
formal parameters is defined in Section 6.4.
Birrane, et al. Expires 8 April 2024 [Page 19]
Internet-Draft DTNMA AMM/ADM October 2023
3.4.2. Semantic Type Definition (TYPEDEF)
An ADM can define a semantic type definition (TYPEDEF) to give a name
to a semantic type (Section 3.3). This TYPEDEF name can then be used
as a type anywhere else in the same ADM or another one which imports
it.
The definition of a TYPEDEF consists of the following:
Name, Enumeration, Status, Reference, Description:
As defined in Common Object Fields.
Type:
A TYPEDEF definition SHALL include the type being named, as
described in Section 3.3. The type of a TYPEDEF is fixed and
SHALL NOT change between ADM revisions. The type SHALL be either
a union of other types or a restriction of or annotation upon
another type.
As defined in this document, TYPEDEFs and semantic types can only be
defined within an ADM. Future capability could allow the use of
TYPEDEFs within ODMs.
3.4.3. Externally Defined Data (EDD)
Externally defined data (EDD) objects, as defined in the DTNMA,
represent data values that are produced based on a source external to
the Agent itself. The Value Production occurs at the moment the
value is needed, by either an Evaluation or a Reporting. The actual
value could come from outside of the Agent proper, or be derived from
data outside of the Agent.
The value production of an EDD SHOULD be nilpotent and have no side-
effects in the processor. This property is not enforced by the Agent
but requires consideration of the ADM designers, see Section 8.
For values managed entirely within the Agent use a Variable (VAR) or
for constant-values use a Constant (CONST). For complex tabular
data, use an EDD with a type which produces a Tabular Report (TBL).
The definition of an EDD consists of the following:
Name, Enumeration, Status, Reference, Description:
As defined in Common Object Fields.
Birrane, et al. Expires 8 April 2024 [Page 20]
Internet-Draft DTNMA AMM/ADM October 2023
Parameters:
An EDD definition MAY include ARI parameters to be used when the
EDD is used to produce a value. Parameterized objects are
discussed in Section 8. The parameters of an EDD are fixed and
SHALL NOT change between ADM revisions.
Type:
An EDD definition SHALL include the type of the value produced by
the object, as described in Section 3.3. The type of an EDD is
fixed and SHALL NOT change between ADM revisions.
As defined in this document, EDDs can only be defined within an ADM.
Future capability could allow the use of EDDs within ODMs.
3.4.4. Constant (CONST)
A Constant (CONST) represents a named literal value, but unlike an
Externally Defined Data (EDD) or Variable (VAR) a CONST always
produces the same value. Examples include common mathematical values
such as PI or well-known time epochs such as the UNIX Epoch. A CONST
typed to produce a simple value can be used within an expression (see
Section 6.7), where the object is used to produce a value at the
moment of evaluation. A CONST can also be typed to produce an EXPR
value to evaluate, or MAC value to execute.
The definition of a CONST consists of the following:
Name, Enumeration, Status, Reference, Description:
As defined in Common Object Fields.
Type:
A CONST definition SHALL include the type of the value produced by
the object, as described in Section 3.3. The type of a CONST is
fixed and SHALL NOT change between ADM revisions.
Value:
A CONST definition SHALL include the literal value produced during
evaluation.
As defined in this document, CONSTs can only be defined within an
ADM. Allowing network operators to define constants dynamically
means that a Constant could be defined, removed, and then re-defined
at a later time with a different value, which defeats the purpose of
having Constants. When adding new "fixed" values to an ODM, a
Variable (VAR) MUST be used instead of a Constant.
Birrane, et al. Expires 8 April 2024 [Page 21]
Internet-Draft DTNMA AMM/ADM October 2023
3.4.5. Control (CTRL)
A Control (CTRL) represents a predefined function that can be
executed on an Agent. Controls are not able to be defined as part of
dynamic network configuration since their execution is typically part
of the firmware or other implementation outside of the Agent proper.
The execution of a CTRL SHOULD be idempotent and have no effect if
executed multiple times in sequence. This property is not enforced
by the Agent but requires consideration of the ADM designers, see
Section 8.
Controls can be executed in a "one shot" manner as part of messaging
from a Manager to an Agent. Network operators that wish to
autonomously execute functions on an Agent may use a State-Based Rule
(SBR) or Time-Based Rule (TBR). When an execution involves the
ordered sequence of controls, a Macro (MAC) SHOULD be used instead of
a more fragile use of CTRL directly.
The definition of a CONST consists of the following:
Name, Enumeration, Status, Reference, Description:
As defined in Common Object Fields.
Parameters:
A CTRL definition MAY include ARI parameters to be used when the
CTRL is executed. Parameterized objects are discussed in
Section 8.
Result:
A CTRL definition MAY include the definition of a result. The
result SHALL have a name and a type. The result MAY have a
default value. The result of a CTRL is separate from the
execution status as being successful or failed.
As defined in this document, CTRLs can only be defined within an ADM.
Future capability could allow the use of CTRLs within ODMs if there
was some mechanism to bind a CTRL definition to some platform-
specific execution specification (_e.g._, a command line sequence).
3.4.6. Operator (OPER)
An Operator (OPER) represents a user-defined, typically mathematical,
function that operates within the evaluation of an Expression (EXPR).
It is expected that operators are implemented in the firmware of an
Agent.
Birrane, et al. Expires 8 April 2024 [Page 22]
Internet-Draft DTNMA AMM/ADM October 2023
The AMM separates the concepts of Operators and Controls to prevent
side-effects in Expression evaluation (e.g. to avoid constructs such
as A = B + GenerateReport()). For this reason, Operators are given
their own object type and Controls do not interact with operators.
The definition of an OPER consists of the following:
Name, Enumeration, Status, Reference, Description:
As defined in Common Object Fields.
Parameters:
An OPER definition MAY include ARI parameters to be used when the
OPER is evaluated. Parameterized objects are discussed in
Section 8. The parameters of an OPER are distinct from the
operands from the expression stack.
Operands:
An OPER definition MAY include definitions of operand values to be
popped from the expression stack when the OPER is evaluated. Each
operand SHALL consist of a name, a type, and a cardinality. Any
non-trivial OPER will have one or more operands. An OPER can have
a non-fixed operand count which is based on a parameter value
(_e.g._, an operator can average the top _N_ values from the
stack, where _N_ is a parameter).
Result:
An OPER definition SHALL include definition of a result value to
be pushed onto the expression stack after the OPER is evaluated.
The result SHALL have a name and a type. The result SHALL NOT
have a default value.
As defined in this document, OPERs can only be defined within an ADM.
Future capability could allow the use of OPERs within ODMs if there
was some mechanism to bind an OPER definition to some platform-
specific evaluation specification.
3.4.7. State-Based Rule (SBR)
A State-Based Rule (SBR) is a form of autonomy in which the Agent
performs an action upon the change of state to meet a specific
condition. The execution model of the SBR is to evaluate the
Condition (as often as necessary to handle changes in its expression
evaluation) and when it evaluates to a truthy (Section 6.9.1) value
and it has been no shorter than the Minimum Interval since the last
execution, the Action is executed. When the Maximum Count of
executions is reached the TBR is disabled. The execution occurs
concurrently with any time processing and may take longer than the
Minimum Interval, so it is possible that multiple executions are
Birrane, et al. Expires 8 April 2024 [Page 23]
Internet-Draft DTNMA AMM/ADM October 2023
requested to overlap in time.
Each SBR has an enabled state to allow rules to be retained in an ADM
or ODM but not enabled during Manager-controlled time periods or
under certain Manager-desired conditions. See Section 4.3 for
details about what SBR-related controls are in the Agent ADM.
The definition of an SBR consists of the following:
Name, Enumeration, Status, Reference, Description:
As defined in Common Object Fields.
Action:
An SBR definition SHALL include an action in the form of a Macro
(MAC). When triggered, the action execution SHALL be executed in
accordance with Section 6.6 in an execution context with no
parameters.
Condition:
An SBR definition SHALL include a condition in the form of an
Expression (EXPR). The condition SHALL be evaluated in accordance
with Section 6.7 in an evaluation context with no parameters. The
result of the condition SHALL be cast to a BOOL value after
evaluation and used to determine when to execute the action of the
SBR.
Minimum Interval:
An SBR definition SHALL include a minimum execution interval in
the form of a non-negative TD value. The interval MAY be zero to
indicate that there is no minimum. This is _not_ a limit on the
interval of evaluations of the condition. This value can be used
to limit potentially high processing loads on an Agent.
Maximum Count:
An SBR definition SHALL include a maximum execution count in the
form of a non-negative UVAST value. The count sentinel value zero
SHALL be interpreted as having no maximum. This is _not_ a limit
on the number of evaluations of the condition.
Initial Enabled:
An SBR definition MAY include an initial value for its enabled
state. If not provided, the initial enabled state SHALL be true.
Birrane, et al. Expires 8 April 2024 [Page 24]
Internet-Draft DTNMA AMM/ADM October 2023
3.4.8. Time-Based Rule (TBR)
A Time-Based Rule (TBR) is a form of autonomy in which the Agent
performs an action at even intervals of time. The execution model of
the TBR is to start a timer at the Start Time of the TBR ticking at
an even Period; each time the timer expires the Action is executed.
When the Maximum Count of executions is reached the TBR is disabled.
The execution occurs concurrently with any time processing and may
take longer than the TBR Period, so it is possible that multiple
executions are requested to overlap in time.
Each TBR has an enabled state to allow rules to be retained in an ADM
or ODM but not enabled during Manager-controlled time periods or
under certain Manager-desired conditions. See Section 4.3 for
details about what TBR-related controls are in the Base ADM.
The definition of an SBR consists of the following:
Name, Enumeration, Status, Reference, Description:
As defined in Common Object Fields.
Action:
An SBR definition SHALL include an action in the form of a Macro
(MAC). When triggered, the action execution SHALL be executed in
accordance with Section 6.6 in an execution context with no
parameters.
Start Time:
An SBR definition SHALL include a start time in the form of a TIME
(Section 4.2.2) value. A relative start time SHALL be interpreted
relative to the absolute time at which the Agent is initialized
(for ADM rules) or the rule is created (for ODM rules). The start
time MAY be the relative time zero to indicate that the TBR is
always active. This is _not_ a limit on the interval of
evaluations of the condition.
Period:
A TBR definition SHALL include a period in the form of a positive
TD value. The period SHALL NOT be zero but any non-zero small
period is valid.
Maximum Count:
A TBR definition SHALL include a maximum execution count in the
form of a non-negative UVAST value. The count sentinel value zero
SHALL be interpreted as having no maximum. This is _not_ a limit
on the number of evaluations of the condition.
Birrane, et al. Expires 8 April 2024 [Page 25]
Internet-Draft DTNMA AMM/ADM October 2023
Initial Enabled:
A TBR definition MAY include an initial value for its enabled
state. If not provided, the initial enabled state SHALL be true.
3.4.9. Variable (VAR)
A Variable (VAR) is a stateful store of a value in an Agent. The
evaluation of a VAR is similar to an EDD except that all the behavior
of a VAR is entirely within an Agent, while the ultimate source of an
EDD value is outside of the Agent. The evaluation of a VAR into a
value SHALL be nilpotent and have no side-effects in the processor.
A VAR has an initializer, which is used at Agent initialization and
to reset the VAR, but the VAR is otherwise stateful and will retain
its last value between any actions which edit it.
The definition of a VAR consists of the following:
Name, Enumeration, Status, Reference, Description:
As defined in Common Object Fields.
Parameters:
A VAR definition MAY include ARI parameters to be used when the
VAR is evaluated. Parameterized objects are discussed in
Section 8. Parameters for a VAR are only meaningful when the VAR
contains a value with actual parameters themselves containing a
LABEL value.
Type:
An VAR definition SHALL include the data type of the value
produced during evaluation, as described in Section 3.3. The type
of a VAR is fixed and SHALL NOT change between ADM revisions.
Initializer:
An VAR definition MAY include an initializer in the form of an
Expression (EXPR). The only times the initializer are evaluated
are at Agent Initialization and when a CTRL is used to reset the
state of the VAR.
| NOTE: It is possible to specify an expression that evaluates to
| a type different than the VAR itself. For example, if an EXPR
| adds two single-precision floating point numbers, the VAR MAY
| have an integer type associated with it. The VAR
| initialization will always be cast (Section 6.9) to the type of
| the VAR before assignment.
Birrane, et al. Expires 8 April 2024 [Page 26]
Internet-Draft DTNMA AMM/ADM October 2023
4. Application Data Models (ADMs)
An ADM is a logical entity for defining static AMM object instances,
which are discussed in detail in Section 3.4. Each ADM exists as a
separate namespace for its contained objects, but allows importing
object _names_ from other ADMs to reuse them. Each Agent can support
any number of ADMs at one time (subject to implementation
limitations) and each Manager can operate with ADMs of different
revisions to support diverse Agents.
The following subsections define what is present in an ADM generally
and what objects necessary to operate a DTNMA Agent are present in
two base ADMs.
4.1. ADM Definitions
An ADM is "static" in the sense that it is revision-controlled and a
released revision of an ADM does not change. Besides AMM object
definitions there are metadata and handling rules for the ADM itself,
which are discussed in this section.
4.1.1. ADM Metadata
This section explains the purposes of the metadata fields of an ADM,
while the profile of Section 7 defines a syntax for how these fields
fit into an ADM module.
Name:
Each ADM definition SHALL contain a name field. An ADM's name
SHALL NOT change between ADM revisions. The name SHALL conform to
the id-text ABNF symbol of Section 4 of [I-D.birrane-dtn-ari].
Enumeration:
An ADM enumeration is an integer associated with the object, which
identifies the object just like its name. ADM enumerations
provide a stable and concise identifier for the binary encoded
form of an ARI. Each ADM definition SHALL contain an enumeration
field. An ADM's enumeration SHALL NOT change between ADM
revisions. The enumeration SHALL be an unsigned integer value.
Revision History:
Each ADM SHALL contain a history of dated revisions. At least one
revision SHALL be present and mark the date at which the ADM was
released for use. During development and testing an ADM need not
have updated revisions, only when a release occurs should a
revision be added.
Birrane, et al. Expires 8 April 2024 [Page 27]
Internet-Draft DTNMA AMM/ADM October 2023
Status:
Each ADM definition SHOULD contain a status field. The valid
status value of an ADM SHALL be identical to the Status field of
YANG Section 7.21.2 of [RFC7950]. In the absence of a status
field, the status of the ADM SHALL be considered the same as the
status of the ADM which contains it.
Reference:
Each ADM definition SHOULD contain a reference field. A reference
is a text string referring to a specification or other document
which details the source or purpose of the ADM.
Description:
Each ADM definition SHOULD contain a description field. A
description is a text string explaining the purpose or usage of
the ADM in a human-readable format.
Features:
Each ADM definition MAY contain a set of feature definitions, see
Section 4.1.2 for details. Each feature SHALL have a name that is
unique within the namespace of the ADM. Each name SHALL conform
to the id-text ABNF symbol of Section 4 of [I-D.birrane-dtn-ari].
4.1.2. Features and Conformance
Following in the pattern of YANG features Section 5.6.2 of [RFC7950]
and SMIv2 conformance groups [RFC2580], the AMM has the concept of
ADM features and Agent conformance to those features. Each feature
is a simple qualified name and each object in an ADM can be
conditional on the conformance to a set of features.
4.2. Contents of an DTNMA ADM
The base DTNMA ADM is a necessary part of the AMM typing, execution,
and evaluation models. Rather than having some Agent logic defined
purely by specification, this document uses a base ADM to define
semantic types and controls needed for normal Agent operations. The
needed types are still set by specification and are unchanging within
an ADM revision, but this avoids having a separate, intermediate
typing system between the AMM-defined semantic types and the ARI-
defined literal types. This is also in-line with how the SMIv2
[RFC2578] and NETCONF/YANG [RFC6991] both rely on base modules for
some core behavior.
Birrane, et al. Expires 8 April 2024 [Page 28]
Internet-Draft DTNMA AMM/ADM October 2023
4.2.1. Simple Semantic Types
The most basic use of a semantic type is to provide additional
meaning to simple types. None of these types associates a unit with
the value, which it is expected that a derived type or an anonymous
type (at the point of use) would add for additional clarity.
These are summarized below:
counter32 and counter64: An unsigned integer value with an arbitrary
initial value which increments over time and wraps around the
maximum value. These correspond with the same names defined in
SMIv2 and YANG [RFC6021].
gauge32 and gauge64: An integer value sampling some measurement
which can increase or decrease arbitrarily over time. These
correspond with the same names defined in SMIv2 and YANG
[RFC6021].
timestamp: An absolute time at which an event happened. This
corresponds with the same name defined in SMIv2 and YANG
[RFC6021].
4.2.2. Type Unions
All of the literal types defined in [I-D.birrane-dtn-ari] have a flat
structure, with some types sharing the same CBOR primitive encoding
but having the concept of a derived "base" of another type. In order
to allow types to fit into a more logical taxonomy, the base ADM
defines some specific semantic typedefs to group literal types.
These groups are not a strict logical hierarchy and are intended only
to simplify the effort of an ADM designer when choosing type
signatures.
These are summarized below:
TYPE-REF: The union of LITTYPE and TYPEDEF-REF types.
INTEGER: The union of BYTE, UINT, INT, UVAST, and VAST types.
FLOAT: The union of REAL32 and REAL64 types.
NUMERIC: The union of INTEGER and FLOAT types.
PRIMITIVE: The union of NONE, BOOL, NUMERIC, TEXTSTR, and BYTESTR
types.
TIME: The union of TP and TD types.
Birrane, et al. Expires 8 April 2024 [Page 29]
Internet-Draft DTNMA AMM/ADM October 2023
SIMPLE: The union of PRIMITIVE, and TIME types.
LITERAL: The union of SIMPLE, LITTYPE, LABEL, CBOR, AC, and AM
types. This matches all values that can be in a literal value
ARI.
VALUE-REF: The union of CONST-REF, EDD-REF, and VAR-REF reference
types. This matches any reference to an object that can produce a
value (Section 6.5).
NONCE: The union of BYTESTR and UINT64 types, used to correlate
messages.
4.2.3. Expression (EXPR)
An Expression (EXPR) is an ordered collection of references to
Operators or operands. An EXPR takes the form of a semantic typedef
refining an AC to be a list of ARIs referencing OPERs, ARIs
referencing evaluate-able objects (see Section 6.7), or literal value
ARIs (with Simple Types). These operands and operators form a
mathematical expression that is used to compute a resulting value.
The evaluation procedure of an EXPR is defined in Section 6.7.
Expressions are used within an ADM for defining the initializer of a
Variable (VAR) and for defining the condition of a State-Based Rule
(SBR).
Since the Expression is an AC, there are no annotative constructs
such as parenthesis to enforce certain orders of operation. To
preserve an unambiguous calculation of values, the ARIs that form an
Expression MUST be represented in postfix order. Postfix notation
requires no additional symbols to enforce precedence, always results
in a more efficient encoding, and post-fix engines can be implemented
efficiently in embedded systems.
For example, the infix expression A * (B * C) is represented as the
postfix A B C * *.
4.2.4. Macro (MAC)
A Macro (MAC) is an ordered collection of references to Controls or
other Macros. A Macro takes the form of a semantic typedef refining
an AC to be a list of ARIs referencing Controls or objects which
produce other Macros.
The execution procedure of an MAC is defined in Section 6.6.3.
Macros are used within an ADM for defining the action of a
State-Based Rule (SBR) or Time-Based Rule (TBR).
Birrane, et al. Expires 8 April 2024 [Page 30]
Internet-Draft DTNMA AMM/ADM October 2023
In cases where a Macro references another Macro, Agent
implementations MUST implement some mechanism for preventing infinite
recursions, such as defining maximum nesting levels, performing Macro
inspection, and/or enforcing maximum execution times.
4.2.5. Report Template (RPTT)
A Report Template (RPTT) is an ordered list of object references or
expression values used as a source for generating report
(Section 4.2.6) values. A RPTT takes the form of a semantic typedef
refining an AC to be a list of expressions or references to value-
producing objects. The object which produces an RPTT can itself be
parameterized so that the RPTT flows down parameters as described in
Section 3.1.2.1.
A RPTT can be viewed as a schema that defines how to generate and
interpret a Report; they contain no values and are either defined in
an ADM or configured between Managers and Agents in an ODM. Reports
themselves are ephemeral and not represented in the AMM object model
directly, see Section 4.2.6. The procedure for reporting on a RPTT
is defined in Section 6.8.2.
RPTT values SHOULD be used within a CONST where possible. RPTT
values MAY be used within a VAR where necessary. This makes
correlating a RPT value with its associated RPTT easier over time.
4.2.6. Report (RPT)
A Report (RPT) is an ordered list of data values populated in
conformance to a source object being reported on. Reports do not
have an individual identifier - rather they are uniquely identified
by their source and the timestamp at which their data values were
collected.
A RPT takes the form of a semantic typedef refining an AC to a
sequence of the following:
Source:
The source of the report in the form of an ARI with an object-
reference for one of the following types: CONST, EDD, VAR, or
CTRL. If the source was parameterized, this ARI SHALL contain the
actual parameters used at the time of reporting.
Generation Time:
The timestamp of the time at which the report items were sampled
in the form of an ARI containing a literal TP value.
Birrane, et al. Expires 8 April 2024 [Page 31]
Internet-Draft DTNMA AMM/ADM October 2023
Correlator:
Either a NONCE, if the report originated from an execution with a
correlator value, or the undefined value.
Items:
A list of ARIs corresponding to the source object, with
cardinality according to the following:
* For a VALUE-REF source the item list SHALL be the result of
reporting (Section 6.8.1) on that object.
* For a CTRL-REF source there SHALL be a single value
representing the Result of the execution. A result of
undefined indicates a failure executing the CTRL.
RPT values SHALL NOT be used directly within any value-producing
object. Values within a RPT are generated by an Agent during
reporting (Section 6.8).
4.2.7. Tabular Report (TBL)
A Tabular Report (TBL) is a collection of values which are logically
structured as a two dimensional table of rows and columns. Similar
to Report (RPT) values, tables are instantiated dynamically as part
of evaluation and not intended to be user-input.
Also similar to RPT values, a TBL can only be interpreted within the
context of a Tabular Report Template (TBLT) defined within an ADM.
The TBLT takes the form of a structured type definition on a value-
producing object which defines the columns of the table, including
each of their column names and types and optional constraints on the
number of rows in the TBL.
A TBL takes the form of a semantic typedef refining an AC to a
sequence of the following:
Column Count:
The number of columns in the associated TBLT. This is used to
interpret the flat list of table items that follow.
Items:
The items of the table flattened in row-major order. The number
of items is the product of the number of rows and columns in the
table.
TBL values SHOULD be used only within an EDD. Values within a TBL
are generated by an Agent during value production (Section 6.5).
Birrane, et al. Expires 8 April 2024 [Page 32]
Internet-Draft DTNMA AMM/ADM October 2023
4.3. Contents of an Agent ADM
While the DTNMA ADM described in Section 4.2 contains definitions of
static aspects of the AMM, the DTNMA Agent ADM is needed to include
necessary dynamic aspects of the operation of an Agent. This
separation is also helpful in order to allow the dynamic behaviors of
an Agent to be modified over time while the AMM definitions stay
stable and unchanging.
4.3.1. Agent State Introspection
The Agent ADM contains the following EDD objects used to introspect
the Agent's state, all of which can change over time.
* The ADMs supported by the Agent, including the unique name and
revision of each. By indicating specific revision and supported
feature set, the contained objects in each ADM can be derived.
Because of this, the ADM-contained objects do not require
additional introspection.
* The set of SBRs and TBRs in the Agent's ODMs, along with controls
to ensure a specific object is either present or absent. These
are all conditioned on whether the Agent actually supports the
built-in rule feature.
* The set of VARs in the Agent's ODMs, along with controls to ensure
a specific object is either present or absent.
4.3.2. Basic Operators
// TBD defining boolean, bitwise, and numeric operators
5. Operational Data Models (ODMs)
An ODM is a logical entity for containing AMM objects, similar to an
ADM (Section 4) but in an ODM the objects are not static. An ODM's
objects can be added, removed, and (with some restrictions) modified
during the runtime of an Agent. Like an ADM, each ODM exists as a
separate namespace for its contained objects and an Agent can contain
any number of ODMs.
Some object types, those which require implementation outside of the
Agent proper, are not available to be created in an ODM. These
include the CTRL, EDD, and OPER.
Birrane, et al. Expires 8 April 2024 [Page 33]
Internet-Draft DTNMA AMM/ADM October 2023
The actions for inspecting and manipulating the contents of an ODM
are available through EDDs and CTRLs of the Agent ADM
(Section 4.3.1).
6. Processing Activities
This section discusses logic and requirements for processing of AMM
objects and values. Each subsection is a separate class of
processing that is performed by an Agent.
A Manager (or any other entity) MAY perform some of the same
processing, _e.g._ evaluating an expression, in order to validate
values or configurations before sending them to an Agent. That kind
of behavior is effectively creating a "digital twin" of the managed
Agent to ensure that the processing will behave as expected before it
is sent. For this reason, the subject noun used in all of these
activities is the "processor".
6.1. Agent Initialization
The initialization of the Agent state can be associated with a power-
on event or, due to the use of volatile memory, can be an explicit
activity initiated from outside the Agent runtime. If volatile
memory is used the contents of the ODMs on an Agent will be present
for the initialization procedure; otherwise the ODMs will be
considered empty or absent.
The procedure to initialize an Agent is as follows:
1. All ADM-defined VAR objects SHALL have their value set to one of
the following:
* If an Initializer is defined for the VAR, the value is the
result of evaluating the associated Initializer expression and
then casting (Section 6.9) to the VAR type.
* Otherwise, the value is undefined.
Any ODM-defined VAR objects MAY retain their state.
2. All ADM-defined TBR and SBR objects SHALL have their Enabled
state set to the Initial Enabled value. Any ODM-defined TBR and
SBR objects MAY retain their Enabled state. Any rules which are
enabled are ready for processing.
Birrane, et al. Expires 8 April 2024 [Page 34]
Internet-Draft DTNMA AMM/ADM October 2023
6.2. ARI Resolving
Within an ADM, ARIs present in the various fields of object
definitions are URI References, which can take the form of Relative
URIs (see Section 4.2 of [RFC3986]). Any ARIs within an ADM
definition SHALL be handled as URI References and resolved in
accordance with the procedure of Section 5 of [RFC3986] with the
following used as a Base URI:
* For ARIs within a single AMM object definition, the non-
parameterized ARI of that object SHALL be the Base URI. This
includes ARIs used in nested structures under the object
definition; the object is the anchor point.
* For all other ARIs, the default Base URI ari:/ SHALL be the Base
URI. This means that all ARIs within an ADM _do not_ require a
URI scheme part.
6.3. Dereferencing
An object-reference value (Section 3.1.2) contains an identity and a
parameter part. Dereferencing an OBJ-REF uses the identity to look
up a specific defined object available to the agent.
The process of dereferencing a value is as follows:
1. The value has to contain an object reference. If the value is
not an object reference, this procedure stops and is considered
failed.
2. The OBJ-REF namespace (whether text or enumeration) is used to
search for a defined ADM or ODM namespace. A text form namespace
SHALL be compared within the UTF-8 character set in accordance
with [RFC3629]. An integer namespace SHALL be compared
numerically. If no corresponding namespace is available, this
procedure stops and is considered failed.
3. Within the namespace the object type and object name (whether
text or enumeration) is used to search for a specific defined
object. A text form object name SHALL be compared within the
UTF-8 character set in accordance with [RFC3629]. An integer
object name namespace SHALL be compared numerically. If no
corresponding object is available, this procedure stops and is
considered failed.
Birrane, et al. Expires 8 April 2024 [Page 35]
Internet-Draft DTNMA AMM/ADM October 2023
6.4. Parameter Handling
An object-reference value (Section 3.1.2) contains an identity and a
parameter part. The parameter part of an OBJ-REF represents the
actual parameters (Section 3.1.2.1) being used.
The process to validate and reconcile provided actual parameters
against an object's formal parameters is as follows:
1. If the object has formal parameters differing in size from the
actual parameters, this procedure stops and is considered failed.
2. For each actual parameter, the processor performs the following:
If the value is a TYPEDEF-REF and the value itself has a
parameter, the original value is replaced by the result of a type
cast (Section 6.9.3) on the parameter value. If the cast fails
this procedure stops and is considered failed.
3. For each correlated pair of single formal and actual parameter,
the processor performs the following:
1. If the actual parameter is undefined and the formal parameter
defines a default value, that default replaces the actual
parameter value.
If the actual parameter is still undefined, this procedure
stops and is considered failed. FIXME: should this pass
through without failure? That's the ECMAscript way.
2. The actual parameter is cast to the type of the formal
parameter in accordance with Section 6.9. If the cast fails,
this procedure stops and is considered failed.
An implementation MAY perform deferred "lazy" processing of any of
the above steps, causing a failure when the actual parameter value is
needed. One caveat about deferred validation is that it will not
fail if the parameter is unused, which is not necessarily a problem
but could mask other issues in whatever generated the parameters.
6.5. Value Production
Value production can be thought of as a common behavior used for
Execution, Evaluation, and Reporting activities. Within the AMM the
following entities have a value production procedure: CONST, EDD, and
VAR object references.
Birrane, et al. Expires 8 April 2024 [Page 36]
Internet-Draft DTNMA AMM/ADM October 2023
6.5.1. CONST and VAR References
Both CONST and VAR objects act as a store of a single literal value
within the Agent. Formal parameters on either CONST or VAR objects
are applicable only when the objects store a value which itself
contains parameters with at least one LABEL type.
The value production for these are as follows:
1. The processor dereferences the OBJ-REF in accordance with
Section 6.3. If the dereference fails, this procedure stops and
is considered failed.
2. The processor verifies that the OBJ-REF actual parameters, if
any, are consistent with the formal parameters of the object from
which production is requested in accordance with Section 6.4.
For this procedure it is consistent to have no actual parameters
but defined formal parameters, that case is handled below. If
there is inconsistency, this procedure stops and is considered
failed.
3. When no actual parameters are present (regardless of formal
parameters), the stored value is considered to be the produced
value and this procedure is complete.
When actual parameters are present, the the stored value is
augmented into the produced value by:
1. Substituting any LABEL actual parameters in the value,
recursively in the case of a collection (Section 3.2.2)
value. This augmentation has no effect on the stored value,
it occurs only in the produced value.
2. It is valid for an actual parameter to have no substitution
occur, but it is not valid for a LABEL in the value to not
have a corresponding actual parameter and in such case this
procedure stops and is considered failed.
6.5.2. EDD References
For EDD object references, the actual parameters are used by the
underlying implementation to produce the value in an arbitrary way.
The produced value is typically either a SIMPLE (Section 4.2.2) value
or a Tabular Report (Section 4.2.7).
The value production for these are as follows:
Birrane, et al. Expires 8 April 2024 [Page 37]
Internet-Draft DTNMA AMM/ADM October 2023
1. The processor dereferences the OBJ-REF in accordance with
Section 6.3. If the dereference fails, this procedure stops and
is considered failed.
2. The processor verifies that the OBJ-REF actual parameters, if
any, are consistent with the formal parameters of the object from
which production is requested in accordance with Section 6.4. If
there is inconsistency, this procedure stops and is considered
failed.
3. The processor passes the execution on to the underlying
implementation of the EDD or TBLT being produced from.
The context given to the implementation is the following:
Object Identity:
This gives visibility into the OBJ-REF which was dereferenced
during the production.
Parameters:
The set of actual parameters augmented for the production.
Result Storage:
The result of the production is placed here before completion.
The initial state of the Result Storage is the undefined value.
It is an implementation matter and author consideration
(Section 8) to enforce that the produced value is consistent with
the type of the object.
6.6. Execution
Within the AMM only two entities have an execution procedure:
controls and macros. Controls are executed by reference, while
macros are executed both by value and by reference.
6.6.1. Value-Producing Object References
The execution of a VALUE-REF (Section 4.2.2) producing a value of any
type is as follows:
1. The value is produced from the OBJ-REF in accordance with
Section 6.5. This step includes substitution of any LABEL
parameters within the value.
2. If the value is an MAC (Section 4.2.4) type, this value is
executed in accordance with Section 6.6.3.
Birrane, et al. Expires 8 April 2024 [Page 38]
Internet-Draft DTNMA AMM/ADM October 2023
Otherwise, the execution is considered failed.
6.6.2. CTRL References
The execution of an OBJ-REF referencing a Control (CTRL) is as
follows:
1. The processor dereferences the OBJ-REF in accordance with
Section 6.3. If the dereference fails, this procedure stops and
is considered failed.
2. The processor verifies that the OBJ-REF actual parameters, if
any, are consistent with the formal parameters of the CTRL being
executed in accordance with Section 6.4. If there is
inconsistency, this procedure stops and is considered failed.
3. The processor passes the execution on to the underlying
implementation of the CTRL being executed.
The context given to the implementation is the following:
Manager:
The manager which directly caused this execution, if
available, is provided as context.
Object Identity:
This gives visibility into the OBJ-REF which was dereferenced
during the execution.
Parameters:
The set of actual parameters augmented for the execution.
Result Storage:
The result of the execution is placed here before completion.
The initial state of the Result Storage is taken from the default
result the CTRL, if defined, or null otherwise.
If the execution procedure fails, the result value SHALL be treated
as the undefined value for the purposes of any subsequent reporting.
6.6.3. MAC Values
The execution of a Macro (MAC) value, which is structured as an AC,
is as follows:
Birrane, et al. Expires 8 April 2024 [Page 39]
Internet-Draft DTNMA AMM/ADM October 2023
1. The processor iterates through all items of the AC recursively,
replacing any VALUE-REF with their value produced in accordance
with Section 6.5. If any dereference fails this procedure stops
and is considered failed.
2. From this point on the AC contains only CTRL-REF values or nested
AC with CTRL-REF. The processor iterates through all items of
the AC recursively, in depth-first order, and performs the
following:
If the item is an CTRL-REF it is executed in accordance with
Section 6.6.2. If the execution fails, this procedure stops and
is considered failed.
Otherwise, this procedure stops and is considered failed.
One effect of this procedure is that if any referenced MAC values
cannot be produced the procedure fails before any CTRL is executed.
Another effect of this procedure is that if any referenced CTRL fails
during execution the processing fails immediately and subsequent
CTRLs or MACs are not executed.
| The Base ADM (Section 4.3) includes a wrapper CTRL "catch"
| which is used to ignore possible failures of specific
| executions and allow MAC processing to continue.
6.7. Evaluation
Within the AMM the following entities have an evaluation procedure:
references to value-producing objects, OPERs, and TYPEDEFs and and
EXPR values.
For the purposes of these procedures, it is important to distinguish
between an EXPR _value_ and a reference to a value-producing object
which is typed to produce an EXPR value.
6.7.1. Value-Producing Object References
The evaluation of a VALUE-REF (Section 4.2.2) producing a value of
any type is as follows:
1. The value is produced from the OBJ-REF in accordance with
Section 6.5. This step includes substitution of any LABEL
parameters within the value.
2. If the value is an EXPR (Section 4.2.3) type, this value is
considered to be a sub-expression and is evaluated in accordance
with Section 6.7.4.
Birrane, et al. Expires 8 April 2024 [Page 40]
Internet-Draft DTNMA AMM/ADM October 2023
Otherwise, the produced value is considered to be the evaluation
result.
6.7.2. OPER References
This procedure applies only during the evaluation of a containing
expression (Section 6.7.4); an OPER cannot be evaluated in isolation.
The evaluation of an OBJ-REF referencing a Operator (OPER) is as
follows:
1. The processor verifies that the actual parameters, if any, are
consistent with the formal parameter associated with the OPER
being evaluated. If there is inconsistency, this procedure stops
and is considered failed.
2. The processor passes the evaluation on to the underlying
implementation of the OPER being evaluated.
The context available to the implementation is the following:
Object Identity:
This gives visibility into the OBJ-REF which was dereferenced
during the evaluation.
Parameters:
The set of actual parameters augmented for the evaluation.
Expression Stack:
The operands are popped from this stack and the result is
pushed here before completion.
If the evaluation procedure fails, the failure SHALL propagate up to
any expression evaluation.
6.7.3. TYPEDEF References
This procedure applies only during the evaluation of a containing
expression (Section 6.7.4); a TYPEDEF cannot be evaluated in
isolation. The evaluation of a TYPEDEF reference is handled
similarly to a unary OPER but it occurs entirely within the Agent and
does not rely on an object-specific implementation.
The evaluation of an OBJ-REF referencing a Semantic Type Definition
(TYPEDEF) is as follows:
Birrane, et al. Expires 8 April 2024 [Page 41]
Internet-Draft DTNMA AMM/ADM October 2023
1. If the TYPEDEF-REF itself has no parameters, the input value is
popped from the stack. If the TYPEDEF-REF itself has one
parameter, the input value is that parameter. If the TYPEDEF-REF
itself has more than parameter, this procedure stops and is
considered failed.
2. The result value is a type cast (Section 6.9.3) on the input
value. If the cast fails this procedure stops and is considered
failed.
3. The result value is pushed onto the stack.
6.7.4. EXPR Values
The evaluation of an Expression (EXPR) value, which is structured as
an AC, is as follows:
1. An empty value stack is initialized for this evaluation.
2. For each item of the AC, recursively, the processor performs the
following:
If the value is a VALUE-REF, the original value is replaced by
the value produced in accordance with Section 6.5. If the
production fails this procedure stops and is considered failed.
3. From this point on the AC is treated as a Reverse Polish Notation
(RPN) sequence, where the following is performed on each item in
the AC in sequence:
If the item is an OPER-REF it is evaluated in accordance with
Section 6.7.2. If the evaluation fails, this procedure stops and
is considered failed.
Otherwise, the item is pushed onto the stack.
4. If the value stack is empty or has more than one item, this
procedure stops and is considered failed. Otherwise, the result
of the evaluation is the single literal value in the stack.
One effect of this procedure is that if any referenced values cannot
be produced the procedure fails before any OPER is evaluated.
Another effect of this procedure is that if any referenced OPER fails
during evaluation or any value production fails the EXPR processing
fails immediately and subsequent OPER-REFs, EXPRs, or VALUE-REF
references are not evaluated.
Birrane, et al. Expires 8 April 2024 [Page 42]
Internet-Draft DTNMA AMM/ADM October 2023
6.8. Reporting
Within the AMM the following entities have a reporting context:
CONST, EDD, and VAR objects and RPTT values. The value-producing
objects are reported-on by reference, while RPTT are reported-on both
by value and by reference.
6.8.1. Value-Producing Object References
The reporting on a VALUE-REF (Section 4.2.2) producing a value of any
type is as follows:
1. The value is produced from the OBJ-REF in accordance with
Section 6.5. This step includes substitution of any LABEL
parameters within the value.
2. If the value is an RPTT (Section 4.2.5) type, this value is used
to generate report items in accordance with Section 6.8.2.
Otherwise, the produced value is used as the single RPT item.
3. The RPT value (Section 4.2.6) is produced by combining: the
source ARI used for this procedure, the current timestamp, and
the items generated in the previous step.
6.8.2. RPTT Values
The reporting on a Report Template (RPTT) value, which is structured
as an AC, is as follows:
1. An empty item list is initialized for this template.
2. The processor iterates through all items of the AC, performing
the following:
If the item is an EXPR value it is replaced by the result of
evaluation in accordance with Section 6.7. If the evaluation
fails the undefined value is used as a substitute.
Otherwise, if the item is a VALUE-REF it is replaced by the value
produced in accordance with Section 6.5. If the production fails
the undefined value is used as a substitute.
Otherwise, the result of the production is the value appended to
the item list.
Birrane, et al. Expires 8 April 2024 [Page 43]
Internet-Draft DTNMA AMM/ADM October 2023
Because this procedure acts on an RPTT value and not an object
reference, the report itself cannot be assembled within this context.
One effect of this procedure is that if any item of the RPTT cannot
be reported on, the undefined value is used as a sentinel and the
other report items are still generated.
6.9. Type Casting
The type system of the AMM allows conversions of values between
different literal and semantic types in a way which is supposed to
preserve the "meaning" of the value.
In some cases, casting is performed implicitly by the Agent while
other cases the casting is explicitly part of an expression. One
example of implicit casting is during Parameter Handling to ensure
each processed parameter meets the formal parameter type signature.
Another example of implicit casting is for numeric operators in the
Agent ADM (Section 4.3.2).
6.9.1. BOOL Type
The AMM has the concepts of "truthy" and "falsey" as being the result
of casting to BOOL type. Similar to the ToBoolean() function from
[ECMA-262], the AMM casting treats the following as falsey and every
other value as truthy:
* undefined
* null value of NULL
* false value of BOOL
* Zero value of BYTE, UINT, INT, UVAST, and VAST
* Positive and negative zero, and NaN values of REAL32 and REAL64
* Empty value of TEXTSTR and BYTESTR
When casting a value to BOOL type, the processor SHALL use the result
value false if the original value is falsey and true otherwise.
6.9.2. NUMERIC Types
The casting of a value to a NUMERIC type is intended to easily allow
mixed-type expressions while keeping the number of operators and
parameter unions small.
Birrane, et al. Expires 8 April 2024 [Page 44]
Internet-Draft DTNMA AMM/ADM October 2023
When casting a value to an INTEGER type from any other NUMERIC type,
the processor SHALL perform the following:
1. If the input is one of the FLOAT types and is not finite, the
cast is considered failed.
2. If the input is one of the FLOAT types, the value is truncated to
an integer by rounding toward zero.
3. If the input value is outside the domain of the output type, the
cast is considered failed.
When casting a value to an FLOAT type from any other NUMERIC type,
the processor SHALL perform the following:
1. If the input value is outside the domain of the output type, the
cast is considered failed.
6.9.2.1. Numeric Promotion
While the earlier discussion of numeric type casting is about
converting from an input type to an output type, the concept of a
type promotion is about finding a "least compatible type" which can
accommodate most, if not all, of the input type range. Casting to a
promoted type is called an "up" cast, and from a promoted type a
"down" cast.
The promotion order for NUMERIC types is as follows:
* A promoted type has a larger span of values (the difference
between largest and smallest representable value).
* A promoted type can gain signed-ness but not lose it.
* A promoted type can lose precision for some values.
This promotion logic does not guarantee that an up-cast will always
succeed (_e.g._ some large UVAST values will not fit within a VAST or
REAL32) but does provide a strict ordering for finding a compatible
type between two NUMERIC values. The "least compatible type" between
two types SHALL be defined as the smallest up-cast that will
accommodate the input types, as indicated in Table 4. This is almost
a strict ordering except for the cast of INT and UVAST to VAST to
accommodate both the signed-ness and the size of the inputs.
Birrane, et al. Expires 8 April 2024 [Page 45]
Internet-Draft DTNMA AMM/ADM October 2023
+========+======+======+=====+=======+======+========+========+
| | BYTE | UINT | INT | UVAST | VAST | REAL32 | REAL64 |
+========+======+======+=====+=======+======+========+========+
| BYTE | BYTE | UINT | INT | UVAST | VAST | REAL32 | REAL64 |
+========+------+------+-----+-------+------+--------+--------+
| UINT | | UINT | INT | UVAST | VAST | REAL32 | REAL64 |
+========+------+------+-----+-------+------+--------+--------+
| INT | | | INT | VAST | VAST | REAL32 | REAL64 |
+========+------+------+-----+-------+------+--------+--------+
| UVAST | | | | UVAST | VAST | REAL32 | REAL64 |
+========+------+------+-----+-------+------+--------+--------+
| VAST | | | | | VAST | REAL32 | REAL64 |
+========+------+------+-----+-------+------+--------+--------+
| REAL32 | | | | | | REAL32 | REAL64 |
+========+------+------+-----+-------+------+--------+--------+
| REAL64 | | | | | | | REAL64 |
+========+------+------+-----+-------+------+--------+--------+
Table 4: NUMERIC Type Promotion
6.9.3. Semantic Types
Unlike literal type casting, which has the potential to change the
form of the value itself, casting to a semantic type is meant to
either affirm or add an association between an AMM value and a
TYPEDEF object. All of this processing is performed independently of
any literal-type-specific handling, so none of it needs to be
specialized to specific TYPEDEF objects.
The cast of an input value to a TYPEDEF is as follows:
1. The underlying literal types usable with a TYPEDEF are obtained
by recursively flattening the TYPEDEF union(s) down to literal
types and removing duplicate literal types after the first
instance of them. This defines a priority list of acceptable
literal types for the result. Because a TYPEDEF union is
unchanging within an ADM (see Section 3.4.2) a processor MAY
cache this flattened type list.
2. The input value is cast to each literal type in the list, and the
first successful cast is taken as the literal type of the result
value. If none of the literal types can successfully cast the
input value, this procedure stops and is considered failed.
3. The result value is associated with the the TYPEDEF being cast
to, and that is the result of this procedure.
Birrane, et al. Expires 8 April 2024 [Page 46]
Internet-Draft DTNMA AMM/ADM October 2023
| Because the processing in Step 2 could successfully match
| multiple literal types for an input value, the ordering of that
| list (and thus the ordering of the union members which
| flattened to produce that list) is significant.
6.10. Translating ARIs and Semantic Types
The procedures in this section allow AMM values, which can have a
semantic type (Section 3.3), to be translated into and out of the ARI
syntax (Section 3.1.3), which has no semantic type information. They
also describe a way to use type-less literal values to give further
compression of values in certain circumstances.
The compression of removing type information is possible only when
the context in which the value is being used has a specific semantic
or literal type associated with it. For example, when a formal
object parameter or a report item is typed to either a literal type
or a semantic type that doesn't represent a type union then a value
being used for the parameter or item can only have that specific
type; any other value type will be mismatched and invalid. Another
way of looking at this compression is when the value has the same
type as its context requires, then the value's type is redundant and
can be elided without loss of information.
In addition to compression by eliding semantic type within a context,
there are also some literal types which have values which only exist
in that type. For example, the BOOL value true exists only within
that type while the UINT value 5 is also within the domain of INT and
several others.
For the procedures below, the contexts which provide type information
SHALL be: all formal parameters, VALUE-REF values, report template
items, tabular columns.
When translating from an AMM value into an ARI, the processor
performs the following:
1. If the use context is associated with a TYPEDEF and the value is
associated with an ambiguous or incompatible TYPEDEF, the ARI
form SHALL be wrapped in a TYPEDEF-as-cast ARI. An ambiguous
type is one where the presence of the inner type cast produces a
different result than if the cast were absent. An incompatible
type is one where the presence of the inner cast results in a
failure of the outer cast.
Birrane, et al. Expires 8 April 2024 [Page 47]
Internet-Draft DTNMA AMM/ADM October 2023
2. If the use context is associated with a single literal type (no
unions) and the literal type is present in Table 2 "Literal
Implied Types" of [I-D.birrane-dtn-ari], the ARI form MAY have
its literal type removed.
When translating from an ARI into an AMM value, the processor
performs the following:
1. If the use context is associated with a type and the value is
associated with a different TYPEDEF or no TYPEDEF, the value
SHALL be cast to the context type in accordance with Section 6.9.
7. ADM Module Syntax
This section provides an ADM syntax in the form of a YANG module
conforming to a profile of [RFC7950] with AMM-specific extensions.
It is not required that this encoding be used for transmission of ADM
information over the wire in the context of a network deployment.
Since the AMM is designed to allow for multiple encodings, the
expression of ADMs in YANG syntax is intended to support translation
to other encodings without loss of information.
Some aspects of this ADM module profile restrict the allowable
definitions to conform with Section 3.4 and by doing so make YANG
modules defining ADMs incompatible with YANG modules intended for
NETCONF, RESTCONF, or other applications. Because of this, YANG
modules defining ADMs SHALL be managed separately from the "YANG
Module Names" sub-registry of [IANA-YANG]. See the ADM sub-registry
defined in Section 9.3 of [I-D.birrane-dtn-ari] for registration of
ADM modules. For the remainder of this section, a YANG module
defining an ADM will be referred to as an "ADM module" and a YANG
module for any other purpose will be referred to as a "Legacy module"
to differentiate it.
| Because the YANG syntax and data modeling language are closely
| coupled, there is no pre-existing example of using YANG for its
| syntax (and its module infrastructure) while using different
| domain-specific language (DSL) of extensions for data modeling.
| Separating the syntax from the data modeling is similar in
| concept to making use of ASN.1 syntax of [X.680] without using
| the SMIv2 data modeling language [RFC2578], which is how
| unrelated things like certificate profile of X.509 [RFC5280]
| use ASN.1 module syntax.
|
Birrane, et al. Expires 8 April 2024 [Page 48]
Internet-Draft DTNMA AMM/ADM October 2023
| One way of thinking of this is that the ADM modules use a
| syntax that has "YANG characteristics" but does not make use of
| all YANG tooling or infrastructure and do not interoperate with
| existing YANG modules.
After explanation of extensions in Section 7.3, the following minimal
ADM module will be expanded upon for further examples.
<CODE BEGINS> file "example-adm.yang"
module example-adm {
yang-version 1.1;
namespace "ari:/example-adm";
prefix example-adm;
import ietf-amm {
prefix amm;
}
organization "Example Org.";
description "Example module.";
amm:enum "4294967296";
}
<CODE ENDS>
7.1. Inherited YANG Module Processing
The benefit of using the pre-existing YANG syntax is to take
advantage of both tools that process YANG modules as well as some of
the syntax and module-level semantics provided by YANG.
7.1.1. Direct Reuse
The following statements and behaviors of YANG are usable within an
ADM with no modification:
Modules and Submodules: The existing concepts and syntax of modules
and submodules defined in Section 5.1 of [RFC7950] is unchanged
for ADM modules. Because ADM modules occupy a separate ecosystem
than Legacy modules, there will not be any cross-imports between
the two ecosystems. There is no harm in including an ADM module
in a Legacy module store, but it will have no data definitions
usable with NETCONF, RESTCONF, _etc._
Module Importing: The existing concept and syntax of importing a
Birrane, et al. Expires 8 April 2024 [Page 49]
Internet-Draft DTNMA AMM/ADM October 2023
module namespace, to reference objects in the other module,
defined in Section 5.1.1 of [RFC7950] is unchanged for ADM
modules. Because the import includes a specific revision, the ARI
references to objects in that other module do not need any ADM
revision information.
File Layout: The existing file naming defined in Section 5.2 of
[RFC7950] is unchanged for ADM modules. Because ADM modules
occupy a separate ecosystem than Legacy modules, their file stores
SHALL be kept separate.
Namespaces: Although an ADM module has no use for an XML namespace
as defined in Section 5.3 of [RFC7950], the "namespace" statement
is preserved for tool compatibility. For ADM modules, the
"namespace" statement argument SHALL be the text-form ARI
referencing the ADM itself. For example, the ADM "example-adm"
will have a namespace of ari:/example-adm which is valid YANG.
Name Resolution: The existing name resolution logic described in
Section 5.4 of [RFC7950] is unchanged for ADM modules. Because
ADM modules are a flat object namespace, the complexity of
namespaces is significantly simplified compared to Legacy modules.
Reusable Groups: The existing group reuse logic described in
Section 4.2.6 of [RFC7950] is unchanged for ADM modules. Because
ADM modules are a flat object namespace, the utility of group
reuse in an ADM module is limited to formal parameters, VALUE-REF
definitions, and table columns.
7.1.2. Restrictions and Exclusions
Because of the different interpretation of data definitions for an
ADM module, the following restrictions are used to limit pre-existing
valid YANG syntax within an ADM module:
Built-In Types: Because ADM modules have data that ultimately
follows the AMM value (Section 3.1) model, the built-in types
listed in Section 4.2.4 of [RFC7950], the "type" statement of
Section 7.4 of [RFC7950], and the "typedef" statement of
Section 7.3 of [RFC7950] do not directly apply to ADM modules. As
defined in this document, there is no direct deterministic mapping
between Legacy module typing and ADM module typing. An ADM module
SHALL NOT contain any YANG built-in type or any "type" or
"typedef" statements.
Data Node Structure: As defined in this document, there is no direct
Birrane, et al. Expires 8 April 2024 [Page 50]
Internet-Draft DTNMA AMM/ADM October 2023
deterministic mapping between the complex, hierarchical, named
data nodes of YANG and unnamed AMM values. An ADM module SHALL
NOT contain any YANG data node statements, among them "container",
"leaf", "leaf-list", "list", "anydata", "anyxml", "choice".
Configuration Versus State: Because of the different semantics of an
ADM module from a Legacy module, there is no concept of a labeling
of some data as "configuration" and other as "state". An ADM
module SHALL NOT contain any "config" statements.
Data Presence Versus Value: Rather than being an extrinsic notion of
presence or absence, AMM objects can use type unions with the NULL
type to indicate optional values and AMM values can use the null
value to represent that state. In the case of formal parameters,
the use of a "default" statement is used to indicate behavior when
an actual parameter is undefined. In any case, the AMM value is
always present when defined in the structure of an AMM object. An
ADM module SHALL NOT contain any "mandatory" statements.
Nested Object Definitions: Because of the flat structure of an ADM,
the nesting allowed and encouraged by Section 5.5 of [RFC7950],
are not allowed to be present in an ADM module. An ADM module
SHALL contain all AMM object definitions at the top (module)
level.
XPath Expressions: The ADM module makes no use of XML or XPath in
its definitions or logical constraints, so the behaviors described
in Section 6.4 of [RFC7950] and in statements containing XPath
expressions ("must", "when", "path", "augment") do not apply to
ADM modules. All references in an ADM module take the form of an
ARI.
NETCONF Operations: Because an ADM module will not be used for
modeling in NETCONF and related protocols, the statements
associated with NETCONF operations (notably "action",
"notification", "rpc") SHALL NOT be present in an ADM module.
Extending Models: Because the transport of AMM values takes the form
of an ARI, which does not include identity information the way XML
elements do, the concept of extending an existing Legacy model by
another model as described in Section 4.2.8 of [RFC7950] cannot
apply to an ADM. The model extension "augment" statement SHALL
NOT be present in an ADM module.
Birrane, et al. Expires 8 April 2024 [Page 51]
Internet-Draft DTNMA AMM/ADM October 2023
7.2. AMM Types, Typedefs, and Type Uses
As discussed in Section 7.1.2, the YANG type and node models are
fundamentally different from the AMM value model of Section 3.1.
While YANG modules have been used to model data for XML
representation for NETCONF (or equivalent representations for
equivalent protocols), AMM values do not have explicit identifiers.
7.2.1. Built-In AMM Types
The built-in types of the AMM are "Literal Types" and "Managed Object
Types" sub-registries of [IANA-DTNMA]. These lists of type names is
not fixed, but does require standards action to add to and updates to
URI processors to handle, so it is expected that this list will be
relatively static (compared to the expected rate of addition or
changes to ADMs).
Similar to how YANG treats built-in types, the AMM literal and object
type names are used without any namespace context.
7.2.2. Type Uses
There are a number of extensions defined in Section 7.3 related to
how AMM types and type definitions are used by object definitions.
These include the following purposes.
Simple Type Use: The simplest case is where an existing type is used
directly and unchanged. This is a "type" statement
(Section 7.3.2.1) with no substatements.
Simple Restriction: Beyond the simple type use, restrictions and
annotations can be added to an existing type This is a "type"
statement (Section 7.3.2.1) with substatements to restrict or
annotate it.
Uniform List: This is the case of a list of AMM values within an AC
where the type of each value is uniform for the whole list. This
is a "ulist" statement (Section 7.3.2.2) with substatements to
establish the list contents.
Diverse List: This is the case of a list of AMM values within an AC
where the type of each value is different throughout the list.
Some of the values can be repeated a fixed or variable number of
times. This is a "dlist" statement (Section 7.3.2.3) with
substatements to establish the list contents.
Table Template: This is the case of a list of AMM values within an
Birrane, et al. Expires 8 April 2024 [Page 52]
Internet-Draft DTNMA AMM/ADM October 2023
AC where the values are interpreted as rows and columns of a
table. The number of columns is fixed and the number of rows
present in any particular table instance is variable (but possibly
bounded by restriction). This is a "tblt" statement
(Section 7.3.2.4) with substatements to establish the column
schema, uniqueness criteria, and sorting.
Type Union: This creates a choice between a combination of other
type uses. Each of the type uses in a union SHOULD be exclusive
to avoid ambiguity in interpretation by a value processor. This
is a "union" statement (Section 7.3.2.5) with substatements to
establish the type uses being combined.
7.2.3. Type Definitions
A type definition is a way for an ADM to apply a name and descriptive
metadata to a specific type use (see Section 7.2.2). The type
definition (TYPEDEF) is also a top-level ADM object, as explained in
Section 3.4.2 with a syntax in Section 7.3.4.
An imported module "prefix" and object name of a TYPEDEF can be used
wherever a type name is needed by one of the type uses. The syntax
for this is the same as for YANG types and uses, where the prefix and
typedef name are joined by a colon (":"). For example, importing a
module with a prefix of "mod" containing a typedef "mytype" is used
by the type name:
mod:mytype
Except for the case of a simple "type" with no restrictions or
annotations, where one of the type uses occurs in an object
definition can be considered as an "anonymous" TYPEDEF. The behavior
in those cases is identical to a TYPEDEF just without a name
associated with the type use.
7.3. ADM Module Extensions
In order to provide syntax necessary for AMM Objects definitions this
document defines, via the DTNMA ADM (Appendix A), the following
extensions for ADM modules.
7.3.1. The amm:enum Statement
This statement is used to apply an integer enumeration to an ADM
module or object, which enables the compressed form of ARI discussed
in Section 3.1 of [I-D.birrane-dtn-ari]. The argument to this
statement is an integer in the YANG range 0..2^31-1 to fit within the
ARI syntax. There are no substatements defined in this profile.
Birrane, et al. Expires 8 April 2024 [Page 53]
Internet-Draft DTNMA AMM/ADM October 2023
7.3.2. Type Use Statements
The statements within this section enable the various type uses as
explained in Section 7.2.2. They are all used as substatements
within one of the AMM object definition statements, sometimes
directly (_e.g._, for CONST or EDD typing) and sometimes indirectly
(_e.g._, for parameter or operand typing), but always as a choice
between the need for one of the type use statements.
7.3.2.1. The amm:type Statement
This statement creates a simple type use by its parent statement.
The argument to this statement is the name of the type being used,
which can either be a built-in type or a qualified typedef name.
The substatements under this are restrictions on the type being used.
+==============+=============+==============================+
| Substatement | Cardinality | Valid for These Types |
+==============+=============+==============================+
| units | 0..1 | NUMERIC |
+--------------+-------------+------------------------------+
| range | 0..1 | INTEGER or FLOAT with |
| | | appropriate quantized values |
+--------------+-------------+------------------------------+
Table 5: amm:typedef Substatements
Examples of the "type" statement are below, some as simple use and
some as restriction.
amm:type uint;
amm:type units {
range "3..10";
units "meter";
}
amm:type textstr {
length "10..100";
}
7.3.2.2. The amm:ulist Statement
This statement creates a structured AC with identical type use in
each of its items. There is no argument to this statement.
Birrane, et al. Expires 8 April 2024 [Page 54]
Internet-Draft DTNMA AMM/ADM October 2023
+==============+=============+
| Substatement | Cardinality |
+==============+=============+
| amm:type | 1 |
+--------------+-------------+
| min-elements | 0..1 |
+--------------+-------------+
| max-elements | 0..1 |
+--------------+-------------+
Table 6: amm:ulist
Substatements
Examples of the "ulist" statement are below, some as simple use and
some as restriction.
amm:ulist {
amm:type uint;
}
amm:ulist {
amm:type uint {
range "3..10";
units "meter";
}
min-elements 2;
max-elements 10;
}
7.3.2.3. The amm:dlist Statement
This statement creates a structured AC with diverse type use among
each of its items. There is no argument to this statement.
+==============+=============+
| Substatement | Cardinality |
+==============+=============+
| amm:type | 0..n |
+--------------+-------------+
| amm:seq | 0..n |
+--------------+-------------+
Table 7: amm:ulist
Substatements
Examples of the "dlist" statement are below, one as simple structure
and the other as a complex sequence.
Birrane, et al. Expires 8 April 2024 [Page 55]
Internet-Draft DTNMA AMM/ADM October 2023
amm:dlist {
// each "type" substatement is one element of the AC
amm:type uint;
amm:type uint;
}
amm:dlist {
amm:seq {
min-elements 2;
max-elements 10;
}
}
7.3.2.4. The amm:tblt Statement
This statement defines the structure of tabular data values. There
is no argument to this statement.
The substatements are a combination of "column" statements defining
table structure and "amm:key", "amm:unique", "min-elements", "max-
elements" statements defining constraints on the table rows.
+==============+=============+
| Substatement | Cardinality |
+==============+=============+
| reference | 0..1 |
+--------------+-------------+
| description | 0..1 |
+--------------+-------------+
| amm:column | 0..n |
+--------------+-------------+
| amm:key | 0..1 |
+--------------+-------------+
| amm:unique | 0..n |
+--------------+-------------+
Table 8: amm:union
Substatements
Examples of the "tblt" statement are below, some as simple use and
some as restriction.
Birrane, et al. Expires 8 April 2024 [Page 56]
Internet-Draft DTNMA AMM/ADM October 2023
amm:tblt {
amm:column first {
amm:type uint;
}
amm:column second {
amm:type textstr;
}
amm:key first;
}
7.3.2.4.1. The amm:column Statement
This statement defines the name and type of each column of a table.
The argument to this statement is an identifier for the column. All
columns SHALL have unique names within the same parent table.
The substatements under this are one of the type use statements
(Section 7.3.2) which defines the type for values in this column.
The type of a column SHALL NOT itself use a "tblt" or a union which
contains a "tblt".
+==============+=============+
| Substatement | Cardinality |
+==============+=============+
| reference | 0..1 |
+--------------+-------------+
| description | 0..1 |
+==============+=============+
| One of the type uses: |
+==============+=============+
| amm:type | 0..1 |
+--------------+-------------+
| amm:ulist | 0..1 |
+--------------+-------------+
| amm:dlist | 0..1 |
+--------------+-------------+
| amm:umap | 0..1 |
+--------------+-------------+
| amm:union | 0..1 |
+--------------+-------------+
Table 9: amm:column
Substatements
7.3.2.5. The amm:union Statement
This statement defines a choice between a combination of other type
uses. There is no argument to this statement.
Birrane, et al. Expires 8 April 2024 [Page 57]
Internet-Draft DTNMA AMM/ADM October 2023
Each of the substatements defines one of the possible choices of the
union.
+==============+=============+
| Substatement | Cardinality |
+==============+=============+
| amm:type | 0..n |
+--------------+-------------+
| amm:ulist | 0..n |
+--------------+-------------+
| amm:dlist | 0..n |
+--------------+-------------+
| amm:tblt | 0..n |
+--------------+-------------+
| amm:umap | 0..n |
+--------------+-------------+
Table 10: amm:union
Substatements
Examples of the "union" statement are below, some as simple use and
some as restriction.
amm:ulist {
amm:type uint;
}
amm:ulist {
amm:type uint {
range "3..10";
units "meter";
}
min-elements 2;
max-elements 10;
}
7.3.3. The amm:parameter Statement
This statement is used to define one formal parameter that apply to
the parent object. The argument to this statement is an identifier
for the parameter. All parameters SHALL have unique names within the
same parent object.
The substatements under this are one of the type use statements
(Section 7.3.2) which defines the type of the parameter.
Birrane, et al. Expires 8 April 2024 [Page 58]
Internet-Draft DTNMA AMM/ADM October 2023
+==============+=============+
| Substatement | Cardinality |
+==============+=============+
| reference | 0..1 |
+--------------+-------------+
| description | 0..1 |
+--------------+-------------+
| amm:default | 0..1 |
+==============+=============+
| One of the type uses: |
+==============+=============+
| amm:type | 0..1 |
+--------------+-------------+
| amm:ulist | 0..1 |
+--------------+-------------+
| amm:dlist | 0..1 |
+--------------+-------------+
| amm:tblt | 0..1 |
+--------------+-------------+
| amm:umap | 0..1 |
+--------------+-------------+
| amm:union | 0..1 |
+--------------+-------------+
Table 11: amm:parameter
Substatements
An example of the "parameter" statement is below, where there are
three defined parameters two of which have default values.
amm:parameter first {
amm:type uint {
range "3..10";
}
}
amm:parameter second {
amm:type textstr;
default "\"value\"";
}
amm:parameter third {
amm:ulist {
amm:type uint;
}
default "/AC/(3,5,8)"
}
Birrane, et al. Expires 8 April 2024 [Page 59]
Internet-Draft DTNMA AMM/ADM October 2023
7.3.3.1. The amm:default Statement
This statement is used to define default parameter or CTRL and OPER
result state as an AMM value. The argument to this statement is the
text form of the ARI encoding the expression.
The Parameter Handling procedure when used under a parameter, the
Execution procedure when used under a CTRL result, and Evaluation
when used under an OPER result.
7.3.4. The amm:typedef Statement
This statement is used to define a Semantic Type Definition (TYPEDEF)
object. The argument to this statement is the name of the AMM
object.
The substatements under this are a choice of the type use (see
Section 7.2.2) being named by the typedef.
Birrane, et al. Expires 8 April 2024 [Page 60]
Internet-Draft DTNMA AMM/ADM October 2023
+==============+=============+
| Substatement | Cardinality |
+==============+=============+
| if-feature | 0..1 |
+--------------+-------------+
| amm:enum | 0..1 |
+--------------+-------------+
| status | 0..1 |
+--------------+-------------+
| reference | 0..1 |
+--------------+-------------+
| description | 0..1 |
+==============+=============+
| One of the type uses: |
+==============+=============+
| amm:type | 0..1 |
+--------------+-------------+
| amm:ulist | 0..1 |
+--------------+-------------+
| amm:dlist | 0..1 |
+--------------+-------------+
| amm:tblt | 0..1 |
+--------------+-------------+
| amm:umap | 0..1 |
+--------------+-------------+
| amm:union | 0..1 |
+--------------+-------------+
Table 12: amm:typedef
Substatements
Examples of the "typedef" statement are below, some as restriction
and some as union.
Birrane, et al. Expires 8 April 2024 [Page 61]
Internet-Draft DTNMA AMM/ADM October 2023
amm:typedef restricted-uint {
amm:type uint {
range "3..10";
}
description "Example restriction";
}
amm:typedef annotated-uint {
amm:type uint {
units "meter";
}
description "Example units annotation";
}
amm:typedef structured-ac {
amm:ulist {
amm:type real32;
amm:units "meter";
min-elements 3;
max-elements 10;
}
description "Example units annotation";
}
7.3.5. The amm:const Statement
This statement is used to define a Constant (CONST) object. The
argument to this statement is the name of the AMM object.
The substatements under this are the common object metadata, optional
formal parameters, and one of the type use statements (Section 7.3.2)
that represents the produced value of the CONST. The "const"
statement SHALL contain a an "init-value", which is the constant
represented by this object.
Birrane, et al. Expires 8 April 2024 [Page 62]
Internet-Draft DTNMA AMM/ADM October 2023
+================+=============+
| Substatement | Cardinality |
+================+=============+
| if-feature | 0..1 |
+----------------+-------------+
| amm:enum | 0..1 |
+----------------+-------------+
| amm:parameter | 0..n |
+----------------+-------------+
| status | 0..1 |
+----------------+-------------+
| reference | 0..1 |
+----------------+-------------+
| description | 0..1 |
+----------------+-------------+
| amm:init-value | 1 |
+================+=============+
| One of the type uses: |
+================+=============+
| amm:type | 0..1 |
+----------------+-------------+
| amm:ulist | 0..1 |
+----------------+-------------+
| amm:dlist | 0..1 |
+----------------+-------------+
| amm:tblt | 0..1 |
+----------------+-------------+
| amm:umap | 0..1 |
+----------------+-------------+
| amm:union | 0..1 |
+----------------+-------------+
Table 13: amm:const
Substatements
An example of a simple-typed CONST is below.
amm:const pi32 {
amm:type real32;
amm:init-value "3.14159";
description "A truncated value of Pi.";
}
Another example of a semantic-typed MAC-valued (Section 4.2.4) CONST
is below.
Birrane, et al. Expires 8 April 2024 [Page 63]
Internet-Draft DTNMA AMM/ADM October 2023
amm:const do_thing {
amm:type amm:MAC;
amm:init-value "/AC/(../CTRL/first,../CTRL/second(2))";
description "Execute two controls in sequence.";
}
7.3.6. The amm:ctrl Statement
This statement is used to define a Control (CTRL) object. The
argument to this statement is the name of the AMM object.
The substatements under this are the common object metadata, optional
formal parameters, and an optional execution result. If the
amm:result substatement is present it SHALL contain an "init-value"
substatement, used to initialize the Result Storage for the execution
procedure (Section 6.6.2). If the amm:result substatement is omitted
the assumed result type SHALL be NULL with a default value of null.
+===============+=============+
| Substatement | Cardinality |
+===============+=============+
| if-feature | 0..1 |
+---------------+-------------+
| amm:enum | 0..1 |
+---------------+-------------+
| amm:parameter | 0..n |
+---------------+-------------+
| status | 0..1 |
+---------------+-------------+
| reference | 0..1 |
+---------------+-------------+
| description | 0..1 |
+---------------+-------------+
| amm:result | 0..1 |
+---------------+-------------+
Table 14: amm:ctrl
Substatements
An example of a single-parameter CTRL is below.
Birrane, et al. Expires 8 April 2024 [Page 64]
Internet-Draft DTNMA AMM/ADM October 2023
amm:ctrl reset_count {
amm:parameter src {
type textstr;
description "The name of the source.";
}
amm:result previous {
type UVAST;
description "The value just before reset.";
}
description "This control resets counts for the given source.";
}
7.3.6.1. The amm:result Statement
The result statement contains one of the type use statements
(Section 7.3.2) which represents the result expected from executing a
CTRL or evaluating an OPER. The argument to this statement is an
identifier for the result.
+==============+=============+
| Substatement | Cardinality |
+==============+=============+
| reference | 0..1 |
+--------------+-------------+
| description | 0..1 |
+--------------+-------------+
| amm:default | 0..1 |
+==============+=============+
| One of the type uses: |
+==============+=============+
| amm:type | 0..1 |
+--------------+-------------+
| amm:ulist | 0..1 |
+--------------+-------------+
| amm:dlist | 0..1 |
+--------------+-------------+
| amm:tblt | 0..1 |
+--------------+-------------+
| amm:umap | 0..1 |
+--------------+-------------+
| amm:union | 0..1 |
+--------------+-------------+
Table 15: amm:result
Substatements
Birrane, et al. Expires 8 April 2024 [Page 65]
Internet-Draft DTNMA AMM/ADM October 2023
7.3.7. The amm:edd Statement
This statement is used to define a Externally Defined Data (EDD)
object. The argument to this statement is the name of the AMM
object.
The substatements under this are the common object metadata, optional
formal parameters, and one of the type use statements (Section 7.3.2)
that represents the produced value of the EDD.
+===============+=============+
| Substatement | Cardinality |
+===============+=============+
| if-feature | 0..1 |
+---------------+-------------+
| amm:enum | 0..1 |
+---------------+-------------+
| amm:parameter | 0..n |
+---------------+-------------+
| status | 0..1 |
+---------------+-------------+
| reference | 0..1 |
+---------------+-------------+
| description | 0..1 |
+===============+=============+
| One of the type uses: |
+===============+=============+
| amm:type | 0..1 |
+---------------+-------------+
| amm:ulist | 0..1 |
+---------------+-------------+
| amm:dlist | 0..1 |
+---------------+-------------+
| amm:tblt | 0..1 |
+---------------+-------------+
| amm:umap | 0..1 |
+---------------+-------------+
| amm:union | 0..1 |
+---------------+-------------+
Table 16: amm:edd Substatements
An example of a simple-typed EDD is below.
Birrane, et al. Expires 8 April 2024 [Page 66]
Internet-Draft DTNMA AMM/ADM October 2023
amm:edd tx_count {
amm:type amm:counter64 {
units "frames";
}
description "The count of the number of frames sent.";
}
7.3.8. The amm:oper Statement
This statement is used to define a Operator (OPER) object. The
argument to this statement is the name of the AMM object.
The substatements under this are the common object metadata, optional
formal parameters, an operands list, and an evaluation result.
+===============+=============+
| Substatement | Cardinality |
+===============+=============+
| if-feature | 0..1 |
+---------------+-------------+
| amm:enum | 0..1 |
+---------------+-------------+
| amm:parameter | 0..n |
+---------------+-------------+
| status | 0..1 |
+---------------+-------------+
| reference | 0..1 |
+---------------+-------------+
| description | 0..1 |
+---------------+-------------+
| operands | 1 |
+---------------+-------------+
| result | 1 |
+---------------+-------------+
Table 17: amm:edd Substatements
An example of an arithmetic OPER is below.
Birrane, et al. Expires 8 April 2024 [Page 67]
Internet-Draft DTNMA AMM/ADM October 2023
amm:oper add {
amm:operand val_a {
amm:type amm:NUMERIC;
}
amm:operand val_b {
amm:type amm:NUMERIC;
}
amm:result sum {
amm:type amm:NUMERIC;
}
description "Sum together the two operands.";
}
A more complex "variadic" OPER with parameters is below. Also note
the anonymous semantic type used to restrict the parameter.
amm:oper sum {
parameter count {
amm:type amm:UINT {
range "1..max";
}
description "The number of operands to pop."
}
operand value {
amm:type amm:NUMERIC;
description
"This is not within a container, so does not represent an AC;
it is multiple operands.";
}
result sum {
type amm:NUMERIC;
}
description "Sum together a sequence from the stack.";
}
7.3.8.1. The amm:operand Statement
This statement is used to define one operand that applies to the
parent object. The argument to this statement is an identifier for
the operand. All operands SHALL have unique names within the same
parent object.
Birrane, et al. Expires 8 April 2024 [Page 68]
Internet-Draft DTNMA AMM/ADM October 2023
+==============+=============+
| Substatement | Cardinality |
+==============+=============+
| reference | 0..1 |
+--------------+-------------+
| description | 0..1 |
+==============+=============+
| One of the type uses: |
+==============+=============+
| amm:type | 0..1 |
+--------------+-------------+
| amm:ulist | 0..1 |
+--------------+-------------+
| amm:dlist | 0..1 |
+--------------+-------------+
| amm:tblt | 0..1 |
+--------------+-------------+
| amm:umap | 0..1 |
+--------------+-------------+
| amm:union | 0..1 |
+--------------+-------------+
Table 18: amm:operand
Substatements
7.3.9. The amm:sbr Statement
This statement is used to define a State-Based Rule (SBR) object.
The argument to this statement is the name of the AMM object.
The substatements under this are the common object metadata, the
action to execute upon trigger, and rule control fields defined
below.
Birrane, et al. Expires 8 April 2024 [Page 69]
Internet-Draft DTNMA AMM/ADM October 2023
+==================+=============+
| Substatement | Cardinality |
+==================+=============+
| if-feature | 0..1 |
+------------------+-------------+
| amm:enum | 0..1 |
+------------------+-------------+
| status | 0..1 |
+------------------+-------------+
| reference | 0..1 |
+------------------+-------------+
| description | 0..1 |
+------------------+-------------+
| amm:action | 1 |
+------------------+-------------+
| amm:condition | 1 |
+------------------+-------------+
| amm:min-interval | 0..1 |
+------------------+-------------+
| amm:max-count | 0..1 |
+------------------+-------------+
| amm:init-enabled | 0..1 |
+------------------+-------------+
Table 19: amm:sbr Substatements
An example of an SBR with some default fields is below.
amm:sbr enable_safe_mode {
amm:action "TBD";
amm:condition "(../EDD/sensor,../VAR/min_threshold,/ietf-amm/OPER/lessthan)";
description "Enable safe mode below threshold.";
}
7.3.9.1. The amm:min-interval Statement
This statement is used to define the Minimum Interval field of
State-Based Rule (SBR) objects. The argument to this statement is
the text form of a TD value. If not present, the default value of
zero (meaning no minimum) is used.
7.3.9.2. The amm:max-count Statement
This statement is used to define the Maximum Count field of
State-Based Rule (SBR) and Time-Based Rule (TBR) objects. The
argument to this statement is the text form of a UVAST value. If not
present, the default value of zero (meaning no limit) is used.
Birrane, et al. Expires 8 April 2024 [Page 70]
Internet-Draft DTNMA AMM/ADM October 2023
7.3.9.3. The amm:init-enabled Statement
This statement is used to define the Initial Enabled state of
State-Based Rule (SBR) and Time-Based Rule (TBR) objects. The
argument to this statement is the text form of a BOOL value. If not
present, the default value of true is used.
7.3.10. The amm:tbr Statement
This statement is used to define a Time-Based Rule (TBR) object. The
argument to this statement is the name of the AMM object.
The substatements under this are the common object metadata, the
action to execute upon trigger, and rule control fields defined
below.
+==================+=============+
| Substatement | Cardinality |
+==================+=============+
| if-feature | 0..1 |
+------------------+-------------+
| amm:enum | 0..1 |
+------------------+-------------+
| status | 0..1 |
+------------------+-------------+
| reference | 0..1 |
+------------------+-------------+
| description | 0..1 |
+------------------+-------------+
| amm:action | 1 |
+------------------+-------------+
| amm:start | 1 |
+------------------+-------------+
| amm:period | 0..1 |
+------------------+-------------+
| amm:max-count | 0..1 |
+------------------+-------------+
| amm:init-enabled | 0..1 |
+------------------+-------------+
Table 20: amm:tbr Substatements
An example of an TBR with some default fields is below.
Birrane, et al. Expires 8 April 2024 [Page 71]
Internet-Draft DTNMA AMM/ADM October 2023
amm:tbr tlm_rule {
amm:action "(../CTRL/first,/adm2/CTRL/other)";
amm:period "/TD/PT30s";
description "Generate telemetry reports.";
}
7.3.10.1. The amm:start Statement
This statement is used to define the Start field of Time-Based Rule
(TBR) objects. The argument to this statement is the text form of a
TIME (Section 4.2.2) value. If not present, the default value of
zero (meaning start immediately) is used.
7.3.11. The amm:var Statement
This statement is used to define a Variable (VAR) object. The
argument to this statement is the name of the AMM object.
The substatements under this are the common object metadata, optional
formal parameters, one of the type use statements (Section 7.3.2)
that represents the stored-and-produced value of the VAR, and an
optional initializer expression.
Birrane, et al. Expires 8 April 2024 [Page 72]
Internet-Draft DTNMA AMM/ADM October 2023
+================+=============+
| Substatement | Cardinality |
+================+=============+
| if-feature | 0..1 |
+----------------+-------------+
| amm:enum | 0..1 |
+----------------+-------------+
| amm:parameter | 0..n |
+----------------+-------------+
| status | 0..1 |
+----------------+-------------+
| reference | 0..1 |
+----------------+-------------+
| description | 0..1 |
+================+=============+
| One of the type uses: |
+================+=============+
| amm:type | 0..1 |
+----------------+-------------+
| amm:ulist | 0..1 |
+----------------+-------------+
| amm:dlist | 0..1 |
+----------------+-------------+
| amm:tblt | 0..1 |
+----------------+-------------+
| amm:umap | 0..1 |
+----------------+-------------+
| amm:union | 0..1 |
+================+=============+
| An optional initializer: |
+================+=============+
| amm:init-value | 0..1 |
+----------------+-------------+
| amm:init-expr | 0..1 |
+----------------+-------------+
Table 21: amm:var Substatements
An example of a simple-typed VAR with an initializer value is below.
amm:var min_threshold {
amm:type real32 {
units "meter";
}
amm:init-value "1e4";
description "The lower threshold to enable safe mode.";
}
Birrane, et al. Expires 8 April 2024 [Page 73]
Internet-Draft DTNMA AMM/ADM October 2023
7.3.11.1. The amm:init-value Statement
This statement is used to define CONST values and VAR initial state
as an AMM value. The argument to this statement is the text form of
the ARI encoding the expression.
The initializer is used as part of the Agent Initialization
procedure, and when new VAR objects are defined in an ODM.
7.3.11.2. The amm:init-expr Statement
This statement is used to define an initial VAR state as an AMM value
or an Expression (EXPR). The argument to this statement is the text
form of the ARI encoding the expression.
The initializer is used as part of the Agent Initialization procedure
and when new VAR objects are defined in an ODM.
7.4. ADM Module Contents
An ADM module is identified, as defined in Section 7.1.1, by the
module "namespace" having an "ari" scheme. Within an ADM module,
this profile makes restrictions in Section 7.1.2 which are formalized
in the following table of allowed module substatements. This table
is adapted from Section 7.1. of [RFC7950].
+==============+=============+
| Substatement | Cardinality |
+==============+=============+
| yang-version | 1 |
+--------------+-------------+
| namespace | 1 |
+--------------+-------------+
| prefix | 1 |
+--------------+-------------+
| include | 0..n |
+--------------+-------------+
| import | 0..n |
+--------------+-------------+
| status | 0..1 |
+--------------+-------------+
| reference | 0..1 |
+--------------+-------------+
| organization | 0..1 |
+--------------+-------------+
| description | 0..1 |
+--------------+-------------+
| revision | 0..n |
Birrane, et al. Expires 8 April 2024 [Page 74]
Internet-Draft DTNMA AMM/ADM October 2023
+--------------+-------------+
| extension | 0..n |
+--------------+-------------+
| feature | 0..n |
+--------------+-------------+
| deviation | 0..n |
+--------------+-------------+
| amm:enum | 1 |
+--------------+-------------+
| amm:typedef | 0..n |
+--------------+-------------+
| amm:const | 0..n |
+--------------+-------------+
| amm:ctrl | 0..n |
+--------------+-------------+
| amm:edd | 0..n |
+--------------+-------------+
| amm:oper | 0..n |
+--------------+-------------+
| amm:sbr | 0..n |
+--------------+-------------+
| amm:tbr | 0..n |
+--------------+-------------+
| amm:var | 0..n |
+--------------+-------------+
Table 22: ADM module
Substatements
8. ADM Author Considerations
The AMM model provides multiple ways to represent certain types of
data. This section provides informative guidance on how to express
application management constructs efficiently when authoring an ADM
document.
Use Parameters for Dynamic Information: Parameters provide a
powerful mechanism for expressing associative look-ups of EDD
data. EDDs SHOULD be parameterized when the definition of the EDD
is dependent upon run-time information. For example, if
requesting the number of bytes through a specific endpoint, the
construct num_bytes("endpoint_name") is simpler to understand and
more robust to new endpoint additions than attempting to enumerate
the number and name of potential endpoints when defining the ADM.
Do Not Use Parameters for Static Information: Parameters incur
Birrane, et al. Expires 8 April 2024 [Page 75]
Internet-Draft DTNMA AMM/ADM October 2023
bandwidth and processing costs (such as type checking) and should
only be used where necessary. If an EDD object can be
parameterized, but the set of parameters is known and unchanging
it may be more efficient to define multiple non-parameterized EDD
objects instead. For example, consider a single parameterized EDD
object reporting the number of bytes of data received for a
specific, known set of priorities and a request to report on those
bytes for the "low", "med", and "high" priorities. Below are two
ways to represent these data: using parameters and not using
parameters.
+------------------------+------------------------+
| Parameterized EDDs | Non-Parameterized EDDs |
+------------------------+------------------------+
| num_bytes_by_pri(low) | num_bytes_by_low_pri |
| num_bytes_by_pri(med) | num_bytes_by_med_pri |
| num_bytes_by_pri(high) | num_bytes_by_high_pri |
+------------------------+------------------------+
Figure 3
The use of parameters in this case only incurs the overhead of
type checking, parameter encoding/decoding, and associative
lookup. This situation should be avoided when deciding when to
parameterize AMM objects.
Use Tables for Related Data: In cases where multiple EDD or VAR
values are likely to be evaluated together, then that information
SHOULD be placed in a Table Template rather than defining multiple
EDD and VAR objects. By making a Table Template, the
relationships among various data values are preserved. Otherwise,
Managers would need to remember to query multiple EDD and/or VAR
objects together which is burdensome, but also results in high
bandwidth and processor utilization.
9. IANA Considerations
This section provides guidance to the Internet Assigned Numbers
Authority (IANA) regarding registration of schema and namespaces
related to core ADMs, in accordance with BCP 26 [RFC1155].
9.1. DTN Management Architecture Parameters
This document relies on existing ARI-defined sub-registries defined
in [IANA-DTNMA] by Section 9.3 of [I-D.birrane-dtn-ari].
Birrane, et al. Expires 8 April 2024 [Page 76]
Internet-Draft DTNMA AMM/ADM October 2023
This document registers the following entries within the "Application
Data Models" sub-registry of the "DTN Management Architecture
Parameters" registry [IANA-DTNMA].
+=============+==================+=================+=======+
| Enumeration | Name | Reference | Notes |
+=============+==================+=================+=======+
| 1 | ietf-dtnma-agent | [This document] | |
+-------------+------------------+-----------------+-------+
Table 23: Application Data Models
10. Security Considerations
This document does not describe any on-the-wire encoding or other
messaging syntax. It is assumed that the exchange of AMM objects
between Agents and Managers occurs within the context of an
appropriate network environment.
This AMM model may be extended to include the concept of Access
Control Lists (ACLs) to enforce roles and responsibilities among
Managers in the network. This access control would be implemented
separately from network security mechanisms.
11. References
11.1. Normative References
[IANA-DTNMA]
IANA, "Delay-Tolerant Networking Management Architecture
(DTNMA) Parameters",
<https://www.iana.org/assignments/TBD/>.
[IEEE.754-2019]
IEEE, "IEEE Standard for Floating-Point Arithmetic",
IEEE IEEE 754-2019, DOI 10.1109/IEEESTD.2019.8766229, 18
July 2019, <https://ieeexplore.ieee.org/document/8766229>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/info/rfc3629>.
Birrane, et al. Expires 8 April 2024 [Page 77]
Internet-Draft DTNMA AMM/ADM October 2023
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<https://www.rfc-editor.org/info/rfc3339>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.
[I-D.birrane-dtn-ari]
Birrane, E. J., Annis, E., and B. Sipos, "DTNMA
Application Resource Identifier", Work in Progress,
Internet-Draft, draft-birrane-dtn-ari-02, 10 July 2023,
<https://datatracker.ietf.org/doc/html/draft-birrane-dtn-
ari-02>.
11.2. Informative References
[ECMA-262] Ecma International, "ECMA-262 12th Edition, June 2021.
ECMAScript 2021 language specification", June 2021,
<https://262.ecma-international.org/12.0/>.
[IANA-YANG]
IANA, "YANG Parameters",
<https://www.iana.org/assignments/yang-parameters/>.
[X.680] ITU-T, "Information technology -- Abstract Syntax Notation
One (ASN.1): Specification of basic notation", ITU-T
Recommendation X.680, ISO/IEC 8824-1:2015, August 2015,
<https://www.itu.int/rec/T-REC-X.680-201508-I/en>.
[RFC1155] Rose, M. and K. McCloghrie, "Structure and identification
of management information for TCP/IP-based internets",
STD 16, RFC 1155, DOI 10.17487/RFC1155, May 1990,
<https://www.rfc-editor.org/info/rfc1155>.
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Structure of Management Information
Version 2 (SMIv2)", STD 58, RFC 2578,
DOI 10.17487/RFC2578, April 1999,
<https://www.rfc-editor.org/info/rfc2578>.
Birrane, et al. Expires 8 April 2024 [Page 78]
Internet-Draft DTNMA AMM/ADM October 2023
[RFC2580] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Conformance Statements for SMIv2",
STD 58, RFC 2580, DOI 10.17487/RFC2580, April 1999,
<https://www.rfc-editor.org/info/rfc2580>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.
[RFC6021] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6021, DOI 10.17487/RFC6021, October 2010,
<https://www.rfc-editor.org/info/rfc6021>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6991, DOI 10.17487/RFC6991, July 2013,
<https://www.rfc-editor.org/info/rfc6991>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/info/rfc8610>.
[I-D.ietf-dtn-dtnma]
Birrane, E. J., Heiner, S., and E. Annis, "DTN Management
Architecture", Work in Progress, Internet-Draft, draft-
ietf-dtn-dtnma-06, 9 July 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-dtn-
dtnma-06>.
Appendix A. ADM Module for AMM Definitions
The following is the ADM module implementing the entities described
in Section 4.2:
* Extensions to support ADM Metadata within a YANG module.
* Extensions to support AMM Objects within a YANG module.
* The literal and object-reference types of ARI (Section 3.1.3)
usable as YANG leaf types. FIXME remove
Birrane, et al. Expires 8 April 2024 [Page 79]
Internet-Draft DTNMA AMM/ADM October 2023
<CODE BEGINS> file "ietf-amm.yang"
module ietf-amm {
namespace "ari:/ietf-amm";
prefix amm;
amm:enum "0";
organization
"IETF Delay Tolerant Networking (DTN) Working Group";
contact
"WG Web: <http://tools.ietf.org/wg/dtn/>
WG List: <mailto:dtn@ietf.org>
Author: Brian Sipos
<mailto:brian.sipos+ietf@gmail.com>";
description
"This module implements the DTN Management Architecture (DTNMA)
Application Management Model (AMM) extensions within YANG";
reference
"draft-birrane-dtn-adm";
revision 2023-06-08 {
description
"Updated for latest AMM contents.";
reference
"draft-birrane-dtn-adm";
}
revision 2016-04-01 {
description
"Updated to fix typos.";
reference
"draft-bsipos-dtn-amp-yang";
}
revision 2016-03-14 {
description
"Initial draft release.";
reference
"draft-bsipos-dtn-amp-yang";
}
/****
* This section contains extension for AMM object definitions
****/
// This group of extensions are for common behavior for AMM objects
extension enum {
argument value;
description
"An enumeration identifies an object within a namespace.
Birrane, et al. Expires 8 April 2024 [Page 80]
Internet-Draft DTNMA AMM/ADM October 2023
The argument to this statement is the integer value.";
}
extension parameter {
argument name;
description
"The schema for a formal parameter of an object.
Order of parameters is significant within this statement.";
}
extension default {
argument value;
description
"The literal value default for a parameter or result.
The argument is the text form of the ARI";
}
extension init-value {
argument value;
description
"The literal value of a CONST object,
initial state for a VAR object.
The argument is the text form of the ARI";
}
extension init-expr {
argument expr;
description
"An expression evaluated to initialize a VAR object.
The argument is the text form of the EXPR AC";
}
// This group are AMM object keywords and their parameters
extension typedef {
argument name;
description
"Definition of a TYPEDEF within an ADM.
The argument to this statement is the object name.
One of the type use substatements must be present.";
}
extension ident {
argument name;
description
"Definition of an IDENT within an ADM.
The argument to this statement is the object name.
An 'base' substatement must be present.";
Birrane, et al. Expires 8 April 2024 [Page 81]
Internet-Draft DTNMA AMM/ADM October 2023
}
extension base {
argument name;
description
"The argument is the base of an IDENT object.";
}
extension const {
argument name;
description
"Definition of a CONST within an ADM.
The argument to this statement is the object name.
An 'init-value' substatement must be present.";
}
extension ctrl {
argument name;
description
"Definition of a CTRL within an ADM.
The argument to this statement is the object name.";
}
extension result {
argument name;
description
"A result value reported as a response to a control.
The substatement is the result type.
Each CTRL can have a single optional result.";
}
extension edd {
argument name;
description
"Definition of an EDD within an ADM.
The argument to this statement is the object name.";
}
extension oper {
argument name;
description
"Definition of an OPER within an ADM.
The argument to this statement is the object name.";
}
extension operand {
argument name;
description
Birrane, et al. Expires 8 April 2024 [Page 82]
Internet-Draft DTNMA AMM/ADM October 2023
"An individual operand taken from the expression stack
during evaluation of the OPER.
Each substatement is an operand as a leaf (ARI).
Order of operands is significant within an object definition.";
}
extension var {
argument name;
description
"Definition of a VAR within an ADM.
The argument to this statement is the object name.";
}
/****
* This section contains ARI (literal and object-reference) value types.
****/
extension type {
argument name;
description
"A reference to a built-in type or prefix-qualified typedef.";
}
extension int-labels {
description
"Type narrowing for an INTEGER to label enum values or bit positions.";
}
extension cddl {
argument text;
description
"Type narrowing for a CBOR item in the form of CDDL syntax.
The argument to this statement is the actual CDDL text.";
}
extension ulist {
description
"Type for an AC containing a list of uniform-typed values.";
}
extension dlist {
description
"Type for an AC containing a list of diverse-typed sequences.";
}
extension seq {
description
"A sequence of uniform-typed values within a 'dlist'.";
Birrane, et al. Expires 8 April 2024 [Page 83]
Internet-Draft DTNMA AMM/ADM October 2023
}
extension tblt {
description
"Type for a table of values with a column schema.";
}
extension column {
argument name;
description
"Type for a table of values with a column schema.";
}
extension key {
argument columns;
description
"Names of columns composing the row key.";
}
extension unique {
argument columns;
description
"Names of columns composing a uniqueness constraint.";
}
extension union {
description
"Type for a union of other types.";
}
// Named type unions for literals
amm:typedef TYPE-REF {
amm:union {
amm:type LITTYPE;
amm:type TYPEDEF-REF;
}
description
"Reference to either a literal type or a typedef.";
}
amm:typedef INTEGER {
amm:union {
amm:type BYTE;
amm:type UINT;
amm:type INT;
amm:type UVAST;
amm:type VAST;
}
description
Birrane, et al. Expires 8 April 2024 [Page 84]
Internet-Draft DTNMA AMM/ADM October 2023
"Any type which represents a discrete integer.";
}
amm:typedef FLOAT {
amm:union {
amm:type REAL32;
amm:type REAL64;
}
description
"Any type which represents a floating point number.";
}
amm:typedef NUMERIC {
amm:union {
amm:type INTEGER;
amm:type FLOAT;
}
description
"Any type which can be used with numeric expressions.";
}
amm:typedef TIME {
amm:union {
amm:type TP;
amm:type TD;
}
description
"Any type which can be used with time expressions.";
}
amm:typedef SIMPLE {
amm:union {
amm:type NULL;
amm:type BOOL;
amm:type NUMERIC;
amm:type TEXTSTR;
amm:type BYTESTR;
amm:type TIME;
amm:type LABEL;
amm:type CBOR;
}
description
"Any type which contains a single literal value (not complex).";
}
amm:typedef COMPLEX {
amm:union {
amm:type AC;
amm:type AM;
}
description
"A literal type which is not SIMPLE.";
}
Birrane, et al. Expires 8 April 2024 [Page 85]
Internet-Draft DTNMA AMM/ADM October 2023
amm:typedef LITERAL {
amm:union {
amm:type TYPE-REF; //FIXME: is typeref a literal or something else?
amm:type SIMPLE;
amm:type COMPLEX;
}
description
"Any type which is represented as a literal ARI.";
}
amm:typedef ANY {
amm:union {
amm:type LITERAL;
amm:type OBJECT;
}
description
"Any type representable by an ARI.";
}
amm:typedef VALUE-OBJ {
amm:union {
amm:type CONST;
amm:type EDD;
amm:type VAR;
}
description
"A reference to an object which can produce a value.";
}
// operational semantic types
amm:typedef counter32 {
amm:type UINT;
description
"A 32-bit counter with an arbitrary initial value that only increments.
When the value reaches the upper range it wraps around to zero.
At least two samples of this value need to be compared over time.";
}
amm:typedef counter64 {
amm:type UVAST;
description
"A 64-bit counter with an arbitrary initial value that only increments.
When the value reaches the upper range it wraps around to zero.
At least two samples of this value need to be compared over time.";
}
amm:typedef gauge32 {
amm:type INT;
description
"A 32-bit value sampling some quantized measurement.
The value can increase or decrease arbitrarily over time.";
}
Birrane, et al. Expires 8 April 2024 [Page 86]
Internet-Draft DTNMA AMM/ADM October 2023
amm:typedef gauge64 {
amm:type VAST;
description
"A 64-bit value sampling some quantized measurement.
The value can increase or decrease arbitrarily over time.";
}
amm:typedef timestamp {
amm:type TP;
description
"A time point representing the system clock at which a specific
occurrence happened.
The specific occurrence must be defined in the description
of any node defined using this type.";
}
// Restrictions on AC item types for specific purposes
amm:typedef EXPR-item {
amm:union {
amm:type SIMPLE;
amm:type VALUE-OBJ;
amm:type TYPEDEF;
amm:type OPER;
}
description
"Each item of an EXPR list.
The value-object must be typed to contain a SIMPLE.";
}
amm:typedef EXPR {
amm:ulist {
amm:type EXPR-item;
}
description
"The contents of an EXPR container.";
}
amm:typedef EXEC-item {
amm:union {
amm:type VALUE-OBJ;
amm:type CTRL;
}
description
"A reference to an object which can be executed.
The value-object must be typed to contain a MAC.";
}
amm:typedef MAC {
amm:ulist {
amm:type EXEC-item;
}
description
Birrane, et al. Expires 8 April 2024 [Page 87]
Internet-Draft DTNMA AMM/ADM October 2023
"The contents of a MAC container.";
}
amm:typedef RPTT-item {
amm:union {
amm:type VALUE-OBJ;
amm:type EXPR;
}
description
"Each item of a RPTT.
Each item references a value-producing object or contains an
expression to be evaluated.";
}
amm:typedef RPTT {
amm:ulist {
amm:type RPTT-item;
}
description
"The contents of a report template, encoded as the sequence of items.";
}
amm:typedef RPT {
amm:dlist {
amm:type VALUE-OBJ {
description
"Reference to the reported object.";
}
amm:type timestamp {
description
"The generation timestamp.";
}
amm:seq {
amm:type ANY;
description
"The sequence of items in the report.";
}
}
description
"The source and contents of a report, encoded as the sequence
of values reported.
The semantics of each item are contained in the associated
source object (RPTT or CTRL).";
}
amm:typedef TBL {
amm:dlist {
amm:type UVAST {
description
"The number of columns in the table.";
}
amm:seq {
Birrane, et al. Expires 8 April 2024 [Page 88]
Internet-Draft DTNMA AMM/ADM October 2023
amm:type ANY;
description
"All table values listed in row-major order.";
}
}
description
"The flattened contents of a table.
The semantics of each column are contained in the associated TBLT.";
}
}
<CODE ENDS>
Appendix B. ADM Module for DTNMA Agents
The following is the ADM module implementing the entities described
in Section 4.3:
* Introspective access to the ADMs supported by the Agent.
* Introspective access to the VARs in ODMs.
* A feature and introspective access to rules in ODMs.
* A report template used to announce presence of an Agent.
* Base helper controls and arithmetic operators
<CODE BEGINS> file "ietf-dtnma-agent.yang"
module ietf-dtnma-agent {
namespace "ari:/ietf-dtnma-agent";
prefix da;
amm:enum "0";
import ietf-amm {
prefix amm;
}
organization
"IETF Delay Tolerant Networking (DTN) Working Group";
contact
"WG Web: <http://tools.ietf.org/wg/dtn/>
WG List: <mailto:dtn@ietf.org>
Editor: Brian Sipos
<mailto:brian.sipos+ietf@gmail.com>";
description
"This module implements the DTN Management Architecture (DTNMA)
Agent core functionality.";
Birrane, et al. Expires 8 April 2024 [Page 89]
Internet-Draft DTNMA AMM/ADM October 2023
reference
"draft-birrane-dtn-adm";
revision 2023-06-08 {
description
"Updated for latest AMM contents.";
reference
"draft-birrane-dtn-adm";
}
feature rules {
description
"Conforming to this feature enables time-based and
state-based autonomy rules.";
}
amm:edd amp_version {
amm:type TEXTSTR;
description
"The version of AMP which this agent supports.";
}
amm:edd capability {
amm:tblt {
amm:key "adm_name";
amm:column adm_name {
amm:type amm:LABEL;
description
"The module name of the ADM";
}
amm:column revision {
amm:type amm:TEXTSTR;
description
"The specific revision the agent supports.";
}
amm:column features {
amm:ulist {
amm:type amm:LABEL;
}
description
"The features of the ADM which the agent supports.";
}
}
description
"A table to indicate the ADM capability of the sending agent.";
}
amm:const hello {
amm:type amm:RPTT;
amm:init-value "(../EDD/amp_version,../EDD/capability)";
Birrane, et al. Expires 8 April 2024 [Page 90]
Internet-Draft DTNMA AMM/ADM October 2023
description
"A report template to indicate the presence of an agent
on a network.";
}
// MAC helper controls
amm:ctrl if_then_else {
amm:parameter condition {
amm:type amm:EXPR;
description
"The condition to evaluate.";
}
amm:parameter on_truthy {
amm:type amm:EXEC-REF;
description
"The object to execute when the condition is truthy.";
}
amm:parameter on_falsy {
amm:union {
amm:type amm:NULL;
amm:type amm:EXEC-REF;
}
amm:default "null";
description
"An optional execution when the condition is falsey.";
}
description
"Evaluate an expression and follow one of two branches of
further evaluation.";
}
amm:ctrl catch {
amm:parameter try {
amm:type amm:EXEC-REF;
description
"The object to execute.";
}
amm:parameter on_failure {
amm:union {
amm:type amm:NULL;
amm:type amm:EXEC-REF;
}
amm:default "null";
description
"An optional execution after failure.";
}
description
"Attempt to execute an object, and if there is some failure catch it
and execute an alternative object.";
Birrane, et al. Expires 8 April 2024 [Page 91]
Internet-Draft DTNMA AMM/ADM October 2023
}
amm:ctrl inspect {
amm:parameter ref {
amm:type amm:VALUE-REF;
description
"An object to produce a value from.";
}
amm:result val {
amm:type amm:ANY;
description
"The produced value.";
}
description
"Produce a result value to inspect the agent state.
This does not perform any EXPR evaluation or RPTT handling.";
}
amm:ctrl report_on {
amm:parameter rptt {
amm:type amm:RPTT;
}
description
"Generate a report on an object without needing to define an object.
The parameter is a single RPTT list that would be produced by an object.
If used for more than one-shot diagnostics, defining a RPTT
(e.g. in a VAR) is more efficient because the RPTT item would not
be present in the report.";
}
grouping obj-list-params {
amm:parameter include_adm {
amm:type amm:BOOL;
amm:default "false";
description
"If true, listings will include objects from ADMs";
}
description
"Common parameters for object listing";
}
amm:edd typedef_list {
uses obj-list-params;
amm:tblt {
amm:key "obj";
amm:column obj {
amm:type amm:TYPEDEF-REF;
}
}
description
Birrane, et al. Expires 8 April 2024 [Page 92]
Internet-Draft DTNMA AMM/ADM October 2023
"A table of TYPEDEF within the agent.";
}
// Objects related to VAR handling
amm:edd var_list {
uses obj-list-params;
amm:tblt {
amm:key "obj";
amm:column obj {
amm:type amm:VAR-REF;
}
amm:column type {
amm:type amm:TYPE-REF;
}
}
description
"A table of VAR within the agent.";
}
amm:ctrl var_present {
amm:parameter obj {
amm:type amm:VAR-REF;
description
"A reference to a VAR within an ODM only.";
}
amm:parameter type {
amm:type amm:TYPE-REF;
description
"The type for the VAR object.";
}
amm:parameter init {
amm:union {
amm:type amm:NULL;
amm:type amm:EXPR;
}
amm:default "null";
description
"An optional initializer expression.";
}
description
"Ensure a specific VAR is present.";
}
amm:ctrl var_absent {
amm:parameter obj {
amm:type amm:VAR-REF;
description
"A reference to a VAR within an ODM only.";
}
description
Birrane, et al. Expires 8 April 2024 [Page 93]
Internet-Draft DTNMA AMM/ADM October 2023
"Ensure a specific VAR is not present.";
}
// Objects related to SBR handling
amm:edd sbr_list {
if-feature "rules";
amm:tblt {
amm:key "obj";
amm:column obj {
amm:type amm:SBR-REF;
}
amm:column action {
amm:type amm:MAC;
description
"The execution when this rule triggers.";
}
amm:column start_time {
amm:type amm:TIME;
}
amm:column condition {
amm:type amm:EXPR;
}
amm:column min_interval {
amm:type TD;
}
amm:column max_count {
amm:type UVAST;
}
}
}
amm:edd tbr_list {
if-feature "rules";
amm:tblt {
amm:key "obj";
amm:column obj {
amm:type amm:OBJ-REF;
}
amm:column action {
amm:type amm:MAC;
description
"The execution when this rule triggers.";
}
amm:column start_time {
amm:type amm:TIME;
}
amm:column period {
amm:type TD;
}
Birrane, et al. Expires 8 April 2024 [Page 94]
Internet-Draft DTNMA AMM/ADM October 2023
amm:column max_count {
amm:type UVAST;
}
}
}
grouping numeric-unary-operands {
amm:operand val {
amm:type amm:NUMERIC;
description
"The single value.";
}
}
grouping numeric-binary-operands {
amm:operand left {
amm:type amm:NUMERIC;
description
"The left-side operand.";
}
amm:operand right {
amm:type amm:NUMERIC;
description
"The left-side operand.";
}
}
grouping numeric-unary-result {
amm:result val {
amm:type amm:NUMERIC;
description
"The single value.";
}
}
amm:oper negate {
uses numeric-unary-operands;
uses numeric-unary-result;
description
"Negate a value.
This is equivalent to multiplying by -1 but a shorter
expression.";
}
amm:oper add {
uses numeric-binary-operands;
uses numeric-unary-result;
description
"Add two numeric values.
Birrane, et al. Expires 8 April 2024 [Page 95]
Internet-Draft DTNMA AMM/ADM October 2023
The operands are cast to the least compatible numeric type
before the arithmetic.";
}
// amm:oper sub
// amm:oper multiply
// amm:oper divide
// amm:oper add
// amm:oper bit_not
// amm:oper bit_and
// amm:oper bit_or
// amm:oper bit_xor
// amm:oper bool_not
// amm:oper bool_and
// amm:oper bool_or
// amm:oper bool_xor
// amm:oper compare_eq
// amm:oper compare_ne
// amm:oper compare_gt
// amm:oper compare_ge
amm:oper compare_lt {
uses numeric-binary-operands;
uses numeric-unary-result;
description
"Compare two operands by value.
The result is true if the left value is less than the right.
The operands are cast to the least compatible numeric type
before the comparison.";
}
amm:oper compare_le {
uses numeric-binary-operands;
uses numeric-unary-result;
description
"Compare two operands by value.
The result is true if the left value is less than or
equal to the right.
The operands are cast to the least compatible numeric type
before the comparison.";
}
}
<CODE ENDS>
Appendix C. Examples
For the sake of adhering to the proper syntax for ARIs, all of the
example reports are timestamped at 2023-01-01T00:00:00Z.
ari:/dtnma-agent/CTRL/report_on(/example-adm/EDD/intvalue)
Birrane, et al. Expires 8 April 2024 [Page 96]
Internet-Draft DTNMA AMM/ADM October 2023
Executing that results in a report containing the following:
(
/example-adm/EDD/intvalue,
/TP/20230101T000000Z,
/INT/10
)
If the produced value has a semantic type which is ambiguous within
the EDD type, the report would instead contain:
(
/example-adm/EDD/intvalue,
/TP/20230101T000000Z,
/example-adm/TYPEDEF/mycounter(/INT/10)
)
For a similar CONST that contains an RPTT value, the report would
contain:
(
../EDD/intvalue,
../EDD/boolvalue
)
(
/example-adm/CONST/report1,
/TP/20230101T000000Z,
/INT/10,
/true
)
Authors' Addresses
Edward J. Birrane, III
The Johns Hopkins University Applied Physics Laboratory
11100 Johns Hopkins Rd.
Laurel, MD 20723
United States of America
Phone: +1 443 778 7423
Email: Edward.Birrane@jhuapl.edu
David Linko
The Johns Hopkins University Applied Physics Laboratory
Email: David.Linko@jhuapl.edu
Birrane, et al. Expires 8 April 2024 [Page 97]
Internet-Draft DTNMA AMM/ADM October 2023
Brian Sipos
The Johns Hopkins University Applied Physics Laboratory
Email: brian.sipos+ietf@gmail.com
Birrane, et al. Expires 8 April 2024 [Page 98]