draft-ietf-netmod-rfc6021-bis-02.txt   draft-ietf-netmod-rfc6021-bis-03.txt 
Network Working Group J. Schoenwaelder, Ed. Network Working Group J. Schoenwaelder, Ed.
Internet-Draft Jacobs University Internet-Draft Jacobs University
Obsoletes: 6021 (if approved) May 8, 2013 Obsoletes: 6021 (if approved) May 16, 2013
Intended status: Standards Track Intended status: Standards Track
Expires: November 9, 2013 Expires: November 17, 2013
Common YANG Data Types Common YANG Data Types
draft-ietf-netmod-rfc6021-bis-02 draft-ietf-netmod-rfc6021-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
6021. 6021.
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 November 9, 2013. This Internet-Draft will expire on November 17, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 23 skipping to change at page 2, line 23
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 . . . . . . . . . . . . . . . 17
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
6. Security Considerations . . . . . . . . . . . . . . . . . . . 29 6. Security Considerations . . . . . . . . . . . . . . . . . . . 28
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 30 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 29
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
9.1. Normative References . . . . . . . . . . . . . . . . . . . 32 9.1. Normative References . . . . . . . . . . . . . . . . . . . 31
9.2. Informative References . . . . . . . . . . . . . . . . . . 32 9.2. Informative References . . . . . . . . . . . . . . . . . . 31
Appendix A. Changes from RFC 6021 . . . . . . . . . . . . . . . . 36 Appendix A. Changes from RFC 6021 . . . . . . . . . . . . . . . . 35
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 37 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 36
1. Introduction 1. Introduction
YANG [RFC6020] is a data modeling language used to model YANG [RFC6020] 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 6, line 11 skipping to change at page 6, 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],
[RFC6020], [XPATH], and [XSD-TYPES]. [RFC6020], [XPATH], and [XSD-TYPES].
<CODE BEGINS> file "ietf-yang-types@2013-05-08.yang" <CODE BEGINS> file "ietf-yang-types@2013-05-16.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 (NETCONF Data Modeling Language) Working Group";
contact contact
skipping to change at page 6, line 51 skipping to change at page 6, 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; see This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
revision 2013-05-08 { revision 2013-05-16 {
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
- uuid - uuid
- dotted-quad"; - dotted-quad";
reference reference
"RFC XXXX: Common YANG Data Types"; "RFC XXXX: Common YANG Data Types";
} }
skipping to change at page 17, line 9 skipping to change at page 17, line 9
notation, i.e., four octets written as decimal numbers notation, i.e., four octets written as decimal numbers
and separated with the '.' (full stop) character."; and separated with the '.' (full stop) character.";
} }
} }
<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], [RFC3492], [RFC2474], [RFC2780], [RFC2782], [RFC3289], [RFC3305], [RFC3595],
[RFC3595], [RFC3986], [RFC4001], [RFC4007], [RFC4271], [RFC4291], [RFC3986], [RFC4001], [RFC4007], [RFC4271], [RFC4291], [RFC4340],
[RFC4340], [RFC4960], [RFC5017], [RFC5891], [RFC5952], and [RFC6793]. [RFC4960], [RFC5017], [RFC5890], [RFC5952], and [RFC6793].
<CODE BEGINS> file "ietf-inet-types@2013-05-08.yang" <CODE BEGINS> file "ietf-inet-types@2013-05-16.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 (NETCONF Data Modeling Language) Working Group";
contact contact
skipping to change at page 18, line 5 skipping to change at page 18, 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; see This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
revision 2013-05-08 { revision 2013-05-16 {
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";
reference reference
"RFC XXXX: Common YANG Data Types"; "RFC XXXX: Common YANG Data Types";
} }
revision 2010-09-24 { revision 2010-09-24 {
skipping to change at page 22, line 9 skipping to change at page 22, line 9
"The ipv6-address type represents an IPv6 address in full, "The ipv6-address type represents an IPv6 address in full,
mixed, shortened, and shortened-mixed notation. The IPv6 mixed, shortened, and shortened-mixed notation. The IPv6
address may include a zone index, separated by a % sign. address may include a zone index, separated by a % sign.
The zone index is used to disambiguate identical address The zone index is used to disambiguate identical address
values. For link-local addresses, the zone index will values. For link-local addresses, the zone index will
typically be the interface index number or the name of an typically be the interface index number or the name of an
interface. If the zone index is not present, the default interface. If the zone index is not present, the default
zone of the device will be used. zone of the device will be used.
The canonical format of IPv6 addresses uses the compressed The canonical format of IPv6 addresses uses the textual
format described in RFC 4291, Section 2.2, item 2 with the representation defined in Section 4 of RFC 5952. The
following additional rules: the :: substitution must be canonical format for the zone index is the numerical
applied to the longest sequence of all-zero 16-bit chunks format as described in Section 11.2 of RFC 4007.";
in an IPv6 address. If there is a tie, the first sequence
of all-zero 16-bit chunks is replaced by ::. Single
all-zero 16-bit chunks are not compressed. The canonical
format uses lowercase characters and leading zeros are
not allowed. The canonical format for the zone index is
the numerical format as described in RFC 4007, Section
11.2.";
reference reference
"RFC 4291: IP Version 6 Addressing Architecture "RFC 4291: IP Version 6 Addressing Architecture
RFC 4007: IPv6 Scoped Address Architecture RFC 4007: IPv6 Scoped Address Architecture
RFC 5952: A Recommendation for IPv6 Address Text RFC 5952: A Recommendation for IPv6 Address Text
Representation"; Representation";
} }
typedef ip-address-no-zone { typedef ip-address-no-zone {
type union { type union {
type inet:ipv4-address-no-zone; type inet:ipv4-address-no-zone;
skipping to change at page 24, line 28 skipping to change at page 24, line 21
A prefix length value of n corresponds to an IP address A prefix length value of n corresponds to an IP address
mask that has n contiguous 1-bits from the most mask that has n contiguous 1-bits from the most
significant bit (MSB) and all other bits set to 0. significant bit (MSB) and all other bits set to 0.
The IPv6 address should have all bits that do not belong The IPv6 address should have all bits that do not belong
to the prefix set to zero. to the prefix set to zero.
The canonical format of an IPv6 prefix has all bits of The canonical format of an IPv6 prefix has all bits of
the IPv6 address set to zero that are not part of the the IPv6 address set to zero that are not part of the
IPv6 prefix. Furthermore, IPv6 address is represented IPv6 prefix. Furthermore, the IPv6 address is represented
in the compressed format described in RFC 4291, Section as defined in Section 4 of RFC 5952.";
2.2, item 2 with the following additional rules: the ::
substitution must be applied to the longest sequence of
all-zero 16-bit chunks in an IPv6 address. If there is
a tie, the first sequence of all-zero 16-bit chunks is
replaced by ::. Single all-zero 16-bit chunks are not
compressed. The canonical format uses lowercase
characters and leading zeros are not allowed.";
reference reference
"RFC 4291: IP Version 6 Addressing Architecture"; "RFC 5952: A Recommendation for IPv6 Address Text
Representation";
} }
/*** collection of domain name and URI types ***/ /*** collection of domain name and URI types ***/
typedef domain-name { typedef domain-name {
type string { type string {
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]\.?)'
+ '|\.'; + '|\.';
skipping to change at page 25, line 37 skipping to change at page 25, line 24
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
may require to query multiple DNS records (e.g., A for IPv4 may require to query multiple DNS records (e.g., A for IPv4
and AAAA for IPv6). The order of the resolution process and and AAAA for IPv6). The order of the resolution process and
which DNS record takes precedence can either be defined which DNS record takes precedence can either be defined
explicitely or it may depend on the configuration of the explicitely or it may depend on the configuration of the
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 encoded in punycode as described in RFC domain names MUST be A-labels as per RFC 5890.";
3492";
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 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 3492: Punycode: A Bootstring encoding of Unicode for RFC 5890: Internationalizing Domain Names in Applications
Internationalized Domain Names in Applications (IDNA): Definitions and Document Framework";
(IDNA)
RFC 5891: Internationalizing Domain Names in Applications
(IDNA): Protocol";
} }
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 32, line 15 skipping to change at page 31, line 15
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, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the
Internet: Timestamps", RFC 3339, July 2002. Internet: Timestamps", RFC 3339, July 2002.
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode
for Internationalized Domain Names in Applications
(IDNA)", RFC 3492, March 2003.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. January 2004.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005. RFC 3986, January 2005.
[RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and
B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, B. Zill, "IPv6 Scoped Address Architecture", RFC 4007,
March 2005. March 2005.
skipping to change at page 34, line 43 skipping to change at page 33, line 38
[RFC4502] Waldbusser, S., "Remote Network Monitoring Management [RFC4502] Waldbusser, S., "Remote Network Monitoring Management
Information Base Version 2", RFC 4502, May 2006. Information Base Version 2", RFC 4502, May 2006.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", [RFC4960] Stewart, R., "Stream Control Transmission Protocol",
RFC 4960, September 2007. RFC 4960, September 2007.
[RFC5017] McWalter, D., "MIB Textual Conventions for Uniform [RFC5017] McWalter, D., "MIB Textual Conventions for Uniform
Resource Identifiers (URIs)", RFC 5017, September 2007. Resource Identifiers (URIs)", RFC 5017, September 2007.
[RFC5891] Klensin, J., "Internationalizing Domain Names in [RFC5890] Klensin, J., "Internationalizing Domain Names in
Applications (IDNA): Protocol", RFC 5891, August 2010. Applications (IDNA): Definitions and Document Framework",
RFC 5890, August 2010.
[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, August 2010. Address Text Representation", RFC 5952, August 2010.
[RFC6021] Schoenwaelder, J., "Common YANG Data Types", RFC 6021, [RFC6021] Schoenwaelder, J., "Common YANG Data Types", RFC 6021,
October 2010. October 2010.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "NETCONF Configuration Protocol and A. Bierman, Ed., "NETCONF Configuration Protocol
(NETCONF)", RFC 6241, June 2011. (NETCONF)", RFC 6241, June 2011.
 End of changes. 18 change blocks. 
54 lines changed or deleted 35 lines changed or added

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