diff options
Diffstat (limited to 'vnfs/TestVNF/netconftemplates/netconftemplates/ietf-yang-types@2013-07-15.yin')
| -rw-r--r-- | vnfs/TestVNF/netconftemplates/netconftemplates/ietf-yang-types@2013-07-15.yin | 479 |
1 files changed, 479 insertions, 0 deletions
diff --git a/vnfs/TestVNF/netconftemplates/netconftemplates/ietf-yang-types@2013-07-15.yin b/vnfs/TestVNF/netconftemplates/netconftemplates/ietf-yang-types@2013-07-15.yin new file mode 100644 index 00000000..07db8feb --- /dev/null +++ b/vnfs/TestVNF/netconftemplates/netconftemplates/ietf-yang-types@2013-07-15.yin @@ -0,0 +1,479 @@ +<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="m-1"> + <data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring"><?xml version="1.0" encoding="UTF-8"?> +<module name="ietf-yang-types" + xmlns="urn:ietf:params:xml:ns:yang:yin:1" + xmlns:yang="urn:ietf:params:xml:ns:yang:ietf-yang-types"> + <namespace uri="urn:ietf:params:xml:ns:yang:ietf-yang-types"/> + <prefix value="yang"/> + <organization> + <text>IETF NETMOD (NETCONF Data Modeling Language) Working Group</text> + </organization> + <contact> + <text>WG Web: &lt;http://tools.ietf.org/wg/netmod/&gt; +WG List: &lt;mailto:netmod@ietf.org&gt; + +WG Chair: David Kessens + &lt;mailto:david.kessens@nsn.com&gt; + +WG Chair: Juergen Schoenwaelder + &lt;mailto:j.schoenwaelder@jacobs-university.de&gt; + +Editor: Juergen Schoenwaelder + &lt;mailto:j.schoenwaelder@jacobs-university.de&gt;</text> + </contact> + <description> + <text>This module contains a collection of generally useful derived +YANG data types. + +Copyright (c) 2013 IETF Trust and the persons identified as +authors of the code. All rights reserved. + +Redistribution and use in source and binary forms, with or +without modification, is permitted pursuant to, and subject +to the license terms contained in, the Simplified BSD License +set forth in Section 4.c of the IETF Trust's Legal Provisions +Relating to IETF Documents +(http://trustee.ietf.org/license-info). + +This version of this YANG module is part of RFC 6991; see +the RFC itself for full legal notices.</text> + </description> + <revision date="2013-07-15"> + <description> + <text>This revision adds the following new data types: +- yang-identifier +- hex-string +- uuid +- dotted-quad</text> + </description> + <reference> + <text>RFC 6991: Common YANG Data Types</text> + </reference> + </revision> + <revision date="2010-09-24"> + <description> + <text>Initial revision.</text> + </description> + <reference> + <text>RFC 6021: Common YANG Data Types</text> + </reference> + </revision> + <typedef name="counter32"> + <type name="uint32"/> + <description> + <text>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.</text> + </description> + <reference> + <text>RFC 2578: Structure of Management Information Version 2 + (SMIv2)</text> + </reference> + </typedef> + <typedef name="zero-based-counter32"> + <type name="yang:counter32"/> + <default value="0"/> + <description> + <text>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.</text> + </description> + <reference> + <text>RFC 4502: Remote Network Monitoring Management Information + Base Version 2</text> + </reference> + </typedef> + <typedef name="counter64"> + <type name="uint64"/> + <description> + <text>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.</text> + </description> + <reference> + <text>RFC 2578: Structure of Management Information Version 2 + (SMIv2)</text> + </reference> + </typedef> + <typedef name="zero-based-counter64"> + <type name="yang:counter64"/> + <default value="0"/> + <description> + <text>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.</text> + </description> + <reference> + <text>RFC 2856: Textual Conventions for Additional High Capacity + Data Types</text> + </reference> + </typedef> + <typedef name="gauge32"> + <type name="uint32"/> + <description> + <text>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.</text> + </description> + <reference> + <text>RFC 2578: Structure of Management Information Version 2 + (SMIv2)</text> + </reference> + </typedef> + <typedef name="gauge64"> + <type name="uint64"/> + <description> + <text>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</text> + </description> + <reference> + <text>RFC 2856: Textual Conventions for Additional High Capacity + Data Types</text> + </reference> + </typedef> + <typedef name="object-identifier"> + <type name="string"> + <pattern value="(([0-1](\.[1-3]?[0-9]))|(2\.(0|([1-9]\d*))))(\.(0|([1-9]\d*)))*"/> + </type> + <description> + <text>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.</text> + </description> + <reference> + <text>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</text> + </reference> + </typedef> + <typedef name="object-identifier-128"> + <type name="object-identifier"> + <pattern value="\d*(\.\d*){1,127}"/> + </type> + <description> + <text>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.</text> + </description> + <reference> + <text>RFC 2578: Structure of Management Information Version 2 + (SMIv2)</text> + </reference> + </typedef> + <typedef name="yang-identifier"> + <type name="string"> + <length value="1..max"/> + <pattern value="[a-zA-Z_][a-zA-Z0-9\-_.]*"/> + <pattern value=".|..|[^xX].*|.[^mM].*|..[^lL].*"/> + </type> + <description> + <text>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'.</text> + </description> + <reference> + <text>RFC 6020: YANG - A Data Modeling Language for the Network + Configuration Protocol (NETCONF)</text> + </reference> + </typedef> + <typedef name="date-and-time"> + <type name="string"> + <pattern value="\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(\.\d+)?(Z|[\+\-]\d{2}:\d{2})"/> + </type> + <description> + <text>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.</text> + </description> + <reference> + <text>RFC 3339: Date and Time on the Internet: Timestamps +RFC 2579: Textual Conventions for SMIv2 +XSD-TYPES: XML Schema Part 2: Datatypes Second Edition</text> + </reference> + </typedef> + <typedef name="timeticks"> + <type name="uint32"/> + <description> + <text>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.</text> + </description> + <reference> + <text>RFC 2578: Structure of Management Information Version 2 + (SMIv2)</text> + </reference> + </typedef> + <typedef name="timestamp"> + <type name="yang:timeticks"/> + <description> + <text>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.</text> + </description> + <reference> + <text>RFC 2579: Textual Conventions for SMIv2</text> + </reference> + </typedef> + <typedef name="phys-address"> + <type name="string"> + <pattern value="([0-9a-fA-F]{2}(:[0-9a-fA-F]{2})*)?"/> + </type> + <description> + <text>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.</text> + </description> + <reference> + <text>RFC 2579: Textual Conventions for SMIv2</text> + </reference> + </typedef> + <typedef name="mac-address"> + <type name="string"> + <pattern value="[0-9a-fA-F]{2}(:[0-9a-fA-F]{2}){5}"/> + </type> + <description> + <text>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.</text> + </description> + <reference> + <text>IEEE 802: IEEE Standard for Local and Metropolitan Area + Networks: Overview and Architecture +RFC 2579: Textual Conventions for SMIv2</text> + </reference> + </typedef> + <typedef name="xpath1.0"> + <type name="string"/> + <description> + <text>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.</text> + </description> + <reference> + <text>XPATH: XML Path Language (XPath) Version 1.0</text> + </reference> + </typedef> + <typedef name="hex-string"> + <type name="string"> + <pattern value="([0-9a-fA-F]{2}(:[0-9a-fA-F]{2})*)?"/> + </type> + <description> + <text>A hexadecimal string with octets represented as hex digits +separated by colons. The canonical representation uses +lowercase characters.</text> + </description> + </typedef> + <typedef name="uuid"> + <type name="string"> + <pattern value="[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}"/> + </type> + <description> + <text>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 +</text> + </description> + <reference> + <text>RFC 4122: A Universally Unique IDentifier (UUID) URN + Namespace</text> + </reference> + </typedef> + <typedef name="dotted-quad"> + <type name="string"> + <pattern value="(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])"/> + </type> + <description> + <text>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.</text> + </description> + </typedef> +</module> +</data> +</rpc-reply> |