Network Working Group S. Chisholm
Internet-Draft Nortel
Intended status: Standards Track A. Clemm
Expires: August 28, 2008 J. Tjong
Cisco
February 25, 2008
Using XML Schema to define NETCONF Content
draft-chisholm-netconf-model-08.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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 August 28, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Chisholm, et al. Expires August 28, 2008 [Page 1]
Internet-Draft XML Schema Usage for NETCONF February 2008
Abstract
This memo defines a framework for defining content for NETCONF using
a meta-model and XML Schema. The approach is to build on existing
well-deployed technology and overlap management specific semantics to
ensure high-quality interoperable definition of NETCONF content.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Definition of Terms . . . . . . . . . . . . . . . . . . . 5
1.2. Embedded Meta-Model . . . . . . . . . . . . . . . . . . . 6
1.2.1. Managed Resource . . . . . . . . . . . . . . . . . . . 8
1.2.2. Relationships . . . . . . . . . . . . . . . . . . . . 10
1.2.3. Extensions and Specializations . . . . . . . . . . . . 11
1.2.4. Event Reports . . . . . . . . . . . . . . . . . . . . 11
1.3. Types of Specification Files . . . . . . . . . . . . . . . 12
1.4. Document Overview . . . . . . . . . . . . . . . . . . . . 13
2. Overview of XML Schema Mapping . . . . . . . . . . . . . . . . 14
2.1. Why XML Schema . . . . . . . . . . . . . . . . . . . . . . 14
2.2. Mapping Meta-Model to XML Schema . . . . . . . . . . . . . 14
2.3. Summary of NETCONF Appinfo Elements & Attributes . . . . . 15
2.4. Mapping Details . . . . . . . . . . . . . . . . . . . . . 15
2.4.1. Schema Namespaces . . . . . . . . . . . . . . . . . . 15
2.4.2. Conformance . . . . . . . . . . . . . . . . . . . . . 15
2.4.3. Versioning and Backwards Compatibility . . . . . . . . 18
2.4.4. Keys and Relationships . . . . . . . . . . . . . . . . 19
2.4.5. Defining Notification Event Messages . . . . . . . . . 21
2.4.6. Error Messages . . . . . . . . . . . . . . . . . . . . 23
2.4.7. Schema Documentation . . . . . . . . . . . . . . . . . 24
2.4.8. Specifying Operational and Configuration
Information . . . . . . . . . . . . . . . . . . . . . 24
2.4.9. Defaults . . . . . . . . . . . . . . . . . . . . . . . 25
2.4.10. Constraints . . . . . . . . . . . . . . . . . . . . . 26
2.4.11. Information about the Model Definition . . . . . . . . 26
2.4.12. Units . . . . . . . . . . . . . . . . . . . . . . . . 26
2.4.13. Modelling Considerations . . . . . . . . . . . . . . . 27
2.4.14. Avoid Mixed Content . . . . . . . . . . . . . . . . . 28
2.4.15. Ease of Parsing . . . . . . . . . . . . . . . . . . . 29
3. XML Schema for appInfo Annotations . . . . . . . . . . . . . . 30
4. DHCP Example . . . . . . . . . . . . . . . . . . . . . . . . . 33
5. XML-based Syntax Data definition . . . . . . . . . . . . . . . 38
5.1. Conformance Information . . . . . . . . . . . . . . . . . 39
5.2. Library and Implementation Packages . . . . . . . . . . . 39
5.3. Translating to XML Schema . . . . . . . . . . . . . . . . 41
6. How this approach meets RCDML Requirements . . . . . . . . . . 42
6.1. REQ#3.1. Consequences of NETCONF . . . . . . . . . . . . 42
Chisholm, et al. Expires August 28, 2008 [Page 2]
Internet-Draft XML Schema Usage for NETCONF February 2008
6.1.1. 3.1.1. Notification Definition (Agreed) . . . . . . . 42
6.1.2. REQ#3.1.2. Notification Get (NOT Agreed) . . . . . . 42
6.1.3. REQ#3.1.3. Locking (Agreed) . . . . . . . . . . . . . 42
6.1.4. REQ#3.1.4. All Base Operations (Agreed) . . . . . . . 43
6.1.5. REQ#3.1.5. Define new NETCONF Operations (Agreed) . . 44
6.1.6. REQ#3.1.6. Separation of Operations and Payload
(Agreed) . . . . . . . . . . . . . . . . . . . . . . . 44
6.1.7. REQ#3.1.7. Error Annotation (Agreed) . . . . . . . . 45
6.1.8. REQ#3.1.8. No Mixed Content (Agreed) . . . . . . . . 45
6.2. REQ#3.2. Model Representation Requirements . . . . . . . 45
6.2.1. REQ#3.2.1. Human Readable (Agreed) . . . . . . . . . 45
6.2.2. REQ#3.2.2. Machine Readable (Agreed) . . . . . . . . 45
6.2.3. REQ#3.2.3. Textual Representation (Agreed) . . . . . 45
6.2.4. REQ#3.2.4. Document Information (Agreed) . . . . . . 46
6.2.5. REQ#3.2.5. Ownership and Change Control (Agreed) . . 46
6.2.6. REQ#3.2.6. Dependency Risk Reduction (Agreed) . . . . 46
6.2.7. REQ#3.2.7. Diff-Friendly (Agreed) . . . . . . . . . . 46
6.2.8. REQ#3.2.8. Internationalization and Localization . . 47
6.3. REQ#3.3. Reusability Requirements . . . . . . . . . . . . 48
6.3.1. REQ#3.3.1. Modularity (Agreed) . . . . . . . . . . . 48
6.3.2. REQ#3.3.2. Reusable Definitions (Agreed) . . . . . . 48
6.3.3. REQ#3.3.3. Modular extension (Agreed) . . . . . . . . 49
6.4. REQ#3.4. Instance Data Requirements . . . . . . . . . . . 49
6.4.1. REQ#3.4.1. Default Values on the Wire (Agreed) . . . 49
6.4.2. REQ#3.4.2. Ordering . . . . . . . . . . . . . . . . . 50
6.4.3. REQ#3.4.3. Validation . . . . . . . . . . . . . . . . 51
6.4.4. REQ#3.4.4. Instance Canonicalization (Agreed) . . . . 52
6.4.5. REQ#3.4.5. Character Set and Encoding (Agreed) . . . 52
6.4.6. REQ#3.4.6. Model Instance Localization (NOT
Agreed) . . . . . . . . . . . . . . . . . . . . . . . 52
6.5. REQ#3.5. Semantic Richness Requirements . . . . . . . . . 53
6.5.1. REQ#3.5.1. Human-Readable Semantics (Agreed) . . . . 53
6.5.2. REQ#3.5.2. Basic Types (Agreed) . . . . . . . . . . . 53
6.5.3. REQ#3.5.3. Handling Opaque Data (Agreed) . . . . . . 53
6.5.4. REQ#3.5.4. Keys . . . . . . . . . . . . . . . . . . . 53
6.5.5. REQ#3.5.5. Relationships . . . . . . . . . . . . . . 54
6.5.6. REQ#3.5.6. Hierarchical Data . . . . . . . . . . . . 55
6.5.7. REQ#3.5.7. Referential Integrity . . . . . . . . . . 55
6.5.8. REQ#3.5.8. Characterize Data (Agreed) . . . . . . . . 56
6.5.9. REQ#3.5.9. Defaults . . . . . . . . . . . . . . . . . 56
6.5.10. REQ#3.5.10. Formal Constraints . . . . . . . . . . . 56
6.5.11. REQ#3.5.11. Units (Agreed) . . . . . . . . . . . . . 57
6.5.12. REQ#3.5.12. Define Actions (NOT Agreed) . . . . . . . 57
6.6. REQ#3.6. Extensibility Requirements . . . . . . . . . . . 57
6.6.1. REQ#3.6.1. Language Extensibility . . . . . . . . . . 58
6.6.2. REQ#3.6.2. Model Extensibility . . . . . . . . . . . 59
6.6.3. REQ#3.6.3. Instance Data Extensibility . . . . . . . 59
6.7. REQ#3.7. Talking About Conformance . . . . . . . . . . . 61
Chisholm, et al. Expires August 28, 2008 [Page 3]
Internet-Draft XML Schema Usage for NETCONF February 2008
6.7.1. REQ#3.7.1. Conformance to the Modeling Language
(NOT Agreed) . . . . . . . . . . . . . . . . . . . . . 61
6.7.2. REQ#3.7.2. Conformance to a Model (Agreed) . . . . . 61
6.8. REQ#3.8. Techno-Political Constraints . . . . . . . . . . 62
6.8.1. REQ#3.8.1. Standard Technology (NOT Agreed) . . . . . 62
6.8.2. REQ#3.8.2. Translate Models to Other Forms (Agreed) . 63
6.8.3. REQ#3.8.3. Minimize SMI Translation Pain (NOT
Agreed) . . . . . . . . . . . . . . . . . . . . . . . 63
6.8.4. REQ#3.8.4. Generate Models from Other Forms (NOT
Agreed) . . . . . . . . . . . . . . . . . . . . . . . 64
6.8.5. REQ#3.8.5. Isolate Models from Protocol (NOT
Agreed) . . . . . . . . . . . . . . . . . . . . . . . 64
6.8.6. REQ#3.8.6. Library Support (NOT Agreed) . . . . . . . 64
6.8.7. REQ#3.8.7. RFC 3139 Considerations . . . . . . . . . 65
6.8.8. REQ#3.8.8. RFC 3216 Considerations . . . . . . . . . 65
7. Relationship to NETCONF Protocol . . . . . . . . . . . . . . . 66
8. Security Considerations . . . . . . . . . . . . . . . . . . . 67
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 68
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 69
10.1. Normative References . . . . . . . . . . . . . . . . . . . 69
10.2. Informational References . . . . . . . . . . . . . . . . . 69
Appendix A. XML Syntax Definition of DHCP . . . . . . . . . . . . 70
A.1. Library Package . . . . . . . . . . . . . . . . . . . . . 70
A.2. Implementation Packages . . . . . . . . . . . . . . . . . 73
A.3. Example Mapping from XML Syntax . . . . . . . . . . . . . 75
Appendix B. Interworking with Yang . . . . . . . . . . . . . . . 77
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 78
Intellectual Property and Copyright Statements . . . . . . . . . . 79
Chisholm, et al. Expires August 28, 2008 [Page 4]
Internet-Draft XML Schema Usage for NETCONF February 2008
1. Introduction
[NETCONF] can be conceptually partitioned into four layers:
Layer Example
+-------------+ +-------------------------------------------+
| Content | | Configuration data |
+-------------+ +-------------------------------------------+
| |
+-------------+ +-------------------------------------------+
| Operations | | <get-config>, <edit-config> <notification>|
+-------------+ +-------------------------------------------+
| | |
+-------------+ +-----------------------------+ |
| RPC | | <rpc>, <rpc-reply> | |
+-------------+ +-----------------------------+ |
| | |
+-------------+ +-------------------------------------------+
| Transport | | BEEP, SSH, SSL, console |
| Protocol | | |
+-------------+ +-------------------------------------------+
This document defines a framework for NETCONF content using a meta-
model and XML Schema. The approach is to build on existing well-
deployed technology and overlap management specific semantics to
ensure high-quality interoperable definition of NETCONF content.
Figure 1
1.1. Definition of Terms
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Element: An XML Element [XML].
Managed Entity: A node, which supports [NETCONF] and has access to
management instrumentation. This is also referred to as the
NETCONF server.
Managed Resource: A collection of one of more Elements that define
an abstract thing of interest.
Chisholm, et al. Expires August 28, 2008 [Page 5]
Internet-Draft XML Schema Usage for NETCONF February 2008
Key: A key is an identifier of uniqueness within a list.
Reference: A reference is a pointer to relationships between Managed
Resources.
1.2. Embedded Meta-Model
NETCONF content is defined in terms of a set of Managed Resources
that can be managed, each containing a set of elements and attributes
representing configuration and operational data. Managed resources
can support actions that are specific to them, in addition to
separately defined NETCONF operations. These actions are methods
that cause the underlying managed system to "do" something, rather
than just having it be reflected as part of management
information(configuration and operational data).
The structure of a Managed Resource definition is depicted in the
following diagram:
Chisholm, et al. Expires August 28, 2008 [Page 6]
Internet-Draft XML Schema Usage for NETCONF February 2008
+----------------------------------------+
| |
| +--------------------+ |
| | managedResource | |
| | +---------------+ |
| | | key attribute | |
| | +---------------+ |
| | +---------------+ |
| | | reference | |
| | +---------------+ |
| | | |
| | +-----------------------------+ |
| | | configData | |
| | | +--------------------------+ |
| | | | attribute and elements | |
| | | +--------------------------+ |
| | +-----------------------------+ |
| | +-----------------------------+ |
| | | operationalData | |
| | | +--------------------------+ |
| | | | attribute and elements | |
| | | +--------------------------+ |
| | +-----------------------------+ |
| | | |
| | +---------------+ |
| | | action | |
| | +---------------+ |
| + |
| +--------------+ |
| | eventReport | |
| +--------------+ |
+----------------------------------------+
Figure 2: Netconf Managed Resource Structure
Entities
o managedResource: the main entity being configured and monitored
o Event Report
o Properties
* The key is used to identify instances of the managed resource.
The key therefore needs to be unique within a naming scope and
are not subject to change. It consists of one of more elements
or attributes.
Chisholm, et al. Expires August 28, 2008 [Page 7]
Internet-Draft XML Schema Usage for NETCONF February 2008
* References are used to represent relationship a Managed
Resource may have with another Managed Resource. References
are associated with certain referential integrity constraints
that also specify who is responsible for maintaining the
reference data.
* Configuration data represents properties of the device that are
subject to configuration by a NETCONF client.
* Operational data represents properties of the device that
represent state (including counters, gauges, statistical
parameters) that can be retrieved from the managed system but
is not subject to configuration.
* Actions are operations directed at a managed resources that are
intended to have a real effect as opposed to retrieving or
modifying management data. Examples would be actions to emit a
test pattern on a line or restart a subsystem.
Managed Resources constitute the main informational entities in an
Netconf data definition. A managed resource represents some aspect
of the managed system that in general can be treated as one holistic
entity, which includes a variety of management parameters. It
represents an "object" of sorts, such as an interface, a service
instance, a line card.
Configuration data and operational data can be defined within a
containing managed resource, or separately for inclusion in different
managed resources.
The Netconf data d efinition also defines event reports. Event
reports are definitions of Notifications that can be emitted by a
Managed Resource. Note that event reports do not necessarily need to
be only associated with a particular Managed Resource.
Instances of a Managed Resource can contain other Managed Resource
instances. For example, the definition of a card Managed Resource
instance may contain the definition of a port Managed Resource
instance. This containment is specified during the model definition.
1.2.1. Managed Resource
A Managed Resource defines an entity to be managed. Its definition
includes its name, a description and a key.
The description contains an explanation of the Managed Resource's
purpose and any behaviour that is not otherwise specified as part of
its definition.
Chisholm, et al. Expires August 28, 2008 [Page 8]
Internet-Draft XML Schema Usage for NETCONF February 2008
The key is an element or attribute, or set of elements or attributes,
used to identify the Managed Resource. The key must be unique within
a scope of the Managed Resource. The value of a key is not allowed
to change during the lifetime of the Managed Resource, from the
moment the Managed Resource is created to the moment in which it is
deleted. This means that a key is in effect read-only or read-
create. The key value needs to be assigned by the Netconf client, in
the case its access properties allow for its creation as part of a
Netconf operation. In all other cases, the key value is assigned by
the Netconf server.
The References are indicative of the relationships that a Managed
Resource can participate in, along with a set of constraints, for
example, concerning the Managed Resources that may be referenced.
Configuration Data is data that is subject to inclusion in a
configuration, subject to manipulation by a client through Netconf
operations such as edit-config or copy-config. It refers to data
that determines and guides the behaviour of the managed system.
Configuration Data consists of a set of configuration elements and
attributes, each representing one particular data item.
Operational Data is in effect any management information that is not
configuration data. It refers to data that results from the
operation of the managed system, such as operational state,
performance data, and utilization data - data that is in effect
determined by the managed system and that results from its behaviour.
In addition, it includes data that is immutable, such as the serial
number of a managed device. Operational data is never subject to
configuration, but subjected to retrieval only. Like Configuration
Data, Operational Data consists of a set of elements and attributes,
each representing one particular data item.
Actions are methods that can be invoked on a Managed Resource whose
functionality goes above and beyond the manipulation and retrieval of
configuration or operational data. Generally, actions have a "real
effect", for example triggering a test. The definition of an Action
includes definition of a set of input and output parameters.
Elements and attributes that are part of configuration data or
operational data can be subjected to a number of constrains and
assertions. Specifically:
o Cardinality: Is the element single valued, or is it a collection
of values
o Size: The size attribute multiplicity is "many", it indicates the
range of sizes of the collection.
Chisholm, et al. Expires August 28, 2008 [Page 9]
Internet-Draft XML Schema Usage for NETCONF February 2008
o Value assertions. An assertion consists of a value constraint,
which allows user to restrict the range of values an attribute may
have. In addition, the assertion allows model developers to
specify a condition under which the constraint is in effect. It
is possible to define several assertions; in that case only the
first applicable assertion is applied and others are ignored, much
like in the case of Access Control Lists, only the first
applicable access control rule is applied. This way, issues with
potentially conflicting assertions are avoided.
1.2.2. Relationships
Managed Resources can maintain relationships with other Managed
Resources. This needs to be captured in the "references" portion of
the Managed Resource definitions. A relationship will not be
specified independently of Managed Resources that are related.
Instead, the definition of a Managed Resource will explicitly state
any references that the Managed Resource needs to be aware of. This
way, relationships resemble more closely associations that can be
traversed, also reflecting the way developers think about
associations. In order to specify a relationship as a reference in a
Managed Resource, the following can be specified: the name of the
reference, the constraints on the reference (what resource can be
involved in the referencec) and, the cardinality of the reference.
As a convention, a reference name should be chosen to indicates the
role that the other Managed Resource plays in the relationship.
A constraint on the relationship defines what the the reference may
point to. The constraint specifies the type of Managed Resource that
is expected on the other side, or that the Managed Resource on the
other side needs to extend or implement. In case no constraint is
specified, the reference may point to any type of Managed Resource.
A cardinaility indicates whether the Managed Resource can be with
one, or with many other instance of a Managed Resources in
relationship with at any one time.
An access constraint indicates whether the reference may be
manipulated by a NETCONF client (read/write), whether the reference
is supposed to be supplied upon object creation (read/create), or
whether the information about the relationship is simply exposed to a
manager but maintained from within (read only). If the Managed
Resource allows the reference to be modified, it is the Managed
Resource's responsibility to ensure that any inverse references on
the other side get updated accordingly - it will not be the NETCONF
client's responsibility to maintain referential integrity, but the
NETCONF server's.
Chisholm, et al. Expires August 28, 2008 [Page 10]
Internet-Draft XML Schema Usage for NETCONF February 2008
It is important to be able to learn the relationships between the
managed resources that are represented in the content in order to be
able to take full advantage of information provided. In addition to
this, it is also important to be able to understand these
relationships to help predict the behaviour of the system. When a
configuration command causes the creation of a managed resource
represented by a piece of content, it causes the creation of all
other bits of XML Schema that represent that managed resource as well
as any applicable specializations of that resource.
Relationships need to be understood in general as well as the
specific run-time instances. The first is what is defined in the
model definition and the second is what we see only in the instance
document. The general relationship needs to be understood when
reading the schema or when designing tools and scripts to use the
Schema. For example, interfaces are associated with ports and there
is a specific method of learning more about this relationship. The
run-time instance relationship, for example that port 3 is associated
with interface number 324 is learned using the general method learned
while learning about the generalized relationships.
1.2.3. Extensions and Specializations
An extension to existing element defines information about the same
managed resource, but just does it in a separate piece of Schema.
For example, if a common Schema defines information about interfaces,
a particular product might define an extension to define information
for that interface that is only applicable to that product.
A specialization of an existing element is an extension that only
applies to a subset of the instances of the managed object that the
original definition applied to. For example, the original element
may define information about interfaces, with a specialization being
defined that is information only applicable to ATM interfaces.
1.2.4. Event Reports
Event Reports define in effect NETCONF event Notifications. The
following must specified for Event Reports:
o Managed Resource related to the event
o Event class
o Additional event information: A list of elements and attributes to
be included with the event report
Chisholm, et al. Expires August 28, 2008 [Page 11]
Internet-Draft XML Schema Usage for NETCONF February 2008
1.3. Types of Specification Files
In order to determine what constitutes valid Netconf Data, we must
make a distinction whether the data is carried as part of a Netconf
operation, or whether the Data represents the management information
of a Netconf server as whole. For example, data that is carried as
part of an "edit-config" operation must contain configuration data
only; it must not contain operational data describing statistical
counters or gauges or state. On the other hand, Netconf data that is
carried as part of a "get" operation may include such data.
There are two ways validate these different flavours of content. The
first is to use tools able to leverage the native XML Schema encoding
as well as the NETCONF-specific appInfo annotations defined in the
specification to determine compliance. A second method is to define
or generate different flavours of XML Schemas that each define a
specific conformance and can be used easily with generic tools to do
the validation.
Accordingly, there are two different types of documents that contain
Netconf Data:
o Netconf content that represents a device's management information,
as implemented by a Netconf agent and stored on a Netconf system.
o Netconf instance data that is carried as part of a Netconf
operation "over the wire". The corresponding XML document is
referred to as Client-XML (Netconf Operations Data XML). There
are separate Client-XMLs for each of the Netconf operations, i.e.
for get-config, get, edit-config, copy-config, delete-config.
There are two corresponding XML Schema Definitions:
o A Netconf data server-XSD describes the XML representation of a
device's management information as a whole.
o A Netconf Operations Data XSD (Client-XSD) describes Client-XML,
i.e. the instance data that is carried as part of Netconf
operations. Again, there are separate Client-XSDs for each of the
Netconf operations.
Server-XSD and Client-XSD either can be manually defined or generated
using tools from source which describes the configuration, perhaps
for use by more then NETCONF.
The diagram below depicts the relationship between the different
types of specification files as well as the instance data.
Chisholm, et al. Expires August 28, 2008 [Page 12]
Internet-Draft XML Schema Usage for NETCONF February 2008
0 A)
/|\ Hand-edit
/ \ definition
|
|
+--------+ +-------+ V +------------+ +--------+
| DDL |---->| Data |--+-->| Server-XSD |--validate-->| SERVER |
| | | Def | | | | | Content|
+--------+ +-------+ | +------------+ +--------+
Language Data Def |
XSD XML | B)generate
|
| +------------+ +-----------+
+-->| Client-XSD |--validate-->| CLIENT-XML|
| +------------+ +-----------+
|
|-->+---------=---+
| Non-Netconf |
| (CLI, etc) |
+-------------+
Figure 3: Relationship between different specification files
1.4. Document Overview
The remainder of the document is structured as follows:
Section 2 contains a brief explanation for the choice of XML
Schema as the basis for Netconf data models and defines how XML
schema is used.
Section 3 defines the XML schema used to define the appInfo
extensions used in Netconf data models.
Section 4 provides a DHCP example specification.
Section 5 discussed features the XML-based syntax.
Section 6 contains an explanation of how this specification meets
the requirements for a Netconf data definition language as laid
out in the RDCML draft.
Chisholm, et al. Expires August 28, 2008 [Page 13]
Internet-Draft XML Schema Usage for NETCONF February 2008
2. Overview of XML Schema Mapping
This section describes how to use XML Schema to define NETCONF
content, with the goal of defining a contract between a NETCONF
client and a NETCONF server as to how and what they will be
communicating with the goal of maximizing interoperabilty.
2.1. Why XML Schema
XML Schema is a great choice for specifying NETCONF content because
it is an existing, well-defined language which allows the NETCONF
community to get immediately started defining NETCONF content. The
language can be used as is and NETCONF specific annotations can be
added as appinfo extensions to the model specifications when they are
sufficiently mature.
Other benefits of using XML Schema result from the fact it is widely
used within the data communications industry and other industries.
This means that the NETCONF community can take advantage of existing
tools, training and subject matter experts for dealing with most
aspects of the content.
Note that this proposal is not advocating use of a subset of XML
Schema, but rather XML Schema itself. While there may be some
theoretical benefit to remove features whose need is not immediately
known, by not subsetting we are in a better position to take
advantage of industry tools and libraries today and this will also
make it easier to take advantage of any future improvements to XML
Schema, should we choose to do so.
It is interesting to look at the history of the NETCONF community
with [XPATH]. When NETCONF was first being designed, there was
concern that XPath might be too general or provide too many features
compared to the needs of the NETCONF protocol and may not be
something which all NETCONF servers would be able to support. The
approach taken was to developed subtree filtering and make both it
and XPath available as options. As time has passed and the community
has gained more experience, there is an increased appreciation of
XPath. It has seen many NETCONF server implementation and is serving
as the core technology in features like fine-grain locking currently
being developed by the NETCONF working group.
2.2. Mapping Meta-Model to XML Schema
The Meta-model described above of Management Resources that consist
of a collection of operation and configuration data as well as events
and actions provides management-specific context to aid in
understanding the definition of NETCONF content.
Chisholm, et al. Expires August 28, 2008 [Page 14]
Internet-Draft XML Schema Usage for NETCONF February 2008
Required information is defined using standard XML Schema constructs
as well as a small set of extensions defined using the appInfo
annotation.
2.3. Summary of NETCONF Appinfo Elements & Attributes
The following table summarizes the XML Schema appinfo annotations
introduced in this memo When these appinfo are used in the definition
of XML Schema for use with NETCONF, they are applicable to all
instances of that Schema.
------------------------------------------------
| appinfo item | | Compliance | Default |
-----------------------------------------------
| minAccess | | Optional | 1 |
| maxAccess | | Optional | 1 |
| status | | Optional | current |
| appErrors | | Optional | |
| eventClass | | Optional | |
| infoType | | Mandatory | |
| default | | Optional | |
| keyref | | Optional | |
| mustUse | | Optional | |
| unordered | | | |
| units | | | |
------------------------------------------------
Figure 4
2.4. Mapping Details
2.4.1. Schema Namespaces
All NETCONF content base elements SHOULD be defined in the namespace
urn:ietf:params:xml:ns:netmod:[something]
2.4.2. Conformance
When defining NETCONF content, it is also necessary to define
machine-readable conformance for that content. The following are the
requirements that have been identified for the conformance and
compliance aspects of NETCONF data models. This conformance is
defined for both the individual elements with the Schema, and also
for the entire schema.
Conformance specifies not only whether to object must be supported,
but also the level of access, read versus write for example, that is
minimally required
Chisholm, et al. Expires August 28, 2008 [Page 15]
Internet-Draft XML Schema Usage for NETCONF February 2008
2.4.2.1. Fine Grain Conformance
When defining elements, the "minOccurs" and "maxOccurs" tags can be
used to specify whether that object is required to have a compliant
schema. If not specified, minOccurs and maxOccurs both default to a
value of '1'. When defining an attribute, the "use" tag should be
used to define whether the attribute is required. If not specified,
it assumes a value of 'optional'.
2.4.2.2. Operations on Managed Resources
Operations that can be performed on managed resources fall into one
of the following equivalence classes: "Create", "Delete","Read",
"Write", and "Execute".
A value of "create" means it is possible to create new instances of
this element using commands like the NETCONF <edit-config> or <copy-
config> commands. A value of "delete" means it is possible to
destroy instances of this element using commands like the NETCONF
<edit-config> , <copy-config> or <delete-config> operations. A value
of "read" means that it is possible to view values of this element
using commands like the <get-config>, <get> or <event> operations. A
value of "write" means it is possible to modify an instance of this
element using commands like the NETCONF <edit-config> or <copy-
config> commands. A value of "execute" means that there is a side
effect execution such as rebooting that is permissible as a result of
the command. For example, commands like the NETCONF <edit-config> or
a <copy-config> command or the ability to execute a commands like the
<lock>, <unlock> or <kill-session> command.
This memo introduces the optional appinfo annotation of "minAccess"
and and "maxAccess", which contain a non-empty list of values. The
"minAccess" element defines the set of operations that must be
supported in order to claim compliance to this schema. The
"maxAccess" element contains the full set of operations that make
operational sense for this object. If not present, 'minAccess' and
'maxAccess' assume the default access privalges associated with their
information type (configuration, status, statistics).
For example, a status object might have a "minAccess" of "read" but a
"maxAccess" of "read write" to indicate that it must be possible to
perform a get operation the status, but implementations could also
allow configuration operations on it as well. In the case of a
statistic, both the "minAccess" and "maxAccess" might have values of
"read".
<ndl:minAcces> <ndl:read/> </ndl:minAccess>
Chisholm, et al. Expires August 28, 2008 [Page 16]
Internet-Draft XML Schema Usage for NETCONF February 2008
<ndl:maxAcces> <ndl:read/> <ndl:write/> </ndl:maxAccess>
2.4.2.3. Element Status
As a schema evolves, certain elements may become obsolete. Simply
deleting these from the Schema may be acceptable for elements that
did not see implementation, but others will require a strategy to
allow implementers to migrate away from the old elements.
An optional appinfo annotation called "status" SHOULD be used to
provide the status of the element. When not present, it will assume
a value of "current". The other value of this object are
"deprecated" and "obsolete". A value of "deprecated" indicates that
implementations should consider migrating away from this object and
that its implementation is no longer required to be considered
conformant. A value of "obsolete" means the object should not be
implemented. Deprecated and obsolete content is never removed from
the document and its element name can never be re-used.
For example
<ndl:status> current </ndl:status>
2.4.2.4. Additional Conformance Information
Additional information about conformance should be specified using a
documentation tag.
Examples of additional conformance information that may be useful to
provide includes how implementations can specify specific exceptions
to required conformance, dependencies between elements (in order to
do A, you need to first do B) and conditional conformance (if BGP,
then ...).
2.4.2.4.1. Schema Level Conformance - Server Side
In order to claim compliant NETCONF content, all elements MUST
conform to their given minOccurs and maxOccurs definitions and all
elements with a status of "current" and with a minOccurs greater than
or equal to one MUST be supported. In addition, all of the
operations listed by the minAccess attribute MUST be supported.
2.4.2.4.2. Schema Level Conformance - Client Side
Client-side conformance is a method of indicating whether presence of
an object is required in order to be a valid configuration. A new
appInfo annotation is added called mustUse to support this. When
present, this object is required in a valid configuration and when
Chisholm, et al. Expires August 28, 2008 [Page 17]
Internet-Draft XML Schema Usage for NETCONF February 2008
not present, it is optional in a valid configuration. Note that
optional objects may have default values to enable them to have
values in the configuration without being explicitly set by the
client. Note that mustUse elements must also have a minOccurs
greater then zero, ie they can't be optional content from a server-
compliance perspective.
It is also possible to generate using the mustUse annotations a
client-specific XSD against which to do compliance against using
standard tools.
2.4.3. Versioning and Backwards Compatibility
2.4.3.1. Backwards Compatibility
Backwards compatibility means that new versions of an XML Schema that
defines NETCONF Content can be rolled out in a way that does not
break existing supporters.
Changes introduced as a result of an update to an existing
specification of NETCONF content fall into three categories: new
concept are added; existing concepts are changed; or existing
concepts are obsoleted. Adding new optional content or adding
optional new content to the content of a component, such as a new
enumeration in a list, are changes that maintain backwards
compatibility. Changing the meaning or semantics of existing
content, except as allowed by element definition, is not permitted.
Restricting the content of an existing component, or adding or
removing required components are also changes that do not maintain
backwards compatibility.
Permitted Changes
o adding optional elements
o deprecating or obsoleting element
o Some modifications to elements
* Adding new values to enumerations
* Adding new child elements
* Extensions and modifications to definitions where not precluded
by the original definition
Note that while it is permissible to add new mandatory content, this
has implications on backwards and forwards compatibility so is
Chisholm, et al. Expires August 28, 2008 [Page 18]
Internet-Draft XML Schema Usage for NETCONF February 2008
therefore discouraged when other options are available, such as
adding optional content with default values.
The following changes are not backwards compatible
o Removing objects (note they can be deprecated or obsoleted)
o Reusing elements names
o Changing data types of elements, except where the original
definition did not preclude this
o Changing keys
If an update to an XML Schema is backwards compatible, then it must
use the same element name. A new element name must be used when
backwards compatibility is not possible.
2.4.3.2. Versioning
Each version of a schema needs to be complete, not a delta from the
previous version.
The XML Schema version attribute must be used to signify version
For example:
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
version="3.1">
<xs:element name="Foo">
</xs:element>
</xs:schema>
This allows applications to be aware of XML Schema versions, and
changes to XML Schema version, without forcing instance documents to
change to a new schema if the new schema is backwards compatible.
2.4.4. Keys and Relationships
2.4.4.1. Keys
Keys are a mandatory construct for specifying the attributes or
element or set of attributes or element that uniquely identifies an
instance of a managed object. The XML Schema 'key' construct is used
to specify keys. This construct has a name and contains a selector
and one or more fields. The selector identifies the set of nodes to
which the constraint applies, which for this solution is the Managed
Chisholm, et al. Expires August 28, 2008 [Page 19]
Internet-Draft XML Schema Usage for NETCONF February 2008
Resource. The one or more fields identify the particular elements or
attributes within the Managed Resource that define the key. Elements
or attributes defined in a key can not be optional.
Note that since this solution uses a keyref definition with a broader
scope then the traditional XML Schema keyref, the key can be defined
inline in the definition of the Managed Resource.
The following defines a key for the subnet Managed Resource. They
key in this case consists of two fields - network and prefix-length.
<xs:key name="subnet_key_">
<xs:selector xpath=".//subnet"/>
<xs:field xpath="network"/>
<xs:field xpath="prefix-length"/>
</xs:key>
Note that using keys does not preclude being able to filter on
arbitrary pieces of information to provides multiple views of the
managed resource.
2.4.4.2. Defining Relationships (References)
2.4.4.2.1. Association Relationship
The easiest way to define an association relationship is using
containment. It is not always possible or desirable though to model
all associations via containment. Managed resources are often
associated with more than one other managed object and containment
within both might cause confusion and certainly causes extra XML to
be generated. In addition, in some associations, it might not be
obvious to decide which objects is contained in which object. And
finally, it may be more workable to break the definition of managed
resources into smaller, related pieces of XML Schema.
While XML Schema does provide a 'keyref' which could be used, in
theory, to define references to the important relationships of a
Managed Resource, in practice it has some serious limitations around
the scope of what a keyref can point to that make it an impractical
solution for use in defining NETCONF content.
This solution therefore introduces a dataType called 'keyref' with
similar syntax to the XML Schema keyref, but without the scoping
issues. The name uniquely defines the relationship within the scope
Chisholm, et al. Expires August 28, 2008 [Page 20]
Internet-Draft XML Schema Usage for NETCONF February 2008
of the Managed Resource. It points to the definition of the key of
the Managed Resource involved in the relationship. It is helpful the
name meaningfully describes the nature of the relationship, such as
'fooRunsOnPort'. The refer attribute points to the key constraint by
its name, qualified if it is found in another namespace. >The element
that is associated with the keyref must use the 'keyref' datatype.
This date types contains information about the key of the Managed
Resource being pointed to as well as the particular instance
information relevant in this case. The value field is mandatory, but
repeating the key information, which is retrievable from the appInfo
'keyref' annotation is optional. The values for name and field are
defined in the Schema using an appInfo extension.
<xs:complexType name="KeyrefType">
<xs:sequence>
<xs:element name="selector" minOccurs="0"/>
<xs:sequence maxOccurs="unbounded">
<xs:element name="field" minOccurs="0"/>
<xs:element name="value"/>
</xs:sequence>
</xs:sequence>
</xs:complexType>
This construct allows for the value of the instance of the reference
to be Sent over the wire and optionally for the value of key of the
Managed Resource to also be sent.
2.4.5. Defining Notification Event Messages
NETCONF provides a mechanism to send asynchronously event
notifications [NETCONF-EVENT]. The protocol specification makes few
restrictions on the content or source of NETCONF notifications. The
only requirement is that the all notifications contain the
<eventTime> element. The additional content which will be sent
asynchronously via NETCONF notifications must be clearly identified
within the XML Schema so that NETCONF clients will know what
behaviour to expect.
In order to encourage that all notifications contain a core set of
necessary information, this proposal defines an extension of the
NotificationContent element which defines additional fields, namely
event class and the resource experiencing the event.. Individual
event record definitions then use this definition to define more
specialized notifications
Chisholm, et al. Expires August 28, 2008 [Page 21]
Internet-Draft XML Schema Usage for NETCONF February 2008
<xs:complexType name="FooNotificationType">
<xs:complexContent>
<xs:extension base="ndl:EventRecordContentType"/>
additional content
</xs:complexContent>
</xs:complexType>
2.4.5.1. Notifiations with Content Definition Reuse
In defining NETCONF Notifications it is helpful to be able to
leverage as much as possible to definitions of Managed Resources and
data that has already been created to support other NETCONF
operations. This not only includes the individual data elements that
have been defined, but large groupings of data. To be able to point
a Notification at a complexType that defines content means that as
the complexType is updated, so automatically is the Notification
content. The following demonstrates how this can be done
<xs:complexType name="dhcpNotificationType">
<xs:complexContent>
<xs:extension base="ncEvent:NotificationContentType">
<xs:sequence>
<xs:element name="dhcp" type="dhcp"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="dhcpStartUp"
type="dhcpNotificationType"
substitutionGroup="ncEvent:notificationContent">
<xs:annotation>
<xs:documentation>
This notification is sent when dhcp starts up.
</xs:documentation>
</xs:annotation>
</xs:element>
2.4.5.2. Event Classification
Event Notifications will be defined in XML Schema with an appinfo of
'eventClasses' used to identify the type of event An event belongs to
one or more classes. The initial set of classes is fault,
Chisholm, et al. Expires August 28, 2008 [Page 22]
Internet-Draft XML Schema Usage for NETCONF February 2008
information, state, audit, configuration, data, maintenance, metrics,
security and heartbeat. A fault event message is generated when a
fault condition (error or warning) occurs. An Information event is
something that happens of interest which is within the expected
operational behaviour and not otherwise covered by another class. A
state event indicates a change from one state to another, where a
state is a condition or stage in the existence of a managed entity.
Audit events provide notification of very specific actions within a
managed device. In isolation an audit event provides very limited
data. A collection of audit information forms an audit trail. A
configuration event, alternatively known as an inventory event, is
used to notify that hardware, software, or a service has been added/
changed/removed. A data dump event is an asynchronous event
containing information about a system, its configuration, state, etc.
A maintenance event signals the beginning, process or end of an
action either generated by a manual or automated maintenance action.
A metrics event contains a metric or a collection of metrics. This
includes performance metrics. A heart beat event is sent
periodically to enable testing that the communications channel is
still functional.
The eventClass is specified in the appInfo of the notification
definition and also sent over the wire. In order to be sent over the
wire, it needs to be explicitly defined as part of the notification
content.
2.4.6. Error Messages
Within NETCONF, the <error-app-tag> element is used to provide
application-level error codes. If implementations don't understand
the application-level specific error codes, they still have the
generic one to go by, but the application-level specific error codes
can provide information about the specific problem that has happened.
A non-exhaustive set of error messages that may get generated by the
application as a result of performing NETCONF operations against that
data model should be included within the XML Schema that defines the
NETCONF content for this Managed Resource.
Chisholm, et al. Expires August 28, 2008 [Page 23]
Internet-Draft XML Schema Usage for NETCONF February 2008
An optional appinfo called 'appErrors ' is used to specify these
application-level error messages.
<ndl:appErrors>
<ndl:appError>
DHCP is not running.
</ndl:appError>
</ndl>appErrors>
These are applicable to any element.
[Editor's Note: The definition of the appErrors appinfo could in
theory be made richer than it is, so long as the information still
goes over the wire as specified in the base NETCONF specification.
We could specify which of the operation equivalence classes can
trigger this message (read, for example) as well as any additional
fields that should get reported in the message. Note that we can't
mix content on the wire, so any additional fields would need to be
embedded - "I can't reach 1.2.3.4" as appose to "I can't read
<ip>1.2.3.4</ip>". ]
2.4.7. Schema Documentation
The "documentation" tag must be used to provide all additional
information to implementers and users of a schema that can not be
modelled within the schema itself or using the appinfo defined within
this memo. This includes further restrictions and additional
complexities as well as any information that will be helpful in
understanding the element.
Note that other means of documenting, including the <!-- -->
construct are not as easily associated within specific elements and
not necessarily understood by all tools. The "documentation" tags,
which can be associated with specific Managed Resources are generally
preferred.
2.4.8. Specifying Operational and Configuration Information
There is value in being able to easily distinguish between
configuration and operational information within a data model. This
would allow better understanding of the nature of each piece of
information without requiring specific knowledge of the context. It
also makes it easier to support the <get-config> operation since it
is then easy to tell which information is in fact part of the
configuration.
Chisholm, et al. Expires August 28, 2008 [Page 24]
Internet-Draft XML Schema Usage for NETCONF February 2008
This memo adds an optional appinfo called infoType which takes a
value of 'configuration' or 'operational'.
Unless explicitly stated using a minAccess and maxAccess clause,
configurtaion data has a minAccess of read and write and a maxAccess
of read, write, create and delete. Unless explicitly stated
otherwise, operational data has a and a maxAccess of read.
For example
<ndl:infoType>configuration</ndl:infoType>
2.4.9. Defaults
2.4.9.1. Schema-Level Defaults
Default values are defined within the solution using an optional
appInfo annotation of 'default'. Default values once defined can not
be removed or modified between versions. Default values show up in
the canonicalized version of the instance data
<ndl:default>3600</ndl:default>
2.4.9.2. Implementation-Level Defaults
The "default" appInfo annotation defines a set of default values that
is tied to the schema implementation. These defaults will be the
same for all implementations of the schema across different products
and different versions. Implementations themselves tend to have a
set of default values which differ from this schema-level default.
This second type, an implementation default, differs between
different implementations and between different versions of the same
product as appropriate. In fact different implementations may have
different sets of elements for which they have defined default
values.
Implementation defaults are an important feature to be able to
maintain backwards compatibility. It allows for new elements to be
added to a schema in a way that clients not familiar with the new
elements can continue to send their older <edit-config> commands and
still successfully change the configuration. In addition, given the
static nature of schema-level defaults, they will rarely be used, so
implementation defaults fill this gap.
Given the volatility of default values and the fact that
implementation may not have control over the schema that define the
Chisholm, et al. Expires August 28, 2008 [Page 25]
Internet-Draft XML Schema Usage for NETCONF February 2008
elements for which they are defining implementation defaults (i.e.,
they might be defined by the IETF), some other method is required to
learn implementation-level defaults. This area is for further study.
2.4.10. Constraints
2.4.10.1. Schema-level Constraints
Scehma-level constraints define limitations on range of values that
an element can take. Once defined they cannot be made more
restrictive, but can be opened up to include additional values.
Constraints can be expressed in the form of enumerations in lists and
other appliations of the 'restriction' keyword. The restriction
element has the following facets - minInclusive, maxInclusive,
minExclusive, maxExclusive, length, minLength, maxLength,
totalDigits, fractionDigits, whiteSpace, enumeration and pattern.
These allow you to restrict the value of an element to a particular
range, to restrict the length of an element, specify an explicit list
of valid values or do use regular expression to restrict the values.
In addition, note that [Schematron] can be used embedded in XML
Schema using appInfo annotations. See the [CANMOD-DSDML] proposal
for more information of how Schematron an be used to provide
additional constraints on data.
2.4.10.2. Implementation-level Constraints
Similar to default values, implementations may have their own
specific constraints on the configuration data and similar to
defaults, this may change from implementation to implementation and
from release to release. It is critical for NETCONF clients wishing
to do their own preliminary validation of configuration before
sending the request to the NETCONF server to be able to dynamically
learn about implementation-level constraints. This area is for
further study.
2.4.11. Information about the Model Definition
Information about the model definition, such as author and revision
history should be provided in accordance to the Dublin Core standard.
2.4.12. Units
An appInfo tag of 'units' is defined to specify the units of an
element.
Chisholm, et al. Expires August 28, 2008 [Page 26]
Internet-Draft XML Schema Usage for NETCONF February 2008
2.4.13. Modelling Considerations
2.4.13.1. Modularity
It is better to publish NETCONF content as a series of XML Schema
files rather then as a single monolithic XML Schema File [XSD].
2.4.13.2. Data Types
XML Schema has 44 built in data types [XML-SCHEMA-2]. Potentially
reusable data types should be declared as simple or complex type,
rather than element.
Emphasis should be replaced on creating reusable application-level
data types such as IP addresses, DateAndTime or OSI states, rather
than developing 20 different flavours of integers.
This solution proposed creating a core set of data types that will be
common to many different Managed Resources and made them available
for use in individual Schema definitions. A good example is the set
of definitions provided by the [NETCONF-Datatypes] work.
In addition, using types instead of declaring everything to be an
element aids extensibility. An example of where this was done is in
the NETCONF Notification [NETCONF-EVENT] draft in the Notification
Management Schema with the <Netconf> root element.
2.4.13.3. Elements and Attributes
When designing encoding rules for NETCONF content, the following
guidelines should be used to determine when use of elements is
appropriate and when using of attributes is.
Attributes should contain metadata about the element, not true data.
Therefore, information about the managed entity should not be encoded
in attributes.
Attributes are unordered, can appear only once, and can have no
children. When modelling data in an XML Schema, it is important to
leave room for future expansion - in future specifications or future
software releases. This is why it is important to only use
attributes for metadata.
Chisholm, et al. Expires August 28, 2008 [Page 27]
Internet-Draft XML Schema Usage for NETCONF February 2008
2.4.13.4. Proper Tag Names
When choosing element names, they should:
o use ASCII (7-bit)
o be lower camel, a method of writing compound words or phrases
where the words are joined without spaces, and each word is
capitalized within the compound. The first letter of the compound
is lower case. An example would be lowerCamel.
o Whenever possible, use full words. There are some well-known
abbreviations and short forms, such as "config" that would be
considered acceptable
o Should be consistent with existing vocabularies
These are guidelines only and should be considered secondary to the
need for consistency with existing vocabularies. For example, when
encoding SNMP MIB variables names in NETCONF, use the existing names
(ifAddr) instead of shifting to these guidelines (ifAddress). These
guidelines are valuable when no common vocabulary exists, because
they help to avoid the scenario in which a dozen developers choose a
dozen names that differ in ways that lead to frustrating
inconsistencies, such as ifaddr, if-addr, if-address, interface-
address, intf-addr, iaddr, and iface-addr.
2.4.14. Avoid Mixed Content
Mixed content is defined as elements that can contain both data and
other elements. Elements in NETCONF can contain either data or
additional elements only. They must not contain both.
This greatly simplifies the complexity of parsing XML, especially in
the area of significant whitespace. Whitespace inside data elements
is significant. Whitespace outside data elements is not.
<valid>
<element>data</element>
<more>data</more>
</valid>
<not-valid>
<element>data<more>data</more>maybe some</element>
</not-valid>
Chisholm, et al. Expires August 28, 2008 [Page 28]
Internet-Draft XML Schema Usage for NETCONF February 2008
2.4.15. Ease of Parsing
NETCONF content can affect the efficiency and robustness of parsing
routines in two ways. The first has to do with whether anything
within the NETCONF content could be confused with any aspect of the
operations, RPC or application protocol layers. If this is possible,
then more careful routines need to be written. In particular, it
might be difficult to separate out an implementation into separate
methods to parse these different layers if it is necessary to parse
the NETCONF content and match open and close brackets rather than
just looking for an appropriate close tag.
Another aspect where the content will affect performance of the
parsing routines is on the assumptions that the parsing routine can
make. The following section outlines some restrictions on the
NETCONF content that will positively impact the performance of
parsing routines with minimum impact on the usability of the
solution.
2.4.15.1. Well-formed XML
All XML used as NETCONF content needs to be well formed [XML] and
conform to an XML Schema specification that conforms to the
guidelines in this document.
Chisholm, et al. Expires August 28, 2008 [Page 29]
Internet-Draft XML Schema Usage for NETCONF February 2008
3. XML Schema for appInfo Annotations
[This needs to be extended to include additional fields]
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns="urn:ietf:params:xml:ns:netmod:base:1.0"
targetNamespace="urn:ietf:params:xml:ns:netmod:base"
elementFormDefault="qualified"
attributeFormDefault="unqualified" version="0.1" >
<xs:complexType name="AppInfo">
<xs:annotation>
<xs:documentation>
This is a set of information that can be
applied to any
element.
</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element name="minAccess" type="AccessList"/>
<xs:element name="maxAccess" type="AccessList"/>
<xs:element name="status" type="Status"
minOccurs="0"/>
<xs:element name="appErrors" type="AppErrors"
minOccurs="0"/>
<xs:element name="eventClasses" type="EventClasses"
minOccurs="0" />
</xs:sequence>
</xs:complexType>
<xs:element name="appInfo" type="AppInfo"/>
<xs:simpleType name="Status">
<xs:restriction base="xs:string">
<xs:enumeration value="current"/>
<xs:enumeration value="deprecated"/>
<xs:enumeration value="obsolete"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="AccessList">
<xs:sequence>
<xs:element ref="Access" maxOccurs="unbounded"/>
Chisholm, et al. Expires August 28, 2008 [Page 30]
Internet-Draft XML Schema Usage for NETCONF February 2008
</xs:sequence>
</xs:complexType>
<xs:complexType name="AccessType"/>
<xs:element name="Access"
type="AccessType" abstract="true"/>
<xs:element name="read" type="AccessType"
substitutionGroup="Access"/>
<xs:element name="write" type="AccessType"
substitutionGroup="Access"/>
<xs:element name="create" type="AccessType"
substitutionGroup="Access"/>
<xs:element name="delete" type="AccessType"
substitutionGroup="Access"/>
<xs:element name="execute" type="AccessType"
substitutionGroup="Access"/>
<xs:complexType name="AppErrors">
<xs:sequence>
<xs:element name="appError"
type="xs:string" maxOccurs="unbounded" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="EventClassType"/>
<xs:element name="EventClass"
type="EventClassType" abstract="true"/>
<xs:element name="fault" type="EventClassType"
substitutionGroup="EventClass"/>
<xs:element name="information" type="EventClassType"
substitutionGroup="EventClass"/>
<xs:element name="state" type="EventClassType"
substitutionGroup="EventClass"/>
<xs:element name="configuration" type="EventClassType"
substitutionGroup="EventClass"/>
<xs:element name="data" type="EventClassType"
substitutionGroup="EventClass"/>
<xs:element name="maintenace" type="EventClassType"
substitutionGroup="EventClass"/>
<xs:element name="metrics" type="EventClassType"
substitutionGroup="EventClass"/>
<xs:element name="security" type="EventClassType"
substitutionGroup="EventClass"/>
<xs:element name="heartbeat" type="EventClassType"
substitutionGroup="EventClass"/>
Chisholm, et al. Expires August 28, 2008 [Page 31]
Internet-Draft XML Schema Usage for NETCONF February 2008
<xs:complexType name="EventClasses">
<xs:sequence>
<xs:element ref="EventClass"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:schema>
Chisholm, et al. Expires August 28, 2008 [Page 32]
Internet-Draft XML Schema Usage for NETCONF February 2008
4. DHCP Example
The following demonstrates managing DHCP, as defined in appendix of
[RCDML-Requirements].
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns="example.org.ns.dhcp:1.0"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:ndl="urn:ietf:params:xml:ns:netmod:base"
targetNamespace="example.org.ns.dhcp:1.0"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:import namespace="urn:ietf:params:xml:ns:netmod:base"
schemaLocation="ndl-base.xsd"/>
<!-- _________________managedResourceDef_______________________ -->
<xs:complexType name="dhcp">
<xs:annotation>
<xs:appinfo>
<ndl:infoType>managedResource</ndl:infoType>
</xs:appinfo>
</xs:annotation>
<xs:sequence>
<xs:element name="subnets">
<xs:complexType>
<xs:sequence>
<xs:element ref="subnet" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="shared-networks">
<xs:complexType>
<xs:sequence>
<xs:element ref="shared-network" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="default-lease-time" type="xs:int"/>
<xs:element name="max-lease-time" type="xs:int"/>
</xs:sequence>
</xs:complexType>
<xs:element name="dhcp" type="dhcp"/>
<xs:complexType name="subnet">
Chisholm, et al. Expires August 28, 2008 [Page 33]
Internet-Draft XML Schema Usage for NETCONF February 2008
<xs:annotation>
<xs:appinfo>
<ndl:infoType>managedResource</ndl:infoType>
</xs:appinfo>
</xs:annotation>
<xs:sequence>
<xs:element name="network" type="ndl:ipAddress"/>
<xs:element name="prefix-length" type="xs:int"/>
<xs:element name="leases" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:element ref="lease" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element ref="range" minOccurs="0"/>
<xs:element ref="dhcp-options" minOccurs="0"/>
<xs:element name="max-lease-time" type="xs:int"
minOccurs="0"/>
<xs:element ref="interface-filter" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:element name="subnet" type="subnet">
<xs:key name="subnet_key_">
<xs:selector xpath=".//subnet"/>
<xs:field xpath="network"/>
<xs:field xpath="prefix-length"/>
</xs:key>
</xs:element>
<xs:complexType name="lease">
<xs:annotation>
<xs:appinfo>
<ndl:infoType>managedResource</ndl:infoType>
<ndl:maxAccess>
<ndl:read/>
</ndl:maxAccess>
</xs:appinfo>
</xs:annotation>
<xs:sequence>
<xs:element name="ip-address" type="xs:string"/>
<xs:element name="starts" type="xs:dateTime"/>
<xs:element name="ends" type="xs:dateTime"/>
<xs:element name="mac-address" type="ndl:nsapAddress"/>
</xs:sequence>
</xs:complexType>
<xs:element name="lease" type="lease">
<xs:key name="lease_key_">
Chisholm, et al. Expires August 28, 2008 [Page 34]
Internet-Draft XML Schema Usage for NETCONF February 2008
<xs:selector xpath=".//lease"/>
<xs:field xpath="ip-address"/>
</xs:key>
</xs:element>
<xs:complexType name="shared-network">
<xs:annotation>
<xs:appinfo>
<ndl:infoType>managedResource</ndl:infoType>
</xs:appinfo>
</xs:annotation>
<xs:sequence>
<xs:element name="name" type="xs:string"/>
<xs:element name="subnets">
<xs:complexType>
<xs:sequence>
<xs:element ref="subnet" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:element name="shared-network" type="shared-network">
<xs:key name="shared-network_key_">
<xs:selector xpath=".//name"/>
<xs:field xpath="shared-network"/>
</xs:key>
</xs:element>
<!-- ______________________configDataDef_____________________ -->
<xs:complexType name="range">
<xs:annotation>
<xs:appinfo>
<ndl:infoType>configData</ndl:infoType>
</xs:appinfo>
</xs:annotation>
<xs:sequence>
<xs:element name="dynamic-bootp" type="xs:boolean"
minOccurs="0"/>
<xs:element name="low" type="ndl:ipAddress" minOccurs="0"/>
<xs:element name="high" type="ndl:ipAddress" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:element name="range" type="range"/>
<xs:complexType name="dhcp-options">
<xs:annotation>
<xs:appinfo>
Chisholm, et al. Expires August 28, 2008 [Page 35]
Internet-Draft XML Schema Usage for NETCONF February 2008
<ndl:infoType>configData</ndl:infoType>
</xs:appinfo>
</xs:annotation>
<xs:sequence>
<xs:element name="router-list" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:element name="router"
type="ndl:ipAddress" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="domain-list" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:element name="domain" type="xs:string"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="custom-list" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:element name="custom"
type="CustomOptionType"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:element name="dhcp-options" type="dhcp-options"/>
<xs:complexType name="interface-filter">
<xs:annotation>
<xs:appinfo>
<ndl:infoType>configData</ndl:infoType>
</xs:appinfo>
</xs:annotation>
<xs:sequence>
<xs:element name="interface-list" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:element name="interface" type="xs:string"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
Chisholm, et al. Expires August 28, 2008 [Page 36]
Internet-Draft XML Schema Usage for NETCONF February 2008
</xs:sequence>
</xs:complexType>
<xs:element name="interface-filter" type="interface-filter"/>
<!-- _________________________typeDef_________________________ -->
<xs:complexType name="CustomOptionType">
<xs:annotation>
<xs:appinfo>
<ndl:infoType>complexType</ndl:infoType>
</xs:appinfo>
</xs:annotation>
<xs:sequence>
<xs:element name="option" type="OptionEnumType"/>
<xs:element name="custom-value"
type="IpAddressOrStringType"/>
</xs:sequence>
</xs:complexType>
<xs:simpleType name="OptionEnumType">
<xs:restriction base="xs:string">
<xs:enumeration value="150"/>
<xs:enumeration value="171"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="IpAddressOrStringType">
<xs:annotation>
<xs:appinfo>
<ndl:infoType>complexType</ndl:infoType>
</xs:appinfo>
</xs:annotation>
<xs:choice>
<xs:element name="ip-address" type="ndl:ipAddress"/>
<xs:element name="string" type="xs:string"/>
</xs:choice>
</xs:complexType>
</xs:schema>
Chisholm, et al. Expires August 28, 2008 [Page 37]
Internet-Draft XML Schema Usage for NETCONF February 2008
5. XML-based Syntax Data definition
Although XML Schema can be written by hand, there are also benefits
of defining the models first in a more abstracted XML-based syntax
and using this To generated the XML Schema as shown in Figure 3.
Using an XML-based syntax, also known as the Netconf data definition,
as opposed to a one-of syntax allows tool developers to take
advantage of standard XML tools and libraries to manipulate the
model. It also allows model definitions to be validated using
standard tools. Making the language more abstract and potentially
more specific to a given implementation has the potential to simplify
the definition for the model developers. It also may allow for
generation of non-NETCONF content such as CLI commands. The key to
the usefulness of these sort of languages is to not merely trade one
syntax for another, but to add value my legitimately simplifying
model definition.
The syntax uses in this XML-based language should be defined in XML
Schema. This allows the features of the language to validated using
standard tools and aids in helping people understand the language.
The XML syntax used here includes constructs to express each of the
artifacts of the embedded meta-model introduced earlier in
Section 1.2
A Netconf Data Definition defines either an implementation package or
a library package. It is labeled as such in the Data definition's
header information.
Data definitions contain definitions for Managed Resources,
Configuration Data, Operational Data, Event Reports, and Type
Definitions.
Managed Resource definitions contain definitions for key attributes
used to identify instances of the Managed Resource; of references
used to describe relationships of instances of the Managed Resource;
of Configuration Data and of Operational Data that the Managed
Resource is composed of; of Actions that are associated with the
Managed Resource.
Configuration Data definitions contain definitions of Managed
Resource properties (referred to as "attributes") that correspond to
parameters of the underlying managed entity that can be subjected to
configuration by a management application.
Operational Data definitions contain definitions of Managed Resource
properties (referred to as "attributes") that correspond to state,
statistical counters, and other properties of the Managed Resource
Chisholm, et al. Expires August 28, 2008 [Page 38]
Internet-Draft XML Schema Usage for NETCONF February 2008
that cannot be altered by a management applications but are subject
to monitoring by a management application.
References contain definitions of relationships, as seen from the
containing Managed Resources. Different types of relationships are
possible: Parent-child relationships represent hierarchical
relationships. Note that while in an Netconf Data Definition, parent
and child managed resources will be defined separate of one another,
in an Server-XML document instance data of the child managed resource
will be nested within the XML of the parent managed resource. On the
other hand, peer relationships represent relationships between
Managed Resources which are otherwise independent. Either way, the
auto- generated XML Schema will represent this relationship as
appropriate.
Key attributes, configuration data and operational data attributes,
and references all can be subjected to unconditional and conditional
value and size constraints.
5.1. Conformance Information
NETCONF Data Definition implementation packages specify exactly the
model that is implemented by a managed entity. NETCONF data
definition implementation packages map into corresponding XML schema
definitions. This means that when a NETCONF Data Definition
implementation package is defined, it effectively double as a
conformance statement. There is no need to specify, for example, a
separate capability file, which would only duplicate the information
already provided as part of the data definition implementation
package.
5.2. Library and Implementation Packages
The document that defines an NETCONF data definition is also referred
to as an NETCONF data definition package. There are two different
categories of NETCONF data definition packages:
o NETCONF data definition implementation packages define the actual
instrumentation provided by a NETCONF server. They specify
exactly what management information is and is not provided.
o NETCONF data definition library packages contain NETCONF data
definition definitions that are intended for reuse. They provide
"building blocks" that NETCONF data definition implementation
packages can pick and choose from to build an NETCONF data
definition for a particular managed resource. NETCONF data
definition library packages will in general not be tied to any
particular implementation; instead they provide the common
Chisholm, et al. Expires August 28, 2008 [Page 39]
Internet-Draft XML Schema Usage for NETCONF February 2008
denominator that is to be reused across systems. NETCONF data
definition Library Packages and the inherent model they represent
therefore play a fundamental role in achieving consistency of
management instrumentation of different managed systems. NETCONF
data definitions that are standardized by IETF accordingly
constitute library packages.
Within a NETCONF data definition package (whether library or
implementation package), configuration data definitions and
operational data definitions can be provided "out-of-line" so that
they can simply be included in the managed resource type and
interface definitions by reference.
Managed Resource definitions in NETCONF data definition library
packages can extend other Managed Resource definitions in (the same
or other) NETCONF data definition library packages. The extending
Managed Resource does not reiterate the properties of extended
Managed Resource. Instead, it merely adds new extensions to the
Managed Resource. The extending Managed Resource can include new
properties, such as additional Configuration and/or Operational Data
Definitions.
Managed Resource definitions in NETCONF data definition
implementation packages implement Managed Resource definitions from
Library Packages. The Managed Resource definition must reiterate the
definition of the Managed Resource definition that it implements, and
may restrict the Managed Resource definition along the way (by adding
constraints, or by adding new data definitions). This way, the
Managed Resource definition in a NETCONF data definition
implementation package constitutes at the same time a glorified
compliance statement. It is not necessary to provide such a
statement separately.
It should be noted that specification reuse falls short of fully
object-oriented inheritance capabilities in the following ways:
A Managed Resource definition may only extend or implement one
other Managed Resource definition. "Multiple Inheritance" is not
allowed. (However, it is possible for Managed Resource
definitions to include several configuration and operational data
definitions.)
Library packages are not allowed to restrict managed resource,
configuration data, and operational data definitions. They are
only allowed to extend them.
The purpose of these restrictions is to keep the NETCONF data
definition artifacts simple to use with straightforward semantics
Chisholm, et al. Expires August 28, 2008 [Page 40]
Internet-Draft XML Schema Usage for NETCONF February 2008
and, while encouraging reuse, encouraging models that are essentially
component-based (with base components being operational and
configuration data definitions) and discouraging models that exhibit
deep model/nesting hierarchies which become unwieldy to use.
5.3. Translating to XML Schema
A translation from a NETCONF data definition to an XML schema can
occur according to a set of straightforward mapping rules. It is
possible to automate this translation.
The detailed mapping rules will be provided in a future revision of
this Internet Draft.
Chisholm, et al. Expires August 28, 2008 [Page 41]
Internet-Draft XML Schema Usage for NETCONF February 2008
6. How this approach meets RCDML Requirements
This section outlines how using a Metamodel and XML Schema can be
used to meet the requirements outlined in the [RCDML-Requirements] as
defined by the RCDML design team. For the reader's convenience, the
requirement is repeated from the RCDML document, followed by the
discussion of how the requirements are met, or if appropriate why a
requirement was not met.
6.1. REQ#3.1. Consequences of NETCONF
6.1.1. 3.1.1. Notification Definition (Agreed)
RCDML: The solution MUST support defining notifications. The
solution MUST describe any transformations or adaptations necessary
to transport notifications using the mechanisms defined in [I-D.ietf-
netconf-notification].
See Section 2.4.5 for more information on Notification strategy
within this solution. The solution supports the definition of
notifications in the same method defined in the NETCONF Event
Notification draft. Model developers define extensions to
NotificationContent elements. In addition, model developers can
define extensions to the eventReport element, which defines
additional standard content for Notifications.
6.1.2. REQ#3.1.2. Notification Get (NOT Agreed)
RCDML:The solution MAY support defining notifications in a way that
minimizes duplication of definitions for polled or configured
content.
See Section 2.4.5 for more information on Notification strategy
within this solution. To support content that is only sent via
notifications, the elements defining the data can be defined in-line
in the Notification definition. To support using the same data
definitions but using a separate wrapper, the Notification definition
can reference (using the 'ref=' syntax) existing data definitions.
To reuse collections of existing parameters, the Notification can
point to the complexType in which they were defined or use a
reference to point at the container itself, as oppose to the
individual elements. This ensure that additions to the polled
content automatically show up in the Notification.
6.1.3. REQ#3.1.3. Locking (Agreed)
RCDML:The solution MUST NOT preclude fine grained locking, as
described for the NETCONF environment in the work-in-progress
Chisholm, et al. Expires August 28, 2008 [Page 42]
Internet-Draft XML Schema Usage for NETCONF February 2008
[I-D.ietf-netconf-partial-lock].
This solution does not preclude the fine-grain locking mechanisms.
That approach primarily is built using XPath and it is well-
understood how to use XPath with XML Schema-based solutions.
6.1.4. REQ#3.1.4. All Base Operations (Agreed)
RCDML: The solution MUST unambiguously describe how all NETCONF
[RFC4741] base operations work with data defined under a model
produced using the solution. This includes both how information
appears on the wire as well as any effects on the configuration data
store.
The edit-config operation can be performed on content whose
minAccess/maxAccess allows creation, modification and deletion and
which a particular implementation has provided supported for these
operations.
Creatable content are elements whose maxAccess clause allows creation
and that exist in an implementation that supports creation of that
element. Writable content are elements whose maxAccess clause allows
writing and that exist in an implementation that supports editing of
that element. Deletable content are elements whose maxAccess clause
allows deleting and that exist in an implementation that supports
deleting of that element. Readable content are elements whose
maxAccess clause allows reading and that exist in an implementation
that supports reading of that element.
The <get-config> operation returns all elements with an infoType
indicating it is configuration data.
The <get> operation returns all elements with of any infoType.
During an edit-config operation using merge, if an element or
attribute is creatable and this object does not exist, it is created.
If it is not creatable, the an error is reported. During a replace,
If the element or attribute is writeable and exists, then all child
nodes not present in the XML that are deletable are deleted, and
child nodes present in the XML but not present in the datastore which
are creatable are created. During a create, the element or attribute
is created if it does not exist, if it is creatable. During a
delete, if the element or attribute is deletable the element is
deleted if it exists. An attempt to create, modify or delete
elements or child elements when these operations are not supported
will result in an error.
The copy-config operations replaces one configuration with another.
Chisholm, et al. Expires August 28, 2008 [Page 43]
Internet-Draft XML Schema Usage for NETCONF February 2008
The access writes of the individual managed resources and data
elements involved in the configuration are not taken into account.
The delete-config operation deletes an entire configuration
datastore. Likewise, the access writes of the individual managed
resources and data elements involved in the configuration are not
taken into account.
Read-only data should not itself be included in an edit-config
operation, but may be included when an operation is performed on a
containing element with sufficient privileges. These elements get
created when their containing element is created and deleted when
their containing element is deleted.
The <lock>, <unlock>, <close-session> and <kill-session> operations
are not impacted by this solution.
6.1.5. REQ#3.1.5. Define new NETCONF Operations (Agreed)
RCDML: The solution MUST provide a means to define new NETCONF
operations and their parameters (base, vendor extensions, and so on)
in the same language as is used for defining models.
NETCONF operations to date have been defined using XML Schema and
this solutions does not changes that. Some, but perhaps not all, of
the annotations defined in the memo might provide additional machine-
readable information about protocol operations and their parameters,
which would be useful in improving interoperability and supporting
the evolution of the operations. For example, it might be helpful to
be able to deprecate parameters to an operation.
The separation between operations and data is a fundamental guiding
principle in the design of management interfaces and also implied by
the Netconf architecture itself and this solutions supports that by
defining content and operations in different parts of the namespace
and in different schemas.
6.1.6. REQ#3.1.6. Separation of Operations and Payload (Agreed)
RCDML:The solution MUST unambiguously describe how all NETCONF
[RFC4741] base operations work with data defined under a model
produced using the solution. This includes both how information
appears on the wire as well as any effects on the configuration data
store.
This is described above related to requirement 3.1.4.
Chisholm, et al. Expires August 28, 2008 [Page 44]
Internet-Draft XML Schema Usage for NETCONF February 2008
6.1.7. REQ#3.1.7. Error Annotation (Agreed)
RCDML: The solution MUST be able to define specific error messages
for a given element. Note that this could interact with support for
internationalization and localization. The solution MUST describe
how specific error strings are associated with error conditions as
required by the NETCONF protocol.
This is done via the error annotation described in Section 2.4.6.
6.1.8. REQ#3.1.8. No Mixed Content (Agreed)
RCDML: The solution MUST prevent mixed content, i.e., tags and data
mixed together as part of a value, other than to treat it as opaque
information. This requirement is a consequence of the NETCONF
protocol environment.
Mixed content is prohibit in this solution by statements made in
section Section 2.4.14m
6.2. REQ#3.2. Model Representation Requirements
6.2.1. REQ#3.2.1. Human Readable (Agreed)
RCDML: The solution MUST support a human-readable representation of
data models. This requirement is independent of how an instance of a
model is represented.
Both data definitions and XML schema definitions are human readable.
In addition, Data Definitions are arguably human friendly.
6.2.2. REQ#3.2.2. Machine Readable (Agreed)
RCDML: The solution MUST support a machine-readable representation of
data models.
Data models are represented using standard XML and XML Schema syntax,
respectively. Machine readability is a given; that combined with
extensive off-the-shelf tooling support can be considered one of the
strengths of this proposal.
6.2.3. REQ#3.2.3. Textual Representation (Agreed)
RCDML: The solution MUST support a text-based representation for
models. It MAY support other representations. It MUST be possible
to represent model definitions as ASCII text in 72 columns so
standard data models can be included in RFCs. This requirement is
independent of how an instance of a model is represented.
Chisholm, et al. Expires August 28, 2008 [Page 45]
Internet-Draft XML Schema Usage for NETCONF February 2008
XML Schema is a textual representation where most, if not all models
can be represented in 72 columns since line feeds can be inserted as
required into the model definition.
6.2.4. REQ#3.2.4. Document Information (Agreed)
RCDML: The solution MUST provide a means to specify document
information for a data model, such as when it was created, its
revision history, point of contact, and so on.
This information can be provided using standard tags at the beginning
of the corresponding XML/XSD documents. These can comply to the
Dublin Core standard.
6.2.5. REQ#3.2.5. Ownership and Change Control (Agreed)
RCDML: It MUST be clear who exercises change control and ownership
over the data modeling framework, e.g., the IETF. This MUST also be
clear for the technologies on which it depends.
This solution is owned by the IETF. It specifies that it is
dependant on XML Schema version 1.0 and XML version 1.0. At some
point in the future the IETF may choose to migrate to a later version
of XML Schema or to include additional technologies into the
solution.
6.2.6. REQ#3.2.6. Dependency Risk Reduction (Agreed)
RCDML: In cases where a proposed solution depends on other
specifications, there MUST be a way to reference the specific
versions required, in case that specification evolves in incompatible
ways. This requirement is motivated by bad experiences with how the
ASN.1 specification mutated after its first version.
This solution is owned by the IETF and it explicitly mentions the
specific versions of technology from other organizations that it is
taking advantage of. It may choose to move or not move to later
versions of these technologies are it feels make sense in the future.
6.2.7. REQ#3.2.7. Diff-Friendly (Agreed)
RCDML: It MUST be possible for an operator using existing tools such
as "diff" to determine what has changed between two versions of a
data model.
XML files being text files, they can be subjected to "diff". In
addition, there is plenty of off-the-shelf- tooling available to
view, process, edit and develop XML and XML Schema files, providing
Chisholm, et al. Expires August 28, 2008 [Page 46]
Internet-Draft XML Schema Usage for NETCONF February 2008
richer comparison capabilities.
6.2.8. REQ#3.2.8. Internationalization and Localization
6.2.8.1. REQ#3.2.8.1. Descriptions using Local Languages (Agreed)
RCDML: The solution MUST be able to support the use of Unicode text
in a model definition to provide human readable descriptions of
information semantics. This is effectively required by [RFC2277].
This is not the same thing as requiring a mechanism for the
internationalization and localization of models, but rather a way of
allowing the model definer to work in his or her preferred language.
The solution includes description elements which allow a model
definer to annotate the model definition with additional information.
UTF-8 is supported (per the following requirement) and therefore so
is Unicode.
6.2.8.2. REQ#3.2.8.2. UTF-8 Encoding (Agreed)
RCDML: It MUST be possible to encode model definitions using UTF-8.
This is effectively required by [RFC2277] as a consequence of the
need for a textual representation and the need to be able to include
descriptive text in the model definer's language of choice.
XML schema and XML instance definitions can be encoded in UTF-8,
hence this proposal meets this requirement.
6.2.8.3. REQ#3.2.8.3. Localization Support (Agreed)
RCDML: The solution MUST outline how localization of an existing
model would proceed. The strong preference of members of the design
team was to treat model localization as a user interface issue. The
solution MUST be in alignment with the guidance given by [RFC2277].
Localization should generally occur at the level of the user
interface, not over-the-wire. At the user interface, it is possible
to provide translations for each information element. Localization
over-the-wire, while possible in principle, makes implementations a
lot more heavy-weight and increases the risk of interoperability
problems.
6.2.8.4. REQ#3.2.8.4. Error String Localization (Agreed)
The solution MUST NOT preclude localization for user display of
NETCONF error strings defined in conjunction with a data model.
(Since the NETCONF protocol itself does not provide for language
negotiation, such localization would presumably take place within the
Chisholm, et al. Expires August 28, 2008 [Page 47]
Internet-Draft XML Schema Usage for NETCONF February 2008
NETCONF client. The question is how to associate an error string
defined as part of a model with its localization.)
This solution recommends that error string localization take place
within the NETCONF client.
6.2.8.5. REQ#3.2.8.5. Tag Names and Strings in Local Languages (NOT
agreed)
The solution MAY support the use of Unicode text for tag names and
strings in definitions. Note that this is not a question of
internationalization and localization, but rather the use of Unicode
for what are effectively protocol elements in an instance document
for a model defined using the solution.
While this is not recommend, substitution groups can be used to
achieve localized tag names.
6.3. REQ#3.3. Reusability Requirements
6.3.1. REQ#3.3.1. Modularity (Agreed)
RCDML: The solution MUST provide a means to define data models in
discrete pieces, and support the publication of portions of models in
separate files.
Different parts of the NETCONF model can be defined in different XML
Schema files.
In addition, the library concept allows model developers to define
configuration data and operational data in "chunks" reusable by
different Managed Resource definitions, allowing for component-based
model definitions. In addition, Managed Resource definitions can to
be organized into library packages, from which they can be extended
by other Managed Resource definitions in the same or a different
package, or implemented by Managed Resource definitions in an
implementation package. The definitions of a managed entity are
instantiated as an implementation package, which reuses and
implements configuration data, operational data, event reports, and
managed resource definitions from library packages.
6.3.2. REQ#3.3.2. Reusable Definitions (Agreed)
RCDML: The solution MUST support a way to reuse definitions from
another model. A type definition is a type of reusable definition.
Note that this potentially interacts with requirements to be able to
revise or extend a model.
Chisholm, et al. Expires August 28, 2008 [Page 48]
Internet-Draft XML Schema Usage for NETCONF February 2008
XML Schema supports reusable definitions with several ways to
leverage existing definitions to define new objects. Chunks of
content can be grouped together into simple and complex types to be
reused in any schema. There is no concept of public and private data
that might limit extensibility to only those items which were thought
to be reusable at design time. Any type definition can be later
reused if it is deemed useful. In addition, elements can be reused
using the 'ref' tag.
6.3.3. REQ#3.3.3. Modular extension (Agreed)
RCDML: It MUST be possible to extend a published data model without
modifying the original data model. Those specifying solutions are
advised to carefully consider how this capability might interact with
the ability to revise definitions and the ability to reference
definitions in other models.
Extensions to existing data elements can be done either in the same
XSD file or in a separate one. The NETCONF protocol definition
demonstrates a powerful way to do extensions using
substitutionGroups. This method allows new protocol operations to be
defined that will validate as proper content within an <rpc> wrapper
without having to modify the base protocol operations.
In addition, new complexTypes and elements can be defined which are
extensions to existing complex types. These new definitions can also
be extended allowing a hierarchy of definitions. For example
productAInterfacesType might be an extension to acmeInterfaceType
which is itself an extension of ietfInterfaceType.
6.4. REQ#3.4. Instance Data Requirements
6.4.1. REQ#3.4.1. Default Values on the Wire (Agreed)
RCDML: The solution MUST specify how default values affect what is
and is not explicitly encoded in an instance document. Possibilities
include a default-free data modeling language, protocol-specific
default handling, or protocol-independent prescribed behavior.
The solution provides the ability for model developers to specify
default values when applicable. Whether these values are retrieved
as a result of a <get>, <get-config> or other operations is a
protocol-specific behaviour and is not prescribed by the solution.
This provides the flexibility for the protocol to support both an
operation which returns elements who currently have the default value
and an operation which does not. It also leaves it up to the
protocol to decide whether or not to present elements who have been
explicitly set to the same value as the default.
Chisholm, et al. Expires August 28, 2008 [Page 49]
Internet-Draft XML Schema Usage for NETCONF February 2008
See Section 2.4.9.2 for more information on defaults.
6.4.2. REQ#3.4.2. Ordering
6.4.2.1. REQ#3.4.2.1. Ordered Lists (Agreed)
RCDML: The solution MUST support the ability to specify whether the
order of list entries in an instance document has semantic
significance, and MUST consequently be preserved. An example of such
a list might be a list of access control rules. An example of a list
where the order would have no semantic significance might be a list
of users. In cases where a list's order would have no semantic
significance, the solution SHOULD nonetheless specify whether order
is maintained, since this would affect instance data
canonicalization.
Order of members of a property whose multiplicity is many (a
collection) type can be specified in using ordered constraint
expression.
6.4.2.2. REQ#3.4.2.2. Order within Containers (NOT Agreed)
RCDML: A solution MAY support the ability to specify that in an
instance of a data model, the order of child elements within a
containing element needs to be preserved, due to semantics, backward
compatibility requirements, or processing efficiency considerations.
Ordering of child elements is achieved using by defining the content
as sequence of elements.
6.4.2.3. REQ#3.4.2.3. Interleaving (NOT Agreed)
RCDML: A solution MAY support the ability for a model to allow
interleaving elements in the XML representation of an instance of a
data model. This means that those child elements MAY appear in any
order on the wire.
Note that unordered data is of most interest in the case of extending
a schema. In this case, although definitions of new content may come
at the end of a list of elements, it might be nicer to be able to
group like elements together in the list.
XML Schema does not provide full native support for unordered lists.
Constructs like the following come close.
Chisholm, et al. Expires August 28, 2008 [Page 50]
Internet-Draft XML Schema Usage for NETCONF February 2008
<xs:element name="unorderedList">
<xs:complexType>
<xs:sequence minOccurs="9" maxOccurs="9">
<xs:choice >
<xs:element name="one"/>
<xs:element name="two"/>
<xs:element name="three"/>
<xs:element name="four"/>
<xs:element name="five"/>
<xs:element name="six"/>
<xs:element name="seven"/>
<xs:element name="eight"/>
<xs:element name="nine"/>
</xs:choice>
</xs:sequence>
</xs:complexType>
</xs:element>
The above definition does not however ensure uniqueness within the
instance elements. To properly achieve an unordered list an appInfo
annotation called 'unordered' should be used with the pattern defined
above.
6.4.3. REQ#3.4.3. Validation
6.4.3.1. REQ#3.4.3.1. Validate Instance Data (Agreed)
RCDML: A solution proposal MUST provide sufficient detail to allow a
determination to be made whether an instance of a data model is well-
formed and valid in terms of the schema, as well as any additional
considerations.
Existing rules to determine whether XML instances are compliant to
XML Schema apply in this case. In addition, the Client-XSD can be
generated to ease validation of on the wire data.
6.4.3.2. REQ#3.4.3.2. Tools to Validate Instance Data (NOT Agreed)
RCDML: A solution MAY provide a means of determining whether an
instance document is a valid instance of a model. (The difference
between the previous requirement and this one is that the former
(agreed) merely requires that a solution is known, while the latter
(not agreed) requires that a solution have been implemented.)
Instance data can be validated against the XML Schema definition of
the content using standard tools.
Chisholm, et al. Expires August 28, 2008 [Page 51]
Internet-Draft XML Schema Usage for NETCONF February 2008
6.4.4. REQ#3.4.4. Instance Canonicalization (Agreed)
RCDML: The solution MUST describe how to produce a canonicalized
version of the instance. This is a transform which can put the data
in a form which is suitable for comparison. See "Canonical XML
Version 1.0" [RFC3076] for more information. This does not imply
that there is any requirement for data on the wire to be sent in
canonicalized form. The design team recognizes that there is a point
of diminishing returns in canonicalizing human-readable strings, and
advises those proposing solutions to consider the trade-offs and not
get carried away.
Since the proposal is XML based, XML canonicalization rules are by
definition automatically applicable. As for canonicalization of
ordering of set-valued data, it is recommended to not prescribe a
particular order in order to not impose unreasonable computation
requirements on implementing Netconf servers. However, if required,
canonicalization rules can be defined even for unordered, multivalued
data, e.g. by imposing a particular order based on order of values or
keys.
6.4.5. REQ#3.4.5. Character Set and Encoding (Agreed)
RCDML: The solution SHOULD support the creation of models which can
handle human-readable information in any language in an instance
document. In keeping with [RFC2277], this means that models MUST be
able to handle UTF-8 data appropriately.
XML supports UTF-8 encoding.
6.4.6. REQ#3.4.6. Model Instance Localization (NOT Agreed)
RCDML: Tags and other human-readable portions of an instance of a
model SHOULD be localizable. Underlying this requirement is the
question of whether tags in an instance document are really "human-
readable" or merely protocol elements. This requirement needs
clarification: is it a question of what an instance document looks
like between a NETCONF client and server, or is it a question of how
an instance document might be transformed for presentation to a user?
We do not agree with this requirement. It is possible to define
models in different languages. However, localizing instance
information, i.e. translating it into different languages, is
something that should occur at the user interface level of NETCONF
clients, not affect instance information that would impede
interoperability, introduce additional elements for negotiation, and
generally make implementations unnecessarily complex, a concern
specifically for the NETCONF server side.
Chisholm, et al. Expires August 28, 2008 [Page 52]
Internet-Draft XML Schema Usage for NETCONF February 2008
6.5. REQ#3.5. Semantic Richness Requirements
6.5.1. REQ#3.5.1. Human-Readable Semantics (Agreed)
RCDML: The solution MUST provide a means for the developer of an
information model to associate human-readable text with components of
that model, in order to describe their semantics and use.
It is possible to add comments describing XML and XML Schema files.
The documentation annotation is used in XML Schema.
6.5.2. REQ#3.5.2. Basic Types (Agreed)
RCDML:The solution MUST define frequently used types. This could be
accomplished in a standard data model definition as part of a
solution or part of the language definition, for example.
As noted in Section 2.4.13.2, XML Schema has a rich set of basic
types that are available. In addition to this, work has already been
done to define a core set of IETF-specific extensions which will be
useful in multiple data model definitions. A good example is the set
of definitions provided by the [NETCONF-Datatypes] work. Additional
datatypes can be added to this list at any time.
6.5.3. REQ#3.5.3. Handling Opaque Data (Agreed)
RCDML:It MUST be possible to perform certain operations on opaque
data. This means that completely replacing the data would be
supported, but not merging, for example. This data potentially does
not conform to any schema definition, but may happen to be well-
formed XML within the opaque data.
The solution supports this by using the any tag so that all data will
pass validation. It is then up to the system to recognize that this
data is meant to be treated opaquely and therefore has a reduced set
of permissions against it. While the solution could in theory define
a way to decompose its current access class of 'edit' into 'replace'
and 'merge', it does not at present.
6.5.4. REQ#3.5.4. Keys
6.5.4.1. 3.5.4.1. Define Keys (Agreed)
RCDML:The solution MUST support defining keys to data (i.e. the list
of fields which uniquely identify an element, or a specially created
identifier like an ifIndex or an XML id.)
The solution uses XML Schema's Keys, as discussed in Section 2.4.4.1.
Chisholm, et al. Expires August 28, 2008 [Page 53]
Internet-Draft XML Schema Usage for NETCONF February 2008
6.5.4.2. REQ#3.5.4.2. Deep Keys (NOT Agreed)
RCDML:The solution SHOULD support using as a key the value of an
element which is not an immediate descendant of the element being
"keyed".
The solution can support this using in its key solution. If all
fields of the key are defined within the same child element of the
Managed Resource, then the selector field would include this child
element in its path. This allows for the definition of arbitrarily
deep keys. Note that this feature is most useful when the child
elements of data type definitions and not contained Managed
Resources. Keying off content in a contain Managed Resource may
point to an underlying modeling issue.
6.5.5. REQ#3.5.5. Relationships
6.5.5.1. REQ#3.5.5.1. Simple Relationships (Agreed)
RCDML: The solution MUST support defining cross references between
elements in different hierarchies. This SHOULD be a formal machine
readable definition rather than the value of an implicitly known
field. The solution SHOULD support defining reference pointers for
both 1:1 and 1:n relationships.
The solution uses a special keyref appInfo as discussed in
Section 2.4.4.2.1. Note that the element for which the keyref is
associated can use its minOccurs and maxOccurs parameters to define
the cardinality of the relationship.
6.5.5.2. REQ#3.5.5.2. Many-to-Many Relationships (NOT Agreed)
RCDML:The solution SHOULD support defining many to many cross
reference relationships.
While from an abstract perspective, objects may have one to many
relationships, in practice these get realized through a series of 1
to many relationships. For example, if multiple interfaces can be
associated with multiple ports, in practice this means that a single
interface is associated with multiple ports, which an be presented by
a 1 to many relationship. Therefore no special syntax is required to
meet this requirement in practice. The ability of a particular
instance of a Managed Resource to be able to express a many to many
relationships is not considered a requirement.
Chisholm, et al. Expires August 28, 2008 [Page 54]
Internet-Draft XML Schema Usage for NETCONF February 2008
6.5.5.3. REQ#3.5.5.3. Retrieve Relationships instance (NOT Agreed)
RCDML:The solution SHOULD support a means of specifying relationships
which can be represented in a configuration or on the wire with
minimal redundancy. Knowledge of the model would be needed to
transform this representation into a fully qualified instance
identifier. The use of an integer interface index in a MIB, rather
than a rowPointer [RFC2579], would be analogous to this capability.
Ideally, the knowledge required to generate the fully qualified
instance identifier would be present in the model in machine-readable
form.
As discussed in the Section 2.4.4.2.1, the keyrefs are associated
with elements. The value of these elements over the wire contains
relationship instance, which can optionally be fully qualified.
6.5.6. REQ#3.5.6. Hierarchical Data
RCDML: The solution MUST support defining data in hierarchies of
arbitrary depth. This enables closer modeling of data to real world
relationships, such as containment.
XML Schema was designed to defined XML content, which is inherently
hierarchical in nature. It is able to model hierarchies of arbitrary
depth by modeling a series of containment relationships.
6.5.7. REQ#3.5.7. Referential Integrity
6.5.7.1. REQ#3.5.7.1. Referential Integrity (NOT Agreed)
RCDML: It SHOULD be possible to describe in the modeling language
that validation (at configuration create / merge time) of data cross
references is required for a given piece of the model.
The solution does not currently provide specific syntax for this, but
does have a method of defining relationships between Managed
Resources (keyref structures), which could be exploited to meet this
requirement. See also Section 1.2
6.5.7.2. REQ#3.5.7.2. Extended Referential Integrity (NOT Agreed)
It SHOULD be possible to support more complex validating of instance
data cross references.
The solution does not currently provide specific syntax for this.
Similar to simpler referential integrity checks, the basics required
to support this are already in the solution.
Chisholm, et al. Expires August 28, 2008 [Page 55]
Internet-Draft XML Schema Usage for NETCONF February 2008
6.5.8. REQ#3.5.8. Characterize Data (Agreed)
RCDML:The solution MUST be able to model configuration data. The
solution MUST be able to model non-configuration data, such as status
information and statistics. The solution MUST support characterizing
data definitions in a model as configuration or non-configuration.
The solution is able to model both configuration and operational data
of the Managed Resource. It is able to characterize data as either
configuration or operational data using the infoType appInfo
annotation. See Section 2.4.8 for more information.
6.5.9. REQ#3.5.9. Defaults
6.5.9.1. REQ#3.5.9.1. Default Values (NOT Agreed)
RCDDML: The solution SHOULD support defining static default values
for elements. In the content of NETCONF, this is understood to mean
that in an edit-config "create" request, if the client does not
provide the value, the server will assume the specific value defined
in the model as the default. The solution SHOULD specify how this
feature interacts with backwards compatibility, canonicalization, and
any other NETCONF operations. The solution SHOULD specify the
implications for claims of conformance to a default if the server
uses a different default value.
Default are supported as described in Section 2.4.9.
6.5.10. REQ#3.5.10. Formal Constraints
6.5.10.1. REQ#3.5.10.1. Formal Description of Constraints (Agreed)
RCDML: It MUST be possible to specify constraints on the value of an
element such as uniqueness, ranges, patterns, etc. These constraints
can be evaluated in isolation and not related to other elements.
The Data Definition allow a property to assert the following
constraints: values, default, size, strlen, regex, max_access,
ordered, and unique
6.5.10.2. REQ#3.5.10.2. Multi-element Constraints (NOT Agreed)
RCDML: A solution MAY provide a means to define constraints on an
element which involve another element of the configuration. An
example would be where the value of an MTU depends on the ifType.
Additional use cases might include dependencies on some non-
configuration data, such as presence of a particular piece of
hardware, or inter-system constraints.
Chisholm, et al. Expires August 28, 2008 [Page 56]
Internet-Draft XML Schema Usage for NETCONF February 2008
The data definition allows constraint assertion to be conditional
based on other property values, size, strlen or regex
6.5.10.3. REQ#3.5.10.3. Non-Key Uniqueness (Agreed)
RCDML: The solution MUST provide a way to specify constraints on
uniqueness of non-key data elements. The scope of the uniqueness
MUST be specified (parent, device, etc.) The extent of checking and
enforcement needs to be spelled out. The solution MUST spell out
whether, for a model to be valid, this constraint always holds true,
or is it only required to be true at the time the configuration is
created or merged.
A property with cardinality of more then one allow constraint
'unique' constraint.
6.5.11. REQ#3.5.11. Units (Agreed)
RCDML: The solution MUST provide a means of associating units with
values, since unit errors in the configuration of values have
potentially catastrophic consequences.
An the appInfo annotation of 'unit' can be specified to meet this
requirement. See Section 2.4.12 for more information.
6.5.12. REQ#3.5.12. Define Actions (NOT Agreed)
RCDML: The solution MAY provide a way to define specific actions to
be performed. Note that this is distinct from adding new operations
types to the protocol. If supported, the solution MUST describe how
these are mapped into the NETCONF protocol.
While it is considered better to define new NETCONF operations in a
more general way, for example defining a general <reboot> operation.
the solution does permit defining of action that are limited to a
single Managed Resource definition. The solution allows for the
definition of actions along with their input and output parameters as
well as error responses. These definitions use the rpcOperation
substitutionGroup like normal NETCONF operation definitions, but are
rooted in the Managed Resource definition. This action then behaves
like a normal NETCONF operation, except it has an implicit scope of
the Managed Resource in which it is defined.
6.6. REQ#3.6. Extensibility Requirements
Chisholm, et al. Expires August 28, 2008 [Page 57]
Internet-Draft XML Schema Usage for NETCONF February 2008
6.6.1. REQ#3.6.1. Language Extensibility
6.6.1.1. REQ#3.6.1.1. Language Versioning (Agreed)
RCDML:The modeling language itself MUST be versioned. This
requirement is motivated by the requirements for language
extensibility below.
This memo defines version 1.0 of the solution. This version number
covers specifically that the solution is using XML Schema version 1.0
and the specific set of appInfo annotations and conventions defined
in this memo.
6.6.1.2. REQ#3.6.1.2. User Extensions (NOT Agreed
RCDML: It SHOULD be possible for the users to extend the language.
This means the ability of the user of the data modeling language, to
add new statements or functionality to the language.
A lot of time and effort was put into designing XML Schema by people
who understand how to model XML content. The resulting richness of
the language should help minimize the number of user extensions
required. For those areas where gaps are identified, the standard
appInfo annotation method can be used to define new language
features, much like was done in this memo.
6.6.1.3. REQ#3.6.1.3. Mandatory Extensions (NOT Agreed)
RCDML:The solution SHOULD support defining language extensions which
the solution MUST understand; a tool which does not understand one of
these modeling language extensions MUST treat it as an error.
While in theory mandatory language extensions seems like a useful
thing, in practice they are of limited value. In practice the
requirement to maximize interoperability with implementations using
different versions of the language outweighs the benefits achieved by
adding new features to a language. Specific experience with a
proprietary data modeling language that had a requirement that any
new models written needed to work on products supporting up to three
releases back meant that it generally took years before a new feature
of the language could actually be used in product.
That having been said, if a mandatory to understand requirement was
identified where it was felt the benefits did outweigh the downside,
this could be accommodated in the language.
Chisholm, et al. Expires August 28, 2008 [Page 58]
Internet-Draft XML Schema Usage for NETCONF February 2008
6.6.2. REQ#3.6.2. Model Extensibility
6.6.2.1. REQ#3.6.2.1. Model Version Identification (Agreed)
RCDML:Different versions of a given schema MUST be unambiguously
identified. This assumes that the schema itself can be uniquely
identified.
As discussed in Section 2.4.3.2, the version tag is used to identify
the version of the Schema.
6.6.2.2. REQ#3.6.2.2. Interaction with defaults (NOT Agreed)
RCDML: The solution SHOULD define interaction of model definition
with defaults. What happens when defaults are added to model or
whether a default can be changed.
As indicated in Section 2.4.9.2, schema default values cannot be
modified.
6.6.2.3. REQ#3.6.2.3. Conformance Interference (NOT Agreed)
RCDML: The solution SHOULD define how revising a model interacts with
claims of conformance to its earlier versions, as well as what the
impact is on claims for conformance to other models which have re-
used definitions from the earlier version.
Conformance is discussed in Section 2.4.2. The backwards
compatibility requirements discussed in Section 2.4.3.1 mean, for the
most part, that an implementation compliant to the latest version of
a schema is also compliant to earlier versions of the schema. A
noteworthy exception is if an implementation chooses not to support
deprecated or obsoleted content which had a status of current in an
older version of the schema.
6.6.2.4. REQ#3.6.2.4. Obsolete Portions of a Model (Agreed)
RCDML: The solution MUST provide a way to signify that elements of a
schema are obsolete.
As discussed in Section 2.4.2 elements can be flagged as either
deprecated or obsolete.
6.6.3. REQ#3.6.3. Instance Data Extensibility
Chisholm, et al. Expires August 28, 2008 [Page 59]
Internet-Draft XML Schema Usage for NETCONF February 2008
6.6.3.1. REQ#3.6.3.1. Schema Version of Instance (NOT Agreed)
RCDML:The solution SHOULD provide a means to determine what schema
version was used to generate an instance document.
The namespace of the schema used to generate an instance document is
included in the instance document. The goal of the solution is to
maximum interoperability between different versions of the schema, so
the version number is not explicitly included.
6.6.3.2. REQ#3.6.3.2. Interaction with default Values (NOT Agreed)
RCDML:The solution SHOULD define its interactions with default values
in the instance, if supported. How does the fact that something is
defaulted show up on the wire and what happens when defaults are
added, removed or modified, for example.
As discussed in Section 2.4.9.2 and Section 6.4.1, how default values
are treated on the wire is left to the protocol.
6.6.3.3. REQ#3.6.3.3. Backwards Compatibility (Agreed)
RCDML:The solution MUST support the ability to extend the model and
still be usable to use it. A NETCONF client familiar with an older
version of the schema should still be able to function. An old
client should be able to work with a new server.
As discussed in Section 2.4.3.1, the solution supports a
comprehensive backwards compatibility section. Features which can
limit backwards compatibility include deprecating and obsoleting
mandatory objects and adding in new mandatory content.
6.6.3.4. REQ#3.6.3.4. Forwards Compatibility (NOT Agreed)
RCDML:The solution should support the ability to extend the model and
still interoperate with older versions. A NETCONF client employing a
newer version of the schema should still be able to function with a
server using an older version.
The solution has good support for forwards compatibility. Note
though that since Schema updates are allowed to make content less
restrictive, there is the potential for a NETCONF client supporting a
new version of a Schema to send content which it thinks is valid, but
that will get rejected by a NETCONF server supporting an older
version of the Schema. Adding in new mandatory content can also
limit forward compatibility since the NETCONF client will send this
in a request. The NETCONF server should ignore content it does not
understand in this case to restore forwards compatiblity.
Chisholm, et al. Expires August 28, 2008 [Page 60]
Internet-Draft XML Schema Usage for NETCONF February 2008
6.6.3.5. REQ#3.6.3.5. Must-Understand Model Extensions (NOT Agreed)
RCDML:The solution should support defining model extensions which the
client MUST understand or otherwise error. Adding mandatory objects
to an update to a Schema for example.
As noted above, mandatory model extensions cause issues with
backwards and forwards compatibility. The risk with completely
forbidding them is that the models can't be evolved in ways that make
the most sense for the technology being managed. This solution
therefore allows for their definition, but strongly advises against
their use when another method, such as using default values can be
used instead. In addition, while it is OK for an edit-config
operation to fail due to missing mandatory content, it is noted that
other functions such as monitoring should still be able to maintain
forwards compatibility in these cases.
6.7. REQ#3.7. Talking About Conformance
6.7.1. REQ#3.7.1. Conformance to the Modeling Language (NOT Agreed)
RCDML:A solution MUST spell out what is meant by "conformance" to
that particular modeling language specification. This requirement is
motivated by the need to evaluate whether or not a tool supports the
chosen solution.
In order to claim compliance to this solution, a tool must be able to
support and validate all XML Schema content. In addition, it should
be able to support and validate the appInfo extensions defined in
this memo.
6.7.2. REQ#3.7.2. Conformance to a Model (Agreed)
6.7.2.1. REQ#3.7.2.1. Conditional Conformance (NOT Agreed)
RCML:The solution should provide a means of providing conditional
compliance. If this is MPLS, then you need the following stuff
supported, for example.
This additional conformance information should be placed in the
element description using the documentation tag.
6.7.2.2. REQ#3.7.2.2. Server Conformance to Schema (Agreed)
RCDML: The solution MUST support a method of indicating whether
support of an object is required in order to claim conformance to a
particular schema.
Chisholm, et al. Expires August 28, 2008 [Page 61]
Internet-Draft XML Schema Usage for NETCONF February 2008
Server conformance is discussed in Section 2.4.2.4.1
6.7.2.3. REQ#3.7.2.3. Client Conformance To Schema (NOT Agreed)
RCDML:The solution should support a method of indicating whether
presence of an object is required in order to be a valid
configuration. This has been explained as "mandatory to use (in a
create) as NETCONF client as opposed to mandatory to implement on
NETCONF server",
Client conformance is discussed in Section 2.4.2.4.2.
6.7.2.4. REQ#3.7.2.4. Versioned Conformance (NOT Agreed)
The solution should provide a means of specifying what is required
for compliance when the schema is updated. One of the motivations
for this requirement is the need to know both what conformance to the
current version of a schema entails, as well as what conformance to a
previous version would entail. This becomes particularly important
when definitions are incorporated by reference in another model,
which is itself subject to revision.
Anyone interested in learning compliance information from earlier
versions of schemas should retrieve this from the earlier versions of
the schema. Including this information in each and every version of
a schema as it gets updated is not felt to add any value, only serves
to complicate the content definition.
6.8. REQ#3.8. Techno-Political Constraints
6.8.1. REQ#3.8.1. Standard Technology (NOT Agreed)
RCDML:The solution SHOULD leverage existing widely used language and
tools to define the NETCONF content, redefining as little as possible
the work that w3c and other relevant bodies have already done.
The solution is based on XML Schema so therefore can take advantage
of may existing tools to view, validate and understand the models.
Most web browsers come ready to display colour-coded XML Schema wih
the ability to expand and collapse hierarchy as desired. There are
many free tools and plugs in for popular tools like Eclipse capable
of editing and manipulating XML Schema. In addition, there are many
inexpensive off the shelf tools such as XMLSpy and oXygen that can be
used to develop models or to test validity of NETCONF content before
putting it into scripts to send to a NETCONF server.
Since appInfo extensions are also written in XML Schema, some tools
are also able to validate that these are used correctly in the
Chisholm, et al. Expires August 28, 2008 [Page 62]
Internet-Draft XML Schema Usage for NETCONF February 2008
NETCONF models.
It is important to note that many of the people who will be
developing NETCONF models will not be management geeks. Most will be
experts in the technology being managed. A solution which is able to
leverage technology which they may be using for another purpose
within their solution will cut down on the management specific things
they need to learn. In the case of this solution, it means they only
need to learn the appInfo extensions and in many cases these could
simply be added by a management expert during a final review process.
In general, be the model developers core management folks or experts
in other technology using existing technology increases the chances
that people are able to get started developing NETCONF content with
little training.
6.8.2. REQ#3.8.2. Translate Models to Other Forms (Agreed)
RCML: The solution MUST support the ability to translate a model
definition to RelaxNG and XML Schema. Any proposed solution MUST
describe whether this translation is lossy or lossless and if lossy,
what information is lost.
The solution is valid XML Schema so there is no need to provide a
translation to XML Schema. In theory it is not always possible to
provide a translation from XML Schema into Relax NG, but there are
tools available that claim to make a good effort at this task. How
appInfo tags get translated in this case is for further study.
6.8.3. REQ#3.8.3. Minimize SMI Translation Pain (NOT Agreed)
RCDML: Minimize translation pain from SMI into NETCONF content.
Translation of NETCONF content into SMI is not a consideration.
Disagreement about this requirement stems from concern about the
possibility that this might be interpreted as requiring the
perpetuation of SMI-style models, rather than merely accommodating
the basic types, as described in the work-in-progress [I-D.ietf-
opsawg-smi-datatypes-in-xsd].
It is possible to define mappings from SMI into NETCONF data
definitions. So, the proposal meets the requirement. Having said
that, we do not agree this should be a requirement, as we share the
concern expressed above. In addition, given the limited use of SNMP
in configuration management, the application area of primary concern
to Netconf, implies that the overlap in management information
between the two may be somewhat limited.
Chisholm, et al. Expires August 28, 2008 [Page 63]
Internet-Draft XML Schema Usage for NETCONF February 2008
6.8.4. REQ#3.8.4. Generate Models from Other Forms (NOT Agreed)
RCDML: The solution SHOULD support higher level modeling languages.
An example would be generating configuration data models from UML
descriptions. This requirement gets interesting regarding the
question of whether anything needed in a network configuration data
model might be impossible to represent in UML in machine-readable
form.
We do not agree with this requirement. Higher level modeling
languages such as UML are too generic for our purposes; we believe
that certain domain-specific constructs need to be provided for more
concise semantics and improved usability. While in principle
anything could be expressed in a higher-level language, capturing
those semantics that are commonly needed in the management domain
significantly adds to the power and expressiveness of the solution.
Having said that, it is certainly possible to provide UML-based
tooling front ends to provide a starting point in the design of
Netconf Data Definitions, although by itself this will not provide
all the construct - and enforce specification of essential semantic
aspects - that are needed for a defining a model that for management
purposes is reasonably complete.
6.8.5. REQ#3.8.5. Isolate Models from Protocol (NOT Agreed)
RCDML: The solution, and data models developed using the solution,
SHOULD NOT be too tightly coupled to the NETCONF protocol. It should
be possible to evolve the NETCONF protocol and data models
independently. One use case is that it should also be possible to
transport the data model instance (NETCONF content) over other
protocols, such as FTP.
This solution did not unnecessarily invent new syntax or constructs.
This means there is an appropriate separation between content and
protocol. This means that new mappings from this content definition
to specific protocols can be defined as deemed useful.
The data models developed using this solution can also easily be used
to generate content to be saved into files for transport via FTP.
This is an important use case for historical performance management
data. Providing this flexibility allows the same content to be
retrievable via a NETCONF <get> operation or retrievable via FTP,
whichever makes operational sense.
6.8.6. REQ#3.8.6. Library Support (NOT Agreed)
RCDML: The solution SHOULD have wide support from development
languages C, etc. The element of disagreement among the members of
Chisholm, et al. Expires August 28, 2008 [Page 64]
Internet-Draft XML Schema Usage for NETCONF February 2008
the design team is whether the evaluation of a solution depends on
the existence or on the feasibility of such support.
There is plenty of tooling available for XML and XML Schema based
development. Availability of standard tools are among the drivers
for picking an XML and XML Schema based solution.
6.8.7. REQ#3.8.7. RFC 3139 Considerations
RCDML: [RFC3139] defines "Requirements for Configuration Management
of IP- based Networks", which should be taken into consideration when
identifying a solution for use with NETCONF. Note that it is
possible that not all of these requirements will necessarily be
applicable to the current problem.
RFC 3139 identifies requirements for an overall configuration
management solution. Many of the its requirements are not applicable
here, as they target the configuration management system and the need
for a network-wide configuration. Our proposal does not inhibit any
of the requirements to be addressed by such a solution. For example,
it provides the ability to represent configurations to be applied at
the device level; it provides the ability to be granular and refer to
specific sub-configurations, specific Managed Resources, and specific
properties of those Managed Resources; it does allow for locking and
access control to be specified at granular levels.
6.8.8. REQ#3.8.8. RFC 3216 Considerations
RCDML: [RFC3216] defines "SMIng Objectives", which should be taken
into consideration when identifying a solution for use with NETCONF.
Note that not all of these requirements will necessarily be
applicable to the current problem.
Some of the requirements developed and captured during the
development of SMIng are relevant to this discussion. Others are
applicable to very specific protocol nuances of either SNMP or
COPS-PR or specific use cases for these technologies that are likely
not relevant to NETCONF. The requirements which are the most
relevant to this discussion are reflected in the list above.
Chisholm, et al. Expires August 28, 2008 [Page 65]
Internet-Draft XML Schema Usage for NETCONF February 2008
7. Relationship to NETCONF Protocol
The NETCONF architecture supports a clear separation between content
and protocol. This is an important architectural separation that
should be maintained. That having been said, there are major
advantages to ensuring that the content of NETCONF is well behaved
and predictable
Whether a NETCONF implementation can be said to be compliant without
also being compliant to the guidelines within this memo is an area of
further study.
Chisholm, et al. Expires August 28, 2008 [Page 66]
Internet-Draft XML Schema Usage for NETCONF February 2008
8. Security Considerations
To be determined once specific aspects of this solution are better
understood. In particular, the access control framework and the
choice of transport will have a major impact on the security of the
solution
Chisholm, et al. Expires August 28, 2008 [Page 67]
Internet-Draft XML Schema Usage for NETCONF February 2008
9. Acknowledgements
This document is a result of discussions at IETF 59, 60 and 64, as
well as on the mailing list by the following people: Sharon Chisholm,
David Harrington, Ray Atarashi, Yoshifumi Atarashi, Bert Wijnen, Dan
Romascanu, Andy Bierman, Randy Presuhn, Chris Lonvick, Eliot Lear,
Avri Doria, Juergen Schoenwaelder, Rob Ennes, Faye Ly, Andre
Westerinen, Orly Nicklass, Alexander Clemm, Keith McCloghrie, Hector
Trevino, James Balestriere Simon Leinen and Ladislav Lhotka. The
editors would also like to thank Sandeep Adwankar for his work on
earlier versions of this document. In preparation for the CANMOD
BOF, input from the following people was helpful: Randy Presuhn,
Rohan Mahy, Ron Buchanan, John Afaganis, Ian Macfarlane and Mark
Scott.
Chisholm, et al. Expires August 28, 2008 [Page 68]
Internet-Draft XML Schema Usage for NETCONF February 2008
10. References
10.1. Normative References
[NETCONF] Enns, R., "NETCONF Configuration Protocol", RFC 4741,
December 2006.
[NETCONF-Datatypes]
Li, Y., "Datatypes for Netconf Data Models", ID http://
www3.tools.ietf.org/html/
draft-romascanu-netconf-datatypes-02, May 2007.
[NETCONF-EVENT]
Chisholm, S. and H. Trevino, "NETCONF Event
Notifications", ID draft-ietf-netconf-notifications-12,
February 2008.
[RFC2119] Bradner, s., "Key words for RFCs to Indicate Requirements
Levels", RFC 2119, March 1997.
[XML] World Wide Web Consortium, "Extensible Markup Language
(XML) 1.0", W3C XML, February 1998,
<http://www.w3.org/TR/1998/REC-xml-19980210>.
[XSD] World Wide Web Consortium, "XML Schema Part 1: Structures
Second Edition", October 2004,
<http://www.w3.org/TR/2004/REC-xmlschema-1-20041021>.
10.2. Informational References
[CANMOD-DSDML]
Mahy, R. and S. Chisholm, "Defining Netconf Data Models
using Document Schema Definition Languages",
ID draft-mahy-canmod-dsdl-approach, February 2008.
[RCDML-Requirements]
Presuhn, R., "Requirements for a Configuration Data
Modeling Language", ID draft-presuhn-rcdml-03,
January 2008.
[Schematron]
ISO, "Document Schema Definition Languages (DSDL) -- Part
3: Rule-based validation -- Schematron", June 2006.
[XPATH] Clark, J. and S. DeRose, "XML Path Language (XPath) 2.0",
January 2007,
<http://www.w3.org/TR/1999/REC-xpath-19991116>.
Chisholm, et al. Expires August 28, 2008 [Page 69]
Internet-Draft XML Schema Usage for NETCONF February 2008
Appendix A. XML Syntax Definition of DHCP
The following DHCP definitions in XML-syntax demonstrate the general
principles of the approach.
A.1. Library Package
<?xml version="1.0" encoding="UTF-8"?>
<ndlLib package="example.org.ns.lib.dhcp" version="1.0"
xmlns="http://www.cisco.com/ndl"
xsi:schemaLocation="http://www.cisco.com/ndl C:\ndl.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<!-- Note: Use of a naming convention for managedResource name
,e.g. Camel cased with capitalized first letter,
will help user identify the MR in the instance XML -->
<managedResourceDef>
<managedResource name="dhcp">
<reference name="subnets" targetIsA="subnet"
targetRole="child" multiplicity="many"/>
<reference name="shared-networks" targetIsA="shared-network"
targetRole="child" multiplicity="many"/>
<configData>
<attribute name="default-lease-time" type="int">
<assert>
<constraint>values(0..max-lease-time)</constraint>
</assert>
</attribute>
<attribute name="max-lease-time" type="int"/>
</configData>
</managedResource>
<managedResource name="subnet">
<key>
<attribute name="network" type="ipAddress"/>
<attribute name="prefix-length" type="int"/>
</key>
<reference name="leases" targetIsA="lease"
targetRole="child" multiplicity="many"/>
Chisholm, et al. Expires August 28, 2008 [Page 70]
Internet-Draft XML Schema Usage for NETCONF February 2008
<configData ref="range"/>
<configData ref="dhcp-options"/>
<configData>
<attribute name="max-lease-time" type="int"/>
</configData>
<configData ref="interface-filter"/>
</managedResource>
<managedResource name="lease" maxAccess="read-only">
<description>
leases top level container contains status information
about active leases. This container cannot be present in a
configuration operation (ex: Netconf set/get-config)
</description>
<key>
<attribute name="ip-address" type="ipAddress"/>
</key>
<operationalData>
<attribute name="starts" type="datetime"/>
<attribute name="ends" type="datetime"/>
<attribute name="mac-address" type="nsapAddress"/>
</operationalData>
</managedResource>
<managedResource name="shared-network">
<description>
networks contain one of more subnets. The DHCP server
can provide addresses on any subnet in the shared network.
For the sake of this example, assume that the name attribute
is the key to the list of shared-networks. The key could be
an XML ID in a real instance.
</description>
<key>
<attribute name="name" type="string"/>
</key>
<reference name="subnets" targetIsA="subnet"
targetRole="child" multiplicity="many"/>
</managedResource>
Chisholm, et al. Expires August 28, 2008 [Page 71]
Internet-Draft XML Schema Usage for NETCONF February 2008
</managedResourceDef>
<configDataDef>
<configData name="range">
<attribute name="dynamic-bootp" type="boolean">
<assert><constraint>size(0..1)
</constraint></assert>
</attribute>
<attribute name="low" type="ipAddress">
<assert>
<condition>dynamic-bootp.values(true)</condition>
<constraint>size(1)</constraint>
</assert>
<assert><constraint>size(0..1)</constraint></assert>
</attribute>
<attribute name="high" type="ipAddress">
<assert>
<condition>dynamic-bootp.values(true)</condition>
<constraint>size(1)</constraint>
</assert>
<assert><constraint>size(0..1)</constraint></assert>
</attribute>
</configData>
<configData name="dhcp-options">
<attribute name="router" type="ipAddress" multiplicity="many">
<assert><constraint>ordered()</constraint></assert>
</attribute>
<attribute name="domain" type="string" multiplicity="many">
<assert><constraint>size(0..*)</constraint></assert>
</attribute>
<attribute name="custom" type="CustomOptionType"
multiplicity="many">
<assert><constraint>size(0..*)
</constraint></assert>
</attribute>
</configData>
<configData name="interface-filter">
<attribute name="interface" type="string" multiplicity="many"/>
</configData>
</configDataDef>
<typeDef>
<complexType name="CustomOptionType">
Chisholm, et al. Expires August 28, 2008 [Page 72]
Internet-Draft XML Schema Usage for NETCONF February 2008
<sequence>
<element name="option" type="OptionEnumType"/>
<element name="custom-value" type="IpAddressOrStringType"/>
</sequence>
</complexType>
<enumerationType name="OptionEnumType">
<enumeration value="150"/>
<enumeration value="171"/>
</enumerationType>
<complexType name="IpAddressOrStringType">
<choice>
<element name="ip-address" type="ipAddress"/>
<element name="string" type="string"/>
</choice>
</complexType>
</typeDef>
</ndlLib>
A.2. Implementation Packages
<?xml version="1.0" encoding="UTF-8"?>
<ndl package="example.org.ns.cal" version="1.0"
xmlns="http://www.cisco.com/ndl"
xsi:schemaLocation="http://www.cisco.com/ndl C:\ndl.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<managedResourceDef>
<managedResource name="dhcp"
implements="example.org.ns.lib.dhcp.dhcp">
<reference name="subnets"
targetIsA="example.org.ns.lib.dhcp.subnet"
targetRole="child" multiplicity="many"/>
<reference name="shared-networks"
targetIsA="example.org.ns.lib.dhcp.shared-network"
targetRole="child" multiplicity="many"/>
<configData>
<attribute name="default-lease-time" type="int"/>
Chisholm, et al. Expires August 28, 2008 [Page 73]
Internet-Draft XML Schema Usage for NETCONF February 2008
<attribute name="max-lease-time" type="int"/>
</configData>
</managedResource>
<managedResource name="subnet"
implements="example.org.ns.lib.dhcp.subnet">
<key>
<attribute name="network" type="ipAddress"/>
<attribute name="prefix-length" type="int"/>
</key>
<reference name="leases"
targetIsA="example.org.ns.lib.dhcp.lease"
targetRole="child" multiplicity="many"/>
<configData name="range">
<attribute name="dynamic-bootp" type="boolean"/>
<attribute name="low" type="ipAddress"/>
<attribute name="high" type="ipAddress"/>
</configData>
<configData name="dhcp-options">
<attribute name="router" type="ipAddress"
multiplicity="many"/>
<attribute name="domain" type="string"
multiplicity="many"/>
<attribute name="custom"
type="example.org.ns.lib.dhcp.CustomOptionType"
multiplicity="many"/>
<attribute name="timezone" type="string">
<assert><constraint>size(0..1)</constraint></assert>
</attribute>
</configData>
<configData>
<attribute name="max-lease-time" type="int"/>
</configData>
<configData name="interface-filter">
<attribute name="interface" type="string"
multiplicity="many"/>
</configData>
Chisholm, et al. Expires August 28, 2008 [Page 74]
Internet-Draft XML Schema Usage for NETCONF February 2008
</managedResource>
<managedResource name="lease" maxAccess="read-only"
implements="example.org.ns.lib.dhcp.lease">
<key>
<attribute name="ip-address" type="ipAddress"/>
</key>
<operationalData>
<attribute name="starts" type="datetime"/>
<attribute name="ends" type="datetime"/>
<attribute name="mac-address" type="nsapAddress"/>
</operationalData>
</managedResource>
<managedResource name="shared-network"
implements="example.org.ns.lib.dhcp.shared-network">
<key>
<attribute name="name" type="string"/>
</key>
<reference name="subnets"
targetIsA="example.org.ns.lib.dhcp.subnet"
targetRole="child" multiplicity="many"/>
</managedResource>
</managedResourceDef>
</ndl>
A.3. Example Mapping from XML Syntax
The following example illustrates the nature of the mapping of how an
XML-syntax translates ultimately into instance information (whose
schema is described using a server XML Schema, generated per the
mapping)
Chisholm, et al. Expires August 28, 2008 [Page 75]
Internet-Draft XML Schema Usage for NETCONF February 2008
<managedResource name="MR">
<key><attribute name="id" .../></key>
<reference name="child-mrs" targetRole="child" .../>
<configData>
<attribute name="c1" .../>
<attribute name="c2" .../>
</configData>
<configData name="cdx">
<attribute name="c3" .../>
</configData>
<operationalData>
<attribute name="o1" .../>
</operationalData>
</managedResource>
<managedResource name="ChildMR">...</managedResource>
MR Configuration Data XML Instance
<MR>
<id>...</id>
<child-mrs>
<ChildMR>
... Child MR data ...
</ChildMR>
</child-mrs>
<c1>...</c1>
<c2>...</c2>
<cdx>
<c3>...</c3>
</cdx>
</MR>
Chisholm, et al. Expires August 28, 2008 [Page 76]
Internet-Draft XML Schema Usage for NETCONF February 2008
Appendix B. Interworking with Yang
Yang is a proposal for specifying NETCONF content which defines its
own syntax. The authors of Yang have discussed automating a
translation from Yang to XSD. Their original view would be of a
translation that only uses core XSD syntax, and would therefore
result in a loss of features. This section describes a way of
getting to a non-lossy mapping from Yang into XSD.
Many of the features described within the XML Schema [XSD]
specification and the body of this menu can be used in a mapping from
Yang.
Conceptually, Yang can be considered a data definition language.
Chisholm, et al. Expires August 28, 2008 [Page 77]
Internet-Draft XML Schema Usage for NETCONF February 2008
Authors' Addresses
Sharon Chisholm
Nortel
3500 Carling Ave
Nepean, Ontario K2H 8E9
Canada
Email: schishol@nortel.com
Alex Clemm
Cisco
560 McCarthy
Milpitas, California 95035
USA
Email: alex@cisco.com
T.J. Tjong
Cisco
560 McCarthy
Milpitas, California 95035
USA
Email: jtjong@cisco.com
Chisholm, et al. Expires August 28, 2008 [Page 78]
Internet-Draft XML Schema Usage for NETCONF February 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Chisholm, et al. Expires August 28, 2008 [Page 79]