TOC 
NETCONFL. Lhotka
Internet-DraftCESNET
Intended status: InformationalMarch 02, 2009
Expires: September 3, 2009 


Modular RELAX NG Schema of NETCONF RPC and Protocol Operations
draft-lhotka-netconf-relaxng-00

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on September 3, 2009.

Copyright Notice

Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

Abstract

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.



Table of Contents

1.  Introduction
2.  Problems of the NETCONF XSD Schema
3.  Description of the RELAX NG Schemas
4.  Assembling the Modules into Validation Schemas
5.  Conclusions
6.  References
Appendix A.  RELAX NG Schema Modules
    A.1.  Common patterns
    A.2.  Base Client Schema
    A.3.  Base Server Schema
    A.4.  Capability :writable-running
    A.5.  Capability :candidate
    A.6.  Capability :confirmed-commit
    A.7.  Capability :rollback-on-error
    A.8.  Capability :validate
    A.9.  Capability :startup
    A.10.  Capability :url
    A.11.  Capability :xpath
§  Author's Address




 TOC 

1.  Introduction

Specification of the NETCONF protocol [1] (Enns, R., Ed., “NETCONF Configuration Protocol,” December 2006.) contains in its Appendix B a formal definition of the vocabulary of RPC and protocol operations expressed using the W3C XML Schema language ([2] (Thompson, H., Ed., Beech, D., Ed., Maloney, M., Ed., and N. Mendelsohn, Ed., “XML Schema Part 1: Structures, Second Edition,” October 2004.), [3] (Biron, P., Ed. and A. Malhotra, Ed., “XML Schema Part 2: Datatypes, Second Edition,” October 2004.) - henceforth referred to as "XSD").

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.

This report introduces a new modular schema for the same NETCONF protocol vocabulary expressed in RELAX NG [4] (ISO/IEC, “Document Schema Definition Languages (DSDL) - Part 2: Regular Grammar-Based Validation - RELAX NG,” December 2002.), a simple but powerful schema language that became Part 2 of the international standard ISO/IEC 19757 [5] (ISO/IEC, “Document Schema Definition Languages (DSDL) - Part 1: Overview,” 11 2004.). 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.

The goal of this work is twofold:

  1. 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.
  2. 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.

The report is organized as follows: In the Section 2 (Problems of the NETCONF XSD Schema) we summarize the problems of the NETCONF XSD schema, Section 3 (Description of the RELAX NG Schemas) describes the structure and main design features of the modular RELAX NG schema, Section 4 (Assembling the Modules into Validation Schemas) shows how to use the modules for effective validation of NETCONF PDUs in specific contexts and finally Section 5 (Conclusions) concludes the reports. Appendix A (RELAX NG Schema Modules) contains full listing of the RELAX NG modules in the compact syntax.



 TOC 

2.  Problems of the NETCONF XSD Schema

The NETCONF XSD schema in Appendix B of [1] (Enns, R., Ed., “NETCONF Configuration Protocol,” December 2006.) 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.

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.

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.

Finally, Appendix A of [1] (Enns, R., Ed., “NETCONF Configuration Protocol,” December 2006.) 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.



 TOC 

3.  Description of the RELAX NG Schemas

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.

The RELAX NG schema is divided into 11 modules, each of them stored in a separate file:

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.

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.

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 [1] (Enns, R., Ed., “NETCONF Configuration Protocol,” December 2006.) 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.

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.



 TOC 

4.  Assembling the Modules into Validation Schemas

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 [1] (Enns, R., Ed., “NETCONF Configuration Protocol,” December 2006.)) will successfully validate against the "nc-base-client" schema:

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

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:

include "nc-base-client.rnc"
include "nc-startup-client.rnc"

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

For the server PDUs the procedure is analogical but generally simpler since none of the standard capabilities defined in [1] (Enns, R., Ed., “NETCONF Configuration Protocol,” December 2006.) affects the server schema, so the "nc-base-server" schema is sufficient for validating server PDUs.



 TOC 

5.  Conclusions

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 [1] (Enns, R., Ed., “NETCONF Configuration Protocol,” December 2006.). 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.

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.

The simplicity and limited scope of the schema modules also enables their inclusion in larger validation frameworks such as DSDL [5] (ISO/IEC, “Document Schema Definition Languages (DSDL) - Part 1: Overview,” 11 2004.) and/or combination with a NETCONF concrete data model expressed in RELAX NG or a different data modelling language.

As a matter of fact, most improvements described in this report could, and probably should, be applied to the NETCONF XSD schema in [1] (Enns, R., Ed., “NETCONF Configuration Protocol,” December 2006.), too. The only notable exception is the compact syntax, which is special to RELAX NG.



 TOC 

6. References

[1] Enns, R., Ed., “NETCONF Configuration Protocol,” RFC 4741, December 2006.
[2] Thompson, H., Ed., Beech, D., Ed., Maloney, M., Ed., and N. Mendelsohn, Ed., “XML Schema Part 1: Structures, Second Edition,” October 2004.
[3] Biron, P., Ed. and A. Malhotra, Ed., “XML Schema Part 2: Datatypes, Second Edition,” October 2004.
[4] ISO/IEC, “Document Schema Definition Languages (DSDL) - Part 2: Regular Grammar-Based Validation - RELAX NG,” ISO/IEC 19757-2, December 2002.
[5] ISO/IEC, “Document Schema Definition Languages (DSDL) - Part 1: Overview,” ISO/IEC 19757-1, 11 2004.


 TOC 

Appendix A.  RELAX NG Schema Modules

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 [1] (Enns, R., Ed., “NETCONF Configuration Protocol,” December 2006.).



 TOC 

A.1.  Common patterns

This module defines several parameters patterns that are referenced in both the client and server schemas.

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 }
    &amp; 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


 TOC 

A.2.  Base Client Schema

This module specifies the NETCONF client vocabulary without any optional capabilities.

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 }
  &amp; 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 }
  &amp; element default-operation { default-operation-choice }?
  &amp; element error-option { error-option-choice }?
  &amp; 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 }
  &amp; 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


 TOC 

A.3.  Base Server Schema

This module specifies the NETCONF server vocabulary without any optional capabilities.

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 &amp;= 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" }
    &amp; element error-type { "rpc" }
    &amp; element error-severity { "error" }
    &amp; element error-info {
        element bad-attribute { "message-id" }
        &amp; element bad-element { "rpc" }
      }
    &amp; 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 }?
  &amp; element error-path { xsd:string }?
  &amp; 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 }
  &amp; element-error-info

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

END


 TOC 

A.4.  Capability :writable-running

This module specifies the extensions to the client schema provided by the :writable-running capability. The server schema is unchanged. See RFC 4741 [1] (Enns, R., Ed., “NETCONF Configuration Protocol,” December 2006.), Sec. 8.2.

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


 TOC 

A.5.  Capability :candidate

This module specifies the extensions to the client schema provided by the :candidate capability. The server schema is unchanged. See RFC 4741 [1] (Enns, R., Ed., “NETCONF Configuration Protocol,” December 2006.), Sec. 8.3.

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


 TOC 

A.6.  Capability :confirmed-commit

This module specifies the extensions to the client schema provided by the :confirmed-commit capability. The server schema is unchanged. See RFC 4741 [1] (Enns, R., Ed., “NETCONF Configuration Protocol,” December 2006.), Sec. 8.4.

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 &amp;=
  (element confirmed { empty }
   &amp; element confirm-timeout { xsd:positiveInteger }?)?

END


 TOC 

A.7.  Capability :rollback-on-error

This module specifies the extensions to the client schema provided by the :rollback-on-error capability. The server schema is unchanged. See RFC 4741 [1] (Enns, R., Ed., “NETCONF Configuration Protocol,” December 2006.), Sec. 8.5.

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


 TOC 

A.8.  Capability :validate

This module specifies the extensions to the client schema provided by the :validate capability. The server schema is unchanged. See RFC 4741 [1] (Enns, R., Ed., “NETCONF Configuration Protocol,” December 2006.), Sec. 8.6.

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


 TOC 

A.9.  Capability :startup

This module specifies the extensions to the client schema provided by the :startup capability. The server schema is unchanged. See RFC 4741 [1] (Enns, R., Ed., “NETCONF Configuration Protocol,” December 2006.), Sec. 8.7.

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


 TOC 

A.10.  Capability :url

This module specifies the extensions to the client schema provided by the :url capability. The server schema is unchanged. See RFC 4741 [1] (Enns, R., Ed., “NETCONF Configuration Protocol,” December 2006.), Sec. 8.8.

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


 TOC 

A.11.  Capability :xpath

This module specifies the extensions to the client schema provided by the :xpath capability. The server schema is unchanged. See RFC 4741 [1] (Enns, R., Ed., “NETCONF Configuration Protocol,” December 2006.), Sec. 8.9.

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


 TOC 

Author's Address

  Ladislav Lhotka
  CESNET
  Zikova 4
  Praha 6 160 00
  CZ
Email:  lhotka@cesnet.cz