Network Working Group S. Chisholm Internet-Draft Nortel Intended status: Standards Track S. Adwankar Expires: July 5, 2007 Motorola January 2007 Using XML Schema to define Netconf Content draft-chisholm-netconf-model-06.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 July 5, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Chisholm & Adwankar Expires July 5, 2007 [Page 1] Internet-Draft XML Schema Usage for Netconf January 2007 Abstract This memo defines a framework for defining content for Netconf using XML Schema. It defines requirements to enable interoperability, extensibility, easy parsing, usability and predictable modelling. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Definition of Terms . . . . . . . . . . . . . . . . . . . 4 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Data Modelling Language . . . . . . . . . . . . . . . . . 5 2.2. Conformance . . . . . . . . . . . . . . . . . . . . . . . 5 2.2.1. Fine Grain Conformance . . . . . . . . . . . . . . . . 5 2.2.2. Operations on managed objects . . . . . . . . . . . . 5 2.2.3. Element Status . . . . . . . . . . . . . . . . . . . . 6 2.2.4. Additional Conformance Information . . . . . . . . . . 6 2.3. Backwards Compatibility . . . . . . . . . . . . . . . . . 7 2.4. Versioning . . . . . . . . . . . . . . . . . . . . . . . . 7 2.5. Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.6. Defining Relationships . . . . . . . . . . . . . . . . . . 9 2.6.1. Association Relationship . . . . . . . . . . . . . . . 10 2.7. Defining Notification Event Messages . . . . . . . . . . . 11 2.8. Considerations for Parse-ability . . . . . . . . . . . . . 12 2.8.1. Well-formed XML . . . . . . . . . . . . . . . . . . . 13 2.9. Naming . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.10. Error Messages . . . . . . . . . . . . . . . . . . . . . . 13 2.11. Schema Documentation . . . . . . . . . . . . . . . . . . . 14 2.12. Specifying Statistics, Status and Configuration Information . . . . . . . . . . . . . . . . . . . . . . . 14 3. Modelling Considerations . . . . . . . . . . . . . . . . . . . 16 3.1. Modularity . . . . . . . . . . . . . . . . . . . . . . . . 16 3.2. Data Types . . . . . . . . . . . . . . . . . . . . . . . . 16 3.3. Elements and Attributes . . . . . . . . . . . . . . . . . 16 3.4. Use Container Elements for Lists . . . . . . . . . . . . . 16 3.5. Naming implications of using XPATH . . . . . . . . . . . . 17 3.5.1. Proper Tag Names . . . . . . . . . . . . . . . . . . . 18 3.6. Granularity of Data Model . . . . . . . . . . . . . . . . 18 3.7. Avoid Mixed Content . . . . . . . . . . . . . . . . . . . 18 4. Summary and Example . . . . . . . . . . . . . . . . . . . . . 20 4.1. Summary of Netconf Appinfo Elements & Attributes . . . . . 20 4.2. XML Schema for per element appInfo . . . . . . . . . . . . 20 4.3. Managed Object Example . . . . . . . . . . . . . . . . . . 22 5. Relationship to Netconf Protocol . . . . . . . . . . . . . . . 26 5.1. Merge Operation . . . . . . . . . . . . . . . . . . . . . 26 5.2. Replace Operation . . . . . . . . . . . . . . . . . . . . 27 5.3. Delete Operation . . . . . . . . . . . . . . . . . . . . . 28 Chisholm & Adwankar Expires July 5, 2007 [Page 2] Internet-Draft XML Schema Usage for Netconf January 2007 5.4. Create Operation . . . . . . . . . . . . . . . . . . . . . 29 5.5. Get Operation . . . . . . . . . . . . . . . . . . . . . . 30 5.6. Get Operation with subtree filtering . . . . . . . . . . . 31 5.7. Get All Operation . . . . . . . . . . . . . . . . . . . . 31 6. Security Considerations . . . . . . . . . . . . . . . . . . . 33 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34 8. Normative References . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 Intellectual Property and Copyright Statements . . . . . . . . . . 37 Chisholm & Adwankar Expires July 5, 2007 [Page 3] Internet-Draft XML Schema Usage for Netconf January 2007 1. Introduction [NETCONF] can be conceptually partitioned into four layers: Layer Example +-------------+ +----------------------------------------+ | Content | | Configuration data | +-------------+ +----------------------------------------+ | | +-------------+ +-------------------------------------------+ | Operations | | , | +-------------+ +-------------------------------------------+ | | | +-------------+ +-----------------------------+ | | RPC | | , | | +-------------+ +-----------------------------+ | | | | +-------------+ +------------------------------------------+ | Transport | | BEEP, SSH, SSL, console | | Protocol | | | +-------------+ +------------------------------------------+ This document defines a framework for Netconf content using XML Schema. 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] and has access to management instrumentation. This is also referred to as the netconf server. Managed Object: A collection of one of more Elements that define an abstract thing of interest. Chisholm & Adwankar Expires July 5, 2007 [Page 4] Internet-Draft XML Schema Usage for Netconf January 2007 2. Requirements This section describes some restrictions on Netconf content and provides guidance on how to use XML Schema to define this content, which 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 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 2.2.1. 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.2. Operations on managed objects Operations that can be performed on managed objects 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 or commands. A value of "delete" means it is possible to destroy instances of this element using commands like the netconf , or operations. A value of "read" means that it is possible to view values of this element using commands like the , or operations. A value of "write" means it is possible to modify an instance of this element using commands like the netconf or commands. A value of "execute" means that there is a side Chisholm & Adwankar Expires July 5, 2007 [Page 5] Internet-Draft XML Schema Usage for Netconf January 2007 effect execution such as rebooting that is permissible as a result of commands like the netconf or a command or the ability to execute a commands like the , or command. This memo introduces the appinfo element of "minAccess" and an optional one of "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, it assumes the same value as the minAccess tag. 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". 2.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 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 no longer required to be considered conformant. Obsolete content is never removed from the document and its element name can never be re-used For example current 2.2.4. Additional Conformance Information Additional information about conformance should be specified using a documentation tag. Chisholm & Adwankar Expires July 5, 2007 [Page 6] Internet-Draft XML Schema Usage for Netconf January 2007 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.2.4.1. Schema Level Conformance 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.3. 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, restricting the content of an existing component, or adding or removing required components are changes that do not maintain backwards compatibility. If an update to an XML Schema is backwards compatibility, then it must use the same element name. A new element name must be used when backwards compatibility is not possible. 2.4. Versioning Each version of a schema needs to be complete, not a delta from the previous version. [Editor's Note: there has been discussion about whether all versions of a Schema maintain backwards compatibility, or if only minor version number changes do. Major version number changes could potentially signify a break in backwards compatibility. For example, version 1.2 would be backwards compatible to version 1.0, while version 2.0 may not be.] Chisholm & Adwankar Expires July 5, 2007 [Page 7] Internet-Draft XML Schema Usage for Netconf January 2007 The XML Schema version attribute will be used to signify version For example: 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.5. Keys Keys are an optional construct for specifying the element or set of element that uniquely identifies an instance of a managed object. The XML Schema 'key' construct is used to specify keys. In the absence of explicitly defined keys, everything can be considered a key from the perspective of the collection of fields that uniquely define an entry. [Editor's Note: we may also want to define an attribute called keys so it can be sent over the wire in the instance document.] Chisholm & Adwankar Expires July 5, 2007 [Page 8] Internet-Draft XML Schema Usage for Netconf January 2007 Note that being able to query on arbitrary pieces of information provides for multiple views of the managed object, and the optional definition of keys does not preclude this. 2.6. Defining Relationships Relationships between elements come in three forms: associations, extensions and specializations. An extension to existing element defines information about the same managed object, but just does it in a separate piece of Schema. For Chisholm & Adwankar Expires July 5, 2007 [Page 9] Internet-Draft XML Schema Usage for Netconf January 2007 example, if a common Schema define information about interfaces, a particular product might define an extension to define information for that interface that is only applicable to that product. To return to our book example, a particular publisher may wish the extend the general book definition to include information specific to their own books, such as the name of the animal depicted on the cover. 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. With our book example, a specialization of children's books might be defined that defines information such as suggested age of reader. An association exists between two different managed objects. For example, a port is associated with an interface or a book within a bookshelf. It is important to be able to learn the relationships between the managed objects that are represented in the XML Schema 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 object represented by a piece of XML schema, it causes the creation of all other bits of XML Schema that represent that managed object as well as any applicable specializations of that object. Relationships need to be understood in general as well as the specific run-time instances. The first is what is defined in the XML Schema and the second is what we see only over the wire. 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, or that the Encyclopaedia is on shelf 3 is learned using the general method learned while learning about the generalized relationships./ 2.6.1. Association Relationship The easiest way to define an association relationship is using containment. A book is on a bookshelf, so the following XML makes this relationship obvious and unambiguous Chisholm & Adwankar Expires July 5, 2007 [Page 10] Internet-Draft XML Schema Usage for Netconf January 2007 It is not always possible or desirable to model all associations via containment. Managed objects 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 objects into smaller, related pieces of XML Schema. The XML Schema 'keyref' construct will be used to define relationships between managed objects. [Editor's Note: ensure 'keyref' can be used to point at elements not within the same scope. If not, define a similar construct that can be.] 2.7. Defining Notification Event Messages Netconf provides a mechanism to send asynchronously event messages [NETCONF-EVENT]. The protocol specification makes few restrictions on the content or source of Netconf notifications. The content that will be sent asynchronously via Netconf notifications should be clearly identified within the XML Schema so that Netconf clients will know what behaviour to expect. The definition of Netconf notifications should allow a single definition of content to be sent either asynchronously and synchronously. An event is something that happens which may be of interest. A fault, a change in status, crossing a threshold, or an external input to the system, for example [RFC3877]. Often this results in an asynchronous message, sometimes referred to as a notification or event message, being sent out to interested parties to notify them that this event has occurred. Event messages will be defined in XML Schema with an appinfo of 'eventClasses' used to both identify which bits of XML Schema define event messages but also what type of event. An event belongs to one or more classes. The initial set of classes is fault, information, state, audit, Chisholm & Adwankar Expires July 5, 2007 [Page 11] Internet-Draft XML Schema Usage for Netconf January 2007 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. Note that it may make operational sense to set the minAccess or maxAccess of an element with element classes defined against it to be a null list to indicate that this information can not be read or configured using other commands. 2.8. Considerations for Parse-ability 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 Chisholm & Adwankar Expires July 5, 2007 [Page 12] Internet-Draft XML Schema Usage for Netconf January 2007 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.8.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. 2.9. 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 The name of an element SHOULD be unique in a given namespace and should be addressed in a reference to a given namespace. 2.10. Error Messages Within Netconf, the 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 is included within the XML Schema that defines the Netconf content. [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 read Les Miserable" as appose to "I can't read Les Miserable". ] Chisholm & Adwankar Expires July 5, 2007 [Page 13] Internet-Draft XML Schema Usage for Netconf January 2007 An optional appinfo called 'appErrors ' is used to specify these application-level error messages. Book is in language you do not understand. appErrors> These are applicable to any element. [Editor's Note: How closely tied are these to the known set of operations that can be performed on the data? How is this determined?] 2.11. 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 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. 2.12. 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. This would allow better understanding of nature of each piece of information without requiring specific knowledge of the context. Propose adding an optional appinfo called dataType which takes a value of 'configuration', 'statistics', or 'status'. [Editor's Note: rework these examples to use appinfo] For example Chisholm & Adwankar Expires July 5, 2007 [Page 14] Internet-Draft XML Schema Usage for Netconf January 2007 configuration [Editor's Note: Test on existing data models?] Chisholm & Adwankar Expires July 5, 2007 [Page 15] Internet-Draft XML Schema Usage for Netconf January 2007 3. Modelling Considerations 3.1. Modularity It is better to publish Netconf content as a series of XML Schema rather then as a single monolithic data model. 3.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. 3.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 is use of attributes. 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 for metadata. 3.4. Use Container Elements for Lists A distinct container should be used when encoding lists with multiple instances (maxOccurs > 1), use a distinct container element. Sometimes this will be the plural form of the instance element, but often there is a more natural container available. Some containers exist in the 'real world' and some are only modelling artefacts. When an appropriate real-world container is available, it is not necessary to create a modelling artefact to artificially contain the list. Chisholm & Adwankar Expires July 5, 2007 [Page 16] Internet-Draft XML Schema Usage for Netconf January 2007 In this example, the element 'book' is contained within the "books" element. .... .... .... .... .... .... Use of container elements allows simpler manipulation of lists and list members. 3.5. 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 . //bk:book/bk:bookTitle/@bk:value 2. Provide ACL information of the . /bk:/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')] 6. Find number of books whose publication year is greater than 2003. count(//bk:book[bk:PublicationYear/@bk:value>'2003']) Chisholm & Adwankar Expires July 5, 2007 [Page 17] Internet-Draft XML Schema Usage for Netconf January 2007 3.5.1. 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. 3.6. Granularity of Data Model Designers should give some thought to the high level information they users need to manage the device and not simple expose the low level information that they have available. Ideally, it should be possible to make a small change to the data model and have it trigger a big change in the managed entity. 3.7. 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. Chisholm & Adwankar Expires July 5, 2007 [Page 18] Internet-Draft XML Schema Usage for Netconf January 2007 data data datadatamaybe some Chisholm & Adwankar Expires July 5, 2007 [Page 19] Internet-Draft XML Schema Usage for Netconf January 2007 4. Summary and Example 4.1. Summary of Netconf Appinfo Elements & Attributes The following table summarizes the XML Schema appinfo 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 | -------------------------------------- | minAccess | | Mandatory | | maxAccess | | Optional | | status | | Optional | | appErrors | | Recommended | | eventClass | | Optional | | dataType | | Optional | -------------------------------------- Figure 15 4.2. XML Schema for per element appInfo This is a set of information that can be applied to any element. Chisholm & Adwankar Expires July 5, 2007 [Page 20] Internet-Draft XML Schema Usage for Netconf January 2007 Chisholm & Adwankar Expires July 5, 2007 [Page 21] Internet-Draft XML Schema Usage for Netconf January 2007 4.3. Managed Object Example An example of a node that describes a system description is shown below. . This element defines information about books Chisholm & Adwankar Expires July 5, 2007 [Page 22] Internet-Draft XML Schema Usage for Netconf January 2007 current Book lent out Book not interesting Book in language you don't know Book eaten by book worm The ISBN for this book. current The author of this book. current Chisholm & Adwankar Expires July 5, 2007 [Page 23] Internet-Draft XML Schema Usage for Netconf January 2007 The year this book was published current The last issue date for this book. current The average review for this book. current Chisholm & Adwankar Expires July 5, 2007 [Page 24] Internet-Draft XML Schema Usage for Netconf January 2007 An example of an instance of a book node is XYZ 0000000123 ABC 2005 2005-02-02 5 Chisholm & Adwankar Expires July 5, 2007 [Page 25] Internet-Draft XML Schema Usage for Netconf January 2007 5. 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. 5.1. Merge Operation RPC Request : replace NetMod for Dummies: Part2 0596002923 NetMod Experts 2003 2003-10-15 1 RPC Reply : Chisholm & Adwankar Expires July 5, 2007 [Page 26] Internet-Draft XML Schema Usage for Netconf January 2007 5.2. Replace Operation RPC Request : replace NetMod for Dummies: Part2 0596002924 NetMod Experts 2003 2003-10-15 1 RPC Reply : Chisholm & Adwankar Expires July 5, 2007 [Page 27] Internet-Draft XML Schema Usage for Netconf January 2007 5.3. Delete Operation RPC Request : RPC Reply : Chisholm & Adwankar Expires July 5, 2007 [Page 28] Internet-Draft XML Schema Usage for Netconf January 2007 5.4. Create Operation RPC Request : replace NetMod for Dummies: Part6 0596002 NetMod Experts 2003 2003-10-15 1 RPC Reply : Chisholm & Adwankar Expires July 5, 2007 [Page 29] Internet-Draft XML Schema Usage for Netconf January 2007 5.5. Get Operation RPC Request : RPC Reply : NetMod for Dummies: Part2 0596002923 NetMod Experts 2003 2003-10-15 1 NetMod for Dummies: Part2 0596002924 NetMod Experts 2003 2003-10-15 1 Chisholm & Adwankar Expires July 5, 2007 [Page 30] Internet-Draft XML Schema Usage for Netconf January 2007 5.6. Get Operation with subtree filtering RPC Request : //bk:ISBN RPC Reply : 0596002924 5.7. Get All Operation RPC Request : RPC Reply : locked 7 Chisholm & Adwankar Expires July 5, 2007 [Page 31] Internet-Draft XML Schema Usage for Netconf January 2007 unlocked unlocked 6 Bob 2:56:01 PM NetMod for Dummies: Part2 0596002924 NetMod Experts 2003 2003-10-15 1 Chisholm & Adwankar Expires July 5, 2007 [Page 32] Internet-Draft XML Schema Usage for Netconf January 2007 6. 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 July 5, 2007 [Page 33] Internet-Draft XML Schema Usage for Netconf January 2007 7. 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. Chisholm & Adwankar Expires July 5, 2007 [Page 34] Internet-Draft XML Schema Usage for Netconf January 2007 8. Normative References [NETCONF] Enns, R., "NETCONF Configuration Protocol", RFC 4741, December 2006. [NETCONF-EVENT] Chisholm, S. and H. Trevino, "NETCONF Event Notifications", ID draft-ietf-netconf-notifications-5, December 2006. [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, . [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. Chisholm & Adwankar Expires July 5, 2007 [Page 35] Internet-Draft XML Schema Usage for Netconf January 2007 Authors' Addresses Sharon Chisholm Nortel 3500 Carling Ave Nepean, Ontario K2H 8E9 Canada Email: schishol@nortel.com Sandeep Admankar Motorola 1301 East Algonquin Road MS IL02-2240 Schaumburg, Il 60196 USA Email: sandeep.adwankar@motorola.com Chisholm & Adwankar Expires July 5, 2007 [Page 36] Internet-Draft XML Schema Usage for Netconf January 2007 Full Copyright Statement Copyright (C) The Internet Society (2007). 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 & Adwankar Expires July 5, 2007 [Page 37]