idnits 2.17.1 draft-lhotka-netmod-ysdl-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 == Line 476 has weird spacing: '...rw name str...' -- The document date (November 30, 2015) is 3063 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-ietf-netconf-yang-library-02 == Outdated reference: A later version (-14) exists of draft-ietf-netmod-rfc6020bis-08 == Outdated reference: A later version (-18) exists of draft-ietf-netconf-restconf-08 == Outdated reference: A later version (-10) exists of draft-ietf-netmod-yang-json-06 == Outdated reference: A later version (-05) exists of draft-rtgyangdt-rtgwg-device-model-01 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). 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 Intended status: Standards Track November 30, 2015 5 Expires: June 2, 2016 7 YANG Schema Dispatching Language 8 draft-lhotka-netmod-ysdl-00 10 Abstract 12 This document defines YANG Schema Dispatching Language (YSDL). It is 13 a meta-schema language that allows for combining YANG modules into 14 any number of schemas, and arranging these schemas in a hierarchical 15 structure. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on June 2, 2016. 34 Copyright Notice 36 Copyright (c) 2015 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Terminology and Notation . . . . . . . . . . . . . . . . . . 2 53 3. YANG Schema Dispatching Language . . . . . . . . . . . . . . 4 54 3.1. YSDL Schemas . . . . . . . . . . . . . . . . . . . . . . 4 55 3.2. Validating Data with YSDL and YANG . . . . . . . . . . . 5 56 4. YSDL YANG Module . . . . . . . . . . . . . . . . . . . . . . 5 57 5. Example YSDL Meta-Schema . . . . . . . . . . . . . . . . . . 8 58 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 59 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 60 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 61 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 62 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 63 9.2. Informative References . . . . . . . . . . . . . . . . . 13 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 66 1. Introduction 68 YANG data modelling language [I-D.ietf-netmod-rfc6020bis] assumes 69 that data trees (configuration and state data) defined in YANG 70 modules start at the common global root. This means that the global 71 path of every dara node is fixed as soon as the data node is defined 72 (for a node defined in a grouping, the path is fixed when the 73 grouping is used). 75 Recent data modeling efforts, such as 76 [I-D.rtgyangdt-rtgwg-device-model] indicate that this arrangement may 77 be too restrictive. A typical use case is a data model that was 78 designed for a stand-alone device but later needs to be reused for 79 logical or virtual devices, and the original data model has to be 80 grafted as a submodel in a top-level schema describing the 81 organization of logical/virtual devices. 83 This document proposes a new minilanguage named YANG Schema 84 Dispatching Language (YSDL) as a solution to this problem. It is a 85 meta-schema language that allows for defining multiple schemas 86 comprising one or more YANG modules, and arrange the schemas in a 87 hierarchical structure. 89 As a useful side-effect, it is also possible to use YSDL schemas to 90 specify a data model for an "anydata" node at run time. 92 2. Terminology and Notation 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in [RFC2119]. 98 The following terms are defined in [I-D.ietf-netmod-rfc6020bis]: 100 o action, 102 o anydata, 104 o augment, 106 o container, 108 o data node, 110 o data tree, 112 o identity, 114 o instance identifier, 116 o leaf, 118 o leaf-list, 120 o list, 122 o module, 124 o notification, 126 o RPC operation, 128 o schema node. 130 The term "server" denotes a server of a network management protocol 131 such as NETCONF [RFC6241] or RESTCONF [I-D.ietf-netconf-restconf]. 133 A simplified graphical representation of the data model is used in 134 this document. The meaning of the symbols in these diagrams is as 135 follows: 137 o Brackets "[" and "]" enclose list keys. 139 o Curly braces "{" and "}" contain names of optional features that 140 make the corresponding node conditional. 142 o Abbreviations before data node names: "rw" means configuration 143 (read-write), "ro" state data (read-only), "-x" RPC operations, 144 and "-n" notifications. 146 o Symbols after data node names: "?" means an optional node, "!" a 147 container with presence, and "*" denotes a "list" or "leaf-list". 149 o Parentheses enclose choice and case nodes, and case nodes are also 150 marked with a colon (":"). 152 o Ellipsis ("...") stands for contents of subtrees that are not 153 shown. 155 3. YANG Schema Dispatching Language 157 The YSDL syntax is defined in Section 4 using YANG in the role of a 158 schema language. YSDL meta-schemas can be serialized in any encoding 159 supported by YANG, such as XML [I-D.ietf-netmod-rfc6020bis] or 160 JSON [I-D.ietf-netmod-yang-json]. 162 YSDL meta-schemas are intended to be used in conjunction with YANG 163 Library [I-D.ietf-netconf-yang-library]: names and revisions of YANG 164 modules appearing in a meta-schema SHALL be resolved from YANG 165 Library data, and YANG Library specifications of supported features 166 and deviations MUST also be taken into account. 168 A YSDL meta-schema only affects the main data tree (configuration and 169 state data), including actions. RPC operations and notifications are 170 handled exactly as specified in [I-D.ietf-netmod-rfc6020bis]. 172 YANG tree diagram for a YSDL meta-schema is as follows: 174 module: ietf-ysdl 175 +--rw schemas 176 +--rw top-schema? schema-ref 177 +--rw schema* [name] 178 +--rw name string 179 +--rw yang-modules* yang:yang-identifier 180 +--rw subschema* [root] 181 +--rw root schema-node-path 182 +--rw schemas* schema-ref 184 3.1. YSDL Schemas 186 A YSDL meta-schema defines one or more schemas, each comprising one 187 or more YANG modules and zero or more subschemas. The same YANG 188 module can be part of multiple schemas. 190 Exactly one of the schemas MUST be the top-level schema which is 191 identified by the "top-schema" leaf. The top-level schema defines 192 the uppermost structure of the entire data model, and its root always 193 coincides with the global root. 195 Any schema can define other schemas as its subschema. For each 196 subschema, the root node has to be specified. Any "container", 197 "list", "case" or "anydata" schema node contained in one of the 198 parent schema modules can act as the root node. 200 Note that the traditional arrangement of YANG modules in a data model 201 can be achieved with a YSDL meta-schema in which all modules are 202 listed in the top-level schema, and no subschemas are defined. 204 3.2. Validating Data with YSDL and YANG 206 The schema tree of a subschema is conceptually attached to the parent 207 schema tree as a subtree of the root node. In other words, the first 208 data node that is either the subschema root or its ancestor coincides 209 with the conceptual root of the subschema data tree. 211 All paths (in leafrefs, instance-identifiers, XPath expressions and 212 target nodes of augments) are interpreted within the subschema data 213 or schema tree. Therefore, they cannot refer to nodes in the 214 ancestor schemas or other subschemas. 216 4. YSDL YANG Module 218 The "ietf-ysdl" module below defines the YSDL meta-schema language 219 using YANG. However, it is not meant to be implemented as datastore 220 contents by a server. 222 file "ietf-ysdl@2015-11-30.yang" 224 module ietf-ysdl { 226 namespace "urn:ietf:params:xml:ns:yang:ietf-ysdl"; 228 prefix "ysdl"; 230 import ietf-yang-types { 231 prefix "yang"; 232 } 234 organization 235 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 237 contact 238 "WG Web: 239 WG List: 241 WG Chair: Thomas Nadeau 242 244 WG Chair: Juergen Schoenwaelder 245 247 WG Chair: Kent Watsen 248 250 Editor: Ladislav Lhotka 251 "; 253 description 254 "This module defines YANG Schema Dispatching Language (YSDL) - a 255 meta-schema language for YANG-based data models. 257 A YSDL schema allows for embedding a YANG schema as a subschema 258 in a specific location of another module. 260 Copyright (c) 2015 IETF Trust and the persons identified as 261 authors of the code. All rights reserved. 263 Redistribution and use in source and binary forms, with or 264 without modification, is permitted pursuant to, and subject to 265 the license terms contained in, the Simplified BSD License set 266 forth in Section 4.c of the IETF Trust's Legal Provisions 267 Relating to IETF Documents 268 (http://trustee.ietf.org/license-info). 270 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 271 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 272 'OPTIONAL' in the module text are to be interpreted as described 273 in RFC 2119 (http://tools.ietf.org/html/rfc2119). 275 This version of this YANG module is part of RFC XXXX 276 (http://tools.ietf.org/html/rfcXXXX); see the RFC itself for 277 full legal notices."; 279 revision 2015-11-30 { 280 description 281 "Initial revision."; 282 reference 283 "RFC XXXX: YANG Schema Dispatching Language"; 284 } 286 /* Typedefs */ 288 typedef schema-node-path { 289 type string { 290 pattern "[a-zA-Z_][a-zA-Z0-9\\-_.]*:[a-zA-Z_][a-zA-Z0-9\\-_.]*" 291 + "(/([a-zA-Z_][a-zA-Z0-9\\-_.]*" 292 + ":)?[a-zA-Z_][a-zA-Z0-9\\-_.]*)"; 293 } 294 description 295 "Intra-schema path to a YANG schema node. 297 The value is a sequence of schema node names separated by the 298 slash character ('/'). The first (leftmost) component is 299 prefixed with the name of the YANG module in which the schema 300 node is defined. A subsequent component has the module prefix 301 if and only if the preceding schema node is defined in another 302 module."; 303 } 305 typedef schema-ref { 306 type leafref { 307 path "/ysdl:schemas/ysdl:schema/ysdl:name"; 308 } 309 description 310 "Reference to a schema."; 311 } 313 /* YSDL */ 315 container schemas { 316 description 317 "Container for YSDL schemas."; 318 leaf top-schema { 319 type schema-ref; 320 description 321 "Reference to the top-level schema."; 322 } 323 list schema { 324 key "name"; 325 min-elements "1"; 326 description 327 "Each entry is a named schema. Exactly one entry must be the 328 top-level schema, other (optional) entries can be used as 329 subschemas."; 330 leaf name { 331 type string; 332 description 333 "Name of the schema."; 334 } 335 leaf-list yang-modules { 336 type yang:yang-identifier; 337 min-elements "1"; 338 description 339 "Each entry is the name of a YANG module contributing to 340 the schema."; 341 } 342 list subschema { 343 key "root"; 344 description 345 "Each entry is a subschema attached to the parent 346 schema."; 347 leaf root { 348 type schema-node-path; 349 description 350 "Each entry specifies the relative (intra-schema) path to 351 the root node where the subschema is attached. The 352 schema node MUST be one of: container, list, case or 353 anydata. 355 The absolute path of the root node depends on the 356 structure of schemas: 358 - For the top-level schema, the root is always '/'. 360 - For other schemas, the root path is formed by 361 concatenation of the corresponding root paths of all 362 ancestor schemas."; 363 } 364 leaf-list schemas { 365 type schema-ref; 366 description 367 "References to schemas that comprise the subschema."; 368 } 369 } 370 } 371 } 372 } 374 376 5. Example YSDL Meta-Schema 378 The following YANG module will be used for the top-level schema. It 379 is a simplified analogy of the "network-device" module from 380 [I-D.rtgyangdt-rtgwg-device-model]. 382 module example-device { 384 namespace "http://www.example.net/example-device"; 386 prefix "exdev"; 388 container device { 389 container logical-NEs { 390 list logical-NE { 391 key "name"; 392 leaf name { 393 type string; 394 } 395 } 396 } 397 } 398 } 400 The YSDL meta-schema is as follows: 402 { 403 "ietf-ysdl:schemas": { 404 "top-schema": "device", 405 "schema": [ 406 { 407 "name": "device", 408 "yang-modules": [ 409 "example-device" 410 ], 411 "subschema": [ 412 { 413 "root": "example-device:device", 414 "schemas": [ 415 "if-ip", 416 "system" 417 ] 418 }, 419 { 420 "root": "example-device:device/logical-NEs/logical-NE", 421 "schemas": [ 422 "if-ip" 423 ] 424 } 425 ] 426 }, 427 { 428 "name": "if-ip", 429 "yang-modules": [ 430 "ietf-interfaces", 431 "ietf-ip" 432 ] 433 }, 434 { 435 "name": "system", 436 "yang-modules": [ 437 "ietf-system" 438 ] 439 } 440 ] 441 } 442 } 444 Apart prom the top-level schema, "device", the meta-schema defines 445 two other schemas: 447 o "if-ip" schema consists of "ietf-interfaces" and "ietf-ip" 448 modules; 450 o "system" schema consist of "ietf-system" module. 452 Two subschemas of the top-level schema defined with the following 453 root nodes: 455 o "example-device:device", 457 o "example-device:device/logical-NEs/logical-NE". 459 The former one uses both "if-ip" and "system" schemas whereas the 460 latter uses only "system". 462 The entire schema tree consisting of the top-level schema and the two 463 subschemas is shown schematically in the following tree diagram: 465 module: example-device 466 +--rw device 467 +--rw if:interfaces 468 | ... 469 +--ro if:interfaces-state 470 | ... 471 +--rw sys:system 472 | ... 473 +--rw sys:system-state 474 +--rw logical-NEs 475 +--rw logical-NE* [name] 476 +--rw name string 477 +--rw if:interfaces 478 | ... 479 +--ro if:interfaces-state 480 | ... 482 6. IANA Considerations 484 RFC Editor: In this section, replace all occurrences of 'XXXX' with 485 the actual RFC number and all occurrences of the revision date below 486 with the date of RFC publication (and remove this note). 488 This document registers a URI in the "IETF XML registry" [RFC3688]. 489 Following the format in RFC 3688, the following registration has been 490 made. 492 --------------------------------------------------------------------- 493 URI: urn:ietf:params:xml:ns:yang:ietf-ysdl 495 Registrant Contact: The NETMOD WG of the IETF. 497 XML: N/A, the requested URI is an XML namespace. 498 --------------------------------------------------------------------- 500 This document registers a YANG module in the "YANG Module Names" 501 registry [RFC6020]. 503 --------------------------------------------------------------------- 504 name: ietf-ysdl 505 namespace: urn:ietf:params:xml:ns:yang:ietf-ysdl 506 prefix: ysdl 507 reference: RFC XXXX 508 --------------------------------------------------------------------- 510 7. Security Considerations 512 TBD 514 8. Acknowledgements 516 YSDL was loosely inspired by Namespace-based Validation Dispatching 517 Language (NVDL) [ISO.19757-4]. 519 9. References 521 9.1. Normative References 523 [I-D.ietf-netconf-yang-library] 524 Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module 525 Library", draft-ietf-netconf-yang-library-02 (work in 526 progress), October 2015. 528 [I-D.ietf-netmod-rfc6020bis] 529 Bjorklund, M., "The YANG 1.1 Data Modeling Language", 530 draft-ietf-netmod-rfc6020bis-08 (work in progress), 531 October 2015. 533 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 534 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 535 RFC2119, March 1997, 536 . 538 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 539 DOI 10.17487/RFC3688, January 2004, 540 . 542 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 543 the Network Configuration Protocol (NETCONF)", RFC 6020, 544 DOI 10.17487/RFC6020, October 2010, 545 . 547 9.2. Informative References 549 [I-D.ietf-netconf-restconf] 550 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 551 Protocol", draft-ietf-netconf-restconf-08 (work in 552 progress), October 2015. 554 [I-D.ietf-netmod-yang-json] 555 Lhotka, L., "JSON Encoding of Data Modeled with YANG", 556 draft-ietf-netmod-yang-json-06 (work in progress), October 557 2015. 559 [I-D.rtgyangdt-rtgwg-device-model] 560 Lindem, A., Berger, L., Bogdanovic, D., and C. Hopps, 561 "Network Device YANG Organizational Model", draft- 562 rtgyangdt-rtgwg-device-model-01 (work in progress), 563 September 2015. 565 [ISO.19757-4] 566 International Organization for Standardization, "Document 567 Schema Definition Languages (DSDL) - Part 4: Namespace- 568 based Validation Dispatching Language (NVDL)", ISO/IEC 569 19757-4, June 2006. 571 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 572 and A. Bierman, Ed., "Network Configuration Protocol 573 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 574 . 576 Author's Address 578 Ladislav Lhotka 579 CZ.NIC 581 Email: lhotka@nic.cz