<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0">
    <channel>
        <title>Recent RFCs</title>
        <link>https://www.rfc-editor.org</link>
        <description>Recently published RFCs</description>
        <lastBuildDate>Wed, 20 May 2026 20:04:40 GMT</lastBuildDate>
        <docs>https://validator.w3.org/feed/docs/rss2.html</docs>
        <generator>https://www.npmjs.com/package/feed</generator>
        <language>en-us</language>
        <item>
            <title><![CDATA[RFC 9991: Domain-Based Message Authentication, Reporting, and Conformance (DMARC) Failure Reporting]]></title>
            <link>https://www.rfc-editor.org/info/rfc9991/</link>
            <guid isPermaLink="true">https://www.rfc-editor.org/info/rfc9991/</guid>
            <pubDate>Tue, 19 May 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a mechanism by which a Domain Owner can request feedback about email messages using their domain in the From: address field. This document describes "failure reports", or "failed message reports", which provide details about individual messages that failed to authenticate according to the DMARC mechanism.

 This document updates RFC 6591 and obsoletes RFC 7489.]]></description>
        </item>
        <item>
            <title><![CDATA[RFC 9990: Domain-Based Message Authentication, Reporting, and Conformance (DMARC) Aggregate Reporting]]></title>
            <link>https://www.rfc-editor.org/info/rfc9990/</link>
            <guid isPermaLink="true">https://www.rfc-editor.org/info/rfc9990/</guid>
            <pubDate>Tue, 19 May 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[Domain-based Message Authentication, Reporting, and Conformance (DMARC) allows for Domain Owners to request aggregate reports from receivers. This report is an XML document and contains extensible elements that allow for other types of data to be specified later. The aggregate reports can be submitted by the receiver to the Domain Owner's specified destination as declared in the associated DNS record.

 This document obsoletes RFC 7489.]]></description>
        </item>
        <item>
            <title><![CDATA[RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC)]]></title>
            <link>https://www.rfc-editor.org/info/rfc9989/</link>
            <guid isPermaLink="true">https://www.rfc-editor.org/info/rfc9989/</guid>
            <pubDate>Tue, 19 May 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[This document describes the Domain-based Message Authentication, Reporting, and Conformance (DMARC) protocol.

 DMARC permits the owner of an email's Author Domain to enable validation of the domain's use to indicate the Domain Owner's or Public Suffix Operator's message handling preference regarding failed validation and to request reports about the use of the domain name. Mail-receiving organizations can use this information when evaluating handling choices for incoming mail.

 This document obsoletes RFCs 7489 and 9091.]]></description>
        </item>
        <item>
            <title><![CDATA[RFC 9983: OSPFv2 Anycast Property Advertisement]]></title>
            <link>https://www.rfc-editor.org/info/rfc9983/</link>
            <guid isPermaLink="true">https://www.rfc-editor.org/info/rfc9983/</guid>
            <pubDate>Tue, 19 May 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[An IP prefix may be configured as anycast and, as such, the same value can be advertised by multiple routers. It is useful for other routers to know that the advertisement is for an anycast prefix.

 This document defines a new flag in the OSPFv2 Extended Prefix TLV Flags to advertise the anycast property. The document also specifies a companion YANG module for managing this function.]]></description>
        </item>
        <item>
            <title><![CDATA[RFC 9972: Advanced BGP Monitoring Protocol (BMP) Statistics Types]]></title>
            <link>https://www.rfc-editor.org/info/rfc9972/</link>
            <guid isPermaLink="true">https://www.rfc-editor.org/info/rfc9972/</guid>
            <pubDate>Tue, 19 May 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[The BGP Monitoring Protocol (BMP) described in RFC 7854 defines statistics message types to observe events that occur on a monitored router.  This document defines new statistics types to monitor BMP Adj-RIB-In and Adj-RIB-Out Routing Information Bases (RIBs).]]></description>
        </item>
        <item>
            <title><![CDATA[RFC 9969: Report from the IAB Workshop on AI-CONTROL]]></title>
            <link>https://www.rfc-editor.org/info/rfc9969/</link>
            <guid isPermaLink="true">https://www.rfc-editor.org/info/rfc9969/</guid>
            <pubDate>Tue, 19 May 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[The AI-CONTROL Workshop was convened by the Internet Architecture Board (IAB) in September 2024. This report summarizes its significant points of discussion and identifies topics that may warrant further consideration and work.

 Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.]]></description>
        </item>
        <item>
            <title><![CDATA[RFC 9965: The eap.arpa. Domain and Extensible Authentication Protocol (EAP) Provisioning]]></title>
            <link>https://www.rfc-editor.org/info/rfc9965/</link>
            <guid isPermaLink="true">https://www.rfc-editor.org/info/rfc9965/</guid>
            <pubDate>Tue, 19 May 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[This document defines the eap.arpa. domain for use only in Network Access Identifiers (NAIs) as a way for Extensible Authentication Protocol (EAP) peers to signal to EAP servers that they wish to obtain limited, and unauthenticated, network access. EAP peers signal which kind of access is required via certain predefined identifiers that use the NAI format of RFC 7542. A table of identifiers and meanings is defined, which includes entries for RFC 9140.

 This document updates RFCs 5216 and 9190 to define an unauthenticated provisioning method. Those specifications suggest that such a method is possible, but they do not define how it would be done. This document also updates RFC 9140 to deprecate "eap-noob.arpa" and replace it with "@noob.eap.arpa".]]></description>
        </item>
        <item>
            <title><![CDATA[RFC 9964: ML-DSA for JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE)]]></title>
            <link>https://www.rfc-editor.org/info/rfc9964/</link>
            <guid isPermaLink="true">https://www.rfc-editor.org/info/rfc9964/</guid>
            <pubDate>Tue, 19 May 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[This document specifies JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) serializations for the Module-Lattice-Based Digital Signature Standard (ML-DSA), a Post-Quantum Cryptography (PQC) digital signature scheme defined in US NIST FIPS 204.]]></description>
        </item>
        <item>
            <title><![CDATA[RFC 9967: System for Cross-Domain Identity Management (SCIM) Profile for Security Event Tokens (SETs)]]></title>
            <link>https://www.rfc-editor.org/info/rfc9967/</link>
            <guid isPermaLink="true">https://www.rfc-editor.org/info/rfc9967/</guid>
            <pubDate>Thu, 14 May 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[This specification defines a set of System for Cross-domain Identity Management (SCIM) Security Events using the Security Event Token (SET) specification (RFC 8417) to enable the asynchronous exchange of messages between SCIM service providers and receivers.

 This specification updates RFC 7643 by defining additional attributes for the "urn:ietf:params:scim:schemas:core:2.0:ServiceProviderConfig" schema, and it updates RFC 7644 with an optional new asynchronous SCIM request capability.]]></description>
        </item>
        <item>
            <title><![CDATA[RFC 9962: A Decentralized Locator/ID Separation Protocol Mapping System (LISP-Decent)]]></title>
            <link>https://www.rfc-editor.org/info/rfc9962/</link>
            <guid isPermaLink="true">https://www.rfc-editor.org/info/rfc9962/</guid>
            <pubDate>Wed, 13 May 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[This document describes how the Locator/ID Separation Protocol (LISP)
Mapping System can be distributed for scale and decentralized for
management, while maintaining trust among data plane nodes.  This is
an Informational RFC and should be used by LISP-Decent
implementations to interoperate with each other.]]></description>
        </item>
        <item>
            <title><![CDATA[RFC 9944: Device Schema Extensions to the System for Cross-Domain Identity Management (SCIM) Model]]></title>
            <link>https://www.rfc-editor.org/info/rfc9944/</link>
            <guid isPermaLink="true">https://www.rfc-editor.org/info/rfc9944/</guid>
            <pubDate>Wed, 13 May 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[The initial core schema for the System for Cross-domain Identity Management (SCIM) was designed for provisioning users.  This memo specifies schema extensions that enable provisioning of devices using various underlying bootstrapping systems such as Wi-Fi Easy Connect, FIDO device onboarding vouchers, Bluetooth Low Energy (BLE) passcodes, and MAC Authenticated Bypass (MAB).]]></description>
        </item>
        <item>
            <title><![CDATA[RFC 9968: Report from the IAB Workshop on the Next Era of Network Management Operations (NEMOPS)]]></title>
            <link>https://www.rfc-editor.org/info/rfc9968/</link>
            <guid isPermaLink="true">https://www.rfc-editor.org/info/rfc9968/</guid>
            <pubDate>Mon, 11 May 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[The "Next Era of Network Management Operations (NEMOPS)" workshop was convened by the Internet Architecture Board (IAB) from December 3-5, 2024 as a three-day online meeting. It builds on a previous 2002 workshop, the outcome of which was documented in RFC 3535, identifying 14 operator requirements for consideration in future network management protocol design and related data models, along with some recommendations for the IETF. Much has changed in the Internet's operation and technological foundations since then. The NEMOPS workshop reviewed the past outcomes and discussed any operational barriers that prevented these technologies from being widely implemented. With the industry, network operators and protocol engineers working in collaboration, the workshop developed a suggested plan of action and network management recommendations for the IETF and IRTF. Building on RFC 3535, this document provides the report of the follow-up IAB workshop on network management.

 Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.]]></description>
        </item>
        <item>
            <title><![CDATA[RFC 9959: Careful Resume: Convergence of Congestion Control from Retained State]]></title>
            <link>https://www.rfc-editor.org/info/rfc9959/</link>
            <guid isPermaLink="true">https://www.rfc-editor.org/info/rfc9959/</guid>
            <pubDate>Mon, 11 May 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[This document specifies a cautious method for Internet transports that enables fast startup of Congestion Control (CC) for a wide range of connections, known as "Careful Resume". It reuses a set of computed CC parameters that are based on previously observed path characteristics between the same pair of transport endpoints. These parameters are saved, allowing them to be later used to modify the CC behaviour of a subsequent connection.

 This document describes the assumptions and defines the requirements for how a sender utilises these parameters to provide opportunities for a connection to more rapidly get up to speed and utilise available capacity. It discusses how the use of this method impacts the capacity at a shared network bottleneck and the safe response that is needed after any indication that the new rate is inappropriate.]]></description>
        </item>
        <item>
            <title><![CDATA[RFC 9957: The DOCSIS Queue Protection Algorithm to Preserve Low Latency]]></title>
            <link>https://www.rfc-editor.org/info/rfc9957/</link>
            <guid isPermaLink="true">https://www.rfc-editor.org/info/rfc9957/</guid>
            <pubDate>Mon, 11 May 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[This Informational RFC explains the specification of the queue protection algorithm introduced into Data-Over-Cable Service Interface Specification (DOCSIS) technology at version 3.1.  A shared low-latency queue relies on the non-queue-building behaviour of every traffic flow using it.  However, some flows might not take such care, either accidentally or maliciously.  If a queue is about to exceed a threshold level of delay, the Queue Protection algorithm can rapidly detect the flows most likely to be responsible.  It can then prevent harm to other traffic in the low-latency queue by ejecting selected packets (or all packets) of these flows.  This document is designed for four audiences: a) congestion control designers who need to understand how to keep on the "good" side of the algorithm; b) implementers of the algorithm who want to understand it in more depth; c) designers of algorithms with similar goals, perhaps for non-DOCSIS scenarios; and d) researchers interested in evaluating the algorithm.]]></description>
        </item>
        <item>
            <title><![CDATA[RFC 9956: A Non-Queue-Building Per-Hop Behavior (NQB PHB) for Differentiated Services]]></title>
            <link>https://www.rfc-editor.org/info/rfc9956/</link>
            <guid isPermaLink="true">https://www.rfc-editor.org/info/rfc9956/</guid>
            <pubDate>Mon, 11 May 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[This document specifies characteristics of a Non-Queue-Building Per-Hop Behavior (NQB PHB).  The NQB PHB provides a shallow-buffered, best-effort service as a complement to a Default deep-buffered, best-effort service for Internet services.  The purpose of this NQB PHB is to provide a separate queue that enables smooth (i.e., non-bursty), low-data-rate, application-limited traffic microflows, to avoid the delay, delay variation and loss that would ordinarily be caused by sharing a queue with bursty, capacity-seeking traffic.  This PHB is implemented without prioritization and can be implemented without rate policing, making it suitable for environments where the use of these features is restricted.  The NQB PHB has been developed primarily for use by access network segments, where queuing delay and queuing loss caused by Queue-Building (QB) protocols are manifested; however, its use is not limited to such segments.  In particular, the application of NQB PHB to cable broadband links, Wi-Fi links, and mobile network radio/core segments are discussed in this document.  This document recommends a specific Differentiated Services Code Point (DSCP) to identify NQB microflows and updates the guidance in RFC 8325 on mapping Differentiated Services (Diffserv or DS) to IEEE 802.11 for this codepoint.]]></description>
        </item>
    </channel>
</rss>