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.
YANG is a data modeling language used to model configuration
and state data manipulated by the NETCONF protocol. 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 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.
The derived types are generally designed to be applicable for modeling
all areas of management information.
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 over the types defined in
subsequent sections and their equivalent SMIv2 data types. list
the types defined in the ietf-yang-types YANG module and the
corresponding SMIv2 types (if any).
ietf-yang-types 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 IDENTIFIERdate-and-time-timeticksTimeTicks (SNMPv2-SMI)timestampTimeStamp (SNMPv2-TC)phys-addressPhysAddress (SNMPv2-TC)mac-addressMacAddress (SNMPv2-TC)xpath1.0- list the types defined in the ietf-inet-types YANG module and the
corresponding SMIv2 types (if any).
ietf-inet-types YANG typeEquivalent SMIv2 type (module)ip-version- 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-prefix- ipv4-prefix- ipv6-prefix- domain-name- host- uriUri (URI-TC-MIB)<CODE BEGINS> file "ietf-yang-types.yang"<CODE ENDS><CODE BEGINS> file "ietf-inet-types.yang"<CODE ENDS>
This document registers two URIs in the IETF XML registry
. Following the format in RFC 3688, the following
registration is requested.
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 draft:
The editor wishes to thank the following individuals for providing
helpful comments on various versions of this document: Ladislav
Lhotka, Lars-Johan Liman, Dan Romascanu.
YANG - A data modeling language for NETCONFTail-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. NETCONF Configuration ProtocolThe Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized on top of a simple Remote Procedure Call (RPC) layer. [STANDARDS TRACK]Structure 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.deDate 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.
Textual 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 2 using SMIv2International Network Services+1 415 254 4251waldbusser@ins.comThis memo 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.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)Until now, there has been no standard method for domain names to use ch
aracters outside the ASCII repertoire. This document defines internationalized
domain names (IDNs) and a mechanism called Internationalizing Domain Names in Ap
plications (IDNA) for handling them in a standard fashion. IDNs use characters
drawn from a large repertoire (Unicode), but IDNA allows the non-ASCII character
s to be represented using only the ASCII characters already allowed in so-called
host names today. This backward-compatible representation is required in exist
ing protocols like DNS, so that IDNs can be introduced with no changes to the ex
isting infrastructure. IDNA is only meant for processing domain names, not free
text. [STANDARDS TRACK]Guidelines 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 ProtocolThis document describes the Stream Control Transmission Protocol (SCTP). [STANDARDS TRACK]Management 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]Uniform 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.
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]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]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 AS Number SpaceCurrently the Autonomous System (AS) number is encoded as a two-octet entity in BGP. This document describes extensions to BGP to carry the Autonomous System number as a four-octet entity. [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]Guidelines for Writing an IANA Considerations Section in RFCsMany protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication transform for IPsec). To ensure that such quantities have consistent values and interpretations across all implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IANA).</t><t> In order for IANA to manage a given namespace prudently, it needs guidelines describing the conditions under which new values can be assigned or when modifications to existing values can be made. If IANA is expected to play a role in the management of a namespace, IANA must be given clear and concise instructions describing that role. This document discusses issues that should be considered in formulating a policy for assigning values to a namespace and provides guidelines for authors on the specific text that must be included in documents that place demands on IANA.</t><t> This document obsoletes RFC 2434. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.IP 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]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.