Network Working Group S. Chisholm
Internet-Draft Nortel
Expires: November 10, 2005 S. Adwankar
Motorola
May 9, 2005
Framework for Netconf Data Models
draft-chisholm-netconf-model-02.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 November 10, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This memo defines a framework for defining content for Netconf
Chisholm & Adwankar Expires November 10, 2005 [Page 1]
Internet-Draft Framework for Netconf Data Models May 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Definition of Terms . . . . . . . . . . . . . . . . . . . 4
2. Considerations for Interoperability . . . . . . . . . . . . . 6
2.1 Data Modelling Language . . . . . . . . . . . . . . . . . . 6
2.2 Conformance . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.1 Requirements . . . . . . . . . . . . . . . . . . . . . 6
2.2.2 Fine Grain Conformance . . . . . . . . . . . . . . . . 6
2.2.3 Operations on Data . . . . . . . . . . . . . . . . . . 6
2.2.4 Element Status . . . . . . . . . . . . . . . . . . . . 7
2.2.5 Schema Level Conformance . . . . . . . . . . . . . . . 8
2.3 Access Control . . . . . . . . . . . . . . . . . . . . . . 8
2.3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . 8
2.3.2 Proposed Solution . . . . . . . . . . . . . . . . . . 9
2.4 Versioning . . . . . . . . . . . . . . . . . . . . . . . . 9
2.5 Backwards Compatibility . . . . . . . . . . . . . . . . . 10
2.5.1 Enumerations . . . . . . . . . . . . . . . . . . . . . 10
2.5.2 Simple and Complex Types . . . . . . . . . . . . . . . 10
2.5.3 Lengths . . . . . . . . . . . . . . . . . . . . . . . 10
3. Considerations for Extensibility . . . . . . . . . . . . . . . 11
3.1 Data Types . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2 Elements and Attributes . . . . . . . . . . . . . . . . . 11
3.2.1 Attributes only for Metadata . . . . . . . . . . . . . 11
3.3 Other Extensibility Considerations . . . . . . . . . . . . 11
4. Considerations for Parse-ability . . . . . . . . . . . . . . . 12
4.1 Well-formed XML . . . . . . . . . . . . . . . . . . . . . 12
4.2 No DTDs . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.3 Avoid Mixed Content . . . . . . . . . . . . . . . . . . . 12
4.4 Use an Explicit Namespace on Attributes . . . . . . . . . 13
4.5 Use Container Elements for Lists . . . . . . . . . . . . . 13
5. Considerations for Usability . . . . . . . . . . . . . . . . . 15
5.1 Naming . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.2 Naming implications of using XPATH . . . . . . . . . . . . 15
5.2.1 Proper Tag Names . . . . . . . . . . . . . . . . . . . 16
5.3 Considerations for Usability . . . . . . . . . . . . . . . 16
5.4 Error Handling . . . . . . . . . . . . . . . . . . . . . . 16
5.4.1 Design Considerations . . . . . . . . . . . . . . . . 16
5.5 Schema Documentation . . . . . . . . . . . . . . . . . . . 17
6. Considerations for Predictable Modelling . . . . . . . . . . . 18
6.1 Managed Object Representation . . . . . . . . . . . . . . 18
6.2 Defining Relationships . . . . . . . . . . . . . . . . . . 20
6.2.1 Element Relationships . . . . . . . . . . . . . . . . 20
6.2.2 Instance Relationships . . . . . . . . . . . . . . . . 20
6.3 Specifying Statistics, Status and Configuration
Information . . . . . . . . . . . . . . . . . . . . . . . 20
7. Other Topics . . . . . . . . . . . . . . . . . . . . . . . . . 23
7.1 Schema Identity Information . . . . . . . . . . . . . . . 23
Chisholm & Adwankar Expires November 10, 2005 [Page 2]
Internet-Draft Framework for Netconf Data Models May 2005
7.2 Granularity of Data Model . . . . . . . . . . . . . . . . 25
7.3 Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
7.3.1 Multiple sets of Keys . . . . . . . . . . . . . . . . 25
7.4 Notifications & Asynchronous Messages . . . . . . . . . . 25
8. Relationship to Netconf Protocol . . . . . . . . . . . . . . . 26
8.1 Merge Operation . . . . . . . . . . . . . . . . . . . . . 26
8.2 Replace Operation . . . . . . . . . . . . . . . . . . . . 27
8.3 Delete Operation . . . . . . . . . . . . . . . . . . . . . 27
8.4 Create Operation . . . . . . . . . . . . . . . . . . . . . 28
8.5 Get Operation . . . . . . . . . . . . . . . . . . . . . . 29
9. Security Considerations . . . . . . . . . . . . . . . . . . . 30
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 31
Intellectual Property and Copyright Statements . . . . . . . . 33
Chisholm & Adwankar Expires November 10, 2005 [Page 3]
Internet-Draft Framework for Netconf Data Models May 2005
1. Introduction
NETCONF [NETCONF-PROTO] can be conceptually partitioned into four
layers:
Layer Example
+-------------+ +-----------------------------+
| Content | | Configuration data |
+-------------+ +-----------------------------+
| |
+-------------+ +-----------------------------+
| Operations | | <get-config>, <edit-config> |
+-------------+ +-----------------------------+
| |
+-------------+ +-----------------------------+
| RPC | | <rpc>, <rpc-reply> |
+-------------+ +-----------------------------+
| |
+-------------+ +-----------------------------+
| Application | | BEEP, SSH, SSL, console |
| Protocol | | |
+-------------+ +-----------------------------+
This document provides an introduction to the Netconf Data Model.
This work provides a framework for Netconf content. This framework
is intended to provide guidance for the creation of Netconf content
for the purposes of enabling interoperability, extensibility, parse-
ability and usability.
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 RFC 2119 [3].
Element: An XML Element[XML].
Managed Entity A node, which supports netconf[NETCONF] and has access
to management instrumentation.
Managed Object A collection of one of more Elements that define an
abstract thing of interest.
Chisholm & Adwankar Expires November 10, 2005 [Page 4]
Internet-Draft Framework for Netconf Data Models May 2005
ACL Access Control List. Used to associate permissions to perform
operations by a particular user to a particular Element.
Chisholm & Adwankar Expires November 10, 2005 [Page 5]
Internet-Draft Framework for Netconf Data Models May 2005
2. Considerations for Interoperability
This section describes some restrictions on Netconf content that will
increase interoperability between implementations and between
different versions of a given implementation.
2.1 Data Modelling Language
XML Schema should be used to define the XML-formatted data that will
be transported via Netconf.
2.2 Conformance
2.2.1 Requirements
The following are the requirements that have been identified for the
conformance and compliance aspects of Netconf data models.
1. Conformance Needs to be machine-readable
2. Both a high level of abstraction and lower one - specific groups
of objects as well as individuals.
3. It would also be good to be able to note specific exceptions to
conformance.
4. Dependencies between conformances should also be discoverable - in
order to do A, you need to first do B, for example. It was noted
that currently adding values to enumerations has an impact on
conformance.
5. It will be necessary to be able to specify the minimum and maximum
access to objects, compared to whether it can be read, written or
created.
2.2.2 Fine Grain Conformance
When defining elements, the "minOccurs" and "maxOccurs" tags must be
used to specify whether that object is required to have a compliant
schema. When defining an attribute, the "use" tag must be used to
define whether the attribute is required.
2.2.3 Operations on Data
Operations 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
Chisholm & Adwankar Expires November 10, 2005 [Page 6]
Internet-Draft Framework for Netconf Data Models May 2005
this element using the netconf <edit-config>; or <copy-config>
commands. A value of "delete" means it is possible to destroy
instances of this element using 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 either the <get-
config> or <get> operations. A value of "write" means it is
possible to modify an instance of this element using 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 a netconf <edit-config> or a <copy-
config> command or the ability to execute a <lock>, <unlock> or
<kill-session> command.
Netmod introduces the appInfo elements of "minAccess" and "maxAccess"
which can contains a non-empty space separated 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.
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 set operations on it as well. In the case of a statistic, both
the "minAccess" and "maxAccess" might have values of "read".
<xs:appinfo>
<xs:element name="minAccess" type="MinAccess" fixed="read" />
<xs:element name="maxAccess" type="MaxAccess"
fixed="read write" />
</xs:appinfo>
2.2.4 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 object.
An optional appInfo element 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 is "obsolete" which
indicates that implementations should consider migrating away from
this object and that its implementation is not longer required to be
considered conformant.
Chisholm & Adwankar Expires November 10, 2005 [Page 7]
Internet-Draft Framework for Netconf Data Models May 2005
For example
<xs:appinfo>
<xs:element minOccurs="0" name="status" type="Status"
fixed="current"/>
</xs:appinfo>
[Need deprecated. Cannot remove anything from a document. Cannot
reuse an element name. It stays in the document so it will not get
used.]
2.2.5 Schema Level Conformance
In order to claim compliance to a netmod schema, 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.3 Access Control
2.3.1 Overview
For discussing access control, we shall use the same equivalence
classes for operations on data: "Create", "Delete", "Detect", "Read",
"Write", and "Execute".
Access control is defined only for the node it is associated with.
It does not cascade throughout a containment hierarchy.
There are four classes of access control that can possibly be
defined:
1. Resource Category: High Level like BGP or DNS, similar to syslog
concept
2. Resource Type: Lowest level before instance
3. Resource Instance
4. Operation Type
There is a fifth class that enables access control within an instance
to specific values. This level of control is beyond the scope of
this specification.
The two main use cases for consideration are single customer and
multiple customers on a single box. Note that the concept of a
virtual router has been successful in solving the latter problem in
Chisholm & Adwankar Expires November 10, 2005 [Page 8]
Internet-Draft Framework for Netconf Data Models May 2005
SNMP and CLI.
Ideally the security model used in netconf is integratable with well-
deployed solutions like RADIUS and TACACS+.
2.3.2 Proposed Solution
[Editors Note: This area is for further study. Which bits belong in
the data model and which in the protocol? Can define a simple
security model that modelled on what CLIs do and integrate with
radius? What impacts would this have on the data model? Do we want
to a fully exposed and described model or just the ability to answer
the question "Is user A allows to run this command?". How do we
identify users, or do we need to (is it out of scope?)? The
requirement is to identify it so it can be deployed in deployed
security infrastructure.]
2.4 Versioning
The current version of a schema needs to be complete, not a delta
from the previous version.
The XML Schema version attribute will 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>
The XML Schema version attribute will be used to signify version.
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.
Instance documents should indicate their compatible version range
with an attribute on the root element which contains a list of
compatible versions. This implies that applications which consume
instance documents must perform processing to confirm XML Schema
compliance
When the context or behaviour of an element is modified between
versions a new schema should be created rather than updating the
version of an existing XML Schema. Alternatively, a new element
could be created in the existing schema, but using a different name.
Chisholm & Adwankar Expires November 10, 2005 [Page 9]
Internet-Draft Framework for Netconf Data Models May 2005
2.5 Backwards Compatibility
Backwards compatibility requirements come in two forms. The first is
bits on the wire compatibility of managed entities and manager
implementations that are based on different revisions of an XML
Schema. The other is compilation compatibility with XML Schema
modules that import definitions from the revised XML Schema module.
[Editors Note: the following questions need to be answered: What
sorts of changes in type are permissible? What sorts of changes to
the minOccurs, maxOccurs are acceptable?]
2.5.1 Enumerations
The semantics and mappings of an enumeration cannot change, but
values can be added with unused mnemonics during an update.
2.5.2 Simple and Complex Types
The removal of features from a simple or complex type would result in
the deletion of properties or methods in those elements that use them
so should be done with restraint. Inserted elements MUST NOT change
keys or add required properties. [Cannot add mandatory things later]
2.5.3 Lengths
It is not permitted to decrease MaxLen, MaxValue or to increase MinLen
or MinValue [Particular care should be taken in setting these sort of
lengths in the first place.]
Chisholm & Adwankar Expires November 10, 2005 [Page 10]
Internet-Draft Framework for Netconf Data Models May 2005
3. Considerations for Extensibility
3.1 Data Types
XML Schema has 44 built in data types [XML-SCHEMA-2]. Potentially
reusable data types should be declared as complex type, rather than
element.
It has been suggested that SMIv2 really had too many derived data
types that were almost the same. People couldn't really tell them
apart and getting the most correct data type was occasionally a non-
value add portion of the MIB review process. Care should be taken
not to define too many data types.
Data types that bring in a bit more application knowledge such as IP
Address, OSI State or DataAndTime have proved to be much more useful.
These are the sort of type definitions that should be created in
netmod.
3.2 Elements and Attributes
The choice of elements and attributes has been widely discussed, but
no absolute guidelines exist. When designing encoding rules for
NETCONF content, the following guidelines should be used:
3.2.1 Attributes only for Metadata
Attributes should contain metadata about the element, not true data.
Therefore, information about the managed entity should not be encoded
in attributes.
In addition, 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 another reason
to only use attributes fro metadata.
3.3 Other Extensibility Considerations
All data which is intended to allow extension in derived schemas
should be defined as (simple or complex) types, not elements. Any
data required in an element form should be a reference to a
simpleType or complexType declaration.
Chisholm & Adwankar Expires November 10, 2005 [Page 11]
Internet-Draft Framework for Netconf Data Models May 2005
4. Considerations for Parse-ability
Netconf content can affect the efficiency and robustness of parsing
routines in two ways. The first has to whether any content within
the Netconf content could be confused with any aspect of the
operations, RPC or application protocol layer. 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.
4.1 Well-formed XML
All XML used within a Netconf solution needs to be well formed [XML]
and conform to an XML Schema specification that conforms to the
guidelines in this document.
4.2 No DTDs
Document type declarations (DTDs) are not permitted to appear in
NETCONF content
4.3 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.
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>
Chisholm & Adwankar Expires November 10, 2005 [Page 12]
Internet-Draft Framework for Netconf Data Models May 2005
</not-valid>
4.4 Use an Explicit Namespace on Attributes
All attributes should be prefixed so that they belong to a specific
namespace. This encourages meaningful definitions that are free of
collisions.
<valid xmlns="http://valid/" xmlns:v="http://valid/"
v:foo="cool" />
<not-valid xmlns="http://not-valid/" foo="not-cool" />
4.5 Use Container Elements for Lists
A distinct container should be used when encoding lists with multiple
instances (maxOccurs > 1), use a distinct container element,
preferably the plural form of the instance element.
In this example, the element 'book' is contained within the "books"
element.
<valid>
<books>
<book>....</book>
<book>....</book>
<book>....</book>
</books>
</valid>
Use of container elements allows simpler manipulation of lists and
list members.
Note that this is only a guidelines as there are circumstances where
this is not the best choice. For example, if the books were
contained within the shelf of a bookcase, the "books" container
becomes superfluous. Also, if initially it was only expected for
there to be one instance of a book (maxOccurs=1), so therefore no
container wrapper of "books" and then in a subsequent update to the
schema it was determined that multiple instances of book
(maxOccurs>1), then it is not possible to retrofit the schema to
conform to this pattern.
Chisholm & Adwankar Expires November 10, 2005 [Page 13]
Internet-Draft Framework for Netconf Data Models May 2005
[Editors Note: Given the above, do we still want this?]
Chisholm & Adwankar Expires November 10, 2005 [Page 14]
Internet-Draft Framework for Netconf Data Models May 2005
5. Considerations for Usability
5.1 Naming
All NetMod base elements SHOULD be defined in the namespace
urn:ietf:params:xml:ns:netmod:base:1.0
All NetMod defined datatypes SHOULD be defined in the namespace
urn:ietf:params:xml:ns:netmod:datatypes:1.0
[Note: separate place for datatypes. Not a single namespace]
The name of an element SHOULD be unique in a given namespace and
should be addressed in a reference to a given namespace.
The network model SHOULD have separate namespaces for protocol
states, management information, enterprises and experimental managed
objects.
Netmod(urn:ietf:params:xml:ns:netmod:base:1.0)
5.2 Naming implications of using XPATH
XPath [XPATH] can be used to locate managed objects in a given
namespace. XPATH based addressing can also be used to select a set
of managed objects based on a set of criteria's, select content that
is combination of different managed object values and to create
simple expressions of managed objects.
Examples of XPATH based addressing are shown below:
1. Provide all book titles in a catalogue. //bk:book/
bk:bookTitle/@bk:value
2. Provide ACL information of the catalogue. /bk:Catalogue/ACL
3. Determine book title for a book whose ISBN number is 0596002923
//bk:book[bk:ISBN/@bk:value="0596002923"]/bk:bookTitle/@bk:value
4. List all book names where the average review rating is greater
than 4. //bk:book[bk:AverageReview/@bk:value>4]/
bk:bookTitle/@bk:value //if:ifEntry[if:ifMtu/@if:value>'500']
5. Select all books that have "NetMod" in their description and
average review rating is greater than 4. //bk:book[(contains(bk:
bookTitle/@bk:value,'NetMod')) and (bk:AverageReview/@bk:value>'4')]
Chisholm & Adwankar Expires November 10, 2005 [Page 15]
Internet-Draft Framework for Netconf Data Models May 2005
6. Find number of books whose publication year is greater than 2003.
count(//bk:book[bk:PublicationYear/@bk:value>'2003'])
[Editors Note: The implications of putting the rules for constructing
the object identifiers within both the protocol and the data model
have been discussed. It will be important to look ahead when
designing the schema. We need to ensure we don't put any
dependencies on data types within the naming hierarchy, for example.]
5.2.1 Proper Tag Names
When choosing element names, they should:
o use ASCII (7-bit).
o be lower camel.
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 MIB variables names in NETCONF, use the existing names
(ifAddr) instead of shifting to these guidelines (if-address). 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.
5.3 Considerations for Usability
5.4 Error Handling
It was agreed that error codes should be structured to consist of
both a generic protocol level error code and data model specific
error codes. If implementations don't understand the data model
specific error codes, they still have the generic one to go by, but
the data model specific error codes can provide information about the
specific problem that has happened.
5.4.1 Design Considerations
1. Granularity of specifying error messages: is it on a per schema,
per element, multiple per element basis?
Chisholm & Adwankar Expires November 10, 2005 [Page 16]
Internet-Draft Framework for Netconf Data Models May 2005
2. What mechanism should be used? Annotation, reserved named element
tags, attributes?
3. How closely tied are these to the known set of operations that can
be performed on the data? How is this determined?
5.5 Schema Documentation
The "documentation" tag must be used to provide all addition
information to implementers and users of a schema that can not be
modelled within the schema itself. 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.
Chisholm & Adwankar Expires November 10, 2005 [Page 17]
Internet-Draft Framework for Netconf Data Models May 2005
6. Considerations for Predictable Modelling
6.1 Managed Object Representation
The managed objects are represented in a hierarchical tree structure
that organizes all available management objects in the managed
entity. Each managed object is represented by a node or collection
of nodes. Each Node is extension of type NodeType that allows
definition of following properties. ACL: The access control
information pertaining to the instance of element LastUpdated: The
time/date when the last update of this instance took place
The XML Schema representation of the NodeType is given below.
<complexType name="NodeType">
<sequence>
<element name="LastUpdated" type="dateTime"
minOccurs="0"/>
</sequence>
</complexType>
[Editors note: we probably don't want this type, but the example is
nice. ]
Chisholm & Adwankar Expires November 10, 2005 [Page 18]
Internet-Draft Framework for Netconf Data Models May 2005
An example of a node that describes a system description is shown
below. The node extends NodeType and provides definition of
maxAccess, status and gives description of this node.
<xs:element name="book">
<xs:complexType>
<xs:complexContent>
<xs:extension base="NodeType">
<xs:annotation>
<xs:appinfo>
<xs:element name="minAccess" type="MinAccess" fixed="read"/>
<xs:element name="maxAccess" type="MaxAccess"
fixed="read"/>
<xs:element name="status" type="Status"
fixed="current"/>
</xs:appinfo>
<xs:documentation xml:lang="en">
Book Information.
</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element ref="bk:bookTitle"/>
<xs:element ref="bk:ISBN"/>
<xs:element ref="bk:Author"/>
<xs:element ref="bk:PublicationYear"/>
<xs:element ref="bk:LastIssueDate"/>
<xs:element ref="bk:AverageReview"/>
</xs:sequence>
<xs:attribute name="value" type="xs:string"
use="required" fixed="Container"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
An example of an instance of a book node is
<bk:book bk:value="Container">
<bk:bookTitle bk:value="NetMod for Dummies: Part2"/>
<bk:ISBN bk:value="0596002923"/>
<bk:Author bk:value="NeMod Experts"/>
<bk:PublicationYear bk:value="2004"/>
<bk:LastIssueDate bk:value="2004-10-15"/>
<bk:AverageReview bk:value="1"/>
</bk:book>
Chisholm & Adwankar Expires November 10, 2005 [Page 19]
Internet-Draft Framework for Netconf Data Models May 2005
6.2 Defining Relationships
Relationships between elements can be defined using XML containment,
for example:
<bookshelf>
<self>
2
</self>
</bookshelf>
But if we wish to represent information about the individual books,
it might be better to define that separately and then associate it
the particular shelf. This section will describe the preferred
method of defining this type of relationship.
What, if any, implications these relationships has on creation,
deletion and modifications needs to be well understood.
6.2.1 Element Relationships
An appInfo element can be used to define what relationships this
element has with other elements that are not implicit within its
element hierarchy.
<xs:appinfo>
<xs:element name="relationship" type="Relationship"
fixed="LivingRoom" />
</xs:appinfo>
[Just create an element shelf="bob". Give some thought to who you
are related to add elements for these>
6.2.2 Instance Relationships
[ What did we mean by that. If stack]
6.3 Specifying Statistics, Status and Configuration Information
[Editors Note: What about historical performance statistics?]
There may be potential value in being able to easily distinguish
between configuration, status and statistical information within a
data model.
Chisholm & Adwankar Expires November 10, 2005 [Page 20]
Internet-Draft Framework for Netconf Data Models May 2005
For example:
<bookshelf>
<numberOfBooks>
2
</numberofBooks>
<maximumNumberOfBooks>
3
</maximumNumberOfBooks>
<usageState>
active
</usageState>
</bookshelf>
numberOfBooks is a statistic, maximumNumberofBooks is a configurable
option and usageStatus is status information. Alternatively, this
information could have been defined using a specific design pattern
that would have provided better understanding of nature of each piece
of information without requiring specific knowledge of the context.
For example
<bookshelf>
<configuration>
<maximumNumberOfBooks>
3
</maximumNumberOfBooks>
</configuration>
<status>
<usageState>
active
</usageState>
</status>
<statistics>
<numberOfBooks>
2
</numberofBooks>
</statistics>
</bookshelf>
[Could do a separate one for configuration and one for configuration.
This is meta data. If it is configuration, I can use it in state,
for example. ]
Chisholm & Adwankar Expires November 10, 2005 [Page 21]
Internet-Draft Framework for Netconf Data Models May 2005
[Test on existing data models?]
Chisholm & Adwankar Expires November 10, 2005 [Page 22]
Internet-Draft Framework for Netconf Data Models May 2005
7. Other Topics
The items within this section may not necessarily belong within this
specification, so may get moved elsewhere at a later date.
It should be possible to discover a box and find out both is major
software release numbers as well as the list of data models and their
versions that are supported.
7.1 Schema Identity Information
A schema must contain schema Identity element as part of the appinfo.
The Identity provides schema information such as last update of this
schema, organization, contact, description and revision history. The
contact and revision information can occur multiple times in a schema
identity.
An example of identity element is as given below
<n:Identity xmlns:n="urn:ietf:params:xml:ns:netmod:base:1.0">
<n:Name>NetConf State Schema</n:Name>
<n:LastUpdated>2001-12-17T09:30:47-05:00</n:LastUpdated>
<n:Organization>Example.com</n:Organization>
<n:Contact>
<n:Name>ExampleName</n:Name>
<n:Postal>ExampleAddress</n:Postal>
<n:EMail>http://www.example.com</n:EMail>
<n:Phone>0000000</n:Phone>
<n:otherInfo>Any other Info</n:otherInfo>
</n:Contact>
<n:Description>The Description of NetConf State Schema
</n:Description>
<n:RevisionHistory>
<n:Revision>2004-12-17T09:30:47-05:00</n:Revision>
<n:Description>The first version of the schema</n:Description>
</n:RevisionHistory>
</n:identity>
Chisholm & Adwankar Expires November 10, 2005 [Page 23]
Internet-Draft Framework for Netconf Data Models May 2005
The XML Schema data types corresponding to Schema Identity
information are as below
<xs:complexType name="IdentityType">
<xs:sequence>
<xs:element name="Name" type="xs:string"/>
<xs:element name="LastUpdated" type="xs:dateTime"/>
<xs:element name="Organization" type="DisplayString"/>
<xs:element name="Contact" type="ContactType"
maxOccurs="unbounded" />
<xs:element name="Description" type="Description" minOccurs="0"/>
<xs:element name="RevisionHistory" type="RevisionType"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="RevisionType">
<xs:sequence>
<xs:element name="Revision" type="xs:dateTime"/>
<xs:element name="Description" type="Description"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="ContactType">
<xs:sequence>
<xs:element name="Name" type="DisplayString"/>
<xs:element name="Postal" type="Description" minOccurs="0"/>
<xs:element name="EMail" type="xs:anyURI"/>
<xs:element name="Phone" type="xs:string" minOccurs="0"/>
<xs:element name="otherInfo" type="Description" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:simpleType name="Description">
<xs:restriction base="xs:string">
<xs:maxLength value="2048"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="DisplayString">
<xs:restriction base="xs:string">
<xs:maxLength value="255"/>
</xs:restriction>
</xs:simpleType>
Chisholm & Adwankar Expires November 10, 2005 [Page 24]
Internet-Draft Framework for Netconf Data Models May 2005
7.2 Granularity of Data Model
Ideally, it should be possible to make a small change to the data
model and have it trigger a big change.
7.3 Keys
[Editors Note: this needs to be moved into one of the other
sections?]
Keys are an optional construct for specifying the element or set of
element that uniquely identifies an instance. Additional keys may be
added over time.
[Editors note: need syntax or other method for identifying keys]
7.3.1 Multiple sets of Keys
It may be desirable to use two different sets of keys to access some
information. Note that being able to query on arbitrary pieces of
information provides this.
[Editors note: do we need more discussion here, like define things as
types or references to provide more flexibility?]
7.4 Notifications & Asynchronous Messages
[Editors Note: This area is for further study. Do we need to
explicitly define notifications in the data model or could we just
say that any bit of content could be sent asynchronously?]
Chisholm & Adwankar Expires November 10, 2005 [Page 25]
Internet-Draft Framework for Netconf Data Models May 2005
8. 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.
The following examples illustrate the netconf protocol commands being
executed against netmod compliant Schemas.
8.1 Merge Operation
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<running/>
</target>
<config xmlns="urn:ietf:params:xml:ns:netmod:data:book:1.0">
<book value="Container">
<bookTitle value="NetMod for Dummies: Part1"/>
<ISBN value="0596002923"/>
<Author value="NetMod Experts"/>
<PublicationYear value="2003"/>
<LastIssueDate value="2003-10-15"/>
<AverageReview value="0"/>
</book>
</config>
</edit-config>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
Chisholm & Adwankar Expires November 10, 2005 [Page 26]
Internet-Draft Framework for Netconf Data Models May 2005
8.2 Replace Operation
<rpc message-id="102"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<running/>
</target>
<config xmlns="urn:ietf:params:xml:ns:netmod:data:book:1.0"
operation="replace">
<book value="Container">
<bookTitle value="NetMod for Dummies: Part2" />
<ISBN value="0596002924"/>
<Author value="NetMod Experts"/>
<PublicationYear value="2003"/>
<LastIssueDate value="2003-10-15"/>
<AverageReview value="0"/>
</book>
</config>
</edit-config>
</rpc>
<rpc-reply message-id="102"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/> </rpc-reply>
8.3 Delete Operation
<rpc message-id="103"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<Path>//bk:book[bk:ISBN/@bk:value="0596002923"]</Path>
</target>
<config xmlns="urn:ietf:params:xml:ns:netmod:data:book:1.0"
operation="delete"/>
</config>
</edit-config>
</rpc>
<rpc-reply message-id="103"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
Chisholm & Adwankar Expires November 10, 2005 [Page 27]
Internet-Draft Framework for Netconf Data Models May 2005
8.4 Create Operation
<rpc message-id="104"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<running/>
</target>
<config xmlns="urn:ietf:params:xml:ns:netmod:data:book:1.0"
operation="create">
<book value="Container">
<bookTitle value="NetMod for Dummies: Part3"/>
<ISBN value="0596002925"/>
<Author value="NetMod Experts"/>
<PublicationYear value="2003"/>
<LastIssueDate value="2003-10-15"/>
<AverageReview value="0"/>
</book>
</config>
</edit-config>
</rpc>
<rpc-reply message-id="104"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/>
</rpc-reply>
Chisholm & Adwankar Expires November 10, 2005 [Page 28]
Internet-Draft Framework for Netconf Data Models May 2005
8.5 Get Operation
<nc:rpc xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
nc:message-id="105">
<nc:get>
<nc:Path>
/bk:Catalog/bk:book[bk:ISBN/@bk:value="0596002921"]
</nc:Path>
</nc:get>
</nc:rpc>
<nc:rpc-reply xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
nc:message-id="105">
<nc:data
xmlns="urn:ietf:params:xml:ns:netmod:data:book:1.0">
<book value="Container">
<bookTitle value="NetMod for Dummies: Part3"/>
<ISBN value="0596002925"/>
<Author value="NetMod Experts"/>
<PublicationYear value="2003"/>
<LastIssueDate value="2003-10-15"/>
<AverageReview value="0"/>
</book>
</nc:data>
</nc:rpc-reply>
Chisholm & Adwankar Expires November 10, 2005 [Page 29]
Internet-Draft Framework for Netconf Data Models May 2005
9. 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 & Adwankar Expires November 10, 2005 [Page 30]
Internet-Draft Framework for Netconf Data Models May 2005
10. Acknowledgements
This document is a result of discussions at IETF 59 and 60, 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, and Andre
Westerinen.
11. References
[NETCONF] Enns, R., "NETCONF Configuration Protocol",
ID draft-ietf-netconf-prot-06, April 2005.
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.
[XML] World Wide Web Consortium, "Extensible Markup Language
(XML) 1.0", W3C XML, February 1998,
<http://www.w3.org/TR/1998/REC-xml-19980210>.
[refs.RFC2026]
Bradner, S., "The Internet Standards Process -- Revision
3", RFC 2026, BCP 9, October 1996.
[refs.RFC2119]
Bradner, s., "Key words for RFCs to Indicate Requirements
Levels", RFC 2119, March 1997.
[refs.RFC2223]
Postel, J. and J. Reynolds, "Instructions to RFC Authors",
RFC 2223, October 1997.
Authors' Addresses
Sharon Chisholm
Nortel
PO Box 3511
Station C
Ottawa, Ontario K1Y 4H7
Canada
Email: schishol@nortel.com
Chisholm & Adwankar Expires November 10, 2005 [Page 31]
Internet-Draft Framework for Netconf Data Models May 2005
Sandeep Admankar
Motorola
1301 East Algonquin Road
MS IL02-2240
Schaumburg, Il 60196
USA
Email: sandeep.adwankar@motorola.com
Chisholm & Adwankar Expires November 10, 2005 [Page 32]
Internet-Draft Framework for Netconf Data Models May 2005
Intellectual Property Statement
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.
The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Chisholm & Adwankar Expires November 10, 2005 [Page 33]
Internet-Draft Framework for Netconf Data Models May 2005
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Chisholm & Adwankar Expires November 10, 2005 [Page 34]