ryu/build/lib.linux-armv7l-2.7/ryu/lib/of_config/ietf-inet-types.xsd

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