One document matched: draft-lhotka-netconf-relaxng-00.xml

<?xml version="1.0"?>

<?rfc toc="yes"?>
<?rfc symrefs="no" ?>
<?rfc sortrefs="yes"?>

<rfc ipr="trust200811" category="info"
     docName="draft-lhotka-netconf-relaxng-00">

<front>
  <title abbrev="NETCONF Data Types">Modular RELAX NG Schema of
  NETCONF RPC and Protocol Operations</title>
  <author initials="L.L." surname="Lhotka" fullname="Ladislav Lhotka">
    <organization>CESNET</organization>
    <address>
      <postal>
	<street>Zikova 4</street>
	<city>Praha 6</city>
	<code>160 00</code>
	<country>CZ</country>
      </postal>
      <email>lhotka@cesnet.cz</email>
    </address>
  </author>
  <date day="2" month="March" year="2009"/>
  <area>Operations and Management</area>
  <workgroup>NETCONF</workgroup>
  <keyword>NETCONF</keyword>
  <keyword>RELAX NG</keyword>
  <keyword>XML schema</keyword>
  <abstract>
    <t>This memo presents a schema for NETCONF RPC and protocol
    operations expressed in RELAX NG (compact syntax). The schema is
    modular and cleanly separates the server and client part of the
    NETCONF vocabulary and also the schema extensions provided by
    optional capabilities. The modular structure improves readability
    but also enables selecting certain modules and assembling them into
    a grammar that can be used for validation of NETCONF protocol data
    units.</t>
  </abstract>
</front>

<middle>
  <section anchor="sec-intro" title="Introduction">
    <t>Specification of the NETCONF protocol <xref target="RFC4741"/>
    contains in its Appendix B a formal definition of the vocabulary
    of RPC and protocol operations expressed using the W3C XML Schema
    language (<xref target="XSD1"/>, <xref target="XSD2"/> -
    henceforth referred to as "XSD").</t>

    <t>However, the NETCONF protocol vocabulary actually consists of
    two distinct parts - one for the NETCONF client and the other for
    the NETCONF server - that can never appear together in the same
    NETCONF PDU. The overlap of these two parts is small and even if
    the same element, such as <hello>, is allowed in both, the
    content model of each version may differ. Moreover, the PDU
    contents in every particular case depend on the capabilities
    supported by the server and negotiated in the <hello>
    messages. The all-encompassing approach of the NETCONF XSD schema
    cannot take these differences into account and the grammar is thus
    in many places too liberal. As a result, the XSD schema can hardly
    be used for serious validation of NETCONF PDUs.</t>
    <t>This report introduces a new modular schema for the same
    NETCONF protocol vocabulary expressed in RELAX NG <xref
    target="RNG"/>, a simple but powerful schema language that became
    Part 2 of the international standard ISO/IEC 19757 <xref
    target="DSDL"/>. RELAX NG has two official syntaxes, XML and
    compact, the latter, being designed primarily for human readers
    without special training, is considerably more suitable for
    inclusion in standardization documents such as RFCs than XML-based
    syntaxes.</t>
    <t>The goal of this work is twofold:
    <list style="numbers">
      <t>Demonstrate that RELAX NG is a sound alternative to XSD for
      the given purpose in that it is able to express the same (or
      even more detailed) grammar and data-typing rules as the
      existing NETCONF XSD schema and do it in a way that is
      considerably more human-readable.</t>
      <t>Use the extensibility framework of RELAX NG for dividing the
      schema into smaller modules according to the logic of the
      NETCONF protocol. Such a decomposition will not only further aid
      readability and make the parts of the schema easier to maintain,
      but also allow for using the modules directly for NETCONF PDU
      validation.</t>
    </list></t>
    <t>The report is organized as follows: In the <xref
    target="sec-xsd"/> we summarize the problems of the NETCONF XSD
    schema, <xref target="sec-desc"/> describes the structure and main
    design features of the modular RELAX NG schema, <xref
    target="sec-use"/> shows how to use the modules for effective
    validation of NETCONF PDUs in specific contexts and finally <xref
    target="sec-conc"/> concludes the reports. <xref
    target="app-schema"/> contains full listing of the RELAX NG
    modules in the compact syntax.</t>
  </section>

  <section anchor="sec-xsd" title="Problems of the NETCONF XSD Schema">
    
    <t>The NETCONF XSD schema in Appendix B of <xref
    target="RFC4741"/> can serve well as a set of formalized
    guidelines for implementers of the NETCONF protocol, especially
    the RPC layer. However, this schema is much less useful for the
    second major purpose of XML schemas, namely for validating
    documents, in our case NETCONF PDUs. The reason for this
    deficiency is that many of the constraints in the schema are
    rather lax or even logically inconsistent. The latter problem is
    manifested, for example, in the <session-id> parameter of
    the <hello> element: the schema declares it as optional
    (minOccurs="0") but, in fact, this content model is appropriate
    neither for server's nor for client's version of <hello> -
    it is mandatory in the former but not allowed at all in the
    latter.</t>
    <t>Similarly, the borderline case of a <rpc-reply> to an
    invalid <rpc> lacking the "message-id" parameter led the
    schema designers to declaring this parameter as optional. As an
    unfortunate result, any <rpc-reply> with "message-id"
    missing will be found valid.</t>
    <t>Strict validation of NETCONF PDUs in a particular context must
    also take into account the set of capabilities supported by the
    concrete server. The XSD schema is not designed to allow such
    specialization.</t>
    <t>Finally, Appendix A of <xref target="RFC4741"/> defines the
    standard NETCONF errors and specifies constraints on their
    contents. For example, some combinations or "error-tag" and
    "error-type" parameters are not permitted, some errors have
    prescribed content of "error-info" while others cannot have this
    parameter, and all these standard errors have severity
    "error". Again, the XSD schema doesn't take these constraints into
    account and allows all possible combinations of error
    parameters.</t>
  </section>

  <section anchor="sec-desc" title="Description of the RELAX NG Schemas">
    <t>Modular RELAX NG schema is designed for much stricter
    validation of NETCONF PDUs than the XSD schema. This is achieved by
    utilizing auxiliary information that is typically available, such
    as the originator of the PDU - server or client - and list of
    capabilities supported by the server.</t>

    <t>The RELAX NG schema is divided into 11 modules, each of them
    stored in a separate file:
    <list style="symbols">
      <t><xref target="base-common">nc-base-common</xref></t>
      <t><xref target="base-client">nc-base-client</xref></t>
      <t><xref target="base-server">nc-base-server</xref></t>
      <t><xref target="writable-running">nc-writable-running-client</xref></t>
      <t><xref target="candidate">nc-candidate-client</xref></t>
      <t><xref target="confirmed-commit">nc-confirmed-commit-client</xref></t>
      <t><xref target="rollback-on-error">nc-rollback-on-error-client</xref></t>
      <t><xref target="validate">nc-validate-client</xref></t>
      <t><xref target="startup">nc-startup-client</xref></t>
      <t><xref target="url">nc-url-client</xref></t>
      <t><xref target="xpath">nc-xpath-client</xref></t>
    </list></t>
    <t>The file names are composed of the module name and the
    appropriate extension - either ".rng" or ".rnc", depending on
    whether the file contains RELAX NG in the XML or compact syntax.</t>
    <t>The main division line in the schema goes between the client
    and server part. Hence, modules "nc-base-client" and
    "nc-base-server" contain the client and server vocabulary,
    respectively. However, this is only the bare-bones NETCONF,
    without any optional capabilities. Few parameters and RELAX NG
    patterns are common to both the client and server schemas and
    these are contained in the "nc-base-common" module.</t>
    <t>Further, extensions to the schema provided by optional
    capabilities are defined in separate modules. In general, there
    would be two modules per capability - one with the server and the
    other with the client extensions. However, all the standard
    extensions defined in <xref target="RFC4741"/> only affect the
    client vocabulary, so the server module is not
    needed. Nevertheless, other capabilities may extend or change the
    server vocabulary, too, for example by introducing new error
    types.</t>
    <t>The schema modules are designed for maximum
    extensibility. Therefore, their RELAX NG patterns mainly use the
    "content-oriented" style that allows new content to be easily
    added without redefining entire patterns. Due to this design, the
    capability modules can be generally very short and easy to
    understand. However, taking the content-oriented design to the
    extreme would make the schemas unwieldy, so we use it only in
    places where extensions are likely.</t>
  </section>

  <section anchor="sec-use"
	   title="Assembling the Modules into Validation Schemas">
    <t>Two of the RELAX NG modules - "nc-base-client" and
    "nc-base-server" - are full-fledged grammars that can be readily
    used for validating NETCONF PDUs generated by the client and
    server, respectively. So the following PDU (taken from <xref
    target="RFC4741"/>) will successfully validate against the
    "nc-base-client" schema:</t>

    <figure>
      <artwork><![CDATA[<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
     message-id="101">
  <get-config>
    <source>
      <running/>
    </source>
  </get-config>
</rpc>]]>
      </artwork>
    </figure>

    <t>However, if we replace the <running/> element in the
    "source" parameter with <startup/>, the validation fails
    since the optional capabilities such as :startup are not supported
    by the "nc-base-client" schema. We can allow <startup/> as
    the value of the "source" parameter simply by using the following
    schema:</t>

    <figure>
      <artwork>
include "nc-base-client.rnc"
include "nc-startup-client.rnc"
      </artwork>
    </figure>

    <t>In the same way, we can include any combination of capabilities
    as long as they are not mutually exclusive.</t>

    <t>For the server PDUs the procedure is analogical but generally
    simpler since none of the standard capabilities defined in <xref
    target="RFC4741"/> affects the server schema, so the
    "nc-base-server" schema is sufficient for validating server
    PDUs.</t>
  </section>

  <section anchor="sec-conc" title="Conclusions">
    <t>The set of RELAX NG schemas presented in this report provide a
    modular grammar that can be used as a formal definition and
    documentation of the NETCONF vocabulary, but also for validating
    NETCONF PDUs. As a validation vehicle, though, these schemas are
    considerably stricter than the W3C XML Schema from <xref
    target="RFC4741"/>. This is mainly due to the fact that each of
    the RELAX NG schema modules deals with a certain specific part of
    the vocabulary - client or server side of a NETCONF channel, or
    individual capabilities. The modules can be assembled in many
    different ways into validation schemas that may be used for
    effective NETCONF PDU validation.</t>
    <t>The fact that the modular RELAX NG schema is stricter and more
    validation-oriented than its XSD counterpart doesn't mean that it
    is less readable. On the contrary, separating the server and
    client vocabularies and factoring out the optional capabilities
    resulted in base server and client schemas that are simple and
    easy to comprehend. Likewise, most capability schemas are almost
    trivial but still show quite precisely where and how each
    capability extends the vocabulary.</t>
    <t>The simplicity and limited scope of the schema modules also
    enables their inclusion in larger validation frameworks such as
    DSDL <xref target="DSDL"/> and/or combination with a NETCONF
    concrete data model expressed in RELAX NG or a different data
    modelling language.</t>
    <t>As a matter of fact, most improvements described in this report
    could, and probably should, be applied to the NETCONF XSD schema
    in <xref target="RFC4741"/>, too. The only notable exception is
    the compact syntax, which is special to RELAX NG.</t>
  </section>

</middle>

<back>
  <references>
    <reference anchor="RFC4741">
      <front>
        <title>NETCONF Configuration Protocol</title>
        <author initials="R." surname="Enns"
                fullname="Rob Enns" role="editor">
          <organization>Juniper Networks</organization>
        </author>
        <date month="December" year="2006"/>
      </front>
      <seriesInfo name="RFC" value="4741"/>
    </reference>

    <reference anchor="XSD1">
      <front>
        <title>XML Schema Part 1: Structures, Second Edition</title>
        <author initials="H.S." surname="Thompson"
                fullname="Henry S. Thompson" role="editor">
	  <organization>University of Edinburgh</organization>
        </author>
        <author initials="D." surname="Beech"
                fullname="David Beech" role="editor">
	  <organization>Oracle Corporation</organization>
        </author>
        <author initials="M." surname="Maloney"
                fullname="Murray Maloney" role="editor">
	  <organization>Commerce One</organization>
        </author>
        <author initials="N." surname="Mendelsohn"
                fullname="Noah Mendelsohn" role="editor">
	  <organization>Lotus Development Corporation</organization>
        </author>
        <date day="28" month="October" year="2004"/>
      </front>
    </reference>

    <reference anchor="XSD2">
      <front>
        <title>XML Schema Part 2: Datatypes, Second Edition</title>
        <author initials="P.V." surname="Biron"
                fullname="Paul V. Biron" role="editor">
	  <organization>Kaiser Permanente</organization>
        </author>
        <author initials="A." surname="Malhotra"
                fullname="Ashok Malhotra" role="editor">
	  <organization>Microsoft</organization>
        </author>
        <date day="28" month="October" year="2004"/>
      </front>
    </reference>

    <reference anchor="DSDL">
      <front>
        <title>Document Schema Definition Languages (DSDL) - Part 1:
        Overview</title>
        <author fullname="ISO/IEC">
          <organization>ISO/IEC</organization>
        </author>
        <date day="14" month="11" year="2004"/>
      </front>
      <seriesInfo name="ISO/IEC" value="19757-1"/>
    </reference>

    <reference anchor="RNG">
      <front>
        <title>Document Schema Definition Languages (DSDL) - Part 2:
	Regular Grammar-Based Validation - RELAX NG</title>
        <author fullname="ISO/IEC">
	  <organization>ISO/IEC</organization>
        </author>
        <date day="12" month="December" year="2002"/>
      </front>
      <seriesInfo name="ISO/IEC" value="19757-2"/>
    </reference>

  </references>

  <section anchor="app-schema" title="RELAX NG Schema Modules">
    <t>This appendix contains listings of the RELAX NG modules in the
    compact syntax. The modules cover the NETCONF client and server
    vocabularies including all optional capabilities described in RFC
    4741 <xref target="RFC4741"/>.</t>

    <section anchor="base-common" title="Common patterns">
      <t>This module defines several parameters patterns that are
      referenced in both the client and server schemas.</t>

      <figure>
	<artwork><![CDATA[BEGIN

# source file: nc-base-common.rng

default namespace = "urn:ietf:params:xml:ns:netconf:base:1.0"
namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0"

## This pattern specifies the URI for the base NETCONF capability.
## See RFC 4741, sec. 10.1.
base-capability-uri = "urn:ietf:params:netconf:base:1.0"

hello-element = element hello { hello-content }

## Common part of the "hello" element. See RFC 4741, sec. 8.1.
hello-content =
  element capabilities {
    element capability { base-capability-uri }
    & element capability { extra-capability-choice }*
  }

## URNs of additional known capabilities
extra-capability-choice =
  "urn:ietf:params:netconf:capability:writable-running:1.0"
  | "urn:ietf:params:netconf:capability:candidate:1.0"
  | "urn:ietf:params:netconf:capability:confirmed-commit:1.0"
  | "urn:ietf:params:netconf:capability:rollback-on-error:1.0"
  | "urn:ietf:params:netconf:capability:validate:1.0"
  | "urn:ietf:params:netconf:capability:startup:1.0"
  | xsd:anyURI {
      pattern =
        "urn:ietf:params:netconf:capability:url:1\.0" ~
        "[?]scheme=(http|ftp|file)"
    }
  | "urn:ietf:params:netconf:capability:xpath:1.0"

## Attribute "message-id" is mandatory in both "rpc" and "rpc-reply".
## See RFC 4741, sec. 4.1.
message-id-attribute =
  attribute message-id {
    xsd:string { maxLength = "4095" }
  }

## The "session-id" parameter identifies a NETCONF session.
session-id-element = element session-id { xsd:positiveInteger }

## This pattern allows arbitrary content.
arbitrary-content =
  (element * { arbitrary-content }
   | attribute * { text }
   | text)*

## This pattern allows arbitrary content wrapped in an element.
wrapped-arbitrary-content = element * { arbitrary-content }

END]]>
	</artwork>
      </figure>

    </section>

    <section anchor="base-client" title="Base Client Schema">
      <t>This module specifies the NETCONF client vocabulary without
      any optional capabilities.</t>

      <figure>
	<artwork><![CDATA[BEGIN

# source file: nc-base-client.rng

default namespace = "urn:ietf:params:xml:ns:netconf:base:1.0"
namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0"

include "nc-base-common.rnc"

## Client messages may have either "hello" or "rpc" as the document
## element. "hello" is reused from netconf-common without change.
start = hello-element | rpc-element

## This element is a wrapper for all RPC requests.
## See RFC 4741, Sec. 4.1.
rpc-element =
  element rpc {
    message-id-attribute,
    attribute * { text }*,
    rpc-operation-choice
  }

## Selection of RPC operations. See RFC 4741, Sec. 7.
## Capabilities may extend this pattern.
rpc-operation-choice =
  element get-config { get-config-content }
  | element edit-config { edit-config-content }
  | element copy-config { copy-config-content }
  | element delete-config { delete-config-content }
  | element lock { lock-content }
  | element unlock { unlock-content }
  | element get { get-content }
  | element close-session { close-session-content }
  | element kill-session { kill-session-content }

## See RFC 4741, Sec. 7.1.
get-config-content =
  element source { source-choice }
  & element filter { filter-content-choice }?

## This element represents the "running" datastore.
running-element = element running { empty }

## Available repositories. Capabilities may extend this pattern.
source-choice = running-element | extra-datastore-choice

## No additional datastores are present in base NETCONF.
## Capabilities may extend this pattern. See RFC 4741, Sec. 5.1.
extra-datastore-choice = empty

## Base NETCONF only supports subtree filters.
## Capabilities may extend this pattern.
filter-content-choice =
  attribute type { "subtree" }?,
  subtree-filter-content

## Content of a subtree filter depends on the data model so
## we have to allow everything here.
subtree-filter-content = wrapped-arbitrary-content

## See RFC 4741, Sec. 7.2.
edit-config-content =
  element target { target-choice }
  & element default-operation { default-operation-choice }?
  & element error-option { error-option-choice }?
  & config-data-spec

## The "operation" attribute may be used inside the "config" parameter
## of edit-config. This pattern may be combined with particular data
## models into a schema validating entire "edit-config" PDUs.
edit-config-operation-attribute =
  attribute operation { "merge" | "replace" | "create" | "delete" }

## Writable repositories (in base NETCONF there are none). 
## Capabilities may extend this pattern.
target-choice = extra-datastore-choice

## Possible values for "default-operation" parameter in "edit-config".
## Default is "merge".
default-operation-choice = "merge" | "replace" | "none"

## Possible values for "error-option" parameter in "edit-config".
## Default is "stop-on-error".
error-option-choice = "stop-on-error" | "ignore-error"

## This pattern gives possible options for specifying configuration
## data. In base NETCONF, only inline tree is allowed.
## Capabilities may extend this pattern.
config-data-spec = element config { wrapped-arbitrary-content }

## See RFC 4741, Sec. 7.3.
copy-config-content =
  element source { source-choice }
  & element target { target-choice }

## See RFC 4741, Sec. 7.4.
delete-config-content = element target { extra-datastore-choice }

## See RFC 4741, Sec. 7.5.
lock-content = element target { target-choice }

## See RFC 4741, Sec. 7.6.
unlock-content = element target { target-choice }

## See RFC 4741, Sec. 7.7.
get-content = element filter { filter-content-choice }?

## See RFC 4741, Sec. 7.8.
close-session-content = empty

## See RFC 4741, Sec. 7.9.
kill-session-content = session-id-element

END]]>
      </artwork>
    </figure>

    </section>

    <section anchor="base-server" title="Base Server Schema">
      <t>This module specifies the NETCONF server vocabulary without
      any optional capabilities.</t>

      <figure>
	<artwork><![CDATA[BEGIN

# source file: nc-base-server.rng

default namespace = "urn:ietf:params:xml:ns:netconf:base:1.0"
namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0"

include "nc-base-common.rnc"

## Server messages may have either "hello" or "rpc-reply" as
## the document element.
start = hello-element | rpc-reply-element

## Server's "hello" message must include "session-id".
## See RFC 4741, Sec. 8.1.
hello-content &= session-id-element

## This element is a wrapper for all RPC replies.
## See RFC 4741, Sec. 4.2.
rpc-reply-element =
  element rpc-reply {
    attribute * { text }*,
    ((# Positive response
      message-id-attribute,
      element rpc-reply { rpc-reply-choice })
     | (# error reply to a rpc without message-id is special
        missing-message-id-error
        | (# Negative response
           message-id-attribute,
           element rpc-error { rpc-error-choice }+)))
  }

## Specific error reply to an "rpc" without message-id.
## Only in this case can "message-id" be missing in an "rpc-reply".
missing-message-id-error =
  element rpc-error {
    element error-tag { "missing-attribute" }
    & element error-type { "rpc" }
    & element error-severity { "error" }
    & element error-info {
        element bad-attribute { "message-id" }
        & element bad-element { "rpc" }
      }
    & optional-error-content
  }

## Possible RPC replies. See RFC 4741, Sec. 4.2.
## Capabilities may extend this pattern.
rpc-reply-choice = ok-element | data-element

## See RFC 4741, Sec. 4.4.
ok-element = element ok { empty }

## Content depends on data model. Here we have to allow everything.
data-element = element data { wrapped-arbitrary-content }

## These errors are defined in RFC 4741, Appendix A.
rpc-error-choice =
  in-use-error-content
  | too-big-error-content
  | missing-attribute-error-content
  | bad-attribute-error-content
  | bad-attribute-error-content
  | unknown-attribute-error-content
  | missing-element-error-content
  | bad-element-error-content
  | unknown-element-error-content
  | unknown-namespace-error-content
  | access-denied-error-content
  | lock-denied-error-content
  | resource-denied-error-content
  | rollback-failed-error-content
  | data-exists-error-content
  | data-missing-error-content
  | operation-not-supported-error-content
  | operation-failed-error-content
  | partial-operation-error-content
error-types-pa = "protocol" | "application"
error-types-rpa = error-types-pa | "rpc"
error-types-all = error-types-rpa | "transport"
optional-error-content =
  element error-app-tag { xsd:string }?
  & element error-path { xsd:string }?
  & element error-message {
      attribute xml:lang { xsd:token }?,
      xsd:string
    }?
element-error-info = element bad-element { xsd:QName }
attribute-error-info =
  element bad-attribute { xsd:QName }
  & element-error-info

## Resource in use
in-use-error-content =
  element error-tag { "in-use" }
  & element error-type { error-types-pa }
  & element error-severity { "error" }
  & optional-error-content

## Response would be too large for the implementation
too-big-error-content =
  element error-tag { "too-big" }
  & element error-type { error-types-all }
  & element error-severity { "error" }
  & optional-error-content

## A required attribute is missing
missing-attribute-error-content =
  element error-tag { "missing-attribute" }
  & element error-type { error-types-rpa }
  & element error-severity { "error" }
  & element error-info { attribute-error-info }
  & optional-error-content

## Incorrect attribute value
bad-attribute-error-content =
  element error-tag { "bad-attribute" }
  & element error-type { error-types-rpa }
  & element error-severity { "error" }
  & element error-info { attribute-error-info }
  & optional-error-content

## An unexpected attribute is present
unknown-attribute-error-content =
  element error-tag { "unknown-attribute" }
  & element error-type { error-types-rpa }
  & element error-severity { "error" }
  & element error-info { attribute-error-info }
  & optional-error-content

## A required element is missing
missing-element-error-content =
  element error-tag { "missing-element" }
  & element error-type { error-types-rpa }
  & element error-severity { "error" }
  & element error-info { element-error-info }
  & optional-error-content

## Incorrect element value
bad-element-error-content =
  element error-tag { "bad-element" }
  & element error-type { error-types-rpa }
  & element error-severity { "error" }
  & element error-info { element-error-info }
  & optional-error-content

## An unexpected element is present
unknown-element-error-content =
  element error-tag { "unknown-element" }
  & element error-type { error-types-rpa }
  & element error-severity { "error" }
  & element error-info { element-error-info }
  & optional-error-content

## An unknown namespace is used
unknown-namespace-error-content =
  element error-tag { "unknown-element" }
  & element error-type { error-types-rpa }
  & element error-severity { "error" }
  & element error-info {
      element-error-info
      & element bad-namespace { xsd:Name }
    }
  & optional-error-content

## Access denied due to authorization failure
access-denied-error-content =
  element error-tag { "access-denied" }
  & element error-type { error-types-rpa }
  & element error-severity { "error" }
  & optional-error-content

## Access to the requested lock is denied
lock-denied-error-content =
  element error-tag { "lock-denied" }
  & element error-type { "protocol" }
  & element error-severity { "error" }
  & element error-info {
      element session-id { xsd:nonNegativeInteger }
    }
  & optional-error-content

## Insufficient resources
resource-denied-error-content =
  element error-tag { "resource-denied" }
  & element error-type { error-types-all }
  & element error-severity { "error" }
  & optional-error-content

## Rollback not completed.
## Requires either :rollback-on-error or :candidate capability.
rollback-failed-error-content =
  element error-tag { "rollback-failed" }
  & element error-type { error-types-pa }
  & element error-severity { "error" }
  & optional-error-content

## Relevant data already exists
data-exists-error-content =
  element error-tag { "data-exists" }
  & element error-type { "application" }
  & element error-severity { "error" }
  & optional-error-content

## Relevant data missing
data-missing-error-content =
  element error-tag { "data-missing" }
  & element error-type { "application" }
  & element error-severity { "error" }
  & optional-error-content

## Operation not supported by the implementation
operation-not-supported-error-content =
  element error-tag { "operation-not-supported" }
  & element error-type { error-types-rpa }
  & element error-severity { "error" }
  & optional-error-content

## Requested operation failed for some reason
operation-failed-error-content =
  element error-tag { "operation-failed" }
  & element error-type { error-types-rpa }
  & element error-severity { "error" }
  & optional-error-content

## Part of the operation failed or was not attempted
partial-operation-error-content =
  element error-tag { "partial-operation" }
  & element error-type { "application" }
  & element error-severity { "error" }
  & element error-info {
      element ok-element { xsd:QName }*
      & element err-element { xsd:QName }*
      & element noop-element { xsd:QName }*
    }
  & optional-error-content

END]]>
      </artwork>
    </figure>

  </section>

    <section anchor="writable-running" title='Capability :writable-running'>
      <t>This module specifies the extensions to the client schema
      provided by the :writable-running capability. The server
      schema is unchanged. See RFC 4741 <xref target="RFC4741"/>,
      Sec. 8.2.</t>

      <figure>
	<artwork><![CDATA[BEGIN

# source file: nc-writable-running-client.rng

default namespace = "urn:ietf:params:xml:ns:netconf:base:1.0"
namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0"

## This adds "running" as an option for the "target" parameter
## of NETCONF operations.
target-choice |= running-element

END]]>
	</artwork>
      </figure>

    </section>

    <section anchor="candidate" title='Capability :candidate'>
      <t>This module specifies the extensions to the client schema
      provided by the :candidate capability. The server schema is
      unchanged. See RFC 4741 <xref target="RFC4741"/>, Sec. 8.3.</t>

      <figure>
	<artwork><![CDATA[BEGIN

# source file: nc-candidate-client.rng

default namespace = "urn:ietf:params:xml:ns:netconf:base:1.0"
namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0"

## This adds "candidate" as an option for both "source" and "target"
## parameter of NETCONF operations.
extra-datastore-choice |= element candidate { empty }

## Two new RPC operations are added.
rpc-operation-choice |=
  element commit { commit-content }
  | element discard-changes { discard-changes-content }

## See RFC 4741, Sec. 8.3.4.1.
commit-content = empty

## See RFC 4741, Sec. 8.3.4.2.
discard-changes-content = empty

END]]>
	</artwork>
      </figure>

    </section>

    <section anchor="confirmed-commit" title='Capability :confirmed-commit'>
      <t>This module specifies the extensions to the client schema
      provided by the :confirmed-commit capability. The server
      schema is unchanged. See RFC 4741 <xref target="RFC4741"/>,
      Sec. 8.4.</t>

      <figure>
	<artwork><![CDATA[BEGIN

# source file: nc-confirmed-commit-client.rng

default namespace = "urn:ietf:params:xml:ns:netconf:base:1.0"
namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0"

## The "confirm-timeout" parameter is given in seconds.
## The default is 600. See RFC 4741, Sec. 8.4.5.1.
commit-content &=
  (element confirmed { empty }
   & element confirm-timeout { xsd:positiveInteger }?)?

END]]>
      </artwork></figure>
    </section>

    <section anchor="rollback-on-error" title='Capability :rollback-on-error'>
      <t>This module specifies the extensions to the client schema
      provided by the :rollback-on-error capability. The server
      schema is unchanged. See RFC 4741 <xref target="RFC4741"/>,
      Sec. 8.5.</t>

      <figure>
	<artwork><![CDATA[BEGIN

# source file: nc-rollback-on-error-client.rng

default namespace = "urn:ietf:params:xml:ns:netconf:base:1.0"
namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0"

error-option-choice |= "rollback-on-error"

END]]>
	</artwork>
      </figure>

    </section>

    <section anchor="validate" title='Capability :validate'>
      <t>This module specifies the extensions to the client schema
      provided by the :validate capability. The server schema is
      unchanged. See RFC 4741 <xref target="RFC4741"/>, Sec. 8.6.</t>

      <figure>
	<artwork><![CDATA[BEGIN

# source file: nc-validate-client.rng

default namespace = "urn:ietf:params:xml:ns:netconf:base:1.0"
namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0"

rpc-operation-choice |= element validate { validate-content }

## See RFC 4741, Sec. 8.6.4.1.
validate-content = element source { source-choice | config-data-spec }

END]]>
	</artwork>
      </figure>

    </section>

    <section anchor="startup" title='Capability :startup'>
      <t>This module specifies the extensions to the client schema
      provided by the :startup capability. The server schema is
      unchanged. See RFC 4741 <xref target="RFC4741"/>, Sec. 8.7.</t>

      <figure>
	<artwork><![CDATA[BEGIN

# source file: nc-startup-client.rng

default namespace = "urn:ietf:params:xml:ns:netconf:base:1.0"
namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0"

## This adds "startup" as an option for both "source" and "target"
## parameter of NETCONF operations.
extra-datastore-choice |= element startup { empty }

END]]>
	</artwork>
      </figure>

    </section>

    <section anchor="url" title='Capability :url'>
      <t>This module specifies the extensions to the client schema
      provided by the :url capability. The server schema is
      unchanged. See RFC 4741 <xref target="RFC4741"/>, Sec. 8.8.</t>

      <figure>
	<artwork><![CDATA[BEGIN

# source file: nc-url-client.rng

default namespace = "urn:ietf:params:xml:ns:netconf:base:1.0"
namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0"

source-choice |= element url { xsd:anyURI }
target-choice |= element url { xsd:anyURI }

END]]>
	</artwork>
      </figure>

    </section>

    <section anchor="xpath" title='Capability :xpath'>
      <t>This module specifies the extensions to the client schema
      provided by the :xpath capability. The server schema is
      unchanged. See RFC 4741 <xref target="RFC4741"/>, Sec. 8.9.</t>

      <figure>
	<artwork><![CDATA[BEGIN

# source file: nc-xpath-client.rng

default namespace = "urn:ietf:params:xml:ns:netconf:base:1.0"
namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0"

filter-content-choice |=
  attribute type { "xpath" },
  attribute select { xsd:string }

END]]>
	</artwork>
      </figure>
    </section>

  </section>

</back>

</rfc>