-<?xml version="1.0" encoding="UTF-8"?>\r
-<module name="ietf-inet-types"\r
- xmlns="urn:ietf:params:xml:ns:yang:yin:1"\r
- xmlns:inet="urn:ietf:params:xml:ns:yang:ietf-inet-types">\r
- <namespace uri="urn:ietf:params:xml:ns:yang:ietf-inet-types"/>\r
- <prefix value="inet"/>\r
- <organization>\r
- <text>IETF NETMOD (NETCONF Data Modeling Language) Working Group</text>\r
- </organization>\r
- <contact>\r
- <text>WG Web: <http://tools.ietf.org/wg/netmod/>\r
-WG List: <mailto:netmod@ietf.org>\r
-\r
-WG Chair: David Partain\r
- <mailto:david.partain@ericsson.com>\r
-\r
-WG Chair: David Kessens\r
- <mailto:david.kessens@nsn.com>\r
-\r
-Editor: Juergen Schoenwaelder\r
- <mailto:j.schoenwaelder@jacobs-university.de></text>\r
- </contact>\r
- <description>\r
- <text>This module contains a collection of generally useful derived\r
-YANG data types for Internet addresses and related things.\r
-\r
-Copyright (c) 2010 IETF Trust and the persons identified as\r
-authors of the code. All rights reserved.\r
-\r
-\r
-\r
-Redistribution and use in source and binary forms, with or without\r
-modification, is permitted pursuant to, and subject to the license\r
-terms contained in, the Simplified BSD License set forth in Section\r
-4.c of the IETF Trust's Legal Provisions Relating to IETF Documents\r
-(http://trustee.ietf.org/license-info).\r
-\r
-This version of this YANG module is part of RFC 6021; see\r
-the RFC itself for full legal notices.</text>\r
- </description>\r
- <revision date="2010-09-24">\r
- <description>\r
- <text>Initial revision.</text>\r
- </description>\r
- <reference>\r
- <text>RFC 6021: Common YANG Data Types</text>\r
- </reference>\r
- </revision>\r
- <typedef name="ip-version">\r
- <type name="enumeration">\r
- <enum name="unknown">\r
- <value value="0"/>\r
- <description>\r
- <text>An unknown or unspecified version of the Internet protocol.</text>\r
- </description>\r
- </enum>\r
- <enum name="ipv4">\r
- <value value="1"/>\r
- <description>\r
- <text>The IPv4 protocol as defined in RFC 791.</text>\r
- </description>\r
- </enum>\r
- <enum name="ipv6">\r
- <value value="2"/>\r
- <description>\r
- <text>The IPv6 protocol as defined in RFC 2460.</text>\r
- </description>\r
- </enum>\r
- </type>\r
- <description>\r
- <text>This value represents the version of the IP protocol.\r
-\r
-In the value set and its semantics, this type is equivalent\r
-to the InetVersion textual convention of the SMIv2.</text>\r
- </description>\r
- <reference>\r
- <text>RFC 791: Internet Protocol\r
-RFC 2460: Internet Protocol, Version 6 (IPv6) Specification\r
-RFC 4001: Textual Conventions for Internet Network Addresses</text>\r
- </reference>\r
- </typedef>\r
- <typedef name="dscp">\r
- <type name="uint8">\r
- <range value="0..63"/>\r
- </type>\r
- <description>\r
- <text>The dscp type represents a Differentiated Services Code-Point\r
-that may be used for marking packets in a traffic stream.\r
-\r
-In the value set and its semantics, this type is equivalent\r
-to the Dscp textual convention of the SMIv2.</text>\r
- </description>\r
- <reference>\r
- <text>RFC 3289: Management Information Base for the Differentiated\r
- Services Architecture\r
-RFC 2474: Definition of the Differentiated Services Field\r
- (DS Field) in the IPv4 and IPv6 Headers\r
-RFC 2780: IANA Allocation Guidelines For Values In\r
- the Internet Protocol and Related Headers</text>\r
- </reference>\r
- </typedef>\r
- <typedef name="ipv6-flow-label">\r
- <type name="uint32">\r
- <range value="0..1048575"/>\r
- </type>\r
- <description>\r
- <text>The flow-label type represents flow identifier or Flow Label\r
-in an IPv6 packet header that may be used to discriminate\r
-traffic flows.\r
-\r
-In the value set and its semantics, this type is equivalent\r
-to the IPv6FlowLabel textual convention of the SMIv2.</text>\r
- </description>\r
- <reference>\r
- <text>RFC 3595: Textual Conventions for IPv6 Flow Label\r
-RFC 2460: Internet Protocol, Version 6 (IPv6) Specification</text>\r
- </reference>\r
- </typedef>\r
- <typedef name="port-number">\r
- <type name="uint16">\r
- <range value="0..65535"/>\r
- </type>\r
- <description>\r
- <text>The port-number type represents a 16-bit port number of an\r
-Internet transport layer protocol such as UDP, TCP, DCCP, or\r
-SCTP. Port numbers are assigned by IANA. A current list of\r
-all assignments is available from <http://www.iana.org/>.\r
-\r
-Note that the port number value zero is reserved by IANA. In\r
-situations where the value zero does not make sense, it can\r
-be excluded by subtyping the port-number type.\r
-\r
-In the value set and its semantics, this type is equivalent\r
-to the InetPortNumber textual convention of the SMIv2.</text>\r
- </description>\r
- <reference>\r
- <text>RFC 768: User Datagram Protocol\r
-RFC 793: Transmission Control Protocol\r
-RFC 4960: Stream Control Transmission Protocol\r
-RFC 4340: Datagram Congestion Control Protocol (DCCP)\r
-RFC 4001: Textual Conventions for Internet Network Addresses</text>\r
- </reference>\r
- </typedef>\r
- <typedef name="as-number">\r
- <type name="uint32"/>\r
- <description>\r
- <text>The as-number type represents autonomous system numbers\r
-which identify an Autonomous System (AS). An AS is a set\r
-of routers under a single technical administration, using\r
-an interior gateway protocol and common metrics to route\r
-packets within the AS, and using an exterior gateway\r
-protocol to route packets to other ASs'. IANA maintains\r
-the AS number space and has delegated large parts to the\r
-regional registries.\r
-\r
-Autonomous system numbers were originally limited to 16\r
-bits. BGP extensions have enlarged the autonomous system\r
-number space to 32 bits. This type therefore uses an uint32\r
-base type without a range restriction in order to support\r
-a larger autonomous system number space.\r
-\r
-In the value set and its semantics, this type is equivalent\r
-to the InetAutonomousSystemNumber textual convention of\r
-the SMIv2.</text>\r
- </description>\r
- <reference>\r
- <text>RFC 1930: Guidelines for creation, selection, and registration\r
- of an Autonomous System (AS)\r
-RFC 4271: A Border Gateway Protocol 4 (BGP-4)\r
-RFC 4893: BGP Support for Four-octet AS Number Space\r
-RFC 4001: Textual Conventions for Internet Network Addresses</text>\r
- </reference>\r
- </typedef>\r
- <typedef name="ip-address">\r
- <type name="union">\r
- <type name="inet:ipv4-address"/>\r
- <type name="inet:ipv6-address"/>\r
- </type>\r
- <description>\r
- <text>The ip-address type represents an IP address and is IP\r
-version neutral. The format of the textual representations\r
-implies the IP version.</text>\r
- </description>\r
- </typedef>\r
- <typedef name="ipv4-address">\r
- <type name="string">\r
- <pattern value="(([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])(%[\p{N}\p{L}]+)?"/>\r
- </type>\r
- <description>\r
- <text>The ipv4-address type represents an IPv4 address in\r
-dotted-quad notation. The IPv4 address may include a zone\r
-index, separated by a % sign.\r
-\r
-The zone index is used to disambiguate identical address\r
-values. For link-local addresses, the zone index will\r
-typically be the interface index number or the name of an\r
-interface. If the zone index is not present, the default\r
-zone of the device will be used.\r
-\r
-The canonical format for the zone index is the numerical\r
-format</text>\r
- </description>\r
- </typedef>\r
- <typedef name="ipv6-address">\r
- <type name="string">\r
- <pattern value="((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))(%[\p{N}\p{L}]+)?"/>\r
- <pattern value="(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)(%.+)?"/>\r
- </type>\r
- <description>\r
- <text>The ipv6-address type represents an IPv6 address in full,\r
-mixed, shortened, and shortened-mixed notation. The IPv6\r
-address may include a zone index, separated by a % sign.\r
-\r
-\r
-\r
-\r
-\r
-The zone index is used to disambiguate identical address\r
-values. For link-local addresses, the zone index will\r
-typically be the interface index number or the name of an\r
-interface. If the zone index is not present, the default\r
-zone of the device will be used.\r
-\r
-The canonical format of IPv6 addresses uses the compressed\r
-format described in RFC 4291, Section 2.2, item 2 with the\r
-following additional rules: the :: substitution must be\r
-applied to the longest sequence of all-zero 16-bit chunks\r
-in an IPv6 address. If there is a tie, the first sequence\r
-of all-zero 16-bit chunks is replaced by ::. Single\r
-all-zero 16-bit chunks are not compressed. The canonical\r
-format uses lowercase characters and leading zeros are\r
-not allowed. The canonical format for the zone index is\r
-the numerical format as described in RFC 4007, Section\r
-11.2.</text>\r
- </description>\r
- <reference>\r
- <text>RFC 4291: IP Version 6 Addressing Architecture\r
-RFC 4007: IPv6 Scoped Address Architecture\r
-RFC 5952: A Recommendation for IPv6 Address Text Representation</text>\r
- </reference>\r
- </typedef>\r
- <typedef name="ip-prefix">\r
- <type name="union">\r
- <type name="inet:ipv4-prefix"/>\r
- <type name="inet:ipv6-prefix"/>\r
- </type>\r
- <description>\r
- <text>The ip-prefix type represents an IP prefix and is IP\r
-version neutral. The format of the textual representations\r
-implies the IP version.</text>\r
- </description>\r
- </typedef>\r
- <typedef name="ipv4-prefix">\r
- <type name="string">\r
- <pattern value="(([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])/(([0-9])|([1-2][0-9])|(3[0-2]))"/>\r
- </type>\r
- <description>\r
- <text>The ipv4-prefix type represents an IPv4 address prefix.\r
-The prefix length is given by the number following the\r
-slash character and must be less than or equal to 32.\r
-\r
-\r
-\r
-A prefix length value of n corresponds to an IP address\r
-mask that has n contiguous 1-bits from the most\r
-significant bit (MSB) and all other bits set to 0.\r
-\r
-The canonical format of an IPv4 prefix has all bits of\r
-the IPv4 address set to zero that are not part of the\r
-IPv4 prefix.</text>\r
- </description>\r
- </typedef>\r
- <typedef name="ipv6-prefix">\r
- <type name="string">\r
- <pattern value="((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))(/(([0-9])|([0-9]{2})|(1[0-1][0-9])|(12[0-8])))"/>\r
- <pattern value="(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)(/.+)"/>\r
- </type>\r
- <description>\r
- <text>The ipv6-prefix type represents an IPv6 address prefix.\r
-The prefix length is given by the number following the\r
-slash character and must be less than or equal 128.\r
-\r
-A prefix length value of n corresponds to an IP address\r
-mask that has n contiguous 1-bits from the most\r
-significant bit (MSB) and all other bits set to 0.\r
-\r
-The IPv6 address should have all bits that do not belong\r
-to the prefix set to zero.\r
-\r
-The canonical format of an IPv6 prefix has all bits of\r
-the IPv6 address set to zero that are not part of the\r
-IPv6 prefix. Furthermore, IPv6 address is represented\r
-in the compressed format described in RFC 4291, Section\r
-2.2, item 2 with the following additional rules: the ::\r
-substitution must be applied to the longest sequence of\r
-all-zero 16-bit chunks in an IPv6 address. If there is\r
-a tie, the first sequence of all-zero 16-bit chunks is\r
-replaced by ::. Single all-zero 16-bit chunks are not\r
-compressed. The canonical format uses lowercase\r
-characters and leading zeros are not allowed.</text>\r
- </description>\r
- <reference>\r
- <text>RFC 4291: IP Version 6 Addressing Architecture</text>\r
- </reference>\r
- </typedef>\r
- <typedef name="domain-name">\r
- <type name="string">\r
- <pattern value="((([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]\.?)|\."/>\r
- <length value="1..253"/>\r
- </type>\r
- <description>\r
- <text>The domain-name type represents a DNS domain name. The\r
-name SHOULD be fully qualified whenever possible.\r
-\r
-Internet domain names are only loosely specified. Section\r
-3.5 of RFC 1034 recommends a syntax (modified in Section\r
-2.1 of RFC 1123). The pattern above is intended to allow\r
-for current practice in domain name use, and some possible\r
-future expansion. It is designed to hold various types of\r
-domain names, including names used for A or AAAA records\r
-(host names) and other records, such as SRV records. Note\r
-that Internet host names have a stricter syntax (described\r
-in RFC 952) than the DNS recommendations in RFCs 1034 and\r
-1123, and that systems that want to store host names in\r
-schema nodes using the domain-name type are recommended to\r
-adhere to this stricter standard to ensure interoperability.\r
-\r
-The encoding of DNS names in the DNS protocol is limited\r
-to 255 characters. Since the encoding consists of labels\r
-prefixed by a length bytes and there is a trailing NULL\r
-byte, only 253 characters can appear in the textual dotted\r
-notation.\r
-\r
-The description clause of schema nodes using the domain-name\r
-type MUST describe when and how these names are resolved to\r
-IP addresses. Note that the resolution of a domain-name value\r
-may require to query multiple DNS records (e.g., A for IPv4\r
-and AAAA for IPv6). The order of the resolution process and\r
-which DNS record takes precedence can either be defined\r
-explicitely or it may depend on the configuration of the\r
-resolver.\r
-\r
-Domain-name values use the US-ASCII encoding. Their canonical\r
-format uses lowercase US-ASCII characters. Internationalized\r
-domain names MUST be encoded in punycode as described in RFC\r
-3492</text>\r
- </description>\r
- <reference>\r
- <text>RFC 952: DoD Internet Host Table Specification\r
-RFC 1034: Domain Names - Concepts and Facilities\r
-RFC 1123: Requirements for Internet Hosts -- Application\r
- and Support\r
-RFC 2782: A DNS RR for specifying the location of services\r
- (DNS SRV)\r
-RFC 3492: Punycode: A Bootstring encoding of Unicode for\r
- Internationalized Domain Names in Applications\r
- (IDNA)\r
-RFC 5891: Internationalizing Domain Names in Applications\r
- (IDNA): Protocol</text>\r
- </reference>\r
- </typedef>\r
- <typedef name="host">\r
- <type name="union">\r
- <type name="inet:ip-address"/>\r
- <type name="inet:domain-name"/>\r
- </type>\r
- <description>\r
- <text>The host type represents either an IP address or a DNS\r
-domain name.</text>\r
- </description>\r
- </typedef>\r
- <typedef name="uri">\r
- <type name="string"/>\r
- <description>\r
- <text>The uri type represents a Uniform Resource Identifier\r
-(URI) as defined by STD 66.\r
-\r
-Objects using the uri type MUST be in US-ASCII encoding,\r
-and MUST be normalized as described by RFC 3986 Sections\r
-6.2.1, 6.2.2.1, and 6.2.2.2. All unnecessary\r
-percent-encoding is removed, and all case-insensitive\r
-characters are set to lowercase except for hexadecimal\r
-digits, which are normalized to uppercase as described in\r
-Section 6.2.2.1.\r
-\r
-The purpose of this normalization is to help provide\r
-unique URIs. Note that this normalization is not\r
-sufficient to provide uniqueness. Two URIs that are\r
-textually distinct after this normalization may still be\r
-equivalent.\r
-\r
-Objects using the uri type may restrict the schemes that\r
-they permit. For example, 'data:' and 'urn:' schemes\r
-might not be appropriate.\r
-\r
-A zero-length URI is not a valid URI. This can be used to\r
-express 'URI absent' where required.\r
-\r
-In the value set and its semantics, this type is equivalent\r
-to the Uri SMIv2 textual convention defined in RFC 5017.</text>\r
- </description>\r
- <reference>\r
- <text>RFC 3986: Uniform Resource Identifier (URI): Generic Syntax\r
-RFC 3305: Report from the Joint W3C/IETF URI Planning Interest\r
- Group: Uniform Resource Identifiers (URIs), URLs,\r
- and Uniform Resource Names (URNs): Clarifications\r
- and Recommendations\r
-RFC 5017: MIB Textual Conventions for Uniform Resource\r
- Identifiers (URIs)</text>\r
- </reference>\r
- </typedef>\r
-</module>\r
+<?xml version="1.0" encoding="UTF-8"?>
+<module xmlns="urn:ietf:params:xml:ns:yang:yin:1" xmlns:inet="urn:ietf:params:xml:ns:yang:ietf-inet-types" name="ietf-inet-types">
+ <namespace uri="urn:ietf:params:xml:ns:yang:ietf-inet-types"/>
+ <prefix value="inet"/>
+ <organization>
+ <text>IETF NETMOD (NETCONF Data Modeling Language) Working Group</text>
+ </organization>
+ <contact>
+ <text>WG Web: <http://tools.ietf.org/wg/netmod/>
+WG List: <mailto:netmod@ietf.org>
+
+WG Chair: David Partain
+ <mailto:david.partain@ericsson.com>
+
+WG Chair: David Kessens
+ <mailto:david.kessens@nsn.com>
+
+Editor: Juergen Schoenwaelder
+ <mailto:j.schoenwaelder@jacobs-university.de></text>
+ </contact>
+ <description>
+ <text>This module contains a collection of generally useful derived
+YANG data types for Internet addresses and related things.
+
+Copyright (c) 2010 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 6021; see
+the RFC itself for full legal notices.</text>
+ </description>
+ <revision date="2010-09-24">
+ <description>
+ <text>Initial revision.</text>
+ </description>
+ <reference>
+ <text>RFC 6021: Common YANG Data Types</text>
+ </reference>
+ </revision>
+ <typedef name="ip-version">
+ <type name="enumeration">
+ <enum name="unknown">
+ <value value="0"/>
+ <description>
+ <text>An unknown or unspecified version of the Internet protocol.</text>
+ </description>
+ </enum>
+ <enum name="ipv4">
+ <value value="1"/>
+ <description>
+ <text>The IPv4 protocol as defined in RFC 791.</text>
+ </description>
+ </enum>
+ <enum name="ipv6">
+ <value value="2"/>
+ <description>
+ <text>The IPv6 protocol as defined in RFC 2460.</text>
+ </description>
+ </enum>
+ </type>
+ <description>
+ <text>This value represents the version of the IP protocol.
+
+In the value set and its semantics, this type is equivalent
+to the InetVersion textual convention of the SMIv2.</text>
+ </description>
+ <reference>
+ <text>RFC 791: Internet Protocol
+RFC 2460: Internet Protocol, Version 6 (IPv6) Specification
+RFC 4001: Textual Conventions for Internet Network Addresses</text>
+ </reference>
+ </typedef>
+ <typedef name="dscp">
+ <type name="uint8">
+ <range value="0..63"/>
+ </type>
+ <description>
+ <text>The dscp type represents a Differentiated Services Code-Point
+that may be used for marking packets in a traffic stream.
+
+In the value set and its semantics, this type is equivalent
+to the Dscp textual convention of the SMIv2.</text>
+ </description>
+ <reference>
+ <text>RFC 3289: Management Information Base for the Differentiated
+ Services Architecture
+RFC 2474: Definition of the Differentiated Services Field
+ (DS Field) in the IPv4 and IPv6 Headers
+RFC 2780: IANA Allocation Guidelines For Values In
+ the Internet Protocol and Related Headers</text>
+ </reference>
+ </typedef>
+ <typedef name="ipv6-flow-label">
+ <type name="uint32">
+ <range value="0..1048575"/>
+ </type>
+ <description>
+ <text>The flow-label type represents flow identifier or Flow Label
+in an IPv6 packet header that may be used to discriminate
+traffic flows.
+
+In the value set and its semantics, this type is equivalent
+to the IPv6FlowLabel textual convention of the SMIv2.</text>
+ </description>
+ <reference>
+ <text>RFC 3595: Textual Conventions for IPv6 Flow Label
+RFC 2460: Internet Protocol, Version 6 (IPv6) Specification</text>
+ </reference>
+ </typedef>
+ <typedef name="port-number">
+ <type name="uint16">
+ <range value="0..65535"/>
+ </type>
+ <description>
+ <text>The port-number type represents a 16-bit port number of an
+Internet transport layer protocol such as UDP, TCP, DCCP, or
+SCTP. Port numbers are assigned by IANA. A current list of
+all assignments is available from <http://www.iana.org/>.
+
+Note that the port number value zero is reserved by IANA. In
+situations where the value zero does not make sense, it can
+be excluded by subtyping the port-number type.
+
+In the value set and its semantics, this type is equivalent
+to the InetPortNumber textual convention of the SMIv2.</text>
+ </description>
+ <reference>
+ <text>RFC 768: User Datagram Protocol
+RFC 793: Transmission Control Protocol
+RFC 4960: Stream Control Transmission Protocol
+RFC 4340: Datagram Congestion Control Protocol (DCCP)
+RFC 4001: Textual Conventions for Internet Network Addresses</text>
+ </reference>
+ </typedef>
+ <typedef name="as-number">
+ <type name="uint32"/>
+ <description>
+ <text>The as-number type represents autonomous system numbers
+which identify an Autonomous System (AS). An AS is a set
+of routers under a single technical administration, using
+an interior gateway protocol and common metrics to route
+packets within the AS, and using an exterior gateway
+protocol to route packets to other ASs'. IANA maintains
+the AS number space and has delegated large parts to the
+regional registries.
+
+Autonomous system numbers were originally limited to 16
+bits. BGP extensions have enlarged the autonomous system
+number space to 32 bits. This type therefore uses an uint32
+base type without a range restriction in order to support
+a larger autonomous system number space.
+
+In the value set and its semantics, this type is equivalent
+to the InetAutonomousSystemNumber textual convention of
+the SMIv2.</text>
+ </description>
+ <reference>
+ <text>RFC 1930: Guidelines for creation, selection, and registration
+ of an Autonomous System (AS)
+RFC 4271: A Border Gateway Protocol 4 (BGP-4)
+RFC 4893: BGP Support for Four-octet AS Number Space
+RFC 4001: Textual Conventions for Internet Network Addresses</text>
+ </reference>
+ </typedef>
+ <typedef name="ip-address">
+ <type name="union">
+ <type name="inet:ipv4-address"/>
+ <type name="inet:ipv6-address"/>
+ </type>
+ <description>
+ <text>The ip-address type represents an IP address and is IP
+version neutral. The format of the textual representations
+implies the IP version.</text>
+ </description>
+ </typedef>
+ <typedef name="ipv4-address">
+ <type name="string">
+ <pattern value="(([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])(%[\p{N}\p{L}]+)?"/>
+ </type>
+ <description>
+ <text>The ipv4-address type represents an IPv4 address in
+dotted-quad notation. The IPv4 address may include a zone
+index, separated by a % sign.
+
+The zone index is used to disambiguate identical address
+values. For link-local addresses, the zone index will
+typically be the interface index number or the name of an
+interface. If the zone index is not present, the default
+zone of the device will be used.
+
+The canonical format for the zone index is the numerical
+format</text>
+ </description>
+ </typedef>
+ <typedef name="ipv6-address">
+ <type name="string">
+ <pattern value="((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))(%[\p{N}\p{L}]+)?"/>
+ <pattern value="(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)(%.+)?"/>
+ </type>
+ <description>
+ <text>The ipv6-address type represents an IPv6 address in full,
+mixed, shortened, and shortened-mixed notation. The IPv6
+address may include a zone index, separated by a % sign.
+
+
+
+
+
+The zone index is used to disambiguate identical address
+values. For link-local addresses, the zone index will
+typically be the interface index number or the name of an
+interface. If the zone index is not present, the default
+zone of the device will be used.
+
+The canonical format of IPv6 addresses uses the compressed
+format described in RFC 4291, Section 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. The canonical format for the zone index is
+the numerical format as described in RFC 4007, Section
+11.2.</text>
+ </description>
+ <reference>
+ <text>RFC 4291: IP Version 6 Addressing Architecture
+RFC 4007: IPv6 Scoped Address Architecture
+RFC 5952: A Recommendation for IPv6 Address Text Representation</text>
+ </reference>
+ </typedef>
+ <typedef name="ip-prefix">
+ <type name="union">
+ <type name="inet:ipv4-prefix"/>
+ <type name="inet:ipv6-prefix"/>
+ </type>
+ <description>
+ <text>The ip-prefix type represents an IP prefix and is IP
+version neutral. The format of the textual representations
+implies the IP version.</text>
+ </description>
+ </typedef>
+ <typedef name="ipv4-prefix">
+ <type name="string">
+ <pattern value="(([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])/(([0-9])|([1-2][0-9])|(3[0-2]))"/>
+ </type>
+ <description>
+ <text>The ipv4-prefix type represents an IPv4 address prefix.
+The prefix length is given by the number following the
+slash character and must be less than or equal to 32.
+
+
+
+A prefix length value of n corresponds to an IP address
+mask that has n contiguous 1-bits from the most
+significant bit (MSB) and all other bits set to 0.
+
+The canonical format of an IPv4 prefix has all bits of
+the IPv4 address set to zero that are not part of the
+IPv4 prefix.</text>
+ </description>
+ </typedef>
+ <typedef name="ipv6-prefix">
+ <type name="string">
+ <pattern value="((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))(/(([0-9])|([0-9]{2})|(1[0-1][0-9])|(12[0-8])))"/>
+ <pattern value="(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)(/.+)"/>
+ </type>
+ <description>
+ <text>The ipv6-prefix type represents an IPv6 address prefix.
+The prefix length is given by the number following the
+slash character and must be less than or equal 128.
+
+A prefix length value of n corresponds to an IP address
+mask that has n contiguous 1-bits from the most
+significant bit (MSB) and all other bits set to 0.
+
+The IPv6 address should have all bits that do not belong
+to the prefix set to zero.
+
+The canonical format of an IPv6 prefix has all bits of
+the IPv6 address set to zero that are not part of the
+IPv6 prefix. Furthermore, IPv6 address is represented
+in the compressed format described in RFC 4291, Section
+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.</text>
+ </description>
+ <reference>
+ <text>RFC 4291: IP Version 6 Addressing Architecture</text>
+ </reference>
+ </typedef>
+ <typedef name="domain-name">
+ <type name="string">
+ <pattern value="((([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]\.?)|\."/>
+ <length value="1..253"/>
+ </type>
+ <description>
+ <text>The domain-name type represents a DNS domain name. The
+name SHOULD be fully qualified whenever possible.
+
+Internet domain names are only loosely specified. Section
+3.5 of RFC 1034 recommends a syntax (modified in Section
+2.1 of RFC 1123). The pattern above is intended to allow
+for current practice in domain name use, and some possible
+future expansion. It is designed to hold various types of
+domain names, including names used for A or AAAA records
+(host names) and other records, such as SRV records. Note
+that Internet host names have a stricter syntax (described
+in RFC 952) than the DNS recommendations in RFCs 1034 and
+1123, and that systems that want to store host names in
+schema nodes 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
+to 255 characters. Since the encoding consists of labels
+prefixed by a length bytes and there is a trailing NULL
+byte, only 253 characters can appear in the textual dotted
+notation.
+
+The description clause of schema nodes using the domain-name
+type MUST describe when and how these names are resolved to
+IP addresses. Note that the resolution of a domain-name value
+may require to query multiple DNS records (e.g., A for IPv4
+and AAAA for IPv6). The order of the resolution process and
+which DNS record takes precedence can either be defined
+explicitely or it may depend on the configuration of the
+resolver.
+
+Domain-name values use the US-ASCII encoding. Their canonical
+format uses lowercase US-ASCII characters. Internationalized
+domain names MUST be encoded in punycode as described in RFC
+3492</text>
+ </description>
+ <reference>
+ <text>RFC 952: DoD Internet Host Table Specification
+RFC 1034: Domain Names - Concepts and Facilities
+RFC 1123: Requirements for Internet Hosts -- Application
+ and Support
+RFC 2782: A DNS RR for specifying the location of services
+ (DNS SRV)
+RFC 3492: Punycode: A Bootstring encoding of Unicode for
+ Internationalized Domain Names in Applications
+ (IDNA)
+RFC 5891: Internationalizing Domain Names in Applications
+ (IDNA): Protocol</text>
+ </reference>
+ </typedef>
+ <typedef name="host">
+ <type name="union">
+ <type name="inet:ip-address"/>
+ <type name="inet:domain-name"/>
+ </type>
+ <description>
+ <text>The host type represents either an IP address or a DNS
+domain name.</text>
+ </description>
+ </typedef>
+ <typedef name="uri">
+ <type name="string"/>
+ <description>
+ <text>The uri type represents a Uniform Resource Identifier
+(URI) as defined by STD 66.
+
+Objects using the uri type MUST be in US-ASCII encoding,
+and MUST be normalized as described by RFC 3986 Sections
+6.2.1, 6.2.2.1, and 6.2.2.2. All unnecessary
+percent-encoding is removed, and all case-insensitive
+characters are set to lowercase except for hexadecimal
+digits, which are normalized to uppercase as described in
+Section 6.2.2.1.
+
+The purpose of this normalization is to help provide
+unique URIs. Note that this normalization is not
+sufficient to provide uniqueness. Two URIs that are
+textually distinct after this normalization may still be
+equivalent.
+
+Objects using the uri type may restrict the schemes that
+they permit. For example, 'data:' and 'urn:' schemes
+might not be appropriate.
+
+A zero-length URI is not a valid URI. This can be used to
+express 'URI absent' where required.
+
+In the value set and its semantics, this type is equivalent
+to the Uri SMIv2 textual convention defined in RFC 5017.</text>
+ </description>
+ <reference>
+ <text>RFC 3986: Uniform Resource Identifier (URI): Generic Syntax
+RFC 3305: Report from the Joint W3C/IETF URI Planning Interest
+ Group: Uniform Resource Identifiers (URIs), URLs,
+ and Uniform Resource Names (URNs): Clarifications
+ and Recommendations
+RFC 5017: MIB Textual Conventions for Uniform Resource
+ Identifiers (URIs)</text>
+ </reference>
+ </typedef>
+</module>
Code Review / dlux.git / commitdiff