draft-ietf-netmod-yang-03.txt   draft-ietf-netmod-yang-04.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 January 12, 2009 Intended status: Standards Track March 6, 2009
Expires: July 16, 2009 Expires: September 7, 2009
YANG - A data modeling language for NETCONF YANG - A data modeling language for NETCONF
draft-ietf-netmod-yang-03 draft-ietf-netmod-yang-04
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 July 16, 2009. This Internet-Draft will expire on September 7, 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 Provisions Relating to IETF Documents in effect on the date of
(http://trustee.ietf.org/license-info) in effect on the date of publication of this document (http://trustee.ietf.org/license-info).
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document.
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 NETCONF protocol, NETCONF remote
procedure calls, and NETCONF notifications. procedure calls, and NETCONF notifications.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 8
skipping to change at page 3, line 8 skipping to change at page 3, line 8
6. YANG syntax . . . . . . . . . . . . . . . . . . . . . . . . . 36 6. YANG syntax . . . . . . . . . . . . . . . . . . . . . . . . . 36
6.1. Lexicographical Tokenization . . . . . . . . . . . . . . 36 6.1. Lexicographical Tokenization . . . . . . . . . . . . . . 36
6.1.1. Comments . . . . . . . . . . . . . . . . . . . . . . 36 6.1.1. Comments . . . . . . . . . . . . . . . . . . . . . . 36
6.1.2. Tokens . . . . . . . . . . . . . . . . . . . . . . . 36 6.1.2. Tokens . . . . . . . . . . . . . . . . . . . . . . . 36
6.1.3. Quoting . . . . . . . . . . . . . . . . . . . . . . . 36 6.1.3. Quoting . . . . . . . . . . . . . . . . . . . . . . . 36
6.2. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 38 6.2. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 38
6.2.1. Identifiers and their namespaces . . . . . . . . . . 38 6.2.1. Identifiers and their namespaces . . . . . . . . . . 38
6.3. Statements . . . . . . . . . . . . . . . . . . . . . . . 39 6.3. Statements . . . . . . . . . . . . . . . . . . . . . . . 39
6.3.1. Language Extensions . . . . . . . . . . . . . . . . . 39 6.3.1. Language Extensions . . . . . . . . . . . . . . . . . 39
6.4. XPath Evaluations . . . . . . . . . . . . . . . . . . . . 39 6.4. XPath Evaluations . . . . . . . . . . . . . . . . . . . . 39
7. YANG Statements . . . . . . . . . . . . . . . . . . . . . . . 40 7. YANG Statements . . . . . . . . . . . . . . . . . . . . . . . 41
7.1. The module Statement . . . . . . . . . . . . . . . . . . 40 7.1. The module Statement . . . . . . . . . . . . . . . . . . 41
7.1.1. The module's Substatements . . . . . . . . . . . . . 41 7.1.1. The module's Substatements . . . . . . . . . . . . . 42
7.1.2. The yang-version Statement . . . . . . . . . . . . . 42 7.1.2. The yang-version Statement . . . . . . . . . . . . . 43
7.1.3. The namespace Statement . . . . . . . . . . . . . . . 42 7.1.3. The namespace Statement . . . . . . . . . . . . . . . 43
7.1.4. The prefix Statement . . . . . . . . . . . . . . . . 43 7.1.4. The prefix Statement . . . . . . . . . . . . . . . . 44
7.1.5. The import Statement . . . . . . . . . . . . . . . . 43 7.1.5. The import Statement . . . . . . . . . . . . . . . . 44
7.1.6. The include Statement . . . . . . . . . . . . . . . . 44 7.1.6. The include Statement . . . . . . . . . . . . . . . . 45
7.1.7. The organization Statement . . . . . . . . . . . . . 44 7.1.7. The organization Statement . . . . . . . . . . . . . 45
7.1.8. The contact Statement . . . . . . . . . . . . . . . . 44 7.1.8. The contact Statement . . . . . . . . . . . . . . . . 46
7.1.9. The revision Statement . . . . . . . . . . . . . . . 45 7.1.9. The revision Statement . . . . . . . . . . . . . . . 46
7.1.10. Usage Example . . . . . . . . . . . . . . . . . . . . 46 7.1.10. Usage Example . . . . . . . . . . . . . . . . . . . . 47
7.2. The submodule Statement . . . . . . . . . . . . . . . . . 46 7.2. The submodule Statement . . . . . . . . . . . . . . . . . 47
7.2.1. The submodule's Substatements . . . . . . . . . . . . 47 7.2.1. The submodule's Substatements . . . . . . . . . . . . 48
7.2.2. The belongs-to Statement . . . . . . . . . . . . . . 48 7.2.2. The belongs-to Statement . . . . . . . . . . . . . . 49
7.2.3. Usage Example . . . . . . . . . . . . . . . . . . . . 49 7.2.3. Usage Example . . . . . . . . . . . . . . . . . . . . 50
7.3. The typedef Statement . . . . . . . . . . . . . . . . . . 49 7.3. The typedef Statement . . . . . . . . . . . . . . . . . . 50
7.3.1. The typedef's Substatements . . . . . . . . . . . . . 50 7.3.1. The typedef's Substatements . . . . . . . . . . . . . 51
7.3.2. The typedef's type Statement . . . . . . . . . . . . 50 7.3.2. The typedef's type Statement . . . . . . . . . . . . 51
7.3.3. The units Statement . . . . . . . . . . . . . . . . . 50 7.3.3. The units Statement . . . . . . . . . . . . . . . . . 51
7.3.4. The typedef's default Statement . . . . . . . . . . . 50 7.3.4. The typedef's default Statement . . . . . . . . . . . 51
7.3.5. Usage Example . . . . . . . . . . . . . . . . . . . . 51 7.3.5. Usage Example . . . . . . . . . . . . . . . . . . . . 52
7.4. The type Statement . . . . . . . . . . . . . . . . . . . 51 7.4. The type Statement . . . . . . . . . . . . . . . . . . . 52
7.4.1. The type's Substatements . . . . . . . . . . . . . . 51 7.4.1. The type's Substatements . . . . . . . . . . . . . . 52
7.5. The container Statement . . . . . . . . . . . . . . . . . 51 7.5. The container Statement . . . . . . . . . . . . . . . . . 52
7.5.1. Containers with Presence . . . . . . . . . . . . . . 52 7.5.1. Containers with Presence . . . . . . . . . . . . . . 53
7.5.2. The container's Substatements . . . . . . . . . . . . 53 7.5.2. The container's Substatements . . . . . . . . . . . . 54
7.5.3. The must Statement . . . . . . . . . . . . . . . . . 53 7.5.3. The must Statement . . . . . . . . . . . . . . . . . 54
7.5.4. The must's Substatements . . . . . . . . . . . . . . 55 7.5.4. The must's Substatements . . . . . . . . . . . . . . 56
7.5.5. The presence Statement . . . . . . . . . . . . . . . 56 7.5.5. The presence Statement . . . . . . . . . . . . . . . 57
7.5.6. The container's Child Node Statements . . . . . . . . 56 7.5.6. The container's Child Node Statements . . . . . . . . 57
7.5.7. XML Encoding Rules . . . . . . . . . . . . . . . . . 56 7.5.7. XML Encoding Rules . . . . . . . . . . . . . . . . . 57
7.5.8. NETCONF <edit-config> Operations . . . . . . . . . . 56 7.5.8. NETCONF <edit-config> Operations . . . . . . . . . . 57
7.5.9. Usage Example . . . . . . . . . . . . . . . . . . . . 57 7.5.9. Usage Example . . . . . . . . . . . . . . . . . . . . 58
7.6. The leaf Statement . . . . . . . . . . . . . . . . . . . 58 7.6. The leaf Statement . . . . . . . . . . . . . . . . . . . 59
7.6.1. The leaf's Substatements . . . . . . . . . . . . . . 59 7.6.1. The leaf's Substatements . . . . . . . . . . . . . . 60
7.6.2. The leaf's type Statement . . . . . . . . . . . . . . 59 7.6.2. The leaf's type Statement . . . . . . . . . . . . . . 60
7.6.3. The leaf's default Statement . . . . . . . . . . . . 59 7.6.3. The leaf's default Statement . . . . . . . . . . . . 60
7.6.4. The leaf's mandatory Statement . . . . . . . . . . . 59 7.6.4. The leaf's mandatory Statement . . . . . . . . . . . 60
7.6.5. XML Encoding Rules . . . . . . . . . . . . . . . . . 60 7.6.5. XML Encoding Rules . . . . . . . . . . . . . . . . . 61
7.6.6. NETCONF <edit-config> Operations . . . . . . . . . . 60 7.6.6. NETCONF <edit-config> Operations . . . . . . . . . . 61
7.6.7. Usage Example . . . . . . . . . . . . . . . . . . . . 60 7.6.7. Usage Example . . . . . . . . . . . . . . . . . . . . 61
7.7. The leaf-list Statement . . . . . . . . . . . . . . . . . 61 7.7. The leaf-list Statement . . . . . . . . . . . . . . . . . 62
7.7.1. Ordering . . . . . . . . . . . . . . . . . . . . . . 61 7.7.1. Ordering . . . . . . . . . . . . . . . . . . . . . . 63
7.7.2. The leaf-list's Substatements . . . . . . . . . . . . 63 7.7.2. The leaf-list's Substatements . . . . . . . . . . . . 64
7.7.3. The min-elements Statement . . . . . . . . . . . . . 63 7.7.3. The min-elements Statement . . . . . . . . . . . . . 64
7.7.4. The max-elements Statement . . . . . . . . . . . . . 63 7.7.4. The max-elements Statement . . . . . . . . . . . . . 64
7.7.5. The ordered-by Statement . . . . . . . . . . . . . . 63 7.7.5. The ordered-by Statement . . . . . . . . . . . . . . 65
7.7.6. XML Encoding Rules . . . . . . . . . . . . . . . . . 64 7.7.6. XML Encoding Rules . . . . . . . . . . . . . . . . . 65
7.7.7. NETCONF <edit-config> operations . . . . . . . . . . 64 7.7.7. NETCONF <edit-config> operations . . . . . . . . . . 65
7.7.8. Usage Example . . . . . . . . . . . . . . . . . . . . 65 7.7.8. Usage Example . . . . . . . . . . . . . . . . . . . . 66
7.8. The list Statement . . . . . . . . . . . . . . . . . . . 67 7.8. The list Statement . . . . . . . . . . . . . . . . . . . 68
7.8.1. The list's Substatements . . . . . . . . . . . . . . 67 7.8.1. The list's Substatements . . . . . . . . . . . . . . 69
7.8.2. The list's key Statement . . . . . . . . . . . . . . 68 7.8.2. The list's key Statement . . . . . . . . . . . . . . 69
7.8.3. The lists's unique Statement . . . . . . . . . . . . 69 7.8.3. The lists's unique Statement . . . . . . . . . . . . 70
7.8.4. The list's Child Node Statements . . . . . . . . . . 70 7.8.4. The list's Child Node Statements . . . . . . . . . . 71
7.8.5. XML Encoding Rules . . . . . . . . . . . . . . . . . 70 7.8.5. XML Encoding Rules . . . . . . . . . . . . . . . . . 71
7.8.6. NETCONF <edit-config> operations . . . . . . . . . . 70 7.8.6. NETCONF <edit-config> operations . . . . . . . . . . 72
7.8.7. Usage Example . . . . . . . . . . . . . . . . . . . . 71 7.8.7. Usage Example . . . . . . . . . . . . . . . . . . . . 72
7.9. The choice Statement . . . . . . . . . . . . . . . . . . 74 7.9. The choice Statement . . . . . . . . . . . . . . . . . . 76
7.9.1. The choice's Substatements . . . . . . . . . . . . . 75 7.9.1. The choice's Substatements . . . . . . . . . . . . . 76
7.9.2. The choice's case Statement . . . . . . . . . . . . . 75 7.9.2. The choice's case Statement . . . . . . . . . . . . . 76
7.9.3. The choice's default Statement . . . . . . . . . . . 76 7.9.3. The choice's default Statement . . . . . . . . . . . 78
7.9.4. The choice's mandatory Statement . . . . . . . . . . 78 7.9.4. The choice's mandatory Statement . . . . . . . . . . 79
7.9.5. XML Encoding Rules . . . . . . . . . . . . . . . . . 78 7.9.5. XML Encoding Rules . . . . . . . . . . . . . . . . . 80
7.9.6. NETCONF <edit-config> operations . . . . . . . . . . 78 7.9.6. NETCONF <edit-config> operations . . . . . . . . . . 80
7.9.7. Usage Example . . . . . . . . . . . . . . . . . . . . 78 7.9.7. Usage Example . . . . . . . . . . . . . . . . . . . . 80
7.10. The anyxml Statement . . . . . . . . . . . . . . . . . . 79 7.10. The anyxml Statement . . . . . . . . . . . . . . . . . . 81
7.10.1. The anyxml's Substatements . . . . . . . . . . . . . 80 7.10.1. The anyxml's Substatements . . . . . . . . . . . . . 82
7.10.2. XML Encoding Rules . . . . . . . . . . . . . . . . . 80 7.10.2. XML Encoding Rules . . . . . . . . . . . . . . . . . 82
7.10.3. NETCONF <edit-config> operations . . . . . . . . . . 80 7.10.3. NETCONF <edit-config> operations . . . . . . . . . . 82
7.10.4. Usage Example . . . . . . . . . . . . . . . . . . . . 81 7.10.4. Usage Example . . . . . . . . . . . . . . . . . . . . 83
7.11. The grouping Statement . . . . . . . . . . . . . . . . . 81 7.11. The grouping Statement . . . . . . . . . . . . . . . . . 83
7.11.1. The grouping's Substatements . . . . . . . . . . . . 82 7.11.1. The grouping's Substatements . . . . . . . . . . . . 84
7.11.2. Usage Example . . . . . . . . . . . . . . . . . . . . 82 7.11.2. Usage Example . . . . . . . . . . . . . . . . . . . . 84
7.12. The uses Statement . . . . . . . . . . . . . . . . . . . 82 7.12. The uses Statement . . . . . . . . . . . . . . . . . . . 84
7.12.1. The uses's Substatements . . . . . . . . . . . . . . 83 7.12.1. The uses's Substatements . . . . . . . . . . . . . . 85
7.12.2. The refine Statement . . . . . . . . . . . . . . . . 83 7.12.2. The refine Statement . . . . . . . . . . . . . . . . 85
7.12.3. XML Encoding Rules . . . . . . . . . . . . . . . . . 84 7.12.3. XML Encoding Rules . . . . . . . . . . . . . . . . . 86
7.12.4. Usage Example . . . . . . . . . . . . . . . . . . . . 84 7.12.4. Usage Example . . . . . . . . . . . . . . . . . . . . 86
7.13. The rpc Statement . . . . . . . . . . . . . . . . . . . . 85 7.13. The rpc Statement . . . . . . . . . . . . . . . . . . . . 87
7.13.1. The rpc's Substatements . . . . . . . . . . . . . . . 86 7.13.1. The rpc's Substatements . . . . . . . . . . . . . . . 88
7.13.2. The input Statement . . . . . . . . . . . . . . . . . 86 7.13.2. The input Statement . . . . . . . . . . . . . . . . . 88
7.13.3. The output Statement . . . . . . . . . . . . . . . . 87 7.13.3. The output Statement . . . . . . . . . . . . . . . . 89
7.13.4. XML Encoding Rules . . . . . . . . . . . . . . . . . 88 7.13.4. XML Encoding Rules . . . . . . . . . . . . . . . . . 90
7.13.5. Usage Example . . . . . . . . . . . . . . . . . . . . 88 7.13.5. Usage Example . . . . . . . . . . . . . . . . . . . . 90
7.14. The notification Statement . . . . . . . . . . . . . . . 89 7.14. The notification Statement . . . . . . . . . . . . . . . 91
7.14.1. The notification's Substatements . . . . . . . . . . 90 7.14.1. The notification's Substatements . . . . . . . . . . 92
7.14.2. XML Encoding Rules . . . . . . . . . . . . . . . . . 90 7.14.2. XML Encoding Rules . . . . . . . . . . . . . . . . . 92
7.14.3. Usage Example . . . . . . . . . . . . . . . . . . . . 90 7.14.3. Usage Example . . . . . . . . . . . . . . . . . . . . 92
7.15. The augment Statement . . . . . . . . . . . . . . . . . . 91 7.15. The augment Statement . . . . . . . . . . . . . . . . . . 93
7.15.1. The augment's Substatements . . . . . . . . . . . . . 92 7.15.1. The augment's Substatements . . . . . . . . . . . . . 94
7.15.2. XML Encoding Rules . . . . . . . . . . . . . . . . . 92 7.15.2. XML Encoding Rules . . . . . . . . . . . . . . . . . 94
7.15.3. Usage Example . . . . . . . . . . . . . . . . . . . . 93 7.15.3. Usage Example . . . . . . . . . . . . . . . . . . . . 95
7.16. The identity Statement . . . . . . . . . . . . . . . . . 95 7.16. The identity Statement . . . . . . . . . . . . . . . . . 97
7.16.1. The identity's Substatements . . . . . . . . . . . . 95 7.16.1. The identity's Substatements . . . . . . . . . . . . 97
7.16.2. The base Statement . . . . . . . . . . . . . . . . . 95 7.16.2. The base Statement . . . . . . . . . . . . . . . . . 97
7.16.3. Usage Example . . . . . . . . . . . . . . . . . . . . 96 7.16.3. Usage Example . . . . . . . . . . . . . . . . . . . . 98
7.17. The extension Statement . . . . . . . . . . . . . . . . . 96 7.17. The extension Statement . . . . . . . . . . . . . . . . . 98
7.17.1. The extension's Substatements . . . . . . . . . . . . 97 7.17.1. The extension's Substatements . . . . . . . . . . . . 99
7.17.2. The argument Statement . . . . . . . . . . . . . . . 97 7.17.2. The argument Statement . . . . . . . . . . . . . . . 99
7.17.3. Usage Example . . . . . . . . . . . . . . . . . . . . 98 7.17.3. Usage Example . . . . . . . . . . . . . . . . . . . . 100
7.18. Conformance-related Statements . . . . . . . . . . . . . 98 7.18. Conformance-related Statements . . . . . . . . . . . . . 100
7.18.1. The feature Statement . . . . . . . . . . . . . . . . 98 7.18.1. The feature Statement . . . . . . . . . . . . . . . . 100
7.18.2. The if-feature Statement . . . . . . . . . . . . . . 100 7.18.2. The if-feature Statement . . . . . . . . . . . . . . 102
7.18.3. The deviation Statement . . . . . . . . . . . . . . . 100 7.18.3. The deviation Statement . . . . . . . . . . . . . . . 102
7.19. Common Statements . . . . . . . . . . . . . . . . . . . . 103 7.19. Common Statements . . . . . . . . . . . . . . . . . . . . 105
7.19.1. The config Statement . . . . . . . . . . . . . . . . 103 7.19.1. The config Statement . . . . . . . . . . . . . . . . 105
7.19.2. The status Statement . . . . . . . . . . . . . . . . 103 7.19.2. The status Statement . . . . . . . . . . . . . . . . 105
7.19.3. The description Statement . . . . . . . . . . . . . . 104 7.19.3. The description Statement . . . . . . . . . . . . . . 106
7.19.4. The reference Statement . . . . . . . . . . . . . . . 104 7.19.4. The reference Statement . . . . . . . . . . . . . . . 106
7.19.5. The when Statement . . . . . . . . . . . . . . . . . 104 7.19.5. The when Statement . . . . . . . . . . . . . . . . . 106
8. Constraints . . . . . . . . . . . . . . . . . . . . . . . . . 106 8. Constraints . . . . . . . . . . . . . . . . . . . . . . . . . 109
8.1. Constraints on Data . . . . . . . . . . . . . . . . . . . 106 8.1. Constraints on Data . . . . . . . . . . . . . . . . . . . 109
8.2. Hierarchy of Constraints . . . . . . . . . . . . . . . . 106 8.2. Hierarchy of Constraints . . . . . . . . . . . . . . . . 109
8.3. Constraint Enforcement Model . . . . . . . . . . . . . . 106 8.3. Constraint Enforcement Model . . . . . . . . . . . . . . 109
8.3.1. Payload Parsing . . . . . . . . . . . . . . . . . . . 107 8.3.1. Payload Parsing . . . . . . . . . . . . . . . . . . . 110
8.3.2. NETCONF <edit-config> Processing . . . . . . . . . . 107 8.3.2. NETCONF <edit-config> Processing . . . . . . . . . . 110
8.3.3. Validation . . . . . . . . . . . . . . . . . . . . . 108 8.3.3. Validation . . . . . . . . . . . . . . . . . . . . . 111
9. Built-in Types . . . . . . . . . . . . . . . . . . . . . . . 109 9. Built-in Types . . . . . . . . . . . . . . . . . . . . . . . 112
9.1. Canonical representation . . . . . . . . . . . . . . . . 109 9.1. Canonical representation . . . . . . . . . . . . . . . . 112
9.2. The Integer Built-in Types . . . . . . . . . . . . . . . 109 9.2. The Integer Built-in Types . . . . . . . . . . . . . . . 112
9.2.1. Lexicographic Representation . . . . . . . . . . . . 110 9.2.1. Lexicographic Representation . . . . . . . . . . . . 113
9.2.2. Canonical Form . . . . . . . . . . . . . . . . . . . 111 9.2.2. Canonical Form . . . . . . . . . . . . . . . . . . . 114
9.2.3. Restrictions . . . . . . . . . . . . . . . . . . . . 111 9.2.3. Restrictions . . . . . . . . . . . . . . . . . . . . 114
9.2.4. The range Statement . . . . . . . . . . . . . . . . . 111 9.2.4. The range Statement . . . . . . . . . . . . . . . . . 114
9.2.5. Usage Example . . . . . . . . . . . . . . . . . . . . 112 9.2.5. Usage Example . . . . . . . . . . . . . . . . . . . . 115
9.3. The Floating Point Built-in Types . . . . . . . . . . . . 112 9.3. The Floating Point Built-in Types . . . . . . . . . . . . 115
9.3.1. Lexicographic Representation . . . . . . . . . . . . 112 9.3.1. Lexicographic Representation . . . . . . . . . . . . 115
9.3.2. Canonical Form . . . . . . . . . . . . . . . . . . . 112 9.3.2. Canonical Form . . . . . . . . . . . . . . . . . . . 115
9.3.3. Restrictions . . . . . . . . . . . . . . . . . . . . 112 9.3.3. Restrictions . . . . . . . . . . . . . . . . . . . . 115
9.3.4. Usage Example . . . . . . . . . . . . . . . . . . . . 113 9.3.4. Usage Example . . . . . . . . . . . . . . . . . . . . 116
9.4. The string Built-in Type . . . . . . . . . . . . . . . . 113 9.4. The string Built-in Type . . . . . . . . . . . . . . . . 116
9.4.1. Lexicographic Representation . . . . . . . . . . . . 113 9.4.1. Lexicographic Representation . . . . . . . . . . . . 116
9.4.2. Canonical Form . . . . . . . . . . . . . . . . . . . 113 9.4.2. Canonical Form . . . . . . . . . . . . . . . . . . . 116
9.4.3. Restrictions . . . . . . . . . . . . . . . . . . . . 113 9.4.3. Restrictions . . . . . . . . . . . . . . . . . . . . 116
9.4.4. The length Statement . . . . . . . . . . . . . . . . 113 9.4.4. The length Statement . . . . . . . . . . . . . . . . 116
9.4.5. Usage Example . . . . . . . . . . . . . . . . . . . . 114 9.4.5. Usage Example . . . . . . . . . . . . . . . . . . . . 117
9.4.6. The pattern Statement . . . . . . . . . . . . . . . . 115 9.4.6. The pattern Statement . . . . . . . . . . . . . . . . 118
9.4.7. Usage Example . . . . . . . . . . . . . . . . . . . . 115 9.4.7. Usage Example . . . . . . . . . . . . . . . . . . . . 118
9.5. The boolean Built-in Type . . . . . . . . . . . . . . . . 115 9.5. The boolean Built-in Type . . . . . . . . . . . . . . . . 119
9.5.1. Lexicographic Representation . . . . . . . . . . . . 116 9.5.1. Lexicographic Representation . . . . . . . . . . . . 119
9.5.2. Restrictions . . . . . . . . . . . . . . . . . . . . 116 9.5.2. Restrictions . . . . . . . . . . . . . . . . . . . . 119
9.6. The enumeration Built-in Type . . . . . . . . . . . . . . 116 9.6. The enumeration Built-in Type . . . . . . . . . . . . . . 119
9.6.1. Lexicographic Representation . . . . . . . . . . . . 116 9.6.1. Lexicographic Representation . . . . . . . . . . . . 119
9.6.2. Canonical Form . . . . . . . . . . . . . . . . . . . 116 9.6.2. Canonical Form . . . . . . . . . . . . . . . . . . . 119
9.6.3. Restrictions . . . . . . . . . . . . . . . . . . . . 116 9.6.3. Restrictions . . . . . . . . . . . . . . . . . . . . 119
9.6.4. The enum Statement . . . . . . . . . . . . . . . . . 116 9.6.4. The enum Statement . . . . . . . . . . . . . . . . . 119
9.6.5. Usage Example . . . . . . . . . . . . . . . . . . . . 117 9.6.5. Usage Example . . . . . . . . . . . . . . . . . . . . 120
9.7. The bits Built-in Type . . . . . . . . . . . . . . . . . 118 9.7. The bits Built-in Type . . . . . . . . . . . . . . . . . 121
9.7.1. Restrictions . . . . . . . . . . . . . . . . . . . . 118 9.7.1. Restrictions . . . . . . . . . . . . . . . . . . . . 121
9.7.2. Lexicographic Representation . . . . . . . . . . . . 118 9.7.2. Lexicographic Representation . . . . . . . . . . . . 121
9.7.3. Canonical Form . . . . . . . . . . . . . . . . . . . 118 9.7.3. Canonical Form . . . . . . . . . . . . . . . . . . . 121
9.7.4. The bit Statement . . . . . . . . . . . . . . . . . . 118 9.7.4. The bit Statement . . . . . . . . . . . . . . . . . . 121
9.7.5. Usage Example . . . . . . . . . . . . . . . . . . . . 119 9.7.5. Usage Example . . . . . . . . . . . . . . . . . . . . 122
9.8. The binary Built-in Type . . . . . . . . . . . . . . . . 119 9.8. The binary Built-in Type . . . . . . . . . . . . . . . . 122
9.8.1. Restrictions . . . . . . . . . . . . . . . . . . . . 120 9.8.1. Restrictions . . . . . . . . . . . . . . . . . . . . 123
9.8.2. Lexicographic Representation . . . . . . . . . . . . 120 9.8.2. Lexicographic Representation . . . . . . . . . . . . 123
9.8.3. Canonical Form . . . . . . . . . . . . . . . . . . . 120 9.8.3. Canonical Form . . . . . . . . . . . . . . . . . . . 123
9.9. The leafref Built-in Type . . . . . . . . . . . . . . . . 120 9.9. The leafref Built-in Type . . . . . . . . . . . . . . . . 123
9.9.1. Restrictions . . . . . . . . . . . . . . . . . . . . 120 9.9.1. Restrictions . . . . . . . . . . . . . . . . . . . . 123
9.9.2. The path Statement . . . . . . . . . . . . . . . . . 120 9.9.2. The path Statement . . . . . . . . . . . . . . . . . 123
9.9.3. The require-instance Statement . . . . . . . . . . . 121 9.9.3. The require-instance Statement . . . . . . . . . . . 124
9.9.4. Lexicographic Representation . . . . . . . . . . . . 121 9.9.4. Lexicographic Representation . . . . . . . . . . . . 124
9.9.5. Canonical Form . . . . . . . . . . . . . . . . . . . 121 9.9.5. Canonical Form . . . . . . . . . . . . . . . . . . . 124
9.9.6. Usage Example . . . . . . . . . . . . . . . . . . . . 121 9.9.6. Usage Example . . . . . . . . . . . . . . . . . . . . 124
9.10. The identityref Built-in Type . . . . . . . . . . . . . . 124 9.10. The identityref Built-in Type . . . . . . . . . . . . . . 127
9.10.1. Restrictions . . . . . . . . . . . . . . . . . . . . 124 9.10.1. Restrictions . . . . . . . . . . . . . . . . . . . . 127
9.10.2. The identityref's base Statement . . . . . . . . . . 124 9.10.2. The identityref's base Statement . . . . . . . . . . 127
9.10.3. Lexicographic Representation . . . . . . . . . . . . 124 9.10.3. Lexicographic Representation . . . . . . . . . . . . 127
9.10.4. Canonical Form . . . . . . . . . . . . . . . . . . . 124 9.10.4. Canonical Form . . . . . . . . . . . . . . . . . . . 127
9.10.5. Usage Example . . . . . . . . . . . . . . . . . . . . 124 9.10.5. Usage Example . . . . . . . . . . . . . . . . . . . . 127
9.11. The empty Built-in Type . . . . . . . . . . . . . . . . . 125 9.11. The empty Built-in Type . . . . . . . . . . . . . . . . . 128
9.11.1. Restrictions . . . . . . . . . . . . . . . . . . . . 126 9.11.1. Restrictions . . . . . . . . . . . . . . . . . . . . 129
9.11.2. Lexicographic Representation . . . . . . . . . . . . 126 9.11.2. Lexicographic Representation . . . . . . . . . . . . 129
9.11.3. Canonical Form . . . . . . . . . . . . . . . . . . . 126 9.11.3. Canonical Form . . . . . . . . . . . . . . . . . . . 129
9.11.4. Usage Example . . . . . . . . . . . . . . . . . . . . 126 9.11.4. Usage Example . . . . . . . . . . . . . . . . . . . . 129
9.12. The union Built-in Type . . . . . . . . . . . . . . . . . 126 9.12. The union Built-in Type . . . . . . . . . . . . . . . . . 129
9.12.1. Restrictions . . . . . . . . . . . . . . . . . . . . 127 9.12.1. Restrictions . . . . . . . . . . . . . . . . . . . . 130
9.12.2. Lexicographic Representation . . . . . . . . . . . . 127 9.12.2. Lexicographic Representation . . . . . . . . . . . . 130
9.12.3. Canonical Form . . . . . . . . . . . . . . . . . . . 127 9.12.3. Canonical Form . . . . . . . . . . . . . . . . . . . 130
9.13. The instance-identifier Built-in Type . . . . . . . . . . 127 9.13. The instance-identifier Built-in Type . . . . . . . . . . 130
9.13.1. Restrictions . . . . . . . . . . . . . . . . . . . . 127 9.13.1. Restrictions . . . . . . . . . . . . . . . . . . . . 130
9.13.2. Lexicographic Representation . . . . . . . . . . . . 127 9.13.2. Lexicographic Representation . . . . . . . . . . . . 131
9.13.3. Canonical Form . . . . . . . . . . . . . . . . . . . 128 9.13.3. Canonical Form . . . . . . . . . . . . . . . . . . . 131
9.13.4. Usage Example . . . . . . . . . . . . . . . . . . . . 128 9.13.4. Usage Example . . . . . . . . . . . . . . . . . . . . 131
10. Updating a Module . . . . . . . . . . . . . . . . . . . . . . 129 10. Updating a Module . . . . . . . . . . . . . . . . . . . . . . 132
11. YIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 11. YIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
11.1. Formal YIN Definition . . . . . . . . . . . . . . . . . . 132 11.1. Formal YIN Definition . . . . . . . . . . . . . . . . . . 135
11.2. Transformation Algorithm YANG-2-YIN . . . . . . . . . . . 132 11.1.1. Usage Example . . . . . . . . . . . . . . . . . . . . 137
11.2.1. Usage Example . . . . . . . . . . . . . . . . . . . . 134 12. YANG ABNF Grammar . . . . . . . . . . . . . . . . . . . . . . 139
11.3. Transformation Algorithm YIN-2-YANG . . . . . . . . . . . 135 13. Error Responses for YANG Related Errors . . . . . . . . . . . 161
11.3.1. Tabulation, Formatting . . . . . . . . . . . . . . . 135 13.1. Error Message for Data that Violates a unique
12. YANG ABNF Grammar . . . . . . . . . . . . . . . . . . . . . . 136 Statement: . . . . . . . . . . . . . . . . . . . . . . . 161
13. Error Responses for YANG Related Errors . . . . . . . . . . . 158 13.2. Error Message for Data that Violates a max-elements
13.1. Error Message for Data that Violates a YANG unique Statement: . . . . . . . . . . . . . . . . . . . . . . . 161
Statement: . . . . . . . . . . . . . . . . . . . . . . . 158 13.3. Error Message for Data that Violates a min-elements
13.2. Error Message for Data that Violates a YANG Statement: . . . . . . . . . . . . . . . . . . . . . . . 161
max-elements Statement: . . . . . . . . . . . . . . . . . 158 13.4. Error Message for Data that Violates a must statement: . 162
13.3. Error Message for Data that Violates a YANG 13.5. Error Message for Data that Violates a
min-elements Statement: . . . . . . . . . . . . . . . . . 158 require-instance statement: . . . . . . . . . . . . . . . 162
13.4. Error Message for Data that Violates a YANG must 13.6. Error Message for Data that Violates a mandatory
statement: . . . . . . . . . . . . . . . . . . . . . . . 159 choice statement: . . . . . . . . . . . . . . . . . . . . 162
13.5. Error Message for the "insert" Operation . . . . . . . . 159 13.7. Error Message for the "insert" Operation . . . . . . . . 162
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 160 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 163
15. Security Considerations . . . . . . . . . . . . . . . . . . . 161 15. Security Considerations . . . . . . . . . . . . . . . . . . . 164
16. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 162 16. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 165
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 163 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 166
17.1. Normative References . . . . . . . . . . . . . . . . . . 163 17.1. Normative References . . . . . . . . . . . . . . . . . . 166
17.2. Non-Normative References . . . . . . . . . . . . . . . . 164 17.2. Non-Normative References . . . . . . . . . . . . . . . . 167
Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . 165 Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . 168
A.1. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 165 A.1. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 168
A.2. Version -02 . . . . . . . . . . . . . . . . . . . . . . . 165 A.2. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 168
A.3. Version -01 . . . . . . . . . . . . . . . . . . . . . . . 165 A.3. Version -02 . . . . . . . . . . . . . . . . . . . . . . . 169
A.4. Version -00 . . . . . . . . . . . . . . . . . . . . . . . 166 A.4. Version -01 . . . . . . . . . . . . . . . . . . . . . . . 169
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 168 A.5. Version -00 . . . . . . . . . . . . . . . . . . . . . . . 170
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 171
1. Introduction 1. Introduction
Today, the NETCONF protocol [RFC4741] lacks a standardized way to Today, the NETCONF protocol [RFC4741] lacks a standardized way to
create data models. Instead, vendors are forced to use proprietary create data models. Instead, vendors are forced to use proprietary
solutions. In order for NETCONF to be a interoperable protocol, solutions. In order for NETCONF to be a interoperable protocol,
models must be defined in a vendor-neutral way. YANG provides the models must be defined in a vendor-neutral way. YANG provides the
language and rules for defining such models for use with NETCONF. 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
skipping to change at page 27, line 33 skipping to change at page 27, line 33
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:
o For a module to reference definitions in an external module, the o For a module or submodule to reference definitions in an external
external module MUST be imported. module, the external module MUST be imported.
o For a module to reference definitions in one of its submodules, o For a module to reference definitions in one of its submodules,
the module MUST include the submodule. the module MUST include the submodule.
o For a submodule to reference definitions in a second submodule of o For a submodule to reference definitions in a second submodule of
the same module, the first submodule MUST include the second the same module, the first submodule MUST include the second
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
skipping to change at page 28, line 36 skipping to change at page 28, line 36
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 a;
revision 2008-01-01; revision-date 2008-01-01;
} }
container bee { container bee {
uses a:a; uses a: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 "a" 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> element. The top-level nodes of YANG modules are encoded as
skipping to change at page 29, line 43 skipping to change at page 29, line 43
<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, with the name of the file on the form: or submodule per file. The name of the file SHOULD be on the form:
module-or-submodule-name ['.' revision-number] ( '.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.
5.3. XML Namespaces 5.3. XML Namespaces
skipping to change at page 33, line 25 skipping to change at page 33, line 25
The namespace URI is advertised as a capability in the NETCONF The namespace URI is advertised as a capability in the NETCONF
<hello> message to indicate support for the YANG module by a NETCONF <hello> message to indicate support for the YANG module by a NETCONF
server. The capability URI advertised MUST be on the form: server. The capability URI advertised MUST be on the form:
capability-string = namespace-uri [ parameter-list ] capability-string = namespace-uri [ parameter-list ]
parameter-list = "?" parameter *( "&" parameter ) parameter-list = "?" parameter *( "&" parameter )
parameter = revision-parameter / parameter = revision-parameter /
module-parameter / module-parameter /
feature-parameter / feature-parameter /
deviation-parameter deviation-parameter
revision-parameter = "revision=" revision-number revision-parameter = "revision=" revision-date
module-parameter = "module=" module-name module-parameter = "module=" module-name
feature-parameter = "features=" feature *( "," feature ) feature-parameter = "features=" feature *( "," feature )
deviation-parameter = "deviations=" deviation *( "," deviation ) deviation-parameter = "deviations=" deviation *( "," deviation )
Where "revision-number" 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).
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 are not advertised in the notifications, or deviations to the device MAY be advertised in the
<hello> message. <hello> message.
For example, this <hello> message advertises one module "my-syslog". For example, this <hello> message advertises one module "syslog".
<hello> <hello>
<capability> <capability>
http://example.com/syslog?module=my-syslog&revision=2008-04-01 http://example.com/syslog?module=syslog&revision=2008-04-01
</capability> </capability>
</hello> </hello>
5.6.4.2. Features 5.6.4.2. Features
Devices indicate the names of supported features via the <hello> Devices indicate the names of supported features via the <hello>
message. In hello messages, the features are encoded in the message. In hello messages, the features are encoded in the
"features" parameter within the URI. The value of this parameter is "features" parameter within the URI. The value of this parameter is
a comma-separated list of feature names which the device supports for a comma-separated list of feature names which the device supports for
the specific module. the specific module.
For example, this <hello> message advertises one module, informing For example, this <hello> message advertises one module, informing
the client that it supports the "local-storage" feature of module the client that it supports the "local-storage" feature of module
"my-syslog". "syslog".
<hello> <hello>
<capability> <capability>
http://example.com/syslog?module=my-syslog&features=local-storage http://example.com/syslog?module=syslog&features=local-storage
</capability> </capability>
</hello> </hello>
5.6.4.3. Deviations 5.6.4.3. Deviations
Device deviations are announced via the "deviations" parameter. The Device deviations are announced via the "deviations" parameter. The
value of the deviations parameter is a comma-separated list of value of the deviations parameter is a comma-separated list of
modules containing deviations from the capability's module. modules containing deviations from the capability's module.
For example, this <hello> message advertises two modules, informing For example, this <hello> message advertises two modules, informing
the client that it deviates from module "my-syslog" according to the the client that it deviates from module "syslog" according to the
deviations listed in the module "my-devs". deviations listed in the module "my-devs".
<hello> <hello>
<capability> <capability>
http://example.com/syslog?module=my-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 5.6.5. Mapping to the NETCONF Schema Discovery Mechanism
+--------------------------------------------------------------+ +--------------------------------------------------------------+
| Open Question | | Open Question |
skipping to change at page 40, line 5 skipping to change at page 39, line 50
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 with the namespace of the current module defined as the null
namespace. References to identifiers in external modules MUST be namespace. References to identifiers in external modules MUST be
qualified with appropriate prefixes, and references to the current qualified with appropriate prefixes, and references to the current
module and its submodules MAY use a prefix. module and its submodules MAY use a prefix.
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
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.
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 43, line 44 skipping to change at page 44, line 44
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.
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" is present, any typedef, grouping, When the optional "revision-date" substatement is present, any
extension, feature, and identity referenced by definitions in the typedef, grouping, extension, feature, and identity referenced by
local module are taken from the specified revision of the imported definitions in the local module are taken from the specified revision
module. of the imported module.
It is an error to import multiple revisions of the same module.
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 | 7.1.9 | 0..1 | | revision-date | 7.1.5.1 | 0..1 |
+--------------+---------+-------------+ +---------------+---------+-------------+
7.1.5.1. The import's revision-date Statement
The import's "revision-date" statement is used to specify the exact
version of the module to import. The "revision-date" statement MUST
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 the 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).
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" is present, the specified revision of When the optional "revision-date" is present, the specified revision
the submodule is included in the module. of the submodule is included in the module.
It is an error to include multiple revisions of the same submodule.
The includes's Substatements The includes's Substatements
+--------------+---------+-------------+ +---------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+---------+-------------+ +---------------+---------+-------------+
| revision | 7.1.9 | 0..1 | | revision-date | 7.1.5.1 | 0..1 |
+--------------+---------+-------------+ +---------------+---------+-------------+
7.1.7. The organization Statement 7.1.7. The organization Statement
The "organization" statement defines the party responsible for this The "organization" statement defines the party responsible for this
module. The argument is a string which is used to specify a textual module. The argument is a string which is used to specify a textual
description of the organization(s) under whose auspices this module description of the organization(s) under whose auspices this module
was developed. was developed.
7.1.8. The contact Statement 7.1.8. The contact Statement
skipping to change at page 46, line 11 skipping to change at page 47, line 11
+--------------+---------+-------------+ +--------------+---------+-------------+
| description | 7.19.3 | 0..1 | | description | 7.19.3 | 0..1 |
+--------------+---------+-------------+ +--------------+---------+-------------+
7.1.10. Usage Example 7.1.10. Usage Example
module acme-system { module acme-system {
namespace "http://acme.example.com/system"; namespace "http://acme.example.com/system";
prefix "acme"; prefix "acme";
import yang-types { import ietf-yang-types {
prefix "yang"; prefix "yang";
} }
include acme-types; include acme-types;
organization "ACME Inc."; organization "ACME Inc.";
contact contact
"Joe L. User "Joe L. User
ACME, Inc. ACME, Inc.
skipping to change at page 49, line 21 skipping to change at page 50, line 21
+--------------+---------+-------------+ +--------------+---------+-------------+
7.2.3. Usage Example 7.2.3. Usage Example
submodule acme-types { submodule acme-types {
belongs-to "acme-system" { belongs-to "acme-system" {
prefix "acme"; prefix "acme";
} }
import yang-types { import ietf-yang-types {
prefix "yang"; prefix "yang";
} }
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
skipping to change at page 53, line 11 skipping to change at page 54, line 11
The "presence" statement (see Section 7.5.5) is used to give The "presence" statement (see Section 7.5.5) is used to give
semantics to the existence of the container in the data tree. semantics to the existence of the container in the data tree.
7.5.2. The container's Substatements 7.5.2. The container's Substatements
+--------------+---------+-------------+ +--------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+---------+-------------+ +--------------+---------+-------------+
| anyxml | 7.10 | 0..n | | anyxml | 7.10 | 0..n |
| augment | 7.15 | 0..n |
| choice | 7.9 | 0..n | | choice | 7.9 | 0..n |
| config | 7.19.1 | 0..1 | | config | 7.19.1 | 0..1 |
| container | 7.5 | 0..n | | container | 7.5 | 0..n |
| description | 7.19.3 | 0..1 | | description | 7.19.3 | 0..1 |
| grouping | 7.11 | 0..n | | grouping | 7.11 | 0..n |
| 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 |
| must | 7.5.3 | 0..n | | must | 7.5.3 | 0..n |
skipping to change at page 59, line 44 skipping to change at page 60, line 44
The value of the "default" statement MUST be valid according to the The value of the "default" statement MUST be valid according to the
type specified in the leaf's "type" statement. type specified in the leaf's "type" statement.
The "default" statement MUST NOT be present on nodes where The "default" statement MUST NOT be present on nodes where
"mandatory" is true. "mandatory" is true.
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". If not specified, the default is the string "true" or "false", and puts a constraint on valid data.
"false". If not specified, the default is "false".
If "mandatory" is "true", the node MUST exist if its parent node If "mandatory" is "true", the behavior of the constraint depends on
exists. This constraint is enforced according to the rules in the type of the leaf's closest ancestor node in the schema tree which
Section 8. is not a presence container (see Section 7.5.1):
Containers without a "presence" statement are ignored when performing o If this ancestor is a case node, the leaf MUST exist if any other
mandatory tests for leafs. A mandatory leaf within such a container node from the case exists.
is mandatory even if the container's data node does not exist.
o Otherwise, the leaf MUST exist if the ancestor node exists.
This constraint is enforced according to the rules in Section 8.
7.6.5. XML Encoding Rules 7.6.5. XML Encoding 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.
skipping to change at page 63, line 28 skipping to change at page 64, 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 always has at least min-elements entries. A valid leaf-list or list MUST have 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 "min-elements" constraint is enforced according to the rules in 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
presence container (see Section 7.5.1):
o If this ancestor is a case node, the constraint is enforced if any
other node from the case exists.
o Otherwise, it is enforced if the ancestor node exists.
The constraint is further enforced according to the rules in
Section 8. Section 8.
7.7.4. The max-elements Statement 7.7.4. The max-elements Statement
The "max-elements" statement, which is optional, takes as an argument The "max-elements" statement, which is optional, takes as an argument
a positive integer or the string "unbounded", which puts a constraint a positive integer or the string "unbounded", which puts a constraint
on valid list entries. A valid leaf-list or list always has at most on valid list entries. A valid leaf-list or list always has at most
max-elements entries. max-elements entries.
If no "max-elements" statement is present, it defaults to If no "max-elements" statement is present, it defaults to
skipping to change at page 68, line 4 skipping to change at page 69, line 6
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.
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 |
| augment | 7.15 | 0..n |
| choice | 7.9 | 0..n | | choice | 7.9 | 0..n |
| config | 7.19.1 | 0..1 | | config | 7.19.1 | 0..1 |
| container | 7.5 | 0..n | | container | 7.5 | 0..n |
| description | 7.19.3 | 0..1 | | description | 7.19.3 | 0..1 |
| grouping | 7.11 | 0..n | | grouping | 7.11 | 0..n |
| if-feature | 7.18.2 | 0..n | | if-feature | 7.18.2 | 0..n |
| key | 7.8.2 | 0..1 | | key | 7.8.2 | 0..1 |
| 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 |
skipping to change at page 69, line 21 skipping to change at page 70, line 21
entries. It takes as an argument a string which contains a space entries. It takes as an argument a string which contains a space
separated list of schema node identifiers, which MUST be given in the separated list of schema node identifiers, which MUST be given in the
descendant form (see the rule "descendant-schema-nodeid" in descendant form (see the rule "descendant-schema-nodeid" in
Section 12). Each such schema node identifier MUST refer to a leaf. Section 12). Each such schema node identifier MUST refer to a leaf.
If one of the referenced leafs represents configuration data, then If one of the referenced leafs represents configuration data, then
all of the referenced leafs MUST represent configuration data. all of the referenced leafs MUST represent configuration data.
The "unique" constraint specifies that the combined values of all the The "unique" constraint specifies that the combined values of all the
leaf instances specified in the argument string, including leafs with leaf instances specified in the argument string, including leafs with
default values, MUST be unique within all list entry instances. The default values, MUST be unique within all list entry instances in
constraint is enforced according to the rules in Section 8. which all referenced leafs exist. The constraint is enforced
according to the rules in Section 8.
The unique string syntax is formally defined by the rule "unique-arg" The unique string syntax is formally defined by the rule "unique-arg"
in Section 12. in Section 12.
7.8.3.1. Usage Example 7.8.3.1. Usage Example
With the following list: With the following list:
list server { list server {
key "name"; key "name";
skipping to change at page 70, line 17 skipping to change at page 71, line 17
<ip>192.0.2.1</ip> <ip>192.0.2.1</ip>
<port>25</port> <port>25</port>
</server> </server>
<server> <server>
<name>http</name> <name>http</name>
<ip>192.0.2.1</ip> <ip>192.0.2.1</ip>
<port>25</port> <port>25</port>
</server> </server>
The following configuration is valid, since the "http" and "ftp" list
entries do not have a value for all referenced leafs, and are thus
not taken into account when the "unique" constraint is enforced:
<server>
<name>smtp</name>
<ip>192.0.2.1</ip>
<port>25</port>
</server>
<server>
<name>http</name>
<ip>192.0.2.1</ip>
</server>
<server>
<name>ftp</name>
<ip>192.0.2.1</ip>
</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 and "choice" statements can be used to define child nodes to the
list. list.
7.8.5. XML Encoding Rules 7.8.5. XML Encoding 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
skipping to change at page 76, line 27 skipping to change at page 78, line 11
} }
The case identifier MUST be unique within a choice. The case identifier MUST be unique within a choice.
7.9.2.1. The case's Substatements 7.9.2.1. The case's Substatements
+--------------+---------+-------------+ +--------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+---------+-------------+ +--------------+---------+-------------+
| anyxml | 7.10 | 0..n | | anyxml | 7.10 | 0..n |
| augment | 7.15 | 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 |
skipping to change at page 78, line 8 skipping to change at page 79, line 36
leaf manual { leaf manual {
type empty; type empty;
} }
} }
} }
} }
7.9.4. The choice's mandatory Statement 7.9.4. The choice'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". If "mandatory" is "true", at least one the string "true" or "false", and puts a constraint on valid data.
node from exactly one of the choice's case branches MUST exist. This If "mandatory" is "true", at least one node from exactly one of the
constraint is enforced according to the rules in Section 8. choice's case branches MUST exist.
If not specified, the default is "false". If not specified, the default is "false".
The behavior of the constraint depends on the type of the choice's
closest ancestor node in the schema tree which is not a presence
container (see Section 7.5.1):
o If this ancestor is a case node, the constraint is enforced if any
other node from the case exists.
o Otherwise, it is enforced if the ancestor node exists.
The constraint is further enforced according to the rules in
Section 8.
7.9.5. XML Encoding Rules 7.9.5. XML Encoding 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 choices 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
skipping to change at page 82, line 14 skipping to change at page 84, line 14
and extension usage are evaluated in the hierarchy where the grouping and extension usage are evaluated in the hierarchy where the grouping
statement appears. For extensions, this means that extensions are statement appears. For extensions, this means that extensions are
applied to the grouping node, not the use node. applied to the grouping node, not the use 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 |
| augment | 7.15 | 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 |
| 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 |
| 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.11.2. Usage Example 7.11.2. Usage Example
import inet-types { import ietf-inet-types {
prefix "inet"; prefix "inet";
} }
grouping address { grouping address {
description "A reusable address group."; description "A reusable address group.";
leaf ip { leaf ip {
type inet:ip-address; type inet:ip-address;
} }
leaf port { leaf port {
type inet:port-number; type inet:port-number;
skipping to change at page 87, line 11 skipping to change at page 89, line 11
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.
7.13.2.1. The input's Substatements 7.13.2.1. The input's Substatements
+--------------+---------+-------------+ +--------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+---------+-------------+ +--------------+---------+-------------+
| anyxml | 7.10 | 0..n | | anyxml | 7.10 | 0..n |
| augment | 7.15 | 0..n |
| 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 |
+--------------+---------+-------------+ +--------------+---------+-------------+
skipping to change at page 88, line 11 skipping to change at page 90, line 11
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.
7.13.3.1. The output's Substatements 7.13.3.1. The output's Substatements
+--------------+---------+-------------+ +--------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+---------+-------------+ +--------------+---------+-------------+
| anyxml | 7.10 | 0..n | | anyxml | 7.10 | 0..n |
| augment | 7.15 | 0..n |
| 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 |
+--------------+---------+-------------+ +--------------+---------+-------------+
skipping to change at page 90, line 11 skipping to change at page 92, line 11
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 |
+--------------+---------+-------------+ +--------------+---------+-------------+
| anyxml | 7.10 | 0..n | | anyxml | 7.10 | 0..n |
| augment | 7.15 | 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 |
| grouping | 7.11 | 0..n | | grouping | 7.11 | 0..n |
| 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 |
skipping to change at page 91, line 38 skipping to change at page 93, line 38
<reporting-entity> <reporting-entity>
<card>Ethernet0</card> <card>Ethernet0</card>
</reporting-entity> </reporting-entity>
<severity>major</severity> <severity>major</severity>
</event> </event>
</notification> </notification>
7.15. The augment Statement 7.15. The augment Statement
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 another module or submodule. The argument is schema tree defined in another module or submodule, and to add to the
a string which identifies a node in the schema tree. This node is nodes from a grouping in a "uses" statement. The argument is a
string which identifies a node in the schema tree. This node is
called the augment's target node. The target node MUST be either a called the augment's target node. The target node MUST be either a
container, list, choice, case, input, output, or notification node. container, list, choice, case, input, output, or notification node.
It is augmented with the nodes defined in the substatements that It is augmented with the nodes defined in the substatements that
follow the "augment" statement. 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
formally defined by the rule "augment-arg" in Section 12. If the formally defined by the rule "augment-arg" in Section 12. If the
"augment" statement is on the top-level in a module or submodule, the "augment" statement is on the top-level in a module or submodule, the
absolute form (defined by the rule "absolute-schema-nodeid" in absolute form (defined by the rule "absolute-schema-nodeid" in
Section 12) of a schema node identifier MUST be used. If the Section 12) of a schema node identifier MUST be used. If the
skipping to change at page 92, line 26 skipping to change at page 94, line 27
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).
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 |
| augment | 7.15 | 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 |
skipping to change at page 99, line 17 skipping to change at page 101, line 17
name is used by the "if-feature" statement to tie the schema nodes to name is used by the "if-feature" statement to tie the schema nodes to
the feature. the feature.
In this example, a feature called "local-storage" represents the In this example, a feature called "local-storage" represents the
ability for a device to store syslog messages on local storage of ability for a device to store syslog messages on local storage of
some sort. This feature is used to make the "local-storage-limit" some sort. This feature is used to make the "local-storage-limit"
leaf conditional on the presence of some sort of local-storage. If leaf conditional on the presence of some sort of local-storage. If
the device does not report that it supports this feature, the local- the device does not report that it supports this feature, the local-
storage-limit node is not supported. storage-limit node is not supported.
module my-syslog { module syslog {
... ...
feature local-storage { feature local-storage {
description description
"This feature means the device supports local "This feature means the device supports local
storage (memory, flash or disk) that can be used to storage (memory, flash or disk) that can be used to
store syslog messages."; store syslog messages.";
} }
container syslog { container syslog {
leaf local-storage-limit { leaf local-storage-limit {
skipping to change at page 100, line 18 skipping to change at page 102, line 18
| 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 |
+--------------+---------+-------------+ +--------------+---------+-------------+
7.18.2. The if-feature Statement 7.18.2. The if-feature Statement
The "if-feature" statement is used to mark portions of the model as The "if-feature" statement makes its parent statement conditional.
conditional. The argument is the name of a feature, as defined by a The argument is the name of a feature, as defined by a "feature"
"feature" statement. If a prefix is present on the feature name, it statement. The parent statement is implemented by servers that
support this feature. If a prefix is present on the feature name, it
refers to a feature defined the module which was imported with that refers to a feature defined the module which was imported with that
prefix, or the local module if the prefix matches the local module's prefix, or the local module if the prefix matches the local module's
prefix. Otherwise a feature with the matching name MUST be defined prefix. Otherwise a feature with the matching name MUST be defined
in the current module or an included submodule. in the current module or an included submodule.
Since submodules cannot include the parent module, any features in Since submodules cannot include the parent module, any features in
the module which need to be exposed to submodules MUST be defined in the module which need to be exposed to submodules MUST be defined in
a submodule. Submodules can then include this submodule to find the a submodule. Submodules can then include this submodule to find the
definition of the feature. definition of the feature.
skipping to change at page 103, line 21 skipping to change at page 105, line 21
7.19. Common Statements 7.19. Common Statements
This section defines sub-statements common to several other This section defines sub-statements common to several other
statements. statements.
7.19.1. The config Statement 7.19.1. The config Statement
The "config" statement takes as an argument the string "true" or The "config" statement takes as an argument the string "true" or
"false". If "config" is "true", the definition represents "false". If "config" is "true", the definition represents
configuration, and will be part of the reply to a <get-config> configuration. Data nodes representing configuration will be part of
request, and may be sent in a <copy-config> or <edit-config> request. the reply to a <get-config> request, and can be sent in a <copy-
If "config" is "false", it represents state data, and will be part of config> or <edit-config> request.
the reply to a <get>, but not to a <get-config> request.
If "config" is "false", the definition represents state data. Data
nodes representing state data will be part of the reply to a <get>,
but not to a <get-config> request.
If "config" is not specified, the default is the same as the parent If "config" is not specified, the default is the same as the parent
node's (in the data model) "config" value. If the top node does not schema node's "config" value. If the parent node is a "case" node,
specify a "config" statement, the default is "true". the value is the same as the "case" node's parent "choice" node.
If the top node does not specify a "config" statement, the default is
"true".
If a node has "config" "false", no node underneath it can have If a node has "config" "false", no node underneath it can have
"config" set to "true". "config" set to "true".
7.19.2. The status Statement 7.19.2. The status Statement
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.
skipping to change at page 104, line 23 skipping to change at page 106, line 28
7.19.4. The reference Statement 7.19.4. The reference Statement
The "reference" statement takes as an argument a string which is used The "reference" statement takes as an argument a string which is used
to specify a textual cross-reference to an external document, either to specify a textual cross-reference to an external document, either
another module which defines related management information, or a another module which defines related management information, or a
document which provides additional information relevant to this document which provides additional information relevant to this
definition. definition.
7.19.5. The when Statement 7.19.5. The when Statement
The "when" statement allows a data definition statement to be The "when" statement makes its parent data definition statement
conditional, with the node(s) defined by the data definition conditional. The node defined by the parent data definition
statement only being valid when a specific criteria is satisfied. statement is only valid when the condition specified by the "when"
The statement's argument is an XPath expression, which is used to statement is satisfied. The statement's argument is an XPath
formally specify this criteria. If the XPath expression conceptually expression, which is used to formally specify this condition. If the
evaluates to "true" for a particular instance, then the nodes defined XPath expression conceptually evaluates to "true" for a particular
by the data definition statement are valid, otherwise they are not. instance, then the node defined by the parent data definition
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:
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
skipping to change at page 106, line 31 skipping to change at page 109, line 31
o If the constraint is defined on RPC input parameters, it MUST be o If the constraint is defined on RPC input parameters, it MUST be
true in an invocation of the RPC method. true in an invocation of the RPC method.
o If the constraint is defined on RPC output parameters, it MUST be o If the constraint is defined on RPC output parameters, it MUST be
true in the RPC reply. true in the RPC reply.
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" and "mandatory" natural consequence of the hierarchy of nodes. "must", "mandatory",
constraints are not enforced if the parent node has a "when" or "if- "min-elements", and "max-elements" constraints are not enforced if
feature" property that is not satisfied on the current device. the parent node has a "when" or "if-feature" property that is not
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 the "has-gps" feature:
container location { container location {
if-feature has-gps; if-feature has-gps;
leaf longitude { leaf longitude {
mandatory true; mandatory true;
... ...
} }
skipping to change at page 107, line 19 skipping to change at page 110, line 19
o during validation o during validation
Each of these scenarios are considered in the following sections. Each of these scenarios are considered in the following sections.
8.3.1. Payload Parsing 8.3.1. Payload Parsing
When content arrives in RPC payloads, it MUST be well-formed and When content arrives in RPC payloads, it MUST be well-formed and
valid XML, following the hierarchy and content rules defined by the valid XML, following the hierarchy and content rules defined by the
set of models the device implements. set of models the device implements.
o Leaf data values MUST match the type constraints for those leafs, o If a leaf data value does not match the type constraints for the
including those defined in the type's range, length, and pattern leaf, including those defined in the type's range, length, and
properties. pattern properties, the server MUST reply with an 'invalid-value'
error-tag in the rpc-error, and with the error-app-tag and error-
message assoicated with the constraint, if any exist.
o Key data MUST be present for all list instances. 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.
o Only data for a single case MUST be present for any choices. 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.
o Data for nodes tagged with "if-feature" MUST NOT be present if the o If data for a node tagged with "if-feature" is present, and the
feature is not supported by the device. feature is not supported by the device, the server MUST reply with
an 'unknown-element' error-tag in the rpc-error.
o Data for nodes tagged with "when" MUST NOT be present if the o If data for a node tagged with "when" is present, and the "when"
condition does not evaluate to "true". condition evaluates to "false", the server MUST reply with an
'unknown-element' error-tag in the rpc-error.
o For insert handling, the value for the attributes "before" and o For insert handling, if the value for the attributes "before" and
"after" MUST be 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-
error.
o The attributes "before" and "after" MUST NOT appear for lists o If the attributes "before" and "after" appears in any element that
whose "ordered-by" property is "system". is not a list whose "ordered-by" property is "user", the server
MUST reply with an 'unkown-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 111, line 27 skipping to change at page 114, line 27
The "range" statement, which is an optional substatement to the The "range" statement, which is an optional substatement to the
"type" statement, takes as an argument a range expression string. It "type" statement, takes as an argument a range expression string. It
is used to restrict integer and floating point built-in types, or is used to restrict integer and floating point built-in types, or
types derived from those. types derived from those.
A range consists of an explicit value, or a lower inclusive bound, A range consists of an explicit value, or a lower inclusive bound,
two consecutive dots "..", and an upper inclusive bound. Multiple two consecutive dots "..", and an upper inclusive bound. Multiple
values or ranges can be given, separated by "|". If multiple values values or ranges can be given, separated by "|". If multiple values
or ranges are given they all MUST be disjoint and MUST be in or ranges are given they all MUST be disjoint and MUST be in
ascending order. If a value restriction is applied to an already ascending order. If a range restriction is applied to an already
restricted type, the new restriction MUST be equal or more limiting, range restricted type, the new restriction MUST be equal or more
that is raising the lower bounds, reducing the upper bounds, removing limiting, that is raising the lower bounds, reducing the upper
explicit values or ranges, or splitting ranges into multiple ranges bounds, removing explicit values or ranges, or splitting ranges into
with intermediate gaps. Each explicit value and range boundary value multiple ranges with intermediate gaps. Each explicit value and
given in the range expression MUST match the type being restricted, range boundary value given in the range expression MUST match the
or be one of the special values "min" or "max". "min" and "max" means type being restricted, or be one of the special values "min" or
the minimum and maximum value accepted for the type being restricted, "max". "min" and "max" means the minimum and maximum value accepted
respectively. for the type being restricted, respectively.
The range expression syntax is formally defined by the rule "range- The range expression syntax is formally defined by the rule "range-
arg" in Section 12. arg" in Section 12.
9.2.4.1. The range's Substatements 9.2.4.1. The range's Substatements
+---------------+---------+-------------+ +---------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+---------------+---------+-------------+ +---------------+---------+-------------+
| description | 7.19.3 | 0..1 | | description | 7.19.3 | 0..1 |
skipping to change at page 115, line 16 skipping to change at page 118, line 16
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. AND:ed together, i.e. all such expressions have to match.
If a pattern restriction is applied to an already pattern restricted
type, values must match all patterns in the base type, in addition to
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 |
+---------------+---------+-------------+ +---------------+---------+-------------+
| description | 7.19.3 | 0..1 | | description | 7.19.3 | 0..1 |
| error-app-tag | 7.5.4.2 | 0..1 | | error-app-tag | 7.5.4.2 | 0..1 |
| error-message | 7.5.4.1 | 0..1 | | error-message | 7.5.4.1 | 0..1 |
| reference | 7.19.4 | 0..1 | | reference | 7.19.4 | 0..1 |
+---------------+---------+-------------+ +---------------+---------+-------------+
skipping to change at page 123, line 7 skipping to change at page 126, line 7
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>
<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>
<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 notification defines two leafrefs to refer to an The following notification defines two leafrefs to refer to an
existing ifIndex: existing ifIndex:
notification link-failure { notification link-failure {
leaf if-name { leaf if-name {
type leafref {
path "/interfaces/interface/name"; path "/interfaces/interface/name";
} }
}
leaf index { leaf index {
path "/interfaces/interface[name = current()/../if-name]" type leafref {
path
"/interfaces/interface[name = current()/../if-name]"
+ "/ifIndex"; + "/ifIndex";
} }
} }
}
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> <index>2</index>
</link-failure> </link-failure>
skipping to change at page 127, line 29 skipping to change at page 130, line 29
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. syntax, which is used to uniquely identify a node in the data tree.
It is an absolute XPath location path in abbreviated syntax, where It is an absolute XPath location path in abbreviated syntax, where
axes are not permitted, and predicates are used only for specifying axes are not permitted, and predicates are used only for specifying
the values for the key nodes for list entries, or a value of a leaf- the values for the key nodes for list entries, a value of a leaf-list
list. Each predicate consists of one equality test per key. Each entry, or a positional index for list without keys. For identifying
key MUST have a corresponding predicate. list entries with keys, each predicate consists of one equality test
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.9.3) 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 "absolute-instid" in The syntax is formally defined by the rule "instance-identifier" in
Section 12. Section 12.
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.9.3).
9.13.2. Lexicographic Representation 9.13.2. Lexicographic Representation
An instance-identifier value is lexicographically represented as a An instance-identifier value is lexicographically represented as a
skipping to change at page 128, line 20 skipping to change at page 131, line 25
9.13.3. Canonical Form 9.13.3. 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.4. Usage Example
The following are examples of instance identifiers: The following are examples of instance identifiers:
/* instance-identifier for a container */
/ex:system/ex:services/ex:ssh
/* 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 */
/ex:system/ex:user[ex:name='fred'] /ex:system/ex:user[ex:name='fred']
/* instance-identifier for a leaf in a list entry */
/ex:system/ex:user[ex:name='fred']/ex:type /ex:system/ex:user[ex:name='fred']/ex:type
/* instance-identifier for a list entry with two keys */
/ex:system/ex:server[ex:ip='192.0.2.1'][ex:port='80'] /ex:system/ex:server[ex:ip='192.0.2.1'][ex:port='80']
/* instance-identifier for a leaf-list entry */
/ex:system/ex:services/ex:ssh/ex:cipher[.='blowfish-cbc'] /ex:system/ex:services/ex:ssh/ex:cipher[.='blowfish-cbc']
/* instance-identifier for a list entry without keys */
/ex:stats/ex:port[3]
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.
skipping to change at page 132, line 19 skipping to change at page 135, line 19
the two formats. the two formats.
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 YANG-2-YIN and the YIN-2-YANG transformations will not modify the The mapping between YANG and YIN does not modify the information
information content of the model. content of the model. Comments and whitespaces are not preserved.
11.1. Formal YIN Definition 11.1. Formal YIN Definition
YIN is described by an algorithm that transforms YANG to 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
corresponding YANG keyword. This means in particular that the
document element (root) of a YIN document is always <module> or
<submodule>.
11.2. Transformation Algorithm YANG-2-YIN YIN elements corresponding to the core YANG keywords belong to the
namespace whose associated URI is
"urn:ietf:params:xml:ns:yang:yin:1". [XXX IANA].
Every keyword results in a new XML element. The name of the element YIN elements corresponding to extension keywords belong to the
is the keyword. All core YANG elements are defined in the namespace namespace of the YANG module where the extension keyword is declared
"urn:ietf:params:xml:ns:yang:yin:1". [XXX IANA] via the "extension" statement.
The top-level element is always <module> or <submodule>. The names of all YIN elements MUST be properly qualified with their
namespaces specified above using the standard mechanisms of
[XML-NAMES], i.e. "xmlns" and "xmlns:xxx" attributes.
Elements which represent keywords that are imported extensions from The argument of a YANG statement is encoded in YIN either as an XML
other modules MUST be properly namespace qualified, where the attribute or a subelement of the keyword element. Table 1 defines
namespace is the namespace of the imported module. The XML prefix the encoding for the set of core YANG keywords. For extensions, the
for such extensions MUST be the same as the prefix defined in the argument encoding is specified within the "extension" statement (see
module's "import" statement. Section 7.17). The following rules hold for arguments of both core
and extension statements:
Elements which represent keywords that are included extensions from o If the argument is encoded as an attribute, this attribute has no
other submodules MUST be properly namespace qualified, where the namespace.
namespace is the namespace of the module that the submodule belongs
to. The XML prefix for such extensions MUST be the same as the local
prefix, i.e. for a module it is as defined in the "prefix" statement,
and for a submodule, as defined in the submodule's "belongs-to"
statement.
If the keyword has an argument, its encoding depends on the value of o If the argument is encoded as an element, it is placed to the same
the argument's "yin-element". If "yin-element" is false, the namespace as its parent keyword element.
argument is encoded as an XML attribute to the keyword's element. If
"yin-element" is true, the argument is encoded as a subelement to the
keyword's element. The name of the attribute or element is the name
of the argument.
The core YANG keywords have arguments according to the table below. o If the argument is encoded as an element, it MUST be the first
Extension keywords have arguments according to Section 7.17.2. child of the keyword element.
YANG to YIN keyword map Substatements of a YANG statement are encoded as (additional)
children of the keyword element and their relative order MUST be the
same as the order of substatements in YANG.
Comments in YANG MAY be mapped to XML comments.
Mapping of arguments of the core YANG statements.
+------------------+---------------+-------------+ +------------------+---------------+-------------+
| keyword | argument name | yin-element | | keyword | argument name | yin-element |
+------------------+---------------+-------------+ +------------------+---------------+-------------+
| anyxml | name | false | | anyxml | name | false |
| argument | name | false | | argument | name | false |
| augment | target-node | false | | augment | target-node | false |
| base | name | false | | base | name | false |
| belongs-to | module | false | | belongs-to | module | false |
| bit | name | false | | bit | name | false |
skipping to change at page 134, line 17 skipping to change at page 137, line 24
| path | value | false | | path | value | false |
| pattern | value | false | | pattern | value | false |
| position | value | false | | position | value | false |
| prefix | value | false | | prefix | value | false |
| presence | value | false | | presence | value | false |
| range | value | false | | range | value | false |
| reference | info | false | | reference | info | false |
| refine | target-node | false | | refine | target-node | false |
| require-instance | value | false | | require-instance | value | false |
| revision | date | false | | revision | date | false |
| revision-date | date | false |
| rpc | name | false | | rpc | name | false |
| status | value | false | | status | value | false |
| submodule | name | false | | submodule | name | false |
| type | name | false | | type | name | false |
| typedef | name | false | | typedef | name | false |
| unique | tag | false | | unique | tag | false |
| units | name | false | | units | name | false |
| uses | name | false | | uses | name | false |
| value | value | false | | value | value | false |
| when | condition | false | | when | condition | false |
| yang-version | value | false | | yang-version | value | false |
| yin-element | value | false | | yin-element | value | false |
+------------------+---------------+-------------+ +------------------+---------------+-------------+
Table 1 Table 1
If a statement is followed by substatements, those substatements are 11.1.1. Usage Example
subelements in the YIN mapping.
Comments in YANG MAY be transformed into XML comments.
11.2.1. Usage Example
The following YANG snippet: The following YANG snippet:
leaf mtu { leaf mtu {
type uint32; type uint32;
description "The MTU of the interface."; description "The MTU of the interface.";
myext:c-define "MY_MTU";
} }
is translated into the following YIN snippet: where the extension "c-define" is defined in Section 7.17.3, is
translated into the following YIN snippet:
<leaf name="mtu"> <leaf name="mtu">
<type name="uint32"/> <type name="uint32"/>
<description> <description>
<text>The MTU of the interface.</text> <text>The MTU of the interface.</text>
</description> </description>
<myext:c-define name="MY_MTU"/>
</leaf> </leaf>
11.3. Transformation Algorithm YIN-2-YANG
The transformation is based on a recursive algorithm that is started
on the <module> or <submodule> element.
The element is transformed into a YANG keyword. If the keyword in
Table 1 is marked as yin-element true, the subelement with the
keyword's argument name in Table 1 contains the YANG keyword's
argument as text content. If the keyword in Table 1 is marked as
yin-element false, the element's attribute with keyword's argument
name in Table 1 contains the YANG keyword's argument.
If there are no other subelements to the element, the YANG statement
is closed with a ";". Otherwise, each such subelement is
transformed, according to the same algorithm, as substatements to the
current YANG statement, enclosed within "{" and "}".
XML comments in YIN MAY be transformed into YANG comments.
11.3.1. Tabulation, Formatting
To get a readable YANG module the YANG output will have to be
indented with appropriate whitespace characters.
12. YANG ABNF Grammar 12. YANG ABNF Grammar
In YANG, almost all statements are unordered. The ABNF grammar In YANG, almost all statements are unordered. The ABNF grammar
[RFC5234] defines the canonical order. To improve module [RFC5234] defines the canonical order. To improve module
readability, it is RECOMMENDED that clauses be entered in this order. readability, it is RECOMMENDED that clauses be entered in this order.
Within the ABNF grammar, unordered statements are marked with Within the ABNF grammar, unordered statements are marked with
comments. comments.
This grammar assumes that the scanner replaces YANG comments with a This grammar assumes that the scanner replaces YANG comments with a
skipping to change at page 136, line 42 skipping to change at page 139, line 42
meta-stmts meta-stmts
revision-stmts revision-stmts
body-stmts body-stmts
"}" optsep "}" optsep
module-header-stmts = ;; these stmts can appear in any order module-header-stmts = ;; these stmts can appear in any order
[yang-version-stmt stmtsep] [yang-version-stmt stmtsep]
namespace-stmt stmtsep namespace-stmt stmtsep
prefix-stmt stmtsep prefix-stmt stmtsep
submodule-header-stmts = ;; these stmts can appear in any order submodule-header-stmts =
;; these stmts can appear in any order
[yang-version-stmt stmtsep] [yang-version-stmt stmtsep]
belongs-to-stmt stmtsep belongs-to-stmt stmtsep
meta-stmts = ;; these stmts can appear in any order meta-stmts = ;; these stmts can appear in any order
[organization-stmt stmtsep] [organization-stmt stmtsep]
[contact-stmt stmtsep] [contact-stmt stmtsep]
[description-stmt stmtsep] [description-stmt stmtsep]
[reference-stmt stmtsep] [reference-stmt stmtsep]
linkage-stmts = ;; these stmts can appear in any order linkage-stmts = ;; these stmts can appear in any order
*(import-stmt stmtsep) *(import-stmt stmtsep)
*(include-stmt stmtsep) *(include-stmt stmtsep)
revision-stmts = *(revision-stmt stmtsep) revision-stmts = *(revision-stmt stmtsep)
body-stmts = *((extension-stmt / body-stmts = *((extension-stmt /
feature-stmt / feature-stmt /
identity-stmt / identity-stmt /
typedef-stmt / typedef-stmt /
skipping to change at page 137, line 46 skipping to change at page 140, line 47
optsep stmtend optsep stmtend
yang-version-arg-str = < a string which matches the rule yang-version-arg-str = < a string which matches the rule
yang-version-arg > yang-version-arg >
yang-version-arg = "1" yang-version-arg = "1"
import-stmt = import-keyword sep identifier-arg-str optsep import-stmt = import-keyword sep identifier-arg-str optsep
"{" stmtsep "{" stmtsep
prefix-stmt stmtsep prefix-stmt stmtsep
[revision-stmt stmtsep] [revision-date-stmt stmtsep]
"}" "}"
include-stmt = include-keyword sep identifier-arg-str optsep include-stmt = include-keyword sep identifier-arg-str optsep
(";" / (";" /
"{" stmtsep "{" stmtsep
[revision-stmt stmtsep] [revision-date-stmt stmtsep]
"}") "}")
namespace-stmt = namespace-keyword sep uri-str optsep stmtend namespace-stmt = namespace-keyword sep uri-str optsep stmtend
uri-str = < a string which matches the rule uri-str = < a string which matches the rule
URI in RFC 3986 > URI in RFC 3986 >
prefix-stmt = prefix-keyword sep prefix-arg-str prefix-stmt = prefix-keyword sep prefix-arg-str
optsep stmtend optsep stmtend
skipping to change at page 138, line 33 skipping to change at page 141, line 34
contact-stmt = contact-keyword sep string optsep stmtend contact-stmt = contact-keyword sep string optsep stmtend
description-stmt = description-keyword sep string optsep description-stmt = description-keyword sep string optsep
stmtend stmtend
reference-stmt = reference-keyword sep string optsep stmtend reference-stmt = reference-keyword sep string optsep stmtend
units-stmt = units-keyword sep string optsep stmtend units-stmt = units-keyword sep string optsep stmtend
revision-stmt = revision-keyword sep date-arg-str optsep revision-stmt = revision-keyword sep revision-date optsep
(";" / (";" /
"{" stmtsep "{" stmtsep
[description-stmt stmtsep] [description-stmt stmtsep]
"}") "}")
revision-date = date-arg-str
revision-date-stmt = revision-date-keyword sep revision-date stmtend
extension-stmt = extension-keyword sep identifier-arg-str optsep extension-stmt = extension-keyword sep identifier-arg-str optsep
(";" / (";" /
"{" stmtsep "{" stmtsep
;; these stmts can appear in any order ;; these stmts can appear in any order
[argument-stmt stmtsep] [argument-stmt stmtsep]
[status-stmt stmtsep] [status-stmt stmtsep]
[description-stmt stmtsep] [description-stmt stmtsep]
[reference-stmt stmtsep] [reference-stmt stmtsep]
"}") "}")
skipping to change at page 140, line 16 skipping to change at page 143, line 20
(";" / (";" /
"{" stmtsep "{" stmtsep
type-body-stmts type-body-stmts
"}") "}")
type-body-stmts = numerical-restrictions / type-body-stmts = numerical-restrictions /
string-restrictions / string-restrictions /
enum-specification / enum-specification /
leafref-specification / leafref-specification /
identityref-specification / identityref-specification /
instance-identifier-specification /
bits-specification / bits-specification /
union-specification union-specification
numerical-restrictions = range-stmt stmtsep numerical-restrictions = range-stmt stmtsep
range-stmt = range-keyword sep range-arg-str optsep range-stmt = range-keyword sep range-arg-str optsep
(";" / (";" /
"{" stmtsep "{" stmtsep
;; these stmts can appear in any order ;; these stmts can appear in any order
[error-message-stmt stmtsep] [error-message-stmt stmtsep]
skipping to change at page 141, line 20 skipping to change at page 144, line 26
enum-stmt = enum-keyword sep string optsep enum-stmt = enum-keyword sep string optsep
(";" / (";" /
"{" stmtsep "{" stmtsep
;; these stmts can appear in any order ;; these stmts can appear in any order
[value-stmt stmtsep] [value-stmt stmtsep]
[status-stmt stmtsep] [status-stmt stmtsep]
[description-stmt stmtsep] [description-stmt stmtsep]
[reference-stmt stmtsep] [reference-stmt stmtsep]
"}") "}")
leafref-specification = ;; these stmts can appear in any order leafref-specification =
;; these stmts can appear in any order
path-stmt stmtsep path-stmt stmtsep
[require-instance-stmt stmtsep] [require-instance-stmt stmtsep]
path-stmt = path-keyword sep path-arg-str stmtend path-stmt = path-keyword sep path-arg-str stmtend
require-instance-stmt = require-instance-keyword sep require-instance-stmt = require-instance-keyword sep
require-instance-arg-str stmtend require-instance-arg-str stmtend
require-instance-arg-str = < a string which matches the rule require-instance-arg-str = < a string which matches the rule
require-instance-arg > require-instance-arg >
require-instance-arg = true-keyword / false-keyword require-instance-arg = true-keyword / false-keyword
identityref-specification = ;; these stmts can appear in any order instance-identifier-specification =
base-stmt stmtsep
[require-instance-stmt stmtsep] [require-instance-stmt stmtsep]
identityref-specification =
base-stmt stmtsep
union-specification = 1*(type-stmt stmtsep) union-specification = 1*(type-stmt stmtsep)
bits-specification = 1*(bit-stmt stmtsep) bits-specification = 1*(bit-stmt stmtsep)
bit-stmt = bit-keyword sep identifier-arg-str optsep bit-stmt = bit-keyword sep identifier-arg-str optsep
(";" / (";" /
"{" stmtsep "{" stmtsep
;; these stmts can appear in any order ;; these stmts can appear in any order
[position-stmt stmtsep] [position-stmt stmtsep]
[status-stmt stmtsep] [status-stmt stmtsep]
[description-stmt stmtsep] [description-stmt stmtsep]
[reference-stmt stmtsep] [reference-stmt stmtsep]
"}" "}"
"}") "}")
skipping to change at page 145, line 26 skipping to change at page 148, line 33
*((typedef-stmt / *((typedef-stmt /
grouping-stmt) stmtsep) grouping-stmt) stmtsep)
1*(data-def-stmt stmtsep) 1*(data-def-stmt stmtsep)
"}" "}"
key-stmt = key-keyword sep key-arg-str stmtend key-stmt = key-keyword sep key-arg-str stmtend
key-arg-str = < a string which matches the rule key-arg-str = < a string which matches the rule
key-arg > key-arg >
key-arg = identifier *(sep identifier) key-arg = node-identifier *(sep node-identifier)
unique-stmt = unique-keyword sep unique-arg-str stmtend unique-stmt = unique-keyword sep unique-arg-str stmtend
unique-arg-str = < a string which matches the rule unique-arg-str = < a string which matches the rule
unique-arg > unique-arg >
unique-arg = descendant-schema-nodeid unique-arg = descendant-schema-nodeid
*(sep descendant-schema-nodeid) *(sep descendant-schema-nodeid)
choice-stmt = choice-keyword sep identifier-arg-str optsep choice-stmt = choice-keyword sep identifier-arg-str optsep
skipping to change at page 147, line 17 skipping to change at page 150, line 24
refine-choice-stmts / refine-choice-stmts /
refine-case-stmts / refine-case-stmts /
refine-anyxml-stmts) refine-anyxml-stmts)
"}") "}")
refine-arg-str = < a string which matches the rule refine-arg-str = < a string which matches the rule
refine-arg > refine-arg >
refine-arg = descendant-schema-nodeid refine-arg = descendant-schema-nodeid
refine-container-stmts = ;; these stmts can appear in any order refine-container-stmts =
;; these stmts can appear in any order
*(must-stmt stmtsep) *(must-stmt stmtsep)
[presence-stmt stmtsep] [presence-stmt stmtsep]
[config-stmt stmtsep] [config-stmt stmtsep]
[description-stmt stmtsep] [description-stmt stmtsep]
[reference-stmt stmtsep] [reference-stmt stmtsep]
refine-leaf-stmts = ;; these stmts can appear in any order refine-leaf-stmts = ;; these stmts can appear in any order
*(must-stmt stmtsep) *(must-stmt stmtsep)
[default-stmt stmtsep] [default-stmt stmtsep]
[config-stmt stmtsep] [config-stmt stmtsep]
[mandatory-stmt stmtsep] [mandatory-stmt stmtsep]
[description-stmt stmtsep] [description-stmt stmtsep]
[reference-stmt stmtsep] [reference-stmt stmtsep]
refine-leaf-list-stmts = ;; these stmts can appear in any order refine-leaf-list-stmts =
;; these stmts can appear in any order
*(must-stmt stmtsep) *(must-stmt stmtsep)
[config-stmt stmtsep] [config-stmt stmtsep]
[min-elements-stmt stmtsep] [min-elements-stmt stmtsep]
[max-elements-stmt stmtsep] [max-elements-stmt stmtsep]
[description-stmt stmtsep] [description-stmt stmtsep]
[reference-stmt stmtsep] [reference-stmt stmtsep]
refine-list-stmts = ;; these stmts can appear in any order refine-list-stmts = ;; these stmts can appear in any order
*(must-stmt stmtsep) *(must-stmt stmtsep)
[config-stmt stmtsep] [config-stmt stmtsep]
skipping to change at page 152, line 5 skipping to change at page 155, line 14
date-arg-str = < a string which matches the rule date-arg-str = < a string which matches the rule
date-arg > date-arg >
date-arg = 4DIGIT "-" 2DIGIT "-" 2DIGIT date-arg = 4DIGIT "-" 2DIGIT "-" 2DIGIT
;; Schema Node Identifiers ;; Schema Node Identifiers
schema-nodeid = absolute-schema-nodeid / schema-nodeid = absolute-schema-nodeid /
relative-schema-nodeid relative-schema-nodeid
absolute-schema-nodeid absolute-schema-nodeid = 1*("/" node-identifier)
= 1*("/" node-identifier)
relative-schema-nodeid relative-schema-nodeid =
= descendant-schema-nodeid / descendant-schema-nodeid /
(("." / "..") "/" (("." / "..") "/"
*relative-schema-nodeid) *relative-schema-nodeid)
descendant-schema-nodeid descendant-schema-nodeid =
= node-identifier node-identifier
absolute-schema-nodeid absolute-schema-nodeid
node-identifier = [prefix ":"] identifier node-identifier = [prefix ":"] identifier
;; Instance Identifiers ;; Instance Identifiers
instance-identifier-str instance-identifier = 1*("/" (node-identifier *predicate))
= < a string which matches the rule
instance-identifier >
instance-identifier = absolute-instid / relative-instid
absolute-instid = 1*("/" (node-identifier *predicate))
relative-instid = descendant-instid /
(("." / "..") "/"
*relative-instid)
descendant-instid = node-identifier *predicate
absolute-instid
predicate = "[" *WSP predicate-expr *WSP "]" predicate = "[" *WSP (predicate-expr / pos) *WSP "]"
predicate-expr = (node-identifier / ".") *WSP "=" *WSP predicate-expr = (node-identifier / ".") *WSP "=" *WSP
((DQUOTE string DQUOTE) / ((DQUOTE string DQUOTE) /
(SQUOTE string SQUOTE)) (SQUOTE string SQUOTE))
pos = non-negative-decimal-value)
;; leafref path ;; leafref path
path-arg-str = < a string which matches the rule path-arg-str = < a string which matches the rule
path-arg > path-arg >
path-arg = absolute-path / relative-path path-arg = absolute-path / relative-path
absolute-path = 1*("/" (node-identifier *path-predicate)) absolute-path = 1*("/" (node-identifier *path-predicate))
relative-path = 1*(".." "/") descendant-path relative-path = 1*(".." "/") descendant-path
skipping to change at page 154, line 25 skipping to change at page 157, line 24
path-keyword = 'path' path-keyword = 'path'
pattern-keyword = 'pattern' pattern-keyword = 'pattern'
position-keyword = 'position' position-keyword = 'position'
prefix-keyword = 'prefix' prefix-keyword = 'prefix'
presence-keyword = 'presence' presence-keyword = 'presence'
range-keyword = 'range' range-keyword = 'range'
reference-keyword = 'reference' reference-keyword = 'reference'
refine-keyword = 'refine' refine-keyword = 'refine'
require-instance-keyword = 'require-instance' require-instance-keyword = 'require-instance'
revision-keyword = 'revision' revision-keyword = 'revision'
revision-date-keyword = 'revision-date'
rpc-keyword = 'rpc' rpc-keyword = 'rpc'
status-keyword = 'status' status-keyword = 'status'
submodule-keyword = 'submodule' submodule-keyword = 'submodule'
type-keyword = 'type' type-keyword = 'type'
typedef-keyword = 'typedef' typedef-keyword = 'typedef'
unique-keyword = 'unique' unique-keyword = 'unique'
units-keyword = 'units' units-keyword = 'units'
uses-keyword = 'uses' uses-keyword = 'uses'
value-keyword = 'value' value-keyword = 'value'
when-keyword = 'when' when-keyword = 'when'
skipping to change at page 158, line 12 skipping to change at page 161, 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 YANG 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"
[XXX IANA]). [XXX IANA]).
13.2. Error Message for Data that Violates a YANG max-elements 13.2. Error Message for Data that Violates a max-elements Statement:
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 YANG min-elements 13.3. Error Message for Data that Violates a min-elements Statement:
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 YANG 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 the "insert" Operation 13.5. Error Message for Data that Violates a require-instance
statement:
If a NETCONF operation would result in configuration data where an
instance reference marked with require-instance "true" refers to a
non-existing instance, the following error is returned:
Tag: data-missing
Error-app-tag: instance-required
Error-path: Path to the element with the require-instance
statement
13.6. Error Message for Data that Violates a mandatory choice
statement:
If a NETCONF operation would result in configuration data where no
nodes exists in a mandatory choice, the following error is returned:
Tag: data-missing
Error-app-tag: missing-choice
Error-path: Path to the element with the missing choice.
Error-info: <missing-choice>: Contains the name of the missing
mandatory choice.
The <missing-choice> element is in the YANG
namespace ("urn:ietf:params:xml:ns:yang:1"
[XXX IANA]).
13.7. Error Message for the "insert" Operation
If the "insert" and "key" or "value" attributes are used in an <edit- If the "insert" and "key" or "value" attributes are used in an <edit-
config> for a list or leaf-list node, and the "key" or "value" refers config> for a list or leaf-list node, and the "key" or "value" refers
to a non-existing instance, the following error is returned: 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 164, line 13 skipping to change at page 167, line 13
[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>.
17.2. Non-Normative References 17.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.
Appendix A. ChangeLog Appendix A. ChangeLog
A.1. Version -03 A.1. Version -04
o Using "revision-date" substatement to "import" and "include".
o Corrected grammar and text for instance-identifier.
o Fixed bugs in some examples.
o Rewrote the YIN description to use a declarative style.
o Added two error codes in Section 13.
o Clarified that YANG uses the same XPath data model as XSLT.
o Specified which errors are generated in Section 8.3.1.
o Corrected grammar for key-arg; now allowing optional prefix on
each leaf identifier.
o Clarified that "unique" constraints only check instances with
values for all referenced leafs.
o Clarified how mandatory and min-elements constraints are enforced.
o Editorial fixes.
A.2. 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.2. Version -02 A.3. 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 165, line 48 skipping to change at page 169, line 30
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.3. Version -01 A.4. 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 166, line 46 skipping to change at page 170, line 27
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.4. Version -00 A.5. 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. 126 change blocks. 
433 lines changed or deleted 565 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/