Common YANG Data TypesJacobs Universityj.schoenwaelder@jacobs-university.de
This document introduces a collection of common data types to be used
with the YANG data modeling language. This document obsoletes
RFC 6021.
YANG is a data modeling language used to model configuration
and state data manipulated by the Network Configuration Protocol
(NETCONF) . The YANG language supports a small set of
built-in data types and provides mechanisms to derive other types from
the built-in types.
This document introduces a collection of common data types derived
from the built-in YANG data types. The derived types are designed to
be applicable for modeling all areas of management information. The
definitions are organized in several YANG modules. The
"ietf‑yang‑types" module contains generally useful data types. The
"ietf‑inet‑types" module contains definitions that are relevant for
the Internet protocol suite.
This version of the document adds new type definitions to the YANG
modules and obsoletes . For the further details, see the
revision statement of the YANG modules.
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 .
This section provides a short overview of the types defined in
subsequent sections and their equivalent Structure of Management
Information Version 2 (SMIv2) data types. A YANG
data type is equivalent to an SMIv2 data type if the data types have
the same set of values and the semantics of the values are equivalent.
lists the types defined in the ietf-yang-types YANG module and
the corresponding SMIv2 types (- indicates there is no corresponding
SMIv2 type).
YANG typeEquivalent SMIv2 type (module)counter32Counter32 (SNMPv2-SMI)zero-based-counter32ZeroBasedCounter32 (RMON2-MIB)counter64Counter64 (SNMPv2-SMI)zero-based-counter64ZeroBasedCounter64 (HCNUM-TC)gauge32Gauge32 (SNMPv2-SMI)gauge64CounterBasedGauge64 (HCNUM-TC)object-identifier-object-identifier-128OBJECT IDENTIFIERyang-identifier-date-and-time-timeticksTimeTicks (SNMPv2-SMI)timestampTimeStamp (SNMPv2-TC)phys-addressPhysAddress (SNMPv2-TC)mac-addressMacAddress (SNMPv2-TC)xpath1.0-hex-string-uuid-dotted-quad- lists the types defined in the ietf-inet-types YANG module and the
corresponding SMIv2 types (if any).
YANG typeEquivalent SMIv2 type (module)ip-versionInetVersion (INET-ADDRESS-MIB)dscpDscp (DIFFSERV-DSCP-TC)ipv6-flow-labelIPv6FlowLabel (IPV6-FLOW-LABEL-MIB)port-numberInetPortNumber (INET-ADDRESS-MIB)as-numberInetAutonomousSystemNumber (INET-ADDRESS-MIB)ip-address- ipv4-address- ipv6-address- ip-address-no-zone- ipv4-address-no-zone- ipv6-address-no-zone- ip-prefix- ipv4-prefix- ipv6-prefix- domain-name- host- uriUri (URI-TC-MIB)
The ietf-yang-types YANG module references
,
,
,
,
,
,
,
,
,
, and
.
<CODE BEGINS> file "ietf-yang-types@2013-03-25.yang"<CODE ENDS>
The ietf-inet-types YANG module references
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
, and
.
<CODE BEGINS> file "ietf-inet-types@2013-03-25.yang"<CODE ENDS>
This document registers two URIs in the IETF XML registry
. Following the format in RFC 3688, the following
registrations have been made.
This document registers two YANG modules in the YANG Module Names
registry .
This document defines common data types using the YANG data modeling
language. The definitions themselves have no security impact on the
Internet but the usage of these definitions in concrete YANG modules
might have. The security considerations spelled out in the YANG
specification apply for this document as well.
The following people contributed significantly to the initial
version of this document:
The editor wishes to thank the following individuals for providing
helpful comments on various versions of this document: Andy Bierman,
Martin Bjorklund, Ladislav Lhotka, Lars-Johan Liman, and Dan
Romascanu.
Juergen Schoenwaelder was partly funded by Flamingo, a Network of
Excellence project (ICT-318488) supported by the European Commission
under its Seventh Framework Programme.
YANG - A Data Modeling Language for the Network Configuration
Protocol (NETCONF)Tail-f SystemsKey words for use in RFCs to Indicate Requirement LevelsHarvard UniversityIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.The IETF XML RegistryThis document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas. Date and Time on the Internet: TimestampsClearswift Corporation1310 WatersideArlington Business ParkThealeReadingRG7 4SAUK+44 11 8903 8903+44 11 8903 9000GK@ACM.ORGSun Microsystems1050 Lakes Drive, Suite 250West CovinaCA91790USAchris.newman@sun.com
This document defines a date and time format for use in Internet
protocols that is a profile of the ISO 8601 standard for
representation of dates and times using the Gregorian calendar.
XML Path Language (XPath) Version 1.0Uniform Resource Identifier (URI): Generic SyntaxWorld Wide Web ConsortiumMassachusetts Institute of Technology77 Massachusetts AvenueCambridgeMA02139USA+1-617-253-5702+1-617-258-5999timbl@w3.orghttp://www.w3.org/People/Berners-Lee/Day Software5251 California Ave., Suite 110IrvineCA92617USA+1-949-679-2960+1-949-679-2972fielding@gbiv.comhttp://roy.gbiv.com/Adobe Systems Incorporated345 Park AveSan JoseCA95110USA+1-408-536-3024LMM@acm.orghttp://larry.masinter.net/
Applications
uniform resource identifierURIURLURNWWWresource
A Uniform Resource Identifier (URI) is a compact sequence of characters
that identifies an abstract or physical resource. This specification
defines the generic URI syntax and a process for resolving URI references
that might be in relative form, along with guidelines and security
considerations for the use of URIs on the Internet.
The URI syntax defines a grammar that is a superset of all valid URIs,
allowing an implementation to parse the common components of a URI
reference without knowing the scheme-specific requirements of every
possible identifier. This specification does not define a generative
grammar for URIs; that task is performed by the individual
specifications of each URI scheme.
Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)Punycode is a simple and efficient transfer encoding syntax designed for use with Internationalized Domain Names in Applications (IDNA). It uniquely and reversibly transforms a Unicode string into an ASCII string. ASCII characters in the Unicode string are represented literally, and non-ASCII characters are represented by ASCII characters that are allowed in host name labels (letters, digits, and hyphens). This document defines a general algorithm called Bootstring that allows a string of basic code points to uniquely represent any string of code points drawn from a larger set. Punycode is an instance of Bootstring that uses particular parameter values specified by this document, appropriate for IDNA. [STANDARDS TRACK]A Universally Unique IDentifier (UUID) URN NamespaceIP Version 6 Addressing ArchitectureThis specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses.</t><t> This document obsoletes RFC 3513, "IP Version 6 Addressing Architecture". [STANDARDS TRACK]IPv6 Scoped Address ArchitectureThis document specifies the architectural characteristics, expected behavior, textual representation, and usage of IPv6 addresses of different scopes. According to a decision in the IPv6 working group, this document intentionally avoids the syntax and usage of unicast site-local addresses. [STANDARDS TRACK]NETCONF Configuration Protocol (NETCONF)Common YANG Data TypesJacobs UniversityStructure of Management Information Version 2 (SMIv2)Cisco Systems, Inc.170 West Tasman DriveSan JoseCA95134-1706US+1 408 526 5260kzm@cisco.comSNMPinfo3763 Benton StreetSanta ClaraCA95051US+1 408 221 8702dperkins@snmpinfo.comTU BraunschweigBueltenweg 74/7538106 BraunschweigDE+49 531 3913283schoenw@ibr.cs.tu-bs.deTextual Conventions for SMIv2Cisco Systems, Inc.170 West Tasman DriveSan JoseCA95134-1706US+1 408 526 5260kzm@cisco.comSNMPinfo3763 Benton StreetSanta ClaraCA95051US+1 408 221 8702dperkins@snmpinfo.comTU BraunschweigBueltenweg 74/7538106 BraunschweigDE+49 531 3913283schoenw@ibr.cs.tu-bs.deTextual Conventions for Additional High Capacity Data TypesThis memo specifies new textual conventions for additional high capacity data types, intended for SNMP implementations which already support the Counter64 data type. [STANDARDS TRACK]Remote Network Monitoring Management Information Base Version 2International Network Services+1 415 254 4251waldbusser@ins.comThis document defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing remote network monitoring devices.This document obsoletes RFC 2021, updates RFC 3273, and contains a new version of the RMON2-MIB module.User Datagram ProtocolUniversity of Southern California (USC)/Information Sciences Institute4676 Admiralty WayMarina del ReyCA90291US+1 213 822 1511Internet ProtocolUniversity of Southern California (USC)/Information Sciences Institute4676 Admiralty WayMarina del ReyCA90291USTransmission Control ProtocolUniversity of Southern California (USC)/Information Sciences Institute4676 Admiralty WayMarina del ReyCA90291USDomain names - concepts and facilitiesInformation Sciences Institute (ISI)Requirements for Internet Hosts - Application and SupportUniversity of Southern California (USC), Information Sciences Institute4676 Admiralty WayMarina del ReyCA90292-6695US+1 213 822 1511Braden@ISI.EDUInternationalizing Domain Names in Applications (IDNA): ProtocolGuidelines for creation, selection, and registration of an Autonomous System (AS)BBN Planet Corporation150 CambridgePark DriveCambridgeMA02139US+1 617 873 3180jhawk@bbnplanet.comMCI2100 Reston ParkwayRestonVA22094US+1 703 715 7521Tony.Bates@mci.netThis memo discusses when it is appropriate to register and utilize an Autonomous System (AS), and lists criteria for such. ASes are the unit of routing policy in the modern world of exterior routing, and are specifically applicable to protocols like EGP (Exterior Gateway Protocol, now at historical status; see, BGP (Border Gateway Protocol, the current de facto standard for inter-AS routing; see, and IDRP (The OSI Inter-Domain Routing Protocol, which the Internet is expected to adopt when BGP becomes obsolete; see. It should be noted that the IDRP equivalent of an AS is the RDI, or Routing Domain Identifier.Internet Protocol, Version 6 (IPv6) SpecificationCisco Systems, Inc.170 West Tasman DriveSan JoseCA95134-1706USA+1 408 527 8213+1 408 527 8254deering@cisco.comNokia232 Java DriveSunnyvaleCA94089USA+1 408 990 2004+1 408 743 5677hinden@iprg.nokia.com
Internet
internet protocol version 6IPv6
This document specifies version 6 of the Internet Protocol (IPv6),
also sometimes referred to as IP Next Generation or IPng.
Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 HeadersCisco Systems170 West Tasman DriveSan JoseCA95134-1706USA+1 408 525 4857kmn@cisco.comTorrent Networking Technologies3000 Aerial CenterMorrisvilleNC27560USA+1 919 468 8466 x232slblake@torrentnet.comCisco Systems519 Lado Drive Santa BarbaraCA93111USA+1 408 526 4257fred@cisco.comEMC Corporation35 Parkwood DriveHopkintonMA01748USA+1 508 435 1000 x76140black_david@emc.com
Internet
internet protocol version 4IPv6IPv4internet protocol version 6type of service
Differentiated services enhancements to the Internet protocol are
intended to enable scalable service discrimination in the Internet
without the need for per-flow state and signaling at every hop. A
variety of services may be built from a small, well-defined set of
building blocks which are deployed in network nodes. The services
may be either end-to-end or intra-domain; they include both those
that can satisfy quantitative performance requirements (e.g., peak
bandwidth) and those based on relative performance (e.g., "class"
differentiation). Services can be constructed by a combination of:
- setting bits in an IP header field at network boundaries
(autonomous system boundaries, internal administrative boundaries,
or hosts),
- using those bits to determine how packets are forwarded by the
nodes inside the network, and
- conditioning the marked packets at network boundaries in accordance
with the requirements or rules of each service.
The requirements or rules of each service must be set through
administrative policy mechanisms which are outside the scope of this
document. A differentiated services-compliant network node includes
a classifier that selects packets based on the value of the DS field,
along with buffer management and packet scheduling mechanisms capable
of delivering the specific packet forwarding treatment indicated by
the DS field value. Setting of the DS field and conditioning of the
temporal behavior of marked packets need only be performed at network
boundaries and may vary in complexity.
This document defines the IP header field, called the DS (for
differentiated services) field. In IPv4, it defines the layout of
the TOS octet; in IPv6, the Traffic Class octet. In addition, a base
set of packet forwarding treatments, or per-hop behaviors, is
defined.
For a more complete understanding of differentiated services, see
also the differentiated services architecture .
IANA Allocation Guidelines For Values In the Internet Protocol and Related HeadersHarvard UniversityCambridgeMA02138US+1 617 495 3864sob@harvard.eduACIRI / ICSI1947 Center StreetSuite 600BerkeleyCA94704-1198US+1 510 666 2882vern@aciri.orgThis memo provides guidance for the IANA to use in assigning parameters for fields in the IPv4, IPv6, ICMP, UDP and TCP protocol headers.Stream Control Transmission ProtocolManagement Information Base for the Differentiated Services ArchitectureThis memo describes an SMIv2 (Structure of Management Information version 2) MIB for a device implementing the Differentiated Services Architecture. It may be used both for monitoring and configuration of a router or switch capable of Differentiated Services functionality. [STANDARDS TRACK]Report from the Joint W3C/IETF URI Planning Interest Group: Uniform Resource Identifiers (URIs), URLs, and Uniform Resource Names (URNs): Clarifications and RecommendationsTextual Conventions for IPv6 Flow LabelThis MIB module defines textual conventions to represent the commonly used IPv6 Flow Label. The intent is that these textual conventions (TCs) will be imported and used in MIB modules that would otherwise define their own representations. [STANDARDS TRACK]Textual Conventions for Internet Network AddressesThis MIB module defines textual conventions to represent commonly used Internet network layer addressing information. The intent is that these textual conventions will be imported and used in MIB modules that would otherwise define their own representations. [STANDARDS TRACK]A Border Gateway Protocol 4 (BGP-4)This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol.</t><t> The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced.</t><t> BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths.</t><t> This document obsoletes RFC 1771. [STANDARDS TRACK]BGP Support for Four-Octet Autonomous System (AS) Number SpaceThe Autonomous System number is encoded as a two-octet entity in the base BGP specification. This document describes extensions to BGP to carry the Autonomous System numbers as four-octet entities. This document obsoletes RFC 4893 and updates RFC 4271. [STANDARDS-TRACK]Datagram Congestion Control Protocol (DCCP)The Datagram Congestion Control Protocol (DCCP) is a transport protocol that provides bidirectional unicast connections of congestion-controlled unreliable datagrams. DCCP is suitable for applications that transfer fairly large amounts of data and that can benefit from control over the tradeoff between timeliness and reliability. [STANDARDS TRACK]MIB Textual Conventions for Uniform Resource Identifiers (URIs)This MIB module defines textual conventions to represent STD 66 Uniform Resource Identifiers (URIs). The intent is that these textual conventions will be imported and used in MIB modules that would otherwise define their own representation(s). [STANDARDS TRACK]DoD Internet host table specificationSRI InternationalSRI InternationalSRI InternationalIEEE Standard for Local and Metropolitan Area Networks: Overview and ArchitectureIEEEA Recommendation for IPv6 Address Text RepresentationNEC BIGLOBE, Ltd.NEC AccessTechnica, Ltd.A DNS RR for specifying the location of services (DNS SRV)Troll TechWaldemar Thranes gate 98BOsloN-0175NO+47 22 806390+47 22 806380arnt@troll.noInternet Software Consortium950 Charter StreetRedwood CityCA94063US+1 650 779 7001Microsoft CorporationOne Microsoft WayRedmondWA98052USlevone@microsoft.comThis document describes a DNS RR which specifies the location of the
server(s) for a specific protocol and domain.XML Schema Part 2: Datatypes Second Edition
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
ISO/IEC
This version adds new type definitions to the YANG modules. The
following new data types have been added to the ietf-yang-types
module:
yang-identifier
hex-string
uuid
dotted-quad
The following new data types have been added to the ietf-inet-types
module:
ip-address-no-zone
ipv4-address-no-zone
ipv6-address-no-zone