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 | | , | +-------------+ +-----------------------------+ | | +-------------+ +-----------------------------+ | RPC | | , | +-------------+ +-----------------------------+ | | +-------------+ +-----------------------------+ | 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 ; or commands. A value of "delete" means it is possible to destroy instances of this element using the netconf , or operations. A value of "read" means that it is possible to view values of this element using either the or operations. A value of "write" means it is possible to modify an instance of this element using the netconf or 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 or a command or the ability to execute a , or 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". 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 [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: 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. data data datadatamaybe some Chisholm & Adwankar Expires November 10, 2005 [Page 12] Internet-Draft Framework for Netconf Data Models May 2005 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. 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. .... .... .... 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. [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. Book Information. An example of an instance of a book node is 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: 2 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. [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: 2 3 active 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 3 active 2 [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 NetConf State Schema 2001-12-17T09:30:47-05:00 Example.com ExampleName ExampleAddress http://www.example.com 0000000 Any other Info The Description of NetConf State Schema 2004-12-17T09:30:47-05:00 The first version of the schema 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 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 Chisholm & Adwankar Expires November 10, 2005 [Page 26] Internet-Draft Framework for Netconf Data Models May 2005 8.2 Replace Operation 8.3 Delete Operation //bk:book[bk:ISBN/@bk:value="0596002923"] Chisholm & Adwankar Expires November 10, 2005 [Page 27] Internet-Draft Framework for Netconf Data Models May 2005 8.4 Create Operation Chisholm & Adwankar Expires November 10, 2005 [Page 28] Internet-Draft Framework for Netconf Data Models May 2005 8.5 Get Operation /bk:Catalog/bk:book[bk:ISBN/@bk:value="0596002921"] 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, . [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]