Network Working Group S. Chisholm Internet-Draft Nortel Expires: October 26, 2006 S. Adwankar Motorola April 24, 2006 Framework for Netconf Content draft-chisholm-netconf-model-05.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 October 26, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This memo defines a framework for defining content for Netconf. It defines requirements to enable interoperability, extensibility, easy parsing, usability and predictable modelling. Chisholm & Adwankar Expires October 26, 2006 [Page 1] Internet-Draft Framework for Netconf Content April 2006 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 . . . . . . . . . . . . . . . . . . 8 2.6.1 Association Relationship . . . . . . . . . . . . . . . 9 2.7 Defining Event Messages . . . . . . . . . . . . . . . . . 10 2.8 Considerations for Parse-ability . . . . . . . . . . . . . 11 2.8.1 Well-formed XML . . . . . . . . . . . . . . . . . . . 11 2.9 Use an Explicit Namespace on Attributes . . . . . . . . . 12 2.10 Naming . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.11 Error Messages . . . . . . . . . . . . . . . . . . . . . . 12 2.12 Schema Documentation . . . . . . . . . . . . . . . . . . . 13 2.13 Specifying Statistics, Status and Configuration Information . . . . . . . . . . . . . . . . . . . . . . . 13 2.14 Schema Identity Information . . . . . . . . . . . . . . . 14 3. Modelling Considerations . . . . . . . . . . . . . . . . . . . 15 3.1 Modularity . . . . . . . . . . . . . . . . . . . . . . . . 15 3.2 Data Types . . . . . . . . . . . . . . . . . . . . . . . . 15 3.3 Elements and Attributes . . . . . . . . . . . . . . . . . 15 3.4 Use Container Elements for Lists . . . . . . . . . . . . . 15 3.5 Naming implications of using XPATH . . . . . . . . . . . . 16 3.5.1 Proper Tag Names . . . . . . . . . . . . . . . . . . . 17 3.6 Granularity of Data Model . . . . . . . . . . . . . . . . 17 3.7 Avoid Mixed Content . . . . . . . . . . . . . . . . . . . 17 4. Summary and Example . . . . . . . . . . . . . . . . . . . . . 19 4.1 Summary of Netconf Appinfo Elements & Attributes . . . . . 19 4.2 XML Schema for Identity appInfo . . . . . . . . . . . . . 20 4.3 XML Schema for per element appInfo . . . . . . . . . . . . 20 4.4 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 5.4 Create Operation . . . . . . . . . . . . . . . . . . . . . 29 5.5 Get Operation . . . . . . . . . . . . . . . . . . . . . . 30 5.6 Get Operation with subtree filtering . . . . . . . . . . . 31 5.7 Get All Operation . . . . . . . . . . . . . . . . . . . . 31 Chisholm & Adwankar Expires October 26, 2006 [Page 2] Internet-Draft Framework for Netconf Content April 2006 6. Security Considerations . . . . . . . . . . . . . . . . . . . 33 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 34 A. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 A.1 Access Control . . . . . . . . . . . . . . . . . . . . . . 36 A.1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . 36 A.1.2 Proposed Solution . . . . . . . . . . . . . . . . . . 36 A.2 Open Issues . . . . . . . . . . . . . . . . . . . . . . . 37 Intellectual Property and Copyright Statements . . . . . . . . 39 Chisholm & Adwankar Expires October 26, 2006 [Page 3] Internet-Draft Framework for Netconf Content April 2006 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 defines 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. 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 October 26, 2006 [Page 4] Internet-Draft Framework for Netconf Content April 2006 2. Requirements This section describes some restrictions on Netconf content and the specifications that describe 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 Chisholm & Adwankar Expires October 26, 2006 [Page 5] Internet-Draft Framework for Netconf Content April 2006 there is a side 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 Chisholm & Adwankar Expires October 26, 2006 [Page 6] Internet-Draft Framework for Netconf Content April 2006 documentation tag. Examples of additional conformance information that may be useful to provide includes how implementations can specify specific exceptions to required conformance, dependencies between elements (in order to do A, you need to first do B) and conditional conformance (if BGP, then ...). 2.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 October 26, 2006 [Page 7] Internet-Draft Framework for Netconf Content April 2006 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.] 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 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 Chisholm & Adwankar Expires October 26, 2006 [Page 8] Internet-Draft Framework for Netconf Content April 2006 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 October 26, 2006 [Page 9] Internet-Draft Framework for Netconf Content April 2006 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 Event Messages 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, 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 Chisholm & Adwankar Expires October 26, 2006 [Page 10] Internet-Draft Framework for Netconf Content April 2006 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 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. Chisholm & Adwankar Expires October 26, 2006 [Page 11] Internet-Draft Framework for Netconf Content April 2006 2.9 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. 2.10 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.11 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 October 26, 2006 [Page 12] Internet-Draft Framework for Netconf Content April 2006 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.12 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.13 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 October 26, 2006 [Page 13] Internet-Draft Framework for Netconf Content April 2006 configuration [Editor's Note: Test on existing data models?] 2.14 Schema Identity Information Replacing the following with something from Dublin Core (http://dublincore.org) is for further study. A schema must contain a schema Identity annotation as part of the appinfo on the highest level schema element. 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 October 26, 2006 [Page 14] Internet-Draft Framework for Netconf Content April 2006 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 October 26, 2006 [Page 15] Internet-Draft Framework for Netconf Content April 2006 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 October 26, 2006 [Page 16] Internet-Draft Framework for Netconf Content April 2006 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 October 26, 2006 [Page 17] Internet-Draft Framework for Netconf Content April 2006 data data datadatamaybe some Chisholm & Adwankar Expires October 26, 2006 [Page 18] Internet-Draft Framework for Netconf Content April 2006 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 | | identity | | Mandatory | | eventClass | | Optional | | dataType | | Optional | -------------------------------------- Figure 17 Chisholm & Adwankar Expires October 26, 2006 [Page 19] Internet-Draft Framework for Netconf Content April 2006 4.2 XML Schema for Identity appInfo 4.3 XML Schema for per element appInfo Chisholm & Adwankar Expires October 26, 2006 [Page 20] Internet-Draft Framework for Netconf Content April 2006 This is a set of information that can be applied to any element. Chisholm & Adwankar Expires October 26, 2006 [Page 21] Internet-Draft Framework for Netconf Content April 2006 4.4 Managed Object Example An example of a node that describes a system description is shown below. . This element defines information about books 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 Chisholm & Adwankar Expires October 26, 2006 [Page 23] Internet-Draft Framework for Netconf Content April 2006 The author of this book. current The year this book was published current The last issue date for this book. current Chisholm & Adwankar Expires October 26, 2006 [Page 24] Internet-Draft Framework for Netconf Content April 2006 The average review for this book. current An example of an instance of a book node is XYZ 0000000123 ABC 2005 2005-02-02 5 Chisholm & Adwankar Expires October 26, 2006 [Page 25] Internet-Draft Framework for Netconf Content April 2006 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 October 26, 2006 [Page 26] Internet-Draft Framework for Netconf Content April 2006 5.2 Replace Operation RPC Request : replace NetMod for Dummies: Part2 0596002924 NetMod Experts 2003 2003-10-15 1 RPC Reply : Chisholm & Adwankar Expires October 26, 2006 [Page 27] Internet-Draft Framework for Netconf Content April 2006 5.3 Delete Operation RPC Request : RPC Reply : Chisholm & Adwankar Expires October 26, 2006 [Page 28] Internet-Draft Framework for Netconf Content April 2006 5.4 Create Operation RPC Request : replace NetMod for Dummies: Part6 0596002 NetMod Experts 2003 2003-10-15 1 RPC Reply : Chisholm & Adwankar Expires October 26, 2006 [Page 29] Internet-Draft Framework for Netconf Content April 2006 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 October 26, 2006 [Page 30] Internet-Draft Framework for Netconf Content April 2006 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 October 26, 2006 [Page 31] Internet-Draft Framework for Netconf Content April 2006 unlocked unlocked 6 Bob 2:56:01 PM NetMod for Dummies: Part2 0596002924 NetMod Experts 2003 2003-10-15 1 Chisholm & Adwankar Expires October 26, 2006 [Page 32] Internet-Draft Framework for Netconf Content April 2006 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 October 26, 2006 [Page 33] Internet-Draft Framework for Netconf Content April 2006 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 Enns, Faye Ly, Andre Westerinen, Orly Nicklass, Alexander Clemm, Keith McCloghrie, Hector Trevino , James Balestriere Simon Leinen and Ladislav Lhotka. 8. 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 3500 Carling Ave Nepean, Ontario K2H 8E9 Canada Email: schishol@nortelcom Chisholm & Adwankar Expires October 26, 2006 [Page 34] Internet-Draft Framework for Netconf Content April 2006 Sandeep Admankar Motorola 1301 East Algonquin Road MS IL02-2240 Schaumburg, Il 60196 USA Email: sandeep.adwankar@motorola.com Chisholm & Adwankar Expires October 26, 2006 [Page 35] Internet-Draft Framework for Netconf Content April 2006 Appendix A. Appendix A.1 Access Control A.1.1 Overview For discussing access control, we shall use the same equivalence classes for operations on managed objects: "Create", "Delete", "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. [Editor's Note: What about permission to traverse through a hierarchy? This naturally imparts information about the hierarchy that might allow a user to gleam things they should not. 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 SNMP and CLI. Ideally the security model used in netconf is integratable with well- deployed solutions like RADIUS and TACACS+. Netconf may only need a mechanism to report information about access control and an API to enable easy integration to an existing solution. A.1.2 Proposed Solution [Editors Note: This area is for further study. Which bits belong in Chisholm & Adwankar Expires October 26, 2006 [Page 36] Internet-Draft Framework for Netconf Content April 2006 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.] A solution will need to identify the type off access that is permitted, profile an identifier for this instance of access permissions and potentially identify a timeframe that this access is good for. This access would then need to be associated with particular class and instance data, as described above. A.2 Open Issues What happens when we are importing from other organizations, and they have different rules. This needs to be thought through for version, backwards compatibility, mixed model, etc to ensure this won't cause any problems. Do we actually needed minAccess and maxAccess or can it be deleted. It was suggested that it could be added back later if it was determined to be necessary. Some people felt that conformance, even run-time indication of what is actually supported, was important. Others felt it didn't work well in SNMP, so perhaps native minOccurs/ maxOccurs would be sufficient. It was suggested that it might be more interesting to distinguish between state, statistics and configuration when defining data rather than providing min and max access. Around section 2.5.1, there was discussion about whether keys could change over time (across reboots, if cards moved, etc) and if so, if perhaps some other less meaningful but more permanent index was also useful. There were some concerns raised about the usability of these Chisholm & Adwankar Expires October 26, 2006 [Page 37] Internet-Draft Framework for Netconf Content April 2006 sort of arbitrary number indices. There was also discussion about the difference between internal and external identifiers - those generated by the system and those input from external systems. The latter will not change unless the user actually wants it to change. Chisholm & Adwankar Expires October 26, 2006 [Page 38] Internet-Draft Framework for Netconf Content April 2006 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 (2006). 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 October 26, 2006 [Page 39] Internet-Draft Framework for Netconf Content April 2006 Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Chisholm & Adwankar Expires October 26, 2006 [Page 40]