From d9bfe9a4f255a3e58bb1b1f37b3af32be7c1692f Mon Sep 17 00:00:00 2001 From: Stephen Kitt Date: Thu, 22 Mar 2018 18:24:29 +0100 Subject: [PATCH] Bump to odlparent 3.1.0 and yangtools 2.0.3 Change-Id: I4daf11b5d2fdb56c34b55b60b324c221f562599a Signed-off-by: Stephen Kitt --- features/features-dlux/pom.xml | 6 +- features/odl-dlux-core/pom.xml | 6 +- features/pom.xml | 5 +- .../assets/yang2xml/ethernet-packet.yang.xml | 6 +- .../assets/yang2xml/ietf-inet-types.yang.xml | 822 +++++++++--------- pom.xml | 4 +- 6 files changed, 419 insertions(+), 430 deletions(-) diff --git a/features/features-dlux/pom.xml b/features/features-dlux/pom.xml index 4491c5f7..d83df83c 100644 --- a/features/features-dlux/pom.xml +++ b/features/features-dlux/pom.xml @@ -6,15 +6,13 @@ terms of the Eclipse Public License v1.0 which accompanies this distribution, and is available at http://www.eclipse.org/legal/epl-v10.html --> - + 4.0.0 org.opendaylight.odlparent feature-repo-parent - 3.0.2 + 3.1.0 diff --git a/features/odl-dlux-core/pom.xml b/features/odl-dlux-core/pom.xml index 60ae460d..9a7e61f8 100644 --- a/features/odl-dlux-core/pom.xml +++ b/features/odl-dlux-core/pom.xml @@ -6,15 +6,13 @@ terms of the Eclipse Public License v1.0 which accompanies this distribution, and is available at http://www.eclipse.org/legal/epl-v10.html --> - + 4.0.0 org.opendaylight.odlparent single-feature-parent - 3.0.2 + 3.1.0 diff --git a/features/pom.xml b/features/pom.xml index 6cba40c7..25567116 100644 --- a/features/pom.xml +++ b/features/pom.xml @@ -6,13 +6,12 @@ terms of the Eclipse Public License v1.0 which accompanies this distribution, and is available at http://www.eclipse.org/legal/epl-v10.html --> - + 4.0.0 org.opendaylight.odlparent odlparent-lite - 3.0.2 + 3.1.0 org.opendaylight.dlux diff --git a/modules/loader-resources/src/main/resources/assets/yang2xml/ethernet-packet.yang.xml b/modules/loader-resources/src/main/resources/assets/yang2xml/ethernet-packet.yang.xml index 09ca439a..ef0ac04b 100644 --- a/modules/loader-resources/src/main/resources/assets/yang2xml/ethernet-packet.yang.xml +++ b/modules/loader-resources/src/main/resources/assets/yang2xml/ethernet-packet.yang.xml @@ -1,9 +1,5 @@ - + diff --git a/modules/loader-resources/src/main/resources/assets/yang2xml/ietf-inet-types.yang.xml b/modules/loader-resources/src/main/resources/assets/yang2xml/ietf-inet-types.yang.xml index 39f6b14e..ec64f846 100644 --- a/modules/loader-resources/src/main/resources/assets/yang2xml/ietf-inet-types.yang.xml +++ b/modules/loader-resources/src/main/resources/assets/yang2xml/ietf-inet-types.yang.xml @@ -1,412 +1,410 @@ - - - - - - IETF NETMOD (NETCONF Data Modeling Language) Working Group - - - 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> - - - 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. - - - - Initial revision. - - - RFC 6021: Common YANG Data Types - - - - - - - - An unknown or unspecified version of the Internet protocol. - - - - - - The IPv4 protocol as defined in RFC 791. - - - - - - The IPv6 protocol as defined in RFC 2460. - - - - - 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. - - - RFC 791: Internet Protocol -RFC 2460: Internet Protocol, Version 6 (IPv6) Specification -RFC 4001: Textual Conventions for Internet Network Addresses - - - - - - - - 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. - - - 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 - - - - - - - - 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. - - - RFC 3595: Textual Conventions for IPv6 Flow Label -RFC 2460: Internet Protocol, Version 6 (IPv6) Specification - - - - - - - - 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. - - - 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 - - - - - - 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. - - - 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 - - - - - - - - - The ip-address type represents an IP address and is IP -version neutral. The format of the textual representations -implies the IP version. - - - - - - - - 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 - - - - - - - - - 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. - - - RFC 4291: IP Version 6 Addressing Architecture -RFC 4007: IPv6 Scoped Address Architecture -RFC 5952: A Recommendation for IPv6 Address Text Representation - - - - - - - - - The ip-prefix type represents an IP prefix and is IP -version neutral. The format of the textual representations -implies the IP version. - - - - - - - - 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. - - - - - - - - - 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. - - - RFC 4291: IP Version 6 Addressing Architecture - - - - - - - - - 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 - - - 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 - - - - - - - - - The host type represents either an IP address or a DNS -domain name. - - - - - - 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. - - - 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) - - - + + + + + + IETF NETMOD (NETCONF Data Modeling Language) Working Group + + + 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> + + + 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. + + + + Initial revision. + + + RFC 6021: Common YANG Data Types + + + + + + + + An unknown or unspecified version of the Internet protocol. + + + + + + The IPv4 protocol as defined in RFC 791. + + + + + + The IPv6 protocol as defined in RFC 2460. + + + + + 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. + + + RFC 791: Internet Protocol +RFC 2460: Internet Protocol, Version 6 (IPv6) Specification +RFC 4001: Textual Conventions for Internet Network Addresses + + + + + + + + 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. + + + 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 + + + + + + + + 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. + + + RFC 3595: Textual Conventions for IPv6 Flow Label +RFC 2460: Internet Protocol, Version 6 (IPv6) Specification + + + + + + + + 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. + + + 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 + + + + + + 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. + + + 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 + + + + + + + + + The ip-address type represents an IP address and is IP +version neutral. The format of the textual representations +implies the IP version. + + + + + + + + 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 + + + + + + + + + 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. + + + RFC 4291: IP Version 6 Addressing Architecture +RFC 4007: IPv6 Scoped Address Architecture +RFC 5952: A Recommendation for IPv6 Address Text Representation + + + + + + + + + The ip-prefix type represents an IP prefix and is IP +version neutral. The format of the textual representations +implies the IP version. + + + + + + + + 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. + + + + + + + + + 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. + + + RFC 4291: IP Version 6 Addressing Architecture + + + + + + + + + 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 + + + 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 + + + + + + + + + The host type represents either an IP address or a DNS +domain name. + + + + + + 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. + + + 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) + + + diff --git a/pom.xml b/pom.xml index 65234048..b8ade6a6 100644 --- a/pom.xml +++ b/pom.xml @@ -4,8 +4,8 @@ org.opendaylight.odlparent odlparent - 3.0.2 - + 3.1.0 + 4.0.0 -- 2.36.6