Recent IETF RFCs2020-06-29T05:00:04ZPeter Eichmanhttp://echodin.net/feeds/rfc.atomRFC8806: Running a Root Server Local to a Resolverhttp://tools.ietf.org/html/rfc8806
(W. Kumari, P. Hoffman)
Some DNS recursive resolvers have longer-than-desired round-trip times to the closest DNS root server; those resolvers may have difficulty getting responses from the root servers, such as during a network attack. Some DNS recursive resolver operators want to prevent snooping by third parties of requests sent to DNS root servers. In both cases, resolvers can greatly decrease the round-trip time and prevent observation of requests by serving a copy of the full root zone on the same server, such as on a loopback address or in the resolver software. This document shows how to start and maintain such a copy of the root zone that does not cause problems for other users of the DNS, at the cost of adding some operational fragility for the operator. This document obsoletes RFC 7706.2020-06-01T00:00:00ZRFC8798: Additional Units for Sensor Measurement Lists (SenML)http://tools.ietf.org/html/rfc8798
(C. Bormann)
The Sensor Measurement Lists (SenML) media type supports the indication of units for a quantity represented. This short document registers a number of additional unit names in the IANA registry for units in SenML. It also defines a registry for secondary units that cannot be in SenML's main registry, as they are derived by linear transformation from units already in that registry.2020-06-01T00:00:00ZRFC8797: Remote Direct Memory Access - Connection Manager (RDMA-CM) Private Data for RPC-over-RDMA Version 1http://tools.ietf.org/html/rfc8797
(C. Lever)
This document specifies the format of Remote Direct Memory Access - Connection Manager (RDMA-CM) Private Data exchanged between RPC-over-RDMA version 1 peers as part of establishing a connection. The addition of the Private Data payload specified in this document is an optional extension that does not alter the RPC-over-RDMA version 1 protocol. This document updates RFC 8166.2020-06-01T00:00:00ZRFC8793: Information-Centric Networking (ICN): Content-Centric Networking (CCNx) and Named Data Networking (NDN) Terminologyhttp://tools.ietf.org/html/rfc8793
(B. Wissingh, C. Wood, A. Afanasyev, L. Zhang, D. Oran, C. Tschudin)
Information-Centric Networking (ICN) is a novel paradigm where network communications are accomplished by requesting named content instead of sending packets to destination addresses. Named Data Networking (NDN) and Content-Centric Networking (CCNx) are two prominent ICN architectures. This document provides an overview of the terminology and definitions that have been used in describing concepts in these two implementations of ICN. While there are other ICN architectures, they are not part of the NDN and CCNx concepts and as such are out of scope for this document. This document is a product of the Information-Centric Networking Research Group (ICNRG).2020-06-01T00:00:00ZRFC8791: YANG Data Structure Extensionshttp://tools.ietf.org/html/rfc8791
(A. Bierman, M. Björklund, K. Watsen)
This document describes YANG mechanisms for defining abstract data structures with YANG.2020-06-01T00:00:00ZRFC8789: IETF Stream Documents Require IETF Rough Consensushttp://tools.ietf.org/html/rfc8789
(J. Halpern, E. Rescorla)
This document requires that the IETF never publish any IETF Stream RFCs without IETF rough consensus. This updates RFC 2026.2020-06-01T00:00:00ZRFC8788: Eligibility for the 2020-2021 Nominating Committeehttp://tools.ietf.org/html/rfc8788
(B. Leiba)
The 2020-2021 Nominating Committee (NomCom) is to be formed between the IETF 107 and IETF 108 meetings, and the issue of eligibility of who can serve on that NomCom needs clarification. This document provides a one-time interpretation of the eligibility rules that is required for the exceptional situation of the cancellation of the in-person IETF 107 meeting. This document only affects the seating of the 2020-2021 NomCom and any rules or processes that relate to NomCom eligibility before IETF 108; it does not set a precedent to be applied in the future.2020-05-01T00:00:00ZRFC8787: Location Source Parameter for the SIP Geolocation Header Fieldhttp://tools.ietf.org/html/rfc8787
(J. Winterbottom, R. Jesske, B. Chatras, A. Hutton)
There are some circumstances where a Geolocation header field may contain more than one locationValue. Knowing the identity of the node adding the locationValue allows the recipient more freedom in selecting the value to look at first rather than relying solely on the order of the locationValues. This document defines the "loc-src" parameter so that the entity adding the locationValue to the Geolocation header field can identify itself using its hostname. This document updates RFC 6442.2020-05-01T00:00:00ZRFC8786: Updated Rules for Processing Stateful PCE Request Parameters Flagshttp://tools.ietf.org/html/rfc8786
(A. Farrel)
Extensions to the Path Computation Element Communication Protocol (PCEP) to support stateful Path Computation Elements (PCEs) are defined in RFC 8231. One of the extensions is the Stateful PCE Request Parameters (SRP) object. That object includes a Flags field that is a set of 32 bit flags, and RFC 8281 defines an IANA registry for tracking assigned flags. However, RFC 8231 does not explain how an implementation should set unassigned flags in transmitted messages, nor how an implementation should process unassigned, unknown, or unsupported flags in received messages. This document updates RFC 8231 by defining the correct behaviors.2020-05-01T00:00:00ZRFC8783: Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specificationhttp://tools.ietf.org/html/rfc8783
(M. Boucadair, T. Reddy.K)
The document specifies a Distributed Denial-of-Service Open Threat Signaling (DOTS) data channel used for bulk exchange of data that cannot easily or appropriately communicated through the DOTS signal channel under attack conditions. This is a companion document to "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification" (RFC 8782).2020-05-01T00:00:00ZRFC8782: Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specificationhttp://tools.ietf.org/html/rfc8782
(T. Reddy.K, M. Boucadair, P. Patil, A. Mortensen, N. Teague)
This document specifies the Distributed Denial-of-Service Open Threat Signaling (DOTS) signal channel, a protocol for signaling the need for protection against Distributed Denial-of-Service (DDoS) attacks to a server capable of enabling network traffic mitigation on behalf of the requesting client. A companion document defines the DOTS data channel, a separate reliable communication layer for DOTS management and configuration purposes.2020-05-01T00:00:00ZRFC8781: Discovering PREF64 in Router Advertisementshttp://tools.ietf.org/html/rfc8781
(L. Colitti, J. Linkova)
This document specifies a Neighbor Discovery option to be used in Router Advertisements (RAs) to communicate prefixes of Network Address and Protocol Translation from IPv6 clients to IPv4 servers (NAT64) to hosts.2020-04-01T00:00:00Z