https://www.rfc-editor.org/ Recently published RFCs en-us Sun, 15 Mar 2026 20:30:12 -0700 https://www.rfc-editor.org/info/rfc9907 This document provides guidelines for authors and reviewers of specifications containing YANG data models, including IANA-maintained YANG modules. Recommendations and procedures are defined, which are intended to increase interoperability and usability of Network Configuration Protocol (NETCONF) and RESTCONF protocol implementations that utilize YANG modules. This document obsoletes RFC 8407; it also updates RFC 8126 by providing additional guidelines for writing the IANA considerations for RFCs that specify IANA-maintained YANG modules. https://www.rfc-editor.org/info/rfc9938 This document provides a framework overview for the Deterministic Networking (DetNet) Controller Plane. It discusses concepts and requirements for the DetNet Controller Plane, which could be the basis for a future solution specification. https://www.rfc-editor.org/info/rfc9853 This document specifies a Return Routability Check (RRC) subprotocol for use in the context of the Connection ID (CID) construct for the Datagram Transport Layer Security (DTLS) protocol versions 1.2 and 1.3. Implementations offering the CID functionality described in RFCs 9146 and 9147 are encouraged to also provide the RRC functionality described in this document. For this reason, this document updates RFCs 9146 and 9147. https://www.rfc-editor.org/info/rfc9922 This document defines common types and groupings that are meant to be used for scheduling purposes, such as events, policies, services, or resources based on date and time. For the sake of better modularity, the YANG module includes a set of recurrence-related groupings with varying levels of representation (i.e., from basic to advanced) to accommodate a variety of requirements. It also defines groupings for validating requested schedules and reporting scheduling statuses. https://www.rfc-editor.org/info/rfc9935 The Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) is a quantum-resistant Key Encapsulation Mechanism. This document specifies the conventions for using the ML-KEM in X.509 Public Key Infrastructure. The conventions for the subject public keys and private keys are also specified. https://www.rfc-editor.org/info/rfc9936 Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) is a quantum-resistant Key Encapsulation Mechanism (KEM). Three parameter sets for the ML-KEM algorithm are specified by the US National Institute of Standards and Technology (NIST) in FIPS 203. In order of increasing security strength (and decreasing performance), these parameter sets are ML-KEM-512, ML-KEM-768, and ML-KEM-1024. This document specifies the conventions for using ML-KEM with the Cryptographic Message Syntax (CMS) using the KEMRecipientInfo structure defined in "Using Key Encapsulation Mechanism (KEM) Algorithms in the Cryptographic Message Syntax (CMS)" (RFC 9629). https://www.rfc-editor.org/info/rfc9931 In HTTP/1.1, the client can request a change to a new protocol on the existing connection. This document discusses the security considerations that apply to data sent by the client before this request is confirmed and adds new requirements to RFCs 9112 and 9298 to avoid related security issues. https://www.rfc-editor.org/info/rfc9934 Encrypted ClientHello (ECH) key pairs need to be configured into TLS servers, which can be built using different TLS libraries. This document specifies a standard file format for this purpose, similar to how RFC 7468 defines other Privacy-Enhanced Mail (PEM) file formats. https://www.rfc-editor.org/info/rfc9848 To use TLS Encrypted ClientHello (ECH), the client needs to learn the ECH configuration for a server before it attempts a connection to the server. This specification provides a mechanism for conveying the ECH configuration information via DNS, using a SVCB or HTTPS resource record (RR). https://www.rfc-editor.org/info/rfc9849 This document describes a mechanism in Transport Layer Security (TLS) for encrypting a message under a server public key. https://www.rfc-editor.org/info/rfc9939 This document defines PKCS #8 content types for use with PrivateKeyInfo and EncryptedPrivateKeyInfo as specified in RFC 5958. https://www.rfc-editor.org/info/rfc9930 This document defines the Tunnel Extensible Authentication Protocol (TEAP) version 1. TEAP is a tunnel-based EAP method that enables secure communication between a peer and a server by using the Transport Layer Security (TLS) protocol to establish a mutually authenticated tunnel. Within the tunnel, TLV objects are used to convey authentication-related data between the EAP peer and the EAP server. This document obsoletes RFC 7170 and updates RFC 9427 by moving all TEAP specifications from those documents to this one. https://www.rfc-editor.org/info/rfc9923 FNV (Fowler/Noll/Vo) is a fast, non-cryptographic hash algorithm with good dispersion that has been widely used and is referenced in a number of standards documents. The purpose of this document is to make information on FNV and open-source code performing all specified sizes of FNV conveniently available to the Internet community. https://www.rfc-editor.org/info/rfc9929 Summarization is often used in multi-area or multi-domain networks to improve network efficiency and scalability. With summarization in place, there is a need to signal loss of reachability to an individual prefix covered by the summary. This enables fast convergence by steering traffic, when applicable, away from the node which owns the prefix and is no longer reachable. This document specifies protocol mechanisms in IS-IS and OSPF, together with two new flags, to advertise such prefix reachability loss. The term "OSPF" in this document is used to refer to both OSPFv2 and OSPFv3. https://www.rfc-editor.org/info/rfc9945 The IETF community will treat people with kindness and grace, but not endless patience. This memo obsoletes RFCs 3683 and 3934, and it updates RFCs 2418 and 9245 by establishing a policy for the moderation of disruptive participation across the IETF's various public contribution channels and discussion fora. It establishes guardrails for moderation and a moderator team. That team will develop a set of moderation procedures and facilitate their consistent implementation with chairs and administrators.