diff options
Diffstat (limited to 'vnfs/TestVNF/netconftemplates/netconftemplates/ietf-inet-types@2013-07-15.yin')
| -rw-r--r-- | vnfs/TestVNF/netconftemplates/netconftemplates/ietf-inet-types@2013-07-15.yin | 449 |
1 files changed, 449 insertions, 0 deletions
diff --git a/vnfs/TestVNF/netconftemplates/netconftemplates/ietf-inet-types@2013-07-15.yin b/vnfs/TestVNF/netconftemplates/netconftemplates/ietf-inet-types@2013-07-15.yin new file mode 100644 index 00000000..b4dfee6c --- /dev/null +++ b/vnfs/TestVNF/netconftemplates/netconftemplates/ietf-inet-types@2013-07-15.yin @@ -0,0 +1,449 @@ +<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="m-1"> + <data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring"><?xml version="1.0" encoding="UTF-8"?> +<module name="ietf-inet-types" + xmlns="urn:ietf:params:xml:ns:yang:yin:1" + xmlns:inet="urn:ietf:params:xml:ns:yang: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: &lt;http://tools.ietf.org/wg/netmod/&gt; +WG List: &lt;mailto:netmod@ietf.org&gt; + +WG Chair: David Kessens + &lt;mailto:david.kessens@nsn.com&gt; + +WG Chair: Juergen Schoenwaelder + &lt;mailto:j.schoenwaelder@jacobs-university.de&gt; + +Editor: Juergen Schoenwaelder + &lt;mailto:j.schoenwaelder@jacobs-university.de&gt;</text> + </contact> + <description> + <text>This module contains a collection of generally useful derived +YANG data types for Internet addresses and related things. + +Copyright (c) 2013 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 6991; see +the RFC itself for full legal notices.</text> + </description> + <revision date="2013-07-15"> + <description> + <text>This revision adds the following new data types: +- ip-address-no-zone +- ipv4-address-no-zone +- ipv6-address-no-zone</text> + </description> + <reference> + <text>RFC 6991: Common YANG Data Types</text> + </reference> + </revision> + <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 ipv6-flow-label type represents the 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 &lt;http://www.iana.org/&gt;. + +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 ASes. 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 4001: Textual Conventions for Internet Network Addresses +RFC 6793: BGP Support for Four-Octet Autonomous System (AS) + Number Space</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 representation +implies the IP version. This type supports scoped addresses +by allowing zone identifiers in the address format.</text> + </description> + <reference> + <text>RFC 4007: IPv6 Scoped Address Architecture</text> + </reference> + </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 textual +representation defined in Section 4 of RFC 5952. The +canonical format for the zone index is the numerical +format as described in Section 11.2 of RFC 4007.</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-address-no-zone"> + <type name="union"> + <type name="inet:ipv4-address-no-zone"/> + <type name="inet:ipv6-address-no-zone"/> + </type> + <description> + <text>The ip-address-no-zone type represents an IP address and is +IP version neutral. The format of the textual representation +implies the IP version. This type does not support scoped +addresses since it does not allow zone identifiers in the +address format.</text> + </description> + <reference> + <text>RFC 4007: IPv6 Scoped Address Architecture</text> + </reference> + </typedef> + <typedef name="ipv4-address-no-zone"> + <type name="inet:ipv4-address"> + <pattern value="[0-9\.]*"/> + </type> + <description> + <text>An IPv4 address without a zone index. This type, derived from +ipv4-address, may be used in situations where the zone is +known from the context and hence no zone index is needed.</text> + </description> + </typedef> + <typedef name="ipv6-address-no-zone"> + <type name="inet:ipv6-address"> + <pattern value="[0-9a-fA-F:\.]*"/> + </type> + <description> + <text>An IPv6 address without a zone index. This type, derived from +ipv6-address, may be used in situations where the zone is +known from the context and hence no zone index is needed.</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 to 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, the IPv6 address is represented +as defined in Section 4 of RFC 5952.</text> + </description> + <reference> + <text>RFC 5952: A Recommendation for IPv6 Address Text + Representation</text> + </reference> + </typedef> + <typedef name="domain-name"> + <type name="string"> + <length value="1..253"/> + <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]\.?)|\."/> + </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 +explicitly or 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 A-labels as per RFC 5890.</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 5890: Internationalized Domain Names in Applications + (IDNA): Definitions and Document Framework</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> +</data> +</rpc-reply> |