[Search] [pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
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

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   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


   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

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

   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

   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

   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

   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 <edit-config>
   operations work for the data definition statements.

   All YANG data definition statements define either configuration or
   non-configuration data, supporting the <get-config> and <get>
   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

   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:

       + '([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";
             "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

   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-

     @@ -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  Descriptions using Local Languages (Agreed)

   YANG supports Unicode text in the data model definitions.

   o  UTF-8 Encoding (Agreed)

   YANG supports UTF-8.  YANG modules are written in the UTF-8 [RFC3629]
   character set.

   o  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  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  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  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  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  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  Formal Description of Constraints (Agreed)

   Constraints local to scalar objects are supported with restrictions
   on the type.  YANG supports "range", "length" and "pattern"

      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  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  Language Versioning (Agreed)

   The YANG language is versioned with the "yang-version" statement.

     yang-version 1;

   o  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  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  Backwards Compatibility (Agreed)

   YANG supports module revisions while allowing backwards
   compatibility.  The rules controlling such changes remains work to be

   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

Bjorklund                Expires August 21, 2008               [Page 18]

Internet-Draft                    YANG                     February 2008

   o  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  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

   o  Default Values (NOT Agreed)

   YANG supports default values.  Any leaf node can specify a static
   default using the "default" statement.

     default 1024;

   o  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  Referential Integrity (NOT Agreed)

   YANG supports formal referential integrity constraints with the
   "keyref" statement.

     leaf mgmt-interface {
         type keyref {
             path "../interface/name";

   o  User Extensions (NOT Agreed)

   YANG supports user-defined extensions to the language itself.

   To define an extension:

     module my-extensions {

       extension c-define {
           "Takes as argument a name string.
           Makes the code generator use the given name in the
         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  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  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

   o  3.1.2.  Notification Get (NOT Agreed)

   o  Tag Names and Strings in Local Languages (NOT agreed)

   o  Order within Containers (NOT Agreed)

   o  Interleaving (NOT Agreed)

   o  3.4.6.  Model Instance Localization (NOT Agreed)

   o  Deep Keys (NOT Agreed)

   o  Many-to-Many Relationships (NOT Agreed)

   o  Retrieve Relationships instance (NOT Agreed)

   o  Retrieve Relationships - qualified (NOT Agreed)

   o  Extended Referential Integrity (NOT Agreed)

   o  Referential Integrity Robustness (NOT Agreed)

Bjorklund                Expires August 21, 2008               [Page 21]

Internet-Draft                    YANG                     February 2008

   o  Dynamic Defaults (NOT Agreed)

   o  3.5.12.  Define Actions (NOT Agreed)

   o  Interaction with defaults (NOT Agreed)

   o  Conformance Interference (NOT Agreed)

   o  Schema Version of Instance (NOT Agreed)

   o  Interaction with default Values (NOT Agreed)

   o  Forwards Compatibility (NOT Agreed)

   o  3.7.1.  Conformance to the Modeling Language (NOT Agreed)

   o  Conditional Conformance (NOT Agreed)

   o  Client Conformance To Schema (NOT Agreed)

   o  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

Bjorklund                Expires August 21, 2008               [Page 22]

Internet-Draft                    YANG                     February 2008

   o  2): translating network-wide configurations into device-local

   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

   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

   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

   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

   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

   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

   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'

   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

   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

   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

   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

   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

   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

   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

   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

   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

   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

   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

   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.

   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

   o  4.2.7 Internationalization

   Internationalization is possible in YANG.  See bullets 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

   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


   o  4.3.14 Module Namespace

   o  4.3.15 Hyphens in Identifiers


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


   o  4.1.2.  Default Values of Defined Types and Attributes


   o  4.1.3.  Language Extensibility

   Compliant.  YANG supports extensions to the language in a compatible

   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
   through in Section 3.1.1.

   o  4.3.1.  Release Support

   Compliant.  See bullet 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

   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

   o  4.4.7.  Containment Relationships

   Compliant using the "container" or the "list" and the augment

   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


   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

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; }

       "Partial data model for DHCP, based on the config of
        the ISC DHCP reference implementation.";

     container dhcp {
         "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' {
             "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;
               "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;
             "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 {
             "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

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, 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

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

   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


   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Bjorklund                Expires August 21, 2008               [Page 46]