draft-ietf-netmod-rfc6991-bis-02.txt   draft-ietf-netmod-rfc6991-bis-03.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) November 4, 2019 Obsoletes: 6991 (if approved) June 26, 2020
Intended status: Standards Track Intended status: Standards Track
Expires: May 7, 2020 Expires: December 28, 2020
Common YANG Data Types Common YANG Data Types
draft-ietf-netmod-rfc6991-bis-02 draft-ietf-netmod-rfc6991-bis-03
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 May 7, 2020. This Internet-Draft will expire on December 28, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 7, line 38 skipping to change at page 7, line 38
description description
"This module contains a collection of generally useful derived "This module contains a collection of generally useful derived
YANG data types. YANG data types.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
'MAY', and 'OPTIONAL' in this document are to be interpreted as 'MAY', and 'OPTIONAL' in this document are to be interpreted as
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here. they appear in all capitals, as shown here.
Copyright (c) 2019 IETF Trust and the persons identified as Copyright (c) 2020 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; This version of this YANG module is part of RFC XXXX;
see the RFC itself for full legal notices."; see the RFC itself for full legal notices.";
revision 2019-11-04 { revision 2020-06-26 {
description description
"This revision adds the following new data types: "This revision adds the following new data types:
- date, time - date, time
- hours32, minutes32, seconds32, centiseconds32, milliseconds32, - hours32, minutes32, seconds32, centiseconds32, milliseconds32,
- microseconds32, microseconds64, nanoseconds32, nanoseconds64 - microseconds32, microseconds64, nanoseconds32, nanoseconds64
- revision-identifier, node-instance-identifier"; - revision-identifier, node-instance-identifier";
reference reference
"RFC XXXX: Common YANG Data Types"; "RFC XXXX: Common YANG Data Types";
} }
skipping to change at page 13, line 16 skipping to change at page 13, line 16
to the OBJECT IDENTIFIER type of the SMIv2."; to the OBJECT IDENTIFIER type of the SMIv2.";
reference reference
"RFC 2578: Structure of Management Information Version 2 "RFC 2578: Structure of Management Information Version 2
(SMIv2)"; (SMIv2)";
} }
/*** collection of types related to date and time ***/ /*** collection of types related to date and time ***/
typedef date-and-time { typedef date-and-time {
type string { type string {
pattern '\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(\.\d+)?' pattern '\d{4}-(1[0-2]|0[1-9])-(0[1-9]|[1|2][0-9]|3[0-1])'
+ '(Z|[\+\-]\d{2}:\d{2})'; + 'T(0[0-9]|1[0-9]|2[0-3]):[0-5][0-9]:[0-5][0-9](\.\d+)?'
+ '(Z|[\+\-]((1[0-3]|0[0-9]):([0-5][0-9])|14:00))?';
} }
description description
"The date-and-time type is a profile of the ISO 8601 "The date-and-time type is a profile of the ISO 8601
standard for representation of dates and times using the standard for representation of dates and times using the
Gregorian calendar. The profile is defined by the Gregorian calendar. The profile is defined by the
date-time production in Section 5.6 of RFC 3339. date-time production in Section 5.6 of RFC 3339.
The date-and-time type is compatible with the dateTime XML The date-and-time type is compatible with the dateTime XML
schema type with the following notable exceptions: schema type with the following notable exceptions:
(a) The date-and-time type does not allow negative years. (a) The date-and-time type does not allow negative years.
(b) The date-and-time time-offset -00:00 indicates an unknown (b) The time-offset -00:00 indicates that the date-and-time
time zone (see RFC 3339) while -00:00 and +00:00 and Z value is reported in UTC and that the local time zone
all represent the same time zone in dateTime. reference point is unknown. The time-offsets +00:00 and Z
both indicate that the date-and-time value is reported in
UTC and that the local time reference point is UTC (see RFC
3339 section 4.3).
(c) The canonical format (see below) of date-and-time values (c) The canonical format (see below) of date-and-time values
differs from the canonical format used by the dateTime XML differs from the canonical format used by the dateTime XML
schema type, which requires all times to be in UTC using schema type, which requires all times to be in UTC using
the time-offset 'Z'. the time-offset 'Z'.
This type is not equivalent to the DateAndTime textual This type is not equivalent to the DateAndTime textual
convention of the SMIv2 since RFC 3339 uses a different convention of the SMIv2 since RFC 3339 uses a different
separator between full-date and full-time and provides separator between full-date and full-time and provides
higher resolution of time-secfrac. higher resolution of time-secfrac.
The canonical format for date-and-time values with a known time The canonical format for date-and-time values with a known time
zone uses a numeric time zone offset that is calculated using 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 configured known offset to UTC time. A change of
the device's offset to UTC time will cause date-and-time values the device's offset to UTC time will cause date-and-time values
to change accordingly. Such changes might happen periodically to change accordingly. Such changes might happen periodically
in case a server follows automatically daylight saving time in case a server follows automatically daylight saving time
(DST) time zone offset changes. The canonical format for (DST) time zone offset changes. The canonical format for
date-and-time values with an unknown time zone (usually date-and-time values with an unknown time zone (usually
referring to the notion of local time) uses the time-offset referring to the notion of local time) uses the time-offset
-00:00."; -00:00, i.e., date-and-time values must be reported in UTC.";
reference reference
"RFC 3339: Date and Time on the Internet: Timestamps "RFC 3339: Date and Time on the Internet: Timestamps
RFC 2579: Textual Conventions for SMIv2 RFC 2579: Textual Conventions for SMIv2
XSD-TYPES: XML Schema Part 2: Datatypes Second Edition"; XSD-TYPES: XML Schema Part 2: Datatypes Second Edition";
} }
typedef date { typedef date {
type string { type string {
pattern '\d{4}-\d{2}-\d{2}' pattern '\d{4}-(1[0-2]|0[1-9])-(0[1-9]|[1|2][0-9]|3[0-1])'
+ '(Z|[\+\-]\d{2}:\d{2})'; + '(Z|[\+\-]((1[0-3]|0[0-9]):([0-5][0-9])|14:00))?';
} }
description description
"The date type represents a time-interval of the length "The date type represents a time-interval of the length
of a day, i.e., 24 hours. of a day, i.e., 24 hours.
The date type is compatible with the date XML schema The date type is compatible with the date XML schema
type with the following notable exceptions: type with the following notable exceptions:
(a) The date type does not allow negative years. (a) The date type does not allow negative years.
(b) The date time-offset -00:00 indicates an unknown (b) The time-offset -00:00 indicates that the date value is
time zone (see RFC 3339) while -00:00 and +00:00 and Z reported in UTC and that the local time zone reference point
all represent the same time zone in date. is unknown. The time-offsets +00:00 and Z both indicate that
the date value is reported in UTC and that the local time
reference point is UTC (see RFC 3339 section 4.3).
(c) The canonical format (see below) of data values (c) The canonical format (see below) of data values
differs from the canonical format used by the date XML differs from the canonical format used by the date XML
schema type, which requires all times to be in UTC using schema type, which requires all times to be in UTC using
the time-offset 'Z'. the time-offset 'Z'.
The canonical format for date values with a known time The canonical format for date values with a known time
zone uses a numeric time zone offset that is calculated using 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 configured known offset to UTC time. A change of
the device's offset to UTC time will cause date values the device's offset to UTC time will cause date values
to change accordingly. Such changes might happen periodically to change accordingly. Such changes might happen periodically
in case a server follows automatically daylight saving time in case a server follows automatically daylight saving time
(DST) time zone offset changes. The canonical format for (DST) time zone offset changes. The canonical format for
date values with an unknown time zone (usually referring date values with an unknown time zone (usually referring
to the notion of local time) uses the time-offset -00:00."; to the notion of local time) uses the time-offset -00:00,
i.e., date values must be reported in UTC.";
reference reference
"RFC 3339: Date and Time on the Internet: Timestamps "RFC 3339: Date and Time on the Internet: Timestamps
XSD-TYPES: XML Schema Part 2: Datatypes Second Edition"; XSD-TYPES: XML Schema Part 2: Datatypes Second Edition";
} }
/* /*
* DISCUSS: * DISCUSS:
* - XML schema seems to use a different canonical format, we * - XML schema seems to use a different canonical format, we
* need to take a closer look how to define the canonical format * need to take a closer look how to define the canonical format
* given that a data really identifies a 24 hour interval and * given that a date really identifies a 24 hour interval and
* what XSD means with 'interval midpoint'. * what XSD means with 'interval midpoint'.
*/ */
typedef time { typedef time {
type string { type string {
pattern '\d{2}:\d{2}:\d{2}(\.\d+)?' pattern '(0[0-9]|1[0-9]|2[0-3]):[0-5][0-9]:[0-5][0-9](\.\d+)?'
+ '(Z|[\+\-]\d{2}:\d{2})'; + '(Z|[\+\-]((1[0-3]|0[0-9]):([0-5][0-9])|14:00))?';
} }
description description
"The time type represents an instance of time of zero-duration "The time type represents an instance of time of zero-duration
that recurs every day. that recurs every day.
The time type is compatible with the time XML schema The time type is compatible with the time XML schema
type with the following notable exceptions: type with the following notable exceptions:
(a) The time time-offset -00:00 indicates an unknown (a) The time-offset -00:00 indicates that the time value is
time zone (see RFC 3339) while -00:00 and +00:00 and Z reported in UTC and that the local time zone reference point
all represent the same time zone in time. is unknown. The time-offsets +00:00 and Z both indicate that
the time value is reported in UTC and that the local time
reference point is UTC (see RFC 3339 section 4.3).
(c) The canonical format (see below) of time values (c) The canonical format (see below) of time values
differs from the canonical format used by the time XML differs from the canonical format used by the time XML
schema type, which requires all times to be in UTC using schema type, which requires all times to be in UTC using
the time-offset 'Z'. the time-offset 'Z'.
The canonical format for time values with a known time The canonical format for time values with a known time
zone uses a numeric time zone offset that is calculated using 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 configured known offset to UTC time. A change of
the device's offset to UTC time will cause time values the device's offset to UTC time will cause time values
to change accordingly. Such changes might happen periodically to change accordingly. Such changes might happen periodically
in case a server follows automatically daylight saving time in case a server follows automatically daylight saving time
(DST) time zone offset changes. The canonical format for (DST) time zone offset changes. The canonical format for
time values with an unknown time zone (usually referring time values with an unknown time zone (usually referring
to the notion of local time) uses the time-offset -00:00."; to the notion of local time) uses the time-offset -00:00,
i.e., time values must be reported in UTC.";
reference reference
"RFC 3339: Date and Time on the Internet: Timestamps "RFC 3339: Date and Time on the Internet: Timestamps
XSD-TYPES: XML Schema Part 2: Datatypes Second Edition"; XSD-TYPES: XML Schema Part 2: Datatypes Second Edition";
} }
typedef hours32 { typedef hours32 {
type int32; type int32;
units "hours"; units "hours";
description description
"A period of time, measured in units of hours. "A period of time, measured in units of hours.
The maximum time period that can be expressed is in the The maximum time period that can be expressed is in the
range [89478485 days 08:00:00 to 89478485 days 07:00:00]. range [89478485 days 08:00:00 to 89478485 days 07:00:00].
This type should be range restricted in situations This type should be range restricted in situations
skipping to change at page 21, line 42 skipping to change at page 22, line 4
followed by an arbitrary sequence of alphabetic or followed by an arbitrary sequence of alphabetic or
numeric characters, underscores, hyphens, or dots. numeric characters, underscores, hyphens, or dots.
A YANG identifier MUST NOT start with any possible A YANG identifier MUST NOT start with any possible
combination of the lowercase or uppercase character combination of the lowercase or uppercase character
sequence 'xml'."; sequence 'xml'.";
reference reference
"RFC 6020: YANG - A Data Modeling Language for the Network "RFC 6020: YANG - A Data Modeling Language for the Network
Configuration Protocol (NETCONF)"; Configuration Protocol (NETCONF)";
} }
typedef revision-identifier { typedef revision-identifier {
type date { type date {
pattern '\d{4}-\d{2}-\d{2}'; pattern '\d{4}-(1[0-2]|0[1-9])-(0[1-9]|[1|2][0-9]|3[0-1])';
} }
description description
"Represents a specific revision of a YANG module by means of "Represents a specific revision of a YANG module by means of
a date value without a time zone."; a date value without a time zone.";
} }
typedef node-instance-identifier { typedef node-instance-identifier {
type xpath1.0; type xpath1.0;
description description
"Path expression used to represent a data node, action, "Path expression used to represent a data node, action,
or notification instance-identifier string. or notification instance-identifier string.
A node-instance-identifier value is an unrestricted A node-instance-identifier value is an unrestricted
YANG instance-identifier expression or the special YANG instance-identifier expression or the special
value '/', which refers to the entire accessible tree. value '/', which refers to the entire accessible tree.
skipping to change at page 24, line 41 skipping to change at page 24, line 41
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 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
'MAY', and 'OPTIONAL' in this document are to be interpreted as 'MAY', and 'OPTIONAL' in this document are to be interpreted as
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here. they appear in all capitals, as shown here.
Copyright (c) 2019 IETF Trust and the persons identified as Copyright (c) 2020 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; This version of this YANG module is part of RFC XXXX;
see the RFC itself for full legal notices."; see the RFC itself for full legal notices.";
revision 2019-11-04 { revision 2020-06-26 {
description description
"This revision adds the following new data types: "This revision adds the following new data types:
- ip-address-and-prefix - ip-address-and-prefix
- ipv4-address-and-prefix - ipv4-address-and-prefix
- ipv6-address-and-prefix - ipv6-address-and-prefix
- email-address"; - email-address";
reference reference
"RFC XXXX: Common YANG Data Types"; "RFC XXXX: Common YANG Data Types";
} }
skipping to change at page 40, line 12 skipping to change at page 40, line 12
- David Partain (Ericsson) - David Partain (Ericsson)
- Phil Shafer (Juniper Networks) - Phil Shafer (Juniper Networks)
8. Acknowledgments 8. Acknowledgments
The editor wishes to thank the following individuals for providing The editor wishes to thank the following individuals for providing
helpful comments on various versions of this document: Andy Bierman, helpful comments on various versions of this document: Andy Bierman,
Martin Bjorklund, Benoit Claise, Joel M. Halpern, Ladislav Lhotka, Martin Bjorklund, Benoit Claise, Joel M. Halpern, Ladislav Lhotka,
Lars-Johan Liman, and Dan Romascanu. Lars-Johan Liman, and Dan Romascanu.
Juergen Schoenwaelder was partly funded by Flamingo, a Network of Juergen Schoenwaelder was partly funded by the European Union's
Excellence project (ICT-318488) supported by the European Commission Seventh Framework Programme under Grant Agreement ICT-318488 and the
under its Seventh Framework Programme. European Union's Horizon 2020 research and innovation programme under
Grant Agreement No. 830927.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997, RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 47, line 5 skipping to change at page 46, line 27
o revision-identifier, node-instance-identifier o revision-identifier, node-instance-identifier
The following new data types have been added to the ietf-inet-types The following new data types have been added to the ietf-inet-types
module: module:
o ip-address-and-prefix, ipv4-address-and-prefix, ipv6-address-and- o ip-address-and-prefix, ipv4-address-and-prefix, ipv6-address-and-
prefix prefix
o email-address o email-address
This version addresses errata 4076 and 5105 of RFC 6991.
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. 25 change blocks. 
34 lines changed or deleted 46 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/