Ditch the old yang library and just use the new one instead.
JIRA: NETCONF-725
Change-Id: I99c9678146ef58d525dda626087a5e74b0e270e4
Signed-off-by: Robert Varga <robert.varga@pantheon.tech>
</dependency>
<dependency>
<groupId>org.opendaylight.mdsal.model</groupId>
- <artifactId>odl-mdsal-model-rfc7895</artifactId>
+ <artifactId>odl-mdsal-model-rfc8525</artifactId>
<type>xml</type>
<classifier>features</classifier>
</dependency>
<feature name="odl-restconf-common" version="${project.version}">
<feature version="[8.1,9)">odl-karaf-feat-jetty</feature>
<feature version="[6,7)">odl-yangtools-export</feature>
- <feature version="[7,8)">odl-mdsal-model-rfc7895</feature>
+ <feature version="[7,8)">odl-mdsal-model-rfc8525</feature>
<feature version="[3,4)">odl-mdsal-broker</feature>
<feature version="[0.13,1)">odl-aaa-shiro</feature>
</feature>
</dependency>
<dependency>
<groupId>org.opendaylight.mdsal.binding.model.ietf</groupId>
- <artifactId>rfc7895</artifactId>
+ <artifactId>rfc8525</artifactId>
</dependency>
<dependency>
<groupId>org.opendaylight.netconf</groupId>
package org.opendaylight.restconf.nb.rfc8040;
import java.net.URI;
-import org.opendaylight.yang.gen.v1.urn.ietf.params.xml.ns.yang.ietf.yang.library.rev160621.$YangModuleInfoImpl;
-import org.opendaylight.yang.gen.v1.urn.ietf.params.xml.ns.yang.ietf.yang.library.rev160621.module.list.Module;
-import org.opendaylight.yang.gen.v1.urn.ietf.params.xml.ns.yang.ietf.yang.library.rev160621.module.list.module.Deviation;
-import org.opendaylight.yang.gen.v1.urn.ietf.params.xml.ns.yang.ietf.yang.library.rev160621.module.list.module.Submodule;
+import org.opendaylight.yang.gen.v1.urn.ietf.params.xml.ns.yang.ietf.yang.library.rev190104.$YangModuleInfoImpl;
+import org.opendaylight.yang.gen.v1.urn.ietf.params.xml.ns.yang.ietf.yang.library.rev190104.module.list.Module;
+import org.opendaylight.yang.gen.v1.urn.ietf.params.xml.ns.yang.ietf.yang.library.rev190104.module.list.module.Deviation;
+import org.opendaylight.yang.gen.v1.urn.ietf.params.xml.ns.yang.ietf.yang.library.rev190104.module.list.module.Submodule;
import org.opendaylight.yangtools.yang.common.QName;
import org.opendaylight.yangtools.yang.common.QNameModule;
import org.opendaylight.yangtools.yang.common.Revision;
import org.opendaylight.restconf.nb.rfc8040.Rfc8040.MonitoringModule;
import org.opendaylight.restconf.nb.rfc8040.Rfc8040.MonitoringModule.QueryParams;
import org.opendaylight.restconf.nb.rfc8040.utils.parser.ParserIdentifier;
-import org.opendaylight.yang.gen.v1.urn.ietf.params.xml.ns.yang.ietf.yang.library.rev160621.ModulesState;
-import org.opendaylight.yang.gen.v1.urn.ietf.params.xml.ns.yang.ietf.yang.library.rev160621.module.list.Module.ConformanceType;
+import org.opendaylight.yang.gen.v1.urn.ietf.params.xml.ns.yang.ietf.yang.library.rev190104.ModulesState;
+import org.opendaylight.yang.gen.v1.urn.ietf.params.xml.ns.yang.ietf.yang.library.rev190104.module.list.Module.ConformanceType;
import org.opendaylight.yangtools.yang.common.QName;
import org.opendaylight.yangtools.yang.common.Revision;
import org.opendaylight.yangtools.yang.data.api.YangInstanceIdentifier;
@BeforeClass
public static void loadTestSchemaContextAndModules() throws Exception {
+ // FIXME: assemble these from dependencies
schemaContext =
YangParserTestUtils.parseYangFiles(TestRestconfUtils.loadFiles("/modules/restconf-module-testing"));
schemaContextMonitoring = YangParserTestUtils.parseYangFiles(TestRestconfUtils.loadFiles("/modules"));
--- /dev/null
+module ietf-datastores {
+ yang-version 1.1;
+ namespace "urn:ietf:params:xml:ns:yang:ietf-datastores";
+ prefix ds;
+
+ organization
+ "IETF Network Modeling (NETMOD) Working Group";
+
+ contact
+ "WG Web: <https://datatracker.ietf.org/wg/netmod/>
+
+ WG List: <mailto:netmod@ietf.org>
+
+ Author: Martin Bjorklund
+ <mailto:mbj@tail-f.com>
+
+ Author: Juergen Schoenwaelder
+ <mailto:j.schoenwaelder@jacobs-university.de>
+
+ Author: Phil Shafer
+ <mailto:phil@juniper.net>
+
+ Author: Kent Watsen
+ <mailto:kwatsen@juniper.net>
+
+ Author: Rob Wilton
+ <rwilton@cisco.com>";
+
+ description
+ "This YANG module defines a set of identities for identifying
+ datastores.
+
+ Copyright (c) 2018 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
+ (https://trustee.ietf.org/license-info).
+
+ This version of this YANG module is part of RFC 8342
+ (https://www.rfc-editor.org/info/rfc8342); see the RFC itself
+ for full legal notices.";
+
+ revision 2018-02-14 {
+ description
+ "Initial revision.";
+ reference
+ "RFC 8342: Network Management Datastore Architecture (NMDA)";
+ }
+
+ /*
+ * Identities
+ */
+
+ identity datastore {
+ description
+ "Abstract base identity for datastore identities.";
+ }
+
+ identity conventional {
+ base datastore;
+ description
+ "Abstract base identity for conventional configuration
+ datastores.";
+ }
+
+ identity running {
+ base conventional;
+ description
+ "The running configuration datastore.";
+ }
+
+ identity candidate {
+ base conventional;
+ description
+ "The candidate configuration datastore.";
+ }
+
+ identity startup {
+ base conventional;
+ description
+ "The startup configuration datastore.";
+ }
+
+ identity intended {
+ base conventional;
+ description
+ "The intended configuration datastore.";
+ }
+
+ identity dynamic {
+ base datastore;
+ description
+ "Abstract base identity for dynamic configuration datastores.";
+ }
+
+ identity operational {
+ base datastore;
+ description
+ "The operational state datastore.";
+ }
+
+ /*
+ * Type definitions
+ */
+
+ typedef datastore-ref {
+ type identityref {
+ base datastore;
+ }
+ description
+ "A datastore identity reference.";
+ }
+}
+++ /dev/null
- module ietf-inet-types {
-
- namespace "urn:ietf:params:xml:ns:yang:ietf-inet-types";
- prefix "inet";
-
- organization
- "IETF NETMOD (NETCONF Data Modeling Language) Working Group";
-
- contact
- "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>";
-
- description
- "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.";
-
- revision 2010-09-24 {
- description
- "Initial revision.";
- reference
- "RFC 6021: Common YANG Data Types";
- }
-
- /*** collection of protocol field related types ***/
-
- typedef ip-version {
- type enumeration {
- enum unknown {
- value "0";
- description
- "An unknown or unspecified version of the Internet protocol.";
- }
- enum ipv4 {
- value "1";
- description
- "The IPv4 protocol as defined in RFC 791.";
- }
- enum ipv6 {
- value "2";
- description
- "The IPv6 protocol as defined in RFC 2460.";
- }
- }
- description
- "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.";
- reference
- "RFC 791: Internet Protocol
- RFC 2460: Internet Protocol, Version 6 (IPv6) Specification
- RFC 4001: Textual Conventions for Internet Network Addresses";
- }
-
- typedef dscp {
- type uint8 {
- range "0..63";
- }
- description
- "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.";
- reference
- "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";
- }
-
- typedef ipv6-flow-label {
- type uint32 {
- range "0..1048575";
- }
- description
- "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.";
- reference
- "RFC 3595: Textual Conventions for IPv6 Flow Label
- RFC 2460: Internet Protocol, Version 6 (IPv6) Specification";
- }
-
- typedef port-number {
- type uint16 {
- range "0..65535";
- }
- description
- "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.";
- reference
- "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";
- }
-
- /*** collection of autonomous system related types ***/
-
- typedef as-number {
- type uint32;
- description
- "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.";
- reference
- "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";
- }
-
- /*** collection of IP address and hostname related types ***/
-
- typedef ip-address {
- type union {
- type inet:ipv4-address;
- type inet:ipv6-address;
- }
- description
- "The ip-address type represents an IP address and is IP
- version neutral. The format of the textual representations
- implies the IP version.";
- }
-
- typedef ipv4-address {
- type string {
- pattern
- '(([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}]+)?';
- }
- description
- "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";
- }
-
- typedef ipv6-address {
- type string {
- pattern '((:|[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 '(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|'
- + '((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)'
- + '(%.+)?';
- }
- description
- "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.";
- reference
- "RFC 4291: IP Version 6 Addressing Architecture
- RFC 4007: IPv6 Scoped Address Architecture
- RFC 5952: A Recommendation for IPv6 Address Text Representation";
- }
-
- typedef ip-prefix {
- type union {
- type inet:ipv4-prefix;
- type inet:ipv6-prefix;
- }
- description
- "The ip-prefix type represents an IP prefix and is IP
- version neutral. The format of the textual representations
- implies the IP version.";
- }
-
- typedef ipv4-prefix {
- type string {
- pattern
- '(([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]))';
- }
- description
- "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.";
- }
-
- typedef ipv6-prefix {
- type string {
- pattern '((:|[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 '(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|'
- + '((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)'
- + '(/.+)';
- }
- description
- "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.";
- reference
- "RFC 4291: IP Version 6 Addressing Architecture";
- }
-
- /*** collection of domain name and URI types ***/
-
- typedef domain-name {
- type string {
- 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]\.?)'
- + '|\.';
- length "1..253";
- }
- description
- "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";
- reference
- "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";
- }
-
- typedef host {
- type union {
- type inet:ip-address;
- type inet:domain-name;
- }
- description
- "The host type represents either an IP address or a DNS
- domain name.";
- }
-
- typedef uri {
- type string;
- description
- "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.";
- reference
- "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)";
- }
-
- }
--- /dev/null
+module ietf-inet-types {
+
+ namespace "urn:ietf:params:xml:ns:yang:ietf-inet-types";
+ prefix "inet";
+
+ organization
+ "IETF NETMOD (NETCONF Data Modeling Language) Working Group";
+
+ contact
+ "WG Web: <http://tools.ietf.org/wg/netmod/>
+ WG List: <mailto:netmod@ietf.org>
+
+ WG Chair: David Kessens
+ <mailto:david.kessens@nsn.com>
+
+ WG Chair: Juergen Schoenwaelder
+ <mailto:j.schoenwaelder@jacobs-university.de>
+
+ Editor: Juergen Schoenwaelder
+ <mailto:j.schoenwaelder@jacobs-university.de>";
+
+ description
+ "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.";
+
+ revision 2013-07-15 {
+ description
+ "This revision adds the following new data types:
+ - ip-address-no-zone
+ - ipv4-address-no-zone
+ - ipv6-address-no-zone";
+ reference
+ "RFC 6991: Common YANG Data Types";
+ }
+
+ revision 2010-09-24 {
+ description
+ "Initial revision.";
+ reference
+ "RFC 6021: Common YANG Data Types";
+ }
+
+ /*** collection of types related to protocol fields ***/
+
+ typedef ip-version {
+ type enumeration {
+ enum unknown {
+ value "0";
+ description
+ "An unknown or unspecified version of the Internet
+ protocol.";
+ }
+ enum ipv4 {
+ value "1";
+ description
+ "The IPv4 protocol as defined in RFC 791.";
+ }
+ enum ipv6 {
+ value "2";
+ description
+ "The IPv6 protocol as defined in RFC 2460.";
+ }
+ }
+ description
+ "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.";
+ reference
+ "RFC 791: Internet Protocol
+ RFC 2460: Internet Protocol, Version 6 (IPv6) Specification
+ RFC 4001: Textual Conventions for Internet Network Addresses";
+ }
+
+ typedef dscp {
+ type uint8 {
+ range "0..63";
+ }
+ description
+ "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.";
+ reference
+ "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";
+ }
+
+ typedef ipv6-flow-label {
+ type uint32 {
+ range "0..1048575";
+ }
+ description
+ "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.";
+ reference
+ "RFC 3595: Textual Conventions for IPv6 Flow Label
+ RFC 2460: Internet Protocol, Version 6 (IPv6) Specification";
+ }
+
+ typedef port-number {
+ type uint16 {
+ range "0..65535";
+ }
+ description
+ "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.";
+ reference
+ "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";
+ }
+
+ /*** collection of types related to autonomous systems ***/
+
+ typedef as-number {
+ type uint32;
+ description
+ "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.";
+ reference
+ "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";
+ }
+
+ /*** collection of types related to IP addresses and hostnames ***/
+
+ typedef ip-address {
+ type union {
+ type inet:ipv4-address;
+ type inet:ipv6-address;
+ }
+ description
+ "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.";
+ reference
+ "RFC 4007: IPv6 Scoped Address Architecture";
+ }
+
+ typedef ipv4-address {
+ type string {
+ pattern
+ '(([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}]+)?';
+ }
+ description
+ "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";
+ }
+
+ typedef ipv6-address {
+ type string {
+ pattern '((:|[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 '(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|'
+ + '((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)'
+ + '(%.+)?';
+ }
+ description
+ "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.";
+ reference
+ "RFC 4291: IP Version 6 Addressing Architecture
+ RFC 4007: IPv6 Scoped Address Architecture
+ RFC 5952: A Recommendation for IPv6 Address Text
+ Representation";
+ }
+
+ typedef ip-address-no-zone {
+ type union {
+ type inet:ipv4-address-no-zone;
+ type inet:ipv6-address-no-zone;
+ }
+ description
+ "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.";
+ reference
+ "RFC 4007: IPv6 Scoped Address Architecture";
+ }
+
+ typedef ipv4-address-no-zone {
+ type inet:ipv4-address {
+ pattern '[0-9\.]*';
+ }
+ description
+ "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.";
+ }
+
+ typedef ipv6-address-no-zone {
+ type inet:ipv6-address {
+ pattern '[0-9a-fA-F:\.]*';
+ }
+ description
+ "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.";
+ reference
+ "RFC 4291: IP Version 6 Addressing Architecture
+ RFC 4007: IPv6 Scoped Address Architecture
+ RFC 5952: A Recommendation for IPv6 Address Text
+ Representation";
+ }
+
+ typedef ip-prefix {
+ type union {
+ type inet:ipv4-prefix;
+ type inet:ipv6-prefix;
+ }
+ description
+ "The ip-prefix type represents an IP prefix and is IP
+ version neutral. The format of the textual representations
+ implies the IP version.";
+ }
+
+ typedef ipv4-prefix {
+ type string {
+ pattern
+ '(([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]))';
+ }
+ description
+ "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.";
+ }
+
+ typedef ipv6-prefix {
+ type string {
+ pattern '((:|[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 '(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|'
+ + '((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)'
+ + '(/.+)';
+ }
+
+ description
+ "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.";
+ reference
+ "RFC 5952: A Recommendation for IPv6 Address Text
+ Representation";
+ }
+
+ /*** collection of domain name and URI types ***/
+
+ typedef domain-name {
+ type string {
+ 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]\.?)'
+ + '|\.';
+ length "1..253";
+ }
+ description
+ "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.";
+ reference
+ "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";
+ }
+
+ typedef host {
+ type union {
+ type inet:ip-address;
+ type inet:domain-name;
+ }
+ description
+ "The host type represents either an IP address or a DNS
+ domain name.";
+ }
+
+ typedef uri {
+ type string;
+ description
+ "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.";
+ reference
+ "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)";
+ }
+
+}
+++ /dev/null
-module ietf-yang-library {
- namespace "urn:ietf:params:xml:ns:yang:ietf-yang-library";
- prefix "yanglib";
- import ietf-yang-types {
- prefix yang;
- }
- import ietf-inet-types {
- prefix inet;
- }
- organization
- "IETF NETCONF (Network Configuration) Working Group";
- contact
- "WG Web: <https://datatracker.ietf.org/wg/netconf/>
- WG List: <mailto:netconf@ietf.org>
- WG Chair: Mehmet Ersue
- <mailto:mehmet.ersue@nsn.com>
- WG Chair: Mahesh Jethanandani
- <mailto:mjethanandani@gmail.com>
- Editor: Andy Bierman
- <mailto:andy@yumaworks.com>
- Editor: Martin Bjorklund
- <mailto:mbj@tail-f.com>
- Editor: Kent Watsen
- <mailto:kwatsen@juniper.net>";
- description
- "This module contains monitoring information about the YANG
- modules and submodules that are used within a YANG-based
- server.
- Copyright (c) 2016 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 7895; see
- the RFC itself for full legal notices.";
- revision 2016-06-21 {
- description
- "Initial revision.";
- reference
- "RFC 7895: YANG Module Library.";
- }
- /*
- * Typedefs
- */
- typedef revision-identifier {
- type string {
- pattern '\d{4}-\d{2}-\d{2}';
- }
- description
- "Represents a specific date in YYYY-MM-DD format.";
- }
- /*
- * Groupings
- */
- grouping module-list {
- description
- "The module data structure is represented as a grouping
- so it can be reused in configuration or another monitoring
- data structure.";
- grouping common-leafs {
- description
- "Common parameters for YANG modules and submodules.";
- leaf name {
- type yang:yang-identifier;
- description
- "The YANG module or submodule name.";
- }
- leaf revision {
- type union {
- type revision-identifier;
- type string { length 0; }
- }
- description
- "The YANG module or submodule revision date.
- A zero-length string is used if no revision statement
- is present in the YANG module or submodule.";
- }
- }
- grouping schema-leaf {
- description
- "Common schema leaf parameter for modules and submodules.";
- leaf schema {
- type inet:uri;
- description
- "Contains a URL that represents the YANG schema
- resource for this module or submodule.
- This leaf will only be present if there is a URL
- available for retrieval of the schema for this entry.";
- }
- }
- list module {
- key "name revision";
- description
- "Each entry represents one revision of one module
- currently supported by the server.";
- uses common-leafs;
- uses schema-leaf;
- leaf namespace {
- type inet:uri;
- mandatory true;
- description
- "The XML namespace identifier for this module.";
- }
- leaf-list feature {
- type yang:yang-identifier;
- description
- "List of YANG feature names from this module that are
- supported by the server, regardless of whether they are
- defined in the module or any included submodule.";
- }
- list deviation {
- key "name revision";
- description
- "List of YANG deviation module names and revisions
- used by this server to modify the conformance of
- the module associated with this entry. Note that
- the same module can be used for deviations for
- multiple modules, so the same entry MAY appear
- within multiple 'module' entries.
- The deviation module MUST be present in the 'module'
- list, with the same name and revision values.
- The 'conformance-type' value will be 'implement' for
- the deviation module.";
- uses common-leafs;
- }
- leaf conformance-type {
- type enumeration {
- enum implement {
- description
- "Indicates that the server implements one or more
- protocol-accessible objects defined in the YANG module
- identified in this entry. This includes deviation
- statements defined in the module.
- For YANG version 1.1 modules, there is at most one
- module entry with conformance type 'implement' for a
- particular module name, since YANG 1.1 requires that,
- at most, one revision of a module is implemented.
- For YANG version 1 modules, there SHOULD NOT be more
- than one module entry for a particular module name.";
- }
- enum import {
- description
- "Indicates that the server imports reusable definitions
- from the specified revision of the module but does
- not implement any protocol-accessible objects from
- this revision.
- Multiple module entries for the same module name MAY
- exist. This can occur if multiple modules import the
- same module but specify different revision dates in
- the import statements.";
- }
- }
- mandatory true;
- description
- "Indicates the type of conformance the server is claiming
- for the YANG module identified by this entry.";
- }
- list submodule {
- key "name revision";
- description
- "Each entry represents one submodule within the
- parent module.";
- uses common-leafs;
- uses schema-leaf;
- }
- }
- }
- /*
- * Operational state data nodes
- */
- container modules-state {
- config false;
- description
- "Contains YANG module monitoring information.";
- leaf module-set-id {
- type string;
- mandatory true;
- description
- "Contains a server-specific identifier representing
- the current set of modules and submodules. The
- server MUST change the value of this leaf if the
- information represented by the 'module' list instances
- has changed.";
- }
- uses module-list;
- }
- /*
- * Notifications
- */
- notification yang-library-change {
- description
- "Generated when the set of modules and submodules supported
- by the server has changed.";
- leaf module-set-id {
- type leafref {
- path "/yanglib:modules-state/yanglib:module-set-id";
- }
- mandatory true;
- description
- "Contains the module-set-id value representing the
- set of modules and submodules supported at the server at
- the time the notification is generated.";
- }
- }
-}
--- /dev/null
+module ietf-yang-library {
+ yang-version 1.1;
+ namespace "urn:ietf:params:xml:ns:yang:ietf-yang-library";
+ prefix yanglib;
+
+ import ietf-yang-types {
+ prefix yang;
+ reference
+ "RFC 6991: Common YANG Data Types";
+ }
+ import ietf-inet-types {
+ prefix inet;
+ reference
+ "RFC 6991: Common YANG Data Types";
+ }
+ import ietf-datastores {
+ prefix ds;
+ reference
+ "RFC 8342: Network Management Datastore Architecture
+ (NMDA)";
+ }
+
+ organization
+ "IETF NETCONF (Network Configuration) Working Group";
+ contact
+ "WG Web: <https://datatracker.ietf.org/wg/netconf/>
+ WG List: <mailto:netconf@ietf.org>
+
+ Author: Andy Bierman
+ <mailto:andy@yumaworks.com>
+
+ Author: Martin Bjorklund
+ <mailto:mbj@tail-f.com>
+
+ Author: Juergen Schoenwaelder
+ <mailto:j.schoenwaelder@jacobs-university.de>
+
+ Author: Kent Watsen
+ <mailto:kent+ietf@watsen.net>
+
+ Author: Robert Wilton
+ <mailto:rwilton@cisco.com>";
+ description
+ "This module provides information about the YANG modules,
+ datastores, and datastore schemas used by a network
+ management server.
+ The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
+ NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
+ 'MAY', and 'OPTIONAL' in this document are to be interpreted as
+ described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
+ they appear in all capitals, as shown here.
+
+ Copyright (c) 2019 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
+ (https://trustee.ietf.org/license-info).
+
+ This version of this YANG module is part of RFC 8525; see
+ the RFC itself for full legal notices.";
+
+ revision 2019-01-04 {
+ description
+ "Added support for multiple datastores according to the
+ Network Management Datastore Architecture (NMDA).";
+ reference
+ "RFC 8525: YANG Library";
+ }
+ revision 2016-04-09 {
+ description
+ "Initial revision.";
+ reference
+ "RFC 7895: YANG Module Library";
+ }
+
+ /*
+ * Typedefs
+ */
+
+ typedef revision-identifier {
+ type string {
+ pattern '\d{4}-\d{2}-\d{2}';
+ }
+ description
+ "Represents a specific date in YYYY-MM-DD format.";
+ }
+
+ /*
+ * Groupings
+ */
+ grouping module-identification-leafs {
+ description
+ "Parameters for identifying YANG modules and submodules.";
+ leaf name {
+ type yang:yang-identifier;
+ mandatory true;
+ description
+ "The YANG module or submodule name.";
+ }
+ leaf revision {
+ type revision-identifier;
+ description
+ "The YANG module or submodule revision date. If no revision
+ statement is present in the YANG module or submodule, this
+ leaf is not instantiated.";
+ }
+ }
+
+ grouping location-leaf-list {
+ description
+ "Common leaf-list parameter for the locations of modules and
+ submodules.";
+ leaf-list location {
+ type inet:uri;
+ description
+ "Contains a URL that represents the YANG schema
+ resource for this module or submodule.
+
+ This leaf will only be present if there is a URL
+ available for retrieval of the schema for this entry.";
+ }
+ }
+
+ grouping module-implementation-parameters {
+ description
+ "Parameters for describing the implementation of a module.";
+ leaf-list feature {
+ type yang:yang-identifier;
+ description
+ "List of all YANG feature names from this module that are
+ supported by the server, regardless whether they are defined
+ in the module or any included submodule.";
+ }
+ leaf-list deviation {
+ type leafref {
+ path "../../module/name";
+ }
+
+ description
+ "List of all YANG deviation modules used by this server to
+ modify the conformance of the module associated with this
+ entry. Note that the same module can be used for deviations
+ for multiple modules, so the same entry MAY appear within
+ multiple 'module' entries.
+
+ This reference MUST NOT (directly or indirectly)
+ refer to the module being deviated.
+
+ Robust clients may want to make sure that they handle a
+ situation where a module deviates itself (directly or
+ indirectly) gracefully.";
+ }
+ }
+
+ grouping module-set-parameters {
+ description
+ "A set of parameters that describe a module set.";
+ leaf name {
+ type string;
+ description
+ "An arbitrary name of the module set.";
+ }
+ list module {
+ key "name";
+ description
+ "An entry in this list represents a module implemented by the
+ server, as per Section 5.6.5 of RFC 7950, with a particular
+ set of supported features and deviations.";
+ reference
+ "RFC 7950: The YANG 1.1 Data Modeling Language";
+ uses module-identification-leafs;
+ leaf namespace {
+ type inet:uri;
+ mandatory true;
+ description
+ "The XML namespace identifier for this module.";
+ }
+ uses location-leaf-list;
+ list submodule {
+ key "name";
+ description
+ "Each entry represents one submodule within the
+ parent module.";
+ uses module-identification-leafs;
+ uses location-leaf-list;
+ }
+ uses module-implementation-parameters;
+ }
+ list import-only-module {
+ key "name revision";
+ description
+ "An entry in this list indicates that the server imports
+ reusable definitions from the specified revision of the
+ module but does not implement any protocol-accessible
+ objects from this revision.
+
+ Multiple entries for the same module name MAY exist. This
+ can occur if multiple modules import the same module but
+ specify different revision dates in the import statements.";
+ leaf name {
+ type yang:yang-identifier;
+ description
+ "The YANG module name.";
+ }
+ leaf revision {
+ type union {
+ type revision-identifier;
+ type string {
+ length "0";
+ }
+ }
+ description
+ "The YANG module revision date.
+ A zero-length string is used if no revision statement
+ is present in the YANG module.";
+ }
+ leaf namespace {
+ type inet:uri;
+ mandatory true;
+ description
+ "The XML namespace identifier for this module.";
+ }
+ uses location-leaf-list;
+ list submodule {
+ key "name";
+ description
+ "Each entry represents one submodule within the
+ parent module.";
+ uses module-identification-leafs;
+ uses location-leaf-list;
+ }
+ }
+ }
+
+ grouping yang-library-parameters {
+ description
+ "The YANG library data structure is represented as a grouping
+ so it can be reused in configuration or another monitoring
+ data structure.";
+ list module-set {
+ key "name";
+ description
+ "A set of modules that may be used by one or more schemas.
+
+ A module set does not have to be referentially complete,
+ i.e., it may define modules that contain import statements
+ for other modules not included in the module set.";
+ uses module-set-parameters;
+ }
+ list schema {
+ key "name";
+ description
+ "A datastore schema that may be used by one or more
+ datastores.
+
+ The schema must be valid and referentially complete, i.e.,
+ it must contain modules to satisfy all used import
+ statements for all modules specified in the schema.";
+ leaf name {
+ type string;
+ description
+ "An arbitrary name of the schema.";
+ }
+ leaf-list module-set {
+ type leafref {
+ path "../../module-set/name";
+ }
+ description
+ "A set of module-sets that are included in this schema.
+ If a non-import-only module appears in multiple module
+ sets, then the module revision and the associated features
+ and deviations must be identical.";
+ }
+ }
+ list datastore {
+ key "name";
+ description
+ "A datastore supported by this server.
+
+ Each datastore indicates which schema it supports.
+
+ The server MUST instantiate one entry in this list per
+ specific datastore it supports.
+ Each datastore entry with the same datastore schema SHOULD
+ reference the same schema.";
+ leaf name {
+ type ds:datastore-ref;
+ description
+ "The identity of the datastore.";
+ }
+ leaf schema {
+ type leafref {
+ path "../../schema/name";
+ }
+ mandatory true;
+ description
+ "A reference to the schema supported by this datastore.
+ All non-import-only modules of the schema are implemented
+ with their associated features and deviations.";
+ }
+ }
+ }
+
+ /*
+ * Top-level container
+ */
+
+ container yang-library {
+ config false;
+ description
+ "Container holding the entire YANG library of this server.";
+ uses yang-library-parameters;
+ leaf content-id {
+ type string;
+ mandatory true;
+ description
+ "A server-generated identifier of the contents of the
+ '/yang-library' tree. The server MUST change the value of
+ this leaf if the information represented by the
+ '/yang-library' tree, except '/yang-library/content-id', has
+ changed.";
+ }
+ }
+
+ /*
+ * Notifications
+ */
+
+ notification yang-library-update {
+ description
+ "Generated when any YANG library information on the
+ server has changed.";
+ leaf content-id {
+ type leafref {
+ path "/yanglib:yang-library/yanglib:content-id";
+ }
+ mandatory true;
+ description
+ "Contains the YANG library content identifier for the updated
+ YANG library at the time the notification is generated.";
+ }
+ }
+
+ /*
+ * Legacy groupings
+ */
+
+ grouping module-list {
+ status deprecated;
+ description
+ "The module data structure is represented as a grouping
+ so it can be reused in configuration or another monitoring
+ data structure.";
+
+ grouping common-leafs {
+ status deprecated;
+ description
+ "Common parameters for YANG modules and submodules.";
+ leaf name {
+ type yang:yang-identifier;
+ status deprecated;
+ description
+ "The YANG module or submodule name.";
+ }
+ leaf revision {
+ type union {
+ type revision-identifier;
+ type string {
+ length "0";
+ }
+ }
+ status deprecated;
+ description
+ "The YANG module or submodule revision date.
+ A zero-length string is used if no revision statement
+ is present in the YANG module or submodule.";
+ }
+ }
+
+ grouping schema-leaf {
+ status deprecated;
+ description
+ "Common schema leaf parameter for modules and submodules.";
+ leaf schema {
+ type inet:uri;
+ description
+ "Contains a URL that represents the YANG schema
+ resource for this module or submodule.
+
+ This leaf will only be present if there is a URL
+ available for retrieval of the schema for this entry.";
+ }
+ }
+ list module {
+ key "name revision";
+ status deprecated;
+ description
+ "Each entry represents one revision of one module
+ currently supported by the server.";
+ uses common-leafs {
+ status deprecated;
+ }
+ uses schema-leaf {
+ status deprecated;
+ }
+ leaf namespace {
+ type inet:uri;
+ mandatory true;
+ status deprecated;
+ description
+ "The XML namespace identifier for this module.";
+ }
+ leaf-list feature {
+ type yang:yang-identifier;
+ status deprecated;
+ description
+ "List of YANG feature names from this module that are
+ supported by the server, regardless of whether they are
+ defined in the module or any included submodule.";
+ }
+ list deviation {
+ key "name revision";
+ status deprecated;
+
+ description
+ "List of YANG deviation module names and revisions
+ used by this server to modify the conformance of
+ the module associated with this entry. Note that
+ the same module can be used for deviations for
+ multiple modules, so the same entry MAY appear
+ within multiple 'module' entries.
+
+ The deviation module MUST be present in the 'module'
+ list, with the same name and revision values.
+ The 'conformance-type' value will be 'implement' for
+ the deviation module.";
+ uses common-leafs {
+ status deprecated;
+ }
+ }
+ leaf conformance-type {
+ type enumeration {
+ enum implement {
+ description
+ "Indicates that the server implements one or more
+ protocol-accessible objects defined in the YANG module
+ identified in this entry. This includes deviation
+ statements defined in the module.
+
+ For YANG version 1.1 modules, there is at most one
+ 'module' entry with conformance type 'implement' for a
+ particular module name, since YANG 1.1 requires that
+ at most one revision of a module is implemented.
+
+ For YANG version 1 modules, there SHOULD NOT be more
+ than one 'module' entry for a particular module
+ name.";
+ }
+ enum import {
+ description
+ "Indicates that the server imports reusable definitions
+ from the specified revision of the module but does
+ not implement any protocol-accessible objects from
+ this revision.
+
+ Multiple 'module' entries for the same module name MAY
+ exist. This can occur if multiple modules import the
+ same module but specify different revision dates in
+ the import statements.";
+ }
+ }
+ mandatory true;
+ status deprecated;
+ description
+ "Indicates the type of conformance the server is claiming
+ for the YANG module identified by this entry.";
+ }
+ list submodule {
+ key "name revision";
+ status deprecated;
+ description
+ "Each entry represents one submodule within the
+ parent module.";
+ uses common-leafs {
+ status deprecated;
+ }
+ uses schema-leaf {
+ status deprecated;
+ }
+ }
+ }
+ }
+
+ /*
+ * Legacy operational state data nodes
+ */
+
+ container modules-state {
+ config false;
+ status deprecated;
+ description
+ "Contains YANG module monitoring information.";
+ leaf module-set-id {
+ type string;
+ mandatory true;
+ status deprecated;
+ description
+ "Contains a server-specific identifier representing
+ the current set of modules and submodules. The
+ server MUST change the value of this leaf if the
+ information represented by the 'module' list instances
+ has changed.";
+ }
+ uses module-list {
+ status deprecated;
+ }
+ }
+
+ /*
+ * Legacy notifications
+ */
+
+ notification yang-library-change {
+ status deprecated;
+ description
+ "Generated when the set of modules and submodules supported
+ by the server has changed.";
+ leaf module-set-id {
+ type leafref {
+ path "/yanglib:modules-state/yanglib:module-set-id";
+ }
+ mandatory true;
+ status deprecated;
+ description
+ "Contains the module-set-id value representing the
+ set of modules and submodules supported at the server
+ at the time the notification is generated.";
+ }
+ }
+}
+++ /dev/null
- module ietf-yang-types {
-
- namespace "urn:ietf:params:xml:ns:yang:ietf-yang-types";
- prefix "yang";
-
- organization
- "IETF NETMOD (NETCONF Data Modeling Language) Working Group";
-
- contact
- "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>";
-
- description
- "This module contains a collection of generally useful derived
- YANG data types.
-
- 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.";
-
- revision 2010-09-24 {
- description
- "Initial revision.";
- reference
- "RFC 6021: Common YANG Data Types";
- }
-
- /*** collection of counter and gauge types ***/
-
- typedef counter32 {
- type uint32;
- description
- "The counter32 type represents a non-negative integer
- that monotonically increases until it reaches a
- maximum value of 2^32-1 (4294967295 decimal), when it
- wraps around and starts increasing again from zero.
-
- Counters have no defined 'initial' value, and thus, a
- single value of a counter has (in general) no information
- content. Discontinuities in the monotonically increasing
- value normally occur at re-initialization of the
- management system, and at other times as specified in the
- description of a schema node using this type. If such
- other times can occur, for example, the creation of
- a schema node of type counter32 at times other than
- re-initialization, then a corresponding schema node
- should be defined, with an appropriate type, to indicate
- the last discontinuity.
-
- The counter32 type should not be used for configuration
- schema nodes. A default statement SHOULD NOT be used in
- combination with the type counter32.
-
- In the value set and its semantics, this type is equivalent
- to the Counter32 type of the SMIv2.";
- reference
- "RFC 2578: Structure of Management Information Version 2 (SMIv2)";
- }
-
- typedef zero-based-counter32 {
- type yang:counter32;
- default "0";
- description
- "The zero-based-counter32 type represents a counter32
- that has the defined 'initial' value zero.
-
- A schema node of this type will be set to zero (0) on creation
- and will thereafter increase monotonically until it reaches
- a maximum value of 2^32-1 (4294967295 decimal), when it
- wraps around and starts increasing again from zero.
-
- Provided that an application discovers a new schema node
- of this type within the minimum time to wrap, it can use the
- 'initial' value as a delta. It is important for a management
- station to be aware of this minimum time and the actual time
- between polls, and to discard data if the actual time is too
- long or there is no defined minimum time.
-
- In the value set and its semantics, this type is equivalent
- to the ZeroBasedCounter32 textual convention of the SMIv2.";
- reference
- "RFC 4502: Remote Network Monitoring Management Information
- Base Version 2";
- }
-
- typedef counter64 {
- type uint64;
- description
- "The counter64 type represents a non-negative integer
- that monotonically increases until it reaches a
- maximum value of 2^64-1 (18446744073709551615 decimal),
- when it wraps around and starts increasing again from zero.
-
- Counters have no defined 'initial' value, and thus, a
- single value of a counter has (in general) no information
- content. Discontinuities in the monotonically increasing
- value normally occur at re-initialization of the
- management system, and at other times as specified in the
- description of a schema node using this type. If such
- other times can occur, for example, the creation of
- a schema node of type counter64 at times other than
- re-initialization, then a corresponding schema node
- should be defined, with an appropriate type, to indicate
- the last discontinuity.
-
- The counter64 type should not be used for configuration
- schema nodes. A default statement SHOULD NOT be used in
- combination with the type counter64.
-
- In the value set and its semantics, this type is equivalent
- to the Counter64 type of the SMIv2.";
- reference
- "RFC 2578: Structure of Management Information Version 2 (SMIv2)";
- }
-
- typedef zero-based-counter64 {
- type yang:counter64;
- default "0";
- description
- "The zero-based-counter64 type represents a counter64 that
- has the defined 'initial' value zero.
-
- A schema node of this type will be set to zero (0) on creation
- and will thereafter increase monotonically until it reaches
- a maximum value of 2^64-1 (18446744073709551615 decimal),
- when it wraps around and starts increasing again from zero.
-
- Provided that an application discovers a new schema node
- of this type within the minimum time to wrap, it can use the
- 'initial' value as a delta. It is important for a management
- station to be aware of this minimum time and the actual time
- between polls, and to discard data if the actual time is too
- long or there is no defined minimum time.
-
- In the value set and its semantics, this type is equivalent
- to the ZeroBasedCounter64 textual convention of the SMIv2.";
- reference
- "RFC 2856: Textual Conventions for Additional High Capacity
- Data Types";
- }
-
- typedef gauge32 {
- type uint32;
- description
- "The gauge32 type represents a non-negative integer, which
- may increase or decrease, but shall never exceed a maximum
- value, nor fall below a minimum value. The maximum value
- cannot be greater than 2^32-1 (4294967295 decimal), and
- the minimum value cannot be smaller than 0. The value of
- a gauge32 has its maximum value whenever the information
- being modeled is greater than or equal to its maximum
- value, and has its minimum value whenever the information
- being modeled is smaller than or equal to its minimum value.
- If the information being modeled subsequently decreases
- below (increases above) the maximum (minimum) value, the
- gauge32 also decreases (increases).
-
- In the value set and its semantics, this type is equivalent
- to the Gauge32 type of the SMIv2.";
- reference
- "RFC 2578: Structure of Management Information Version 2 (SMIv2)";
- }
-
- typedef gauge64 {
- type uint64;
- description
- "The gauge64 type represents a non-negative integer, which
- may increase or decrease, but shall never exceed a maximum
- value, nor fall below a minimum value. The maximum value
- cannot be greater than 2^64-1 (18446744073709551615), and
- the minimum value cannot be smaller than 0. The value of
- a gauge64 has its maximum value whenever the information
- being modeled is greater than or equal to its maximum
- value, and has its minimum value whenever the information
- being modeled is smaller than or equal to its minimum value.
- If the information being modeled subsequently decreases
- below (increases above) the maximum (minimum) value, the
- gauge64 also decreases (increases).
-
- In the value set and its semantics, this type is equivalent
- to the CounterBasedGauge64 SMIv2 textual convention defined
- in RFC 2856";
- reference
- "RFC 2856: Textual Conventions for Additional High Capacity
- Data Types";
- }
-
- /*** collection of identifier related types ***/
-
- typedef object-identifier {
- type string {
- pattern '(([0-1](\.[1-3]?[0-9]))|(2\.(0|([1-9]\d*))))'
- + '(\.(0|([1-9]\d*)))*';
- }
- description
- "The object-identifier type represents administratively
- assigned names in a registration-hierarchical-name tree.
-
- Values of this type are denoted as a sequence of numerical
- non-negative sub-identifier values. Each sub-identifier
- value MUST NOT exceed 2^32-1 (4294967295). Sub-identifiers
- are separated by single dots and without any intermediate
- whitespace.
-
- The ASN.1 standard restricts the value space of the first
- sub-identifier to 0, 1, or 2. Furthermore, the value space
- of the second sub-identifier is restricted to the range
- 0 to 39 if the first sub-identifier is 0 or 1. Finally,
- the ASN.1 standard requires that an object identifier
- has always at least two sub-identifier. The pattern
- captures these restrictions.
-
- Although the number of sub-identifiers is not limited,
- module designers should realize that there may be
- implementations that stick with the SMIv2 limit of 128
- sub-identifiers.
-
- This type is a superset of the SMIv2 OBJECT IDENTIFIER type
- since it is not restricted to 128 sub-identifiers. Hence,
- this type SHOULD NOT be used to represent the SMIv2 OBJECT
- IDENTIFIER type, the object-identifier-128 type SHOULD be
- used instead.";
- reference
- "ISO9834-1: Information technology -- Open Systems
- Interconnection -- Procedures for the operation of OSI
- Registration Authorities: General procedures and top
- arcs of the ASN.1 Object Identifier tree";
- }
-
-
-
-
- typedef object-identifier-128 {
- type object-identifier {
- pattern '\d*(\.\d*){1,127}';
- }
- description
- "This type represents object-identifiers restricted to 128
- sub-identifiers.
-
- In the value set and its semantics, this type is equivalent
- to the OBJECT IDENTIFIER type of the SMIv2.";
- reference
- "RFC 2578: Structure of Management Information Version 2 (SMIv2)";
- }
-
- typedef yang-identifier {
- type string {
- length "1..max";
- pattern '[a-zA-Z_][a-zA-Z0-9\-_.]*';
- pattern '.|..|[^xX].*|.[^mM].*|..[^lL].*';
- }
- description
- "A YANG identifier string as defined by the 'identifier'
- rule in Section 12 of RFC 6020. An identifier must
- start with an alphabetic character or an underscore
- followed by an arbitrary sequence of alphabetic or
- numeric characters, underscores, hyphens, or dots.
-
- A YANG identifier MUST NOT start with any possible
- combination of the lowercase or uppercase character
- sequence 'xml'.";
- reference
- "RFC 6020: YANG - A Data Modeling Language for the Network
- Configuration Protocol (NETCONF)";
- }
-
- /*** collection of date and time related types ***/
-
- typedef date-and-time {
- type string {
- pattern '\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(\.\d+)?'
- + '(Z|[\+\-]\d{2}:\d{2})';
- }
- description
- "The date-and-time type is a profile of the ISO 8601
- standard for representation of dates and times using the
- Gregorian calendar. The profile is defined by the
- date-time production in Section 5.6 of RFC 3339.
-
- The date-and-time type is compatible with the dateTime XML
- schema type with the following notable exceptions:
-
- (a) The date-and-time type does not allow negative years.
-
- (b) The date-and-time time-offset -00:00 indicates an unknown
- time zone (see RFC 3339) while -00:00 and +00:00 and Z all
- represent the same time zone in dateTime.
-
- (c) The canonical format (see below) of data-and-time values
- differs from the canonical format used by the dateTime XML
- schema type, which requires all times to be in UTC using the
- time-offset 'Z'.
-
- This type is not equivalent to the DateAndTime textual
- convention of the SMIv2 since RFC 3339 uses a different
- separator between full-date and full-time and provides
- higher resolution of time-secfrac.
-
- The canonical format for date-and-time values with a known time
- zone uses a numeric time zone offset that is calculated using
- the device's configured known offset to UTC time. A change of
- the device's offset to UTC time will cause date-and-time values
- to change accordingly. Such changes might happen periodically
- in case a server follows automatically daylight saving time
- (DST) time zone offset changes. The canonical format for
- date-and-time values with an unknown time zone (usually referring
- to the notion of local time) uses the time-offset -00:00.";
- reference
- "RFC 3339: Date and Time on the Internet: Timestamps
- RFC 2579: Textual Conventions for SMIv2
- XSD-TYPES: XML Schema Part 2: Datatypes Second Edition";
- }
-
- typedef timeticks {
- type uint32;
- description
- "The timeticks type represents a non-negative integer that
- represents the time, modulo 2^32 (4294967296 decimal), in
- hundredths of a second between two epochs. When a schema
- node is defined that uses this type, the description of
- the schema node identifies both of the reference epochs.
-
- In the value set and its semantics, this type is equivalent
- to the TimeTicks type of the SMIv2.";
- reference
- "RFC 2578: Structure of Management Information Version 2 (SMIv2)";
- }
-
- typedef timestamp {
- type yang:timeticks;
- description
- "The timestamp type represents the value of an associated
- timeticks schema node at which a specific occurrence happened.
- The specific occurrence must be defined in the description
- of any schema node defined using this type. When the specific
- occurrence occurred prior to the last time the associated
- timeticks attribute was zero, then the timestamp value is
- zero. Note that this requires all timestamp values to be
- reset to zero when the value of the associated timeticks
- attribute reaches 497+ days and wraps around to zero.
-
- The associated timeticks schema node must be specified
- in the description of any schema node using this type.
-
- In the value set and its semantics, this type is equivalent
- to the TimeStamp textual convention of the SMIv2.";
- reference
- "RFC 2579: Textual Conventions for SMIv2";
- }
-
- /*** collection of generic address types ***/
-
- typedef phys-address {
- type string {
- pattern '([0-9a-fA-F]{2}(:[0-9a-fA-F]{2})*)?';
- }
- description
- "Represents media- or physical-level addresses represented
- as a sequence octets, each octet represented by two hexadecimal
- numbers. Octets are separated by colons. The canonical
- representation uses lowercase characters.
-
- In the value set and its semantics, this type is equivalent
- to the PhysAddress textual convention of the SMIv2.";
- reference
- "RFC 2579: Textual Conventions for SMIv2";
- }
-
- typedef mac-address {
- type string {
- pattern '[0-9a-fA-F]{2}(:[0-9a-fA-F]{2}){5}';
- }
- description
- "The mac-address type represents an IEEE 802 MAC address.
- The canonical representation uses lowercase characters.
-
- In the value set and its semantics, this type is equivalent
- to the MacAddress textual convention of the SMIv2.";
- reference
- "IEEE 802: IEEE Standard for Local and Metropolitan Area
- Networks: Overview and Architecture
- RFC 2579: Textual Conventions for SMIv2";
- }
-
- /*** collection of XML specific types ***/
-
- typedef xpath1.0 {
- type string;
- description
- "This type represents an XPATH 1.0 expression.
-
- When a schema node is defined that uses this type, the
- description of the schema node MUST specify the XPath
- context in which the XPath expression is evaluated.";
- reference
- "XPATH: XML Path Language (XPath) Version 1.0";
- }
-
- }
--- /dev/null
+module ietf-yang-types {
+
+ namespace "urn:ietf:params:xml:ns:yang:ietf-yang-types";
+ prefix "yang";
+
+ organization
+ "IETF NETMOD (NETCONF Data Modeling Language) Working Group";
+
+ contact
+ "WG Web: <http://tools.ietf.org/wg/netmod/>
+ WG List: <mailto:netmod@ietf.org>
+
+ WG Chair: David Kessens
+ <mailto:david.kessens@nsn.com>
+
+ WG Chair: Juergen Schoenwaelder
+ <mailto:j.schoenwaelder@jacobs-university.de>
+
+ Editor: Juergen Schoenwaelder
+ <mailto:j.schoenwaelder@jacobs-university.de>";
+
+ description
+ "This module contains a collection of generally useful derived
+ YANG data types.
+
+ 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.";
+
+ revision 2013-07-15 {
+ description
+ "This revision adds the following new data types:
+ - yang-identifier
+ - hex-string
+ - uuid
+ - dotted-quad";
+ reference
+ "RFC 6991: Common YANG Data Types";
+ }
+
+ revision 2010-09-24 {
+ description
+ "Initial revision.";
+ reference
+ "RFC 6021: Common YANG Data Types";
+ }
+
+ /*** collection of counter and gauge types ***/
+
+ typedef counter32 {
+ type uint32;
+ description
+ "The counter32 type represents a non-negative integer
+ that monotonically increases until it reaches a
+ maximum value of 2^32-1 (4294967295 decimal), when it
+ wraps around and starts increasing again from zero.
+
+ Counters have no defined 'initial' value, and thus, a
+ single value of a counter has (in general) no information
+ content. Discontinuities in the monotonically increasing
+ value normally occur at re-initialization of the
+ management system, and at other times as specified in the
+ description of a schema node using this type. If such
+ other times can occur, for example, the creation of
+ a schema node of type counter32 at times other than
+ re-initialization, then a corresponding schema node
+ should be defined, with an appropriate type, to indicate
+ the last discontinuity.
+
+ The counter32 type should not be used for configuration
+ schema nodes. A default statement SHOULD NOT be used in
+ combination with the type counter32.
+
+ In the value set and its semantics, this type is equivalent
+ to the Counter32 type of the SMIv2.";
+ reference
+ "RFC 2578: Structure of Management Information Version 2
+ (SMIv2)";
+ }
+
+ typedef zero-based-counter32 {
+ type yang:counter32;
+ default "0";
+ description
+ "The zero-based-counter32 type represents a counter32
+ that has the defined 'initial' value zero.
+
+ A schema node of this type will be set to zero (0) on creation
+ and will thereafter increase monotonically until it reaches
+ a maximum value of 2^32-1 (4294967295 decimal), when it
+ wraps around and starts increasing again from zero.
+
+ Provided that an application discovers a new schema node
+ of this type within the minimum time to wrap, it can use the
+ 'initial' value as a delta. It is important for a management
+ station to be aware of this minimum time and the actual time
+ between polls, and to discard data if the actual time is too
+ long or there is no defined minimum time.
+
+ In the value set and its semantics, this type is equivalent
+ to the ZeroBasedCounter32 textual convention of the SMIv2.";
+ reference
+ "RFC 4502: Remote Network Monitoring Management Information
+ Base Version 2";
+ }
+
+ typedef counter64 {
+ type uint64;
+ description
+ "The counter64 type represents a non-negative integer
+ that monotonically increases until it reaches a
+ maximum value of 2^64-1 (18446744073709551615 decimal),
+ when it wraps around and starts increasing again from zero.
+
+ Counters have no defined 'initial' value, and thus, a
+ single value of a counter has (in general) no information
+ content. Discontinuities in the monotonically increasing
+ value normally occur at re-initialization of the
+ management system, and at other times as specified in the
+ description of a schema node using this type. If such
+ other times can occur, for example, the creation of
+ a schema node of type counter64 at times other than
+ re-initialization, then a corresponding schema node
+ should be defined, with an appropriate type, to indicate
+ the last discontinuity.
+
+ The counter64 type should not be used for configuration
+ schema nodes. A default statement SHOULD NOT be used in
+ combination with the type counter64.
+
+ In the value set and its semantics, this type is equivalent
+ to the Counter64 type of the SMIv2.";
+ reference
+ "RFC 2578: Structure of Management Information Version 2
+ (SMIv2)";
+ }
+
+ typedef zero-based-counter64 {
+ type yang:counter64;
+ default "0";
+ description
+ "The zero-based-counter64 type represents a counter64 that
+ has the defined 'initial' value zero.
+
+ A schema node of this type will be set to zero (0) on creation
+ and will thereafter increase monotonically until it reaches
+ a maximum value of 2^64-1 (18446744073709551615 decimal),
+ when it wraps around and starts increasing again from zero.
+
+ Provided that an application discovers a new schema node
+ of this type within the minimum time to wrap, it can use the
+ 'initial' value as a delta. It is important for a management
+ station to be aware of this minimum time and the actual time
+ between polls, and to discard data if the actual time is too
+ long or there is no defined minimum time.
+
+ In the value set and its semantics, this type is equivalent
+ to the ZeroBasedCounter64 textual convention of the SMIv2.";
+ reference
+ "RFC 2856: Textual Conventions for Additional High Capacity
+ Data Types";
+ }
+
+ typedef gauge32 {
+ type uint32;
+ description
+ "The gauge32 type represents a non-negative integer, which
+ may increase or decrease, but shall never exceed a maximum
+ value, nor fall below a minimum value. The maximum value
+ cannot be greater than 2^32-1 (4294967295 decimal), and
+ the minimum value cannot be smaller than 0. The value of
+ a gauge32 has its maximum value whenever the information
+ being modeled is greater than or equal to its maximum
+ value, and has its minimum value whenever the information
+ being modeled is smaller than or equal to its minimum value.
+ If the information being modeled subsequently decreases
+ below (increases above) the maximum (minimum) value, the
+ gauge32 also decreases (increases).
+
+ In the value set and its semantics, this type is equivalent
+ to the Gauge32 type of the SMIv2.";
+ reference
+ "RFC 2578: Structure of Management Information Version 2
+ (SMIv2)";
+ }
+
+ typedef gauge64 {
+ type uint64;
+ description
+ "The gauge64 type represents a non-negative integer, which
+ may increase or decrease, but shall never exceed a maximum
+ value, nor fall below a minimum value. The maximum value
+ cannot be greater than 2^64-1 (18446744073709551615), and
+ the minimum value cannot be smaller than 0. The value of
+ a gauge64 has its maximum value whenever the information
+ being modeled is greater than or equal to its maximum
+ value, and has its minimum value whenever the information
+ being modeled is smaller than or equal to its minimum value.
+ If the information being modeled subsequently decreases
+ below (increases above) the maximum (minimum) value, the
+ gauge64 also decreases (increases).
+
+ In the value set and its semantics, this type is equivalent
+ to the CounterBasedGauge64 SMIv2 textual convention defined
+ in RFC 2856";
+ reference
+ "RFC 2856: Textual Conventions for Additional High Capacity
+ Data Types";
+ }
+
+ /*** collection of identifier-related types ***/
+
+ typedef object-identifier {
+ type string {
+ pattern '(([0-1](\.[1-3]?[0-9]))|(2\.(0|([1-9]\d*))))'
+ + '(\.(0|([1-9]\d*)))*';
+ }
+ description
+ "The object-identifier type represents administratively
+ assigned names in a registration-hierarchical-name tree.
+
+ Values of this type are denoted as a sequence of numerical
+ non-negative sub-identifier values. Each sub-identifier
+ value MUST NOT exceed 2^32-1 (4294967295). Sub-identifiers
+ are separated by single dots and without any intermediate
+ whitespace.
+
+ The ASN.1 standard restricts the value space of the first
+ sub-identifier to 0, 1, or 2. Furthermore, the value space
+ of the second sub-identifier is restricted to the range
+ 0 to 39 if the first sub-identifier is 0 or 1. Finally,
+ the ASN.1 standard requires that an object identifier
+ has always at least two sub-identifiers. The pattern
+ captures these restrictions.
+
+ Although the number of sub-identifiers is not limited,
+ module designers should realize that there may be
+ implementations that stick with the SMIv2 limit of 128
+ sub-identifiers.
+
+ This type is a superset of the SMIv2 OBJECT IDENTIFIER type
+ since it is not restricted to 128 sub-identifiers. Hence,
+ this type SHOULD NOT be used to represent the SMIv2 OBJECT
+ IDENTIFIER type; the object-identifier-128 type SHOULD be
+ used instead.";
+ reference
+ "ISO9834-1: Information technology -- Open Systems
+ Interconnection -- Procedures for the operation of OSI
+ Registration Authorities: General procedures and top
+ arcs of the ASN.1 Object Identifier tree";
+ }
+
+ typedef object-identifier-128 {
+ type object-identifier {
+ pattern '\d*(\.\d*){1,127}';
+ }
+ description
+ "This type represents object-identifiers restricted to 128
+ sub-identifiers.
+
+ In the value set and its semantics, this type is equivalent
+ to the OBJECT IDENTIFIER type of the SMIv2.";
+ reference
+ "RFC 2578: Structure of Management Information Version 2
+ (SMIv2)";
+ }
+
+ typedef yang-identifier {
+ type string {
+ length "1..max";
+ pattern '[a-zA-Z_][a-zA-Z0-9\-_.]*';
+ pattern '.|..|[^xX].*|.[^mM].*|..[^lL].*';
+ }
+ description
+ "A YANG identifier string as defined by the 'identifier'
+ rule in Section 12 of RFC 6020. An identifier must
+ start with an alphabetic character or an underscore
+ followed by an arbitrary sequence of alphabetic or
+ numeric characters, underscores, hyphens, or dots.
+
+ A YANG identifier MUST NOT start with any possible
+ combination of the lowercase or uppercase character
+ sequence 'xml'.";
+ reference
+ "RFC 6020: YANG - A Data Modeling Language for the Network
+ Configuration Protocol (NETCONF)";
+ }
+
+ /*** collection of types related to date and time***/
+
+ typedef date-and-time {
+ type string {
+ pattern '\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(\.\d+)?'
+ + '(Z|[\+\-]\d{2}:\d{2})';
+ }
+ description
+ "The date-and-time type is a profile of the ISO 8601
+ standard for representation of dates and times using the
+ Gregorian calendar. The profile is defined by the
+ date-time production in Section 5.6 of RFC 3339.
+
+ The date-and-time type is compatible with the dateTime XML
+ schema type with the following notable exceptions:
+
+ (a) The date-and-time type does not allow negative years.
+
+ (b) The date-and-time time-offset -00:00 indicates an unknown
+ time zone (see RFC 3339) while -00:00 and +00:00 and Z
+ all represent the same time zone in dateTime.
+
+ (c) The canonical format (see below) of data-and-time values
+ differs from the canonical format used by the dateTime XML
+ schema type, which requires all times to be in UTC using
+ the time-offset 'Z'.
+
+ This type is not equivalent to the DateAndTime textual
+ convention of the SMIv2 since RFC 3339 uses a different
+ separator between full-date and full-time and provides
+ higher resolution of time-secfrac.
+
+ The canonical format for date-and-time values with a known time
+ zone uses a numeric time zone offset that is calculated using
+ the device's configured known offset to UTC time. A change of
+ the device's offset to UTC time will cause date-and-time values
+ to change accordingly. Such changes might happen periodically
+ in case a server follows automatically daylight saving time
+ (DST) time zone offset changes. The canonical format for
+ date-and-time values with an unknown time zone (usually
+ referring to the notion of local time) uses the time-offset
+ -00:00.";
+ reference
+ "RFC 3339: Date and Time on the Internet: Timestamps
+ RFC 2579: Textual Conventions for SMIv2
+ XSD-TYPES: XML Schema Part 2: Datatypes Second Edition";
+ }
+
+ typedef timeticks {
+ type uint32;
+ description
+ "The timeticks type represents a non-negative integer that
+ represents the time, modulo 2^32 (4294967296 decimal), in
+ hundredths of a second between two epochs. When a schema
+ node is defined that uses this type, the description of
+ the schema node identifies both of the reference epochs.
+
+ In the value set and its semantics, this type is equivalent
+ to the TimeTicks type of the SMIv2.";
+ reference
+ "RFC 2578: Structure of Management Information Version 2
+ (SMIv2)";
+ }
+
+ typedef timestamp {
+ type yang:timeticks;
+ description
+ "The timestamp type represents the value of an associated
+ timeticks schema node at which a specific occurrence
+ happened. The specific occurrence must be defined in the
+ description of any schema node defined using this type. When
+ the specific occurrence occurred prior to the last time the
+ associated timeticks attribute was zero, then the timestamp
+ value is zero. Note that this requires all timestamp values
+ to be reset to zero when the value of the associated timeticks
+ attribute reaches 497+ days and wraps around to zero.
+
+ The associated timeticks schema node must be specified
+ in the description of any schema node using this type.
+
+ In the value set and its semantics, this type is equivalent
+ to the TimeStamp textual convention of the SMIv2.";
+ reference
+ "RFC 2579: Textual Conventions for SMIv2";
+ }
+
+ /*** collection of generic address types ***/
+
+ typedef phys-address {
+ type string {
+ pattern '([0-9a-fA-F]{2}(:[0-9a-fA-F]{2})*)?';
+ }
+
+ description
+ "Represents media- or physical-level addresses represented
+ as a sequence octets, each octet represented by two hexadecimal
+ numbers. Octets are separated by colons. The canonical
+ representation uses lowercase characters.
+
+ In the value set and its semantics, this type is equivalent
+ to the PhysAddress textual convention of the SMIv2.";
+ reference
+ "RFC 2579: Textual Conventions for SMIv2";
+ }
+
+ typedef mac-address {
+ type string {
+ pattern '[0-9a-fA-F]{2}(:[0-9a-fA-F]{2}){5}';
+ }
+ description
+ "The mac-address type represents an IEEE 802 MAC address.
+ The canonical representation uses lowercase characters.
+
+ In the value set and its semantics, this type is equivalent
+ to the MacAddress textual convention of the SMIv2.";
+ reference
+ "IEEE 802: IEEE Standard for Local and Metropolitan Area
+ Networks: Overview and Architecture
+ RFC 2579: Textual Conventions for SMIv2";
+ }
+
+ /*** collection of XML-specific types ***/
+
+ typedef xpath1.0 {
+ type string;
+ description
+ "This type represents an XPATH 1.0 expression.
+
+ When a schema node is defined that uses this type, the
+ description of the schema node MUST specify the XPath
+ context in which the XPath expression is evaluated.";
+ reference
+ "XPATH: XML Path Language (XPath) Version 1.0";
+ }
+
+ /*** collection of string types ***/
+
+ typedef hex-string {
+ type string {
+ pattern '([0-9a-fA-F]{2}(:[0-9a-fA-F]{2})*)?';
+ }
+ description
+ "A hexadecimal string with octets represented as hex digits
+ separated by colons. The canonical representation uses
+ lowercase characters.";
+ }
+
+ typedef uuid {
+ type string {
+ pattern '[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-'
+ + '[0-9a-fA-F]{4}-[0-9a-fA-F]{12}';
+ }
+ description
+ "A Universally Unique IDentifier in the string representation
+ defined in RFC 4122. The canonical representation uses
+ lowercase characters.
+
+ The following is an example of a UUID in string representation:
+ f81d4fae-7dec-11d0-a765-00a0c91e6bf6
+ ";
+ reference
+ "RFC 4122: A Universally Unique IDentifier (UUID) URN
+ Namespace";
+ }
+
+ typedef dotted-quad {
+ type string {
+ pattern
+ '(([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])';
+ }
+ description
+ "An unsigned 32-bit number expressed in the dotted-quad
+ notation, i.e., four octets written as decimal numbers
+ and separated with the '.' (full stop) character.";
+ }
+}
Code Review / netconf.git / commitdiff