idnits 2.17.1 draft-bsipos-dtn-amp-yang-01.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 : ---------------------------------------------------------------------------- ** There are 49 instances of too long lines in the document, the longest one being 19 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 4, 2016) is 2934 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'I-D.birrane-dtn-ama' is defined on line 889, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3548 (Obsoleted by RFC 4648) ** Obsolete normative reference: RFC 6087 (Obsoleted by RFC 8407) == Outdated reference: A later version (-08) exists of draft-birrane-dtn-amp-02 == Outdated reference: A later version (-07) exists of draft-birrane-dtn-ama-02 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Delay Tolerant Networking B. Sipos 3 Internet-Draft RKF Engineering 4 Intended status: Experimental E. Birrane, Ed. 5 Expires: October 6, 2016 JHU APL 6 April 4, 2016 8 A YANG profile for defining Asynchronous Management Protocol Application 9 Data Models 10 draft-bsipos-dtn-amp-yang-01 12 Abstract 14 This document specifies a YANG profile for defining Application Data 15 Model (ADM) schema for the Asynchronous Management Protocol (AMP). 16 The AMP has no relation to NETCONF; YANG is used here only for its 17 language syntax, and its module and type systems. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on October 6, 2016. 36 Copyright Notice 38 Copyright (c) 2016 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 55 2. Application Data Models . . . . . . . . . . . . . . . . . . . 3 56 2.1. Module Restrictions . . . . . . . . . . . . . . . . . . . 3 57 2.2. OID Assignment . . . . . . . . . . . . . . . . . . . . . 4 58 3. YANG Types for AMP . . . . . . . . . . . . . . . . . . . . . 4 59 3.1. The Integer Types . . . . . . . . . . . . . . . . . . . . 4 60 3.2. The Floating Point Types . . . . . . . . . . . . . . . . 5 61 3.3. Other Simple Types . . . . . . . . . . . . . . . . . . . 5 62 3.4. The Compound Types . . . . . . . . . . . . . . . . . . . 5 63 3.5. Object Identifier Types . . . . . . . . . . . . . . . . . 5 64 3.6. Applicaiton Module Subtyping . . . . . . . . . . . . . . 5 65 4. YANG Extensions for AMP . . . . . . . . . . . . . . . . . . . 6 66 4.1. Object Identifiers . . . . . . . . . . . . . . . . . . . 6 67 4.1.1. The fulloid Extension Statement . . . . . . . . . . . 6 68 4.1.2. The suboid Extension Statement . . . . . . . . . . . 6 69 4.1.3. The nickname Extension Statement . . . . . . . . . . 7 70 4.1.4. The compressoid Extension Statement . . . . . . . . . 7 71 4.2. The group Extension Statement . . . . . . . . . . . . . . 8 72 4.3. Model Definition Extensions . . . . . . . . . . . . . . . 8 73 4.3.1. The primitive Extension Statement . . . . . . . . . . 8 74 4.3.2. The control Extension Statement . . . . . . . . . . . 9 75 4.3.3. The parameter Extension Statement . . . . . . . . . . 10 76 4.3.4. The result Extension Statement . . . . . . . . . . . 10 77 4.3.5. The report Extension Statement . . . . . . . . . . . 11 78 4.3.6. The reportitem Extension Statement . . . . . . . . . 11 79 4.3.7. The macro Extension Statement . . . . . . . . . . . . 12 80 4.3.8. The operator Extension Statement . . . . . . . . . . 12 81 4.3.9. The operand Extension Statement . . . . . . . . . . . 13 82 4.4. Data Instance Extensions . . . . . . . . . . . . . . . . 13 83 4.4.1. The number-instance Extension Statement . . . . . . . 14 84 4.4.2. The string-instance Extension Statement . . . . . . . 15 85 4.4.3. The BLOB-instance Extension Statement . . . . . . . . 15 86 4.4.4. The TS-instance Extension Statement . . . . . . . . . 15 87 4.4.5. The MID-instance Extension Statement . . . . . . . . 16 88 4.4.6. The DC-instance Extension Statement . . . . . . . . . 17 89 4.4.7. The MC-instance Extension Statement . . . . . . . . . 17 90 4.4.8. The TDC-instance Extension Statement . . . . . . . . 17 91 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 92 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 93 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 94 7.1. Normative References . . . . . . . . . . . . . . . . . . 19 95 7.2. Informative References . . . . . . . . . . . . . . . . . 20 97 Appendix A. YANG Definitions . . . . . . . . . . . . . . . . . . 20 98 A.1. AMP Module . . . . . . . . . . . . . . . . . . . . . . . 20 99 A.2. AMP Type Submodule . . . . . . . . . . . . . . . . . . . 21 100 A.3. AMP Extensions Submodule . . . . . . . . . . . . . . . . 27 101 A.4. AMP Instances Submodule . . . . . . . . . . . . . . . . . 29 102 Appendix B. Example Application Data Model . . . . . . . . . . . 32 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 105 1. Introduction 107 This profile uses YANG [RFC6020] as an encoding for the management 108 schema and makes use of the YANG module and type systems. The fact 109 that YANG is also used to specify data models for the NETCONF 110 protocol has no direct influence over this use of YANG to specify 111 data models for AMP. 113 This specification follows [RFC6087] in the definition of the "amp- 114 adm" YANG module. The amp-adm module defines only subtypes and 115 extensions; it does not define any actual data model elements. 117 1.1. Requirements Language 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in [RFC2119]. 123 2. Application Data Models 125 An AMP application SHALL define its Application Data Model (ADM) by 126 means of a YANG module which imports and uses "amp-adm" module 127 extensions. An official Pyang tool [pyang] plugin SHOULD be used to 128 validate the contents of an ADM YANG module. 130 2.1. Module Restrictions 132 A YANG module which defines an AMP ADM SHALL NOT be used to also 133 define a data model for NETCONF or any other non-AMP protocol. It 134 may be syntatically allowable to mix models for multiple protocols 135 but it decreases the intelligability of the module for either 136 purpose. 138 A YANG module which defines an AMP ADM SHALL NOT contain any 139 "default" statements. 141 2.2. OID Assignment 143 For each ADM-specific YANG statement which requires an OID to be 144 assigned to it, it is possible to use one of the "fulloid", "suboid", 145 or "compressoid" substatements to make that assignment. Not all of 146 the OID assignment substatements are available in all contexts, so 147 following the allowed substatement table is important. 149 The types of OID assignments are: 151 o Full OIDs can be used in any situation where an OID is needed. 153 o Compressed OIDs can also be used in any situation where an OID is 154 needed, but require the use of a module-unique OID nickname ID. 156 o Sub-OIDs can be used where the OID being assigned is relative to 157 the structural (module-statement-wise) parent of the assignment. 159 An ADM SHOULD make use of sub-OIDs where possible, both to avoid 160 typos possible with full OIDs and to avoid nickname assignment for 161 every group within the ADM. Using sub-OIDs also guarantees that the 162 tree structure of the ADM module matches one-for-one with the OID 163 tree. 165 3. YANG Types for AMP 167 This section specifies how AMP types interact with native YANG types. 168 All AMP data types are sub-typed from YANG native types solely for 169 the purpose of providing a baseline of behavior for YANG parsers. 170 Any YANG module which defines an AMP ADM SHALL only use types (or 171 derived types) from the "amp-adm" module. 173 3.1. The Integer Types 175 The AMP types of "BYTE", "INT", "UINT", "VAST", and "UVAST" are 176 derived directly from the built-in YANG type of the same numeric 177 domain. There is no functional difference between these types and 178 the native types, other than the namespace of these types. Using 179 AMP-specific names allows ADM module authors to keep consistent 180 terminology between textual specification and YANG specification. 182 The "SDNV" type is derived from YANG "binary" type due to its domain 183 being larger than any of the built-in YANG types. 185 3.2. The Floating Point Types 187 The AMP types of "REAL32" and "REAL64" are derived from YANG "binary" 188 type because the built-in floating point type is not a clear superset 189 of the floating point types of [I-D.birrane-dtn-amp]. 191 3.3. Other Simple Types 193 The "SDNV" type is derived from YANG "binary" type due to its domain 194 being larger than any of the built-in YANG numeric types. 196 The "TS" type is also derived from YANG "binary" type due to the more 197 complex encoding semantics of the TS type. 199 3.4. The Compound Types 201 The "STR" type is derived from the YANG "string" type only because 202 they both are intended to have the semantics of human-readable text. 203 An ADM SHOULD NOT use the amp:STR type for any data other than text 204 encoded with UTF-8 (see [RFC3629]). The encoding of "STR" type is 205 wholy unrelated to any NETCONF use of the YANG "string" type. 207 The "BLOB" type is derived from YANG "binary" type. The BLOB is the 208 simplest AMP-specific type which is encoded using internal sub-items 209 (the size separate from the bytes). 211 The "DC" and "TDC" types are also derived from YANG "binary" type for 212 lack of specific YANG mechanism for type decomposition. 214 3.5. Object Identifier Types 216 The "MID" type is derived from YANG "binary" type due to its combined 217 use of bit patterns (in its header) and BER-encoded data. 219 The "MC" type is also derived from YANG "binary" type for lack of 220 specific YANG mechanism for type decomposition. 222 3.6. Applicaiton Module Subtyping 224 An ADM SHOULD subtype any numeric type in order to apply additional 225 semantic context to the numerical values (similar to the SMIv2 226 CounterXX and GaugeXX [RFC2578]). An ADM SHOULD make use of the YANG 227 "units" substatement when numeric types are used (within either a 228 typedef or a type-use). 230 An ADM SHOULD subtype the BLOB type in order to identify application- 231 specific encoding formats. Using plain BLOB types within an ADM is 232 discouraged due to the opaqueness of the 233 Any ADM subtype SHALL have no effect on the value encoding of AMP. 234 Subtypes are purely used to assist applications in managing value 235 semantics. Any ADM subtype SHALL include a description substatement 236 explaining the purpose of the subtype. 238 4. YANG Extensions for AMP 240 This section specifies how AMP extension statements interact with 241 native YANG statements within an application YANG module. 243 4.1. Object Identifiers 245 This section contains extensions for identifying a data node within 246 the YANG model tree by a unique OID value. 248 4.1.1. The fulloid Extension Statement 250 A "fulloid" statement is used to anchor an item in the OID tree. The 251 value of a fulloid is the dotted-numeric notation of the OID value. 252 A fulloid value must not be empty. Any substatements which are 253 sibling to a "fulloid" will be relative to that OID root for the 254 purposes of "suboid" processing. 256 The format of a fulloid argument is a string of period-separated 257 numeric components. 259 +--------------+-------------+ 260 | substatement | cardinality | 261 +--------------+-------------+ 262 | description | 0..1 | 263 +--------------+-------------+ 265 Table 1: fulloid Substatements 267 4.1.2. The suboid Extension Statement 269 A "suboid" statement is used to define an item's OID relative to a 270 sibling statement's full OID. The value of a suboid is the dotted- 271 numeric notation of the OID parts under the full OID. A suboid value 272 must not be empty. 274 The format of a suboid argument is the same as a fulloid argument. 275 The interpretation of a suboid depends upon the context of the 276 statement. 278 +--------------+-------------+ 279 | substatement | cardinality | 280 +--------------+-------------+ 281 | description | 0..1 | 282 +--------------+-------------+ 284 Table 2: suboid Substatements 286 4.1.3. The nickname Extension Statement 288 A "nickname" statement is used to define an application-specific 289 numeric identifier for a full OID prefix. The nickname is used by 290 both the AMP agent and manager to shorten OID encoding. 292 The format of a nickname argument is a single non-negative integer 293 value. Each nickname is defined within the namespace of the ADM 294 module. 296 +--------------+-------------+ 297 | substatement | cardinality | 298 +--------------+-------------+ 299 | description | 0..1 | 300 | | | 301 | fulloid | 1 | 302 +--------------+-------------+ 304 Table 3: nickname Substatements 306 4.1.4. The compressoid Extension Statement 308 A "compressoid" statement is used to define a full OID based on a 309 module-specific nickname (see Section 4.1.3) as a prefix and a suboid 310 suffix. 312 The format of a compressoid argument is a nickname value (see 313 Section 4.1.3) within square brackets followed by a suboid string. 315 +--------------+-------------+ 316 | substatement | cardinality | 317 +--------------+-------------+ 318 | description | 0..1 | 319 +--------------+-------------+ 321 Table 4: compressoid Substatements 323 4.2. The group Extension Statement 325 The "group" statement is used to define a grouping of other items 326 within the ADM. Each group is assigned an OID (see Section 2.2) and 327 used as an OID anchor for its substatements. 329 The order of substatements within a group is not significant. Only 330 the OID assignment of each item is significant. 332 +--------------------------------+-------------+ 333 | substatement | cardinality | 334 +--------------------------------+-------------+ 335 | description | 0..1 | 336 | | | 337 | reference | 0..1 | 338 | | | 339 | status | 0..1 | 340 | | | 341 | fulloid | suboid | compressoid | 1 | 342 | | | 343 | group | 0..* | 344 | | | 345 | primitive | 0..* | 346 | | | 347 | control | 0..* | 348 | | | 349 | report | 0..* | 350 | | | 351 | macro | 0..* | 352 | | | 353 | operator | 0..* | 354 +--------------------------------+-------------+ 356 Table 5: group Substatements 358 4.3. Model Definition Extensions 360 4.3.1. The primitive Extension Statement 362 The "primitive" statement is used to define an atomic value within an 363 ADM. Each primitive is assigned an OID (see Section 2.2) and a type. 364 The primitive has different semantics from the YANG "leaf" statement 365 due to the lack of secondary (non-type) attributes (e.g. config/state 366 distinction). All primitive objects are state; any configuration is 367 performed via "control" statements. 369 +--------------------------------+-------------+ 370 | substatement | cardinality | 371 +--------------------------------+-------------+ 372 | description | 0..1 | 373 | | | 374 | reference | 0..1 | 375 | | | 376 | status | 0..1 | 377 | | | 378 | fulloid | suboid | compressoid | 1 | 379 | | | 380 | type | 1 | 381 | | | 382 | units | 0..1 | 383 +--------------------------------+-------------+ 385 Table 6: primitive Substatements 387 4.3.2. The control Extension Statement 389 The "control" statement is used to define an available control within 390 the ADM. Each control is assigned an OID (see Section 2.2) and an 391 ordered list of parmeter and result items. The control has different 392 semantics from the YANG "rpc" statement due to the difference in 393 protocol encoding and to the asynchronous nature of the AMP. 395 Each control is parameterized by some number of parameters (see 396 Section 4.3.3) and some number of results (see Section 4.3.4). There 397 is no provision in an ADM for specifying alternative parameters or 398 alternative results (i.e. no parameters are optional). 400 +--------------------------------+-------------+ 401 | substatement | cardinality | 402 +--------------------------------+-------------+ 403 | description | 0..1 | 404 | | | 405 | reference | 0..1 | 406 | | | 407 | status | 0..1 | 408 | | | 409 | fulloid | suboid | compressoid | 1 | 410 | | | 411 | parameter | 0..* | 412 | | | 413 | result | 0..* | 414 +--------------------------------+-------------+ 416 Table 7: control Substatements 418 4.3.3. The parameter Extension Statement 420 The "parameter" statement is used to define single expected parameter 421 of a "control" statement. In the AMP each control has a fixed number 422 of typed parameters, there is no provision for overloaded controls 423 which take variable numbers of parameters. 425 A control parameter is an atomic value with a distinct type, but has 426 no distinct OID. The parameter statement's argument is used as the 427 parameter's name. Within a single control, each parameter name SHALL 428 be unique. The parameter name is not related to any AMP encoding, so 429 is useful only for the sake of identifying the parameter within the 430 ADM. 432 +--------------+-------------+ 433 | substatement | cardinality | 434 +--------------+-------------+ 435 | description | 0..1 | 436 | | | 437 | type | 1 | 438 | | | 439 | units | 0..1 | 440 +--------------+-------------+ 442 Table 8: parameter Substatements 444 4.3.4. The result Extension Statement 446 The "result" statement is used to define single expected result of a 447 "control" statement. In the AMP each control has a fixed number of 448 typed results, there is no provision for overloaded controls which 449 yield variable numbers of results. 451 A control result is an atomic value with a distinct type, but has no 452 distinct OID. The result statement's argument is used as the 453 result's name. Within a single control, each result name SHALL be 454 unique. The result name is not related to any AMP encoding, so is 455 useful only for the sake of identifying the result within the ADM. 457 +--------------+-------------+ 458 | substatement | cardinality | 459 +--------------+-------------+ 460 | description | 0..1 | 461 | | | 462 | type | 1 | 463 | | | 464 | units | 0..1 | 465 +--------------+-------------+ 467 Table 9: result Substatements 469 4.3.5. The report Extension Statement 471 The "report" statement is used to define the contents of an AMP 472 report, but does not define when any instances of the report may be 473 created. Each report is assigned an OID (see Section 2.2) and an 474 ordered list of content items. Asynchronous reporting is a distinct 475 feature of the AMP from other management protocols. 477 Each report is parameterized by some number of items which are to be 478 contained in corresponding report instances (see Section 4.3.6). 479 There is no provision in an ADM for specifying alternative report 480 contents. 482 +--------------------------------+-------------+ 483 | substatement | cardinality | 484 +--------------------------------+-------------+ 485 | description | 0..1 | 486 | | | 487 | reference | 0..1 | 488 | | | 489 | status | 0..1 | 490 | | | 491 | fulloid | suboid | compressoid | 1 | 492 | | | 493 | reportitem | 0..* | 494 +--------------------------------+-------------+ 496 Table 10: report Substatements 498 4.3.6. The reportitem Extension Statement 500 The "reportitem" statement is used to define single expected item 501 within a report instance. In the AMP each report has a fixed number 502 of typed items, there is no provision for overloaded reports which 503 yield variable numbers of items. 505 A reportitem is an atomic value with a distinct OID of the primitive 506 to be included in a report instance. A reportitem has no type of its 507 own. The reportitem statement's argument is used as the item's name. 508 Within a single report, each reportitem name SHALL be unique. The 509 reportitem name is not related to any AMP encoding, so is useful only 510 for the sake of identifying the item within the ADM. 512 +-----------------------+-------------+ 513 | substatement | cardinality | 514 +-----------------------+-------------+ 515 | description | 0..1 | 516 | | | 517 | fulloid | compressoid | 1 | 518 +-----------------------+-------------+ 520 Table 11: reportitem Substatements 522 4.3.7. The macro Extension Statement 524 The "macro" statement is used to declare an AMP macro within an ADM. 526 //FIXME: what value is there in the inline definition? 528 +--------------------------------+-------------+ 529 | substatement | cardinality | 530 +--------------------------------+-------------+ 531 | description | 0..1 | 532 | | | 533 | reference | 0..1 | 534 | | | 535 | status | 0..1 | 536 | | | 537 | fulloid | suboid | compressoid | 1 | 538 +--------------------------------+-------------+ 540 Table 12: macro Substatements 542 4.3.8. The operator Extension Statement 544 The "operator" statement is used to define the syntax of an ADM 545 operator (for use in expressions). Each operator is assigned an OID 546 (see Section 2.2) and an ordered list of operands. 548 Each operator is parameterized by some number of items which are to 549 be used as operands at statement execution time. (see 550 Section 4.3.9). 552 +--------------------------------+-------------+ 553 | substatement | cardinality | 554 +--------------------------------+-------------+ 555 | description | 0..1 | 556 | | | 557 | reference | 0..1 | 558 | | | 559 | status | 0..1 | 560 | | | 561 | fulloid | suboid | compressoid | 1 | 562 | | | 563 | operand | 0..* | 564 +--------------------------------+-------------+ 566 Table 13: operator Substatements 568 4.3.9. The operand Extension Statement 570 The "operand" statement is used to define single expected operand 571 within an operator statement. In the AMP each operation has a fixed 572 number of untyped operands. There is no provision for overloaded 573 operators which take variable numbers of operands. 575 An operand is an atomic value with no associated OID or type. The 576 operand statement's argument is used as the item's name. Within a 577 single operator, each operand name SHALL be unique. The operand name 578 is not related to any AMP encoding, so is useful only for the sake of 579 identifying the item within the ADM. 581 +--------------+-------------+ 582 | substatement | cardinality | 583 +--------------+-------------+ 584 | description | 0..1 | 585 +--------------+-------------+ 587 Table 14: operand Substatements 589 4.4. Data Instance Extensions 591 Some aspects of an ADM module require in-line instantiations of data 592 which will eventually be encoded in AMP format. Rather than 593 requiring the ADM module author to do the encoding manually, and to 594 allow easier inspection by an ADM module reader, each to-be-encoded 595 data item is represented in the ADM module by one of the 596 "amp:*-instance" statements. Examples of uses for these instances 597 are: a numeric value used in the definition of a "literal" statement, 598 or OID values used in the definition of a "report" statement. 600 Where possible, an ADM author SHOULD supply all data instances 601 necessary to interpret the constant-data items within an ADM. 603 4.4.1. The number-instance Extension Statement 605 The "number-instance" statement is used to define single value of one 606 of the integer data types (BYTE, INT, UINT, VAST, UVAST, SDNV) or one 607 of the floating point types (REAL32, REAL64). The number-type 608 substatement SHALL be present unless the number-instance is a direct 609 substatement of a typed statement (e.g. a literal statement). 611 The lexical representation of all AMP integer types SHALL conform to 612 the corresponding integer types [RFC6020]. The lexical 613 representation of AMP floating point types SHALL conform to the 614 "decimal64" type of [RFC6020]. The binary-valued floating point 615 domain of the AMP types SHALL be enforced by any YANG module parser. 617 +--------------+-------------+ 618 | substatement | cardinality | 619 +--------------+-------------+ 620 | description | 0..1 | 621 | | | 622 | number-type | 0..1 | 623 +--------------+-------------+ 625 Table 15: number-instance Substatements 627 4.4.1.1. The number-type Extension Statement 629 The "number-type" statement is used to identify the specific encoding 630 type for a number-instance parent statement. A number-type 631 statement's argument SHALL be one of the numeric type names: 633 BYTE 635 INT 637 UINT 639 VAST 641 UVAST 643 SDNV 645 REAL32 647 REAL64 649 The number-type statement has no substatemnts. 651 4.4.2. The string-instance Extension Statement 653 The "string-instance" statement is used to define single text value 654 for the STR data type. The string-instance argument SHALL NOT 655 contain the UTF-8 code point zero. Code point zero is used to 656 terminate strings in AMP. 658 +--------------+-------------+ 659 | substatement | cardinality | 660 +--------------+-------------+ 661 | description | 0..1 | 662 +--------------+-------------+ 664 Table 16: string-instance Substatements 666 4.4.3. The BLOB-instance Extension Statement 668 The "BLOB-instance" statement is used to define single binary-data 669 value for the BLOB data type. The BLOB-instance argument SHALL be 670 represented by Base-64 encoded text according to [RFC3548]. The 671 length of the encoded BLOB is implicit in the BLOB-instance 672 representation. 674 +--------------+-------------+ 675 | substatement | cardinality | 676 +--------------+-------------+ 677 | description | 0..1 | 678 +--------------+-------------+ 680 Table 17: string-instance Substatements 682 4.4.4. The TS-instance Extension Statement 684 The "TS-instance" statement is used to define single time-stamp 685 value. Although its encoding is identical to the SDNV number- 686 instance, the TS-instance YANG representation is different. The TS- 687 instance argument SHALL contain an fully qualified absolute time 688 represented according to [RFC3339]. 690 +--------------+-------------+ 691 | substatement | cardinality | 692 +--------------+-------------+ 693 | description | 0..1 | 694 +--------------+-------------+ 696 Table 18: TS-instance Substatements 698 4.4.5. The MID-instance Extension Statement 700 The "MID-instance" statement is used to define single MID value, 701 including all of the possible MID variations. 703 +--------------+-------------+ 704 | substatement | cardinality | 705 +--------------+-------------+ 706 | description | 0..1 | 707 | | | 708 | MID-type | 1 | 709 | | | 710 | MID-category | 1 | 711 | | | 712 | MID-issuer | 0..1 | 713 | | | 714 | MID-tag | 0..1 | 715 +--------------+-------------+ 717 Table 19: MID-instance Substatements 719 4.4.5.1. The MID-issuer Extension Statement 721 The "MID-issuer" statement is used to define the optional Issuer 722 payload of the MID value. The presence or absense of a MID-issuer 723 statement determines the header and payload encoding of the MID 724 value. The MID-issuer argument SHALL be a positive integer value. 726 +--------------+-------------+ 727 | substatement | cardinality | 728 +--------------+-------------+ 729 | description | 0..1 | 730 +--------------+-------------+ 732 Table 20: MID-issuer Substatements 734 4.4.5.2. The MID-tag Extension Statement 736 The "MID-tag" statement is used to define the optional Tag payload of 737 the MID value. The presence or absense of a MID-tag statement 738 determines the header and payload encoding of the MID value. The 739 MID-tag argument SHALL be a positive integer value. 741 +--------------+-------------+ 742 | substatement | cardinality | 743 +--------------+-------------+ 744 | description | 0..1 | 745 +--------------+-------------+ 747 Table 21: MID-tag Substatements 749 4.4.6. The DC-instance Extension Statement 751 The "DC-instance" statement is used to define a list of BLOB values. 752 The count of values present in the DC is implicit in the number of 753 BLOB-instance substatements. The order of BLOB-instance 754 substatements SHALL correpsond with the encoded DC value. 756 +---------------+-------------+ 757 | substatement | cardinality | 758 +---------------+-------------+ 759 | description | 0..1 | 760 | | | 761 | BLOB-instance | 0..* | 762 +---------------+-------------+ 764 Table 22: DC-instance Substatements 766 4.4.7. The MC-instance Extension Statement 768 The "MC-instance" statement is used to define a list of MID values. 769 The count of values present in the MC is implicit in the number of 770 MID-instance substatements. The order of MID-instance substatements 771 SHALL correpsond with the encoded MC value. 773 +--------------+-------------+ 774 | substatement | cardinality | 775 +--------------+-------------+ 776 | description | 0..1 | 777 | | | 778 | MID-instance | 0..* | 779 +--------------+-------------+ 781 Table 23: MC-instance Substatements 783 4.4.8. The TDC-instance Extension Statement 785 The "TDC-instance" statement is used to define a list of typed data 786 instance values. The count of values present in the TDC is implicit 787 in the number of "*-instance" substatements. The order of data 788 instance substatements SHALL correpsond with the encoded TDC value. 790 +-----------------------------------------------------+-------------+ 791 | substatement | cardinality | 792 +-----------------------------------------------------+-------------+ 793 | description | 0..1 | 794 | | | 795 | number-instance | string-instance | BLOB-instance | | 0..* | 796 | TS-instance | MID-instance | DC-instance | TDC- | | 797 | instance | | 798 +-----------------------------------------------------+-------------+ 800 Table 24: TDC-instance Substatements 802 5. IANA Considerations 804 This document registers one URI in the IETF XML registry [RFC3688]. 805 NOTE TO EDITOR: module registration is pending I-D approval. The 806 following registration has been made: 808 +--------------------+---------------------------------------------+ 809 | Field | Value | 810 +--------------------+---------------------------------------------+ 811 | URI | urn:ietf:params:xml:ns:yang:amp-adm | 812 | | | 813 | Registrant Contact | The DTN WG of the IETF. | 814 | | | 815 | XML | N/A, the requested URI is an XML namespace. | 816 +--------------------+---------------------------------------------+ 818 This document registers one module name/namespace in the IETF YANG 819 Module Names Registry [RFC6020]. NOTE TO EDITOR: module registration 820 is pending I-D approval. The following registration has been made: 822 +-----------+-------------------------------------+ 823 | Field | Value | 824 +-----------+-------------------------------------+ 825 | Name | amp-adm | 826 | | | 827 | Namespace | urn:ietf:params:xml:ns:yang:amp-adm | 828 | | | 829 | Prefix | amp | 830 | | | 831 | Reference | draft-bsipos-dtn-amp-yang | 832 +-----------+-------------------------------------+ 834 6. Security Considerations 836 This memo only defines a mechanism to specify an application schema, 837 it does not impose any limitations or requirements on the contents of 838 that schema. The amp-adm module defines only subtypes and 839 extensions. It does not define any actual data model elements, so 840 there are no direct security implications. 842 7. References 844 7.1. Normative References 846 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 847 Requirement Levels", BCP 14, RFC 2119, 848 DOI 10.17487/RFC2119, March 1997, 849 . 851 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 852 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 853 . 855 [RFC3548] Josefsson, S., Ed., "The Base16, Base32, and Base64 Data 856 Encodings", RFC 3548, DOI 10.17487/RFC3548, July 2003, 857 . 859 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 860 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 861 2003, . 863 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 864 DOI 10.17487/RFC3688, January 2004, 865 . 867 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 868 the Network Configuration Protocol (NETCONF)", RFC 6020, 869 DOI 10.17487/RFC6020, October 2010, 870 . 872 [RFC6087] Bierman, A., "Guidelines for Authors and Reviewers of YANG 873 Data Model Documents", RFC 6087, DOI 10.17487/RFC6087, 874 January 2011, . 876 [I-D.birrane-dtn-amp] 877 Birrane, E. and J. Pierce-Mayer, "Asynchronous Management 878 Protocol", draft-birrane-dtn-amp-02 (work in progress), 879 March 2016. 881 7.2. Informative References 883 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 884 Schoenwaelder, Ed., "Structure of Management Information 885 Version 2 (SMIv2)", STD 58, RFC 2578, 886 DOI 10.17487/RFC2578, April 1999, 887 . 889 [I-D.birrane-dtn-ama] 890 Birrane, E., "Asynchronous Management Architecture", 891 draft-birrane-dtn-ama-02 (work in progress), March 2016. 893 [pyang] Bjorklund, M., "An extensible YANG validator and converter 894 in python", March 2016. 896 [CCITT.X690.2002] 897 International Telephone and Telegraph Consultative 898 Committee, "ASN.1 encoding rules: Specification of basic 899 encoding Rules (BER), Canonical encoding rules (CER) and 900 Distinguished encoding rules (DER)", CCITT Recommendation 901 X.690, July 2002. 903 Appendix A. YANG Definitions 905 The contents of this section is the machine-readable specification of 906 this YANG module. 908 A.1. AMP Module 910 The following YANG definition is the top-level "amp" module. 912 file "amp-adm.yang" 914 module amp-adm { 915 namespace "urn:ietf:params:xml:ns:yang:amp-adm"; 916 prefix "amp"; 918 include amp-types; 919 include amp-extensions; 920 include amp-instances; 922 organization 923 "IETF Delay Tolerant Networking Working Group"; 924 contact 925 "WG Web: 926 WG List: 928 WG Chairs: Brian Haberman 929 930 Marc Blanchet 931 933 Editor: Brian Sipos 934 "; 936 description 937 "This module implements the " 938 +"Asynchornous Management Protocol (AMP) " 939 +"Application Data Model (ADM) profile within YANG"; 940 reference "draft Asynchronous Management Protocol"; 942 revision "2016-04-01" { 943 description "Updated to fix typos."; 944 reference "I-D draft-bsipos-dtn-amp-yang"; 945 } 946 revision "2016-03-14" { 947 description "Initial draft release."; 948 reference "I-D draft-bsipos-dtn-amp-yang"; 949 } 950 } 952 954 A.2. AMP Type Submodule 956 The following YANG definition includes types specific to AMP. 958 file "amp-types.yang" 959 submodule amp-types { 960 belongs-to amp-adm { 961 prefix "amp"; 962 } 964 organization 965 "IETF Delay Tolerant Networking Working Group"; 966 contact 967 "WG Web: 968 WG List: 970 WG Chairs: Brian Haberman 971 972 Marc Blanchet 973 975 Editor: Brian Sipos 976 "; 978 description 979 "This submodule contains the set of core types necessary to " 980 +"define an Asynchronous Management Protocol data model."; 981 reference "draft Asynchronous Management Protocol"; 983 revision "2016-04-01" { 984 description "Updated to fix typos."; 985 reference "I-D draft-bsipos-dtn-amp-yang"; 986 } 987 revision "2016-03-14" { 988 description "Initial draft release."; 989 reference "I-D draft-bsipos-dtn-amp-yang"; 990 } 992 // These extensions are only used within this submodule for annotation 993 extension amp-type-id { 994 argument "num"; 995 description "Internal annotation of the AMP ID number of a type."; 996 } 997 extension amp-type-item { 998 argument "name"; 999 description "Internal annotation of a sub-type item."; 1000 } 1001 extension amp-type-list { 1002 argument "name"; 1003 description "Internal annotation of a sub-type list-of-items."; 1004 } 1006 typedef "BYTE" { 1007 type "uint8"; 1008 amp:amp-type-id 0; 1009 description "Unsigned 8-bit integer"; 1010 reference "draft Asynchronous Management Protocol"; 1011 } 1012 typedef "INT" { 1013 type "int32"; 1014 amp:amp-type-id 1; 1015 description "Signed 32-bit integer"; 1016 reference "draft Asynchronous Management Protocol"; 1017 } 1018 typedef "UINT" { 1019 type "uint32"; 1020 amp:amp-type-id 2; 1021 description "Unsigned 32-bit integer"; 1022 reference "draft Asynchronous Management Protocol"; 1023 } 1024 typedef "VAST" { 1025 type "int64"; 1026 amp:amp-type-id 3; 1027 description "Signed 64-bit integer"; 1028 reference "draft Asynchronous Management Protocol"; 1029 } 1030 typedef "UVAST" { 1031 type "uint64"; 1032 amp:amp-type-id 4; 1033 description "Unsigned 64-bit integer"; 1034 reference "draft Asynchronous Management Protocol"; 1035 } 1036 typedef "REAL32" { 1037 type "binary"; 1038 amp:amp-type-id 5; 1039 description 1040 "Binary encoding of IEEE-754 32-bit floating point number."; 1041 reference "draft Asynchronous Management Protocol"; 1042 } 1043 typedef "REAL64" { 1044 type "binary"; 1045 amp:amp-type-id 6; 1046 description 1047 "Binary encoding of IEEE-754 64-bit floating point number."; 1048 reference "draft Asynchronous Management Protocol"; 1049 } 1050 typedef "SDNV" { 1051 type "binary"; 1052 amp:amp-type-id 9; 1053 description 1054 "Binary encoding of self-delimited numeric value."; 1055 reference "draft Asynchronous Management Protocol"; 1057 } 1058 typedef "STR" { 1059 type "string"; 1060 amp:amp-type-id 7; 1061 description 1062 "Same UTF-8 encoding as YANG base type. " 1063 +"Must be zero-terminated."; 1064 reference "draft Asynchronous Management Protocol"; 1065 } 1067 typedef "TS" { 1068 type "binary"; 1069 amp:amp-type-id 10; 1070 description "A timestamp value."; 1071 reference "draft Asynchronous Management Protocol"; 1072 } 1074 typedef "MID" { 1075 type "binary"; 1076 amp:amp-type-id 12; 1077 description "The basic managed-identifier definition."; 1078 reference "draft Asynchronous Management Protocol"; 1079 } 1081 typedef "BLOB" { 1082 type "binary"; 1083 amp:amp-type-id 8; 1084 description 1085 "The BLOB type should be used as a base type for " 1086 +"applicaiton-specific types used in data models."; 1087 reference "draft Asynchronous Management Protocol"; 1089 amp:amp-type-item "count" { type "SDNV"; } 1090 amp:amp-type-list "octets" { type "BYTE"; } 1091 } 1093 typedef "DC" { 1094 type "binary"; 1095 amp:amp-type-id 11; 1096 description "Untyped data collection"; 1098 amp:amp-type-item "count" { type "SDNV"; } 1099 amp:amp-type-list "items" { type "BLOB"; } 1100 } 1101 typedef "TDC" { 1102 type "binary"; 1103 amp:amp-type-id 18; 1104 description "Typed data collection"; 1105 amp:amp-type-item "entry-count" { type "SDNV"; } 1106 // These really need not be BLOBs with internal sizes 1107 amp:amp-type-item "entry-types" { type "BLOB"; } 1108 amp:amp-type-list "entry-values" { type "BLOB"; } 1109 } 1110 typedef "MC" { 1111 type "binary"; 1112 amp:amp-type-id 13; 1113 description "Ordered list of MID values."; 1115 amp:amp-type-item "count" { type "SDNV"; } 1116 amp:amp-type-list "values" { type "MID"; } 1117 } 1119 // Should be pure MC with no type-id? 1120 // The only time [EXPR] type is used in AMP spec is 1121 // for DEF definition, which is unambiguous on type. 1122 typedef "EXPR" { 1123 type "binary"; 1124 amp:amp-type-id 14; 1125 description 1126 "Ordered list of MID values representing a " 1127 +"postfix arithmetic."; 1129 amp:amp-type-item "expression" { type "MC"; } 1130 } 1131 // PRED is not a type 1132 typedef "DEF" { 1133 type "binary"; 1134 amp:amp-type-id 15; 1135 description 1136 "Ordered list of MID values with a corresponding result" 1137 +"type and overall OID"; 1139 amp:amp-type-item "id" { type "MID"; } 1140 amp:amp-type-item "type" { type "BYTE"; } 1141 amp:amp-type-item "definition" { type "MC"; } 1142 } 1143 typedef "TRL" { 1144 type "binary"; 1145 amp:amp-type-id 16; 1146 description 1147 "Identify and define a time-based macro rule."; 1149 amp:amp-type-item "id" { type "MID"; } 1150 amp:amp-type-item "start" { type "TS"; } 1151 amp:amp-type-item "period" { type "SDNV"; units "seconds"; } 1152 amp:amp-type-item "count" { type "SDNV"; } 1153 amp:amp-type-item "action" { type "MC"; } 1154 } 1155 typedef "SRL" { 1156 type "binary"; 1157 amp:amp-type-id 17; 1158 description 1159 "Identify and define a state-based macro rule."; 1161 amp:amp-type-item "id" { type "MID"; } 1162 amp:amp-type-item "start" { type "TS"; } 1163 // Mismatch in AMP spec for PRED type 1164 // amp:amp-type-item "condition" { type "PRED"; } 1165 amp:amp-type-item "condition" { type "EXPR"; } 1166 amp:amp-type-item "count" { type "SDNV"; } 1167 amp:amp-type-item "action" { type "MC"; } 1168 } 1169 // Should be pure TDC with no type-id? 1170 // The only time [RPT] is used, the RPT type is unnecessary 1171 // because there is no alternative but RPT (i.e. TDC) data. 1172 typedef "RPT" { 1173 type "binary"; 1174 amp:amp-type-id 19; 1175 description 1176 "Identify and define a report template."; 1178 // how is this different from TDC type + MID? 1179 amp:amp-type-item "id" { type "MID"; } 1180 amp:amp-type-item "entry-count" { type "SDNV"; } 1181 // These really need not be BLOBs with internal sizes? 1182 amp:amp-type-item "entry-types" { type "BLOB"; } 1183 amp:amp-type-list "entry-values" { type "BLOB"; } 1184 } 1185 // May be useful to define a protocol-level CONFIGURE type which 1186 // looks similar to... 1187 //typedef CFG { 1188 // amp:amp-type-item "target-id" { type "MID"; } 1189 // amp:amp-type-list "value" { type "BLOB"; } 1190 //} 1191 // This would allow a simple macro of CFG values 1193 // Should be pure DEF with no type-id? 1194 // The only time MACRO is used is not for encoding, but for 1195 // typing objects in OID tree. 1196 typedef "MACRO" { 1197 type "DEF"; 1198 amp:amp-type-id 20; 1199 description "Ordered list of control/macro MID values."; 1200 } 1201 typedef "UNK" { 1202 type "binary"; 1203 amp:amp-type-id 21; 1204 description "Invalid type"; 1205 } 1206 } 1208 1210 A.3. AMP Extensions Submodule 1212 The following YANG definition includes extensions specific to AMP. 1214 file "amp-extensions.yang" 1215 submodule amp-extensions { 1216 belongs-to amp-adm { 1217 prefix "amp"; 1218 } 1220 organization 1221 "IETF Delay Tolerant Networking Working Group"; 1222 contact 1223 "WG Web: 1224 WG List: 1226 WG Chairs: Brian Haberman 1227 1228 Marc Blanchet 1229 1231 Editor: Brian Sipos 1232 "; 1234 description 1235 "This submodule contains the set of core extensions necessary to " 1236 +"define an Asynchronous Management Protocol data model."; 1237 reference "draft Asynchronous Management Protocol"; 1239 revision "2016-04-01" { 1240 description "Updated to fix typos."; 1241 reference "I-D draft-bsipos-dtn-amp-yang"; 1242 } 1243 revision "2016-03-14" { 1244 description "Initial draft release."; 1245 reference "I-D draft-bsipos-dtn-amp-yang"; 1246 } 1248 extension fulloid { 1249 argument "value"; 1250 description 1251 "This extension defines the complete OID for the parent " 1252 +"statement. "; 1253 } 1254 extension suboid { 1255 argument "value"; 1256 description 1257 "This extension defines a sub-OID of a statement relative " 1258 +"to a parent-statement OID."; 1259 } 1261 extension nickname { 1262 argument "id"; 1263 description 1264 "A nickname is a single integer ID which correpsonds to a " 1265 +"full OID value."; 1266 } 1267 extension compressoid { 1268 argument "value"; 1269 description 1270 "This extension allows using an ADM nickname within the " 1271 +"ADM itself."; 1272 } 1274 extension "group" { 1275 argument "name"; 1276 description 1277 "A logical grouping of ADM items under a parent OID."; 1278 } 1280 extension "primitive" { 1281 argument "name"; 1282 description "A single typed value associated with an OID."; 1283 } 1285 extension "computed" { 1286 argument "name"; 1287 description "A single typed value-expression associated with an OID."; 1288 } 1290 extension "report" { 1291 argument "name"; 1292 description "Definition of a report within an ADM."; 1293 } 1294 extension "reportitem" { 1295 argument "name"; 1296 description 1297 "A reference to a primitive within a report definition."; 1298 } 1300 extension "control" { 1301 argument "name"; 1302 description "Definition of a control within an ADM."; 1303 } 1304 extension "parameter" { 1305 argument "name"; 1306 description 1307 "An individual parameter to a \"control\" statement. " 1308 +"Order of parameters is signifigant within a control."; 1309 } 1310 extension "result" { 1311 argument "name"; 1312 description 1313 "An individual result value reported as a response to " 1314 +"a \"control\" statement. " 1315 +"Order of results is signifigant within a control."; 1316 } 1317 } 1319 1321 A.4. AMP Instances Submodule 1323 The following YANG definition includes extensions to define AMP 1324 instance values. 1326 file "amp-instances.yang" 1327 submodule amp-instances { 1328 belongs-to amp-adm { 1329 prefix "amp"; 1330 } 1332 organization 1333 "IETF Delay Tolerant Networking Working Group"; 1334 contact 1335 "WG Web: 1336 WG List: 1338 WG Chairs: Brian Haberman 1339 1340 Marc Blanchet 1341 1343 Editor: Brian Sipos 1344 "; 1346 description 1347 "This submodule contains the extensions necessary to " 1348 +"define AMP data instances directly in an ADM."; 1349 reference "draft Asynchronous Management Protocol"; 1351 revision "2016-04-01" { 1352 description "Updated to fix typos."; 1353 reference "I-D draft-bsipos-dtn-amp-yang"; 1354 } 1355 revision "2016-03-14" { 1356 description "Initial draft release."; 1357 reference "I-D draft-bsipos-dtn-amp-yang"; 1358 } 1360 extension number-instance { 1361 argument "value"; 1362 description 1363 "Instantiate a value of BYTE, INT, UINT, VAST, UVAST, " 1364 +"SDNV, REAL32, or REAL64 within an ADM."; 1365 } 1366 extension number-type { 1367 argument "name"; 1368 description 1369 "The type name of a number-instance."; 1370 } 1372 extension string-instance { 1373 argument "value"; 1374 description 1375 "Instantiate a value of STR from a text value."; 1376 } 1378 extension TS-instance { 1379 argument "value"; 1380 description 1381 "Instantiate a value of TS from a text value. " 1382 +"The value is encoded according to RFC3339."; 1383 } 1385 extension MID-instance { 1386 description 1387 "Instantiate a value of MID from substatements " 1388 +"specializing the MID."; 1389 /// Must contain instance-identifer, amp:fulloid, or amp:compressoid 1390 /// May also contain DC-instance for parameterized OID 1391 } 1392 /// are type and cat necessary? 1393 extension MID-type { 1394 argument "value"; 1395 description "One of data, control, literal, or operator. " 1396 +"Default is data."; 1397 } 1398 extension MID-category { 1399 argument "value"; 1400 description "One of atomic, computed, or collection. " 1401 +"Default is atomic."; 1402 } 1403 extension MID-issuer { 1404 argument "value"; 1405 description "A numeric value identifying an issuer."; 1406 } 1407 extension MID-tag { 1408 argument "value"; 1409 description "A numeric value identifying a tag."; 1410 } 1412 extension BLOB-instance { 1413 argument "value"; 1414 description 1415 "Instantiate a value of BLOB from a text value. " 1416 +"The value is encoded in Base-64 per RFC3548. "; 1417 } 1419 extension DC-instance { 1420 description 1421 "Instantiate a value of DC from BLOB-instance substatements."; 1422 } 1423 extension TDC-instance { 1424 description 1425 "Instantiate a value of TDC from *-instance substatements."; 1426 } 1427 extension MC-instance { 1428 description 1429 "Instantiate a value of MC from MID-instance substatements."; 1430 } 1432 /// Really is just MC-instance 1433 extension MACRO-instance { 1434 description 1435 "Instantiate a value of MACRO from MID-instance substatements."; 1436 } 1438 } 1440 1441 Appendix B. Example Application Data Model 1443 The following YANG definition includes extensions specific to AMP. 1445 module example-adm { 1446 namespace "urn:example-adm"; 1447 prefix "example-adm"; 1449 import amp-adm { 1450 prefix "amp"; 1451 } 1453 organization "Example Org."; 1454 description "Example module."; 1456 amp:fulloid "1.3.6.1.2.3.3"; 1458 amp:nickname "3" { 1459 amp:fulloid "1.3.6.1.2"; 1460 } 1462 amp:group "primitives" { 1463 amp:suboid "1"; 1464 description "Primitive data available for getting or setting"; 1466 amp:primitive "example" { 1467 amp:suboid "1"; 1468 type "amp:UVAST"; 1469 description "Example value."; 1470 } 1471 } 1473 amp:group "reports" { 1474 amp:suboid 3; 1476 amp:report showall { 1477 amp:suboid 8; 1479 amp:MC-instance { 1480 amp:MID-instance { 1481 // instance-identifier "/primitives/example"; 1482 } 1483 } 1484 } 1485 } 1487 amp:group "controls" { 1488 amp:suboid "4"; 1489 description "Container for all commands in this ADM."; 1491 amp:control "get" { 1492 amp:suboid "2"; 1493 description "Get a single MIB value from the agent."; 1495 amp:parameter "corrid" { 1496 type "amp:SDNV"; 1497 description "The correlation identifier for the request."; 1498 } 1499 amp:parameter "object" { 1500 type "amp:MID"; 1501 description "Identity of the object to retrieve."; 1502 } 1504 amp:result "corrid" { 1505 type "amp:SDNV"; 1506 description "The correlation identifier for the response."; 1507 } 1508 amp:result "errorcode" { 1509 type "amp:BYTE"; 1510 description "If non-zero, an indicator of an error."; 1511 } 1512 amp:result "data" { 1513 type "amp:BLOB"; 1514 description "Encoded value of the object."; 1515 } 1516 } 1518 amp:control "set" { 1519 amp:suboid "3"; 1520 description "Set a single MIB value in the agent."; 1522 amp:parameter "corrid" { 1523 type "amp:SDNV"; 1524 description "The correlation identifier for the request."; 1525 } 1526 amp:parameter "object" { 1527 type "amp:MID"; 1528 description "Identify the value to retrieve."; 1529 } 1530 amp:parameter "data" { 1531 type "amp:BLOB"; 1532 description "Encoded value used to write the object."; 1533 } 1535 amp:result "corrid" { 1536 type "amp:SDNV"; 1537 description "The correlation identifier for the response."; 1538 } 1539 amp:result "errorcode" { 1540 type "amp:BYTE"; 1541 description "If non-zero, an indicator of an error."; 1542 } 1543 } 1544 } 1546 } 1548 Authors' Addresses 1550 Brian Sipos 1551 RKF Engineering Solutions, LLC 1552 1229 19th Street NW 1553 Wasington, DC 20036 1554 US 1556 Email: BSipos@rkf-eng.com 1558 Edward Birrane (editor) 1559 Johns Hopkins University Applied Physics Laboratory 1561 Email: Edward.Birrane@jhuapl.edu