< draft-schoenw-netmod-rfc6991-bis-00.txt   draft-schoenw-netmod-rfc6991-bis-01.txt >
Network Working Group J. Schoenwaelder, Ed. Network Working Group J. Schoenwaelder, Ed.
Internet-Draft Jacobs University Internet-Draft Jacobs University
Obsoletes: 6991 (if approved) February 27, 2019 Obsoletes: 6991 (if approved) March 11, 2019
Intended status: Standards Track Intended status: Standards Track
Expires: August 31, 2019 Expires: September 12, 2019
Common YANG Data Types Common YANG Data Types
draft-schoenw-netmod-rfc6991-bis-00 draft-schoenw-netmod-rfc6991-bis-01
Abstract Abstract
This document introduces a collection of common data types to be used This document introduces a collection of common data types to be used
with the YANG data modeling language. This document obsoletes RFC with the YANG data modeling language. This document obsoletes RFC
6991. 6991.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 33 skipping to change at page 1, line 33
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 31, 2019. This Internet-Draft will expire on September 12, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 22 skipping to change at page 2, line 22
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Core YANG Derived Types . . . . . . . . . . . . . . . . . . . 6 3. Core YANG Derived Types . . . . . . . . . . . . . . . . . . . 6
4. Internet-Specific Derived Types . . . . . . . . . . . . . . . 17 4. Internet-Specific Derived Types . . . . . . . . . . . . . . . 22
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
6. Security Considerations . . . . . . . . . . . . . . . . . . . 28 6. Security Considerations . . . . . . . . . . . . . . . . . . . 34
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 29 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 35
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37
9.1. Normative References . . . . . . . . . . . . . . . . . . . 31 9.1. Normative References . . . . . . . . . . . . . . . . . . . 37
9.2. Informative References . . . . . . . . . . . . . . . . . . 32 9.2. Informative References . . . . . . . . . . . . . . . . . . 38
Appendix A. Changes from RFC 6991 . . . . . . . . . . . . . . . . 36 Appendix A. Changes from RFC 6991 . . . . . . . . . . . . . . . . 42
Appendix B. Changes from RFC 6021 . . . . . . . . . . . . . . . . 37 Appendix B. Changes from RFC 6021 . . . . . . . . . . . . . . . . 43
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 38 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 44
1. Introduction 1. Introduction
YANG [RFC7950] is a data modeling language used to model YANG [RFC7950] is a data modeling language used to model
configuration and state data manipulated by the Network Configuration configuration and state data manipulated by the Network Configuration
Protocol (NETCONF) [RFC6241]. The YANG language supports a small set Protocol (NETCONF) [RFC6241]. The YANG language supports a small set
of built-in data types and provides mechanisms to derive other types of built-in data types and provides mechanisms to derive other types
from the built-in types. from the built-in types.
This document introduces a collection of common data types derived This document introduces a collection of common data types derived
skipping to change at page 3, line 26 skipping to change at page 3, line 26
definitions are organized in several YANG modules. The definitions are organized in several YANG modules. The
"ietf-yang-types" module contains generally useful data types. The "ietf-yang-types" module contains generally useful data types. The
"ietf-inet-types" module contains definitions that are relevant for "ietf-inet-types" module contains definitions that are relevant for
the Internet protocol suite. the Internet protocol suite.
This document adds new type definitions to the YANG modules and This document adds new type definitions to the YANG modules and
obsoletes [RFC6991]. For further details, see the revision obsoletes [RFC6991]. For further details, see the revision
statements of the YANG modules in Section 3 and Section 4 and the statements of the YANG modules in Section 3 and Section 4 and the
summary in Appendix A. summary in Appendix A.
This document uses the YANG terminology defined in Section 3 of
[RFC7950].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119]. 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Overview 2. Overview
This section provides a short overview of the types defined in This section provides a short overview of the types defined in
subsequent sections and their equivalent Structure of Management subsequent sections and their equivalent Structure of Management
Information Version 2 (SMIv2) [RFC2578][RFC2579] data types. A YANG Information Version 2 (SMIv2) [RFC2578][RFC2579] data types. A YANG
data type is equivalent to an SMIv2 data type if the data types have data type is equivalent to an SMIv2 data type if the data types have
the same set of values and the semantics of the values are the same set of values and the semantics of the values are
equivalent. equivalent.
Table 1 lists the types defined in the ietf-yang-types YANG module Table 1 lists the types defined in the ietf-yang-types YANG module
and the corresponding SMIv2 types (- indicates there is no and the corresponding SMIv2 types (- indicates there is no
corresponding SMIv2 type). corresponding SMIv2 type).
+-----------------------+--------------------------------+ +--------------------------+--------------------------------+
| YANG type | Equivalent SMIv2 type (module) | | YANG type | Equivalent SMIv2 type (module) |
+-----------------------+--------------------------------+ +--------------------------+--------------------------------+
| counter32 | Counter32 (SNMPv2-SMI) | | counter32 | Counter32 (SNMPv2-SMI) |
| zero-based-counter32 | ZeroBasedCounter32 (RMON2-MIB) | | zero-based-counter32 | ZeroBasedCounter32 (RMON2-MIB) |
| counter64 | Counter64 (SNMPv2-SMI) | | counter64 | Counter64 (SNMPv2-SMI) |
| zero-based-counter64 | ZeroBasedCounter64 (HCNUM-TC) | | zero-based-counter64 | ZeroBasedCounter64 (HCNUM-TC) |
| gauge32 | Gauge32 (SNMPv2-SMI) | | gauge32 | Gauge32 (SNMPv2-SMI) |
| gauge64 | CounterBasedGauge64 (HCNUM-TC) | | gauge64 | CounterBasedGauge64 (HCNUM-TC) |
| object-identifier | - | | object-identifier | - |
| object-identifier-128 | OBJECT IDENTIFIER | | object-identifier-128 | OBJECT IDENTIFIER |
| yang-identifier | - | | date-and-time | - |
| date-and-time | - | | date | - |
| timeticks | TimeTicks (SNMPv2-SMI) | | time | - |
| timestamp | TimeStamp (SNMPv2-TC) | | hours | - |
| phys-address | PhysAddress (SNMPv2-TC) | | minutes | - |
| mac-address | MacAddress (SNMPv2-TC) | | seconds | - |
| xpath1.0 | - | | centiseconds | - |
| hex-string | - | | milliseconds | - |
| uuid | - | | microseconds | - |
| dotted-quad | - | | nanoseconds | - |
+-----------------------+--------------------------------+ | timeticks | TimeTicks (SNMPv2-SMI) |
| timestamp | TimeStamp (SNMPv2-TC) |
| phys-address | PhysAddress (SNMPv2-TC) |
| mac-address | MacAddress (SNMPv2-TC) |
| xpath1.0 | - |
| hex-string | - |
| uuid | - |
| dotted-quad | - |
| yang-identifier | - |
| revision-identifier | - |
| node-instance-identifier | - |
+--------------------------+--------------------------------+
Table 1: ietf-yang-types Table 1: ietf-yang-types
Table 2 lists the types defined in the ietf-inet-types YANG module Table 2 lists the types defined in the ietf-inet-types YANG module
and the corresponding SMIv2 types (if any). and the corresponding SMIv2 types (if any).
+----------------------+--------------------------------------------+ +----------------------+--------------------------------------------+
| YANG type | Equivalent SMIv2 type (module) | | YANG type | Equivalent SMIv2 type (module) |
+----------------------+--------------------------------------------+ +----------------------+--------------------------------------------+
| ip-version | InetVersion (INET-ADDRESS-MIB) | | ip-version | InetVersion (INET-ADDRESS-MIB) |
skipping to change at page 5, line 26 skipping to change at page 5, line 29
| ipv6-address | - | | ipv6-address | - |
| ip-address-no-zone | - | | ip-address-no-zone | - |
| ipv4-address-no-zone | - | | ipv4-address-no-zone | - |
| ipv6-address-no-zone | - | | ipv6-address-no-zone | - |
| ip-prefix | - | | ip-prefix | - |
| ipv4-prefix | - | | ipv4-prefix | - |
| ipv6-prefix | - | | ipv6-prefix | - |
| domain-name | - | | domain-name | - |
| host | - | | host | - |
| uri | Uri (URI-TC-MIB) | | uri | Uri (URI-TC-MIB) |
| email-address | - |
+----------------------+--------------------------------------------+ +----------------------+--------------------------------------------+
Table 2: ietf-inet-types Table 2: ietf-inet-types
3. Core YANG Derived Types 3. Core YANG Derived Types
The ietf-yang-types YANG module references [IEEE802], [ISO9834-1], The ietf-yang-types YANG module references [IEEE802], [ISO9834-1],
[RFC2578], [RFC2579], [RFC2856], [RFC3339], [RFC4122], [RFC4502], [RFC2578], [RFC2579], [RFC2856], [RFC3339], [RFC4122], [RFC4502],
[RFC7950], [XPATH], and [XSD-TYPES]. [RFC5322], [RFC7950], [XPATH], and [XSD-TYPES].
<CODE BEGINS> file "ietf-yang-types@2019-02-27.yang" <CODE BEGINS> file "ietf-yang-types@2019-03-11.yang"
module ietf-yang-types { module ietf-yang-types {
namespace "urn:ietf:params:xml:ns:yang:ietf-yang-types"; namespace "urn:ietf:params:xml:ns:yang:ietf-yang-types";
prefix "yang"; prefix "yang";
organization organization
"IETF NETMOD (NETCONF Data Modeling Language) Working Group"; "IETF NETMOD (Network Modeling) Working Group";
contact contact
"WG Web: <http://tools.ietf.org/wg/netmod/> "WG Web: <https://datatracker.ietf.org/wg/netmod/>
WG List: <mailto:netmod@ietf.org> WG List: <mailto:netmod@ietf.org>
WG Chair: David Kessens Editor: Juergen Schoenwaelder
<mailto:david.kessens@nsn.com> <mailto:j.schoenwaelder@jacobs-university.de>";
WG Chair: Juergen Schoenwaelder description
<mailto:j.schoenwaelder@jacobs-university.de> "This module contains a collection of generally useful derived
YANG data types.
Editor: Juergen Schoenwaelder The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
<mailto:j.schoenwaelder@jacobs-university.de>"; NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
'MAY', and 'OPTIONAL' in this document are to be interpreted as
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here.
Copyright (c) 2019 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX;
see the RFC itself for full legal notices.";
revision 2019-03-11 {
description description
"This module contains a collection of generally useful derived "This revision adds the following new data types:
YANG data types. - date, time
- hours, minutes, seconds
- centiseconds, milliseconds, microseconds, nanoseconds
- revision-identifier, node-instance-identifier";
reference
"RFC XXXX: Common YANG Data Types";
}
Copyright (c) 2019 IETF Trust and the persons identified as revision 2013-07-15 {
authors of the code. All rights reserved. description
"This revision adds the following new data types:
- yang-identifier
- hex-string
- uuid
- dotted-quad";
reference
"RFC 6991: Common YANG Data Types";
}
Redistribution and use in source and binary forms, with or revision 2010-09-24 {
without modification, is permitted pursuant to, and subject description
to the license terms contained in, the Simplified BSD License "Initial revision.";
set forth in Section 4.c of the IETF Trust's Legal Provisions reference
Relating to IETF Documents "RFC 6021: Common YANG Data Types";
(http://trustee.ietf.org/license-info). }
This version of this YANG module is part of RFC XXXX; see /*** collection of counter and gauge types ***/
the RFC itself for full legal notices.";
revision 2019-02-27 { typedef counter32 {
description type uint32;
"This revision adds the following new data types: description
- TBD"; "The counter32 type represents a non-negative integer
reference that monotonically increases until it reaches a
"RFC XXXX: Common YANG Data Types"; maximum value of 2^32-1 (4294967295 decimal), when it
} wraps around and starts increasing again from zero.
revision 2013-07-15 { Counters have no defined 'initial' value, and thus, a
description single value of a counter has (in general) no information
"This revision adds the following new data types: content. Discontinuities in the monotonically increasing
- yang-identifier value normally occur at re-initialization of the
- hex-string management system, and at other times as specified in the
- uuid description of a schema node using this type. If such
- dotted-quad"; other times can occur, for example, the instantiation of
reference a schema node of type counter32 at times other than
"RFC 6991: Common YANG Data Types"; re-initialization, then a corresponding schema node
} should be defined, with an appropriate type, to indicate
the last discontinuity.
revision 2010-09-24 { The counter32 type should not be used for configuration
description schema nodes. A default statement SHOULD NOT be used in
"Initial revision."; combination with the type counter32.
reference
"RFC 6021: Common YANG Data Types";
}
/*** collection of counter and gauge types ***/ In the value set and its semantics, this type is equivalent
to the Counter32 type of the SMIv2.";
reference
"RFC 2578: Structure of Management Information Version 2
(SMIv2)";
}
typedef counter32 { typedef zero-based-counter32 {
type uint32; type yang:counter32;
description default "0";
"The counter32 type represents a non-negative integer description
that monotonically increases until it reaches a "The zero-based-counter32 type represents a counter32
maximum value of 2^32-1 (4294967295 decimal), when it that has the defined 'initial' value zero.
wraps around and starts increasing again from zero.
Counters have no defined 'initial' value, and thus, a A schema node instance of this type will be set to zero (0)
single value of a counter has (in general) no information on creation and will thereafter increase monotonically until
content. Discontinuities in the monotonically increasing it reaches a maximum value of 2^32-1 (4294967295 decimal),
value normally occur at re-initialization of the when it wraps around and starts increasing again from zero.
management system, and at other times as specified in the
description of a schema node using this type. If such
other times can occur, for example, the creation of
a schema node of type counter32 at times other than
re-initialization, then a corresponding schema node
should be defined, with an appropriate type, to indicate
the last discontinuity.
The counter32 type should not be used for configuration Provided that an application discovers a new schema node
schema nodes. A default statement SHOULD NOT be used in instance of this type within the minimum time to wrap, it
combination with the type counter32. can use the 'initial' value as a delta. It is important for
a management station to be aware of this minimum time and the
actual time between polls, and to discard data if the actual
time is too long or there is no defined minimum time.
In the value set and its semantics, this type is equivalent In the value set and its semantics, this type is equivalent
to the Counter32 type of the SMIv2."; to the ZeroBasedCounter32 textual convention of the SMIv2.";
reference reference
"RFC 2578: Structure of Management Information Version 2 "RFC 4502: Remote Network Monitoring Management Information
(SMIv2)"; Base Version 2";
} }
typedef zero-based-counter32 { typedef counter64 {
type yang:counter32; type uint64;
default "0"; description
description "The counter64 type represents a non-negative integer
"The zero-based-counter32 type represents a counter32 that monotonically increases until it reaches a
that has the defined 'initial' value zero. maximum value of 2^64-1 (18446744073709551615 decimal),
when it wraps around and starts increasing again from zero.
A schema node of this type will be set to zero (0) on creation Counters have no defined 'initial' value, and thus, a
and will thereafter increase monotonically until it reaches single value of a counter has (in general) no information
a maximum value of 2^32-1 (4294967295 decimal), when it content. Discontinuities in the monotonically increasing
wraps around and starts increasing again from zero. value normally occur at re-initialization of the
management system, and at other times as specified in the
description of a schema node using this type. If such
other times can occur, for example, the instantiation of
a schema node of type counter64 at times other than
re-initialization, then a corresponding schema node
should be defined, with an appropriate type, to indicate
the last discontinuity.
Provided that an application discovers a new schema node The counter64 type should not be used for configuration
of this type within the minimum time to wrap, it can use the schema nodes. A default statement SHOULD NOT be used in
'initial' value as a delta. It is important for a management combination with the type counter64.
station to be aware of this minimum time and the actual time
between polls, and to discard data if the actual time is too
long or there is no defined minimum time.
In the value set and its semantics, this type is equivalent In the value set and its semantics, this type is equivalent
to the ZeroBasedCounter32 textual convention of the SMIv2."; to the Counter64 type of the SMIv2.";
reference reference
"RFC 4502: Remote Network Monitoring Management Information "RFC 2578: Structure of Management Information Version 2
Base Version 2"; (SMIv2)";
} }
typedef counter64 { typedef zero-based-counter64 {
type uint64; type yang:counter64;
description default "0";
"The counter64 type represents a non-negative integer description
that monotonically increases until it reaches a "The zero-based-counter64 type represents a counter64 that
maximum value of 2^64-1 (18446744073709551615 decimal), has the defined 'initial' value zero.
when it wraps around and starts increasing again from zero.
Counters have no defined 'initial' value, and thus, a A schema node instance of this type will be set to zero (0)
single value of a counter has (in general) no information on creation and will thereafter increase monotonically until
content. Discontinuities in the monotonically increasing it reaches a maximum value of 2^64-1 (18446744073709551615
value normally occur at re-initialization of the decimal), when it wraps around and starts increasing again
management system, and at other times as specified in the from zero.
description of a schema node using this type. If such
other times can occur, for example, the creation of
a schema node of type counter64 at times other than
re-initialization, then a corresponding schema node
should be defined, with an appropriate type, to indicate
the last discontinuity.
The counter64 type should not be used for configuration Provided that an application discovers a new schema node
schema nodes. A default statement SHOULD NOT be used in instance of this type within the minimum time to wrap, it
combination with the type counter64. can use the 'initial' value as a delta. It is important for
a management station to be aware of this minimum time and the
actual time between polls, and to discard data if the actual
time is too long or there is no defined minimum time.
In the value set and its semantics, this type is equivalent In the value set and its semantics, this type is equivalent
to the Counter64 type of the SMIv2."; to the ZeroBasedCounter64 textual convention of the SMIv2.";
reference reference
"RFC 2578: Structure of Management Information Version 2 "RFC 2856: Textual Conventions for Additional High Capacity
(SMIv2)"; Data Types";
} }
typedef zero-based-counter64 { typedef gauge32 {
type yang:counter64; type uint32;
default "0"; description
description "The gauge32 type represents a non-negative integer, which
"The zero-based-counter64 type represents a counter64 that may increase or decrease, but shall never exceed a maximum
has the defined 'initial' value zero. value, nor fall below a minimum value. The maximum value
cannot be greater than 2^32-1 (4294967295 decimal), and
the minimum value cannot be smaller than 0. The value of
a gauge32 has its maximum value whenever the information
being modeled is greater than or equal to its maximum
value, and has its minimum value whenever the information
being modeled is smaller than or equal to its minimum value.
If the information being modeled subsequently decreases
below (increases above) the maximum (minimum) value, the
gauge32 also decreases (increases).
A schema node of this type will be set to zero (0) on creation In the value set and its semantics, this type is equivalent
and will thereafter increase monotonically until it reaches to the Gauge32 type of the SMIv2.";
a maximum value of 2^64-1 (18446744073709551615 decimal), reference
when it wraps around and starts increasing again from zero. "RFC 2578: Structure of Management Information Version 2
(SMIv2)";
}
Provided that an application discovers a new schema node typedef gauge64 {
of this type within the minimum time to wrap, it can use the type uint64;
'initial' value as a delta. It is important for a management description
station to be aware of this minimum time and the actual time "The gauge64 type represents a non-negative integer, which
between polls, and to discard data if the actual time is too may increase or decrease, but shall never exceed a maximum
long or there is no defined minimum time. value, nor fall below a minimum value. The maximum value
cannot be greater than 2^64-1 (18446744073709551615), and
the minimum value cannot be smaller than 0. The value of
a gauge64 has its maximum value whenever the information
being modeled is greater than or equal to its maximum
value, and has its minimum value whenever the information
being modeled is smaller than or equal to its minimum value.
If the information being modeled subsequently decreases
below (increases above) the maximum (minimum) value, the
gauge64 also decreases (increases).
In the value set and its semantics, this type is equivalent In the value set and its semantics, this type is equivalent
to the ZeroBasedCounter64 textual convention of the SMIv2."; to the CounterBasedGauge64 SMIv2 textual convention defined
reference in RFC 2856";
"RFC 2856: Textual Conventions for Additional High Capacity reference
Data Types"; "RFC 2856: Textual Conventions for Additional High Capacity
Data Types";
}
/*** collection of identifier-related types ***/
typedef object-identifier {
type string {
pattern '(([0-1](\.[1-3]?[0-9]))|(2\.(0|([1-9]\d*))))'
+ '(\.(0|([1-9]\d*)))*';
} }
description
"The object-identifier type represents administratively
assigned names in a registration-hierarchical-name tree.
typedef gauge32 { Values of this type are denoted as a sequence of numerical
type uint32; non-negative sub-identifier values. Each sub-identifier
description value MUST NOT exceed 2^32-1 (4294967295). Sub-identifiers
"The gauge32 type represents a non-negative integer, which are separated by single dots and without any intermediate
may increase or decrease, but shall never exceed a maximum whitespace.
value, nor fall below a minimum value. The maximum value
cannot be greater than 2^32-1 (4294967295 decimal), and
the minimum value cannot be smaller than 0. The value of
a gauge32 has its maximum value whenever the information
being modeled is greater than or equal to its maximum
value, and has its minimum value whenever the information
being modeled is smaller than or equal to its minimum value.
If the information being modeled subsequently decreases
below (increases above) the maximum (minimum) value, the
gauge32 also decreases (increases).
In the value set and its semantics, this type is equivalent The ASN.1 standard restricts the value space of the first
to the Gauge32 type of the SMIv2."; sub-identifier to 0, 1, or 2. Furthermore, the value space
reference of the second sub-identifier is restricted to the range
"RFC 2578: Structure of Management Information Version 2 0 to 39 if the first sub-identifier is 0 or 1. Finally,
(SMIv2)"; the ASN.1 standard requires that an object identifier
has always at least two sub-identifiers. The pattern
captures these restrictions.
Although the number of sub-identifiers is not limited,
module designers should realize that there may be
implementations that stick with the SMIv2 limit of 128
sub-identifiers.
This type is a superset of the SMIv2 OBJECT IDENTIFIER type
since it is not restricted to 128 sub-identifiers. Hence,
this type SHOULD NOT be used to represent the SMIv2 OBJECT
IDENTIFIER type; the object-identifier-128 type SHOULD be
used instead.";
reference
"ISO9834-1: Information technology -- Open Systems
Interconnection -- Procedures for the operation of OSI
Registration Authorities: General procedures and top
arcs of the ASN.1 Object Identifier tree";
}
typedef object-identifier-128 {
type object-identifier {
pattern '\d*(\.\d*){1,127}';
} }
description
"This type represents object-identifiers restricted to 128
sub-identifiers.
typedef gauge64 { In the value set and its semantics, this type is equivalent
type uint64; to the OBJECT IDENTIFIER type of the SMIv2.";
description reference
"The gauge64 type represents a non-negative integer, which "RFC 2578: Structure of Management Information Version 2
may increase or decrease, but shall never exceed a maximum (SMIv2)";
value, nor fall below a minimum value. The maximum value }
cannot be greater than 2^64-1 (18446744073709551615), and
the minimum value cannot be smaller than 0. The value of
a gauge64 has its maximum value whenever the information
being modeled is greater than or equal to its maximum
value, and has its minimum value whenever the information
being modeled is smaller than or equal to its minimum value.
If the information being modeled subsequently decreases
below (increases above) the maximum (minimum) value, the
gauge64 also decreases (increases).
In the value set and its semantics, this type is equivalent /*** collection of types related to date and time ***/
to the CounterBasedGauge64 SMIv2 textual convention defined
in RFC 2856"; typedef date-and-time {
reference type string {
"RFC 2856: Textual Conventions for Additional High Capacity pattern '\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(\.\d+)?'
Data Types"; + '(Z|[\+\-]\d{2}:\d{2})';
} }
description
"The date-and-time type is a profile of the ISO 8601
standard for representation of dates and times using the
Gregorian calendar. The profile is defined by the
date-time production in Section 5.6 of RFC 3339.
/*** collection of identifier-related types ***/ The date-and-time type is compatible with the dateTime XML
schema type with the following notable exceptions:
typedef object-identifier { (a) The date-and-time type does not allow negative years.
type string {
pattern '(([0-1](\.[1-3]?[0-9]))|(2\.(0|([1-9]\d*))))'
+ '(\.(0|([1-9]\d*)))*';
}
description
"The object-identifier type represents administratively
assigned names in a registration-hierarchical-name tree.
Values of this type are denoted as a sequence of numerical (b) The date-and-time time-offset -00:00 indicates an unknown
non-negative sub-identifier values. Each sub-identifier time zone (see RFC 3339) while -00:00 and +00:00 and Z
value MUST NOT exceed 2^32-1 (4294967295). Sub-identifiers all represent the same time zone in dateTime.
are separated by single dots and without any intermediate
whitespace.
The ASN.1 standard restricts the value space of the first (c) The canonical format (see below) of date-and-time values
sub-identifier to 0, 1, or 2. Furthermore, the value space differs from the canonical format used by the dateTime XML
of the second sub-identifier is restricted to the range schema type, which requires all times to be in UTC using
0 to 39 if the first sub-identifier is 0 or 1. Finally, the time-offset 'Z'.
the ASN.1 standard requires that an object identifier
has always at least two sub-identifiers. The pattern
captures these restrictions.
Although the number of sub-identifiers is not limited, This type is not equivalent to the DateAndTime textual
module designers should realize that there may be convention of the SMIv2 since RFC 3339 uses a different
implementations that stick with the SMIv2 limit of 128 separator between full-date and full-time and provides
sub-identifiers. higher resolution of time-secfrac.
This type is a superset of the SMIv2 OBJECT IDENTIFIER type The canonical format for date-and-time values with a known time
since it is not restricted to 128 sub-identifiers. Hence, zone uses a numeric time zone offset that is calculated using
this type SHOULD NOT be used to represent the SMIv2 OBJECT the device's configured known offset to UTC time. A change of
IDENTIFIER type; the object-identifier-128 type SHOULD be the device's offset to UTC time will cause date-and-time values
used instead."; to change accordingly. Such changes might happen periodically
reference in case a server follows automatically daylight saving time
"ISO9834-1: Information technology -- Open Systems (DST) time zone offset changes. The canonical format for
Interconnection -- Procedures for the operation of OSI date-and-time values with an unknown time zone (usually
Registration Authorities: General procedures and top referring to the notion of local time) uses the time-offset
arcs of the ASN.1 Object Identifier tree"; -00:00.";
reference
"RFC 3339: Date and Time on the Internet: Timestamps
RFC 2579: Textual Conventions for SMIv2
XSD-TYPES: XML Schema Part 2: Datatypes Second Edition";
}
typedef date {
type string {
pattern '\d{4}-\d{2}-\d{2}'
+ '(Z|[\+\-]\d{2}:\d{2})';
} }
description
"The date type represents a time-interval of the length
of a day, i.e., 24 hours.
typedef object-identifier-128 { The date type is compatible with the date XML schema
type object-identifier { type with the following notable exceptions:
pattern '\d*(\.\d*){1,127}';
}
description
"This type represents object-identifiers restricted to 128
sub-identifiers.
In the value set and its semantics, this type is equivalent (a) The date type does not allow negative years.
to the OBJECT IDENTIFIER type of the SMIv2.";
reference
"RFC 2578: Structure of Management Information Version 2
(SMIv2)";
}
typedef yang-identifier { (b) The date time-offset -00:00 indicates an unknown
type string { time zone (see RFC 3339) while -00:00 and +00:00 and Z
length "1..max"; all represent the same time zone in date.
pattern '[a-zA-Z_][a-zA-Z0-9\-_.]*';
pattern '.|..|[^xX].*|.[^mM].*|..[^lL].*';
}
description
"A YANG identifier string as defined by the 'identifier'
rule in Section 12 of RFC 6020. An identifier must
start with an alphabetic character or an underscore
followed by an arbitrary sequence of alphabetic or
numeric characters, underscores, hyphens, or dots.
A YANG identifier MUST NOT start with any possible (c) The canonical format (see below) of data values
combination of the lowercase or uppercase character differs from the canonical format used by the date XML
sequence 'xml'."; schema type, which requires all times to be in UTC using
reference the time-offset 'Z'.
"RFC 6020: YANG - A Data Modeling Language for the Network
Configuration Protocol (NETCONF)"; The canonical format for date values with a known time
zone uses a numeric time zone offset that is calculated using
the device's configured known offset to UTC time. A change of
the device's offset to UTC time will cause date values
to change accordingly. Such changes might happen periodically
in case a server follows automatically daylight saving time
(DST) time zone offset changes. The canonical format for
date values with an unknown time zone (usually referring
to the notion of local time) uses the time-offset -00:00.";
reference
"RFC 3339: Date and Time on the Internet: Timestamps
XSD-TYPES: XML Schema Part 2: Datatypes Second Edition";
}
/*
* DISCUSS:
* - XML schema seems to use a different canonical format, we
* need to take a closer look how to define the canonical format
* given that a data really identifies a 24 hour interval and
* what XSD means with 'interval midpoint'.
*/
typedef time {
type string {
pattern '\d{2}:\d{2}:\d{2}(\.\d+)?'
+ '(Z|[\+\-]\d{2}:\d{2})';
} }
description
"The time type represents an instance of time of zero-duration
that recurs every day.
/*** collection of types related to date and time ***/ The time type is compatible with the time XML schema
type with the following notable exceptions:
typedef date-and-time { (a) The time time-offset -00:00 indicates an unknown
type string { time zone (see RFC 3339) while -00:00 and +00:00 and Z
pattern '\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(\.\d+)?' all represent the same time zone in time.
+ '(Z|[\+\-]\d{2}:\d{2})';
}
description
"The date-and-time type is a profile of the ISO 8601
standard for representation of dates and times using the
Gregorian calendar. The profile is defined by the
date-time production in Section 5.6 of RFC 3339.
The date-and-time type is compatible with the dateTime XML (c) The canonical format (see below) of time values
schema type with the following notable exceptions: differs from the canonical format used by the time XML
schema type, which requires all times to be in UTC using
the time-offset 'Z'.
(a) The date-and-time type does not allow negative years. The canonical format for time values with a known time
zone uses a numeric time zone offset that is calculated using
the device's configured known offset to UTC time. A change of
the device's offset to UTC time will cause time values
to change accordingly. Such changes might happen periodically
in case a server follows automatically daylight saving time
(DST) time zone offset changes. The canonical format for
time values with an unknown time zone (usually referring
to the notion of local time) uses the time-offset -00:00.";
reference
"RFC 3339: Date and Time on the Internet: Timestamps
XSD-TYPES: XML Schema Part 2: Datatypes Second Edition";
}
(b) The date-and-time time-offset -00:00 indicates an unknown typedef hours {
time zone (see RFC 3339) while -00:00 and +00:00 and Z type uint32;
all represent the same time zone in dateTime. units "hours";
description
"A period of time, measured in units of hours.";
}
(c) The canonical format (see below) of data-and-time values typedef minutes {
differs from the canonical format used by the dateTime XML type uint32;
schema type, which requires all times to be in UTC using units "minutes";
the time-offset 'Z'. description
"A period of time, measured in units of minutes.";
}
This type is not equivalent to the DateAndTime textual typedef seconds {
convention of the SMIv2 since RFC 3339 uses a different type uint32;
separator between full-date and full-time and provides units "seconds";
higher resolution of time-secfrac. description
"A period of time, measured in units of seconds.
The maximum duration that can be expressed is in the
order of 49710 days and 6 hours and 28 minutes and 15
seconds.";
}
The canonical format for date-and-time values with a known time typedef centiseconds {
zone uses a numeric time zone offset that is calculated using type uint32;
the device's configured known offset to UTC time. A change of units "centiseconds";
the device's offset to UTC time will cause date-and-time values description
to change accordingly. Such changes might happen periodically "A period of time, measured in units of 10^-2 seconds.
in case a server follows automatically daylight saving time The maximum duration that can be expressed is in the
(DST) time zone offset changes. The canonical format for order of 497 days and 2 hours and 27 minutes and 52
date-and-time values with an unknown time zone (usually seconds.";
referring to the notion of local time) uses the time-offset }
-00:00.";
reference
"RFC 3339: Date and Time on the Internet: Timestamps
RFC 2579: Textual Conventions for SMIv2
XSD-TYPES: XML Schema Part 2: Datatypes Second Edition";
}
typedef timeticks { typedef milliseconds {
type uint32; type uint32;
description units "milliseconds";
"The timeticks type represents a non-negative integer that description
represents the time, modulo 2^32 (4294967296 decimal), in "A period of time, measured in units of 10^-3 seconds.
hundredths of a second between two epochs. When a schema The maximum duration that can be expressed is in the
node is defined that uses this type, the description of order of 49 days and 17 hours and 2 minutes and 47
the schema node identifies both of the reference epochs. seconds.";
}
In the value set and its semantics, this type is equivalent typedef microseconds {
to the TimeTicks type of the SMIv2."; type uint32;
reference units "microseconds";
"RFC 2578: Structure of Management Information Version 2 description
(SMIv2)"; "A period of time, measured in units of 10^-6 seconds.
} The maximum duration that can be expressed is in the
order of 1 hour and 11 minutes and 34 seconds.";
}
typedef timestamp { typedef nanoseconds {
type yang:timeticks; type uint32;
description units "nanoseconds";
"The timestamp type represents the value of an associated description
timeticks schema node at which a specific occurrence "A period of time, measured in units of 10^-9 seconds.
happened. The specific occurrence must be defined in the The maximum duration that can be expressed is in the
description of any schema node defined using this type. When order of 4 seconds.";
the specific occurrence occurred prior to the last time the }
associated timeticks attribute was zero, then the timestamp
value is zero. Note that this requires all timestamp values
to be reset to zero when the value of the associated timeticks
attribute reaches 497+ days and wraps around to zero.
The associated timeticks schema node must be specified /*
in the description of any schema node using this type. * DISCUSS:
* - do we need (nano|micro|milli)seconds with 64 bits?
* - do we add typedef timeinterval { type centiseconds
* { range 0..2147483647 } } for compatibility with SMIv2?
*/
In the value set and its semantics, this type is equivalent typedef timeticks {
to the TimeStamp textual convention of the SMIv2."; type uint32;
reference description
"RFC 2579: Textual Conventions for SMIv2"; "The timeticks type represents a non-negative integer that
} represents the time, modulo 2^32 (4294967296 decimal), in
hundredths of a second between two epochs. When a schema
node is defined that uses this type, the description of
the schema node identifies both of the reference epochs.
/*** collection of generic address types ***/ In the value set and its semantics, this type is equivalent
to the TimeTicks type of the SMIv2.";
reference
"RFC 2578: Structure of Management Information Version 2
(SMIv2)";
}
typedef phys-address { typedef timestamp {
type string { type yang:timeticks;
pattern '([0-9a-fA-F]{2}(:[0-9a-fA-F]{2})*)?'; description
} "The timestamp type represents the value of an associated
description timeticks schema node instance at which a specific occurrence
"Represents media- or physical-level addresses represented happened. The specific occurrence must be defined in the
as a sequence octets, each octet represented by two hexadecimal description of any schema node defined using this type. When
numbers. Octets are separated by colons. The canonical the specific occurrence occurred prior to the last time the
representation uses lowercase characters. associated timeticks schema node instance was zero, then the
timestamp value is zero.
In the value set and its semantics, this type is equivalent Note that this requires all timestamp values to be reset to
to the PhysAddress textual convention of the SMIv2."; zero when the value of the associated timeticks schema node
reference instance reaches 497+ days and wraps around to zero.
"RFC 2579: Textual Conventions for SMIv2";
The associated timeticks schema node must be specified
in the description of any schema node using this type.
In the value set and its semantics, this type is equivalent
to the TimeStamp textual convention of the SMIv2.";
reference
"RFC 2579: Textual Conventions for SMIv2";
}
/*** collection of generic address types ***/
typedef phys-address {
type string {
pattern '([0-9a-fA-F]{2}(:[0-9a-fA-F]{2})*)?';
} }
description
"Represents media- or physical-level addresses represented
as a sequence octets, each octet represented by two hexadecimal
numbers. Octets are separated by colons. The canonical
representation uses lowercase characters.
typedef mac-address { In the value set and its semantics, this type is equivalent
type string { to the PhysAddress textual convention of the SMIv2.";
pattern '[0-9a-fA-F]{2}(:[0-9a-fA-F]{2}){5}'; reference
} "RFC 2579: Textual Conventions for SMIv2";
description }
"The mac-address type represents an IEEE 802 MAC address.
The canonical representation uses lowercase characters.
In the value set and its semantics, this type is equivalent typedef mac-address {
to the MacAddress textual convention of the SMIv2."; type string {
reference pattern '[0-9a-fA-F]{2}(:[0-9a-fA-F]{2}){5}';
"IEEE 802: IEEE Standard for Local and Metropolitan Area
Networks: Overview and Architecture
RFC 2579: Textual Conventions for SMIv2";
} }
/*** collection of XML-specific types ***/ description
"The mac-address type represents an IEEE 802 MAC address.
The canonical representation uses lowercase characters.
typedef xpath1.0 { In the value set and its semantics, this type is equivalent
type string; to the MacAddress textual convention of the SMIv2.";
description reference
"This type represents an XPATH 1.0 expression. "IEEE 802: IEEE Standard for Local and Metropolitan Area
Networks: Overview and Architecture
RFC 2579: Textual Conventions for SMIv2";
}
When a schema node is defined that uses this type, the /*** collection of XML-specific types ***/
description of the schema node MUST specify the XPath
context in which the XPath expression is evaluated."; typedef xpath1.0 {
reference type string;
"XPATH: XML Path Language (XPath) Version 1.0"; description
"This type represents an XPATH 1.0 expression.
When a schema node is defined that uses this type, the
description of the schema node MUST specify the XPath
context in which the XPath expression is evaluated.";
reference
"XPATH: XML Path Language (XPath) Version 1.0";
}
/*
* DISCUSS:
* - How do we deal with xpath expressions in other encodings
* such as JSON. Do we assume an xpath context populated with
* module names such that module names can be used to qualify
* path expressions. This may need discussion and/or a new
* definition.
* - This interacts with the definition of node-instance-identifier.
*/
/*** collection of string types ***/
typedef hex-string {
type string {
pattern '([0-9a-fA-F]{2}(:[0-9a-fA-F]{2})*)?';
} }
description
"A hexadecimal string with octets represented as hex digits
separated by colons. The canonical representation uses
lowercase characters.";
}
/*** collection of string types ***/ typedef uuid {
type string {
pattern '[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-'
+ '[0-9a-fA-F]{4}-[0-9a-fA-F]{12}';
}
description
"A Universally Unique IDentifier in the string representation
defined in RFC 4122. The canonical representation uses
lowercase characters.
typedef hex-string { The following is an example of a UUID in string representation:
type string { f81d4fae-7dec-11d0-a765-00a0c91e6bf6
pattern '([0-9a-fA-F]{2}(:[0-9a-fA-F]{2})*)?'; ";
} reference
description "RFC 4122: A Universally Unique IDentifier (UUID) URN
"A hexadecimal string with octets represented as hex digits Namespace";
separated by colons. The canonical representation uses }
lowercase characters.";
typedef dotted-quad {
type string {
pattern
'(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}'
+ '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])';
} }
description
"An unsigned 32-bit number expressed in the dotted-quad
notation, i.e., four octets written as decimal numbers
and separated with the '.' (full stop) character.";
}
typedef uuid { /*** collection of YANG specific types ***/
type string {
pattern '[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-'
+ '[0-9a-fA-F]{4}-[0-9a-fA-F]{12}';
}
description
"A Universally Unique IDentifier in the string representation
defined in RFC 4122. The canonical representation uses
lowercase characters.
The following is an example of a UUID in string representation: typedef yang-identifier {
f81d4fae-7dec-11d0-a765-00a0c91e6bf6 type string {
"; length "1..max";
reference pattern '[a-zA-Z_][a-zA-Z0-9\-_.]*';
"RFC 4122: A Universally Unique IDentifier (UUID) URN pattern '.|..|[^xX].*|.[^mM].*|..[^lL].*';
Namespace";
} }
description
"A YANG identifier string as defined by the 'identifier'
rule in Section 12 of RFC 6020. An identifier must
start with an alphabetic character or an underscore
followed by an arbitrary sequence of alphabetic or
numeric characters, underscores, hyphens, or dots.
typedef dotted-quad { A YANG identifier MUST NOT start with any possible
type string { combination of the lowercase or uppercase character
pattern sequence 'xml'.";
'(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}' reference
"RFC 6020: YANG - A Data Modeling Language for the Network
Configuration Protocol (NETCONF)";
}
+ '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])'; typedef revision-identifier {
} type date {
description pattern '\d{4}-\d{2}-\d{2}';
"An unsigned 32-bit number expressed in the dotted-quad
notation, i.e., four octets written as decimal numbers
and separated with the '.' (full stop) character.";
} }
description
"Represents a specific revision of a YANG module by means of
a date value without a time zone.";
}
typedef node-instance-identifier {
type xpath1.0;
description
"Path expression used to represent a special
data node, action, or notification instance-identifier
string.
A node-instance-identifier value is an
unrestricted YANG instance-identifier expression.
All the same rules as an instance-identifier apply,
except that predicates for keys are optional. If a key
predicate is missing, then the node-instance-identifier
represents all possible server instances for that key.
This XML Path Language (XPath) expression is evaluated in the
following context:
o The set of namespace declarations are those in scope on
the leaf element where this type is used.
o The set of variable bindings contains one variable,
'USER', which contains the name of the user of the
current session.
o The function library is the core function library, but
note that due to the syntax restrictions of an
instance-identifier, no functions are allowed.
o The context node is the root node in the data tree.
The accessible tree includes actions and notifications tied
to data nodes.";
} }
/*
* DISCUSS:
* - This is taken from RFC 8341 and the idea is that this definition
* is useful without requiring a dependency on NACM
* - What does the second bullet actually do? Do we keep this?
* - How does this work with JSON? Can we make this encoding neutral
* (but then we knowingly depart from NACM)?
* - This interacts with the definition of xpath1.0.
*/
/* DISCUSS:
* - It was suggested to add types for longitude, latitude,
* postal code, country-code. Do we go there or do we leave
* these for other modules to define?
*/
/* DISCUSS:
* - It was suggested to add percentage types but they tend to differ
* widely. However, percentages are also widely used.
*/
}
<CODE ENDS> <CODE ENDS>
4. Internet-Specific Derived Types 4. Internet-Specific Derived Types
The ietf-inet-types YANG module references [RFC0768], [RFC0791], The ietf-inet-types YANG module references [RFC0768], [RFC0791],
[RFC0793], [RFC0952], [RFC1034], [RFC1123], [RFC1930], [RFC2460], [RFC0793], [RFC0952], [RFC1034], [RFC1123], [RFC1930], [RFC2460],
[RFC2474], [RFC2780], [RFC2782], [RFC3289], [RFC3305], [RFC3595], [RFC2474], [RFC2780], [RFC2782], [RFC3289], [RFC3305], [RFC3595],
[RFC3986], [RFC4001], [RFC4007], [RFC4271], [RFC4291], [RFC4340], [RFC3986], [RFC4001], [RFC4007], [RFC4271], [RFC4291], [RFC4340],
[RFC4960], [RFC5017], [RFC5890], [RFC5952], and [RFC6793]. [RFC4960], [RFC5017], [RFC5890], [RFC5952], and [RFC6793].
<CODE BEGINS> file "ietf-inet-types@2019-02-27.yang" <CODE BEGINS> file "ietf-inet-types@2019-03-11.yang"
module ietf-inet-types { module ietf-inet-types {
namespace "urn:ietf:params:xml:ns:yang:ietf-inet-types"; namespace "urn:ietf:params:xml:ns:yang:ietf-inet-types";
prefix "inet"; prefix "inet";
organization organization
"IETF NETMOD (NETCONF Data Modeling Language) Working Group"; "IETF NETMOD (Network Modeling) Working Group";
contact contact
"WG Web: <http://tools.ietf.org/wg/netmod/> "WG Web: <https://datatracker.ietf.org/wg/netmod/>
WG List: <mailto:netmod@ietf.org> WG List: <mailto:netmod@ietf.org>
WG Chair: David Kessens
<mailto:david.kessens@nsn.com>
WG Chair: Juergen Schoenwaelder
<mailto:j.schoenwaelder@jacobs-university.de>
Editor: Juergen Schoenwaelder Editor: Juergen Schoenwaelder
<mailto:j.schoenwaelder@jacobs-university.de>"; <mailto:j.schoenwaelder@jacobs-university.de>";
description description
"This module contains a collection of generally useful derived "This module contains a collection of generally useful derived
YANG data types for Internet addresses and related things. YANG data types for Internet addresses and related things.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
'MAY', and 'OPTIONAL' in this document are to be interpreted as
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here.
Copyright (c) 2019 IETF Trust and the persons identified as Copyright (c) 2019 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see This version of this YANG module is part of RFC XXXX;
the RFC itself for full legal notices."; see the RFC itself for full legal notices.";
revision 2019-02-27 { revision 2019-03-11 {
description description
"This revision adds the following new data types: "This revision adds the following new data types:
- TBD"; - email-address";
reference reference
"RFC XXXX: Common YANG Data Types"; "RFC XXXX: Common YANG Data Types";
} }
revision 2013-07-15 { revision 2013-07-15 {
description description
"This revision adds the following new data types: "This revision adds the following new data types:
- ip-address-no-zone - ip-address-no-zone
- ipv4-address-no-zone - ipv4-address-no-zone
- ipv6-address-no-zone"; - ipv6-address-no-zone";
skipping to change at page 25, line 15 skipping to change at page 30, line 15
Internet domain names are only loosely specified. Section Internet domain names are only loosely specified. Section
3.5 of RFC 1034 recommends a syntax (modified in Section 3.5 of RFC 1034 recommends a syntax (modified in Section
2.1 of RFC 1123). The pattern above is intended to allow 2.1 of RFC 1123). The pattern above is intended to allow
for current practice in domain name use, and some possible for current practice in domain name use, and some possible
future expansion. It is designed to hold various types of future expansion. It is designed to hold various types of
domain names, including names used for A or AAAA records domain names, including names used for A or AAAA records
(host names) and other records, such as SRV records. Note (host names) and other records, such as SRV records. Note
that Internet host names have a stricter syntax (described that Internet host names have a stricter syntax (described
in RFC 952) than the DNS recommendations in RFCs 1034 and in RFC 952) than the DNS recommendations in RFCs 1034 and
1123, and that systems that want to store host names in 1123, and that systems that want to store host names in
schema nodes using the domain-name type are recommended to schema node instances using the domain-name type are
adhere to this stricter standard to ensure interoperability. recommended to adhere to this stricter standard to ensure
interoperability.
The encoding of DNS names in the DNS protocol is limited The encoding of DNS names in the DNS protocol is limited
to 255 characters. Since the encoding consists of labels to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL prefixed by a length bytes and there is a trailing NULL
byte, only 253 characters can appear in the textual dotted byte, only 253 characters can appear in the textual dotted
notation. notation.
The description clause of schema nodes using the domain-name The description clause of schema nodes using the domain-name
type MUST describe when and how these names are resolved to type MUST describe when and how these names are resolved to
IP addresses. Note that the resolution of a domain-name value IP addresses. Note that the resolution of a domain-name value
skipping to change at page 26, line 47 skipping to change at page 31, line 48
reference reference
"RFC 3986: Uniform Resource Identifier (URI): Generic Syntax "RFC 3986: Uniform Resource Identifier (URI): Generic Syntax
RFC 3305: Report from the Joint W3C/IETF URI Planning Interest RFC 3305: Report from the Joint W3C/IETF URI Planning Interest
Group: Uniform Resource Identifiers (URIs), URLs, Group: Uniform Resource Identifiers (URIs), URLs,
and Uniform Resource Names (URNs): Clarifications and Uniform Resource Names (URNs): Clarifications
and Recommendations and Recommendations
RFC 5017: MIB Textual Conventions for Uniform Resource RFC 5017: MIB Textual Conventions for Uniform Resource
Identifiers (URIs)"; Identifiers (URIs)";
} }
typedef email-address {
type string {
// dot-atom-text "@" ...
pattern "[a-zA-Z0-9!#$%&'*+/=?^_`{|}~-]+"
+ "(\\.[a-zA-Z0-9!#$%&'*+/=?^_`{|}~-]+)*"
+ "@"
+ "[a-zA-Z0-9!#$%&'*+/=?^_`{|}~-]+"
+ "(\\.[a-zA-Z0-9!#$%&'*+/=?^_`{|}~-]+)*";
}
description
"The email-address type represents an email address as
defined as addr-spec in RFC 5322 section 3.4.1.";
reference
"RFC 5322: Internet Message Format";
}
/*
* DISCUSS:
* - It was suggested to add email types following RFC 5322
* email-address (addr-spec, per Section 3.4.1)
* named-email-address (name-addr, per Section 3.4)
* - This sounds useful but the devil is in the details,
* in particular name-addr is a quite complex construct;
* perhaps addr-spec is sufficient, this is also the
* format allowed in mailto: URIs (mailto: seems to use
* only a subset of addr-spec which may be good enough
* here as well).
* - Need to define a pattern that has a meaningful trade-off
* between precision and complexity (there are very tight
* pattern that are very long and complex). The current
* pattern does not take care of quoted-string, obs-local-part,
* domain-literal, obs-domain.
*/
} }
<CODE ENDS> <CODE ENDS>
5. IANA Considerations 5. IANA Considerations
This document registers two URIs in the IETF XML registry [RFC3688]. This document registers two URIs in the IETF XML registry [RFC3688].
Following the format in RFC 3688, the following registrations have Following the format in RFC 3688, the following registrations have
been made. been made.
skipping to change at page 32, line 5 skipping to change at page 38, line 5
<https://www.rfc-editor.org/info/rfc6020>. <https://www.rfc-editor.org/info/rfc6020>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6991, DOI 10.17487/RFC6991, July 2013, RFC 6991, DOI 10.17487/RFC6991, July 2013,
<https://www.rfc-editor.org/info/rfc6991>. <https://www.rfc-editor.org/info/rfc6991>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016, RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>. <https://www.rfc-editor.org/info/rfc7950>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[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>.
9.2. Informative References 9.2. Informative References
[IEEE802] IEEE, "IEEE Standard for Local and Metropolitan Area [IEEE802] IEEE, "IEEE Standard for Local and Metropolitan Area
Networks: Overview and Architecture", IEEE Std. 802-2001. Networks: Overview and Architecture", IEEE Std. 802-2001.
skipping to change at page 34, line 36 skipping to change at page 40, line 40
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",
RFC 4960, DOI 10.17487/RFC4960, September 2007, RFC 4960, DOI 10.17487/RFC4960, September 2007,
<https://www.rfc-editor.org/info/rfc4960>. <https://www.rfc-editor.org/info/rfc4960>.
[RFC5017] McWalter, D., Ed., "MIB Textual Conventions for Uniform [RFC5017] McWalter, D., Ed., "MIB Textual Conventions for Uniform
Resource Identifiers (URIs)", RFC 5017, DOI 10.17487/ Resource Identifiers (URIs)", RFC 5017, DOI 10.17487/
RFC5017, September 2007, RFC5017, September 2007,
<https://www.rfc-editor.org/info/rfc5017>. <https://www.rfc-editor.org/info/rfc5017>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
DOI 10.17487/RFC5322, October 2008,
<https://www.rfc-editor.org/info/rfc5322>.
[RFC5890] Klensin, J., "Internationalized Domain Names for [RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework", Applications (IDNA): Definitions and Document Framework",
RFC 5890, DOI 10.17487/RFC5890, August 2010, RFC 5890, DOI 10.17487/RFC5890, August 2010,
<https://www.rfc-editor.org/info/rfc5890>. <https://www.rfc-editor.org/info/rfc5890>.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952, DOI 10.17487/ Address Text Representation", RFC 5952, DOI 10.17487/
RFC5952, August 2010, RFC5952, August 2010,
<https://www.rfc-editor.org/info/rfc5952>. <https://www.rfc-editor.org/info/rfc5952>.
skipping to change at page 37, line 4 skipping to change at page 42, line 6
DOI 10.17487/RFC6793, December 2012, DOI 10.17487/RFC6793, December 2012,
<https://www.rfc-editor.org/info/rfc6793>. <https://www.rfc-editor.org/info/rfc6793>.
[XSD-TYPES] [XSD-TYPES]
Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes
Second Edition", World Wide Web Consortium Second Edition", World Wide Web Consortium
Recommendation REC-xmlschema-2-20041028, October 2004, Recommendation REC-xmlschema-2-20041028, October 2004,
<http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>. <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
Appendix A. Changes from RFC 6991 Appendix A. Changes from RFC 6991
This version adds new type definitions to the YANG modules. The
following new data types have been added to the ietf-yang-types
module:
o date, time
o hours, minutes, seconds
o centiseconds, milliseconds, microseconds, nanoseconds
o revision-identifier, node-instance-identifier
The following new data types have been added to the ietf-inet-types
module:
o email-address
Appendix B. Changes from RFC 6021 Appendix B. Changes from RFC 6021
This version adds new type definitions to the YANG modules. The This version adds new type definitions to the YANG modules. The
following new data types have been added to the ietf-yang-types following new data types have been added to the ietf-yang-types
module: module:
o yang-identifier o yang-identifier
o hex-string o hex-string
 End of changes. 108 change blocks. 
453 lines changed or deleted 762 lines changed or added

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