Network Working Group                                          P. Shafer
Internet-Draft                                          Juniper Networks
Intended status: Informational                         February 27,                             March 8, 2010
Expires: August 31, September 9, 2010

    An NETCONF- and NETMOD-based Architecture for Network Management
                       draft-ietf-netmod-arch-03
                       draft-ietf-netmod-arch-04

Abstract

   NETCONF gives access to native capabilities of the devices within a
   network, defining methods for manipulating configuration databases,
   retrieving operational data, and invoking specific operations.  YANG
   provides the means to define the content carried via NETCONF, both
   data and operations.  Using both technologies, standard modules can
   be defined to give interoperability and commonality to devices, while
   still allowing devices to express their unique capabilities.

   This document describes how NETCONF and YANG help build network
   management applications that meet the needs of network operators.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and 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 31, September 9, 2010.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Table of Contents

   1.  Key Words  . . .  Origins of YANG  . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Introduction  Elements of YANG . . . . . . . . . . . . . . . . . . . . . . .  6
     2.1.  NETCONF  . .  5
     2.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .  5  6
     2.2.  NETCONF  .  YANG . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.3.  YANG . . .  8
       2.2.1.  Constraints  . . . . . . . . . . . . . . . . . . . . . 10
       2.2.2.  Flexibility  . . .  7
       2.3.1.  Extensibility Model . . . . . . . . . . . . . . . . .  9
   3.  An Architecture for NETMOD . 11
       2.2.3.  Extensibility Model  . . . . . . . . . . . . . . . . . 11
   4.
     2.3.  YANG and Related Technologies  . . . . . . . . . . . . . . . . 14
     4.1.  YIN . . . . 13
       2.3.1.  YIN  . . . . . . . . . . . . . . . . . . . . . . . . . 14
     4.2. 13
       2.3.2.  DSDL (Relax NG)  . . . . . . . . . . . . . . . . . . . 13
     2.4.  YANG Types . . . . . . . . . . . . . . . . . . . . . . . . 14
     4.3.
   3.  Working with YANG Types  . . . . . . . . . . . . . . . . . . . . . . 15
     3.1.  Addressing Operator Problems . . . 15
   5.  Applicability . . . . . . . . . . . . 15
     3.2.  Building YANG-based Solutions  . . . . . . . . . . . . 16
     5.1.  Device Developer . . 17
     3.3.  Modeler  . . . . . . . . . . . . . . . . . . . 16
     5.2.  Generic Content Support . . . . . . 17
     3.4.  Reviewer . . . . . . . . . . . 16
     5.3.  XML "over the wire" Definitions . . . . . . . . . . . . . 16
     5.4.  Application . 17
     3.5.  Device Developer . . . . . . . . . . . . . . . . . . 16
       5.4.1.  Hard Coded . . . 17
       3.5.1.  Generic Content Support  . . . . . . . . . . . . . . . 17
       3.5.2.  XML "over the wire" Definitions  . . . . . . . 16
       5.4.2.  Bottom Up . . . . 18
     3.6.  Application Developer  . . . . . . . . . . . . . . . . . . 17
       5.4.3.  Top Down 18
       3.6.1.  Hard Coded . . . . . . . . . . . . . . . . . . . . . . 18
       3.6.2.  Bottom Up  . . . 17
   6.  Modeling Considerations . . . . . . . . . . . . . . . . . . . 18
   7.  Data Distinctions
       3.6.3.  Top Down . . . . . . . . . . . . . . . . . . . . . . . 19
     7.1.  Background
   4.  Modeling Considerations  . . . . . . . . . . . . . . . . . . . 21
     4.1.  Default Values . . . . . 19
     7.2.  Definitions . . . . . . . . . . . . . . . . . 21
     4.2.  Compliance . . . . . . 19
       7.2.1.  Example 1: IP Routing Table . . . . . . . . . . . . . 20
       7.2.2.  Example 2: Interfaces . . . . . 21
     4.3.  Data Distinctions  . . . . . . . . . . . 20
       7.2.3.  Example 3: Account Information . . . . . . . . . 22
       4.3.1.  Background . . . 20
     7.3.  Implications . . . . . . . . . . . . . . . . . . . 22
       4.3.2.  Definitions  . . . . 21
       7.3.1.  Data Models . . . . . . . . . . . . . . . . . 22
       4.3.3.  Implications . . . . 21
       7.3.2.  Additional Operations to Retrieve Operational State . 21
       7.3.3.  Introduction of an Operational State Datastore . . . . 21
   8. . . . . . . . . . . . . 24
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 22
   9. 25
   6.  Normative References . . . . . . . . . . . . . . . . . . . . . 23 26
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24 27

1.  Key Words

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14, [RFC2119].

2.  Introduction  Origins of YANG

   Networks are increasing in complexity and capacity, as well as the
   density of the services deployed upon them.  Uptime, reliability, and
   predictable latency requirements drive the need for automation.  The
   problems with network management are not simple.  They are complex
   and intricate.  But these problems must be solved for networks to
   meet the stability needs of existing services while incorporating new
   services in a world where the growth of the networks is exhausting the
   supply of qualified networking engineers.
   We need to move from

   In June of 2002, Internet Architecture Board (IAB) held a CLI world into workshop on
   Network Management ([RFC3535]).  The members of this workshop made a world
   number of automation, but that
   automation must be robust and trustworthy.

   This document presents an architecture based on NETCONF ([RFC4741])
   and [YANG].  NETCONF observations and YANG address recommendations for the problems of IETF's
   consideration concerning the issues operators were facing in their
   network
   management management-related work as well as issues they were having
   with flexibility and expressiveness.  NETCONF allows any
   manner the direction of configuration the IETF activities in this area.

   The output of this workshop was focused on current problems.  The
   operator's needs were reasonable and operational data to be carried with few
   rules governing straight forward, including the data.  YANG allows data models to be defined that
   are flexible
   need for transactions, rollback, low implementation costs, and extensible in ways that allow the data
   ability to be
   cohesive save and structured, but not rigid.

   This approach allows restore the device's configuration data.  Many of
   the observations give insight into the problems operators were having
   with existing network management solutions, such as the lack of full
   coverage of device to express its native capabilities in
   a way that is flexible and extensible.  Evolution of devices and the ability to distinguish
   between configuration data
   models are permitted and managed.

2.1.  Terminology

   The document mirrors terminology from NETCONF. other types of data.

   Based on these directions, the NETCONF uses working group was formed and
   the NETCONF protocol was created.  This protocol defines a simple
   RPC-based mechanism to facilitate communication between a client and
   a server.  The client can be a script or application typically
   running as part of a where network management system.  The server is
   typically a network device.  The terms "device" and "server" are used
   interchangeably in this document, applications, acting as are "client" and "application".

2.2.  NETCONF
   clients, can invoke operations on the devices, which act as servers.
   The NETCONF specification defines an XML-based RPC mechanism that leverages the
   simplicity and availability of high-quality XML parsers.  XML gives a
   rich, flexible, hierarchical, standard representation small set of data that
   matches the needs operations, but goes
   out of networking devices.  NETCONF carries
   configuration its way to avoid making any requirements on the data and operations encoded carried
   in XML using an RPC
   mechanism over a connection-oriented transport.

   XML's hierarchical data representation those operations, preferring to allow the protocol to carry any
   data.  This "data model agnostic" approach allows complex networking data models to be rendered in a natural way.  For example, the following
   configuration places interfaces in OSPF areas.  The <ospf> element
   contains a list of <area> elements, each of which contain
   defined independently.

   But lacking a list means of
   <interface> elements.  The <name> element identifies the specific
   area or interface.  Additional configuration for each area or
   interface appears directly inside defining data models, the appropriate element.

         <ospf xmlns="http://ns.ietf.org/netconf/ospf">

           <area>
             <name>0.0.0.0</name>

             <interface>
               <name>ge-0/0/0.0</name>
               <!-- The priority for this interface -->
               <priority>30</priority>
               <metric>100</metric>
               <dead-interval>120</dead-interval>
             </interface>

             <interface>
               <name>ge-0/0/1.0</name>
               <metric>140</metric>
             </interface>
           </area>

           <area>
             <name>10.1.2.0</name>

             <interface>
               <name>ge-0/0/2.0</name>
               <metric>100</metric>
             </interface>

             <interface>
               <name>ge-0/0/3.0</name>
               <metric>140</metric>
               <dead-interval>120</dead-interval>
             </interface>
           </area>
         </ospf> NETCONF includes mechanisms protocol was
   not usable for controlling configuration datastores,
   fetching state data, receiving notifications, standards-based work.  Existing data modeling
   languages such as XSD and allows for
   additional RPC methods.  Configuration operations include Relax NG were considered, but were rejected
   because the ability
   to lock datastores to isolate one application problem domains have little natural overlap.  Defining an
   RPC which is encoded in XML is a distinct problem from defining an
   XML document.

   In early 2005, the actions of
   others, the ability to save and restore configuration NETMOD working group embraced YANG ([RFCYANG]) as
   a means for defining data sets, models for NETCONF, allowing both standard
   and
   the ability proprietary data models to discover (via the <hello> message) the capabilities be published in a form that easily
   digestible by human readers and satisfies many of the device.

2.3.  YANG

   YANG is issues raised
   in the data model language for IAB NM workshop.  This brings NETCONF that to a point where is can
   be used to develop standards within the IETF.

   YANG allows a modeler to create a data model, to define the
   description of hierarchies
   organization of the data model nodes ("nodes") in that model, and the to define constraints on
   that exist amongst them. data.  Once published, the YANG defines data models and module acts as a contract
   between the client and server, with both parties understanding how
   their peer will expect them to behave.  A client knows how to create
   valid data for the server, and knows what data will be sent from the
   server.  A server knows the rules that govern the data and how it
   should behave.

   YANG also incorporates a level of extensibility and flexibility not
   present in other model languages.  New modules can augment the data
   hierarchies defined in other modules, seemlessly adding data at
   appropriate places in the existing data organization.  YANG also
   allows new statements to be defined, allowing the language itself to
   be expanded in a consistent way.

   This document presents an architecture for YANG, describing how YANG-
   related technologies work and how solutions built on them can address
   the network management problem domain.

2.  Elements of YANG

2.1.  NETCONF

   YANG is focused on creating data models for NETCONF, and any
   understanding of the former must begin with the latter.

   NETCONF defines an XML-based RPC mechanism that leverages the
   simplicity and availability of high-quality XML parsers.  XML gives a
   rich, flexible, hierarchical, standard representation of data that
   matches the needs of networking devices.  NETCONF carries
   configuration data and operations encoded in XML using an RPC
   mechanism over a connection-oriented transport.

   XML's hierarchical data representation allows complex networking data
   to be rendered in a natural way.  For example, the following
   configuration places interfaces in OSPF areas.  The <ospf> element
   contains a list of <area> elements, each of which contain a list of
   <interface> elements.  The <name> element identifies the specific
   area or interface.  Additional configuration for each area or
   interface appears directly inside the appropriate element.

         <ospf xmlns="http://example.org/netconf/ospf">

           <area>
             <name>0.0.0.0</name>

             <interface>
               <name>ge-0/0/0.0</name>
               <!-- The priority for this interface -->
               <priority>30</priority>
               <metric>100</metric>
               <dead-interval>120</dead-interval>
             </interface>

             <interface>
               <name>ge-0/0/1.0</name>
               <metric>140</metric>
             </interface>
           </area>

           <area>
             <name>10.1.2.0</name>

             <interface>
               <name>ge-0/0/2.0</name>
               <metric>100</metric>
             </interface>

             <interface>
               <name>ge-0/0/3.0</name>
               <metric>140</metric>
               <dead-interval>120</dead-interval>
             </interface>
           </area>
         </ospf>

   NETCONF includes mechanisms for controlling configuration datastores,
   fetching state data, and receiving notifications, and permits
   additional RPC methods.  Configuration operations include the ability
   to lock datastores to isolate one application from the actions of
   others, the ability to save and restore configuration data sets, and
   the ability to discover (via the <hello> message) the capabilities of
   the device.

   More information about NETCONF can be found in [RFC4741].

2.2.  YANG

   YANG is a data modeling language for NETCONF.  It allows the
   description of hierarchies of data model nodes ("nodes") and the
   constraints that exist among them.  YANG defines data models and how
   to manipulate those models via NETCONF protocol operations.

   Each YANG module defines a data model, uniquely identified by a
   namespace URI.  These data models are extensible in a manner that
   allows tight integration of standard data models and proprietary data
   models.  Models are built from organizational containers, lists of
   data instances and leaf data values.

       module ietf-ospf example-ospf {
           namespace http://ns.ietf.org/netconf/ospf; http://example.org/netconf/ospf;
           prefix ospf;

           import network-types {  // Access another module's def'ns
               prefix nett;
           }

           container ospf {   // Declare the top-level tag
               list area {    // Declare a list of "area" nodes
                   key name;  // The key "name" identifies list members
                   leaf name {
                       type nett:area-id;
                   }
                   list interface {
                       key name;
                       leaf name {
                           type nett:interface-name;
                       }
                       leaf priority {
                           description "Designated router priority";
                           type uint {       // The type and range are
                               range 0..255; //  constraints on valid
                           }                 //  values for "priority".
                       }
                       leaf metric {
                           type uint {
                               range 1..65535;
                           }
                       }
                       leaf dead-interval {
                           units seconds;
                           type uint {
                               range 1..65535;
                           }
                       }
                   }
               }
           }
       }

   A YANG module defines a data model in terms of the data, its
   hierarchical organization, and the constraints on that data.  YANG
   defines how this data is represented in XML and how that data is used
   in NETCONF operations.

2.3.1.  Extensibility Model

   XML includes the concept

   The following table briefly describes some common YANG statements:

   +--------------+----------------------------------------------------+
   | Statement    | Description                                        |
   +--------------+----------------------------------------------------+
   | augment      | Extends existing data hierarchies                  |
   | choice       | Defines mutually exclusive alternatives            |
   | container    | Defines a layer of namespaces, allowing XML elements from
   different sources the data hierarchy              |
   | extension    | Allows new statements to be combined added to YANG          |
   | feature      | Indicates parts of the model are optional          |
   | grouping     | Groups data definitions into reusable sets         |
   | key          | Defines the keys leafs for lists                   |
   | leaf         | Defines a leaf node in the same data hierarchy without
   risking collision.          |
   | leaf-list    | A leaf node that can appear as multiple times      |
   | list         | A layer of hierarchy that can appear multiple      |
   |              | times                                              |
   | notification | Define an notification                             |
   | rpc          | Define an RPC operation                            |
   | typedef      | Define a new type                                  |
   | uses         | Incorporate the contents of a "grouping"           |
   +--------------+----------------------------------------------------+

2.2.1.  Constraints

   YANG modules define content for specific
   namespaces, allows the modeler to add constraints to the data model to
   prevent impossible or illogical data.  These constraints give clients
   information about the data being sent from the device, and also allow
   the client to know as much as possible about the data the device will
   accept, so the client can send correct data.  These constraints apply
   to configuration data, but one module may augment can also be used for rpc and notification
   data.

   The principal constraint is the definition "type" statement, which limits the
   contents of another
   module, introducing elements from a leaf node to that module's namespace into of the
   first module's hierarchy.

   Since one module can augment another module's definition, hierarchies named type.  The following
   table briefly describes some other common YANG constraints:

   +--------------+----------------------------------------------------+
   | Statement    | Description                                        |
   +--------------+----------------------------------------------------+
   | length       | Limits the length of definitions are allowed a string                      |
   | mandatory    | Requires the node appear                           |
   | max-elements | Limits the number of instances in a list           |
   | min-elements | Limits the number of instances in a list           |
   | must         | XPath expression must be true                      |
   | pattern      | Regular expression must be satisfied               |
   | range        | Value must appear in range                         |
   | reference    | Value must appear elsewhere in the data            |
   | unique       | Value must be unique within the data               |
   | when         | Node is only present when XPath expression is true |
   +--------------+----------------------------------------------------+
   The "must" and "when" statements use XPath expressions to grow, as definitions from multiple
   sources specify
   conditions that are added to semantically evaluated against the base hierarchy.  These augmentations are
   qualified using data
   hierarchy, but neither the namespace of client nor the source module, helping server are required to avoid
   issues with name conflicts as
   implement the modules change over time.

   For example, if XPath specification.  Instead they can use any means to
   ensure these conditions are met.

2.2.2.  Flexibility

   YANG uses the above OSPF configuration were "union" type and the standard, "choice" and "feature" statements
   to give modelers flexibility in defining their data models.  The
   "union" type allows a
   vendor module may augment this with vendor-specific extensions.

       module vendorx-ospf {
           namespace http://vendorx.example.com/ospf;
           prefix vendorx;

           import ietf-ospf {
               prefix ospf;
           }

           augment /ospf:ospf/ospf:area/ospf:interfaces { single leaf no-neighbor-down-notification to accept multiple types, like an
   integer or the word "unbounded":

     type union {
         type empty;
                   description "Don't inform other protocols about"
                             + " neighbor down events";
               } int32;
         type enumeration {
             enum "unbounded";
         }
     }

   The <no-neighbor-down-notification> element is then placed in the
   vendorx namespace:

       <protocols xmlns="http://ietf.org/netconf/protocols"
                  xmlns:vendorx="http://vendorx.example.com/ospf">
         <ospf xmlns="http://ietf.org/netconf/ospf">

           <area>
             <name>0.0.0.0</name>

             <interface>
               <name>ge-0/0/0.0</name>
               <priority>30</priority>
               <vendorx:no-neighbor-down-notification/>
             </interface>

           </area>
         </ospf>
       </protocols>

   Augmentations are seamlessly integrated with base modules, allowing
   them to be fetched, archived, loaded, and deleted within their
   natural hierarchy.  If a client application asks for the
   configuration for a specific OSPF area, it will receive the sub-
   hierarchy for that area, complete with any augmentations.

3.  An Architecture for NETMOD

   In the NETMOD architecture, each device vendor implements

   A choice gives a set of
   data models in their devices.  These models are either standard data
   models, defined in YANG modules published by mutually exclusive nodes, so a standards body, or
   proprietary data models, defined in YANG modules published by
   vendors.

   Standard data models define content that is independent of valid
   configuration can choose any one node (or case).  The "feature"
   allows the
   vendor, allowing client applications modeler to request specific behavior
   without concern for the vendor, product line, or installed software
   revision.  The translation between identify parts of the standard model which can be
   optional, and allows the device
   specific behavior is performed by the device, freeing the application
   from such concerns.

   Proprietary data models allow the vendor to accurately describe the
   content and behavior of their devices in explicit detail.
   Applications may take advantage of indicate whether it implements
   these specifics to optional portions.

   The "deviation" give their
   users complete control over some flexibility to the device.

   When device, allowing it to
   define parts of a NETCONF session begins, the namespaces for all supported
   modules are announced as capabilities via YANG module which the device's <hello>
   message.  The device should also support the schema discovery
   mechanism [ref], enabling applications does not faithfully
   implement.  While devices are encouraged to fully abide according to discover
   the location from
   which contract presented in the modules may be downloaded.

   The schema discovery for standard YANG modules should list a common,
   standard location for these modules, presumably one set by the
   organization that defined the standard.

   When an application connects with a device, it receives the list of
   capabilities supported by that device.  The application module, real world situations may compare
   the set of capabilities announced by
   force the device with to break the set contract.  Deviations give a means of
   modules
   declaring this problem, rather than ignoring it.

2.2.3.  Extensibility Model

   XML includes the application is aware of.  Any new modules or new
   revisions concept of known modules may be downloaded as needed namespaces, allowing XML elements from the
   locations given via the schema discovery mechanism.

   Once the application has access
   different sources to be combined in the same hierarchy without
   risking collision.  YANG modules, it modules define content for specific
   namespaces, but one module may
   manipulate augment the device as a "YANG data browser", capable definition of parsing
   the another
   module, introducing elements sent from that module's namespace into the
   first module's hierarchy.

   Since one module can augment another module's definition, hierarchies
   of definitions are allowed to grow, as definitions from multiple
   sources are added to the device with an understanding of base hierarchy.  These augmentations are
   qualified using the
   organization namespace of the data.  The module describes source module, helping to avoid
   issues with name conflicts as the syntax of modules change over time.

   For example, if the
   data and constraints on that data, allowing above OSPF configuration were the application to create
   data that abides by those constraints.

   To have a real understanding of standard, a module's content, the application
   vendor module may need to incorporate logic specific to that module.  Semantic
   information contained in augment this with vendor-specific extensions.

       module vendorx-ospf {
           namespace http://vendorx.example.com/ospf;
           prefix vendorx;

           import example-ospf {
               prefix ospf;
           }

           augment /ospf:ospf/ospf:area/ospf:interfaces {
               leaf no-neighbor-down-notification {
                   type empty;
                   description statements "Don't inform other protocols about"
                             + " neighbor down events";
               }
           }
       }

   The <no-neighbor-down-notification> element is not machine
   readable, but module-specific custom work can be done to tailor then placed in the
   user interface
   vendorx namespace:

       <protocols xmlns="http://example.org/netconf/protocols"
                  xmlns:vendorx="http://vendorx.example.com/ospf">
         <ospf xmlns="http://example.org/netconf/ospf">

           <area>
             <name>0.0.0.0</name>

             <interface>
               <name>ge-0/0/0.0</name>
               <priority>30</priority>
               <vendorx:no-neighbor-down-notification/>
             </interface>

           </area>
         </ospf>
       </protocols>

   Augmentations are seamlessly integrated with base modules, allowing
   them to the particular semantic needs of a module.

   For example, be fetched, archived, loaded, and deleted within their
   natural hierarchy.  If a module could define client application asks for the "location" of
   configuration for a device using
   longitude and latitude, and the application can use specific OSPF area, it will receive the "browser"
   style to display this sub-
   hierarchy for that area, complete with any augmentated data.

2.3.  YANG Technologies

   The YANG data using input fields in modeling language is the central piece of a web form.  Custom
   logic would be needed to take group of
   related technologies.  The YANG language itself, described in
   [RFCYANG], defines the value syntax of these fields the language and place its statements, the
   device on a map
   meaning of the world, those statements, and additional logic would be needed how to combine them to
   update build the
   hierarchy of nodes that describe a data values when the user drags model.

   That document also defines the device from Dallas to
   Dulles.

   If an application is meant to manage a specific problem, it may model "on the wire" XML content for NETCONF
   operations on data internally models defined in whatever form is most convenient to its
   organizational needs.  When the application interacts with a device,
   it may choose one of two paths.  If the device implements a standard
   module, YANG modules.  This includes the application may generate
   basic mapping between YANG data tree nodes and XML elements, as well
   as mechanisms used in <edit-config> content for to manipulate that standard by
   translating its internal form into the standard one.

   If the device doesn't implement such a standard or no data,
   such standard
   exists, as arranging the application may use order of nodes within a transformation list.

   YANG uses a syntax that is particular regular and easily described, primarily
   designed for human readability.  YANG's syntax is friendly to that device's vendor, product model, hardware, or software.
   Depending on email,
   diff, patch, and the application, this transformation constraints of RFC formatting.

2.3.1.  YIN

   In some environments, incorporating a YANG parser may not be provided by
   the application vendor, the device vendor, a third-party, or the
   provider. an
   acceptable option.  For a popular application, those scenarios, an XML grammar for YANG is
   defined as YIN (YANG Independent Notation).  YIN allows the device vendor may wish to provide this
   transformation to increase market acceptance use of their devices.  For
   popular devices,
   XML parsers which are readily available in both open source and
   commercial versions.  Conversion between YANG and YIN is direct,
   loss-less and reversible.  YANG statements are converted to XML
   elements, preserving the application may provide this transformation as a
   means structure and content of making the application useful in YANG, but enabling
   the maximum number use of
   provider networks.  For problem domains where the mapping from the
   application to off-the-shelf XML parsers rather than requiring the device
   integration of a YANG parser.  YIN maintains complete semantic
   equivalence with YANG.

2.3.2.  DSDL (Relax NG)

   Since NETCONF content is not straight-forward or requires
   tailoring to the specific provider or environment, the provider may
   wish encoded in XML, it is natural to control this transformation.  Additionally, other parties may
   make such transformations available via open source.

   Note that both cases may appear within use XML
   schema languages for their validation.  To facilitate this, YANG
   offers a single application on an "as
   needed" basis.  If standardized mapping of YANG modules into Document Schema
   Description Languages (DSDL) [DSDL].

   DSDL is considered to be the device announces best choice for the capability given purpose
   because it addresses not only grammar and datatypes of XML documents
   but also semantic constraints and rules for modifying information set
   of the
   standard YANG module, document.

   In addition, DSDL offers formal means for coordinating multiple
   independent schemas and specifying how to apply the application may transmit schemas to the device via
   NETCONF
   various parts of the document.  This is useful since YANG content in the standard modules format.  If the device
   does not announce the appropriate capability, the application may
   find is
   typically composed of multiple vocabularies.

2.4.  YANG Types

   YANG supports a transformation that matches the device, perform the
   transformation on the standard data to produce device native
   configuration, number of builtin types, and transmit via NETCONF that device configuration allows additional types
   to be derived from those types in an extensible manner.  New types
   can add additional restrictions to allowable data values.

   A standard type library for use by YANG is available [RFCYANGTYPES].
   These YANG modules define commonly used data types for IETF-related
   standards.

3.  Working with YANG

3.1.  Addressing Operator Problems

   YANG addresses many of the device.

   In both cases, issues raised in the key IAB NM workshop.

   o  Ease of use: YANG is the ability designed to be human friendly, simple and
      readable.  Many tricky issues remain due to discover the capabilities complexity of the specific device, download the
      problem domain, but YANG modules that support those
   capabilities, gain an understanding of those data models and their
   constraints, generate appropriate content, strives to make them more visible and transmit that content
      easier to the device.

4.  YANG deal with.

   o  Configuration and Related Technologies

   The Operational data: YANG clearly divides
      configuration data modeling language is the central piece from other types of data.

   o  Transactions: NETCONF provides a group simple transaction mechanism.

   o  Generation of
   related technologies.  The deltas: A YANG language itself, described in [ref],
   defines the syntax of module gives enough information to
      generate a the language delta needed to change between two configuration
      data sets.

   o  Dump and its statements, restore: NETCONF gives the meaning ability to save and restore
      configuration data.  This can also performed for a specific YANG
      module.

   o  Network-wide configuration: A standard YANG module can be
      implemented in all devices, giving a common view of
   those statements, configuration
      data.

   o  Text-friendly: YANG modules are very text friendly, as is the data
      they define.

   o  Configuration handling: NETCONF addresses the ability to
      distinguish between distributing configuration data and how activating
      it.

   o  Task-oriented: A YANG module can define specific tasks as rpc
      methods.  A client can choose to combine them invoke the rpc or to build access any
      underlying data directly.

   o  Full coverage: YANG modules can be defined that give full coverage
      to all the hierarchy native abilities of
   nodes the device.  Giving this access
      avoids the need to resort to CLI/Expect access.

   o  Timeliness: YANG modules can be tied to CLI operations, so all
      native operations and data are immediately available.

   o  Implementation difficulty: YANG's flexibility should allow simpler
      modules that describe can be more easily implemented.  Adding "features"
      and replacing "third normal form" with a natural data model.

   That document also defines the "on the wire" XML content for NETCONF
   operations on data models defined in hierarchy
      should reduce complexity.

   o  Simple DDL: YANG modules.  This includes has sufficient power to be usable in other
      situations.  In particular, on-box API and native CLI can be
      integrated to achieve simplification of the
   basic mapping between infrastructure.

   o  Internationalization: YANG data tree nodes uses UTF-8 data.

   o  Event correlation: YANG integrated rpc, notification, operational,
      and XML elements, as well
   as mechanisms used in <edit-config> content to manipulate that configuration data,
   such as arranging allowing the order of nodes within data to make internal
      references.  For example, a list.

   YANG uses field in a syntax that is regular notification can be tagged
      as pointing to a BGP peer, and the client application can easily described, primarily
   designed for human readability.
      find that peer in the configuration data.

   o  Implementation costs: Significant effort has been made to keep
      implementation costs as low as possible.

   o  Human friendly syntax: YANG's syntax is friendly to email,
   diff, patch, and the constraints of RFC formatting.

4.1.  YIN

   In some environments, incorporating a YANG parser may not be an
   acceptable option.  For those scenarios, an XML grammar optimized for YANG the reader,
      specifically the reviewer on the basis that this is
   defined in YIN (YANG Independent Notation) [ref].  YIN allows the use most
      common human interaction.

   o  Post-processing: Use of XML parsers which are readily available in both open source and
   commercial versions.  Conversion between YANG and YIN is direct,
   loss-less and reversible.  YANG statements are converted to XML
   elements, preserving will maximize the structure opportunities for
      post-processing of data, possibly using XML-based technologies
      like XPath, XQuery, and content XSLT.

   o  Semantic mismatch: Richer, more descriptive data models will
      reduce the possibility of YANG, but enabling semantic mismatch.  With the use ability to
      define new primitives, YANG modules will be more specific in
      content, allowing more enforcement of off-the-shelf XML parsers rather than requiring rules and constraints.

   o  Security: NETCONF runs as an ssh service, allowing secure
      communications and authentication using well-trusted technology.
      This uses the
   integration of a existing key and credential management
      infrastructure, reducing deployment costs.

   o  Reliable: NETCONF and YANG parser.  YIN maintains complete semantic
   equivalence with YANG.

4.2.  DSDL (Relax NG)

   Since are solid and reliable technologies.
      NETCONF content is encoded in XML, it connection based, and includes automatic recovery
      mechanisms when the connection is natural to use XML
   schema languages for their validation.  To facilitate this, YANG
   offers a standardized mapping of lost.

   o  Delta friendly: YANG-based models support operations that are
      delta friendly.  Add, change, insert, and delete operations are
      all well defined.

   o  Method-oriented: YANG modules into Document Schema
   Description Languages (DSDL) [DSDL].

   DSDL is considered allows new NETCONF RPCs to be the best choice for the given purpose
   because it addresses not only grammar defined,
      including an operation name, which is essentially a method.  The
      RPC's input and datatypes of XML documents
   but output data are also semantic constraints and rules for modifying information set
   of defined in the document.

   In addition, DSDL offers formal means for coordinating multiple
   independent schemas and specifying YANG module.

3.2.  Building YANG-based Solutions

   Building YANG-based solutions requires interacting with many distinct
   groups.  Modelers must understand how to apply the schemas build useful models that
   give structure and meaning to data while maximizing the
   various parts flexibility
   of the document.  This is useful since YANG content that data to "future proof" their work.  Reviewers need to quickly
   determine if that structure is
   typically composed accurate.  Device developers need to
   code that data model into their devices, and application developers
   need to code their applications to take advantage of multiple vocabularies.

4.3.  YANG Types

   YANG supports that data model.
   There are a number variety of strategies for performing each piece of this
   work.  This section discusses some of builtin types, and allows additional types
   to be derived from those types in an extensible manner.  New types
   can add additional restrictions strategies.

3.3.  Modeler

   (No clue what needs said here; lots to say, but what's important?)

   Additional modeling issues are discussed in Section 4.

3.4.  Reviewer

   The reviewer role is perhaps the more important and the time
   reviewers are willing to allowable data values.

   A standard type library for use by YANG give is available [ref].  These precious.  To help the reviewer,
   YANG modules define commonly used data types for IETF-related
   standards.

5.  Applicability

   The data model in stresses readability, with a YANG module yields value human-friendly syntax, natural data
   hierarchy, and simple, concise statements.

   In addition, reviewers can encode review policies in five specific areas.

5.1. scripts, such as
   XSLT.  A policy that leaf names can't have underscores can be coded
   as:

        <xsl:template match="leaf[contains(@name, '_')]">
            Error: leaf name contains underscore
        </xsl:template>

3.5.  Device Developer

   The YANG model tells the device developer what data is being modeled.
   The developer reads the YANG models, absorbs the zen of the model,
   and writes code that supports the model.  The model describes the
   data hierarchy and associated constraints, and the description and
   reference material helps the developer understand how to transform
   the models view into the device device's native implementation.

5.2.

3.5.1.  Generic Content Support

   The YANG model can be compiled into a YANG-based engine for either
   the client or server side.  Incoming data can be validated, as can
   outgoing data.  The complete configuration datastore may be validated
   in accordance with the constraints described in the data model.

   Serializers and deserializers for generating and receiving NETCONF
   content can be driven by the meta-data in the model.  As data is
   received, the meta-data is consulted to ensure the validity of
   incoming XML elements.

5.3.

3.5.2.  XML "over the wire" Definitions

   The YANG module dictates the XML encoding sent "over the wire",
   though actual transmission should be encrypted so as not to appear as
   readable text on the physical media.  The rules that define the
   encoding are fixed, so the YANG module can be used to ascertain
   whether a specific NETCONF payload is obeying the rules.

5.4.

3.6.  Application Developer

   The YANG module tells the application developer what data can be
   modeled.  Developers can inspect the modules and take one of three
   distinct views.  In this section, we will consider them and the
   impact of YANG on their design.  In the real world, most applications
   are a mixture of these approaches.

5.4.1.

3.6.1.  Hard Coded

   An application can be coded against the specific, well-known contents
   of YANG modules, implementing their organization, rules, and logic
   directly with explicit knowledge.  For example, a script could be
   written to change the domain name of a set of devices using a
   standard YANG module that includes such a leaf node.  This script
   takes the new domain name as an argument and insert inserts it into a string
   containing the rest of the XML encoding as required by the YANG
   module.  This content is then sent via NETCONF to each of the
   devices.

   This type of application is useful for small, fixed problems where
   the cost and complexity of flexibility is overwhelmed by the ease of
   hard coding direct knowledge into the application.

5.4.2.

3.6.2.  Bottom Up

   An application may take a generic, bottom up approach to
   configuration, concentrating on the device's data directly and
   treating that data without specific understanding.

   YANG modules may be used to drive the operation of the YANG
   equivalent of a "MIB Browser".  Such an application manipulates the
   device's configuration data based on the data organization contained
   in the YANG module.  For example, a GUI may present a straight-
   forward visualization where elements of the YANG hierarchy are
   depicted in a hierarchy of folders or GUI panels.  Clicking on a line
   expands to the contents of the matching content. XML hierarchy.

   This type of GUI can easily be built by generating XSLT stylesheets
   from the YANG data models.  An XSLT engine can then be used to turn
   configuration data into a set of web pages.

   The YANG modules allows the application to enforce a set of
   constraints without understanding the semantics of the YANG module.

5.4.3.

3.6.3.  Top Down

   In contrast to the bottom-up approach, the top-down approach allows
   the application to take a view of the configuration data which is
   distinct from the standard and/or proprietary YANG modules.  The
   application is free to construct its own model for data organization
   and to present this model to the user.  When the application needs to
   transmit data to a device, the application transforms its data from
   the problem-oriented view of the world into the data needed for that
   particular device.  This transformation is under the control and
   maintenance of the application, allowing the transformation to be
   changed and updated without affecting the device.

   For example, an application could be written that models VPNs in a
   network-oriented view.  The application would need to transform these
   high-level VPN definitions into the configuration data that would be
   handed to any particular device within a VPN.

6.

   Even in this approach, YANG is useful since it can be used to model
   the VPN.

       list vpn {
           key name;
           leaf name { ... }
           leaf type {
               type enumeration {
                   enum bgpvpn;
                   enum l2vpn;
               }
           }
           leaf topology {
               type enumeration {
                   enum hub-n-spoke;
                   enum mesh;
               }
           }
           list members {
               key "device interface";
               leaf device { ... }
               leaf interface { ... }
           }
           list classifiers {
               ...
           }
       }

   The application can use such a YANG module to drive its operation,
   building VPN instances in a database and then pushing the
   configuration for those VPNs to individual devices uses either a
   standard device model (e.g. bgp.yang) or by transforming that
   standard device content into some proprietary format for devices that
   do not support that standard.

4.  Modeling Considerations

   This section discusses considerations the modeler should be aware of
   while developing models in YANG.

4.1.  Default Values

   (With all the discussion on this point, it needs to be mentioned
   here.)

4.2.  Compliance

   In developing good data models, there are many conflicting interests
   the data modeler must keep in mind.  Modelers need to be aware of
   four types of behavior in modeled device:

   o  [strict compliance] behavior that follow the model completely

   o  [modeled deviations] behavior that follows within deviations
      allowed by the model

   o  [allowable deviations] behavior that falls outside the model, but
      can still be handled

   o  [unacceptable deviations] behavior that is not at all consistent
      with the model

   Once the model is published, an implementer may decide to make a
   particular data model node configurable, where the standard model
   describes it a state data.  The implementation reports the value
   normally and may have an "out of band" mechanism for reporting declare a deviation that this device behaves in a
   different manner than the standard.  Applications capable of
   discovering such behavior this deviation can make allowances, but applications that
   do not discover such behavior the deviation can continue treating the
   implementation as if it were compliant.

   Rarely, implementations may make decisions that prevent compliance
   with the standard.  Such occasions are regrettable, but they remain a
   part of reality, and modelers and application writers ignore them at
   their own risk.  An implementation that emits an integer leaf as
   "cow" would be difficult to manage, but applications must expect to
   encounter such misbehaving devices in the field.

   Despite this, both client and server should view the YANG module as a
   contract, with both sides agreeing to abide by the terms.  The
   modeler should be explicit about the terms of such a contract, and
   both client and server implementations should strive to faithfully
   and accurately implement the data model described in the YANG module.

7.

4.3.  Data Distinctions

   The distinction between configuration data, operational state data,
   and statistics is important to understand for data model writers and
   people who plan to extend the NETCONF protocol.  This section first
   discusses some background and then provides a definition and some
   examples.

7.1.

4.3.1.  Background

   During the IAB Network Management Workshop documented in RFC 3535, NM workshop, operators did formulate the following two
   requirements:

    2.  It is necessary to make a clear distinction between
        configuration data, data that describes operational state
        and statistics.  Some devices make it very hard to determine
        which parameters were administratively configured and which
        were obtained via other mechanisms such as routing
        protocols.

    3.  It is required to be able to fetch separately configuration
        data, operational state data, and statistics from devices,
        and to be able to compare these between devices.

   The NETCONF protocol defined in RFC 4741 distinguishes two types of
   data, namely configuration data and state data:

      Configuration data is the set of writable data that is
      required to transform a system from its initial default state
      into its current state.

      State data is the additional data on a system that is not
      configuration data such as read-only status information and
      collected statistics.

   NETCONF does not follow the distinction formulated by the operators
   between configuration data, operational state data, and statistical
   data, since it considers state data to include both statistics and
   operational state data.

7.2.

4.3.2.  Definitions

   Below is a definition for configuration data, operational state data,
   and statistical data.  The definition borrows from previous work.

   o  Configuration data is the set of writable data that is required to
      transform a system from its initial default state into its current
      state.  [RFC 4741]

   o  Operational state data is a set of data that has been obtained by
      the system at runtime and influences the system's behaviour
      similar to configuration data.  In contrast to configuration data,
      operational state is transient and modified by interactions with
      internal components or other systems via specialized protocols.

   o  Statistical data is the set of read-only data created by a system
      itself.  It describes the performance of the system and its
      components.

   The following examples help to clarify the difference between
   configuration data, operational state data and statistical data.

7.2.1.

4.3.2.1.  Example 1: IP Routing Table

   IP routing tables can contain entries that are statically configured
   (configuration data) as well as entries obtained from routing
   protocols such as OSPF (operational state data).  In addition, a
   routing engine might collect statistics like how often a particular
   routing table entry has been used.

7.2.2.

4.3.2.2.  Example 2: Interfaces

   Network interfaces usually comes with a large number of attributes
   that are specific to the interface type and in some cases specific to
   the cable plugged into an interface.  Examples are the maximum
   transmission unit of an interface or the speed detected by an
   Ethernet interface.

   In many deployments, systems use the interface attributes detected
   when an interface is initialized.  As such, these attributes
   constitute operational state.  However, there are usually provisions
   to overwrite the discovered attributes with static configuration
   data, like for example configuring the interface MTU to use a
   specific value or forcing an Ethernet interface to run at a given
   speed.

   The system will record statistics (counters) measuring the number of
   packets, bytes, and errors received and transmitted on each
   interface.

7.2.3.

4.3.2.3.  Example 3: Account Information

   Systems usually maintain static configuration information about the
   accounts on the system.  In addition, systems can obtain information
   about accounts from other sources (e.g.  LDAP, NIS) dynamically,
   leading to operational state data.  Information about account usage
   are examples of statistic data.

   Note that configuration data supplied to a system in order to create
   a new account might be supplemented with additional configuration
   information determined by the system when the account is being
   created (such as a unique account id).  Even though the system might
   create such information, it usually becomes part of the static
   configuration of the system since this data is not transient.

7.3.

4.3.3.  Implications

   The primary focus of YANG is configuration data.  There is no single
   mechanism defined for the separation of operational state data and
   statistics since NETCONF treats them both as state data.  This
   section describes several different options for addressing this
   issue.

7.3.1.

4.3.3.1.  Data Models

   The first option is to have data models that provide explicitly
   differentiate between configuration data and operational state data.
   This leads to duplication of data structures and might not scale well
   from a modeling perspective.

   For example, the configured duplex value and the operational duplex
   value would be distinct leafs in the data model.

7.3.2.

4.3.3.2.  Additional Operations to Retrieve Operational State

   The NETCONF protocol can be extended with new protocol operations
   that specifically allow the retrieval of all operational state, e.g.
   by introducing a <get-ops> operation (and perhaps also a <get-stats>
   operation).

7.3.3.

4.3.3.3.  Introduction of an Operational State Datastore

   Another option could be to introduce a new "configuration" data store
   that represents the operational state.  A <get-config> operation on
   the <operational> data store would then return the operational state
   determining the behaviour of the box instead of its static and
   explicit configuration state.

8.

5.  Security Considerations

   This document defines a language with which to write discusses data modeling using YANG, and read
   descriptions of management information.  The language itself has no security
   impact on the Internet.

9.

6.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14,

   [RFC3535]  Schoenwaelder, J., "Overview of the 2002 IAB Network
              Management Workshop", RFC 2119, March 1997. 3535, May 2003.

   [RFC4741]  Enns, R., "NETCONF Configuration Protocol", RFC 4741,
              December 2006.

   [YANG]

   [RFCYANG]  Bjorklund, M., Ed., "YANG - A data modeling language for
              NETCONF", draft-ietf-netmod-yang-11 (work in progress).

   [RFCYANGTYPES]
              Schoenwaelder, J., Ed., "Common YANG Data Types",
              draft-ietf-netmod-yang-types-07.txt (work in progress).

Author's Address

   Phil Shafer
   Juniper Networks

   Email: phil@juniper.net