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