1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
|
module openconfig-extensions {
yang-version "1";
// namespace
namespace "http://openconfig.net/yang/openconfig-ext";
prefix "oc-ext";
// meta
organization "OpenConfig working group";
contact
"OpenConfig working group
www.openconfig.net";
description
"This module provides extensions to the YANG language to allow
OpenConfig specific functionality and meta-data to be defined.";
oc-ext:openconfig-version "0.6.0";
revision "2024-09-19" {
description
"Add telemetry-atomic-exempt annotation.";
reference "0.6.0";
}
revision "2022-10-05" {
description
"Add missing version statement.";
reference "0.5.1";
}
revision "2020-06-16" {
description
"Add extension for POSIX pattern statements.";
reference "0.5.0";
}
revision "2018-10-17" {
description
"Add extension for regular expression type.";
reference "0.4.0";
}
revision "2017-04-11" {
description
"rename password type to 'hashed' and clarify description";
reference "0.3.0";
}
revision "2017-01-29" {
description
"Added extension for annotating encrypted values.";
reference "0.2.0";
}
revision "2015-10-09" {
description
"Initial OpenConfig public release";
reference "0.1.0";
}
// extension statements
extension openconfig-version {
argument "semver" {
yin-element false;
}
description
"The OpenConfig version number for the module. This is
expressed as a semantic version number of the form:
x.y.z
where:
* x corresponds to the major version,
* y corresponds to a minor version,
* z corresponds to a patch version.
This version corresponds to the model file within which it is
defined, and does not cover the whole set of OpenConfig models.
Individual YANG modules are versioned independently -- the
semantic version is generally incremented only when there is a
change in the corresponding file. Submodules should always
have the same semantic version as their parent modules.
A major version number of 0 indicates that this model is still
in development (whether within OpenConfig or with industry
partners), and is potentially subject to change.
Following a release of major version 1, all modules will
increment major revision number where backwards incompatible
changes to the model are made.
The minor version is changed when features are added to the
model that do not impact current clients use of the model.
The patch-level version is incremented when non-feature changes
(such as bugfixes or clarifications to human-readable
descriptions that do not impact model functionality) are made
that maintain backwards compatibility.
The version number is stored in the module meta-data.";
}
extension openconfig-hashed-value {
description
"This extension provides an annotation on schema nodes to
indicate that the corresponding value should be stored and
reported in hashed form.
Hash algorithms are by definition not reversible. Clients
reading the configuration or applied configuration for the node
should expect to receive only the hashed value. Values written
in cleartext will be hashed. This annotation may be used on
nodes such as secure passwords in which the device never reports
a cleartext value, even if the input is provided as cleartext.";
}
extension regexp-posix {
description
"This extension indicates that the regular expressions included
within the YANG module specified are conformant with the POSIX
regular expression format rather than the W3C standard that is
specified by RFC6020 and RFC7950.";
}
extension posix-pattern {
argument "pattern" {
yin-element false;
}
description
"Provides a POSIX ERE regular expression pattern statement as an
alternative to YANG regular expresssions based on XML Schema Datatypes.
It is used the same way as the standard YANG pattern statement defined in
RFC6020 and RFC7950, but takes an argument that is a POSIX ERE regular
expression string.";
reference
"POSIX Extended Regular Expressions (ERE) Specification:
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html#tag_09_04";
}
extension telemetry-on-change {
description
"The telemetry-on-change annotation is specified in the context
of a particular subtree (container, or list) or leaf within the
YANG schema. Where specified, it indicates that the value stored
by the nodes within the context change their value only in response
to an event occurring. The event may be local to the target, for
example - a configuration change, or external - such as the failure
of a link.
When a telemetry subscription allows the target to determine whether
to export the value of a leaf in a periodic or event-based fashion
(e.g., TARGET_DEFINED mode in gNMI), leaves marked as
telemetry-on-change should only be exported when they change,
i.e., event-based.";
}
extension telemetry-atomic {
description
"The telemetry-atomic annotation is specified in the context of
a subtree (container, or list), and indicates that all nodes
within the subtree are always updated together within the data
model. For example, all elements under the subtree may be updated
as a result of a new alarm being raised, or the arrival of a new
protocol message.
Transport protocols may use the atomic specification to determine
optimisations for sending or storing the corresponding data.";
}
extension telemetry-atomic-exempt {
description
"The telemetry-atomic-exempt annotation is specified in the context
of a node or subtree (container, or list), and indicates that the node
or all nodes within the subtree are not always updated together within
the data model of the parent tree. All elements under the subtree may
not be updated as a result of a new alarm being raised, or the arrival
of a new protocol message that updates the parent tree.
This annotation allows parent tree containers with telemetry-atomic
annotation to not be updated when a more frequently updated node or
subtree. For example, a counters container is present.
This extension should only be used when there is a parent that
contains telemetry-atomic extension.";
}
extension operational {
description
"The operational annotation is specified in the context of a
grouping, leaf, or leaf-list within a YANG module. It indicates
that the nodes within the context are derived state on the device.
OpenConfig data models divide nodes into the following three categories:
- intended configuration - these are leaves within a container named
'config', and are the writable configuration of a target.
- applied configuration - these are leaves within a container named
'state' and are the currently running value of the intended configuration.
- derived state - these are the values within the 'state' container which
are not part of the applied configuration of the device. Typically, they
represent state values reflecting underlying operational counters, or
protocol statuses.";
}
extension catalog-organization {
argument "org" {
yin-element false;
}
description
"This extension specifies the organization name that should be used within
the module catalogue on the device for the specified YANG module. It stores
a pithy string where the YANG organization statement may contain more
details.";
}
extension origin {
argument "origin" {
yin-element false;
}
description
"This extension specifies the name of the origin that the YANG module
falls within. This allows multiple overlapping schema trees to be used
on a single network element without requiring module based prefixing
of paths.";
}
}
|
