draft-ietf-netmod-rfc6020bis-05.txt   draft-ietf-netmod-rfc6020bis-06.txt 
Network Working Group M. Bjorklund, Ed. Network Working Group M. Bjorklund, Ed.
Internet-Draft Tail-f Systems Internet-Draft Tail-f Systems
Obsoletes: 6020 (if approved) May 4, 2015 Obsoletes: 6020 (if approved) July 6, 2015
Intended status: Standards Track Intended status: Standards Track
Expires: November 5, 2015 Expires: January 7, 2016
YANG - A Data Modeling Language for the Network Configuration Protocol YANG - A Data Modeling Language for the Network Configuration Protocol
(NETCONF) (NETCONF)
draft-ietf-netmod-rfc6020bis-05 draft-ietf-netmod-rfc6020bis-06
Abstract Abstract
YANG is a data modeling language used to model configuration and YANG is a data modeling language used to model configuration and
state data manipulated by the Network Configuration Protocol state data manipulated by the Network Configuration Protocol
(NETCONF), NETCONF remote procedure calls, and NETCONF notifications. (NETCONF), NETCONF remote procedure calls, and NETCONF notifications.
This document obsoletes RFC 6020. This document obsoletes RFC 6020.
Status of This Memo Status of This Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 5, 2015. This Internet-Draft will expire on January 7, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 4 skipping to change at page 3, line 4
5.1.2. Module Hierarchies . . . . . . . . . . . . . . . . . 29 5.1.2. Module Hierarchies . . . . . . . . . . . . . . . . . 29
5.2. File Layout . . . . . . . . . . . . . . . . . . . . . . . 30 5.2. File Layout . . . . . . . . . . . . . . . . . . . . . . . 30
5.3. XML Namespaces . . . . . . . . . . . . . . . . . . . . . 31 5.3. XML Namespaces . . . . . . . . . . . . . . . . . . . . . 31
5.3.1. YANG XML Namespace . . . . . . . . . . . . . . . . . 31 5.3.1. YANG XML Namespace . . . . . . . . . . . . . . . . . 31
5.4. Resolving Grouping, Type, and Identity Names . . . . . . 31 5.4. Resolving Grouping, Type, and Identity Names . . . . . . 31
5.5. Nested Typedefs and Groupings . . . . . . . . . . . . . . 31 5.5. Nested Typedefs and Groupings . . . . . . . . . . . . . . 31
5.6. Conformance . . . . . . . . . . . . . . . . . . . . . . . 32 5.6. Conformance . . . . . . . . . . . . . . . . . . . . . . . 32
5.6.1. Basic Behavior . . . . . . . . . . . . . . . . . . . 33 5.6.1. Basic Behavior . . . . . . . . . . . . . . . . . . . 33
5.6.2. Optional Features . . . . . . . . . . . . . . . . . . 33 5.6.2. Optional Features . . . . . . . . . . . . . . . . . . 33
5.6.3. Deviations . . . . . . . . . . . . . . . . . . . . . 33 5.6.3. Deviations . . . . . . . . . . . . . . . . . . . . . 33
5.6.4. Announcing Conformance Information in the <hello> 5.6.4. Implementing a Module . . . . . . . . . . . . . . . . 34
Message . . . . . . . . . . . . . . . . . . . . . . . 34 5.6.5. Announcing Conformance Information in NETCONF . . . . 37
5.7. Data Store Modification . . . . . . . . . . . . . . . . . 34 5.7. Data Store Modification . . . . . . . . . . . . . . . . . 38
6. YANG Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 35 6. YANG Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 38
6.1. Lexical Tokenization . . . . . . . . . . . . . . . . . . 35 6.1. Lexical Tokenization . . . . . . . . . . . . . . . . . . 38
6.1.1. Comments . . . . . . . . . . . . . . . . . . . . . . 35 6.1.1. Comments . . . . . . . . . . . . . . . . . . . . . . 38
6.1.2. Tokens . . . . . . . . . . . . . . . . . . . . . . . 35 6.1.2. Tokens . . . . . . . . . . . . . . . . . . . . . . . 38
6.1.3. Quoting . . . . . . . . . . . . . . . . . . . . . . . 35 6.1.3. Quoting . . . . . . . . . . . . . . . . . . . . . . . 39
6.2. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 37 6.2. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 40
6.2.1. Identifiers and Their Namespaces . . . . . . . . . . 37 6.2.1. Identifiers and Their Namespaces . . . . . . . . . . 40
6.3. Statements . . . . . . . . . . . . . . . . . . . . . . . 38 6.3. Statements . . . . . . . . . . . . . . . . . . . . . . . 41
6.3.1. Language Extensions . . . . . . . . . . . . . . . . . 38 6.3.1. Language Extensions . . . . . . . . . . . . . . . . . 41
6.4. XPath Evaluations . . . . . . . . . . . . . . . . . . . . 39 6.4. XPath Evaluations . . . . . . . . . . . . . . . . . . . . 42
6.4.1. XPath Context . . . . . . . . . . . . . . . . . . . . 39 6.4.1. XPath Context . . . . . . . . . . . . . . . . . . . . 42
6.5. Schema Node Identifier . . . . . . . . . . . . . . . . . 41 6.5. Schema Node Identifier . . . . . . . . . . . . . . . . . 44
7. YANG Statements . . . . . . . . . . . . . . . . . . . . . . . 41 7. YANG Statements . . . . . . . . . . . . . . . . . . . . . . . 44
7.1. The module Statement . . . . . . . . . . . . . . . . . . 42 7.1. The module Statement . . . . . . . . . . . . . . . . . . 45
7.1.1. The module's Substatements . . . . . . . . . . . . . 43 7.1.1. The module's Substatements . . . . . . . . . . . . . 46
7.1.2. The yang-version Statement . . . . . . . . . . . . . 44 7.1.2. The yang-version Statement . . . . . . . . . . . . . 47
7.1.3. The namespace Statement . . . . . . . . . . . . . . . 45 7.1.3. The namespace Statement . . . . . . . . . . . . . . . 48
7.1.4. The prefix Statement . . . . . . . . . . . . . . . . 45 7.1.4. The prefix Statement . . . . . . . . . . . . . . . . 48
7.1.5. The import Statement . . . . . . . . . . . . . . . . 45 7.1.5. The import Statement . . . . . . . . . . . . . . . . 48
7.1.6. The include Statement . . . . . . . . . . . . . . . . 46 7.1.6. The include Statement . . . . . . . . . . . . . . . . 49
7.1.7. The organization Statement . . . . . . . . . . . . . 47 7.1.7. The organization Statement . . . . . . . . . . . . . 50
7.1.8. The contact Statement . . . . . . . . . . . . . . . . 47 7.1.8. The contact Statement . . . . . . . . . . . . . . . . 50
7.1.9. The revision Statement . . . . . . . . . . . . . . . 47 7.1.9. The revision Statement . . . . . . . . . . . . . . . 50
7.1.10. Usage Example . . . . . . . . . . . . . . . . . . . . 48 7.1.10. Usage Example . . . . . . . . . . . . . . . . . . . . 51
7.2. The submodule Statement . . . . . . . . . . . . . . . . . 49 7.2. The submodule Statement . . . . . . . . . . . . . . . . . 52
7.2.1. The submodule's Substatements . . . . . . . . . . . . 50 7.2.1. The submodule's Substatements . . . . . . . . . . . . 53
7.2.2. The belongs-to Statement . . . . . . . . . . . . . . 51 7.2.2. The belongs-to Statement . . . . . . . . . . . . . . 54
7.2.3. Usage Example . . . . . . . . . . . . . . . . . . . . 52 7.2.3. Usage Example . . . . . . . . . . . . . . . . . . . . 55
7.3. The typedef Statement . . . . . . . . . . . . . . . . . . 52 7.3. The typedef Statement . . . . . . . . . . . . . . . . . . 55
7.3.1. The typedef's Substatements . . . . . . . . . . . . . 53 7.3.1. The typedef's Substatements . . . . . . . . . . . . . 56
7.3.2. The typedef's type Statement . . . . . . . . . . . . 53 7.3.2. The typedef's type Statement . . . . . . . . . . . . 56
7.3.3. The units Statement . . . . . . . . . . . . . . . . . 53 7.3.3. The units Statement . . . . . . . . . . . . . . . . . 56
7.3.4. The typedef's default Statement . . . . . . . . . . . 53 7.3.4. The typedef's default Statement . . . . . . . . . . . 56
7.3.5. Usage Example . . . . . . . . . . . . . . . . . . . . 54 7.3.5. Usage Example . . . . . . . . . . . . . . . . . . . . 57
7.4. The type Statement . . . . . . . . . . . . . . . . . . . 54 7.4. The type Statement . . . . . . . . . . . . . . . . . . . 57
7.4.1. The type's Substatements . . . . . . . . . . . . . . 54 7.4.1. The type's Substatements . . . . . . . . . . . . . . 57
7.5. The container Statement . . . . . . . . . . . . . . . . . 54 7.5. The container Statement . . . . . . . . . . . . . . . . . 57
7.5.1. Containers with Presence . . . . . . . . . . . . . . 55 7.5.1. Containers with Presence . . . . . . . . . . . . . . 58
7.5.2. The container's Substatements . . . . . . . . . . . . 55 7.5.2. The container's Substatements . . . . . . . . . . . . 58
7.5.3. The must Statement . . . . . . . . . . . . . . . . . 56 7.5.3. The must Statement . . . . . . . . . . . . . . . . . 59
7.5.4. The must's Substatements . . . . . . . . . . . . . . 57 7.5.4. The must's Substatements . . . . . . . . . . . . . . 60
7.5.5. The presence Statement . . . . . . . . . . . . . . . 58 7.5.5. The presence Statement . . . . . . . . . . . . . . . 61
7.5.6. The container's Child Node Statements . . . . . . . . 58 7.5.6. The container's Child Node Statements . . . . . . . . 61
7.5.7. XML Mapping Rules . . . . . . . . . . . . . . . . . . 58 7.5.7. XML Mapping Rules . . . . . . . . . . . . . . . . . . 61
7.5.8. NETCONF <edit-config> Operations . . . . . . . . . . 59 7.5.8. NETCONF <edit-config> Operations . . . . . . . . . . 62
7.5.9. Usage Example . . . . . . . . . . . . . . . . . . . . 59 7.5.9. Usage Example . . . . . . . . . . . . . . . . . . . . 62
7.6. The leaf Statement . . . . . . . . . . . . . . . . . . . 60 7.6. The leaf Statement . . . . . . . . . . . . . . . . . . . 63
7.6.1. The leaf's default value . . . . . . . . . . . . . . 61 7.6.1. The leaf's default value . . . . . . . . . . . . . . 64
7.6.2. The leaf's Substatements . . . . . . . . . . . . . . 61 7.6.2. The leaf's Substatements . . . . . . . . . . . . . . 64
7.6.3. The leaf's type Statement . . . . . . . . . . . . . . 62 7.6.3. The leaf's type Statement . . . . . . . . . . . . . . 65
7.6.4. The leaf's default Statement . . . . . . . . . . . . 62 7.6.4. The leaf's default Statement . . . . . . . . . . . . 65
7.6.5. The leaf's mandatory Statement . . . . . . . . . . . 62 7.6.5. The leaf's mandatory Statement . . . . . . . . . . . 65
7.6.6. XML Mapping Rules . . . . . . . . . . . . . . . . . . 62 7.6.6. XML Mapping Rules . . . . . . . . . . . . . . . . . . 65
7.6.7. NETCONF <edit-config> Operations . . . . . . . . . . 63 7.6.7. NETCONF <edit-config> Operations . . . . . . . . . . 66
7.6.8. Usage Example . . . . . . . . . . . . . . . . . . . . 63 7.6.8. Usage Example . . . . . . . . . . . . . . . . . . . . 66
7.7. The leaf-list Statement . . . . . . . . . . . . . . . . . 64 7.7. The leaf-list Statement . . . . . . . . . . . . . . . . . 67
7.7.1. Ordering . . . . . . . . . . . . . . . . . . . . . . 64 7.7.1. Ordering . . . . . . . . . . . . . . . . . . . . . . 67
7.7.2. The leaf-list's default values . . . . . . . . . . . 65 7.7.2. The leaf-list's default values . . . . . . . . . . . 68
7.7.3. The leaf-list's Substatements . . . . . . . . . . . . 66 7.7.3. The leaf-list's Substatements . . . . . . . . . . . . 69
7.7.4. The leaf-list's default Statement . . . . . . . . . . 66 7.7.4. The leaf-list's default Statement . . . . . . . . . . 69
7.7.5. The min-elements Statement . . . . . . . . . . . . . 66 7.7.5. The min-elements Statement . . . . . . . . . . . . . 69
7.7.6. The max-elements Statement . . . . . . . . . . . . . 67 7.7.6. The max-elements Statement . . . . . . . . . . . . . 70
7.7.7. The ordered-by Statement . . . . . . . . . . . . . . 67 7.7.7. The ordered-by Statement . . . . . . . . . . . . . . 70
7.7.8. XML Mapping Rules . . . . . . . . . . . . . . . . . . 68 7.7.8. XML Mapping Rules . . . . . . . . . . . . . . . . . . 71
7.7.9. NETCONF <edit-config> Operations . . . . . . . . . . 68 7.7.9. NETCONF <edit-config> Operations . . . . . . . . . . 71
7.7.10. Usage Example . . . . . . . . . . . . . . . . . . . . 69 7.7.10. Usage Example . . . . . . . . . . . . . . . . . . . . 72
7.8. The list Statement . . . . . . . . . . . . . . . . . . . 71 7.8. The list Statement . . . . . . . . . . . . . . . . . . . 74
7.8.1. The list's Substatements . . . . . . . . . . . . . . 71 7.8.1. The list's Substatements . . . . . . . . . . . . . . 74
7.8.2. The list's key Statement . . . . . . . . . . . . . . 72 7.8.2. The list's key Statement . . . . . . . . . . . . . . 75
7.8.3. The list's unique Statement . . . . . . . . . . . . . 73 7.8.3. The list's unique Statement . . . . . . . . . . . . . 76
7.8.4. The list's Child Node Statements . . . . . . . . . . 74 7.8.4. The list's Child Node Statements . . . . . . . . . . 77
7.8.5. XML Mapping Rules . . . . . . . . . . . . . . . . . . 74 7.8.5. XML Mapping Rules . . . . . . . . . . . . . . . . . . 77
7.8.6. NETCONF <edit-config> Operations . . . . . . . . . . 75 7.8.6. NETCONF <edit-config> Operations . . . . . . . . . . 78
7.8.7. Usage Example . . . . . . . . . . . . . . . . . . . . 76 7.8.7. Usage Example . . . . . . . . . . . . . . . . . . . . 79
7.9. The choice Statement . . . . . . . . . . . . . . . . . . 79 7.9. The choice Statement . . . . . . . . . . . . . . . . . . 82
7.9.1. The choice's Substatements . . . . . . . . . . . . . 79 7.9.1. The choice's Substatements . . . . . . . . . . . . . 82
7.9.2. The choice's case Statement . . . . . . . . . . . . . 80 7.9.2. The choice's case Statement . . . . . . . . . . . . . 83
7.9.3. The choice's default Statement . . . . . . . . . . . 81 7.9.3. The choice's default Statement . . . . . . . . . . . 84
7.9.4. The choice's mandatory Statement . . . . . . . . . . 83 7.9.4. The choice's mandatory Statement . . . . . . . . . . 86
7.9.5. XML Mapping Rules . . . . . . . . . . . . . . . . . . 83 7.9.5. XML Mapping Rules . . . . . . . . . . . . . . . . . . 86
7.9.6. NETCONF <edit-config> Operations . . . . . . . . . . 83 7.9.6. NETCONF <edit-config> Operations . . . . . . . . . . 86
7.9.7. Usage Example . . . . . . . . . . . . . . . . . . . . 83 7.9.7. Usage Example . . . . . . . . . . . . . . . . . . . . 86
7.10. The anydata Statement . . . . . . . . . . . . . . . . . . 84 7.10. The anydata Statement . . . . . . . . . . . . . . . . . . 87
7.10.1. The anydata's Substatements . . . . . . . . . . . . 85 7.10.1. The anydata's Substatements . . . . . . . . . . . . 88
7.10.2. XML Mapping Rules . . . . . . . . . . . . . . . . . 85 7.10.2. XML Mapping Rules . . . . . . . . . . . . . . . . . 88
7.10.3. NETCONF <edit-config> Operations . . . . . . . . . . 85 7.10.3. NETCONF <edit-config> Operations . . . . . . . . . . 88
7.10.4. Usage Example . . . . . . . . . . . . . . . . . . . 86 7.10.4. Usage Example . . . . . . . . . . . . . . . . . . . 89
7.11. The anyxml Statement . . . . . . . . . . . . . . . . . . 86 7.11. The anyxml Statement . . . . . . . . . . . . . . . . . . 89
7.11.1. The anyxml's Substatements . . . . . . . . . . . . . 87 7.11.1. The anyxml's Substatements . . . . . . . . . . . . . 90
7.11.2. XML Mapping Rules . . . . . . . . . . . . . . . . . 87 7.11.2. XML Mapping Rules . . . . . . . . . . . . . . . . . 90
7.11.3. NETCONF <edit-config> Operations . . . . . . . . . . 87 7.11.3. NETCONF <edit-config> Operations . . . . . . . . . . 90
7.11.4. Usage Example . . . . . . . . . . . . . . . . . . . 88 7.11.4. Usage Example . . . . . . . . . . . . . . . . . . . 91
7.12. The grouping Statement . . . . . . . . . . . . . . . . . 88 7.12. The grouping Statement . . . . . . . . . . . . . . . . . 91
7.12.1. The grouping's Substatements . . . . . . . . . . . . 89 7.12.1. The grouping's Substatements . . . . . . . . . . . . 92
7.12.2. Usage Example . . . . . . . . . . . . . . . . . . . 89 7.12.2. Usage Example . . . . . . . . . . . . . . . . . . . 92
7.13. The uses Statement . . . . . . . . . . . . . . . . . . . 90 7.13. The uses Statement . . . . . . . . . . . . . . . . . . . 93
7.13.1. The uses's Substatements . . . . . . . . . . . . . . 90 7.13.1. The uses's Substatements . . . . . . . . . . . . . . 93
7.13.2. The refine Statement . . . . . . . . . . . . . . . . 90 7.13.2. The refine Statement . . . . . . . . . . . . . . . . 93
7.13.3. XML Mapping Rules . . . . . . . . . . . . . . . . . 91 7.13.3. XML Mapping Rules . . . . . . . . . . . . . . . . . 94
7.13.4. Usage Example . . . . . . . . . . . . . . . . . . . 91 7.13.4. Usage Example . . . . . . . . . . . . . . . . . . . 94
7.14. The rpc Statement . . . . . . . . . . . . . . . . . . . . 93 7.14. The rpc Statement . . . . . . . . . . . . . . . . . . . . 96
7.14.1. The rpc's Substatements . . . . . . . . . . . . . . 93 7.14.1. The rpc's Substatements . . . . . . . . . . . . . . 96
7.14.2. The input Statement . . . . . . . . . . . . . . . . 93 7.14.2. The input Statement . . . . . . . . . . . . . . . . 96
7.14.3. The output Statement . . . . . . . . . . . . . . . . 94 7.14.3. The output Statement . . . . . . . . . . . . . . . . 97
7.14.4. XML Mapping Rules . . . . . . . . . . . . . . . . . 95 7.14.4. XML Mapping Rules . . . . . . . . . . . . . . . . . 98
7.14.5. Usage Example . . . . . . . . . . . . . . . . . . . 96 7.14.5. Usage Example . . . . . . . . . . . . . . . . . . . 99
7.15. The action Statement . . . . . . . . . . . . . . . . . . 96 7.15. The action Statement . . . . . . . . . . . . . . . . . . 99
7.15.1. The action's Substatements . . . . . . . . . . . . . 97 7.15.1. The action's Substatements . . . . . . . . . . . . . 100
7.15.2. XML Mapping Rules . . . . . . . . . . . . . . . . . 97 7.15.2. XML Mapping Rules . . . . . . . . . . . . . . . . . 100
7.15.3. Usage Example . . . . . . . . . . . . . . . . . . . 98 7.15.3. Usage Example . . . . . . . . . . . . . . . . . . . 101
7.16. The notification Statement . . . . . . . . . . . . . . . 99 7.16. The notification Statement . . . . . . . . . . . . . . . 102
7.16.1. The notification's Substatements . . . . . . . . . . 100 7.16.1. The notification's Substatements . . . . . . . . . . 103
7.16.2. XML Mapping Rules . . . . . . . . . . . . . . . . . 100 7.16.2. XML Mapping Rules . . . . . . . . . . . . . . . . . 103
7.16.3. Usage Example . . . . . . . . . . . . . . . . . . . 101 7.16.3. Usage Example . . . . . . . . . . . . . . . . . . . 104
7.17. The augment Statement . . . . . . . . . . . . . . . . . . 102 7.17. The augment Statement . . . . . . . . . . . . . . . . . . 105
7.17.1. The augment's Substatements . . . . . . . . . . . . 103 7.17.1. The augment's Substatements . . . . . . . . . . . . 106
7.17.2. XML Mapping Rules . . . . . . . . . . . . . . . . . 104 7.17.2. XML Mapping Rules . . . . . . . . . . . . . . . . . 107
7.17.3. Usage Example . . . . . . . . . . . . . . . . . . . 104 7.17.3. Usage Example . . . . . . . . . . . . . . . . . . . 107
7.18. The identity Statement . . . . . . . . . . . . . . . . . 106 7.18. The identity Statement . . . . . . . . . . . . . . . . . 109
7.18.1. The identity's Substatements . . . . . . . . . . . . 106 7.18.1. The identity's Substatements . . . . . . . . . . . . 109
7.18.2. The base Statement . . . . . . . . . . . . . . . . . 106 7.18.2. The base Statement . . . . . . . . . . . . . . . . . 109
7.18.3. Usage Example . . . . . . . . . . . . . . . . . . . 107 7.18.3. Usage Example . . . . . . . . . . . . . . . . . . . 110
7.19. The extension Statement . . . . . . . . . . . . . . . . . 107 7.19. The extension Statement . . . . . . . . . . . . . . . . . 110
7.19.1. The extension's Substatements . . . . . . . . . . . 108 7.19.1. The extension's Substatements . . . . . . . . . . . 111
7.19.2. The argument Statement . . . . . . . . . . . . . . . 108 7.19.2. The argument Statement . . . . . . . . . . . . . . . 111
7.19.3. Usage Example . . . . . . . . . . . . . . . . . . . 109 7.19.3. Usage Example . . . . . . . . . . . . . . . . . . . 112
7.20. Conformance-Related Statements . . . . . . . . . . . . . 109 7.20. Conformance-Related Statements . . . . . . . . . . . . . 112
7.20.1. The feature Statement . . . . . . . . . . . . . . . 109 7.20.1. The feature Statement . . . . . . . . . . . . . . . 112
7.20.2. The if-feature Statement . . . . . . . . . . . . . . 111 7.20.2. The if-feature Statement . . . . . . . . . . . . . . 114
7.20.3. The deviation Statement . . . . . . . . . . . . . . 112 7.20.3. The deviation Statement . . . . . . . . . . . . . . 115
7.21. Common Statements . . . . . . . . . . . . . . . . . . . . 114 7.21. Common Statements . . . . . . . . . . . . . . . . . . . . 117
7.21.1. The config Statement . . . . . . . . . . . . . . . . 114 7.21.1. The config Statement . . . . . . . . . . . . . . . . 117
7.21.2. The status Statement . . . . . . . . . . . . . . . . 115 7.21.2. The status Statement . . . . . . . . . . . . . . . . 118
7.21.3. The description Statement . . . . . . . . . . . . . 116 7.21.3. The description Statement . . . . . . . . . . . . . 119
7.21.4. The reference Statement . . . . . . . . . . . . . . 116 7.21.4. The reference Statement . . . . . . . . . . . . . . 119
7.21.5. The when Statement . . . . . . . . . . . . . . . . . 116 7.21.5. The when Statement . . . . . . . . . . . . . . . . . 119
8. Constraints . . . . . . . . . . . . . . . . . . . . . . . . . 117 8. Constraints . . . . . . . . . . . . . . . . . . . . . . . . . 120
8.1. Constraints on Data . . . . . . . . . . . . . . . . . . . 117 8.1. Constraints on Data . . . . . . . . . . . . . . . . . . . 120
8.2. Hierarchy of Constraints . . . . . . . . . . . . . . . . 118 8.2. Hierarchy of Constraints . . . . . . . . . . . . . . . . 121
8.3. Constraint Enforcement Model . . . . . . . . . . . . . . 118 8.3. Constraint Enforcement Model . . . . . . . . . . . . . . 121
8.3.1. Payload Parsing . . . . . . . . . . . . . . . . . . . 118 8.3.1. Payload Parsing . . . . . . . . . . . . . . . . . . . 121
8.3.2. NETCONF <edit-config> Processing . . . . . . . . . . 119 8.3.2. NETCONF <edit-config> Processing . . . . . . . . . . 122
8.3.3. Validation . . . . . . . . . . . . . . . . . . . . . 120 8.3.3. Validation . . . . . . . . . . . . . . . . . . . . . 123
9. Built-In Types . . . . . . . . . . . . . . . . . . . . . . . 120 9. Built-In Types . . . . . . . . . . . . . . . . . . . . . . . 123
9.1. Canonical Representation . . . . . . . . . . . . . . . . 120 9.1. Canonical Representation . . . . . . . . . . . . . . . . 123
9.2. The Integer Built-In Types . . . . . . . . . . . . . . . 121 9.2. The Integer Built-In Types . . . . . . . . . . . . . . . 124
9.2.1. Lexical Representation . . . . . . . . . . . . . . . 121 9.2.1. Lexical Representation . . . . . . . . . . . . . . . 124
9.2.2. Canonical Form . . . . . . . . . . . . . . . . . . . 122 9.2.2. Canonical Form . . . . . . . . . . . . . . . . . . . 125
9.2.3. Restrictions . . . . . . . . . . . . . . . . . . . . 122 9.2.3. Restrictions . . . . . . . . . . . . . . . . . . . . 125
9.2.4. The range Statement . . . . . . . . . . . . . . . . . 122 9.2.4. The range Statement . . . . . . . . . . . . . . . . . 125
9.2.5. Usage Example . . . . . . . . . . . . . . . . . . . . 123 9.2.5. Usage Example . . . . . . . . . . . . . . . . . . . . 126
9.3. The decimal64 Built-In Type . . . . . . . . . . . . . . . 123 9.3. The decimal64 Built-In Type . . . . . . . . . . . . . . . 126
9.3.1. Lexical Representation . . . . . . . . . . . . . . . 124 9.3.1. Lexical Representation . . . . . . . . . . . . . . . 127
9.3.2. Canonical Form . . . . . . . . . . . . . . . . . . . 124 9.3.2. Canonical Form . . . . . . . . . . . . . . . . . . . 127
9.3.3. Restrictions . . . . . . . . . . . . . . . . . . . . 124 9.3.3. Restrictions . . . . . . . . . . . . . . . . . . . . 127
9.3.4. The fraction-digits Statement . . . . . . . . . . . . 124 9.3.4. The fraction-digits Statement . . . . . . . . . . . . 127
9.3.5. Usage Example . . . . . . . . . . . . . . . . . . . . 125 9.3.5. Usage Example . . . . . . . . . . . . . . . . . . . . 128
9.4. The string Built-In Type . . . . . . . . . . . . . . . . 125 9.4. The string Built-In Type . . . . . . . . . . . . . . . . 128
9.4.1. Lexical Representation . . . . . . . . . . . . . . . 125 9.4.1. Lexical Representation . . . . . . . . . . . . . . . 128
9.4.2. Canonical Form . . . . . . . . . . . . . . . . . . . 126 9.4.2. Canonical Form . . . . . . . . . . . . . . . . . . . 129
9.4.3. Restrictions . . . . . . . . . . . . . . . . . . . . 126 9.4.3. Restrictions . . . . . . . . . . . . . . . . . . . . 129
9.4.4. The length Statement . . . . . . . . . . . . . . . . 126 9.4.4. The length Statement . . . . . . . . . . . . . . . . 129
9.4.5. The pattern Statement . . . . . . . . . . . . . . . . 127 9.4.5. The pattern Statement . . . . . . . . . . . . . . . . 130
9.4.6. The modifier Statement . . . . . . . . . . . . . . . 127 9.4.6. The modifier Statement . . . . . . . . . . . . . . . 130
9.4.7. Usage Example . . . . . . . . . . . . . . . . . . . . 127 9.4.7. Usage Example . . . . . . . . . . . . . . . . . . . . 130
9.5. The boolean Built-In Type . . . . . . . . . . . . . . . . 128 9.5. The boolean Built-In Type . . . . . . . . . . . . . . . . 131
9.5.1. Lexical Representation . . . . . . . . . . . . . . . 129 9.5.1. Lexical Representation . . . . . . . . . . . . . . . 132
9.5.2. Canonical Form . . . . . . . . . . . . . . . . . . . 129 9.5.2. Canonical Form . . . . . . . . . . . . . . . . . . . 132
9.5.3. Restrictions . . . . . . . . . . . . . . . . . . . . 129 9.5.3. Restrictions . . . . . . . . . . . . . . . . . . . . 132
9.6. The enumeration Built-In Type . . . . . . . . . . . . . . 129 9.6. The enumeration Built-In Type . . . . . . . . . . . . . . 132
9.6.1. Lexical Representation . . . . . . . . . . . . . . . 129 9.6.1. Lexical Representation . . . . . . . . . . . . . . . 132
9.6.2. Canonical Form . . . . . . . . . . . . . . . . . . . 129 9.6.2. Canonical Form . . . . . . . . . . . . . . . . . . . 132
9.6.3. Restrictions . . . . . . . . . . . . . . . . . . . . 129 9.6.3. Restrictions . . . . . . . . . . . . . . . . . . . . 132
9.6.4. The enum Statement . . . . . . . . . . . . . . . . . 129 9.6.4. The enum Statement . . . . . . . . . . . . . . . . . 132
9.6.5. Usage Example . . . . . . . . . . . . . . . . . . . . 130 9.6.5. Usage Example . . . . . . . . . . . . . . . . . . . . 133
9.7. The bits Built-In Type . . . . . . . . . . . . . . . . . 132 9.7. The bits Built-In Type . . . . . . . . . . . . . . . . . 135
9.7.1. Restrictions . . . . . . . . . . . . . . . . . . . . 132 9.7.1. Restrictions . . . . . . . . . . . . . . . . . . . . 135
9.7.2. Lexical Representation . . . . . . . . . . . . . . . 132 9.7.2. Lexical Representation . . . . . . . . . . . . . . . 135
9.7.3. Canonical Form . . . . . . . . . . . . . . . . . . . 132 9.7.3. Canonical Form . . . . . . . . . . . . . . . . . . . 135
9.7.4. The bit Statement . . . . . . . . . . . . . . . . . . 132 9.7.4. The bit Statement . . . . . . . . . . . . . . . . . . 135
9.7.5. Usage Example . . . . . . . . . . . . . . . . . . . . 133 9.7.5. Usage Example . . . . . . . . . . . . . . . . . . . . 136
9.8. The binary Built-In Type . . . . . . . . . . . . . . . . 134 9.8. The binary Built-In Type . . . . . . . . . . . . . . . . 137
9.8.1. Restrictions . . . . . . . . . . . . . . . . . . . . 134 9.8.1. Restrictions . . . . . . . . . . . . . . . . . . . . 137
9.8.2. Lexical Representation . . . . . . . . . . . . . . . 134 9.8.2. Lexical Representation . . . . . . . . . . . . . . . 137
9.8.3. Canonical Form . . . . . . . . . . . . . . . . . . . 134 9.8.3. Canonical Form . . . . . . . . . . . . . . . . . . . 137
9.9. The leafref Built-In Type . . . . . . . . . . . . . . . . 134 9.9. The leafref Built-In Type . . . . . . . . . . . . . . . . 137
9.9.1. Restrictions . . . . . . . . . . . . . . . . . . . . 135 9.9.1. Restrictions . . . . . . . . . . . . . . . . . . . . 138
9.9.2. The path Statement . . . . . . . . . . . . . . . . . 135 9.9.2. The path Statement . . . . . . . . . . . . . . . . . 138
9.9.3. The require-instance Statement . . . . . . . . . . . 135 9.9.3. The require-instance Statement . . . . . . . . . . . 138
9.9.4. Lexical Representation . . . . . . . . . . . . . . . 136 9.9.4. Lexical Representation . . . . . . . . . . . . . . . 139
9.9.5. Canonical Form . . . . . . . . . . . . . . . . . . . 136 9.9.5. Canonical Form . . . . . . . . . . . . . . . . . . . 139
9.9.6. Usage Example . . . . . . . . . . . . . . . . . . . . 136 9.9.6. Usage Example . . . . . . . . . . . . . . . . . . . . 139
9.10. The identityref Built-In Type . . . . . . . . . . . . . . 140 9.10. The identityref Built-In Type . . . . . . . . . . . . . . 143
9.10.1. Restrictions . . . . . . . . . . . . . . . . . . . . 140 9.10.1. Restrictions . . . . . . . . . . . . . . . . . . . . 143
9.10.2. The identityref's base Statement . . . . . . . . . . 140 9.10.2. The identityref's base Statement . . . . . . . . . . 143
9.10.3. Lexical Representation . . . . . . . . . . . . . . . 140 9.10.3. Lexical Representation . . . . . . . . . . . . . . . 143
9.10.4. Canonical Form . . . . . . . . . . . . . . . . . . . 141 9.10.4. Canonical Form . . . . . . . . . . . . . . . . . . . 144
9.10.5. Usage Example . . . . . . . . . . . . . . . . . . . 141 9.10.5. Usage Example . . . . . . . . . . . . . . . . . . . 144
9.11. The empty Built-In Type . . . . . . . . . . . . . . . . . 142 9.11. The empty Built-In Type . . . . . . . . . . . . . . . . . 145
9.11.1. Restrictions . . . . . . . . . . . . . . . . . . . . 142 9.11.1. Restrictions . . . . . . . . . . . . . . . . . . . . 145
9.11.2. Lexical Representation . . . . . . . . . . . . . . . 142 9.11.2. Lexical Representation . . . . . . . . . . . . . . . 145
9.11.3. Canonical Form . . . . . . . . . . . . . . . . . . . 142 9.11.3. Canonical Form . . . . . . . . . . . . . . . . . . . 145
9.11.4. Usage Example . . . . . . . . . . . . . . . . . . . 142 9.11.4. Usage Example . . . . . . . . . . . . . . . . . . . 145
9.12. The union Built-In Type . . . . . . . . . . . . . . . . . 143 9.12. The union Built-In Type . . . . . . . . . . . . . . . . . 146
9.12.1. Restrictions . . . . . . . . . . . . . . . . . . . . 143 9.12.1. Restrictions . . . . . . . . . . . . . . . . . . . . 146
9.12.2. Lexical Representation . . . . . . . . . . . . . . . 143 9.12.2. Lexical Representation . . . . . . . . . . . . . . . 146
9.12.3. Canonical Form . . . . . . . . . . . . . . . . . . . 143 9.12.3. Canonical Form . . . . . . . . . . . . . . . . . . . 146
9.12.4. Usage Example . . . . . . . . . . . . . . . . . . . 143 9.12.4. Usage Example . . . . . . . . . . . . . . . . . . . 146
9.13. The instance-identifier Built-In Type . . . . . . . . . . 144 9.13. The instance-identifier Built-In Type . . . . . . . . . . 147
9.13.1. Restrictions . . . . . . . . . . . . . . . . . . . . 145 9.13.1. Restrictions . . . . . . . . . . . . . . . . . . . . 148
9.13.2. Lexical Representation . . . . . . . . . . . . . . . 145 9.13.2. Lexical Representation . . . . . . . . . . . . . . . 148
9.13.3. Canonical Form . . . . . . . . . . . . . . . . . . . 145 9.13.3. Canonical Form . . . . . . . . . . . . . . . . . . . 148
9.13.4. Usage Example . . . . . . . . . . . . . . . . . . . 145 9.13.4. Usage Example . . . . . . . . . . . . . . . . . . . 148
10. XPath Functions . . . . . . . . . . . . . . . . . . . . . . . 146 10. XPath Functions . . . . . . . . . . . . . . . . . . . . . . . 149
10.1. Functions for Node Sets . . . . . . . . . . . . . . . . 146 10.1. Functions for Node Sets . . . . . . . . . . . . . . . . 149
10.1.1. current() . . . . . . . . . . . . . . . . . . . . . 146 10.1.1. current() . . . . . . . . . . . . . . . . . . . . . 149
10.2. Functions for Strings . . . . . . . . . . . . . . . . . 146 10.2. Functions for Strings . . . . . . . . . . . . . . . . . 149
10.2.1. re-match() . . . . . . . . . . . . . . . . . . . . . 146 10.2.1. re-match() . . . . . . . . . . . . . . . . . . . . . 149
10.3. Functions for the YANG Types "leafref" and "instance- 10.3. Functions for the YANG Types "leafref" and "instance-
identifier" . . . . . . . . . . . . . . . . . . . . . . 147 identifier" . . . . . . . . . . . . . . . . . . . . . . 150
10.3.1. deref() . . . . . . . . . . . . . . . . . . . . . . 147 10.3.1. deref() . . . . . . . . . . . . . . . . . . . . . . 150
10.4. Functions for the YANG Type "identityref" . . . . . . . 148 10.4. Functions for the YANG Type "identityref" . . . . . . . 151
10.4.1. derived-from() . . . . . . . . . . . . . . . . . . . 148 10.4.1. derived-from() . . . . . . . . . . . . . . . . . . . 151
10.4.2. derived-from-or-self() . . . . . . . . . . . . . . . 148 10.4.2. derived-from-or-self() . . . . . . . . . . . . . . . 151
10.5. Functions for the YANG Type "enumeration" . . . . . . . 149 10.5. Functions for the YANG Type "enumeration" . . . . . . . 152
10.5.1. enum-value() . . . . . . . . . . . . . . . . . . . . 149 10.5.1. enum-value() . . . . . . . . . . . . . . . . . . . . 152
10.6. Functions for the YANG Type "bits" . . . . . . . . . . . 150 10.6. Functions for the YANG Type "bits" . . . . . . . . . . . 153
10.6.1. bit-is-set() . . . . . . . . . . . . . . . . . . . . 150 10.6.1. bit-is-set() . . . . . . . . . . . . . . . . . . . . 153
11. Updating a Module . . . . . . . . . . . . . . . . . . . . . . 151 11. Updating a Module . . . . . . . . . . . . . . . . . . . . . . 154
12. YIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 12. YIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
12.1. Formal YIN Definition . . . . . . . . . . . . . . . . . 154 12.1. Formal YIN Definition . . . . . . . . . . . . . . . . . 157
12.1.1. Usage Example . . . . . . . . . . . . . . . . . . . 156 12.1.1. Usage Example . . . . . . . . . . . . . . . . . . . 159
13. YANG ABNF Grammar . . . . . . . . . . . . . . . . . . . . . . 157 13. YANG ABNF Grammar . . . . . . . . . . . . . . . . . . . . . . 160
14. Error Responses for YANG Related Errors . . . . . . . . . . . 181 14. Error Responses for YANG Related Errors . . . . . . . . . . . 184
14.1. Error Message for Data That Violates a unique Statement 181 14.1. Error Message for Data That Violates a unique Statement 184
14.2. Error Message for Data That Violates a max-elements 14.2. Error Message for Data That Violates a max-elements
Statement . . . . . . . . . . . . . . . . . . . . . . . 182 Statement . . . . . . . . . . . . . . . . . . . . . . . 185
14.3. Error Message for Data That Violates a min-elements 14.3. Error Message for Data That Violates a min-elements
Statement . . . . . . . . . . . . . . . . . . . . . . . 182 Statement . . . . . . . . . . . . . . . . . . . . . . . 185
14.4. Error Message for Data That Violates a must Statement . 182 14.4. Error Message for Data That Violates a must Statement . 185
14.5. Error Message for Data That Violates a require-instance 14.5. Error Message for Data That Violates a require-instance
Statement . . . . . . . . . . . . . . . . . . . . . . . 183 Statement . . . . . . . . . . . . . . . . . . . . . . . 186
14.6. Error Message for Data That Does Not Match a leafref 14.6. Error Message for Data That Does Not Match a leafref
Type . . . . . . . . . . . . . . . . . . . . . . . . . . 183 Type . . . . . . . . . . . . . . . . . . . . . . . . . . 186
14.7. Error Message for Data That Violates a mandatory choice 14.7. Error Message for Data That Violates a mandatory choice
Statement . . . . . . . . . . . . . . . . . . . . . . . 183 Statement . . . . . . . . . . . . . . . . . . . . . . . 186
14.8. Error Message for the "insert" Operation . . . . . . . . 183 14.8. Error Message for the "insert" Operation . . . . . . . . 186
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 184 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 187
15.1. Media type application/yang . . . . . . . . . . . . . . 185 15.1. Media type application/yang . . . . . . . . . . . . . . 188
15.2. Media type application/yin+xml . . . . . . . . . . . . . 186 15.2. Media type application/yin+xml . . . . . . . . . . . . . 189
16. Security Considerations . . . . . . . . . . . . . . . . . . . 188 16. Security Considerations . . . . . . . . . . . . . . . . . . . 191
17. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 188 17. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 191
18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 189 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 192
19. ChangeLog . . . . . . . . . . . . . . . . . . . . . . . . . . 189 19. ChangeLog . . . . . . . . . . . . . . . . . . . . . . . . . . 192
19.1. Version -05 . . . . . . . . . . . . . . . . . . . . . . 189 19.1. Version -06 . . . . . . . . . . . . . . . . . . . . . . 192
19.2. Version -04 . . . . . . . . . . . . . . . . . . . . . . 189 19.2. Version -05 . . . . . . . . . . . . . . . . . . . . . . 192
19.3. Version -03 . . . . . . . . . . . . . . . . . . . . . . 189 19.3. Version -04 . . . . . . . . . . . . . . . . . . . . . . 192
19.4. Version -02 . . . . . . . . . . . . . . . . . . . . . . 190 19.4. Version -03 . . . . . . . . . . . . . . . . . . . . . . 192
19.5. Version -01 . . . . . . . . . . . . . . . . . . . . . . 190 19.5. Version -02 . . . . . . . . . . . . . . . . . . . . . . 193
19.6. Version -00 . . . . . . . . . . . . . . . . . . . . . . 190 19.6. Version -01 . . . . . . . . . . . . . . . . . . . . . . 193
20. References . . . . . . . . . . . . . . . . . . . . . . . . . 190 19.7. Version -00 . . . . . . . . . . . . . . . . . . . . . . 193
20.1. Normative References . . . . . . . . . . . . . . . . . . 191 20. References . . . . . . . . . . . . . . . . . . . . . . . . . 194
20.2. Informative References . . . . . . . . . . . . . . . . . 192 20.1. Normative References . . . . . . . . . . . . . . . . . . 194
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 193 20.2. Informative References . . . . . . . . . . . . . . . . . 195
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 196
1. Introduction 1. Introduction
YANG is a data modeling language used to model configuration and YANG is a data modeling language used to model configuration and
state data manipulated by the Network Configuration Protocol state data manipulated by the Network Configuration Protocol
(NETCONF), NETCONF remote procedure calls, and NETCONF notifications. (NETCONF), NETCONF remote procedure calls, and NETCONF notifications.
YANG is used to model the operations and content layers of NETCONF YANG is used to model the operations and content layers of NETCONF
(see the NETCONF Configuration Protocol [RFC6241], Section 1.2). (see the NETCONF Configuration Protocol [RFC6241], Section 1.2).
This document describes the syntax and semantics of the YANG This document describes the syntax and semantics of the YANG
skipping to change at page 10, line 5 skipping to change at page 10, line 7
o Allow identities to be derived from multiple base identities (see o Allow identities to be derived from multiple base identities (see
Section 7.18 and Section 9.10). Section 7.18 and Section 9.10).
o Allow enumerations to be subtyped (see Section 9.6). o Allow enumerations to be subtyped (see Section 9.6).
o Allow leaf-lists to have default values (see Section 7.7.2). o Allow leaf-lists to have default values (see Section 7.7.2).
o Use [RFC7405] syntax for case-sensitive strings in the grammar. o Use [RFC7405] syntax for case-sensitive strings in the grammar.
o Changed the module advertisement mechanism (see Section 5.6.4). o Changed the module advertisement mechanism (see Section 5.6.5).
o Changed the scoping rules for definitions in submodules. A o Changed the scoping rules for definitions in submodules. A
submodule can now reference all defintions in all submodules that submodule can now reference all defintions in all submodules that
belong to the same module, without using the "include" statement. belong to the same module, without using the "include" statement.
o Added a new statement "action" that is used to define operations o Added a new statement "action" that is used to define operations
tied to data nodes. tied to data nodes.
o Allow notifications to be tied to data nodes. o Allow notifications to be tied to data nodes.
skipping to change at page 34, line 23 skipping to change at page 34, line 23
that could not succeed. that could not succeed.
Device deviations are declared using the "deviation" statement, which Device deviations are declared using the "deviation" statement, which
takes as its argument a string that identifies a node in the schema takes as its argument a string that identifies a node in the schema
tree. The contents of the statement details the manner in which the tree. The contents of the statement details the manner in which the
device implementation deviates from the contract as defined in the device implementation deviates from the contract as defined in the
module. module.
Further details are available in Section 7.20.3. Further details are available in Section 7.20.3.
5.6.4. Announcing Conformance Information in the <hello> Message 5.6.4. Implementing a Module
A server implements a module if it implements the module's data
nodes, rpcs, notifications, and deviations.
A server MUST NOT implement more than one revision of a module.
If a server implements a module A that imports a module B, and A uses
any node from B in an "augment" or "path" statement that the server
supports, then the server MUST implement a revision of module B that
has these nodes defined. This is regardless of if module B is
imported by revision or not.
NOTE: The next paragraph needs to be aligned with
ietf-yang-library.
If a server implements a module A that imports a module C without
specifying the revision date of module C, and the server does not
implement C (e.g., if C only defines some typedefs), the server MUST
list module C in the "/modules/module" list from "ietf-yang-library",
and it MUST set the leaf "default-revision" to "true" for this
module.
The reason for these rules is that clients need to be able to know
the exact data model structure and types of all leafs and leaf-lists
implemented in a server.
For example, with these modules:
module a {
yang-version 1.1;
namespace "http://example.com/a";
prefix "a";
import b {
revision-date 2015-01-01;
}
import c;
revision 2015-01-01;
feature foo;
augement "/b:x" {
if-feature foo;
leaf y {
type b:myenum;
}
}
container a {
leaf x {
type c:bar;
}
}
}
module b {
yang-version 1.1;
namespace "http://example.com/b";
prefix "b";
revision 2015-04-04;
revision 2015-01-01;
typedef myenum {
type enumeration {
enum zero; // added in 2015-01-01
enum one; // added in 2015-04-04
}
}
container x { // added in 2015-01-01
container y; // added in 2015-04-04
}
}
module c {
yang-version 1.1;
namespace "http://example.com/c";
prefix "c";
revision 2015-03-03;
revision 2015-02-02;
typedef foo {
...
}
}
A server that implements revision "2015-01-01" of module "a" and
supports feature "foo" can implement revision "2015-01-01" or
"2015-04-04" of module "b". Since "b" was imported by revision, the
type of leaf "/b:x/a:y" is the same regardless of which revision of
"b" the server implements.
A server that implements module "a", but does not support feature
"foo" does not have to implement module "b".
A server that implements revision "2015-01-01" of module "a" must
pick a revision of module "c", and list it in the "/modules/module"
list from "ietf-yang-library".
The following shows valid data for the "/modules/module" list for a
server that implements module "a":
<modules xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library">
<module-set-id>ee1ecb017370cafd</module-set-id>
<module>
<name>a</module>
<revision>2015-01-01</revision>
<feature>foo</feature>
<conformance>implement</conformance>
</module>
<module>
<name>b</module>
<revision>2015-04-04</revision>
<conformance>implement</conformance>
</module>
<module>
<name>c</module>
<revision>2015-02-02</revision>
<conformance>import</conformance>
</module>
</modules>
#}}
5.6.5. Announcing Conformance Information in NETCONF
This document defines the following mechanism for announcing This document defines the following mechanism for announcing
conformance information. Other mechanisms may be defined by future conformance information. Other mechanisms may be defined by future
specificiations. specifications.
A NETCONF server announces the modules it implements by implementing A NETCONF server announces the modules it implements by implementing
the YANG module "ietf-yang-library" defined in the YANG module "ietf-yang-library" defined in
[I-D.ietf-netconf-yang-library]. The server also advertises the [I-D.ietf-netconf-yang-library], and listing all implemented modules
following capability in the <hello> message (line-breaks and in the "/modules/module" list.
whitespaces are used for formatting reasons only):
The server also advertises the following capability in the <hello>
message (line-breaks and whitespaces are used for formatting reasons
only):
urn:ietf:params:netconf:capability:yang-library:1.0? urn:ietf:params:netconf:capability:yang-library:1.0?
module-set-id=<id> module-set-id=<id>
The parameter "module-set-id" has the same value as the leaf "/ The parameter "module-set-id" has the same value as the leaf
modules/module-set-id" from "ietf-yang-library". This parameter MUST "/modules/module-set-id" from "ietf-yang-library". This parameter
be present. MUST be present.
With this mechanism, a client can cache the supported modules for a With this mechanism, a client can cache the supported modules for a
server, and only update the cache if the "module-set-id" value in the server, and only update the cache if the "module-set-id" value in the
<hello> message changes. <hello> message changes.
5.7. Data Store Modification 5.7. Data Store Modification
Data models may allow the server to alter the configuration data Data models may allow the server to alter the configuration data
store in ways not explicitly directed via NETCONF protocol messages. store in ways not explicitly directed via NETCONF protocol messages.
For example, a data model may define leafs that are assigned system- For example, a data model may define leafs that are assigned system-
skipping to change at page 46, line 28 skipping to change at page 49, line 28
modules. modules.
When the optional "revision-date" substatement is present, any When the optional "revision-date" substatement is present, any
typedef, grouping, extension, feature, and identity referenced by typedef, grouping, extension, feature, and identity referenced by
definitions in the local module are taken from the specified revision definitions in the local module are taken from the specified revision
of the imported module. It is an error if the specified revision of of the imported module. It is an error if the specified revision of
the imported module does not exist. If no "revision-date" the imported module does not exist. If no "revision-date"
substatement is present, it is undefined from which revision of the substatement is present, it is undefined from which revision of the
module they are taken. module they are taken.
Multiple revisions of the same module MUST NOT be imported. Multiple revisions of the same module can be imported, provided that
different prefixes are used.
+---------------+---------+-------------+ +---------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+---------------+---------+-------------+ +---------------+---------+-------------+
| prefix | 7.1.4 | 1 | | prefix | 7.1.4 | 1 |
| revision-date | 7.1.5.1 | 0..1 | | revision-date | 7.1.5.1 | 0..1 |
+---------------+---------+-------------+ +---------------+---------+-------------+
The import's Substatements The import's Substatements
skipping to change at page 72, line 50 skipping to change at page 75, line 50
list. The leafs can be defined directly in substatements to the list. The leafs can be defined directly in substatements to the
list, or in groupings used in the list. list, or in groupings used in the list.
The combined values of all the leafs specified in the key are used to The combined values of all the leafs specified in the key are used to
uniquely identify a list entry. All key leafs MUST be given values uniquely identify a list entry. All key leafs MUST be given values
when a list entry is created. Thus, any default values in the key when a list entry is created. Thus, any default values in the key
leafs or their types are ignored. It also implies that any mandatory leafs or their types are ignored. It also implies that any mandatory
statement in the key leafs are ignored. statement in the key leafs are ignored.
A leaf that is part of the key can be of any built-in or derived A leaf that is part of the key can be of any built-in or derived
type, except it MUST NOT be the built-in type "empty". type.
All key leafs in a list MUST have the same value for their "config" All key leafs in a list MUST have the same value for their "config"
as the list itself. as the list itself.
The key string syntax is formally defined by the rule "key-arg" in The key string syntax is formally defined by the rule "key-arg" in
Section 13. Section 13.
7.8.3. The list's unique Statement 7.8.3. The list's unique Statement
The "unique" statement is used to put constraints on valid list The "unique" statement is used to put constraints on valid list
skipping to change at page 85, line 12 skipping to change at page 88, line 12
The "anydata" statement is used to represent an unknown set of nodes The "anydata" statement is used to represent an unknown set of nodes
that can be modelled with YANG. An example of where this can be that can be modelled with YANG. An example of where this can be
useful is a list of received notifications, where the exact useful is a list of received notifications, where the exact
notifications are not known as design time. notifications are not known as design time.
An anydata node cannot be augmented (see Section 7.17). An anydata node cannot be augmented (see Section 7.17).
An anydata node exists in zero or one instances in the data tree. An anydata node exists in zero or one instances in the data tree.
Since the use of anydata limits the manipulation of the content, it Since the use of anydata limits the manipulation of the content, it
is RECOMMENDED that the "anydata" statement not be used to represent is RECOMMENDED that the "anydata" statement not be used to define
configuration data. configuration data.
7.10.1. The anydata's Substatements 7.10.1. The anydata's Substatements
+--------------+---------+-------------+ +--------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+---------+-------------+ +--------------+---------+-------------+
| config | 7.21.1 | 0..1 | | config | 7.21.1 | 0..1 |
| description | 7.21.3 | 0..1 | | description | 7.21.3 | 0..1 |
| if-feature | 7.20.2 | 0..n | | if-feature | 7.20.2 | 0..n |
skipping to change at page 87, line 10 skipping to change at page 90, line 10
The "anyxml" statement is used to represent an unknown chunk of XML. The "anyxml" statement is used to represent an unknown chunk of XML.
No restrictions are placed on the XML. This can be useful, for No restrictions are placed on the XML. This can be useful, for
example, in RPC replies. An example is the <filter> parameter in the example, in RPC replies. An example is the <filter> parameter in the
<get-config> operation. <get-config> operation.
An anyxml node cannot be augmented (see Section 7.17). An anyxml node cannot be augmented (see Section 7.17).
An anyxml node exists in zero or one instances in the data tree. An anyxml node exists in zero or one instances in the data tree.
Since the use of anyxml limits the manipulation of the content, it is Since the use of anyxml limits the manipulation of the content, it is
RECOMMENDED that the "anyxml" statement not be used to represent RECOMMENDED that the "anyxml" statement not be used to define
configuration data. configuration data.
It should be noted that in YANG version 1, anyxml was the only It should be noted that in YANG version 1, anyxml was the only
statement that could model an unknown hierarchy of data. In many statement that could model an unknown hierarchy of data. In many
cases this unknown hierarchy of data is actually modelled in YANG, cases this unknown hierarchy of data is actually modelled in YANG,
but the exact YANG model is not known at design time. In these but the exact YANG model is not known at design time. In these
situations, it is RECOMMENDED to use anydata (Section 7.10) instead situations, it is RECOMMENDED to use anydata (Section 7.10) instead
of anyxml. of anyxml.
7.11.1. The anyxml's Substatements 7.11.1. The anyxml's Substatements
skipping to change at page 98, line 5 skipping to change at page 101, line 5
The "action" element contains an hierarchy of nodes that identifies The "action" element contains an hierarchy of nodes that identifies
the node in the data tree. It MUST contain all containers and list the node in the data tree. It MUST contain all containers and list
nodes from the top level down to the list or container containing the nodes from the top level down to the list or container containing the
action. For lists, all key leafs MUST also be included. The last action. For lists, all key leafs MUST also be included. The last
container or list contains an XML element that carries the name of container or list contains an XML element that carries the name of
the defined action. Within this element the input parameters are the defined action. Within this element the input parameters are
encoded as child XML elements, in the same order as they are defined encoded as child XML elements, in the same order as they are defined
within the "input" statement. within the "input" statement.
Only one action can be invoked in one <rpc>. If more than one Only one action can be invoked in one <rpc>. If more than one action
actions are present in the <rpc>, the server MUST reply with an is present in the <rpc>, the server MUST reply with an "bad-element"
"bad-element" error-tag in the <rpc-error>. error-tag in the <rpc-error>.
If the action operation invocation succeeded, and no output If the action operation invocation succeeded, and no output
parameters are returned, the <rpc-reply> contains a single <ok/> parameters are returned, the <rpc-reply> contains a single <ok/>
element defined in [RFC6241]. If output parameters are returned, element defined in [RFC6241]. If output parameters are returned,
they are encoded as child elements to the <rpc-reply> element defined they are encoded as child elements to the <rpc-reply> element defined
in [RFC6241], in the same order as they are defined within the in [RFC6241], in the same order as they are defined within the
"output" statement. "output" statement.
7.15.3. Usage Example 7.15.3. Usage Example
skipping to change at page 111, line 36 skipping to change at page 114, line 36
rule "if-feature-expr" in Section 13. When this boolean expression rule "if-feature-expr" in Section 13. When this boolean expression
is evaluated, the operator order of precedence is (highest precedence is evaluated, the operator order of precedence is (highest precedence
first): "not", "and", "or". first): "not", "and", "or".
If a prefix is present on a feature name in the boolean expression, If a prefix is present on a feature name in the boolean expression,
the prefixed name refers to a feature defined in the module that was the prefixed name refers to a feature defined in the module that was
imported with that prefix, or the local module if the prefix matches imported with that prefix, or the local module if the prefix matches
the local module's prefix. Otherwise, a feature with the matching the local module's prefix. Otherwise, a feature with the matching
name MUST be defined in the current module or an included submodule. name MUST be defined in the current module or an included submodule.
A leaf that is a list key MUST NOT have any "if-feature" statements, A leaf that is a list key MUST NOT have any "if-feature" statements.
unless the conditions specified in the "if-feature" statements are
the same as the "if-feature" conditions in effect on the leaf's
parent node.
7.20.2.1. Usage Example 7.20.2.1. Usage Example
In this example, the container "target" is implemented if any of the In this example, the container "target" is implemented if any of the
features "outbound-tls" or "outbound-ssh" is implemented by the features "outbound-tls" or "outbound-ssh" is implemented by the
server. server.
container target { container target {
if-feature "outbound-tls or outbound-ssh"; if-feature "outbound-tls or outbound-ssh";
... ...
skipping to change at page 116, line 42 skipping to change at page 119, line 42
The "when" statement makes its parent data definition statement The "when" statement makes its parent data definition statement
conditional. The node defined by the parent data definition conditional. The node defined by the parent data definition
statement is only valid when the condition specified by the "when" statement is only valid when the condition specified by the "when"
statement is satisfied. The statement's argument is an XPath statement is satisfied. The statement's argument is an XPath
expression (see Section 6.4), which is used to formally specify this expression (see Section 6.4), which is used to formally specify this
condition. If the XPath expression conceptually evaluates to "true" condition. If the XPath expression conceptually evaluates to "true"
for a particular instance, then the node defined by the parent data for a particular instance, then the node defined by the parent data
definition statement is valid; otherwise, it is not. definition statement is valid; otherwise, it is not.
A leaf that is a list key MUST NOT have a "when" statement, unless A leaf that is a list key MUST NOT have a "when" statement.
the condition specified in the "when" statement is the same as the
"when" condition in effect on the leaf's parent node.
See Section 8.3.2 for additional information. See Section 8.3.2 for additional information.
The XPath expression is conceptually evaluated in the following The XPath expression is conceptually evaluated in the following
context, in addition to the definition in Section 6.4.1: context, in addition to the definition in Section 6.4.1:
o If the "when" statement is a child of an "augment" statement, then o 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 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 target node is a data node. Otherwise, the context node is
the closest ancestor node to the target node that is also a data the closest ancestor node to the target node that is also a data
skipping to change at page 123, line 46 skipping to change at page 126, line 46
// illegal range restriction // illegal range restriction
range "11..100"; range "11..100";
} }
} }
9.3. The decimal64 Built-In Type 9.3. The decimal64 Built-In Type
The decimal64 type represents a subset of the real numbers, which can The decimal64 type represents a subset of the real numbers, which can
be represented by decimal numerals. The value space of decimal64 is be represented by decimal numerals. The value space of decimal64 is
the set of numbers that can be obtained by multiplying a 64-bit the set of numbers that can be obtained by multiplying a 64-bit
signed integer by a negative power of ten, i.e., expressible as signed integer by a negative power of ten, i.e., expressible as "i x
"i x 10^-n" where i is an integer64 and n is an integer between 1 and 10^-n" where i is an integer64 and n is an integer between 1 and 18,
18, inclusively. inclusively.
9.3.1. Lexical Representation 9.3.1. Lexical Representation
A decimal64 value is lexically represented as an optional sign ("+" A decimal64 value is lexically represented as an optional sign ("+"
or "-"), followed by a sequence of decimal digits, optionally or "-"), followed by a sequence of decimal digits, optionally
followed by a period ('.') as a decimal indicator and a sequence of followed by a period ('.') as a decimal indicator and a sequence of
decimal digits. If no sign is specified, "+" is assumed. decimal digits. If no sign is specified, "+" is assumed.
9.3.2. Canonical Form 9.3.2. Canonical Form
skipping to change at page 154, line 49 skipping to change at page 157, line 49
Substatements of a YANG statement are represented as (additional) Substatements of a YANG statement are represented as (additional)
children of the keyword element and their relative order MUST be the children of the keyword element and their relative order MUST be the
same as the order of substatements in YANG. same as the order of substatements in YANG.
Comments in YANG MAY be mapped to XML comments. Comments in YANG MAY be mapped to XML comments.
+------------------+---------------+-------------+ +------------------+---------------+-------------+
| keyword | argument name | yin-element | | keyword | argument name | yin-element |
+------------------+---------------+-------------+ +------------------+---------------+-------------+
| action | name | false |
| anydata | 7.10 | 0..n | | anydata | 7.10 | 0..n |
| anyxml | name | false | | anyxml | name | false |
| argument | name | false | | argument | name | false |
| augment | target-node | false | | augment | target-node | false |
| base | name | false | | base | name | false |
| belongs-to | module | false | | belongs-to | module | false |
| bit | name | false | | bit | name | false |
| case | name | false | | case | name | false |
| choice | name | false | | choice | name | false |
| config | value | false | | config | value | false |
skipping to change at page 189, line 17 skipping to change at page 192, line 17
The editor wishes to thank the following individuals, who all The editor wishes to thank the following individuals, who all
provided helpful comments on various versions of this document: provided helpful comments on various versions of this document:
Mehmet Ersue, Washam Fan, Joel Halpern, Leif Johansson, Ladislav Mehmet Ersue, Washam Fan, Joel Halpern, Leif Johansson, Ladislav
Lhotka, Gerhard Muenz, Tom Petch, Randy Presuhn, David Reid, and Bert Lhotka, Gerhard Muenz, Tom Petch, Randy Presuhn, David Reid, and Bert
Wijnen. Wijnen.
19. ChangeLog 19. ChangeLog
RFC Editor: remove this section upon publication as an RFC. RFC Editor: remove this section upon publication as an RFC.
19.1. Version -05 19.1. Version -06
o Included solution Y45-05.
19.2. Version -05
o Included solution Y18-01. o Included solution Y18-01.
o Included solution Y25-02 (parts of it was included in -04). o Included solution Y25-02 (parts of it was included in -04).
o Included solution Y34-05. o Included solution Y34-05.
o Included solution Y36-03. o Included solution Y36-03.
19.2. Version -04 19.3. Version -04
o Incorporated changes to ABNF grammar after review and errata for o Incorporated changes to ABNF grammar after review and errata for
RFC 6020. RFC 6020.
o Included solution Y16-03. o Included solution Y16-03.
o Included solution Y49-04. o Included solution Y49-04.
o Included solution Y58-01. o Included solution Y58-01.
o Included solution Y59-01. o Included solution Y59-01.
19.3. Version -03 19.4. Version -03
o Incorporated changes from WG reviews. o Incorporated changes from WG reviews.
o Included solution Y05-01. o Included solution Y05-01.
o Included solution Y10-01. o Included solution Y10-01.
o Included solution Y13-01. o Included solution Y13-01.
o Included solution Y28-02. o Included solution Y28-02.
o Included solution Y55-01 (parts of it was included in -01). o Included solution Y55-01 (parts of it was included in -01).
19.4. Version -02 19.5. Version -02
o Included solution Y02-01. o Included solution Y02-01.
o Included solution Y04-02. o Included solution Y04-02.
o Included solution Y11-01. o Included solution Y11-01.
o Included solution Y41-01. o Included solution Y41-01.
o Included solution Y56-01. o Included solution Y56-01.
19.5. Version -01 19.6. Version -01
o Included solution Y01-01. o Included solution Y01-01.
o Included solution Y03-01. o Included solution Y03-01.
o Included solution Y06-02. o Included solution Y06-02.
o Included solution Y07-01. o Included solution Y07-01.
o Included solution Y14-01. o Included solution Y14-01.
skipping to change at page 190, line 41 skipping to change at page 193, line 45
o Included solution Y23-01. o Included solution Y23-01.
o Included solution Y29-01. o Included solution Y29-01.
o Included solution Y30-01. o Included solution Y30-01.
o Included solution Y31-01. o Included solution Y31-01.
o Included solution Y35-01. o Included solution Y35-01.
19.6. Version -00 19.7. Version -00
o Applied all reported errata for RFC 6020. o Applied all reported errata for RFC 6020.
o Updated YANG version to 1.1, and made the "yang-version" statement o Updated YANG version to 1.1, and made the "yang-version" statement
mandatory. mandatory.
20. References 20. References
20.1. Normative References 20.1. Normative References
[I-D.ietf-netconf-yang-library] [I-D.ietf-netconf-yang-library]
Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module
Library", draft-ietf-netconf-yang-library (work in Library", draft-ietf-netconf-yang-library (work in
progress), January 2015. progress), January 2015.
[ISO.10646] [ISO.10646]
International Organization for Standardization, International Organization for Standardization,
"Information Technology - Universal Multiple-Octet Coded "Information Technology - Universal Multiple-Octet Coded
 End of changes. 32 change blocks. 
297 lines changed or deleted 429 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/