yang/yang-parser-rfc7950/src/test/resources/semantic-statement-parser/yin/test.yin

   1 <module xmlns="urn:ietf:params:xml:ns:yang:yin:1" name="my-test">
   2     <yang-version value="1"></yang-version>
   3     <namespace uri="urn:ietf:params:xml:ns:yang:ietf-inet-types"></namespace>
   4     <prefix value="inet"></prefix>
   5
   6     <organization><text>IETF NETMOD (NETCONF Data Modeling Language) Working Group"></text></organization>
   7     <contact><text>WG Web:   &lt;http://tools.ietf.org/wg/netmod/&gt;
   8     WG List:  &lt;mailto:netmod@ietf.org&gt;
   9
  10     WG Chair: David Partain
  11               &lt;mailto:david.partain@ericsson.com&gt;
  12
  13     WG Chair: David Kessens
  14               &lt;mailto:david.kessens@nsn.com&gt;
  15
  16     Editor:   Juergen Schoenwaelder
  17               &lt;mailto:j.schoenwaelder@jacobs-university.de&gt;</text></contact>
  18
  19     <description><text>This module contains a collection of generally useful derived
  20     YANG data types for Internet addresses and related things.
  21
  22     Copyright (c) 2010 IETF Trust and the persons identified as
  23     authors of the code.  All rights reserved.
  24
  25
  26
  27     Redistribution and use in source and binary forms, with or without
  28     modification, is permitted pursuant to, and subject to the license
  29     terms contained in, the Simplified BSD License set forth in Section
  30     4.c of the IETF Trust's Legal Provisions Relating to IETF Documents
  31     (http://trustee.ietf.org/license-info).
  32
  33     This version of this YANG module is part of RFC 6021; see
  34     the RFC itself for full legal notices.</text></description>
  35
  36     <reference><text>RFC 6021: Common YANG Data Types</text></reference>
  37     <revision date="2010-09-24"></revision>
  38
  39     <typedef name="as-number">
  40         <type name="uint32"></type>
  41         <status value="current"></status>
  42         <description><text>The as-number type represents autonomous system numbers
  43       which identify an Autonomous System (AS).  An AS is a set
  44       of routers under a single technical administration, using
  45       an interior gateway protocol and common metrics to route
  46       packets within the AS, and using an exterior gateway
  47       protocol to route packets to other ASs'.  IANA maintains
  48       the AS number space and has delegated large parts to the
  49       regional registries.
  50
  51       Autonomous system numbers were originally limited to 16
  52       bits.  BGP extensions have enlarged the autonomous system
  53       number space to 32 bits.  This type therefore uses an uint32
  54       base type without a range restriction in order to support
  55       a larger autonomous system number space.
  56
  57       In the value set and its semantics, this type is equivalent
  58       to the InetAutonomousSystemNumber textual convention of
  59       the SMIv2.</text></description>
  60
  61         <reference><text>RFC 1930: Guidelines for creation, selection, and registration
  62                 of an Autonomous System (AS)
  63       RFC 4271: A Border Gateway Protocol 4 (BGP-4)
  64       RFC 4893: BGP Support for Four-octet AS Number Space
  65       RFC 4001: Textual Conventions for Internet Network Addresses</text></reference>
  66     </typedef>
  67
  68     <typedef name="domain-name">
  69         <type name="string">
  70             <length value="1..253">
  71                 <error-message><value>The argument is out of bounds &lt;1, 253&gt;</value></error-message>
  72                 <error-app-tag value="length-out-of-specified-bounds"></error-app-tag>
  73             </length>
  74             <pattern
  75                     value="^((([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.)*([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.?)|\.$">
  76                 <error-app-tag value="invalid-regular-expression"></error-app-tag>
  77             </pattern>
  78         </type>
  79         <status value="current"></status>
  80
  81         <description><text>The domain-name type represents a DNS domain name.  The
  82       name SHOULD be fully qualified whenever possible.
  83
  84       Internet domain names are only loosely specified.  Section
  85       3.5 of RFC 1034 recommends a syntax (modified in Section
  86       2.1 of RFC 1123).  The pattern above is intended to allow
  87       for current practice in domain name use, and some possible
  88       future expansion.  It is designed to hold various types of
  89       domain names, including names used for A or AAAA records
  90       (host names) and other records, such as SRV records.  Note
  91       that Internet host names have a stricter syntax (described
  92       in RFC 952) than the DNS recommendations in RFCs 1034 and
  93       1123, and that systems that want to store host names in
  94       schema nodes using the domain-name type are recommended to
  95       adhere to this stricter standard to ensure interoperability.
  96
  97       The encoding of DNS names in the DNS protocol is limited
  98       to 255 characters.  Since the encoding consists of labels
  99       prefixed by a length bytes and there is a trailing NULL
 100       byte, only 253 characters can appear in the textual dotted
 101       notation.
 102
 103       The description clause of schema nodes using the domain-name
 104       type MUST describe when and how these names are resolved to
 105       IP addresses.  Note that the resolution of a domain-name value
 106       may require to query multiple DNS records (e.g., A for IPv4
 107       and AAAA for IPv6).  The order of the resolution process and
 108       which DNS record takes precedence can either be defined
 109       explicitely or it may depend on the configuration of the
 110       resolver.
 111
 112       Domain-name values use the US-ASCII encoding.  Their canonical
 113       format uses lowercase US-ASCII characters.  Internationalized
 114       domain names MUST be encoded in punycode as described in RFC
 115       3492</text></description>
 116
 117         <reference><text>RFC  952: DoD Internet Host Table Specification
 118       RFC 1034: Domain Names - Concepts and Facilities
 119       RFC 1123: Requirements for Internet Hosts -- Application
 120                 and Support
 121       RFC 2782: A DNS RR for specifying the location of services
 122                 (DNS SRV)
 123       RFC 3492: Punycode: A Bootstring encoding of Unicode for
 124                 Internationalized Domain Names in Applications
 125                 (IDNA)
 126       RFC 5891: Internationalizing Domain Names in Applications
 127                 (IDNA): Protocol</text></reference>
 128
 129     </typedef>
 130
 131     <typedef name="dscp">
 132         <type name="uint8">
 133             <range value="0..63">
 134                 <error-message><value>The argument is out of bounds &lt;0, 63&gt;</value></error-message>
 135                 <error-app-tag value="range-out-of-specified-bounds"></error-app-tag>
 136             </range>
 137         </type>
 138         <status value="current"></status>
 139         <description><text>The dscp type represents a Differentiated Services Code-Point
 140       that may be used for marking packets in a traffic stream.
 141
 142       In the value set and its semantics, this type is equivalent
 143       to the Dscp textual convention of the SMIv2.</text></description>
 144         <reference><text>RFC 3289: Management Information Base for the Differentiated
 145                 Services Architecture
 146       RFC 2474: Definition of the Differentiated Services Field
 147                 (DS Field) in the IPv4 and IPv6 Headers
 148       RFC 2780: IANA Allocation Guidelines For Values In
 149                 the Internet Protocol and Related Headers</text></reference>
 150     </typedef>
 151     <typedef name="host">
 152         <type name="union">
 153             <type name="ip-address"></type>
 154             <type name="domain-name"></type>
 155         </type>
 156         <status value="current"></status>
 157         <description><text>The host type represents either an IP address or a DNS
 158       domain name.</text></description>
 159     </typedef>
 160     <typedef name="ip-address">
 161         <type name="union">
 162             <type name="ipv4-address"></type>
 163             <type name="ipv6-address"></type>
 164         </type>
 165         <status value="current"></status>
 166         <description><text>The ip-address type represents an IP address and is IP
 167       version neutral.  The format of the textual representations
 168       implies the IP version.</text></description>
 169     </typedef>
 170     <typedef name="ip-prefix">
 171         <type name="union">
 172             <type name="ipv4-prefix"></type>
 173             <type name="ipv6-prefix"></type>
 174         </type>
 175         <status value="current"></status>
 176         <description><text>The ip-prefix type represents an IP prefix and is IP
 177       version neutral.  The format of the textual representations
 178       implies the IP version.</text></description>
 179     </typedef>
 180     <typedef name="ip-version">
 181         <type name="enumeration">
 182             <enum name="unknown">
 183                 <value value="0"></value>
 184                 <description><text>An unknown or unspecified version of the Internet protocol.</text></description>
 185             </enum>
 186             <enum name="ipv4">
 187                 <value value="1"></value>
 188                 <description><text>The IPv4 protocol as defined in RFC 791.</text></description>
 189             </enum>
 190             <enum name="ipv6">
 191                 <value value="2"></value>
 192                 <description><text>The IPv6 protocol as defined in RFC 2460.</text></description>
 193             </enum>
 194         </type>
 195         <status value="current"></status>
 196         <description><text>This value represents the version of the IP protocol.
 197
 198       In the value set and its semantics, this type is equivalent
 199       to the InetVersion textual convention of the SMIv2.</text></description>
 200         <reference><text>RFC  791: Internet Protocol
 201       RFC 2460: Internet Protocol, Version 6 (IPv6) Specification
 202       RFC 4001: Textual Conventions for Internet Network Addresses</text></reference>
 203     </typedef>
 204     <typedef name="ipv4-address">
 205         <type name="string">
 206             <pattern
 207                     value="^(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])(%[\p{N}\p{L}]+)?$">
 208                 <error-app-tag value="invalid-regular-expression"></error-app-tag>
 209             </pattern>
 210         </type>
 211         <status value="current"></status>
 212         <description><text>The ipv4-address type represents an IPv4 address in
 213        dotted-quad notation.  The IPv4 address may include a zone
 214        index, separated by a % sign.
 215
 216        The zone index is used to disambiguate identical address
 217        values.  For link-local addresses, the zone index will
 218        typically be the interface index number or the name of an
 219        interface.  If the zone index is not present, the default
 220        zone of the device will be used.
 221
 222        The canonical format for the zone index is the numerical
 223        format</text></description>
 224     </typedef>
 225     <typedef name="ipv4-prefix">
 226         <type name="string">
 227             <pattern
 228                     value="^(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])/(([0-9])|([1-2][0-9])|(3[0-2]))$">
 229                 <error-app-tag value="invalid-regular-expression"></error-app-tag>
 230             </pattern>
 231         </type>
 232         <status value="current"></status>
 233         <description><text>The ipv4-prefix type represents an IPv4 address prefix.
 234       The prefix length is given by the number following the
 235       slash character and must be less than or equal to 32.
 236
 237
 238
 239       A prefix length value of n corresponds to an IP address
 240       mask that has n contiguous 1-bits from the most
 241       significant bit (MSB) and all other bits set to 0.
 242
 243       The canonical format of an IPv4 prefix has all bits of
 244       the IPv4 address set to zero that are not part of the
 245       IPv4 prefix.</text></description>
 246     </typedef>
 247     <typedef name="ipv6-address">
 248         <type name="string">
 249             <pattern
 250                     value="^((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))(%[\p{N}\p{L}]+)?$">
 251                 <error-app-tag value="invalid-regular-expression"></error-app-tag>
 252             </pattern>
 253             <pattern value="^(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)(%.+)?$">
 254                 <error-app-tag value="invalid-regular-expression"></error-app-tag>
 255             </pattern>
 256         </type>
 257         <status value="current"></status>
 258         <description><text>The ipv6-address type represents an IPv6 address in full,
 259       mixed, shortened, and shortened-mixed notation.  The IPv6
 260       address may include a zone index, separated by a % sign.
 261
 262
 263
 264
 265
 266       The zone index is used to disambiguate identical address
 267       values.  For link-local addresses, the zone index will
 268       typically be the interface index number or the name of an
 269       interface.  If the zone index is not present, the default
 270       zone of the device will be used.
 271
 272       The canonical format of IPv6 addresses uses the compressed
 273       format described in RFC 4291, Section 2.2, item 2 with the
 274       following additional rules: the :: substitution must be
 275       applied to the longest sequence of all-zero 16-bit chunks
 276       in an IPv6 address.  If there is a tie, the first sequence
 277       of all-zero 16-bit chunks is replaced by ::.  Single
 278       all-zero 16-bit chunks are not compressed.  The canonical
 279       format uses lowercase characters and leading zeros are
 280       not allowed.  The canonical format for the zone index is
 281       the numerical format as described in RFC 4007, Section
 282       11.2.</text></description>
 283         <reference><text>RFC 4291: IP Version 6 Addressing Architecture
 284       RFC 4007: IPv6 Scoped Address Architecture
 285       RFC 5952: A Recommendation for IPv6 Address Text Representation</text></reference>
 286     </typedef>
 287     <typedef name="ipv6-flow-label">
 288         <type name="uint32">
 289             <range value="0..1048575">
 290                 <error-message><value>The argument is out of bounds &lt;0, 1048575&gt;</value></error-message>
 291                 <error-app-tag value="range-out-of-specified-bounds"></error-app-tag>
 292             </range>
 293         </type>
 294         <status value="current"></status>
 295         <description><text>The flow-label type represents flow identifier or Flow Label
 296       in an IPv6 packet header that may be used to discriminate
 297       traffic flows.
 298
 299       In the value set and its semantics, this type is equivalent
 300       to the IPv6FlowLabel textual convention of the SMIv2.</text></description>
 301         <reference><text>RFC 3595: Textual Conventions for IPv6 Flow Label
 302       RFC 2460: Internet Protocol, Version 6 (IPv6) Specification</text></reference>
 303     </typedef>
 304     <typedef name="ipv6-prefix">
 305         <type name="string">
 306             <pattern
 307                     value="^((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))(/(([0-9])|([0-9]{2})|(1[0-1][0-9])|(12[0-8])))$">
 308                 <error-app-tag value="invalid-regular-expression"></error-app-tag>
 309             </pattern>
 310             <pattern value="^(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)(/.+)$">
 311                 <error-app-tag value="invalid-regular-expression"></error-app-tag>
 312             </pattern>
 313         </type>
 314         <status value="current"></status>
 315         <description><text>The ipv6-prefix type represents an IPv6 address prefix.
 316       The prefix length is given by the number following the
 317       slash character and must be less than or equal 128.
 318
 319       A prefix length value of n corresponds to an IP address
 320       mask that has n contiguous 1-bits from the most
 321       significant bit (MSB) and all other bits set to 0.
 322
 323       The IPv6 address should have all bits that do not belong
 324       to the prefix set to zero.
 325
 326       The canonical format of an IPv6 prefix has all bits of
 327       the IPv6 address set to zero that are not part of the
 328       IPv6 prefix.  Furthermore, IPv6 address is represented
 329       in the compressed format described in RFC 4291, Section
 330       2.2, item 2 with the following additional rules: the ::
 331       substitution must be applied to the longest sequence of
 332       all-zero 16-bit chunks in an IPv6 address.  If there is
 333       a tie, the first sequence of all-zero 16-bit chunks is
 334       replaced by ::.  Single all-zero 16-bit chunks are not
 335       compressed.  The canonical format uses lowercase
 336       characters and leading zeros are not allowed.</text></description>
 337         <reference><text>RFC 4291: IP Version 6 Addressing Architecture</text></reference>
 338     </typedef>
 339     <typedef name="port-number">
 340         <type name="uint16">
 341             <range value="0..65535">
 342                 <error-message><value>The argument is out of bounds &lt;0, 65535&gt;</value></error-message>
 343                 <error-app-tag value="range-out-of-specified-bounds"></error-app-tag>
 344             </range>
 345         </type>
 346         <status value="current"></status>
 347         <description><text>The port-number type represents a 16-bit port number of an
 348       Internet transport layer protocol such as UDP, TCP, DCCP, or
 349       SCTP.  Port numbers are assigned by IANA.  A current list of
 350       all assignments is available from &lt;http://www.iana.org/&gt;.
 351
 352       Note that the port number value zero is reserved by IANA.  In
 353       situations where the value zero does not make sense, it can
 354       be excluded by subtyping the port-number type.
 355
 356       In the value set and its semantics, this type is equivalent
 357       to the InetPortNumber textual convention of the SMIv2.</text></description>
 358         <reference><text>RFC  768: User Datagram Protocol
 359       RFC  793: Transmission Control Protocol
 360       RFC 4960: Stream Control Transmission Protocol
 361       RFC 4340: Datagram Congestion Control Protocol (DCCP)
 362       RFC 4001: Textual Conventions for Internet Network Addresses</text></reference>
 363     </typedef>
 364     <typedef name="uri">
 365         <type name="string"></type>
 366         <status value="current"></status>
 367         <description><text>The uri type represents a Uniform Resource Identifier
 368       (URI) as defined by STD 66.
 369
 370       Objects using the uri type MUST be in US-ASCII encoding,
 371       and MUST be normalized as described by RFC 3986 Sections
 372       6.2.1, 6.2.2.1, and 6.2.2.2.  All unnecessary
 373       percent-encoding is removed, and all case-insensitive
 374       characters are set to lowercase except for hexadecimal
 375       digits, which are normalized to uppercase as described in
 376       Section 6.2.2.1.
 377
 378       The purpose of this normalization is to help provide
 379       unique URIs.  Note that this normalization is not
 380       sufficient to provide uniqueness.  Two URIs that are
 381       textually distinct after this normalization may still be
 382       equivalent.
 383
 384       Objects using the uri type may restrict the schemes that
 385       they permit.  For example, 'data:' and 'urn:' schemes
 386       might not be appropriate.
 387
 388       A zero-length URI is not a valid URI.  This can be used to
 389       express 'URI absent' where required.
 390
 391       In the value set and its semantics, this type is equivalent
 392       to the Uri SMIv2 textual convention defined in RFC 5017.</text></description>
 393         <reference><text>RFC 3986: Uniform Resource Identifier (URI): Generic Syntax
 394       RFC 3305: Report from the Joint W3C/IETF URI Planning Interest
 395                 Group: Uniform Resource Identifiers (URIs), URLs,
 396                 and Uniform Resource Names (URNs): Clarifications
 397                 and Recommendations
 398       RFC 5017: MIB Textual Conventions for Uniform Resource
 399                 Identifiers (URIs)</text></reference>
 400     </typedef>
 401
 402 </module>