idnits 2.17.1 draft-birrane-dtn-ari-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (17 December 2021) is 851 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-06) exists of draft-birrane-dtn-adm-03 -- Obsolete informational reference (is this intentional?): RFC 7320 (Obsoleted by RFC 8820) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Delay-Tolerant Networking E.J. Birrane 3 Internet-Draft JHU/APL 4 Intended status: Standards Track E.A. Annis 5 Expires: 20 June 2022 Johns Hopkins Applied Physics Laboratory 6 17 December 2021 8 AMM Resource Identifier 9 draft-birrane-dtn-ari-00 11 Abstract 13 This document defines the structure, format, and features of the 14 naming scheme for the objects defined in the Delay-Tolerant 15 Networking Autonomous Management Model (AMM), in support of 16 challenged network management solutions described in the Delay- 17 Tolerant Networking Autonomous Management Architecture (AMA). 19 This document defines a new AMM Resource Identifier (ARI), based on 20 the structure of a common URI, meeting the needs for a concise, 21 typed, parameterized, and hierarchically organized set of data 22 elements. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on 20 June 2022. 41 Copyright Notice 43 Copyright (c) 2021 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 48 license-info) in effect on the date of publication of this document. 49 Please review these documents carefully, as they describe your rights 50 and restrictions with respect to this document. Code Components 51 extracted from this document must include Revised BSD License text as 52 described in Section 4.e of the Trust Legal Provisions and are 53 provided without warranty as described in the Revised BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 60 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4. ARI Scheme Utility . . . . . . . . . . . . . . . . . . . . . 5 62 4.1. Resource Parameterization . . . . . . . . . . . . . . . . 5 63 4.2. Compressible Structure . . . . . . . . . . . . . . . . . 6 64 4.2.1. Relative Paths . . . . . . . . . . . . . . . . . . . 6 65 4.2.2. Path Suffixing . . . . . . . . . . . . . . . . . . . 6 66 4.2.3. Patterning . . . . . . . . . . . . . . . . . . . . . 6 67 5. ARI Component Definitions . . . . . . . . . . . . . . . . . . 7 68 5.1. Namespaces . . . . . . . . . . . . . . . . . . . . . . . 7 69 5.1.1. Anonymous Namespaces . . . . . . . . . . . . . . . . 7 70 5.1.2. Regular Namespaces . . . . . . . . . . . . . . . . . 7 71 5.1.2.1. Moderated Namespaces . . . . . . . . . . . . . . 8 72 5.1.2.2. Informal Namespaces . . . . . . . . . . . . . . . 8 73 5.2. Object . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 5.3. Parameters . . . . . . . . . . . . . . . . . . . . . . . 9 75 5.3.1. Formal Parameters . . . . . . . . . . . . . . . . . . 9 76 5.3.2. Actual Parameters . . . . . . . . . . . . . . . . . . 9 77 5.4. Special Case: Literal Values . . . . . . . . . . . . . . 10 78 6. ARI Scheme Syntax . . . . . . . . . . . . . . . . . . . . . . 11 79 6.1. Literal String Encoding . . . . . . . . . . . . . . . . . 12 80 6.2. Delimiting Characters . . . . . . . . . . . . . . . . . . 12 81 6.2.1. Wildcards . . . . . . . . . . . . . . . . . . . . . . 12 82 7. Encoding Considerations . . . . . . . . . . . . . . . . . . . 12 83 8. Scheme Registration Considerations . . . . . . . . . . . . . 13 84 9. Interoperability Considerations . . . . . . . . . . . . . . . 13 85 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 86 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 87 11.1. ARI Scheme . . . . . . . . . . . . . . . . . . . . . . . 14 88 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 89 12.1. Normative References . . . . . . . . . . . . . . . . . . 14 90 12.2. Informative References . . . . . . . . . . . . . . . . . 14 91 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 15 92 A.1. Namespace Examples . . . . . . . . . . . . . . . . . . . 15 93 A.2. Object Examples . . . . . . . . . . . . . . . . . . . . . 16 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 96 1. Introduction 98 The unique limitations of Delay-Tolerant Networking (DTN) transport 99 capabilities [RFC4838] necessitate increased reliance on individual 100 node behavior. These limitations are considered part of the expected 101 operational environment of the system and, thus, contemporaneous end- 102 to-end data exchange cannot be considered a requirement for 103 successful communication. 105 The primary DTN transport mechanism, Bundle Protocol version 7, 106 (BPv7) [I-D.ietf-dtn-bpbis], standardizes a store-and-forward 107 behavior required to communicate effectively between endpoints that 108 may never co-exist in a single network partition. BPv7 might be 109 deployed in static environments, but the design and operation of BPv7 110 cannot presume that to be the case. 112 Similarly, the management of any BPv7 protocol agent (BPA) (or any 113 software reliant upon DTN for its communication) cannot presume to 114 operate in a resourced, connected network. Just as DTN transport 115 must be delay-tolerant, DTN network management must also be delay- 116 tolerant. 118 The DTN Autonomous Management Architecture (DTN AMA) 119 [I-D.ietf-dtn-ama] outlines an architecture that achieves this result 120 through the self-management of a DTN node as configured by one or 121 more remote managers in an asynchronous and open-loop system. An 122 important part of this architecture is the definition of a conceptual 123 data schema for defining resources configured by remote managers and 124 implemented by the local autonomy of a DTN node. 126 The DTN Asynchronous Management Model (DTN AMM) [I-D.birrane-dtn-adm] 127 defines a logical schema that can be used to represent data types and 128 structures, autonomous controls, and other kinds of information 129 expected to be required for the local management of a DTN node. The 130 DTN AMM further describes a physical data model, called the 131 Application Data Model, that can be defined in the context of 132 applications to create resources in accordance with the DTN AMM 133 logical schema. These named resources can be predefined in moderated 134 publications or custom-defined as part of the operational management 135 of a network or a node. 137 Every AMM resource must be uniquely identifiable. To accomplish 138 this, an expressive naming scheme is required. The AMM Resource 139 Identifier (ARI) provides this naming scheme. This document defines 140 an ARI, based on the structure of a URI, meeting the needs for a 141 concise, typed, parameterized, and hierarchically organized naming 142 convention. 144 1.1. Scope 146 The ARI scheme is based on the structure of a URI [RFC3986] in 147 accordance with the practices outlined in [RFC8820]. 149 ARIs are designed to support the identification requirements of the 150 DTN AMM logical schema. As such, this specification will discuss 151 these requirements to the extent necessary to explain the structure 152 and use of the ARI syntax. 154 This specification does not constrain the syntax or structure of any 155 existing URI (or part thereof). As such, the ARI scheme does not 156 impede the ownership of any other URI definition and is therefore 157 clear of the concerns presented in [RFC7320]. 159 This specification does not discuss the manner in which ARIs might be 160 generated, populated, and used by applications. The operational 161 utility and configuration of ARIs in a system are described in other 162 documents associated with DTN management, to include the AMA and AMM 163 specifications. 165 This specification does not describe the way in which path prefixes 166 associated with an ARI are standardized, moderated, or otherwise 167 populated. Path suffixes may be specified where they do not lead to 168 collision or ambiguity. 170 This specification does not describe the mechanisms for generating 171 either standardized or custom ARIs in the context of any given 172 application, protocol, or network. 174 This specification does not describe the ways in which an ARI could 175 be encoded into other formats, to include compressed binary formats. 176 However, the design of the ARI syntax discusses compressibility to 177 the extent that the design impacts the ability to create such 178 encodings. 180 2. Requirements Language 182 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 183 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 184 document are to be interpreted as described in BCP 14 [RFC2119] 185 [RFC8174] when, and only when, they appear in all capitals, as shown 186 here. 188 3. Terminology 190 * DTN Autonomous Management Model (AMM) - data types and data 191 structures needed to manage applications in challenged networks. 193 * AMM Resource Identifier (ARI) - A unique identifier for any AMM 194 object, syntactically conformant to the Uniform Resource 195 Identifier (URI) syntax documented in [RFC3986] and using the 196 scheme name "ari". 198 * AMM Namespace - A moderated, hierarchical taxonomy of namespaces 199 that describe a set of AMM scopes. Specifically, an individual 200 AMM namespace is a specific sequence of AMM namespaces, from most 201 general to most specific, that uniquely and unambiguously identify 202 the namespace of a particular AMM. 204 * Operational Data Model (ODM) - The operational configuration of an 205 Agent. This includes the union of all ADM information supported 206 by the Agent as well as all operational, dynamic configuration 207 applied to the Agent by Managers in the network. 209 4. ARI Scheme Utility 211 AMM resources are referenced in the context of autonomous 212 applications on an agent. The naming scheme of these resources must 213 support certain features to inform AMA processing in accordance with 214 the AMM logical schema. 216 This section defines the set of unique characteristics of the ARI 217 scheme, the combination of which provides a unique utility for 218 naming. While certain other naming schemes might incorporate certain 219 elements, there are no such schemes that both support needed features 220 and exclude prohibited features. 222 4.1. Resource Parameterization 224 The AMM schema allows for the parameterization of resources to both 225 reduce the overall data volume communicated between DTN nodes and to 226 remove the need for any round-trip data negotiation. 228 Parameterization reduces the communicated data volume when parameters 229 are used as filter criteria. By associating a parameter with a data 230 source, data characteristic, or other differentiating attribute, DTN 231 nodes can locally process parameters to construct the minimal set of 232 information to either process for local autonomy or report to remote 233 managers in the network. 235 Parameterization eliminates the need for round-trip negotiation to 236 identify where information is located or how it should be accessed. 237 When parameters define the ability to perform an associative lookup 238 of a value, the index or location of the data at a particular DTN 239 node can be resolved locally as part of the local autonomy of the 240 node and not communicated back to a remote manager. 242 4.2. Compressible Structure 244 The ability to encode information in very concise formats enables DTN 245 communications in a variety of ways. Reduced message sizes increase 246 the likelihood of message delivery, require fewer processing 247 resources to secure, store, and forward, and require less resources 248 to transmit. 250 While the encoding of an ARI is outside of the scope of this 251 document, the structure of portions of the ARI syntax lend themselves 252 to better compressibility. For example, DTN AMM encodings support 253 the ability to identify resources in as few as 3 bytes by exploiting 254 the compressible structure of the ARI. 256 The ARI syntax supports three design elements to aid in the creation 257 of more concise encodings: relative paths, path suffixing, and 258 patterning. 260 4.2.1. Relative Paths 262 Hierarchical structures are well known to support compressible 263 encodings by strategically enumerating well-known branching points in 264 a hierarchy. For this reason, the ARI syntax uses the URI path to 265 implement a naming hierarchy. 267 Supporting relative paths allow for the ARI namespace to be shortened 268 relative to a well-known prefix. By eliminating the need to repeat 269 common path prefixes in ARIs (in any encoding) the size of any given 270 ARI can be reduced. 272 This relative prefix might be relative to an existing location, such 273 as the familiar "../item" or relative to a defined nickname for a 274 particular path prefix, such as "{root}/item". 276 4.2.2. Path Suffixing 278 Path suffixing refers to specifying how information close to the 279 "leaf" node of a hierarchy is structured. By codifying this 280 structure into the ARI syntax, elements of the AMM logical scheme can 281 be enumerated and compressed in the same way for any physical data 282 model instantiation of an ARI. 284 4.2.3. Patterning 286 Patterning in this context refers to the structuring of ARI 287 information to allow for meaning data selection as a function of 288 wildcards, regular expressions, and other expressions of a pattern. 290 Patterns allow for both better compression and fewer ARI 291 representations by allowing a single ARI pattern to stand-in for a 292 variety of actual ARIs. 294 This benefit is best achieved when the structure of the ARI is both 295 expressive enough to include information that is useful to pattern 296 match, and regular enough to understand how to create these patterns. 298 5. ARI Component Definitions 300 This section describes the components of the ARI scheme to inform the 301 discussion of the ARI syntax in Section Section 6. These components 302 include ARI Namespaces, Object Names, Parameters, and Special 303 Representations. 305 5.1. Namespaces 307 AMM resources exist within namespaces to eliminate the chance of a 308 conflicting resource name, aid in the application of patterns, and 309 improve the compressibility of the ARI. Namespaces MUST NOT be used 310 as a security mechanism. An Agent or Manager MUST NOT infer security 311 information or access control based solely on namespace information 312 in an ARI. 314 The AMM defines two types of namespaces whose representation within 315 an ARI is slight different: Regular Namespaces and Anonymous 316 Namespaces. 318 5.1.1. Anonymous Namespaces 320 The ARI syntax supports the definition of AMM resources absent a 321 containing namespace. In this sense, the resource is considered 322 "anonymous" in that it is not placeable in a particular hierarchy 323 and, thus, not able to be located based on relative paths, patterns 324 over the namespace hierarchy, or other characteristic based on the 325 namespace. 327 Anonymous namespaces are most effectively used for the representation 328 of literal values and constants that have utility and definition that 329 is not otherwise associated with a single namespace. 331 For example, the representation of the strongly typed integer value 4 332 could be representing using the anonymous namespace as: ari:uint(4) 334 5.1.2. Regular Namespaces 336 A regular namespace is simply any namespace other than the empty 337 namespace reserved for anonymous ARIs. 339 Namespaces are hierarchical, which allows the grouping of resources 340 that share common attributes - for example, resources associated with 341 related protocols may have protocol-specific namespaces that are 342 grouped under a single encompassing namespace. Namespaces that are 343 closer to a "root node" in a hierarchy have broader scope than 344 namespaces closer to "leaf nodes" in the same hierarchy. 346 In a hierarchical model of namespaces, a particular namespace is 347 identified as the path to that namespace through the hierarchy. The 348 ARI encodes this path with the URI path attribute. 350 The ARI scheme defines two types of namespaces: moderated and 351 informal. 353 5.1.2.1. Moderated Namespaces 355 Moderated namespaces identify AMM resources that have been defined in 356 a normative, moderated way by some standards organization. These 357 resources are immutable and can be relied on the be define and used 358 the same way across multiple networks and multiple implementations. 360 Because the source of the resource definition in a moderated 361 namespace represents an authoritative reference to this object, 362 moderated namespaces always include an authority segment. 364 5.1.2.2. Informal Namespaces 366 Informal namespaces represent resources that are only defined in the 367 context of a specific network, mission, or application or those 368 resources that might only be defined for a certain period of time. 370 Unlike moderated namespaces, informal namespaces have no defined 371 authority associated with them. The path representing these 372 namespaces may be any valid path. 374 The general form of an informal namespace is given as: 375 /. 377 An Issuer is any string that identifies the organization that is 378 defining an AMM object. This value may come from a global registry 379 of organizations, an issuing node address, a signed known value, or 380 some other network-unique marking. Issuers MUST NOT conflict with 381 known moderated namespaces, and AMA Agents and Managers should not 382 process Issuers that conflict with existing moderated namespaces. 384 A Tag is any (optional) string used to disambiguate AMM Objects for 385 an Issuer. The contents of the tag are left to the discretion of the 386 Issuer. Examples of potential tag values include an issuer-known 387 version number or a (signed) hashing of the data item associated with 388 the reference identifier. 390 5.2. Object 392 An object is any one of a number of data elements defined for the 393 management of a given application or protocol that conforms to the 394 AMM logical schema. 396 Objects are identified in the ARI scheme by the catenation of their 397 AMM logical schema type and a string name. Additionally, objects may 398 be further differentiated by any parameters defined for that object. 400 5.3. Parameters 402 The AMM logical schema allows many object types to be parameterized 403 when defined in the context of an application or a protocol. 405 If two instances of an AMM resource have the same namespace and same 406 object type and object name but have different parameter values, then 407 those instances are unique and the ARIs for those instances MUST also 408 be unique. Therefore, parameters are considered part of the ARI 409 syntax. 411 The AMM logical schema defines two types of parameters: Formal and 412 Actual. The terms formal parameter and actual parameter follow 413 common computer programming vernacular for discussing function 414 declarations and function calls, respectively. 416 5.3.1. Formal Parameters 418 Formal parameters define the type, name, and order of the information 419 that customizes an ARI. They represent the unchanging "definition" 420 of the parameterized object. 422 Formal parameters MUST include type and name information and MAY 423 include an optional default value. If specified, a default value 424 will be used whenever a set of actual parameters fails to provide a 425 value for this formal parameter. 427 5.3.2. Actual Parameters 429 Actual parameters represent the data values used to distinguish 430 different instances of a parameterized object. 432 An actual parameter MUST specify a value and MAY specify a type. If 433 a type is provided it MUST match the type provided by the formal 434 parameter. An actual parameter MUST NOT include NAME information. 436 Including type information in an actual parameters allows for 437 explicit type checking of a value, which might otherwise be 438 implicitely cast. 440 There are two ways in which the value of an actual parameter can be 441 specified: parameter-by-value and parameter-by-name. 443 Parameter-By-Value 444 This method involves directly supplying the value as part of 445 the actual parameter. It is the default method for supplying 446 values. 448 Parameter-By-Name 449 This method involves specifying the name of some other 450 parameter and using that other parameter's value for the 451 value of this parameter. This method is useful when a 452 parameterized ARI contains another parameterized ARI. The 453 contained object's actual parameter can be given as the name 454 of the containing ARI's parameter. In that way, a containing 455 ARI's parameters can be "flowed down" to all of the objects 456 it contains. 458 NOTE: In cases where a formal parameter contains a default value, the 459 associated actual parameter may be omitted. Default values in formal 460 parameters (and, thus, optional actual parameters) are encouraged as 461 they reduce the size of data items communicated amongst Managers and 462 Agents in a network. 464 5.4. Special Case: Literal Values 466 A literal value is one whose value and name are equivalent. The name 467 is, literally, the value. For example, the literal "4" serves as 468 both a name and a value. When literal values are represented, the 469 object name MUST be omitted and the literal value substituted as a 470 parameterization of the object. 472 Further, because the value of a Literal serves as its name, there is 473 no need for regular namespaces. All literals exist in the anonymous 474 namespace. 476 6. ARI Scheme Syntax 478 There are three components to the ARI: namespaces, objects, and 479 parameters. This section defines the syntactic representation of 480 each of these components, and discusses special cases. 482 The scheme name of the ARI is "ari". The scheme-specific part of the 483 "ari" scheme follows the format: 484 ari://<(Parameters)> The string representation of 485 each component is given as follows. 487 Namespaces 488 Namespaces are represented as "/" separated lists, with 489 individual namespace types represented as follows: 491 * Moderated namespaces are listed using a URI authority 492 representing the normative moderator for the resource 493 followed by a URI path relative to that moderator. 495 For example: "ari://sdo/ietf/dtn/adm/bp/". 497 * Anonymous namespaces are empty and are represented as the 498 lack of a starting / or //. 500 For example: "ari:type.name(parm)". 502 * Informal namespaces are URI paths without a URI authority 503 present. 505 For example: "ari:/myproject/dtn/bp/dynamic". 507 Objects 508 The object name is represented as the two-tuple of the object 509 type and the object name, joined with the '.' character. 511 For example: "uint.num_bundles". 513 Parameters 514 If present, parameters are represented as a comma-separated 515 string enclosed in parenthesis. Different types of 516 parameters are represented as follows. 518 * Formal parameters follow the pattern and if 519 there is a default value, it is represented by the 520 substring "= ". 522 * Actual Parameters-By-Value are represented as the string 523 encoding of their value. 525 * Actual Parameters-By-Name are represented as the name of 526 the parameter enclosed in angle brackets. 528 Note: If an actual parameter is missing for a formal 529 parameter that has a default value, then the ARI MUST have a 530 blank space where the actual parameter would have been. This 531 missing parameter will also have a comma, separating it from 532 other actual parameters in the ARI string. 534 6.1. Literal String Encoding 536 The string representation of a Literal ARI is much simpler and 537 consists of simply the data type of the Literal followed by the 538 value, as follows: 540 "ari:/type(value)" 542 6.2. Delimiting Characters 544 For the scheme specific parts, there is no authority to be defined 545 for the ARI URI. The scheme is separated from the path using a ":" 546 and the path components are separated and terminated using a "/". 547 The path is comprised of the namespaces which hierarchally organize 548 the AMM objects. The object is defined by both its AMM object type 549 (such as EDD, VAR, RPTT, etc.) and the object name, each separated by 550 a ".". The object parameters are separated using reserved characters 551 "{", "}", "[", "]", "(", ")" described below. Finally the "#" sign 552 is used at the end of the ARI only in cases where custom issuer 553 specific objects are defined. Example = ari:/top-a/mid-c/low-b/ 554 edd.dtnObject([int dtnObjParam1], [str dtnObjParam2])#custom-issuer-1 556 6.2.1. Wildcards 558 TBD 560 7. Encoding Considerations 562 ARIs might be represented in a variety of different formats, to 563 include human-readable strings, structured language representations 564 (such as XML or JSON), and binary encodings (such as CBOR). An ARI 565 scheme must support the mechanical translation amongst this diversity 566 of representations. 568 An ARI scheme should represent, and differentiate, different kinds of 569 information using a standard format. Such standard formats should 570 rely on delimiters and other structural components and not informal 571 naming conventions. 573 8. Scheme Registration Considerations 575 This section contains fields required for the URI scheme 576 registration, following the guidelines in [RFC7595] 578 TODO: Define characters used for globs, wildcards, expression 579 matching, etc. 581 9. Interoperability Considerations 583 DTN challenged networks might interface with better resourced 584 networks that are managed using non-DTN management protocols. When 585 this occurs, the federated network architecture might need to define 586 management gateways that translate between DTN and non-DTN management 587 approaches. 589 NOTE: It is also possible for DTN management be used end-to-end 590 because this approach can also operate in less challenged networks. 591 The opposite is not true; non-DTN management approaches should not be 592 assumed to work in DTN challenged networks. 594 Where possible, ARIs should be translatable to other, non-DTN 595 management naming schemes. This translation might not be 1-1, as the 596 features of the AMM may differ from features in other management 597 naming schemes. Therefore, it is unlikely that a single naming 598 scheme can be used for both DTN and non-DTN management. 600 10. Security Considerations 602 Policy decisions as to whether anonymous namespaces are allowed in 603 the system should be determined before network deployment. The use 604 of an anonymous namespace greatly increases the chances of naming 605 collisions. 607 Because informal namespaces are defined by any entity, no security or 608 permission meaning can be inferred simply from the expression of 609 namespace. 611 11. IANA Considerations 613 This section provides guidance to the Internet Assigned Numbers 614 Authority (IANA) regarding registration of schema and namespaces 615 related to the AMM Resource Identifier (ARI), in accordance with BCP 616 26 [RFC1155]. 618 11.1. ARI Scheme 620 This document defines a new URI scheme, "ari", as defined in 621 Section 6. This scheme to be registered by IANA here: 622 https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml 624 12. References 626 12.1. Normative References 628 [I-D.ietf-dtn-bpbis] 629 Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol 630 Version 7", Work in Progress, Internet-Draft, draft-ietf- 631 dtn-bpbis-31, 25 January 2021, . 634 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 635 Requirement Levels", BCP 14, RFC 2119, 636 DOI 10.17487/RFC2119, March 1997, 637 . 639 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 640 Resource Identifier (URI): Generic Syntax", STD 66, 641 RFC 3986, DOI 10.17487/RFC3986, January 2005, 642 . 644 [RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines 645 and Registration Procedures for URI Schemes", BCP 35, 646 RFC 7595, DOI 10.17487/RFC7595, June 2015, 647 . 649 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 650 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 651 May 2017, . 653 12.2. Informative References 655 [I-D.birrane-dtn-adm] 656 Birrane, E., DiPietro, E., and D. Linko, "AMA Application 657 Data Model", Work in Progress, Internet-Draft, draft- 658 birrane-dtn-adm-03, 2 July 2018, . 661 [I-D.ietf-dtn-ama] 662 Birrane, E. J., Annis, J. E., and S. Heiner, "Asynchronous 663 Management Architecture", Work in Progress, Internet- 664 Draft, draft-ietf-dtn-ama-03, 25 October 2021, 665 . 668 [RFC1155] Rose, M. and K. McCloghrie, "Structure and identification 669 of management information for TCP/IP-based internets", 670 STD 16, RFC 1155, DOI 10.17487/RFC1155, May 1990, 671 . 673 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 674 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 675 Networking Architecture", RFC 4838, DOI 10.17487/RFC4838, 676 April 2007, . 678 [RFC7320] Nottingham, M., "URI Design and Ownership", RFC 7320, 679 DOI 10.17487/RFC7320, July 2014, 680 . 682 [RFC8820] Nottingham, M., "URI Design and Ownership", BCP 190, 683 RFC 8820, DOI 10.17487/RFC8820, June 2020, 684 . 686 Appendix A. Examples 688 A.1. Namespace Examples 690 For example, consider the namespaces in Figure 1. 692 ARI Namespace Hierarchy 694 +-------+ +--------+ 695 | SDO | | VENDOR | 696 +---+---+ +---+----+ 697 | _____|_____ 698 | | | 699 +-------+ +-------+ +-------+ 700 | IETF | | PROD1 | | PROD2 | 701 +-------+ +-------+ +-------+ 702 _________|_________ | | 703 | | | | | 704 +-------+ +-------+ +-------+ +-------+ +-------+ 705 | APP-1 | | APP-2 | | APP-3 | | APP-4 | | APP-5 | 706 +-------+ +-------+ +-------+ +-------+ +-------+ 708 Figure 1 710 Given this hierarchy, the following are all valid namespace 711 representations. 713 ari://sdo/ietf/ 715 ari://sdo/ietf/app-1/ 717 ari://sdo/ietf/app-3/ 719 ari:/vendor/ 721 ari:/vendor/prod1/ 723 ari:/vendor/prod2/app-5 725 ari:/ 727 A.2. Object Examples 729 The ARIs for the following sample AMM objects are encoded in Table 1. 730 Note that these examples are for the identifiers of AMM objects, not 731 their entire definition. 733 * The number of bytes received by an Agent, defined in the N1/N2 734 namespace and called num_bytes. 736 * The number of bytes received through an interface, called 737 num_bytes_if, which takes a single string parameter named 738 "if_name" with a default value oth "eth0". 740 * An anonymous, operator-defined object named "obj1" which takes two 741 unsigned integer parameters, n1 and n2, with default values of 3 742 and 4, respectively. 744 * The typed, Literal value of 4. 746 +========================+========================================+ 747 | ARI String | Description | 748 +========================+========================================+ 749 | "ari:/N1/N2/num_bytes" | Unparameterized num_bytes object in | 750 | | the N1/N2 informal namespace. | 751 +------------------------+----------------------------------------+ 752 | "num_bytes" | Shortform encoding where the N1/N2 | 753 | | namespace can be assumed. | 754 +------------------------+----------------------------------------+ 755 | "num_bytes_if(String | Formal parameter definition of | 756 | if_name)" | num_bytes object that accepts a string | 757 | | interface name. | 758 +------------------------+----------------------------------------+ 759 | "num_bytes_if(String | Formal parameter definition of | 760 | if_name=eth0)" | num_bytes object that accepts a string | 761 | | interface name with a default value. | 762 +------------------------+----------------------------------------+ 763 | "num_bytes_if()" | Actual parameter using the default | 764 | | value of eth0. | 765 +------------------------+----------------------------------------+ 766 | "num_bytes_if(eth0)" | Actual parameter of eth0. | 767 +------------------------+----------------------------------------+ 768 | "ari:/obj1(Int n1 = 0, | Formal parameter of object obj1 in | 769 | Int n2 = 3)" | anonymous namespace taking 2 default | 770 | | parameters. | 771 +------------------------+----------------------------------------+ 772 | "ari:/obj1(, )" | Actual parameter using the default | 773 | | values of 0 for n1 and 3 for n2. | 774 +------------------------+----------------------------------------+ 775 | "ari:/obj1(, 4)" | Actual parameter using the default | 776 | | value of 0 for n1. | 777 +------------------------+----------------------------------------+ 778 | "ari:/obj1(4, )" | Actual parameter using the default | 779 | | value of 3 for n2. | 780 +------------------------+----------------------------------------+ 781 | "ari:/obj1(4,4)" | Actual parameters provided for all | 782 | | obj1 parameters. | 783 +------------------------+----------------------------------------+ 784 | "ari:/obj1(,4)" | Actual parameters provided for all | 785 | | obj1 parameters, with the value of the | 786 | | first parameter taken from some other | 787 | | parameter named "input". | 788 +------------------------+----------------------------------------+ 789 | "ari:uint(4)" | The Literal value 4 interpreted as a | 790 | | 32-bit unsigned integer. | 791 +------------------------+----------------------------------------+ 793 Table 1 795 Authors' Addresses 797 Edward J. Birrane, III 798 The Johns Hopkins University Applied Physics Laboratory 799 11100 Johns Hopkins Rd. 800 Laurel, MD 20723 801 United States of America 803 Phone: +1 443 778 7423 804 Email: Edward.Birrane@jhuapl.edu 805 Emery Annis 806 Johns Hopkins Applied Physics Laboratory 808 Email: Emery.Annis@jhuapl.edu