idnits 2.17.1 draft-ietf-netmod-yang-metadata-07.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC6110, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 21, 2016) is 2955 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) -- Looks like a reference, but probably isn't: '6' on line 554 -- Looks like a reference, but probably isn't: '3' on line 554 -- Looks like a reference, but probably isn't: '7' on line 554 -- Looks like a reference, but probably isn't: '8' on line 554 == Outdated reference: A later version (-14) exists of draft-ietf-netmod-rfc6020bis-11 == Outdated reference: A later version (-10) exists of draft-ietf-netmod-yang-json-09 ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) == Outdated reference: A later version (-18) exists of draft-ietf-netconf-restconf-10 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETMOD Working Group L. Lhotka 3 Internet-Draft CZ.NIC 4 Updates: 6110 (if approved) March 21, 2016 5 Intended status: Standards Track 6 Expires: September 22, 2016 8 Defining and Using Metadata with YANG 9 draft-ietf-netmod-yang-metadata-07 11 Abstract 13 This document defines a YANG extension statement that allows for 14 defining metadata annotations in YANG modules. The document also 15 specifies XML and JSON encoding of annotations and other rules for 16 annotating instances of YANG data nodes. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on September 22, 2016. 35 Copyright Notice 37 Copyright (c) 2016 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2.1. Keywords . . . . . . . . . . . . . . . . . . . . . . . . 5 55 2.2. Terms Defined in Other Documents . . . . . . . . . . . . 5 56 2.3. Namespaces and Prefixes . . . . . . . . . . . . . . . . . 6 57 2.4. Definitions of New Terms . . . . . . . . . . . . . . . . 7 58 3. Defining Annotations in YANG . . . . . . . . . . . . . . . . 7 59 3.1. Example Definition . . . . . . . . . . . . . . . . . . . 8 60 4. Using Annotations . . . . . . . . . . . . . . . . . . . . . . 8 61 5. The Encoding of Annotations . . . . . . . . . . . . . . . . . 9 62 5.1. XML Encoding . . . . . . . . . . . . . . . . . . . . . . 9 63 5.2. JSON Encoding . . . . . . . . . . . . . . . . . . . . . . 10 64 5.2.1. Metadata Object and Annotations . . . . . . . . . . . 10 65 5.2.2. Adding Annotations to Anydata, Container and List 66 Entries . . . . . . . . . . . . . . . . . . . . . . . 11 67 5.2.3. Adding Annotations to Anyxml and Leaf Instances . . . 11 68 5.2.4. Adding Annotations to Leaf-list Entries . . . . . . . 12 69 6. Representing Annotations in DSDL Schemas . . . . . . . . . . 13 70 7. Metadata YANG Module . . . . . . . . . . . . . . . . . . . . 14 71 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 72 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 73 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 74 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 75 11.1. Normative References . . . . . . . . . . . . . . . . . . 17 76 11.2. Informative References . . . . . . . . . . . . . . . . . 18 77 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 19 78 A.1. Changes Between Revisions -06 and -07 . . . . . . . . . . 19 79 A.2. Changes Between Revisions -05 and -06 . . . . . . . . . . 19 80 A.3. Changes Between Revisions -04 and -05 . . . . . . . . . . 19 81 A.4. Changes Between Revisions -03 and -04 . . . . . . . . . . 19 82 A.5. Changes Between Revisions -02 and -03 . . . . . . . . . . 19 83 A.6. Changes Between Revisions -01 and -02 . . . . . . . . . . 19 84 A.7. Changes Between Revisions -00 and -01 . . . . . . . . . . 20 85 A.8. Changes Between draft-lhotka-netmod-yang-metadata-01 and 86 draft-ietf-netmod-yang-metadata-00 . . . . . . . . . . . 20 87 A.9. Changes Between draft-lhotka-netmod-yang-metadata-00 and 88 -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 89 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20 91 1. Introduction 93 There is a need to be able to annotate instances of 94 YANG [I-D.ietf-netmod-rfc6020bis] data nodes with metadata. Typical 95 use cases are: 97 o Complementing regular data model information with instance- 98 specific metadata, comments etc. 100 o Providing information about data rendering in user interfaces. 102 o Deactivating a subtree in a configuration datastore while keeping 103 the data in place. 105 o Network management protocols often use metadata annotations for 106 various purposes in both operation requests and responses. For 107 example, the operation in the NETCONF protocol (see 108 section 7.2 of [RFC6241]) uses annotations in the form of XML 109 attributes for identifying the location in a configuration 110 datastore and the type of the operation. 112 However, metadata annotations could potentially lead to 113 interoperability problems if they are used in an ad hoc fashion by 114 different parties and/or without proper documentation. A sound 115 metadata framework for YANG should therefore satisfy these 116 requirements: 118 1. The set of annotations must be extensible in a decentralised 119 manner so as to allow for defining new annotations without 120 running into the risk of collisions with annotations defined and 121 used by others. 123 2. Syntax and semantics of annotations must be documented and the 124 documentation must be easily accessible. 126 3. Clients of network management protocols such as NETCONF [RFC6241] 127 or RESTCONF [I-D.ietf-netconf-restconf] must be able to discover 128 all annotations supported by a given server and identify each of 129 them correctly. 131 4. Annotations sent by a server should not break clients that don't 132 support them. 134 This document proposes a systematic way for defining metadata 135 annotations. For this purpose, YANG extension statement "annotation" 136 is defined in the module "ietf-yang-metadata" (Section 7). Other 137 YANG modules importing this module can use the "annotation" statement 138 for defining one or more annotations. 140 The benefits of defining the metadata annotations in a YANG module 141 are the following: 143 o Each annotation is bound to a YANG module name and namespace URI. 144 This makes its encoding in instance documents (both XML and JSON) 145 straightforward and consistent with the encoding of YANG data node 146 instances. 148 o Annotations defined in IETF standard-track documents are 149 indirectly registered through IANA in the "YANG Module Names" 150 registry [RFC6020]. 152 o Annotations are included in the data model. YANG compilers and 153 tools supporting a certain annotation can thus take them into 154 account and modify their behavior accordingly. 156 o Semantics of an annotation are defined in the "description" and 157 "reference" statements. 159 o An annotation can be declared as conditional by using the "if- 160 feature" statement. 162 o The type of each annotation is explicitly specified; any YANG 163 built-in or derived type that is available for leaf or leaf-list 164 data nodes may be specified for annotations as well. 166 In the XML encoding, XML attributes are a natural instrument for 167 attaching annotations to data node instances. This document 168 deliberately adopts some restrictions in order to remain compatible 169 with the XML encoding of YANG data node instances and limitations of 170 XML attributes. Specifically, 172 o annotations can only be scalar values; 174 o annotations cannot be attached to a whole list or leaf-list 175 instance, only to individual list or leaf-list entries. 177 Due to the rules for YANG extensions (see sec. 6.3.1 in 178 [I-D.ietf-netmod-rfc6020bis]), annotation definitions posit 179 relatively weak conformance requirements. The alternative of 180 introducing a new built-in YANG statement for defining annotations 181 was considered, but it was seen as a major change to the language 182 that is inappropriate for YANG 1.1, which was chartered as a 183 maintenance revision. After evaluating real-life usage of metadata 184 annotations, it is conceivable that such a new built-in statement 185 might be added in a future revision of YANG. 187 2. Terminology 188 2.1. Keywords 190 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 191 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 192 document are to be interpreted as described in [RFC2119]. 194 2.2. Terms Defined in Other Documents 196 The following terms are defined in [RFC6241]: 198 o capability, 200 o client, 202 o datastore, 204 o message, 206 o protocol operation, 208 o server. 210 The following terms are defined in [I-D.ietf-netmod-rfc6020bis]: 212 o action, 214 o anydata, 216 o anyxml, 218 o built-in type, 220 o container, 222 o data model, 224 o data node, 226 o data tree, 228 o derived type, 230 o extension, 232 o leaf, 234 o leaf-list, 235 o list, 237 o module, 239 o RPC input and output. 241 The following terms are defined in [W3C.REC-xml-infoset-20040204]: 243 o attribute, 245 o document, 247 o element. 249 The following terms are defined in [W3C.REC-xml-names11-20060816]: 251 o local name, 253 o namespace name, 255 o prefix, 257 o qualified name. 259 The following terms are defined in [RFC7159]: 261 o array, 263 o member, 265 o object, 267 o primitive type. 269 2.3. Namespaces and Prefixes 271 In the following text, XML element names and YANG extension 272 statements are always written with explicit namespace prefixes that 273 are assumed to be bound to URI references as shown in Table 1. 275 +--------+------------------------------------------------+ 276 | Prefix | URI Reference | 277 +--------+------------------------------------------------+ 278 | elm | http://example.org/example-last-modified | 279 | md | urn:ietf:params:xml:ns:yang:ietf-yang-metadata | 280 | rng | http://relaxng.org/ns/structure/1.0 | 281 +--------+------------------------------------------------+ 283 Table 1: Used namespace prefixes and corresponding URI references 285 2.4. Definitions of New Terms 287 o annotation: a single item of metadata that is attached to YANG 288 data node instances. 290 o metadata: additional information that complements a data tree. 292 o metadata object: an object in JSON encoding that contains all 293 annotations attached to a given data node instance. 295 3. Defining Annotations in YANG 297 Metadata annotations are defined by YANG extension statement 298 "md:annotation". This YANG language extension is defined in the 299 module "ietf-yang-metadata" (Section 7). 301 Substatements of "md:annotation" are shown in Table 2. They are all 302 core YANG statements, and the numbers in the second column refer to 303 the corresponding section in [I-D.ietf-netmod-rfc6020bis] where each 304 statement is described. 306 +--------------+---------------------+-------------+ 307 | substatement | RFC 6020bis section | cardinality | 308 +--------------+---------------------+-------------+ 309 | description | 7.21.3 | 0..1 | 310 | if-feature | 7.20.2 | 0..n | 311 | reference | 7.21.4 | 0..1 | 312 | status | 7.21.2 | 0..1 | 313 | type | 7.6.3 | 1 | 314 | units | 7.3.3 | 0..1 | 315 +--------------+---------------------+-------------+ 317 Table 2: Substatements of "md:annotation". 319 An annotation carries a single value. The type substatement, which 320 MUST be present, takes as an argument the name of an existing built- 321 in or derived type, and the value of the annotation MUST match this 322 type. See Section 7.4 of [I-D.ietf-netmod-rfc6020bis] for details. 324 An annotation can be made conditional by using one or more "if- 325 feature" statements; the annotation is then supported only by servers 326 that advertise the corresponding feature. 328 The semantics and usage rules for an annotation SHOULD be fully 329 specified in "description", "reference" and "units" statements. 331 An annotation MUST NOT change the data tree semantics defined by 332 YANG. For example, it is illegal to define and use an annotation 333 that allows for overriding uniqueness of leaf-list entries. 335 The "status" statement can be used exactly as for YANG data nodes. 337 A YANG module containing one or more "md:annotation" extension 338 statements SHOULD NOT be used for defining data nodes or groupings. 339 Also, derived types, identities and features SHOULD NOT be defined in 340 such a module unless they are used by the definitions of annotations 341 in that module. 343 3.1. Example Definition 345 The following module defines the "last-modified" annotation: 347 module example-last-modified { 348 namespace "http://example.org/example-last-modified"; 349 prefix "elm"; 350 import ietf-yang-types { 351 prefix "yang"; 352 } 353 import ietf-yang-metadata { 354 prefix "md"; 355 } 356 md:annotation last-modified { 357 type yang:date-and-time; 358 description 359 "This annotation contains date and time when the 360 annotated instance was last modified (or created)."; 361 } 362 } 364 4. Using Annotations 366 By advertising a YANG module in which a metadata annotation is 367 defined using the "md:annotation" statement, a server indicates that 368 it is prepared to handle that annotation according to the 369 annotation's definition. That is, an annotation advertised by the 370 server may be attached to an instance of a data node defined in any 371 YANG module that is implemented by the server. 373 Depending on its semantics, an annotation may have an effect only in 374 certain data trees and/or on instances of specific data nodes types. 376 A client MUST NOT add a specific annotation to data node instances if 377 the server didn't advertise it. 379 Due care has to be exercised when introducing annotations in network 380 management systems in order to avoid interoperability problems and 381 software failures caused by a client that does not understand the 382 annotations' semantics. Generally, it is safe for a server to use 383 annotations in the following cases: 385 o An annotation is an integral part of a built-in or negotiated 386 protocol capability. 388 o An annotation contains auxiliary information that is not critical 389 for protocol operation. 391 o The client explicitly asks the server, e.g., via a parameter of a 392 protocol operation request, for including an annotation in the 393 response. 395 5. The Encoding of Annotations 397 XML attributes are a natural choice for encoding metadata in XML 398 instance documents. For JSON [RFC7159], there is no generally 399 established method for encoding metadata. This document thus 400 introduces a special encoding method that is consistent with the JSON 401 encoding of YANG data node instances as defined 402 in [I-D.ietf-netmod-yang-json]. 404 5.1. XML Encoding 406 Metadata annotations are added to XML-encoded instances of YANG data 407 nodes as XML attributes according to these rules: 409 o The local name of the attribute SHALL be the same as the name of 410 the annotation specified in the argument of the corresponding 411 "md:annotation" statement. 413 o The namespace of the attribute SHALL be identified by the URI that 414 appears as the argument of the "namespace" statement in the YANG 415 module where the annotation is defined. It is RECOMMENDED that 416 the prefix specified by the "prefix" statement in the same module 417 is used in the qualified name of the attribute. 419 o The attribute value SHALL be encoded in the same way as the value 420 of a YANG leaf instance having the same type, 421 see [I-D.ietf-netmod-rfc6020bis], sec. 9. 423 For example, the "last-modified" annotation defined in Section 3.1 424 may be encoded as follows: 426 428 ... 429 431 5.2. JSON Encoding 433 The JSON metadata encoding defined in this section has the following 434 properties: 436 1. The encoding of YANG data node instances as defined in 437 [I-D.ietf-netmod-yang-json] does not change. 439 2. Namespaces of metadata annotations are encoded in the same way as 440 namespaces of YANG data node instances, see 441 [I-D.ietf-netmod-yang-json]. 443 5.2.1. Metadata Object and Annotations 445 All metadata annotations assigned to a YANG data node instance are 446 encoded as members (name/value pairs) of a single JSON object, 447 henceforth denoted as the metadata object. The placement and name of 448 this object depends on the type of the data node as specified in the 449 following subsections. 451 The name of a metadata annotation (as a member of the metadata 452 object) has the following ABNF syntax [RFC5234], where the production 453 for "identifier" is defined in sec. 13 of 454 [I-D.ietf-netmod-rfc6020bis] 456 annotation-name = identifier ":" identifier 458 where the left identifier is the name of the YANG module in which the 459 annotation is defined, and the identifier on the right is the name of 460 the annotation specified in the argument of the corresponding 461 "md:annotation" statement. 463 Note that unlike member names of YANG data node instances in JSON 464 encoding (see sec. 4 in [I-D.ietf-netmod-yang-json]), for annotations 465 the explicit namespace identifier (module name) must always be 466 present. 468 The value of a metadata annotation SHALL be encoded in exactly the 469 same way as the value of a YANG leaf node having the same type as the 470 annotation, see [I-D.ietf-netmod-yang-json], sec. 6. 472 5.2.2. Adding Annotations to Anydata, Container and List Entries 474 For a data node instance that is encoded as a JSON object (i.e., a 475 container, list entry, or anydata node), the metadata object is added 476 as a new member of that object with the name "@". 478 Examples: 480 o "cask" is a container or anydata node: 482 "cask": { 483 "@": { 484 "example-last-modified:last-modified": 485 "2015-09-16T10:27:35+02:00" 486 }, 487 ... 488 } 490 o "seq" is a list whose key is "name", annotation "last-modified" is 491 added only to the first entry: 493 "seq": [ 494 { 495 "@": { 496 "example-last-modified:last-modified": 497 "2015-09-16T10:27:35+02:00" 498 }, 499 "name": "one", 500 ... 501 }, 502 { 503 "name": "two", 504 ... 505 } 506 ] 508 5.2.3. Adding Annotations to Anyxml and Leaf Instances 510 For an anyxml or leaf instance, the metadata object is added as a 511 sibling name/value pair whose name is the symbol "@" concatenated 512 with the name of the leaf or anyxml member that is being annotated. 513 The namespace part (module name) is included if and only if it is in 514 the name of the annotated member. 516 Examples: 518 o "flag" is a leaf node of the "boolean" type defined in module 519 "foo", and we assume the namespace name has to be expressed in its 520 JSON encoding: 522 "foo:flag": true, 523 "@foo:flag": { 524 "example-last-modified:last-modified": 525 "2015-09-16T10:27:35+02:00" 526 } 528 o "stuff" is an anyxml node: 530 "stuff": [1, null, "three"], 531 "@stuff": { 532 "example-last-modified:last-modified": 533 "2015-09-16T10:27:35+02:00" 534 } 536 5.2.4. Adding Annotations to Leaf-list Entries 538 For a leaf-list entry, which is represented as a JSON array with 539 values of a primitive type, annotations may be assigned to one or 540 more entries by adding a name/array pair as a sibling of the leaf- 541 list entry, where the name is symbol "@" concatenated with the name 542 of the leaf-list that is being annotated, and the value is a JSON 543 array whose i-th element is the metadata object with annotations 544 assigned to the i-th entry of the leaf-list entry, or null if the 545 i-th entry has no annotations. 547 Trailing null values in that array, i.e., those following the last 548 non-null metadata object, MAY be omitted. 550 For example, in the following leaf-list instance with four entries, 551 the "last-modified" annotation is added to the second and third entry 552 in the following way: 554 "bibliomod:folio": [6, 3, 7, 8], 555 "@bibliomod:folio": [ 556 null, 557 { "example-last-modified:last-modified": 558 "2015-06-18T17:01:14+02:00" 559 }, 560 { "example-last-modified:last-modified": 561 "2015-09-16T10:27:35+02:00" 562 } 563 ] 565 6. Representing Annotations in DSDL Schemas 567 [RFC6110] defines the standard mapping of YANG data models to 568 Document Schema Definition Languages (DSDL) [ISO.19757-1]. This 569 section specifies the mapping for the extension statement 570 "md:annotation" (Section 7), which enables validation of XML instance 571 documents containing metadata annotations. 573 The first step of the DSDL mapping procedure, i.e., the 574 transformation of the YANG data model to the hybrid schema (see 575 sec. 6 in [RFC6110]), is modified as follows: 577 1. If the data model contains at least one "md:annotation" 578 statement, then a RELAX NG named pattern definition MUST be added 579 as a child of the root element in the hybrid 580 schema. It is RECOMMENDED to use the name "__yang_metadata__" 581 for this named pattern. 583 2. A reference to the named pattern described in item 1 MUST be 584 included as a child of every pattern that 585 corresponds to an anydata, container, leaf, leaf-list or list 586 data node. 588 3. Every metadata annotation definition in the form 590 md:annotation ARGUMENT { 591 ... 592 } 594 is mapped to the following RELAX NG pattern: 596 597 598 ... 599 600 602 where PREFIX is the prefix bound to the namespace URI of the YANG 603 module that contains the "md:annotation" statement. The above 604 pattern SHALL be inserted as a child of the named pattern 605 described in item 1. 607 4. Substatements of "md:annotation" SHALL be mapped to children of 608 the "rng:attribute" pattern exactly as described in sec. 10 of 609 [RFC6110]. 611 For example, the named pattern (item 1), when constructed only for 612 the "last-modified" annotation, will have the following definition: 614 615 616 617 618 619 620 622 Every "rng:element" pattern that corresponds to an anydata, 623 container, leaf, list or leaf-list data node will then contain a 624 reference to the above named pattern, for example 626 627 628 ... 629 631 Note that it is not necessary to use such a reference for 632 "rng:element" patterns corresponding to anyxml data nodes because 633 they already permit any XML attributes to be attached to their 634 instances. 636 The second step of the DSDL mapping procedure, i.e., the 637 transformation of the hybrid schema to RELAX NG, Schematron and DSRL 638 schemas, is unaffected by the inclusion of "md:annotation". 640 7. Metadata YANG Module 642 RFC Editor: In this section, replace all occurrences of 'XXXX' with 643 the actual RFC number and all occurrences of the revision date below 644 with the date of RFC publication (and remove this note). 646 RFC Editor: Also please replace all occurrences of 'RFC 6020bis' with 647 the actual RFC number that will be assigned to 648 [I-D.ietf-netmod-rfc6020bis]. 650 file "ietf-yang-metadata@2016-03-21.yang" 652 module ietf-yang-metadata { 654 namespace "urn:ietf:params:xml:ns:yang:ietf-yang-metadata"; 656 prefix "md"; 658 organization 659 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 661 contact 662 "WG Web: 663 WG List: 665 WG Chair: Lou Berger 666 668 WG Chair: Juergen Schoenwaelder 669 671 WG Chair: Kent Watsen 672 674 Editor: Ladislav Lhotka 675 "; 677 description 678 "This YANG module defines an extension statement that allows for 679 defining metadata annotations. 681 Copyright (c) 2016 IETF Trust and the persons identified as 682 authors of the code. All rights reserved. 684 Redistribution and use in source and binary forms, with or 685 without modification, is permitted pursuant to, and subject to 686 the license terms contained in, the Simplified BSD License set 687 forth in Section 4.c of the IETF Trust's Legal Provisions 688 Relating to IETF Documents 689 (http://trustee.ietf.org/license-info). 691 This version of this YANG module is part of RFC XXXX 692 (http://tools.ietf.org/html/rfcXXXX); see the RFC itself for 693 full legal notices."; 695 revision 2016-03-21 { 696 description 697 "Initial revision."; 698 reference 699 "RFC XXXX: Defining and Using Metadata with YANG"; 700 } 702 extension annotation { 703 argument name; 704 description 705 "This extension allows for defining metadata annotations in 706 YANG modules. The 'md:annotation' statement can appear only at 707 the top level of a YANG module or submodule, i.e. it becomes a 708 new alternative in the ABNF production rule for 'body-stmts' 709 (sec. 14 in RFC 6020bis). 711 The argument of the 'md:annotation' statement defines the name 712 of the annotation. Syntactically it is a YANG identifier as 713 defined in RFC 6020bis, sec. 6.2. 715 An annotation defined with this extension statement inherits 716 the namespace and other context from the YANG module in which 717 it is defined. 719 Data type of the annotation value is specified in the same way 720 as for a leaf data node using the 'type' statement. 722 Semantics of the annotation and other documentation can be 723 specified using the following standard YANG substatements (all 724 are optional): 'description', 'if-feature', 'reference', 725 'status', and 'units'. 727 A server announces support for a particular annotation by 728 including the module in which the annotation is defined among 729 the advertised YANG modules (e.g., in NETCONF hello message or 730 yang-library). The annotation then can be attached to any 731 instance of data node defined in any YANG module that is 732 advertised by the server. 734 XML and JSON encoding of annotations is defined in 735 RFC XXXX."; 736 } 737 } 739 741 8. IANA Considerations 743 RFC Editor: In this section, replace all occurrences of 'XXXX' with 744 the actual RFC number and all occurrences of the revision date below 745 with the date of RFC publication (and remove this note). 747 This document registers a URI in the "IETF XML registry" [RFC3688]. 748 Following the format in RFC 3688, the following registration has been 749 made. 751 --------------------------------------------------------------------- 752 URI: urn:ietf:params:xml:ns:yang:ietf-yang-metadata 754 Registrant Contact: The NETMOD WG of the IETF. 756 XML: N/A, the requested URI is an XML namespace. 757 --------------------------------------------------------------------- 758 This document registers a YANG module in the "YANG Module Names" 759 registry [RFC6020]. 761 --------------------------------------------------------------------- 762 name: ietf-yang-metadata 763 namespace: urn:ietf:params:xml:ns:yang:ietf-yang-metadata 764 prefix: md 765 reference: RFC XXXX 766 --------------------------------------------------------------------- 768 9. Security Considerations 770 This document introduces a mechanism for defining metadata 771 annotations in YANG modules and attaching them to instances of YANG 772 data nodes. By itself, this mechanism represents no security threat. 773 Security implications of a particular annotation defined using this 774 mechanism MUST be duly considered and documented in the the 775 annotation's definition. 777 An annotation SHOULD be subject to the same or stricter access 778 control rules as the data node instance to which the annotation is 779 attached. It is RECOMMENDED that security-sensitive or privacy- 780 sensitive data be modeled as regular YANG data nodes rather than 781 annotations. 783 10. Acknowledgments 785 The author wishes to thank Andy Bierman, Martin Bjorklund, Benoit 786 Claise, Juergen Schoenwaelder, and Kent Watsen for their helpful 787 comments and suggestions. 789 11. References 791 11.1. Normative References 793 [I-D.ietf-netmod-rfc6020bis] 794 Bjorklund, M., "The YANG 1.1 Data Modeling Language", 795 draft-ietf-netmod-rfc6020bis-11 (work in progress), 796 February 2016. 798 [I-D.ietf-netmod-yang-json] 799 Lhotka, L., "JSON Encoding of Data Modeled with YANG", 800 draft-ietf-netmod-yang-json-09 (work in progress), March 801 2016. 803 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 804 Requirement Levels", BCP 14, RFC 2119, 805 DOI 10.17487/RFC2119, March 1997, 806 . 808 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 809 DOI 10.17487/RFC3688, January 2004, 810 . 812 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 813 Specifications: ABNF", STD 68, RFC 5234, 814 DOI 10.17487/RFC5234, January 2008, 815 . 817 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 818 the Network Configuration Protocol (NETCONF)", RFC 6020, 819 DOI 10.17487/RFC6020, October 2010, 820 . 822 [RFC6110] Lhotka, L., Ed., "Mapping YANG to Document Schema 823 Definition Languages and Validating NETCONF Content", 824 RFC 6110, DOI 10.17487/RFC6110, February 2011, 825 . 827 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 828 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 829 2014, . 831 [W3C.REC-xml-infoset-20040204] 832 Cowan, J. and R. Tobin, "XML Information Set (Second 833 Edition)", World Wide Web Consortium Recommendation REC- 834 xml-infoset-20040204, February 2004, 835 . 837 [W3C.REC-xml-names11-20060816] 838 Bray, T., Hollander, D., Layman, A., and R. Tobin, 839 "Namespaces in XML 1.1 (Second Edition)", World Wide Web 840 Consortium Recommendation REC-xml-names11-20060816, August 841 2006, 842 . 844 11.2. Informative References 846 [I-D.ietf-netconf-restconf] 847 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 848 Protocol", draft-ietf-netconf-restconf-10 (work in 849 progress), March 2016. 851 [ISO.19757-1] 852 International Organization for Standardization, "Document 853 Schema Definition Languages (DSDL) - Part 1: Overview", 854 ISO/IEC 19757-1, November 2004. 856 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 857 and A. Bierman, Ed., "Network Configuration Protocol 858 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 859 . 861 Appendix A. Change Log 863 RFC Editor: Remove this section upon publication as an RFC. 865 A.1. Changes Between Revisions -06 and -07 867 o Added sentence in Sec. 9 (Stephen Farrell's suggestion). 869 A.2. Changes Between Revisions -05 and -06 871 o Added explanation of why a YANG extension is used rather than a 872 built-in statement. 874 A.3. Changes Between Revisions -04 and -05 876 o Clarification regarding the type of an annotation. 878 A.4. Changes Between Revisions -03 and -04 880 o Added explanation of what "top level of a module" means. 882 A.5. Changes Between Revisions -02 and -03 884 o Section 4 was considerably simplified, also because member names 885 starting with "@" are now permitted by 886 [I-D.ietf-netmod-yang-json]. 888 A.6. Changes Between Revisions -01 and -02 890 o The "type" statement became mandatory. 892 o Terminology section was extended. 894 o The annotation "inactive" defined in the example module was 895 replaced with "last-modified" that is supposedly less 896 controversial. 898 o Introduction now states limitation due to XML attribute 899 properties. 901 o A recommendation was added to define annotations in a module by 902 themselves. 904 o Section "Using Annotations" was added. 906 o An example for "anyxml" was added. 908 o RFC 6241 was moved to informative references. 910 A.7. Changes Between Revisions -00 and -01 912 o Define JSON encoding for annotations attached to 'anydata' nodes. 914 A.8. Changes Between draft-lhotka-netmod-yang-metadata-01 and draft- 915 ietf-netmod-yang-metadata-00 917 o References to RFC 6020 were changed to the 6020bis I-D. 919 o Text about RFC 2119 key words was added to "ietf-yang-metadata" 920 module description. 922 A.9. Changes Between draft-lhotka-netmod-yang-metadata-00 and -01 924 o Encoding of annotations for anyxml nodes was changed to be the 925 same as for leafs. This was necessary because anyxml value now 926 needn't be an object. 928 o It is stated that "md:annotation" statement defines only the 929 syntax of an annotation. 931 o Allowed "if-feature" as a substatement of "md:annotation". 933 Author's Address 935 Ladislav Lhotka 936 CZ.NIC 938 Email: lhotka@nic.cz