Internet-Draft DTNMA ARI July 2026
Birrane, et al. Expires 21 January 2027 [Page]
Workgroup:
Delay-Tolerant Networking
Internet-Draft:
draft-ietf-dtn-ari-09
Published:
Intended Status:
Standards Track
Expires:
Authors:
E.J. Birrane
JHU/APL
E.A. Annis
JHU/APL
B. Sipos
JHU/APL

DTNMA Application Resource Identifier (ARI)

Abstract

This document defines the structure, format, and features of the naming scheme for the objects defined in the Delay-Tolerant Networking Management Architecture (DTNMA) Application Management Model (AMM), in support of challenged network management solutions described in the DTNMA document.

This document defines the DTNMA Application Resource Identifier (ARI), using a text-form based on the common Uniform Resource Identifier (URI) and a binary-form based on Concise Binary Object Representation (CBOR). These meet the needs for a concise, typed, parameterized, and hierarchically organized set of managed data 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 21 January 2027.

▲

Table of Contents

1. Introduction

The unique limitations of Delay-Tolerant Networking (DTN) transport capabilities [RFC4838] necessitate increased reliance on individual node behavior. These limitations are considered part of the expected operational environment of the system and, thus, contemporaneous end-to-end data exchange cannot be considered a requirement for successful communication.

The primary DTN transport mechanism, Bundle Protocol version 7 (BPv7) [RFC9171], standardizes a store-and-forward behavior required to communicate effectively between endpoints that may never co-exist in a single network partition. BPv7 might be deployed in static environments, but the design and operation of BPv7 cannot presume that to be the case.

Similarly, the management of any BPv7 protocol agent (BPA) (or any software reliant upon DTN for its communication) cannot presume to operate in a resourced, connected network. Just as DTN transport must be delay-tolerant, DTN network management must also be delay-tolerant.

The DTN Management Architecture (DTNMA) [RFC9675] outlines an architecture that achieves this result through the self-management of a DTN node as configured by one or more remote managers in an asynchronous and open-loop system. An important part of this architecture is the definition of a conceptual data schema for defining resources configured by remote managers and implemented by the local autonomy of a DTN node.

The DTNMA Application Management Model (AMM) [I-D.ietf-dtn-amm] defines a logical schema that can be used to represent data types and structures, autonomous controls, and other kinds of information expected to be required for the local management of a DTN node. The AMM further describes a physical data model, called the Application Data Model (ADM), that can be defined in the context of applications to create resources in accordance with the AMM schema. These named resources can be predefined in moderated publications or custom-defined as part of the Operational Data Model (ODM) of an agent.

Every AMM resource must be uniquely identifiable. To accomplish this, an expressive naming scheme is required. The Application Resource Identifier (ARI) provides this naming scheme. This document defines the ARI, based on the structure of a Uniform Resource Identifier (URI) of [RFC3986], meeting the needs for a concise, typed, parameterized, and hierarchically organized naming convention. Additionally, a binary form of ARI encoding based on Concise Binary Object Representation (CBOR) of [RFC8949] is defined for more compact interchange of the same information.

1.1. Scope

The ARI scheme is based on the structure of a URI [RFC3986] in accordance with the practices outlined in [RFC8820].

ARIs are designed to support the identification requirements of the AMM logical schema. As such, this specification will discuss these requirements to the extent necessary to explain the structure and use of the ARI syntax.

This specification does not constrain the syntax or structure of any existing URI (or part thereof). As such, the ARI scheme does not impede the ownership of any other URI scheme and is therefore clear of the concerns presented in [RFC7320].

This specification does not discuss the manner in which ARIs might be generated, populated, and used by applications. The operational utility and configuration of ARIs in a system are described in other documents associated with DTN management, to include the DTNMA and AMM specifications.

This specification does not describe the way in which path prefixes associated with an ARI are standardized, moderated, or otherwise populated. Path suffixes may be specified where they do not lead to collision or ambiguity.

This specification does not describe the mechanisms for generating either standardized or custom ARIs in the context of any given application, protocol, or network.

1.2. Use of ABNF

This document defines text structure using the Augmented Backus-Naur Form (ABNF) of [RFC5234]. The entire ABNF structure can be extracted from the XML version of this document using the XPath expression:

'//sourcecode[@type="abnf"]'

The following initial fragment defines the top-level rules of this document's ABNF.

start = ari

From the document [RFC3986] the definitions are taken for pchar, unreserved, pct-encoded. From the document [RFC3339] the definitions are taken for date-time, full-date, and duration. From the document [RFC5234] the definitions are taken for bit, hexdig, digit, and char-val. From the document [RFC8259] the definitions are taken for char and unescaped.

1.3. Use of CDDL

This document defines CBOR structure using the Concise Data Definition Language (CDDL) of [RFC8610]. The entire CDDL structure can be extracted from the XML version of this document using the XPath expression:

'//sourcecode[@type="cddl"]'

The following initial fragment defines the top-level rules of this document's CDDL, which includes the example CBOR content.

start = ari

; Limited sizes to fit the AMM data model
int32 = (-2147483648 .. 2147483647) .within int
uint32 = uint .le 4294967295
int64 = (-9223372036854775808 .. 9223372036854775807) .within int
uint64 = uint

; Restricted identifier text
id-text = tstr .regexp "!?[A-Za-z_][A-Za-z0-9_\\-\\.]*"
; Restricted identifier enumerations
id-int = int32

This document does not rely on any CDDL symbol names from other documents.

1.4. Example ARI Line Folding

The URI encoding of Section 4 does not allow blank space characters and some of the example ARIs are longer than RFC recommended line lengths, the examples uses the "single backslash" folding strategy of Section 7 of [RFC8792] for line wrapping. The header from that strategy is not used explicitly in this document, so any use of indentation in example ARIs will make use of this folding strategy.

1.5. 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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

The terms "Application Data Model", "Application Resource Identifier", "Operational Data Model", "Externally Defined Data", "Variable", "Constant", "Control", "Literal", "Namespace", "Operator", "Report", "State-Based Rule", "Table", and "Time-Based Rule" are used without modification from the definitions provided in [I-D.ietf-dtn-amm].

2. ARI Purpose

AMM resources (contained within ADM and ODM namespaces) are referenced in the context of autonomous applications on an agent. The naming scheme of these resources must support certain features to inform DTNMA processing in accordance with the ADM logical schema.

This section defines the set of unique characteristics of the logical ARI scheme, the combination of which provides a unique utility for naming. While certain other naming schemes might incorporate certain elements, there are no such schemes that both support needed features and exclude prohibited features.

2.1. Resource Parameterization

The ADM schema allows for the parameterization of resources to both reduce the overall data volume communicated between DTN nodes and to remove the need for any round-trip data negotiation.

Parameterization reduces the communicated data volume when parameters are used as filter criteria. By associating a parameter with a data source, data characteristic, or other differentiating attribute, DTN nodes can locally process parameters to construct the minimal set of information to either process for local autonomy or report to remote managers in the network.

Parameterization eliminates the need for round-trip negotiation to identify where information is located or how it should be accessed. When parameters define the ability to perform an associative lookup of a value, the index or location of the data at a particular DTN node can be resolved locally as part of the local autonomy of the node and not communicated back to a remote manager.

2.2. Compressible Structure

The ability to encode information in very concise formats enables DTN communications in a variety of ways. Reduced message sizes increase the likelihood of message delivery, require fewer processing resources to secure, store, and forward, and require less resources to transmit.

The ARI syntax supports the following design elements to aid in the creation of more concise encodings: fixed-depth of hierarchy, enumerated forms of path segments, relative paths, and patterning. For example, the binary form of ARI (Section 5) supports the ability to identify objects in as few as 5 bytes and the ability to contain specific primitive values in as few as a single byte.

2.2.1. Enumerated Path Segments

Because the ARI structure includes paths segments with stable enumerated identifiers, each segment can be represented by either its text name or its integer enumeration. For human-readability in text form the text name is preferred, but for binary encoding and for comparisons the integer form is preferred. It is a translation done by the entity handling an ARI to switch between preferred representations (see Section 7); the data model of both forms of the ARI allows for either.

2.2.2. Relative Paths

Within an ARI, as defined in Section 3, literal values require no external context to interpret an so have no use for relative paths. Object reference values, however, always refer to an object within an ADM or ODM namespace and this namespace can be used as a base for resolving URI References as discussed in Section 4.5 and Section 5.5.

2.2.3. Patterning

Patterning in this context refers to the structuring of ARI information to allow defining value-matching logic as a function of wildcards and other expressions of general structure. Patterns allow for both better compression and fewer ARI representations by allowing a single ARI pattern to stand-in for a variety of actual ARI values.

This benefit is best achieved when the structure of the ARI is both expressive enough to include information that is useful to pattern match, and regular enough to understand how to create these patterns. A concrete definition for logic of and encodings for object reference patterns is defined in Section 3.2.1.

3. ARI Logical Structure

This section describes the information model of the ARI scheme to inform the discussion of the ARI syntax in Section 4 and Section 5. At the top-level, an ARI represents one of of the following AMM value classes defined in later subsections.

Literal values:
These are values are those whose value and identifier are equivalent and are discussed in more detail in Section 3.2.
Object Reference values:
These values refer to an individual object, possibly with parameters, and are discussed in Section 3.3.
Namespace Reference values:
These values refer to an individual namespace and are discussed in Section 3.4.

3.1. Names, Enumerations, Comparisons, and Canonicalizations

Within the ARI logical model, there are a number of domains in which items are identified by a combination of text name and integer enumeration: ADMs, ODMs, literal types, object types, and objects. In all cases, within a single domain the text name and integer enumeration SHALL NOT be considered comparable. It is an explicit activity by any entity processing ARIs to make the translation between text name and integer enumeration (see Section 7).

Text names SHALL be restricted to begin with an alphabetic character followed by any number of other characters, as defined in the id-text ABNF rule. This excludes a large class of characters, including non-printing characters. When represented in text form, the text name for ODMs is prefixed with a "!" character to disambiguate it from an ADM name (see Section 3.3).

For text names, comparison and uniqueness SHALL be based on case-insensitive logic. The canonical form of text names SHALL be the lower case representation.

Integer enumerations for ADMs and ODMs SHALL be restricted to a magnitude less than 2**63 to allow them to fit within a signed 64-bit storage. The ADM registration in Table 6 reserves high-valued code points for private and experimental ADMs, while the entire domain of ODM code points (negative integers) is considered private use. Integer enumerations for literal types and object types SHALL be restricted to a magnitude less than 2**31 to allow them to fit within a signed 32-bit storage. The registrations in Table 2 and Table 3 respectively Integer enumerations for objects (within an ADM or ODM) SHALL be restricted to a magnitude less than 2**31 to allow them to fit within a signed 32-bit storage, although negative-value object enumerations are disallowed.

For integer enumerations, comparison and uniqueness SHALL be based on numeric values not on encoded forms. The canonical form of integer enumerations in text form SHALL be the shortest length decimal representation.

3.2. Literals

Literals represent a special class of ARI which are not associated with any particular ADM or ODM. A literal has no other name other than its value, but literals may be explicitly typed in order to force the receiver to handle it in a specific way.

Because literals will be based on the CBOR data model [RFC8949] and its extended diagnostic notation, a literal has an intrinsic representable data type as well as an AMM data type. The CBOR primitive types are named CDDL rules as defined in Section 3.3 of [RFC8610].

When converting from AMM literal types, the chosen CBOR type SHALL be determined by the mapping in Table 1. Additionally, when handling typed literal ARIs any combination of AMM literal type and CBOR primitive type not in Table 1 SHALL be considered invalid. This restriction is enforced by the CDDL defined in Section 5. Additionally, when handling a literal of AMM type CBOR the well-formed-ness of the CBOR contained SHOULD be verified before the literal is treated as valid.

Table 1: AMM Literal Types to CBOR Types
AMM Literal Type Used CBOR Type
NULL null
BOOL bool
BYTE uint
INT int
UINT uint
VAST int
UVAST uint
REAL32 float
REAL64 float
TEXTSTR tstr
BYTESTR bstr
Non-primitive types
TP lit-time
TD lit-time
LABEL lit-label
CBOR lit-cbor
ARITYPE lit-label
OBJPAT lit-objpat
Containers
AC ari-collection
AM ari-map
TBL ari-tbl
EXECSET exec-set
RPTSET rpt-set

The text forms of time point and difference values defined in Section 4.2.1 allow both human-friendly representations (derived from [RFC3339] encodings) and direct numeric representation. The internal form of TP and TD values SHALL be as a decimal fraction supporting nanosecond precision. The internal form of TP and TD values SHALL be as a decimal fraction with a decimal mantissa large enough to hold a 64-bit signed integer (number of nanoseconds).

For the CBOR type, an implementation MAY perform CBOR decoding to validate that the byte string value is in fact well-formed CBOR but SHALL preserve the original byte string when transforming between the internal form and different encoded forms.

3.2.1. Object Reference Patterns

One of the considerations discussed in Section 2.2.3 is the ability to construct patterns to match and group objects by their various parts of their identity.

Although the logical structure of and encoded forms of Object Reference Patterns are similar to Object Reference values, they are different and they cannot be used interchangeably. The context used to interpret and match an pattern SHALL be explicit and separate from that used to interpret and dereference an Object Reference value.

While an Object Reference value can be used to dereference to a specific managed object and invoke behavior on that object, an Object Reference Pattern is used solely to perform matching logic against specific objects. The potential for an Object Reference Pattern to match specific objects SHALL NOT be interpreted as the existence of such hypothetical objects or any possible references to those objects.

As defined in the AMM, these patterns contain four separate parts (organization ID, model ID, object type, and object ID) and are used to match the four parts of an object path independently. Each part of the pattern contains one of the following to match the corresponding part of the object path:

Single value:
This will match only a single identifier value as either integer enumeration or text name.
Range:
This will match any identifier value contained in a disjoint set of integer intervals over the signed 32-bit domain.
Wildcard:
This will match any possible identifier in that part.

A diagram for logic and encoded fields of the range is shown in Figure 1. The text form of range encoding (Section 4.2.1) contains only the "min" and "max" values from the included intervals; it elides the least minimum and largest maximum if they are the limits of the integer domain. The binary form of range encoding (Section 5.2) contains only the "least" value and the width of each subsequent included and excluded interval; it elides the least value and last included width if the intervals cover the limits of the domain.

      _____(repeated)______
     /                     \
      Include       Exclude       Include
   min       max min       max min       max    integer
 <..|.........|...|.........|...|.........|..>  space
    |         |   |         |   |         |
    |<------->|<->|<------->|<->|<------->|
   /   incl     1    excl     1    incl         binary
least  width         width         width        fields
Figure 1: Integer Range Encoding

The most simple finite range is a single value, for example the value 10 is text encoded as "10" and binary encoded (shown using EDN) as [10,0] (which is a special case because this can also use the non-range specific value encoding). The most simple disjoint range containing the values 2, 4, and 5 is text encoded as "2,4..5" and binary encoded as [2,0,0,1] because the first included interval is width zero, excluded interval is width zero, and last included interval is width 1. The largest possible range covering the entire 32-bit number space can be text encoded as "-2147483648..4294967295" and binary encoded as [-0x80000000,0xFFFFFFFF] or the more concise elided form of ".." and [null,null] respectively (and even this is a special case because this can also be represented by the wildcard value true, but that is a normalization decision not a coding one).

3.3. Object References

Object references are composed of two parts: object identifier and optional parameters. The object identifier can be dereferenced to a specific object in the ADM/ODM, while the parameters provide additional information for certain types of object and only when allowed by the parameter "signature" from the ADM/ODM.

The object identifier itself contains these components, described in the following subsections: organization ID, model ID with optional model revision, object type, and object ID. When encoded in text form (see Section 4), the identifier components correspond to the URI authority and path segments.

Each identifier component has two possible forms; one more human-friendly and one more compressible. Values can only be converted between forms based on a local registry of data models. There is nothing intrinsic in either form which relates to the other form (i.e., each name and enumeration value is arbitrary).

Text name form:

This form corresponds with a human-readable identifier for the component. A text form component SHALL contain only URI path segment characters (pchar) representing valid UTF-8 text in accordance with [RFC3629]. This requirement applies to text components generally, specific component uses will restrict this valid domain further.

There is no intrinsic limit to the length of a text form component. Implementations are RECOMMENDED to not impose an arbitrary small limit to text form components.

Integer enumeration form:
This form corresponds with a compressible value suitable for on-the-wire encoding between Manager and Agent. Sorting and matching integer components is also faster than text form. Every integer form component SHALL be small enough to be represented as a 32-bit signed integer.

An Agent implementation MAY be incapable of handling text form object identifier components, and this needs to be communicated to any associated Manager prior to encoding any ARIs for that Agent.

The organization ID, model ID, and model revision together are be referred to as a "namespace". ADM resources exist within namespaces to eliminate the possibility of a conflicting resource name, aid in the application of patterns, and improve the compressibility of the ARI. Namespaces SHALL NOT be used as a security mechanism to manage access. An Agent or Manager SHALL NOT infer security information or access control based solely on namespace information in an ARI.

3.3.1. Organization ID

Organization IDs are used to segment the full domain of object identifiers into separately managed logical segments. Some organizations will be well known and registered with IANA, others will choose to make use of the private use reserved range for enumerations and names. This document allocates well known organization IDs in Section 10.2 for the IETF and IANA, as well as for example models.

Well Known organizations:
A well known organization ID SHALL be registered with IANA. All text form well known organization IDs SHALL match the id-text rule of Section 4.1 and not begin with the bang character "!". All integer form well known organization IDs SHALL be non-negative.
Private Use organizations:
A private use organization ID need not be registered with IANA. All text form private use organization IDs SHALL match the id-text rule and begin with the bang character "!". All integer form private use organization IDs SHALL be negative.

3.3.2. Model ID

Model IDs are used to segment a full organizational domain into individual object namespaces. There are two types of model IDs corresponding to the two types of namespaces described in the AMM Section 3.1.3 of [I-D.ietf-dtn-amm] as follows.

ADM namespace:
A model ID for an ADM namespace is unique within an organization and, except for private or experimental use, SHOULD be registered with IANA (see Section 10.2) or an organization-specific authority. All text form ADM model IDs SHALL match the id-text rule of Section 4.1and not begin with the bang character "!". All integer form ADM model IDs SHALL be non-negative.
ODM namespace:
A model IDs for an ODM namespace does not have universal registration and SHALL be considered to be private use. It is expected that runtime ODM namespaces will be allocated and managed per-user and per-mission. All text form ODM model IDs SHALL match the id-text rule and begin with the bang character "!". All integer form ODM model IDs SHALL be negative.

3.3.3. Model Revision

A single ADM is allowed and expected to change over time, and references to objects within an ADM can include an identifier for a specific ADM revision. Each released revision of an ADM SHALL be identified by a specific revision date in the Gregorian calendar. An ARI referencing an object within an ADM MAY contain a specific model revision.

Because an ODM is expected to be dynamic and modified during Agent runtime, there is no meaning to a revision on an ODM. An ARI referencing an object within an ODM SHALL NOT contain a model revision.

The internal representation of revision dates is an implementation matter, but the encoded representations defined in this document include both text and integer form consistent with external standards (cited by the encodings of Section 4 and Section 5). Note that because ARI structure includes some recursion (e.g., object reference parameters and container members are themselves ARIs), it is possible to have a model revision present at any depth of a complex ARI.

Because an Agent is able to implement only a single revision of any model, the model revision data SHALL NOT be present in an ARI being communicated to or from an Agent. If an Agent receives an ARI containing model revision information and that is inconsistent with the revision implemented by the Agent, it is an implementation matter for how to detect and handle the inconsistency.

The reason for including revision information in an ARI is to allow a Manager to keep that information intrinsic to the rest of the ARI in its own bookkeeping. A Manager SHALL recursively remove any model revision(s) before transmitting an ARI to an Agent, which satisfies the earlier paragraph. A Manager MAY add model revision(s) to an ARI received from an Agent to help its own data bookkeeping.

3.3.4. Object Type

Due to the flat structure of an ADM, as defined in Section 4 of [I-D.ietf-dtn-amm], all managed objects are of a specific and unchanging type from a set of available DTNMA object types. The preferred form for object types in text ARIs is the text name, while in binary form it is the integer enumeration (see Section 7). Both of these forms have values registered with IANA in Table 3.

The following subsection explains the form of those object identifiers.

3.3.5. Object ID

Within a single ADM or ODM namespace and a single object type, all managed objects have similar characteristics and all objects are identified by a single text name or integer enumeration. The preferred form for object names in text ARIs is the text name, while in binary form it is the integer enumeration.

Any ADM-defined object will have both name and enumeration, while a ODM-defined object can have either but not both. Conversion between the two forms requires access to the original ADM, and its specific revision, in which the object was defined. All text form object names SHALL match the id-text rule of Section 4.1..

3.3.6. Parameters

The ADM logical schema allows many object types to be parameterized when defined in the context of an application or a protocol.

If two instances of an ADM resource have the same namespace and same object type and object name but have different parameter values, then those instances are unique and the ARIs for those instances SHALL also be unique. Therefore, parameters are considered part of the ARI syntax.

The ADM logical schema defines specialized uses for the term "parameter" to disambiguate each purpose, as defined below.

Formal Parameters:
Formal parameters define the type, name, and order of the information that customizes an ARI. They represent the unchanging "signature" of the parameterized object. Because ARIs represent a use of an object and not its definition, formal parameters are not present in an ARI and instead are part of an object model.
Given Parameters:

Given parameters represent the data values used to distinguish different instances of a parameterized object. A given parameter is an AMM value and is represented by an ARI within the context of a parameter list (AC) or parameter map (AM). Because of necessary normalizing (of type and default value) based on formal parameters, multiple given parameters can correspond with the same meaning (see Actual Parameters below).

Additionally, there are two ways in which the value of a given parameter can be specified: parameter-by-value and parameter-by-name.

Parameter-By-Value:
This method involves directly supplying the value as part of the actual parameter. It is the default method for supplying values.
Parameter-By-Name:
This method involves specifying the name of an other parameter and using that other parameter's value as a substitute for the value of this parameter. This method is useful when a parameterized ARI is produced by an AMM object which itself is parameterized. The original ARI parameters contain literal ARIs with LABEL type, and when the value is produced based on input parameters the substitution is made. In this way, an actual parameter can be "flowed down" to produced values at runtime.
Actual Parameters:

Actual parameters represent a normalized set of values taken from a set of given parameters and normalized using a set of corresponding formal parameters. An actual parameter is an AMM value and is represented by an ARI.

Because normalizing can cause a given parameter to change type (in order to conform to a formal parameter type) or take on a default value (when not present in the given parameters), a single set of actual parameters can correspond with multiple options for given parameters.

3.4. Namespace References

A namespace reference is composed of the same initial parts as an object reference: the organization ID and model ID with optional model revision. These are used to refer to an entire ADM or ODM namespace. It is treated as a separate class of ARI in order to separate it from the additional required parts of an Object Reference (object type and object ID) and optional given parameters. The purpose of a namespace reference is to give an ARI value to the whole namespace separately from any of its contained objects.

4.