Network Working Group M. Bjorklund, Ed. Internet-Draft Tail-f Systems Intended status: Informational February 18, 2008 Expires: August 21, 2008 YANG's Compliance with Respect to Various Requirements Documents draft-bjorklund-yang-requirements-00 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 21, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Bjorklund Expires August 21, 2008 [Page 1] Internet-Draft YANG February 2008 Abstract This draft addresses requirements for a NETCONF data modeling language and how the YANG Modeling Language proposes to fulfill these requirements or specifically chooses not to. Requirements have been gathered from multiple documents and each document's requirements are handled in a separate section in this draft. This draft also explains some of the design choices behind YANG. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. The case for YANG . . . . . . . . . . . . . . . . . . . . . . 4 2.1. YANG - Wir koennen nicht anders! . . . . . . . . . . . . . 4 2.2. YANG - Solving "the configuration problem" . . . . . . . . 5 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Requirements from draft-presuhn-rcdml-01 . . . . . . . . . 8 3.1.1. Agreed . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1.2. "NOT Agreed" with which YANG complies . . . . . . . . 19 3.1.3. "NOT Agreed" with which YANG does not comply (or not determined) . . . . . . . . . . . . . . . . . . . 21 3.2. Requirements from RFC 3139 . . . . . . . . . . . . . . . . 22 3.3. Requirements from RFC 3216 . . . . . . . . . . . . . . . . 25 3.3.1. Accepted objectives . . . . . . . . . . . . . . . . . 25 3.3.2. Nice-to-have objectives . . . . . . . . . . . . . . . 30 3.3.3. Rejected objectives . . . . . . . . . . . . . . . . . 31 3.4. Requirements from draft-linowski-netconf-dml-requirements-00 . . . . . . . . 32 4. YANG DHCP Module . . . . . . . . . . . . . . . . . . . . . . . 36 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 6. Security Considerations . . . . . . . . . . . . . . . . . . . 42 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 43 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44 8.1. Normative References . . . . . . . . . . . . . . . . . . . 44 8.2. Non-Normative References . . . . . . . . . . . . . . . . . 44 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 45 Intellectual Property and Copyright Statements . . . . . . . . . . 46 Bjorklund Expires August 21, 2008 [Page 2] Internet-Draft YANG February 2008 1. Introduction This draft details YANG's [YANG] compliance with respect to a list of requirements for a data modeling language for NETCONF. The requirements have been put together from multiple documents that represent the IETF's current collected understanding of what a data modeling language for NETCONF must be able to do. Bjorklund Expires August 21, 2008 [Page 3] Internet-Draft YANG February 2008 2. The case for YANG On the last day of the 68th IETF in Prague, a small band of NETCONF veterans assembled over breakfast and talked about the need for a simple modeling language for NETCONF. This was an area where NETCONF was failing to make forward progress, putting the future of NETCONF at risk. We compared our experience implementing in-house tools for our proprietary NETCONF engines and found that we had all reached similar solutions to the problem. The areas of overlap and similarities were immense, and we began work on a proposal that built on our experiences, picking the "best of breed" feature from our existing solutions, and tailoring them into a consistent language that is as powerful as it is simple. This document, together with the [YANG] specification, explain the needs and benefits of this "second generation" data modeling language. 2.1. YANG - Wir koennen nicht anders! YANG is designed specifically for use with NETCONF. While it might be useful for data modeling in other contexts, that is not the focus of this work. Our perception is that there is a very serious problem to be solved: we have a protocol ([RFC4741]) for configuration, but we have no standardized way to define the models for that which we are going to configure, much less models themselves. Without timely forward progress in this area, NETCONF cannot service the needs of the network management community, and will quickly move lose what momentum remains. YANG aims to fill that gap by providing NETCONF what the SMI ([RFC2578]) gives the SNMP-based framework. YANG has a strong heritage. YANG is based on languages used actively for development of NETCONF-based management systems in products today. As such, the design of YANG is based heavily on requirements placed upon those languages by their users and the experience of writing NETCONF data models in the vendor-specific languages from which much of YANG was derived. Real world usage is the best way to understand requirements and YANG takes advantage of years of real world usage from these internal tools, building on their requirements and their solutions to complex issues in data modeling. YANG is designed to give priority to data model readers. The readers and reviewers of data models need insight into the organization, constraints, and meaning of its elements. The reader of a YANG module can easily see the high-level view of the data model while seeing how the object will be encoded in NETCONF operations. While YANG models the data content, the XML rendering of this content is very apparent. Bjorklund Expires August 21, 2008 [Page 4] Internet-Draft YANG February 2008 YANG has a history that demonstrates the need for a new language. During previous proprietary implementations that were input to YANG, developers realized that models written in existing languages (specifically XSD, RelaxNG) were very difficult both to read and write, so the languages were based on something "home grown" designed for the developers who would be writing models and implementing them on devices. Given that experience, YANG's syntax was chosen specifically for its readability, since YANG values the time and effort of the readers of models above those of modules writers and YANG tool-chain developers. Above all, the users of NETCONF models (operators) were given highest priority in YANG's design. 2.2. YANG - Solving "the configuration problem" NETCONF and YANG are all about solving "the configuration problem", a problem that is not simple. The history of network management (and configuration management in particular) over the last 20 years clearly demonstrates the industry's failure to provide interoperable, multi-vendor configuration tools. It is instructive to understand some of the factors that make configuration a difficult problem, as the modeling language for NETCONF should do all that it can to alleviate these difficulties. In designing configuration for a complex device, you have a number of goals: o Avoid human error: design the configuration to make errors detectable in software, and observable in "show" output. o Avoid misunderstanding: If the syntax/semantics of the modeling language is not simple enough, operators/readers will definitely make mistakes during configuration. If its complicated it is unusable even if it works. o Be flexible: customer deployment scenarios always exceed your vision when you design something. Allowing for these cases is both important and painful. o Complexity reduction: if it's complex to configure, it won't get deployed. And even if it does get deployed, the support costs for both the customer and the vendor will be high. o Details should be hidden where possible: the user shouldn't need to fully understand hardware, software, or protocol issues to configure them. o Enhancement/future proofing: this configuration needs to work on next year's hardware running next year's software, often running Bjorklund Expires August 21, 2008 [Page 5] Internet-Draft YANG February 2008 next year's protocols. o Full feature support: the configuration needs to fully represent the available features your hardware and software support. o Be consistent: make it fit inside the rules and conventions of your existing syntax. o Holistic view: the configuration should look like a single description of a complete system. o Easy to learn: If its complicated, people never learn it. In striving for simplification, many of these goals are in conflict with one other. For example, in trying to be flexible, one must decide when an odd configuration is an error and when the user is just doing something clever (which may be an error, but is an intentional one). In standardization, the goals are often completely different. Expressiveness and accuracy win over simplicity. A single complex method of configuration wins over a dual "common" and "advanced" approach. The model for a standard must be something that can support all platforms, which leads to complexity, and the translation between the standard's complex model and the unique abilities of individual platforms is non-trivial. An example is packet filtering, where the device configuration is more often dictated by the hardware architecture and the layout of that hardware (in terms of where packets can be filtered, what can be filtered on, what can be done to them at that layer, and what resources are consumed) is often directly visible in the configuration in order for the customer to express their desired setup. A standard, on the other hand, needs a model that is "bigger" than one vendor's solution, where any sort of filtering can be done at any place with any outcome without concern for resource impact. No vendor will implement such a model, and the translation between the model and the device configuration requires understanding the performance versus resource utilization tradeoffs that the customer is willing to make. For example, some functionality may be available in hardware at wire rate, other in hardware at lower speed, other in dedicated CPUs, and still other in the main CPU. Choosing the proper filtering point is a matter of both the speed and abilities of that point, plus chip memory and other contention issues. And getting a correct assignment Bjorklund Expires August 21, 2008 [Page 6] Internet-Draft YANG February 2008 will still be wrong if it's not the assignment the customer wanted. This translation must be performed in a way that avoids letting small changes in the configuration turn into large configuration changes on the device. This is not an easy problem, but is key to device- independent configuration. The problem isn't getting a few knobs to configure basic functionality, but getting a solution that's complete enough to give folks sufficient faith to move toward it. If it solved 20% of the problem, it's worthless. When it solves 80-90% of the problem, it's interesting. NETCONF gives us the ability to manipulate configuration in XML, which is a good first step. With YANG, we now have the ability to define that XML in a way that allows extensibility and the expression of device-specific content, which is a good second step. The next step will be a translation framework that allows robust translation between a standard view and a device-specific view. Bjorklund Expires August 21, 2008 [Page 7] Internet-Draft YANG February 2008 3. Requirements The following sections address requirements from various internet drafts and RFCs. For each document, the requirements are named by section and title (if available) or with a short summary of the requirement. For a full explanation of the requirement, see the source document. For each requirement, we state: o If YANG is compliant o If so, we identify the mechanism in YANG that fulfills the requirement o If not, we explain why YANG is not compliant 3.1. Requirements from draft-presuhn-rcdml-01 [PRESUHN], "Requirements for a Configuration Data Modeling Language", has the following requirements. They are listed by section number in [PRESUHN] and divided into two lists. The first list is all of the requirements that the requirements design team reached rough consensus on. The second list is those where rough consensus was NOT reached. For both of these lists, YANG states its compliance with respect to the requirement and provides additional commentary as deemed necessary. The text explaining the requirements themselves are not reproduced here. RFC 3139 and RFC 3216 Considerations are handled separately. 3.1.1. Agreed YANG complies with all Agreed requirements. o 3.1.1. Notification Definition (Agreed) Supported with the "notification" statement. Bjorklund Expires August 21, 2008 [Page 8] Internet-Draft YANG February 2008 notification link-failure { description "A link failure has been detected"; leaf if-index { type int32 { range "1 .. max"; } } leaf if-name { type keyref { path "/interfaces/interface/name"; } } } o 3.1.3. Locking (Agreed) YANG does not impose any restrictions for partial locking. o 3.1.4. All Base Operations (Agreed) The YANG specification explicitly details how all operations work for the data definition statements. All YANG data definition statements define either configuration or non-configuration data, supporting the and operations of NETCONF. o 3.1.5. Define new NETCONF Operations (Agreed) New NETCONF operations, vendor-specific or standard, are defined with the "rpc" statement. This statement covers input parameters, the result and semantics of the operation. rpc activate-software-image { description "Activate a new software image " + "(upgrade or downgrade)"; input { leaf image-name { description "Local file name of the incoming image"; type string; } } output { leaf status { description "Status string returned by the new software"; type string; } } } Bjorklund Expires August 21, 2008 [Page 9] Internet-Draft YANG February 2008 Operations defined in YANG can be extended by vendors with extra information with the "augment" statement. augment /rpc/activate-software-image/input { vend1:custom-flag true; } o 3.1.6. Separation of Operations and Payload (Agreed) The "rpc" statement is clearly separated from the data definition statements in YANG. The operation name appears as the argument to the "rpc" statement, while the input payload appears in the "input" statement. Output payload appears in the "output" statement. o 3.1.7. Error Annotation (Agreed) YANG allows the user to define the error-app-tag and the error- message NETCONF elements both for common constraints like range and for specific constraints defined using the "must" statement. leaf cell-count { type uint32; must "ifType == 'atm'" { error-message "'cell-count' is only valid for ATM interfaces"; error-app-tag invalid-interface-type; } } NETCONF-specific error information (error-message and error-app-tag) can be assigned to statements that put syntactic and semantic restrictions on the data model. o 3.1.8. No Mixed Content (Agreed) YANG does not provide a mechanism to define mixed XML content. o 3.2.1. Human Readable (Agreed) The YANG syntax is similar to that of SMIng [RFC3780] and programming languages like C and C++. This C-like syntax was chosen specifically for its readability and conciseness, since YANG values the time and effort of the readers of models above those of modules writers and YANG tool-chain developers. Bjorklund Expires August 21, 2008 [Page 10] Internet-Draft YANG February 2008 o 3.2.2. Machine Readable (Agreed) YANG has a few, simple syntactical rules which are easy to parse for tools. YANG also supports an equivalent XML-based syntax called YIN, which can be used to feed into standard XML tools such as XSLT script. All YANG statements are of the following format: stmt -> keyword argument? ( ';' | '{' stmt-list '}' ) stmt-list -> null | stmt-list stmt This simple syntax allows the creation of parsers using a trivial state machine, rather than needing traditional compiler tools. o 3.2.3. Textual Representation (Agreed) YANG models are represented as text. They can be built in a normal editor, sent via email, saved in cvs or svn repositories, diffed, grepped, or handled in any manner used on MIBs. YANG supports a string concatenation operator which can be used to split long strings into multiple lines, supporting inclusion of YANG model in 72 column RFCs. An example is the IPv4 regular expression: pattern '(([0-1]?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])\.){3}' + '([0-1]?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])' + '(%[\p{N}\p{L}]+)?'; o 3.2.4. Document Information (Agreed) YANG supports the "organization", "contact", "revision", "description", and "reference" statements for modules. Bjorklund Expires August 21, 2008 [Page 11] Internet-Draft YANG February 2008 // Contents of "acme-system.yang" module acme-system { namespace "http://acme.example.com/system"; prefix "acme"; organization "ACME Inc."; contact "joe@acme.example.com"; description "The module for entities implementing the ACME system."; revision 2007-06-09 { description "Initial revision."; } ... } o 3.2.5. Ownership and Change Control (Agreed) YANG is owned and defined by IETF. It depends on some W3C technologies - XML basics, namespaces - and IEEE data types. YANG depends only on a limited set of stable external standards to avoid problems with future versions of these specifications e.g. XSD 1.1. o 3.2.6. Dependency Risk Reduction (Agreed) YANG has minimal dependencies on external standards. The exact revisions of the standards are specified in the YANG specification. o 3.2.7. Diff-Friendly (Agreed) Because of its simple syntax, a YANG module is diff- and email- friendly. @@ -62,10 +62,12 @@ } typedef direction-type { + description "Which direction of traffic is requested?"; type enumeration { enum ingress; enum egress; enum both; + enum neither; } } Bjorklund Expires August 21, 2008 [Page 12] Internet-Draft YANG February 2008 o 3.2.8.1. Descriptions using Local Languages (Agreed) YANG supports Unicode text in the data model definitions. o 3.2.8.2. UTF-8 Encoding (Agreed) YANG supports UTF-8. YANG modules are written in the UTF-8 [RFC3629] character set. o 3.2.8.3. Localization Support (Agreed) While many YANG text statements ("description", "reference", etc) are targeted at the reader and implementer, not the end user, the reality is that these strings are commonly placed before users in generic browsers. Internationalization of these strings can be performed using extensions, such as: leaf trunk-status { type string; description "The status of the trunk"; i18n:description "en_GB:The condition of the boot"; i18n:description "sv_SE:Trunkens nuvarande tillstaand"; } o 3.2.8.4. Error String Localization (Agreed) YANG explicitly lists the app-tags and messages of generated messages, allowing applications to translate between the values sent over the wire and catalogs of localized messages. o 3.3.1. Modularity (Agreed) YANG supports a flexible modularization mechanism. YANG structures data models into modules and submodules. A module can import data from other external modules, and include data from submodules. The hierarchy can be extended, allowing one module to add data nodes to the hierarchy defined in another module. This augmentation can be conditional, with new nodes to appearing only if certain conditions are met. o 3.3.2. Reusable Definitions (Agreed) YANG supports reusable simple (scalar) types with the "typedef" statement, and reusable structures with the "grouping" statement. Bjorklund Expires August 21, 2008 [Page 13] Internet-Draft YANG February 2008 typedef percent { type uint16 { range "0 .. 100"; } description "Percentage"; } leaf completed { type percent; } grouping target { leaf address { type inet:ip-address; description "Target IP address"; } leaf port { type inet:port-number; description "Target port number"; } } container peer { container destination { uses target; } } o 3.3.3. Modular extension (Agreed) A published YANG module can be extended from another module with the "augment" statement. This statement allows for very flexible extensions, where the original module does not have to be explicitly designed for specific extensibility. With the "augment" statement, YANG fully utilizes the flexible extensibility of XML with namespaces. A module can extend the data model defined in another module using the "augment" statement. Augmentation allows flexible extensions to existing modules without forcing the original module to explicitly allow for such extensibility. Augmented nodes are encoded in the XML namespace of the augmenting module, avoiding ambiguity and conflicts. o 3.4.1. Default Values on the Wire (Agreed) In YANG modules, leafs can have default values. YANG supports NETCONF protocol extensions such as "with-defaults" which control how Bjorklund Expires August 21, 2008 [Page 14] Internet-Draft YANG February 2008 defaults are sent over the wire. In YANG modules, leafs can have default values. Defaults need not be transmitted on the wire since both client and server understand the impact of such defaults. YANG supports NETCONF protocol extensions such as "with-defaults" which control how defaults are sent over the wire. o 3.4.2.1. Ordered Lists (Agreed) Lists can be declared as "ordered-by user" which specifies that the order has semantic significance, or "ordered-by system" which specifies that the order of the list entries has no semantic meaning. o 3.4.3.1. Validate Instance Data (Agreed) The ABNF grammar and general tokenization rules specifies what a valid module looks like on a syntactic level. The semantic meaning is defined in the description of the statements. o 3.4.4. Instance Canonicalization (Agreed) This is work to be done. Canonicalization of the XML follows the rules defined in [RFC3076]. o 3.4.5. Character Set and Encoding (Agreed) YANG supports models defined in UTF-8. o 3.5.1. Human-Readable Semantics (Agreed) YANG supports the "description" statement as a way to describe additional semantics to a definition. The "description" statement is supported on almost all statements, including individual enumerated values and bits (which was a problem in SMI). Furthermore, the statement is supported in YANG extensions. o 3.5.2. Basic Types (Agreed) YANG has a set of built-in types, similar to those of many programming languages, but with some differences due to special requirements from the management information model. Most built-in types have a direct mapping to XSD types. o 3.5.3. Handling Opaque Data (Agreed) Non-YANG XML data is supported with the "anyxml" statement. Bjorklund Expires August 21, 2008 [Page 15] Internet-Draft YANG February 2008 anyxml contents { description "Contains the unfiltered contents of some XML thing"; } o 3.5.4.1. Define Keys (Agreed) A list used for configuration data must have keys in YANG. list user { key "name"; leaf name { type string; } leaf full-name { type string; } leaf class { type string; } } o 3.5.5.1. Simple Relationships (Agreed) The "keyref" statement is used to formally define 1:1 and 1:n relationships in YANG models. These formal machine readable relationships can cross module boundaries. notification link-failure { description "A link failure has been detected"; leaf if-index { type int32 { range "1 .. max"; } } leaf if-name { type keyref { path "/interfaces/interface/name"; } } } o 3.5.6. Hierarchical Data YANG supports the definition of hierarchical data. o 3.5.8. Characterize Data (Agreed) Each data object in a YANG module is either defined as configuration or non-configuration, with the "config" statement. Bjorklund Expires August 21, 2008 [Page 16] Internet-Draft YANG February 2008 leaf observed-speed { type uint32; config false; } o 3.5.10.1. Formal Description of Constraints (Agreed) Constraints local to scalar objects are supported with restrictions on the type. YANG supports "range", "length" and "pattern" restrictions. type union { type int { range 0..15; } type string { length 5..10; pattern "full.*"; } } Uniqueness is controlled with the "unique" statement, as discussed in the next section. o 3.5.10.3. Non-Key Uniqueness (Agreed) A common type of constraint is uniqueness constraints, i.e. the ability to specify that within some context, the values of some objects must be unique across all instances. YANG supports this with the "unique" statement. list server { key "name"; unique "ip port"; leaf name { type string; } leaf ip { type inet:ip-address; } leaf port { type inet:port-number; } } Bjorklund Expires August 21, 2008 [Page 17] Internet-Draft YANG February 2008 o 3.5.11. Units (Agreed) YANG supports associating units with values or derived types with the "units" statement. leaf max-lease-time { type uint32; units seconds; } o 3.6.1.1. Language Versioning (Agreed) The YANG language is versioned with the "yang-version" statement. yang-version 1; o 3.6.2.1. Model Version Identification (Agreed) A YANG module has a revision, and the revision number is reported as part of the schema discovery process. revision "2007-06-09" { description "Initial revision."; } o 3.6.2.4. Obsolete Portions of a Model (Agreed) YANG uses the well-known STATUS clause from SMI, with the "status" statement. The meaning is the same as in the SMI. status deprecated; o 3.6.3.3. Backwards Compatibility (Agreed) YANG supports module revisions while allowing backwards compatibility. The rules controlling such changes remains work to be done. o 3.7.2. Conformance to a Model (Agreed) In the current version of YANG, conformance is on the module level. Support for finer-grained conformance is work to be done. In designing this feature, it is important to learn from the experience with AGENT-CAPABILITIES in SMIv2. Bjorklund Expires August 21, 2008 [Page 18] Internet-Draft YANG February 2008 o 3.7.2.2. Server Conformance to Schema (Agreed) Since the conformance in YANG is on module level, a server that claims conformance to a module must implement the entire module. o 3.8.2. Translate Models to Other Forms (Agreed) YANG models can be translated to XSD or RelaxNG, if needed. The XSD translation is implemented in one open source tool. Since a YANG module contains much more information than the XML grammar supported by these languages, the transformation to standard XSD or RelaxNG will be lossy. As a simple example, the information if an object represents configuration can not be expressed in standard XSD and RelaxNG. Since both these languages support user-defined annotations, the missing information can be encoded in non-standard user-defined annotations. 3.1.2. "NOT Agreed" with which YANG complies YANG complies with the following "NOT Agreed" requirements. o 3.4.3.2. Tools to Validate Instance Data (NOT Agreed) There is currently one open-source tool available to validate YANG modules, and at least two more open-source tools are being worked upon. o 3.5.9.1. Default Values (NOT Agreed) YANG supports default values. Any leaf node can specify a static default using the "default" statement. default 1024; o 3.5.10.2. Multi-element Constraints (NOT Agreed) We believe that there is a value in having formal descriptions of integrity constraints. One reason is that with formal descriptions, interoperability is easier to achieve. Another reason is that tools can reduce the implementation effort of data models. We also believe that there is a balance between the expressiveness and usefulness of formal descriptions - if the formal definition of a constraint is too complex to read, a textual description might be more appropriate. YANG supports XPath based constraints. XPath is a fairly simple language (in its expressiveness), but covers many common use cases. More complex constraints are defined in description clauses. Bjorklund Expires August 21, 2008 [Page 19] Internet-Draft YANG February 2008 must "ifType != ethernet or " + "(ifType = ethernet and ifMTU = 1500)" { error-message "An ethernet MTU must be 1500"; } o 3.5.7.1. Referential Integrity (NOT Agreed) YANG supports formal referential integrity constraints with the "keyref" statement. leaf mgmt-interface { type keyref { path "../interface/name"; } } o 3.6.1.2. User Extensions (NOT Agreed) YANG supports user-defined extensions to the language itself. To define an extension: module my-extensions { ... extension c-define { description "Takes as argument a name string. Makes the code generator use the given name in the #define."; argument "name"; } } To use the extension: module my-interfaces { ... import my-extensions { prefix "myext"; } ... container interfaces { ... myext:c-define "MY_INTERFACES"; } } Bjorklund Expires August 21, 2008 [Page 20] Internet-Draft YANG February 2008 o 3.6.1.3. Mandatory Extensions (NOT Agreed) We believe that this is a bad idea, since it will break backwards compatibility. Marking an extension as "must-understand" would be necessary when the existing semantics of a definition has been altered in a backwards incompatible way. We believe it is a feature to not allow extensions that modifies the semantics in such a way. o 3.6.3.5. Must-Understand Model Extensions (NOT Agreed) See above. o 3.8.3. Minimize SMI Translation Pain (NOT Agreed) To the extent possible, YANG maintains compatibility with SNMP's SMIv2 (Structure of Management Information version 2 [RFC2578], [RFC2579]). SMIv2-based MIB modules can be automatically translated into YANG modules for read-only access. However YANG is not concerned with reverse translation from YANG to SMIv2. 3.1.3. "NOT Agreed" with which YANG does not comply (or not determined) This section lists those "NOT Agreed" requirements with which YANG either does not comply or no determination of compliance has yet been made. o 3.1.2. Notification Get (NOT Agreed) o 3.2.8.5. Tag Names and Strings in Local Languages (NOT agreed) o 3.4.2.2. Order within Containers (NOT Agreed) o 3.4.2.3. Interleaving (NOT Agreed) o 3.4.6. Model Instance Localization (NOT Agreed) o 3.5.4.2. Deep Keys (NOT Agreed) o 3.5.5.2. Many-to-Many Relationships (NOT Agreed) o 3.5.5.3. Retrieve Relationships instance (NOT Agreed) o 3.5.5.4. Retrieve Relationships - qualified (NOT Agreed) o 3.5.7.2. Extended Referential Integrity (NOT Agreed) o 3.5.7.3. Referential Integrity Robustness (NOT Agreed) Bjorklund Expires August 21, 2008 [Page 21] Internet-Draft YANG February 2008 o 3.5.9.2. Dynamic Defaults (NOT Agreed) o 3.5.12. Define Actions (NOT Agreed) o 3.6.2.2. Interaction with defaults (NOT Agreed) o 3.6.2.3. Conformance Interference (NOT Agreed) o 3.6.3.1. Schema Version of Instance (NOT Agreed) o 3.6.3.2. Interaction with default Values (NOT Agreed) o 3.6.3.4. Forwards Compatibility (NOT Agreed) o 3.7.1. Conformance to the Modeling Language (NOT Agreed) o 3.7.2.1. Conditional Conformance (NOT Agreed) o 3.7.2.3. Client Conformance To Schema (NOT Agreed) o 3.7.2.4. Versioned Conformance (NOT Agreed) o 3.8.1. Standard Technology (NOT Agreed) o 3.8.4. Generate Models from Other Forms (NOT Agreed) o 3.8.5. Isolate Models from Protocol (NOT Agreed) o 3.8.6. Library Support (NOT Agreed) 3.2. Requirements from RFC 3139 [RFC3139], "Requirements for Configuration Management of IP-based Networks", lists requirements in Section 3.0, "Requirements for an IP-based Configuration Management System". In this document, only the number in that section and a brief summary are reproduced. o 1): higher level of abstraction Network-wide configuration is very difficult to achieve. Many system components beyond the data modeling language impact the design of such an application. YANG provides a consistent and interoperable definition of NETCONF content independent of any one device, which is an important component of a network-wide configuration management system. Bjorklund Expires August 21, 2008 [Page 22] Internet-Draft YANG February 2008 o 2): translating network-wide configurations into device-local configuration YANG supports language extensions, which can be added by an application to data model files to identify conceptual data definitions which vary in implementation on specific platforms. YANG will soon support NETCONF capabilities, which can be used to partition data model definitions in device-specific ways. YANG can also be translated to YIN, and then manipulated with XSLT scripts, to construct device-specific variants of network-wide configurations. o 3): interpret device-local configuration This is an application requirement, not related to the data modeling language. YANG does not have any specific constructs that differentiate between network-wide and device-specific configurations. o 4): provisioning complete or partial configuration data to network devices simultaneously or in a synchronized fashion This is a protocol requirement, not related to the data modeling language. Transfer of configuration data in this manner is supported by the NETCONF protocol. o 4a): provision multiple device-local configurations This is a protocol requirement, not related to the data modeling language. Transfer of configuration data in this manner is supported by the NETCONF protocol. o 5): means by which network devices can send feedback This is a protocol requirement, supported by the NETCONF protocol. o 6): provisioning complete or partial configuration data to network devices dynamically This is an application requirement, supported by the NETCONF protocol. o 7): efficient and reliable means to provision large amounts of configuration data This is a protocol requirement, supported by the NETCONF protocol. Bjorklund Expires August 21, 2008 [Page 23] Internet-Draft YANG February 2008 o 8): secure means to provision configuration data This is a transport requirement, supported by the NETCONF protocol stack. o 9): provide expiration time and effective time capabilities to configuration data This is a protocol and possibly data model requirement. NETCONF does not support configuration expire times. o 10): provide error detection and failure recovery mechanisms NETCONF provides extensive error information, which can include content-layer specific fields. YANG supports the definition of data- model specific error information, which an agent can return in these fields. o 11): eliminate the potential for mis-configuration occurring through concurrent shared write access This is a protocol requirement, supported by the NETCONF protocol. o 12): help in tracing back configuration changes This is a protocol and possibly data model requirement. NETCONF does not support configuration change history traceback explicitly, but the mechanisms exist in the protocol to support this feature. o 13): allow for the use of redundant components This is a platform-specific feature, not related to the data modeling language. o 14): be flexible and extensible to accommodate future needs YANG supports language extensions, language versioning, and augmentation of data models defined in existing documents. o 15): leverage knowledge of the existing SNMP management infrastructure YANG is based in part on SMIng and SMIv2, and includes as many familiar concepts from SNMP data modeling as possible. YANG is designed to extend SMIv2, not throw it out and start over. Bjorklund Expires August 21, 2008 [Page 24] Internet-Draft YANG February 2008 3.3. Requirements from RFC 3216 [RFC3216], "SMIng Objectives", divides its objectives into three categories: accepted, nice-to-have, and rejected. 3.3.1. Accepted objectives o 4.1.1 The Set of Specification Documents YANG is specified in one document. o 4.1.2 Textual Representation YANG uses a textual representation. o 4.1.3 Human Readability It is easy for humans to read and write YANG modules. Many features, such as string formatting, string concatenation, and small set of language tokens, are included for ease-of-use. o 4.1.4 Rigorously Defined Syntax The YANG language is fully specified using ABNF. o 4.1.5 Accessibility Protocol accessibility is built into certain YANG constructs, such as 'rpc' or 'notification'. NETCONF data access is controlled with several language constructs, such as the 'config' and 'mandatory' statements. o 4.1.6 Language Extensibility YANG supports language extensions. o 4.1.7 Special Characters in Text YANG provides full support of UTF-8 strings and many special characters can be inserted in strings. o 4.1.8 Naming YANG supports complete instance naming using the Xpath language. Indexed lists are supported as well. Bjorklund Expires August 21, 2008 [Page 25] Internet-Draft YANG February 2008 o 4.1.9 Namespace Control YANG allows full control of XML namespace usage within a data model. o 4.1.10 Modules YANG supports modular definitions, and self-consistent sub-modules as well. o 4.1.11 Module Conformance YANG only supports full module conformance at this time. Work is under-way to add NETCONF capability based conformance and other mechanisms to support partial module conformance. o 4.1.12 Arbitrary Unambiguous Identities YANG includes the 'instance-identifier' built-in data-type, which can be used for XML the way an OBJECT IDENTIFIER is used in SNMP. o 4.1.13 Protocol Independence YANG is not protocol independent. It is designed to fully support definition of the NETCONF content layer, allowing interoperable manipulation of network configuration data. YANG does not support SNMP or COPS-PR. o 4.1.14 Protocol Mapping YANG does not provide mechanisms to manually map data model constructs to arbitrary protocols. Experience gained in the SMING WG suggests that it is too difficult to maintain separate data model files, or sections within a file, in order to split definitions into a protocol independent section and 1 or more protocol-dependent sections, YANG builds complete NETCONF protocol support into the language, increasing human ease-of-use, and reducing the chance of errors introduced by additional complicated language constructs to define protocol mappings. The YANG specification defines NETCONF / XML Encoding Rules in separate sections, which allows a possible later mapping to other protocols. o 4.1.15 Translation to Other Data Definition Languages YANG can be translated to XSD or RelaxNG. It cannot be translated to Bjorklund Expires August 21, 2008 [Page 26] Internet-Draft YANG February 2008 SMIv2 or SPPI, without loss of semantics. o 4.1.16 Base Data Types YANG supports all of the listed data types. All are built into the language, except OID, which is a derived type. o 4.1.17 Enumerations SMIv2 style enumerations are fully supported in YANG. o 4.1.18 Discriminated Unions YANG includes the 'union' data type, which is a non-discriminated union. It is trivial to construct a discriminated union with data modeling constructs (i.e, container with a leaf as the discriminator, plus a union leaf.) o 4.1.19 Instance Pointers YANG supports instance pointers with the 'instance-identifier built-in data type. A well-established and industry accepted method is used to identify NETCONF data model objects, and named instances of those objects. o 4.1.20 Row Pointers The YANG instance-identifier is used to identify all conceptual data model nodes, including conceptual rows in YANG lists. o 4.1.21 Constraints on Pointers YANG supports constraints on object instances with the 'keyref' built-in data type. This data type uses an Xpath expression to identify specific object(s) or object instances that are valid for a particular object. o 4.1.22 Base Type Set YANG supports a fixed type set, and does not include and extensible numeric base types. These data types are named similar to SMIv2 data types, starting with the kind of numeric type, followed by the number of bits in the data type (int8, uint8, int16, uint16, int32, uint32, int64, uint64, float32, and float64). o 4.1.23 Extended Data Types YANG fully supports derived types for leafs and leaf-lists, which can Bjorklund Expires August 21, 2008 [Page 27] Internet-Draft YANG February 2008 be based on a built-in type or another derived type. YANG supports global derived types which can be exported, and nested in-line local derived types which are private, and limited to a local (private) inline scope, o 4.1.24 Units, Formats, and Default Values of Defined Types and Attributes YANG contains a 'units' clause which is equivalent to the SMIv2 UNITS clause. Default values are mandatory-to-implement, and can be applied to a derived type or a leaf definition. The DISPLAY-HINT construct is supported with a language extension, and used by the smidump program to convert SMIv2 modules to SMIv2 files. o 4.1.25 Table Existence Relationships YANG supports an INDEX clause (key), AUGMENTS clause (augment), but not the SPPI table EXTENDS mechanism. YANG also SPARSE-AUGMENTS with an Xpath expression (when clause), and arbitrarily complex table relationship expressions (must clause). Non-key tuple uniqueness is also provided (unique clause). o 4.1.26 Table Existence Relationships (2) The SPPI EXPAND and REORDERS mechanisms are not supported by YANG. They are needed in SPPI for protocol mappings, which are not required in YANG. o 4.1.27 Attribute Groups YANG has powerful groupings that can be reused, and refined for each use. o 4.1.28 Containment Groupings, data definitions, and augmentation of data can be mixed in arbitrarily complex ways. Unlimited nesting of any complex data construct (container, list, choice, uses, augment) is allowed. o 4.1.29 Single Inheritance Although YANG is not object-oriented, a simple form of single inheritance can be modeled with a grouping that extends an existing grouping. o 4.1.30 Reusable vs. Final Attribute Groups YANG does not currently support a 'final' attribute. All typedef and Bjorklund Expires August 21, 2008 [Page 28] Internet-Draft YANG February 2008 grouping definitions can be refined. o 4.1.31 Events YANG provides full support of NETCONF notification content definition. o 4.1.32 Creation/Deletion YANG fully supports the create and delete operations in the NETCONF protocol, and includes additional support for user-controlled list or leaf-list insertion. o 4.1.33 Range and Size Constraints The YANG range (and length) clauses are almost identical to the SMIv2 SIZE clause, except it is better. In addition to the usual syntax, e.g., (1..10) or (1 | 3 5..10), the 'min' and 'max' keywords are allowed to indicate that the range boundary is derived from the parent, in the chain of derived types. In addition, float32 and float64 range definitions can contain the4 '-INF' and 'INF' keywords, which are synonyms for 'min' and 'max', traditionally used for floating point numbers. o 4.1.34 Uniqueness The YANG 'unique' clause supports uniqueness constraint specification. o 4.1.35 Extension Rules YANG defines rules for extending and updating modules in a compatible way (work to be done). The YANG "augment" statement allows extending a data model with the contents of a new module in a compatible way. o 4.1.36 Deprecate Use of IMPLIED Keyword This requirement is not applicable to NETCONF. o 4.1.37 No Redundancy YANG is designed with minimal data entry redundancy in mind. No data ever needs to be entered in multiple places, within a module, in order to define any construct. o 4.1.38 Compliance and Conformance YANG does not have any partial module conformance. Only full module Bjorklund Expires August 21, 2008 [Page 29] Internet-Draft YANG February 2008 conformance is supported at this time. Could be added, if needed. o 4.1.39 Allow Refinement of All Definitions in Conformance Statements This feature could be supported in YANG, if some sort of module variance mechanism is added. o 4.1.40 Categories YANG does not contain explicit support for SPPI subject categories. This could be achieved with a language extension, if needed in NETCONF. o 4.1.41 Core Language Keywords vs. Defined Identifiers YANG is similar to SPPI, in that no language keywords are ever imported, or built-in data types. Only user-defined identifiers are imported or included in YANG. o 4.1.42 Instance Naming SPPI and SMIv2 instance naming is not relevant to NETCONF. o 4.1.43 Length of Identifiers YANG defines a minimum value that all implementations must support as their maximum identifier length (63 characters). A hard-wired maximum identifier length is not used. o 4.1.44 Assign OIDs in the Protocol Mappings COPS-PR protocol mapping is not relevant to NETCONF. 3.3.2. Nice-to-have objectives o 4.2.1 Methods YANG and NETCONF support methods with a remote procedure call construct. This is not the same as an object-oriented method, but YANG fully supports the mechanisms with NETCONF for this purpose. o 4.2.2 Unions YANG contains the 'union' built-in data type, which can contain an arbitrary mix of types, including other unions. Bjorklund Expires August 21, 2008 [Page 30] Internet-Draft YANG February 2008 o 4.2.3 Float Data Types YANG supports IEEE floating point math with the 'float32' and 'float64' built-in data types. A range or default clause for these types can be specified in IEEE floating point syntax. [ed. reference]. o 4.2.4 Comments YANG supports single line C++ style comments '// ...EOLN' as well as C-style multi-line comments (/* ... */). o 4.2.5 Referencing Tagged Rows SPPI instance tagging is not relevant to NETCONF. o 4.2.6 Arrays YANG supports variable-length, multi-valued objects with the 'choice' construct, which provides extensible cases and some NETCONF protocol control (mandatory, default) for this type of flexible object definition. o 4.2.7 Internationalization Internationalization is possible in YANG. See bullets 3.2.8.2- 3.2.8.4 in chapter Section 3.1.1. o 4.2.8 Separate Data Modelling from Management Protocol Mapping Almost all NETCONF protocol details are hidden by YANG, allowing data modelers to focus on the domain-specific aspects of the data model, and not the language syntax. YANG clauses have a very flexible syntax, loose ordering, and relatively few language constructs, to allow users to concentrate on writing data definitions, not fixing MIB compiler errors. 3.3.3. Rejected objectives YANG supports some of the rejected requirements from SMING. Support is described below specifically if present in YANG. o 4.3.1 Incomplete Translations o 4.3.2 Attribute Value Constraints Supported with the "must" statement. Bjorklund Expires August 21, 2008 [Page 31] Internet-Draft YANG February 2008 o 4.3.3 Attribute Transaction Constraints o 4.3.4 Method Constraints o 4.3.5 Agent Capabilities o 4.3.6 Relationships Partly supported with the "must" statement and the keyref built-in type. o 4.3.7 Procedures Supported with the "rpc" statement. o 4.3.8 Associations Supported with the "keyref" built-in type. o 4.3.9 Association Cardinalities The "keyref" built-in type is used to formally define 1:1 and 1:n associations/relationships in YANG models. o 4.3.10 Categories of Modules o 4.3.11 Mapping Modules to Files YANG provides a recommendation for mapping to files. o 4.3.12 Simple Grammar o 4.3.13 Place of Module Information Supported. o 4.3.14 Module Namespace o 4.3.15 Hyphens in Identifiers Supported. 3.4. Requirements from draft-linowski-netconf-dml-requirements-00 [LINOWSKI], "NETCONF Data Modeling Language Requirements", has the following requirements: Bjorklund Expires August 21, 2008 [Page 32] Internet-Draft YANG February 2008 o 4.1.1. Base Data Types Compliant. o 4.1.2. Default Values of Defined Types and Attributes Compliant. o 4.1.3. Language Extensibility Compliant. YANG supports extensions to the language in a compatible way. o 4.1.4. Model Modularity Compliant, using the "module" and "submodule" statements. o 4.1.5. Protocol Independence Compliant, see bullets 4.1.13 and 4.1.14 in Section 3.3.1. o 4.1.6. Translation to Other Data Definition Languages Compliant. See bullet 3.8.2 in Section 3.1.1. o 4.1.7. Module Conformance Compliant, see bullet 4.1.11 in Section 3.3.1. o 4.2.1. Model Element Identifiers Partly compliant. YANG identifiers are case sensitive, and hyphens, dots and leading underscores are allowed as well. o 4.2.2. Model Element Documentation Text Compliant. YANG provides a number of documentation and information elements that support UTF-8 characters. o 4.2.3. Model Element Presentation Name Compliant. For localization/internationalization see bullet 3.2.8.1 through 3.2.8.4 in Section 3.1.1. o 4.3.1. Release Support Compliant. See bullet 3.6.2.1. in Section 3.1.1. Bjorklund Expires August 21, 2008 [Page 33] Internet-Draft YANG February 2008 o 4.3.2. Multiple sub-module revisions in one model Not compliant, disagree with the requirement. Handling multiple possibly incompatible versions of a model in one document would be confusing to the user. Keep the (sub)modules side by side, don't merge them. Incompatible versions of the (sub)modules must have different names as in SMI. o 4.4.1. Concrete Classes Not compliant. YANG is not object oriented. Groupings can be used as a proxy to classes. A grouping can define all attributes of a class. o 4.4.2. Abstract Classes Not compliant. o 4.4.3. Single Class Inheritance Partly compliant. Although YANG is not object-oriented, a simple form of single inheritance can be modeled with a grouping that extends an existing grouping. o 4.4.4. Attributes Partly compliant. Classes and attribute groups can be modeled using the "grouping" statement. o 4.4.5. Attribute Groups Compliant using the "grouping" statement. o 4.4.6. Reference Relationships Partly compliant. The keyref built-in type can be used to describe references. o 4.4.7. Containment Relationships Compliant using the "container" or the "list" and the augment statement. o 4.4.8 Calculated Relationships Compliant, based on a leaf-list of the keyref built-in type. Adding relationships without altering the source- or target-end class is possible with a keyref list stored externally to both ends of the Bjorklund Expires August 21, 2008 [Page 34] Internet-Draft YANG February 2008 relationship. o 4.4.9. Simple Attribute Constraints Compliant, but all constraints are combined with the AND operator that is all constraints must be met simultaneously. o 4.5.1. Typed Annotations Partly compliant based on the "extension" statement. The type, the placement and the optionality of an extension is intentionally not defined. If it is an extension then by definition it should allow free usage; most tools will anyway not understand it - will ignore it. Bjorklund Expires August 21, 2008 [Page 35] Internet-Draft YANG February 2008 4. YANG DHCP Module The BOF proposal for the CANMOD BOF at the seventy-first IETF states: "Design teams have also prepared annotated examples of instance documents to illustrate many of the requirements." The example instance document is in Appendix C of [PRESUHN]. This section shows the YANG modules written for that instance document. module dhcp { namespace "http://example.com/ns/dhcp"; prefix dhcp; import yang-types { prefix yang; } import inet-types { prefix inet; } import ieee-types { prefix ieee; } import interfaces { prefix if; } organization "yang-central.org"; description "Partial data model for DHCP, based on the config of the ISC DHCP reference implementation."; container dhcp { description "configuration and operational parameters for a DHCP server."; leaf max-lease-time { type uint32; units seconds; default 7200; } leaf default-lease-time { type uint32; units seconds; must '$this <= ../max-lease-time' { error-message "The default-lease-time must be less than max-lease-time"; } default 600; } uses subnet-list; container shared-networks { list shared-network { key name; Bjorklund Expires August 21, 2008 [Page 36] Internet-Draft YANG February 2008 leaf name { type string; } uses subnet-list; } } } grouping subnet-list { description "A reusable list of subnets"; list subnet { key "network prefix-length"; leaf network { type inet:ip-address; } leaf prefix-length { type uint8 { range "0..128"; } } container range { presence "enables dynamic address assignment"; leaf dynamic-bootp { type empty; description "Allows BOOTP clients to get addresses in this range"; } leaf low { type inet:ip-address; mandatory true; } leaf high { type inet:ip-address; mandatory true; } } container dhcp-options { description "Options in the DHCP protocol"; container router-list { leaf-list router { type inet:host; ordered-by user; reference "RFC 2132, sec. 3.8"; } } container domain-list { leaf-list domain-name { Bjorklund Expires August 21, 2008 [Page 37] Internet-Draft YANG February 2008 type inet:domain-name; reference "RFC 2132, sec. 3.17"; } } list custom { key option; leaf option { type uint32; } choice type { leaf ipv4-address { type inet:ipv4-address; } leaf string { type string; } } } } leaf max-lease-time { type uint32; units seconds; default 7200; } container leases { config false; description "Contains status information about active leases."; list lease { key address; leaf address { type inet:ip-address; } leaf starts { type yang:date-and-time; } leaf ends { type yang:date-and-time; } leaf mac-address { type yang:phys-address; } } } Bjorklund Expires August 21, 2008 [Page 38] Internet-Draft YANG February 2008 container interface-filter { description "The DHCP server will only respond to requests for this subnet when they come from one of these interfaces"; leaf-list interface { type keyref { path "/if:interfaces/if:interface/if:ifName"; } } } } } } The next module is an example of a YANG module that augments the existing dhcp module. module calendar { namespace "http://example.com/ns/cal"; prefix cal; import dhcp { prefix dhcp; } augment "/dhcp:dhcp/dhcp:subnet/dhcp:dhcp-options" { leaf timezone { type string; } } // more data definitions added here... } The interface module is an incomplete stub module for the keyref in dhcp.yang. Bjorklund Expires August 21, 2008 [Page 39] Internet-Draft YANG February 2008 module interfaces { namespace "http://example.com/ns/int"; prefix if; // This is a stub module to make sure the keyref in // dhcp module points to a real list. container interfaces { list interface { key ifName; leaf ifName { type string; } } } } Bjorklund Expires August 21, 2008 [Page 40] Internet-Draft YANG February 2008 5. IANA Considerations This document has no actions for IANA. Bjorklund Expires August 21, 2008 [Page 41] Internet-Draft YANG February 2008 6. Security Considerations This document is only a statement of compliance to a set of requirements. It does not itself define any protocol or information content so security considerations are not applicable. Bjorklund Expires August 21, 2008 [Page 42] Internet-Draft YANG February 2008 7. Contributors The following people all contributed significantly to this document: - Andy Bierman (andybierman.com) - Balazs Lengyel (Ericsson) - David Partain (Ericsson) - Juergen Schoenwaelder (Jacobs University Bremen) - Phil Shafer (Juniper Networks) Bjorklund Expires August 21, 2008 [Page 43] Internet-Draft YANG February 2008 8. References 8.1. Normative References [LINOWSKI] Linowski, B., "NETCONF Data Modeling Language Requirements", draft-linowski-netconf-dml-requirements-01 (work in progress), February 2008. [PRESUHN] Presuhn, R., "Requirements for a Configuration Data Modeling Language", draft-presuhn-rcdml-03 (work in progress), February 2008. [RFC3076] Boyer, J., "Canonical XML Version 1.0", RFC 3076, March 2001. [RFC3139] Sanchez, L., McCloghrie, K., and J. Saperia, "Requirements for Configuration Management of IP-based Networks", RFC 3139, June 2001. [RFC3216] Elliott, C., Harrington, D., Jason, J., Schoenwaelder, J., and W. Weiss, "SMIng Objectives", RFC 3216, December 2001. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, December 2006. [YANG] Bjorklund, M., "YANG - A data modeling language for NETCONF", draft-bjorklund-netconf-yang-02 (work in progress), February 2008. 8.2. Non-Normative References [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC3780] Strauss, F. and J. Schoenwaelder, "SMIng - Next Generation Structure of Management Information", RFC 3780, May 2004. Bjorklund Expires August 21, 2008 [Page 44] Internet-Draft YANG February 2008 Author's Address Martin Bjorklund (editor) Tail-f Systems Email: mbj@tail-f.com Bjorklund Expires August 21, 2008 [Page 45] Internet-Draft YANG 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). Bjorklund Expires August 21, 2008 [Page 46]