idnits 2.17.1 draft-lhotka-netconf-relaxng-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 2, 2009) is 5533 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4741 (ref. '1') (Obsoleted by RFC 6241) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETCONF L. Lhotka 3 Internet-Draft CESNET 4 Intended status: Informational March 2, 2009 5 Expires: September 3, 2009 7 Modular RELAX NG Schema of NETCONF RPC and Protocol Operations 8 draft-lhotka-netconf-relaxng-00 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on September 3, 2009. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. 45 Abstract 47 This memo presents a schema for NETCONF RPC and protocol operations 48 expressed in RELAX NG (compact syntax). The schema is modular and 49 cleanly separates the server and client part of the NETCONF 50 vocabulary and also the schema extensions provided by optional 51 capabilities. The modular structure improves readability but also 52 enables selecting certain modules and assembling them into a grammar 53 that can be used for validation of NETCONF protocol data units. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Problems of the NETCONF XSD Schema . . . . . . . . . . . . . . 5 59 3. Description of the RELAX NG Schemas . . . . . . . . . . . . . 6 60 4. Assembling the Modules into Validation Schemas . . . . . . . . 8 61 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 9 62 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 63 Appendix A. RELAX NG Schema Modules . . . . . . . . . . . . . . . 11 64 A.1. Common patterns . . . . . . . . . . . . . . . . . . . . . 11 65 A.2. Base Client Schema . . . . . . . . . . . . . . . . . . . . 12 66 A.3. Base Server Schema . . . . . . . . . . . . . . . . . . . . 14 67 A.4. Capability :writable-running . . . . . . . . . . . . . . . 20 68 A.5. Capability :candidate . . . . . . . . . . . . . . . . . . 20 69 A.6. Capability :confirmed-commit . . . . . . . . . . . . . . . 21 70 A.7. Capability :rollback-on-error . . . . . . . . . . . . . . 21 71 A.8. Capability :validate . . . . . . . . . . . . . . . . . . . 21 72 A.9. Capability :startup . . . . . . . . . . . . . . . . . . . 22 73 A.10. Capability :url . . . . . . . . . . . . . . . . . . . . . 22 74 A.11. Capability :xpath . . . . . . . . . . . . . . . . . . . . 23 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24 77 1. Introduction 79 Specification of the NETCONF protocol [1] contains in its Appendix B 80 a formal definition of the vocabulary of RPC and protocol operations 81 expressed using the W3C XML Schema language ([2], [3] - henceforth 82 referred to as "XSD"). 84 However, the NETCONF protocol vocabulary actually consists of two 85 distinct parts - one for the NETCONF client and the other for the 86 NETCONF server - that can never appear together in the same NETCONF 87 PDU. The overlap of these two parts is small and even if the same 88 element, such as , is allowed in both, the content model of 89 each version may differ. Moreover, the PDU contents in every 90 particular case depend on the capabilities supported by the server 91 and negotiated in the messages. The all-encompassing 92 approach of the NETCONF XSD schema cannot take these differences into 93 account and the grammar is thus in many places too liberal. As a 94 result, the XSD schema can hardly be used for serious validation of 95 NETCONF PDUs. 97 This report introduces a new modular schema for the same NETCONF 98 protocol vocabulary expressed in RELAX NG [4], a simple but powerful 99 schema language that became Part 2 of the international standard ISO/ 100 IEC 19757 [5]. RELAX NG has two official syntaxes, XML and compact, 101 the latter, being designed primarily for human readers without 102 special training, is considerably more suitable for inclusion in 103 standardization documents such as RFCs than XML-based syntaxes. 105 The goal of this work is twofold: 107 1. Demonstrate that RELAX NG is a sound alternative to XSD for the 108 given purpose in that it is able to express the same (or even 109 more detailed) grammar and data-typing rules as the existing 110 NETCONF XSD schema and do it in a way that is considerably more 111 human-readable. 113 2. Use the extensibility framework of RELAX NG for dividing the 114 schema into smaller modules according to the logic of the NETCONF 115 protocol. Such a decomposition will not only further aid 116 readability and make the parts of the schema easier to maintain, 117 but also allow for using the modules directly for NETCONF PDU 118 validation. 120 The report is organized as follows: In the Section 2 we summarize the 121 problems of the NETCONF XSD schema, Section 3 describes the structure 122 and main design features of the modular RELAX NG schema, Section 4 123 shows how to use the modules for effective validation of NETCONF PDUs 124 in specific contexts and finally Section 5 concludes the reports. 126 Appendix A contains full listing of the RELAX NG modules in the 127 compact syntax. 129 2. Problems of the NETCONF XSD Schema 131 The NETCONF XSD schema in Appendix B of [1] can serve well as a set 132 of formalized guidelines for implementers of the NETCONF protocol, 133 especially the RPC layer. However, this schema is much less useful 134 for the second major purpose of XML schemas, namely for validating 135 documents, in our case NETCONF PDUs. The reason for this deficiency 136 is that many of the constraints in the schema are rather lax or even 137 logically inconsistent. The latter problem is manifested, for 138 example, in the parameter of the element: the 139 schema declares it as optional (minOccurs="0") but, in fact, this 140 content model is appropriate neither for server's nor for client's 141 version of - it is mandatory in the former but not allowed at 142 all in the latter. 144 Similarly, the borderline case of a to an invalid 145 lacking the "message-id" parameter led the schema designers to 146 declaring this parameter as optional. As an unfortunate result, any 147 with "message-id" missing will be found valid. 149 Strict validation of NETCONF PDUs in a particular context must also 150 take into account the set of capabilities supported by the concrete 151 server. The XSD schema is not designed to allow such specialization. 153 Finally, Appendix A of [1] defines the standard NETCONF errors and 154 specifies constraints on their contents. For example, some 155 combinations or "error-tag" and "error-type" parameters are not 156 permitted, some errors have prescribed content of "error-info" while 157 others cannot have this parameter, and all these standard errors have 158 severity "error". Again, the XSD schema doesn't take these 159 constraints into account and allows all possible combinations of 160 error parameters. 162 3. Description of the RELAX NG Schemas 164 Modular RELAX NG schema is designed for much stricter validation of 165 NETCONF PDUs than the XSD schema. This is achieved by utilizing 166 auxiliary information that is typically available, such as the 167 originator of the PDU - server or client - and list of capabilities 168 supported by the server. 170 The RELAX NG schema is divided into 11 modules, each of them stored 171 in a separate file: 173 o nc-base-common (Appendix A.1) 175 o nc-base-client (Appendix A.2) 177 o nc-base-server (Appendix A.3) 179 o nc-writable-running-client (Appendix A.4) 181 o nc-candidate-client (Appendix A.5) 183 o nc-confirmed-commit-client (Appendix A.6) 185 o nc-rollback-on-error-client (Appendix A.7) 187 o nc-validate-client (Appendix A.8) 189 o nc-startup-client (Appendix A.9) 191 o nc-url-client (Appendix A.10) 193 o nc-xpath-client (Appendix A.11) 195 The file names are composed of the module name and the appropriate 196 extension - either ".rng" or ".rnc", depending on whether the file 197 contains RELAX NG in the XML or compact syntax. 199 The main division line in the schema goes between the client and 200 server part. Hence, modules "nc-base-client" and "nc-base-server" 201 contain the client and server vocabulary, respectively. However, 202 this is only the bare-bones NETCONF, without any optional 203 capabilities. Few parameters and RELAX NG patterns are common to 204 both the client and server schemas and these are contained in the 205 "nc-base-common" module. 207 Further, extensions to the schema provided by optional capabilities 208 are defined in separate modules. In general, there would be two 209 modules per capability - one with the server and the other with the 210 client extensions. However, all the standard extensions defined in 211 [1] only affect the client vocabulary, so the server module is not 212 needed. Nevertheless, other capabilities may extend or change the 213 server vocabulary, too, for example by introducing new error types. 215 The schema modules are designed for maximum extensibility. 216 Therefore, their RELAX NG patterns mainly use the "content-oriented" 217 style that allows new content to be easily added without redefining 218 entire patterns. Due to this design, the capability modules can be 219 generally very short and easy to understand. However, taking the 220 content-oriented design to the extreme would make the schemas 221 unwieldy, so we use it only in places where extensions are likely. 223 4. Assembling the Modules into Validation Schemas 225 Two of the RELAX NG modules - "nc-base-client" and "nc-base-server" - 226 are full-fledged grammars that can be readily used for validating 227 NETCONF PDUs generated by the client and server, respectively. So 228 the following PDU (taken from [1]) will successfully validate against 229 the "nc-base-client" schema: 230 232 233 234 235 236 237 239 However, if we replace the element in the "source" 240 parameter with , the validation fails since the optional 241 capabilities such as :startup are not supported by the "nc-base- 242 client" schema. We can allow as the value of the "source" 243 parameter simply by using the following schema: 245 include "nc-base-client.rnc" 246 include "nc-startup-client.rnc" 248 In the same way, we can include any combination of capabilities as 249 long as they are not mutually exclusive. 251 For the server PDUs the procedure is analogical but generally simpler 252 since none of the standard capabilities defined in [1] affects the 253 server schema, so the "nc-base-server" schema is sufficient for 254 validating server PDUs. 256 5. Conclusions 258 The set of RELAX NG schemas presented in this report provide a 259 modular grammar that can be used as a formal definition and 260 documentation of the NETCONF vocabulary, but also for validating 261 NETCONF PDUs. As a validation vehicle, though, these schemas are 262 considerably stricter than the W3C XML Schema from [1]. This is 263 mainly due to the fact that each of the RELAX NG schema modules deals 264 with a certain specific part of the vocabulary - client or server 265 side of a NETCONF channel, or individual capabilities. The modules 266 can be assembled in many different ways into validation schemas that 267 may be used for effective NETCONF PDU validation. 269 The fact that the modular RELAX NG schema is stricter and more 270 validation-oriented than its XSD counterpart doesn't mean that it is 271 less readable. On the contrary, separating the server and client 272 vocabularies and factoring out the optional capabilities resulted in 273 base server and client schemas that are simple and easy to 274 comprehend. Likewise, most capability schemas are almost trivial but 275 still show quite precisely where and how each capability extends the 276 vocabulary. 278 The simplicity and limited scope of the schema modules also enables 279 their inclusion in larger validation frameworks such as DSDL [5] 280 and/or combination with a NETCONF concrete data model expressed in 281 RELAX NG or a different data modelling language. 283 As a matter of fact, most improvements described in this report 284 could, and probably should, be applied to the NETCONF XSD schema in 285 [1], too. The only notable exception is the compact syntax, which is 286 special to RELAX NG. 288 6. References 290 [1] Enns, R., Ed., "NETCONF Configuration Protocol", RFC 4741, 291 December 2006. 293 [2] Thompson, H., Ed., Beech, D., Ed., Maloney, M., Ed., and N. 294 Mendelsohn, Ed., "XML Schema Part 1: Structures, Second 295 Edition", October 2004. 297 [3] Biron, P., Ed. and A. Malhotra, Ed., "XML Schema Part 2: 298 Datatypes, Second Edition", October 2004. 300 [4] ISO/IEC, "Document Schema Definition Languages (DSDL) - Part 2: 301 Regular Grammar-Based Validation - RELAX NG", ISO/IEC 19757-2, 302 December 2002. 304 [5] ISO/IEC, "Document Schema Definition Languages (DSDL) - Part 1: 305 Overview", ISO/IEC 19757-1, 11 2004. 307 Appendix A. RELAX NG Schema Modules 309 This appendix contains listings of the RELAX NG modules in the 310 compact syntax. The modules cover the NETCONF client and server 311 vocabularies including all optional capabilities described in RFC 312 4741 [1]. 314 A.1. Common patterns 316 This module defines several parameters patterns that are referenced 317 in both the client and server schemas. 318 BEGIN 320 # source file: nc-base-common.rng 322 default namespace = "urn:ietf:params:xml:ns:netconf:base:1.0" 323 namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0" 325 ## This pattern specifies the URI for the base NETCONF capability. 326 ## See RFC 4741, sec. 10.1. 327 base-capability-uri = "urn:ietf:params:netconf:base:1.0" 329 hello-element = element hello { hello-content } 331 ## Common part of the "hello" element. See RFC 4741, sec. 8.1. 332 hello-content = 333 element capabilities { 334 element capability { base-capability-uri } 335 & element capability { extra-capability-choice }* 336 } 338 ## URNs of additional known capabilities 339 extra-capability-choice = 340 "urn:ietf:params:netconf:capability:writable-running:1.0" 341 | "urn:ietf:params:netconf:capability:candidate:1.0" 342 | "urn:ietf:params:netconf:capability:confirmed-commit:1.0" 343 | "urn:ietf:params:netconf:capability:rollback-on-error:1.0" 344 | "urn:ietf:params:netconf:capability:validate:1.0" 345 | "urn:ietf:params:netconf:capability:startup:1.0" 346 | xsd:anyURI { 347 pattern = 348 "urn:ietf:params:netconf:capability:url:1\.0" ~ 349 "[?]scheme=(http|ftp|file)" 350 } 351 | "urn:ietf:params:netconf:capability:xpath:1.0" 353 ## Attribute "message-id" is mandatory in both "rpc" and "rpc-reply". 354 ## See RFC 4741, sec. 4.1. 356 message-id-attribute = 357 attribute message-id { 358 xsd:string { maxLength = "4095" } 359 } 361 ## The "session-id" parameter identifies a NETCONF session. 362 session-id-element = element session-id { xsd:positiveInteger } 364 ## This pattern allows arbitrary content. 365 arbitrary-content = 366 (element * { arbitrary-content } 367 | attribute * { text } 368 | text)* 370 ## This pattern allows arbitrary content wrapped in an element. 371 wrapped-arbitrary-content = element * { arbitrary-content } 373 END 375 A.2. Base Client Schema 377 This module specifies the NETCONF client vocabulary without any 378 optional capabilities. 379 BEGIN 381 # source file: nc-base-client.rng 383 default namespace = "urn:ietf:params:xml:ns:netconf:base:1.0" 384 namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0" 386 include "nc-base-common.rnc" 388 ## Client messages may have either "hello" or "rpc" as the document 389 ## element. "hello" is reused from netconf-common without change. 390 start = hello-element | rpc-element 392 ## This element is a wrapper for all RPC requests. 393 ## See RFC 4741, Sec. 4.1. 394 rpc-element = 395 element rpc { 396 message-id-attribute, 397 attribute * { text }*, 398 rpc-operation-choice 399 } 401 ## Selection of RPC operations. See RFC 4741, Sec. 7. 402 ## Capabilities may extend this pattern. 403 rpc-operation-choice = 404 element get-config { get-config-content } 405 | element edit-config { edit-config-content } 406 | element copy-config { copy-config-content } 407 | element delete-config { delete-config-content } 408 | element lock { lock-content } 409 | element unlock { unlock-content } 410 | element get { get-content } 411 | element close-session { close-session-content } 412 | element kill-session { kill-session-content } 414 ## See RFC 4741, Sec. 7.1. 415 get-config-content = 416 element source { source-choice } 417 & element filter { filter-content-choice }? 419 ## This element represents the "running" datastore. 420 running-element = element running { empty } 422 ## Available repositories. Capabilities may extend this pattern. 423 source-choice = running-element | extra-datastore-choice 425 ## No additional datastores are present in base NETCONF. 426 ## Capabilities may extend this pattern. See RFC 4741, Sec. 5.1. 427 extra-datastore-choice = empty 429 ## Base NETCONF only supports subtree filters. 430 ## Capabilities may extend this pattern. 431 filter-content-choice = 432 attribute type { "subtree" }?, 433 subtree-filter-content 435 ## Content of a subtree filter depends on the data model so 436 ## we have to allow everything here. 437 subtree-filter-content = wrapped-arbitrary-content 439 ## See RFC 4741, Sec. 7.2. 440 edit-config-content = 441 element target { target-choice } 442 & element default-operation { default-operation-choice }? 443 & element error-option { error-option-choice }? 444 & config-data-spec 446 ## The "operation" attribute may be used inside the "config" parameter 447 ## of edit-config. This pattern may be combined with particular data 448 ## models into a schema validating entire "edit-config" PDUs. 449 edit-config-operation-attribute = 450 attribute operation { "merge" | "replace" | "create" | "delete" } 452 ## Writable repositories (in base NETCONF there are none). 453 ## Capabilities may extend this pattern. 454 target-choice = extra-datastore-choice 456 ## Possible values for "default-operation" parameter in "edit-config". 457 ## Default is "merge". 458 default-operation-choice = "merge" | "replace" | "none" 460 ## Possible values for "error-option" parameter in "edit-config". 461 ## Default is "stop-on-error". 462 error-option-choice = "stop-on-error" | "ignore-error" 464 ## This pattern gives possible options for specifying configuration 465 ## data. In base NETCONF, only inline tree is allowed. 466 ## Capabilities may extend this pattern. 467 config-data-spec = element config { wrapped-arbitrary-content } 469 ## See RFC 4741, Sec. 7.3. 470 copy-config-content = 471 element source { source-choice } 472 & element target { target-choice } 474 ## See RFC 4741, Sec. 7.4. 475 delete-config-content = element target { extra-datastore-choice } 477 ## See RFC 4741, Sec. 7.5. 478 lock-content = element target { target-choice } 480 ## See RFC 4741, Sec. 7.6. 481 unlock-content = element target { target-choice } 483 ## See RFC 4741, Sec. 7.7. 484 get-content = element filter { filter-content-choice }? 486 ## See RFC 4741, Sec. 7.8. 487 close-session-content = empty 489 ## See RFC 4741, Sec. 7.9. 490 kill-session-content = session-id-element 492 END 494 A.3. Base Server Schema 496 This module specifies the NETCONF server vocabulary without any 497 optional capabilities. 498 BEGIN 499 # source file: nc-base-server.rng 501 default namespace = "urn:ietf:params:xml:ns:netconf:base:1.0" 502 namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0" 504 include "nc-base-common.rnc" 506 ## Server messages may have either "hello" or "rpc-reply" as 507 ## the document element. 508 start = hello-element | rpc-reply-element 510 ## Server's "hello" message must include "session-id". 511 ## See RFC 4741, Sec. 8.1. 512 hello-content &= session-id-element 514 ## This element is a wrapper for all RPC replies. 515 ## See RFC 4741, Sec. 4.2. 516 rpc-reply-element = 517 element rpc-reply { 518 attribute * { text }*, 519 ((# Positive response 520 message-id-attribute, 521 element rpc-reply { rpc-reply-choice }) 522 | (# error reply to a rpc without message-id is special 523 missing-message-id-error 524 | (# Negative response 525 message-id-attribute, 526 element rpc-error { rpc-error-choice }+))) 527 } 529 ## Specific error reply to an "rpc" without message-id. 530 ## Only in this case can "message-id" be missing in an "rpc-reply". 531 missing-message-id-error = 532 element rpc-error { 533 element error-tag { "missing-attribute" } 534 & element error-type { "rpc" } 535 & element error-severity { "error" } 536 & element error-info { 537 element bad-attribute { "message-id" } 538 & element bad-element { "rpc" } 539 } 540 & optional-error-content 541 } 543 ## Possible RPC replies. See RFC 4741, Sec. 4.2. 544 ## Capabilities may extend this pattern. 545 rpc-reply-choice = ok-element | data-element 546 ## See RFC 4741, Sec. 4.4. 547 ok-element = element ok { empty } 549 ## Content depends on data model. Here we have to allow everything. 550 data-element = element data { wrapped-arbitrary-content } 552 ## These errors are defined in RFC 4741, Appendix A. 553 rpc-error-choice = 554 in-use-error-content 555 | too-big-error-content 556 | missing-attribute-error-content 557 | bad-attribute-error-content 558 | bad-attribute-error-content 559 | unknown-attribute-error-content 560 | missing-element-error-content 561 | bad-element-error-content 562 | unknown-element-error-content 563 | unknown-namespace-error-content 564 | access-denied-error-content 565 | lock-denied-error-content 566 | resource-denied-error-content 567 | rollback-failed-error-content 568 | data-exists-error-content 569 | data-missing-error-content 570 | operation-not-supported-error-content 571 | operation-failed-error-content 572 | partial-operation-error-content 573 error-types-pa = "protocol" | "application" 574 error-types-rpa = error-types-pa | "rpc" 575 error-types-all = error-types-rpa | "transport" 576 optional-error-content = 577 element error-app-tag { xsd:string }? 578 & element error-path { xsd:string }? 579 & element error-message { 580 attribute xml:lang { xsd:token }?, 581 xsd:string 582 }? 583 element-error-info = element bad-element { xsd:QName } 584 attribute-error-info = 585 element bad-attribute { xsd:QName } 586 & element-error-info 588 ## Resource in use 589 in-use-error-content = 590 element error-tag { "in-use" } 591 & element error-type { error-types-pa } 592 & element error-severity { "error" } 593 & optional-error-content 595 ## Response would be too large for the implementation 596 too-big-error-content = 597 element error-tag { "too-big" } 598 & element error-type { error-types-all } 599 & element error-severity { "error" } 600 & optional-error-content 602 ## A required attribute is missing 603 missing-attribute-error-content = 604 element error-tag { "missing-attribute" } 605 & element error-type { error-types-rpa } 606 & element error-severity { "error" } 607 & element error-info { attribute-error-info } 608 & optional-error-content 610 ## Incorrect attribute value 611 bad-attribute-error-content = 612 element error-tag { "bad-attribute" } 613 & element error-type { error-types-rpa } 614 & element error-severity { "error" } 615 & element error-info { attribute-error-info } 616 & optional-error-content 618 ## An unexpected attribute is present 619 unknown-attribute-error-content = 620 element error-tag { "unknown-attribute" } 621 & element error-type { error-types-rpa } 622 & element error-severity { "error" } 623 & element error-info { attribute-error-info } 624 & optional-error-content 626 ## A required element is missing 627 missing-element-error-content = 628 element error-tag { "missing-element" } 629 & element error-type { error-types-rpa } 630 & element error-severity { "error" } 631 & element error-info { element-error-info } 632 & optional-error-content 634 ## Incorrect element value 635 bad-element-error-content = 636 element error-tag { "bad-element" } 637 & element error-type { error-types-rpa } 638 & element error-severity { "error" } 639 & element error-info { element-error-info } 640 & optional-error-content 642 ## An unexpected element is present 643 unknown-element-error-content = 644 element error-tag { "unknown-element" } 645 & element error-type { error-types-rpa } 646 & element error-severity { "error" } 647 & element error-info { element-error-info } 648 & optional-error-content 650 ## An unknown namespace is used 651 unknown-namespace-error-content = 652 element error-tag { "unknown-element" } 653 & element error-type { error-types-rpa } 654 & element error-severity { "error" } 655 & element error-info { 656 element-error-info 657 & element bad-namespace { xsd:Name } 658 } 659 & optional-error-content 661 ## Access denied due to authorization failure 662 access-denied-error-content = 663 element error-tag { "access-denied" } 664 & element error-type { error-types-rpa } 665 & element error-severity { "error" } 666 & optional-error-content 668 ## Access to the requested lock is denied 669 lock-denied-error-content = 670 element error-tag { "lock-denied" } 671 & element error-type { "protocol" } 672 & element error-severity { "error" } 673 & element error-info { 674 element session-id { xsd:nonNegativeInteger } 675 } 676 & optional-error-content 678 ## Insufficient resources 679 resource-denied-error-content = 680 element error-tag { "resource-denied" } 681 & element error-type { error-types-all } 682 & element error-severity { "error" } 683 & optional-error-content 685 ## Rollback not completed. 686 ## Requires either :rollback-on-error or :candidate capability. 687 rollback-failed-error-content = 688 element error-tag { "rollback-failed" } 689 & element error-type { error-types-pa } 690 & element error-severity { "error" } 691 & optional-error-content 693 ## Relevant data already exists 694 data-exists-error-content = 695 element error-tag { "data-exists" } 696 & element error-type { "application" } 697 & element error-severity { "error" } 698 & optional-error-content 700 ## Relevant data missing 701 data-missing-error-content = 702 element error-tag { "data-missing" } 703 & element error-type { "application" } 704 & element error-severity { "error" } 705 & optional-error-content 707 ## Operation not supported by the implementation 708 operation-not-supported-error-content = 709 element error-tag { "operation-not-supported" } 710 & element error-type { error-types-rpa } 711 & element error-severity { "error" } 712 & optional-error-content 714 ## Requested operation failed for some reason 715 operation-failed-error-content = 716 element error-tag { "operation-failed" } 717 & element error-type { error-types-rpa } 718 & element error-severity { "error" } 719 & optional-error-content 721 ## Part of the operation failed or was not attempted 722 partial-operation-error-content = 723 element error-tag { "partial-operation" } 724 & element error-type { "application" } 725 & element error-severity { "error" } 726 & element error-info { 727 element ok-element { xsd:QName }* 728 & element err-element { xsd:QName }* 729 & element noop-element { xsd:QName }* 730 } 731 & optional-error-content 733 END 735 A.4. Capability :writable-running 737 This module specifies the extensions to the client schema provided by 738 the :writable-running capability. The server schema is unchanged. 739 See RFC 4741 [1], Sec. 8.2. 740 BEGIN 742 # source file: nc-writable-running-client.rng 744 default namespace = "urn:ietf:params:xml:ns:netconf:base:1.0" 745 namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0" 747 ## This adds "running" as an option for the "target" parameter 748 ## of NETCONF operations. 749 target-choice |= running-element 751 END 753 A.5. Capability :candidate 755 This module specifies the extensions to the client schema provided by 756 the :candidate capability. The server schema is unchanged. See RFC 757 4741 [1], Sec. 8.3. 758 BEGIN 760 # source file: nc-candidate-client.rng 762 default namespace = "urn:ietf:params:xml:ns:netconf:base:1.0" 763 namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0" 765 ## This adds "candidate" as an option for both "source" and "target" 766 ## parameter of NETCONF operations. 767 extra-datastore-choice |= element candidate { empty } 769 ## Two new RPC operations are added. 770 rpc-operation-choice |= 771 element commit { commit-content } 772 | element discard-changes { discard-changes-content } 774 ## See RFC 4741, Sec. 8.3.4.1. 775 commit-content = empty 777 ## See RFC 4741, Sec. 8.3.4.2. 778 discard-changes-content = empty 780 END 782 A.6. Capability :confirmed-commit 784 This module specifies the extensions to the client schema provided by 785 the :confirmed-commit capability. The server schema is unchanged. 786 See RFC 4741 [1], Sec. 8.4. 787 BEGIN 789 # source file: nc-confirmed-commit-client.rng 791 default namespace = "urn:ietf:params:xml:ns:netconf:base:1.0" 792 namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0" 794 ## The "confirm-timeout" parameter is given in seconds. 795 ## The default is 600. See RFC 4741, Sec. 8.4.5.1. 796 commit-content &= 797 (element confirmed { empty } 798 & element confirm-timeout { xsd:positiveInteger }?)? 800 END 802 A.7. Capability :rollback-on-error 804 This module specifies the extensions to the client schema provided by 805 the :rollback-on-error capability. The server schema is unchanged. 806 See RFC 4741 [1], Sec. 8.5. 807 BEGIN 809 # source file: nc-rollback-on-error-client.rng 811 default namespace = "urn:ietf:params:xml:ns:netconf:base:1.0" 812 namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0" 814 error-option-choice |= "rollback-on-error" 816 END 818 A.8. Capability :validate 820 This module specifies the extensions to the client schema provided by 821 the :validate capability. The server schema is unchanged. See RFC 822 4741 [1], Sec. 8.6. 824 BEGIN 826 # source file: nc-validate-client.rng 828 default namespace = "urn:ietf:params:xml:ns:netconf:base:1.0" 829 namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0" 831 rpc-operation-choice |= element validate { validate-content } 833 ## See RFC 4741, Sec. 8.6.4.1. 834 validate-content = element source { source-choice | config-data-spec } 836 END 838 A.9. Capability :startup 840 This module specifies the extensions to the client schema provided by 841 the :startup capability. The server schema is unchanged. See RFC 842 4741 [1], Sec. 8.7. 843 BEGIN 845 # source file: nc-startup-client.rng 847 default namespace = "urn:ietf:params:xml:ns:netconf:base:1.0" 848 namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0" 850 ## This adds "startup" as an option for both "source" and "target" 851 ## parameter of NETCONF operations. 852 extra-datastore-choice |= element startup { empty } 854 END 856 A.10. Capability :url 858 This module specifies the extensions to the client schema provided by 859 the :url capability. The server schema is unchanged. See RFC 4741 860 [1], Sec. 8.8. 861 BEGIN 863 # source file: nc-url-client.rng 865 default namespace = "urn:ietf:params:xml:ns:netconf:base:1.0" 866 namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0" 868 source-choice |= element url { xsd:anyURI } 869 target-choice |= element url { xsd:anyURI } 871 END 873 A.11. Capability :xpath 875 This module specifies the extensions to the client schema provided by 876 the :xpath capability. The server schema is unchanged. See RFC 4741 877 [1], Sec. 8.9. 878 BEGIN 880 # source file: nc-xpath-client.rng 882 default namespace = "urn:ietf:params:xml:ns:netconf:base:1.0" 883 namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0" 885 filter-content-choice |= 886 attribute type { "xpath" }, 887 attribute select { xsd:string } 889 END 891 Author's Address 893 Ladislav Lhotka 894 CESNET 895 Zikova 4 896 Praha 6 160 00 897 CZ 899 Email: lhotka@cesnet.cz