1 module ietf-yang-types {
3 namespace "urn:ietf:params:xml:ns:yang:ietf-yang-types";
7 "IETF Network Modeling (NETMOD) Working Group";
10 "WG Web: <https://datatracker.ietf.org/wg/netmod/>
11 WG List: <mailto:netmod@ietf.org>
13 Editor: Juergen Schoenwaelder
14 <mailto:j.schoenwaelder@jacobs-university.de>";
17 "This module contains a collection of generally useful derived
20 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
21 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
22 'MAY', and 'OPTIONAL' in this document are to be interpreted as
23 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
24 they appear in all capitals, as shown here.
26 Copyright (c) 2019 IETF Trust and the persons identified as
27 authors of the code. All rights reserved.
29 Redistribution and use in source and binary forms, with or
30 without modification, is permitted pursuant to, and subject
31 to the license terms contained in, the Simplified BSD License
32 set forth in Section 4.c of the IETF Trust's Legal Provisions
33 Relating to IETF Documents
34 (http://trustee.ietf.org/license-info).
36 This version of this YANG module is part of RFC XXXX;
37 see the RFC itself for full legal notices.";
41 "This revision adds the following new data types:
43 - hours32, minutes32, seconds32, centiseconds32, milliseconds32,
44 - microseconds32, microseconds64, nanoseconds32, nanoseconds64
45 - revision-identifier, node-instance-identifier";
47 "RFC XXXX: Common YANG Data Types";
52 "This revision adds the following new data types:
58 "RFC 6991: Common YANG Data Types";
65 "RFC 6021: Common YANG Data Types";
68 /*** collection of counter and gauge types ***/
73 "The counter32 type represents a non-negative integer
74 that monotonically increases until it reaches a
75 maximum value of 2^32-1 (4294967295 decimal), when it
76 wraps around and starts increasing again from zero.
78 Counters have no defined 'initial' value, and thus, a
79 single value of a counter has (in general) no information
80 content. Discontinuities in the monotonically increasing
81 value normally occur at re-initialization of the
82 management system, and at other times as specified in the
83 description of a schema node using this type. If such
84 other times can occur, for example, the instantiation of
85 a schema node of type counter32 at times other than
86 re-initialization, then a corresponding schema node
87 should be defined, with an appropriate type, to indicate
88 the last discontinuity.
89 The counter32 type should not be used for configuration
90 schema nodes. A default statement SHOULD NOT be used in
91 combination with the type counter32.
93 In the value set and its semantics, this type is equivalent
94 to the Counter32 type of the SMIv2.";
96 "RFC 2578: Structure of Management Information Version 2
100 typedef zero-based-counter32 {
104 "The zero-based-counter32 type represents a counter32
105 that has the defined 'initial' value zero.
107 A schema node instance of this type will be set to zero (0)
108 on creation and will thereafter increase monotonically until
109 it reaches a maximum value of 2^32-1 (4294967295 decimal),
110 when it wraps around and starts increasing again from zero.
112 Provided that an application discovers a new schema node
113 instance of this type within the minimum time to wrap, it
114 can use the 'initial' value as a delta. It is important for
115 a management station to be aware of this minimum time and the
116 actual time between polls, and to discard data if the actual
117 time is too long or there is no defined minimum time.
119 In the value set and its semantics, this type is equivalent
120 to the ZeroBasedCounter32 textual convention of the SMIv2.";
122 "RFC 4502: Remote Network Monitoring Management Information
129 "The counter64 type represents a non-negative integer
130 that monotonically increases until it reaches a
131 maximum value of 2^64-1 (18446744073709551615 decimal),
132 when it wraps around and starts increasing again from zero.
134 Counters have no defined 'initial' value, and thus, a
135 single value of a counter has (in general) no information
136 content. Discontinuities in the monotonically increasing
137 value normally occur at re-initialization of the
138 management system, and at other times as specified in the
139 description of a schema node using this type. If such
140 other times can occur, for example, the instantiation of
141 a schema node of type counter64 at times other than
142 re-initialization, then a corresponding schema node
143 should be defined, with an appropriate type, to indicate
144 the last discontinuity.
146 The counter64 type should not be used for configuration
147 schema nodes. A default statement SHOULD NOT be used in
148 combination with the type counter64.
150 In the value set and its semantics, this type is equivalent
151 to the Counter64 type of the SMIv2.";
153 "RFC 2578: Structure of Management Information Version 2
157 typedef zero-based-counter64 {
161 "The zero-based-counter64 type represents a counter64 that
162 has the defined 'initial' value zero.
164 A schema node instance of this type will be set to zero (0)
165 on creation and will thereafter increase monotonically until
166 it reaches a maximum value of 2^64-1 (18446744073709551615
167 decimal), when it wraps around and starts increasing again
170 Provided that an application discovers a new schema node
171 instance of this type within the minimum time to wrap, it
172 can use the 'initial' value as a delta. It is important for
173 a management station to be aware of this minimum time and the
174 actual time between polls, and to discard data if the actual
175 time is too long or there is no defined minimum time.
177 In the value set and its semantics, this type is equivalent
178 to the ZeroBasedCounter64 textual convention of the SMIv2.";
180 "RFC 2856: Textual Conventions for Additional High Capacity
187 "The gauge32 type represents a non-negative integer, which
188 may increase or decrease, but shall never exceed a maximum
189 value, nor fall below a minimum value. The maximum value
190 cannot be greater than 2^32-1 (4294967295 decimal), and
191 the minimum value cannot be smaller than 0. The value of
192 a gauge32 has its maximum value whenever the information
193 being modeled is greater than or equal to its maximum
194 value, and has its minimum value whenever the information
195 being modeled is smaller than or equal to its minimum value.
196 If the information being modeled subsequently decreases
197 below (increases above) the maximum (minimum) value, the
198 gauge32 also decreases (increases).
200 In the value set and its semantics, this type is equivalent
201 to the Gauge32 type of the SMIv2.";
203 "RFC 2578: Structure of Management Information Version 2
210 "The gauge64 type represents a non-negative integer, which
211 may increase or decrease, but shall never exceed a maximum
212 value, nor fall below a minimum value. The maximum value
213 cannot be greater than 2^64-1 (18446744073709551615), and
214 the minimum value cannot be smaller than 0. The value of
215 a gauge64 has its maximum value whenever the information
216 being modeled is greater than or equal to its maximum
217 value, and has its minimum value whenever the information
218 being modeled is smaller than or equal to its minimum value.
219 If the information being modeled subsequently decreases
220 below (increases above) the maximum (minimum) value, the
221 gauge64 also decreases (increases).
223 In the value set and its semantics, this type is equivalent
224 to the CounterBasedGauge64 SMIv2 textual convention defined
227 "RFC 2856: Textual Conventions for Additional High Capacity
231 /*** collection of identifier-related types ***/
233 typedef object-identifier {
235 pattern '(([0-1](\.[1-3]?[0-9]))|(2\.(0|([1-9]\d*))))'
236 + '(\.(0|([1-9]\d*)))*';
239 "The object-identifier type represents administratively
240 assigned names in a registration-hierarchical-name tree.
242 Values of this type are denoted as a sequence of numerical
243 non-negative sub-identifier values. Each sub-identifier
244 value MUST NOT exceed 2^32-1 (4294967295). Sub-identifiers
245 are separated by single dots and without any intermediate
248 The ASN.1 standard restricts the value space of the first
249 sub-identifier to 0, 1, or 2. Furthermore, the value space
250 of the second sub-identifier is restricted to the range
251 0 to 39 if the first sub-identifier is 0 or 1. Finally,
252 the ASN.1 standard requires that an object identifier
253 has always at least two sub-identifiers. The pattern
254 captures these restrictions.
256 Although the number of sub-identifiers is not limited,
257 module designers should realize that there may be
258 implementations that stick with the SMIv2 limit of 128
261 This type is a superset of the SMIv2 OBJECT IDENTIFIER type
262 since it is not restricted to 128 sub-identifiers. Hence,
263 this type SHOULD NOT be used to represent the SMIv2 OBJECT
264 IDENTIFIER type; the object-identifier-128 type SHOULD be
267 "ISO9834-1: Information technology -- Open Systems
268 Interconnection -- Procedures for the operation of OSI
269 Registration Authorities: General procedures and top
270 arcs of the ASN.1 Object Identifier tree";
273 typedef object-identifier-128 {
274 type object-identifier {
275 pattern '\d*(\.\d*){1,127}';
278 "This type represents object-identifiers restricted to 128
281 In the value set and its semantics, this type is equivalent
282 to the OBJECT IDENTIFIER type of the SMIv2.";
284 "RFC 2578: Structure of Management Information Version 2
288 /*** collection of types related to date and time ***/
290 typedef date-and-time {
292 pattern '\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(\.\d+)?'
293 + '(Z|[\+\-]\d{2}:\d{2})';
296 "The date-and-time type is a profile of the ISO 8601
297 standard for representation of dates and times using the
298 Gregorian calendar. The profile is defined by the
299 date-time production in Section 5.6 of RFC 3339.
301 The date-and-time type is compatible with the dateTime XML
302 schema type with the following notable exceptions:
304 (a) The date-and-time type does not allow negative years.
306 (b) The date-and-time time-offset -00:00 indicates an unknown
307 time zone (see RFC 3339) while -00:00 and +00:00 and Z
308 all represent the same time zone in dateTime.
310 (c) The canonical format (see below) of date-and-time values
311 differs from the canonical format used by the dateTime XML
312 schema type, which requires all times to be in UTC using
315 This type is not equivalent to the DateAndTime textual
316 convention of the SMIv2 since RFC 3339 uses a different
317 separator between full-date and full-time and provides
318 higher resolution of time-secfrac.
320 The canonical format for date-and-time values with a known time
321 zone uses a numeric time zone offset that is calculated using
322 the device's configured known offset to UTC time. A change of
323 the device's offset to UTC time will cause date-and-time values
324 to change accordingly. Such changes might happen periodically
325 in case a server follows automatically daylight saving time
326 (DST) time zone offset changes. The canonical format for
327 date-and-time values with an unknown time zone (usually
328 referring to the notion of local time) uses the time-offset
331 "RFC 3339: Date and Time on the Internet: Timestamps
332 RFC 2579: Textual Conventions for SMIv2
333 XSD-TYPES: XML Schema Part 2: Datatypes Second Edition";
338 pattern '\d{4}-\d{2}-\d{2}'
339 + '(Z|[\+\-]\d{2}:\d{2})';
342 "The date type represents a time-interval of the length
343 of a day, i.e., 24 hours.
345 The date type is compatible with the date XML schema
346 type with the following notable exceptions:
348 (a) The date type does not allow negative years.
350 (b) The date time-offset -00:00 indicates an unknown
351 time zone (see RFC 3339) while -00:00 and +00:00 and Z
352 all represent the same time zone in date.
354 (c) The canonical format (see below) of data values
355 differs from the canonical format used by the date XML
356 schema type, which requires all times to be in UTC using
359 The canonical format for date values with a known time
360 zone uses a numeric time zone offset that is calculated using
361 the device's configured known offset to UTC time. A change of
362 the device's offset to UTC time will cause date values
363 to change accordingly. Such changes might happen periodically
364 in case a server follows automatically daylight saving time
365 (DST) time zone offset changes. The canonical format for
366 date values with an unknown time zone (usually referring
367 to the notion of local time) uses the time-offset -00:00.";
369 "RFC 3339: Date and Time on the Internet: Timestamps
370 XSD-TYPES: XML Schema Part 2: Datatypes Second Edition";
375 * - XML schema seems to use a different canonical format, we
376 * need to take a closer look how to define the canonical format
377 * given that a data really identifies a 24 hour interval and
378 * what XSD means with 'interval midpoint'.
383 pattern '\d{2}:\d{2}:\d{2}(\.\d+)?'
384 + '(Z|[\+\-]\d{2}:\d{2})';
387 "The time type represents an instance of time of zero-duration
388 that recurs every day.
390 The time type is compatible with the time XML schema
391 type with the following notable exceptions:
393 (a) The time time-offset -00:00 indicates an unknown
394 time zone (see RFC 3339) while -00:00 and +00:00 and Z
395 all represent the same time zone in time.
397 (c) The canonical format (see below) of time values
398 differs from the canonical format used by the time XML
399 schema type, which requires all times to be in UTC using
402 The canonical format for time values with a known time
403 zone uses a numeric time zone offset that is calculated using
404 the device's configured known offset to UTC time. A change of
405 the device's offset to UTC time will cause time values
406 to change accordingly. Such changes might happen periodically
407 in case a server follows automatically daylight saving time
408 (DST) time zone offset changes. The canonical format for
409 time values with an unknown time zone (usually referring
410 to the notion of local time) uses the time-offset -00:00.";
412 "RFC 3339: Date and Time on the Internet: Timestamps
413 XSD-TYPES: XML Schema Part 2: Datatypes Second Edition";
420 "A period of time, measured in units of hours.
422 The maximum time period that can be expressed is in the
423 range [89478485 days 08:00:00 to 89478485 days 07:00:00].
425 This type should be range restricted in situations
426 where only non-negative time periods are desirable,
427 (i.e., range '0..max').";
434 "A period of time, measured in units of minutes.
436 The maximum time period that can be expressed is in the
437 range [-1491308 days 2:08:00 to 1491308 days 2:07:00].
439 This type should be range restricted in situations
440 where only non-negative time periods are desirable,
441 (i.e., range '0..max').";
448 "A period of time, measured in units of seconds.
450 The maximum time period that can be expressed is in the
451 range [-24855 days 03:14:08 to 24855 days 03:14:07].
453 This type should be range restricted in situations
454 where only non-negative time periods are desirable,
455 (i.e., range '0..max').";
458 typedef centiseconds32 {
460 units "centiseconds";
462 "A period of time, measured in units of 10^-2 seconds.
464 The maximum time period that can be expressed is in the
465 range [-248 days 13:13:56 to 248 days 13:13:56].
467 This type should be range restricted in situations
468 where only non-negative time periods are desirable,
469 (i.e., range '0..max').";
472 typedef milliseconds32 {
474 units "milliseconds";
476 "A period of time, measured in units of 10^-3 seconds.
478 The maximum time period that can be expressed is in the
479 range [-24 days 20:31:23 to 24 days 20:31:23].
481 This type should be range restricted in situations
482 where only non-negative time periods are desirable,
483 (i.e., range '0..max').";
486 typedef microseconds32 {
488 units "microseconds";
490 "A period of time, measured in units of 10^-6 seconds.
492 The maximum time period that can be expressed is in the
493 range [-00:35:47 to 00:35:47].
495 This type should be range restricted in situations
496 where only non-negative time periods are desirable,
497 (i.e., range '0..max').";
500 typedef microseconds64 {
502 units "microseconds";
504 "A period of time, measured in units of 10^-6 seconds.
506 The maximum time period that can be expressed is in the
507 range [-106751991 days 04:00:54 to 106751991 days 04:00:54].
509 This type should be range restricted in situations
510 where only non-negative time periods are desirable,
511 (i.e., range '0..max').";
514 typedef nanoseconds32 {
518 "A period of time, measured in units of 10^-9 seconds.
520 The maximum time period that can be expressed is in the
521 range [-00:00:02 to 00:00:02].
523 This type should be range restricted in situations
524 where only non-negative time periods are desirable,
525 (i.e., range '0..max').";
528 typedef nanoseconds64 {
532 "A period of time, measured in units of 10^-9 seconds.
534 The maximum time period that can be expressed is in the
535 range [-106753 days 23:12:44 to 106752 days 0:47:16].
537 This type should be range restricted in situations
538 where only non-negative time periods are desirable,
539 (i.e., range '0..max').";
545 "The timeticks type represents a non-negative integer that
546 represents the time, modulo 2^32 (4294967296 decimal), in
547 hundredths of a second between two epochs. When a schema
548 node is defined that uses this type, the description of
549 the schema node identifies both of the reference epochs.
551 In the value set and its semantics, this type is equivalent
552 to the TimeTicks type of the SMIv2.";
554 "RFC 2578: Structure of Management Information Version 2
561 "The timestamp type represents the value of an associated
562 timeticks schema node instance at which a specific occurrence
563 happened. The specific occurrence must be defined in the
564 description of any schema node defined using this type. When
565 the specific occurrence occurred prior to the last time the
566 associated timeticks schema node instance was zero, then the
567 timestamp value is zero.
569 Note that this requires all timestamp values to be reset to
570 zero when the value of the associated timeticks schema node
571 instance reaches 497+ days and wraps around to zero.
573 The associated timeticks schema node must be specified
574 in the description of any schema node using this type.
576 In the value set and its semantics, this type is equivalent
577 to the TimeStamp textual convention of the SMIv2.";
579 "RFC 2579: Textual Conventions for SMIv2";
582 /*** collection of generic address types ***/
584 typedef phys-address {
586 pattern '([0-9a-fA-F]{2}(:[0-9a-fA-F]{2})*)?';
589 "Represents media- or physical-level addresses represented
590 as a sequence octets, each octet represented by two hexadecimal
591 numbers. Octets are separated by colons. The canonical
592 representation uses lowercase characters.
594 In the value set and its semantics, this type is equivalent
595 to the PhysAddress textual convention of the SMIv2.";
597 "RFC 2579: Textual Conventions for SMIv2";
600 typedef mac-address {
602 pattern '[0-9a-fA-F]{2}(:[0-9a-fA-F]{2}){5}';
605 "The mac-address type represents an IEEE 802 MAC address.
606 The canonical representation uses lowercase characters.
608 In the value set and its semantics, this type is equivalent
609 to the MacAddress textual convention of the SMIv2.";
611 "IEEE 802: IEEE Standard for Local and Metropolitan Area
612 Networks: Overview and Architecture
613 RFC 2579: Textual Conventions for SMIv2";
616 /*** collection of XML-specific types ***/
620 "This type represents an XPATH 1.0 expression.
622 When a schema node is defined that uses this type, the
623 description of the schema node MUST specify the XPath
624 context in which the XPath expression is evaluated.";
626 "XPATH: XML Path Language (XPath) Version 1.0";
631 * - How do we deal with xpath expressions in other encodings
632 * such as JSON. Do we assume an xpath context populated with
633 * module names such that module names can be used to qualify
634 * path expressions. This may need discussion and/or a new
636 * - This interacts with the definition of node-instance-identifier.
639 /*** collection of string types ***/
643 pattern '([0-9a-fA-F]{2}(:[0-9a-fA-F]{2})*)?';
646 "A hexadecimal string with octets represented as hex digits
647 separated by colons. The canonical representation uses
648 lowercase characters.";
653 pattern '[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-'
654 + '[0-9a-fA-F]{4}-[0-9a-fA-F]{12}';
657 "A Universally Unique IDentifier in the string representation
658 defined in RFC 4122. The canonical representation uses
659 lowercase characters.
661 The following is an example of a UUID in string representation:
662 f81d4fae-7dec-11d0-a765-00a0c91e6bf6
665 "RFC 4122: A Universally Unique IDentifier (UUID) URN
669 typedef dotted-quad {
672 '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}'
673 + '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])';
676 "An unsigned 32-bit number expressed in the dotted-quad
677 notation, i.e., four octets written as decimal numbers
678 and separated with the '.' (full stop) character.";
681 /*** collection of YANG specific types ***/
683 typedef yang-identifier {
686 pattern '[a-zA-Z_][a-zA-Z0-9\-_.]*';
687 pattern '.|..|[^xX].*|.[^mM].*|..[^lL].*';
690 "A YANG identifier string as defined by the 'identifier'
691 rule in Section 12 of RFC 6020. An identifier must
692 start with an alphabetic character or an underscore
693 followed by an arbitrary sequence of alphabetic or
694 numeric characters, underscores, hyphens, or dots.
696 A YANG identifier MUST NOT start with any possible
697 combination of the lowercase or uppercase character
700 "RFC 6020: YANG - A Data Modeling Language for the Network
701 Configuration Protocol (NETCONF)";
704 typedef revision-identifier {
706 pattern '\d{4}-\d{2}-\d{2}';
709 "Represents a specific revision of a YANG module by means of
710 a date value without a time zone.";
713 typedef node-instance-identifier {
716 "Path expression used to represent a data node, action,
717 or notification instance-identifier string.
719 A node-instance-identifier value is an unrestricted
720 YANG instance-identifier expression or the special
721 value '/', which refers to the entire accessible tree.
723 All the rules for instance-identifier apply, except that
724 predicates for keys are optional. If a key predicate is
725 missing, then the node-instance-identifier represents all
726 possible server instances for that key.
728 This XML Path Language (XPath) expression is evaluated in the
731 o The set of namespace declarations are those in scope on
732 the leaf element where this type is used.
734 o The set of variable bindings contains one variable,
735 'USER', which contains the name of the user of the
738 o The function library is the core function library, but
739 note that due to the syntax restrictions of an
740 instance-identifier, no functions are allowed.
742 o The context node is the root node in the data tree.
744 The accessible tree includes actions and notifications tied
750 * - This is taken from RFC 8341 and the idea is that this definition
751 * is useful without requiring a dependency on NACM
752 * - What does the second bullet actually do? Do we keep this?
753 * - This interacts with the definition of xpath1.0.
757 * - It was suggested to add types for longitude, latitude,
758 * postal code, country-code. Do we go there or do we leave
759 * these for other modules to define? It seems such definitions
760 * should go into draft-ietf-netmod-geo-location.
764 * - It was suggested to add percentage types but they tend to differ
765 * widely. However, percentages are also widely used.