Network Working Group                                  M. Bjorklund, Ed.
Internet-Draft                                            Tail-f Systems
Intended status: Standards Track                         August 29,                        November 3, 2008
Expires: March 2, May 7, 2009

              YANG - A data modeling language for NETCONF
                       draft-ietf-netmod-yang-01
                       draft-ietf-netmod-yang-02

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on March 2, May 7, 2009.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

Abstract

   YANG is a data modeling language used to model configuration and
   state data manipulated by the NETCONF protocol, NETCONF remote
   procedure calls, and NETCONF notifications.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   7   8
   2.  Key Words . . . . . . . . . . . . . . . . . . . . . . . . . .   8   9
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   9  10
     3.1.  Mandatory nodes . . . . . . . . . . . . . . . . . . . . .  11  12
   4.  YANG Overview . . . . . . . . . . . . . . . . . . . . . . . .  12  13
     4.1.  Functional Overview . . . . . . . . . . . . . . . . . . .  12  13
     4.2.  Language Overview . . . . . . . . . . . . . . . . . . . .  13  14
       4.2.1.  Modules and Submodules  . . . . . . . . . . . . . . .  13  14
       4.2.2.  Data Modeling Basics  . . . . . . . . . . . . . . . .  14  15
       4.2.3.  Operational Data  . . . . . . . . . . . . . . . . . .  19  20
       4.2.4.  Built-in Types  . . . . . . . . . . . . . . . . . . .  19  20
       4.2.5.  Derived Types (typedef) . . . . . . . . . . . . . . .  20  21
       4.2.6.  Reusable Node Groups (grouping) . . . . . . . . . . .  21  22
       4.2.7.  Choices . . . . . . . . . . . . . . . . . . . . . . .  22  23
       4.2.8.  Extending Data Models (augment) . . . . . . . . . . .  23  24
       4.2.9.  RPC Definitions . . . . . . . . . . . . . . . . . . .  24  25
       4.2.10. Notification Definitions  . . . . . . . . . . . . . .  25  26
   5.  Language Concepts . . . . . . . . . . . . . . . . . . . . . .  27  28
     5.1.  Modules and Submodules  . . . . . . . . . . . . . . . . .  27  28
       5.1.1.  Module Hierarchies  . . . . . . . . . . . . . . . . .  27  28
     5.2.  File Layout . . . . . . . . . . . . . . . . . . . . . . .  27  28
     5.3.  Object Based View of YANG . . . . . . . . . . . . . . . .  28  29
     5.4.  XML Namespaces  . . . . . . . . . . . . . . . . . . . . .  28  29
       5.4.1.  YANG Namespace  . . . . . . . . . . . . . . . . . . .  29  30
     5.5.  Ordering  . . . . . . . . . . . . . . . . . . . . . . . .  29  30
     5.6.  Containers with Presence  . . . . . . . . . . . . . . . .  30  31
     5.7.  Scoping . . . . . . . . . . . . . . . . . . . . . . . . .  30  32
     5.8.  Nested Typedefs and Groupings . . . . . . . . . . . . . .  31  32
     5.9.  Conformance . . . . . . . . . . . . . . . . . . . . . . .  32
       5.9.1.  Basic Behavior  . . . . . . . . . . . . . . . . . . .  33
       5.9.2.  Optional Features . . . . . . . . . . . . . . . . . .  33
       5.9.3.  Deviations  . . . . . . . . . . . . . . . . . . . . .  34
       5.9.4.  Announcing Conformance Information in the <hello>
               Message . . . . . . . . . . . . . . . . . . . . . . .  34
   6.  YANG syntax . . . . . . . . . . . . . . . . . . . . . . . . .  32  36
     6.1.  Lexicographical Tokenization  . . . . . . . . . . . . . .  32  36
       6.1.1.  Comments  . . . . . . . . . . . . . . . . . . . . . .  32  36
       6.1.2.  Tokens  . . . . . . . . . . . . . . . . . . . . . . .  32  36
       6.1.3.  Quoting . . . . . . . . . . . . . . . . . . . . . . .  32  36
     6.2.  Identifiers . . . . . . . . . . . . . . . . . . . . . . .  34  38
       6.2.1.  Identifiers and their namespaces  . . . . . . . . . .  34  38
     6.3.  Statements  . . . . . . . . . . . . . . . . . . . . . . .  34  39
       6.3.1.  Language Extensions . . . . . . . . . . . . . . . . .  35  39
     6.4.  XPath Evaluations . . . . . . . . . . . . . . . . . . . .  35  39
   7.  YANG Statements . . . . . . . . . . . . . . . . . . . . . . .  36  40
     7.1.  The module Statement  . . . . . . . . . . . . . . . . . .  36  40
       7.1.1.  The module's Substatements  . . . . . . . . . . . . .  37  41
       7.1.2.  The yang-version Statement  . . . . . . . . . . . . .  38  42
       7.1.3.  The namespace Statement . . . . . . . . . . . . . . .  38  43
       7.1.4.  The prefix Statement  . . . . . . . . . . . . . . . .  39  43
       7.1.5.  The import Statement  . . . . . . . . . . . . . . . .  39  43
       7.1.6.  The include Statement . . . . . . . . . . . . . . . .  40  44
       7.1.7.  The organization Statement  . . . . . . . . . . . . .  40  44
       7.1.8.  The contact Statement . . . . . . . . . . . . . . . .  40  44
       7.1.9.  The revision Statement  . . . . . . . . . . . . . . .  40  44
       7.1.10. Usage Example . . . . . . . . . . . . . . . . . . . .  41  45
     7.2.  The submodule Statement . . . . . . . . . . . . . . . . .  41  45
       7.2.1.  The submodule's Substatements . . . . . . . . . . . .  43  47
       7.2.2.  The belongs-to Statement  . . . . . . . . . . . . . .  44  48
       7.2.3.  Usage Example . . . . . . . . . . . . . . . . . . . .  45  49
     7.3.  The typedef Statement . . . . . . . . . . . . . . . . . .  45  49
       7.3.1.  The typedef's Substatements . . . . . . . . . . . . .  46  50
       7.3.2.  The typedef's type Statement  . . . . . . . . . . . .  46  50
       7.3.3.  The units Statement . . . . . . . . . . . . . . . . .  46  50
       7.3.4.  The typedef's default Statement . . . . . . . . . . .  46  50
       7.3.5.  Usage Example . . . . . . . . . . . . . . . . . . . .  47  51
     7.4.  The type Statement  . . . . . . . . . . . . . . . . . . .  47  51
       7.4.1.  The type's Substatements  . . . . . . . . . . . . . .  47  51
     7.5.  The container Statement . . . . . . . . . . . . . . . . .  47  51
       7.5.1.  The container's Substatements . . . . . . . . . . . .  48  52
       7.5.2.  The must Statement  . . . . . . . . . . . . . . . . .  48  52
       7.5.3.  The must's Substatements  . . . . . . . . . . . . . .  49  53
       7.5.4.  The presence Statement  . . . . . . . . . . . . . . .  50  54
       7.5.5.  The container's Child Node Statements . . . . . . . .  50  55
       7.5.6.  XML Encoding Rules  . . . . . . . . . . . . . . . . .  50  55
       7.5.7.  NETCONF <edit-config> Operations  . . . . . . . . . .  51  55
       7.5.8.  Usage Example . . . . . . . . . . . . . . . . . . . .  51  56
     7.6.  The leaf Statement  . . . . . . . . . . . . . . . . . . .  52  57
       7.6.1.  The leaf's Substatements  . . . . . . . . . . . . . .  53  58
       7.6.2.  The leaf's type Statement . . . . . . . . . . . . . .  53  58
       7.6.3.  The leaf's default Statement  . . . . . . . . . . . .  53  58
       7.6.4.  The leaf's mandatory Statement  . . . . . . . . . . .  53  58
       7.6.5.  XML Encoding Rules  . . . . . . . . . . . . . . . . .  54  59
       7.6.6.  NETCONF <edit-config> Operations  . . . . . . . . . .  54  59
       7.6.7.  Usage Example . . . . . . . . . . . . . . . . . . . .  54  59
     7.7.  The leaf-list Statement . . . . . . . . . . . . . . . . .  55  60
       7.7.1.  The leaf-list's Substatements . . . . . . . . . . . .  56  61
       7.7.2.  The min-elements Statement  . . . . . . . . . . . . .  56  61
       7.7.3.  The max-elements Statement  . . . . . . . . . . . . .  56  61
       7.7.4.  The ordered-by Statement  . . . . . . . . . . . . . .  56  61
       7.7.5.  XML Encoding Rules  . . . . . . . . . . . . . . . . .  57  62
       7.7.6.  NETCONF <edit-config> operations  . . . . . . . . . .  57  62
       7.7.7.  Usage Example . . . . . . . . . . . . . . . . . . . .  58  63
     7.8.  The list Statement  . . . . . . . . . . . . . . . . . . .  59  65
       7.8.1.  The list's Substatements  . . . . . . . . . . . . . .  60  65
       7.8.2.  The list's key Statement  . . . . . . . . . . . . . .  60  66
       7.8.3.  The lists's unique Statement  . . . . . . . . . . . .  61  67
       7.8.4.  The list's Child Node Statements  . . . . . . . . . .  62  68
       7.8.5.  XML Encoding Rules  . . . . . . . . . . . . . . . . .  62  68
       7.8.6.  NETCONF <edit-config> operations  . . . . . . . . . .  62  68
       7.8.7.  Usage Example . . . . . . . . . . . . . . . . . . . .  63  69
     7.9.  The choice Statement  . . . . . . . . . . . . . . . . . .  66  72
       7.9.1.  The choice's Substatements  . . . . . . . . . . . . .  66  73
       7.9.2.  The choice's case Statement . . . . . . . . . . . . .  66  73
       7.9.3.  The choice's default Statement  . . . . . . . . . . .  68  74
       7.9.4.  The choice's mandatory Statement  . . . . . . . . . .  69  76
       7.9.5.  XML Encoding Rules  . . . . . . . . . . . . . . . . .  69  76
       7.9.6.  NETCONF <edit-config> operations  . . . . . . . . . .  69  76
       7.9.7.  Usage Example . . . . . . . . . . . . . . . . . . . .  70  76
     7.10. The anyxml Statement  . . . . . . . . . . . . . . . . . .  71  77
       7.10.1. The anyxml's Substatements  . . . . . . . . . . . . .  71  78
       7.10.2. XML Encoding Rules  . . . . . . . . . . . . . . . . .  71  78
       7.10.3. NETCONF <edit-config> operations  . . . . . . . . . .  71  78
       7.10.4. Usage Example . . . . . . . . . . . . . . . . . . . .  72  79
     7.11. The grouping Statement  . . . . . . . . . . . . . . . . .  72  79
       7.11.1. The grouping's Substatements  . . . . . . . . . . . .  74  80
       7.11.2. Usage Example . . . . . . . . . . . . . . . . . . . .  74  80
     7.12. The uses Statement  . . . . . . . . . . . . . . . . . . .  74  80
       7.12.1. The uses's Substatements  . . . . . . . . . . . . . .  75  81
       7.12.2. The uses's Refinement Statements refine Statement  . . . . . . . . . . . . . .  75 . .  81
       7.12.3. XML Encoding Rules  . . . . . . . . . . . . . . . . .  76  82
       7.12.4. Usage Example . . . . . . . . . . . . . . . . . . . .  76  82
     7.13. The rpc Statement . . . . . . . . . . . . . . . . . . . .  77  83
       7.13.1. The rpc's Substatements . . . . . . . . . . . . . . .  78  84
       7.13.2. The input Statement . . . . . . . . . . . . . . . . .  78  84
       7.13.3. The output Statement  . . . . . . . . . . . . . . . .  79  85
       7.13.4. XML Encoding Rules  . . . . . . . . . . . . . . . . .  80  86
       7.13.5. Usage Example . . . . . . . . . . . . . . . . . . . .  80  86
     7.14. The notification Statement  . . . . . . . . . . . . . . .  81  87
       7.14.1. The notification's Substatements  . . . . . . . . . .  82  88
       7.14.2. XML Encoding Rules  . . . . . . . . . . . . . . . . .  82  88
       7.14.3. Usage Example . . . . . . . . . . . . . . . . . . . .  82  88
     7.15. The augment Statement . . . . . . . . . . . . . . . . . .  83  89
       7.15.1. The augment's Substatements . . . . . . . . . . . . .  84  90
       7.15.2. The when Statement  . . . . . . . . . . . . . . . . .  84
       7.15.3. XML Encoding Rules  . . . . . . . . . . . . . . . . .  85
       7.15.4.  90
       7.15.3. Usage Example . . . . . . . . . . . . . . . . . . . .  85  91
     7.16. The extension identity Statement  . . . . . . . . . . . . . . . . .  87  93
       7.16.1. The extension's identity's Substatements  . . . . . . . . . . . .  88  93
       7.16.2. The argument base Statement  . . . . . . . . . . . . . . .  88 . .  93
       7.16.3. Usage Example . . . . . . . . . . . . . . . . . . . .  88  94
     7.17. Common Statements . . . The extension Statement . . . . . . . . . . . . . . . . .  89  94
       7.17.1. The config Statement  . . . . extension's Substatements . . . . . . . . . . . .  89  95
       7.17.2. The status argument Statement  . . . . . . . . . . . . . . . .  90  95
       7.17.3. The description Statement . Usage Example . . . . . . . . . . . . .  90
       7.17.4. The reference Statement . . . . . . .  96
     7.18. Conformance-related Statements  . . . . . . . .  90
   8.  Built-in Types . . . . .  96
       7.18.1. The feature Statement . . . . . . . . . . . . . . . .  96
       7.18.2. The if-feature Statement  . .  91
     8.1.  The Integer Built-in Types . . . . . . . . . . . .  98
       7.18.3. The deviation Statement . . .  91
       8.1.1.  Lexicographic Representation . . . . . . . . . . . .  92
       8.1.2.  Restrictions  98
     7.19. Common Statements . . . . . . . . . . . . . . . . . . . .  92
       8.1.3. 101
       7.19.1. The range config Statement  . . . . . . . . . . . . . . . . .  92
       8.1.4.  Usage Example 101
       7.19.2. The status Statement  . . . . . . . . . . . . . . . . 101
       7.19.3. The description Statement . . . .  93
     8.2.  The Floating Point Built-in Types . . . . . . . . . . 102
       7.19.4. The reference Statement . .  93
       8.2.1.  Lexicographic Representation . . . . . . . . . . . .  94
       8.2.2.  Restrictions . 102
       7.19.5. The when Statement  . . . . . . . . . . . . . . . . . 102
   8.  Constraints . .  94
       8.2.3.  Usage Example . . . . . . . . . . . . . . . . . . . .  94
     8.3.  The string Built-in Type . . . 104
   9.  Built-in Types  . . . . . . . . . . . . .  94
       8.3.1.  Lexicographic Representation . . . . . . . . . . 105
     9.1.  Canonical representation  . .  94
       8.3.2.  Restrictions . . . . . . . . . . . . . . . . . . . .  94
       8.3.3. 105
     9.2.  The length Statement Integer Built-in Types  . . . . . . . . . . . . . . . 105
       9.2.1.  Lexicographic Representation  .  95
       8.3.4.  Usage Example . . . . . . . . . . . 106
       9.2.2.  Canonical Form  . . . . . . . . .  96
       8.3.5.  The pattern Statement . . . . . . . . . . 106
       9.2.3.  Restrictions  . . . . . .  96
       8.3.6.  Usage Example . . . . . . . . . . . . . . 106
       9.2.4.  The range Statement . . . . . .  96
     8.4.  The boolean Built-in Type . . . . . . . . . . . 107
       9.2.5.  Usage Example . . . . .  97
       8.4.1.  Lexicographic Representation . . . . . . . . . . . .  97
       8.4.2.  Restrictions . . . 108
     9.3.  The Floating Point Built-in Types . . . . . . . . . . . . 108
       9.3.1.  Lexicographic Representation  . . . . .  97
     8.5.  The enumeration Built-in Type . . . . . . . 108
       9.3.2.  Canonical Form  . . . . . . .  97
       8.5.1.  Lexicographic Representation . . . . . . . . . . . .  97
       8.5.2. 108
       9.3.3.  Restrictions  . . . . . . . . . . . . . . . . . . . .  97
       8.5.3.  The enum Statement 108
       9.3.4.  Usage Example . . . . . . . . . . . . . . . . .  97
       8.5.4.  Usage Example . . . 109
     9.4.  The string Built-in Type  . . . . . . . . . . . . . . . . 109
       9.4.1.  Lexicographic Representation  . .  98
     8.6.  The bits Built-in Type . . . . . . . . . . 109
       9.4.2.  Canonical Form  . . . . . . .  99
       8.6.1.  Restrictions . . . . . . . . . . . . 109
       9.4.3.  Restrictions  . . . . . . . .  99
       8.6.2.  Lexicographic Representation . . . . . . . . . . . .  99
       8.6.3. 109
       9.4.4.  The bit length Statement  . . . . . . . . . . . . . . . . . .  99
       8.6.4. 109
       9.4.5.  Usage Example . . . . . . . . . . . . . . . . . . . . 100
     8.7. 110
       9.4.6.  The binary Built-in Type pattern Statement . . . . . . . . . . . . . . . . 100
       8.7.1.  Restrictions 111
       9.4.7.  Usage Example . . . . . . . . . . . . . . . . . . . . 100
       8.7.2.  Lexicographic Representation 111
     9.5.  The boolean Built-in Type . . . . . . . . . . . . 100
     8.8.  The keyref Built-in Type . . . . 111
       9.5.1.  Lexicographic Representation  . . . . . . . . . . . . 101
       8.8.1. 112
       9.5.2.  Restrictions  . . . . . . . . . . . . . . . . . . . . 101
       8.8.2. 112
     9.6.  The path Statement enumeration Built-in Type . . . . . . . . . . . . . . 112
       9.6.1.  Lexicographic Representation  . . . 101
       8.8.3.  Lexicographic Representation . . . . . . . . . 112
       9.6.2.  Canonical Form  . . . 101
       8.8.4.  Usage Example . . . . . . . . . . . . . . . . 112
       9.6.3.  Restrictions  . . . . 101
     8.9.  The empty Built-in Type . . . . . . . . . . . . . . . . 112
       9.6.4.  The enum Statement  . 103
       8.9.1.  Restrictions . . . . . . . . . . . . . . . . 112
       9.6.5.  Usage Example . . . . 103
       8.9.2.  Lexicographic Representation . . . . . . . . . . . . 103
       8.9.3.  Usage Example . . . . 113
     9.7.  The bits Built-in Type  . . . . . . . . . . . . . . . . 103
     8.10. The union Built-in Type . 114
       9.7.1.  Restrictions  . . . . . . . . . . . . . . . . 104
       8.10.1. Restrictions . . . . 114
       9.7.2.  Lexicographic Representation  . . . . . . . . . . . . 114
       9.7.3.  Canonical Form  . . . . 104
       8.10.2. Lexicographic Representation . . . . . . . . . . . . 104
     8.11. . . . 114
       9.7.4.  The instance-identifier Built-in Type bit Statement . . . . . . . . . . 104
       8.11.1. Restrictions . . . . . . . . 114
       9.7.5.  Usage Example . . . . . . . . . . . . 105
       8.11.2. Lexicographic Representation . . . . . . . . 115
     9.8.  The binary Built-in Type  . . . . 105
       8.11.3. Usage Example . . . . . . . . . . . . 115
       9.8.1.  Restrictions  . . . . . . . . 105
   9.  Updating a Module . . . . . . . . . . . . 116
       9.8.2.  Lexicographic Representation  . . . . . . . . . . 106
   10. YIN . . 116
       9.8.3.  Canonical Form  . . . . . . . . . . . . . . . . . . . 116
     9.9.  The keyref Built-in Type  . . . . . . . . 107
     10.1. Formal YIN Definition . . . . . . . . 116
       9.9.1.  Restrictions  . . . . . . . . . . 107
     10.2. Transformation Algorithm YANG-2-YIN . . . . . . . . . . 116
       9.9.2.  The path Statement  . 107
       10.2.1. Usage Example . . . . . . . . . . . . . . . . 116
       9.9.3.  Lexicographic Representation  . . . . 109
     10.3. Transformation Algorithm YIN-2-YANG . . . . . . . . 117
       9.9.4.  Canonical Form  . . . 109
       10.3.1. Tabulation, Formatting . . . . . . . . . . . . . . . 110
   11. YANG ABNF Grammar . 117
       9.9.5.  Usage Example . . . . . . . . . . . . . . . . . . . . 117
     9.10. The identityref Built-in Type . 111
   12. Error Responses for YANG Related Errors . . . . . . . . . . . 130
     12.1. Error Message for Data that Violates a YANG unique
           Statement: . . 118
       9.10.1. Restrictions  . . . . . . . . . . . . . . . . . . . . 118
       9.10.2. The identityref's base Statement  . 130
     12.2. Error Message for Data that Violates a YANG
           max-elements Statement: . . . . . . . . . 119
       9.10.3. Lexicographic Representation  . . . . . . . . 130
     12.3. Error Message for Data that Violates a YANG
           min-elements Statement: . . . . 119
       9.10.4. Usage Example . . . . . . . . . . . . . 130
     12.4. Error Message for Data that Violates a YANG must
           statement: . . . . . . . 119
     9.11. The empty Built-in Type . . . . . . . . . . . . . . . . 131
     12.5. Error Message for the "insert" Operation . 120
       9.11.1. Restrictions  . . . . . . . 131
   13. IANA Considerations . . . . . . . . . . . . . 120
       9.11.2. Lexicographic Representation  . . . . . . . . 132
   14. Security Considerations . . . . 120
       9.11.3. Canonical Representation  . . . . . . . . . . . . . . 120
       9.11.4. Usage Example . 133
   15. Contributors . . . . . . . . . . . . . . . . . . . 120
     9.12. The union Built-in Type . . . . . 134
   16. References . . . . . . . . . . . . 120
       9.12.1. Restrictions  . . . . . . . . . . . . . 135
     16.1. Normative References . . . . . . . 121
       9.12.2. Lexicographic Representation  . . . . . . . . . . . 135
     16.2. Non-Normative References . 121
       9.12.3. Canonical Form  . . . . . . . . . . . . . . . 136
   Appendix A.  ChangeLog . . . . 121
     9.13. The instance-identifier Built-in Type . . . . . . . . . . 121
       9.13.1. Restrictions  . . . . . . . 137
     A.1.  Version -01 . . . . . . . . . . . . . 121
       9.13.2. Lexicographic Representation  . . . . . . . . . . 137
     A.2.  Version -00 . . 121
       9.13.3. Canonical Form  . . . . . . . . . . . . . . . . . . . 122
       9.13.4. Usage Example . . 138
   Author's Address . . . . . . . . . . . . . . . . . . 122
   10. Updating a Module . . . . . . 139
   Intellectual Property and Copyright Statements . . . . . . . . . 140

1.  Introduction

   Today, the NETCONF protocol [RFC4741] lacks a standardized way to
   create data models.  Instead, vendors are forced to use proprietary
   solutions.  In order for NETCONF to be a interoperable protocol,
   models must be defined in a vendor-neutral way.  YANG provides the
   language and rules for defining such models for use with NETCONF.

   YANG is a data modeling language used to model configuration and
   state data manipulated by the NETCONF protocol, NETCONF remote
   procedure calls, and NETCONF notifications.  This document describes
   the syntax and semantics of the YANG language, how the data model
   defined in a YANG module is represented in XML, and how NETCONF
   operations are used to manipulate the data.

2.  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].

3.  Terminology

   o  anyxml: A node which can contain an unknown chunk of XML data.

   o  augment: Adds new nodes to a previously defined node.

   o  base type: The type from which a derived type was derived, which
      may be either a built-in type or another derived type.

   o  built-in type: A . . . . . . . 123
   11. YIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
     11.1. Formal YIN Definition . . . . . . . . . . . . . . . . . . 126
     11.2. Transformation Algorithm YANG-2-YIN . . . . . . . . . . . 126
       11.2.1. Usage Example . . . . . . . . . . . . . . . . . . . . 128
     11.3. Transformation Algorithm YIN-2-YANG . . . . . . . . . . . 129
       11.3.1. Tabulation, Formatting  . . . . . . . . . . . . . . . 129
   12. YANG data type defined in the ABNF Grammar . . . . . . . . . . . . . . . . . . . . . . 130
   13. Error Responses for YANG language, such
      as uint32 or string.

   o  choice: A node where only one of a number of identified
      alternative values is valid.

   o  configuration data: The set of writable data Related Errors . . . . . . . . . . . 151
     13.1. Error Message for Data that is required to
      transform a system from its initial default state into its current
      state [RFC4741].

   o  container: An interior node in the data tree which exist in at
      most one instance.  A container node has no value, but rather Violates a
      set of child nodes.

   o  data definition statement: A statement YANG unique
           Statement:  . . . . . . . . . . . . . . . . . . . . . . . 151
     13.2. Error Message for Data that defines new data
      nodes.  One of container, leaf, leaf-list, list, augment, uses,
      and anyxml.

   o  data model: A data model describes how data is represented and
      accessed.

   o  data model object: A definition within Violates a module YANG
           max-elements Statement: . . . . . . . . . . . . . . . . . 151
     13.3. Error Message for Data that represents a
      construct which can be accessed via Violates a network management protocol.
      Also called an object.

   o  data node: A node in the schema tree YANG
           min-elements Statement: . . . . . . . . . . . . . . . . . 151
     13.4. Error Message for Data that can be instantiated in a
      data tree.  One of container, leaf, leaf-list, list, and anyxml.

   o  data tree: The instantiated tree of configuration and state data
      on a device.

   o  derived type: A type which is derived from Violates a built-in type (such
      as uint32), or another derived type.

   o  extension: An extension attaches non-YANG semantics to nodes.  The
      extension statement defines new statements to express these
      semantics.

   o  grouping: A reusable set of nodes, which may be used locally in
      the module, in modules which include it, and by other modules
      which import from it.

   o  identifier: Used to identify different kinds of YANG items by
      name.

   o  instance identifier: A mechanism for identifying a particular node
      in a data tree.

   o  interior node: Nodes within a hierarchy that are not leaf nodes.

   o  leaf: A node in the data tree with a value but no child nodes.

   o  leaf-list: Like the leaf node but defines a set of uniquely
      identifiable nodes rather than a single node.  Each node has a
      value but no child nodes.

   o  list: Interior nodes in the data tree which may exist in multiple
      instances.  A list node has no value, but rather a set of child
      nodes.

   o  MIB: A Management Information Base, traditionally referring to a
      management information defined using SNMP's SMI.

   o  module: A YANG module defines a hierarchy of nodes which can be
      used must
           statement:  . . . . . . . . . . . . . . . . . . . . . . . 152
     13.5. Error Message for NETCONF-based operations.  With its definitions and the
      definitions it imports or includes from elsewhere, a module is
      self-contained and "compilable".

   o  RPC: A Remote Procedure Call, as used within the NETCONF protocol.

   o  RPC method: A specific Remote Procedure Call, as used within the
      NETCONF protocol.  Also called a protocol operation.

   o  schema node: A node in the schema tree.  One of container, leaf,
      leaf-list, "insert" Operation  . . . . . . . . 152
   14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 153
   15. Security Considerations . . . . . . . . . . . . . . . . . . . 154
   16. Contributors  . . . . . . . . . . . . . . . . . . . . . . . . 155
   17. References  . . . . . . . . . . . . . . . . . . . . . . . . . 156
     17.1. Normative References  . . . . . . . . . . . . . . . . . . 156
     17.2. Non-Normative References  . . . . . . . . . . . . . . . . 157
   Appendix A.  ChangeLog  . . . . . . . . . . . . . . . . . . . . . 158
     A.1.  Version -02 . . . . . . . . . . . . . . . . . . . . . . . 158
     A.2.  Version -01 . . . . . . . . . . . . . . . . . . . . . . . 158
     A.3.  Version -00 . . . . . . . . . . . . . . . . . . . . . . . 159
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . 160
   Intellectual Property and Copyright Statements  . . . . . . . . . 161

1.  Introduction

   Today, the NETCONF protocol [RFC4741] lacks a standardized way to
   create data models.  Instead, vendors are forced to use proprietary
   solutions.  In order for NETCONF to be a interoperable protocol,
   models must be defined in a vendor-neutral way.  YANG provides the
   language and rules for defining such models for use with NETCONF.

   YANG is a data modeling language used to model configuration and
   state data manipulated by the NETCONF protocol, NETCONF remote
   procedure calls, and NETCONF notifications.  This document describes
   the syntax and semantics of the YANG language, how the data model
   defined in a YANG module is represented in XML, and how NETCONF
   operations are used to manipulate the data.

2.  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].

3.  Terminology

   o  anyxml: A node which can contain an unknown chunk of XML data.

   o  augment: Adds new nodes to a previously defined node.

   o  base type: The type from which a derived type was derived, which
      may be either a built-in type or another derived type.

   o  built-in type: A YANG data type defined in the YANG language, such
      as uint32 or string.

   o  choice: A node where only one of a number of identified
      alternative values is valid.

   o  configuration data: The set of writable data that is required to
      transform a system from its initial default state into its current
      state [RFC4741].

   o  conformance: A measure of how accurately a device follows the
      model.

   o  container: An interior node in the data tree which exist in at
      most one instance.  A container node has no value, but rather a
      set of child nodes.

   o  data definition statement: A statement that defines new data
      nodes.  One of container, leaf, leaf-list, list, choice, case,
      augment, uses, and anyxml.

   o  data model: A data model describes how data is represented and
      accessed.

   o  data model object: A definition within a module that represents a
      construct which can be accessed via a network management protocol.
      Also called an object.

   o  data node: A node in the schema tree that can be instantiated in a
      data tree.  One of container, leaf, leaf-list, list, and anyxml.

   o  data tree: The instantiated tree of configuration and state data
      on a device.

   o  derived type: A type which is derived from a built-in type (such
      as uint32), or another derived type.

   o  device deviation: A failure of the device to implement the module
      faithfully.

   o  extension: An extension attaches non-YANG semantics to nodes.  The
      extension statement defines new statements to express these
      semantics.

   o  feature: A mechanism for marking a portion of the model as
      optional.  Definitions can be tagged with a feature name and are
      only valid on devices which support that feature.

   o  grouping: A reusable set of nodes, which may be used locally in
      the module, in modules which include it, and by other modules
      which import from it.

   o  identifier: Used to identify different kinds of YANG items by
      name.

   o  instance identifier: A mechanism for identifying a particular node
      in a data tree.

   o  interior node: Nodes within a hierarchy that are not leaf nodes.

   o  leaf: A node in the data tree with a value but no child nodes.

   o  leaf-list: Like the leaf node but defines a set of uniquely
      identifiable nodes rather than a single node.  Each node has a
      value but no child nodes.

   o  list: Interior nodes in the data tree which may exist in multiple
      instances.  A list node has no value, but rather a set of child
      nodes.

   o  MIB: A Management Information Base, traditionally referring to a
      management information defined using SNMP's SMI.

   o  module: A YANG module defines a hierarchy of nodes which can be
      used for NETCONF-based operations.  With its definitions and the
      definitions it imports or includes from elsewhere, a module is
      self-contained and "compilable".

   o  RPC: A Remote Procedure Call, as used within the NETCONF protocol.

   o  RPC method: A specific Remote Procedure Call, as used within the
      NETCONF protocol.  Also called a protocol operation.

   o  schema node: A node in the schema tree.  One of container, leaf,
      leaf-list, list, choice, case, rpc, input, output, notification,
      and anyxml.

   o  schema node identifier: A mechanism for identifying a particular
      node in the schema tree.

   o  schema tree: The definition hierarchy specified within a module.

   o  state data: The additional data on a system that is not
      configuration data such as read-only status information and
      collected statistics [RFC4741].

   o  submodule: A partial module definition which contributes derived
      types, groupings, data nodes, RPCs, and notifications to a module.
      A YANG module can be constructed from a number of submodules.

   o  uses: The "uses" statement is used to instantiate the set of nodes
      defined in a grouping statement.  The instantiated nodes may be
      refined and augmented to tailor them to any specific needs.

3.1.  Mandatory nodes

   A mandatory node is one of:

   o  A leaf or choice node with a "mandatory" statement with the value
      "true".

   o  A list or leaf-list node with a "min-elements" statement with a
      value greater than zero.

   o  A container node without a "presence" statement, which has has at
      least one mandatory node as a child.

4.  YANG Overview

4.1.  Functional Overview

   YANG is a language used to model data for the NETCONF protocol.  A
   YANG module defines a hierarchy of nodes which can be used for
   NETCONF-based operations, including configuration, state data, remote
   procedure calls (RPCs), and notifications.  This allows a complete
   description of all data sent between a NETCONF client and server.

   YANG models the hierarchical organization of data as a tree in which
   each node has a name, and either a value or a set of child nodes.
   YANG provides clear and concise descriptions of the nodes, as well as
   the interaction between those nodes.

   YANG structures data models into modules and
      notification.

   o  schema node identifier: 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.

   YANG models can describe constraints to be enforced on the data,
   restricting the appearance or value of nodes based on the presence or
   value of other nodes in the hierarchy.  These constraints are
   enforceable by either the client or the server, and valid content
   must abide by them.

   YANG defines a set of built-in types, and has a type mechanism
   through which additional types may be defined.  Derived types can
   restrict their base type's set of valid values using mechanisms like
   range or pattern restrictions that can be enforced by clients or
   servers.  They can also define usage conventions for use of the
   derived type, such as a string-based type that contains a host name.

   YANG permits the definition of complex types using reusable grouping
   of nodes.  The instantiation of these groupings can refine or augment
   the nodes, allowing it to tailor the nodes to its particular needs.
   Derived types and groupings can be defined in one module or submodule
   and used in either that location or in another module or submodule
   that imports or includes it.

   YANG organizational constructs include defining lists of nodes with
   the same names and identifying the keys which distinguish list
   members from each other.  Such lists may be defined as either sorted
   by user or automatically sorted by the system.  For user-sorted
   lists, operations are defined for manipulating the order of the
   nodes.

   YANG modules can be translated into an XML format called YIN
   (Section 11), allowing applications using XML parsers and XSLT
   scripts to operate on the models.

   YANG strikes a particular
      node balance between high-level object-oriented modeling
   and low-level bits-on-the-wire encoding.  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.

   YANG is an extensible language, allowing extension statements to be
   defined by standards bodies, vendors, and individuals.  The statement
   syntax allows these extensions to coexist with standard YANG
   statements in a natural way, while making extensions stand out
   sufficiently for the reader to notice them.

   YANG resists the tendency to solve all possible problems, limiting
   the problem space to allow expression of NETCONF data models, not
   arbitrary XML documents or arbitrary data models.  The data models
   described by YANG are designed to be easily operated upon by NETCONF
   operations.

   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.

   Like NETCONF, YANG targets smooth integration with device's native
   management infrastructure.  This allows implementations to leverage
   their existing access control mechanisms to protect or expose
   elements of the schema tree.

   o  schema tree: The definition hierarchy specified within a module.

   o  state data: The additional data on a system model.

4.2.  Language Overview

   This section introduces some important constructs used in YANG that
   will aid in the understanding of the language specifics in later
   sections.

4.2.1.  Modules and Submodules

   YANG defines modules using the "module" statement.  This statement
   defines the name of the module, which is not
      configuration data such typically used as read-only status information and
      collected statistics [RFC4741].

   o  submodule: the base
   name of the file containing the module.  The file suffix ".yang" is
   typically used for YANG files.  A partial module contains three types of
   statements: module-header statements, revision statements, and
   definition which contributes statements.  The module header statements describe the
   module and give information about the module itself, the revision
   statements give information about the history of the module, and the
   definition statements are the body of the module where the data model
   is defined.

   Submodule are partial modules that contribute derived types,
   groupings, data nodes, RPCs, RPCs and notifications to a module.  A YANG module can be constructed from
   may include a number of submodules.

   o  uses: submodules, but each submodule may belong to
   only one module.  The "uses" "include" statement allows a module or
   submodule to reference material in submodules, and the "import"
   statement allows references to material defined in other modules.

   To reference an item that is used defined in an external module it MUST be
   imported.  Identifiers that are neither defined, imported nor
   included MUST NOT be visible in the local module.

   To reference an item that is defined in one of its submodules, the
   module MUST include the submodule.

   A submodule that needs to instantiate reference an item defined in another
   submodule of the set same module, MUST include this submodule.

   There MUST NOT be any circular chains of nodes
      defined imports or includes.  For
   example, if submodule "a" includes submodule "b", "b" cannot include
   "a".

   When a definition in an external module is referenced, a grouping statement.  The instantiated nodes may locally
   defined prefix MUST be
      refined used, followed by ":", and augmented then the external
   identifier.  References to tailor them definitions in the local module MAY use
   the prefix notation.  References to any specific needs.

3.1.  Mandatory built-in data types (e.g., int32)
   MUST NOT use the prefix notation.

   Forward references are allowed in YANG.

4.2.2.  Data Modeling Basics

   YANG defines four types of nodes

   A mandatory node is one of:

   o  A leaf or choice node with a "mandatory" statement with for data modeling.  In each of the value
      "true".

   o  A list or leaf-list node with a "min-elements" statement with
   following subsections, the example shows the YANG syntax as well as a
      value greater than zero.

   o
   corresponding NETCONF XML representation.

4.2.2.1.  Leaf Nodes

   A container leaf node without contains simple data like an integer or a "presence" statement, which has string.  It has at
      least
   exactly one mandatory node as value of a child.

4.  YANG Overview

4.1.  Functional Overview particular type, and no child nodes.

   YANG is a language used to model data Example:

       leaf host-name {
           type string;
           description "Hostname for the this system";
       }

   NETCONF protocol. XML Encoding:

       <host-name>my.example.com</host-name>

   The "leaf" statement is covered in Section 7.6.

4.2.2.2.  Leaf-list Nodes

   A
   YANG module defines leaf-list is a hierarchy sequence of leaf nodes which can be used for
   NETCONF-based operations, including configuration, state data, remote
   procedure calls (RPCs), and notifications.  This allows a complete
   description with exactly one value of all data sent between a NETCONF client and server.
   particular type per leaf.

   YANG models the hierarchical organization Example:

     leaf-list domain-search {
         type string;
         description "List of data as a tree domain names to search";
     }

   NETCONF XML Encoding:

     <domain-search>high.example.com</domain-search>
     <domain-search>low.example.com</domain-search>
     <domain-search>everywhere.example.com</domain-search>

   The "leaf-list" statement is covered in which
   each Section 7.7.

4.2.2.3.  Container Nodes

   A container node has is used to group related nodes in a name, subtree.  A
   container has only child nodes and either a value or a set no value.  A container may contain
   any number of child nodes.
   YANG provides clear and concise descriptions nodes of the nodes, as well as
   the interaction between those nodes.

   YANG structures data models into modules and submodules.  A module
   can import data from other external modules, any type (including leafs, lists,
   containers, and include data from
   submodules. leaf-lists).

   YANG Example:

     container system {
         container login {
             leaf message {
                 type string;
                 description
                     "Message given at start of login session";
             }
         }
     }

   NETCONF XML Encoding:

     <system>
       <login>
         <message>Good morning, Dave</message>
       </login>
     </system>

   The hierarchy can be extended, allowing one module to
   add data nodes to the hierarchy defined "container" statement is covered in another module.  This
   augmentation can be conditional, with new nodes to appearing only if
   certain conditions are met.

   YANG models can describe constraints to be enforced on the data,
   restricting the appearance or value Section 7.5.

4.2.2.4.  List Nodes

   A list is a sequence of nodes based the presence list entries.  An entry is like a structure
   or
   value a record.  A list entry is uniquely identified by the values of other
   its key leafs.  A list entry can have multiple keys.  A list entry
   may contain any number of child nodes of any type (including leafs,
   lists, containers etc.).

   YANG Example:

     list user {
         key "name";
         leaf name {
             type string;
         }
         leaf full-name {
             type string;
         }
         leaf class {
             type string;
         }
     }

   NETCONF XML Encoding:

     <user>
       <name>glocks</name>
       <full-name>Goldie Locks</full-name>
       <class>intruder</class>
     </user>
     <user>
       <name>snowey</name>
       <full-name>Snow White</full-name>
       <class>free-loader</class>
     </user>
     <user>
       <name>rzull</name>
       <full-name>Repun Zell</full-name>
       <class>tower</class>
     </user>
   The "list" statement is covered in the hierarchy. Section 7.8.

4.2.2.5.  Example Module

   These constraints statements are
   enforceable by either the client or combined to define the server, and valid content
   must abide by them.

   YANG defines a set module:

     // Contents of built-in types, and has a "acme-system.yang"
     module acme-system {
         namespace "http://acme.example.com/system";
         prefix "acme";

         organization "ACME Inc.";
         contact "joe@acme.example.com";
         description
             "The module for entities implementing the ACME system.";

         revision 2007-06-09 {
             description "Initial revision.";
         }

         container system {
             leaf host-name {
                 type mechanism
   through which additional types may be defined.  Derived types can
   restrict their base type's set of valid values using mechanisms like
   range or pattern restrictions that can be enforced by clients or
   servers.  They can also define usage conventions string;
                 description "Hostname for use this system";
             }

             leaf-list domain-search {
                 type string;
                 description "List of the
   derived type, such as a string-based domain names to search";
             }

             container login {
                 leaf message {
                     type string;
                     description
                         "Message given at start of login session";
                 }

                 list user {
                     key "name";
                     leaf name {
                         type that contains a host name. string;
                     }
                     leaf full-name {
                         type string;
                     }
                     leaf class {
                         type string;
                     }
                 }
             }
         }
     }

4.2.3.  Operational Data

   YANG permits the definition of complex types using reusable grouping
   of nodes.  The instantiation of these groupings can refine or augment
   the nodes, allowing it to tailor model operational data, as well as configuration data, based
   on the nodes to "config" statement.  When a node is tagged with "config
   false", its particular needs.
   Derived types and groupings can subhierarchy is flagged as operational data, to be defined in one module or submodule
   and used in either that location or in another module or submodule
   that imports or includes it.

   YANG organizational constructs include defining lists of nodes with
   reported using NETCONF's <get> operation, not the same names <get-config>
   operation.  Parent containers, lists, and identifying key leafs are reported
   also, giving the keys which distinguish list
   members from each other.  Such lists may be defined as either sorted
   by user or automatically sorted by context for the system.  For user-sorted
   lists, operations operational data.

   In this example, two leafs are defined for manipulating the order of the
   nodes.

   YANG modules can be translated into an XML format called YIN
   (Section 10), allowing applications using XML parsers and XSLT
   scripts to operate on the models.

   YANG strikes a balance between high-level object-oriented modeling
   and low-level bits-on-the-wire encoding.  The reader of each interface, a YANG module
   can easily see the high-level view of the data model while seeing how
   the object will
   configured speed and an observed speed.  The observed speed is not
   configuration, so it can be encoded in returned with NETCONF <get> operations,
   but not with <get-config> operations.

   YANG  The observed speed is an extensible language, allowing extension statements to be
   defined by standards bodies, vendors, not
   configuration data, and individuals.  The statement
   syntax allows these extensions to coexist with standard cannot be manipulated using <edit-config>.

     list interface {
         key "name";
         config true;

         leaf name {
             type string;
         }
         leaf speed {
             type enumeration {
                 enum 10m;
                 enum 100m;
                 enum auto;
             }
         }
         leaf observed-speed {
             type uint32;
             config false;
         }
     }

4.2.4.  Built-in Types

   YANG
   statements in has a natural way, while making extensions stand out
   sufficiently for the reader set of built-in types, similar to notice them.

   YANG resists those of many
   programming languages, but with some differences due to special
   requirements from the tendency management domain.  The following table
   summarizes the built-in types discussed in Section 9:

   +---------------------+-------------+-------------------------------+
   | Name                | Type        | Description                   |
   +---------------------+-------------+-------------------------------+
   | binary              | Text        | Any binary data               |
   | bits                | Text/Number | A set of bits or flags        |
   | boolean             | Text        | "true" or "false"             |
   | empty               | Empty       | A leaf that does not have any |
   |                     |             | value                         |
   | enumeration         | Text/Number | Enumerated strings with       |
   |                     |             | associated numeric values     |
   | float32             | Number      | 32-bit IEEE floating point    |
   |                     |             | real number                   |
   | float64             | Number      | 64-bit IEEE floating point    |
   |                     |             | real number                   |
   | identityref         | Text        | A reference to solve all possible problems, limiting
   the problem space an abstract    |
   |                     |             | identity                      |
   | instance-identifier | Text        | References a data tree node   |
   | int8                | Number      | 8-bit signed integer          |
   | int16               | Number      | 16-bit signed integer         |
   | int32               | Number      | 32-bit signed integer         |
   | int64               | Number      | 64-bit signed integer         |
   | keyref              | Text/Number | A reference to allow expression a list's key   |
   |                     |             | value                         |
   | string              | Text        | Human readable string         |
   | uint8               | Number      | 8-bit unsigned integer        |
   | uint16              | Number      | 16-bit unsigned integer       |
   | uint32              | Number      | 32-bit unsigned integer       |
   | uint64              | Number      | 64-bit unsigned integer       |
   | union               | Text/Number | Choice of NETCONF data models, not
   arbitrary XML documents or arbitrary data models. member types        |
   +---------------------+-------------+-------------------------------+

   The data models
   described by "type" statement is covered in Section 9.

4.2.5.  Derived Types (typedef)

   YANG are designed to be easily operated upon by NETCONF
   operations.

   To can define derived types from base types using the extent possible, YANG maintains compatibility with SNMP's
   SMIv2 (Structure of Management Information version 2 [RFC2578],
   [RFC2579]).  SMIv2-based MIB modules "typedef"
   statement.  A base type can be automatically translated
   into YANG modules for read-only access.  However YANG is not
   concerned with reverse translation from YANG to SMIv2.

   Like NETCONF, YANG targets smooth integration with device's native
   management infrastructure.  This allows implementations to leverage
   their existing access control mechanisms to protect either a built-in type or expose
   elements a derived
   type, allowing a hierarchy of the data model.

4.2.  Language Overview

   This section introduces some important constructs derived types.

   A derived type can be used in as the argument for the "type" statement.

   YANG that
   will aid Example:

     typedef percent {
         type uint16 {
             range "0 .. 100";
         }
         description "Percentage";
     }

     leaf completed {
         type percent;
     }

   NETCONF XML Encoding:

     <completed>20</completed>

   The "typedef" statement is covered in the understanding Section 7.3.

4.2.6.  Reusable Node Groups (grouping)

   Groups of nodes can be assembled into the language specifics in later
   sections.

4.2.1.  Modules and Submodules

   YANG defines modules equivalent of complex types
   using the "module" "grouping" statement.  This statement "grouping" defines the name a set of nodes
   that are instantiated with the module, which is typically used "uses" statement:

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

   NETCONF XML Encoding:

     <peer>
       <destination>
         <address>192.0.2.1</address>
         <port>830</port>
       </destination>
     </peer>
   The grouping can be refined as it is used, allowing certain
   statements to be overridden.  In this example, the base
   name of description is
   refined:

     container connection {
         container source {
             uses target {
                 refine "address" {
                     description "Source IP address";
                 }
                 refine "port" {
                     description "Source port number";
                 }
             }
         }
         container destination {
             uses target {
                 refine "address" {
                     description "Destination IP address";
                 }
                 refine "port" {
                     description "Destination port number";
                 }
             }
         }
     }

   The "grouping" statement is covered in Section 7.11.

4.2.7.  Choices

   YANG allows the file containing data model to segregate incompatible nodes into
   distinct choices using the module.  The file suffix ".yang" is
   typically used for YANG files.  A module contains three types of
   statements: module-header statements, revision statements, "choice" and
   definition "case" statements.  The module header statements describe the
   module and give information about the module itself, the revision
   statements give information about the history
   "choice" statement contains a set of the module, and the
   definition "case" statements are the body which define
   sets of the module where the data model
   is defined.

   Submodule are partial modules schema nodes that contribute derived types,
   groupings, data nodes, RPCs and notifications to a module.  A module cannot appear together.  Each "case" may include a number of submodules,
   contain multiple nodes, but each submodule node may belong to appear in only one module.  The "include" statement allows "case"
   under a module or
   submodule to reference material "choice".

   When an element from one case is created, all elements from all other
   cases are implicitly deleted.  The device handles the enforcement of
   the constraint, preventing incompatibilities from existing in submodules, and the "import"
   statement allows references to material defined
   configuration.

   The choice and case nodes appear only in other modules.

   To reference an item that is defined the schema tree, not in an external module it MUST be
   imported.  Identifiers that the
   data tree or XML encoding.  The additional levels of hierarchy are neither defined nor imported MUST NOT
   be visible in
   not needed beyond the local module.

   To reference an item that conceptual schema.

   YANG Example:

     container food {
       choice snack {
           mandatory true;
           case sports-arena {
               leaf pretzel {
                   type empty;
               }
               leaf beer {
                   type empty;
               }
           }
           case late-night {
               leaf chocolate {
                   type enumeration {
                       enum dark;
                       enum milk;
                       enum first-available;
                   }
               }
           }
       }
    }

   NETCONF XML Encoding:

     <food>
       <chocolate>first-available</chocolate>
     </food>

   The "choice" statement is defined covered in one of its submodules, the Section 7.9.

4.2.8.  Extending Data Models (augment)

   YANG allows a module MUST include the submodule.

   A submodule that needs to reference an item defined in another
   submodule of insert additional nodes into data models,
   including both the same module, MUST include this submodule.

   There MUST NOT be any circular chains of imports current module (and its submodules) or includes.  For
   example, if submodule "a" includes submodule "b", "b" cannot include
   "a".

   When a definition in an external module
   module.  This is referenced, a locally
   defined prefix MUST be used, followed by ":", and then the external
   identifier.  References useful e.g. for vendors to definitions in the local module MAY use
   the prefix notation.  References add vendor-specific
   parameters to built-in standard data types (e.g., int32)
   MUST NOT use the prefix notation.

   Forward references are allowed models in YANG.

4.2.2.  Data Modeling Basics

   YANG an interoperable way.

   The "augment" statement defines four types of nodes for the location in the data modeling.  In each of model
   hierarchy where new nodes are inserted, and the
   following subsections, "when" statement
   defines the example shows conditions when the new nodes are valid.

   YANG syntax as well as a
   corresponding NETCONF XML representation.

4.2.2.1.  Leaf Nodes

   A Example:

     augment system/login/user {
         when "class != 'wheel'";
         leaf uid {
             type uint16 {
                 range "1000 .. 30000";
             }
         }
     }

   This example defines a "uid" node contains simple data like an integer or that only is valid when the user's
   "class" is not "wheel".

   If a string.  It has
   exactly one value module augments another model, the XML representation of the
   data will reflect the prefix of the augmenting model.  For example,
   if the above augmentation were in a particular type, and no child nodes.

   YANG Example:

       leaf host-name {
           type string;
           description "Hostname for this system";
       } module with prefix "other", the
   XML would look like:

   NETCONF XML Encoding:

       <host-name>my.example.com</host-name>

     <user>
       <name>alicew</name>
       <full-name>Alice N. Wonderland</full-name>
       <class>drop-out</class>
       <other:uid>1024</other:uid>
     </user>

   The "leaf" "augment" statement is covered in Section 7.6.

4.2.2.2.  Leaf-list Nodes

   A leaf-list is a sequence of leaf nodes with exactly one value 7.15.

4.2.9.  RPC Definitions

   YANG allows the definition of a
   particular type per leaf. NETCONF RPCs.  The method names, input
   parameters and output parameters are modeled using YANG data
   definition statements.

   YANG Example:

       leaf-list domain-search

     rpc activate-software-image {
         input {
             leaf image-name {
                 type string;
             }
         }
         output {
             leaf status {
                 type string;
           description "List of domain names to search";
             }
         }
     }
   NETCONF XML Encoding:

       <domain-search>high.example.com</domain-search>
       <domain-search>low.example.com</domain-search>
       <domain-search>everywhere.example.com</domain-search>

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <activate-software-image xmlns="http://acme.example.com/system">
         <name>acmefw-2.3</name>
      </activate-software-image>
     </rpc>

     <rpc-reply message-id="101"
                xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <status xmlns="http://acme.example.com/system">
         The "leaf-list" image acmefw-2.3 is being installed.
       </status>
     </rpc-reply>

   The "rpc" statement is covered in Section 7.7.

4.2.2.3.  Container Nodes

   A container node is 7.13.

4.2.10.  Notification Definitions

   YANG allows the definition of notifications suitable for NETCONF.
   YANG data definition statements are used to group related nodes in a subtree.  A
   container has only child nodes and no value.  A container may contain
   any number of child nodes model the content of any type (including leafs, lists,
   containers, and leaf-lists). the
   notification.

   YANG Example:

       container system

     notification link-failure {
           container login
         description "A link failure has been detected";
         leaf if-name {
             type keyref {
                 path "/interfaces/interface/name";
             }
         }
         leaf message if-admin-status {
             type string;
                   description
                       "Message given at start of login session";
               } ifAdminStatus;
         }
     }

   NETCONF XML Encoding:

       <system>
           <login>
               <message>Good morning, Dave</message>
           </login>
       </system>

     <notification
         xmlns="urn:ietf:params:netconf:capability:notification:1.0">
       <eventTime>2007-09-01T10:00:00Z</eventTime>
       <link-failure xmlns="http://acme.example.com/system">
         <if-name>so-1/2/3.0</if-name>
         <if-admin-status>up</if-admin-status>
       </link-failure>
     </notification>
   The "container" "notification" statement is covered in Section 7.5.

4.2.2.4.  List Nodes

   A list 7.14.

5.  Language Concepts

5.1.  Modules and Submodules

   The module is the base unit of definition in YANG.  A module defines
   a single data model.  A module can define a complete, cohesive model,
   or augment an existing data model with additional nodes.

   A NETCONF server may implement a number of modules, allowing multiple
   views of the same data, or multiple views of disjoint subsections of
   the device's data.  Alternatively, the server may implement only one
   module that defines all available data.  Any modules that are
   implemented MUST be available for all defined datastores.

   A module may be divided into submodules, based on the needs of the
   module owner.  The external view remains that of a single module,
   regardless of the presence or size of its submodules.

   A module uses the "include" statement to include its submodules, and
   the "import" statement to reference external modules.  Similarly, a
   submodule may use the "import" statement to reference other modules,
   and may use the "include" statement to reference other submodules
   within its module.  A module or submodule may not include submodules
   from other modules, nor may a submodule import its own module.

   The names of all standard modules must be unique, but different
   revisions of the same module should have the same name.  Developers
   of enterprise modules are encouraged to choose names for their
   modules that will have a sequence low probability of list entries.  An entry is like a structure colliding with standard
   or a record.  A list entry is uniquely identified other enterprise modules, e.g., by using the values enterprise or
   organization name as a prefix.

5.1.1.  Module Hierarchies

   YANG allows modeling of
   its key leafs.  A list entry can have data in multiple keys.  A list entry hierarchies, where data may contain any number of child
   have more than one root node.  Models that have multiple roots nodes of any type (including leafs,
   lists, containers etc.).
   are sometimes convenient, and are supported by YANG.

5.2.  File Layout

   YANG Example:

     list user {
         key "name";
         leaf name {
             type string;
         }
         leaf full-name {
             type string;
         }
         leaf class {
             type string;
         }
     }

   NETCONF XML Encoding:

     <user>
       <name>glocks</name>
       <full-name>Goldie Locks</full-name>
       <class>intruder</class>
     </user>
     <user>
       <name>snowey</name>
       <full-name>Snow White</full-name>
       <class>free-loader</class>
     </user>
     <user>
       <name>rzull</name>
       <full-name>Repun Zell</full-name>
       <class>tower</class>
     </user>
   The "list" statement is covered in Section 7.8.

4.2.2.5.  Example Module

   These statements modules and submodules are combined to define the module:

     // Contents of "acme-system.yang"
     module acme-system {
         namespace "http://acme.example.com/system";
         prefix "acme";

         organization "ACME Inc.";
         contact "joe@acme.example.com";
         description
             "The typically stored in files, one module for entities implementing
   or submodule per file, with the ACME system.";

         revision 2007-06-09 {
             description "Initial revision.";
         }

         container system {
             leaf host-name {
                 type string;
                 description "Hostname for this system";
             }

             leaf-list domain-search {
                 type string;
                 description "List name of domain names to search";
             }

             container login {
                 leaf message {
                     type string;
                     description
                         "Message the file given at start of login session";
                 }

                 list user {
                     key "name";
                     leaf by the
   concatenation of the module or submodule name {
                         type string;
                     }
                     leaf full-name {
                         type string;
                     }
                     leaf class {
                         type string;
                     }
                 }
             }
         }
     }

4.2.3.  Operational Data and the file suffix
   ".yang".  YANG compilers can model operational data, as well as configuration data, based
   on the "config" statement.  When a node is tagged with "config
   false", its subhierarchy is flagged as operational data, to be
   reported using NETCONF's <get> operation, not the <get-config>
   operation.  Parent containers, lists, find imported modules and key leafs are reported
   also, giving included
   submodules via this convention.  While the context YANG language defines
   modules, tools may compile submodules independently for performance
   and manageability reasons.  Many errors and warnings that cannot be
   detected during submodule compilation may be delayed until the operational data.

   In this example, two leafs
   submodules are defined for each interface, linked into a
   configured speed and an observed speed.  The observed speed is not
   configuration, so cohesive module.

5.3.  Object Based View of YANG

   While YANG models the configuration as a data tree, it can be returned with NETCONF <get> operations,
   but not with <get-config> operations. used in
   an object-based manner as well.

   The observed speed is not configuration data, and cannot be manipulated using <edit-config>.

     list interface {
         key "name";
         config true;

         leaf name {
             type string;
         }
         leaf speed {
             type enumeration {
                 enum 10m;
                 enum 100m;
                 enum auto;
             }
         }
         leaf observed-speed {
             type uint32;
             config false;
         }
     }

4.2.4.  Built-in Types

   YANG state data of the device is modeled as a tree
   of object instances (objects for short).  Each object in the tree has
   a type name (or managed object class name), a namespace, a (possibly
   empty) set of built-in types, similar to those attributes and a (possibly empty) set of many
   programming languages, but child objects.

   A managed object class could be defined as a grouping, containing
   just one list.  Attributes should be defined as leafs inside the
   list.  Child objects should be defined with some differences due the corresponding uses
   statements.

   A defined grouping unambiguously defines its properties, it has its
   own unique name, so when it is referred to special
   requirements from in the management domain.  The following table
   summarizes "uses" statement it
   is always the built-in types discussed in Section 8:

   +---------------------+-------------+-------------------------------+
   | Name                | Type        | Description                   |
   +---------------------+-------------+-------------------------------+
   | int8                | Number      | 8-bit signed integer          |
   | int16               | Number      | 16-bit signed integer         |
   | int32               | Number      | 32-bit signed integer         |
   | int64               | Number      | 64-bit signed integer         |
   | uint8               | Number      | 8-bit unsigned integer        |
   | uint16              | Number      | 16-bit unsigned integer       |
   | uint32              | Number      | 32-bit unsigned integer       |
   | uint64              | Number      | 64-bit unsigned integer       |
   | float32             | Number      | 32-bit IEEE floating point    |
   |                     |             | real number                   |
   | float64             | Number      | 64-bit IEEE floating point    |
   |                     |             | real number                   |
   | string              | Text        | Human readable string         |
   | boolean             | Text        | "true" or "false"             |
   | enumeration         | Text/Number | Enumerated strings with       |
   |                     |             | associated numeric values     |
   | bits                | Text/Number | A same well defined set of bits properties that we are using.

   The data tree can be defined as one or flags        |
   | binary              | Text        | Any binary more top level containers
   containing managed object classes defined as groupings.  All further
   levels of the data               |
   | keyref              | Text/Number | tree are defined by managed object classes
   containing further managed objects.

5.4.  XML Namespaces

   All YANG definitions are specified within a particular XML Namespace.
   Each module defines an XML namespace as a globally unique URI
   [RFC3986].  A reference NETCONF client or server uses the namespace during XML
   encoding of data.

   The namespace URI is advertised as a capability in the NETCONF
   <hello> message to indicate support for the YANG module by a list's key   |
   |                     |             | value                         |
   | empty               | Empty       | A leaf NETCONF
   server.  The capability URI advertised MUST be on the form:

     capability-string   = namespace-uri [ parameter-list ]
     parameter-list      = "?" parameter *( "&" parameter )
     parameter           = revision-parameter /
                           module-parameter /
                           feature-parameter /
                           deviation-parameter
     revision-parameter  = "revision=" revision-number
     module-parameter    = "module=" module-name
     feature-parameter   = "features=" feature *( "," feature )
     deviation-parameter = "deviations=" deviation *( "," deviation )
   Where "revision-number" is the revision of the module (see
   Section 7.1.9) that the server implements, "module-name" is the name
   of module as it appears in the "module" statement (see Section 7.1),
   "namespace-uri" is the namespace for the module as it appears in the
   "namespace" statement, "feature" is the name of an optional feature
   implemented by the device (see Section 7.18.1), and "deviation" is
   the name of a module defining device deviations (see Section 7.18.3).

   Namespaces for standard module names will be assigned by IANA.  They
   MUST be unique (but different revisions of the same module should
   have the same namespace).

   Namespaces for private module names will be assigned by the
   organization owning the module without a central registry.  It is
   recommended to choose namespaces that will have a low probability of
   colliding with standard or other enterprise modules, e.g. by using
   the enterprise or organization name in the namespace.

   The "namespace" statement is covered in Section 7.1.3.

5.4.1.  YANG Namespace

   YANG defines its own namespace for NETCONF <edit-config> operations.
   This namespace is "urn:ietf:params:xml:ns:yang:1" [XXX IANA].

5.5.  Ordering

   YANG supports two styles for ordering the entries within a list.  In
   many lists, the order of list entries does not have impact the
   implementation of the list's configuration, and the device is free to
   sort the list entries in any |
   |                     |             | value                         |
   | union               | Text/Number | Choice reasonable order.  The "description"
   string for the list may suggest an order.  YANG calls this style of member types        |
   | instance-identifier | Text        | References
   list "system ordered" and they are indicated with the statement
   "ordered-by system".

   For example, a data tree node   |
   +---------------------+-------------+-------------------------------+

   The "type" list of valid users would typically be sorted
   alphabetically, since the order in which the users appeared in the
   configuration would not impact the creation of those users' accounts.

   In the other style of lists, the order of list entries matters for
   the implementation of the list's configuration and the user is
   responsible for ordering the entries, while the device maintains that
   order.  YANG calls this style of list "user ordered" and they are
   indicated with the statement "ordered-by user".

   For example, the order in which firewall filters entries are applied
   to incoming traffic may affect how that traffic is covered in Section 8.

4.2.5.  Derived Types (typedef)

   YANG can define derived types from base types using filtered.  The
   user would need to decide if the "typedef"
   statement.  A base type can filter entry that discards all TCP
   traffic should be either a built-in type applied before or after the filter entry that
   allows all traffic from trusted interfaces.  The choice of order
   would be crucial.

   YANG provides a derived
   type, allowing a hierarchy rich set of derived types.

   A derived type can facilities within NETCONF's <edit-config>
   operation which allow the order of list entries in user-ordered lists
   to be used controlled.  List entries may be inserted or rearranged,
   positioned as the argument for first or last entry in the "type" statement.

   YANG Example:

     typedef percent {
         type uint16 {
             range "0 .. 100";
         }
         description "Percentage";
     }

     leaf completed {
         type percent;
     }

   NETCONF XML Encoding:

     <completed>20</completed> list, or positioned
   before or after another specific entry.

   The "typedef" "ordered-by" statement is covered in Section 7.3.

4.2.6.  Reusable Node Groups (grouping)

   Groups 7.7.4.

5.6.  Containers with Presence

   YANG supports two styles of containers, those which exist only for
   organizing the hierarchy of data nodes, and those whose presence in
   the configuration has an explicit meaning.

   In the first style, the container has no meaning of its own, existing
   only to contain child nodes.  The container data node is implicitly
   created when the first child data node is created.  The data node is
   implicitly deleted when the last non-key child is deleted, since an
   empty container has no meaning.

   For example, the set of scrambling options for SONET interfaces may
   be placed inside a "scrambling" container to enhance the organization
   of the configuration hierarchy, and to keep these nodes can be assembled into together.
   The "scrambling" node itself has no meaning, so removing the equivalent node
   when it becomes empty relieves the user from the task of complex types
   using performing
   this task.

   In the "grouping" statement. "grouping" defines a set second style, the presence of nodes
   that are instantiated with the "uses" statement:

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

   NETCONF XML Encoding:

     <peer>
       <destination>
         <address>192.0.2.1</address>
         <port>830</port>
       </destination>
     </peer> itself is
   configuration data, representing a single bit of configuration data.
   The grouping can be refined container acts as it is used, allowing certain
   statements to be overridden.  In both a configuration knob and a means of
   organizing related configuration.  These containers are explicitly
   created and deleted.

   YANG calls this example style a "presence container" and they are indicated
   using the description is
   refined:

     container connection {
         container source {
             uses target {
                 leaf address {
                     description "Source IP address";
                 }
                 leaf port {
                     description "Source port number";
                 }
             }
         } "presence" statement, which takes as its argument a text
   string indicating what the presence of the node means.

   For example, an "ssh" container destination {
             uses target {
                 leaf address {
                     description "Destination IP address";
                 }
                 leaf port {
                     description "Destination port number";
                 }
             }
         }
     } may turn on the ability to log into
   the device using ssh, but can also contain any ssh-related
   configuration knobs, such as connection rates or retry limits.

   The "grouping" "presence" statement is covered in Section 7.11.

4.2.7.  Choices 7.5.4.

5.7.  Scoping

   YANG allows uses static scoping.  Grouping definitions are resolved in the data model
   context in which they are defined, rather than the context in which
   they are used.  Users of groupings are not required to segregate incompatible nodes into
   distinct choices using import modules
   or include submodules to satisfy all references made by the "choice" and "case" statements.  The
   "choice" statement contains grouping.

   For example, if a set of "case" statements module defines a grouping in which a type is
   referenced, when the grouping is used in a second module, the type is
   resolved in the original module, not the second module.  There is no
   worry over conflicts if both modules define
   sets of schema nodes that cannot appear together.  Each "case" may
   contain multiple nodes, but each node the type, since there is
   no ambiguity.

5.8.  Nested Typedefs and Groupings

   Typedefs and groupings may appear in only one "case" nested under a "choice".

   When an element from one case is created, all elements from all other
   cases many YANG statements,
   allowing these to be lexically scoped by the hierarchy under which
   they appear.  This allows types and groupings to be defined near
   where they are implicitly deleted.  The device handles used, rather than placing them at the enforcement top level of the constraint, preventing incompatibilities from existing
   hierarchy.  The close proximity increases readability.

   Scoping also allows types to be defined without concern for naming
   conflicts between types in different submodules.  Type names can be
   specified without adding leading strings designed to prevent name
   collisions within large modules.

   Finally, scoping allows the
   configuration.

   The choice module author to keep types and case nodes appear groupings
   private to their module or submodule, preventing their reuse.  Since
   only in the schema tree, not in top-level types and groupings can be used outside the
   data tree module or XML encoding.  The additional levels
   submodule, the developer has more control over what pieces of hierarchy their
   module are
   not needed beyond presented to the conceptual schema.

   YANG Example:

     container food {
       choice snack {
           mandatory true;
           case sports-arena {
               leaf pretzel {
                   type empty;
               }
               leaf beer {
                   type empty;
               }
           }
           case late-night {
               leaf chocolate {
                   type enumeration {
                       enum dark;
                       enum milk;
                       enum first-available;
                   }
               }
           }
       }
    }

   NETCONF XML Encoding:

     <food>
       <chocolate>first-available</chocolate>
     </food>

   The "choice" statement outside world, supporting the need to
   hide internal information and maintaining a boundary between what is covered
   shared with the outside world and what is kept private.

   Scoped definitions MUST NOT shadow definitions at a higher scope.  A
   type or group cannot be defined if a higher level in Section 7.9.

4.2.8.  Extending Data Models (augment) the schema
   hierarchy has a definition with a matching identifier.

   When a YANG allows implementation resolves a module to insert additional nodes into data models,
   including both the current module (and its submodules) or an external
   module.  This is useful e.g. for vendors to add vendor-specific
   parameters reference to standard data models in an interoperable way.

   The "augment" statement defines unprefixed type
   or grouping, or one which uses the prefix of the local module, it
   searches up the location levels of hierarchy in the data model
   hierarchy where new nodes are inserted, and schema tree, starting at
   the "when" statement
   defines current level, for the conditions when definition of the new nodes are valid.

   YANG Example:

     augment system/login/user {
         when "class != 'wheel'";
         leaf uid { type uint16 {
                 range "1000 .. 30000";
             }
         }
     }

   This example defines a "uid" node that only is valid when the user's
   "class" or grouping.

5.9.  Conformance

   Conformance is not "wheel".

   If a module augments another model, the XML representation measure of how accurately a device follows the
   data will reflect
   model.  Generally speaking, devices are responsible for implementing
   the prefix of model faithfully, allowing applications to treat devices which
   implement the augmenting model.  For example,
   if model identically.  Deviations from the above augmentation were in a module with prefix "other", model can
   reduce the
   XML would look like:

   NETCONF XML Encoding:

     <user>
       <name>alicew</name>
       <full-name>Alice N. Wonderland</full-name>
       <class>drop-out</class>
       <other:uid>1024</other:uid>
     </user>

   The "augment" statement is covered in Section 7.15.

4.2.9.  RPC Definitions utility of the model and increase fragility into
   applications that use it.

   YANG allows modelers have three levels of conformance:

   o  the definition basic behavior of NETCONF RPCs.  The method names, input
   parameters and output parameters the model

   o  optional features that are modeled using YANG data
   definition statements.

   YANG Example:

     rpc activate-software-image {
         input {
             leaf image-name {
                 type string;
             }
         }
         output {
             leaf status {
                 type string;
             }
         }
     }
   NETCONF XML Encoding:

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <activate-software-image xmlns="http://acme.example.com/system">
         <name>acmefw-2.3</name>
      </activate-software-image>
     </rpc>

     <rpc-reply message-id="101"
                xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <data>
         <status xmlns="http://acme.example.com/system"> part of the model

   o  deviations from the model

   We will consider each of these in sequence.

5.9.1.  Basic Behavior

   The image acmefw-2.3 is being installed.
         </status>
       </data>
     </rpc-reply> model defines a contract between the client and server, which
   allows both parties to have faith the other knows the syntax and
   semantics behind the modeled data.  The "rpc" statement is covered in Section 7.13.

4.2.10.  Notification Definitions strength of YANG allows lies in the definition
   strength of notifications suitable this contract and the mindless devotion with which
   implementers follow it.

5.9.2.  Optional Features

   In many models, the modeler will allow sections of the model to be
   conditional, based on the device.  The device controls whether these
   conditional portions of the model are supported or valid for NETCONF.
   YANG that
   particular device.

   For example, a syslog data definition statements are used to model may choose to include the content of ability to
   save logs locally, but the
   notification.

   YANG Example:

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

   NETCONF XML Encoding:

     <notification
         xmlns="urn:ietf:params:netconf:capability:notification:1.0">
       <eventTime>2007-09-01T10:00:00Z</eventTime>
       <link-failure xmlns="http://acme.example.com/system">
         <if-name>so-1/2/3.0</if-name>
       </link-failure>
     </notification>

   The "notification" statement modeler will realize that this is covered in Section 7.14.

5.  Language Concepts

5.1.  Modules and Submodules

   The module only
   possible if the device has local storage.  If there is no local
   storage, an application should not tell the base unit of definition in YANG.  A module defines device to save logs.

   YANG supports this conditional mechanism using a single data model. construct called
   "features".  A module can define a complete, cohesive model,
   or augment an existing data model with additional nodes.

   A NETCONF server may implement a declare any number of modules, allowing multiple
   views of the same data, or multiple views of disjoint subsections of
   the device's data.  Alternatively, the server features, identified
   by simple strings, and may implement only one
   module that defines all available data.  Any modules that are
   implemented MUST be available for all defined datastores.

   A make portions of the module may be divided into submodules, optional based
   on those feature.  If the needs device supports a feature, then the
   corresponding portions of the module owner.  The external view remains are valid for that device.  If
   the device doesn't support the feature, those parts of the module are
   not valid, and applications should behave accordingly.

   Features give the modeler a single module,
   regardless mechanism for making portions of the presence or size of its submodules.

   A
   module uses conditional in a manner that is controlled by the "include" statement device.  The
   model can express constructs which are not universally present in all
   devices.  These features are included in the model definition,
   allowing a consistent view and allowing applications to include its submodules, learn which
   features are supported and tailor their behavior to the "import" statement device.

   Features are defined using the "feature" statement.  Definitions in
   the module that are conditional to reference external modules.  Similarly, a
   submodule may use the "import" feature are noted by the "if-
   feature" statement with the name of the feature as its argument.

   Further details are available in Section 7.18.1.

5.9.3.  Deviations

   In an ideal world, all devices would be required to reference other modules, implement the
   model exactly as defined, and may use deviations from the "include" statement model would not be
   allowed.  But in the real world, devices are often not able or
   willing to reference other submodules
   within its module.  A implement the model as written.  For YANG-based automation
   to deal with these device deviations, a mechanism must exist for
   devices to inform applications of the specifics of such deviations.

   For example, a BGP module or submodule may not include submodules
   from other modules, nor may a submodule import its own module.

   The names allow any number of all standard modules must be unique, BGP peers, but different
   revisions a
   particular device may only support 16 BGP peers.  Any application
   configuring the 17th peer will receive an error.  While an error may
   suffice to let the application know it cannot add another peer, it
   would be far better if the application had prior knowledge of this
   limitation and could prevent the same module should have user from starting down the same name.  Developers
   of enterprise modules are encouraged to choose names for their
   modules path
   that will have a low probability of colliding with standard
   or other enterprise modules, e.g., by could not succeed.

   Device deviations are declared using the enterprise or
   organization name "deviation" statement, which
   takes as its argument a prefix.

5.1.1.  Module Hierarchies

   YANG allows modeling string which identifies a node in the schema
   tree.  The contents of data the statement details the manner in multiple hierarchies, where data may
   have more than one root node.  Models that have multiple roots nodes
   are sometimes convenient, and are which the
   device implementation deviates from the contract as defined in the
   module.

5.9.4.  Announcing Conformance Information in the <hello> Message

   Devices indicate the names of supported by YANG.

5.2.  File Layout

   YANG modules features and submodules device
   deviations via the <hello> message.  In hello messages, the features
   are typically stored encoded in files, one module
   or submodule per file, with the name "features" parameter within the URI.  The value of
   this parameter is a comma-separated list of feature names which the file given by
   device supports for the
   concatenation of specific module.

     <hello>
       <capability>
         http://example.com/mod/mcp?features=feat1&module=mcp
       </capability>
       <capability>
         http://example.com/mod/some?module=some&features=one,two,three
       </capability>
     </hello>

   Device deviations are announced via the module or submodule name and "deviations" parameter.  The
   value of the file suffix
   ".yang".  YANG compilers can find imported deviations parameter is a comma-separated list of
   modules and included
   submodules via this convention.  While containing deviations from the capability's module.

     <hello>
       <capability>
         http://example.com/abc?deviations=my-devs
       </capability>
     </hello>

6.  YANG language defines
   modules, tools may compile submodules independently for performance syntax

   The YANG syntax is similar to that of SMIng [RFC3780] and manageability reasons.  Many errors programming
   languages like C and C++.  This C-like syntax was chosen specifically
   for its readability, since YANG values the time and warnings that cannot be
   detected during submodule compilation may be delayed until effort of the
   submodules are linked into a cohesive module.

5.3.  Object Based View
   readers of models above those of modules writers and YANG

   While tool-chain
   developers.  This section introduces the YANG models syntax.

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

6.1.  Lexicographical Tokenization

   YANG modules are parsed as a data tree, it can be used in series of tokens.  This section details
   the rules for recognizing tokens from an object-based manner as well. input stream.  YANG
   tokenization rules are both simple and powerful.  The configuration simplicity is
   driven by a need to keep the parsers easy to implement, while the
   power is driven by the fact that modelers need to express their
   models in readable formats.

6.1.1.  Comments

   Comments are C++ style.  A single line comment starts with "//" and state data
   ends at the end of the device line.  A block comment is modeled as enclosed within "/*"
   and "*/".

6.1.2.  Tokens

   A token in YANG is either a tree keyword, a string, ";", "{", or "}".  A
   string can be quoted or unquoted.  A keyword is either one of object instances (objects for short).  Each object in the tree has
   core YANG keywords defined in this document, or a type name (or managed object class name), prefix identifier,
   followed by ":", followed by a namespace, language extension keyword.  Keywords
   are case sensitive.  See Section 6.2 for a (possibly
   empty) set formal definition of attributes and
   identifiers.

6.1.3.  Quoting

   If a (possibly empty) set of child objects.

   A managed object class could be defined as string contains any whitespace characters, a grouping, containing
   just one list.  Attributes should be defined as leafs inside the
   list.  Child objects should semicolon (";"),
   curly braces ("{" or "}"), or comment sequences ("//", "/*", or
   "*/"), then it MUST be defined with enclosed within double or single quotes.

   If the corresponding uses
   statements.

   A defined grouping unambiguously defines its properties, it has its
   own unique name, so when it double quoted string contains a line break followed by
   whitespace which is referred used to indent the text according to the layout
   in the "uses" statement it YANG file, this leading whitespace is always stripped from the
   string, up to at most the same well defined set of properties that we are using.

   The data tree can be defined as one or more top level containers
   containing managed object classes defined as groupings.  All further
   levels column of the data tree are defined by managed object classes
   containing further managed objects.

5.4.  XML Namespaces

   All YANG definitions are specified double quote character.

   If the double quoted string contains whitespace before a line break,
   this trailing whitespace is stripped from the string.

   A single quoted string (enclosed within ' ') preserves each character
   within the quotes.  A single quote character can not occur in a particular XML Namespace.
   Each module defines an XML namespace as
   single quoted string, even when preceded by a globally unique URI
   [RFC3986].  A NETCONF client or server uses backslash.

   If a quoted string is followed by a plus character ("+"), followed by
   another quoted string, the namespace during XML
   encoding two strings are concatenated into one
   quoted string, allowing multiple concatenations to build one quoted
   string.  Whitespace trimming of data.

   The namespace URI double quoted strings is advertised as done before
   concatenation.

   Within a capability in the NETCONF
   <hello> message to indicate support for the YANG module by double quoted string (enclosed within " "), a NETCONF
   server.  The capability URI advertised SHOULD be backslash
   character introduces a special character, which depends on the form:

     namespace-uri "?" revision

   Where "revision" is the revision of the module (see Section 7.1.9)
   character that immediately follows the server implements.

   Namespaces for standard module names will be assigned backslash:

    \n      new line
    \t      a tab character
    \"      a double quote
    \\      a single backslash

6.1.3.1.  Quoting Examples

   The following strings are equivalent:

     hello
     "hello"
     'hello'
     "hel" + "lo"
     'hel' + "lo"

   The following examples show some special strings:

     "\""  - string containing a double quote
     '"'   - string containing a double quote
     "\n"  - string containing a newline character
     '\n'  - string containing a backslash followed
             by IANA.  They
   MUST be unique (but different revisions of the same module should
   have the same namespace).

   Namespaces for private module names will character n

   The following examples show some illegal strings:

     ''''  - a single-quoted string cannot contain single quotes
     """   - a double quote must be assigned by the
   organization owning the module without escaped in a central registry.  It is
   recommended double quoted string

   The following strings are equivalent:

         "first line
            second line"

     "first line\n" + "  second line"

6.2.  Identifiers

   Identifiers are used to choose namespaces that will have a low probability identify different kinds of
   colliding YANG items by
   name.  Each identifier starts with standard an upper-case or other enterprise modules, e.g. lower-case ASCII
   letter or an underscore character, followed by using
   the enterprise zero or organization name more ASCII
   letters, digits, underscore characters, hyphens, and dots.
   Implementations MUST support identifiers up to 63 characters in the namespace.
   length.  Identifiers are case sensitive.  The "namespace" statement identifier syntax is covered
   formally defined by the rule "identifier" in Section 7.1.3.

5.4.1.  YANG Namespace

   YANG defines its own namespace for NETCONF <edit-config> operations.
   This namespace 12.  Identifiers
   can be specified as quoted or unquoted strings.

6.2.1.  Identifiers and their namespaces

   Each identifier is "urn:ietf:params:xml:ns:yang:1" [XXX IANA].

5.5.  Ordering

   YANG supports two styles for ordering the entries within valid in a list.  In
   many lists, the order of list entries does not impact namespace which depends on the
   implementation type of
   the list's configuration, and the device is free to
   sort the list entries in any reasonable order.  The "description"
   string for the list may suggest an order. YANG calls this style of
   list "system ordered" item being defined:

   o  All module and they are indicated with submodule names share the statement
   "ordered-by system".

   For example, same global module
      identifier namespace.

   o  All extension names defined in a list of valid users would typically be sorted
   alphabetically, since module and its submodules share
      the order same extension identifier namespace.

   o  All feature names defined in which a module and its submodules share the users appeared
      same feature identifier namespace.

   o  All identity names defined in a module and its submodules share
      the
   configuration would not impact the creation of those users' accounts.

   In same identity identifier namespace.

   o  All derived type names defined within a parent node or at the other style top-
      level of lists, the order of list entries matters for module or its submodules share the implementation same type
      identifier namespace.  This namespace is scoped to the parent node
      or module.

   o  All groupings defined within a parent node or at the top-level of
      the list's configuration and module or its submodules share the user same grouping identifier
      namespace.  This namespace is
   responsible for ordering scoped to the entries, while parent node or module.

   o  All leafs, leaf-lists, lists, containers, choices, rpcs, and
      notifications defined within a parent node or at the device maintains that
   order.  YANG calls this style top-level of list "user ordered" and they are
   indicated with
      the statement "ordered-by user".

   For example, module or its submodules share the order in which firewall filters entries are applied
   to incoming traffic may affect how that traffic same identifier namespace.
      This namespace is filtered.  The
   user would need scoped to decide if the filter entry that discards all TCP
   traffic should be applied before parent node or after module, unless the filter entry that
   allows all traffic from trusted interfaces.  The choice of order
   would be crucial.

   YANG provides
      parent node is a rich set case node.  In that case, the namespace is scoped
      to the parent node of facilities the case node's parent choice node.

   o  All cases within NETCONF's <edit-config>
   operation which allow a choice share the order of list entries in user-ordered lists same case identifier
      namespace.  This namespace is scoped to be controlled.  List entries may be inserted or rearranged,
   positioned as the first or last entry parent choice node.

   All identifiers defined in the list, a namespace MUST be unique.

6.3.  Statements

   A YANG module contains a sequence of statements.  Each statement
   starts with a keyword, followed by zero or positioned
   before one argument, followed
   either by a semicolon (";") or after another specific entry.

   The "ordered-by" a block of substatements enclosed
   within curly braces ("{ }"):

     statement = keyword [argument] (";" / "{" *statement "}")

   The argument is covered a string, as defined in Section 7.7.4.

5.6.  Containers with Presence 6.1.2.

6.3.1.  Language Extensions

   A module can introduce YANG supports two styles of containers, those which exist only for
   organizing extensions by using the hierarchy of data nodes, and those whose presence in "extension"
   keyword (see Section 7.17).  The extensions can be imported by other
   modules with the configuration has "import" statement (see Section 7.1.5).  When an explicit meaning.

   In
   imported extension is used, the first style, extension's keyword must be qualified
   using the container has no meaning of its own, existing
   only to contain child nodes.  The container data node is implicitly
   created when prefix with which the first child data node is created.  The data node extension's module was imported.  If
   an extension is
   implicitly deleted when used in the last non-key child module where it is deleted, since an
   empty container has no meaning.

   For example, defined, the set of scrambling options for SONET interfaces may
   extension's keyword must be placed inside a "scrambling" container to enhance the organization
   of the configuration hierarchy, and to keep these nodes together.
   The "scrambling" node itself has no meaning, so removing qualified with the node
   when it becomes empty relieves module's prefix.

   Since submodules cannot include the user from parent module, any extensions in
   the task of performing module which need to be exposed to submodules must be defined in
   a submodule.  Submodules can then include this task.

   In the second style, submodule to find the presence
   definition of the container itself is
   configuration data, representing a single bit of configuration data.
   The container acts extension.

6.4.  XPath Evaluations

   YANG relies on XPath 1.0 [XPATH] as both a configuration knob and a means of
   organizing related configuration.  These containers are explicitly
   created notation for specifying many
   inter-node references and deleted.

   YANG calls this style a "presence container" dependencies.  NETCONF clients and they servers
   are indicated
   using not required to implement an XPath interpreter, but MUST ensure
   that the "presence" statement, which takes as its argument a text
   string indicating what requirements encoded in the presence data model are enforced.  The
   manner of the node means.

   For example, enforcement is an "ssh" container implementation decision.  The XPath
   expressions MUST be valid, but any implementation may turn on the ability choose to log into
   the device
   implement them by hand, rather than using ssh, but can also contain any ssh-related
   configuration knobs, such as connection rates or retry limits.

   The "presence" statement is covered in Section 7.5.4.

5.7.  Scoping

   YANG uses static scoping.  Grouping definitions the XPath expression
   directly.

   XPath expressions are resolved evaluated in the context in which they are defined, rather than of the context in which
   they are used.  Users current node,
   with the namespace of groupings are not required the current module defined as the null
   namespace.  References to import identifiers in external modules
   or include submodules to satisfy all references made by the grouping.

   For example, if a MUST be
   qualified with appropriate prefixes, and references to the current
   module defines a grouping in which and its submodules MAY use a type is
   referenced, when prefix.

7.  YANG Statements

   The following sections describe all of the grouping is used in YANG core statements.

   Note that even a second module, the type is
   resolved statement which does not have any substatements
   defined in core YANG can have vendor-specific extensions as
   substatements.  For example, the original module, "description" statement does not
   have any substatements defined in core YANG, but the second module.  There following is no
   worry over conflicts if both modules define
   legal:

     description "some text" {
         acme:documentation-flag 5;
     }

7.1.  The module Statement

   The "module" statement defines the type, since there is
   no ambiguity.

5.8.  Nested Typedefs and Groupings

   Typedefs module's name, and groupings may appear nested under many YANG statements,
   allowing these to be lexically scoped by the hierarchy under groups all
   statements which
   they appear.  This allows types and groupings belong to be defined near
   where they are used, rather than placing them at the top level module together.  The "module"
   statement's argument is the name of the
   hierarchy. module, followed by a block
   of substatements that hold detailed module information.  The close proximity increases readability.

   Scoping also allows types to be defined without concern module
   name follows the rules for naming
   conflicts between types identifiers in different submodules.  Type Section 6.2.

   Standard module names can will be
   specified without adding leading strings designed to prevent name
   collisions within large modules.

   Finally, scoping allows the module author to keep types and groupings
   private to their module or submodule, preventing their reuse.  Since
   only top-level types and groupings can assigned by IANA.  The names of all
   standard modules MUST be used outside unique (but different revisions of the same
   module or
   submodule, should have the developer has more control over what pieces of their same name).

   Private module are presented to names will be assigned by the outside world, supporting organization owning the need to
   hide internal information and maintaining
   module without a boundary between what central registry.  It is
   shared recommended to choose names
   for their modules that will have a low probability of colliding with
   standard or other enterprise modules, e.g. by using the outside world and what is kept private.

   Scoped definitions MUST NOT shadow definitions at a higher scope.  A
   type enterprise or group cannot be defined if
   organization name as a higher level in prefix.

   A module SHOULD have the schema
   hierarchy has a definition with a matching identifier.

   When a YANG implementation resolves a following layout:

     module <module-name> {

         // header information
         <yang-version statement>
         <namespace statement>
         <prefix statement>

         // linkage statements
         <import statements>
         <include statements>

         // meta information
         <organization statement>
         <contact statement>
         <description statement>
         <reference statement>

         // revision history
         <revision statements>

         // module definitions
         <extension statements>
         <feature statements>
         <typedef statements>
         <grouping statements>
         <container statements>
         <leaf statements>
         <leaf-list statements>
         <list statements>
         <choice statements>
         <uses statements>
         <rpc statements>
         <notification statements>
         <augment statements>
         <deviation statements>
     }

7.1.1.  The module's Substatements
                 +--------------+---------+-------------+
                 | substatement | section | cardinality |
                 +--------------+---------+-------------+
                 | anyxml       | 7.10    | 0..n        |
                 | augment      | 7.15    | 0..n        |
                 | choice       | 7.9     | 0..n        |
                 | contact      | 7.1.8   | 0..1        |
                 | container    | 7.5     | 0..n        |
                 | description  | 7.19.3  | 0..1        |
                 | deviation    | 7.18.3  | 0..n        |
                 | extension    | 7.17    | 0..n        |
                 | feature      | 7.18.1  | 0..n        |
                 | grouping     | 7.11    | 0..n        |
                 | import       | 7.1.5   | 0..n        |
                 | include      | 7.1.6   | 0..n        |
                 | leaf         | 7.6     | 0..n        |
                 | leaf-list    | 7.7     | 0..n        |
                 | list         | 7.8     | 0..n        |
                 | namespace    | 7.1.3   | 1           |
                 | notification | 7.14    | 0..n        |
                 | organization | 7.1.7   | 0..1        |
                 | prefix       | 7.1.4   | 1           |
                 | reference to an unprefixed type
   or grouping, or one which    | 7.19.4  | 0..1        |
                 | revision     | 7.1.9   | 0..n        |
                 | rpc          | 7.13    | 0..n        |
                 | typedef      | 7.3     | 0..n        |
                 | uses the prefix of the local module, it
   searches up the levels of hierarchy in the schema tree, starting at
   the current level, for the definition of the type or grouping.

6.  YANG syntax

   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, since YANG values the time and effort of the
   readers of models above those of modules writers and YANG tool-chain
   developers.  This section introduces the YANG syntax.

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

6.1.  Lexicographical Tokenization

   YANG modules are parsed as a series of tokens.  This section details
   the rules for recognizing tokens from an input stream.  YANG
   tokenization rules are both simple and powerful.         | 7.12    | 0..n        |
                 | yang-version | 7.1.2   | 0..1        |
                 +--------------+---------+-------------+

7.1.2.  The simplicity is
   driven by a need to keep the parsers easy to implement, while the
   power is driven by the fact that modelers need to express their
   models in readable formats.

6.1.1.  Comments

   Comments are C++ style.  A single line comment starts with "//" and
   ends at the end of the line.  A block comment is enclosed within "/*"
   and "*/".

6.1.2.  Tokens

   A token in YANG is either a keyword, a string, ";", "{", or "}".  A
   string can be quoted or unquoted.  A keyword is either one yang-version Statement

   The "yang-version" statement specifies which version of the
   core YANG keywords defined in this document, or a prefix identifier,
   followed by ":", followed by a
   language extension keyword.  Keywords
   are case sensitive.  See Section 6.2 for a formal definition of
   identifiers.

6.1.3.  Quoting

   If a string contains any whitespace characters, a semicolon (";"),
   curly braces ("{" or "}"), or comment sequences ("//", "/*", or
   "*/"), then it MUST be enclosed within double or single quotes.

   If was used in developing the double quoted string module.  The statement's argument
   contains a line break followed by
   whitespace value "1", which is used to indent the text according to the layout
   in current yang version and the YANG file, this leading whitespace default
   value.

   This statement is stripped from the
   string, up to at most intended for future-proofing the same column syntax of YANG
   against possible changes in later versions of YANG.  Since the double quote character.

   If the double quoted string contains whitespace before a line break,
   this trailing whitespace
   current version is stripped from the string.

   A single quoted string (enclosed within ' ') preserves each character
   within default value, the quotes.  A single quote character can statement need not occur appear
   in YANG modules until a
   single quoted string, even when preceded by a backslash.

   If a quoted string future version is followed by defined.  When a plus character ("+"), followed by
   another quoted string, the two strings are concatenated into one
   quoted string, allowing multiple concatenations to build one quoted
   string.  Whitespace trimming of double quoted strings new
   version is done before
   concatenation.

   Within a double quoted string (enclosed defined, YANG modules can either use version 2 statements
   and add the "yang-version 2" statement, or remain within " "), a backslash
   character introduces a special character, which depends on the
   character that immediately follows version
   1 feature set and continue to use the backslash:

    \n      new line
    \t      a tab character
    \"      a double quote
    \\      a single backslash

6.1.3.1.  Quoting Examples default setting of "yang-
   version 1".

7.1.3.  The following strings are equivalent:

     hello
     "hello"
     'hello'
     "hel" + "lo"
     'hel' + "lo" namespace Statement

   The following examples show some special strings:

     "\""  - string containing a double quote
     '"'   - string containing a double quote
     "\n"  - string containing a newline character
     '\n'  - string containing a backslash followed "namespace" statement defines the XML namespace for all XML
   elements defined by the character n module.  Its argument is the URI of the
   namespace.

   See also Section 5.4.

7.1.4.  The following examples show some illegal strings:

     ''''  - prefix Statement

   The "prefix" statement is used to define the prefix associated with
   the namespace of a single-quoted module.  The "prefix" statement's argument is the
   prefix string cannot contain single quotes
     """   - which is used as a double quote must be escaped in prefix to access a double quoted string module.  The following strings are equivalent:

         "first line
            second line"

     "first line\n" + "  second line"

6.2.  Identifiers

   Identifiers are
   prefix string may be used to identify different kinds of YANG items by
   name.  Each identifier starts with an upper-case or lower-case ASCII
   letter or an underscore character, followed by zero or more ASCII
   letters, digits, underscore characters, hyphens, and dots.
   Implementations MUST support identifiers up refer to 63 characters definitions contained in
   length.  Identifiers are case sensitive.  The the
   module, e.g. "if:ifName".  A prefix follows the same rules as an
   identifier syntax (see Section 6.2).

   When used inside the "module" statement, the "prefix" statement
   defines the prefix to be used when this module is
   formally imported.  To
   improve readability of the NETCONF XML, a NETCONF client or server
   which generates XML or XPath that use prefixes, the prefix defined by
   a module SHOULD be used, unless there is a conflict.

   When used inside the rule "identifier" in Section 11.  Identifiers
   can "import" statement, the "prefix" statement
   defines the prefix to be specified as quoted or unquoted strings.

6.2.1.  Identifiers and their namespaces

   Each used when accessing definitions inside the
   imported module.  When a reference to an identifier from the imported
   module is valid used, the prefix string for the module from which objects
   are being imported is used in combination with a namespace which depends on colon (":") and the type
   identifier, e.g. "if:ifIndex".  To improve readability of
   the YANG item being defined:

   o  All module and submodule names share
   modules, the same global module
      identifier namespace.

   o  All extension names prefix defined in by a module and its submodules share SHOULD be used when the same extension identifier namespace.

   o
   module is imported, unless there is a conflict.

   All derived type names defined prefixes, including the prefix for the module itself MUST be
   unique within a parent node the module or at submodule.

7.1.5.  The import Statement

   The "import" statement makes definitions from one module available
   inside another module or submodule.  The argument is the top-
      level name of the
   module or its submodules share the same type
      identifier namespace.  This namespace is scoped to import, and the parent node
      or module.

   o  All groupings defined within statement is followed by a parent node or at the top-level block of
   substatements that holds detailed import information.

   All identifiers contained in an imported module are imported into the
   current module or its submodules share submodule, so that they can be referenced by
   definitions in the same grouping identifier
      namespace.  This namespace current module or submodule.  The mandatory
   "prefix" substatement assigns a prefix for the imported module which
   is scoped to the parent node importing module or module.

   o  All leafs, leaf-lists, lists, containers, choices, rpcs, and
      notifications defined within submodule.  Multiple "import"
   statements may be specified to import from different modules.

                        The import's Substatements

                 +--------------+---------+-------------+
                 | substatement | section | cardinality |
                 +--------------+---------+-------------+
                 | prefix       | 7.1.4   | 1           |
                 +--------------+---------+-------------+

7.1.6.  The include Statement

   The "include" statement is used to make content from a parent node or at submodule
   available to the top-level module.  The argument is an identifier which is the
   name of the module or its submodule to include.  Modules are only allowed to
   include submodules share the same identifier namespace.
      This namespace is scoped that belong to the parent node or that module, unless as defined by the
      parent node is
   "belongs-to" statement (see Section 7.2.2).

   When a case node.  In that case, module includes a submodule, it incorporates the namespace is scoped
      to contents of
   the submodule into the parent node hierarchy of the case node's parent choice node.

   o  All cases within module.  When a choice share
   submodule includes another submodule, the same case identifier
      namespace.  This namespace is scoped target submodule's
   definitions are made available to the parent choice node.

   All identifiers defined in a namespace MUST be unique.

6.3.  Statements

   A YANG module contains a sequence of statements.  Each current submodule.

7.1.7.  The organization Statement

   The "organization" statement
   starts with a keyword, followed by zero or one argument, followed
   either by defines the party responsible for this
   module.  The argument is a semicolon (";") or string which is used to specify a block textual
   description of substatements enclosed
   within curly braces ("{ }"): the organization(s) under whose auspices this module
   was developed.

7.1.8.  The contact Statement

   The "contact" statement = keyword [argument] (";" / "{" *statement "}") provides contact information for the module.
   The argument is a string, as defined in Section 6.1.2.

6.3.1.  Language Extensions

   A module can introduce YANG extensions by using the "extension"
   keyword (see Section 7.16).  The extensions can be imported by other
   modules with the "import" statement (see Section 7.1.5).  When an
   imported extension string which is used, used to specify the name, postal
   address, telephone number, and electronic mail address of the extension's keyword must person
   to whom technical queries concerning this module should be qualified
   using sent.

7.1.9.  The revision Statement

   The "revision" statement specifies the prefix with which editorial revision history of
   the extension's module was imported.  If
   an extension is used in module, including the module where it is defined, initial revision.  A series of revisions
   statements detail the
   extension's keyword must be qualified with changes in the module's prefix.

6.4.  XPath Evaluations

   YANG relies on XPath 1.0 [XPATH] as definition.  The
   argument is a notation for specifying many
   inter-node references and dependencies.  NETCONF clients and servers
   are not required to implement an XPath interpreter, but MUST ensure
   that the requirements encoded date string in the data model are enforced.  The
   manner format "YYYY-MM-DD", followed by a
   block of enforcement is an implementation decision.  The XPath
   expressions MUST substatements that holds detailed revision information.  A
   module SHOULD have at least one initial "revision" statement.  For
   every editorial change, a new one SHOULD be valid, but any implementation may choose to
   implement them by hand, rather than using the XPath expression
   directly.

   XPath expressions are evaluated added in the context front of the current node,
   with the
   revisions sequence, so that all revisions are in reverse
   chronological order.

7.1.9.1.  The revision's Substatement

                 +--------------+---------+-------------+
                 | substatement | section | cardinality |
                 +--------------+---------+-------------+
                 | description  | 7.19.3  | 0..1        |
                 +--------------+---------+-------------+

7.1.10.  Usage Example

     module acme-system {
         namespace of the current "http://acme.example.com/system";
         prefix "acme";

         import yang-types {
             prefix "yang";
         }

         include acme-types;

         organization "ACME Inc.";
         contact
             "Joe L. User

              ACME, Inc.
              42 Anywhere Drive
              Nowhere, CA 95134
              USA

              Phone: +1 800 555 0815
              EMail: joe@acme.example.com";

         description
             "The module defined as for entities implementing the null
   namespace.  References to identifiers ACME protocol.";

         revision "2007-06-09" {
             description "Initial revision.";
         }

         // definitions follows...
     }

7.2.  The submodule Statement

   While the primary unit in external modules MUST YANG is a module, a YANG module can itself
   be
   qualified with appropriate prefixes, and references constructed out of several submodules.  Submodules allow to the current
   module and its submodules MAY use split
   a prefix.

7.  YANG Statements

   The following sections describe complex module in several pieces where all of the YANG core statements.

   Note that even submodules
   contribute to a statement single namespace, which does not have any substatements
   defined in core YANG can have vendor-specific extensions as
   substatements.  For example, the "description" statement does not
   have any substatements is defined in core YANG, but by the following is
   legal:

     description "some text" {
         acme:documentation-flag 5;
     }

7.1.  The module Statement
   including the submodules.

   The "module" "submodule" statement defines is used to give the module's submodule a name, and groups
   to group all statements which belong to the module submodule together.

   The "module"
   statement's "submodule" statement, which must be present at most once, takes
   as an argument an identifier which is the name of the module, submodule,
   followed by a block of substatements that hold detailed module submodule
   information.  The module
   name follows the rules for identifiers in Section 6.2.

   Standard module submodule names will be assigned by IANA.  The names  Name of all
   standard modules MUST submodules must be unique and in addition not conflict with
   module names (but different revisions of the same
   module submodule should
   have the same name).

   Private module submodule names will be assigned by the organization owning
   the
   module submodule without a central registry.  It is recommended to
   choose names for their modules submodules that will have a low probability of
   colliding with standard or other enterprise modules, modules and submodules,
   e.g. by using the enterprise or organization name as a prefix.

   A module submodule SHOULD have the following layout:

     module

     submodule <module-name> {

         // header information

         <yang-version statement>
         <namespace statement>
         <prefix
         // module identification
         <belongs-to statement>

         // linkage statements
         <import statements>
         <include statements>

         // meta information
         <organization statement>
         <contact statement>
         <description statement>
         <reference statement>

         // revision history
         <revision statements>

         // module definitions
         <extension statements>
         <feature statements>
         <typedef statements>
         <grouping statements>
         <container statements>
         <leaf statements>
         <leaf-list statements>
         <list statements>
         <choice statements>
         <uses statements>
         <rpc statements>
         <notification statements>
         <augment statements>
         <deviation statements>
     }

7.1.1.

7.2.1.  The module's submodule's Substatements
                 +--------------+---------+-------------+
                 | substatement | section | cardinality |
                 +--------------+---------+-------------+
                 | anyxml       | 7.10    | 0..n        |
                 | augment      | 7.15    | 0..n        |
                 | belongs-to   | 7.2.2   | 1           |
                 | choice       | 7.9     | 0..n        |
                 | contact      | 7.1.8   | 0..1        |
                 | container    | 7.5 7.5     | 0..n        |
                 | description  | 7.19.3  | 0..1        |
                 | deviation    | 7.18.3  | 0..n        |
                 | description extension    | 7.17.3 7.17    | 0..1 0..n        |
                 | extension feature      | 7.16 7.18.1  | 0..n        |
                 | grouping     | 7.11    | 0..n        |
                 | import       | 7.1.5   | 0..n        |
                 | include      | 7.1.6   | 0..n        |
                 | leaf         | 7.6     | 0..n        |
                 | leaf-list    | 7.7     | 0..n        |
                 | list         | 7.8     | 0..n        |
                 | namespace    | 7.1.3   | 1           |
                 | notification | 7.14    | 0..n        |
                 | organization | 7.1.7   | 0..1        |
                 | prefix       | 7.1.4   | 1           |
                 | reference    | 7.17.4 7.19.4  | 0..1        |
                 | revision     | 7.1.9   | 0..n        |
                 | rpc          | 7.13    | 0..n        |
                 | typedef      | 7.3     | 0..n        |
                 | uses         | 7.12    | 0..n        |
                 | yang-version | 7.1.2   | 0..1        |
                 +--------------+---------+-------------+

7.1.2.  The yang-version Statement

   The "yang-version" statement specifies which version of the YANG
   language was used in developing the module.  The statement's argument
   contains value "1", which is the current yang version and the default
   value.

   This statement is intended for future-proofing the syntax of YANG
   against possible changes in later versions of YANG.  Since the
   current version is the default value, the statement need not appear
   in YANG modules until a future version is defined.  When a new
   version is defined, YANG modules can either use version 2 features
   and add the "yang-version 2" statement, or remain within the version
   1 feature set and continue to use the default setting of "yang-
   version 1".

7.1.3.  The namespace Statement

   The "namespace" statement defines the XML namespace for all XML
   elements defined by the module.  Its argument is the URI of the
   namespace.

   See also Section 5.4.

7.1.4.  The prefix Statement

   The "prefix" statement is used to define the prefix associated with
   the namespace of a module.  The "prefix" statement's argument is the
   prefix string which is used as a prefix to access a module.  The
   prefix string may be used to refer to definitions contained in the
   module, e.g. "if:ifName".  A prefix follows the same rules as an
   identifier (see Section 6.2).

   When used inside the "module" statement, the "prefix"
                 | uses         | 7.12    | 0..n        |
                 | yang-version | 7.1.2   | 0..1        |
                 +--------------+---------+-------------+

7.2.2.  The belongs-to Statement

   The "belongs-to" statement
   defines specifies the prefix to be used when this module is imported.  To
   improve readability of the NETCONF XML, a NETCONF client or server to which generates XML or XPath that use prefixes, the prefix defined by
   a module SHOULD be used, unless there
   submodule belongs.  The argument is a conflict.

   When used inside the "import" statement, the "prefix" statement
   defines the prefix to be used when accessing data inside the imported
   module.  When a reference to an identifier from the imported module
   is used, the prefix string for the module from which objects are
   being imported is used in combination with a colon (":") and the
   identifier, e.g. "if:ifIndex".  To improve readability name
   of YANG
   modules, the prefix defined by a module SHOULD be used when module.  Only the module is imported, unless there is to which a conflict.

   All prefixes, including the prefix for the module itself MUST be
   unique within the module submodule belongs, or submodule.

7.1.5.  The import Statement

   The "import" statement makes definitions from one module available
   inside
   another module or submodule.  The argument is the name of the
   module submodule that belongs to import, and the statement is followed by a block of
   substatements that holds detailed import information.

   All identifiers contained in an imported module same module, are imported into the
   current module or submodule, so allowed to
   include that they can be referenced by
   definitions in the current module or submodule.

   The mandatory "prefix" substatement assigns a prefix for the imported module which
   is scoped
   to which the importing module or submodule.  Multiple "import"
   statements may submodule belongs.  All definitions in the local
   submodule and any included submodules can be specified to import from different modules. accessed by using the
   prefix.

                      The belongs-to's Substatements

                 +--------------+---------+-------------+
                 | substatement | section | cardinality |
                 +--------------+---------+-------------+
                 | prefix       | 7.1.4   | 1           |
                 +--------------+---------+-------------+

7.1.6.

7.2.3.  Usage Example

     submodule acme-types {

         belongs-to "acme-system" {
             prefix "acme";
         }

         import yang-types {
             prefix "yang";
         }

         organization "ACME Inc.";
         contact
             "Joe L. User

              ACME, Inc.
              42 Anywhere Drive
              Nowhere, CA 95134
              USA

              Phone: +1 800 555 0815
              EMail: joe@acme.example.com";

         description
             "This submodule defines common ACME types.";

         revision "2007-06-09" {
             description "Initial revision.";
         }

         // definitions follows...
     }

7.3.  The include typedef Statement

   The "include" "typedef" statement is defines a new type which may be used to make content locally
   in the module, in modules or submodules which include it, and by
   other modules which import from a submodule
   available to it.  The new type is called the module.
   "derived type", and the type from which it was derived is called the
   "base type".  All derived types can be traced back to a YANG built-in
   type.

   The "typedef" statement's argument is an identifier which is the name
   of the submodule to include.  Modules are only allowed to
   include submodules that belong type to that module, as defined be defined, and MUST be followed by the
   "belongs-to" statement (see Section 7.2.2).

   When a module includes a submodule, it incorporates block of
   substatements that holds detailed typedef information.

   The name of the contents type MUST NOT be one of the submodule into YANG built-in types.  If
   the node hierarchy of typedef is defined at the module.  When top level of a
   submodule includes another YANG module or
   submodule, the target submodule's
   definitions are made available name of the type to be defined MUST be unique within
   the current submodule.

7.1.7. module.  For details about scoping for nested typedef, see
   Section 5.8.

7.3.1.  The organization typedef's Substatements

                 +--------------+---------+-------------+
                 | substatement | section | cardinality |
                 +--------------+---------+-------------+
                 | default      | 7.3.4   | 0..1        |
                 | description  | 7.19.3  | 0..1        |
                 | reference    | 7.19.4  | 0..1        |
                 | status       | 7.19.2  | 0..1        |
                 | type         | 7.3.2   | 1           |
                 | units        | 7.3.3   | 0..1        |
                 +--------------+---------+-------------+

7.3.2.  The typedef's type Statement

   The "organization" statement "type" statement, which must be present, defines the party responsible for base type
   from which this
   module. type is derived.  See Section 7.4 for details.

7.3.3.  The argument units Statement

   The "units" statement, which is optional, takes as an argument a
   string which is used to specify contains a textual
   description definition of the organization(s) under whose auspices this module
   was developed.

7.1.8. units associated
   with the type.

7.3.4.  The contact typedef's default Statement

   The "contact" "default" statement provides contact information for the module.
   The takes as an argument is a string which is used to specify contains
   a default value for the name, postal
   address, telephone number, and electronic mail address new type.

   The value of the person
   to whom technical queries concerning this module should be sent.

7.1.9.  The revision Statement

   The "revision" "default" statement specifies MUST correspond to the editorial revision history of type
   specified in the module, including "type" statement.

   If the initial revision.  A series base type has a default value, and the new derived type does
   not specify a new default value, the base type's default value is
   also the default value of revisions
   statements detail the changes new derived type.  The default value
   MUST correspond to any restrictions in the module's definition. derived type.

   If the base type's default value does not correspond to the new
   restrictions, the derived type MUST define a new default value.

7.3.5.  Usage Example

     typedef listen-ipv4-address {
         type inet:ipv4-address;
         default "0.0.0.0";
     }

7.4.  The type Statement

   The "type" statement takes as an argument is a date string in which is the format "YYYY-MM-DD", name
   of a YANG built-in type (see Section 9) or a derived type (see
   Section 7.3), followed by a an optional block of substatements that holds detailed revision information.  A
   module SHOULD have at least one initial "revision" statement.  For
   every editorial change, a new one SHOULD be added in front of are
   used to put further restrictions on the
   revisions sequence, so type.

   The restrictions that all revisions can be applied depends on the type being
   restricted.  All restriction statements are described in reverse
   chronological order.

7.1.9.1. conjunction
   with the built-in types in Section 9.

7.4.1.  The revision's Substatement type's Substatements

                 +--------------+---------+-------------+
                 | substatement | section | cardinality |
                 +--------------+---------+-------------+
                 | description bit          | 7.17.3 9.7.4   | 0..n        |
                 | enum         | 9.6.4   | 0..n        |
                 | length       | 9.4.4   | 0..1        |
                 +--------------+---------+-------------+

7.1.10.  Usage Example

     module acme-system {
         namespace "http://acme.example.com/system";
         prefix "acme";

         import yang-types {
             prefix "yang";
         }

         include acme-types;

         organization "ACME Inc.";
         contact
             "Joe L. User

              ACME, Inc.
              42 Anywhere Drive
              Nowhere, CA 95134
              USA

              Phone: +1 800 555 0815
              EMail: joe@acme.example.com";

         description
             "The module for entities implementing the ACME protocol.";

         revision "2007-06-09" {
             description "Initial revision.";
         }

         // definitions follows...
     }

7.2.  The submodule Statement

   While the primary unit in YANG is a module, a YANG module can itself
   be constructed out of several submodules.  Submodules allow to split
   a complex module in several pieces where all the submodules
   contribute to a single namespace, which is defined by the module
   including the submodules.
                 | path         | 9.9.2   | 0..1        |
                 | pattern      | 9.4.6   | 0..n        |
                 | range        | 9.2.4   | 0..1        |
                 | type         | 7.4     | 0..n        |
                 +--------------+---------+-------------+

7.5.  The "submodule" container Statement

   The "container" statement is used to give the submodule a name, and
   to group all statements which belong to define an interior node in the submodule together.

   The "submodule" statement, which must be present at most once,
   schema tree.  It takes
   as an argument an identifier one argument, which is the name of the submodule, an identifier, followed
   by a block of substatements that hold holds detailed submodule container
   information.

   Standard submodule names will be assigned by IANA.  Name of all
   standard submodules must be unique and in addition

   A container node does not conflict with
   module names (but different revisions of the same submodule should have the same name).

   Private submodule names will be assigned by the organization owning
   the submodule without a central registry.  It is recommended to
   choose names for their submodules that will have value, but it has a low probability list of
   colliding with standard or other enterprise modules and submodules,
   e.g. by using child
   nodes in the enterprise or organization name as a prefix.

   A submodule SHOULD have data tree.  The child nodes are defined in the following layout:

     submodule <module-name> {

         <yang-version statement>
         // module identification
         <belongs-to statement>

         // linkage statements
         <import statements>
         <include statements>

         // meta information
         <organization statement>
         <contact statement>
         <description statement>
         <reference statement>

         // revision history
         <revision statements>

         // module definitions
         <extension statements>
         <typedef statements>
         <grouping statements>
         <container statements>
         <leaf statements>
         <leaf-list statements>
         <list statements>
         <choice statements>
         <uses statements>
         <rpc statements>
         <notification statements>
         <augment statements>
     }

7.2.1.
   container's substatements.

   By default, a container does not carry any information, but is used
   to organize and give structure to the data being defined.  The submodule's
   "presence" statement (see Section 7.5.4) is used to give semantics to
   the existence of the container in the data tree.

7.5.1.  The container's Substatements

                 +--------------+---------+-------------+
                 | substatement | section | cardinality |
                 +--------------+---------+-------------+
                 | anyxml       | 7.10    | 0..n        |
                 | augment      | 7.15    | 0..n        |
                 | belongs-to   | 7.2.2   | 1           |
                 | choice       | 7.9     | 0..n        |
                 | contact config       | 7.1.8 7.19.1  | 0..1        |
                 | container    | 7.5     | 0..n        |
                 | description  | 7.17.3 7.19.3  | 0..1        |
                 | extension    | 7.16    | 0..n        |
                 | grouping     | 7.11    | 0..n        |
                 | import       | 7.1.5   | 0..n        |
                 | include if-feature   | 7.1.6 7.18.2  | 0..n        |
                 | leaf         | 7.6     | 0..n        |
                 | leaf-list    | 7.7     | 0..n        |
                 | list         | 7.8     | 0..n        |
                 | notification must         | 7.14 7.5.2   | 0..n        |
                 | organization presence     | 7.1.7 7.5.4   | 0..1        |
                 | reference    | 7.17.4 7.19.4  | 0..1        |
                 | revision     | 7.1.9   | 0..n        |
                 | rpc status       | 7.13 7.19.2  | 0..n 0..1        |
                 | typedef      | 7.3     | 0..n        |
                 | uses         | 7.12    | 0..n        |
                 | yang-version when         | 7.1.2 7.19.5  | 0..1        |
                 +--------------+---------+-------------+

7.2.2.

7.5.2.  The belongs-to must Statement

   The "belongs-to" statement specifies the module to "must" statement, which the
   submodule belongs.  The argument is optional, takes as an identifier argument a
   string which contains an XPath expression.  It is the name
   of the module.  Only the module used to which formally
   declare a submodule belongs, or
   another submodule that belongs constraint on valid data.  The constraint is enforced
   according to the same module, rules in Section 8.

   When a data is validated, all "must" constraints are allowed to
   include that submodule.

7.2.3.  Usage Example

     submodule acme-types {

         belongs-to "acme-system";

         import yang-types {
             prefix "yang";
         }

         organization "ACME Inc.";
         contact
             "Joe L. User

              ACME, Inc.
              42 Anywhere Drive
              Nowhere, CA 95134
              USA

              Phone: +1 800 555 0815
              EMail: joe@acme.example.com";

         description
             "This submodule defines common ACME types.";

         revision "2007-06-09" {
             description "Initial revision.";
         }

         // definitions follows...
     }

7.3.  The typedef Statement

   The "typedef" statement defines conceptually
   evaluated once for each corresponding instance in the data tree, and
   for all leafs with default values in effect.  If an instance does not
   exist in the data tree, and it does not have a new type which may default value, its
   "must" statements are not evaluated.

   All such constraints MUST evaluate to true for the data to be used locally
   in valid.

   The "must" statement is ignored if the module, data does not represent
   configuration.

   The XPath expression is conceptually evaluated in modules or submodules which include it, and by
   other modules which import from it. the following
   context:

   o  The new type context node is called the
   "derived type", and node in the type from data tree for which it was derived is called the
   "base type".  All derived types can be traced back to a YANG built-in
   type. "must"
      statement is defined.

   o  The "typedef" statement's argument accessible tree is an identifier which made up of all nodes in the data tree, and
      all leafs with default values.

   o  The set of namespace declarations is the name set of all "import"
      statements' prefix and namespace pairs, and the type "prefix"
      statement's prefix for the "namespace" statement's URI.

   o  Elements without a namespace refer to be defined, nodes in the current module.

   o  The function library is the core function library defined in
      [XPATH], and MUST be followed by a block of
   substatements that holds detailed typedef information. function "current()" which returns a node set with
      the initial context node.

   The name result of the type MUST NOT be one of XPath expression is converted to a boolean value
   using the YANG built-in types. standard XPath rules.

   If the typedef is defined at node with the must statement represents configuration data,
   any node referenced in the XPath expression MUST also represent
   configuration.

   Note that since all leaf values in the top level of a YANG module or
   submodule, data tree are conceptually
   stored in their canonical form (see Section 7.6 and Section 7.7), any
   XPath comparisons are done on the name of canonical value.

   Also note that the type XPath expression is conceptually evaluated.  This
   means that an implementation does not have to be defined MUST be unique within use an XPath evaluator
   on the module.  For details about scoping for nested typedef, see
   Section 5.8.

7.3.1. device.  How the evaluation is done in practice is an
   implementation decision.

7.5.3.  The typedef's must's Substatements

                 +--------------+---------+-------------+

                 +---------------+---------+-------------+
                 | substatement  | section | cardinality |
                 +--------------+---------+-------------+
                 | default      | 7.3.4   | 0..1        |
                 +---------------+---------+-------------+
                 | description   | 7.17.3 7.19.3  | 0..1        |
                 | reference error-app-tag | 7.17.4 7.5.3.2 | 0..1        |
                 | status error-message | 7.17.2 7.5.3.1 | 0..1        |
                 | type         | 7.3.2   | 1           |
                 | units reference     | 7.3.3 7.19.4  | 0..1        |
                 +--------------+---------+-------------+

7.3.2.
                 +---------------+---------+-------------+

7.5.3.1.  The typedef's type error-message Statement

   The "type" "error-message" statement, which must be present, defines is optional, takes a string as
   an argument.  If the base type
   from constraint evaluates to false, the string is
   passed as <error-message> in the <rpc-error>.

7.5.3.2.  The error-app-tag Statement

   The "error-app-tag" statement, which this type is derived.  See Section 7.4 for details.

7.3.3. optional, takes a string as
   an argument.  If the constraint evaluates to false, the string is
   passed as <error-app-tag> in the <rpc-error>.

7.5.3.3.  Usage Example of must and error-message

     container interface {
         leaf ifType {
             type enumeration {
                 enum ethernet;
                 enum atm;
             }
         }
         leaf ifMTU {
             type uint32;
         }
         must "ifType != 'ethernet' or " +
              "(ifType = 'ethernet' and ifMTU = 1500)" {
             error-message "An ethernet MTU must be 1500";
         }
         must "ifType != 'atm' or " +
              "(ifType = 'atm' and ifMTU <= 17966 and ifMTU >= 64)" {
             error-message "An atm MTU must be  64 .. 17966";
         }
     }

7.5.4.  The units presence Statement

   The "units" statement, which is optional, "presence" statement assigns a meaning to the presence of a
   container in the data tree.  It takes as an argument a string which
   contains a textual definition description of what the units associated
   with node's presence means.

   If a container has the type.

7.3.4.  The typedef's default Statement "presence" statement, the container's
   existence in the data tree carries some meaning.  Otherwise, the
   container is used to give some structure to the data, and it carries
   no meaning by itself.

   See Section 5.6 for additional information.

7.5.5.  The "default" statement takes container's Child Node Statements

   Within a container, the "container", "leaf", "list", "leaf-list",
   "uses", and "choice" statements can be used to define child nodes to
   the container.

7.5.6.  XML Encoding Rules

   A container node is encoded as an argument XML element.  The element's name is
   the container's identifier, and its XML namespace is the module's XML
   namespace.

   The container's child nodes are encoded as subelements to the
   container element, in the same order as they are defined within the
   container statement.

   A NETCONF server that replies to a string which contains <get> or <get-config> request MAY
   choose not to send a default value container element if the container node does not
   have the "presence" statement and no child nodes exist.  Thus, a
   client that receives an <rpc-reply> for a <get> or <get-config>
   request, must be prepared to handle the case that a container node
   without a presence statement is not present in the XML.

7.5.7.  NETCONF <edit-config> Operations

   When a NETCONF server processes an <edit-config> request, the new type.

   The value
   elements of procedure for the "default" statement MUST correspond to the type
   specified in the "type" statement. container node are:

      If the base type has a default value, and operation is "merge" the new derived type node is created if it does not specify a new default value,
      exist.

      If the base type's default value operation is
   also "replace" and the default value of node exists, all child nodes
      not present in the new derived type.  The default value
   MUST correspond to any restrictions XML are deleted, and child nodes present in the derived type.
      XML but not present in the datastore are created.

      If the base type's default value operation is "create" the node is created if it does not correspond to
      exist.

      If the new
   restrictions, operation is "delete" the derived type MUST define node is deleted if it exists.

      If the container has a new default value.

7.3.5. "presence" statement, it may be implicitly
      created if it does not exist, even if the operation is "none".

      If a container has a "presence" statement and the last child node
      is deleted, the NETCONF server MAY delete the container.

7.5.8.  Usage Example

     typedef listen-ipv4-address

   Given the following container definition:

     container system {
         type inet:ipv4-address;
         default "0.0.0.0";
         description "Contains various system parameters";
         container services {
             description "Configure externally available services";
             container "ssh" {
                 presence "Enables SSH";
                 description "SSH service specific configuration";
                 // more leafs, containers and stuff here...
             }

7.4.  The type Statement

   The "type" statement takes as an argument a string which is
         }
     }

   A corresponding XML encoding would look like this:

     <system>
       <services>
         <ssh/>
       </services>
     </system>

   Since the name
   of a YANG built-in type (see Section 8) or <ssh> element is present, ssh is enabled.

   To delete a derived type (see
   Section 7.3), followed by an optional block of substatements that are
   used to put further restrictions on the type.

   The restrictions that can be applied depends on the type being
   restricted.  All restriction statements are described in conjunction container with the built-in types in Section 8.

7.4.1.  The type's Substatements

                 +--------------+---------+-------------+
                 | substatement | section | cardinality |
                 +--------------+---------+-------------+
                 | bit          | 8.6.3   | 0..n        |
                 | enum         | 8.5.3   | 0..n        |
                 | length       | 8.3.3   | 0..1        |
                 | path         | 8.8.2   | 0..1        |
                 | pattern      | 8.3.5   | 0..n        |
                 | range        | 8.1.3   | 0..1        |
                 | type         | 7.4     | 0..n        |
                 +--------------+---------+-------------+

7.5. an <edit-config>:

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
          xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
       <edit-config>
         <target>
           <running/>
         </target>
         <config>
           <system xmlns="http://example.com/schema/config">
             <services>
               <ssh nc:operation="delete"/>
             </services>
           </system>
         </config>
       </edit-config>
     </rpc>

7.6.  The container leaf Statement

   The "container" "leaf" statement is used to define an interior a leaf node in the schema
   tree.  It takes one argument, which is an identifier, followed by a
   block of substatements that holds detailed container leaf information.

   A container leaf node has a value, but no child nodes in the data tree.
   Conceptually, the value in the data tree is always in the canonical
   form (see Section 9.1).

   A leaf node exists in zero or one instances in the data tree,
   depending on the value of the "mandatory" statement.

   The "leaf" statement is used to define a scalar variable of a
   particular built-in or derived type.

   If a leaf has a "default" statement, the leaf's default value is set
   to the value of the "default" statement.  Otherwise, if the leaf's
   type has a default value, and the leaf is not mandatory, then the
   leaf's default value is set to the type's default value.  In all
   other cases, the leaf does not have a value, but it default value.

   If the leaf has a list of child
   nodes in the data tree.  The child nodes are defined in default value, the
   container's substatements.

   By default, a container does not carry any information, but server MUST use this value
   internally if no value is used
   to organize and give structure to provided by the data being defined.  The
   "presence" statement (see Section 7.5.4) NETCONF client whenthe
   instance is used to give semantics to
   the existence of the container in the data tree.

7.5.1. created.

7.6.1.  The container's leaf's Substatements

                 +--------------+---------+-------------+
                 | substatement | section | cardinality |
                 +--------------+---------+-------------+
                 | anyxml       | 7.10    | 0..n        |
                 | augment      | 7.15    | 0..n        |
                 | choice       | 7.9     | 0..n        |
                 | config       | 7.17.1 7.19.1  | 0..1        |
                 | container default      | 7.5 7.6.3   | 0..n 0..1        |
                 | description  | 7.17.3 7.19.3  | 0..1        |
                 | grouping     | 7.11    | 0..n        |
                 | leaf         | 7.6     | 0..n        |
                 | leaf-list if-feature   | 7.7 7.18.2  | 0..n        |
                 | list mandatory    | 7.8 7.6.4   | 0..n 0..1        |
                 | must         | 7.5.2   | 0..n        |
                 | presence reference    | 7.5.4 7.19.4  | 0..1        |
                 | reference status       | 7.17.4 7.19.2  | 0..1        |
                 | status type         | 7.17.2 7.6.2   | 0..1 1           |
                 | typedef units        | 7.3 7.3.3   | 0..n 0..1        |
                 | uses when         | 7.12 7.19.5  | 0..n 0..1        |
                 +--------------+---------+-------------+

7.5.2.

7.6.2.  The leaf's type Statement

   The "type" statement, which must be present, takes as an argument the
   name of an existing built-in or derived type.  The optional
   substatements specify restrictions on this type.  See Section 7.4 for
   details.

7.6.3.  The leaf's default Statement

   The "default" statement, which is optional, takes as an argument a
   string which contains a default value for the leaf.

   The value of the "default" statement MUST correspond to the type
   specified in the leaf's "type" statement.

   The must "default" statement MUST NOT be present on nodes where
   "mandatory" is true.

7.6.4.  The leaf's mandatory Statement

   The "must" "mandatory" statement, which is optional, takes as an argument a
   the string which contains an XPath expression.  It "true" or "false".  If not specified, the default is used
   "false".

   If "mandatory" is "true", the node MUST exist if its parent node
   exists.  This constraint is enforced according to formally
   declare the rules in
   Section 8.

   Since containers without a constraint on "presence" statement are implicitly
   created and deleted when needed, they are ignored when performing
   mandatory tests for leafs.  A mandatory leaf within such a container
   is mandatory even if the configuration data.  When container's data node does not exist.

7.6.5.  XML Encoding Rules

   A leaf node is encoded as an XML element.  The element's name is the
   leaf's identifier, and its XML namespace is the module's XML
   namespace.

   The value of the leaf node is encoded to XML according to the type,
   and sent as character data in the element.

   A NETCONF server that replies to a configuration
   datastore <get> or <get-config> request MAY
   choose not to send the leaf element if its value is validated, all "must" constraints are conceptually
   evaluated once the default
   value.  Thus, a client that receives an <rpc-reply> for each corresponding instance a <get> or
   <get-config> request, must be prepared to handle the case that a leaf
   node with a default value is not present in the datastore's
   data tree, and XML.  In this case,
   the value used by the server is known to be the default value.

   See Section 7.6.7 for an example.

7.6.6.  NETCONF <edit-config> Operations

   When a NETCONF server processes an <edit-config> request, the
   elements of procedure for all leafs with default values in effect. the leaf node are:

      If an
   instance does not exist in the data tree, and operation is "merge", the node is created if it does not have a
   default value,
      exist, and its "must" statements are not evaluated.

   All such constraints MUST evaluate value is set to true for the configuration to
   be valid.

   The "must" statement is ignored if value found in the data does not represent
   configuration.

   The XPath expression XML RPC
      data.

      If the operation is conceptually evaluated in "replace", the following
   context:

   o  The context node is created if it does not
      exist, and its value is set to the node value found in the data tree for which XML RPC
      data.

      If the "must"
      statement operation is defined.

   o  The accessible tree "create" the node is made up of all nodes in created if it does not
      exist.

      If the data tree, and
      all leafs with default values.

   o  The set of namespace declarations operation is "delete" the set of all "import"
      statements' prefix and namespace pairs, and node is deleted if it exists.

7.6.7.  Usage Example

   Given the "prefix"
      statement's prefix for following leaf statement:

     leaf port {
         type inet:port-number;
         default 22;
         description "The port which the "namespace" statement's URI.

   o  Elements without SSH server listens to"
     }
   A corresponding XML encoding:

     <port>2022</port>

   To create a namespace refer leaf with an edit-config:

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
          xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
       <edit-config>
         <target>
           <running/>
         </target>
         <config>
           <system xmlns="http://example.com/schema/config">
             <services>
               <ssh>
                 <port>2022</port>
               </ssh>
             </services>
           </system>
         </config>
       </edit-config>
     </rpc>

7.7.  The leaf-list Statement

   Where the "leaf" statement is used to nodes in define a simple scalar variable
   of a particular type, the current module.

   o  The function library "leaf-list" statement is the core function library defined in
      [XPATH], and used to define an
   array of a function "current()" particular type.  The "leaf-list" statement takes one
   argument, which returns is an identifier, followed by a node set with
      the initial context node.

   The result block of the XPath expression is converted to
   substatements that holds detailed leaf-list information.

   The values in a boolean value
   using the standard XPath rules.

   If the node with leaf-list MUST be unique.

   Conceptually, the must statement represents configuration data,
   any node referenced values in the XPath expression MUST also represent
   configuration.

   Note that data tree are always in the XPath expression is conceptually evaluated.  This means
   that an implementation does not have to use an XPath evaluator on canonical
   form (see Section 9.1).

   If the
   device.  How type referenced by the evaluation is done leaf-list has a default value, it has
   no effect in practice is an implementation
   decision.

7.5.3. the leaf-list.

7.7.1.  The must's leaf-list's Substatements

                 +---------------+---------+-------------+

                 +--------------+---------+-------------+
                 | substatement | section | cardinality |
                 +---------------+---------+-------------+
                 +--------------+---------+-------------+
                 | config       | 7.19.1  | 0..1        |
                 | description  | 7.17.3 7.19.3  | 0..1        |
                 | error-app-tag if-feature   | 7.5.3.2 7.18.2  | 0..n        |
                 | max-elements | 7.7.3   | 0..1        |
                 | error-message min-elements | 7.5.3.1 7.7.2   | 0..1        |
                 | must         | 7.5.2   | 0..n        |
                 | ordered-by   | 7.7.4   | 0..1        |
                 | reference    | 7.17.4 7.19.4  | 0..1        |
                 +---------------+---------+-------------+

7.5.3.1.
                 | status       | 7.19.2  | 0..1        |
                 | type         | 7.4     | 1           |
                 | units        | 7.3.3   | 0..1        |
                 | when         | 7.19.5  | 0..1        |
                 +--------------+---------+-------------+

7.7.2.  The min-elements Statement

   The "min-elements" statement, which is optional, takes as an argument
   a non-negative integer which puts a constraint on valid list entries.
   A valid leaf-list or list always has at least min-elements entries.

   If no "min-elements" statement is present, it defaults to zero.

   The error-message "min-elements" constraint is enforced according to the rules in
   Section 8.

7.7.3.  The max-elements Statement

   The "error-message" "max-elements" statement, which is optional, takes a string as an argument.  If argument
   a positive integer or the string "unbounded", which puts a constraint evaluates
   on valid list entries.  A valid leaf-list or list always has at most
   max-elements entries.

   If no "max-elements" statement is present, it defaults to false, the string
   "unbounded".

   The "max-elements" constraint is
   passed as <error-message> in enforced according to the <rpc-error>.

7.5.3.2. rules in
   Section 8.

7.7.4.  The error-app-tag ordered-by Statement

   The "error-app-tag" statement, which is optional, takes "ordered-by" statement defines whether the order of entries
   within a string as
   an argument.  If list are determined by the constraint evaluates to false, user or the string system.  The argument
   is
   passed as <error-app-tag> in the <rpc-error>.

7.5.3.3.  Usage Example one of must and error-message

     container interface {
         leaf ifType {
             type enumeration {
                 enum ethernet;
                 enum atm;
             }
         }
         leaf ifMTU {
             type uint32;
         }
         must "ifType != 'ethernet' the strings "system" or " +
              "(ifType = 'ethernet' and ifMTU = 1500)" {
             error-message "An ethernet MTU must be 1500";
         }
         must "ifType != 'atm' "user".  If not present, order
   defaults to "system".

   This statement is ignored if the list represents state data, RPC
   output parameters, or " +
              "(ifType = 'atm' and ifMTU <= 17966 and ifMTU >= 64)" {
             error-message "An atm MTU must be  64 .. 17966";
         }
     }

7.5.4.  The presence Statement notification content.

   See Section 5.5 for additional information.

7.7.4.1.  ordered-by system

   The "presence" statement assigns a meaning entries in the list are sorted according to an unspecified order.
   Thus an implementation is free to sort the presence of a
   container entries in the data tree.  It takes as an argument a string which
   contains a textual description most
   appropriate order.  An implementation SHOULD use the same order for
   the same data, regardless of what how the node's presence means.

   If data were created.  Using a container has the "presence" statement,
   deterministic order will makes comparisons possible using simple
   tools like "diff".

   This is the container's
   existence default order.

7.7.4.2.  ordered-by user

   The entries in the data tree carries some meaning.  Otherwise, the
   container is used to give some structure list are sorted according to an order defined by
   the data, and it carries
   no meaning user.  This order is controlled by itself. using special XML attributes
   in the <edit-config> request.  See Section 5.6 7.7.6 for additional information.

7.5.5.  The container's Child Node Statements

   Within a container, the "container", "leaf", "list", "leaf-list",
   "uses", and "choice" statements can be used to define child nodes to
   the container.

7.5.6. details.

7.7.5.  XML Encoding Rules

   A container leaf-list node is encoded as an a series of XML element.  The elements.  Each
   element's name is the container's leaf-list's identifier, and its XML namespace
   is the module's XML namespace.

   The container's child nodes are value of the leaf-list node is encoded as subelements to XML according to the
   container element,
   type, and sent as character data in the same order as they are defined within element.

   See Section 7.7.7 for an example.

7.7.6.  NETCONF <edit-config> operations

   Leaf-list entries can be created and deleted, but not modified,
   through <edit-config>, by using the "operation" attribute in the
   leaf-list entry's XML element.

   In an "ordered-by user" leaf-list, the attributes "insert" and
   "value" in the YANG namespace (Section 5.4.1) can be used to control
   where in the
   container statement.

   A NETCONF server that replies leaf-list the entry is inserted.  These can be used
   during "create" operations to insert a <get> new leaf-list entry, or <get-config> request MAY
   choose not during
   "merge" or "replace" operations to send insert a container element if the container node does not
   have new leaf-list entry or
   move an existing one.

   The "insert" attribute can take the "presence" statement values "first", "last", "before",
   and no child nodes exist.  Thus, a
   client that receives an <rpc-reply> for a <get> "after".  If the value is "before" or <get-config>
   request, "after", the "value"
   attribute must also be prepared used to handle specify an existing entry in the case that a container node
   without a presence statement leaf-
   list.

   If no "insert" attribute is not present in the XML.

7.5.7.  NETCONF "create" operation, it
   defaults to "last".

   In a <copy-config>, or an <edit-config> Operations with a "replace" operation
   which covers the entire leaf-list, the leaf-list order is the same as
   the order of the XML elements in the request.

   When a NETCONF server processes an <edit-config> request, the
   elements of procedure for the container a leaf-list node are:

      If the operation is "merge" or "replace" the node leaf-list entry is
      created if it does not exist.

      If the operation is "replace" and the node exists, all child nodes
      not present in the XML are deleted, and child nodes present in the
      XML but not present in the datastore are created.

      If the operation is "create" the node leaf-list entry is created if it
      does not exist.

      If the operation is "delete" the node entry is deleted if it exists.

      If the container has a "presence" statement, it may be implicitly
      created if it does not exist, even if the operation is "none".

      If a container has a "presence" statement and the last child node
      is deleted, the NETCONF server MAY delete the container.

7.5.8. from the leaf-
      list if it exists.

7.7.7.  Usage Example

   Given the following container definition:

     container system {
         description "Contains various system parameters";
         container services {
             description "Configure externally available services";
             container "ssh"

     leaf-list allow-user  {
                 presence "Enables SSH";
         type string;
         description "SSH service specific configuration";
                 // more leafs, containers and stuff here...
             }
         } "A list of user name patterns to allow";
     }

   A corresponding XML encoding would look like this:

     <system> encoding:

     <allow-user>alice</allow-user>
     <allow-user>bob</allow-user>

   To create a new element in the list:

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
          xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
       <edit-config>
         <target>
           <running/>
         </target>
         <config>
           <system xmlns="http://example.com/schema/config">
             <services>
         <ssh/>
               <ssh>
                 <allow-user>eric</allow-user>
               </ssh>
             </services>
           </system>

   Since
         </config>
       </edit-config>
     </rpc>

   Given the <ssh> element is present, ssh is enabled.

   To delete following ordered-by user leaf-list:

     leaf-list cipher  {
         type string;
         ordered-by user;
         description "A list of ciphers";
     }

   The following would be used to insert a container with an <edit-config>: new cipher "blowfish-cbc"
   after "3des-cbc":

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
          xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
          xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
          xmlns:yang="urn:ietf:params:xml:ns:yang:1">
       <edit-config>
         <target>
           <running/>
         </target>
         <config>
           <system xmlns="http://example.com/schema/config">
             <services>
               <ssh nc:operation="delete"/>
               <ssh>
                 <cipher nc:operation="create"
                         yang:insert="after"
                         yang:value="3des-cbc">blowfish-cbc</cipher>
               </ssh>
             </services>
           </system>
         </config>
       </edit-config>
     </rpc>

7.6.

7.8.  The leaf list Statement

   The "leaf" "list" statement is used to define a leaf node interior nodes in the schema
   tree.  It  A list node may exist in multiple instances in the data tree.
   Each such instance is known as a list entry.  The "list" statement
   takes one argument, argument which is an identifier, followed by a block of
   substatements that holds detailed leaf list information.

   A leaf node has a value, but no child nodes in the data tree.

   A leaf node exists in zero or one instances in the data tree,
   depending on the value of the "mandatory" statement.

   The "leaf" statement is used to define a scalar variable of a
   particular built-in or derived type.

   If a leaf has a "default" statement, the leaf's default value list entry is set
   to uniquely identified by the value values of the "default" statement.  Otherwise, if the leaf's
   type has a default value, and the leaf is not mandatory, then the
   leaf's default value list's keys.

   A list is set similar to the type's default value.  In all
   other cases, the leaf does not have a default value.

   If the leaf has a default value, the server MUST use this value
   internally if no value table where each list entry is provided by the NETCONF client when a row in the
   instance is created.

7.6.1.
   table.

7.8.1.  The leaf's list's Substatements
                 +--------------+---------+-------------+
                 | substatement | section | cardinality |
                 +--------------+---------+-------------+
                 | anyxml       | 7.10    | 0..n        |
                 | augment      | 7.15    | 0..n        |
                 | choice       | 7.9     | 0..n        |
                 | config       | 7.17.1 7.19.1  | 0..1        |
                 | default container    | 7.6.3 7.5     | 0..1 0..n        |
                 | description  | 7.17.3 7.19.3  | 0..1        |
                 | mandatory grouping     | 7.6.4 7.11    | 0..n        |
                 | if-feature   | 7.18.2  | 0..n        |
                 | key          | 7.8.2   | 0..1        |
                 | leaf         | 7.6     | 0..n        |
                 | leaf-list    | 7.7     | 0..n        |
                 | list         | 7.8     | 0..n        |
                 | max-elements | 7.7.3   | 0..1        |
                 | min-elements | 7.7.2   | 0..1        |
                 | must         | 7.5.2   | 0..n        |
                 | ordered-by   | 7.7.4   | 0..1        |
                 | reference    | 7.17.4 7.19.4  | 0..1        |
                 | status       | 7.17.2 7.19.2  | 0..1        |
                 | type typedef      | 7.6.2 7.3     | 1 0..n        |
                 | units unique       | 7.3.3 7.8.3   | 0..n        |
                 | uses         | 7.12    | 0..n        |
                 | when         | 7.19.5  | 0..1        |
                 +--------------+---------+-------------+

7.6.2.

7.8.2.  The leaf's type list's key Statement

   The "type" statement, which must "key" statement, which MUST be present if the list represents
   configuration, and MAY be present otherwise, takes as an argument a
   string which specifies a space separated list of leaf identifiers of
   this list.  A leaf identifier MUST NOT appear more than once in the
   key.  Each such leaf identifier MUST refer to a child leaf of the
   list.

   The combined values of all the leafs specified in the key are used to
   uniquely identify a list entry.  All key leafs MUST be present, takes as an argument given values
   when a list entry is created.  Thus, any default values in the
   name key
   leafs or their types are ignored.  It also implies that any mandatory
   statement in the key leafs are ignored.

   A leaf that is part of an existing the key can be of any built-in or derived type.
   type, except it MUST NOT be the built-in type "empty".

   All key leafs in a list MUST have the same value for their "config"
   as the list itself.

   The optional
   substatements specify restrictions on this type.  See key string syntax is formally defined by the rule "key-arg" in
   Section 7.4 for
   details.

7.6.3. 12.

7.8.3.  The leaf's default lists's unique Statement

   The "default" statement, which "unique" statement is optional, used to put constraints on valid list
   entries.  It takes as an argument a string which contains a default value for space
   separated list of schema node identifiers, which MUST be given in the
   descendant form (see the rule "descendant-schema-nodeid" in
   Section 12).  Each such schema node identifier MUST refer to a leaf.

   The value

   If one of the "default" statement referenced leafs represents configuration data, then
   all of the referenced leafs MUST correspond to represent configuration data.

   The "unique" constraint specifies that the type combined values of all the
   leaf instances specified in the leaf's "type" statement.

   The "default" statement argument string, including leafs with
   default values, MUST NOT be present on nodes where
   "mandatory" is true.

7.6.4.  The leaf's mandatory Statement unique within all list entry instances.  The "mandatory" statement, which
   constraint is optional, takes as an argument enforced according to the rules in Section 8.

   The unique string "true" or "false".  If "mandatory" syntax is "true", formally defined by the node
   must exist rule "unique-arg"
   in a valid configuration if its parent node exists.  Since
   containers without a "presence" statement are implicitly created and
   deleted when needed, they are ignored when performing mandatory tests
   for leafs.  A mandatory Section 12.

7.8.3.1.  Usage Example

   With the following list:

     list server {
         key "name";
         unique "ip port";
         leaf within such a container name {
             type string;
         }
         leaf ip {
             type inet:ip-address;
         }
         leaf port {
             type inet:port-number;
         }
     }

   The following configuration is mandatory
   even if the container's data node does not exist.

   If not specified, valid:

     <server>
       <name>smtp</name>
       <ip>192.0.2.1</ip>
       <port>25</port>
     </server>

     <server>
       <name>http</name>
       <ip>192.0.2.1</ip>
       <port>25</port>
     </server>

7.8.4.  The list's Child Node Statements

   Within a list, the default is "false".

7.6.5. "container", "leaf", "list", "leaf-list", "uses",
   and "choice" statements can be used to define child nodes to the
   list.

7.8.5.  XML Encoding Rules

   A leaf node list is encoded as an a series of XML element.  The elements, one for each entry in
   the list.  Each element's name is the
   leaf's list's identifier, and its XML
   namespace is the module's XML namespace.

   The value list's key nodes are encoded as subelements to the list's
   identifier element, in the same order as they are defined within the
   key statement.

   The rest of the leaf node is list's child nodes are encoded to XML according as subelements to the type,
   and sent
   list element, after the keys, in the same order as character data they are defined
   within the list statement.

7.8.6.  NETCONF <edit-config> operations

   List entries can be created, deleted, replaced and modified through
   <edit-config>, by using the "operation" attribute in the list's XML
   element.

   A NETCONF server that replies  In each case, the values of all keys are used to uniquely
   identify a <get> or <get-config> request MAY
   choose list entry.  If all keys are not to send the leaf element if its value is the default
   value.  Thus, a client that receives an <rpc-reply> specified for a <get> or
   <get-config> request, must be prepared to handle the case that a leaf
   node with list
   entry, a default value "missing-element" error is not present in the XML. returned.

   In this case, an "ordered-by user" list, the value attributes "insert" and "key" in
   the YANG namespace (Section 5.4.1) can be used by to control where in
   the server list the entry is known to inserted.  These can be the default value.

   See Section 7.6.7 for an example.

7.6.6.  NETCONF <edit-config> Operations

   When used during "create"
   operations to insert a NETCONF server processes new list entry, or during "merge" or "replace"
   operations to insert a new list entry or move an <edit-config> request, the
   elements of procedure for existing one.

   The "insert" attribute can take the leaf node are: values "first", "last", "before",
   and "after".  If the operation is "merge", the node is created if it does not
      exist, and its value is set to "before" or "after", the value found "key"
   attribute must also be used, to specify an existing element in the XML RPC
      data.

      If
   list.  The value of the operation "key" attribute is "replace", the node is created if it does not
      exist, and its value is set to key predicates of the value found
   full instance identifier (see Section 9.13) for the list entry.

   If no "insert" attribute is present in the XML RPC
      data.

      If the operation is "create" the node is created if operation, it does not
      exist.

      If the
   defaults to "last".

   In a <copy-config>, or an <edit-config> with a "replace" operation is "delete"
   which covers the node entire list, the list entry order is deleted if it exists.

7.6.7. the same as the
   order of the XML elements in the request.

7.8.7.  Usage Example

   Given the following list:

     list user {
         key "name";
         config true;
         description "This is a list of users in the system.";

         leaf statement: name {
             type string;
         }
         leaf port type {
             type inet:port-number;
         default 22;
         description "The port which the SSH server listens to" string;
         }
         leaf full-name {
             type string;
         }
     }

   A corresponding XML encoding:

     <port>2022</port>

     <user>
       <name>fred</name>
       <type>admin</type>
       <full-name>Fred Flintstone</full-name>
     </name>

   To create a new user "barney":

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
          xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
       <edit-config>
         <target>
           <running/>
         </target>
         <config>
           <system xmlns="http://example.com/schema/config">
             <user nc:operation="create">
               <name>barney</name>
               <type>admin</type>
               <full-name>Barney Rubble</full-name>
             </user>
           </system>
         </config>
       </edit-config>
     </rpc>

   To change the type of "fred" to "superuser":

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
          xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
       <edit-config>
         <target>
           <running/>
         </target>
         <config>
           <system xmlns="http://example.com/schema/config">
             <user>
               <name>fred</name>
               <type>superuser</type>
             </user>
           </system>
         </config>
       </edit-config>
     </rpc>

   Given the following ordered-by user list:

     list user {
         description "This is a list of users in the system.";
         ordered-by user;
         config true;

         key "name";

         leaf with an edit-config: name {
             type string;
         }
         leaf type {
             type string;
         }
         leaf full-name {
             type string;
         }
     }

   The following would be used to insert a new user "barney" after the
   user "fred":

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
          xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
          xmlns:yang="urn:ietf:params:xml:ns:yang:1">
       <edit-config>
         <target>
           <running/>
         </target>
         <config>
           <system xmlns="http://example.com/schema/config"
                xmlns:ex="http://example.com/schema/config">
             <user nc:operation="create"
                   yang:insert="after"
                   yang:key="[ex:name='fred']">
               <name>barney</name>
               <type>admin</type>
               <full-name>Barney Rubble</full-name>
             </user>
           </system>
         </config>
       </edit-config>
     </rpc>

   The following would be used to move the user "barney" before the user
   "fred":

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
          xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
          xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
          xmlns:yang="urn:ietf:params:xml:ns:yang:1">
       <edit-config>
         <target>
           <running/>
         </target>
         <config>
           <system xmlns="http://example.com/schema/config">
             <services>
               <ssh>
                 <port>2022</port>
               </ssh>
             </services> xmlns="http://example.com/schema/config"
                xmlns:ex="http://example.com/schema/config">
             <user nc:operation="merge"
                   yang:insert="before"
                   yang:key="[ex:name='fred']">
               <name>barney</name>
             </user>
           </system>
         </config>
       </edit-config>
     </rpc>

7.7.

7.9.  The leaf-list choice Statement

   Where the "leaf"

   The "choice" statement defines a set of alternatives, only one of
   which may exist at any one time.  The argument is an identifier,
   followed by a block of substatements that holds detailed choice
   information.  The identifier is used to define identify the choice node in
   the schema tree.  A choice node does not exist in the data tree.

   A choice consists of a simple scalar variable number of branches, defined with the case
   substatement.  Each branch contains a number of child nodes.  The
   "choice" statement puts a particular type, constraint on a valid configuration.  In a
   valid configuration, the "leaf-list" nodes from at most one of the choice's
   branches exist at the same time.

   See Section 4.2.7 for additional information.

7.9.1.  The choice's Substatements

                 +--------------+---------+-------------+
                 | substatement | section | cardinality |
                 +--------------+---------+-------------+
                 | anyxml       | 7.10    | 0..n        |
                 | case         | 7.9.2   | 0..n        |
                 | config       | 7.19.1  | 0..1        |
                 | container    | 7.5     | 0..n        |
                 | default      | 7.9.3   | 0..1        |
                 | description  | 7.19.3  | 0..1        |
                 | if-feature   | 7.18.2  | 0..n        |
                 | leaf         | 7.6     | 0..n        |
                 | leaf-list    | 7.7     | 0..n        |
                 | list         | 7.8     | 0..n        |
                 | mandatory    | 7.9.4   | 0..1        |
                 | reference    | 7.19.4  | 0..1        |
                 | status       | 7.19.2  | 0..1        |
                 | when         | 7.19.5  | 0..1        |
                 +--------------+---------+-------------+

7.9.2.  The choice's case Statement

   The "case" statement is used to define an
   array branches of a particular type.  The "leaf-list" statement the choice.  It
   takes one
   argument, which is as an argument an identifier, followed by a block of
   substatements that holds detailed leaf-list case information.

   The values identifier is used to identify the case node in the schema tree.
   A case node does not exist in the data tree.

   Within a leaf-list MUST "case" statement, the "anyxml", "container", "leaf", "list",
   "leaf-list", "uses", and "augment" statements can be unique.

   If used to define
   child nodes to the type referenced by case node.  The identifiers of all these child
   nodes must be unique within all cases in a choice.  For example, the leaf-list has
   following is illegal:

     choice interface-type {     // This example is illegal YANG
         case a default value, it has
   no effect {
             leaf ethernet { ... }
         }
         case b {
             container ethernet { ...}
         }
     }

   As a shorthand, the "case" statement can be omitted if the branch
   contains a single "anyxml", "container", "leaf", "list", or "leaf-
   list" statement.  In this case, the identifier of the case node is
   the same as the identifier in the leaf-list.

7.7.1. branch statement.  The leaf-list's following
   example:

     choice interface-type {
       container ethernet { ... }
     }

   is equivalent to:

     choice interface-type {
       case ethernet {
         container ethernet { ... }
       }
     }

   The case identifier MUST be unique within a choice.

7.9.2.1.  The case's Substatements

                 +--------------+---------+-------------+
                 | substatement | section | cardinality |
                 +--------------+---------+-------------+
                 | config anyxml       | 7.17.1 7.10    | 0..1 0..n        |
                 | augment      | 7.15    | 0..n        |
                 | container    | 7.5     | 0..n        |
                 | description  | 7.17.3 7.19.3  | 0..1        |
                 | max-elements if-feature   | 7.7.3 7.18.2  | 0..1 0..n        |
                 | min-elements leaf         | 7.7.2 7.6     | 0..1 0..n        |
                 | must leaf-list    | 7.5.2 7.7     | 0..n        |
                 | ordered-by list         | 7.7.4 7.8     | 0..1 0..n        |
                 | reference    | 7.17.4 7.19.4  | 0..1        |
                 | status       | 7.17.2 7.19.2  | 0..1        |
                 | type uses         | 7.4 7.12    | 1 0..n        |
                 | units when         | 7.3.3 7.19.5  | 0..1        |
                 +--------------+---------+-------------+

7.7.2.

7.9.3.  The min-elements choice's default Statement

   The "min-elements" statement, which is optional, takes as an argument
   a non-negative integer which puts a constraint on "default" statement indicates if a valid
   configuration.  A valid configuration always has at least min-
   elements values in case should be considered as
   the leaf-list or list.

   If default if no "min-elements" statement is present, it defaults to zero.

7.7.3.  The max-elements Statement child nodes from any of the choice's cases exists.
   The "max-elements" statement, which is optional, takes as an argument
   a positive integer or is the string "unbounded", which puts a constraint
   on a valid configuration.  A valid configuration always has at most
   max-elements values in identifier of the leaf-list or list. "case" statement.  If no "max-elements" the
   "default" statement is present, it defaults to
   "unbounded".

7.7.4.  The ordered-by Statement missing, there is no default case.

   The "ordered-by" "default" statement defines whether the order of entries
   within a list are determined by the user or the system.  The argument MUST NOT be present on choices where
   "mandatory" is one of the strings "system" or "user".  If not present, order
   defaults to "system".

   See Section 5.5 for additional information.

7.7.4.1.  ordered-by system true.

   The entries in the list are sorted according to an unspecified order.
   Thus an implementation default case is free to sort the entries in the most
   appropriate order.  An implementation SHOULD use the same order for only important when considering the same data, regardless default
   values of how the data were created.  Using a
   deterministic order will makes comparisons possible using simple
   tools like "diff".

   This is nodes under the default order.

7.7.4.2.  ordered-by user cases.  The entries in default values for nodes under
   the list default case are sorted according to an order defined by used if none of the user.  This order is controlled by using special XML attributes
   in nodes under any of the <edit-config> request.  See Section 7.7.6 cases
   are present.

   There MUST NOT be any mandatory nodes (Section 3.1) directly under
   the default case.

   Default values for details.

7.7.5.  XML Encoding Rules

   A leaf-list node is encoded as child nodes under a series case are only used if one of XML elements.  Each
   element's name is
   the leaf-list's identifier, and its XML namespace nodes under that case is present, or if that case is the module's XML namespace.

   The value default
   case.  If none of the leaf-list node is encoded to XML according to the
   type, nodes under a case are present and sent as character data in the element.

   See Section 7.7.7 for an example.

7.7.6.  NETCONF <edit-config> operations

   Leaf-list entries can be created and deleted, but case is
   not modified,
   through <edit-config>, by using the "operation" attribute in default case, the
   leaf-list entry's XML element.

   In an "ordered-by user" leaf-list, default values of the attributes "insert" and
   "value" in cases' child nodes
   are ignored.

   In this example, the YANG namespace (Section 5.4.1) can be used choice defaults to control
   where in the leaf-list "interval", and the entry is inserted.  These can default
   value will be used
   during "create" operations to insert a new leaf-list entry, or during
   "merge" or "replace" operations to insert a new leaf-list entry or
   move an existing one.

   The "insert" attribute can take the values "first", "last", "before",
   and "after". if none of "daily", "time-of-day", or "manual" are
   present.  If the value "daily" is "before" or "after", present, the "value"
   attribute must also default value for "time-of-day"
   will be used to specify used.

     container transfer {
         choice how {
             default interval;
             case interval {
                 leaf interval {
                     type uint16;
                     default 30;
                     units minutes;
                 }
             }
             case daily {
                 leaf daily {
                     type empty;
                 }
                 leaf time-of-day {
                     type string;
                     units 24-hour-clock;
                     default 1am;
                 }
             }
             case manual {
                 leaf manual {
                     type empty;
                 }
             }
         }
     }

7.9.4.  The choice's mandatory Statement

   The "mandatory" statement, which is optional, takes as an existing entry in argument
   the leaf-
   list. string "true" or "false".  If no "insert" attribute "mandatory" is present in "true", at least one
   node from exactly one of the "create" operation, it
   defaults choice's case branches MUST exist.  This
   constraint is enforced according to "last".

   In a <copy-config>, or an <edit-config> with a "replace" operation
   which covers the entire leaf-list, rules in Section 8.

   If not specified, the leaf-list order default is the same as
   the order of the "false".

7.9.5.  XML elements Encoding Rules

   The choice and case nodes are not visible in the request.

   When a XML.

7.9.6.  NETCONF server processes an <edit-config> request, operations

   Since only one of the
   elements choices cases can be valid at any time, the
   creation of procedure for a leaf-list node are:

      If the operation is "merge" or "replace" the leaf-list entry is
      created if it does not exist.

      If the operation is "create" the leaf-list entry is created if it
      does not exist. from one case implicitly deletes all nodes from
   all other cases.  If the an <edit-config> operation is "delete" creates a node, the entry is deleted from
   NETCONF server will delete any existing nodes that are defined in
   other cases inside the leaf-
      list if it exists.

7.7.7. choice.

7.9.7.  Usage Example

     leaf-list allow-user

   Given the following choice:

     container protocol {
         type string;
         description "A list of user
         choice name patterns to allow"; {
             case a {
                 leaf udp {
                     type empty;
                 }
             }
             case b {
                 leaf tcp {
                    type empty;
                 }
             }
         }
     }

   A corresponding XML encoding:

     <allow-user>alice</allow-user>
     <allow-user>bob</allow-user>

     <protocol>
       <tcp/>
     </protocol>

   To create a new element in the list:

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
          xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
       <edit-config>
         <target>
           <running/>
         </target>
         <config>
           <system xmlns="http://example.com/schema/config">
             <services>
               <ssh>
                 <allow-user>eric</allow-user>
               </ssh>
             </services>
           </system>
         </config>
       </edit-config>
     </rpc>
   Given change the following ordered-by user leaf-list:

     leaf-list ciphers  {
         type string;
         ordered-by user;
         description "A list of ciphers";
     }

   The following would be used protocol from tcp to insert a new cipher "blowfish-cbc"
   after "3des-cbc": udp:

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
          xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
          xmlns:yang="urn:ietf:params:xml:ns:yang:1">
          xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
       <edit-config>
         <target>
           <running/>
         </target>
         <config>
           <system xmlns="http://example.com/schema/config">
             <services>
               <ssh>
                 <cipher nc:operation="create"
                         yang:insert="after"
                         yang:value="3des-cbc">blowfish-cbc</cipher>
               </ssh>
             </services>
             <protocol>
               <udp nc:operation="create"/>
             </protocol>
           </system>
         </config>
       </edit-config>
     </rpc>

7.8.

7.10.  The list anyxml Statement

   The "list" "anyxml" statement is used to define defines an interior nodes in the schema
   tree.  A list node may exist in multiple instances in the data schema tree.
   Each such instance is known as a list entry.  The "list" statement
   It takes one argument argument, which is an identifier, followed by a block of
   substatements that holds detailed list anyxml information.

   A list entry

   The anyxml statement is uniquely identified by the values used to represent an unknown chunk of XML.
   No restrictions are placed on the list's keys.

   A list is similar to a table where each list entry XML.  This can be useful in e.g.
   RPC replies.  An example is a row the <filter> parameter in the
   table.

7.8.1. <get-
   config> operation.

   An anyxml node cannot be augmented.

   It is NOT RECOMMENDED that the anyxml statement is used to represent
   configuration data.

7.10.1.  The list's anyxml's Substatements

                 +--------------+---------+-------------+
                 | substatement | section | cardinality |
                 +--------------+---------+-------------+
                 | anyxml       | 7.10    | 0..n        |
                 | augment      | 7.15    | 0..n        |
                 | choice       | 7.9     | 0..n        |
                 | config       | 7.17.1 7.19.1  | 0..1        |
                 | container    | 7.5     | 0..n        |
                 | description  | 7.17.3  | 0..1        |
                 | grouping     | 7.11    | 0..n        |
                 | key          | 7.8.2   | 0..1        |
                 | leaf         | 7.6     | 0..n        |
                 | leaf-list    | 7.7     | 0..n        |
                 | list         | 7.8     | 0..n        |
                 | max-elements | 7.7.3   | 0..1        |
                 | min-elements | 7.7.2 7.19.3  | 0..1        |
                 | must if-feature   | 7.5.2 7.18.2  | 0..n        |
                 | ordered-by mandatory    | 7.7.4 7.6.4   | 0..1        |
                 | reference    | 7.17.4 7.19.4  | 0..1        |
                 | status       | 7.17.2 7.19.2  | 0..1        |
                 | typedef      | 7.3     | 0..n        |
                 | unique       | 7.8.3   | 0..n        |
                 | uses when         | 7.12 7.19.5  | 0..n 0..1        |
                 +--------------+---------+-------------+

7.8.2.  The list's key Statement

7.10.2.  XML Encoding Rules

   An anyxml node is encoded as an XML element.  The "key" statement, which MUST be present if element's name is
   the list represents
   configuration, anyxml's identifier, and MAY its XML namespace is the module's XML
   namespace.  The value of the anyxml node is encoded as XML content of
   this element.

   Note that any prefixes used in the encoding are local to each
   instance encoding.  This means that the same XML may be present otherwise, takes encoded
   differently by different implementations.

7.10.3.  NETCONF <edit-config> operations

   An anyxml node is treated as an argument a
   string which specifies opaque chunk of data.  This data can
   be modified in its entirety only.

   Any "operation" attributes within the XML value of an anyxml node are
   ignored by the NETCONF server.

   When a space separated list NETCONF server processes an <edit-config> request, the
   elements of leaf identifiers procedure for the anyxml node are:

      If the operation is "merge", the node is created if it does not
      exist, and its value is set to the XML content of
   this list.  A leaf identifier MUST NOT appear more than once the anyxml node
      found in the
   key.  Each such leaf identifier MUST refer XML RPC data.

      If the operation is "replace", the node is created if it does not
      exist, and its value is set to a child leaf the XML content of the
   list.

   The combined values anyxml node
      found in the XML RPC data.

      If the operation is "create" the node is created if it does not
      exist, and its value is set to the XML content of all the leafs specified anyxml node
      found in the key XML RPC data.

      If the operation is "delete" the node is deleted if it exists.

7.10.4.  Usage Example

   Given the following anyxml statement:

     anyxml data;

   The following are two valid encodings of the same anyxml value:

     <data xmlns:if="http://example.com/ns/interface">
       <if:interface>
         <if:ifIndex>1</if:ifIndex>
       </if:interface>
     </data>

     <data>
       <interface xmlns="http://example.com/ns/interface">
         <ifIndex>1</ifIndex>
       </interface>
     </data>

7.11.  The grouping Statement

   The "grouping" statement is used to
   uniquely identify define a list entry.  All key leafs MUST reusable block of nodes,
   which may be given values
   when a list entry is created.  Thus, any default values used locally in the key
   leafs or their types are ignored. module, in modules which include it,
   and by other modules which import from it.  It also implies takes one argument
   which is an identifier, followed by a block of substatements that any mandatory
   holds detailed grouping information.

   The grouping statement is not a data definition statement and, as
   such, does not define any nodes in the key leafs are ignored. schema tree.

   A leaf that grouping is part of the key can be of any built-in like a "structure" or derived
   type, except a "record" in conventional
   programming languages.

   Once a grouping is defined, it MUST NOT can be the built-in type "empty".

   All key leafs referenced in a list "uses"
   statement (see Section 7.12).  A grouping MUST have the same value for their "config"
   as NOT reference itself,
   neither directly nor indirectly through a chain of other groupings.

   If the list itself.

   The key string syntax grouping is formally defined by at the rule "key-arg" in
   Section 11.

7.8.3.  The lists's top level of a YANG module or
   submodule, the grouping's identifier MUST be unique Statement

   The "unique" statement within the
   module.  For details about scoping for nested groupings, see
   Section 5.8.

   A grouping is used to put constraints on valid
   configurations.  It takes as an argument more than just a string which contains mechanism for textual substitution,
   but defines a
   space separated list collection of schema node identifiers, nodes.  References from inside the
   grouping are relative to the scope in which MUST be given the grouping is defined,
   not where it is used.  Prefix mappings, type names, grouping names,
   and extension usage are evaluated in the descendant form (see hierarchy where the rule "descendant-schema-nodeid" in
   Section 11).  Each such schema node identifier MUST refer grouping
   statement appears.  For extensions, this means that extensions are
   applied to a leaf.

   In a valid configuration, the combined values of all grouping node, not the use node.

7.11.1.  The grouping's Substatements

                 +--------------+---------+-------------+
                 | substatement | section | cardinality |
                 +--------------+---------+-------------+
                 | anyxml       | 7.10    | 0..n        |
                 | augment      | 7.15    | 0..n        |
                 | choice       | 7.9     | 0..n        |
                 | container    | 7.5     | 0..n        |
                 | description  | 7.19.3  | 0..1        |
                 | grouping     | 7.11    | 0..n        |
                 | leaf
   instances specified in the string MUST be unique within all         | 7.6     | 0..n        |
                 | leaf-list    | 7.7     | 0..n        |
                 | list
   entry instances.

   The unique string syntax is formally defined by the rule "unique-arg"
   in Section 11.

7.8.3.1.         | 7.8     | 0..n        |
                 | reference    | 7.19.4  | 0..1        |
                 | status       | 7.19.2  | 0..1        |
                 | typedef      | 7.3     | 0..n        |
                 | uses         | 7.12    | 0..n        |
                 +--------------+---------+-------------+

7.11.2.  Usage Example

   With the following list:

     list server {
         key "name";
         unique "ip port";
         leaf name

     import inet-types {
             type string;
         prefix "inet";
     }

     grouping address {
         description "A reusable address group.";
         leaf ip {
             type inet:ip-address;
         }
         leaf port {
             type inet:port-number;
         }
     }

7.12.  The following configuration is not valid:

     <server>
       <name>smtp</name>
       <ip>192.0.2.1</ip>
       <port>25</port>
     </server>

     <server>
       <name>http</name>
       <ip>192.0.2.1</ip>
       <port>25</port>
     </server>

7.8.4. uses Statement

   The list's Child Node Statements

   Within a list, the "container", "leaf", "list", "leaf-list", "uses",
   and "choice" statements can be "uses" statement is used to define child nodes to the
   list.

7.8.5.  XML Encoding Rules

   A list is encoded as reference a series of XML elements, "grouping" definition.
   It takes one for each entry in
   the list.  Each element's name is the list's identifier, and its XML
   namespace is the module's XML namespace.

   The list's key nodes are encoded as subelements to the list's
   identifier element, in the same order as they are defined within argument, which is the
   key statement.

   The rest name of the list's child nodes are encoded as subelements grouping.

   The effect of a "uses" reference to a grouping is that the
   list element, after the keys, in the same order as they are nodes
   defined
   within the list statement.

7.8.6.  NETCONF <edit-config> operations

   List entries can be created, deleted, replaced and modified through
   <edit-config>, by using the "operation" attribute in the list's XML
   element.  In each case, the values of all keys are used to uniquely
   identify a list entry.  If all keys grouping are not specified for a list
   entry, a "missing-element" error is returned.

   In an "ordered-by user" list, copied into the attributes "insert" current schema tree, and "key" in
   the YANG namespace (Section 5.4.1) can be used
   then updated according to control where in the list refinement statements.  Thus, the entry is inserted.  These can be used during "create"
   operations to insert a new list entry, or during "merge" or "replace"
   operations to insert a new list entry or move an existing one.

   The "insert" attribute can take
   identifiers defined in the values "first", "last", "before",
   and "after".  If grouping are copied into the value current
   module's namespace, even if the grouping is "before" or "after", imported from some other
   module.

7.12.1.  The uses's Substatements

                 +--------------+---------+-------------+
                 | substatement | section | cardinality |
                 +--------------+---------+-------------+
                 | augment      | 7.15    | 0..1        |
                 | description  | 7.19.3  | 0..1        |
                 | if-feature   | 7.18.2  | 0..n        |
                 | refine       | 7.12.2  | 0..1        |
                 | reference    | 7.19.4  | 0..1        |
                 | status       | 7.19.2  | 0..1        |
                 | when         | 7.19.5  | 0..1        |
                 +--------------+---------+-------------+

7.12.2.  The refine Statement

   Some of the "key"
   attribute must also be used, to specify an existing element properties of each node in the
   list.  The value of grouping can be refined
   with the "key" attribute "refine" statement.  The argument is a a string which
   identifies a node in the key predicates of the
   full instance identifier (see Section 8.11) for grouping.  This node is called the list entry. refine's
   target node.  If no "insert" attribute a node in the grouping is not present as target node
   of a refine statement, it is not refined, and thus used exactly as it
   was defined in the "create" operation, grouping.

   The argument string is a schema node identifier.  The syntax is
   formally defined by the rule "descendant-schema-nodeid" in
   Section 12.

   The following refinements can be done:

   o  A leaf or choice node may get a default value, or a new default
      value if it
   defaults to "last".

   In already had one.

   o  Any node may get a <copy-config>, specialized "description" string.

   o  Any node may get a specialized "reference" string.

   o  Any node may get a different "config" statement.

   o  A leaf or an <edit-config> with choice node may get a "replace" operation
   which covers the entire list, the different "mandatory" statement.

   o  A container node may get a "presence" statement.

   o  A leaf, leaf-list, list entry order is the same as the
   order of the or container node may get additional
      "must" expressions.

   o  A leaf-list or list node may get a different "min-elements" or
      "max-elements" statement.

7.12.3.  XML elements Encoding Rules

   Each node in the request.

7.8.7. grouping is encoded as if it was defined inline,
   even if it is imported from another module with another XML
   namespace.

7.12.4.  Usage Example

   Given

   To use the following list:

     list user {
         key "name";
         config true;
         description "This is "address" grouping defined in Section 7.11.2 in a list
   definition of users an HTTP server in the system.";

         leaf name some other module, we can do:

     import acme-system {
             type string;
         prefix "acme";
     }
         leaf type

     container http-server {
             type string;
         }
         leaf full-name name {
             type string;
         }
         uses acme:address;
     }

   A corresponding XML encoding:

     <user>
       <name>fred</name>
       <type>admin</type>
       <full-name>Fred Flintstone</full-name>
     </name>

   To create a new user "barney":

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
          xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
       <edit-config>
         <target>
           <running/>
         </target>
         <config>
           <system xmlns="http://example.com/schema/config">
             <user nc:operation="create">
               <name>barney</name>
               <type>admin</type>
               <full-name>Barney Rubble</full-name>
             </user>
           </system>
         </config>
       </edit-config>
     </rpc>
   To change

     <http-server>
       <name>extern-web</name>
       <ip>192.0.2.1</ip>
       <port>80</port>
     </http-server>

   If port 80 should be the type of "fred" to "superuser":

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
          xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
       <edit-config>
         <target>
           <running/>
         </target>
         <config>
           <system xmlns="http://example.com/schema/config">
             <user>
               <name>fred</name>
               <type>superuser</type>
             </user>
           </system>
         </config>
       </edit-config>
     </rpc>

   Given default for the following ordered-by user list:

     list user HTTP server, default can be
   added:

     container http-server {
         description "This is a list of users in the system.";
         ordered-by user;
         config true;

         key "name";
         leaf name {
             type string;
         }
         leaf type
         uses acme:address {
             type string;
             refine port {
                 default 80;
             }
         }
     }

   If we want to define a list of servers, and each server has the ip
   and port as keys, we can do:

     list server {
         key "ip port";
         leaf full-name name {
             type string;
         }
         uses acme:address;
     }

   The following would be used to insert a new user "barney" after the
   user "fred":

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
          xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
          xmlns:yang="urn:ietf:params:xml:ns:yang:1">
       <edit-config>
         <target>
           <running/>
         </target>
         <config>
           <system xmlns="http://example.com/schema/config"
                xmlns:ex="http://example.com/schema/config">
             <user nc:operation="create"
                   yang:insert="after"
                   yang:key="[ex:name='fred']">
               <name>barney</name>
               <type>admin</type>
               <full-name>Barney Rubble</full-name>
             </user>
           </system>
         </config>
       </edit-config>
     </rpc>

   The following would be is an error:

     container http-server {
         uses acme:address;
         leaf ip {          // illegal - same identifier "ip" used to move the user "barney" before the user
   "fred":

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
          xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
          xmlns:yang="urn:ietf:params:xml:ns:yang:1">
       <edit-config>
         <target>
           <running/>
         </target>
         <config>
           <system xmlns="http://example.com/schema/config"
                xmlns:ex="http://example.com/schema/config">
             <user nc:operation="merge"
                   yang:insert="before"
                   yang:key="[ex:name='fred']">
               <name>barney</name>
             </user>
           </system>
         </config>
       </edit-config>
     </rpc>

7.9. twice
             type string;
         }
     }

7.13.  The choice rpc Statement

   The "choice" "rpc" statement defines is used to define a set of alternatives, only NETCONF RPC method.  It takes
   one of argument, which may exist at any one time.  The argument is an identifier, followed by a block of
   substatements that holds detailed choice rpc information.  The identifier  This argument is
   the name of the RPC, and is used to identify as the choice element name directly under
   the <rpc> element, as designated by the substitution group
   "rpcOperation" in [RFC4741].

   The "rpc" statement defines an rpc node in the schema tree.  A choice  Under
   the rpc node, an input node does not exist in with the data tree.

   A choice consists of a number of branches, defined name "input", and an output node
   with the case
   substatement.  Each branch contains a number of child nodes. name "output" are also defined.  The
   "choice" statement puts a constraint on a valid configuration.  In a
   valid configuration, the nodes from at most one of the choice's
   branches exist at "input" and
   "output" are defined in the same time.

   See Section 4.2.7 for additional information.

7.9.1. module's namespace.

7.13.1.  The choice's rpc's Substatements

                 +--------------+---------+-------------+
                 | substatement | section | cardinality |
                 +--------------+---------+-------------+
                 | anyxml description  | 7.10 7.19.3  | 0..n 0..1        |
                 | case grouping     | 7.9.2 7.11    | 0..n        |
                 | config       | 7.17.1  | 0..1 if-feature   |
                 | container    | 7.5 7.18.2  | 0..n        |
                 | default input        | 7.9.3 7.13.2  | 0..1        |
                 | description output       | 7.17.3 7.13.3  | 0..1        |
                 | leaf         | 7.6     | 0..n        |
                 | leaf-list    | 7.7     | 0..n        |
                 | list         | 7.8     | 0..n        |
                 | mandatory reference    | 7.9.4 7.19.4  | 0..1        |
                 | reference status       | 7.17.4 7.19.2  | 0..1        |
                 | status typedef      | 7.17.2 7.3     | 0..1 0..n        |
                 +--------------+---------+-------------+

7.9.2.

7.13.2.  The choice's case input Statement

   The "case" statement "input" statement, which is optional, is used to define branches of input
   parameters to the choice. RPC method.  It
   takes as an argument does not take an identifier, followed by a block of
   substatements that holds detailed case information. argument.  The identifier is used
   substatements to identify the case node in "input" defines nodes under the schema tree.
   A case node does not exist RPC's input node.

   If a container in the data tree.

   Within input tree has a "case" "presence" statement, the "anyxml", "container", "leaf", "list",
   "leaf-list", "uses", and "augment" statements can be used to define
   child nodes to the case node.  The identifiers of all these child
   nodes must
   container need not be unique within all cases present in a choice.  For example, the
   following is illegal:

     choice interface-type {     // This example is illegal YANG
         case NETCONF RPC invocation.

   If a { leaf ethernet { ... }
         }
         case b {
             container ethernet { ...}
         }
     }

   As a shorthand, the "case" statement can be omitted if in the branch
   contains input tree has a single "anyxml", "container", "leaf", "list", or "leaf-
   list" statement.  In this case, the identifier of the case node is "mandatory" statement with the same as
   value "true", the identifier leaf MUST be present in a NETCONF RPC invocation.

   If a leaf in the branch statement.  The following
   example:

     choice interface-type {
       container ethernet { ... }
     }

   is equivalent to:

     choice interface-type {
       case ethernet {
         container ethernet { ... }
       }
     }

   The case identifier input tree has a default value, the NETCONF server
   MUST be unique within internally use this default if the leaf is not present in a choice.

7.9.2.1.
   NETCONF RPC invocation.

   If a "config" statement is present for any node in the input tree, it
   is ignored.

7.13.2.1.  The case's input's Substatements

                 +--------------+---------+-------------+
                 | substatement | section | cardinality |
                 +--------------+---------+-------------+
                 | anyxml       | 7.10    | 0..n        |
                 | augment      | 7.15    | 0..n        |
                 | choice       | 7.9     | 0..n        |
                 | container    | 7.5     | 0..n        |
                 | description grouping     | 7.17.3 7.11    | 0..1 0..n        |
                 | leaf         | 7.6     | 0..n        |
                 | leaf-list    | 7.7     | 0..n        |
                 | list         | 7.8     | 0..n        |
                 | reference    | 7.17.4  | 0..1        |
                 | status typedef      | 7.17.2 7.3     | 0..1 0..n        |
                 | uses         | 7.12    | 0..n        |
                 +--------------+---------+-------------+

7.9.3.

7.13.3.  The choice's default output Statement

   The "default" statement indicates if a case should be considered as
   the default if no child nodes from any of the choice's cases exists.
   The argument is the identifier of the "case" statement.  If the
   "default" statement is missing, there is no default case.

   The "default" statement MUST NOT be present on choices where
   "mandatory" "output" statement, which is true.

   The default case optional, is only important when considering the default
   values of nodes under the cases.  The default values for nodes under
   the default case are used if none of the nodes under any of the cases
   are present.

   There MUST NOT be any mandatory nodes (Section 3.1) under the default
   case.

   Default values for child nodes under a case are only used if one of to define output
   parameters to the RPC method.  It does not take an argument.  The
   substatements to "output" defines nodes under that case is present, or if that case is the default
   case. RPC's output node.

   If none of the nodes under a case are present and the case is
   not the default case, the default values of the cases' child nodes
   are ignored.

   In this example, container in the choice defaults to "interval", and output tree has a "presence" statement, the default
   value will
   container need not be used if none of "daily", "time-of-day", or "manual" are
   present. present in a NETCONF RPC reply

   If "daily" is present, a leaf in the output tree has a "mandatory" statement with the default
   value for "time-of-day"
   will "true", the leaf MUST be used.

       container transfer {
           choice how {
               default interval;
               case interval { present in a NETCONF RPC reply.

   If a leaf interval {
                       type uint16; in the output tree has a default 30;
                       units minutes;
                   }
               }
               case daily {
                   leaf daily {
                       type empty;
                   }
                   leaf time-of-day {
                       type string;
                       units 24-hour-clock; value, the NETCONF client
   MUST internally use this default 1am;
                   }
               }
               case manual { if the leaf manual {
                       type empty;
                   }
               }
           }
       }

7.9.4.  The choice's mandatory Statement

   The "mandatory" statement, which is optional, takes as an argument
   the string "true" or "false". not present in a
   NETCONF RPC reply.

   If "mandatory" a "config" statement is "true", at least one present for any node in the output tree,
   it is ignored.

7.13.3.1.  The output's Substatements

                 +--------------+---------+-------------+
                 | substatement | section | cardinality |
                 +--------------+---------+-------------+
                 | anyxml       | 7.10    | 0..n        |
                 | augment      | 7.15    | 0..n        |
                 | choice       | 7.9     | 0..n        |
                 | container    | 7.5     | 0..n        |
                 | grouping     | 7.11    | 0..n        |
                 | leaf         | 7.6     | 0..n        |
                 | leaf-list    | 7.7     | 0..n        |
                 | list         | 7.8     | 0..n        |
                 | typedef      | 7.3     | 0..n        |
                 | uses         | 7.12    | 0..n        |
                 +--------------+---------+-------------+

7.13.4.  XML Encoding Rules

   An rpc node from exactly one of the choice's case branches MUST exist in a
   valid configuration.  If "mandatory" is "false", encoded as a valid
   configuration MAY have no nodes from child XML element to the choice's case branches
   present.

   If not specified, <rpc> element
   defined in [RFC4741].  The element's name is the default rpc's identifier,
   and its XML namespace is "false".

7.9.5. the module's XML Encoding Rules

   The choice and case nodes namespace.

   Input parameters are not visible encoded as child XML elements to the rpc node's
   XML element, in XML.

7.9.6.  NETCONF <edit-config> operations

   Since only one of the choices cases can be valid at any time, same order as they are defined within the
   creation of a node from one case implicitly deletes all nodes from
   all other cases. input
   statement.

   If an <edit-config> operation creates a node, the
   NETCONF server will delete any existing nodes that rpc method invocation succeeded, and no output parameters are
   returned, the <rpc-reply> contains a single <ok/> element defined in
   other cases inside
   [RFC4741].  If output parameters are returned, they are encoded as
   child elements to the choice.

7.9.7. <rpc-reply> element defined in [RFC4741], in
   the same order as they are defined within the output statement.

7.13.5.  Usage Example

   Given the

   The following choice:

     container protocol {
         choice name {
             case a example defines an RPC method:

     module rock {
                 leaf udp
         namespace "http://example.net/rock";
         prefix "rock";

         rpc rock-the-house {
                     type empty;
                 }
             }
             case b
             input {
                 leaf tcp zip-code {
                     type empty; string;
                 }
             }
         }
     }

   A corresponding XML encoding:

     <protocol>
       <tcp/>
     </protocol>

   To change the protocol from tcp to udp:

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
          xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
       <edit-config>
         <target>
           <running/>
         </target>
         <config>
           <system xmlns="http://example.com/schema/config">
             <protocol>
               <udp nc:operation="create"/>
             </protocol>
           </system>
         </config>
       </edit-config> XML encoding of the complete rpc and rpc-reply:

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <rock-the-house xmlns="http://example.net/rock">
         <zip-code>27606-0100</zip-code>
        </rock-the-house>
     </rpc>

7.10.

     <rpc-reply message-id="101"
                xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <ok/>
     </rpc-reply>

7.14.  The anyxml notification Statement

   The "anyxml" "notification" statement defines an interior node in the schema tree. is used to define a NETCONF
   notification.  It takes one argument, which is an identifier,
   followed by a block of substatements that holds detailed anyxml notification
   information.  The anyxml statement is used to represent an unknown chunk of XML.
   No restrictions are placed on notification "statement" defines a notification
   node in the XML.  This can be useful schema tree.

   If a container in e.g.
   RPC replies.  An example is the <filter> parameter notification tree has a "presence" statement,
   the container need not be present in a NETCONF notification.

   If a leaf in the <get-
   config> operation.

   An anyxml node cannot notification tree has a "mandatory" statement with
   the value "true", the leaf MUST be augmented.

   It is NOT RECOMMENDED that present in a NETCONF notification.

   If a leaf in the anyxml notification tree has a default value, the NETCONF
   server MUST internally use this default if the leaf is not present in
   a NETCONF notification.

   If a "config" statement is used to represent
   configuration data.

7.10.1. present for any node in the notification
   tree, it is ignored.

7.14.1.  The anyxml's notification's Substatements

                 +--------------+---------+-------------+
                 | substatement | section | cardinality |
                 +--------------+---------+-------------+
                 | config anyxml       | 7.17.1 7.10    | 0..n        | 0..1
                 | augment      | 7.15    | 0..n        |
                 | choice       | 7.9     | 0..n        |
                 | container    | 7.5     | 0..n        |
                 | description  | 7.17.3 7.19.3  | 0..1        |
                 | mandatory grouping     | 7.6.4 7.11    | 0..n        |
                 | if-feature   | 7.18.2  | 0..n        | 0..1
                 | leaf         | 7.6     | 0..n        |
                 | leaf-list    | 7.7     | 0..n        |
                 | list         | 7.8     | 0..n        |
                 | reference    | 7.17.4 7.19.4  | 0..1        |
                 | status       | 7.19.2  | 0..1        |
                 | status typedef      | 7.3     | 0..n        |
                 | uses         | 7.17.2 7.12    | 0..1 0..n        |
                 +--------------+---------+-------------+

7.10.2.

7.14.2.  XML Encoding Rules

   An anyxml

   A notification node is encoded as an a child XML element. element to the
   <notification> element defined in [RFC5277].  The element's name is
   the anyxml's notification's identifier, and its XML namespace is the module's
   XML namespace.

   The value of the anyxml node is encoded as XML content of
   this element.

   Note that any prefixes used in the encoding notifications's child nodes are local to each
   instance encoding.  This means that the same XML may be encoded
   differently by different implementations.

7.10.3.  NETCONF <edit-config> operations

   An anyxml node is treated as an opaque chunk of data.  This data can
   be modified in its entirety only.

   Any "operation" attributes within the XML value of an anyxml node are
   ignored by the NETCONF server.

   When a NETCONF server processes an <edit-config> request, the
   elements of procedure for the anyxml node are:

      If the operation is "merge", the node is created if it does not
      exist, and its value is set to the XML content of the anyxml node
      found in the XML RPC data.

      If the operation is "replace", the node is created if it does not
      exist, and its value is set to the XML content of the anyxml node
      found in the XML RPC data.

      If the operation is "create" the node is created if it does not
      exist, and its value is set subelements to the
   notification node's XML content of the anyxml node
      found element, in the XML RPC data.

      If the operation is "delete" same order as they are
   defined within the node is deleted if it exists.

7.10.4. notification statement.

7.14.3.  Usage Example

   Given the

   The following example defines a notification:

     module event {

         namespace "http://example.com/event";
         prefix "ev";

         notification event {
             leaf event-class {
                 type string;
             }
             anyxml statement:

     anyxml data;

   The following are two valid encodings reporting-entity;
             leaf severity {
                 type string;
             }
         }
     }

   A corresponding XML encoding of the same anyxml value:

     <data xmlns:if="http://example.com/ns/interface">
       <if:interface>
         <if:ifIndex>1</if:ifIndex>
       </if:interface>
     </data>

     <data>
       <interface xmlns="http://example.com/ns/interface">
         <ifIndex>1</ifIndex>
       </interface>
     </data>

7.11. complete notification:

     <notification
       xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
       <eventTime>2008-07-08T00:01:00Z</eventTime>
       <event xmlns="http://example.com/event">
         <event-class>fault</event-class>
         <reporting-entity>
           <card>Ethernet0</card>
         </reporting-entity>
         <severity>major</severity>
       </event>
     </notification>

7.15.  The grouping augment Statement

   The "grouping" "augment" statement is used to define allows a reusable block of nodes,
   which may be used locally in module or submodule to add to the module,
   schema tree defined in modules which include it,
   and by other modules which import from it.  It takes one another module or submodule.  The argument
   which is an identifier, followed by
   a block of substatements that
   holds detailed grouping information.

   The grouping statement is not string which identifies a data definition statement and, as
   such, does not define any nodes node in the schema tree.

   A grouping  This node is like
   called the augment's target node.  The target node MUST be either a "structure"
   container, list, choice, case, input, output, or a "record" notification node.
   It is augmented with the nodes defined in conventional
   programming languages.

   Once the substatements that
   follow the "augment" statement.

   The argument string is a grouping schema node identifier.  The syntax is defined, it can be referenced
   formally defined by the rule "augment-arg" in a "uses"
   statement (see Section 7.12).  A grouping MUST NOT reference itself,
   neither directly nor indirectly through a chain of other groupings. 12.  If the grouping
   "augment" statement is defined at on the top level of top-level in a YANG module or submodule, the grouping's
   absolute form (defined by the rule "absolute-schema-nodeid" in
   Section 12) of a schema node identifier MUST be unique within used.  If the
   module.  For details about scoping for nested groupings, see
   Section 5.8.

   A grouping
   "augment" statement is more than just in a mechanism "uses" statement, the descendant form
   (defined by the rule "descendant-schema-nodeid" in Section 12) MUST
   be used.

   The syntax for textual substitution,
   but defines a collection schema node identifier is a subset of nodes.  References from inside the
   grouping are XPath
   syntax.  It is an absolute or relative to the scope XPath location path in which the grouping is defined,
   not
   abbreviated syntax, where it is used.  Prefix mappings, type names, grouping names, axes and extension usage predicates are evaluated in not permitted.

   If the hierarchy where target node is a container, list, case, input, output, or
   notification node, the grouping
   statement appears.  For extensions, this means that extensions are
   applied to "container", "leaf", "list", "leaf-list",
   "uses", and "choice" statements can be used within the grouping "augment"
   statement.

   If the target node is a choice node, not the use node.

7.11.1. "case" statement can be used
   within the "augment" statement.

   If the target node is in another module, then nodes added by the
   augmentation MUST NOT be mandatory nodes (see Section 3.1).

7.15.1.  The grouping's augment's Substatements

                 +--------------+---------+-------------+
                 | substatement | section | cardinality |
                 +--------------+---------+-------------+
                 | anyxml       | 7.10    | 0..n        |
                 | augment      | 7.15    | 0..n        |
                 | case         | 7.9.2   | 0..n        |
                 | choice       | 7.9     | 0..n        |
                 | container    | 7.5     | 0..n        |
                 | description  | 7.17.3 7.19.3  | 0..1        |
                 | grouping if-feature   | 7.11 7.18.2  | 0..n        |
                 | leaf         | 7.6     | 0..n        |
                 | leaf-list    | 7.7     | 0..n        |
                 | list         | 7.8     | 0..n        |
                 | reference    | 7.17.4 7.19.4  | 0..1        |
                 | status       | 7.17.2 7.19.2  | 0..1        |
                 | typedef uses         | 7.3 7.12    | 0..n        |
                 | uses when         | 7.12 7.19.5  | 0..n 0..1        |
                 +--------------+---------+-------------+

7.11.2.

7.15.2.  XML Encoding Rules

   All data nodes defined in the "augment" statement are defined as XML
   elements in the XML namespace of the module where the "augment" is
   specified.

   When a node is augmented, the augmented child nodes are encoded after
   all normal child nodes.  If the node is augmented more than once, the
   blocks of augmented child nodes are sorted (in alphanumeric order)
   according to their namespace URI and name of the first child node in
   each block.

7.15.3.  Usage Example

   In namespace http://example.com/schema/interfaces, we have:

     container interfaces {
         list ifEntry {
             key "ifIndex";

             leaf ifIndex {
                 type uint32;
             }
             leaf ifDescr {
                 type string;
             }
             leaf ifType {
                 type iana:IfType;
             }
             leaf ifMtu {
                 type int32;
             }
         }
     }

   Then in namespace http://example.com/schema/ds0, we have:

     import inet-types interface-module {
         prefix "inet"; "if";
     }

     grouping address
     augment "/if:interfaces/if:ifEntry" {
         description "A reusable address group.";
         when "if:ifType='ds0'";
         leaf ip ds0ChannelNumber {
             type inet:ip-address; ChannelNumber;
         }
     }

   A corresponding XML encoding:

     <interfaces xmlns="http://example.com/schema/interfaces"
                 xmlns:ds0="http://example.com/schema/ds0"
       <ifEntry>
         <ifIndex>1</ifIndex>
         <ifDescr>Flintstone Inc Ethernet A562</ifDescr>
         <ifType>ethernetCsmacd</ifType>
         <ifMtu>1500</ifMtu>
       </ifEntry>
       <ifEntry>
         <ifIndex>2</ifIndex>
         <ifDescr>Flintstone Inc DS0</ifDescr>
         <ifType>ds0</ifType>
         <ds0:ds0ChannelNumber>1</ds0:ds0ChannelNumber>
       </ifEntry>
     </interfaces>

   As another example, suppose we have the choice defined in
   Section 7.9.7.  The following construct can be used to extend the
   protocol definition:

     augment /ex:system/ex:protocol/ex:name {
         case c {
             leaf port smtp {
                 type inet:port-number; empty;
             }
         }

7.12.
     }

   A corresponding XML encoding:

     <ex:system>
       <ex:protocol>
         <ex:tcp/>
       </ex:protocol>
     </ex:system>

   or

     <ex:system>
       <ex:protocol>
         <other:smtp/>
       </ex:protocol>
     </ex:system>

7.16.  The uses identity Statement

   The "uses" "identity" statement is used to reference define a "grouping" definition.
   It takes one argument, which new globally unique,
   abstract and untyped identity.  Its only purpose is the name of the grouping.

   The effect of a "uses" reference to a grouping is that the nodes
   defined by the grouping are copied into the current schema tree, denote its
   name, semantics, and
   then updated according to the refinement statements.  Thus, the
   identifiers existence.  An identity can be defined in the grouping are copied into the current
   module's namespace, even if either
   from scratch or derived from a base identity.  The identity's
   argument is an identifier that is the grouping name of the identity.  It is imported from some other
   module.

7.12.1.
   followed by a block of substatements that holds detailed identity
   information.

   The uses's built-in datatype "identityref" (see Section 9.10) can be used to
   reference identities within a data model.

7.16.1.  The identity's Substatements

                 +--------------+---------+-------------+
                 | substatement | section | cardinality |
                 +--------------+---------+-------------+
                 | anyxml       | 7.10    | 0..n        |
                 | choice       | 7.9     | 0..n        |
                 | container base         | 7.5 7.16.2  | 0..n 0..1        |
                 | description  | 7.17.3 7.19.3  | 0..1        |
                 | leaf         | 7.6     | 0..n        |
                 | leaf-list    | 7.7     | 0..n        |
                 | list         | 7.8     | 0..n        |
                 | reference    | 7.17.4 7.19.4  | 0..1        |
                 | status       | 7.17.2 7.19.2  | 0..1        |
                 | uses         | 7.12    | 0..n        |
                 +--------------+---------+-------------+

7.12.2.

7.16.2.  The uses's Refinement Statements

   Some of the properties of each node in the grouping can be refined in
   substatements to "uses".  If a node is not present in a substatement,
   it base Statement

   The base statement, which is not refined, and thus used exactly optional, takes as it was defined in the
   "grouping".  A node can be refined only once in "uses".

   The following refinements can be done:

   o  A leaf or choice node may get a default value, or a new default
      value if it already had one.

   o  Any node may get a specialized "description" string.

   o  Any node may get a specialized "reference" string.

   o  Any node may get a different "config" statement.

   o  A leaf or choice node may get a different "mandatory" statement.

   o  A container node may get a "presence" statement.

   o  A leaf, leaf-list, list or container node may get additional
      "must" expressions.

   o  A leaf-list or list node may get an argument a different "min-elements" or
      "max-elements" statement.

7.12.3.  XML Encoding Rules

   Each node in string
   which is the grouping name of an existing identity, from which the new
   identity is derived.  If no base statement is present, the identity
   is encoded as if it was defined inline,
   even if it from scratch.

   If a prefix is present on the base name, it refers to an identity
   defined in the module which was imported from another with that prefix, or the
   local module if the prefix matches the local module's prefix.
   Otherwise an identity with another XML
   namespace.

7.12.4.  Usage Example

   To use the "address" grouping matching name must be defined in Section 7.11.2 the
   current module or an included submodule.

   Since submodules cannot include the parent module, any identities in
   the module which need to be exposed to submodules must be defined in
   a submodule.  Submodules can then include this submodule to find the
   definition of an HTTP server in some other module, we can do:

     import acme-system the identity.

7.16.3.  Usage Example

     module crypto-base {
         namespace "http://example.com/crypto-base";
         prefix acme;
     }

     container http-server {
         leaf name "crypto";

         identitiy crypto-alg {
             type string;
             description
                "Base identity from which all crypto algorithms
                 are derived.";
             }
         uses acme:address;
         }

   A corresponding XML encoding:

     <http-server>
       <name>extern-web</name>
       <ip>192.0.2.1</ip>
       <port>80</port>
     </http-server>

   If port 80 should be the default for the HTTP server, default can be
   added:

     container http-server {
         leaf name {
             type string;
     }
         uses acme:address

     module des {
             leaf port
         namespace "http://example.com/des";
         prefix "des";

         import "crypto-base" {
                 default 80;
             }
         }
             prefix "crypto";
         }

   If we want to define a list of servers, and each server has the ip
   and port as keys, we can do:

     list server {
         key "ip port";
         leaf name

         identity des {
             type string;
         }
         uses acme:address;
             base "crypto:crypto-alg";
             description "DES crypto algorithm";
         }

   The following is an error:

     container http-server

         identity des3 {
         uses acme:address;
         leaf ip {          // illegal - same identifier "ip" used twice
             type string;
             base "crypto:crypto-alg";
             description "Triple DES crypto algorithm";
         }
     }

7.13.

7.17.  The rpc extension Statement

   The "rpc" "extension" statement is allows the definition of new statements
   within the YANG language.  This new statement definition can be
   imported and used to define a NETCONF RPC method.  It takes
   one argument, which by other modules.

   The statement's argument is an identifier, identifier that is the new keyword for
   the extension and must be followed by a block of substatements that
   holds detailed rpc extension information.  This argument is
   the name  The purpose of the RPC, and extension
   statement is to define a keyword, so that it can be imported and used as
   by other modules.

   The extension can be used like a normal YANG statement, with the element
   statement name directly under
   the <rpc> element, as designated followed by an argument if one is defined by the substitution group
   "rpcOperation" in [RFC4741].

   The "rpc" statement defines
   extension, and an rpc node in optional block of substatements.  The statement's
   name is created by combining the schema tree.  Under the rpc node, an input node with prefix of the name "input", module in which
   the extension was defined, a colon (":"), and an output node
   with the name "output" are also defined. extension's
   keyword, with no interleaving whitespace.  The nodes "input" and
   "output" substatements of an
   extension are defined by the extension, using some mechanism outside
   the scope of this specification.  Syntactically, the substatements
   MUST be core YANG statements, or also defined using "extension"
   statements.  Core YANG statements in extensions MUST follow the module's namespace.

7.13.1.
   syntactical rules in Section 12.

7.17.1.  The rpc's extension's Substatements

                 +--------------+---------+-------------+
                 | substatement | section | cardinality |
                 +--------------+---------+-------------+
                 | description  | 7.17.3  | 0..1        |
                 | grouping     | 7.11    | 0..n        |
                 | input argument     | 7.13.2 7.17.2  | 0..1        |
                 | output description  | 7.13.3 7.19.3  | 0..1        |
                 | reference    | 7.17.4 7.19.4  | 0..1        |
                 | status       | 7.17.2 7.19.2  | 0..1        |
                 | typedef      | 7.3     | 0..n        |
                 +--------------+---------+-------------+

7.13.2.

7.17.2.  The input argument Statement

   The "input" "argument" statement, which is optional, is used to define input
   parameters to the RPC method.  It does not take takes as an argument.  The
   substatements to "input" defines nodes under the RPC's input node.

   If a container in the input tree has a "presence" statement, the
   container need not be present in a NETCONF RPC invocation.

   If argument a leaf in
   string which is the input tree has a "mandatory" statement with name of the
   value "true", argument to the leaf MUST be present in a NETCONF RPC invocation. keyword.  If a leaf in the input tree has a default value, the NETCONF server
   MUST internally use this default if no
   argument statement is present, the leaf keyword expects no argument when
   it is not present in a
   NETCONF RPC invocation.

   If a "config" or "must" statement used.

   The argument's name is present for any node used in the
   input tree, YIN mapping, where it is ignored.

7.13.2.1. used as
   an XML attribute or element name, depending on the argument's text
   statement.

7.17.2.1.  The input's argument's Substatements

                 +--------------+---------+-------------+

                 +--------------+----------+-------------+
                 | substatement | section  | cardinality |
                 +--------------+---------+-------------+
                 | anyxml       | 7.10    | 0..n        |
                 | augment      | 7.15    | 0..n        |
                 | choice
                 +--------------+----------+-------------+
                 | 7.9 yin-element  | 0..n 7.17.2.2 | 0..1        |
                 +--------------+----------+-------------+

7.17.2.2.  The yin-element Statement

   The "yin-element" statement, which is optional, takes as an argument
   the string "true" or "false".  This statement indicates if the
   argument should be mapped to an XML element in YIN or to an XML
   attribute. (see Section 11).

   If no "yin-element" statement is present, it defaults to "false".

7.17.3.  Usage Example

   To define an extension:

     module my-extensions {
       ...

       extension c-define {
         description
           "Takes as argument a name string.
           Makes the code generator use the given name in the
           #define.";
         argument "name";
       }
     }

   To use the extension:

     module my-interfaces {
       ...
       import my-extensions {
         prefix "myext";
       }
       ...

       container    | 7.5     | 0..n        |
                 | grouping     | 7.11    | 0..n        |
                 | leaf         | 7.6     | 0..n        |
                 | leaf-list    | 7.7     | 0..n        |
                 | list         | 7.8     | 0..n        |
                 | typedef      | 7.3     | 0..n        |
                 | uses         | 7.12    | 0..n        |
                 +--------------+---------+-------------+

7.13.3. interfaces {
         ...
         myext:c-define "MY_INTERFACES";
       }
     }

7.18.  Conformance-related Statements

   This section defines statements related to conformance, as described
   in Section 5.9.

7.18.1.  The output feature Statement

   The "output" statement, which is optional, "feature" statement is used to define output
   parameters to a mechanism by which
   portions of the RPC method.  It does not take an argument.  The
   substatements to "output" defines nodes under schema are marked as conditional.  A feature name is
   defined that can later be referenced using the RPC's output node.

   If "if-feature" statement
   (see Section 7.18.2).  Schema nodes tagged with a container in feature are ignored
   unless the output tree has a "presence" statement, device supports the
   container need not given feature.  This allows portions
   of the YANG module to be present in a NETCONF RPC reply

   If a leaf in conditional based on conditions on the output tree has
   device.  The model can represent the abilities of the device within
   the model, giving a "mandatory" richer model that allows for differing device
   abilities and roles.

   The argument to the "feature" statement with is the
   value "true", name of the leaf MUST be present new
   feature, and follows the rules for identifiers in Section 6.2.  This
   name is used by the "if-feature" statement to tie the schema nodes to
   the feature.

   In this example, a NETCONF RPC reply.

   If feature called "local-storage" represents the
   ability for a device to store syslog messages on local storage of
   some sort.  This feature is used to make the "local-storage-limit"
   leaf in conditional on the output tree has a default value, presence of some sort of local-storage.  If
   the NETCONF client
   MUST internally use device does not report that it supports this default if feature, the leaf local-
   storage-limit node is not present in a
   NETCONF RPC reply.

   If a "config" supported.

     module my-syslog {
         ...
         feature local-storage {
             description "This feature means the device supports local
                 storage (memory, flash or "must" disk) that can be used to
                 store syslog messages.";
         }

         container syslog {
             leaf local-storage-limit {
                 if-feature local-storage;
                 config false;
                 description "The amount of local storage that can be
                     used to hold syslog messages.";
             }
         }
     }

   The "if-feature" statement is present for any node can be used in many places within the
   output tree, it is ignored.

7.13.3.1. YANG
   syntax.  Definitions tagged with "if-feature" are ignored when the
   device does not support that feature.

7.18.1.1.  The output's feature's Substatements

                 +--------------+---------+-------------+
                 | substatement | section | cardinality |
                 +--------------+---------+-------------+
                 | anyxml       | 7.10    | 0..n        |
                 | augment      | 7.15    | 0..n        |
                 | choice       | 7.9     | 0..n        |
                 | container    | 7.5     | 0..n        |
                 | grouping     | 7.11    | 0..n        |
                 | leaf         | 7.6     | 0..n        |
                 | leaf-list description  | 7.7 7.19.3  | 0..n 0..1        |
                 | list if-feature   | 7.8 7.18.2  | 0..n        |
                 | typedef status       | 7.3 7.19.2  | 0..n 0..1        |
                 | uses reference    | 7.12 7.19.4  | 0..n 0..1        |
                 +--------------+---------+-------------+

7.13.4.  XML Encoding Rules

   An rpc node

7.18.2.  The if-feature Statement

   The "if-feature" statement is encoded used to mark portions of the model as
   conditional.  The argument is the name of a feature, as defined by a child XML element
   "feature" statement.  If a prefix is present on the feature name, it
   refers to a feature defined the module which was imported with that
   prefix, or the local module if the prefix matches the local module's
   prefix.  Otherwise a feature with the <rpc> element matching name must be defined
   in [RFC4741]. the current module or an included submodule.

   Since submodules cannot include the parent module, any features in
   the module which need to be exposed to submodules must be defined in
   a submodule.  Submodules can then include this submodule to find the
   definition of the feature.

7.18.3.  The element's name deviation Statement

   The deviation statement defines a hierarchy of the module which the
   device does not implement faithfully.  The argument is a string that
   identifies the rpc's identifier,
   and its XML namespace node in the schema tree where a deviation from the
   module occurs.  This node is called the module's XML namespace.

   Input parameters are encoded as child XML elements to deviation's target node.  The
   contents of the rpc node's
   XML element, deviation statement give details about the deviation.

   The argument's syntax is formally defined by the rule "deviation-arg"
   in Section 12.

   Deviations define the same order as way a device or class of devices deviate from
   the standard.  This means that deviations MUST never be part of a
   published standard, since they are defined within the input
   statement.

   If mechanism for learning how
   implementations vary from the rpc method invocation succeeded, and no output parameters standards.

   Device deviations are
   returned, strongly discouraged and should only be used as
   a last resort.  Telling the <rpc-reply> contains application how a single <ok/> element defined device fails to follow
   the standard is no substitute for implementing the standard directly.

   However in
   [RFC4741].  If output parameters are returned, they are encoded some cases the cost of following the standard is heavy and
   the payoff may be small.  A particular device may not have the
   hardware or software ability to support parts of a standard module.
   When this occurs, the device makes a choice to treat attempts to
   configure unsupported parts of the module as
   child elements either an error that is
   reported back to the <rpc-reply> element defined in [RFC4741], in unsuspecting application, or ignore that
   incoming requests.  Neither choice is acceptable.

   Instead, YANG allows devices to document portions of the same order as they base module
   which are defined within not supported or supported but with different syntax, by
   using the output "deviation" statement.

7.13.5.  Usage Example

7.18.3.1.  The following example defines an RPC method:

     module rock {
         namespace "http://example.net/rock";
         prefix rock;

         rpc rock-the-house {
             input {
                 leaf zip-code {
                     type string;
                 }
             }
         }
     }

   A corresponding XML encoding of the complete rpc and rpc-reply:

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <rock-the-house xmlns="http://example.net/rock">
         <zip-code>27606-0100</zip-code>
        </rock-the-house>
     </rpc>

     <rpc-reply message-id="101"
                xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <ok/>
     </rpc-reply>

7.14. deviation's Substatements

                 +--------------+----------+-------------+
                 | substatement | section  | cardinality |
                 +--------------+----------+-------------+
                 | description  | 7.19.3   | 0..1        |
                 | deviate      | 7.18.3.2 | 0..n        |
                 | reference    | 7.19.4   | 0..1        |
                 +--------------+----------+-------------+

7.18.3.2.  The notification deviate Statement

   The "notification" "deviate" statement defines how the device's implementation of
   the target node deviates from its original definition.  The argument
   is used to define a NETCONF
   notification.  It takes one argument, which is an identifier,
   followed by a block of substatements the strings "not-supported", "add", "replace", or "delete".

   The argument "not-supported" indicates that holds detailed notification
   information. the target node is not
   implemented by this device.

   The notification "statement" defines argument "add" adds properties to the target node.  The
   properties to add are identified as a notification
   node in substatement to the schema tree. "deviate"
   statement.  If a container in the notification tree has a "presence" statement, property can only appear once, the container need not be present in a NETCONF notification.

   If a leaf property MUST
   NOT exist in the notification tree has a "mandatory" statement with target node.

   The argument "replace" replaces properties of the value "true", target node.  The
   properties to replace are identified by substatements to the leaf
   "deviate" statement.  The property to replace MUST be present exist in the
   target node.

   The argument "delete" deletes properties from the target node.  The
   properties to delete are identified by substatement to "delete".  The
   substatement's keyword MUST match a NETCONF notification.

   If a leaf corresponding keyword in the notification tree has a default value,
   target node, and the NETCONF
   server argument's string MUST internally use this default if be equal to the leaf is not present in
   a NETCONF notification.

   If a "config" or "must" statement is present for any node
   corresponding keyword's argument string in the
   notification tree, it is ignored.

7.14.1. target node.

                       The notification's deviates's Substatements

                 +--------------+---------+-------------+
                 | substatement | section | cardinality |
                 +--------------+---------+-------------+
                 | anyxml       | 7.10    | 0..n        |
                 | augment      | 7.15    | 0..n        |
                 | choice       | 7.9     | 0..n        |
                 | container config       | 7.5 7.19.1  | 0..n 0..1        |
                 | description default      | 7.17.3 7.6.3   | 0..1        |
                 | grouping mandatory    | 7.11 7.6.4   | 0..n 0..1        |
                 | leaf max-elements | 7.6 7.7.3   | 0..n 0..1        |
                 | leaf-list min-elements | 7.7 7.7.2   | 0..n 0..1        |
                 | list must         | 7.8 7.5.2   | 0..n        |
                 | reference    | 7.17.4  | 0..1        |
                 | status type         | 7.17.2 7.4     | 0..1        |
                 | typedef unique       | 7.3 7.8.3   | 0..n        |
                 | uses units        | 7.12 7.3.3   | 0..n 0..1        |
                 +--------------+---------+-------------+

7.14.2.  XML Encoding Rules

   A notification node is encoded as a child XML element to the
   <notification> element defined in [RFC5277].  The element's name is

7.18.3.3.  Usage Example

   In this example, the notification's identifier, and its XML namespace device is informing client applications that it
   does not support the module's
   XML namespace.

   The notifications's child nodes are encoded as subelements to the
   notification node's XML element, in the same order as they are
   defined within the notification statement.

7.14.3.  Usage Example old RFC867-style "daytime" service.

     deviation /base:system/base:daytime {
         deviate not-supported;
     }

   The following example defines sets a notification:

     module event device-specific default value to a leaf
   that does not have a default value defined:

     deviation /base:system/base:user/base:type {

         namespace "http://example.com/event";
         prefix ev;

         notification event
         deviate add {
             leaf event-class
             default "admin"; // new users are 'admin' by default
         }
     }

   In this example, the device limits the number of name servers to 3:

     deviation /base:system/base:name-server {
                 type string;
         deviate replace {
             max-elements 3;
         }
             anyxml reporting-entity;
             leaf severity
     }

   If the original definition is:

     container system {
                 type string;
         must "daytime or time";
         ...
     }
   a device might remove this must constraint by doing:

     deviation "/base:system" {
         deviate delete {
             must "daytime or time";
         }
     }

   A corresponding XML encoding of the complete notification:

     <notification
       xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
       <eventTime>2008-07-08T00:01:00Z</eventTime>
       <event xmlns="http://example.com/event">
         <event-class>fault</event-class>
         <reporting-entity>
           <card>Ethernet0</card>
         </reporting-entity>
         <severity>major</severity>
       </event>
     </notification>

7.15.

7.19.  Common Statements

   This section defines sub-statements common to several other
   statements.

7.19.1.  The augment config Statement

   The "augment" "config" statement allows a module or submodule to add to the
   schema tree defined in another module or submodule.  The takes as an argument is
   a string which identifies a node in the schema tree.  This node is
   called the augment's target node.  The target node MUST be either a
   container, list, choice, case, input, output, or notification node.
   It is augmented with the nodes defined in the substatements that
   follow the "augment" statement.

   The augment string is a schema node identifier.  The syntax is
   formally defined by the rule "augment-arg" in Section 11. "true" or
   "false".  If the
   "augment" statement "config" is on the top-level in a module or submodule, the
   absolute form (defined by "true", the rule "absolute-schema-nodeid" in
   Section 11) definition represents
   configuration, and will be part of the reply to a schema node identifier MAY <get-config>
   request, and may be used.  Otherwise, the
   descendant form (defined by the rule "descendant-schema-nodeid" sent in
   Section 11) MUST be used.

   The syntax for a schema node identifier <copy-config> or <edit-config> request.
   If "config" is a subset "false", it represents state data, and will be part of
   the XPath
   syntax.  It is an absolute or relative XPath location path in
   abbreviated syntax, where axes and predicates are reply to a <get>, but not permitted. to a <get-config> request.

   If "config" is not specified, the target node default is a container, list, case, input, output, or
   notification node, the "container", "leaf", "list", "leaf-list",
   "uses", and "choice" statements can be used within same as the "augment"
   statement. parent
   node's (in the data model) "config" value.  If the target top node is does not
   specify a choice node, "config" statement, the "case" statement default is "true".

   If a node has "config" "false", no node underneath it can be used
   within have
   "config" set to "true".

7.19.2.  The status Statement

   The "status" statement takes as an argument one of the "augment" statement.

   If strings
   "current", "deprecated", or "obsolete".

   o  "current" means that the target node definition is current and valid.

   o  "deprecated" indicates an obsolete definition, but it permits new/
      continued implementation in another module, then nodes added by order to foster interoperability with
      older/existing implementations.

   o  "obsolete" means the
   augmentation MUST NOT definition is obsolete and should not be mandatory nodes (see Section 3.1).

7.15.1.  The augment's Substatements

                 +--------------+---------+-------------+
                 | substatement | section | cardinality |
                 +--------------+---------+-------------+
                 | anyxml       | 7.10    | 0..n        |
                 | augment      | 7.15    | 0..n        |
                 | case         | 7.9.2   | 0..n        |
                 | choice       | 7.9     | 0..n        |
                 | container    | 7.5     | 0..n        |
                 |
      implemented and/or can be removed if previously implemented.

   If no status is specified, the default is "current".

   If a definition is "current", it MUST NOT reference a "deprecated" or
   "obsolete" definition within the same module.

   If a definition is "deprecated", it MUST NOT reference an "obsolete"
   definition within the same module.

7.19.3.  The description  | 7.17.3  | 0..1        |
                 | leaf         | 7.6     | 0..n        |
                 | leaf-list    | 7.7     | 0..n        |
                 | list         | 7.8     | 0..n        |
                 | Statement

   The "description" statement takes as an argument a string which
   contains a high-level textual description of this definition.

7.19.4.  The reference    | 7.17.4  | 0..1        |
                 | status       | 7.17.2  | 0..1        |
                 | uses         | 7.12    | 0..n        |
                 | when         | 7.15.2  | 0..1        |
                 +--------------+---------+-------------+

7.15.2. Statement

   The "reference" statement takes as an argument a string which is used
   to specify a textual cross-reference to an external document, either
   another module which defines related management information, or a
   document which provides additional information relevant to this
   definition.

7.19.5.  The when Statement

   The "when" statement allows the augmentation a data definition statement to be
   conditional, with the nodes node(s) defined by the data defined statement
   only being valid when a specific criteria is satisfied.  The
   statement's argument is an XPath expression, which is used to
   formally specify constraints on which instances in the data tree will
   be augmented by this statement. criteria.  If the XPath expression conceptually
   evaluates to "true" for a particular instance, then it is augmented, the nodes defined
   by the data definition statement are valid, otherwise it is they are not.

   The XPath expression is conceptually evaluated in the following
   context:

   o  The  If the "when" statement is a child of an "augment" statement, then
      the context node is the augment's target node in the data tree, if
      the target node is a data node.  Otherwise, the context node is
      the closest ancestor node to the target node which is also a data
      node.
      node.

   o  If the "when" statement is a child of a "choice" or "case"
      statement, then the context node is the closest ancestor node to
      the "choice" or "case" node which is also a data node.

   o  If the "when" statement is a child of any other data definition
      statement, teh context node is the data definition's node in the
      data tree.

   o  The accessible tree is made up of all nodes in the data tree, and
      all leafs with default values.

   o  The set of namespace declarations is the set of all "import"
      statements' prefix and namespace pairs, and the "prefix"
      statement's prefix for the "namespace" statement's URI.

   o  Elements without a namespace refer to nodes in the current module.

   o  The function library is the core function library defined in
      [XPATH], and a function "current()" which returns a node set with
      the initial context node.

   The result of the XPath expression is converted to the XPath expression is converted to a boolean value
   using the standard XPath rules.

   Note that the XPath expression is conceptually evaluated.  This means
   that an implementation does not have to use an XPath evaluator on the
   device.  The augment can very well be implemented with specially
   written code.

8.  Constraints

   Several YANG statements define constraints on valid data.  These
   constraints are enforced at different times, depending on what type
   of data the statement defines.

   If the constraint is defined on configuration data, it MUST be true
   in a valid configuration data tree.

   If the constraint is defined on state data, it MUST be true in a
   reply to the <get> command.

   If the constraint is defined on notification content, it MUST be true
   in any notification instance.

   If the constraint is defined on RPC input parameters, it MUST be true
   in an invocation of the RPC method.

   If the constraint is defined on RPC output parameters, it MUST be
   true in the RPC reply.

9.  Built-in Types

   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.

   Additional types may be defined, derived from those built-in types or
   from other derived types.  Derived types may use subtyping to
   formally restrict the set of possible values.

   The different built-in types and their derived types allow different
   kinds of subtyping, namely length and regular expression restrictions
   of strings (Section 9.4.4, Section 9.4.6) and range restrictions of
   numeric types (Section 9.2.4).

   The lexicographic representation of a boolean value
   using the standard XPath rules.

   Note that the XPath expression of a certain type is conceptually evaluated.  This means
   that an implementation does not have to use an XPath evaluator on the
   device.  The augment can very well be implemented with specially
   written code.

7.15.3.  XML Encoding Rules

   All data nodes defined used
   in the "augment" statement are defined as XML
   elements encoding over NETCONF, and when specifying default values
   in the XML namespace of the module where the "augment" is
   specified.

   When a node YANG module.

9.1.  Canonical representation

   For each type, there is augmented, a single canonical representation of the augmented child nodes are encoded after
   all normal child nodes.  If
   type's values.  Some types allow multiple lexicographic
   representations of the node is augmented more than once, same value, for example the
   blocks of augmented child nodes positive integer
   "17" can be represented as "+17" or "17".

9.2.  The Integer Built-in Types

   The integer built-in types are sorted (in alphanumeric order)
   according to their namespace URI int8, int16, int32, int64, uint8,
   uint16, uint32, and name uint64.  They represent signed and unsigned
   integers of different sizes:

   int8  represents integer values between -128 and 127, inclusively.

   int16  represents integer values between -32768 and 32767,
      inclusively.

   int32  represents integer values between -2147483648 and 2147483647,
      inclusively.

   int64  represents integer values between -9223372036854775808 and
      9223372036854775807, inclusively.

   uint8  represents integer values between 0 and 255, inclusively.

   uint16  represents integer values between 0 and 65535, inclusively.

   uint32  represents integer values between 0 and 4294967295,
      inclusively.

   uint64  represents integer values between 0 and 18446744073709551615,
      inclusively.

9.2.1.  Lexicographic Representation

   An integer value is lexicographically represented as an optional sign
   ("+" or "-"), followed by a sequence of the first child node in
   each block.

7.15.4.  Usage Example

   In namespace http://example.com/schema/interfaces, we have:

     container interfaces {
         list ifEntry {
             key "ifIndex";

             leaf ifIndex {
                 type uint32;
             }
             leaf ifDescr {
                 type string;
             }
             leaf ifType {
                 type iana:IfType;
             }
             leaf ifMtu {
                 type int32;
             }
         }
     }

   Then in namespace http://example.com/schema/ds0, we have:

     import interface-module {
         prefix if;
     }
     augment "/if:interfaces/if:ifEntry" { decimal digits.  If no sign
   is specified, "+" is assumed.

   For convenience, when "if:ifType='ds0'";
         leaf ds0ChannelNumber {
             type ChannelNumber;
         }
     }

   A corresponding XML encoding:

     <interfaces xmlns="http://example.com/schema/interfaces"
                 xmlns:ds0="http://example.com/schema/ds0"
       <ifEntry>
         <ifIndex>1</ifIndex>
         <ifDescr>Flintstone Inc Ethernet A562</ifDescr>
         <ifType>ethernetCsmacd</ifType>
         <ifMtu>1500</ifMtu>
       </ifEntry>
       <ifEntry>
         <ifIndex>2</ifIndex>
         <ifDescr>Flintstone Inc DS0</ifDescr>
         <ifType>ds0</ifType>
         <ds0:ds0ChannelNumber>1</ds0:ds0ChannelNumber>
       </ifEntry>
     </interfaces>
   As another example, suppose we have the choice defined specifying a default value for an integer in
   Section 7.9.7.  The following construct a
   YANG module, an alternative lexicographic representation can be used to extend used,
   which represents the
   protocol definition:

     augment /ex:system/ex:protocol/ex:name {
         case c {
             leaf smtp {
                 type empty;
             }
         }
     }

   A corresponding XML encoding:

     <ex:system>
       <ex:protocol>
         <ex:tcp/>
       </ex:protocol>
     </ex:system> value in a hexadecimal or

     <ex:system>
       <ex:protocol>
         <other:smtp/>
       </ex:protocol>
     </ex:system>

7.16. octal notation.  The extension Statement
   hexadecimal notation consists of an optional sign ("+" or "-"), the
   characters "0x" followed a number of hexadecimal digits, where
   letters may be upper- or lowercase.  The octal notation consists of
   an optional sign ("+" or "-"), the character "0" followed a number of
   octal digits.

   Examples:

     // legal values
     +4711                       // legal positive value
     4711                        // legal positive value
     -123                        // legal negative value
     0xf00f                      // legal positive hexadecimal value
     -0xf                        // legal negative hexadecimal value
     052                         // legal positive octal value

     // illegal values
     - 1                         // illegal intermediate space

9.2.2.  Canonical Form

   The "extension" statement allows the definition canonical form of new statements
   within a positive integer does not include the YANG language.  This new statement definition sign
   "+".

9.2.3.  Restrictions

   All integer types can be
   imported and used by other modules. restricted with the "range" statement
   (Section 9.2.4).

9.2.4.  The statement's argument range Statement

   The "range" statement, which is an identifier that is the new keyword for optional substatement to the extension and must be followed by
   "type" statement, takes as an argument a block of substatements that
   holds detailed extension information.  The purpose of the extension
   statement range expression string.  It
   is used to define restrict integer and floating point built-in types, or
   types derived from those.

   A range consists of an explicit value, or a keyword, so that it lower inclusive bound,
   two consecutive dots "..", and an upper inclusive bound.  Multiple
   values or ranges can be imported and used given, separated by other modules.

   The extension can "|".  If multiple values
   or ranges are given they all MUST be used like disjoint and MUST be in
   ascending order.  If a normal YANG statement, with the
   statement name followed by an argument if one value restriction is defined by the
   extension, and applied to an optional block of substatements.  The statement's
   name already
   restricted type, the new restriction MUST be equal or more limiting,
   that is created by combining raising the lower bounds, reducing the upper bounds, removing
   explicit values or ranges, or splitting ranges into multiple ranges
   with intermediate gaps.  Each explicit value and range boundary value
   given in the range expression MUST match the prefix type being restricted,
   or be one of the module in which special values "min" or "max". "min" and "max" means
   the extension was defined, a colon (":"), minimum and maximum value accepted for the extension's
   keyword, with no interleaving whitespace. type being restricted,
   respectively.

   The substatements of an
   extension are range expression syntax is formally defined by the extension, using some mechanism outside
   the scope of this specification.  Syntactically, the substatements
   MUST be core YANG statements, or also defined using "extension"
   statements.  Core YANG statements in extensions MUST follow the
   syntactical rules rule "range-
   arg" in Section 11.

7.16.1. 12.

9.2.4.1.  The extension's range's Substatements

                 +--------------+---------+-------------+

                 +---------------+---------+-------------+
                 | substatement  | section | cardinality |
                 +--------------+---------+-------------+
                 | argument     | 7.16.2  | 0..1        |
                 +---------------+---------+-------------+
                 | description   | 7.17.3 7.19.3  | 0..1        |
                 | reference error-app-tag | 7.17.4 7.5.3.2 | 0..1        |
                 | status error-message | 7.17.2 7.5.3.1 | 0..1        |
                 +--------------+---------+-------------+

7.16.2.  The argument Statement

   The "argument" statement, which is optional, takes as an argument a
   string which is the name of the argument to the keyword.  If no
   argument statement is present, the keyword expects no argument when
   it is used.

   The argument's name is used in the YIN mapping, where it is used as
   an XML attribute or element name, depending on the argument's text
   statement.

7.16.2.1.  The argument's Substatements

                 +--------------+----------+-------------+
                 | substatement | section  | cardinality |
                 +--------------+----------+-------------+
                 | yin-element reference     | 7.16.2.2 7.19.4  | 0..1        |
                 +--------------+----------+-------------+

7.16.2.2.  The yin-element Statement

   The "yin-element" statement, which is optional, takes as an argument
   the string "true" or "false".  This statement indicates if the
   argument should be mapped to an XML element in YIN or to an XML
   attribute. (see Section 10).

   If no "yin-element" statement is present, it defaults to "false".

7.16.3.
                 +---------------+---------+-------------+

9.2.5.  Usage Example

   To define an extension:

     module my-extensions

     typedef my-base-int32-type {
       ...

       extension c-define
         type int32 {
         description
           "Takes as argument a name string.
           Makes the code generator use the given name in the
           #define.";
         argument "name";
             range "1..4 | 10..20";
         }
     }

   To use the extension:

     module my-interfaces {
       ...
       import my-extensions

     type my-base-int32-type {
         prefix "myext";
         // legal range restriction
         range "11..max"; // 11..20
     }
       ...

       container interfaces

     type my-base-int32-type {
         ...
         myext:c-define "MY_INTERFACES";
       }
         // illegal range restriction
         range "11..100";
     }

7.17.  Common Statements

   This section defines sub-statements common to several other
   statements.

7.17.1.

9.3.  The config Statement Floating Point Built-in Types

   The "config" statement takes as an argument the string "true" or
   "false".  If "config" is "true", the definition represents
   configuration, floating point built-in types are float32 and will be part float64.  They
   represent floating point values of the reply to a <get-config>
   request, single and may be sent double precision as
   defined in a <copy-config> or <edit-config> request.
   If "config" is "false", it represents state data, [IEEE.754].  Special values are positive and will be part of
   the reply to a <get>, but not to a <get-config> request.

   If "config" is not specified, the default negative
   infinity, and not-a-number.

9.3.1.  Lexicographic Representation

   A floating point value is the same lexicographically represented as consisting
   of a decimal mantissa followed, optionally, by the parent
   node's (in the data model) "config" value.  If the top node does not
   specify character "E" or
   "e", followed by an integer exponent.  The special values positive
   and negative infinity and not-a-number have lexical representations
   INF, -INF and NaN, respectively.  The minimal value accepted for a "config" statement,
   float is -INF, and the default is "true".

   If maximal value accepted for a node has "config" "false", no node underneath it float is INF.

9.3.2.  Canonical Form

   [Editor's Note: TBD]

9.3.3.  Restrictions

   All floating point types can have
   "config" set be restricted with the "range" statement
   (Section 9.2.4).

9.3.4.  Usage Example

     type float32 {
         range "1..4.5 | 10 | 20..INF";
     }

    is equivalent to "true".

7.17.2.

     type float32 {
         range "1..4.5 | 10 | 20..max";
     }

9.4.  The status Statement string Built-in Type

   The "status" statement takes as an argument one of the string built-in type represents human readable strings
   "current", "deprecated", or "obsolete".

   o  "current" means that the definition is current and valid.

   o  "deprecated" indicates an obsolete definition, but it permits new/
      continued implementation in order to foster interoperability with
      older/existing implementations.

   o  "obsolete" means YANG.
   Legal characters are tab, carriage return, line feed, and the definition is obsolete legal
   characters of Unicode and should not be
      implemented and/or can be removed if previously implemented.

   If no status is specified, ISO/IEC 10646 [ISO.10646]:

     // any Unicode character, excluding the default is "current".

   If a definition surrogate blocks,
     // FFFE, and FFFF.
     string = *char
     char = %x9 / %xA / %xD / %x20-DFFF / %xE000-FFFD /
            %x10000-10FFFF

9.4.1.  Lexicographic Representation

   A string value is "current", it MUST NOT reference a "deprecated" or
   "obsolete" definition within lexicographically represented as character data in
   the same module.

   If a definition XML encoding.

9.4.2.  Canonical Form

   The canonical form is "deprecated", it MUST NOT reference an "obsolete"
   definition within the same module.

7.17.3.  The description Statement

   The "description" statement takes as an argument a string which
   contains a high-level textual description of this definition.

7.17.4. the lexicographical representation.
   No Unicode normalization is performed of string values.

9.4.3.  Restrictions

   A string can be restricted with the "length" (Section 9.4.4) and
   "pattern" (Section 9.4.6) statements.

9.4.4.  The reference length Statement

   The "reference" statement "length" statement, which is an optional substatement to the
   "type" statement, takes as an argument a string which length expression string.
   It is used to specify a textual cross-reference to an external document, either
   another module which defines related management information, or a
   document which provides additional information relevant to this
   definition.

8.  Built-in Types

   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.

   Additional types may be defined, derived from those built-in types or
   from other derived types.  Derived types may use subtyping to
   formally restrict the set of possible values.

   The different built-in type "string", or types and their derived types allow different
   kinds
   from "string".

   A "length" statement restricts the number of subtyping, namely characters in the
   string.

   A length and regular expression restrictions
   of strings (Section 8.3.3, Section 8.3.5) and range restrictions of
   numeric types (Section 8.1.3).

   The lexicographic representation of a value consists of an explicit value, or a certain type is used
   in the XML encoding over NETCONF, and when specifying default values
   in a YANG module.

8.1.  The Integer Built-in Types

   The integer built-in types are int8, int16, int32, int64, uint8,
   uint16, uint32, and uint64.  They represent signed and unsigned
   integers of different sizes:

   int8  represents integer values between -128 and 127, inclusively.

   int16  represents integer values between -32768 and 32767,
      inclusively.

   int32  represents integer values between -2147483648 lower bound, two
   consecutive dots "..", and 2147483647,
      inclusively.

   int64  represents integer an upper bound.  Multiple values between -9223372036854775808 and
      9223372036854775807, inclusively.

   uint8  represents integer or ranges
   can be given, separated by "|".  Length restricting values between 0 and 255, inclusively.

   uint16  represents integer MUST NOT
   be negative.  If multiple values between 0 or ranges are given, they all MUST
   be disjoint and 65535, inclusively.

   uint32  represents integer MUST be in ascending order.  If a length restriction
   is applied to an already length restricted type, the new restriction
   MUST be equal or more limiting, that is, raising the lower bounds,
   reducing the upper bounds, removing explicit length values between 0 and 4294967295,
      inclusively.

   uint64  represents integer or ranges,
   or splitting ranges into multiple ranges with intermediate gaps.  A
   length value is a non-negative integer, or one of the special values between 0
   "min" or "max". "min" and 18446744073709551615,
      inclusively.

8.1.1.  Lexicographic Representation "max" means the minimum and maximum length
   accepted for the type being restricted, respectively.  An integer
   implementation is not required to support a length value larger than
   18446744073709551615.

   The length expression syntax is formally defined by the rule "length-
   arg" in Section 12.

9.4.4.1.  The length's Substatements

                 +---------------+---------+-------------+
                 | substatement  | section | cardinality |
                 +---------------+---------+-------------+
                 | description   | 7.19.3  | 0..1        |
                 | error-app-tag | 7.5.3.2 | 0..1        |
                 | error-message | 7.5.3.1 | 0..1        |
                 | reference     | 7.19.4  | 0..1        |
                 +---------------+---------+-------------+

9.4.5.  Usage Example

     typedef my-base-str-type {
         type string {
             length "1..255";
         }
     }

     type my-base-str-type {
         // legal length refinement
         length "11 | 42..max"; // 11 | 42..255
     }

     type my-base-str-type {
         // illegal length refinement
         length "1..999";
     }

9.4.6.  The pattern Statement

   The "pattern" statement, which is lexicographically represented as an optional sign
   ("+" or "-"), followed by a sequence of decimal digits.  If no sign
   is specified, "+" is assumed.

   For convenience, when specifying a default value for substatement to the
   "type" statement, takes as an integer in argument a
   YANG module, an alternative lexicographic representation can be used,
   which represents the value regular expression string,
   as defined in a hexadecimal or octal notation.  The
   hexadecimal notation consists of an optional sign ("+" or "-"), [XSD-TYPES].  It is used to restrict the
   characters "0x" followed a number of hexadecimal digits, where
   letters may be upper- built-in type
   "string", or lowercase. types derived from "string", to values that completely
   matches the pattern.

   If the type has multiple "pattern" statements, the expressions are
   AND:ed together, i.e. all such expressions have to match.

9.4.6.1.  The octal notation consists of
   an optional sign ("+" or "-"), pattern's Substatements

                 +---------------+---------+-------------+
                 | substatement  | section | cardinality |
                 +---------------+---------+-------------+
                 | description   | 7.19.3  | 0..1        |
                 | error-app-tag | 7.5.3.2 | 0..1        |
                 | error-message | 7.5.3.1 | 0..1        |
                 | reference     | 7.19.4  | 0..1        |
                 +---------------+---------+-------------+

9.4.7.  Usage Example

   With the character "0" followed a number of
   octal digits.

   Examples:

     // legal values
     +4711                       // legal positive value
     4711                        // legal positive value
     -123 following type:

     type string {
         length "0..4";
         pattern "[0-9a-fA-F]*";
     }

   the following strings match:

     AB          // legal negative value
     0xf00f
     9A00        // legal positive hexadecimal value
     -0xf

   and the following strings do not match:

     00ABAB      // legal negative hexadecimal value
     052 illegal
     xx00        // legal positive octal illegal

9.5.  The boolean Built-in Type

   The boolean built-in type represents a boolean value.

9.5.1.  Lexicographic Representation

   The lexicographical representation of a boolean value

     // illegal values
     - 1                         // illegal intermediate space

8.1.2. is the strings
   "true" and "false".

9.5.2.  Restrictions

   All integer types can

   A boolean cannot be restricted with restricted.

9.6.  The enumeration Built-in Type

   The enumeration built-in type represents values from a set of
   assigned names.

9.6.1.  Lexicographic Representation

   The lexicographical representation of an enumeration value is the "range" statement
   (Section 8.1.3).

8.1.3.
   assigned name string.

9.6.2.  Canonical Form

   The range canonical form is the assigned name string.

9.6.3.  Restrictions

   An enumeration cannot be restricted.

9.6.4.  The enum Statement

   The "range" "enum" statement, which is an optional a substatement to the "type"
   statement, MUST be present if the type is "enumeration".  It is
   repeatedly used to specify each assigned name of an enumeration type.
   It takes as an argument a range expression string.  It string which is used to restrict integer the assigned name.  The
   string MUST NOT be empty and floating point built-in types, MUST NOT have any leading or
   types derived from those.

   A range consists trailing
   whitespace characters.  The use of an explicit value, or control codes SHOULD be avoided.

   The statement is optionally followed by a lower inclusive bound,
   two consecutive dots "..", and block of substatements
   which holds detailed enum information.

   All assigned names in an upper inclusive bound.  Multiple
   values or ranges can enumeration MUST be given, separated by "|".  If multiple values
   or ranges are given they all unique.

9.6.4.1.  The enum's Substatements

                 +--------------+---------+-------------+
                 | substatement | section | cardinality |
                 +--------------+---------+-------------+
                 | description  | 7.19.3  | 0..1        |
                 | reference    | 7.19.4  | 0..1        |
                 | status       | 7.19.2  | 0..1        |
                 | value        | 9.6.4.2 | 0..1        |
                 +--------------+---------+-------------+

9.6.4.2.  The value Statement

   The "value" statement, which is optional, is used to associate an
   integer value with the assigned name for the enum.  This integer
   value MUST be disjoint in the range -2147483648 to 2147483647, and it MUST be in
   ascending order.
   unique within the enumeration type.

   If a value restriction is applied not specified, then one will be automatically assigned.
   If the enum sub-statement is the first one defined, the assigned
   value is zero (0), otherwise the assigned value is one greater than
   the current highest enum value.

   If the current highest value is equal to 2147483647, then an already
   restricted type, the new restriction enum
   value MUST be equal or more limiting,
   that specified for enum sub-statements following the one
   with the current highest value.

9.6.5.  Usage Example

     type enumeration {
         enum enabled {
             value 1;
         }
         enum disabled {
             value 2;
         }
     }

     type enumeration {
         enum zero;
         enum one;
         enum seven {
             value 7;
         }
     }

9.7.  The bits Built-in Type

   The bits built-in type represents a bit set.  That is, a bits value
   is raising a set of flags identified by small integer position numbers
   starting at 0.  Each bit number has an assigned name.

9.7.1.  Restrictions

   A bits type cannot be restricted.

9.7.2.  Lexicographic Representation

   The lexicographical representation of the lower bounds, reducing bits type is a space
   separated list of the upper bounds, removing
   explicit individual bit values or ranges, or splitting ranges into multiple ranges
   with intermediate gaps.  Each explicit value and range boundary that are set.  An empty
   string thus represents a value
   given where no bits are set.

9.7.3.  Canonical Form

   In the canonical form, the bit values in the space separated list
   appear in the same order as they are specified in the range expression "bits"
   statement.

9.7.4.  The bit Statement

   The "bit" statement, which is a substatement to the "type" statement,
   MUST match be present if the type being restricted,
   or be one is "bits".  It is repeatedly used to
   specify each assigned named bit of a bits type.  It takes as an
   argument a string which is the special values "min" or "max". "min" and "max" means
   the minimum and maximum value accepted for assigned name of the type being restricted,
   respectively.

   The range expression syntax bit.  It is formally defined
   followed by a block of substatements which holds detailed bit
   information.  A bit name follows the rule "range-
   arg" in same syntax rules as an
   identifier (see Section 11.

8.1.3.1. 6.2).

   All bit names in a bits type MUST be unique.

9.7.4.1.  The range's bit's Substatements

                 +---------------+---------+-------------+

                 +--------------+---------+-------------+
                 | substatement | section | cardinality |
                 +---------------+---------+-------------+
                 +--------------+---------+-------------+
                 | description  | 7.17.3 7.19.3  | 0..1        |
                 | error-app-tag reference    | 7.5.3.2 7.19.4  | 0..1        |
                 | error-message status       | 7.5.3.1 7.19.2  | 0..1        |
                 | reference position     | 7.17.4 9.7.4.2 | 0..1        |
                 +---------------+---------+-------------+

8.1.4.  Usage Example

     typedef my-base-int32-type {
         type int32 {
             range "1..4 | 10..20";
         }
     }

     type my-base-int32-type {
         // legal range restriction
         range "11..max"; // 11..20
     }

     type int32 {
         // illegal range restriction
         range "11..100";
     }

8.2.
                 +--------------+---------+-------------+

9.7.4.2.  The Floating Point Built-in Types position Statement

   The floating point built-in types are float32 and float64.  They
   represent floating point values of single and double precision as
   defined in [IEEE.754].  Special values are positive and negative
   infinity, and not-a-number.

8.2.1.  Lexicographic Representation

   A floating point value "position" statement, which is lexicographically represented optional, takes as consisting
   of a decimal mantissa followed, optionally, by the character "E" or
   "e", followed by an argument a
   non-negative integer exponent. value which specifies the bit's position within
   a hypothetical bit field.  The special values positive
   and negative infinity and not-a-number have lexical representations
   INF, -INF position value MUST be in the range 0
   to 4294967295, and NaN, respectively. it MUST be unique within the bits type.  The minimal value accepted for a
   float
   is -INF, unused by YANG and the maximal value accepted for XML encoding, but is carried as a float
   convenience to implementors.

   If a bit position is INF.

8.2.2.  Restrictions

   All floating point types can not specified, then one will be restricted automatically
   assigned.  If the bit sub-statement is the first one defined, the
   assigned value is zero (0), otherwise the assigned value is one
   greater than the current highest bit position.

   If the current highest bit position value is equal to 4294967295,
   then a position value MUST be specified for bit sub-statements
   following the one with the "range" statement
   (Section 8.1.3).

8.2.3. current highest position value.

9.7.5.  Usage Example

   Given the following type:

     leaf mybits {
         type float32 bits {
         range "1..4.5 | 10 | 20..INF";
             bit disable-nagle {
                 position 0;
             }

    is equivalent to

     type float32
             bit auto-sense-speed {
         range "1..4.5 | 10 | 20..max";
                 position 1;
             }
             bit 10-Mb-only {
                 position 2;
             }
         }
         default "auto-sense-speed";
     }

8.3.

   The string lexicographic representation of this leaf with bit values
   disable-nagle and 10-Mb-only set would be:

     <mybits>disable-nagle 10-Mb-only</mybits>

9.8.  The binary Built-in Type

   The string binary built-in type represents human readable strings in YANG.
   Legal characters are tab, carriage return, line feed, and the legal
   characters of Unicode and ISO/IEC 10646 [ISO.10646]:

     // any Unicode character, excluding the surrogate blocks,
     // FFFE, and FFFF.
     string = *char
     char = %x9 / %xA / %xD / %x20-DFFF / %xE000-FFFD /
            %x10000-10FFFF

8.3.1.  Lexicographic Representation

   A string value is lexicographically represented as character data in
   the XML encoding.

8.3.2. binary data, i.e. a sequence
   of octets.

9.8.1.  Restrictions

   A string binary can be restricted with the "length" (Section 8.3.3) and
   "pattern" (Section 8.3.5) statements.

8.3.3. 9.4.4)
   statement.  The length Statement

   The "length" statement, which of a binary value is an optional substatement to the
   "type" statement, takes as an argument number of octets it
   contains.

9.8.2.  Lexicographic Representation

   Binary values are encoded with the base64 encoding scheme [RFC4648].

9.8.3.  Canonical Form

   The canonical form of a length expression string.
   It binary value follow the rules in [RFC4648].

9.9.  The keyref Built-in Type

   The keyref type is used to restrict reference a particular list entry in the built-in type "string", or types derived
   from "string".

   A "length" statement restricts
   data tree.  Its value is constrained to be the number of characters in same as the
   string.

   A length range consists key of an explicit value, or a lower bound, two
   consecutive dots "..", and an upper bound.  Multiple values or ranges
   can be given, separated by "|".  Length restricting values MUST NOT
   be negative.
   existing list entry.

   If multiple values or ranges are given, they all the leaf with the keyref type represents configuration data, the
   list entry it refers to MUST
   be disjoint and also represent configuration.  Such a
   leaf puts a constraint on valid data.  All keyref nodes MUST
   reference existing list entries for the data to be in ascending order.  If a length restriction valid.  This
   constraint is applied enforced according to an already length restricted type, the new restriction
   MUST be equal or more limiting, that is, raising the lower bounds,
   reducing the upper bounds, removing explicit length values or ranges,
   or splitting ranges into multiple ranges with intermediate gaps. rules in Section 8.

9.9.1.  Restrictions

   A
   length value keyref cannot be restricted.

9.9.2.  The path Statement

   The "path" statement, which is a non-negative integer, or substatement to the "type"
   statement, MUST be present if the type is "keyref".  It takes as an
   argument a string which MUST refer to one key node of a list entry.

   The syntax for a path argument is a subset of the special values
   "min" XPath syntax.  It
   is an absolute or "max". "min" relative XPath location path in abbreviated syntax,
   where axes are not permitted, and "max" means predicates are used only for
   constraining the minimum and maximum length
   accepted values for the type being restricted, respectively.  An
   implementation key nodes for list entries.  Each
   predicate consists of at most one equality test per key.

   The predicates are only used when more than one key reference is not required
   needed to support uniquely identify a length value larger than
   18446744073709551615. list entry.  This occurs if the list
   has multiple keys, or a reference to a list within a list is needed.
   In these cases, multiple keyref leafs are typically specified, and
   predicates are used to tie them together.

   The length expression syntax is formally defined by the rule "length-
   arg" "path-arg" in Section 11.

8.3.3.1.  The length's Substatements

                 +---------------+---------+-------------+
                 | substatement  | section | cardinality |
                 +---------------+---------+-------------+
                 | description   | 7.17.3  | 0..1        |
                 | error-app-tag | 7.5.3.2 | 0..1        |
                 | error-message | 7.5.3.1 | 0..1        |
                 | reference     | 7.17.4  | 0..1        |
                 +---------------+---------+-------------+

8.3.4.  Usage Example

      typedef my-base-str-type {
          type string {
              length "1..255";
          }
      }

      type my-base-str-type {
          // legal length refinement
          length "11 | 42..max"; // 11 | 42..255
      }

      type my-base-str-type {
          // illegal length refinement
          length "1..999";
      }

8.3.5.  The pattern Statement

   The "pattern" statement, which 12.

9.9.3.  Lexicographic Representation

   A keyref value is an optional substatement to encoded the
   "type" statement, takes same way as an argument the key it references.

9.9.4.  Canonical Form

   The canonical form of a regular expression string,
   as defined in [XSD-TYPES].  It keyref is used to restrict the built-in type
   "string", or types derived from "string", to values that completely
   matches the pattern.

   If same as the type has multiple "pattern" statements, canonical form of
   the expressions are
   AND:ed together, i.e. all such expressions have to match.

8.3.5.1.  The pattern's Substatements

                 +---------------+---------+-------------+
                 | substatement  | section | cardinality |
                 +---------------+---------+-------------+
                 | description   | 7.17.3  | 0..1        |
                 | error-app-tag | 7.5.3.2 | 0..1        |
                 | error-message | 7.5.3.1 | 0..1        |
                 | reference     | 7.17.4  | 0..1        |
                 +---------------+---------+-------------+

8.3.6. key it references.

9.9.5.  Usage Example

   With the following type: list:

     list interface {
         key "name";
         leaf name {
             type string string;
         }
         list address {
         length "0..4";
         pattern "[0-9a-fA-F]*";
             key "ip";
             leaf ip {
                 type yang:ip-address;
             }
         }
     }
   the following strings match:

     AB          // legal
     9A00        // legal

   and the following strings do not match:

     00ABAB      // illegal
     xx00        // illegal

8.4.  The boolean Built-in Type

   The boolean built-in following keyref refers to an existing interface:

     leaf mgmt-interface {
         type represents a boolean value.

8.4.1.  Lexicographic Representation keyref {
             path "../interface/name";
         }
     }

   A corresponding XML snippet is e.g.:

     <interface>
       <name>eth0</name>
     </interface>
     <interface>
       <name>lo</name>
     </interface>

     <mgmt-interface>eth0</mgmt-interface>

   The lexicographical representation following keyrefs refer to an existing address of a boolean value is the strings
   "true" and "false".

8.4.2.  Restrictions an interface:

     container default-address {
         leaf ifname {
             type keyref {
                 path "../../interface/name";
             }
         }
         leaf address {
             type keyref {
                 path "../../interface[name = current()/../ifname]"
                    + "/address/ip";
             }
         }
     }

   A boolean cannot be restricted.

8.5. corresponding XML snippet is e.g.:

     <interface>
       <name>eth0</name>
       <address>
         <ip>192.0.2.1</ip>
       </address>
       <address>
         <ip>192.0.2.2</ip>
       </address>
     </interface>
     <interface>
       <name>lo</name>
       <address>
         <ip>127.0.0.1</ip>
       </address>
     </interface>

     <default-address>
       <ifname>eth0</ifname>
       <address>192.0.2.2</address>
     </default-address>

9.10.  The enumeration identityref Built-in Type

   The enumeration built-in identityref type represents values from a set of
   assigned names.

8.5.1.  Lexicographic Representation

   The lexicographical representation of an enumeration value is the
   assigned name string.

8.5.2. used to reference an existing identity (see
   Section 7.16).

9.10.1.  Restrictions

   An enumeration identityref cannot be restricted.

8.5.3.

9.10.2.  The enum identityref's base Statement

   The "enum" "base" statement, which is a substatement to the "type"
   statement, MUST be present if the type is "enumeration".  It "identityref".  The
   argument is
   repeatedly used to specify each assigned the name of an enumeration type.
   It takes identity, as defined by an argument "identity"
   statement.  If a string which prefix is present on the assigned name.  It is
   optionally followed by a block of substatements which holds detailed
   enum information.

   All assigned names in identity name, it refers to
   an enumeration MUST be unique.

8.5.3.1.  The enum's Substatements

                 +--------------+---------+-------------+
                 | substatement | section | cardinality |
                 +--------------+---------+-------------+
                 | description  | 7.17.3  | 0..1        |
                 | reference    | 7.17.4  | 0..1        |
                 | status       | 7.17.2  | 0..1        |
                 | value        | 8.5.3.2 | 0..1        |
                 +--------------+---------+-------------+

8.5.3.2.  The value Statement

   The "value" statement, identity defined the module which is optional, is used to associate was imported with that prefix.
   Otherwise an
   integer value identity with the assigned matching name for the enum.  This integer
   value MUST be in the range -2147483648 to 2147483647, and it MUST be
   unique within the enumeration type.

   If a value is not specified, then one will be automatically assigned.
   If the enum sub-statement is the first one defined, the assigned
   value is zero (0), otherwise the assigned value is one greater than
   the current highest enum value.

   If the current highest value is equal to 2147483647, then an enum
   value MUST must be specified defined in the
   current module or an included submodule.

   Valid values for enum sub-statements following an identityref are any identities derived from the one
   with
   identityref's base identity.

9.10.3.  Lexicographic Representation

   An identityref is encoded as the current highest value.

8.5.4. referred identity's qualified name
   [XML-NAMES].

   [Editor's Note: TBD.  How to handle prefixes?]

9.10.4.  Usage Example

     type enumeration {
         enum enabled

   With the identity definitions in Section 7.16.3, the leaf:

     import "crypto-base" {
             value 1;
         prefix "crypto";
     }
         enum disabled

     leaf crypto {
             value 2;
         }
     }
         type enumeration identity-ref {
         enum zero;
         enum one;
         enum seven {
             value 7;
             base "crypto:crypto-alg";
         }
     }

8.6.

   will be encoded as:

     <crypto xmlns:des="http://example.com/des">des:des3</crypto>

   Any prefixes used in the encoding are local to each instance
   encoding.  This means that the same identityref may be encoded
   differently by different implementations.  For example, the following
   example encodes the same leaf as above:

     <crypto xmlns:x="http://example.com/des">x:des3</crypto>

9.11.  The bits empty Built-in Type

   The bits empty built-in type represents a bit set.  That is, a bits value
   is a set of flags identified leaf that does not have any
   value, it conveys information by small integer position numbers
   starting at 0.  Each bit number has an assigned name.

8.6.1. its presence or absence.

   An empty type cannot have a default value.

9.11.1.  Restrictions

   A bits

   An empty type cannot be restricted.

8.6.2.

9.11.2.  Lexicographic Representation

   Not applicable.

9.11.3.  Canonical Representation

   Not applicable.

9.11.4.  Usage Example

   The lexicographical representation of the bits following leaf

     leaf enable-qos {
         type is a space
   separated list of the individual bit values that are set.  An empty
   string thus represents a value where no bits are set.

8.6.3. empty;
     }

   will be encoded as

     <enable-qos/>

   if it exists.

9.12.  The bit Statement union Built-in Type

   The "bit" statement, which is union built-in type represents a substatement value that corresponds to one of
   its member types.

   When the type is "union", the "type" statement, statement (Section 7.4) MUST be present if the type is "bits".
   present.  It is repeatedly used to repeatedly specify each assigned named bit member type of a bits type. the
   union.  It takes as an argument a string which is the assigned name of the bit.  It is
   followed by a block of substatements which holds detailed bit
   information.
   member type.

   A bit name follows the same syntax rules as an
   identifier (see Section 6.2).

   All bit names in a bits member type MUST be unique.

8.6.3.1.  The bit's Substatements

                 +--------------+---------+-------------+
                 | substatement | section | cardinality |
                 +--------------+---------+-------------+
                 | description  | 7.17.3  | 0..1        |
                 | reference    | 7.17.4  | 0..1        |
                 | status       | 7.17.2  | 0..1        |
                 | position     | 8.6.3.2 | 0..1        |
                 +--------------+---------+-------------+

8.6.3.2.  The position Statement

   The "position" statement, which is optional, takes as an argument a
   non-negative integer value which specifies the bit's position within
   a hypothetical bit field.  The position value MUST can be in the range 0
   to 4294967295, and of any built-in or derived type, except it MUST
   NOT be unique within the bits type.  The value
   is unused by YANG and the XML encoding, but is carried as a
   convenience to implementors.

   If a bit position is not specified, then one will be automatically
   assigned.  If the bit sub-statement is the first one defined, the
   assigned value is zero (0), otherwise the assigned value is one
   greater than the current highest bit position.

   If the current highest bit position value is equal to 4294967295,
   then a position value MUST be specified for bit sub-statements
   following the one with the current highest position value.

8.6.4.  Usage Example

   Given of the following type:

     leaf mybits {
         type bits {
             bit disable-nagle {
                 position 0;
             }
             bit auto-sense-speed built-in types "empty" or "keyref".

   Example:

     type union {
                 position 1;
             }
             bit 10-Mb-only
         type int32;
         type enumeration {
                 position 2;
             }
             enum "unbounded";
         }
         default "auto-sense-speed";
     }

   The lexicographic representation of this leaf with bit values
   disable-nagle and 10-Mb-only set would be:

     <mybits>disable-nagle 10-Mb-only</mybits>

8.7.  The binary Built-in Type

   The binary built-in type represents any binary data, i.e. a sequence
   of octets.

8.7.1.

9.12.1.  Restrictions

   A binary union can not be restricted with restricted.  However, each member type can be
   restricted, based on the "length" (Section 8.3.3)
   statement. rules defined in Section 9 chapter.

9.12.2.  Lexicographic Representation

   The length lexicographical representation of an union is a binary value is that
   corresponds to the number representation of any one of octets it
   contains.

8.7.2.  Lexicographic Representation

   Binary values are encoded with the base64 encoding scheme [RFC4648].

8.8.  The keyref Built-in Type member types.

9.12.3.  Canonical Form

   The keyref type is used to reference canonical form of a particular list entry in the
   data tree.  Its union value is constrained to be the same as the key canonical form
   of an
   existing list entry.

   If the leaf with the keyref member type represents configuration, of the list
   entry it refers to MUST also represent configuration.  Such a leaf
   puts a constraint on a valid configuration.  In a valid
   configuration, all keyref nodes MUST reference existing list entries.

8.8.1.  Restrictions

   A keyref cannot be restricted.

8.8.2. value.

9.13.  The path Statement instance-identifier Built-in Type

   The "path" statement, which is a substatement to the "type"
   statement, MUST be present if the instance-identifier built-in type is "keyref".  It takes as an
   argument a string which MUST refer used to one key node of uniquely identify a list entry.
   particular instance node in the data tree.

   The syntax for a path argument an instance-identifier is a subset of the XPath syntax. XPath
   syntax, which is used to uniquely identify a node in the data tree.
   It is an absolute or relative XPath location path in abbreviated syntax, where
   axes are not permitted, and predicates are used only for
   constraining specifying
   the values for the key nodes for list entries.  Each
   predicate consists of at most one equality test per key.

   The predicates are only used when more than one key reference is
   needed to uniquely identify a list entry.  This occurs if the list
   has multiple keys, or a reference to a list within a list is needed.
   In these cases, multiple keyref leafs are typically specified, and
   predicates are used to tie them together.

   The syntax is formally defined by the rule "path-arg" in Section 11.

8.8.3.  Lexicographic Representation

   A keyref value is encoded the same way as the key it references.

8.8.4.  Usage Example

   With the following list:

     list interface {
         key "name";
         leaf name {
             type string;
         }
         list address {
             key "ip";
             leaf ip {
                 type yang:ip-address;
             }
         }
     }

   The following keyref refers to an existing interface:

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

   A corresponding XML snippet is e.g.:

     <interface>
       <name>eth0</name>
     </interface>
     <interface>
       <name>lo</name>
     </interface>

     <mgmt-interface>eth0</mgmt-interface>

   The following keyrefs refer to an existing address of an interface:

     container default-address {
         leaf ifname {
             type keyref {
                 path "../../interface/name";
             }
         }
         leaf address {
             type keyref {
                 path "../../interface[name = current()/../ifname]"
                    + "/address/ip";
             }
         }
     }
   A corresponding XML snippet is e.g.:

     <interface>
       <name>eth0</name>
       <address>
         <ip>192.0.2.1</ip>
       </address>
       <address>
         <ip>192.0.2.2</ip>
       </address>
     </interface>
     <interface>
       <name>lo</name>
       <address>
         <ip>127.0.0.1</ip>
       </address>
     </interface>

     <default-address>
       <ifname>eth0</ifname>
       <address>192.0.2.2</address>
     </default-address>

8.9.  The empty Built-in Type

   The empty built-in type represents a leaf that does not have any
   value, it conveys information by its presence entries, or absence.

   An empty type cannot a value of a leaf-
   list.  Each predicate consists of one equality test per key.  Each
   key MUST have a default value.

8.9.1. corresponding predicate.

   The syntax is formally defined by the rule "absolute-instid" in
   Section 12.

9.13.1.  Restrictions

   An empty type instance-identifier cannot be restricted.

8.9.2.

9.13.2.  Lexicographic Representation

   Not applicable.

8.9.3.

   An instance-identifier value is lexicographically represented as a
   string in the XML encoding.  The namespace prefixes used in the
   encoding MUST be declared in the XML namespace scope in the instance-
   idenfitier's XML element.

   Any prefixes used in the encoding are local to each instance
   encoding.  This means that the same instance-identifier may be
   encoded differently by different implementations.

9.13.3.  Canonical Form

   [Editor's Note: TBD.  How to handle prefixes?]

9.13.4.  Usage Example

   The following leaf

     leaf enable-qos {
         type empty;
     }

   will are examples of instance identifiers:

     /ex:system/ex:services/ex:ssh/ex:port

     /ex:system/ex:user[ex:name='fred']

     /ex:system/ex:user[ex:name='fred']/ex:type

     /ex:system/ex:server[ex:ip='192.0.2.1'][ex:port='80']

     /ex:system/ex:services/ex:ssh/ex:cipher[.='blowfish-cbc']

10.  Updating a Module

   As experience is gained with a module, it may be desirable to revise
   that module.  However, changes are not allowed if they have any
   potential to cause interoperability problems between a client using
   an original specification and a server using an updated
   specification.

   For any published change, a new "revision" statement (Section 7.1.9)
   SHOULD be included in front of the existing revision statements.
   Furthermore, any necessary changes MUST be applied to any meta
   statements, including the "organization" and "contact" statements
   (Section 7.1.7, Section 7.1.8).

   Note that definitions contained in a module are available to be
   imported by any other module, and are referenced in "import"
   statements via the module name.  Thus, a module name MUST NOT be
   changed.  Furthermore, the "namespace" statement MUST NOT be changed,
   since all XML elements are encoded in the namespace.

   Obsolete definitions MUST NOT be removed from modules since their
   identifiers may still be encoded as
     <enable-qos/>

   if it exists.

8.10.  The union Built-in Type

   The union built-in type represents a value that corresponds to one referenced by other modules.

   A definition may be revised in any of
   its member types.

   When the following ways:

   o  An "enumeration" type is "union", may have new enums added, provided the "type" old
      enums's values do not change.

   o  A "bits" type may have new bits added, provided the old bits's
      positions do not change.

   o  A "range", "length", or "pattern" statement (Section 7.4) MUST may expand the allowed
      value space.

   o  A "default" statement may be
   present.  It is used added.

   o  A "units" statement may be added.

   o  A "reference" statement may be added or updated.

   o  A "must" statement may be removed or its constraint relaxed.

   o  A "mandatory" statement may be removed or changed from "true" to repeatedly specify each member type
      "false".

   o  A "min-elements" statement may be removed, or changed to require
      less elements.

   o  A "max-elements" statement may be removed, or changed to allow
      more elements.

   o  A "description" statement may be added or clarified without
      changing the semantics of the
   union.  It takes as an argument definition.

   o  New typedefs, groupings, rpc, notifications, extensions, features,
      and identities may be added.

   o  New data definition statements may be added if they do not add
      mandatory nodes (Section 3.1) to existing nodes or at the top-
      level in a string module or submodule, or if they are conditionally
      dependent on a new feature (i.e. have a "if-feature" statement
      which is the name of refers to a
   member type. new feature).

   o  A new "case" statement may be added.

   o  A node that represented state data may be changed to represent
      configuration, provided it is not mandatory (Section 3.1).

   o  An "if-feature" statement may be removed, provided its node is not
      mandatory (Section 3.1).

   o  A member type can "status" statement may be of any built-in added, or derived type, except it MUST
   NOT be one of the built-in types "empty" changed from "current" to
      "deprecated" or "keyref".

   Example:

     type union {
         type int32;
         type enumeration {
             enum "unbounded";
         }
     }

8.10.1.  Restrictions "obsolete", or from "deprecated" to "obsolete".

   o  A union can not be restricted.  However, each member type can "type" statement may be
   restricted, based on replaced with another "type" statement
      which does not change the rules defined in Section 8 chapter.

8.10.2.  Lexicographic Representation

   The lexicographical representation syntax or semantics of the type.  For
      example, an union is inline type definition may be replaced with a value that
   corresponds to the representation of any one of the member types.

8.11.  The instance-identifier Built-in Type

   The instance-identifier built-in typedef,
      but a int8 type is used to uniquely identify cannot be replaced by a
   particular instance node in int16, since the data tree.

   The syntax for an instance-identifier is a subset
      would change.

   o  Any set of the XPath
   syntax, which is used to uniquely identify a node in the data tree.
   It is an absolute XPath location path in abbreviated syntax, where
   axes are not permitted, and predicates are used only for specifying
   the values for the key definition nodes for list entries, or a value may be replaced with another set
      of syntactically and semantically equivalent nodes.  For example,
      a leaf-
   list.  Each predicate consists set of one equality test per key.  Each
   key MUST have a corresponding predicate.

   The syntax is formally defined by the rule "absolute-instid" in
   Section 11.

8.11.1.  Restrictions

   An instance-identifier cannot be restricted.

8.11.2.  Lexicographic Representation

   An instance-identifier value is lexicographically represented as leafs may be replaced by a
   string in the XML encoding.  The namespace prefixes used in uses of a grouping with the
   encoding MUST
      same leafs.

   o  A module may be declared in split into a set of submodules, or submodule may
      be removed, provided the XML namespace scope definitions in the instance-
   idenfitier's XML element.

   Any prefixes used module do not change
      in any other way than allowed here.

   o  The "prefix" statment may be changed, provided all local uses of
      the encoding prefix also are local to each instance
   encoding.  This means that changed.

   Otherwise, if the same instance-identifier may semantics of any previous definition are changed
   (i.e. if a non-editorial change is made to any definition other than
   those specifically allowed above), then this MUST be
   encoded differently achieved by different implementations.

8.11.3.  Usage Example

   The following are examples of instance identifiers:

     /ex:system/ex:services/ex:ssh/ex:port

     /ex:system/ex:user[ex:name='fred']

     /ex:system/ex:user[ex:name='fred']/ex:type

     /ex:system/ex:server[ex:ip='192.0.2.1'][ex:port='80']

     /ex:system/ex:services/ex:ssh/ex:cipher[.='blowfish-cbc']

9.  Updating a Module
   new definition with a new identifier.

   In statements which have any data definition statements as
   substatements, those data definition substatements MUST NOT be
   reordered.

   [Editor's Note: add versioning rules, i.e. what can be done w/o
   changing the module name and the namespace]

10. These rules work as long as we have import/include by
   revision]

11.  YIN

   A YANG module can be specified in an alternative XML-based syntax
   called YIN.  This appendix section describes symmetric mapping rules between
   the two formats.

   The YANG and YIN formats contain equivalent information using
   different notations.  The purpose of the YIN notation is to allow the
   user to translate YANG into YIN, use the rich set of XML based tools
   on the YIN format to transform, or filter the model information.
   Tools like XSLT or XML validators can be utilized.  After this the
   model can be transformed back to the YANG format if needed, which
   provides a more concise and readable format.

   The YANG-2-YIN and the YIN-2-YANG transformations will not modify the
   information content of the model.

10.1.

11.1.  Formal YIN Definition

   YIN is described by an algorithm that transforms YANG to YIN.

10.2.

11.2.  Transformation Algorithm YANG-2-YIN

   Every keyword results in a new XML element.  The name of the element
   is the keyword.  All core YANG elements are defined in the namespace
   "urn:ietf:params:xml:ns:yang:yin:1".  [XXX IANA]

   The top-level element is always <module> or <submodule>.

   Elements which represent keywords that are imported extensions from
   other modules MUST be properly namespace qualified, where the
   namespace is the namespace of the imported module.  Translators
   SHOULD use  The XML prefix
   for such extensions MUST be the same as the prefix defined in the
   module's "import" statement.

   Elements which represent keywords that are included extensions from
   other submodules MUST be properly namespace qualified, where the
   namespace is the namespace of the module that the submodule belongs
   to.  The XML prefix for such extensions MUST be the same as used the local
   prefix, i.e. for a module it is as defined in the YANG module. "prefix" statement,
   and for a submodule, as defined in the submodule's "belongs-to"
   statement.

   If the keyword has an argument, its encoding depends on the value of
   the argument's "yin-element".  If "yin-element" is false, the
   argument is encoded as an XML attribute to the keyword's element.  If
   "yin-element" is true, the argument is encoded as a subelement to the
   keyword's element.  The name of the attribute or element is the name
   of the argument.

   The core YANG keywords have arguments according to the table below.
   Extension keywords have arguments according to Section 7.16.2. 7.17.2.

                          YANG to YIN keyword map

              +---------------+---------------+-------------+
              | keyword       | argument name | yin-element |
              +---------------+---------------+-------------+
              | anyxml        | name          | false       |
              | argument      | name          | false       |
              | augment       | target-node   | false       |
              | base          | name          | false       |
              | belongs-to    | module        | false       |
              | bit           | name          | false       |
              | case          | name          | false       |
              | choice        | name          | false       |
              | config        | value         | false       |
              | contact       | info          | true        |
              | container     | name          | false       |
              | default       | value         | false       |
              | description   | text          | true        |
              | enum          | name          | false       |
              | error-app-tag | value         | false       |
              | error-message | value         | true        |
              | extension     | name          | false       |
              | deviate       | target-node   | false       |
              | deviation     | value         | false       |
              | feature       | name          | false       |
              | grouping      | name          | false       |
              | identity      | name          | false       |
              | if-feature    | name          | false       |
              | import        | module        | false       |
              | include       | module        | false       |
              | input         | <no argument> | n/a         |
              | key           | value         | false       |
              | leaf          | name          | false       |
              | leaf-list     | name          | false       |
              | length        | value         | false       |
              | list          | name          | false       |
              | mandatory     | value         | false       |
              | max-elements  | value         | false       |
              | min-elements  | value         | false       |
              | module        | name          | false       |
              | must          | condition     | false       |
              | namespace     | uri           | false       |
              | notification  | name          | false       |
              | ordered-by    | value         | false       |
              | organization  | info          | true        |
              | output        | <no argument> | n/a         |
              | path          | value         | false       |
              | pattern       | value         | false       |
              | position      | value         | false       |
              | prefix        | value         | false       |
              | presence      | value         | false       |
              | range         | value         | false       |
              | reference     | info          | false       |
              | refine        | target-node   | false       |
              | revision      | date          | false       |
              | rpc           | name          | false       |
              | status        | value         | false       |
              | submodule     | name          | false       |
              | type          | name          | false       |
              | typedef       | name          | false       |
              | unique        | tag           | false       |
              | units         | name          | false       |
              | uses          | name          | false       |
              | value         | value         | false       |
              | when          | condition     | false       |
              | yang-version  | value         | false       |
              | yin-element   | value         | false       |
              +---------------+---------------+-------------+

                                 Table 30 35

   If a statement is followed by substatements, those substatements are
   subelements in the YIN mapping.

   Comments in YANG MAY be transformed into XML comments.

10.2.1.

11.2.1.  Usage Example

   The following YANG snippet:

     leaf mtu {
         type uint32;
         description "The MTU of the interface.";
     }

   is translated into the following YIN snippet:

     <leaf name="mtu">
       <type name="uint32"/>
       <description>
         <text>The MTU of the interface."</text>
       </description>
     </leaf>

10.3.

11.3.  Transformation Algorithm YIN-2-YANG

   The transformation is based on a recursive algorithm that is started
   on the <module> or <submodule> element.

   The element is transformed into a YANG keyword.  If the keyword in
   Table 30 35 is marked as yin-element true, the subelement with the
   keyword's argument name in Table 30 35 contains the YANG keyword's
   argument as text content.  If the keyword in Table 30 35 is marked as
   yin-element false, the element's attribute with keyword's argument
   name in Table 30 35 contains the YANG keyword's argument.

   If there are no other subelements to the element, the YANG statement
   is closed with a ";".  Otherwise, each such subelement is
   transformed, according to the same algorithm, as substatements to the
   current YANG statement, enclosed within "{" and "}".

   XML comments in YIN MAY be transformed into YANG comments.

10.3.1.

11.3.1.  Tabulation, Formatting

   To get a readable YANG module the YANG output will have to be
   indented with appropriate whitespace characters.

11.

12.  YANG ABNF Grammar

   In YANG, almost all statements are unordered.  The ABNF grammar
   [RFC5234] defines the canonical order.  To improve module
   readability, it is RECOMMENDED that clauses be entered in this order.

   Within the ABNF grammar, unordered statements are marked with
   comments.

   This grammar assumes that the scanner replaces YANG comments with a
   single space character.

module-stmt            = optsep module-keyword sep identifier-arg-str
                         optsep
                         "{" stmtsep
                             module-header-stmts
                             linkage-stmts
                             meta-stmts
                             revision-stmts
                             body-stmts
                         "}" optsep

submodule-stmt         = optsep submodule-keyword sep identifier-arg-str
                         optsep
                         "{" stmtsep
                             submodule-header-stmts
                             linkage-stmts
                             meta-stmts
                             revision-stmts
                             body-stmts
                         "}" optsep

module-header-stmts    = ;; these stmts can appear in any order
                         [yang-version-stmt stmtsep]
                          namespace-stmt stmtsep
                          prefix-stmt stmtsep

submodule-header-stmts = ;; these stmts can appear in any order
                         [yang-version-stmt stmtsep]
                          belongs-to-stmt stmtsep

meta-stmts             = ;; these stmts can appear in any order
                         [organization-stmt stmtsep]
                         [contact-stmt stmtsep]
                         [description-stmt stmtsep]
                         [reference-stmt stmtsep]

linkage-stmts          = ;; these stmts can appear in any order
                         *(import-stmt stmtsep)
                         *(include-stmt stmtsep)

revision-stmts         = *(revision-stmt stmtsep)

body-stmts             = *((extension-stmt /
                            feature-stmt /
                            identity-stmt /
                            typedef-stmt /
                            grouping-stmt /
                            data-def-stmt /
                            augment-stmt /
                            rpc-stmt /
                            notification-stmt)
                            notification-stmt /
                            deviation-stmt) stmtsep)

data-def-stmt          = container-stmt /
                         leaf-stmt /
                         leaf-list-stmt /
                         list-stmt /
                         choice-stmt /
                         anyxml-stmt /
                         uses-stmt /
                         augment-stmt

case-data-def-stmt     = container-stmt /
                         leaf-stmt /
                         leaf-list-stmt /
                         list-stmt /
                         anyxml-stmt /
                         uses-stmt /
                         augment-stmt

yang-version-stmt      = yang-version-keyword sep yang-version-arg-str
                         optsep stmtend

yang-version-arg-str   = < a string which matches the rule
                           yang-version-arg >

yang-version-arg       = "1"

import-stmt            = import-keyword sep identifier-arg-str optsep
                         "{" stmtsep
                             prefix-stmt stmtsep
                         "}"

include-stmt           = include-keyword sep identifier-arg-str optsep
                         stmtend

namespace-stmt         = namespace-keyword sep uri-str optsep stmtend

uri-str                = < a string which matches the rule
                           URI in RFC 3986 >

prefix-stmt            = prefix-keyword sep prefix-arg-str
                         optsep stmtend

belongs-to-stmt        = belongs-to-keyword sep identifier-arg-str
                         optsep stmtend
                         "{" stmtsep
                             prefix-stmt stmtsep
                         "}"

organization-stmt      = organization-keyword sep string
                         optsep stmtend

contact-stmt           = contact-keyword sep string optsep stmtend

description-stmt       = description-keyword sep string optsep
                         stmtend

reference-stmt         = reference-keyword sep string optsep stmtend

units-stmt             = units-keyword sep string optsep stmtend

revision-stmt          = revision-keyword sep date-arg-str optsep
                         (";" /
                          "{" stmtsep
                              [description-stmt stmtsep]
                          "}")

extension-stmt         = extension-keyword sep identifier-arg-str optsep
                         (";" /
                          "{" stmtsep
                              ;; these stmts can appear in any order
                              [argument-stmt stmtsep]
                              [status-stmt stmtsep]
                              [description-stmt stmtsep]
                              [reference-stmt stmtsep]
                          "}")

argument-stmt          = argument-keyword sep identifier-arg-str optsep
                         (";" /
                          "{" stmtsep
                              [yin-element-stmt stmtsep]
                          "}")

yin-element-stmt       = yin-element-keyword sep yin-element-arg-str
                         stmtend

yin-element-arg-str    = < a string which matches the rule
                           yin-element-arg >

yin-element-arg        = true-keyword / false-keyword

identity-stmt          = identity-keyword sep identifier-arg-str optsep
                         (";" /
                          "{" stmtsep
                              ;; these stmts can appear in any order
                              [base-stmt stmtsep]
                              [status-stmt stmtsep]
                              [description-stmt stmtsep]
                              [reference-stmt stmtsep]
                          "}")

base-stmt              = base-keyword sep identifier-ref-arg-str
                         optsep stmtend

feature-stmt           = feature-keyword sep identifier-arg-str optsep
                         (";" /
                          "{" stmtsep
                              ;; these stmts can appear in any order
                              *(if-feature-stmt stmtsep)
                              [status-stmt stmtsep]
                              [description-stmt stmtsep]
                              [reference-stmt stmtsep]
                          "}")

if-feature-stmt        = if-feature-keyword sep identifier-ref-arg-str
                         optsep stmtend

typedef-stmt           = typedef-keyword sep identifier-arg-str optsep
                         "{" stmtsep
                             ;; these stmts can appear in any order
                             type-stmt stmtsep
                             [units-stmt stmtsep]
                             [default-stmt stmtsep]
                             [status-stmt stmtsep]
                             [description-stmt stmtsep]
                             [reference-stmt stmtsep]
                          "}"

type-stmt              = type-keyword sep identifier-ref-arg-str optsep
                         (";" /
                          "{" stmtsep
                              (
                              type-body-stmts
                          "}")

type-body-stmts        = numerical-restrictions /
                         string-restrictions /
                         enum-specification /
                         keyref-specification /
                         identityref-specification /
                         bits-specification /
                         union-specification )
                              stmtsep
                          "}")

numerical-restrictions = range-stmt stmtsep

range-stmt             = range-keyword sep range-arg-str optsep
                         (";" /
                          "{" stmtsep
                              ;; these stmts can appear in any order
                              [error-message-stmt stmtsep]
                              [error-app-tag-stmt stmtsep]
                              [description-stmt stmtsep]
                              [reference-stmt stmtsep]
                           "}")

string-restrictions    = ;; these stmts can appear in any order
                         [length-stmt stmtsep]
                         *(pattern-stmt stmtsep)

length-stmt            = length-keyword sep length-arg-str optsep
                         (";" /
                          "{" stmtsep
                              ;; these stmts can appear in any order
                              [error-message-stmt stmtsep]
                              [error-app-tag-stmt stmtsep]
                              [description-stmt stmtsep]
                              [reference-stmt stmtsep]
                           "}")

pattern-stmt           = pattern-keyword sep string optsep
                         (";" /
                          "{" stmtsep
                              ;; these stmts can appear in any order
                              [error-message-stmt stmtsep]
                              [error-app-tag-stmt stmtsep]
                              [description-stmt stmtsep]
                              [reference-stmt stmtsep]
                           "}")

default-stmt           = default-keyword sep string stmtend

enum-specification     = 1*(enum-stmt stmtsep)

enum-stmt              = enum-keyword sep identifier-arg-str string optsep
                         (";" /
                          "{" stmtsep
                              ;; these stmts can appear in any order
                              [value-stmt stmtsep]
                              [status-stmt stmtsep]
                              [description-stmt stmtsep]
                              [reference-stmt stmtsep]
                           "}")

keyref-specification   = path-stmt stmtsep

path-stmt              = path-keyword sep path-arg-str stmtend

identityref-specification = base-stmt stmtsep

union-specification    = 1*(type-stmt stmtsep)

bits-specification     = 1*(bit-stmt stmtsep)

bit-stmt               = bit-keyword sep identifier-arg-str optsep
                         (";" /
                          "{" stmtsep
                              ;; these stmts can appear in any order
                              [position-stmt stmtsep]
                              [status-stmt stmtsep]
                              [description-stmt stmtsep]
                              [reference-stmt stmtsep]
                            "}"
                          "}")

position-stmt          = position-keyword sep
                         position-value-arg-str stmtend

position-value-arg-str = < a string which matches the rule
                           position-value-arg >

position-value-arg     = non-negative-decimal-value

status-stmt            = status-keyword sep status-arg-str stmtend

status-arg-str         = < a string which matches the rule
                           status-arg >

status-arg             = current-keyword /
                         obsolete-keyword /
                         deprecated-keyword

config-stmt            = config-keyword sep
                         config-arg-str stmtend

config-arg-str         = < a string which matches the rule
                           config-arg >

config-arg             = true-keyword / false-keyword

mandatory-stmt         = mandatory-keyword sep
                         mandatory-arg-str stmtend

mandatory-arg-str      = < a string which matches the rule
                           mandatory-arg >

mandatory-arg          = true-keyword / false-keyword

presence-stmt          = presence-keyword sep string stmtend

ordered-by-stmt        = ordered-by-keyword sep
                         ordered-by-arg-str stmtend

ordered-by-arg-str     = < a string which matches the rule
                           ordered-by-arg >

ordered-by-arg         = user-keyword / system-keyword

must-stmt              = must-keyword sep string optsep
                         (";" /
                          "{" stmtsep
                              ;; these stmts can appear in any order
                              [error-message-stmt stmtsep]
                              [error-app-tag-stmt stmtsep]
                              [description-stmt stmtsep]
                              [reference-stmt stmtsep]
                           "}")

error-message-stmt     = error-message-keyword sep string stmtend

error-app-tag-stmt     = error-app-tag-keyword sep string stmtend

min-elements-stmt      = min-elements-keyword sep
                         min-value-arg-str stmtend;

min-value-arg-str      = < a string which matches the rule
                           min-value-arg >

min-value-arg          = non-negative-decimal-value

max-elements-stmt      = max-elements-keyword sep
                         max-value-arg-str stmtend;

max-value-arg-str      = < a string which matches the rule
                           max-value-arg >

max-value-arg          = unbounded-keyword /
                         positive-decimal-value

value-stmt             = value-keyword sep decimal-value stmtend

grouping-stmt          = grouping-keyword sep identifier-arg-str optsep
                         (";" /
                          "{" stmtsep
                              ;; these stmts can appear in any order
                              [status-stmt stmtsep]
                              [description-stmt stmtsep]
                              [reference-stmt stmtsep]
                              *((typedef-stmt /
                                 grouping-stmt) stmtsep)
                              *(data-def-stmt stmtsep)
                          "}")

container-stmt         = container-keyword sep identifier-arg-str optsep
                         (";" /
                          "{" stmtsep
                              ;; these stmts can appear in any order
                              [when-stmt stmtsep]
                              *(if-feature-stmt stmtsep)
                              *(must-stmt stmtsep)
                              [presence-stmt stmtsep]
                              [config-stmt stmtsep]
                              [status-stmt stmtsep]
                              [description-stmt stmtsep]
                              [reference-stmt stmtsep]
                              *((typedef-stmt /
                                 grouping-stmt) stmtsep)
                              *(data-def-stmt stmtsep)
                          "}")

leaf-stmt              = leaf-keyword sep identifier-arg-str optsep
                         "{" stmtsep
                             ;; these stmts can appear in any order
                             [when-stmt stmtsep]
                             *(if-feature-stmt stmtsep)
                             type-stmt stmtsep
                             [units-stmt stmtsep]
                             *(must-stmt stmtsep)
                             [default-stmt stmtsep]
                             [config-stmt stmtsep]
                             [mandatory-stmt stmtsep]
                             [status-stmt stmtsep]
                             [description-stmt stmtsep]
                             [reference-stmt stmtsep]
                          "}"

leaf-list-stmt         = leaf-list-keyword sep identifier-arg-str optsep
                         "{" stmtsep
                             ;; these stmts can appear in any order
                             [when-stmt stmtsep]
                             *(if-feature-stmt stmtsep)
                             type-stmt stmtsep
                             [units-stmt stmtsep]
                             *(must-stmt stmtsep)
                             [config-stmt stmtsep]
                             [min-elements-stmt stmtsep]
                             [max-elements-stmt stmtsep]
                             [ordered-by-stmt stmtsep]
                             [status-stmt stmtsep]
                             [description-stmt stmtsep]
                             [reference-stmt stmtsep]
                          "}"

list-stmt              = list-keyword sep identifier-arg-str optsep
                         "{" stmtsep
                             ;; these stmts can appear in any order
                             [when-stmt stmtsep]
                             *(if-feature-stmt stmtsep)
                             *(must-stmt stmtsep)
                             [key-stmt stmtsep]
                             *(unique-stmt stmtsep)
                             [config-stmt stmtsep]
                             [min-elements-stmt stmtsep]
                             [max-elements-stmt stmtsep]
                             [ordered-by-stmt stmtsep]
                             [status-stmt stmtsep]
                             [description-stmt stmtsep]
                             [reference-stmt stmtsep]
                             *((typedef-stmt /
                                grouping-stmt) stmtsep)
                             1*(data-def-stmt stmtsep)
                          "}"

key-stmt               = key-keyword sep key-arg-str stmtend

key-arg-str            = < a string which matches the rule
                           key-arg >

key-arg                = identifier *(sep identifier)

unique-stmt            = unique-keyword sep unique-arg-str stmtend

unique-arg-str         = < a string which matches the rule
                           unique-arg >

unique-arg             = descendant-schema-nodeid
                         *(sep descendant-schema-nodeid)

choice-stmt            = choice-keyword sep identifier-arg-str optsep
                         (";" /
                          "{" stmtsep
                              ;; these stmts can appear in any order
                              [when-stmt stmtsep]
                              *(if-feature-stmt stmtsep)
                              [default-stmt stmtsep]
                              [config-stmt stmtsep]
                              [mandatory-stmt stmtsep]
                              [status-stmt stmtsep]
                              [description-stmt stmtsep]
                              [reference-stmt stmtsep]
                              *((short-case-stmt / case-stmt) stmtsep)
                          "}")

short-case-stmt        = container-stmt /
                         leaf-stmt /
                         leaf-list-stmt /
                         list-stmt /
                         anyxml-stmt

case-stmt              = case-keyword sep identifier-arg-str optsep
                         (";" /
                          "{" stmtsep
                              ;; these stmts can appear in any order
                              [when-stmt stmtsep]
                              *(if-feature-stmt stmtsep)
                              [status-stmt stmtsep]
                              [description-stmt stmtsep]
                              [reference-stmt stmtsep]
                              *(case-data-def-stmt stmtsep)
                          "}")

anyxml-stmt            = anyxml-keyword sep identifier-arg-str optsep
                         (";" /
                          "{" stmtsep
                              ;; these stmts can appear in any order
                              [when-stmt stmtsep]
                              *(if-feature-stmt stmtsep)
                              [config-stmt stmtsep]
                              [mandatory-stmt stmtsep]
                              [status-stmt stmtsep]
                              [description-stmt stmtsep]
                              [reference-stmt stmtsep]
                           "}")

uses-stmt              = uses-keyword sep identifier-ref-arg-str optsep
                         (";" /
                          "{" stmtsep
                              ;; these stmts can appear in any order
                              [when-stmt stmtsep]
                              *(if-feature-stmt stmtsep)
                              [status-stmt stmtsep]
                              [description-stmt stmtsep]
                              [reference-stmt stmtsep]
                              *(refinement-stmt stmtsep)
                              *(uses-augment-stmt stmtsep)
                          "}")

refinement-stmt        = refine-container-stmt refine-keyword sep refine-arg-str optsep
                         "{" stmtsep
                             (refine-container-stmts /
                         refine-leaf-stmt
                              refine-leaf-stmts /
                         refine-leaf-list-stmt
                              refine-leaf-list-stmts /
                         refine-list-stmt
                              refine-list-stmts /
                         refine-choice-stmt
                              refine-choice-stmts /
                         refine-anyxml-stmt

refine-leaf-stmt       = leaf-keyword sep identifier-arg-str optsep
                         (";"
                              refine-case-stmts /
                          "{" stmtsep
                              refine-anyxml-stmts)
                         "}"

refine-arg-str         = < a string which matches the rule
                           refine-arg >

refine-arg             = descendant-schema-nodeid

refine-container-stmts = ;; these stmts can appear in any order
                         *(must-stmt stmtsep)
                         [presence-stmt stmtsep]
                         [config-stmt stmtsep]
                         [description-stmt stmtsep]
                         [reference-stmt stmtsep]

refine-leaf-stmts      = ;; these stmts can appear in any order
                         *(must-stmt stmtsep)
                         [default-stmt stmtsep]
                         [config-stmt stmtsep]
                         [mandatory-stmt stmtsep]
                         [description-stmt stmtsep]
                         [reference-stmt stmtsep]
                          "}")

refine-leaf-list-stmt

refine-leaf-list-stmts = leaf-list-keyword sep identifier-arg-str optsep
                         (";" /
                          "{" stmtsep ;; these stmts can appear in any order
                         *(must-stmt stmtsep)
                         [config-stmt stmtsep]
                         [min-elements-stmt stmtsep]
                         [max-elements-stmt stmtsep]
                         [description-stmt stmtsep]
                         [reference-stmt stmtsep]
                          "}")

refine-list-stmt

refine-list-stmts      = list-keyword sep identifier-arg-str optsep
                         (";" /
                          "{" stmtsep ;; these stmts can appear in any order
                         *(must-stmt stmtsep)
                         [config-stmt stmtsep]
                         [min-elements-stmt stmtsep]
                         [max-elements-stmt stmtsep]
                         [description-stmt stmtsep]
                         [reference-stmt stmtsep]
                             *(refinement-stmt stmtsep)
                          "}")

refine-choice-stmt

refine-choice-stmts    = choice-keyword sep identifier-arg-str optsep
                         (";" /
                          "{" stmtsep ;; these stmts can appear in any order
                         [default-stmt stmtsep]
                         [mandatory-stmt stmtsep]
                         [description-stmt stmtsep]
                             [reference-stmt stmtsep]
                             *(refine-case-stmt stmtsep)
                          "}")

refine-case-stmt       = case-keyword sep identifier-arg-str optsep
                        (";" /
                         "{" stmtsep stmtsep]
                         [reference-stmt stmtsep]

refine-case-stmts      = ;; these stmts can appear in any order
                         [description-stmt stmtsep]
                         [reference-stmt stmtsep]
                              *(refinement-stmt stmtsep)
                          "}")

refine-container-stmt

refine-anyxml-stmts    = container-keyword sep identifier-arg-str optsep
                        (";" /
                         "{" stmtsep ;; these stmts can appear in any order
                             *(must-stmt stmtsep)
                             [presence-stmt stmtsep]
                         [config-stmt stmtsep]
                         [mandatory-stmt stmtsep]
                         [description-stmt stmtsep]
                         [reference-stmt stmtsep]
                             *(refinement-stmt stmtsep)
                          "}")

refine-anyxml-stmt

uses-augment-stmt      = anyxml-keyword augment-keyword sep identifier-arg-str uses-augment-arg-str optsep
                        (";" /
                         "{" stmtsep
                             ;; these stmts can appear in any order
                             [config-stmt
                             [when-stmt stmtsep]
                             [mandatory-stmt
                             *(if-feature-stmt stmtsep)
                             [status-stmt stmtsep]
                             [description-stmt stmtsep]
                             [reference-stmt stmtsep]
                          "}")

unknown-statement      = prefix ":" identifier [sep string] optsep
                         (";"
                             1*((data-def-stmt stmtsep) / "{" *unknown-statement "}")
                                (case-stmt stmtsep))
                          "}"

uses-augment-arg-str   = < a string which matches the rule
                           uses-augment-arg >

uses-augment-arg       = descendant-schema-nodeid

augment-stmt           = augment-keyword sep augment-arg-str optsep
                         "{" stmtsep
                             ;; these stmts can appear in any order
                             [when-stmt stmtsep]
                             *(if-feature-stmt stmtsep)
                             [status-stmt stmtsep]
                             [description-stmt stmtsep]
                             [reference-stmt stmtsep]
                             1*((data-def-stmt stmtsep) /
                                (case-stmt stmtsep))
                          "}"

augment-arg-str        = < a string which matches the rule
                           augment-arg >

augment-arg            = absolute-schema-nodeid

unknown-statement      = prefix ":" identifier [sep string] optsep
                         (";" /
                         descendant-schema-nodeid "{" *unknown-statement "}")

when-stmt              = when-keyword sep string stmtend

rpc-stmt               = rpc-keyword sep identifier-arg-str optsep
                         (";" /
                          "{" stmtsep
                              ;; these stmts can appear in any order
                              *(if-feature-stmt stmtsep)
                              [status-stmt stmtsep]
                              [description-stmt stmtsep]
                              [reference-stmt stmtsep]
                              *((typedef-stmt /
                                 grouping-stmt) stmtsep)
                              [input-stmt stmtsep]
                              [output-stmt stmtsep]
                          "}")

input-stmt             = input-keyword optsep
                         "{" stmtsep
                             ;; these stmts can appear in any order
                             *((typedef-stmt /
                                grouping-stmt) stmtsep)
                             1*(data-def-stmt stmtsep)
                         "}"

output-stmt            = output-keyword optsep
                         "{" stmtsep
                             ;; these stmts can appear in any order
                             *((typedef-stmt /
                                grouping-stmt) stmtsep)
                             1*(data-def-stmt stmtsep)
                         "}"

notification-stmt      = notification-keyword sep
                         identifier-arg-str optsep
                         (";" /
                          "{" stmtsep
                              ;; these stmts can appear in any order
                              *(if-feature-stmt stmtsep)
                              [status-stmt stmtsep]
                              [description-stmt stmtsep]
                              [reference-stmt stmtsep]
                              *((typedef-stmt /
                                 grouping-stmt) stmtsep)
                              *(data-def-stmt stmtsep)
                          "}")

deviation-stmt         = deviation-keyword sep
                         deviation-arg-str optsep
                         "{" stmtsep
                             ;; these stmts can appear in any order
                             [description-stmt stmtsep]
                             [reference-stmt stmtsep]
                             *(deviate-stmt stmtsep)
                         "}"

deviation-arg-str      = < a string which matches the rule
                           deviation-arg >

deviation-arg          = absolute-schema-nodeid

deviate-stmt           = deviate-keyword sep deviate-arg-str optsep
                         "{" stmtsep
                             ;; these stmts can appear in any order
                             [type-stmt stmtsep]
                             [units-stmt stmtsep]
                             *(must-stmt stmtsep)
                             *(unique-stmt stmtsep)
                             [default-stmt stmtsep]
                             [config-stmt stmtsep]
                             [mandatory-stmt stmtsep]
                             [min-elements-stmt stmtsep]
                             [max-elements-stmt stmtsep]
                         "}"

deviate-arg-str        = < a string which matches the rule
                           deviate-arg >

deviate-arg            = add-keyword /
                         delete-keyword /
                         replace-keyword /
                         not-supported-keyword

;; Ranges

range-arg-str          = < a string which matches the rule
                           range-arg >

range-arg              = range-part *(optsep "|" optsep range-part)

range-part             = range-boundary
                         [optsep ".." optsep range-boundary]

range-boundary         = neginf-keyword / posinf-keyword /
                         min-keyword / max-keyword /
                         decimal-value / float-value

;; Lengths

length-arg-str         = < a string which matches the rule
                           length-arg >

length-arg             = length-part *(optsep "|" optsep length-part)

length-part            = length-boundary
                         [optsep ".." optsep length-boundary]

length-boundary        = min-keyword / max-keyword /
                         non-negative-decimal-value

;; Date

date-arg-str           = < a string which matches the rule
                           date-arg >

date-arg               = 4DIGIT "-" 2DIGIT "-" 2DIGIT

;; Schema Node Identifiers

schema-nodeid          = absolute-schema-nodeid /
                         relative-schema-nodeid

absolute-schema-nodeid
                       = 1*("/" node-identifier)

relative-schema-nodeid
                       = descendant-schema-nodeid /
                         (("." / "..") "/"
                         *relative-schema-nodeid)

descendant-schema-nodeid
                       = node-identifier
                         absolute-schema-nodeid

node-identifier        = [prefix ":"] identifier

;; Instance Identifiers

instance-identifier-str
                       = < a string which matches the rule
                           instance-identifier >

instance-identifier    = absolute-instid / relative-instid

absolute-instid        = 1*("/" (node-identifier *predicate))

relative-instid        = descendant-instid /
                         (("." / "..") "/"
                          *relative-instid)

descendant-instid      = node-identifier *predicate
                         absolute-instid

predicate              = "[" *WSP predicate-expr *WSP "]"

predicate-expr         = (node-identifier / ".") *WSP "=" *WSP
                         ((DQUOTE string DQUOTE) /
                          (SQUOTE string SQUOTE))

;; keyref path

path-arg-str           = < a string which matches the rule
                           path-arg >

path-arg               = absolute-path / relative-path

absolute-path          = 1*("/" (node-identifier *path-predicate))

relative-path          = descendant-path /
                         (".." "/"
                         *relative-path)

descendant-path        = node-identifier *path-predicate
                         absolute-path

path-predicate         = "[" *WSP path-equality-expr *WSP "]"

path-equality-expr     = node-identifier *WSP "=" *WSP path-key-expr

path-key-expr          = this-variable-keyword current-function-invocation "/"
                         rel-path-keyexpr

rel-path-keyexpr       = 1*(".." "/") *(node-identifier "/")
                         node-identifier

;;; Keywords, using abnfgen's syntax for case-sensitive strings

;; statment keywords
anyxml-keyword         = 'anyxml'
argument-keyword       = 'argument'
augment-keyword        = 'augment'
base-keyword           = 'base'
belongs-to-keyword     = 'belongs-to'
bit-keyword            = 'bit'
case-keyword           = 'case'
choice-keyword         = 'choice'
config-keyword         = 'config'
contact-keyword        = 'contact'
container-keyword      = 'container'
default-keyword        = 'default'
description-keyword    = 'description'
enum-keyword           = 'enum'
error-app-tag-keyword  = 'error-app-tag'
error-message-keyword  = 'error-message'
extension-keyword      = 'extension'
deviation-keyword      = 'deviation'
deviate-keyword        = 'deviate'
feature-keyword        = 'feature'
grouping-keyword       = 'grouping'
identity-keyword       = 'identity'
if-feature-keyword     = 'if-feature'
import-keyword         = 'import'

include-keyword        = 'include'
input-keyword          = 'input'
key-keyword            = 'key'
leaf-keyword           = 'leaf'
leaf-list-keyword      = 'leaf-list'
length-keyword         = 'length'
list-keyword           = 'list'
mandatory-keyword      = 'mandatory'
max-elements-keyword   = 'max-elements'
min-elements-keyword   = 'min-elements'
module-keyword         = 'module'
must-keyword           = 'must'
namespace-keyword      = 'namespace'
notification-keyword   = 'notification'
ordered-by-keyword     = 'ordered-by'
organization-keyword   = 'organization'
output-keyword         = 'output'
path-keyword           = 'path'
pattern-keyword        = 'pattern'
position-keyword       = 'position'
prefix-keyword         = 'prefix'
presence-keyword       = 'presence'
range-keyword          = 'range'
reference-keyword      = 'reference'
refine-keyword         = 'refine'
revision-keyword       = 'revision'
rpc-keyword            = 'rpc'
status-keyword         = 'status'
submodule-keyword      = 'submodule'
type-keyword           = 'type'
typedef-keyword        = 'typedef'
unique-keyword         = 'unique'
units-keyword          = 'units'
uses-keyword           = 'uses'
value-keyword          = 'value'
when-keyword           = 'when'
yang-version-keyword   = 'yang-version'
yin-element-keyword    = 'yin-element'

;; other keywords

add-keyword            = 'add'
current-keyword        = 'current'
delete-keyword         = 'delete'
deprecated-keyword     = 'deprecated'
false-keyword          = 'false'
max-keyword            = 'max'
min-keyword            = 'min'

nan-keyword            = 'NaN'
neginf-keyword         = '-INF'
not-supported-keyword  = 'not-supported'
obsolete-keyword       = 'obsolete'
posinf-keyword         = 'INF'
replace-keyword        = 'replace'
system-keyword         = 'system'
this-variable-keyword  = '$this'
true-keyword           = 'true'
unbounded-keyword      = 'unbounded'
user-keyword           = 'user'

current-function-invocation = 'current()'

;; Basic Rules

keyword                = [prefix ":"] identifier

prefix-arg-str         = < a string which matches the rule
                           prefix-arg >

prefix-arg             = prefix

prefix                 = identifier

identifier-arg-str     = < a string which matches the rule
                           identifier-arg >

identifier-arg         = identifier

identifier             = (ALPHA / "_")
                         *(ALPHA / DIGIT / "_" / "-" / ".")

identifier-ref-arg-str = < a string which matches the rule
                           identifier-ref-arg >

identifier-ref-arg     = [prefix ":"] identifier

string                 = < an unquoted string as returned by
                           the scanner >

decimal-value          = ("-" non-negative-decimal-value)  /
                          non-negative-decimal-value

non-negative-decimal-value = "0" / positive-decimal-value

positive-decimal-value = (non-zero-digit *DIGIT)

zero-decimal-value     = 1*DIGIT

stmtend                = ";" / "{" *unknown-statement "}"

sep                    = 1*(WSP / line-break)
                         ; unconditional separator

optsep                 = *(WSP / line-break)

stmtsep                = *(WSP / line-break / unknown-statement)

line-break             = CRLF / LF

non-zero-digit         = %x31-39

float-value            = neginf-keyword /
                         posinf-keyword /
                         nan-keyword /
                         decimal-value "." zero-decimal-value
                            *1("E" ("+"/"-") zero-decimal-value)

SQUOTE                 = %x27
                         ; ' (Single Quote)

;;
;; RFC 4234 core rules.
;;

ALPHA                  = %x41-5A / %x61-7A
                         ; A-Z / a-z

CR                     = %x0D
                         ; carriage return

CRLF                   = CR LF
                         ; Internet standard newline

DIGIT                  = %x30-39
                         ; 0-9

DQUOTE                 = %x22
                         ; " (Double Quote)

HEXDIG                 = DIGIT /
                         %x61 / %x62 / %x63 / %x64 / %x65 / %x66
                         ; only lower-case a..f

HTAB                   = %x09
                         ; horizontal tab

LF                     = %x0A
                         ; linefeed

SP                     = %x20
                         ; space

VCHAR                  = %x21-7E
                         ; visible (printing) characters

WSP                    = SP / HTAB
                         ; white space

12.

13.  Error Responses for YANG Related Errors

   A number of NETCONF error responses are defined for error cases
   related to the data-model handling.  If the relevant YANG statement
   has an "error-app-tag" substatement, that overrides the default value
   specified below.

12.1.

13.1.  Error Message for Data that Violates a YANG unique Statement:

   If a NETCONF operation would result in configuration data where a
   unique constraint is invalidated, the following error is returned:

     Tag:            operation-failed
     Error-app-tag:  data-not-unique
     Error-info:     <non-unique>: Contains an instance identifier which
                     points to a leaf which invalidates the unique
                     constraint. This element is present once for each
                     leaf invalidating the unique constraint.

                     The <non-unique> element is in the YANG
                     namespace ("urn:ietf:params:xml:ns:yang:1"
                     [XXX IANA]).

12.2.

13.2.  Error Message for Data that Violates a YANG max-elements
       Statement:

   If a NETCONF operation would result in configuration data where a
   list or a leaf-list would have too many entries the following error
   is returned:

     Tag:            operation-failed
     Error-app-tag:  too-many-elements

   This error is returned once, with the error-path identifying the list
   node, even if there are more than one extra child present.

12.3.

13.3.  Error Message for Data that Violates a YANG min-elements
       Statement:

   If a NETCONF operation would result in configuration data where a
   list or a leaf-list would have too few entries the following error is
   returned:

     Tag:            operation-failed
     Error-app-tag:  too-few-elements

   This error is returned once, with the error-path identifying the list
   node, even if there are more than one child missing.

12.4.

13.4.  Error Message for Data that Violates a YANG must statement:

   If a NETCONF operation would result in configuration data where the
   restrictions imposed by a "must" statement is violated the following
   error is returned, unless a specific "error-app-tag" substatement is
   present for the "must" statement.

     Tag:            operation-failed
     Error-app-tag:  must-violation

12.5.

13.5.  Error Message for the "insert" Operation

   If the "insert" and "key" or "value" attributes are used in an <edit-
   config> for a list or leaf-list node, and the "key" or "value" refers
   to a non-existing instance, the following error is returned:

     Tag:            bad-attribute
     Error-app-tag:  missing-instance

13.

14.  IANA Considerations

   This document registers two URIs for the YANG XML namespace in the
   IETF XML registry [RFC3688].

     URI: urn:ietf:params:xml:ns:yang:yin:1

     URI: urn:ietf:params:xml:ns:yang:1

14.

15.  Security Considerations

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

   Data modeled in YANG might contain sensitive information.  RPCs or
   notifications defined in YANG might transfer sensitive information.

   Security issues are related to the usage of data modeled in YANG.
   Such issues shall be dealt with in documents describing the data
   models and documents about the interfaces used to manipulate the data
   e.g. the NETCONF documents.

   YANG is dependent upon:

   o  the security of the transmission infrastructure used to send
      sensitive information

   o  the security of applications which store or release such sensitive
      information.

   o  adequate authentication and access control mechanisms to restrict
      the usage of sensitive data.

15.

16.  Contributors

   The following people all contributed significantly to the initial
   YANG draft:

    - Andy Bierman (andybierman.com)
    - Balazs Lengyel (Ericsson)
    - David Partain (Ericsson)
    - Juergen Schoenwaelder (Jacobs University Bremen)
    - Phil Shafer (Juniper Networks)

16.

17.  References

16.1.

17.1.  Normative References

   [IEEE.754]
              Institute of Electrical and Electronics Engineers,
              "Standard for Binary Floating-Point Arithmetic",
              IEEE Standard 754, August 1985.

   [ISO.10646]
              International Organization for Standardization,
              "Information Technology - Universal Multiple-octet coded
              Character Set (UCS) - Part 1: Architecture and Basic
              Multilingual Plane", ISO Standard 10646-1, May 1993.

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

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, November 2003.

   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              January 2004.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, January 2005.

   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 4648, October 2006.

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

   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, January 2008.

   [RFC5277]  Chisholm, S. and H. Trevino, "NETCONF Event
              Notifications", RFC 5277, July 2008.

   [XML-NAMES]
              Tobin, R., Bray, T., Hollander, D., and A. Layman,
              "Namespaces in XML 1.0 (Second Edition)", World Wide Web
              Consortium Recommendation REC-xml-names-20060816,
              August 2006,
              <http://www.w3.org/TR/2006/REC-xml-names-20060816>.

   [XPATH]    Clark, J. and S. DeRose, "XML Path Language (XPath)
              Version 1.0", World Wide Web Consortium
              Recommendation REC-xpath-19991116, November 1999,
              <http://www.w3.org/TR/1999/REC-xpath-19991116>.

   [XSD-TYPES]
              Biron, P V. and A. Malhotra, "XML Schema Part 2: Datatypes
              Second Edition", W3C REC REC-xmlschema-2-20041028,
              October 2004.

16.2.

17.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.

Appendix A.  ChangeLog

A.1.  Version -02

   o  Added module update rules. (yang-00000)

   o  Added "refine" statement as a substatement to "uses". (yang-00088)

   o  Allow "augment" on top-level and in "uses" only. (yang-00088)

   o  Allow "when" on all data defintion statements. (yang-00088)

   o  Added section "Constraints" and clarified when constraints are
      enforced. (yang-00172)

   o  Added "feature" and "if-feature" statements. (yang-00750)

   o  Added "prefix" as a substatement to "belongs-to". (yang-00755)

   o  Added section on Conformance. (yang-01281)

   o  Added "deviation" statement. (yang-01281)

   o  Added "identity" statement and "identityref" type. (yang-01339)

   o  Aligned grammar for "enum" with text.

A.2.  Version -01

   o  Removed "Appendix A.  Derived YANG Types".

   o  Removed "Appendix C.  XML Schema Considerations".

   o  Removed "Appendix F.  Why We Need a New Modeling Language".

   o  Moved "Appendix B.  YIN" to its own section.

   o  Moved "Appendix D.  YANG ABNF Grammar" to its own section.

   o  Moved "Appendix E.  Error Responses for YANG Related Errors" into
      its own section.

   o  The "input" and "output" nodes are now implicitly created by the
      "rpc" statement, in order for augmentation of these nodes to work
      correctly.

   o  Allow "config" in "choice".

   o  Added reference to XPath 1.0.

   o  Using an XPath function "current()" instead of the variable
      "$this".

   o  Clarified that a "must" expression in a configuration node must
      not reference non-configuration nodes.

   o  Added XML encoding rules and usage examples for rpc and
      notification.

   o  Removed requirement that refinements are specified in the same
      order as in the original grouping's definition.

   o  Fixed whitespace issues in the ABNF grammar.

   o  Added the term "mandatory node", and refer to it in the
      description of augment (see Section 7.15), and choice (see
      Section 7.9.3).

   o  Added support for multiple "pattern" statements in "type".

   o  Several clarifications and fixed typos.

A.2.

A.3.  Version -00

   Changes from draft-bjorklund-netconf-yang-02.txt

   o  Fixed bug in grammar for bit-stmt

   o  Fixed bugs in example XPath expressions

   o  Added keyword 'presence' to the YIN mapping table

Author's Address

   Martin Bjorklund (editor)
   Tail-f Systems

   Email: mbj@tail-f.com

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgment

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