draft-ietf-netmod-rfc6991-bis-01.txt   draft-ietf-netmod-rfc6991-bis-02.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) July 21, 2019 Obsoletes: 6991 (if approved) November 4, 2019
Intended status: Standards Track Intended status: Standards Track
Expires: January 22, 2020 Expires: May 7, 2020
Common YANG Data Types Common YANG Data Types
draft-ietf-netmod-rfc6991-bis-01 draft-ietf-netmod-rfc6991-bis-02
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 January 22, 2020. This Internet-Draft will expire on May 7, 2020.
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 21 skipping to change at page 2, line 21
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
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 . . . . . . . . . . . . . . . . . . . 7
4. Internet-Specific Derived Types . . . . . . . . . . . . . . . 22 4. Internet-Specific Derived Types . . . . . . . . . . . . . . . 24
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
6. Security Considerations . . . . . . . . . . . . . . . . . . . 36 6. Security Considerations . . . . . . . . . . . . . . . . . . . 38
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 37 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 39
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 40
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41
9.1. Normative References . . . . . . . . . . . . . . . . . . . 39 9.1. Normative References . . . . . . . . . . . . . . . . . . . 41
9.2. Informative References . . . . . . . . . . . . . . . . . . 40 9.2. Informative References . . . . . . . . . . . . . . . . . . 42
Appendix A. Changes from RFC 6991 . . . . . . . . . . . . . . . . 44 Appendix A. Changes from RFC 6991 . . . . . . . . . . . . . . . . 46
Appendix B. Changes from RFC 6021 . . . . . . . . . . . . . . . . 45 Appendix B. Changes from RFC 6021 . . . . . . . . . . . . . . . . 47
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 46 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 48
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 4, line 32 skipping to change at page 5, line 19
| 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 |
| date-and-time | - | | date-and-time | - |
| date | - | | date | - |
| time | - | | time | - |
| hours | - | | hours32 | - |
| minutes | - | | minutes32 | - |
| seconds | - | | seconds32 | - |
| centiseconds | - | | centiseconds32 | TimeInterval (SNMPv2-TC) |
| milliseconds | - | | milliseconds32 | - |
| microseconds | - | | microseconds32 | - |
| nanoseconds | - | | microseconds64 | - |
| nanoseconds32 | - |
| nanoseconds64 | - |
| timeticks | TimeTicks (SNMPv2-SMI) | | timeticks | TimeTicks (SNMPv2-SMI) |
| timestamp | TimeStamp (SNMPv2-TC) | | timestamp | TimeStamp (SNMPv2-TC) |
| phys-address | PhysAddress (SNMPv2-TC) | | phys-address | PhysAddress (SNMPv2-TC) |
| mac-address | MacAddress (SNMPv2-TC) | | mac-address | MacAddress (SNMPv2-TC) |
| xpath1.0 | - | | xpath1.0 | - |
| hex-string | - | | hex-string | - |
| uuid | - | | uuid | - |
| dotted-quad | - | | dotted-quad | - |
| yang-identifier | - | | yang-identifier | - |
| revision-identifier | - | | revision-identifier | - |
skipping to change at page 6, line 11 skipping to change at page 7, line 11
+----------------------+--------------------------------------------+ +----------------------+--------------------------------------------+
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],
[RFC5322], [RFC7950], [XPATH], and [XSD-TYPES]. [RFC5322], [RFC7950], [XPATH], and [XSD-TYPES].
<CODE BEGINS> file "ietf-yang-types@2019-07-21.yang" <CODE BEGINS> file "ietf-yang-types@2019-11-04.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 Network Modeling (NETMOD) Working Group"; "IETF Network Modeling (NETMOD) Working Group";
contact contact
skipping to change at page 6, line 51 skipping to change at page 7, line 51
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-07-21 { revision 2019-11-04 {
description description
"This revision adds the following new data types: "This revision adds the following new data types:
- date, time - date, time
- hours, minutes, seconds - hours32, minutes32, seconds32, centiseconds32, milliseconds32,
- centiseconds, milliseconds, microseconds, nanoseconds - 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";
} }
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:
- yang-identifier - yang-identifier
- hex-string - hex-string
skipping to change at page 14, line 43 skipping to change at page 15, line 43
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.";
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 hours { typedef hours32 {
type uint32; 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
range [89478485 days 08:00:00 to 89478485 days 07:00:00].
This type should be range restricted in situations
where only non-negative time periods are desirable,
(i.e., range '0..max').";
} }
typedef minutes { typedef minutes32 {
type uint32; type int32;
units "minutes"; units "minutes";
description description
"A period of time, measured in units of minutes."; "A period of time, measured in units of minutes.
The maximum time period that can be expressed is in the
range [-1491308 days 2:08:00 to 1491308 days 2:07:00].
This type should be range restricted in situations
where only non-negative time periods are desirable,
(i.e., range '0..max').";
} }
typedef seconds { typedef seconds32 {
type uint32; type int32;
units "seconds"; units "seconds";
description description
"A period of time, measured in units of seconds. "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 The maximum time period that can be expressed is in the
seconds."; range [-24855 days 03:14:08 to 24855 days 03:14:07].
This type should be range restricted in situations
where only non-negative time periods are desirable,
(i.e., range '0..max').";
} }
typedef centiseconds { typedef centiseconds32 {
type uint32; type int32;
units "centiseconds"; units "centiseconds";
description description
"A period of time, measured in units of 10^-2 seconds. "A period of time, measured in units of 10^-2 seconds.
The maximum duration that can be expressed is in the
order of 497 days and 2 hours and 27 minutes and 52 The maximum time period that can be expressed is in the
seconds."; range [-248 days 13:13:56 to 248 days 13:13:56].
This type should be range restricted in situations
where only non-negative time periods are desirable,
(i.e., range '0..max').";
} }
typedef milliseconds { typedef milliseconds32 {
type uint32; type int32;
units "milliseconds"; units "milliseconds";
description description
"A period of time, measured in units of 10^-3 seconds. "A period of time, measured in units of 10^-3 seconds.
The maximum duration that can be expressed is in the
order of 49 days and 17 hours and 2 minutes and 47 The maximum time period that can be expressed is in the
seconds."; range [-24 days 20:31:23 to 24 days 20:31:23].
This type should be range restricted in situations
where only non-negative time periods are desirable,
(i.e., range '0..max').";
} }
typedef microseconds { typedef microseconds32 {
type uint32; type int32;
units "microseconds"; units "microseconds";
description description
"A period of time, measured in units of 10^-6 seconds. "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."; The maximum time period that can be expressed is in the
range [-00:35:47 to 00:35:47].
This type should be range restricted in situations
where only non-negative time periods are desirable,
(i.e., range '0..max').";
} }
typedef nanoseconds { typedef microseconds64 {
type uint32; type int64;
units "microseconds";
description
"A period of time, measured in units of 10^-6 seconds.
The maximum time period that can be expressed is in the
range [-106751991 days 04:00:54 to 106751991 days 04:00:54].
This type should be range restricted in situations
where only non-negative time periods are desirable,
(i.e., range '0..max').";
}
typedef nanoseconds32 {
type int32;
units "nanoseconds"; units "nanoseconds";
description description
"A period of time, measured in units of 10^-9 seconds. "A period of time, measured in units of 10^-9 seconds.
The maximum duration that can be expressed is in the
order of 4 seconds."; The maximum time period that can be expressed is in the
range [-00:00:02 to 00:00:02].
This type should be range restricted in situations
where only non-negative time periods are desirable,
(i.e., range '0..max').";
} }
/* typedef nanoseconds64 {
* DISCUSS: type int64;
* - do we need (nano|micro|milli)seconds with 64 bits? units "nanoseconds";
* - do we add typedef timeinterval { type centiseconds description
* { range 0..2147483647 } } for compatibility with SMIv2? "A period of time, measured in units of 10^-9 seconds.
* - some modules use negative minutes, do we care? A _duration_
* does likely not need negative values. However, if minutes are The maximum time period that can be expressed is in the
* used to represent a relative time offset, then negative minutes range [-106753 days 23:12:44 to 106752 days 0:47:16].
* do make sense. Do we have to support durations as well as
* time offsets? This type should be range restricted in situations
*/ where only non-negative time periods are desirable,
(i.e., range '0..max').";
}
typedef timeticks { typedef timeticks {
type uint32; type uint32;
description description
"The timeticks type represents a non-negative integer that "The timeticks type represents a non-negative integer that
represents the time, modulo 2^32 (4294967296 decimal), in represents the time, modulo 2^32 (4294967296 decimal), in
hundredths of a second between two epochs. When a schema hundredths of a second between two epochs. When a schema
node is defined that uses this type, the description of node is defined that uses this type, the description of
the schema node identifies both of the reference epochs. the schema node identifies both of the reference epochs.
skipping to change at page 19, line 47 skipping to change at page 22, line 4
} }
typedef revision-identifier { typedef revision-identifier {
type date { type date {
pattern '\d{4}-\d{2}-\d{2}'; pattern '\d{4}-\d{2}-\d{2}';
} }
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 special "Path expression used to represent a data node, action,
data node, action, or notification instance-identifier or notification instance-identifier string.
string.
A node-instance-identifier value is an A node-instance-identifier value is an unrestricted
unrestricted YANG instance-identifier expression. YANG instance-identifier expression or the special
value '/', which refers to the entire accessible tree.
All the same rules as an instance-identifier apply, All the rules for instance-identifier apply, except that
except that predicates for keys are optional. If a key predicates for keys are optional. If a key predicate is
predicate is missing, then the node-instance-identifier missing, then the node-instance-identifier represents all
represents all possible server instances for that key. possible server instances for that key.
This XML Path Language (XPath) expression is evaluated in the This XML Path Language (XPath) expression is evaluated in the
following context: following context:
o The set of namespace declarations are those in scope on o The set of namespace declarations are those in scope on
the leaf element where this type is used. the leaf element where this type is used.
o The set of variable bindings contains one variable, o The set of variable bindings contains one variable,
'USER', which contains the name of the user of the 'USER', which contains the name of the user of the
current session. current session.
skipping to change at page 20, line 40 skipping to change at page 22, line 44
The accessible tree includes actions and notifications tied The accessible tree includes actions and notifications tied
to data nodes."; to data nodes.";
} }
/* /*
* DISCUSS: * DISCUSS:
* - This is taken from RFC 8341 and the idea is that this definition * - This is taken from RFC 8341 and the idea is that this definition
* is useful without requiring a dependency on NACM * is useful without requiring a dependency on NACM
* - What does the second bullet actually do? Do we keep this? * - 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. * - This interacts with the definition of xpath1.0.
*/ */
/* DISCUSS: /* DISCUSS:
* - It was suggested to add types for longitude, latitude, * - It was suggested to add types for longitude, latitude,
* postal code, country-code. Do we go there or do we leave * postal code, country-code. Do we go there or do we leave
* these for other modules to define? It seems such definitions * these for other modules to define? It seems such definitions
* should go into draft-ietf-netmod-geo-location. * should go into draft-ietf-netmod-geo-location.
*/ */
/* DISCUSS: /* DISCUSS:
* - It was suggested to add percentage types but they tend to differ * - It was suggested to add percentage types but they tend to differ
* widely. However, percentages are also widely used. * widely. However, percentages are also widely used.
*/ */
} }
<CODE ENDS> <CODE ENDS>
skipping to change at page 22, line 8 skipping to change at page 24, line 8
* - It was suggested to add percentage types but they tend to differ * - It was suggested to add percentage types but they tend to differ
* widely. However, percentages are also widely used. * 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], [RFC2317],
[RFC2474], [RFC2780], [RFC2782], [RFC3289], [RFC3305], [RFC3595], [RFC2460], [RFC2474], [RFC2780], [RFC2782], [RFC3289], [RFC3305],
[RFC3986], [RFC4001], [RFC4007], [RFC4271], [RFC4291], [RFC4340], [RFC3595], [RFC3986], [RFC4001], [RFC4007], [RFC4271], [RFC4291],
[RFC4960], [RFC5017], [RFC5890], [RFC5952], and [RFC6793]. [RFC4340], [RFC4592] [RFC4960], [RFC5017], [RFC5890], [RFC5952], and
[RFC6793].
<CODE BEGINS> file "ietf-inet-types@2019-07-021.yang" <CODE BEGINS> file "ietf-inet-types@2019-11-04.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 Network Modeling (NETMOD) Working Group"; "IETF Network Modeling (NETMOD) Working Group";
contact contact
skipping to change at page 23, line 5 skipping to change at page 25, line 5
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-07-21 { revision 2019-11-04 {
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 31, line 25 skipping to change at page 33, line 25
typedef domain-name { typedef domain-name {
type string { type string {
length "1..253"; length "1..253";
pattern pattern
'((([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.)*' '((([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.)*'
+ '([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.?)' + '([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.?)'
+ '|\.'; + '|\.';
} }
description description
"The domain-name type represents a DNS domain name. The "The domain-name type represents a DNS domain name. The
name SHOULD be fully qualified whenever possible. name SHOULD be fully qualified whenever possible. This
type does not support wildcards (see RFC 4592) or
classless in-addr.arpa delegations (see RFC 2317).
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. Note that Internet host names have a
domain names, including names used for A or AAAA records stricter syntax (described in RFC 952) than the DNS
(host names) and other records, such as SRV records. Note recommendations in RFCs 1034 and 1123, and that systems
that Internet host names have a stricter syntax (described that want to store host names in schema node instances
in RFC 952) than the DNS recommendations in RFCs 1034 and using the domain-name type are recommended to adhere to
1123, and that systems that want to store host names in this stricter standard to ensure interoperability.
schema node instances using the domain-name type are
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 32, line 16 skipping to change at page 34, line 15
resolver. resolver.
Domain-name values use the US-ASCII encoding. Their canonical Domain-name values use the US-ASCII encoding. Their canonical
format uses lowercase US-ASCII characters. Internationalized format uses lowercase US-ASCII characters. Internationalized
domain names MUST be A-labels as per RFC 5890."; domain names MUST be A-labels as per RFC 5890.";
reference reference
"RFC 952: DoD Internet Host Table Specification "RFC 952: DoD Internet Host Table Specification
RFC 1034: Domain Names - Concepts and Facilities RFC 1034: Domain Names - Concepts and Facilities
RFC 1123: Requirements for Internet Hosts -- Application RFC 1123: Requirements for Internet Hosts -- Application
and Support and Support
RFC 2317: Classless IN-ADDR.ARPA delegation
RFC 2782: A DNS RR for specifying the location of services RFC 2782: A DNS RR for specifying the location of services
(DNS SRV) (DNS SRV)
RFC 4592: The Role of Wildcards in the Domain Name System
RFC 5890: Internationalized Domain Names in Applications RFC 5890: Internationalized Domain Names in Applications
(IDNA): Definitions and Document Framework"; (IDNA): Definitions and Document Framework";
} }
/*
* DISCUSS:
* - Lada suggested to have a type that supports wildcards and
* the forward slash character.
*/
typedef host { typedef host {
type union { type union {
type inet:ip-address; type inet:ip-address;
type inet:domain-name; type inet:domain-name;
} }
description description
"The host type represents either an IP address or a DNS "The host type represents either an IP address or a DNS
domain name."; domain name.";
} }
skipping to change at page 34, line 21 skipping to change at page 36, line 16
* perhaps addr-spec is sufficient, this is also the * perhaps addr-spec is sufficient, this is also the
* format allowed in mailto: URIs (mailto: seems to use * format allowed in mailto: URIs (mailto: seems to use
* only a subset of addr-spec which may be good enough * only a subset of addr-spec which may be good enough
* here as well). * here as well).
* - Need to define a pattern that has a meaningful trade-off * - Need to define a pattern that has a meaningful trade-off
* between precision and complexity (there are very tight * between precision and complexity (there are very tight
* pattern that are very long and complex). The current * pattern that are very long and complex). The current
* pattern does not take care of quoted-string, obs-local-part, * pattern does not take care of quoted-string, obs-local-part,
* domain-literal, obs-domain. * domain-literal, obs-domain.
*/ */
/*
* DISCUSS:
* - There was a request to add types for URI fields (scheme,
* authority, path, query, fragment) but it is not clear how
* commonly useful these types are, the WG was pretty silent
* about this proposal. On the technical side, it is unclear
* whether data is represented with percent escapes resolved
* or not. (Mahesh's proposal does not spell this out, the
* pattern does not allow the % character, which may be wrong.)
*/
} }
<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 41, line 7 skipping to change at page 43, line 7
[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts -
Application and Support", STD 3, RFC 1123, DOI 10.17487/ Application and Support", STD 3, RFC 1123, DOI 10.17487/
RFC1123, October 1989, RFC1123, October 1989,
<https://www.rfc-editor.org/info/rfc1123>. <https://www.rfc-editor.org/info/rfc1123>.
[RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, [RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation,
selection, and registration of an Autonomous System (AS)", selection, and registration of an Autonomous System (AS)",
BCP 6, RFC 1930, DOI 10.17487/RFC1930, March 1996, BCP 6, RFC 1930, DOI 10.17487/RFC1930, March 1996,
<https://www.rfc-editor.org/info/rfc1930>. <https://www.rfc-editor.org/info/rfc1930>.
[RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN-
ADDR.ARPA delegation", BCP 20, RFC 2317, DOI 10.17487/
RFC2317, March 1998,
<https://www.rfc-editor.org/info/rfc2317>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <https://www.rfc-editor.org/info/rfc2460>. December 1998, <https://www.rfc-editor.org/info/rfc2460>.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS "Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998, DOI 10.17487/RFC2474, December 1998,
<https://www.rfc-editor.org/info/rfc2474>. <https://www.rfc-editor.org/info/rfc2474>.
skipping to change at page 42, line 31 skipping to change at page 44, line 36
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340, Congestion Control Protocol (DCCP)", RFC 4340,
DOI 10.17487/RFC4340, March 2006, DOI 10.17487/RFC4340, March 2006,
<https://www.rfc-editor.org/info/rfc4340>. <https://www.rfc-editor.org/info/rfc4340>.
[RFC4502] Waldbusser, S., "Remote Network Monitoring Management [RFC4502] Waldbusser, S., "Remote Network Monitoring Management
Information Base Version 2", RFC 4502, DOI 10.17487/ Information Base Version 2", RFC 4502, DOI 10.17487/
RFC4502, May 2006, RFC4502, May 2006,
<https://www.rfc-editor.org/info/rfc4502>. <https://www.rfc-editor.org/info/rfc4502>.
[RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name
System", RFC 4592, DOI 10.17487/RFC4592, July 2006,
<https://www.rfc-editor.org/info/rfc4592>.
[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, [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
skipping to change at page 44, line 13 skipping to change at page 46, line 13
<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 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 date, time o date, time
o hours, minutes, seconds o hours32, minutes32, seconds32, centiseconds32, milliseconds32,
o centiseconds, milliseconds, microseconds, nanoseconds o microseconds32, microseconds64, nanoseconds32, nanoseconds64
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
 End of changes. 43 change blocks. 
103 lines changed or deleted 171 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/