draft-ietf-netmod-yang-05.txt   draft-ietf-netmod-yang-06.txt 
Network Working Group M. Bjorklund, Ed. Network Working Group M. Bjorklund, Ed.
Internet-Draft Tail-f Systems Internet-Draft Tail-f Systems
Intended status: Standards Track April 20, 2009 Intended status: Standards Track June 25, 2009
Expires: October 22, 2009 Expires: December 27, 2009
YANG - A data modeling language for NETCONF YANG - A data modeling language for NETCONF
draft-ietf-netmod-yang-05 draft-ietf-netmod-yang-06
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 32 skipping to change at page 1, line 32
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 22, 2009. This Internet-Draft will expire on December 27, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
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 NETCONF protocol, NETCONF remote state data manipulated by the Network Configuration Protocol
procedure calls, and NETCONF notifications. (NETCONF) protocol, NETCONF remote procedure calls, and NETCONF
notifications.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 8
2. Key Words . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2. Key Words . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 10 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1. Mandatory nodes . . . . . . . . . . . . . . . . . . . . . 12 3.1. Mandatory nodes . . . . . . . . . . . . . . . . . . . . . 12
4. YANG Overview . . . . . . . . . . . . . . . . . . . . . . . . 13 4. YANG Overview . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1. Functional Overview . . . . . . . . . . . . . . . . . . . 13 4.1. Functional Overview . . . . . . . . . . . . . . . . . . . 13
4.2. Language Overview . . . . . . . . . . . . . . . . . . . . 14 4.2. Language Overview . . . . . . . . . . . . . . . . . . . . 14
skipping to change at page 2, line 45 skipping to change at page 2, line 46
5.3. XML Namespaces . . . . . . . . . . . . . . . . . . . . . 30 5.3. XML Namespaces . . . . . . . . . . . . . . . . . . . . . 30
5.3.1. YANG XML Namespace . . . . . . . . . . . . . . . . . 30 5.3.1. YANG XML Namespace . . . . . . . . . . . . . . . . . 30
5.4. Resolving Grouping, Type, and Identity Names . . . . . . 30 5.4. Resolving Grouping, Type, and Identity Names . . . . . . 30
5.5. Nested Typedefs and Groupings . . . . . . . . . . . . . . 30 5.5. Nested Typedefs and Groupings . . . . . . . . . . . . . . 30
5.6. Conformance . . . . . . . . . . . . . . . . . . . . . . . 31 5.6. Conformance . . . . . . . . . . . . . . . . . . . . . . . 31
5.6.1. Basic Behavior . . . . . . . . . . . . . . . . . . . 31 5.6.1. Basic Behavior . . . . . . . . . . . . . . . . . . . 31
5.6.2. Optional Features . . . . . . . . . . . . . . . . . . 32 5.6.2. Optional Features . . . . . . . . . . . . . . . . . . 32
5.6.3. Deviations . . . . . . . . . . . . . . . . . . . . . 32 5.6.3. Deviations . . . . . . . . . . . . . . . . . . . . . 32
5.6.4. Announcing Conformance Information in the <hello> 5.6.4. Announcing Conformance Information in the <hello>
Message . . . . . . . . . . . . . . . . . . . . . . . 33 Message . . . . . . . . . . . . . . . . . . . . . . . 33
5.6.5. Mapping to the NETCONF Schema Discovery Mechanism . . 35 6. YANG syntax . . . . . . . . . . . . . . . . . . . . . . . . . 35
6. YANG syntax . . . . . . . . . . . . . . . . . . . . . . . . . 36 6.1. Lexicographical Tokenization . . . . . . . . . . . . . . 35
6.1. Lexicographical Tokenization . . . . . . . . . . . . . . 36 6.1.1. Comments . . . . . . . . . . . . . . . . . . . . . . 35
6.1.1. Comments . . . . . . . . . . . . . . . . . . . . . . 36 6.1.2. Tokens . . . . . . . . . . . . . . . . . . . . . . . 35
6.1.2. Tokens . . . . . . . . . . . . . . . . . . . . . . . 36 6.1.3. Quoting . . . . . . . . . . . . . . . . . . . . . . . 35
6.1.3. Quoting . . . . . . . . . . . . . . . . . . . . . . . 36 6.2. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 37
6.2. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 38 6.2.1. Identifiers and their namespaces . . . . . . . . . . 37
6.2.1. Identifiers and their namespaces . . . . . . . . . . 38 6.3. Statements . . . . . . . . . . . . . . . . . . . . . . . 38
6.3. Statements . . . . . . . . . . . . . . . . . . . . . . . 39 6.3.1. Language Extensions . . . . . . . . . . . . . . . . . 38
6.3.1. Language Extensions . . . . . . . . . . . . . . . . . 39 6.4. XPath Evaluations . . . . . . . . . . . . . . . . . . . . 38
6.4. XPath Evaluations . . . . . . . . . . . . . . . . . . . . 39 6.4.1. XPath Context . . . . . . . . . . . . . . . . . . . . 39
7. YANG Statements . . . . . . . . . . . . . . . . . . . . . . . 41 7. YANG Statements . . . . . . . . . . . . . . . . . . . . . . . 40
7.1. The module Statement . . . . . . . . . . . . . . . . . . 41 7.1. The module Statement . . . . . . . . . . . . . . . . . . 40
7.1.1. The module's Substatements . . . . . . . . . . . . . 42 7.1.1. The module's Substatements . . . . . . . . . . . . . 41
7.1.2. The yang-version Statement . . . . . . . . . . . . . 43 7.1.2. The yang-version Statement . . . . . . . . . . . . . 42
7.1.3. The namespace Statement . . . . . . . . . . . . . . . 43 7.1.3. The namespace Statement . . . . . . . . . . . . . . . 42
7.1.4. The prefix Statement . . . . . . . . . . . . . . . . 44 7.1.4. The prefix Statement . . . . . . . . . . . . . . . . 43
7.1.5. The import Statement . . . . . . . . . . . . . . . . 44 7.1.5. The import Statement . . . . . . . . . . . . . . . . 43
7.1.6. The include Statement . . . . . . . . . . . . . . . . 45 7.1.6. The include Statement . . . . . . . . . . . . . . . . 44
7.1.7. The organization Statement . . . . . . . . . . . . . 45 7.1.7. The organization Statement . . . . . . . . . . . . . 45
7.1.8. The contact Statement . . . . . . . . . . . . . . . . 46 7.1.8. The contact Statement . . . . . . . . . . . . . . . . 45
7.1.9. The revision Statement . . . . . . . . . . . . . . . 46 7.1.9. The revision Statement . . . . . . . . . . . . . . . 45
7.1.10. Usage Example . . . . . . . . . . . . . . . . . . . . 47 7.1.10. Usage Example . . . . . . . . . . . . . . . . . . . . 46
7.2. The submodule Statement . . . . . . . . . . . . . . . . . 47 7.2. The submodule Statement . . . . . . . . . . . . . . . . . 46
7.2.1. The submodule's Substatements . . . . . . . . . . . . 48 7.2.1. The submodule's Substatements . . . . . . . . . . . . 47
7.2.2. The belongs-to Statement . . . . . . . . . . . . . . 49 7.2.2. The belongs-to Statement . . . . . . . . . . . . . . 48
7.2.3. Usage Example . . . . . . . . . . . . . . . . . . . . 50 7.2.3. Usage Example . . . . . . . . . . . . . . . . . . . . 49
7.3. The typedef Statement . . . . . . . . . . . . . . . . . . 50 7.3. The typedef Statement . . . . . . . . . . . . . . . . . . 49
7.3.1. The typedef's Substatements . . . . . . . . . . . . . 51 7.3.1. The typedef's Substatements . . . . . . . . . . . . . 50
7.3.2. The typedef's type Statement . . . . . . . . . . . . 51 7.3.2. The typedef's type Statement . . . . . . . . . . . . 50
7.3.3. The units Statement . . . . . . . . . . . . . . . . . 51 7.3.3. The units Statement . . . . . . . . . . . . . . . . . 50
7.3.4. The typedef's default Statement . . . . . . . . . . . 51 7.3.4. The typedef's default Statement . . . . . . . . . . . 50
7.3.5. Usage Example . . . . . . . . . . . . . . . . . . . . 52 7.3.5. Usage Example . . . . . . . . . . . . . . . . . . . . 51
7.4. The type Statement . . . . . . . . . . . . . . . . . . . 52 7.4. The type Statement . . . . . . . . . . . . . . . . . . . 51
7.4.1. The type's Substatements . . . . . . . . . . . . . . 52 7.4.1. The type's Substatements . . . . . . . . . . . . . . 51
7.5. The container Statement . . . . . . . . . . . . . . . . . 52 7.5. The container Statement . . . . . . . . . . . . . . . . . 51
7.5.1. Containers with Presence . . . . . . . . . . . . . . 53 7.5.1. Containers with Presence . . . . . . . . . . . . . . 52
7.5.2. The container's Substatements . . . . . . . . . . . . 54 7.5.2. The container's Substatements . . . . . . . . . . . . 53
7.5.3. The must Statement . . . . . . . . . . . . . . . . . 54 7.5.3. The must Statement . . . . . . . . . . . . . . . . . 53
7.5.4. The must's Substatements . . . . . . . . . . . . . . 56 7.5.4. The must's Substatements . . . . . . . . . . . . . . 55
7.5.5. The presence Statement . . . . . . . . . . . . . . . 57 7.5.5. The presence Statement . . . . . . . . . . . . . . . 56
7.5.6. The container's Child Node Statements . . . . . . . . 57 7.5.6. The container's Child Node Statements . . . . . . . . 56
7.5.7. XML Encoding Rules . . . . . . . . . . . . . . . . . 57 7.5.7. XML Mapping Rules . . . . . . . . . . . . . . . . . . 56
7.5.8. NETCONF <edit-config> Operations . . . . . . . . . . 57 7.5.8. NETCONF <edit-config> Operations . . . . . . . . . . 56
7.5.9. Usage Example . . . . . . . . . . . . . . . . . . . . 58 7.5.9. Usage Example . . . . . . . . . . . . . . . . . . . . 57
7.6. The leaf Statement . . . . . . . . . . . . . . . . . . . 59 7.6. The leaf Statement . . . . . . . . . . . . . . . . . . . 58
7.6.1. The leaf's Substatements . . . . . . . . . . . . . . 60 7.6.1. The leaf's Substatements . . . . . . . . . . . . . . 59
7.6.2. The leaf's type Statement . . . . . . . . . . . . . . 60 7.6.2. The leaf's type Statement . . . . . . . . . . . . . . 59
7.6.3. The leaf's default Statement . . . . . . . . . . . . 60 7.6.3. The leaf's default Statement . . . . . . . . . . . . 59
7.6.4. The leaf's mandatory Statement . . . . . . . . . . . 60 7.6.4. The leaf's mandatory Statement . . . . . . . . . . . 59
7.6.5. XML Encoding Rules . . . . . . . . . . . . . . . . . 61 7.6.5. XML Mapping Rules . . . . . . . . . . . . . . . . . . 60
7.6.6. NETCONF <edit-config> Operations . . . . . . . . . . 61 7.6.6. NETCONF <edit-config> Operations . . . . . . . . . . 60
7.6.7. Usage Example . . . . . . . . . . . . . . . . . . . . 61 7.6.7. Usage Example . . . . . . . . . . . . . . . . . . . . 61
7.7. The leaf-list Statement . . . . . . . . . . . . . . . . . 62 7.7. The leaf-list Statement . . . . . . . . . . . . . . . . . 61
7.7.1. Ordering . . . . . . . . . . . . . . . . . . . . . . 63 7.7.1. Ordering . . . . . . . . . . . . . . . . . . . . . . 62
7.7.2. The leaf-list's Substatements . . . . . . . . . . . . 64 7.7.2. The leaf-list's Substatements . . . . . . . . . . . . 63
7.7.3. The min-elements Statement . . . . . . . . . . . . . 64 7.7.3. The min-elements Statement . . . . . . . . . . . . . 63
7.7.4. The max-elements Statement . . . . . . . . . . . . . 64 7.7.4. The max-elements Statement . . . . . . . . . . . . . 63
7.7.5. The ordered-by Statement . . . . . . . . . . . . . . 65 7.7.5. The ordered-by Statement . . . . . . . . . . . . . . 64
7.7.6. XML Encoding Rules . . . . . . . . . . . . . . . . . 65 7.7.6. XML Mapping Rules . . . . . . . . . . . . . . . . . . 64
7.7.7. NETCONF <edit-config> operations . . . . . . . . . . 65 7.7.7. NETCONF <edit-config> operations . . . . . . . . . . 64
7.7.8. Usage Example . . . . . . . . . . . . . . . . . . . . 66 7.7.8. Usage Example . . . . . . . . . . . . . . . . . . . . 65
7.8. The list Statement . . . . . . . . . . . . . . . . . . . 68 7.8. The list Statement . . . . . . . . . . . . . . . . . . . 67
7.8.1. The list's Substatements . . . . . . . . . . . . . . 69 7.8.1. The list's Substatements . . . . . . . . . . . . . . 68
7.8.2. The list's key Statement . . . . . . . . . . . . . . 69 7.8.2. The list's key Statement . . . . . . . . . . . . . . 68
7.8.3. The list's unique Statement . . . . . . . . . . . . . 70 7.8.3. The list's unique Statement . . . . . . . . . . . . . 69
7.8.4. The list's Child Node Statements . . . . . . . . . . 71 7.8.4. The list's Child Node Statements . . . . . . . . . . 70
7.8.5. XML Encoding Rules . . . . . . . . . . . . . . . . . 71 7.8.5. XML Mapping Rules . . . . . . . . . . . . . . . . . . 70
7.8.6. NETCONF <edit-config> operations . . . . . . . . . . 72 7.8.6. NETCONF <edit-config> operations . . . . . . . . . . 71
7.8.7. Usage Example . . . . . . . . . . . . . . . . . . . . 72 7.8.7. Usage Example . . . . . . . . . . . . . . . . . . . . 71
7.9. The choice Statement . . . . . . . . . . . . . . . . . . 76 7.9. The choice Statement . . . . . . . . . . . . . . . . . . 75
7.9.1. The choice's Substatements . . . . . . . . . . . . . 76 7.9.1. The choice's Substatements . . . . . . . . . . . . . 75
7.9.2. The choice's case Statement . . . . . . . . . . . . . 76 7.9.2. The choice's case Statement . . . . . . . . . . . . . 75
7.9.3. The choice's default Statement . . . . . . . . . . . 78 7.9.3. The choice's default Statement . . . . . . . . . . . 77
7.9.4. The choice's mandatory Statement . . . . . . . . . . 79 7.9.4. The choice's mandatory Statement . . . . . . . . . . 78
7.9.5. XML Encoding Rules . . . . . . . . . . . . . . . . . 80 7.9.5. XML Mapping Rules . . . . . . . . . . . . . . . . . . 79
7.9.6. NETCONF <edit-config> operations . . . . . . . . . . 80 7.9.6. NETCONF <edit-config> operations . . . . . . . . . . 79
7.9.7. Usage Example . . . . . . . . . . . . . . . . . . . . 80 7.9.7. Usage Example . . . . . . . . . . . . . . . . . . . . 79
7.10. The anyxml Statement . . . . . . . . . . . . . . . . . . 81 7.10. The anyxml Statement . . . . . . . . . . . . . . . . . . 80
7.10.1. The anyxml's Substatements . . . . . . . . . . . . . 82 7.10.1. The anyxml's Substatements . . . . . . . . . . . . . 81
7.10.2. XML Encoding Rules . . . . . . . . . . . . . . . . . 82 7.10.2. XML Mapping Rules . . . . . . . . . . . . . . . . . . 81
7.10.3. NETCONF <edit-config> operations . . . . . . . . . . 82 7.10.3. NETCONF <edit-config> operations . . . . . . . . . . 81
7.10.4. Usage Example . . . . . . . . . . . . . . . . . . . . 83 7.10.4. Usage Example . . . . . . . . . . . . . . . . . . . . 82
7.11. The grouping Statement . . . . . . . . . . . . . . . . . 83 7.11. The grouping Statement . . . . . . . . . . . . . . . . . 82
7.11.1. The grouping's Substatements . . . . . . . . . . . . 84 7.11.1. The grouping's Substatements . . . . . . . . . . . . 83
7.11.2. Usage Example . . . . . . . . . . . . . . . . . . . . 84 7.11.2. Usage Example . . . . . . . . . . . . . . . . . . . . 83
7.12. The uses Statement . . . . . . . . . . . . . . . . . . . 84 7.12. The uses Statement . . . . . . . . . . . . . . . . . . . 83
7.12.1. The uses's Substatements . . . . . . . . . . . . . . 85 7.12.1. The uses's Substatements . . . . . . . . . . . . . . 84
7.12.2. The refine Statement . . . . . . . . . . . . . . . . 85 7.12.2. The refine Statement . . . . . . . . . . . . . . . . 84
7.12.3. XML Encoding Rules . . . . . . . . . . . . . . . . . 86 7.12.3. XML Mapping Rules . . . . . . . . . . . . . . . . . . 85
7.12.4. Usage Example . . . . . . . . . . . . . . . . . . . . 86 7.12.4. Usage Example . . . . . . . . . . . . . . . . . . . . 85
7.13. The rpc Statement . . . . . . . . . . . . . . . . . . . . 87 7.13. The rpc Statement . . . . . . . . . . . . . . . . . . . . 86
7.13.1. The rpc's Substatements . . . . . . . . . . . . . . . 88 7.13.1. The rpc's Substatements . . . . . . . . . . . . . . . 87
7.13.2. The input Statement . . . . . . . . . . . . . . . . . 88 7.13.2. The input Statement . . . . . . . . . . . . . . . . . 87
7.13.3. The output Statement . . . . . . . . . . . . . . . . 89 7.13.3. The output Statement . . . . . . . . . . . . . . . . 88
7.13.4. XML Encoding Rules . . . . . . . . . . . . . . . . . 90 7.13.4. XML Mapping Rules . . . . . . . . . . . . . . . . . . 89
7.13.5. Usage Example . . . . . . . . . . . . . . . . . . . . 90 7.13.5. Usage Example . . . . . . . . . . . . . . . . . . . . 89
7.14. The notification Statement . . . . . . . . . . . . . . . 91 7.14. The notification Statement . . . . . . . . . . . . . . . 90
7.14.1. The notification's Substatements . . . . . . . . . . 92 7.14.1. The notification's Substatements . . . . . . . . . . 91
7.14.2. XML Encoding Rules . . . . . . . . . . . . . . . . . 92 7.14.2. XML Mapping Rules . . . . . . . . . . . . . . . . . . 91
7.14.3. Usage Example . . . . . . . . . . . . . . . . . . . . 92 7.14.3. Usage Example . . . . . . . . . . . . . . . . . . . . 91
7.15. The augment Statement . . . . . . . . . . . . . . . . . . 93 7.15. The augment Statement . . . . . . . . . . . . . . . . . . 92
7.15.1. The augment's Substatements . . . . . . . . . . . . . 95 7.15.1. The augment's Substatements . . . . . . . . . . . . . 93
7.15.2. XML Encoding Rules . . . . . . . . . . . . . . . . . 95 7.15.2. XML Mapping Rules . . . . . . . . . . . . . . . . . . 93
7.15.3. Usage Example . . . . . . . . . . . . . . . . . . . . 95 7.15.3. Usage Example . . . . . . . . . . . . . . . . . . . . 93
7.16. The identity Statement . . . . . . . . . . . . . . . . . 97 7.16. The identity Statement . . . . . . . . . . . . . . . . . 95
7.16.1. The identity's Substatements . . . . . . . . . . . . 98 7.16.1. The identity's Substatements . . . . . . . . . . . . 96
7.16.2. The base Statement . . . . . . . . . . . . . . . . . 98 7.16.2. The base Statement . . . . . . . . . . . . . . . . . 96
7.16.3. Usage Example . . . . . . . . . . . . . . . . . . . . 99 7.16.3. Usage Example . . . . . . . . . . . . . . . . . . . . 97
7.17. The extension Statement . . . . . . . . . . . . . . . . . 99 7.17. The extension Statement . . . . . . . . . . . . . . . . . 97
7.17.1. The extension's Substatements . . . . . . . . . . . . 100 7.17.1. The extension's Substatements . . . . . . . . . . . . 98
7.17.2. The argument Statement . . . . . . . . . . . . . . . 100 7.17.2. The argument Statement . . . . . . . . . . . . . . . 98
7.17.3. Usage Example . . . . . . . . . . . . . . . . . . . . 101 7.17.3. Usage Example . . . . . . . . . . . . . . . . . . . . 99
7.18. Conformance-related Statements . . . . . . . . . . . . . 101 7.18. Conformance-related Statements . . . . . . . . . . . . . 99
7.18.1. The feature Statement . . . . . . . . . . . . . . . . 101 7.18.1. The feature Statement . . . . . . . . . . . . . . . . 99
7.18.2. The if-feature Statement . . . . . . . . . . . . . . 103 7.18.2. The if-feature Statement . . . . . . . . . . . . . . 101
7.18.3. The deviation Statement . . . . . . . . . . . . . . . 103 7.18.3. The deviation Statement . . . . . . . . . . . . . . . 101
7.19. Common Statements . . . . . . . . . . . . . . . . . . . . 106 7.19. Common Statements . . . . . . . . . . . . . . . . . . . . 104
7.19.1. The config Statement . . . . . . . . . . . . . . . . 106 7.19.1. The config Statement . . . . . . . . . . . . . . . . 104
7.19.2. The status Statement . . . . . . . . . . . . . . . . 106 7.19.2. The status Statement . . . . . . . . . . . . . . . . 104
7.19.3. The description Statement . . . . . . . . . . . . . . 107 7.19.3. The description Statement . . . . . . . . . . . . . . 105
7.19.4. The reference Statement . . . . . . . . . . . . . . . 107 7.19.4. The reference Statement . . . . . . . . . . . . . . . 105
7.19.5. The when Statement . . . . . . . . . . . . . . . . . 107 7.19.5. The when Statement . . . . . . . . . . . . . . . . . 105
8. Constraints . . . . . . . . . . . . . . . . . . . . . . . . . 110 8. Constraints . . . . . . . . . . . . . . . . . . . . . . . . . 107
8.1. Constraints on Data . . . . . . . . . . . . . . . . . . . 110 8.1. Constraints on Data . . . . . . . . . . . . . . . . . . . 107
8.2. Hierarchy of Constraints . . . . . . . . . . . . . . . . 110 8.2. Hierarchy of Constraints . . . . . . . . . . . . . . . . 107
8.3. Constraint Enforcement Model . . . . . . . . . . . . . . 110 8.3. Constraint Enforcement Model . . . . . . . . . . . . . . 107
8.3.1. Payload Parsing . . . . . . . . . . . . . . . . . . . 111 8.3.1. Payload Parsing . . . . . . . . . . . . . . . . . . . 108
8.3.2. NETCONF <edit-config> Processing . . . . . . . . . . 111 8.3.2. NETCONF <edit-config> Processing . . . . . . . . . . 108
8.3.3. Validation . . . . . . . . . . . . . . . . . . . . . 112 8.3.3. Validation . . . . . . . . . . . . . . . . . . . . . 109
9. Built-in Types . . . . . . . . . . . . . . . . . . . . . . . 113 9. Built-in Types . . . . . . . . . . . . . . . . . . . . . . . 110
9.1. Canonical representation . . . . . . . . . . . . . . . . 113 9.1. Canonical representation . . . . . . . . . . . . . . . . 110
9.2. The Integer Built-in Types . . . . . . . . . . . . . . . 113 9.2. The Integer Built-in Types . . . . . . . . . . . . . . . 110
9.2.1. Lexicographic Representation . . . . . . . . . . . . 114 9.2.1. Lexicographic Representation . . . . . . . . . . . . 111
9.2.2. Canonical Form . . . . . . . . . . . . . . . . . . . 115 9.2.2. Canonical Form . . . . . . . . . . . . . . . . . . . 112
9.2.3. Restrictions . . . . . . . . . . . . . . . . . . . . 115 9.2.3. Restrictions . . . . . . . . . . . . . . . . . . . . 112
9.2.4. The range Statement . . . . . . . . . . . . . . . . . 115 9.2.4. The range Statement . . . . . . . . . . . . . . . . . 112
9.2.5. Usage Example . . . . . . . . . . . . . . . . . . . . 116 9.2.5. Usage Example . . . . . . . . . . . . . . . . . . . . 113
9.3. The decimal64 Built-in Type . . . . . . . . . . . . . . . 116 9.3. The decimal64 Built-in Type . . . . . . . . . . . . . . . 113
9.3.1. Lexicographic Representation . . . . . . . . . . . . 116 9.3.1. Lexicographic Representation . . . . . . . . . . . . 113
9.3.2. Canonical Form . . . . . . . . . . . . . . . . . . . 116 9.3.2. Canonical Form . . . . . . . . . . . . . . . . . . . 113
9.3.3. Restrictions . . . . . . . . . . . . . . . . . . . . 116 9.3.3. Restrictions . . . . . . . . . . . . . . . . . . . . 113
9.3.4. The fraction-digits Statement . . . . . . . . . . . . 117 9.3.4. The fraction-digits Statement . . . . . . . . . . . . 114
9.3.5. Usage Example . . . . . . . . . . . . . . . . . . . . 117 9.3.5. Usage Example . . . . . . . . . . . . . . . . . . . . 114
9.4. The string Built-in Type . . . . . . . . . . . . . . . . 117 9.4. The string Built-in Type . . . . . . . . . . . . . . . . 114
9.4.1. Lexicographic Representation . . . . . . . . . . . . 117 9.4.1. Lexicographic Representation . . . . . . . . . . . . 115
9.4.2. Canonical Form . . . . . . . . . . . . . . . . . . . 117 9.4.2. Canonical Form . . . . . . . . . . . . . . . . . . . 115
9.4.3. Restrictions . . . . . . . . . . . . . . . . . . . . 117 9.4.3. Restrictions . . . . . . . . . . . . . . . . . . . . 115
9.4.4. The length Statement . . . . . . . . . . . . . . . . 117 9.4.4. The length Statement . . . . . . . . . . . . . . . . 115
9.4.5. Usage Example . . . . . . . . . . . . . . . . . . . . 119 9.4.5. Usage Example . . . . . . . . . . . . . . . . . . . . 116
9.4.6. The pattern Statement . . . . . . . . . . . . . . . . 119 9.4.6. The pattern Statement . . . . . . . . . . . . . . . . 116
9.4.7. Usage Example . . . . . . . . . . . . . . . . . . . . 120 9.4.7. Usage Example . . . . . . . . . . . . . . . . . . . . 117
9.5. The boolean Built-in Type . . . . . . . . . . . . . . . . 120 9.5. The boolean Built-in Type . . . . . . . . . . . . . . . . 117
9.5.1. Lexicographic Representation . . . . . . . . . . . . 120 9.5.1. Lexicographic Representation . . . . . . . . . . . . 117
9.5.2. Restrictions . . . . . . . . . . . . . . . . . . . . 120 9.5.2. Canonical Form . . . . . . . . . . . . . . . . . . . 117
9.6. The enumeration Built-in Type . . . . . . . . . . . . . . 120 9.5.3. Restrictions . . . . . . . . . . . . . . . . . . . . 117
9.6.1. Lexicographic Representation . . . . . . . . . . . . 120 9.6. The enumeration Built-in Type . . . . . . . . . . . . . . 118
9.6.2. Canonical Form . . . . . . . . . . . . . . . . . . . 120 9.6.1. Lexicographic Representation . . . . . . . . . . . . 118
9.6.3. Restrictions . . . . . . . . . . . . . . . . . . . . 121 9.6.2. Canonical Form . . . . . . . . . . . . . . . . . . . 118
9.6.4. The enum Statement . . . . . . . . . . . . . . . . . 121 9.6.3. Restrictions . . . . . . . . . . . . . . . . . . . . 118
9.6.5. Usage Example . . . . . . . . . . . . . . . . . . . . 122 9.6.4. The enum Statement . . . . . . . . . . . . . . . . . 118
9.7. The bits Built-in Type . . . . . . . . . . . . . . . . . 122 9.6.5. Usage Example . . . . . . . . . . . . . . . . . . . . 119
9.7.1. Restrictions . . . . . . . . . . . . . . . . . . . . 122 9.7. The bits Built-in Type . . . . . . . . . . . . . . . . . 119
9.7.2. Lexicographic Representation . . . . . . . . . . . . 122 9.7.1. Restrictions . . . . . . . . . . . . . . . . . . . . 119
9.7.3. Canonical Form . . . . . . . . . . . . . . . . . . . 122 9.7.2. Lexicographic Representation . . . . . . . . . . . . 120
9.7.4. The bit Statement . . . . . . . . . . . . . . . . . . 122 9.7.3. Canonical Form . . . . . . . . . . . . . . . . . . . 120
9.7.5. Usage Example . . . . . . . . . . . . . . . . . . . . 123 9.7.4. The bit Statement . . . . . . . . . . . . . . . . . . 120
9.8. The binary Built-in Type . . . . . . . . . . . . . . . . 124 9.7.5. Usage Example . . . . . . . . . . . . . . . . . . . . 121
9.8.1. Restrictions . . . . . . . . . . . . . . . . . . . . 124 9.8. The binary Built-in Type . . . . . . . . . . . . . . . . 121
9.8.2. Lexicographic Representation . . . . . . . . . . . . 124 9.8.1. Restrictions . . . . . . . . . . . . . . . . . . . . 121
9.8.3. Canonical Form . . . . . . . . . . . . . . . . . . . 124 9.8.2. Lexicographic Representation . . . . . . . . . . . . 121
9.9. The leafref Built-in Type . . . . . . . . . . . . . . . . 124 9.8.3. Canonical Form . . . . . . . . . . . . . . . . . . . 121
9.9.1. Restrictions . . . . . . . . . . . . . . . . . . . . 125 9.9. The leafref Built-in Type . . . . . . . . . . . . . . . . 122
9.9.2. The path Statement . . . . . . . . . . . . . . . . . 125 9.9.1. Restrictions . . . . . . . . . . . . . . . . . . . . 122
9.9.3. The require-instance Statement . . . . . . . . . . . 125 9.9.2. The path Statement . . . . . . . . . . . . . . . . . 122
9.9.4. Lexicographic Representation . . . . . . . . . . . . 126 9.9.3. Lexicographic Representation . . . . . . . . . . . . 123
9.9.5. Canonical Form . . . . . . . . . . . . . . . . . . . 126 9.9.4. Canonical Form . . . . . . . . . . . . . . . . . . . 123
9.9.6. Usage Example . . . . . . . . . . . . . . . . . . . . 126 9.9.5. Usage Example . . . . . . . . . . . . . . . . . . . . 123
9.10. The identityref Built-in Type . . . . . . . . . . . . . . 128 9.10. The identityref Built-in Type . . . . . . . . . . . . . . 126
9.10.1. Restrictions . . . . . . . . . . . . . . . . . . . . 128 9.10.1. Restrictions . . . . . . . . . . . . . . . . . . . . 126
9.10.2. The identityref's base Statement . . . . . . . . . . 128 9.10.2. The identityref's base Statement . . . . . . . . . . 126
9.10.3. Lexicographic Representation . . . . . . . . . . . . 129 9.10.3. Lexicographic Representation . . . . . . . . . . . . 127
9.10.4. Canonical Form . . . . . . . . . . . . . . . . . . . 129 9.10.4. Canonical Form . . . . . . . . . . . . . . . . . . . 127
9.10.5. Usage Example . . . . . . . . . . . . . . . . . . . . 129 9.10.5. Usage Example . . . . . . . . . . . . . . . . . . . . 127
9.11. The empty Built-in Type . . . . . . . . . . . . . . . . . 130 9.11. The empty Built-in Type . . . . . . . . . . . . . . . . . 128
9.11.1. Restrictions . . . . . . . . . . . . . . . . . . . . 130 9.11.1. Restrictions . . . . . . . . . . . . . . . . . . . . 128
9.11.2. Lexicographic Representation . . . . . . . . . . . . 130 9.11.2. Lexicographic Representation . . . . . . . . . . . . 128
9.11.3. Canonical Form . . . . . . . . . . . . . . . . . . . 130 9.11.3. Canonical Form . . . . . . . . . . . . . . . . . . . 128
9.11.4. Usage Example . . . . . . . . . . . . . . . . . . . . 130 9.11.4. Usage Example . . . . . . . . . . . . . . . . . . . . 128
9.12. The union Built-in Type . . . . . . . . . . . . . . . . . 130 9.12. The union Built-in Type . . . . . . . . . . . . . . . . . 128
9.12.1. Restrictions . . . . . . . . . . . . . . . . . . . . 131 9.12.1. Restrictions . . . . . . . . . . . . . . . . . . . . 129
9.12.2. Lexicographic Representation . . . . . . . . . . . . 131 9.12.2. Lexicographic Representation . . . . . . . . . . . . 129
9.12.3. Canonical Form . . . . . . . . . . . . . . . . . . . 131 9.12.3. Canonical Form . . . . . . . . . . . . . . . . . . . 129
9.13. The instance-identifier Built-in Type . . . . . . . . . . 131 9.13. The instance-identifier Built-in Type . . . . . . . . . . 129
9.13.1. Restrictions . . . . . . . . . . . . . . . . . . . . 132 9.13.1. Restrictions . . . . . . . . . . . . . . . . . . . . 130
9.13.2. Lexicographic Representation . . . . . . . . . . . . 132 9.13.2. The require-instance Statement . . . . . . . . . . . 130
9.13.3. Canonical Form . . . . . . . . . . . . . . . . . . . 132 9.13.3. Lexicographic Representation . . . . . . . . . . . . 131
9.13.4. Usage Example . . . . . . . . . . . . . . . . . . . . 132 9.13.4. Canonical Form . . . . . . . . . . . . . . . . . . . 131
10. Updating a Module . . . . . . . . . . . . . . . . . . . . . . 134 9.13.5. Usage Example . . . . . . . . . . . . . . . . . . . . 131
11. YIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 10. Updating a Module . . . . . . . . . . . . . . . . . . . . . . 132
11.1. Formal YIN Definition . . . . . . . . . . . . . . . . . . 137 11. YIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
11.1.1. Usage Example . . . . . . . . . . . . . . . . . . . . 139 11.1. Formal YIN Definition . . . . . . . . . . . . . . . . . . 135
12. YANG ABNF Grammar . . . . . . . . . . . . . . . . . . . . . . 141 11.1.1. Usage Example . . . . . . . . . . . . . . . . . . . . 137
13. Error Responses for YANG Related Errors . . . . . . . . . . . 162 12. YANG ABNF Grammar . . . . . . . . . . . . . . . . . . . . . . 139
13.1. Error Message for Data that Violates a unique 13. Error Responses for YANG Related Errors . . . . . . . . . . . 160
Statement: . . . . . . . . . . . . . . . . . . . . . . . 162 13.1. Error Message for Data that Violates a unique Statement . 160
13.2. Error Message for Data that Violates a max-elements 13.2. Error Message for Data that Violates a max-elements
Statement: . . . . . . . . . . . . . . . . . . . . . . . 162 Statement . . . . . . . . . . . . . . . . . . . . . . . . 160
13.3. Error Message for Data that Violates a min-elements 13.3. Error Message for Data that Violates a min-elements
Statement: . . . . . . . . . . . . . . . . . . . . . . . 162 Statement . . . . . . . . . . . . . . . . . . . . . . . . 160
13.4. Error Message for Data that Violates a must statement: . 163 13.4. Error Message for Data that Violates a must Statement . . 161
13.5. Error Message for Data that Violates a 13.5. Error Message for Data that Violates a
require-instance statement: . . . . . . . . . . . . . . . 163 require-instance Statement . . . . . . . . . . . . . . . 161
13.6. Error Message for Data that Violates a mandatory 13.6. Error Message for Data that does not Match a leafref
choice statement: . . . . . . . . . . . . . . . . . . . . 163 Type . . . . . . . . . . . . . . . . . . . . . . . . . . 161
13.7. Error Message for the "insert" Operation . . . . . . . . 163 13.7. Error Message for Data that Violates a mandatory
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 164 choice Statement . . . . . . . . . . . . . . . . . . . . 161
15. Security Considerations . . . . . . . . . . . . . . . . . . . 165 13.8. Error Message for the "insert" Operation . . . . . . . . 162
16. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 166 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 163
17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 167 15. Security Considerations . . . . . . . . . . . . . . . . . . . 164
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 168 16. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 165
18.1. Normative References . . . . . . . . . . . . . . . . . . 168 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 166
18.2. Non-Normative References . . . . . . . . . . . . . . . . 169 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 167
Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . 170 18.1. Normative References . . . . . . . . . . . . . . . . . . 167
A.1. Version -05 . . . . . . . . . . . . . . . . . . . . . . . 170 18.2. Non-Normative References . . . . . . . . . . . . . . . . 168
A.2. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 170 Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . 169
A.3. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 171 A.1. Version -06 . . . . . . . . . . . . . . . . . . . . . . . 169
A.4. Version -02 . . . . . . . . . . . . . . . . . . . . . . . 171 A.2. Version -05 . . . . . . . . . . . . . . . . . . . . . . . 169
A.5. Version -01 . . . . . . . . . . . . . . . . . . . . . . . 171 A.3. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 169
A.6. Version -00 . . . . . . . . . . . . . . . . . . . . . . . 172 A.4. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 170
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 174 A.5. Version -02 . . . . . . . . . . . . . . . . . . . . . . . 170
A.6. Version -01 . . . . . . . . . . . . . . . . . . . . . . . 171
A.7. Version -00 . . . . . . . . . . . . . . . . . . . . . . . 172
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 173
1. Introduction 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 YANG is a data modeling language used to model configuration and
state data manipulated by the NETCONF protocol, NETCONF remote state data manipulated by the Network Configuration Protocol
procedure calls, and NETCONF notifications. YANG models the (NETCONF) protocol, NETCONF remote procedure calls, and NETCONF
operations and content layers of NETCONF (see the NETCONF protocol notifications. YANG is used to model the operations and content
[RFC4741], section 1.1). layers of NETCONF (see the NETCONF Configuration Protocol [RFC4741],
section 1.1).
This document describes the syntax and semantics of the YANG This document describes the syntax and semantics of the YANG
language, how the data model defined in a YANG module is represented language, how the data model defined in a YANG module is represented
in XML, and how NETCONF operations are used to manipulate the data. in XML, and how NETCONF operations are used to manipulate the data.
2. Key Words 2. Key Words
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
skipping to change at page 10, line 38 skipping to change at page 10, line 38
most one instance. A container node has no value, but rather a most one instance. A container node has no value, but rather a
set of child nodes. set of child nodes.
o data definition statement: A statement that defines new data o data definition statement: A statement that defines new data
nodes. One of container, leaf, leaf-list, list, choice, case, nodes. One of container, leaf, leaf-list, list, choice, case,
augment, uses, and anyxml. augment, uses, and anyxml.
o data model: A data model describes how data is represented and o data model: A data model describes how data is represented and
accessed. 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 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. data tree. One of container, leaf, leaf-list, list, and anyxml.
o data tree: The instantiated tree of configuration and state data o data tree: The instantiated tree of configuration and state data
on a device. on a device.
o derived type: A type which is derived from a built-in type (such o derived type: A type which is derived from a built-in type (such
as uint32), or another derived type. as uint32), or another derived type.
o device deviation: A failure of the device to implement the module o device deviation: A failure of the device to implement the module
skipping to change at page 11, line 35 skipping to change at page 11, line 31
o leaf: A node in the data tree with a value but no child 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 o leaf-list: Like the leaf node but defines a set of uniquely
identifiable nodes rather than a single node. Each node has a identifiable nodes rather than a single node. Each node has a
value but no child nodes. value but no child nodes.
o list: Interior nodes in the data tree which may exist in multiple 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 instances. A list node has no value, but rather a set of child
nodes. 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 o module: A YANG module defines a hierarchy of nodes which can be
used for NETCONF-based operations. With its definitions and the used for NETCONF-based operations. With its definitions and the
definitions it imports or includes from elsewhere, a module is definitions it imports or includes from elsewhere, a module is
self-contained and "compilable". self-contained and "compilable".
o RPC: A Remote Procedure Call, as used within the NETCONF protocol. o RPC: A Remote Procedure Call, as used within the NETCONF protocol.
o RPC method: A specific Remote Procedure Call, as used within the o RPC method: A specific Remote Procedure Call, as used within the
NETCONF protocol. Also called a protocol operation. NETCONF protocol. Also called a protocol operation.
skipping to change at page 12, line 26 skipping to change at page 12, line 17
A YANG module can be constructed from a number of submodules. A YANG module can be constructed from a number of submodules.
o uses: The "uses" statement is used to instantiate the set of nodes o uses: The "uses" statement is used to instantiate the set of nodes
defined in a grouping statement. The instantiated nodes may be defined in a grouping statement. The instantiated nodes may be
refined and augmented to tailor them to any specific needs. refined and augmented to tailor them to any specific needs.
3.1. Mandatory nodes 3.1. Mandatory nodes
A mandatory node is one of: A mandatory node is one of:
o A leaf or choice node with a "mandatory" statement with the value o A leaf, choice, or anyxml node with a "mandatory" statement with
"true". the value "true".
o A list or leaf-list node with a "min-elements" statement with a o A list or leaf-list node with a "min-elements" statement with a
value greater than zero. value greater than zero.
o A container node without a "presence" statement, which has has at o A container node without a "presence" statement, which has at
least one mandatory node as a child. least one mandatory node as a child.
4. YANG Overview 4. YANG Overview
4.1. Functional Overview 4.1. Functional Overview
YANG is a language used to model data for the NETCONF protocol. A YANG is a language used to model data for the NETCONF protocol. A
YANG module defines a hierarchy of data which can be used for YANG module defines a hierarchy of data which can be used for
NETCONF-based operations, including configuration, state data, remote NETCONF-based operations, including configuration, state data, remote
procedure calls (RPCs), and notifications. This allows a complete procedure calls (RPCs), and notifications. This allows a complete
description of all data sent between a NETCONF client and server. description of all data sent between a NETCONF client and server.
YANG models the hierarchical organization of data as a tree in which 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. 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 YANG provides clear and concise descriptions of the nodes, as well as
the interaction between those nodes. the interaction between those nodes.
YANG structures data models into modules and submodules. A module YANG structures data models into modules and submodules. A module
can import data from other external modules, and include data from can import data from other external modules, and include data from
submodules. The hierarchy can be extended, allowing one module to submodules. The hierarchy can be augmented, allowing one module to
add data nodes to the hierarchy defined in another module. This add data nodes to the hierarchy defined in another module. This
augmentation can be conditional, with new nodes appearing only if augmentation can be conditional, with new nodes appearing only if
certain conditions are met. certain conditions are met.
YANG models can describe constraints to be enforced on the data, YANG models can describe constraints to be enforced on the data,
restricting the appearance or value of nodes based on the presence or restricting the appearance or value of nodes based on the presence or
value of other nodes in the hierarchy. These constraints are value of other nodes in the hierarchy. These constraints are
enforceable by either the client or the server, and valid content enforceable by either the client or the server, and valid content
must abide by them. must abide by them.
skipping to change at page 14, line 5 skipping to change at page 14, line 5
and used in either that location or in another module or submodule and used in either that location or in another module or submodule
that imports or includes it. that imports or includes it.
YANG organizational constructs include defining lists where list YANG organizational constructs include defining lists where list
entries are identified by keys which distinguish them from each entries are identified by keys which distinguish them from each
other. Such lists may be defined as either sorted by user or other. Such lists may be defined as either sorted by user or
automatically sorted by the system. For user-sorted lists, automatically sorted by the system. For user-sorted lists,
operations are defined for manipulating the order of the list operations are defined for manipulating the order of the list
entries. entries.
YANG modules can be translated into an XML format called YIN YANG modules can be translated into an XML format called YANG
(Section 11), allowing applications using XML parsers and XSLT Independent Notation (YIN) (Section 11), allowing applications using
scripts to operate on the models. The conversion from YANG to YIN is XML parsers and XSLT scripts to operate on the models. The
loss-less, so content in YIN can round-tripped back into YANG. conversion from YANG to YIN is loss-less, so content in YIN can be
round-tripped back into YANG.
YANG strikes a balance between high-level data modeling and low-level YANG strikes a balance between high-level data modeling and low-level
bits-on-the-wire encoding. The reader of a YANG module can see the bits-on-the-wire encoding. The reader of a YANG module can see the
high-level view of the data model while understanding how the data high-level view of the data model while understanding how the data
will be encoded in NETCONF operations. will be encoded in NETCONF operations.
YANG is an extensible language, allowing extension statements to be YANG is an extensible language, allowing extension statements to be
defined by standards bodies, vendors, and individuals. The statement defined by standards bodies, vendors, and individuals. The statement
syntax allows these extensions to coexist with standard YANG syntax allows these extensions to coexist with standard YANG
statements in a natural way, while making extensions stand out statements in a natural way, while making extensions stand out
skipping to change at page 14, line 43 skipping to change at page 14, line 44
Like NETCONF, YANG targets smooth integration with device's native Like NETCONF, YANG targets smooth integration with device's native
management infrastructure. This allows implementations to leverage management infrastructure. This allows implementations to leverage
their existing access control mechanisms to protect or expose their existing access control mechanisms to protect or expose
elements of the data model. elements of the data model.
4.2. Language Overview 4.2. Language Overview
This section introduces some important constructs used in YANG that This section introduces some important constructs used in YANG that
will aid in the understanding of the language specifics in later will aid in the understanding of the language specifics in later
sections. This progressive approach handles the inter-related nature sections. This progressive approach handles the inter-related nature
of YANG concepts and statements. Specifics about YANG statements and of YANG concepts and statements. A detailed description of YANG
syntax begins in Section 7. statements and syntax begins in Section 7.
4.2.1. Modules and Submodules 4.2.1. Modules and Submodules
A module contains three types of statements: module-header A module contains three types of statements: module-header
statements, revision statements, and definition statements. The statements, revision statements, and definition statements. The
module header statements describe the module and give information module header statements describe the module and give information
about the module itself, the revision statements give information about the module itself, the revision statements give information
about the history of the module, and the definition statements are about the history of the module, and the definition statements are
the body of the module where the data model is defined. the body of the module where the data model is defined.
skipping to change at page 15, line 37 skipping to change at page 15, line 38
A leaf node contains simple data like an integer or a string. It has A leaf node contains simple data like an integer or a string. It has
exactly one value of a particular type, and no child nodes. exactly one value of a particular type, and no child nodes.
YANG Example: YANG Example:
leaf host-name { leaf host-name {
type string; type string;
description "Hostname for this system"; description "Hostname for this system";
} }
NETCONF XML Encoding: NETCONF XML Example:
<host-name>my.example.com</host-name> <host-name>my.example.com</host-name>
The "leaf" statement is covered in Section 7.6. The "leaf" statement is covered in Section 7.6.
4.2.2.2. Leaf-list Nodes 4.2.2.2. Leaf-list Nodes
A leaf-list is a sequence of leaf nodes with exactly one value of a A leaf-list is a sequence of leaf nodes with exactly one value of a
particular type per leaf. particular type per leaf.
YANG Example: YANG Example:
leaf-list domain-search { leaf-list domain-search {
type string; type string;
description "List of domain names to search"; description "List of domain names to search";
} }
NETCONF XML Encoding: NETCONF XML Example:
<domain-search>high.example.com</domain-search> <domain-search>high.example.com</domain-search>
<domain-search>low.example.com</domain-search> <domain-search>low.example.com</domain-search>
<domain-search>everywhere.example.com</domain-search> <domain-search>everywhere.example.com</domain-search>
The "leaf-list" statement is covered in Section 7.7. The "leaf-list" statement is covered in Section 7.7.
4.2.2.3. Container Nodes 4.2.2.3. Container Nodes
A container node is used to group related nodes in a subtree. A A container node is used to group related nodes in a subtree. A
skipping to change at page 16, line 37 skipping to change at page 16, line 37
container system { container system {
container login { container login {
leaf message { leaf message {
type string; type string;
description description
"Message given at start of login session"; "Message given at start of login session";
} }
} }
} }
NETCONF XML Encoding: NETCONF XML Example:
<system> <system>
<login> <login>
<message>Good morning, Dave</message> <message>Good morning, Dave</message>
</login> </login>
</system> </system>
The "container" statement is covered in Section 7.5. The "container" statement is covered in Section 7.5.
4.2.2.4. List Nodes 4.2.2.4. List Nodes
skipping to change at page 17, line 21 skipping to change at page 17, line 21
type string; type string;
} }
leaf full-name { leaf full-name {
type string; type string;
} }
leaf class { leaf class {
type string; type string;
} }
} }
NETCONF XML Encoding: NETCONF XML Example:
<user> <user>
<name>glocks</name> <name>glocks</name>
<full-name>Goldie Locks</full-name> <full-name>Goldie Locks</full-name>
<class>intruder</class> <class>intruder</class>
</user> </user>
<user> <user>
<name>snowey</name> <name>snowey</name>
<full-name>Snow White</full-name> <full-name>Snow White</full-name>
<class>free-loader</class> <class>free-loader</class>
skipping to change at page 19, line 22 skipping to change at page 19, line 22
context for the state data. context for the state data.
In this example, two leafs are defined for each interface, a In this example, two leafs are defined for each interface, a
configured speed and an observed speed. The observed speed is not configured speed and an observed speed. The observed speed is not
configuration, so it can be returned with NETCONF <get> operations, configuration, so it can be returned with NETCONF <get> operations,
but not with <get-config> operations. The observed speed is not but not with <get-config> operations. The observed speed is not
configuration data, and cannot be manipulated using <edit-config>. configuration data, and cannot be manipulated using <edit-config>.
list interface { list interface {
key "name"; key "name";
config true;
leaf name { leaf name {
type string; type string;
} }
leaf speed { leaf speed {
type enumeration { type enumeration {
enum 10m; enum 10m;
enum 100m; enum 100m;
enum auto; enum auto;
} }
skipping to change at page 20, line 33 skipping to change at page 20, line 33
| leafref | Text/Number | A reference to a leaf | | leafref | Text/Number | A reference to a leaf |
| | | instance | | | | instance |
| string | Text | Human readable string | | string | Text | Human readable string |
| uint8 | Number | 8-bit unsigned integer | | uint8 | Number | 8-bit unsigned integer |
| uint16 | Number | 16-bit unsigned integer | | uint16 | Number | 16-bit unsigned integer |
| uint32 | Number | 32-bit unsigned integer | | uint32 | Number | 32-bit unsigned integer |
| uint64 | Number | 64-bit unsigned integer | | uint64 | Number | 64-bit unsigned integer |
| union | Text/Number | Choice of member types | | union | Text/Number | Choice of member types |
+---------------------+-------------+-------------------------------+ +---------------------+-------------+-------------------------------+
The "type" statement is covered in Section 9. The "type" statement is covered in Section 7.4.
4.2.5. Derived Types (typedef) 4.2.5. Derived Types (typedef)
YANG can define derived types from base types using the "typedef" YANG can define derived types from base types using the "typedef"
statement. A base type can be either a built-in type or a derived statement. A base type can be either a built-in type or a derived
type, allowing a hierarchy of derived types. type, allowing a hierarchy of derived types.
A derived type can be used as the argument for the "type" statement. A derived type can be used as the argument for the "type" statement.
YANG Example: YANG Example:
typedef percent { typedef percent {
type uint16 { type uint8 {
range "0 .. 100"; range "0 .. 100";
} }
description "Percentage"; description "Percentage";
} }
leaf completed { leaf completed {
type percent; type percent;
} }
NETCONF XML Encoding: NETCONF XML Example:
<completed>20</completed> <completed>20</completed>
The "typedef" statement is covered in Section 7.3. The "typedef" statement is covered in Section 7.3.
4.2.6. Reusable Node Groups (grouping) 4.2.6. Reusable Node Groups (grouping)
Groups of nodes can be assembled into the equivalent of complex types Groups of nodes can be assembled into the equivalent of complex types
using the "grouping" statement. "grouping" defines a set of nodes using the "grouping" statement. "grouping" defines a set of nodes
that are instantiated with the "uses" statement: that are instantiated with the "uses" statement:
skipping to change at page 21, line 45 skipping to change at page 21, line 45
description "Target port number"; description "Target port number";
} }
} }
container peer { container peer {
container destination { container destination {
uses target; uses target;
} }
} }
NETCONF XML Encoding: NETCONF XML Example:
<peer> <peer>
<destination> <destination>
<address>192.0.2.1</address> <address>192.0.2.1</address>
<port>830</port> <port>830</port>
</destination> </destination>
</peer> </peer>
The grouping can be refined as it is used, allowing certain The grouping can be refined as it is used, allowing certain
statements to be overridden. In this example, the description is statements to be overridden. In this example, the description is
refined: refined:
skipping to change at page 22, line 48 skipping to change at page 22, line 48
sets of schema nodes that cannot appear together. Each "case" may sets of schema nodes that cannot appear together. Each "case" may
contain multiple nodes, but each node may appear in only one "case" contain multiple nodes, but each node may appear in only one "case"
under a "choice". under a "choice".
When an element from one case is created, all elements from all other When an element from one case is created, all elements from all other
cases are implicitly deleted. The device handles the enforcement of cases are implicitly deleted. The device handles the enforcement of
the constraint, preventing incompatibilities from existing in the the constraint, preventing incompatibilities from existing in the
configuration. configuration.
The choice and case nodes appear only in the schema tree, not in the The choice and case nodes appear only in the schema tree, not in the
data tree or XML encoding. The additional levels of hierarchy are data tree or NETCONF PDUs. The additional levels of hierarchy are
not needed beyond the conceptual schema. not needed beyond the conceptual schema.
YANG Example: YANG Example:
container food { container food {
choice snack { choice snack {
mandatory true;
case sports-arena { case sports-arena {
leaf pretzel { leaf pretzel {
type empty; type empty;
} }
leaf beer { leaf beer {
type empty; type empty;
} }
} }
case late-night { case late-night {
leaf chocolate { leaf chocolate {
type enumeration { type enumeration {
enum dark; enum dark;
enum milk; enum milk;
enum first-available; enum first-available;
} }
} }
} }
} }
} }
NETCONF XML Encoding: NETCONF XML Example:
<food> <food>
<chocolate>first-available</chocolate> <pretzel/>
<beer/>
</food> </food>
The "choice" statement is covered in Section 7.9. The "choice" statement is covered in Section 7.9.
4.2.8. Extending Data Models (augment) 4.2.8. Extending Data Models (augment)
YANG allows a module to insert additional nodes into data models, YANG allows a module to insert additional nodes into data models,
including both the current module (and its submodules) or an external including both the current module (and its submodules) or an external
module. This is useful e.g. for vendors to add vendor-specific module. This is useful for example for vendors to add vendor-
parameters to standard data models in an interoperable way. specific parameters to standard data models in an interoperable way.
The "augment" statement defines the location in the data model The "augment" statement defines the location in the data model
hierarchy where new nodes are inserted, and the "when" statement hierarchy where new nodes are inserted, and the "when" statement
defines the conditions when the new nodes are valid. defines the conditions when the new nodes are valid.
YANG Example: YANG Example:
augment system/login/user { augment /system/login/user {
when "class != 'wheel'"; when "class != 'wheel'";
leaf uid { leaf uid {
type uint16 { type uint16 {
range "1000 .. 30000"; range "1000 .. 30000";
} }
} }
} }
This example defines a "uid" node that only is valid when the user's This example defines a "uid" node that only is valid when the user's
"class" is not "wheel". "class" is not "wheel".
If a module augments another model, the XML representation of the If a module augments another module, the XML representation of the
data will reflect the prefix of the augmenting model. For example, data will reflect the prefix of the augmenting module. For example,
if the above augmentation were in a module with prefix "other", the if the above augmentation were in a module with prefix "other", the
XML would look like: XML would look like:
NETCONF XML Encoding: NETCONF XML Example:
<user> <user>
<name>alicew</name> <name>alicew</name>
<full-name>Alice N. Wonderland</full-name> <full-name>Alice N. Wonderland</full-name>
<class>drop-out</class> <class>drop-out</class>
<other:uid>1024</other:uid> <other:uid>1024</other:uid>
</user> </user>
The "augment" statement is covered in Section 7.15. The "augment" statement is covered in Section 7.15.
skipping to change at page 25, line 4 skipping to change at page 25, line 4
leaf image-name { leaf image-name {
type string; type string;
} }
} }
output { output {
leaf status { leaf status {
type string; type string;
} }
} }
} }
NETCONF XML Encoding: NETCONF XML Example:
<rpc message-id="101" <rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<activate-software-image xmlns="http://acme.example.com/system"> <activate-software-image xmlns="http://acme.example.com/system">
<name>acmefw-2.3</name> <image-name>acmefw-2.3</image-name>
</activate-software-image> </activate-software-image>
</rpc> </rpc>
<rpc-reply message-id="101" <rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<status xmlns="http://acme.example.com/system"> <status xmlns="http://acme.example.com/system">
The image acmefw-2.3 is being installed. The image acmefw-2.3 is being installed.
</status> </status>
</rpc-reply> </rpc-reply>
skipping to change at page 25, line 38 skipping to change at page 25, line 38
YANG Example: YANG Example:
notification link-failure { notification link-failure {
description "A link failure has been detected"; description "A link failure has been detected";
leaf if-name { leaf if-name {
type leafref { type leafref {
path "/interfaces/interface/name"; path "/interfaces/interface/name";
} }
} }
leaf if-admin-status { leaf if-admin-status {
type ifAdminStatus; type admin-status;
}
leaf if-oper-status {
type oper-status;
} }
} }
NETCONF XML Encoding: NETCONF XML Example:
<notification <notification
xmlns="urn:ietf:params:netconf:capability:notification:1.0"> xmlns="urn:ietf:params:netconf:capability:notification:1.0">
<eventTime>2007-09-01T10:00:00Z</eventTime> <eventTime>2007-09-01T10:00:00Z</eventTime>
<link-failure xmlns="http://acme.example.com/system"> <link-failure xmlns="http://acme.example.com/system">
<if-name>so-1/2/3.0</if-name> <if-name>so-1/2/3.0</if-name>
<if-admin-status>up</if-admin-status> <if-admin-status>up</if-admin-status>
<if-oper-status>down</if-oper-status>
</link-failure> </link-failure>
</notification> </notification>
The "notification" statement is covered in Section 7.14. The "notification" statement is covered in Section 7.14.
5. Language Concepts 5. Language Concepts
5.1. Modules and Submodules 5.1. Modules and Submodules
The module is the base unit of definition in YANG. A module defines 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, a single data model. A module can define a complete, cohesive model,
or augment an existing data model with additional nodes. or augment an existing data model with additional nodes.
skipping to change at page 27, line 13 skipping to change at page 27, line 13
The "notification" statement is covered in Section 7.14. The "notification" statement is covered in Section 7.14.
5. Language Concepts 5. Language Concepts
5.1. Modules and Submodules 5.1. Modules and Submodules
The module is the base unit of definition in YANG. A module defines 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, a single data model. A module can define a complete, cohesive model,
or augment an existing data model with additional nodes. or augment an existing data model with additional nodes.
Submodule are partial modules that contribute definitions to a Submodules are partial modules that contribute definitions to a
module. A module may include any number of submodules, but each module. A module may include any number of submodules, but each
submodule may belong to only one module. submodule may belong to only one module.
The names of all standard modules and submodules MUST be unique. The names of all standard modules and submodules MUST be unique.
Developers of enterprise modules are RECOMMENDED to choose names for Developers of enterprise modules are RECOMMENDED to choose names for
their modules that will have a low probability of colliding with their modules that will have a low probability of colliding with
standard or other enterprise modules, e.g. by using the enterprise or standard or other enterprise modules, e.g., by using the enterprise
organization name as a prefix. or organization name as a prefix.
A module uses the "include" statement to include its submodules, and A module uses the "include" statement to include its submodules, and
the "import" statement to reference external modules. Similarly, a the "import" statement to reference external modules. Similarly, a
submodule uses the "import" statement to reference other modules, and submodule uses the "import" statement to reference other modules, and
uses the "include" statement to reference other submodules within its uses the "include" statement to reference other submodules within its
module. A module or submodule MUST NOT include submodules from other module. A module or submodule MUST NOT include submodules from other
modules, and a submodule MUST NOT import its own module. modules, and a submodule MUST NOT import its own module.
The import and include statements are used to make definitions The import and include statements are used to make definitions
available to other modules and submodules: available to other modules and submodules:
skipping to change at page 27, line 51 skipping to change at page 27, line 51
submodule. submodule.
There MUST NOT be any circular chains of imports or includes. For There MUST NOT be any circular chains of imports or includes. For
example, if submodule "a" includes submodule "b", "b" cannot include example, if submodule "a" includes submodule "b", "b" cannot include
"a". "a".
When a definition in an external module is referenced, a locally When a definition in an external module is referenced, a locally
defined prefix MUST be used, followed by ":", and then the external defined prefix MUST be used, followed by ":", and then the external
identifier. References to definitions in the local module MAY use identifier. References to definitions in the local module MAY use
the prefix notation. Since built-in data types do not belong to any the prefix notation. Since built-in data types do not belong to any
module and have no prefix, references to built-in data types (e.g. module and have no prefix, references to built-in data types (e.g.,
int32) cannot use the prefix notation. int32) cannot use the prefix notation.
5.1.1. Import and Include by Revision 5.1.1. Import and Include by Revision
Published modules evolve independently over time. In order to allow Published modules evolve independently over time. In order to allow
for this evolution, modules need to be imported using specific for this evolution, modules need to be imported using specific
revisions. When a module is written, it uses the current revisions revisions. When a module is written, it uses the current revisions
of other modules, based on what is available at the time. As future of other modules, based on what is available at the time. As future
revisions of the imported modules are published, the importing module revisions of the imported modules are published, the importing module
is unaffected and its contents are unchanged. When the author of the is unaffected and its contents are unchanged. When the author of the
module is prepared to move to the most recently published revision of module is prepared to move to the most recently published revision of
an imported module, the module is republished with an updated import an imported module, the module is republished with an updated import
statement. By republishing with the new revision, the author is statement. By republishing with the new revision, the authors
explicitly indicating their acceptance of any changes in the imported explicitly indicate their acceptance of any changes in the imported
module. module.
For submodules, the issue is related but simpler. A module or For submodules, the issue is related but simpler. A module or
submodule that includes submodules need to specify the revision of submodule that includes submodules need to specify the revision of
the included submodules. If a submodule changes, any module or the included submodules. If a submodule changes, any module or
submodule that includes it needs to be updated. submodule that includes it needs to be updated.
For example, module "b" imports module "a". For example, module "b" imports module "a".
module a { module a {
revision 2008-01-01 { ... } revision 2008-01-01 { ... }
grouping a { grouping a {
leaf eh { .... } leaf eh { .... }
} }
} }
module b { module b {
import a { import a {
prefix a; prefix p;
revision-date 2008-01-01; revision-date 2008-01-01;
} }
container bee { container bee {
uses a:a; uses p:a;
} }
} }
When the author of "a" publishes a new revision, the changes may not When the author of "a" publishes a new revision, the changes may not
be acceptable to the author of "b". If the new revision is be acceptable to the author of "b". If the new revision is
acceptable, the author of "b" can republish with an updated revision acceptable, the author of "b" can republish with an updated revision
in the import statement. in the import statement.
5.1.2. Module Hierarchies 5.1.2. Module Hierarchies
YANG allows modeling of data in multiple hierarchies, where data may YANG allows modeling of data in multiple hierarchies, where data may
have more than one top-level node. Models that have multiple top- have more than one top-level node. Models that have multiple top-
level nodes are sometimes convenient, and are supported by YANG. level nodes are sometimes convenient, and are supported by YANG.
NETCONF is capable of carrying any XML content as the payload in the NETCONF is capable of carrying any XML content as the payload in the
<config> element. The top-level nodes of YANG modules are encoded as <config> and <data> elements. The top-level nodes of YANG modules
child elements within the <config> element. are encoded as child elements within these elements. This
encapsulation guarantees that the corresponding NETCONF PDUs are
always well-formed XML documents.
For example: For example:
module my-config { module my-config {
namespace "http://example.com/schema/config"; namespace "http://example.com/schema/config";
prefix "co"; prefix "co";
container system { ... } container system { ... }
container routing { ... } container routing { ... }
} }
skipping to change at page 29, line 43 skipping to change at page 29, line 45
<routing xmlns="http://example.com/schema/config"> <routing xmlns="http://example.com/schema/config">
<!-- routing data here --> <!-- routing data here -->
</routing> </routing>
</config> </config>
</edit-config> </edit-config>
</rpc> </rpc>
5.2. File Layout 5.2. File Layout
YANG modules and submodules are typically stored in files, one module YANG modules and submodules are typically stored in files, one module
or submodule per file. The name of the file SHOULD be on the form: or submodule per file. The name of the file SHOULD be of the form:
module-or-submodule-name ['.' revision-date] ( '.yang' / '.yin' ) module-or-submodule-name ['.' revision-date] ( '.yang' / '.yin' )
YANG compilers can find imported modules and included submodules via YANG compilers can find imported modules and included submodules via
this convention. While the YANG language defines modules, tools may this convention. While the YANG language defines modules, tools may
compile submodules independently for performance and manageability compile submodules independently for performance and manageability
reasons. Many errors and warnings that cannot be detected during reasons. Many errors and warnings that cannot be detected during
submodule compilation may be delayed until the submodules are linked submodule compilation may be delayed until the submodules are linked
into a cohesive module. into a cohesive module.
skipping to change at page 30, line 17 skipping to change at page 30, line 19
All YANG definitions are specified within a module that is bound to a All YANG definitions are specified within a module that is bound to a
particular XML Namespace [XML-NAMES], which is a globally unique URI particular XML Namespace [XML-NAMES], which is a globally unique URI
[RFC3986]. A NETCONF client or server uses the namespace during XML [RFC3986]. A NETCONF client or server uses the namespace during XML
encoding of data. encoding of data.
Namespaces for modules published in RFC streams MUST be assigned by Namespaces for modules published in RFC streams MUST be assigned by
IANA, see Section 14. IANA, see Section 14.
Namespaces for private modules are assigned by the organization Namespaces for private modules are assigned by the organization
owning the module without a central registry. It is RECOMMENDED to owning the module without a central registry. Namespace URIs MUST be
choose namespaces that will have a low probability of colliding with choosen so they cannot collide with standard or other enterprise
standard or other enterprise modules, e.g. by using the enterprise or namespaces, for example by using the enterprise or organization name
organization name in the namespace. in the namespace.
The "namespace" statement is covered in Section 7.1.3. The "namespace" statement is covered in Section 7.1.3.
5.3.1. YANG XML Namespace 5.3.1. YANG XML Namespace
YANG defines its own XML namespace for NETCONF <edit-config> YANG defines an XML namespace for NETCONF <edit-config> operations
operations. This namespace is "urn:ietf:params:xml:ns:yang:1". and <error-info> content. This namespace is
"urn:ietf:params:xml:ns:yang:1".
5.4. Resolving Grouping, Type, and Identity Names 5.4. Resolving Grouping, Type, and Identity Names
Grouping, type, and identity names are resolved in the context in Grouping, type, and identity names are resolved in the context in
which they are defined, rather than the context in which they are which they are defined, rather than the context in which they are
used. Users of groupings, typedefs, and identities are not required used. Users of groupings, typedefs, and identities are not required
to import modules or include submodules to satisfy all references to import modules or include submodules to satisfy all references
made by the original definition. This behaves like static scoping in made by the original definition. This behaves like static scoping in
a conventional programming language. a conventional programming language.
skipping to change at page 31, line 33 skipping to change at page 31, line 35
or grouping, or one which uses the prefix of the local module, it or grouping, or one which uses the prefix of the local module, it
searches up the levels of hierarchy in the schema tree, starting at searches up the levels of hierarchy in the schema tree, starting at
the current level, for the definition of the type or grouping. the current level, for the definition of the type or grouping.
5.6. Conformance 5.6. Conformance
Conformance is a measure of how accurately a device follows the Conformance is a measure of how accurately a device follows the
model. Generally speaking, devices are responsible for implementing model. Generally speaking, devices are responsible for implementing
the model faithfully, allowing applications to treat devices which the model faithfully, allowing applications to treat devices which
implement the model identically. Deviations from the model can implement the model identically. Deviations from the model can
reduce the utility of the model and increase fragility into reduce the utility of the model and increase fragility of
applications that use it. applications that use it.
YANG modelers have three mechanisms for conformance: YANG modelers have three mechanisms for conformance:
o the basic behavior of the model o the basic behavior of the model
o optional features that are part of the model o optional features that are part of the model
o deviations from the model o deviations from the model
skipping to change at page 32, line 18 skipping to change at page 32, line 21
conditional, based on the device. The device controls whether these conditional, based on the device. The device controls whether these
conditional portions of the model are supported or valid for that conditional portions of the model are supported or valid for that
particular device. particular device.
For example, a syslog data model may choose to include the ability to For example, a syslog data model may choose to include the ability to
save logs locally, but the modeler will realize that this is only save logs locally, but the modeler will realize that this is only
possible if the device has local storage. If there is no local possible if the device has local storage. If there is no local
storage, an application should not tell the device to save logs. storage, an application should not tell the device to save logs.
YANG supports this conditional mechanism using a construct called YANG supports this conditional mechanism using a construct called
"features". Features give the modeler a mechanism for making "feature". Features give the modeler a mechanism for making portions
portions of the module conditional in a manner that is controlled by of the module conditional in a manner that is controlled by the
the device. The model can express constructs which are not device. The model can express constructs which are not universally
universally present in all devices. These features are included in present in all devices. These features are included in the model
the model definition, allowing a consistent view and allowing definition, allowing a consistent view and allowing applications to
applications to learn which features are supported and tailor their learn which features are supported and tailor their behavior to the
behavior to the device. device.
A module may declare any number of features, identified by simple A module may declare any number of features, identified by simple
strings, and may make portions of the module optional based on those strings, and may make portions of the module optional based on those
feature. If the device supports a feature, then the corresponding features. If the device supports a feature, then the corresponding
portions of the module are valid for that device. If the device portions of the module are valid for that device. If the device
doesn't support the feature, those parts of the module are not valid, doesn't support the feature, those parts of the module are not valid,
and applications should behave accordingly. and applications should behave accordingly.
Features are defined using the "feature" statement. Definitions in Features are defined using the "feature" statement. Definitions in
the module that are conditional to the feature are noted by the the module that are conditional to the feature are noted by the
"if-feature" statement with the name of the feature as its argument. "if-feature" statement with the name of the feature as its argument.
Further details are available in Section 7.18.1. Further details are available in Section 7.18.1.
skipping to change at page 33, line 39 skipping to change at page 33, line 43
Where "revision-date" is the revision of the module (see Where "revision-date" is the revision of the module (see
Section 7.1.9) that the NETCONF server implements, "module-name" is Section 7.1.9) that the NETCONF server implements, "module-name" is
the name of module as it appears in the "module" statement (see 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 Section 7.1), "namespace-uri" is the namespace for the module as it
appears in the "namespace" statement, "feature" is the name of an appears in the "namespace" statement, "feature" is the name of an
optional feature implemented by the device (see Section 7.18.1), and optional feature implemented by the device (see Section 7.18.1), and
"deviation" is the name of a module defining device deviations (see "deviation" is the name of a module defining device deviations (see
Section 7.18.3). Section 7.18.3).
In the parameter list, each named parameter MUST occur at most once.
5.6.4.1. Modules 5.6.4.1. Modules
Devices indicate the names of supported modules via the <hello> Devices indicate the names of supported modules via the <hello>
message. Module namespaces are encoded as the base URI in the message. Module namespaces are encoded as the base URI in the
capability string, and the module name is encoded as the "module" capability string, and the module name is encoded as the "module"
parameter to the base URI. parameter to the base URI.
Modules that do not contribute any data definitions, rpcs, Modules that do not contribute any data definitions, rpcs,
notifications, or deviations to the device MAY be advertised in the notifications, or deviations to the device MAY be advertised in the
<hello> message. <hello> message.
skipping to change at page 35, line 5 skipping to change at page 35, line 5
<hello> <hello>
<capability> <capability>
http://example.com/syslog?module=syslog&deviations=my-devs http://example.com/syslog?module=syslog&deviations=my-devs
</capability> </capability>
<capability> <capability>
http://example.com/my-deviations?module=my-devs http://example.com/my-deviations?module=my-devs
</capability> </capability>
</hello> </hello>
5.6.5. Mapping to the NETCONF Schema Discovery Mechanism
+--------------------------------------------------------------+
| Open Question |
+--------------------------------------------------------------+
| Move this section to the monitoring spec? |
+--------------------------------------------------------------+
The NETCONF Schema Discovery process is defined in [TBD]. It
specifies a "schema" list where each entry is identified by
"identifier", "version", and "format".
All revisions of all YANG modules and submodules supported by a
device SHOULD be present in the "schema" list, including modules with
only typedefs and groupings.
The following table specifies how the fields in the "schema" list are
used for YANG modules and submodules:
identifier - the name of the module or submodule.
version - the supported YANG revision string.
format - the string "YANG".
namespace - the module's namespace. if the list entry describes a
submodule, this field contains the namespace of the
module to which the submodule belongs.
Note that the format is "YANG", even if the YIN syntax is used.
6. YANG syntax 6. YANG syntax
The YANG syntax is similar to that of SMIng [RFC3780] and programming The YANG syntax is similar to that of SMIng [RFC3780] and programming
languages like C and C++. This C-like syntax was chosen specifically languages like C and C++. This C-like syntax was chosen specifically
for its readability, since YANG values the time and effort of the for its readability, since YANG values the time and effort of the
readers of models above those of modules writers and YANG tool-chain readers of models above those of modules writers and YANG tool-chain
developers. This section introduces the YANG syntax. developers. This section introduces the YANG syntax.
YANG modules are written in the UTF-8 [RFC3629] character set. YANG modules are written in the UTF-8 [RFC3629] character set.
skipping to change at page 36, line 41 skipping to change at page 35, line 41
A token in YANG is either a keyword, a string, ";", "{", or "}". A A token in YANG is either a keyword, a string, ";", "{", or "}". A
string can be quoted or unquoted. A keyword is either one of the string can be quoted or unquoted. A keyword is either one of the
core YANG keywords defined in this document, or a prefix identifier, core YANG keywords defined in this document, or a prefix identifier,
followed by ":", followed by a language extension keyword. Keywords followed by ":", followed by a language extension keyword. Keywords
are case sensitive. See Section 6.2 for a formal definition of are case sensitive. See Section 6.2 for a formal definition of
identifiers. identifiers.
6.1.3. Quoting 6.1.3. Quoting
If a string contains any whitespace characters, a semicolon (";"), If a string contains any space or tab characters, a semicolon (";"),
braces ("{" or "}"), or comment sequences ("//", "/*", or "*/"), then braces ("{" or "}"), or comment sequences ("//", "/*", or "*/"), then
it MUST be enclosed within double or single quotes. it MUST be enclosed within double or single quotes.
If the double quoted string contains a line break followed by If the double quoted string contains a line break followed by space
whitespace which is used to indent the text according to the layout or tab characters which is used to indent the text according to the
in the YANG file, this leading whitespace is stripped from the layout in the YANG file, this leading whitespace is stripped from the
string, up to at most the same column of the double quote character. string, up to at most the column of the double quote character.
If the double quoted string contains whitespace before a line break, If the double quoted string contains space or tab characters before a
this trailing whitespace is stripped from the string. line break, this trailing whitespace is stripped from the string.
A single quoted string (enclosed within ' ') preserves each character A single quoted string (enclosed within ' ') preserves each character
within the quotes. A single quote character can not occur in a within the quotes. A single quote character cannot occur in a single
single quoted string, even when preceded by a backslash. quoted string, even when preceded by a backslash.
If a quoted string is followed by 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 is done before
concatenation.
Within a double quoted string (enclosed within " "), a backslash Within a double quoted string (enclosed within " "), a backslash
character introduces a special character, which depends on the character introduces a special character, which depends on the
character that immediately follows the backslash: character that immediately follows the backslash:
\n new line \n new line
\t a tab character \t a tab character
\" a double quote \" a double quote
\\ a single backslash \\ a single backslash
If a quoted string is followed by a plus character ("+"), followed by
another quoted string, the two strings are concatenated into one
string, allowing multiple concatenations to build one string.
Whitespace trimming and substition of backslash-escaped characters in
double quoted strings is done before concatenation.
6.1.3.1. Quoting Examples 6.1.3.1. Quoting Examples
The following strings are equivalent: The following strings are equivalent:
hello hello
"hello" "hello"
'hello' 'hello'
"hel" + "lo" "hel" + "lo"
'hel' + "lo" 'hel' + "lo"
skipping to change at page 38, line 19 skipping to change at page 37, line 19
letter or an underscore character, followed by zero or more ASCII letter or an underscore character, followed by zero or more ASCII
letters, digits, underscore characters, hyphens, and dots. letters, digits, underscore characters, hyphens, and dots.
Implementations MUST support identifiers up to 64 characters in Implementations MUST support identifiers up to 64 characters in
length. Identifiers are case sensitive. The identifier syntax is length. Identifiers are case sensitive. The identifier syntax is
formally defined by the rule "identifier" in Section 12. Identifiers formally defined by the rule "identifier" in Section 12. Identifiers
can be specified as quoted or unquoted strings. can be specified as quoted or unquoted strings.
6.2.1. Identifiers and their namespaces 6.2.1. Identifiers and their namespaces
Each identifier is valid in a namespace which depends on the type of Each identifier is valid in a namespace which depends on the type of
the YANG item being defined: the YANG item being defined. All identifiers defined in a namespace
MUST be unique.
o All module and submodule names share the same global module o All module and submodule names share the same global module
identifier namespace. identifier namespace.
o All extension names defined in a module and its submodules share o All extension names defined in a module and its submodules share
the same extension identifier namespace. the same extension identifier namespace.
o All feature names defined in a module and its submodules share the o All feature names defined in a module and its submodules share the
same feature identifier namespace. same feature identifier namespace.
o All identity names defined in a module and its submodules share o All identity names defined in a module and its submodules share
the same identity identifier namespace. the same identity identifier namespace.
o All derived type names defined within a parent node or at the top- o All derived type names defined within a parent node or at the top-
level of the module or its submodules share the same type level of the module or its submodules share the same type
identifier namespace. This namespace is scoped to the parent node identifier namespace. This namespace is scoped to all descendant
or module. nodes of the parent node or module. This means that any
descendent node may use that typedef, and it MUST NOT define a
typedef with the same name.
o All groupings defined within a parent node or at the top-level of o All groupings defined within a parent node or at the top-level of
the module or its submodules share the same grouping identifier the module or its submodules share the same type identifier
namespace. This namespace is scoped to the parent node or module. namespace. This namespace is scoped to all descendant nodes of
the parent node or module. This means that any descendent node
may use that grouping, and it MUST NOT define a grouping with the
same name.
o All leafs, leaf-lists, lists, containers, choices, rpcs, and o All leafs, leaf-lists, lists, containers, choices, rpcs,
notifications defined within a parent node or at the top-level of notifications, and anyxmls defined within a parent node or at the
the module or its submodules share the same identifier namespace. top-level of the module or its submodules share the same
This namespace is scoped to the parent node or module, unless the identifier namespace. This namespace is scoped to the parent node
parent node is a case node. In that case, the namespace is scoped or module, unless the parent node is a case node. In that case,
to the parent node of the case node's parent choice node. the namespace is scoped to the parent node of the case node's
parent choice node.
o All cases within a choice share the same case identifier o All cases within a choice share the same case identifier
namespace. This namespace is scoped to the parent choice node. namespace. This namespace is scoped to the parent choice node.
All identifiers defined in a namespace MUST be unique.
Forward references are allowed in YANG. Forward references are allowed in YANG.
6.3. Statements 6.3. Statements
A YANG module contains a sequence of statements. Each statement A YANG module contains a sequence of statements. Each statement
starts with a keyword, followed by zero or one argument, followed starts with a keyword, followed by zero or one argument, followed
either by a semicolon (";") or a block of substatements enclosed either by a semicolon (";") or a block of substatements enclosed
within braces ("{ }"): within braces ("{ }"):
statement = keyword [argument] (";" / "{" *statement "}") statement = keyword [argument] (";" / "{" *statement "}")
skipping to change at page 39, line 44 skipping to change at page 38, line 49
YANG relies on XPath 1.0 [XPATH] as a notation for specifying many YANG relies on XPath 1.0 [XPATH] as a notation for specifying many
inter-node references and dependencies. NETCONF clients and servers inter-node references and dependencies. NETCONF clients and servers
are not required to implement an XPath interpreter, but MUST ensure are not required to implement an XPath interpreter, but MUST ensure
that the requirements encoded in the data model are enforced. The that the requirements encoded in the data model are enforced. The
manner of enforcement is an implementation decision. The XPath manner of enforcement is an implementation decision. The XPath
expressions MUST be valid, but any implementation may choose to expressions MUST be valid, but any implementation may choose to
implement them by hand, rather than using the XPath expression implement them by hand, rather than using the XPath expression
directly. directly.
XPath expressions are evaluated in the context of the current node, XPath expressions are evaluated in the context of the current node.
with the namespace of the current module defined as the null The namespace URI of the current module is used for any unprefixed
namespace. References to identifiers in external modules MUST be node name appearing in an XPath expression. References to
qualified with appropriate prefixes, and references to the current identifiers defined in external modules MUST be qualified with
module and its submodules MAY use a prefix. appropriate prefixes, and references to identifiers defined in the
current module and its submodules MAY use a prefix.
The above concept of default namespace is adopted from XPath 2.0
[XPATH2.0]. It helps simplify XPath expressions in YANG. No
ambiguity may ever arise because YANG node identifiers are always
qualified names with a non-null namespace URI.
The data model used in the XPath expressions is the same as that used The data model used in the XPath expressions is the same as that used
in XPath 1.0 [XPATH], with the same extension for root node children in XPath 1.0 [XPATH], with the same extension for root node children
as used by XSLT 1.0 [XSLT] (section 3.1). Specifically, it means as used by XSLT 1.0 [XSLT] (section 3.1). Specifically, it means
that the root node may have any number of root node children. that the root node may have any number of element nodes as its
children.
6.4.1. XPath Context
All YANG XPath expressions share the following XPath context
definition:
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 prefix refer to nodes in the
namespace of 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.
o The set of variable bindings is empty.
The context node varies with the YANG XPath expression, and is
specified where the YANG statement with the XPath expression is
defined.
7. YANG Statements 7. YANG Statements
The following sections describe all of the YANG core statements. The following sections describe all of the YANG core statements.
Note that even a statement which does not have any substatements Note that even a statement which does not have any substatements
defined in core YANG can have vendor-specific extensions as defined in core YANG can have vendor-specific extensions as
substatements. For example, the "description" statement does not substatements. For example, the "description" statement does not
have any substatements defined in core YANG, but the following is have any substatements defined in core YANG, but the following is
legal: legal:
skipping to change at page 41, line 32 skipping to change at page 40, line 32
statements which belong to the module together. The "module" statements which belong to the module together. The "module"
statement's argument is the name of the module, followed by a block statement's argument is the name of the module, followed by a block
of substatements that hold detailed module information. The module of substatements that hold detailed module information. The module
name follows the rules for identifiers in Section 6.2. name follows the rules for identifiers in Section 6.2.
Names of modules published in RFC streams MUST be assigned by IANA, Names of modules published in RFC streams MUST be assigned by IANA,
see Section 14. see Section 14.
Private module names are assigned by the organization owning the Private module names are assigned by the organization owning the
module without a central registry. It is RECOMMENDED to choose module without a central registry. It is RECOMMENDED to choose
submodule names that will have a low probability of colliding with module names that will have a low probability of colliding with
standard or other enterprise modules and submodules, e.g. by using standard or other enterprise modules and submodules, e.g., by using
the enterprise or organization name as a prefix. the enterprise or organization name as a prefix.
A module SHOULD have the following layout: A module SHOULD have the following layout:
module <module-name> { module <module-name> {
// header information // header information
<yang-version statement> <yang-version statement>
<namespace statement> <namespace statement>
<prefix statement> <prefix statement>
skipping to change at page 43, line 17 skipping to change at page 42, line 17
| anyxml | 7.10 | 0..n | | anyxml | 7.10 | 0..n |
| augment | 7.15 | 0..n | | augment | 7.15 | 0..n |
| choice | 7.9 | 0..n | | choice | 7.9 | 0..n |
| contact | 7.1.8 | 0..1 | | contact | 7.1.8 | 0..1 |
| container | 7.5 | 0..n | | container | 7.5 | 0..n |
| description | 7.19.3 | 0..1 | | description | 7.19.3 | 0..1 |
| deviation | 7.18.3 | 0..n | | deviation | 7.18.3 | 0..n |
| extension | 7.17 | 0..n | | extension | 7.17 | 0..n |
| feature | 7.18.1 | 0..n | | feature | 7.18.1 | 0..n |
| grouping | 7.11 | 0..n | | grouping | 7.11 | 0..n |
| identity | 7.16 | 0..n |
| import | 7.1.5 | 0..n | | import | 7.1.5 | 0..n |
| include | 7.1.6 | 0..n | | include | 7.1.6 | 0..n |
| leaf | 7.6 | 0..n | | leaf | 7.6 | 0..n |
| leaf-list | 7.7 | 0..n | | leaf-list | 7.7 | 0..n |
| list | 7.8 | 0..n | | list | 7.8 | 0..n |
| namespace | 7.1.3 | 1 | | namespace | 7.1.3 | 1 |
| notification | 7.14 | 0..n | | notification | 7.14 | 0..n |
| organization | 7.1.7 | 0..1 | | organization | 7.1.7 | 0..1 |
| prefix | 7.1.4 | 1 | | prefix | 7.1.4 | 1 |
| reference | 7.19.4 | 0..1 | | reference | 7.19.4 | 0..1 |
| revision | 7.1.9 | 0..n | | revision | 7.1.9 | 0..n |
| rpc | 7.13 | 0..n | | rpc | 7.13 | 0..n |
| typedef | 7.3 | 0..n | | typedef | 7.3 | 0..n |
| uses | 7.12 | 0..n | | uses | 7.12 | 0..n |
| yang-version | 7.1.2 | 0..1 | | yang-version | 7.1.2 | 0..1 |
+--------------+---------+-------------+ +--------------+---------+-------------+
7.1.2. The yang-version Statement 7.1.2. The yang-version Statement
The "yang-version" statement specifies which version of the YANG The optional "yang-version" statement specifies which version of the
language was used in developing the module. The statement's argument YANG language was used in developing the module. The statement's
contains value "1", which is the current yang version and the default argument is a string. If present, it MUST contain the value "1",
value. which is the current yang version and the default value.
7.1.3. The namespace Statement 7.1.3. The namespace Statement
The "namespace" statement defines the XML namespace for all XML The "namespace" statement defines the XML namespace to which all
elements defined by the module. Its argument is the URI of the identifiers defined by the module belong, with the exception of data
namespace. node identifiers defined inside a grouping (see Section 7.12 for
details). Its argument is the URI of the namespace.
See also Section 5.3. See also Section 5.3.
7.1.4. The prefix Statement 7.1.4. The prefix Statement
The "prefix" statement is used to define the prefix associated with The "prefix" statement is used to define the prefix associated with
the module and its namespace. The "prefix" statement's argument is the module and its namespace. The "prefix" statement's argument is
the prefix string which is used as a prefix to access a module. The 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 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 module, e.g., "if:ifName". A prefix follows the same rules as an
identifier (see Section 6.2). identifier (see Section 6.2).
When used inside the "module" statement, the "prefix" statement When used inside the "module" statement, the "prefix" statement
defines the prefix to be used when this module is imported. To defines the prefix to be used when this module is imported. To
improve readability of the NETCONF XML, a NETCONF client or server improve readability of the NETCONF XML, a NETCONF client or server
which generates XML or XPath that use prefixes, the prefix defined by which generates XML or XPath that use prefixes, the prefix defined by
a module SHOULD be used, unless there is a conflict. a module SHOULD be used, unless there is a conflict.
When used inside the "import" statement, the "prefix" statement When used inside the "import" statement, the "prefix" statement
defines the prefix to be used when accessing definitions inside the defines the prefix to be used when accessing definitions inside the
imported module. When a reference to an identifier from the imported imported module. When a reference to an identifier from the imported
module is used, the prefix string for the module from which objects module is used, the prefix string for the imported module is used in
are being imported is used in combination with a colon (":") and the combination with a colon (":") and the identifier, e.g., "if:
identifier, e.g. "if:ifIndex". To improve readability of YANG ifIndex". To improve readability of YANG modules, the prefix defined
modules, the prefix defined by a module SHOULD be used when the by a module SHOULD be used when the module is imported, unless there
module is imported, unless there is a conflict. is a conflict.
All prefixes, including the prefix for the module itself MUST be All prefixes, including the prefix for the module itself MUST be
unique within the module or submodule. unique within the module or submodule.
7.1.5. The import Statement 7.1.5. The import Statement
The "import" statement makes definitions from one module available The "import" statement makes definitions from one module available
inside another module or submodule. The argument is the name of the inside another module or submodule. The argument is the name of the
module to import, and the statement is followed by a block of module to import, and the statement is followed by a block of
substatements that holds detailed import information. substatements that holds detailed import information. When a module
is imported, the importing module may:
o use any grouping and typedef defined at the top-level in the
imported module or its submodules
o use any extension, feature, and identity defined in the imported
module or its submodules
o use any node in the imported module's schema tree in augment,
must, path, and when statements
The mandatory "prefix" substatement assigns a prefix for the imported The mandatory "prefix" substatement assigns a prefix for the imported
module which is scoped to the importing module or submodule. module which is scoped to the importing module or submodule.
Multiple "import" statements may be specified to import from Multiple "import" statements may be specified to import from
different modules. different 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. of the imported module. Otherwise, it is undefined from which
revision of the module they are taken.
It is an error to import multiple revisions of the same module. Multiple revisions of the same module MUST NOT be imported.
The import's Substatements The import's Substatements
+---------------+---------+-------------+ +---------------+---------+-------------+
| 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 |
+---------------+---------+-------------+ +---------------+---------+-------------+
7.1.5.1. The import's revision-date Statement 7.1.5.1. The import's revision-date Statement
The import's "revision-date" statement is used to specify the exact The import's "revision-date" statement is used to specify the exact
version of the module to import. The "revision-date" statement MUST version of the module to import. The "revision-date" statement MUST
match the most recent "revision" statement in the imported module. match the most recent "revision" statement in the imported module.
7.1.6. The include Statement 7.1.6. The include Statement
The "include" statement is used to make content from a submodule The "include" statement is used to make content from a submodule
available to the module. The argument is an identifier which is the available to that submodule's parent module, or to another submodule
of that parent module. The argument is an identifier which is the
name of the submodule to include. Modules are only allowed to name of the submodule to include. Modules are only allowed to
include submodules that belong to that module, as defined by the include submodules that belong to that module, as defined by the
"belongs-to" statement (see Section 7.2.2). "belongs-to" statement (see Section 7.2.2). Submodules are only
allowed to include other submodules belonging to the same module.
When a module includes a submodule, it incorporates the contents of When a module includes a submodule, it incorporates the contents of
the submodule into the node hierarchy of the module. When a the submodule into the node hierarchy of the module. When a
submodule includes another submodule, the target submodule's submodule includes another submodule, the target submodule's
definitions are made available to the current submodule. definitions are made available to the current submodule.
When the optional "revision-date" is present, the specified revision When the optional "revision-date" is present, the specified revision
of the submodule is included in the module. of the submodule is included in the module. Otherwise, it is
undefined which revision of the submodule is included.
It is an error to include multiple revisions of the same submodule. Multiple revisions of the same submodule MUST NOT be included.
The includes's Substatements The includes's Substatements
+---------------+---------+-------------+ +---------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+---------------+---------+-------------+ +---------------+---------+-------------+
| revision-date | 7.1.5.1 | 0..1 | | revision-date | 7.1.5.1 | 0..1 |
+---------------+---------+-------------+ +---------------+---------+-------------+
7.1.7. The organization Statement 7.1.7. The organization Statement
skipping to change at page 46, line 20 skipping to change at page 45, line 35
to whom technical queries concerning this module should be sent. to whom technical queries concerning this module should be sent.
7.1.9. The revision Statement 7.1.9. The revision Statement
The "revision" statement specifies the editorial revision history of The "revision" statement specifies the editorial revision history of
the module, including the initial revision. A series of revisions the module, including the initial revision. A series of revisions
statements detail the changes in the module's definition. The statements detail the changes in the module's definition. The
argument is a date string in the format "YYYY-MM-DD", followed by a argument is a date string in the format "YYYY-MM-DD", followed by a
block of substatements that holds detailed revision information. A block of substatements that holds detailed revision information. A
module SHOULD have at least one initial "revision" statement. For module SHOULD have at least one initial "revision" statement. For
every editorial change, a new one SHOULD be added in front of the every published editorial change, a new one SHOULD be added in front
revisions sequence, so that all revisions are in reverse of the revisions sequence, so that all revisions are in reverse
chronological order. chronological order.
7.1.9.1. The revision's Substatement 7.1.9.1. The revision's Substatement
+--------------+---------+-------------+ +--------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+---------+-------------+ +--------------+---------+-------------+
| description | 7.19.3 | 0..1 | | description | 7.19.3 | 0..1 |
+--------------+---------+-------------+ +--------------+---------+-------------+
skipping to change at page 47, line 26 skipping to change at page 46, line 26
organization "ACME Inc."; organization "ACME Inc.";
contact contact
"Joe L. User "Joe L. User
ACME, Inc. ACME, Inc.
42 Anywhere Drive 42 Anywhere Drive
Nowhere, CA 95134 Nowhere, CA 95134
USA USA
Phone: +1 800 555 0815 Phone: +1 800 555 0100
EMail: joe@acme.example.com"; EMail: joe@acme.example.com";
description description
"The module for entities implementing the ACME protocol."; "The module for entities implementing the ACME protocol.";
revision "2007-06-09" { revision "2007-06-09" {
description "Initial revision."; description "Initial revision.";
} }
// definitions follows... // definitions follows...
} }
7.2. The submodule Statement 7.2. The submodule Statement
While the primary unit in YANG is a module, a YANG module can itself While the primary unit in YANG is a module, a YANG module can itself
be constructed out of several submodules. Submodules allows a module be constructed out of several submodules. Submodules allow a module
designer to split a complex model into several pieces where all the designer to split a complex model into several pieces where all the
submodules contribute to a single namespace, which is defined by the submodules contribute to a single namespace, which is defined by the
module that includes the submodules. module that includes the submodules.
The "submodule" statement is used to give the submodule a name, and The "submodule" statement defines the submodule's name, and groups
to group all statements which belong to the submodule together. all statements which belong to the submodule together. The
"submodule" statement's argument is the name of the submodule,
The "submodule" statement, which MUST be present at most once, takes
as an argument an identifier which is the name of the submodule,
followed by a block of substatements that hold detailed submodule followed by a block of substatements that hold detailed submodule
information. information. The submodule name follows the rules for identifiers in
Section 6.2.
Names of submodules published in RFC streams MUST be assigned by Names of submodules published in RFC streams MUST be assigned by
IANA, see Section 14. IANA, see Section 14.
Private submodule names are assigned by the organization owning the Private submodule names are assigned by the organization owning the
submodule without a central registry. It is RECOMMENDED to choose submodule without a central registry. It is RECOMMENDED to choose
submodule names that will have a low probability of colliding with submodule names that will have a low probability of colliding with
standard or other enterprise modules and submodules, e.g. by using standard or other enterprise modules and submodules, e.g., by using
the enterprise or organization name as a prefix. the enterprise or organization name as a prefix.
A submodule SHOULD have the following layout: A submodule SHOULD have the following layout:
submodule <module-name> { submodule <module-name> {
<yang-version statement> <yang-version statement>
// module identification // module identification
<belongs-to statement> <belongs-to statement>
skipping to change at page 49, line 18 skipping to change at page 48, line 18
| augment | 7.15 | 0..n | | augment | 7.15 | 0..n |
| belongs-to | 7.2.2 | 1 | | belongs-to | 7.2.2 | 1 |
| choice | 7.9 | 0..n | | choice | 7.9 | 0..n |
| contact | 7.1.8 | 0..1 | | contact | 7.1.8 | 0..1 |
| container | 7.5 | 0..n | | container | 7.5 | 0..n |
| description | 7.19.3 | 0..1 | | description | 7.19.3 | 0..1 |
| deviation | 7.18.3 | 0..n | | deviation | 7.18.3 | 0..n |
| extension | 7.17 | 0..n | | extension | 7.17 | 0..n |
| feature | 7.18.1 | 0..n | | feature | 7.18.1 | 0..n |
| grouping | 7.11 | 0..n | | grouping | 7.11 | 0..n |
| identity | 7.16 | 0..n |
| import | 7.1.5 | 0..n | | import | 7.1.5 | 0..n |
| include | 7.1.6 | 0..n | | include | 7.1.6 | 0..n |
| leaf | 7.6 | 0..n | | leaf | 7.6 | 0..n |
| leaf-list | 7.7 | 0..n | | leaf-list | 7.7 | 0..n |
| list | 7.8 | 0..n | | list | 7.8 | 0..n |
| notification | 7.14 | 0..n | | notification | 7.14 | 0..n |
| organization | 7.1.7 | 0..1 | | organization | 7.1.7 | 0..1 |
| reference | 7.19.4 | 0..1 | | reference | 7.19.4 | 0..1 |
| revision | 7.1.9 | 0..n | | revision | 7.1.9 | 0..n |
| rpc | 7.13 | 0..n | | rpc | 7.13 | 0..n |
skipping to change at page 50, line 34 skipping to change at page 49, line 34
organization "ACME Inc."; organization "ACME Inc.";
contact contact
"Joe L. User "Joe L. User
ACME, Inc. ACME, Inc.
42 Anywhere Drive 42 Anywhere Drive
Nowhere, CA 95134 Nowhere, CA 95134
USA USA
Phone: +1 800 555 0815 Phone: +1 800 555 0100
EMail: joe@acme.example.com"; EMail: joe@acme.example.com";
description description
"This submodule defines common ACME types."; "This submodule defines common ACME types.";
revision "2007-06-09" { revision "2007-06-09" {
description "Initial revision."; description "Initial revision.";
} }
// definitions follows... // definitions follows...
skipping to change at page 52, line 21 skipping to change at page 51, line 21
} }
7.4. The type Statement 7.4. The type Statement
The "type" statement takes as an argument a string which is the name The "type" statement takes as an argument a string which is the name
of a YANG built-in type (see Section 9) or a derived type (see of a YANG built-in type (see Section 9) or a derived type (see
Section 7.3), followed by an optional block of substatements that are Section 7.3), followed by an optional block of substatements that are
used to put further restrictions on the type. used to put further restrictions on the type.
The restrictions that can be applied depend on the type being The restrictions that can be applied depend on the type being
restricted. The restriction statements are described in subsections restricted. The restriction statements for all built-in types are
for each built-in type in Section 9. described in the subsections of Section 9.
7.4.1. The type's Substatements 7.4.1. The type's Substatements
+--------------+---------+-------------+ +------------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+---------+-------------+ +------------------+---------+-------------+
| bit | 9.7.4 | 0..n | | bit | 9.7.4 | 0..n |
| enum | 9.6.4 | 0..n | | enum | 9.6.4 | 0..n |
| length | 9.4.4 | 0..1 | | length | 9.4.4 | 0..1 |
| path | 9.9.2 | 0..1 | | path | 9.9.2 | 0..1 |
| pattern | 9.4.6 | 0..n | | pattern | 9.4.6 | 0..n |
| range | 9.2.4 | 0..1 | | range | 9.2.4 | 0..1 |
| require-instance | 9.13.2 | 0..1 |
| type | 7.4 | 0..n | | type | 7.4 | 0..n |
+--------------+---------+-------------+ +------------------+---------+-------------+
7.5. The container Statement 7.5. The container Statement
The "container" statement is used to define an interior node in the The "container" statement is used to define an interior node in the
schema tree. It takes one argument, which is an identifier, followed schema tree. It takes one argument, which is an identifier, followed
by a block of substatements that holds detailed container by a block of substatements that holds detailed container
information. information.
A container node does not have a value, but it has a list of child A container node does not have a value, but it has a list of child
nodes in the data tree. The child nodes are defined in the nodes in the data tree. The child nodes are defined in the
skipping to change at page 54, line 45 skipping to change at page 53, line 45
When a data store is validated, all "must" constraints are When a data store is validated, all "must" constraints are
conceptually evaluated once for each corresponding instance in the conceptually evaluated once for each corresponding instance in the
data tree, and for all leafs with default values in effect. If an 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 instance does not exist in the data tree, and it does not have a
default value, its "must" statements are not evaluated. default value, its "must" statements are not evaluated.
All such constraints MUST evaluate to true for the data to be valid. All such constraints MUST evaluate to true for the data to be valid.
The XPath expression is conceptually evaluated in the following The XPath expression is conceptually evaluated in the following
context: context, in addition to the definition in Section 6.4.1:
o The context node is the node in the data tree for which the "must" o The context node is the node in the data tree for which the "must"
statement is defined. statement is defined.
o The accessible tree is made up of all nodes in the data tree, and o The accessible tree is made up of all nodes in the data tree, and
all leafs with default values. all leafs with default values.
o The set of namespace declarations is the set of all "import" The accessible tree depends on the context node:
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 accessible data tree depends on the context node:
o If the context node represents configuration, the tree is the data o If the context node represents configuration, the tree is the data
in one of the datastores <startup/>, <running/>, or <candidate/>. in one of the NETCONF datastores. The XPath root node has all
The XPath root node has all top-level configuration data nodes in top-level configuration data nodes in all modules as children.
all modules as children.
o If the context node represents state data, the tree is all state o If the context node represents state data, the tree is all state
data on the device, and the <running/> datastore. The XPath root data on the device, and the <running/> datastore. The XPath root
node has all top-level data nodes in all modules as children. node has all top-level data nodes in all modules as children.
o If the context node represents notification content, the tree is o If the context node represents notification content, the tree is
the notification XML instance document. The XPath root node has the notification XML instance document. The XPath root node has
the element representing the notification being defined as the the element representing the notification being defined as the
only child. only child.
skipping to change at page 57, line 21 skipping to change at page 56, line 21
If a container has the "presence" statement, the container's If a container has the "presence" statement, the container's
existence in the data tree carries some meaning. Otherwise, the existence in the data tree carries some meaning. Otherwise, the
container is used to give some structure to the data, and it carries container is used to give some structure to the data, and it carries
no meaning by itself. no meaning by itself.
See Section 7.5.1 for additional information. See Section 7.5.1 for additional information.
7.5.6. The container's Child Node Statements 7.5.6. The container's Child Node Statements
Within a container, the "container", "leaf", "list", "leaf-list", Within a container, the "container", "leaf", "list", "leaf-list",
"uses", and "choice" statements can be used to define child nodes to "uses", "choice", and "anyxml" statements can be used to define child
the container. nodes to the container.
7.5.7. XML Encoding Rules 7.5.7. XML Mapping Rules
A container node is encoded as an XML element. The element's name is A container node is encoded as an XML element. The element's name is
the container's identifier, and its XML namespace is the module's XML the container's identifier, and its XML namespace is the module's XML
namespace. namespace.
The container's child nodes are encoded as subelements to the The container's child nodes are encoded as subelements to the
container element. If the container defines RPC input or output container element. If the container defines RPC input or output
parameters, the subelements are encoded in the same order as they are parameters, the subelements are encoded in the same order as they are
defined within the container statement. Otherwise, the subelements defined within the container statement. Otherwise, the subelements
are encoded in any order. are encoded in any order.
A NETCONF server that replies to a <get> or <get-config> request MAY A NETCONF server that replies to a <get> or <get-config> request MAY
choose not to send a container element if the container node does not choose not to send a container element if the container node does not
have the "presence" statement and no child nodes exist. Thus, a have the "presence" statement and no child nodes exist. Thus, a
client that receives an <rpc-reply> for a <get> or <get-config> client that receives an <rpc-reply> for a <get> or <get-config>
request, must be prepared to handle the case that a container node request, must be prepared to handle the case that a container node
without a presence statement is not present in the XML. without a presence statement is not present in the XML.
7.5.8. NETCONF <edit-config> Operations 7.5.8. NETCONF <edit-config> Operations
When a NETCONF server processes an <edit-config> request, the Containers can be created, deleted, replaced and modified through
elements of procedure for the container node are: <edit-config>, by using the "operation" attribute (See [RFC4741],
section 7.2) in the container's XML element.
If the operation is "merge" the node 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 is created if it does not
exist.
If the operation is "delete" the node 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 If a container does not have a "presence" statement and the last
is deleted, the NETCONF server MAY delete the container. child node is deleted, the NETCONF server MAY delete the container.
7.5.9. Usage Example 7.5.9. Usage Example
Given the following container definition: Given the following container definition:
container system { container system {
description "Contains various system parameters"; description "Contains various system parameters";
container services { container services {
description "Configure externally available services"; description "Configure externally available services";
container "ssh" { container "ssh" {
presence "Enables SSH"; presence "Enables SSH";
description "SSH service specific configuration"; description "SSH service specific configuration";
// more leafs, containers and stuff here... // more leafs, containers and stuff here...
} }
} }
} }
A corresponding XML encoding would look like this: A corresponding XML instance example:
<system> <system>
<services> <services>
<ssh/> <ssh/>
</services> </services>
</system> </system>
Since the <ssh> element is present, ssh is enabled. Since the <ssh> element is present, ssh is enabled.
To delete a container with an <edit-config>: To delete a container with an <edit-config>:
skipping to change at page 61, line 5 skipping to change at page 60, line 5
7.6.4. The leaf's mandatory Statement 7.6.4. The leaf's mandatory Statement
The "mandatory" statement, which is optional, takes as an argument The "mandatory" statement, which is optional, takes as an argument
the string "true" or "false", and puts a constraint on valid data. the string "true" or "false", and puts a constraint on valid data.
If not specified, the default is "false". If not specified, the default is "false".
If "mandatory" is "true", the behavior of the constraint depends on If "mandatory" is "true", the behavior of the constraint depends on
the type of the leaf's closest ancestor node in the schema tree which the type of the leaf's closest ancestor node in the schema tree which
is not a non-presence container (see Section 7.5.1): is not a non-presence container (see Section 7.5.1):
o If this ancestor is a case node, the leaf MUST exist if any other o If no such ancestor exists, the leaf MUST exist.
node from the case exists.
o Otherwise, if this ancestor is a case node, the leaf MUST exist if
any node from the case exists.
o Otherwise, the leaf MUST exist if the ancestor node exists. o Otherwise, the leaf MUST exist if the ancestor node exists.
This constraint is enforced according to the rules in Section 8. This constraint is enforced according to the rules in Section 8.
7.6.5. XML Encoding Rules 7.6.5. XML Mapping Rules
A leaf node is encoded as an XML element. The element's name is the 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 leaf's identifier, and its XML namespace is the module's XML
namespace. namespace.
The value of the leaf node is encoded to XML according to the type, The value of the leaf node is encoded to XML according to the type,
and sent as character data in the element. and sent as character data in the element.
A NETCONF server that replies to a <get> or <get-config> request MAY A NETCONF server that replies to a <get> or <get-config> request MAY
choose not to send the leaf element if its value is the default choose not to send the leaf element if its value is the default
skipping to change at page 61, line 50 skipping to change at page 61, line 7
exist, and its value is set to the value found in the XML RPC exist, and its value is set to the value found in the XML RPC
data. data.
If the operation is "create" the node is created if it does not If the operation is "create" the node is created if it does not
exist. exist.
If the operation is "delete" the node is deleted if it exists. If the operation is "delete" the node is deleted if it exists.
7.6.7. Usage Example 7.6.7. Usage Example
Given the following leaf statement: Given the following leaf statement, placed in the previously defined
"ssh" container (See Section 7.5.9):
leaf port { leaf port {
type inet:port-number; type inet:port-number;
default 22; default 22;
description "The port which the SSH server listens to" description "The port which the SSH server listens to"
} }
A corresponding XML encoding: A corresponding XML instance example:
<port>2022</port> <port>2022</port>
To create a leaf with an <edit-config>: To create a leaf with an <edit-config>:
<rpc message-id="101" <rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" 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">
<edit-config> <edit-config>
<target> <target>
skipping to change at page 63, line 7 skipping to change at page 62, line 10
The values in a leaf-list MUST be unique. The values in a leaf-list MUST be unique.
Conceptually, the values in the data tree are always in the canonical Conceptually, the values in the data tree are always in the canonical
form (see Section 9.1). form (see Section 9.1).
If the type referenced by the leaf-list has a default value, it has If the type referenced by the leaf-list has a default value, it has
no effect in the leaf-list. no effect in the leaf-list.
7.7.1. Ordering 7.7.1. Ordering
YANG supports two styles for ordering the entries within a list. In YANG supports two styles for ordering the entries within lists and
many lists, the order of list entries does not impact the leaf-lists. In many lists, the order of list entries does not impact
implementation of the list's configuration, and the device is free to the implementation of the list's configuration, and the device is
sort the list entries in any reasonable order. The "description" free to sort the list entries in any reasonable order. The
string for the list may suggest an order. YANG calls this style of "description" string for the list may suggest an order. YANG calls
list "system ordered" and they are indicated with the statement this style of list "system ordered" and they are indicated with the
"ordered-by system". statement "ordered-by system".
For example, a list of valid users would typically be sorted For example, a list of valid users would typically be sorted
alphabetically, since the order in which the users appeared in the alphabetically, since the order in which the users appeared in the
configuration would not impact the creation of those users' accounts. configuration would not impact the creation of those users' accounts.
In the other style of lists, the order of list entries matters for In the other style of lists, the order of list entries matters for
the implementation of the list's configuration and the user is the implementation of the list's configuration and the user is
responsible for ordering the entries, while the device maintains that responsible for ordering the entries, while the device maintains that
order. YANG calls this style of list "user ordered" and they are order. YANG calls this style of list "user ordered" and they are
indicated with the statement "ordered-by user". indicated with the statement "ordered-by user".
skipping to change at page 64, line 28 skipping to change at page 63, line 28
| status | 7.19.2 | 0..1 | | status | 7.19.2 | 0..1 |
| type | 7.4 | 1 | | type | 7.4 | 1 |
| units | 7.3.3 | 0..1 | | units | 7.3.3 | 0..1 |
| when | 7.19.5 | 0..1 | | when | 7.19.5 | 0..1 |
+--------------+---------+-------------+ +--------------+---------+-------------+
7.7.3. The min-elements Statement 7.7.3. The min-elements Statement
The "min-elements" statement, which is optional, takes as an argument The "min-elements" statement, which is optional, takes as an argument
a non-negative integer which puts a constraint on valid list entries. a non-negative integer which puts a constraint on valid list entries.
A valid leaf-list or list MUST have least min-elements entries. A valid leaf-list or list MUST have at least min-elements entries.
If no "min-elements" statement is present, it defaults to zero. If no "min-elements" statement is present, it defaults to zero.
The behavior of the constraint depends on the type of the leaf-list's The behavior of the constraint depends on the type of the leaf-list's
or list's closest ancestor node in the schema tree which is not a or list's closest ancestor node in the schema tree which is not a
non-presence container (see Section 7.5.1): non-presence container (see Section 7.5.1):
o If this ancestor is a case node, the constraint is enforced if any o If this ancestor is a case node, the constraint is enforced if any
other node from the case exists. other node from the case exists.
skipping to change at page 65, line 26 skipping to change at page 64, line 26
output parameters, or notification content. output parameters, or notification content.
See Section 7.7.1 for additional information. See Section 7.7.1 for additional information.
7.7.5.1. ordered-by system 7.7.5.1. ordered-by system
The entries in the list are sorted according to an unspecified order. The entries in the list are sorted according to an unspecified order.
Thus an implementation is free to sort the entries in the most Thus an implementation is free to sort the entries in the most
appropriate order. An implementation SHOULD use the same order for appropriate order. An implementation SHOULD use the same order for
the same data, regardless of how the data were created. Using a the same data, regardless of how the data were created. Using a
deterministic order will makes comparisons possible using simple deterministic order will make comparisons possible using simple tools
tools like "diff". like "diff".
This is the default order. This is the default order.
7.7.5.2. ordered-by user 7.7.5.2. ordered-by user
The entries in the list are sorted according to an order defined by The entries in the list are sorted according to an order defined by
the user. This order is controlled by using special XML attributes the user. This order is controlled by using special XML attributes
in the <edit-config> request. See Section 7.7.7 for details. in the <edit-config> request. See Section 7.7.7 for details.
7.7.6. XML Encoding Rules 7.7.6. XML Mapping Rules
A leaf-list node is encoded as a series of XML elements. Each A leaf-list node is encoded as a series of XML elements. Each
element's name is the leaf-list's identifier, and its XML namespace element's name is the leaf-list's identifier, and its XML namespace
is the module's XML namespace. is the module's XML namespace.
The value of the leaf-list node is encoded to XML according to the The value of the leaf-list node is encoded to XML according to the
type, and sent as character data in the element. type, and sent as character data in the element.
See Section 7.7.8 for an example. See Section 7.7.8 for an example.
skipping to change at page 66, line 20 skipping to change at page 65, line 20
entry or move an existing one. entry or move an existing one.
The "insert" attribute can take the values "first", "last", "before", The "insert" attribute can take the values "first", "last", "before",
and "after". If the value is "before" or "after", the "value" and "after". If the value is "before" or "after", the "value"
attribute MUST also be used to specify an existing entry in the leaf- attribute MUST also be used to specify an existing entry in the leaf-
list. list.
If no "insert" attribute is present in the "create" operation, it If no "insert" attribute is present in the "create" operation, it
defaults to "last". defaults to "last".
If several entries in an "ordered-by user" leaf-list are modified in
the same <edit-config> request, the entires are modified one at the
time, in the order of the XML elements in the request.
In a <copy-config>, or an <edit-config> with a "replace" operation In a <copy-config>, or an <edit-config> with a "replace" operation
which covers the entire leaf-list, the leaf-list order is the same as which covers the entire leaf-list, the leaf-list order is the same as
the order of the XML elements in the request. the order of the XML elements in the request.
When a NETCONF server processes an <edit-config> request, the When a NETCONF server processes an <edit-config> request, the
elements of procedure for a leaf-list node are: elements of procedure for a leaf-list node are:
If the operation is "merge" or "replace" the leaf-list entry is If the operation is "merge" or "replace" the leaf-list entry is
created if it does not exist. created if it does not exist.
skipping to change at page 66, line 43 skipping to change at page 65, line 47
If the operation is "delete" the entry is deleted from the leaf- If the operation is "delete" the entry is deleted from the leaf-
list if it exists. list if it exists.
7.7.8. Usage Example 7.7.8. Usage Example
leaf-list allow-user { leaf-list allow-user {
type string; type string;
description "A list of user name patterns to allow"; description "A list of user name patterns to allow";
} }
A corresponding XML encoding: A corresponding XML instance example:
<allow-user>alice</allow-user> <allow-user>alice</allow-user>
<allow-user>bob</allow-user> <allow-user>bob</allow-user>
To create a new element in the list: To create a new element in the list:
<rpc message-id="101" <rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" 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">
<edit-config> <edit-config>
skipping to change at page 68, line 35 skipping to change at page 67, line 35
</rpc> </rpc>
7.8. The list Statement 7.8. The list Statement
The "list" statement is used to define interior nodes in the schema The "list" statement is used to define interior nodes in the schema
tree. A list node may exist in multiple instances in the data tree. tree. A list node may exist in multiple instances in the data tree.
Each such instance is known as a list entry. The "list" statement Each such instance is known as a list entry. The "list" statement
takes one argument which is an identifier, followed by a block of takes one argument which is an identifier, followed by a block of
substatements that holds detailed list information. substatements that holds detailed list information.
A list entry is uniquely identified by the values of the list's keys. A list entry is uniquely identified by the values of the list's keys,
if defined.
A list is similar to a table where each list entry is a row in the A list is similar to a table where each list entry is a row in the
table. table.
7.8.1. The list's Substatements 7.8.1. The list's Substatements
+--------------+---------+-------------+ +--------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+---------+-------------+ +--------------+---------+-------------+
| anyxml | 7.10 | 0..n | | anyxml | 7.10 | 0..n |
skipping to change at page 69, line 40 skipping to change at page 68, line 40
| when | 7.19.5 | 0..1 | | when | 7.19.5 | 0..1 |
+--------------+---------+-------------+ +--------------+---------+-------------+
7.8.2. The list's key Statement 7.8.2. The list's key Statement
The "key" statement, which MUST be present if the list represents The "key" statement, which MUST be present if the list represents
configuration, and MAY be present otherwise, takes as an argument a configuration, and MAY be present otherwise, takes as an argument a
string which specifies a space separated list of leaf identifiers of string which specifies a space separated list of leaf identifiers of
this list. A leaf identifier MUST NOT appear more than once in the 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 key. Each such leaf identifier MUST refer to a child leaf of the
list. list. The leafs can be defined directly in substatements to the
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, except it MUST NOT be the built-in type "empty".
skipping to change at page 71, line 40 skipping to change at page 70, line 40
</server> </server>
<server> <server>
<name>ftp</name> <name>ftp</name>
<ip>192.0.2.1</ip> <ip>192.0.2.1</ip>
</server> </server>
7.8.4. The list's Child Node Statements 7.8.4. The list's Child Node Statements
Within a list, the "container", "leaf", "list", "leaf-list", "uses", Within a list, the "container", "leaf", "list", "leaf-list", "uses",
and "choice" statements can be used to define child nodes to the "choice", and "anyxml" statements can be used to define child nodes
list. to the list.
7.8.5. XML Encoding Rules 7.8.5. XML Mapping Rules
A list is encoded as a series of XML elements, one for each entry in A list is encoded as a series of XML elements, one for each entry in
the list. Each element's name is the list's identifier, and its XML the list. Each element's name is the list's identifier, and its XML
namespace is the module's XML namespace. namespace is the module's XML namespace.
The list's key nodes are encoded as subelements to the list's The list's key nodes are encoded as subelements to the list's
identifier element, in the same order as they are defined within the identifier element, in the same order as they are defined within the
key statement. key statement.
The rest of the list's child nodes are encoded as subelements to the The rest of the list's child nodes are encoded as subelements to the
skipping to change at page 72, line 34 skipping to change at page 71, line 34
The "insert" attribute can take the values "first", "last", "before", The "insert" attribute can take the values "first", "last", "before",
and "after". If the value is "before" or "after", the "key" and "after". If the value is "before" or "after", the "key"
attribute MUST also be used, to specify an existing element in the attribute MUST also be used, to specify an existing element in the
list. The value of the "key" attribute is the key predicates of the list. The value of the "key" attribute is the key predicates of the
full instance identifier (see Section 9.13) for the list entry. full instance identifier (see Section 9.13) for the list entry.
If no "insert" attribute is present in the "create" operation, it If no "insert" attribute is present in the "create" operation, it
defaults to "last". defaults to "last".
If several entries in an "ordered-by user" list are modified in the
same <edit-config> request, the entires are modified one at the time,
in the order of the XML elements in the request.
In a <copy-config>, or an <edit-config> with a "replace" operation In a <copy-config>, or an <edit-config> with a "replace" operation
which covers the entire list, the list entry order is the same as the which covers the entire list, the list entry order is the same as the
order of the XML elements in the request. order of the XML elements in the request.
7.8.7. Usage Example 7.8.7. Usage Example
Given the following list: Given the following list:
list user { list user {
key "name"; key "name";
skipping to change at page 73, line 21 skipping to change at page 72, line 21
type string; type string;
} }
leaf type { leaf type {
type string; type string;
} }
leaf full-name { leaf full-name {
type string; type string;
} }
} }
A corresponding XML encoding: A corresponding XML instance example:
<user> <user>
<name>fred</name> <name>fred</name>
<type>admin</type> <type>admin</type>
<full-name>Fred Flintstone</full-name> <full-name>Fred Flintstone</full-name>
</name> </name>
To create a new user "barney": To create a new user "barney":
<rpc message-id="101" <rpc message-id="101"
skipping to change at page 80, line 5 skipping to change at page 79, line 5
container (see Section 7.5.1): container (see Section 7.5.1):
o If this ancestor is a case node, the constraint is enforced if any o If this ancestor is a case node, the constraint is enforced if any
other node from the case exists. other node from the case exists.
o Otherwise, it is enforced if the ancestor node exists. o Otherwise, it is enforced if the ancestor node exists.
The constraint is further enforced according to the rules in The constraint is further enforced according to the rules in
Section 8. Section 8.
7.9.5. XML Encoding Rules 7.9.5. XML Mapping Rules
The choice and case nodes are not visible in XML. The choice and case nodes are not visible in XML.
7.9.6. NETCONF <edit-config> operations 7.9.6. NETCONF <edit-config> operations
Since only one of the choices cases can be valid at any time, the Since only one of the choice's cases can be valid at any time, the
creation of a node from one case implicitly deletes all nodes from creation of a node from one case implicitly deletes all nodes from
all other cases. If an <edit-config> operation creates a node, the all other cases. If an <edit-config> operation creates a node, the
NETCONF server will delete any existing nodes that are defined in NETCONF server will delete any existing nodes that are defined in
other cases inside the choice. other cases inside the choice.
7.9.7. Usage Example 7.9.7. Usage Example
Given the following choice: Given the following choice:
container protocol { container protocol {
skipping to change at page 80, line 36 skipping to change at page 79, line 36
} }
} }
case b { case b {
leaf tcp { leaf tcp {
type empty; type empty;
} }
} }
} }
} }
A corresponding XML encoding: A corresponding XML instance example:
<protocol> <protocol>
<tcp/> <tcp/>
</protocol> </protocol>
To change the protocol from tcp to udp: To change the protocol from tcp to udp:
<rpc message-id="101" <rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" 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">
skipping to change at page 81, line 29 skipping to change at page 80, line 29
</edit-config> </edit-config>
</rpc> </rpc>
7.10. The anyxml Statement 7.10. The anyxml Statement
The "anyxml" statement defines an interior node in the schema tree. The "anyxml" statement defines an interior node in the schema tree.
It takes one argument, which is an identifier, followed by a block of It takes one argument, which is an identifier, followed by a block of
substatements that holds detailed anyxml information. substatements that holds detailed anyxml information.
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 in e.g. No restrictions are placed on the XML. This can be useful in for
RPC replies. An example is the <filter> parameter in the example RPC replies. An example is the <filter> parameter in the
<get-config> operation. <get-config> operation.
An anyxml node cannot be augmented. An anyxml node cannot be augmented.
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 represent
configuration data. configuration data.
An anyxml node exists in zero or one instances in the data tree.
7.10.1. The anyxml's Substatements 7.10.1. The anyxml's Substatements
+--------------+---------+-------------+ +--------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+---------+-------------+ +--------------+---------+-------------+
| config | 7.19.1 | 0..1 | | config | 7.19.1 | 0..1 |
| description | 7.19.3 | 0..1 | | description | 7.19.3 | 0..1 |
| if-feature | 7.18.2 | 0..n | | if-feature | 7.18.2 | 0..n |
| mandatory | 7.6.4 | 0..1 | | mandatory | 7.6.4 | 0..1 |
| must | 7.5.3 | 0..n | | must | 7.5.3 | 0..n |
| reference | 7.19.4 | 0..1 | | reference | 7.19.4 | 0..1 |
| status | 7.19.2 | 0..1 | | status | 7.19.2 | 0..1 |
| when | 7.19.5 | 0..1 | | when | 7.19.5 | 0..1 |
+--------------+---------+-------------+ +--------------+---------+-------------+
7.10.2. XML Encoding Rules 7.10.2. XML Mapping Rules
An anyxml node is encoded as an XML element. The element's name is An anyxml node is encoded as an XML element. The element's name is
the anyxml's identifier, and its XML namespace is the module's XML the anyxml's identifier, and its XML namespace is the module's XML
namespace. The value of the anyxml node is encoded as XML content of namespace. The value of the anyxml node is encoded as XML content of
this element. this element.
Note that any prefixes used in the encoding are local to each Note that any prefixes used in the encoding are local to each
instance encoding. This means that the same XML may be encoded instance encoding. This means that the same XML may be encoded
differently by different implementations. differently by different implementations.
7.10.3. NETCONF <edit-config> operations 7.10.3. NETCONF <edit-config> operations
An anyxml node is treated as an opaque chunk of data. This data can An anyxml node is treated as an opaque chunk of data. This data can
be modified in its entirety only. be modified in its entirety only.
Any "operation" attributes within the XML value of an anyxml node are Any "operation" attributes present on subelements of an anyxml node
ignored by the NETCONF server. are ignored by the NETCONF server.
When a NETCONF server processes an <edit-config> request, the When a NETCONF server processes an <edit-config> request, the
elements of procedure for the anyxml node are: elements of procedure for the anyxml node are:
If the operation is "merge", the node is created if it does not 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 exist, and its value is set to the XML content of the anyxml node
found in the XML RPC data. found in the XML RPC data.
If the operation is "replace", the node is created if it does not 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 exist, and its value is set to the XML content of the anyxml node
skipping to change at page 83, line 50 skipping to change at page 82, line 50
Once a grouping is defined, it can be referenced in a "uses" Once a grouping is defined, it can be referenced in a "uses"
statement (see Section 7.12). A grouping MUST NOT reference itself, statement (see Section 7.12). A grouping MUST NOT reference itself,
neither directly nor indirectly through a chain of other groupings. neither directly nor indirectly through a chain of other groupings.
If the grouping is defined at the top level of a YANG module or If the grouping is defined at the top level of a YANG module or
submodule, the grouping's identifier MUST be unique within the submodule, the grouping's identifier MUST be unique within the
module. module.
A grouping is more than just a mechanism for textual substitution, A grouping is more than just a mechanism for textual substitution,
but defines a collection of nodes. References from inside the but defines a collection of nodes. Identifiers appearing inside the
grouping are relative to the scope in which the grouping is defined, grouping are resolved relative to the scope in which the grouping is
not where it is used. Prefix mappings, type names, grouping names, defined, not where it is used. Prefix mappings, type names, grouping
and extension usage are evaluated in the hierarchy where the grouping names, and extension usage are evaluated in the hierarchy where the
statement appears. For extensions, this means that extensions are grouping statement appears. For extensions, this means that
applied to the grouping node, not the use node. extensions are applied to the grouping node, not the uses node.
7.11.1. The grouping's Substatements 7.11.1. The grouping's Substatements
+--------------+---------+-------------+ +--------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+---------+-------------+ +--------------+---------+-------------+
| anyxml | 7.10 | 0..n | | anyxml | 7.10 | 0..n |
| choice | 7.9 | 0..n | | choice | 7.9 | 0..n |
| container | 7.5 | 0..n | | container | 7.5 | 0..n |
| description | 7.19.3 | 0..1 | | description | 7.19.3 | 0..1 |
skipping to change at page 84, line 50 skipping to change at page 83, line 50
} }
} }
7.12. The uses Statement 7.12. The uses Statement
The "uses" statement is used to reference a "grouping" definition. The "uses" statement is used to reference a "grouping" definition.
It takes one argument, which is the name of the grouping. It takes one argument, which is the name of the grouping.
The effect of a "uses" reference to a grouping is that the nodes The effect of a "uses" reference to a grouping is that the nodes
defined by the grouping are copied into the current schema tree, and defined by the grouping are copied into the current schema tree, and
then updated according to the refinement statements. Thus, the then updated according to the refinement and augment statements.
identifiers defined in the grouping are copied into the current Thus, the identifiers defined in the grouping are copied into the
module's namespace, even if the grouping is imported from some other current module's namespace, even if the grouping is imported from
module. some other module.
7.12.1. The uses's Substatements 7.12.1. The uses's Substatements
+--------------+---------+-------------+ +--------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+---------+-------------+ +--------------+---------+-------------+
| augment | 7.15 | 0..1 | | augment | 7.15 | 0..1 |
| description | 7.19.3 | 0..1 | | description | 7.19.3 | 0..1 |
| if-feature | 7.18.2 | 0..n | | if-feature | 7.18.2 | 0..n |
| refine | 7.12.2 | 0..1 | | refine | 7.12.2 | 0..1 |
skipping to change at page 86, line 8 skipping to change at page 85, line 8
o A leaf or choice node may get a different "mandatory" statement. o A leaf or choice node may get a different "mandatory" statement.
o A container node may get a "presence" statement. o A container node may get a "presence" statement.
o A leaf, leaf-list, list or container node may get additional o A leaf, leaf-list, list or container node may get additional
"must" expressions. "must" expressions.
o A leaf-list or list node may get a different "min-elements" or o A leaf-list or list node may get a different "min-elements" or
"max-elements" statement. "max-elements" statement.
7.12.3. XML Encoding Rules 7.12.3. XML Mapping Rules
Each node in the grouping is encoded as if it was defined inline, Each node in the grouping is encoded as if it was defined inline,
even if it is imported from another module with another XML even if it is imported from another module with another XML
namespace. namespace.
7.12.4. Usage Example 7.12.4. Usage Example
To use the "address" grouping defined in Section 7.11.2 in a To use the "address" grouping defined in Section 7.11.2 in a
definition of an HTTP server in some other module, we can do: definition of an HTTP server in some other module, we can do:
skipping to change at page 86, line 30 skipping to change at page 85, line 30
prefix "acme"; prefix "acme";
} }
container http-server { container http-server {
leaf name { leaf name {
type string; type string;
} }
uses acme:address; uses acme:address;
} }
A corresponding XML encoding: A corresponding XML instance example:
<http-server> <http-server>
<name>extern-web</name> <name>extern-web</name>
<ip>192.0.2.1</ip> <ip>192.0.2.1</ip>
<port>80</port> <port>80</port>
</http-server> </http-server>
If port 80 should be the default for the HTTP server, default can be If port 80 should be the default for the HTTP server, default can be
added: added:
skipping to change at page 88, line 24 skipping to change at page 87, line 24
| output | 7.13.3 | 0..1 | | output | 7.13.3 | 0..1 |
| reference | 7.19.4 | 0..1 | | reference | 7.19.4 | 0..1 |
| status | 7.19.2 | 0..1 | | status | 7.19.2 | 0..1 |
| typedef | 7.3 | 0..n | | typedef | 7.3 | 0..n |
+--------------+---------+-------------+ +--------------+---------+-------------+
7.13.2. The input Statement 7.13.2. The input Statement
The "input" statement, which is optional, is used to define input The "input" statement, which is optional, is used to define input
parameters to the RPC method. It does not take an argument. The parameters to the RPC method. It does not take an argument. The
substatements to "input" defines nodes under the RPC's input node. substatements to "input" define nodes under the RPC's input node.
If a leaf in the input tree has a "mandatory" statement with the If a leaf in the input tree has a "mandatory" statement with the
value "true", the leaf MUST be present in a NETCONF RPC invocation. value "true", the leaf MUST be present in a NETCONF RPC invocation.
If a leaf in the input tree has a default value, the NETCONF server If a leaf in the input tree has a default value, the NETCONF server
MUST internally use this default if the leaf is not present in a MUST internally use this default if the leaf is not present in a
NETCONF RPC invocation. NETCONF RPC invocation.
If a "config" statement is present for any node in the input tree, it If a "config" statement is present for any node in the input tree, it
is ignored. is ignored.
skipping to change at page 89, line 25 skipping to change at page 88, line 25
| leaf-list | 7.7 | 0..n | | leaf-list | 7.7 | 0..n |
| list | 7.8 | 0..n | | list | 7.8 | 0..n |
| typedef | 7.3 | 0..n | | typedef | 7.3 | 0..n |
| uses | 7.12 | 0..n | | uses | 7.12 | 0..n |
+--------------+---------+-------------+ +--------------+---------+-------------+
7.13.3. The output Statement 7.13.3. The output Statement
The "output" statement, which is optional, is used to define output The "output" statement, which is optional, is used to define output
parameters to the RPC method. It does not take an argument. The parameters to the RPC method. It does not take an argument. The
substatements to "output" defines nodes under the RPC's output node. substatements to "output" define nodes under the RPC's output node.
If a leaf in the output tree has a "mandatory" statement with the If a leaf in the output tree has a "mandatory" statement with the
value "true", the leaf MUST be present in a NETCONF RPC reply. value "true", the leaf MUST be present in a NETCONF RPC reply.
If a leaf in the output tree has a default value, the NETCONF client If a leaf in the output tree has a default value, the NETCONF client
MUST internally use this default if the leaf is not present in a MUST internally use this default if the leaf is not present in a
NETCONF RPC reply. NETCONF RPC reply.
If a "config" statement is present for any node in the output tree, If a "config" statement is present for any node in the output tree,
it is ignored. it is ignored.
skipping to change at page 90, line 21 skipping to change at page 89, line 21
| choice | 7.9 | 0..n | | choice | 7.9 | 0..n |
| container | 7.5 | 0..n | | container | 7.5 | 0..n |
| grouping | 7.11 | 0..n | | grouping | 7.11 | 0..n |
| leaf | 7.6 | 0..n | | leaf | 7.6 | 0..n |
| leaf-list | 7.7 | 0..n | | leaf-list | 7.7 | 0..n |
| list | 7.8 | 0..n | | list | 7.8 | 0..n |
| typedef | 7.3 | 0..n | | typedef | 7.3 | 0..n |
| uses | 7.12 | 0..n | | uses | 7.12 | 0..n |
+--------------+---------+-------------+ +--------------+---------+-------------+
7.13.4. XML Encoding Rules 7.13.4. XML Mapping Rules
An rpc node is encoded as a child XML element to the <rpc> element An rpc node is encoded as a child XML element to the <rpc> element
defined in [RFC4741]. The element's name is the rpc's identifier, defined in [RFC4741]. The element's name is the rpc's identifier,
and its XML namespace is the module's XML namespace. and its XML namespace is the module's XML namespace.
Input parameters are encoded as child XML elements to the rpc node's Input parameters are encoded as child XML elements to the rpc node's
XML element, in the same order as they are defined within the input XML element, in the same order as they are defined within the input
statement. statement.
If the RPC method invocation succeeded, and no output parameters are If the RPC method invocation succeeded, and no output parameters are
skipping to change at page 91, line 4 skipping to change at page 90, line 4
prefix "rock"; prefix "rock";
rpc rock-the-house { rpc rock-the-house {
input { input {
leaf zip-code { leaf zip-code {
type string; type string;
} }
} }
} }
} }
A corresponding XML encoding of the complete rpc and rpc-reply: A corresponding XML instance example of the complete rpc and rpc-
reply:
<rpc message-id="101" <rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<rock-the-house xmlns="http://example.net/rock"> <rock-the-house xmlns="http://example.net/rock">
<zip-code>27606-0100</zip-code> <zip-code>27606-0100</zip-code>
</rock-the-house> </rock-the-house>
</rpc> </rpc>
<rpc-reply message-id="101" <rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/> <ok/>
</rpc-reply> </rpc-reply>
7.14. The notification Statement 7.14. The notification Statement
The "notification" statement is used to define a NETCONF The "notification" statement is used to define a NETCONF
notification. It takes one argument, which is an identifier, notification. It takes one argument, which is an identifier,
followed by a block of substatements that holds detailed notification followed by a block of substatements that holds detailed notification
information. The notification "statement" defines a notification information. The "notification" statement defines a notification
node in the schema tree. node in the schema tree.
If a container in the notification tree has a "presence" statement, If a container in the notification tree has a "presence" statement,
the container need not be present in a NETCONF notification. the container need not be present in a NETCONF notification.
If a leaf in the notification tree has a "mandatory" statement with If a leaf in the notification tree has a "mandatory" statement with
the value "true", the leaf MUST be present in a NETCONF notification. the value "true", the leaf MUST be present in a NETCONF notification.
If a leaf in the notification tree has a default value, the NETCONF If a leaf in the notification tree has a default value, the NETCONF
server MUST internally use this default if the leaf is not present in client MUST internally use this default if the leaf is not present in
a NETCONF notification. a NETCONF notification.
If a "config" statement is present for any node in the notification If a "config" statement is present for any node in the notification
tree, it is ignored. tree, it is ignored.
7.14.1. The notification's Substatements 7.14.1. The notification's Substatements
+--------------+---------+-------------+ +--------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+---------+-------------+ +--------------+---------+-------------+
skipping to change at page 92, line 25 skipping to change at page 91, line 25
| if-feature | 7.18.2 | 0..n | | if-feature | 7.18.2 | 0..n |
| leaf | 7.6 | 0..n | | leaf | 7.6 | 0..n |
| leaf-list | 7.7 | 0..n | | leaf-list | 7.7 | 0..n |
| list | 7.8 | 0..n | | list | 7.8 | 0..n |
| reference | 7.19.4 | 0..1 | | reference | 7.19.4 | 0..1 |
| status | 7.19.2 | 0..1 | | status | 7.19.2 | 0..1 |
| typedef | 7.3 | 0..n | | typedef | 7.3 | 0..n |
| uses | 7.12 | 0..n | | uses | 7.12 | 0..n |
+--------------+---------+-------------+ +--------------+---------+-------------+
7.14.2. XML Encoding Rules 7.14.2. XML Mapping Rules
A notification node is encoded as a child XML element to the A notification node is encoded as a child XML element to the
<notification> element defined in NETCONF Event Notifications <notification> element defined in NETCONF Event Notifications
[RFC5277]. The element's name is the notification's identifier, and [RFC5277]. The element's name is the notification's identifier, and
its XML namespace is the module's XML namespace. its XML namespace is 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 7.14.3. Usage Example
The following example defines a notification: The following example defines a notification:
module event { module event {
namespace "http://example.com/event"; namespace "http://example.com/event";
prefix "ev"; prefix "ev";
notification event { notification event {
leaf event-class { leaf event-class {
type string; type string;
} }
anyxml reporting-entity; anyxml reporting-entity;
leaf severity { leaf severity {
type string; type string;
} }
} }
} }
A corresponding XML encoding of the complete notification: A corresponding XML instance example of the complete notification:
<notification <notification
xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
<eventTime>2008-07-08T00:01:00Z</eventTime> <eventTime>2008-07-08T00:01:00Z</eventTime>
<event xmlns="http://example.com/event"> <event xmlns="http://example.com/event">
<event-class>fault</event-class> <event-class>fault</event-class>
<reporting-entity> <reporting-entity>
<card>Ethernet0</card> <card>Ethernet0</card>
</reporting-entity> </reporting-entity>
<severity>major</severity> <severity>major</severity>
skipping to change at page 93, line 46 skipping to change at page 92, line 28
The "augment" statement allows a module or submodule to add to the The "augment" statement allows a module or submodule to add to the
schema tree defined in an external module, or the current module and schema tree defined in an external module, or the current module and
its submodules, and to add to the nodes from a grouping in a "uses" its submodules, and to add to the nodes from a grouping in a "uses"
statement. The argument is a string which identifies a node in the statement. The argument is a string which identifies a node in the
schema tree. This node is called the augment's target node. The schema tree. This node is called the augment's target node. The
target node MUST be either a container, list, choice, case, input, target node MUST be either a container, list, choice, case, input,
output, or notification node. It is augmented with the nodes defined output, or notification node. It is augmented with the nodes defined
in the substatements that follow the "augment" statement. in the substatements that follow the "augment" statement.
The argument string is a schema node identifier. The syntax is The argument string is a schema node identifier. The syntax is a
formally defined by the rule "augment-arg" in Section 12. If the subset of the XPath abbreviated syntax, formally defined by the rule
"augment" statement is on the top-level in a module or submodule, the "augment-arg" in Section 12. If the "augment" statement is on the
absolute form (defined by the rule "absolute-schema-nodeid" in top-level in a module or submodule, the absolute form (defined by the
Section 12) of a schema node identifier MUST be used. If the rule "absolute-schema-nodeid" in Section 12) of a schema node
"augment" statement is in a "uses" statement, the descendant form identifier MUST be used. If the "augment" statement is in a "uses"
(defined by the rule "descendant-schema-nodeid" in Section 12) MUST statement, the descendant form (defined by the rule
be used. "descendant-schema-nodeid" in Section 12) MUST be used.
The syntax for a schema node identifier is a subset of the XPath
syntax. It is an absolute or relative XPath location path in
abbreviated syntax, where axes and predicates are not permitted.
If the target node is a container, list, case, input, output, or If the target node is a container, list, case, input, output, or
notification node, the "container", "leaf", "list", "leaf-list", notification node, the "container", "leaf", "list", "leaf-list",
"uses", and "choice" statements can be used within the "augment" "uses", and "choice" statements can be used within the "augment"
statement. statement.
If the target node is a choice node, the "case" statement can be used If the target node is a choice node, the "case" statement, or a case
within the "augment" statement. shorthand statement (see Section 7.9.2) can be used within the
"augment" statement.
If the target node is in another module, then nodes added by the If the target node is in another module, then nodes added by the
augmentation MUST NOT be mandatory nodes (see Section 3.1). augmentation MUST NOT be mandatory nodes (see Section 3.1).
The augment statement MUST NOT add multiple nodes with the same name The augment statement MUST NOT add multiple nodes with the same name
from the same module to the target node. from the same module to the target node.
The "augment" XPath expression is conceptually evaluated in the
following context, in addition to the definition in Section 6.4.1:
o The context node is the target node in the schema tree.
o The accessible tree is made up of all nodes in the schema tree.
The XPath root node has all top-level schema nodes in all modules
as children.
7.15.1. The augment's Substatements 7.15.1. The augment's Substatements
+--------------+---------+-------------+ +--------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+---------+-------------+ +--------------+---------+-------------+
| anyxml | 7.10 | 0..n | | anyxml | 7.10 | 0..n |
| case | 7.9.2 | 0..n | | case | 7.9.2 | 0..n |
| choice | 7.9 | 0..n | | choice | 7.9 | 0..n |
| container | 7.5 | 0..n | | container | 7.5 | 0..n |
| description | 7.19.3 | 0..1 | | description | 7.19.3 | 0..1 |
| if-feature | 7.18.2 | 0..n | | if-feature | 7.18.2 | 0..n |
| leaf | 7.6 | 0..n | | leaf | 7.6 | 0..n |
| leaf-list | 7.7 | 0..n | | leaf-list | 7.7 | 0..n |
| list | 7.8 | 0..n | | list | 7.8 | 0..n |
| reference | 7.19.4 | 0..1 | | reference | 7.19.4 | 0..1 |
| status | 7.19.2 | 0..1 | | status | 7.19.2 | 0..1 |
| uses | 7.12 | 0..n | | uses | 7.12 | 0..n |
| when | 7.19.5 | 0..1 | | when | 7.19.5 | 0..1 |
+--------------+---------+-------------+ +--------------+---------+-------------+
7.15.2. XML Encoding Rules 7.15.2. XML Mapping Rules
All data nodes defined in the "augment" statement are defined as XML All data nodes defined in the "augment" statement are defined as XML
elements in the XML namespace of the module where the "augment" is elements in the XML namespace of the module where the "augment" is
specified. specified.
When a node is augmented, the augmenting child nodes are encoded as When a node is augmented, the augmenting child nodes are encoded as
subelements to the augmented node, in any order. subelements to the augmented node, in any order.
7.15.3. Usage Example 7.15.3. Usage Example
skipping to change at page 96, line 36 skipping to change at page 94, line 36
import interface-module { import interface-module {
prefix "if"; prefix "if";
} }
augment "/if:interfaces/if:ifEntry" { augment "/if:interfaces/if:ifEntry" {
when "if:ifType='ds0'"; when "if:ifType='ds0'";
leaf ds0ChannelNumber { leaf ds0ChannelNumber {
type ChannelNumber; type ChannelNumber;
} }
} }
A corresponding XML encoding: A corresponding XML instance example:
<interfaces xmlns="http://example.com/schema/interfaces" <interfaces xmlns="http://example.com/schema/interfaces"
xmlns:ds0="http://example.com/schema/ds0" xmlns:ds0="http://example.com/schema/ds0"
<ifEntry> <ifEntry>
<ifIndex>1</ifIndex> <ifIndex>1</ifIndex>
<ifDescr>Flintstone Inc Ethernet A562</ifDescr> <ifDescr>Flintstone Inc Ethernet A562</ifDescr>
<ifType>ethernetCsmacd</ifType> <ifType>ethernetCsmacd</ifType>
<ifMtu>1500</ifMtu> <ifMtu>1500</ifMtu>
</ifEntry> </ifEntry>
<ifEntry> <ifEntry>
skipping to change at page 97, line 16 skipping to change at page 95, line 16
protocol definition: protocol definition:
augment /ex:system/ex:protocol/ex:name { augment /ex:system/ex:protocol/ex:name {
case c { case c {
leaf smtp { leaf smtp {
type empty; type empty;
} }
} }
} }
A corresponding XML encoding: A corresponding XML instance example:
<ex:system> <ex:system>
<ex:protocol> <ex:protocol>
<ex:tcp/> <ex:tcp/>
</ex:protocol> </ex:protocol>
</ex:system> </ex:system>
or or
<ex:system> <ex:system>
skipping to change at page 103, line 5 skipping to change at page 100, line 46
} }
} }
The "if-feature" statement can be used in many places within the YANG The "if-feature" statement can be used in many places within the YANG
syntax. Definitions tagged with "if-feature" are ignored when the syntax. Definitions tagged with "if-feature" are ignored when the
device does not support that feature. device does not support that feature.
A feature MUST NOT reference itself, neither directly nor indirectly A feature MUST NOT reference itself, neither directly nor indirectly
through a chain of other features. through a chain of other features.
If a feature is dependent on any other features (i.e., the feature
has one or more "if-feature" sub-statements), then all of features it
depends on MUST also be implemented by the device.
7.18.1.1. The feature's Substatements 7.18.1.1. The feature's Substatements
+--------------+---------+-------------+ +--------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+---------+-------------+ +--------------+---------+-------------+
| description | 7.19.3 | 0..1 | | description | 7.19.3 | 0..1 |
| if-feature | 7.18.2 | 0..n | | if-feature | 7.18.2 | 0..n |
| status | 7.19.2 | 0..1 | | status | 7.19.2 | 0..1 |
| reference | 7.19.4 | 0..1 | | reference | 7.19.4 | 0..1 |
+--------------+---------+-------------+ +--------------+---------+-------------+
skipping to change at page 104, line 22 skipping to change at page 102, line 22
Instead, YANG allows devices to document portions of the base module Instead, YANG allows devices to document portions of the base module
which are not supported or supported but with different syntax, by which are not supported or supported but with different syntax, by
using the "deviation" statement. using the "deviation" statement.
7.18.3.1. The deviation's Substatements 7.18.3.1. The deviation's Substatements
+--------------+----------+-------------+ +--------------+----------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+----------+-------------+ +--------------+----------+-------------+
| description | 7.19.3 | 0..1 | | description | 7.19.3 | 0..1 |
| deviate | 7.18.3.2 | 0..n | | deviate | 7.18.3.2 | 1..n |
| reference | 7.19.4 | 0..1 | | reference | 7.19.4 | 0..1 |
+--------------+----------+-------------+ +--------------+----------+-------------+
7.18.3.2. The deviate Statement 7.18.3.2. The deviate Statement
The "deviate" statement defines how the device's implementation of The "deviate" statement defines how the device's implementation of
the target node deviates from its original definition. The argument the target node deviates from its original definition. The argument
is one of the strings "not-supported", "add", "replace", or "delete". is one of the strings "not-supported", "add", "replace", or "delete".
The argument "not-supported" indicates that the target node is not The argument "not-supported" indicates that the target node is not
skipping to change at page 106, line 51 skipping to change at page 104, line 51
The "status" statement takes as an argument one of the strings The "status" statement takes as an argument one of the strings
"current", "deprecated", or "obsolete". "current", "deprecated", or "obsolete".
o "current" means that the definition is current and valid. o "current" means that the definition is current and valid.
o "deprecated" indicates an obsolete definition, but it permits new/ o "deprecated" indicates an obsolete definition, but it permits new/
continued implementation in order to foster interoperability with continued implementation in order to foster interoperability with
older/existing implementations. older/existing implementations.
o "obsolete" means the definition is obsolete and SHOULD NOT be o "obsolete" means the definition is obsolete and SHOULD NOT be
implemented and/or can be removed if previously implemented. implemented and/or can be removed from implementations.
If no status is specified, the default is "current". If no status is specified, the default is "current".
If a definition is "current", it MUST NOT reference a "deprecated" or If a definition is "current", it MUST NOT reference a "deprecated" or
"obsolete" definition within the same module. "obsolete" definition within the same module.
If a definition is "deprecated", it MUST NOT reference an "obsolete" If a definition is "deprecated", it MUST NOT reference an "obsolete"
definition within the same module. definition within the same module.
7.19.3. The description Statement 7.19.3. The description Statement
skipping to change at page 107, line 40 skipping to change at page 105, line 40
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, which is used to formally specify this condition. If the expression, which is used to formally specify this condition. If the
XPath expression conceptually evaluates to "true" for a particular XPath expression conceptually evaluates to "true" for a particular
instance, then the node defined by the parent data definition instance, then the node defined by the parent data definition
statement is valid, otherwise it is not. statement is valid, otherwise it is not.
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: 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 which is also a data 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" o If the "when" statement is a child of a "choice" or "case"
statement, then the context node is the closest ancestor node to statement, then the context node is the closest ancestor node to
the "choice" or "case" node which is also a data node. the "choice" or "case" node which is also a data node.
o If the "when" statement is a child of any other data definition o If the "when" statement is a child of any other data definition
statement, the context node is the data definition's node in the statement, the context node is the data definition's node in the
data tree. data tree.
o The accessible tree is made up of all nodes in the data tree, and o The accessible tree is made up of all nodes in the data tree, and
all leafs with default values. all leafs with default values.
o The set of namespace declarations is the set of all "import" The accessible tree depends on the context node:
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 accessible data tree depends on the context node:
o If the context node represents configuration, the tree is the data o If the context node represents configuration, the tree is the data
in one of the datastores <startup/>, <running/>, or <candidate/>. in one of the NETCONF datastores. The XPath root node has all
The XPath root node has all top-level configuration data nodes in top-level configuration data nodes in all modules as children.
all modules as children.
o If the context node represents state data, the tree is all state o If the context node represents state data, the tree is all state
data on the device, and the <running/> datastore. The XPath root data on the device, and the <running/> datastore. The XPath root
node has all top-level data nodes in all modules as children. node has all top-level data nodes in all modules as children.
o If the context node represents notification content, the tree is o If the context node represents notification content, the tree is
the notification XML instance document. The XPath root node has the notification XML instance document. The XPath root node has
the element representing the notification being defined as the the element representing the notification being defined as the
only child. only child.
skipping to change at page 110, line 37 skipping to change at page 107, line 37
8.2. Hierarchy of Constraints 8.2. Hierarchy of Constraints
Conditions on parent nodes affect constraints on child nodes as a Conditions on parent nodes affect constraints on child nodes as a
natural consequence of the hierarchy of nodes. "must", "mandatory", natural consequence of the hierarchy of nodes. "must", "mandatory",
"min-elements", and "max-elements" constraints are not enforced if "min-elements", and "max-elements" constraints are not enforced if
the parent node has a "when" or "if-feature" property that is not the parent node has a "when" or "if-feature" property that is not
satisfied on the current device. satisfied on the current device.
In this example, the mandatory constraints on the "longitude" leaf is In this example, the mandatory constraints on the "longitude" leaf is
not enforced on devices that lack the the "has-gps" feature: not enforced on devices that lack the "has-gps" feature:
container location { container location {
if-feature has-gps; if-feature has-gps;
leaf longitude { leaf longitude {
mandatory true; mandatory true;
... ...
} }
} }
8.3. Constraint Enforcement Model 8.3. Constraint Enforcement Model
skipping to change at page 111, line 23 skipping to change at page 108, line 23
8.3.1. Payload Parsing 8.3.1. Payload Parsing
When content arrives in RPC payloads, it MUST be well-formed XML, When content arrives in RPC payloads, it MUST be well-formed XML,
following the hierarchy and content rules defined by the set of following the hierarchy and content rules defined by the set of
models the device implements. models the device implements.
o If a leaf data value does not match the type constraints for the o If a leaf data value does not match the type constraints for the
leaf, including those defined in the type's range, length, and leaf, including those defined in the type's range, length, and
pattern properties, the server MUST reply with an "invalid-value" pattern properties, the server MUST reply with an "invalid-value"
error-tag in the rpc-error, and with the error-app-tag and error- error-tag in the rpc-error, and with the error-app-tag and error-
message assoicated with the constraint, if any exist. message associated with the constraint, if any exist.
o If all keys of a list entry are not present, the server MUST reply o If all keys of a list entry are not present, the server MUST reply
with a "missing-element" error-tag in the rpc-error. with a "missing-element" error-tag in the rpc-error.
o If data for more than one case branch of a choice is present, the o If data for more than one case branch of a choice is present, the
server MUST reply with a "bad-element" in the rpc-error. server MUST reply with a "bad-element" in the rpc-error.
o If data for a node tagged with "if-feature" is present, and the o If data for a node tagged with "if-feature" is present, and the
feature is not supported by the device, the server MUST reply with feature is not supported by the device, the server MUST reply with
an "unknown-element" error-tag in the rpc-error. an "unknown-element" error-tag in the rpc-error.
skipping to change at page 111, line 46 skipping to change at page 108, line 46
condition evaluates to "false", the server MUST reply with an condition evaluates to "false", the server MUST reply with an
"unknown-element" error-tag in the rpc-error. "unknown-element" error-tag in the rpc-error.
o For insert handling, if the value for the attributes "before" and o For insert handling, if the value for the attributes "before" and
"after" are not valid for the type of the appropriate key leafs, "after" are not valid for the type of the appropriate key leafs,
the server MUST reply with a "bad-attribute" error-tag in the rpc- the server MUST reply with a "bad-attribute" error-tag in the rpc-
error. error.
o If the attributes "before" and "after" appears in any element that o If the attributes "before" and "after" appears in any element that
is not a list whose "ordered-by" property is "user", the server is not a list whose "ordered-by" property is "user", the server
MUST reply with an "unkown-attribute" error-tag in the rpc-error. MUST reply with an "unknown-attribute" error-tag in the rpc-error.
8.3.2. NETCONF <edit-config> Processing 8.3.2. NETCONF <edit-config> Processing
After the incoming data is parsed, the NETCONF server performs the After the incoming data is parsed, the NETCONF server performs the
<edit-config> operation by applying the data to the configuration <edit-config> operation by applying the data to the configuration
datastore. During this processing the following errors MUST be datastore. During this processing the following errors MUST be
detected: detected:
o Delete requests for non-existent data. o Delete requests for non-existent data.
skipping to change at page 112, line 30 skipping to change at page 109, line 30
"when" expression becomes false, then that node is deleted by the "when" expression becomes false, then that node is deleted by the
server. server.
8.3.3. Validation 8.3.3. Validation
When datastore processing is complete, the final contents MUST obey When datastore processing is complete, the final contents MUST obey
all validation constraints. This validation processing is performed all validation constraints. This validation processing is performed
at differing time according to the datastore. If the datastore is at differing time according to the datastore. If the datastore is
<running/> or <startup/>, these constraints MUST be enforced at the <running/> or <startup/>, these constraints MUST be enforced at the
end of the <edit-config> or <copy-config> operation. If the end of the <edit-config> or <copy-config> operation. If the
datastore is <candidate>, the constraint enforcement is delayed until datastore is <candidate/>, the constraint enforcement is delayed
a <commit> or <validate> operation. until a <commit> or <validate> operation.
o Any "must" constraints MUST evaluate to "true". o Any "must" constraints MUST evaluate to "true".
o Any referential integrity constraints defined via the "path" o Any referential integrity constraints defined via the "path"
statement MUST be satisfied. statement MUST be satisfied.
o Any "unique" constraints on lists MUST be satisfied. o Any "unique" constraints on lists MUST be satisfied.
o The "min-elements" and "max-elements" constraints are enforced for o The "min-elements" and "max-elements" constraints are enforced for
lists and leaf-lists. lists and leaf-lists.
skipping to change at page 113, line 21 skipping to change at page 110, line 21
Additional types may be defined, derived from those built-in types or Additional types may be defined, derived from those built-in types or
from other derived types. Derived types may use subtyping to from other derived types. Derived types may use subtyping to
formally restrict the set of possible values. formally restrict the set of possible values.
The different built-in types and their derived types allow different The different built-in types and their derived types allow different
kinds of subtyping, namely length and regular expression restrictions kinds of subtyping, namely length and regular expression restrictions
of strings (Section 9.4.4, Section 9.4.6) and range restrictions of of strings (Section 9.4.4, Section 9.4.6) and range restrictions of
numeric types (Section 9.2.4). numeric types (Section 9.2.4).
The lexicographic representation of a value of a certain type is used The lexicographic representation of a value of a certain type is used
in the XML encoding over NETCONF, and when specifying default values in the NETCONF PDUs, and when specifying default values and numerical
in a YANG module. ranges in YANG modules.
9.1. Canonical representation 9.1. Canonical representation
For most types, there is a single canonical representation of the For most types, there is a single canonical representation of the
type's values. Some types allow multiple lexicographic type's values. Some types allow multiple lexicographic
representations of the same value, for example the positive integer representations of the same value, for example the positive integer
"17" can be represented as "+17" or "17". "17" can be represented as "+17" or "17".
When NETCONF servers sends data, it MUST be in the canonical form. When a NETCONF server sends data, it MUST be in the canonical form.
Some types have a lexical representation that depends on the XML Some types have a lexical representation that depends on the XML
context in which they occur. These types do not have a canonical context in which they occur. These types do not have a canonical
form. form.
9.2. The Integer Built-in Types 9.2. The Integer Built-in Types
The integer built-in types are int8, int16, int32, int64, uint8, The integer built-in types are int8, int16, int32, int64, uint8,
uint16, uint32, and uint64. They represent signed and unsigned uint16, uint32, and uint64. They represent signed and unsigned
integers of different sizes: integers of different sizes:
skipping to change at page 114, line 34 skipping to change at page 111, line 34
For convenience, when specifying a default value for an integer in a For convenience, when specifying a default value for an integer in a
YANG module, an alternative lexicographic representation can be used, YANG module, an alternative lexicographic representation can be used,
which represents the value in a hexadecimal or octal notation. The which represents the value in a hexadecimal or octal notation. The
hexadecimal notation consists of an optional sign ("+" or "-"), the hexadecimal notation consists of an optional sign ("+" or "-"), the
characters "0x" followed a number of hexadecimal digits, where characters "0x" followed a number of hexadecimal digits, where
letters may be upper- or lowercase. The octal notation consists of letters may be upper- or lowercase. The octal notation consists of
an optional sign ("+" or "-"), the character "0" followed a number of an optional sign ("+" or "-"), the character "0" followed a number of
octal digits. octal digits.
Note that if a default value in a YANG module has a leading zero Note that if a default value in a YANG module has a leading zero
("0"), it is interpreted as an octal number. In the XML encoding, an ("0"), it is interpreted as an octal number. In the XML instance
integer is always interpreted as a decimal number, and leading zeros documents, an integer is always interpreted as a decimal number, and
are allowed. leading zeros are allowed.
Examples: Examples:
// legal values // legal values
+4711 // legal positive value +4711 // legal positive value
4711 // legal positive value 4711 // legal positive value
-123 // legal negative value -123 // legal negative value
0xf00f // legal positive hexadecimal value 0xf00f // legal positive hexadecimal value
-0xf // legal negative hexadecimal value -0xf // legal negative hexadecimal value
052 // legal positive octal value 052 // legal positive octal value
skipping to change at page 116, line 28 skipping to change at page 113, line 28
type my-base-int32-type { type my-base-int32-type {
// 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 10^-n" where i is an integer64 and n is an integer between 1 and "i x 10^-n" where i is an integer64 and n is an integer between 1 and
18, inclusively. 18, inclusively.
9.3.1. Lexicographic Representation 9.3.1. Lexicographic Representation
A decimal64 value is lexicographically represented as an optional A decimal64 value is lexicographically represented as an optional
sign ("+" or "-"), followed by a sequence of decimal digits, sign ("+" or "-"), followed by a sequence of decimal digits,
optionally followed by a period ('.') as a decmial indicator and a optionally followed by a period ('.') as a decimal indicator and a
sequence of decimal digits. If no sign is specified, "+" is assumed. sequence of decimal digits. If no sign is specified, "+" is assumed.
9.3.2. Canonical Form 9.3.2. Canonical Form
The canonical form of a positive decimal64 does not include the sign The canonical form of a positive decimal64 does not include the sign
"+". The decimal point is required. Leading and trailing zeros are "+". The decimal point is required. Leading and trailing zeros are
prohibited, subject to the rule that there MUST be at least one digit prohibited, subject to the rule that there MUST be at least one digit
before and after the decimal point. The value zero is represented as before and after the decimal point. The value zero is represented as
"0.0". "0.0".
9.3.3. Restrictions 9.3.3. Restrictions
A decmial64 type can be restricted with the "range" statement A decimal64 type can be restricted with the "range" statement
(Section 9.2.4). (Section 9.2.4).
9.3.4. The fraction-digits Statement 9.3.4. The fraction-digits Statement
The "fraction-digits" statement, which is a substatement to the The "fraction-digits" statement, which is a substatement to the
"type" statement, MUST be present if the type is "decimal64". It "type" statement, MUST be present if the type is "decimal64". It
takes as an argument an integer between 1 and 18, inclusively. It takes as an argument an integer between 1 and 18, inclusively. It
controls the size of the minimum difference between values of a controls the size of the minimum difference between values of a
decimal64 type, by restricting the value space to numbers that are decimal64 type, by restricting the value space to numbers that are
expressible as "i x 10^-n" where n is the fraction-digits argument. expressible as "i x 10^-n" where n is the fraction-digits argument.
The following table lists the minimum and maximum value for each
fraction-digit value:
+----------------+-----------------------+----------------------+
| fraction-digit | min | max |
+----------------+-----------------------+----------------------+
| 1 | -922337203685477580.8 | 922337203685477580.7 |
| 2 | -92233720368547758.08 | 92233720368547758.07 |
| 3 | -9223372036854775.808 | 9223372036854775.807 |
| 4 | -922337203685477.5808 | 922337203685477.5807 |
| 5 | -92233720368547.75808 | 92233720368547.75807 |
| 6 | -9223372036854.775808 | 9223372036854.775807 |
| 7 | -922337203685.4775808 | 922337203685.4775807 |
| 8 | -92233720368.54775808 | 92233720368.54775807 |
| 9 | -9223372036.854775808 | 9223372036.854775807 |
| 10 | -922337203.6854775808 | 922337203.6854775807 |
| 11 | -92233720.36854775808 | 92233720.36854775807 |
| 12 | -9223372.036854775808 | 9223372.036854775807 |
| 13 | -922337.2036854775808 | 922337.2036854775807 |
| 14 | -92233.72036854775808 | 92233.72036854775807 |
| 15 | -9223.372036854775808 | 9223.372036854775807 |
| 16 | -922.3372036854775808 | 922.3372036854775807 |
| 17 | -92.23372036854775808 | 92.23372036854775807 |
| 18 | -9.223372036854775808 | 9.223372036854775807 |
+----------------+-----------------------+----------------------+
9.3.5. Usage Example 9.3.5. Usage Example
type decimal64 { type decimal64 {
fraction-digits 2; fraction-digits 2;
range "1 .. 3.14 | 10 | 20..max"; range "1 .. 3.14 | 10 | 20..max";
} }
9.4. The string Built-in Type 9.4. The string Built-in Type
The string built-in type represents human readable strings in YANG. The string built-in type represents human readable strings in YANG.
skipping to change at page 117, line 36 skipping to change at page 115, line 14
// any Unicode character, excluding the surrogate blocks, // any Unicode character, excluding the surrogate blocks,
// FFFE, and FFFF. // FFFE, and FFFF.
string = *char string = *char
char = %x9 / %xA / %xD / %x20-DFFF / %xE000-FFFD / char = %x9 / %xA / %xD / %x20-DFFF / %xE000-FFFD /
%x10000-10FFFF %x10000-10FFFF
9.4.1. Lexicographic Representation 9.4.1. Lexicographic Representation
A string value is lexicographically represented as character data in A string value is lexicographically represented as character data in
the XML encoding. the XML instance documents.
9.4.2. Canonical Form 9.4.2. Canonical Form
The canonical form is the same as the lexicographical representation. The canonical form is the same as the lexicographical representation.
No Unicode normalization is performed of string values. No Unicode normalization is performed of string values.
9.4.3. Restrictions 9.4.3. Restrictions
A string can be restricted with the "length" (Section 9.4.4) and A string can be restricted with the "length" (Section 9.4.4) and
"pattern" (Section 9.4.6) statements. "pattern" (Section 9.4.6) statements.
skipping to change at page 119, line 32 skipping to change at page 116, line 43
9.4.6. The pattern Statement 9.4.6. The pattern Statement
The "pattern" statement, which is an optional substatement to the The "pattern" statement, which is an optional substatement to the
"type" statement, takes as an argument a regular expression string, "type" statement, takes as an argument a regular expression string,
as defined in [XSD-TYPES]. It is used to restrict the built-in type as defined in [XSD-TYPES]. It is used to restrict the built-in type
"string", or types derived from "string", to values that completely "string", or types derived from "string", to values that completely
matches the pattern. matches the pattern.
If the type has multiple "pattern" statements, the expressions are If the type has multiple "pattern" statements, the expressions are
AND:ed together, i.e. all such expressions have to match. ANDed together, i.e., all such expressions have to match.
If a pattern restriction is applied to an already pattern restricted If a pattern restriction is applied to an already pattern restricted
type, values must match all patterns in the base type, in addition to type, values must match all patterns in the base type, in addition to
the new patterns. the new patterns.
9.4.6.1. The pattern's Substatements 9.4.6.1. The pattern's Substatements
+---------------+---------+-------------+ +---------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+---------------+---------+-------------+ +---------------+---------+-------------+
skipping to change at page 120, line 21 skipping to change at page 117, line 32
pattern "[0-9a-fA-F]*"; pattern "[0-9a-fA-F]*";
} }
the following strings match: the following strings match:
AB // legal AB // legal
9A00 // legal 9A00 // legal
and the following strings do not match: and the following strings do not match:
00ABAB // illegal 00ABAB // illegal, too long
xx00 // illegal xx00 // illegal, bad characters
9.5. The boolean Built-in Type 9.5. The boolean Built-in Type
The boolean built-in type represents a boolean value. The boolean built-in type represents a boolean value.
9.5.1. Lexicographic Representation 9.5.1. Lexicographic Representation
The lexicographical representation of a boolean value is the strings The lexicographical representation of a boolean value is the strings
"true" and "false". "true" and "false".
9.5.2. Restrictions 9.5.2. Canonical Form
The canonical form is the same as the lexicographical representation.
9.5.3. Restrictions
A boolean cannot be restricted. A boolean cannot be restricted.
9.6. The enumeration Built-in Type 9.6. The enumeration Built-in Type
The enumeration built-in type represents values from a set of The enumeration built-in type represents values from a set of
assigned names. assigned names.
9.6.1. Lexicographic Representation 9.6.1. Lexicographic Representation
skipping to change at page 121, line 39 skipping to change at page 119, line 4
| reference | 7.19.4 | 0..1 | | reference | 7.19.4 | 0..1 |
| status | 7.19.2 | 0..1 | | status | 7.19.2 | 0..1 |
| value | 9.6.4.2 | 0..1 | | value | 9.6.4.2 | 0..1 |
+--------------+---------+-------------+ +--------------+---------+-------------+
9.6.4.2. The value Statement 9.6.4.2. The value Statement
The "value" statement, which is optional, is used to associate an The "value" statement, which is optional, is used to associate an
integer value with the assigned name for the enum. This integer integer value with the assigned name for the enum. This integer
value MUST be in the range -2147483648 to 2147483647, and it MUST be value MUST be in the range -2147483648 to 2147483647, and it MUST be
unique within the enumeration type. unique within the enumeration type. The value is unused by YANG and
the XML encoding, but is carried as a convenience to implementors.
If a value is not specified, then one will be automatically assigned. If a value is not specified, then one will be automatically assigned.
If the enum sub-statement is the first one defined, the 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 value is zero (0), otherwise the assigned value is one greater than
the current highest enum value. the current highest enum value.
If the current highest value is equal to 2147483647, then an enum If the current highest value is equal to 2147483647, then an enum
value MUST be specified for enum sub-statements following the one value MUST be specified for enum sub-statements following the one
with the current highest value. with the current highest value.
skipping to change at page 122, line 16 skipping to change at page 119, line 27
type enumeration { type enumeration {
enum enabled { enum enabled {
value 1; value 1;
} }
enum disabled { enum disabled {
value 2; value 2;
} }
} }
leaf myenum {
type enumeration { type enumeration {
enum zero; enum zero;
enum one; enum one;
enum seven { enum seven {
value 7; value 7;
} }
} }
}
The lexicographic representation of the leaf "myenum" with value
"seven" is:
<myenum>seven</myenum>
9.7. The bits Built-in Type 9.7. The bits Built-in Type
The bits built-in type represents a bit set. That is, a bits value The bits built-in type represents a bit set. That is, a bits value
is a set of flags identified by small integer position numbers is a set of flags identified by small integer position numbers
starting at 0. Each bit number has an assigned name. starting at 0. Each bit number has an assigned name.
9.7.1. Restrictions 9.7.1. Restrictions
A bits type cannot be restricted. A bits type cannot be restricted.
skipping to change at page 123, line 26 skipping to change at page 120, line 46
| status | 7.19.2 | 0..1 | | status | 7.19.2 | 0..1 |
| position | 9.7.4.2 | 0..1 | | position | 9.7.4.2 | 0..1 |
+--------------+---------+-------------+ +--------------+---------+-------------+
9.7.4.2. The position Statement 9.7.4.2. The position Statement
The "position" statement, which is optional, takes as an argument a The "position" statement, which is optional, takes as an argument a
non-negative integer value which specifies the bit's position within non-negative integer value which specifies the bit's position within
a hypothetical bit field. The position value MUST be in the range 0 a hypothetical bit field. The position value MUST be in the range 0
to 4294967295, and it MUST be unique within the bits type. The value to 4294967295, and it MUST be unique within the bits type. The value
is unused by YANG and the XML encoding, but is carried as a is unused by YANG and the NETCONF PDUs, but is carried as a
convenience to implementors. convenience to implementors.
If a bit position is not specified, then one will be automatically 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. If the bit sub-statement is the first one defined, the
assigned value is zero (0), otherwise the assigned value is one assigned value is zero (0), otherwise the assigned value is one
greater than the current highest bit position. greater than the current highest bit position.
If the current highest bit position value is equal to 4294967295, If the current highest bit position value is equal to 4294967295,
then a position value MUST be specified for bit sub-statements then a position value MUST be specified for bit sub-statements
following the one with the current highest position value. following the one with the current highest position value.
skipping to change at page 124, line 27 skipping to change at page 121, line 35
default "auto-sense-speed"; default "auto-sense-speed";
} }
The lexicographic representation of this leaf with bit values The lexicographic representation of this leaf with bit values
disable-nagle and 10-Mb-only set would be: disable-nagle and 10-Mb-only set would be:
<mybits>disable-nagle 10-Mb-only</mybits> <mybits>disable-nagle 10-Mb-only</mybits>
9.8. The binary Built-in Type 9.8. The binary Built-in Type
The binary built-in type represents any binary data, i.e. a sequence The binary built-in type represents any binary data, i.e., a sequence
of octets. of octets.
9.8.1. Restrictions 9.8.1. Restrictions
A binary can be restricted with the "length" (Section 9.4.4) A binary can be restricted with the "length" (Section 9.4.4)
statement. The length of a binary value is the number of octets it statement. The length of a binary value is the number of octets it
contains. contains.
9.8.2. Lexicographic Representation 9.8.2. Lexicographic Representation
Binary values are encoded with the base64 encoding scheme [RFC4648]. Binary values are encoded with the base64 encoding scheme [RFC4648].
9.8.3. Canonical Form 9.8.3. Canonical Form
The canonical form of a binary value follow the rules in [RFC4648]. The canonical form of a binary value follow the rules in [RFC4648].
9.9. The leafref Built-in Type 9.9. The leafref Built-in Type
The leafref type is used to reference a particular leaf instance in The leafref type is used to reference a particular leaf instance in
the data tree. Its value is constrained to be the same as the value the data tree. The "path" substatement (Section 9.9.2) selects a set
of an existing leaf. of leaf instances, and the leafref value space is the set of values
of these leaf instances.
If the leaf with the leafref type represents configuration data, and If the leaf with the leafref type represents configuration data, the
the "require-instance" property (Section 9.9.3) is "true", the leaf leaf it refers to MUST also represent configuration. Such a leaf
it refers to MUST also represent configuration. Such a leaf puts a puts a constraint on valid data. All leafref nodes MUST reference
constraint on valid data. All leafref nodes MUST reference existing existing leaf instances for the data to be valid. This constraint is
leaf instances for the data to be valid. This constraint is enforced enforced according to the rules in Section 8.
according to the rules in Section 8.
9.9.1. Restrictions 9.9.1. Restrictions
A leafref can be restricted with the "require-instance" statement A leafref cannot be restricted.
(Section 9.9.3).
9.9.2. The path Statement 9.9.2. The path Statement
The "path" statement, which is a substatement to the "type" The "path" statement, which is a substatement to the "type"
statement, MUST be present if the type is "leafref". It takes as an statement, MUST be present if the type is "leafref". It takes as an
argument a string which MUST refer to a leaf node. The value of the argument a string which MUST refer to a leaf or leaf-list node.
referring leaf MUST match the type of the referred leaf.
The syntax for a path argument is a subset of the XPath syntax. It The syntax for a path argument is a subset of the XPath abbreviated
is an absolute or relative XPath location path in abbreviated syntax, syntax. Predicates are used only for constraining the values for the
where axes are not permitted, and predicates are used only for key nodes for list entries. Each predicate consists of exactly one
constraining the values for the key nodes for list entries. Each equality test per key, and multiple adjacent predicates MAY be
predicate consists of exactly one equality test per key. present if a list has multiple keys. The syntax is formally defined
by the rule "path-arg" in Section 12.
The predicates are only used when more than one key reference is The predicates are only used when more than one key reference is
needed to uniquely identify a leaf instance. This occurs if a list needed to uniquely identify a leaf instance. This occurs if a list
has multiple keys, or a reference to a leaf other than the key in a has multiple keys, or a reference to a leaf other than the key in a
list is needed. In these cases, multiple leafrefs are typically list is needed. In these cases, multiple leafrefs are typically
specified, and predicates are used to tie them together. specified, and predicates are used to tie them together.
The syntax is formally defined by the rule "path-arg" in Section 12. The "path" expression evaluates to a node set consisting of zero, one
or more nodes. If the leaf with the leafref type represents
configuration data, this node set MUST be non-empty.
For leafs of type "leafref", the "path" expression evaluates to a The "path" XPath expression is conceptually evaluated in the
node set consisting of zero, one or more nodes. If following context, in addition to the definition in Section 6.4.1:
"require-instance" is "true", the node set MUST be non-empty.
9.9.3. The require-instance Statement o The context node is the node in the data tree for which the "path"
statement is defined.
The "require-instance" statement, which is a substatement to the The accessible tree depends on the context node:
"type" statement, MAY be present if the type is "leafref" or
"instance-identifier". It takes as an argument the string "true" or
"false". If this statement is not present, it defaults to "true".
If "require-instance" is "true", it means that the instance being o If the leaf with the instance-identifier type represents
referred MUST exist for the data to be valid. This constraint is configuration data, the tree is the data in one of the NETCONF
enforced according to the rules in Section 8. datastores. The XPath root node has all top-level configuration
data nodes in all modules as children.
9.9.4. Lexicographic Representation o Otherwise the tree is all state data on the device, and the
<running/> datastore. The XPath root node has all top-level data
nodes in all modules as children.
9.9.3. Lexicographic Representation
A leafref value is encoded the same way as the leaf it references. A leafref value is encoded the same way as the leaf it references.
9.9.5. Canonical Form 9.9.4. Canonical Form
The canonical form of a leafref is the same as the canonical form of The canonical form of a leafref is the same as the canonical form of
the leaf it references. the leaf it references.
9.9.6. Usage Example 9.9.5. Usage Example
With the following list: With the following list:
list interface { list interface {
key "name"; key "name";
leaf name { leaf name {
type string; type string;
} }
leaf ifIndex { leaf admin-status {
type uint32; type admin-status;
} }
list address { list address {
key "ip"; key "ip";
leaf ip { leaf ip {
type yang:ip-address; type yang:ip-address;
} }
} }
} }
The following leafref refers to an existing interface: The following leafref refers to an existing interface:
skipping to change at page 127, line 24 skipping to change at page 124, line 34
path "../../interface[name = current()/../ifname]" path "../../interface[name = current()/../ifname]"
+ "/address/ip"; + "/address/ip";
} }
} }
} }
An example of a corresponding XML snippet: An example of a corresponding XML snippet:
<interface> <interface>
<name>eth0</name> <name>eth0</name>
<ifIndex>2</ifIndex> <admin-status>up</admin-status>
<address> <address>
<ip>192.0.2.1</ip> <ip>192.0.2.1</ip>
</address> </address>
<address> <address>
<ip>192.0.2.2</ip> <ip>192.0.2.2</ip>
</address> </address>
</interface> </interface>
<interface> <interface>
<name>lo</name> <name>lo</name>
<ifIndex>1</ifIndex> <admin-status>up</admin-status>
<address> <address>
<ip>127.0.0.1</ip> <ip>127.0.0.1</ip>
</address> </address>
</interface> </interface>
<default-address> <default-address>
<ifname>eth0</ifname> <ifname>eth0</ifname>
<address>192.0.2.2</address> <address>192.0.2.2</address>
</default-address> </default-address>
The following list uses a leafref for one of its keys. This is
similar to a foreign key in a relational database.
list packet-filter {
key "if-name filter-id";
leaf if-name {
type leafref {
path "/interfaces/interface/name";
}
}
leaf filter-id {
type uint32;
}
...
}
An example of a corresponding XML anippet:
<interface>
<name>eth0</name>
<admin-status>up</admin-status>
<address>
<ip>192.0.2.1</ip>
</address>
<address>
<ip>192.0.2.2</ip>
</address>
</interface>
<packet-filter>
<if-name>eth0</if-name>
<filter-id>1</filter-id>
...
</packet-filter>
<packet-filter>
<if-name>eth0</if-name>
<filter-id>2</filter-id>
...
</packet-filter>
The following notification defines two leafrefs to refer to an The following notification defines two leafrefs to refer to an
existing ifIndex: existing admin-status:
notification link-failure { notification link-failure {
leaf if-name { leaf if-name {
type leafref { type leafref {
path "/interfaces/interface/name"; path "/interfaces/interface/name";
} }
} }
leaf index { leaf admin-status {
type leafref { type leafref {
path path
"/interfaces/interface[name = current()/../if-name]" "/interfaces/interface[name = current()/../if-name]"
+ "/ifIndex"; + "/admin-status";
} }
} }
} }
An example of a corresponding XML notification: An example of a corresponding XML notification:
<notification <notification
xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
<eventTime>2008-04-01T00:01:00Z</eventTime> <eventTime>2008-04-01T00:01:00Z</eventTime>
<link-failure xmlns="http://acme.example.com/system"> <link-failure xmlns="http://acme.example.com/system">
<if-name>eth0</if-name> <if-name>eth0</if-name>
<index>2</index> <admin-status>up</admin-status>
</link-failure> </link-failure>
</notification> </notification>
9.10. The identityref Built-in Type 9.10. The identityref Built-in Type
The identityref type is used to reference an existing identity (see The identityref type is used to reference an existing identity (see
Section 7.16). Section 7.16).
9.10.1. Restrictions 9.10.1. Restrictions
skipping to change at page 131, line 15 skipping to change at page 129, line 15
union. It takes as an argument a string which is the name of a union. It takes as an argument a string which is the name of a
member type. member type.
A member type can be of any built-in or derived type, except it MUST A member type can be of any built-in or derived type, except it MUST
NOT be one of the built-in types "empty" or "leafref". NOT be one of the built-in types "empty" or "leafref".
When a string representing a union data type is validated, the string When a string representing a union data type is validated, the string
is validated against each member type, in the order they are is validated against each member type, in the order they are
specified in the type statement, until a match is found. specified in the type statement, until a match is found.
Any default values or units properties defined in the member types
are not inherited by the union type.
Example: Example:
type union { type union {
type int32; type int32;
type enumeration { type enumeration {
enum "unbounded"; enum "unbounded";
} }
} }
9.12.1. Restrictions 9.12.1. Restrictions
skipping to change at page 131, line 45 skipping to change at page 129, line 48
The canonical form of a union value is the same as the canonical form The canonical form of a union value is the same as the canonical form
of the member type of the value. of the member type of the value.
9.13. The instance-identifier Built-in Type 9.13. The instance-identifier Built-in Type
The instance-identifier built-in type is used to uniquely identify a The instance-identifier built-in type is used to uniquely identify a
particular instance node in the data tree. particular instance node in the data tree.
The syntax for an instance-identifier is a subset of the XPath The syntax for an instance-identifier is a subset of the XPath
syntax, which is used to uniquely identify a node in the data tree. abbreviated syntax, formally defined by the rule
It is an absolute XPath location path in abbreviated syntax, where "instance-identifier" in Section 12. It is used to uniquely identify
axes are not permitted, and predicates are used only for specifying a node in the data tree. Predicates are used only for specifying the
the values for the key nodes for list entries, a value of a leaf-list values for the key nodes for list entries, a value of a leaf-list
entry, or a positional index for list without keys. For identifying entry, or a positional index for list without keys. For identifying
list entries with keys, each predicate consists of one equality test list entries with keys, each predicate consists of one equality test
per key, and each key MUST have a corresponding predicate. per key, and each key MUST have a corresponding predicate.
If the leaf with the instance-identifier type represents If the leaf with the instance-identifier type represents
configuration data, and the "require-instance" property configuration data, and the "require-instance" property
(Section 9.9.3) is "true", the node it refers to MUST also represent (Section 9.13.2) is "true", the node it refers to MUST also represent
configuration. Such a leaf puts a constraint on valid data. All configuration. Such a leaf puts a constraint on valid data. All
such leaf nodes MUST reference existing nodes for the data to be such leaf nodes MUST reference existing nodes for the data to be
valid. This constraint is enforced according to the rules in valid. This constraint is enforced according to the rules in
Section 8. Section 8.
The syntax is formally defined by the rule "instance-identifier" in The "instance-identifier" XPath expression is conceptually evaluated
Section 12. in the following context, in addition to the definition in
Section 6.4.1:
o The context node is the root node in the accessible tree.
The accessible tree depends on the context node:
o If the leaf with the instance-identifier type represents
configuration data, the tree is the data in one of the NETCONF
datastores. The XPath root node has all top-level configuration
data nodes in all modules as children.
o Otherwise the tree is all state data on the device, and the
<running/> datastore. The XPath root node has all top-level data
nodes in all modules as children.
9.13.1. Restrictions 9.13.1. Restrictions
An instance-identifier can be restricted with the "require-instance" An instance-identifier can be restricted with the "require-instance"
statement (Section 9.9.3). statement (Section 9.13.2).
9.13.2. Lexicographic Representation 9.13.2. The require-instance Statement
The "require-instance" statement, which is a substatement to the
"type" statement, MAY be present if the type is
"instance-identifier". It takes as an argument the string "true" or
"false". If this statement is not present, it defaults to "true".
If "require-instance" is "true", it means that the instance being
referred MUST exist for the data to be valid. This constraint is
enforced according to the rules in Section 8.
If "require-instance" is "false", it means that the instance being
referred MAY exist in valid data, and if it exists, its value MUST be
equal to the value of the referring leaf.
9.13.3. Lexicographic Representation
An instance-identifier value is lexicographically represented as a An instance-identifier value is lexicographically represented as a
string in the XML encoding. The namespace prefixes used in the string. All node names in an instance-identifier value MUST be
encoding MUST be declared in the XML namespace scope in the instance- qualified with explicit namespace prefixes and these prefixes MUST be
idenfitier's XML element. declared in the XML namespace scope in the instance-identifier's XML
element.
Any prefixes used in the encoding are local to each instance Any prefixes used in the encoding are local to each instance
encoding. This means that the same instance-identifier may be encoding. This means that the same instance-identifier may be
encoded differently by different implementations. encoded differently by different implementations.
9.13.3. Canonical Form 9.13.4. Canonical Form
Since the lexicographic form depends on the XML context in which the Since the lexicographic form depends on the XML context in which the
value occurs, this type does not have a canonical form. value occurs, this type does not have a canonical form.
9.13.4. Usage Example 9.13.5. Usage Example
The following are examples of instance identifiers: The following are examples of instance identifiers:
/* instance-identifier for a container */ /* instance-identifier for a container */
/ex:system/ex:services/ex:ssh /ex:system/ex:services/ex:ssh
/* instance-identifier for a leaf */ /* instance-identifier for a leaf */
/ex:system/ex:services/ex:ssh/ex:port /ex:system/ex:services/ex:ssh/ex:port
/* instance-identifier for a list entry */ /* instance-identifier for a list entry */
skipping to change at page 134, line 15 skipping to change at page 132, line 15
10. Updating a Module 10. Updating a Module
As experience is gained with a module, it may be desirable to revise As experience is gained with a module, it may be desirable to revise
that module. However, changes are not allowed if they have any that module. However, changes are not allowed if they have any
potential to cause interoperability problems between a client using potential to cause interoperability problems between a client using
an original specification and a server using an updated an original specification and a server using an updated
specification. specification.
For any published change, a new "revision" statement (Section 7.1.9) For any published change, a new "revision" statement (Section 7.1.9)
SHOULD be included in front of the existing revision statements. SHOULD be included in front of the existing revision statements.
Furthermore, any necessary changes MUST be applied to any meta Furthermore, any necessary changes MUST be applied to any meta data
statements, including the "organization" and "contact" statements statements, including the "organization" and "contact" statements
(Section 7.1.7, Section 7.1.8). (Section 7.1.7, Section 7.1.8).
Note that definitions contained in a module are available to be Note that definitions contained in a module are available to be
imported by any other module, and are referenced in "import" imported by any other module, and are referenced in "import"
statements via the module name. Thus, a module name MUST NOT be statements via the module name. Thus, a module name MUST NOT be
changed. Furthermore, the "namespace" statement MUST NOT be changed, changed. Furthermore, the "namespace" statement MUST NOT be changed,
since all XML elements are encoded in the namespace. since all XML elements are encoded in the namespace.
Obsolete definitions MUST NOT be removed from modules since their Obsolete definitions MUST NOT be removed from modules since their
identifiers may still be referenced by other modules. identifiers may still be referenced by other modules.
A definition may be revised in any of the following ways: A definition may be revised in any of the following ways:
o An "enumeration" type may have new enums added, provided the old o An "enumeration" type may have new enums added, provided the old
enums's values do not change. enums's values do not change.
o A "bits" type may have new bits added, provided the old bits's o A "bits" type may have new bits added, provided the old bit
positions do not change. positions do not change.
o A "range", "length", or "pattern" statement may expand the allowed o A "range", "length", or "pattern" statement may expand the allowed
value space. value space.
o A "default" statement may be added. o A "default" statement may be added.
o A "units" statement may be added. o A "units" statement may be added.
o A "reference" statement may be added or updated. o A "reference" statement may be added or updated.
skipping to change at page 135, line 17 skipping to change at page 133, line 17
o A "description" statement may be added or clarified without o A "description" statement may be added or clarified without
changing the semantics of the definition. changing the semantics of the definition.
o New typedefs, groupings, rpc, notifications, extensions, features, o New typedefs, groupings, rpc, notifications, extensions, features,
and identities may be added. and identities may be added.
o New data definition statements may be added if they do not add 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- mandatory nodes (Section 3.1) to existing nodes or at the top-
level in a module or submodule, or if they are conditionally level in a module or submodule, or if they are conditionally
dependent on a new feature (i.e. have a "if-feature" statement dependent on a new feature (i.e., have a "if-feature" statement
which refers to a new feature). which refers to a new feature).
o A new "case" statement may be added. o A new "case" statement may be added.
o A node that represented state data may be changed to represent o A node that represented state data may be changed to represent
configuration, provided it is not mandatory (Section 3.1). configuration, provided it is not mandatory (Section 3.1).
o An "if-feature" statement may be removed, provided its node is not o An "if-feature" statement may be removed, provided its node is not
mandatory (Section 3.1). mandatory (Section 3.1).
skipping to change at page 135, line 46 skipping to change at page 133, line 46
o Any set of data definition nodes may be replaced with another set o Any set of data definition nodes may be replaced with another set
of syntactically and semantically equivalent nodes. For example, of syntactically and semantically equivalent nodes. For example,
a set of leafs may be replaced by a uses of a grouping with the a set of leafs may be replaced by a uses of a grouping with the
same leafs. same leafs.
o A module may be split into a set of submodules, or submodule may o A module may be split into a set of submodules, or submodule may
be removed, provided the definitions in the module do not change be removed, provided the definitions in the module do not change
in any other way than allowed here. in any other way than allowed here.
o The "prefix" statment may be changed, provided all local uses of o The "prefix" statement may be changed, provided all local uses of
the prefix also are changed. the prefix also are changed.
Otherwise, if the semantics of any previous definition are changed Otherwise, if the semantics of any previous definition are changed
(i.e. if a non-editorial change is made to any definition other than (i.e., if a non-editorial change is made to any definition other than
those specifically allowed above), then this MUST be achieved by a those specifically allowed above), then this MUST be achieved by a
new definition with a new identifier. new definition with a new identifier.
In statements which have any data definition statements as In statements which have any data definition statements as
substatements, those data definition substatements MUST NOT be substatements, those data definition substatements MUST NOT be
reordered. reordered.
11. YIN 11. YIN
A YANG module can be specified in an alternative XML-based syntax A YANG module can be specified in an alternative XML-based syntax
skipping to change at page 137, line 20 skipping to change at page 135, line 20
The YANG and YIN formats contain equivalent information using The YANG and YIN formats contain equivalent information using
different notations. The purpose of the YIN notation is to allow the 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 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. on the YIN format to transform, or filter the model information.
Tools like XSLT or XML validators can be utilized. After this the Tools like XSLT or XML validators can be utilized. After this the
model can be transformed back to the YANG format if needed, which model can be transformed back to the YANG format if needed, which
provides a more concise and readable format. provides a more concise and readable format.
The mapping between YANG and YIN does not modify the information The mapping between YANG and YIN does not modify the information
content of the model. Comments and whitespaces are not preserved. content of the model. Comments and whitespace are not preserved.
11.1. Formal YIN Definition 11.1. Formal YIN Definition
There is a one-to-one correspondence between YANG keywords and YIN There is a one-to-one correspondence between YANG keywords and YIN
elements. The local name of a YIN element is identical to the elements. The local name of a YIN element is identical to the
corresponding YANG keyword. This means in particular that the corresponding YANG keyword. This means in particular that the
document element (root) of a YIN document is always <module> or document element (root) of a YIN document is always <module> or
<submodule>. <submodule>.
YIN elements corresponding to the core YANG keywords belong to the YIN elements corresponding to the core YANG keywords belong to the
namespace whose associated URI is namespace whose associated URI is
"urn:ietf:params:xml:ns:yang:yin:1". "urn:ietf:params:xml:ns:yang:yin:1".
YIN elements corresponding to extension keywords belong to the YIN elements corresponding to extension keywords belong to the
namespace of the YANG module where the extension keyword is declared namespace of the YANG module where the extension keyword is declared
via the "extension" statement. via the "extension" statement.
The names of all YIN elements MUST be properly qualified with their The names of all YIN elements MUST be properly qualified with their
namespaces specified above using the standard mechanisms of namespaces specified above using the standard mechanisms of
[XML-NAMES], i.e. "xmlns" and "xmlns:xxx" attributes. [XML-NAMES], i.e., "xmlns" and "xmlns:xxx" attributes.
The argument of a YANG statement is encoded in YIN either as an XML The argument of a YANG statement is encoded in YIN either as an XML
attribute or a subelement of the keyword element. Table 1 defines attribute or a subelement of the keyword element. Table 1 defines
the encoding for the set of core YANG keywords. For extensions, the the encoding for the set of core YANG keywords. For extensions, the
argument encoding is specified within the "extension" statement (see argument encoding is specified within the "extension" statement (see
Section 7.17). The following rules hold for arguments of both core Section 7.17). The following rules hold for arguments of both core
and extension statements: and extension statements:
o If the argument is encoded as an attribute, this attribute has no o If the argument is encoded as an attribute, this attribute has no
namespace. namespace.
skipping to change at page 148, line 34 skipping to change at page 146, line 34
[error-app-tag-stmt stmtsep] [error-app-tag-stmt stmtsep]
[description-stmt stmtsep] [description-stmt stmtsep]
[reference-stmt stmtsep] [reference-stmt stmtsep]
"}") "}")
error-message-stmt = error-message-keyword sep string stmtend error-message-stmt = error-message-keyword sep string stmtend
error-app-tag-stmt = error-app-tag-keyword sep string stmtend error-app-tag-stmt = error-app-tag-keyword sep string stmtend
min-elements-stmt = min-elements-keyword sep min-elements-stmt = min-elements-keyword sep
min-value-arg-str stmtend; min-value-arg-str stmtend
min-value-arg-str = < a string which matches the rule min-value-arg-str = < a string which matches the rule
min-value-arg > min-value-arg >
min-value-arg = non-negative-integer-value min-value-arg = non-negative-integer-value
max-elements-stmt = max-elements-keyword sep max-elements-stmt = max-elements-keyword sep
max-value-arg-str stmtend; max-value-arg-str stmtend
max-value-arg-str = < a string which matches the rule max-value-arg-str = < a string which matches the rule
max-value-arg > max-value-arg >
max-value-arg = unbounded-keyword / max-value-arg = unbounded-keyword /
positive-integer-value positive-integer-value
value-stmt = value-keyword sep integer-value stmtend value-stmt = value-keyword sep integer-value stmtend
grouping-stmt = grouping-keyword sep identifier-arg-str optsep grouping-stmt = grouping-keyword sep identifier-arg-str optsep
(";" / (";" /
skipping to change at page 162, line 12 skipping to change at page 160, line 12
WSP = SP / HTAB WSP = SP / HTAB
; white space ; white space
13. Error Responses for YANG Related Errors 13. Error Responses for YANG Related Errors
A number of NETCONF error responses are defined for error cases A number of NETCONF error responses are defined for error cases
related to the data-model handling. If the relevant YANG statement related to the data-model handling. If the relevant YANG statement
has an "error-app-tag" substatement, that overrides the default value has an "error-app-tag" substatement, that overrides the default value
specified below. specified below.
13.1. Error Message for Data that Violates a unique Statement: 13.1. Error Message for Data that Violates a unique Statement
If a NETCONF operation would result in configuration data where a If a NETCONF operation would result in configuration data where a
unique constraint is invalidated, the following error is returned: unique constraint is invalidated, the following error is returned:
Tag: operation-failed Tag: operation-failed
Error-app-tag: data-not-unique Error-app-tag: data-not-unique
Error-info: <non-unique>: Contains an instance identifier which Error-info: <non-unique>: Contains an instance identifier which
points to a leaf which invalidates the unique points to a leaf which invalidates the unique
constraint. This element is present once for each constraint. This element is present once for each
leaf invalidating the unique constraint. leaf invalidating the unique constraint.
The <non-unique> element is in the YANG The <non-unique> element is in the YANG
namespace ("urn:ietf:params:xml:ns:yang:1"). namespace ("urn:ietf:params:xml:ns:yang:1").
13.2. Error Message for Data that Violates a max-elements Statement: 13.2. Error Message for Data that Violates a max-elements Statement
If a NETCONF operation would result in configuration data where a If a NETCONF operation would result in configuration data where a
list or a leaf-list would have too many entries the following error list or a leaf-list would have too many entries the following error
is returned: is returned:
Tag: operation-failed Tag: operation-failed
Error-app-tag: too-many-elements Error-app-tag: too-many-elements
This error is returned once, with the error-path identifying the list This error is returned once, with the error-path identifying the list
node, even if there are more than one extra child present. node, even if there are more than one extra child present.
13.3. Error Message for Data that Violates a min-elements Statement: 13.3. Error Message for Data that Violates a min-elements Statement
If a NETCONF operation would result in configuration data where a 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 list or a leaf-list would have too few entries the following error is
returned: returned:
Tag: operation-failed Tag: operation-failed
Error-app-tag: too-few-elements Error-app-tag: too-few-elements
This error is returned once, with the error-path identifying the list This error is returned once, with the error-path identifying the list
node, even if there are more than one child missing. node, even if there are more than one child missing.
13.4. Error Message for Data that Violates a must statement: 13.4. Error Message for Data that Violates a must Statement
If a NETCONF operation would result in configuration data where the If a NETCONF operation would result in configuration data where the
restrictions imposed by a "must" statement is violated the following restrictions imposed by a "must" statement is violated the following
error is returned, unless a specific "error-app-tag" substatement is error is returned, unless a specific "error-app-tag" substatement is
present for the "must" statement. present for the "must" statement.
Tag: operation-failed Tag: operation-failed
Error-app-tag: must-violation Error-app-tag: must-violation
13.5. Error Message for Data that Violates a require-instance 13.5. Error Message for Data that Violates a require-instance Statement
statement:
If a NETCONF operation would result in configuration data where an If a NETCONF operation would result in configuration data where a
instance reference marked with require-instance "true" refers to a leaf of type "instance-identifier" marked with require-instance
non-existing instance, the following error is returned: "true" refers to a non-existing instance, the following error is
returned:
Tag: data-missing Tag: data-missing
Error-app-tag: instance-required Error-app-tag: instance-required
Error-path: Path to the element with the require-instance Error-path: Path to the instance-identifier leaf.
statement
13.6. Error Message for Data that Violates a mandatory choice 13.6. Error Message for Data that does not Match a leafref Type
statement:
If a NETCONF operation would result in configuration data where a
leaf of type "leafref" refers to a non-existing instance, the
following error is returned:
Tag: data-missing
Error-app-tag: instance-required
Error-path: Path to the leafref leaf.
13.7. Error Message for Data that Violates a mandatory choice Statement
If a NETCONF operation would result in configuration data where no If a NETCONF operation would result in configuration data where no
nodes exists in a mandatory choice, the following error is returned: nodes exists in a mandatory choice, the following error is returned:
Tag: data-missing Tag: data-missing
Error-app-tag: missing-choice Error-app-tag: missing-choice
Error-path: Path to the element with the missing choice. Error-path: Path to the element with the missing choice.
Error-info: <missing-choice>: Contains the name of the missing Error-info: <missing-choice>: Contains the name of the missing
mandatory choice. mandatory choice.
The <missing-choice> element is in the YANG The <missing-choice> element is in the YANG
namespace ("urn:ietf:params:xml:ns:yang:1"). namespace ("urn:ietf:params:xml:ns:yang:1").
13.7. Error Message for the "insert" Operation 13.8. Error Message for the "insert" Operation
If the "insert" and "key" or "value" attributes are used in an 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" <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: refers to a non-existing instance, the following error is returned:
Tag: bad-attribute Tag: bad-attribute
Error-app-tag: missing-instance Error-app-tag: missing-instance
14. IANA Considerations 14. IANA Considerations
skipping to change at page 165, line 17 skipping to change at page 164, line 17
This document defines a language with which to write and read This document defines a language with which to write and read
descriptions of management information. The language itself has no descriptions of management information. The language itself has no
security impact on the Internet. security impact on the Internet.
Data modeled in YANG might contain sensitive information. RPCs or Data modeled in YANG might contain sensitive information. RPCs or
notifications defined in YANG might transfer sensitive information. notifications defined in YANG might transfer sensitive information.
Security issues are related to the usage of data modeled in YANG. Security issues are related to the usage of data modeled in YANG.
Such issues shall be dealt with in documents describing the data Such issues shall be dealt with in documents describing the data
models and documents about the interfaces used to manipulate the data models and documents about the interfaces used to manipulate the data
e.g. the NETCONF documents. e.g., the NETCONF documents.
YANG is dependent upon: Data modeled in YANG is dependent upon:
o the security of the transmission infrastructure used to send o the security of the transmission infrastructure used to send
sensitive information sensitive information
o the security of applications which store or release such sensitive o the security of applications which store or release such sensitive
information. information.
o adequate authentication and access control mechanisms to restrict o adequate authentication and access control mechanisms to restrict
the usage of sensitive data. the usage of sensitive data.
16. Contributors 16. Contributors
The following people all contributed significantly to the initial The following people all contributed significantly to the initial
YANG draft: YANG draft:
- Andy Bierman (andybierman.com) - Andy Bierman (Netconf Central)
- Balazs Lengyel (Ericsson) - Balazs Lengyel (Ericsson)
- David Partain (Ericsson) - David Partain (Ericsson)
- Juergen Schoenwaelder (Jacobs University Bremen) - Juergen Schoenwaelder (Jacobs University Bremen)
- Phil Shafer (Juniper Networks) - Phil Shafer (Juniper Networks)
17. Acknowledgements 17. Acknowledgements
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 Preshun, David Reid, and Bert Lhotka, Gerhard Muenz, Tom Petch, Randy Presuhn, David Reid, and Bert
Wijnen. Wijnen.
18. References 18. References
18.1. Normative References 18.1. Normative References
[ISO.10646] [ISO.10646]
International Organization for Standardization, International Organization for Standardization,
"Information Technology - Universal Multiple-octet coded "Information Technology - Universal Multiple-octet coded
Character Set (UCS) - Part 1: Architecture and Basic Character Set (UCS) - Part 1: Architecture and Basic
skipping to change at page 169, line 12 skipping to change at page 168, line 12
[XPATH] Clark, J. and S. DeRose, "XML Path Language (XPath) [XPATH] Clark, J. and S. DeRose, "XML Path Language (XPath)
Version 1.0", World Wide Web Consortium Version 1.0", World Wide Web Consortium
Recommendation REC-xpath-19991116, November 1999, Recommendation REC-xpath-19991116, November 1999,
<http://www.w3.org/TR/1999/REC-xpath-19991116>. <http://www.w3.org/TR/1999/REC-xpath-19991116>.
[XSD-TYPES] [XSD-TYPES]
Biron, P V. and A. Malhotra, "XML Schema Part 2: Datatypes Biron, P V. and A. Malhotra, "XML Schema Part 2: Datatypes
Second Edition", W3C REC REC-xmlschema-2-20041028, Second Edition", W3C REC REC-xmlschema-2-20041028,
October 2004. October 2004.
[XSLT] Clark, J., "XSL Transformations (XSLT) Version 1.0", World
Wide Web Consortium Recommendation REC-xslt-19991116,
November 1999,
<http://www.w3.org/TR/1999/REC-xslt-19991116>.
18.2. Non-Normative References 18.2. Non-Normative References
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Structure of Management Information Schoenwaelder, Ed., "Structure of Management Information
Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Textual Conventions for SMIv2", Schoenwaelder, Ed., "Textual Conventions for SMIv2",
STD 58, RFC 2579, April 1999. STD 58, RFC 2579, April 1999.
[RFC3780] Strauss, F. and J. Schoenwaelder, "SMIng - Next Generation [RFC3780] Strauss, F. and J. Schoenwaelder, "SMIng - Next Generation
Structure of Management Information", RFC 3780, May 2004. Structure of Management Information", RFC 3780, May 2004.
[XPATH2.0]
Chamberlin, D., Boag, S., Berglund, A., Robie, J., Simeon,
J., Fernandez, M., and M. Kay, "XML Path Language (XPath)
2.0", World Wide Web Consortium Recommendation REC-
xpath20-20070123, January 2007,
<http://www.w3.org/TR/2007/REC-xpath20-20070123>.
[XSLT] Clark, J., "XSL Transformations (XSLT) Version 1.0", World
Wide Web Consortium Recommendation REC-xslt-19991116,
November 1999,
<http://www.w3.org/TR/1999/REC-xslt-19991116>.
Appendix A. ChangeLog Appendix A. ChangeLog
A.1. Version -05 RFC Editor: remove this section upon publication as an RFC.
A.1. Version -06
o Various bug fixes, clarifications and editorial fixes after WGLC.
o Removed "require-instance" for leafref.
o Allow leafrefs to refer to leaf-lists.
o Clarified the XPath context in Section 6.4.1, and for "must",
"when", "augment", "path" and "instance-identifier".
A.2. Version -05
o Replaced the data types "float32" and "float64" with "decimal64". o Replaced the data types "float32" and "float64" with "decimal64".
o Specified that the elements in the XML encoding of configuration o Specified that the elements in the XML encoding of configuration
data can occur in any order. data can occur in any order.
o Clarified that "augment" cannot add multiple nodes with the same o Clarified that "augment" cannot add multiple nodes with the same
name. name.
o Clarified what "when" means in RPC input / output. o Clarified what "when" means in RPC input / output.
o Wrote the IANA Considerations section. o Wrote the IANA Considerations section.
o Changed requirement for minimum identifier length to 64 o Changed requirement for minimum identifier length to 64
characters. characters.
A.2. Version -04 A.3. Version -04
o Using "revision-date" substatement to "import" and "include". o Using "revision-date" substatement to "import" and "include".
o Corrected grammar and text for instance-identifier. o Corrected grammar and text for instance-identifier.
o Fixed bugs in some examples. o Fixed bugs in some examples.
o Rewrote the YIN description to use a declarative style. o Rewrote the YIN description to use a declarative style.
o Added two error codes in Section 13. o Added two error codes in Section 13.
skipping to change at page 171, line 5 skipping to change at page 170, line 15
o Corrected grammar for key-arg; now allowing optional prefix on o Corrected grammar for key-arg; now allowing optional prefix on
each leaf identifier. each leaf identifier.
o Clarified that "unique" constraints only check instances with o Clarified that "unique" constraints only check instances with
values for all referenced leafs. values for all referenced leafs.
o Clarified how mandatory and min-elements constraints are enforced. o Clarified how mandatory and min-elements constraints are enforced.
o Editorial fixes. o Editorial fixes.
A.3. Version -03 A.4. Version -03
o Added import by revision (yang-00413) o Added import by revision (yang-00413)
o Changed type "keyref" to "leafref", and added the statement o Changed type "keyref" to "leafref", and added the statement
"require-instance" (yang-01253) "require-instance" (yang-01253)
o Clarified that data sent from the server must be in the canonical o Clarified that data sent from the server must be in the canonical
form. form.
o Clarified when and how constraints in the models are enforced. o Clarified when and how constraints in the models are enforced.
o Many editorial fixes o Many editorial fixes
o Added more strict grammar for the "deviate" statement. o Added more strict grammar for the "deviate" statement.
A.4. Version -02 A.5. Version -02
o Added module update rules. (yang-00000) o Added module update rules. (yang-00000)
o Added "refine" statement as a substatement to "uses". (yang-00088) 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 "augment" on top-level and in "uses" only. (yang-00088)
o Allow "when" on all data defintion statements. (yang-00088) o Allow "when" on all data defintion statements. (yang-00088)
o Added section "Constraints" and clarified when constraints are o Added section "Constraints" and clarified when constraints are
skipping to change at page 171, line 41 skipping to change at page 171, line 4
o Added section "Constraints" and clarified when constraints are o Added section "Constraints" and clarified when constraints are
enforced. (yang-00172) enforced. (yang-00172)
o Added "feature" and "if-feature" statements. (yang-00750) o Added "feature" and "if-feature" statements. (yang-00750)
o Added "prefix" as a substatement to "belongs-to". (yang-00755) o Added "prefix" as a substatement to "belongs-to". (yang-00755)
o Added section on Conformance. (yang-01281) o Added section on Conformance. (yang-01281)
o Added "deviation" statement. (yang-01281) o Added "deviation" statement. (yang-01281)
o Added "identity" statement and "identityref" type. (yang-01339) o Added "identity" statement and "identityref" type. (yang-01339)
o Aligned grammar for "enum" with text. o Aligned grammar for "enum" with text.
A.5. Version -01 A.6. Version -01
o Removed "Appendix A. Derived YANG Types". o Removed "Appendix A. Derived YANG Types".
o Removed "Appendix C. XML Schema Considerations". o Removed "Appendix C. XML Schema Considerations".
o Removed "Appendix F. Why We Need a New Modeling Language". o Removed "Appendix F. Why We Need a New Modeling Language".
o Moved "Appendix B. YIN" to its own section. o Moved "Appendix B. YIN" to its own section.
o Moved "Appendix D. YANG ABNF Grammar" to its own section. o Moved "Appendix D. YANG ABNF Grammar" to its own section.
skipping to change at page 172, line 44 skipping to change at page 172, line 7
o Fixed whitespace issues in the ABNF grammar. o Fixed whitespace issues in the ABNF grammar.
o Added the term "mandatory node", and refer to it in the o Added the term "mandatory node", and refer to it in the
description of augment (see Section 7.15), and choice (see description of augment (see Section 7.15), and choice (see
Section 7.9.3). Section 7.9.3).
o Added support for multiple "pattern" statements in "type". o Added support for multiple "pattern" statements in "type".
o Several clarifications and fixed typos. o Several clarifications and fixed typos.
A.6. Version -00 A.7. Version -00
Changes from draft-bjorklund-netconf-yang-02.txt Changes from draft-bjorklund-netconf-yang-02.txt
o Fixed bug in grammar for bit-stmt o Fixed bug in grammar for bit-stmt
o Fixed bugs in example XPath expressions o Fixed bugs in example XPath expressions
o Added keyword 'presence' to the YIN mapping table o Added keyword 'presence' to the YIN mapping table
Author's Address Author's Address
Martin Bjorklund (editor) Martin Bjorklund (editor)
Tail-f Systems Tail-f Systems
Email: mbj@tail-f.com Email: mbj@tail-f.com
 End of changes. 233 change blocks. 
651 lines changed or deleted 804 lines changed or added

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