Delay-Tolerant Networking E.J. Birrane
Internet-Draft JHU/APL
Intended status: Standards Track E.A. Annis
Expires: 20 June 2022 Johns Hopkins Applied Physics Laboratory
17 December 2021
AMM Resource Identifier
draft-birrane-dtn-ari-00
Abstract
This document defines the structure, format, and features of the
naming scheme for the objects defined in the Delay-Tolerant
Networking Autonomous Management Model (AMM), in support of
challenged network management solutions described in the Delay-
Tolerant Networking Autonomous Management Architecture (AMA).
This document defines a new AMM Resource Identifier (ARI), based on
the structure of a common URI, meeting the needs for a concise,
typed, parameterized, and hierarchically organized set of 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 20 June 2022.
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
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.
Birrane & Annis Expires 20 June 2022 [Page 1]
Internet-Draft ARI December 2021
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. ARI Scheme Utility . . . . . . . . . . . . . . . . . . . . . 5
4.1. Resource Parameterization . . . . . . . . . . . . . . . . 5
4.2. Compressible Structure . . . . . . . . . . . . . . . . . 6
4.2.1. Relative Paths . . . . . . . . . . . . . . . . . . . 6
4.2.2. Path Suffixing . . . . . . . . . . . . . . . . . . . 6
4.2.3. Patterning . . . . . . . . . . . . . . . . . . . . . 6
5. ARI Component Definitions . . . . . . . . . . . . . . . . . . 7
5.1. Namespaces . . . . . . . . . . . . . . . . . . . . . . . 7
5.1.1. Anonymous Namespaces . . . . . . . . . . . . . . . . 7
5.1.2. Regular Namespaces . . . . . . . . . . . . . . . . . 7
5.1.2.1. Moderated Namespaces . . . . . . . . . . . . . . 8
5.1.2.2. Informal Namespaces . . . . . . . . . . . . . . . 8
5.2. Object . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.3. Parameters . . . . . . . . . . . . . . . . . . . . . . . 9
5.3.1. Formal Parameters . . . . . . . . . . . . . . . . . . 9
5.3.2. Actual Parameters . . . . . . . . . . . . . . . . . . 9
5.4. Special Case: Literal Values . . . . . . . . . . . . . . 10
6. ARI Scheme Syntax . . . . . . . . . . . . . . . . . . . . . . 11
6.1. Literal String Encoding . . . . . . . . . . . . . . . . . 12
6.2. Delimiting Characters . . . . . . . . . . . . . . . . . . 12
6.2.1. Wildcards . . . . . . . . . . . . . . . . . . . . . . 12
7. Encoding Considerations . . . . . . . . . . . . . . . . . . . 12
8. Scheme Registration Considerations . . . . . . . . . . . . . 13
9. Interoperability Considerations . . . . . . . . . . . . . . . 13
10. Security Considerations . . . . . . . . . . . . . . . . . . . 13
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
11.1. ARI Scheme . . . . . . . . . . . . . . . . . . . . . . . 14
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
12.1. Normative References . . . . . . . . . . . . . . . . . . 14
12.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 15
A.1. Namespace Examples . . . . . . . . . . . . . . . . . . . 15
A.2. Object Examples . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
Birrane & Annis Expires 20 June 2022 [Page 2]
Internet-Draft ARI December 2021
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) [I-D.ietf-dtn-bpbis], 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 Autonomous Management Architecture (DTN AMA)
[I-D.ietf-dtn-ama] 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 DTN Asynchronous Management Model (DTN AMM) [I-D.birrane-dtn-adm]
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
DTN AMM further describes a physical data model, called the
Application Data Model, that can be defined in the context of
applications to create resources in accordance with the DTN AMM
logical schema. These named resources can be predefined in moderated
publications or custom-defined as part of the operational management
of a network or a node.
Every AMM resource must be uniquely identifiable. To accomplish
this, an expressive naming scheme is required. The AMM Resource
Identifier (ARI) provides this naming scheme. This document defines
an ARI, based on the structure of a URI, meeting the needs for a
concise, typed, parameterized, and hierarchically organized naming
convention.
Birrane & Annis Expires 20 June 2022 [Page 3]
Internet-Draft ARI December 2021
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
DTN 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 definition 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 AMA 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.
This specification does not describe the ways in which an ARI could
be encoded into other formats, to include compressed binary formats.
However, the design of the ARI syntax discusses compressibility to
the extent that the design impacts the ability to create such
encodings.
2. Requirements Language
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.
3. Terminology
* DTN Autonomous Management Model (AMM) - data types and data
structures needed to manage applications in challenged networks.
Birrane & Annis Expires 20 June 2022 [Page 4]
Internet-Draft ARI December 2021
* AMM Resource Identifier (ARI) - A unique identifier for any AMM
object, syntactically conformant to the Uniform Resource
Identifier (URI) syntax documented in [RFC3986] and using the
scheme name "ari".
* AMM Namespace - A moderated, hierarchical taxonomy of namespaces
that describe a set of AMM scopes. Specifically, an individual
AMM namespace is a specific sequence of AMM namespaces, from most
general to most specific, that uniquely and unambiguously identify
the namespace of a particular AMM.
* Operational Data Model (ODM) - The operational configuration of an
Agent. This includes the union of all ADM information supported
by the Agent as well as all operational, dynamic configuration
applied to the Agent by Managers in the network.
4. ARI Scheme Utility
AMM resources are referenced in the context of autonomous
applications on an agent. The naming scheme of these resources must
support certain features to inform AMA processing in accordance with
the AMM logical schema.
This section defines the set of unique characteristics of the 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.
4.1. Resource Parameterization
The AMM 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.
Birrane & Annis Expires 20 June 2022 [Page 5]
Internet-Draft ARI December 2021
4.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.
While the encoding of an ARI is outside of the scope of this
document, the structure of portions of the ARI syntax lend themselves
to better compressibility. For example, DTN AMM encodings support
the ability to identify resources in as few as 3 bytes by exploiting
the compressible structure of the ARI.
The ARI syntax supports three design elements to aid in the creation
of more concise encodings: relative paths, path suffixing, and
patterning.
4.2.1. Relative Paths
Hierarchical structures are well known to support compressible
encodings by strategically enumerating well-known branching points in
a hierarchy. For this reason, the ARI syntax uses the URI path to
implement a naming hierarchy.
Supporting relative paths allow for the ARI namespace to be shortened
relative to a well-known prefix. By eliminating the need to repeat
common path prefixes in ARIs (in any encoding) the size of any given
ARI can be reduced.
This relative prefix might be relative to an existing location, such
as the familiar "../item" or relative to a defined nickname for a
particular path prefix, such as "{root}/item".
4.2.2. Path Suffixing
Path suffixing refers to specifying how information close to the
"leaf" node of a hierarchy is structured. By codifying this
structure into the ARI syntax, elements of the AMM logical scheme can
be enumerated and compressed in the same way for any physical data
model instantiation of an ARI.
4.2.3. Patterning
Patterning in this context refers to the structuring of ARI
information to allow for meaning data selection as a function of
wildcards, regular expressions, and other expressions of a pattern.
Birrane & Annis Expires 20 June 2022 [Page 6]
Internet-Draft ARI December 2021
Patterns allow for both better compression and fewer ARI
representations by allowing a single ARI pattern to stand-in for a
variety of actual ARIs.
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.
5. ARI Component Definitions
This section describes the components of the ARI scheme to inform the
discussion of the ARI syntax in Section Section 6. These components
include ARI Namespaces, Object Names, Parameters, and Special
Representations.
5.1. Namespaces
AMM resources exist within namespaces to eliminate the chance of a
conflicting resource name, aid in the application of patterns, and
improve the compressibility of the ARI. Namespaces 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
in an ARI.
The AMM defines two types of namespaces whose representation within
an ARI is slight different: Regular Namespaces and Anonymous
Namespaces.
5.1.1. Anonymous Namespaces
The ARI syntax supports the definition of AMM resources absent a
containing namespace. In this sense, the resource is considered
"anonymous" in that it is not placeable in a particular hierarchy
and, thus, not able to be located based on relative paths, patterns
over the namespace hierarchy, or other characteristic based on the
namespace.
Anonymous namespaces are most effectively used for the representation
of literal values and constants that have utility and definition that
is not otherwise associated with a single namespace.
For example, the representation of the strongly typed integer value 4
could be representing using the anonymous namespace as: ari:uint(4)
5.1.2. Regular Namespaces
A regular namespace is simply any namespace other than the empty
namespace reserved for anonymous ARIs.
Birrane & Annis Expires 20 June 2022 [Page 7]
Internet-Draft ARI December 2021
Namespaces are hierarchical, which allows the grouping of resources
that share common attributes - for example, resources associated with
related protocols may have protocol-specific namespaces that are
grouped under a single encompassing namespace. Namespaces that are
closer to a "root node" in a hierarchy have broader scope than
namespaces closer to "leaf nodes" in the same hierarchy.
In a hierarchical model of namespaces, a particular namespace is
identified as the path to that namespace through the hierarchy. The
ARI encodes this path with the URI path attribute.
The ARI scheme defines two types of namespaces: moderated and
informal.
5.1.2.1. Moderated Namespaces
Moderated namespaces identify AMM resources that have been defined in
a normative, moderated way by some standards organization. These
resources are immutable and can be relied on the be define and used
the same way across multiple networks and multiple implementations.
Because the source of the resource definition in a moderated
namespace represents an authoritative reference to this object,
moderated namespaces always include an authority segment.
5.1.2.2. Informal Namespaces
Informal namespaces represent resources that are only defined in the
context of a specific network, mission, or application or those
resources that might only be defined for a certain period of time.
Unlike moderated namespaces, informal namespaces have no defined
authority associated with them. The path representing these
namespaces may be any valid path.
The general form of an informal namespace is given as:
<ISSUER>/<TAG>.
An Issuer is any string that identifies the organization that is
defining an AMM object. This value may come from a global registry
of organizations, an issuing node address, a signed known value, or
some other network-unique marking. Issuers MUST NOT conflict with
known moderated namespaces, and AMA Agents and Managers should not
process Issuers that conflict with existing moderated namespaces.
Birrane & Annis Expires 20 June 2022 [Page 8]
Internet-Draft ARI December 2021
A Tag is any (optional) string used to disambiguate AMM Objects for
an Issuer. The contents of the tag are left to the discretion of the
Issuer. Examples of potential tag values include an issuer-known
version number or a (signed) hashing of the data item associated with
the reference identifier.
5.2. Object
An object is any one of a number of data elements defined for the
management of a given application or protocol that conforms to the
AMM logical schema.
Objects are identified in the ARI scheme by the catenation of their
AMM logical schema type and a string name. Additionally, objects may
be further differentiated by any parameters defined for that object.
5.3. Parameters
The AMM 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 AMM 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 MUST also
be unique. Therefore, parameters are considered part of the ARI
syntax.
The AMM logical schema defines two types of parameters: Formal and
Actual. The terms formal parameter and actual parameter follow
common computer programming vernacular for discussing function
declarations and function calls, respectively.
5.3.1. Formal Parameters
Formal parameters define the type, name, and order of the information
that customizes an ARI. They represent the unchanging "definition"
of the parameterized object.
Formal parameters MUST include type and name information and MAY
include an optional default value. If specified, a default value
will be used whenever a set of actual parameters fails to provide a
value for this formal parameter.
5.3.2. Actual Parameters
Actual parameters represent the data values used to distinguish
different instances of a parameterized object.
Birrane & Annis Expires 20 June 2022 [Page 9]
Internet-Draft ARI December 2021
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. An actual parameter MUST NOT include NAME information.
Including type information in an actual parameters allows for
explicit type checking of a value, which might otherwise be
implicitely cast.
There are two ways in which the value of an actual 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 some other
parameter and using that other parameter's value for the
value of this parameter. This method is useful when a
parameterized ARI contains another parameterized ARI. The
contained object's actual parameter can be given as the name
of the containing ARI's parameter. In that way, a containing
ARI's parameters can be "flowed down" to all of the objects
it contains.
NOTE: 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 amongst Managers and
Agents in a network.
5.4. Special Case: Literal Values
A literal value is one whose value and name are equivalent. The name
is, literally, the value. For example, the literal "4" serves as
both a name and a value. When literal values are represented, the
object name MUST be omitted and the literal value substituted as a
parameterization of the object.
Further, because the value of a Literal serves as its name, there is
no need for regular namespaces. All literals exist in the anonymous
namespace.
Birrane & Annis Expires 20 June 2022 [Page 10]
Internet-Draft ARI December 2021
6. ARI Scheme Syntax
There are three components to the ARI: namespaces, objects, and
parameters. This section defines the syntactic representation of
each of these components, and discusses special cases.
The scheme name of the ARI is "ari". The scheme-specific part of the
"ari" scheme follows the format:
ari:/<Namespace>/<Object><(Parameters)> The string representation of
each component is given as follows.
Namespaces
Namespaces are represented as "/" separated lists, with
individual namespace types represented as follows:
* Moderated namespaces are listed using a URI authority
representing the normative moderator for the resource
followed by a URI path relative to that moderator.
For example: "ari://sdo/ietf/dtn/adm/bp/".
* Anonymous namespaces are empty and are represented as the
lack of a starting / or //.
For example: "ari:type.name(parm)".
* Informal namespaces are URI paths without a URI authority
present.
For example: "ari:/myproject/dtn/bp/dynamic".
Objects
The object name is represented as the two-tuple of the object
type and the object name, joined with the '.' character.
For example: "uint.num_bundles".
Parameters
If present, parameters are represented as a comma-separated
string enclosed in parenthesis. Different types of
parameters are represented as follows.
* Formal parameters follow the pattern <type> <name> and if
there is a default value, it is represented by the
substring "= <value>".
* Actual Parameters-By-Value are represented as the string
encoding of their value.
Birrane & Annis Expires 20 June 2022 [Page 11]
Internet-Draft ARI December 2021
* Actual Parameters-By-Name are represented as the name of
the parameter enclosed in angle brackets.
Note: If an actual parameter is missing for a formal
parameter that has a default value, then the ARI MUST have a
blank space where the actual parameter would have been. This
missing parameter will also have a comma, separating it from
other actual parameters in the ARI string.
6.1. Literal String Encoding
The string representation of a Literal ARI is much simpler and
consists of simply the data type of the Literal followed by the
value, as follows:
"ari:/type(value)"
6.2. Delimiting Characters
For the scheme specific parts, there is no authority to be defined
for the ARI URI. The scheme is separated from the path using a ":"
and the path components are separated and terminated using a "/".
The path is comprised of the namespaces which hierarchally organize
the AMM objects. The object is defined by both its AMM object type
(such as EDD, VAR, RPTT, etc.) and the object name, each separated by
a ".". The object parameters are separated using reserved characters
"{", "}", "[", "]", "(", ")" described below. Finally the "#" sign
is used at the end of the ARI only in cases where custom issuer
specific objects are defined. Example = ari:/top-a/mid-c/low-b/
edd.dtnObject([int dtnObjParam1], [str dtnObjParam2])#custom-issuer-1
6.2.1. Wildcards
TBD
7. Encoding Considerations
ARIs might be represented in a variety of different formats, to
include human-readable strings, structured language representations
(such as XML or JSON), and binary encodings (such as CBOR). An ARI
scheme must support the mechanical translation amongst this diversity
of representations.
An ARI scheme should represent, and differentiate, different kinds of
information using a standard format. Such standard formats should
rely on delimiters and other structural components and not informal
naming conventions.
Birrane & Annis Expires 20 June 2022 [Page 12]
Internet-Draft ARI December 2021
8. Scheme Registration Considerations
This section contains fields required for the URI scheme
registration, following the guidelines in [RFC7595]
TODO: Define characters used for globs, wildcards, expression
matching, etc.
9. Interoperability Considerations
DTN challenged networks might interface with better resourced
networks that are managed using non-DTN management protocols. When
this occurs, the federated network architecture might need to define
management gateways that translate between DTN and non-DTN management
approaches.
NOTE: It is also possible for DTN management be used end-to-end
because this approach can also operate in less challenged networks.
The opposite is not true; non-DTN management approaches should not be
assumed to work in DTN challenged networks.
Where possible, ARIs should be translatable to other, non-DTN
management naming schemes. This translation might not be 1-1, as the
features of the AMM may differ from features in other management
naming schemes. Therefore, it is unlikely that a single naming
scheme can be used for both DTN and non-DTN management.
10. Security Considerations
Policy decisions as to whether anonymous namespaces are allowed in
the system should be determined before network deployment. The use
of an anonymous namespace greatly increases the chances of naming
collisions.
Because informal namespaces are defined by any entity, no security or
permission meaning can be inferred simply from the expression of
namespace.
11. IANA Considerations
This section provides guidance to the Internet Assigned Numbers
Authority (IANA) regarding registration of schema and namespaces
related to the AMM Resource Identifier (ARI), in accordance with BCP
26 [RFC1155].
Birrane & Annis Expires 20 June 2022 [Page 13]
Internet-Draft ARI December 2021
11.1. ARI Scheme
This document defines a new URI scheme, "ari", as defined in
Section 6. This scheme to be registered by IANA here:
https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml
12. References
12.1. Normative References
[I-D.ietf-dtn-bpbis]
Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol
Version 7", Work in Progress, Internet-Draft, draft-ietf-
dtn-bpbis-31, 25 January 2021, <https://www.ietf.org/
internet-drafts/draft-ietf-dtn-bpbis-31.txt>.
[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>.
[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>.
[RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines
and Registration Procedures for URI Schemes", BCP 35,
RFC 7595, DOI 10.17487/RFC7595, June 2015,
<https://www.rfc-editor.org/info/rfc7595>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
12.2. Informative References
[I-D.birrane-dtn-adm]
Birrane, E., DiPietro, E., and D. Linko, "AMA Application
Data Model", Work in Progress, Internet-Draft, draft-
birrane-dtn-adm-03, 2 July 2018, <http://www.ietf.org/
internet-drafts/draft-birrane-dtn-adm-03.txt>.
Birrane & Annis Expires 20 June 2022 [Page 14]
Internet-Draft ARI December 2021
[I-D.ietf-dtn-ama]
Birrane, E. J., Annis, J. E., and S. Heiner, "Asynchronous
Management Architecture", Work in Progress, Internet-
Draft, draft-ietf-dtn-ama-03, 25 October 2021,
<https://www.ietf.org/archive/id/draft-ietf-dtn-ama-
03.txt>.
[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>.
[RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst,
R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant
Networking Architecture", RFC 4838, DOI 10.17487/RFC4838,
April 2007, <https://www.rfc-editor.org/info/rfc4838>.
[RFC7320] Nottingham, M., "URI Design and Ownership", RFC 7320,
DOI 10.17487/RFC7320, July 2014,
<https://www.rfc-editor.org/info/rfc7320>.
[RFC8820] Nottingham, M., "URI Design and Ownership", BCP 190,
RFC 8820, DOI 10.17487/RFC8820, June 2020,
<https://www.rfc-editor.org/info/rfc8820>.
Appendix A. Examples
A.1. Namespace Examples
For example, consider the namespaces in Figure 1.
ARI Namespace Hierarchy
+-------+ +--------+
| SDO | | VENDOR |
+---+---+ +---+----+
| _____|_____
| | |
+-------+ +-------+ +-------+
| IETF | | PROD1 | | PROD2 |
+-------+ +-------+ +-------+
_________|_________ | |
| | | | |
+-------+ +-------+ +-------+ +-------+ +-------+
| APP-1 | | APP-2 | | APP-3 | | APP-4 | | APP-5 |
+-------+ +-------+ +-------+ +-------+ +-------+
Figure 1
Birrane & Annis Expires 20 June 2022 [Page 15]
Internet-Draft ARI December 2021
Given this hierarchy, the following are all valid namespace
representations.
ari://sdo/ietf/
ari://sdo/ietf/app-1/
ari://sdo/ietf/app-3/
ari:/vendor/
ari:/vendor/prod1/
ari:/vendor/prod2/app-5
ari:/
A.2. Object Examples
The ARIs for the following sample AMM objects are encoded in Table 1.
Note that these examples are for the identifiers of AMM objects, not
their entire definition.
* The number of bytes received by an Agent, defined in the N1/N2
namespace and called num_bytes.
* The number of bytes received through an interface, called
num_bytes_if, which takes a single string parameter named
"if_name" with a default value oth "eth0".
* An anonymous, operator-defined object named "obj1" which takes two
unsigned integer parameters, n1 and n2, with default values of 3
and 4, respectively.
* The typed, Literal value of 4.
+========================+========================================+
| ARI String | Description |
+========================+========================================+
| "ari:/N1/N2/num_bytes" | Unparameterized num_bytes object in |
| | the N1/N2 informal namespace. |
+------------------------+----------------------------------------+
| "num_bytes" | Shortform encoding where the N1/N2 |
| | namespace can be assumed. |
+------------------------+----------------------------------------+
| "num_bytes_if(String | Formal parameter definition of |
| if_name)" | num_bytes object that accepts a string |
| | interface name. |
Birrane & Annis Expires 20 June 2022 [Page 16]
Internet-Draft ARI December 2021
+------------------------+----------------------------------------+
| "num_bytes_if(String | Formal parameter definition of |
| if_name=eth0)" | num_bytes object that accepts a string |
| | interface name with a default value. |
+------------------------+----------------------------------------+
| "num_bytes_if()" | Actual parameter using the default |
| | value of eth0. |
+------------------------+----------------------------------------+
| "num_bytes_if(eth0)" | Actual parameter of eth0. |
+------------------------+----------------------------------------+
| "ari:/obj1(Int n1 = 0, | Formal parameter of object obj1 in |
| Int n2 = 3)" | anonymous namespace taking 2 default |
| | parameters. |
+------------------------+----------------------------------------+
| "ari:/obj1(, )" | Actual parameter using the default |
| | values of 0 for n1 and 3 for n2. |
+------------------------+----------------------------------------+
| "ari:/obj1(, 4)" | Actual parameter using the default |
| | value of 0 for n1. |
+------------------------+----------------------------------------+
| "ari:/obj1(4, )" | Actual parameter using the default |
| | value of 3 for n2. |
+------------------------+----------------------------------------+
| "ari:/obj1(4,4)" | Actual parameters provided for all |
| | obj1 parameters. |
+------------------------+----------------------------------------+
| "ari:/obj1(<input>,4)" | Actual parameters provided for all |
| | obj1 parameters, with the value of the |
| | first parameter taken from some other |
| | parameter named "input". |
+------------------------+----------------------------------------+
| "ari:uint(4)" | The Literal value 4 interpreted as a |
| | 32-bit unsigned integer. |
+------------------------+----------------------------------------+
Table 1
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
Birrane & Annis Expires 20 June 2022 [Page 17]
Internet-Draft ARI December 2021
Emery Annis
Johns Hopkins Applied Physics Laboratory
Email: Emery.Annis@jhuapl.edu
Birrane & Annis Expires 20 June 2022 [Page 18]