Internet Drafts - IDs for Apr/2025

Index - Month Index of IDs

All IDs - sorted by date)

30/04/2025

	ESP Echo Protocol
	draft-ietf-ipsecme-esp-ping-00.txt   Date: 30/04/2025   Authors: Lorenzo Colitti, Jen Linkova, Michael Richardson   Working Group: IP Security Maintenance and Extensions (ipsecme)	This document defines an ESP echo function which can be used to detect whether a given network path supports ESP packets.
	Layer-3 Discovery and Liveness
	draft-ietf-lsvr-l3dl-15.txt   Date: 30/04/2025   Authors: Randy Bush, Rob Austein, Russ Housley, Keyur Patel   Working Group: Link State Vector Routing (lsvr)	In Massive Data Centers, BGP-SPF and similar routing protocols are used to build topology and reachability databases. These protocols need to discover IP Layer-3 attributes of links, such as neighbor IP addressing, logical link IP encapsulation abilities, and link liveness. This Layer-3 Discovery and Liveness protocol collects these data, which may then be disseminated using BGP-SPF and similar protocols.
	Using Attestation in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)
	draft-fossati-tls-attestation-09.txt   Date: 30/04/2025   Authors: Hannes Tschofenig, Yaron Sheffer, Paul Howard, Ionut Mihalcea, Yogesh Deshpande, Arto Niemi, Thomas Fossati   Working Group: Individual Submissions (none)	The TLS handshake protocol allows authentication of one or both peers using static, long-term credentials. In some cases, it is also desirable to ensure that the peer runtime environment is in a secure state. Such an assurance can be achieved using attestation which is a process by which an entity produces evidence about itself that another party can use to appraise whether that entity is found in a secure state. This document describes a series of protocol extensions to the TLS 1.3 handshake that enables the binding of the TLS authentication key to a remote attestation session. This enables an entity capable of producing attestation evidence, such as a confidential workload running in a Trusted Execution Environment (TEE), or an IoT device that is trying to authenticate itself to a network access point, to present a more comprehensive set of security metrics to its peer. These extensions have been designed to allow the peers to use any attestation technology, in any remote attestation topology, and mutually.
	Resource Guarantee for SRv6 Policies
	draft-cheng-spring-srv6-policy-resource-gurantee-05.txt   Date: 30/04/2025   Authors: Weiqiang Cheng, Jiang Wenying, Ran Chen, Changwang Lin, Geng Zhang   Working Group: Individual Submissions (none)	This document defines a new SRv6 Endpoint behavior which can be used to associate with a set of network resource partition (e.g. bandwidth, buffer and queue resources ) Programming, called End.NRP. By using the End.NRP SID to build its segment list, the SRv6 policy has the capability to program network resources and achieve strict SLA guarantees.
	AI Content Disclosure Header
	draft-abaris-aicdh-00.txt   Date: 30/04/2025   Authors: Dogu Abaris   Working Group: Individual Submissions (none)	This document proposes a machine-readable Hypertext Transfer Protocol (HTTP) response header field, AI-Disclosure, to disclose the presence and degree of Artificial Intelligence (AI) generated or AI-assisted content in web responses. The header is designed for compatibility with HTTP structured field syntax and provides metadata for user agents, bots, and archiving systems. It supports layered disclosure strategies alongside human-readable and structured metadata formats.
	SRv6 for Inter-Layer Network Programming
	draft-ietf-spring-srv6-inter-layer-programming-00.txt   Date: 30/04/2025   Authors: Liuyan Han, Jie Dong, Minxue Wang, Ran Chen, Zongpeng Du   Working Group: Source Packet Routing in Networking (spring)	The Segment Routing over IPv6 (SRv6) Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header. Following the SRv6 Network Programming concept, this document defines SRv6 based mechanisms for inter-layer network programming, which can help to integrate the packet network layer with its underlying layers efficiently. For inter-layer path programming, a new SRv6 behavior is defined for steering packets to underlay network connections. The applicability of this new SRv6 behavior in typical scenarios is illustrated.

29/04/2025

	Use cases,Network Scenarios and gap analysis for Packet Optical Integration (POI) with programmable pluggables under ACTN Framework
	draft-ietf-ccamp-actn-poi-pluggable-usecases-gaps-01.txt   Date: 29/04/2025   Authors: Oscar de Dios, Jean-Francois Bouquier, Julien Meuric, Gyan Mishra, Gabriele Galimberti   Working Group: Common Control and Measurement Plane (ccamp)	This document provides general overarching guidelines for control and management of packet over optical converged networks with programmable pluggables and focuses on operators' use cases and network scenarios. It provides a set of use cases which are needed for the control and management of the packet over optical networks which comprise devices with mixes of packet and optical functions where the optical functions may be provided on programmable pluggables. The document provides a gap analysis to solve the use cases.
	A JSON Encoding for HTTP Field Values
	draft-reschke-http-jfv-17.txt   Date: 29/04/2025   Authors: Julian Reschke   Working Group: Individual Submissions (none)	This document establishes a convention for use of JSON-encoded field values in new HTTP fields.
	Path Computation Element Communication Protocol (PCEP) extension to advertise the PCE Controlled Identifier Space
	draft-ietf-pce-controlled-id-space-02.txt   Date: 29/04/2025   Authors: Cheng Li, Hang Shi, Aijun Wang, Weiqiang Cheng, Chao Zhou   Working Group: Path Computation Element (pce)	The Path Computation Element Communication Protocol (PCEP) provides a mechanism for the Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. The Stateful PCE extensions allow stateful control of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) using PCEP. Furthermore, PCE can be used for computing paths in the SR networks. Stateful PCE provides active control of MPLS-TE LSPs via PCEP, for a model where the PCC delegates control over one or more locally configured LSPs to the PCE. Further, stateful PCE could also create and remove PCE-initiated LSPs by itself. A PCE-based Central Controller (PCECC) simplify the processing of a distributed control plane by integrating with elements of Software-Defined Networking (SDN). In some use cases, such as PCECC provisioning or Binding Segment Identifier (SID) for Segment Routing (SR) allocation, there are requirements for a stateful PCE to make allocation of labels, SIDs, etc. These use cases require PCE to be aware of various identifier spaces from where to make allocations on behalf of a PCC. This document defines a generic mechanism by which a PCC can inform the PCE of the identifier space set aside for the PCE control via PCEP. The identifier could be an MPLS label, a SID, or any other identifier that can be allocated and managed by the PCE.
	Extensible Provisioning Protocol (EPP) Transport over HTTPS
	draft-ietf-regext-epp-https-01.txt   Date: 29/04/2025   Authors: Mario Loffredo, Lorenzo Trombacchi, Maurizio Martinelli, Dan Keathley, James Gould   Working Group: Registration Protocols Extensions (regext)	This document describes how an Extensible Provisioning Protocol (EPP) connection is mapped onto a Hypertext Transfer Protocol (HTTP) session. EPP over HTTP (EoH) requires the use of Transport Layer Security (TLS) to secure EPP information (i.e. HTTPS).
	DCCP Extensions for Multipath Operation with Multiple Addresses
	draft-ietf-tsvwg-multipath-dccp-24.txt   Date: 29/04/2025   Authors: Markus Amend, Anna Brunstrom, Andreas Kassler, Veselin Rakocevic, Stephen Johnson   Working Group: Transport and Services Working Group (tsvwg)	Datagram Congestion Control Protocol (DCCP) communications, as defined in RFC 4340, are inherently restricted to a single path per connection, despite the availability of multiple network paths between peers. The ability to utilize multiple paths simultaneously for a DCCP session can enhance network resource utilization, improve throughput, and increase resilience to network failures, ultimately enhancing the user experience. Use cases for Multipath DCCP (MP-DCCP) include mobile devices (e.g., handsets, vehicles) and residential home gateways that maintain simultaneous connections to distinct network types, such as cellular and Wireless Local Area Networks (WLANs) or cellular and fixed access networks. Compared to existing multipath transport protocols, such as Multipath TCP (MPTCP), MP-DCCP is particularly suited for latency- sensitive applications with varying requirements for reliability and in-order delivery. This document specifies a set of protocol extensions to DCCP that enable multipath operations. These extensions maintain the same service model as DCCP while introducing mechanisms to establish and utilize multiple concurrent DCCP flows across different network paths.

28/04/2025

	Unsolved Challenges of IS-IS MP-TLV Proposal
	draft-wang-lsr-unsolved-challenge-of-mp-tlv-02.txt   Date: 28/04/2025   Authors: Aijun Wang   Working Group: Individual Submissions (none)	The IS-IS routing protocol uses TLV (Type-Length-Value) encoding in a variety of protocol messages. The original IS-IS TLV definition allows only for 255 octets of value in maximum. MP-TLV [I-D.ietf-lsr-multi-tlv] gives one proposal trying to solve this issue, but has some unsolved challenges for its implementations and deployment. This document analyzes in detail these challenges and proposes the community to find other better solution.

27/04/2025

	Discovery of Network Rate-Limit Policies (NRLPs)
	draft-brw-scone-rate-policy-discovery-03.txt   Date: 27/04/2025   Authors: Dan Wing, Tirumaleswar Reddy.K, Sridharan Rajagopalan, Gyan Mishra, Markus Amend, Luis Contreras   Working Group: Individual Submissions (none)	This document specifies mechanims for hosts to dynamically discover Network Rate-Limit Policies (NRLPs). This information is then passed to applications that might adjust their behaviors accordingly. Networks already support mechanisms to advertize a set of network properties to hosts (e.g., link MTU (RFC 4861) and PREFIX64 (RFC 8781)). This document complements these tools and specifies a Neighbor Discovery option to be used in Router Advertisements (RAs) to communicate NRLPs to hosts. For address family parity, a new DHCP option is also defined. The document also discusses how Provisioning Domains (PvD) can be used to notify hosts with NRLPs.
	Throughput Advice Object for SCONE
	draft-brw-scone-throughput-advice-blob-03.txt   Date: 27/04/2025   Authors: Dan Wing, Tirumaleswar Reddy.K, Sridharan Rajagopalan, Luis Contreras   Working Group: Individual Submissions (none)	Traffic exchanged over a network may be subject to rate-limit policies for various operational reasons. This document specifies a generic object (called, Throughput Advice) that can be used by mechanisms for hosts to dynamically discover these network rate-limit policies. This information is then passed to applications that might adjust their behaviors accordingly. The design of the throughput advice object is independent of the discovery channel (protocol, API, etc.).
	SCONE Solution Analysis
	draft-brw-scone-analysis-01.txt   Date: 27/04/2025   Authors: Dan Wing, Tirumaleswar Reddy.K, Sridharan Rajagopalan, Luis Contreras   Working Group: Individual Submissions (none)	This document provides an analysis of various SCONE solutions to share the throughput advice.
	Secure Task-bound Agent Message Proof (STAMP) Protocol
	draft-guy-bary-stamp-protocol-00.txt   Date: 27/04/2025   Authors: Guy Bary   Working Group: Individual Submissions (none)	The Secure Task-bound Agent Message Proof (STAMP) protocol provides a cryptographically verifiable delegation and proof framework for AI- driven multi-agent systems. STAMP introduces task-bound access tokens and message-level proofs for agentic environments, binding tokens to specific user intents, tasks, and agent identities. STAMP tokens ensure that delegation, execution, and agent-to-agent communication comply with least-privilege and zero-trust security principles. STAMP interoperates with OAuth 2.0, GNAP, and modern proof-of- possession (PoP) techniques, providing stronger security for dynamic, non-deterministic workflows involving autonomous agents.

26/04/2025

	REST API Media Types
	draft-ietf-httpapi-rest-api-mediatypes-07.txt   Date: 26/04/2025   Authors: Roberto Polli   Working Group: Building Blocks for HTTP APIs (httpapi)	This document registers the following media types used in APIs on the IANA Media Types registry: application/openapi+json, and application/ openapi+yaml.
	X.509 Certificate Extensions for Attestation Results
	draft-ounsworth-lamps-x509-ar-00.txt   Date: 26/04/2025   Authors: Mike Ounsworth, Monty Wiseman, Hannes Tschofenig, Tirumaleswar Reddy.K, Ned Smith   Working Group: Individual Submissions (none)	This document defines extensions for X.509 certificates to include attestation results as part of the certificate's content. The primary use case for these extensions is in the context of Certificate Signing Request (CSR) attestation, where claims about the trustworthiness of an Attester are conveyed to the Certification Authority (CA) as part of the CSR process. These extensions enable the CA to appraise the submitted evidence and embed attestation results into the issued certificate. This allows Relying Parties to evaluate the Attester's trustworthiness consistently and efficiently, supporting scalable policies for verification in environments with diverse attestation technologies.

25/04/2025

	Enhanced Topology Independent Loop-free Alternate Fast Re-route
	draft-li-rtgwg-enhanced-ti-lfa-12.txt   Date: 25/04/2025   Authors: Cheng Li, Zhibo Hu, Yongqing Zhu, Shraddha Hegde   Working Group: Individual Submissions (none)	Topology Independent Loop-free Alternate Fast Re-route (TI-LFA) aims at providing protection of node and adjacency segments within the Segment Routing (SR) framework. A key aspect of TI-LFA is the FRR path selection approach establishing protection over the expected post-convergence paths from the point of local repair. However, the TI-LFA FRR path may skip the node even if it is specified in the SID list to be traveled. This document defines Enhanced TI-LFA(TI-LFA+) by adding a No-bypass indicator for segments to ensure that the FRR route will not bypass the specific node, such as firewall. Also, this document defines No- bypass flag and No-FRR flag in SRH to indicate not to bypass nodes and not to perform FRR on all the nodes along the SRv6 path, respectively.
	Binary Application Record Encoding (BARE)
	draft-devault-bare-13.txt   Date: 25/04/2025   Authors: Drew DeVault   Working Group: Individual Submissions (none)	The Binary Application Record Encoding (BARE) is a data format used to represent application records for storage or transmission between programs. BARE messages are concise and have a well-defined schema, and implementations may be simple and broadly compatible. A schema language is also provided to express message schemas out-of-band. Comments Comments are solicited and should be addressed to the mailing list at ~sircmpwn/public-inbox@lists.sr.ht and/or the author(s).
	Flooding Reduction Algorithms Framework
	draft-prz-lsr-interop-flood-reduction-architecture-01.txt   Date: 25/04/2025   Authors: Tony Przygienda, Shraddha Hegde   Working Group: Individual Submissions (none)	This document introduces a framework to deploy multiple flood reduction algorithms within the same IGP domain in an interoperable fashion.
	Reverse HTTP CONNECT for TCP and UDP
	draft-rosomakho-masque-reverse-connect-00.txt   Date: 25/04/2025   Authors: Yaroslav Rosomakho   Working Group: Individual Submissions (none)	This document specifies an extension to the HTTP CONNECT method, enabling a proxy client to accept inbound TCP and UDP sessions proxied through HTTP/1.1, HTTP/2, or HTTP/3. This mechanism allows the client to dynamically advertise available local or internal network services and expose them through a HTTP proxy without reliance on IP routing.
	Initialisation of DNSSEC Policy for DNS Catalog Zones Members
	draft-dyson-dnssec-policy-initialisation-00.txt   Date: 25/04/2025   Authors: Karl Dyson   Working Group: Individual Submissions (none)	This document describes an update to "DNS Catalog Zones" ([RFC9432]) that facilitates a method to signal DNSSEC policy to DNSSEC signers for member zone(s) using information contained within a catalog zone.
	Register a new reserved content coding value
	draft-deng-httpbis-unknown-content-coding-00.txt   Date: 25/04/2025   Authors: Guohui Deng   Working Group: Individual Submissions (none)	This document proposes a new reserved value unknown for the HTTP protocol parameter content coding.
	JSON-Based Dynamic Configuration Management
	draft-abaris-json-dcm-00.txt   Date: 25/04/2025   Authors: Dogu Abaris   Working Group: Individual Submissions (none)	JavaScript Object Notation (JSON) is a widely used data interchange format, suitable for storing configuration data due to its simple syntax, machine-readable structure, and ease of parsing and generation. This document describes informational practices associated with JSON- Based Dynamic Configuration Management. It outlines a recommended naming convention for configuration files in the form of a structured filename pattern, such as "@.json", and specifies a configuration schema to support validation, traceability, and non- disruptive updates. The document also describes the rationale for standardization and presents real-world scenarios where these practices apply.

24/04/2025

	ISP Dual Queue Networking Deployment Recommendations
	draft-livingood-low-latency-deployment-09.txt   Date: 24/04/2025   Authors: Jason Livingood   Working Group: Individual Submissions (none)	The IETF's Transport and Services Working Group (TSVWG) has finalized experimental RFCs for Low Latency, Low Loss, Scalable Throughput (L4S) and new Non-Queue-Building (NQB) per hop behavior. These documents describe a new architecture and protocol for deploying low latency networking. Since deployment decisions are left to implementers, this document explores the potential implications of those decisions and makes recommendations that can help drive adoption and acceptance of L4S and NQB.
	Security Considerations for Computing-Aware Traffic Steering
	draft-wang-cats-security-considerations-02.txt   Date: 24/04/2025   Authors: Cuicui Wang, Yu Fu   Working Group: Individual Submissions (none)	Computing-Aware Traffic Steering (CATS) inherits potential security vulnerabilities from the network, computing nodes as well as workflows of CATS. This document describes various threats and security concerns related to CATS and existing approaches to solve these threats.
	Adaptive Routing Framework
	draft-cheng-rtgwg-adaptive-routing-framework-04.txt   Date: 24/04/2025   Authors: Weiqiang Cheng, Changwang Lin, Kevin Wang, Jiaming Ye, Rui Zhuang, PengFei Huo   Working Group: Individual Submissions (none)	In many cases, ECMP (Equal-Cost Multi-Path) flow-based hashing leads to high congestion and variable flow completion time. This reduces applications performance. Load balancing based on local link quality is not always optimal, A global view of congestion, with information from remote links, is needed for optimal balancing. Adaptive routing is a technology that makes dynamic routing decision based on changes in traffic load and network topology. This document describes a framework for Adaptive Routing. Specifically, it identifies a set of adaptive routing components, explains their interactions, and exemplifies the workflow mechanism.
	Link Discovery Protocol (LLDP) Extensions for Segment Routing over IPv6 (SRv6)
	draft-gong-spring-lldp-srv6-extensions-02.txt   Date: 24/04/2025   Authors: Liyan Gong, Changwang Lin, Zheng Zhang   Working Group: Individual Submissions (none)	This document describes the method of carrying SRv6 Locator information through the LLDP protocol to simplify SRv6 deployment.
	BGP - Link State (BGP-LS) Advertisement of BGP Egress Peer Engineering Performance Metric Extensions
	draft-liu-idr-bgpls-epe-te-pm-01.txt   Date: 24/04/2025   Authors: Yisong Liu, Changwang Lin, Jinming Li, 104101   Working Group: Individual Submissions (none)	This document specifies a method for advertising BGP Egress Peer Engineering (EPE) Traffic Engineering (TE) Performance Metric information via BGP-LS.
	Inter-domain Source Address Validation (SAVNET) OAM
	draft-cheng-savnet-inter-domain-oam-01.txt   Date: 24/04/2025   Authors: Weiqiang Cheng, Dan Li, Changwang Lin, 1211176911910469110103   Working Group: Individual Submissions (none)	This document is a framework for how Source Address Validation (SAVNET) can be applied to operations and maintenance procedures for Inter-domain network. The document is structured to outline how Operations and Management (OAM) functionality can be used to assist in fault, configuration, accounting, performance, and security management, commonly known by the acronym FCAPS.
	Encapsulation and Forwarding Process for IPv6 Multicast Source Routing (MSR6) Data Plane
	draft-liu-pim-msr6-encapsulation-and-forwarding-01.txt   Date: 24/04/2025   Authors: Yisong Liu, Xuesong Geng, Changwang Lin   Working Group: Individual Submissions (none)	This document specifies the mechanism of IPv6 Multicast Source Routing (MSR6), covering the encapsulation and forwarding processes in the data plane. It introduces the hierarchical bitstring structure (HBS) to organize replication information, and represent more information than flat bit strings. It indicates multicast forwarding behavior based on the local bitstring forwarding table, requires less BIFT state and improve scalability.
	DHCPv6 Active Leasequery over QUIC
	draft-lin-dhc-dhcpv6-active-leasequery-quic-00.txt   Date: 24/04/2025   Authors: Changwang Lin   Working Group: Individual Submissions (none)	RFC7653 allows for actively transferring the real-time binding information data of Dynamic Host Configuration Protocol for IPv6 (DHCPv6) via TCP, which satisfies the need of continuous update of an external requestor with Leasequery data. QUIC could provide useful, reliable and secure semantics for transferring active leasequery of DHCPv6, which enabling much better efficiency and performance by reducing connect time. This document describes how to use the QUIC transport protocol to deliver DHCPv6 Active Leasequery messages, named DHCP6oQUIC.
	OAuth 2.0 for First-Party Applications
	draft-ietf-oauth-first-party-apps-01.txt   Date: 24/04/2025   Authors: Aaron Parecki, George Fletcher, Pieter Kasselman   Working Group: Web Authorization Protocol (oauth)	This document defines the Authorization Challenge Endpoint, which supports a first-party client that wants to control the process of obtaining authorization from the user using a native experience. In many cases, this can provide an entirely browserless OAuth 2.0 experience suited for native applications, only delegating to the browser in unexpected, high risk, or error conditions.

23/04/2025

	Encrypted DNS Server Redirection
	draft-ietf-add-encrypted-dns-server-redirection-02.txt   Date: 23/04/2025   Authors: John Todd, Tommy Jensen, Corey Mosher   Working Group: Adaptive DNS Discovery (add)	This document defines Encrypted DNS Server Redirection (EDSR), a mechanism for encrypted DNS servers to redirect clients to other encrypted DNS servers. This enables dynamic routing to geo-located or otherwise more desirable encrypted DNS servers without modifying DNS client endpoint configurations or the use of anycast by the DNS server.
	Advertising In-situ Flow Information Telemetry (IFIT) Capabilities in BGP
	draft-ietf-idr-bgp-ifit-capabilities-07.txt   Date: 23/04/2025   Authors: Giuseppe Fioccola, Ran Pang, Subin Wang, Bruno Decraene, Shunwan Zhuang, Haibo Wang   Working Group: Inter-Domain Routing (idr)	In-situ Flow Information Telemetry (IFIT) refers to network OAM data plane on-path telemetry techniques, in particular In-situ OAM (IOAM) and Alternate Marking. This document defines a new Characteristic to advertise the In-situ Flow Information Telemetry (IFIT) capabilities. Within an IFIT domain, the IFIT capabilities advertisement from the tail node to the head node assists the head node to determine whether a particular IFIT Option type can be encapsulated in data packets. Such advertisement helps mitigating the leakage threat and facilitating the deployment of IFIT measurements on a per-service and on-demand basis.
	Non-source-routed Multicast in SR Networks
	draft-ietf-mboned-non-source-routed-sr-mcast-02.txt   Date: 23/04/2025   Authors: Zhaohui Zhang, IJsbrand Wijnands, Hooman Bidgoli, Yisong Liu   Working Group: MBONE Deployment (mboned)	With Segment Routing (SR) architecture, a unicast flow can be source- routed through an SR network following an explicit path specified in the packet, w/o the need for per-flow state in the network. As a result, the otherwise needed protocols to signal the per-flow unicast state can also be removed from the network. In the case of multicast, traffic can be either source-routed or non-source-routed, and this document discusses non-sourced-routed options for multicast in an SR network with either MPLS or IPv6/SRv6 data plane.
	Semantic Definition Format (SDF) for Data and Interactions of Things: Compact Notation
	draft-bormann-asdf-sdf-compact-08.txt   Date: 23/04/2025   Authors: Carsten Bormann   Working Group: Individual Submissions (none)	The Semantic Definition Format (SDF) is a format for domain experts to use in the creation and maintenance of data and interaction models that describe Things, i.e., physical objects that are available for interaction over a network. It was created as a common language for use in the development of the One Data Model liaison organization (OneDM) definitions. Tools convert this format to database formats and other serializations as needed. The SDF format is mainly intended for interchange between machine generation and machine processing. However, there is often a need for humans to look at and edit SDF models. Similar to the way Relax-NG as defined in ISO/IEC 19757-2 has an XML- based format and a compact format (its Annex C), this specification defines a compact format to go along SDF's JSON-based format. The present version of this document is mostly a proof of concept, but was deemed useful to obtain initial feedback on the approach taken.
	REST API Linked Data Keywords
	draft-polli-restapi-ld-keywords-06.txt   Date: 23/04/2025   Authors: Roberto Polli   Working Group: Individual Submissions (none)	This document defines two keywords to provide semantic information in OpenAPI Specification and JSON Schema documents, and support contract-first semantic schema design.
	Aggregation Trace Option for In-situ Operations,Administration,and Maintenance (IOAM)
	draft-cxx-ippm-ioamaggr-03.txt   Date: 23/04/2025   Authors: Alexander Clemm, Metzger, Ramon Bister, Severin Dellsperger   Working Group: Individual Submissions (none)	The purpose of this memo is to describe a new option type for In-Situ Operations, Administration, and Maintenance (IOAM). This option type allows to aggregate IOAM data along a network path. Aggregates include functions such as the sum, average, minimum, or maximum of a given data parameter.
	Autonomous System Relationship Authorization (ASRA) as an Extension to ASPA for Enhanced AS Path Verification
	draft-sriram-sidrops-asra-verification-02.txt   Date: 23/04/2025   Authors: Kotikalapudi Sriram, Nan Geng, Amir Herzberg   Working Group: Individual Submissions (none)	Autonomous System Provider Authorization (ASPA) record authorizes provider ASes of a customer AS (CAS). While ASPA-based AS_PATH verification can correctly detect and mitigate route leaks and some forged-origin or forged-path-segment hijacks, it fails to detect some malicious path manipulations for routes that are received from transit providers. This document utilizes a new RPKI object called Autonomous System Relationship Authorization (ASRA) that significantly enhances AS_PATH verification complementing ASPA. ASRA fills in a significant gap in the ASPA method by adding the capability to detect fake links in the AS_PATHs in BGP Updates propagated from providers to customers. ASRA achieves this by allowing an AS to register additional AS relationships, i.e., customers and lateral peers.
	A mechanism of security monitoring and management for service resources in Computing-Aware Traffic Steering (CATS)
	draft-lu-cats-smam-security-01.txt   Date: 23/04/2025   Authors: LU Li, Meiling Chen, Li Su   Working Group: Individual Submissions (none)	This draft proposes a mechanism to realize monitoring and management of service resources.
	Guidance on RESTful Design for Internet of Things Systems
	draft-irtf-t2trg-rest-iot-16.txt   Date: 23/04/2025   Authors: Ari Keranen, Matthias Kovatsch, Klaus Hartke   Working Group: Thing-to-Thing (t2trg)	This document gives guidance for designing Internet of Things (IoT) systems that follow the principles of the Representational State Transfer (REST) architectural style. This document is a product of the IRTF Thing-to-Thing Research Group (T2TRG).

22/04/2025

	An Architecture for DNS-Bound Client and Sender Identities
	draft-ietf-dance-architecture-08.txt   Date: 22/04/2025   Authors: Ash Wilson, Shumon Huque, Olle Johansson, Michael Richardson   Working Group: DANE Authentication for Network Clients Everywhere (dance)	This architecture document defines terminology, interaction, and authentication patterns, related to the use of DANE DNS records for TLS client and messaging peer identity, within the context of existing object security and TLS-based protocols.
	The DRIP DET public Key Infrastructure
	draft-ietf-drip-dki-08.txt   Date: 22/04/2025   Authors: Robert Moskowitz, Stuart Card   Working Group: Drone Remote ID Protocol (drip)	The DRIP Entity Tag (DET) public Key Infrastructure (DKI) is a specific variant of classic Public Key Infrastructures (PKI) where the organization is around the DET, in place of X.520 Distinguished Names. Further, the DKI uses DRIP Endorsements in place of X.509 certificates for establishing trust within the DKI. There are two X.509 profiles for shadow PKI behind the DKI, with many of their X.509 fields mirroring content in the DRIP Endorsements. These PKIs can at times be used where X.509 is expected and non- constrained communication links are available that can handle their larger size. It is recommended that a DRIP deployment implement both of these along side the Endorsement trees. C509 (CBOR) encoding of all X.509 certificates are also provided as an alternative for where there are gains in reduced object size.
	Flexible Session Protocol
	draft-gao-flexible-session-protocol-14.txt   Date: 22/04/2025   Authors: Jun-an Gao   Working Group: Individual Submissions (none)	FSP is a connection-oriented transport layer protocol that provides mobility and multihoming support by introducing the concept of 'upper layer thread ID', which is associated with some shared secret that is applied with some authenticated encryption algorithm to protect authenticity of the origin of the FSP packets. It is able to provide following services to the upper layer application: * Stream-oriented send-receive with native message boundary * Flexibility to exploit authenticated encryption * On-the-wire compression * Light-weight session management
	KEM-based Authentication for TLS 1.3
	draft-celi-wiggers-tls-authkem-05.txt   Date: 22/04/2025   Authors: Thom Wiggers, Sofia Celi, Peter Schwabe, Douglas Stebila, Nick Sullivan   Working Group: Individual Submissions (none)	This document gives a construction for a Key Encapsulation Mechanism (KEM)-based authentication mechanism in TLS 1.3. This proposal authenticates peers via a key exchange protocol, using their long- term (KEM) public keys.
	Compressed SID (CSID) for SRv6 SFC
	draft-lh-spring-srv6-sfc-csid-04.txt   Date: 22/04/2025   Authors: Cheng Li, Weiqiang Cheng, Hongyi Huang   Working Group: Individual Submissions (none)	In SRv6, an SRv6 SID is a 128-bit value. When too many 128-bit SRv6 SIDs are included in an SRH, the introduced overhead will affect the transmission efficiency of payload. In order to address this problem, Compressed SID(CSID) is proposed. This document defines new behaviors for service segments with REPLACE-CSID and NEXT-CSID flavors to enable compressed SRv6 service programming.
	Aircraft to Anything AdHoc Broadcasts and Session
	draft-moskowitz-drip-a2x-adhoc-session-06.txt   Date: 22/04/2025   Authors: Robert Moskowitz, Stuart Card, Andrei Gurtov   Working Group: Individual Submissions (none)	Aircraft-to-anything (A2X) communications are often single broadcast messages that to be trustable, need to be signed with expensive (in cpu and payload size) asymmetric cryptography. There are also frequent cases of extended exchanges between two devices where trust can be maintained via a lower cost symmetric key protect flow. This document shows both how to secure A2X broadcast messages with DRIP Entity Tags (DET) and DRIP Endorsement objects and to leverage these to create an AdHoc session key for just such a communication flow. There is also provision for DETs within X.509 certificates, encoded in c509, as an alternative DET trust model.
	KEM-based pre-shared-key handshakes for TLS 1.3
	draft-wiggers-tls-authkem-psk-03.txt   Date: 22/04/2025   Authors: Thom Wiggers, Sofia Celi, Peter Schwabe, Douglas Stebila, Nick Sullivan   Working Group: Individual Submissions (none)	This document gives a construction in which (long-term) KEM public keys are used in the place of TLS PSK keys, avoiding concerns that may affect systems that use symmetric-key-based PSK, such as requiring key diversification and protection of symmetric-keys' confidentiality. This mechanism is inspired by AuthKEM (and could use AuthKEM certificate public keys for resumption), but can be independently implemented.
	Ways to convey the Ratchet Tree in Messaging Layer Security
	draft-mahy-mls-ratchet-tree-options-02.txt   Date: 22/04/2025   Authors: Rohan Mahy   Working Group: Individual Submissions (none)	The Messaging Layer Security (MLS) protocol needs to share its ratchet_tree object to welcome new clients into a group and in external joins. While the protocol only defines a mechanism for sharing the entire tree, most implementations use various optimizations to avoid sending this structure repeatedly in large groups. This document describes a way to convey these improvements in a standardized way and to convey the parts of a GroupInfo object that are not visible to an intermediary server.
	Advertising Router Information
	draft-zzhang-rtgwg-router-info-03.txt   Date: 22/04/2025   Authors: Zhaohui Zhang, Kevin Wang, Changwang Lin, Niranjan Vaidya, Jeff Tantsura, Yisong Liu   Working Group: Individual Submissions (none)	This document specifies a generic mechanism for a router to advertise some information to its neighbors. One use case of this mechanism is to advertise link/path information so that a receiving router can better react to network changes.
	Root CA Certificate Rekeying in the Scenario of Post Quantum Migration
	draft-wang-lamps-root-ca-cert-rekeying-02.txt   Date: 22/04/2025   Authors: Guilin WANG, Yanjiang Yang, Jie Zhang   Working Group: Individual Submissions (none)	In the public key infrastructures (PKIs), root certifcation authority (CA) certificate rekeying is crucial to guarantee business continuity. Two approaches are given in [RFC4210] for entities which are belonging to different generations to verify each other's certificate chain. However, these approaches rely on the assumption that the old entities can be updated. In this draft, we propose a one-way link certificate based solution such that old entities are transparent to root CA certificate rekeying. Namely, during the overlapping lifetime of two root CA certificates, without any update in old entities, old and new entities can verify each other's certificate chain smoothly. Furthermore, the proposed solution works in both traditional PKIs, and post-quantum (PQ) PKIs, where the cerficate can be pure PQ ones or hybrid ones.
	Convertible Forms with Multiple Keys and Signatures For Use In Internet X.509 Certificates
	draft-sun-lamps-hybrid-scheme-01.txt   Date: 22/04/2025   Authors: Sun Shuzhou, Yidi He, Hsiao-Ying Lin   Working Group: Individual Submissions (none)	This document presents a hybrid key and signature solution, which allows to integrate two public keys and/or two signatures into a single certificate. The scheme enables a single certificate to be converted between different forms, allowing an alternative public key and/or an alternative signature to be transmitted either by direct inclusion or by referencing external data. This flexibility ensures that the scheme is backward-compatible with legacy devices, while also providing enhanced security support for upgraded devices. Four CSR attributes and two new X.509v3 certificate extensions are defined, and the procedures for signing and verifying certificates containing the defined attributes and extensions are described.
	Automated Summaries of IETF Contributions
	draft-sayre-modpod-summary-01.txt   Date: 22/04/2025   Authors: Robert Sayre   Working Group: Individual Submissions (none)	Automated summaries of IETF contributions are permissible contributions.
	OAuth Pushed Client Registration
	draft-richer-oauth-pushed-client-registration-00.txt   Date: 22/04/2025   Authors: Justin Richer, Aaron Parecki   Working Group: Individual Submissions (none)	This specification provides a way for an ephemeral or transactional OAuth 2.0 client to signal to the AS that the client does not need or expect to have an identified state outside the existence of any issued access and refresh tokens. The specification also enables a client to push its registration information to the AS during a pushed authorization request.
	AS2 Specification Modernization
	draft-petta-rfc4130bis-00.txt   Date: 22/04/2025   Authors: Debra Petta   Working Group: Individual Submissions (none)	This document provides an applicability statement (RFC 2026, Section 3.2) that describes how to exchange structured business data securely using the HTTP transfer protocol, instead of SMTP; the applicability statement for SMTP is found in RFC 3335. Structured business data may be XML; Electronic Data Interchange (EDI) in either the American National Standards Committee (ANSI) X12 format or the UN Electronic Data Interchange for Administration, Commerce, and Transport (UN/EDIFACT) format; or other structured data formats. The data is packaged using standard MIME structures. Authentication and data confidentiality are obtained by using Cryptographic Message Syntax with S/MIME security body parts. Authenticated acknowledgements make use of multipart/signed Message Disposition Notification (MDN) responses to the original HTTP message. This applicability statement is informally referred to as "AS2" because it is the second applicability statement, produced after "AS1", RFC 3335.
	PQuAKE - Post-Quantum Authenticated Key Exchange
	draft-uri-lake-pquake-00.txt   Date: 22/04/2025   Authors: Uri Blumenthal, Brandon Luo, Sean O'Melia, Gabriel Torres, David Wilson   Working Group: Individual Submissions (none)	This document defines the Post-Quantum Authenticated Key Exchange (PQuAKE) protocol that addresses the needs of bandwidth- and/or power-constrained environments, while maintaining strong security guarantees. It accomplishes that by minimizing the number of bits that need to be exchanged and by utilizing an implicit peer authentication approach similar to Menezes-Qu-Vanstone (MQV) design. This protocol is suitable for integration into protocols that establish dynamic secure sessions, such as Extensible Authentication Protocol (EAP), Internet Key Exchange Version 2 (IKEv2), or Secure COmmunications Interoperability Protocol (SCIP). This protocol has proofs in the verifiers Verifpal and CryptoVerif for security properties such as secrecy of the session key, mutual authentication, identity hiding with a preshared secret, and forward secrecy of the session key. The authors are in the process of publishing the proofs.
	Best Practices for Persistent References in DNS
	draft-sheth-identifiers-dns-00.txt   Date: 22/04/2025   Authors: Swapneel Sheth, Andrew Kaizer   Working Group: Individual Submissions (none)	This document details some best practices for Application Service Providers who allow associations between a global DNS domain name and use case specific references using DNSSEC to provide a globally consistent, cryptographically verifiable association. Such a mechanism is needed when nonce-based domain control validation is not practical, such as use cases where each participant wants to confirm the association independently. As such, no single Application Service Provider exists to provide and validate a nonce to prove domain control that would satisfy other participating Application Service Providers.
	Conveying the More Instant Messaging Interoperability Message ID in Messaging Layer Security Additional Authenticated Data
	draft-mahy-mimi-msgid-aad-00.txt   Date: 22/04/2025   Authors: Rohan Mahy   Working Group: Individual Submissions (none)	The More Instant Messaging Interoperability (MIMI) content format defines a MIMI Message ID, communicated only to members of the Messaging Layer Security (MLS) group in which the message was sent. This document defines a way to share a Message ID in the MLS Additional Authenticated Data (AAD) so it is visible to MIMI providers.
	Roughtime
	draft-ietf-ntp-roughtime-14.txt   Date: 22/04/2025   Authors: Watson Ladd, Marcus Dansarie   Working Group: Network Time Protocols (ntp)	This document describes Roughtime—a protocol that aims to achieve two things: secure rough time synchronization even for clients without any idea of what time it is, and giving clients a format by which to report any inconsistencies they observe between time servers. This document specifies the on-wire protocol required for these goals, and discusses aspects of the ecosystem needed for it to work.

21/04/2025

	RUSH - Reliable (unreliable) streaming protocol
	draft-kpugin-rush-03.txt   Date: 21/04/2025   Authors: Kirill Pugin, Nitin Garg, Alan Frindell, Jorge Ferret, Jake Weissman   Working Group: Individual Submissions (none)	RUSH is an application-level protocol for ingesting live video. This document describes the protocol and how it maps onto QUIC. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the mailing list (), which is archived at . Source for this draft and an issue tracker can be found at https://github.com/afrind/draft-rush.
	Problem Statement and Gap Analysis for Connecting to Cloud DCs via Optical Networks
	draft-liu-ccamp-optical2cloud-problem-statement-08.txt   Date: 21/04/2025   Authors: Sheng Liu, Haomian Zheng, Aihua Guo, Yang Zhao, Daniel King   Working Group: Individual Submissions (none)	Optical networking technologies such as fine-grain OTN (fgOTN) enable premium cloud-based services, including optical leased line, cloud Virtual Reality (cloud-VR), and computing to be carried end-to-end optically between applications and cloud data centers (DCs), offering premium quality and deterministic performance. This document describes the problem statement and requirements for accessing cloud services through optical networks. It also discusses technical gaps for IETF-developed management and control protocols to support service provisioning and management in such an all-optical network scenario.
	Datagram Transport Layer Security (DTLS) 1.3 for Stream Control Transmission Protocol (SCTP)
	draft-tuexen-tsvwg-rfc6083-bis-07.txt   Date: 21/04/2025   Authors: Michael Tuexen, Hannes Tschofenig, Tirumaleswar Reddy.K   Working Group: Individual Submissions (none)	This document describes the usage of the Datagram Transport Layer Security (DTLS) 1.3 protocol over the Stream Control Transmission Protocol (SCTP) and obsoletes RFC 6083. DTLS 1.3 over SCTP provides communications privacy for applications that use SCTP as their transport protocol and allows client/server applications to communicate in a way that is designed to prevent eavesdropping and detect tampering or message forgery. Applications using DTLS 1.3 over SCTP can use almost all transport features provided by SCTP and its extensions.
	4map6 Segments for IPv4 Service delivery over IPv6-only underlay networks
	draft-dong-spring-sr-4map6-segments-04.txt   Date: 21/04/2025   Authors: Guozhen Dong, Chongfeng Xie, Xing Li, Shuping Peng   Working Group: Individual Submissions (none)	This document defines a new type of segment for Segment Routing, 4map6 segment, which is an IPv4/IPv6 conversion function based on stateless mapping rules running in PE nodes for the delivery of IPv4 services over IPv6-only network. At the same time, the BGP Prefix- SID attribute SRv6 Service TLVs is extended to transmit IPv4/IPv6 address mapping rules in IPv6-only domain and cross-domain.
	Semi-Private Messages in the Messaging Layer Security (MLS) Protocol
	draft-mahy-mls-semiprivatemessage-05.txt   Date: 21/04/2025   Authors: Rohan Mahy   Working Group: Individual Submissions (none)	This document defines a SemiPrivateMessage for the Messaging Layer Security (MLS) protocol. It allows members to share otherwise private commits and proposals with a designated list of external receivers rather than send these handshakes in a PublicMessage.
	Perceptive Routing Information Model
	draft-zhou-rtgwg-perceptive-routing-information-01.txt   Date: 21/04/2025   Authors: Tianran Zhou, Dan Li, Xuesong Geng   Working Group: Individual Submissions (none)	This docuement defines the information model for perceptive routing, which could serve as a foundational component in the implementation of perceptive routing.
	Protocol for Automation Control
	draft-liao-aipref-autoctl-core-01.txt   Date: 21/04/2025   Authors: Liao Peiyuan   Working Group: Individual Submissions (none)	This document specifies a machine-readable protocol for server-side automation permissions in the light of recent advances in AI-driven web automation. Building upon RFC9309, this protocol addresses a broader range of state-changing activities that service owners may wish to control. It defines the file format, HTTP method restrictions, and purpose requirements.
	Protocol Extension for Automation Control
	draft-liao-aipref-autoctl-ext-01.txt   Date: 21/04/2025   Authors: Liao Peiyuan   Working Group: Individual Submissions (none)	This document specifies extensions to [CORE-SPEC], providing a wider range of controls for server-side automation permissions. It supports rate limiting, automation technology restrictions, API permissions, session requirements, and HTML asset annotations. These extensions enable service owners to exercise more granular control over automated interactions.
	The agent:// Protocol -- A URI-Based Framework for Interoperable Agents
	draft-narvaneni-agent-uri-01.txt   Date: 21/04/2025   Authors: Yaswanth Narvaneni   Working Group: Individual Submissions (none)	This document defines the agent:// protocol, a URI template-based framework as described in RFC 6570 for addressing, invoking, and interoperating with autonomous and semi-autonomous software agents. It introduces a layered architecture that supports minimal implementations (addressing and transport) and extensible features (capability discovery, contracts, orchestration). The protocol aims to foster interoperability among agents across ecosystems, platforms, and modalities, enabling composable and collaborative intelligent systems.
	A YANG Data Model for Segment Routing (SR) Policy and SR in IPv6 (SRv6) support in Path Computation Element Communications Protocol (PCEP)
	draft-ietf-pce-pcep-srv6-yang-07.txt   Date: 21/04/2025   Authors: Cheng Li, Siva Sivabalan, Shuping Peng, Mike Koldychev, Luc-Fabrice Ndifor   Working Group: Path Computation Element (pce)	This document augments a YANG data model for the management of Path Computation Element Communications Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs in support for Segment Routing in IPv6 (SRv6) and SR Policy. The data model includes configuration data and state data (status information and counters for the collection of statistics).
	PCEP extensions for Distribution of Link-State and TE Information
	draft-ietf-pce-pcep-ls-03.txt   Date: 21/04/2025   Authors: Dhruv Dhody, Shuping Peng, Young Lee, Daniele Ceccarelli, Aijun Wang, Gyan Mishra   Working Group: Path Computation Element (pce)	In order to compute and provide optimal paths, Path Computation Elements (PCEs) require an accurate and timely Traffic Engineering Database (TED). Traditionally, this TED has been obtained from a link state (LS) routing protocol supporting the traffic engineering extensions. This document extends the Path Computation Element Communication Protocol (PCEP) with Link-State and TE Information as an experimental extension to allow gathering more deployment and implementation feedback on the use of PCEP in this way.
	ECN++: Adding Explicit Congestion Notification (ECN) to TCP Control Packets
	draft-ietf-tcpm-generalized-ecn-17.txt   Date: 21/04/2025   Authors: Marcelo Bagnulo, Bob Briscoe   Working Group: TCP Maintenance and Minor Extensions (tcpm)	This document specifies an experimental modification to ECN when used with TCP. It allows the use of ECN in the IP header of the following TCP packets: SYNs, SYN/ACKs, pure ACKs, Window probes, FINs, RSTs and retransmissions. This specification obsoletes RFC5562, which described a different way to use ECN on SYN/ACKs alone.
	YANG models for Virtual Network (VN)/TE Performance Monitoring Telemetry and Scaling Intent Autonomics
	draft-ietf-teas-actn-pm-telemetry-autonomics-15.txt   Date: 21/04/2025   Authors: Young Lee, Dhruv Dhody, Ricard Vilalta, Daniel King, Daniele Ceccarelli   Working Group: Traffic Engineering Architecture and Signaling (teas)	This document provides YANG data models that describe the performance monitoring parameters and scaling intent mechanisms for TE-tunnels and Virtual Networks (VNs). Their performance monitoring parameters are exposed as the key telemetry data for tunnels and VN. The models presented in this document allow customers to subscribe to and monitor the key performance data of the TE-tunnel or the VN. The models also provide customers with the ability to program autonomic scaling intent mechanisms on the level of TE-tunnel as well as VN.
	Authenticated Chunks for the Stream Control Transmission Protocol (SCTP)
	draft-ietf-tsvwg-rfc4895-bis-05.txt   Date: 21/04/2025   Authors: Michael Tuexen, Randall Stewart, Peter Lei, Hannes Tschofenig   Working Group: Transport and Services Working Group (tsvwg)	This document describes a new chunk type, several parameters, and procedures for the Stream Control Transmission Protocol (SCTP). This new chunk type can be used to authenticate SCTP chunks by using shared keys between the sender and receiver. The new parameters are used to establish the shared keys. This document obsoletes RFC 4895.

20/04/2025

	Enforcing end-to-end delay bounds via queue resizing
	draft-aft-detnet-bound-delay-queue-04.txt   Date: 20/04/2025   Authors: Antoine Fressancourt   Working Group: Individual Submissions (none)	This document presents a distributed mechanism to enforce strict delay bounds for some network flows in large scale networks. It leverages on the capacity of modern network devices to adapt their queue's capacities to bound the maximum time spent by packets in those devices. It is using a reservation protocol to guarantee the availability of the resources in the devices' queues to serve packets belonging to specific flows while enforcing an end-to-end delay constraint.
	Customer Experience Index for Evaluating Network Quality for Cloud Applications
	draft-hz-ippm-cei-03.txt   Date: 20/04/2025   Authors: Sifa Liu, Yaojing Wang, Wei Sun, Xiang Huang, Shuai Zhou, Xuesong Geng, Hongyi Huang, Tianran Zhou, Jian Ge, KE Ma, Ruihao Chen   Working Group: Individual Submissions (none)	This document outlines a unified Customer Experience Index (CEI) designed to assist cloud vendors in assessing network quality, reflecting the customer experience with cloud applications when accessed via the public network.
	Pisces: Real-Time Video Transport Framework
	draft-zheng-pisces-01.txt   Date: 20/04/2025   Authors: Jiaqi Zheng, Feida Liu, Yu Liu, Yi Lu, Guihai Chen   Working Group: Individual Submissions (none)	This document specifies the Pisces, an ensemble video transport framework for real-time communication. Pisces complements the benefits of rule-based and learning-based approaches, without modifying the codec layer. Pisces uses an incremental and iterative reinforcement learning model to adapt to the unseen environment. When the real environment well matches the training environment, the learning-based approach is actively working. Otherwise, the rule- based approach is used to ensure transport safety. By simultaneously leveraging both rule-based logic and learning models to proactively probe network capacity, Pisces achieves high efficiency in both single-flow and cross-flow scenarios, while ensuring stable and fair cross-flow convergence. Pisces can be deployed in WebRTC, which replaces the default Google congestion control algorithm.
	Content-based IP-Multicast Grouping Framework for Real-time Spatial Sensing and Control Applications with Edge Computing
	draft-akiyama-cmg-01.txt   Date: 20/04/2025   Authors: Kuon Akiyama, Ryoichi Shinkuma   Working Group: Individual Submissions (none)	This document describes a content-based multicast grouping framework aimed at simplifying routing control and reducing unnecessary traffic in large-scale networks for real-time spatial sensing and control applications. The framework introduces content-based multicast groups, which are managed at the local level by routers without the need for global group membership tracking. Additionally, a "topic" concept is introduced, allowing routers to manage multicast delivery based on data content. This framework reduces bandwidth consumption and simplifies multicast routing while offering flexible data delivery across various topics.
	Framework for Implementing Lossless Techniques in Wide Area Networks
	draft-hs-rtgwg-wan-lossless-framework-01.txt   Date: 20/04/2025   Authors: Tao He, Hang Shi, Han Zhengxin, Gao xing, Tianran Zhou   Working Group: Individual Submissions (none)	This document proposes a comprehensive framework to address the challenges of efficient, reliable, and cost-effective large volume data transmission over Wide Area Networks (WANs). The framework focuses on planning and managing traffic paths, network slicing, and utilizing multi-level network buffers. It introduces dynamic path scheduling and advanced resource allocation techniques to optimize network resouce and minimize congestion. By leveraging cross-device buffer coordination and real-time adjustments, the framework ensures high throughput and low latency, meeting the demands of modern, data- intensive applications while providing a robust solution for large- scale data transmission.
	SCONE Real Time Communication Requirement
	draft-shi-scone-rtc-requirement-02.txt   Date: 20/04/2025   Authors: Hang Shi, Xuesong Geng, Qiangzhou Gao, Qinghua Wu, Jiaxing Zhang   Working Group: Individual Submissions (none)	In real-time communication (RTC) applications, low latency is essential, but unstable network conditions make it challenging. Traditional control loop reacts slowly and inaccurately to network changes. A new approach is proposed, communicating bandwidth and queue information from the bottleneck to the end-host for more accurate control.
	BGP Prefix Independent Convergence
	draft-ietf-rtgwg-bgp-pic-22.txt   Date: 20/04/2025   Authors: Ahmed Bashandy, Clarence Filsfils, Prodosh Mohapatra   Working Group: Routing Area Working Group (rtgwg)	In a network comprising thousands of BGP peers exchanging millions of routes, many routes are reachable via more than one next-hop. Given the large scaling targets, it is desirable to restore traffic after failure in a time period that does not depend on the number of BGP prefixes. This document describes an architecture by which traffic can be re- routed to equal cost multi-path (ECMP) or pre-calculated backup paths in a timeframe that does not depend on the number of BGP prefixes. The objective is achieved through organizing the forwarding data structures in a hierarchical manner and sharing forwarding elements among the maximum possible number of routes. The described technique yields prefix independent convergence while ensuring incremental deployment, complete automation, and zero management and provisioning effort. It is noteworthy to mention that the benefits of BGP Prefix Independent Convergence (BGP-PIC) are hinged on the existence of more than one path whether as ECMP or primary-backup.

19/04/2025

	Enforcing DNSSEC via HTTPS: Combining DANE and MTA-STS
	draft-frickl-mta-sts-dnssec-policy-02.txt   Date: 19/04/2025   Authors: Gunther Nitzsche   Working Group: Individual Submissions (none)	This document proposes a minimal, backward-compatible extension to the SMTP MTA-STS policy format by adding an optional field "dnssec:" to indicate whether the recipient domain operator expects DNSSEC validation to be active. This allows sending MTAs to detect silent DNSSEC stripping attacks and apply more secure delivery behavior accordingly. The mechanism leverages the existing HTTPS-secured delivery channel of MTA-STS and does not require changes to the DNS infrastructure or SMTP protocol.
	CBOR Simple Value for CSF
	draft-rundgren-cbor-simple-4-csf-00.txt   Date: 19/04/2025   Authors: Anders Rundgren   Working Group: Individual Submissions (none)	This document defines a CBOR "simple" value to be used as a unique label for a container map holding an embedded signature.

18/04/2025

	BGP SR Policy Extensions to Enable IFIT
	draft-ietf-idr-sr-policy-ifit-10.txt   Date: 18/04/2025   Authors: Fengwei Qin, Hang Yuan, Shunxing Yang, Tianran Zhou, Giuseppe Fioccola   Working Group: Inter-Domain Routing (idr)	Segment Routing (SR) policy is a set of candidate SR paths consisting of one or more segment lists and necessary path attributes. It enables instantiation of an ordered list of segments with a specific intent for traffic steering. In-situ Flow Information Telemetry (IFIT) refers to network OAM data plane on-path telemetry techniques, in particular the most popular are In-situ OAM (IOAM) and Alternate Marking. This document defines extensions to BGP to distribute SR policies carrying IFIT information. So that IFIT methods can be enabled automatically when the SR policy is applied.
	Secure UAS Stateless Network RID
	draft-moskowitz-drip-stateless-nrid-01.txt   Date: 18/04/2025   Authors: Robert Moskowitz, Stuart Card, Adam Wiethuechter, Andrei Gurtov   Working Group: Individual Submissions (none)	This document defines a stateless transport mechanism and message content between an Uncrewed Aircraft System (UAS) and its UAS Service Supplier (USS) for Network Remote ID (Net-RID) messages. It leverages the Broadcast Remote ID (B-RID) messages as constructed by the UA, or constructed by the Ground Control Station (GCS) from the Command-and-Control (C2) messages that are then sent directly over UDP from the UAS. These messages are authenticated by the DRIP Authentication messages if originating from the UA. When originating from the GCS, CBOR Web Tokens (CWT) signed by the GCS's DRIP Entity Tag (DET), are used. Transport privacy is out-of-scope in this approach per the stateless design. Some proposals are offered for data privacy that require some minimal state.
	Homomorphic Cryptography Protocols for Measurement Information Collection
	draft-li-ppm-homomorphic-encryption-01.txt   Date: 18/04/2025   Authors: Lun Li, Faye Liu   Working Group: Individual Submissions (none)	Homomorphic encryption is an algorithm that allows computations to be performed on encrypted data without first having to decrypt it. This document provides a homomorphic cryptographic protocol that supports addition and multiplication in the ciphertext state. In this document, the proposed protocol can be used to protect user privacy in measurement information collection and statistics by using homomorphic encryption. And let the collector server receive the computation results without having to acknowledge the information plaintext of each individual client.
	Extensions to IOAM Trace Option for Carrying Fixed-Size Data
	draft-xiao-ippm-ioam-trace-extensions-01.txt   Date: 18/04/2025   Authors: Xiao Min, Yisong Liu, Changwang Lin   Working Group: Individual Submissions (none)	In situ Operations, Administration, and Maintenance (IOAM) Trace- Option data defined in RFC 9197 is a variable-length data, the length of this kind of data varies with the transited IOAM-capable nodes and the selection of data fields processed by each IOAM-capable node. This document extends the IOAM Trace Option to carry a fixed-size data, the length of this kind of data is fixed once the selection of data fields processed by each IOAM-capable node is determined, and doesn't vary with the transited IOAM-capable nodes.
	Zixt Secure Messaging Protocol (ZSMP)
	draft-huff-zsmp-00.txt   Date: 18/04/2025   Authors: Ryan Huff   Working Group: Individual Submissions (none)	This document specifies the Zixt Secure Messaging Protocol (ZSMP), a protocol for secure, end-to-end encrypted messaging in the Zixt Chat application. ZSMP provides authentication, confidentiality, and integrity for messages exchanged between clients, with support for group messaging and extensibility. This specification defines the message formats, cryptographic mechanisms, and session management procedures for ZSMP.

17/04/2025

	Push And Pull Based Security Event Token (SET) Delivery
	draft-tulshibagwale-saag-pushpull-delivery-03.txt   Date: 17/04/2025   Authors: Atul Tulshibagwale, Apoorva Deshpande, Aaron Parecki   Working Group: Security Area (sec)	This specification defines how multiple Security Event Tokens (SETs) can be delivered and received to and by an intended recipeint using HTTP POST over TLS or WebSocket binding. This specification enabled following two use cases - * In situations where a transmitter of Security Event Tokens (SETs) to a network peer is also a receiver of SETs from the same peer, it is helpful to have an efficient way of sending and receiving SETs in one HTTP transaction. In many cases, such as when using the OpenID Shared Signals Framework (SSF), the situation where each entity is both a transmitter and receiver is getting increasingly common. * In situations where a transmitter of Security Event Tokens (SETs) wants to transmit multiple SETs to the reciever in a single HTTP call. Using current mechanisms such as "Push-Based Delivery of Security Event Tokens (SETs) Using HTTP" or "Poll-Based Delivery of Security Event Tokens (SETs) Using HTTP" both require two or more HTTP connections to exchange SETs between peers. This is inefficient due to the latency of setting up each communication. This specification enables mutiple events to be transmitted in bi-directional transmission and reception of multiple SETs in one HTTP connection, and enables them to do so over a single HTTP or WebSocket binding. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://sgnl- ai.github.io/pushpull/. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-tulshibagwale-saag- pushpull-delivery/. Source for this draft and an issue tracker can be found at https://github.com/SGNL-ai/pushpull.

16/04/2025

	CPace,a balanced composable PAKE
	draft-irtf-cfrg-cpace-14.txt   Date: 16/04/2025   Authors: Michel Abdalla, Bjoern Haase, Julia Hesse   Working Group: Crypto Forum (cfrg)	This document describes CPace which is a protocol that allows two parties that share a low-entropy secret (password) to derive a strong shared key without disclosing the secret to offline dictionary attacks. The CPace protocol was tailored for constrained devices and can be used on groups of prime- and non-prime order.
	SR Policies Extensions for Path Segment and Bidirectional Path in BGP-LS
	draft-ietf-idr-bgp-ls-sr-policy-path-segment-09.txt   Date: 16/04/2025   Authors: Cheng Li, Zhenbin Li, Yongqing Zhu, Weiqiang Cheng, Ketan Talaulikar   Working Group: Inter-Domain Routing (idr)	This document specifies the way of collecting configuration and states of SR policies carrying Path Segment and bidirectional path information by using BPG-LS. Such information can be used by external conponents for many use cases such as performance measurement, path re-optimization and end-to-end protection.
	A Mechanism for Encoding Differences in Paired Certificates
	draft-bonnell-lamps-chameleon-certs-06.txt   Date: 16/04/2025   Authors: Corey Bonnell, John Gray, D. Hook, Tomofumi Okubo, Mike Ounsworth   Working Group: Individual Submissions (none)	This document specifies a method to efficiently convey the differences between two certificates in an X.509 version 3 extension. This method allows a relying party to extract information sufficient to reconstruct the paired certificate and perform certification path validation using the reconstructed certificate. In particular, this method is especially useful as part of a key or signature algorithm migration, where subjects may be issued multiple certificates containing different public keys or signed with different CA private keys or signature algorithms. This method does not require any changes to the certification path validation algorithm as described in RFC 5280. Additionally, this method does not violate the constraints of serial number uniqueness for certificates issued by a single certification authority.
	Path Computation Element Communication Protocol (PCEP) Extension for Path Segment in Segment Routing (SR)
	draft-ietf-pce-sr-path-segment-13.txt   Date: 16/04/2025   Authors: Cheng Li, Mach Chen, Weiqiang Cheng, Rakesh Gandhi, Quan Xiong   Working Group: Path Computation Element (pce)	The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The Source Packet Routing in Networking (SPRING) architecture describes how Segment Routing (SR) can be used to steer packets through an IPv6 or MPLS network using the source routing paradigm. A Segment Routed Path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), explicit configuration, or a Path Computation Element (PCE). Path identification is needed for several use cases such as performance measurement in Segment Routing (SR) network. This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) to support requesting, replying, reporting and updating the Path Segment ID (Path SID) between PCEP speakers.

15/04/2025

	Reliable and Available Wireless (RAW) Technologies
	draft-ietf-raw-technologies-17.txt   Date: 15/04/2025   Authors: Pascal Thubert, Dave Cavalcanti, Xavier Vilajosana, Corinna Schmitt, Janos Farkas   Working Group: Deterministic Networking (detnet)	This document surveys the short and middle range radio technologies that are suitable to provide a Deterministic Networking / Reliable and Available Wireless (RAW) service over, presents the characteristics that RAW may leverage, and explores the applicability of the technologies to carry deterministic flows, as of its time of publication. The studied technologies are Wi-Fi 6/7, TimeSlotted Channel Hopping (TSCH), 3GPP 5G, and L-band Digital Aeronautical Communications System (LDACS).
	ICANN Registry Interfaces
	draft-lozano-icann-registry-interfaces-24.txt   Date: 15/04/2025   Authors: Gustavo Ibarra, Eduardo Alvarez   Working Group: Individual Submissions (none)	This document describes the technical details of the interfaces provided by the Internet Corporation for Assigned Names and Numbers (ICANN) to its contracted parties to fulfill reporting requirements. The interfaces provided by ICANN to Data Escrow Agents and Registry Operators to fulfill the requirements of Specifications 2 and 3 of the gTLD Base Registry Agreement are described in this document. Additionally, interfaces for retrieving the IP addresses of the probe nodes used in the SLA Monitoring System (SLAM) and interfaces for supporting maintenance window objects are described in this document.
	ICANN Registrar Interfaces
	draft-icann-registrar-interfaces-14.txt   Date: 15/04/2025   Authors: Gustavo Ibarra, Eduardo Alvarez   Working Group: Individual Submissions (none)	This document describes the interfaces provided by ICANN to Registrars and Data Escrow Agents to fulfill the data escrow requirements of the Registrar Accreditation Agreement and the Registrar Data Escrow Specifications.
	IP Payload Compression excluding transport layer
	draft-ls-ipsecme-ipcomp-exclude-transport-layer-01.txt   Date: 15/04/2025   Authors: Cheng Li, Hang Shi, Meng Zhang, Xiaobo Ding   Working Group: Individual Submissions (none)	IP Payload Compression Protocol (IPComp) is used for compressing the IP payload in transmission to increase communication performance. The IPComp is applied to the payload of the IP datagram, starting with the first octet immediately after the IP header in IPv4, and the first octet after the excluded IPv6 Extension headers. However, transport layer information such as source port and destination port are useful in many network functions in transmission. This document defines extensions of IP payload compression protocol (IPComp) to support compressing the payload excluding the transport layer information, to enable network functions using transport layer information (e.g., ECMP) working together with the payload compression. This document also defines an extension of IPComp to indicate the payload is not compressed to solve the out-of-order problems between the compressed and uncompressed packets.
	Hybrid-Function-Chain (HFC) Framework
	draft-yuan-rtgwg-hfc-framework-01.txt   Date: 15/04/2025   Authors: Dongyu Yuan, Yan Zhang, Daniel Huang, Chuanyang Miao   Working Group: Individual Submissions (none)	With the maturity of cloud native application development, applications can be decomposed into finer grained atomic services. On the other hand, as a distributed computing paradigm, fine grained micro-services could be deployed and implemented in a distributive way among edges to make computing, storage and run-time processing capabilities as close to users as possible to provide satisfied QoE. Under the circumstances analyzed, a Hybrid-Function-Chain (HFC) framework is proposed in this draft, aiming to wisely allocate and schedule resources and services in order to provide consistent end- to-end service provisioning.
	A Profile for Autonomous System Relationship Authorization (ASRA)
	draft-geng-sidrops-asra-profile-01.txt   Date: 15/04/2025   Authors: Nan Geng, Kotikalapudi Sriram, Mingqing(Michael) Huang   Working Group: Individual Submissions (none)	This document defines a Cryptographic Message Syntax (CMS) protected content type for Autonomous System Relationship Authorization (ASRA) objects for use with the Resource Public Key Infrastructure (RPKI). An ASRA is a digitally signed object through which the issuer (the holder of an Autonomous System identifier), can authorize one or more other Autonomous Systems (ASes) as its customers and lateral peers. When validated, an ASRA's eContent can be used for detection and mitigation of BGP AS path manipulation attacks together with Autonomous System Provider Authorization (ASPA). ASRA is complementary to ASPA.
	Architecture for Service Flow Characteristics and Modal Mapping Based on SDN and ALTO Protocol
	draft-xsaopig-nmop-service-flow-modal-mapping-03.txt   Date: 15/04/2025   Authors: Huanxing Zhu   Working Group: Individual Submissions (none)	This Internet-Draft specifies a comprehensive framework for mapping service flow characteristics to network modal resources in multi- modal intelligent computing networks. It introduces the use of the ALTO protocol for collecting service flow data and leverages an SDN architecture to separate control and data planes. The ALTO protocol facilitates the acquisition of diverse network state information, including data from several SDN domains and dynamic network environments, directly from controllers while keeping the provider's internal details confidential. It then transmits the controller's decisions using a proven method. The document details methods for characteristic identification, intelligent mapping, and continuous optimization, enabling dynamic resource allocation and improved network performance. The framework is designed to support scalable, efficient, and secure operations in environments with complex network loads and diverse service requirements.
	Hybrid Post-Quantum Password Authenticated Key Exchange
	draft-vos-cfrg-pqpake-00.txt   Date: 15/04/2025   Authors: Jelle Vos, Stanislaw Jarecki, Christopher Wood   Working Group: Individual Submissions (none)	This document describes the CPaceOQUAKE+ protocol, a hybrid asymmetric password-authenticated key exchange (aPAKE) that supports mutual authentication in a client-server setting secure against quantum-capable attackers. CPaceOQUAKE+ is the result of a KEM-based transformation from the hybrid symmetric PAKE protocol called CPaceOQUAKE that is also described in this document. This document recommends configurations for CPaceOQUAKE+.
	Doing an Inventory of IoT devices using IDevID scanning
	draft-richardson-iotops-mud-query-00.txt   Date: 15/04/2025   Authors: Michael Richardson   Working Group: Individual Submissions (none)	This document describes a mechanism to do an inventory of devices on a network. While there are significant abuse and privacy concerns with kind of scanning, the practice of scanning networks and fingerprinting devices has been occuring since the mid 1990s. But, the adhoc methods are not reliable and do not provide any kind of strong device identity. This document takes the approach that if it will happen, it might as well be reliable and secure.
	LDP Extensions for Flex-Algo
	draft-lin-mpls-ldp-flex-algo-00.txt   Date: 15/04/2025   Authors: Changwang Lin, Yisong Liu   Working Group: Individual Submissions (none)	This document specifies extensions to LDP to support the use Flex- Algo, enabling Label Switched Paths (LSPs) to follow a specific Flex-Algo.

14/04/2025

	A YANG Data Model for Ethernet TE Topology
	draft-ietf-ccamp-eth-client-te-topo-yang-09.txt   Date: 14/04/2025   Authors: Chaode Yu, Haomian Zheng, Aihua Guo, Italo Busi, Yunbin Xu, Yang Zhao, Xufeng Liu   Working Group: Common Control and Measurement Plane (ccamp)	This document describes a YANG data model for Ethernet networks when used either as a client-layer network of an underlay transport network (e.g., an Optical Transport Network (OTN)) or as a transport network itself.
	A YANG Data Model for requesting Path Computation in an Optical Transport Network (OTN)
	draft-ietf-ccamp-otn-path-computation-yang-05.txt   Date: 14/04/2025   Authors: Italo Busi, Aihua Guo, Sergio Belotti   Working Group: Common Control and Measurement Plane (ccamp)	This document provides a mechanism to request path computation in an Optical Transport Network (OTN) by augmenting the Remote Procedure Calls (RPCs) defined in RFC YYYY. [RFC EDITOR NOTE: Please replace RFC YYYY with the RFC number of draft-ietf-teas-yang-path-computation once it has been published.
	Multiple IPv4 - IPv6 mapped IPv6 address (M46A)
	draft-matsuhira-m46a-18.txt   Date: 14/04/2025   Authors: Naoki Matsuhira   Working Group: Individual Submissions (none)	This document specifies Multiple IPv4 - IPv6 mapped IPv6 address(M46A) spefification. M46A is an IPv4-mapped IPv6 address with a plane ID. Unique allocation of plane id value enables IPv4 private address unique in IPv6 address space. This address may use IPv4 over IPv6 encapsulation and IPv4 - IPv6 translation.
	Multiple IPv4 - IPv6 address mapping encapsulation - fixed prefix (M46E-FP)
	draft-matsuhira-m46e-fp-18.txt   Date: 14/04/2025   Authors: Naoki Matsuhira   Working Group: Individual Submissions (none)	This document specifies Multiple IPv4 - IPv6 address mapping encapsulation - fixed prefix (M46E-FP) specification. M46E-FP makes backbone network to IPv6 only. And also, M46E-FP can stack many IPv4 networks, i.e. the networks using same IPv4 (private) addresses, without interdependence.
	Multiple IPv4 - IPv6 address mapping encapsulation - prefix resolution (M46E-PR)
	draft-matsuhira-m46e-pr-18.txt   Date: 14/04/2025   Authors: Naoki Matsuhira   Working Group: Individual Submissions (none)	This document specifies M46E Prefix Resolution (M46E-PR) specification. M46E-PR connect IPv4 stub networks between IPv6 backbone network. And also, M46E-PR can stack many IPv4 networks, i.e. the nwtworks using same IPv4 private addresses without interdependence.
	Multiple IPv4 - IPv6 address mapping encapsulation - prefix translator (M46E-PT)
	draft-matsuhira-m46e-pt-18.txt   Date: 14/04/2025   Authors: Naoki Matsuhira   Working Group: Individual Submissions (none)	This document specifies Multiple IPv4 - IPv6 mapping encapsulation - Prefix Translator (M46E-PT) specification. M46E-PT expand IPv4 network plane by connecting M46E-FP domain and M46E-PR domain. M46E- PT translate prefix part of M46E-FP address and M46E-PR address both are IPv6 address. M46E-PT does not translate IPv4 packet which is encapsulated, so transparency of IPv4 packet is not broken.
	Multiple IPv4 - IPv6 address mapping translator (M46T)
	draft-matsuhira-m46t-18.txt   Date: 14/04/2025   Authors: Naoki Matsuhira   Working Group: Individual Submissions (none)	This document specifies Multiple IPv4 - IPv6 address mapping Translator (M46T) specification. M46T enable access to IPv4 only host from IPv6 host. IPv4 host is identified as M46 address in IPv6 address space. The address assigned to IPv4 host may be global IPv4 address or private IPv4 address. M46T does not support access to IPv6 host from IPv4 only host.
	Multiple IPv4 address and port number - IPv6 address mapping encapsulation (M4P6E)
	draft-matsuhira-m4p6e-18.txt   Date: 14/04/2025   Authors: Naoki Matsuhira   Working Group: Individual Submissions (none)	This document specifies Multiple IPv4 address and port number - IPv6 address mapping encapulation (M4P6E) specification.
	A YANG Data Model for Client-layer Tunnel
	draft-zheng-ccamp-client-tunnel-yang-17.txt   Date: 14/04/2025   Authors: Chaode Yu, Haomian Zheng, Aihua Guo, Italo Busi, Yunbin Xu, Yang Zhao, Xufeng Liu   Working Group: Individual Submissions (none)	A transport network is a server-layer network to provide connectivity services to its client. In this draft the tunnel of client is described, with the definition of client tunnel YANG model.
	Distribution of Service Metadata in BGP-LS
	draft-ls-idr-bgp-ls-service-metadata-05.txt   Date: 14/04/2025   Authors: Cheng Li, Hang Shi, Tao He, Ran Pang, Guofeng Qian   Working Group: Individual Submissions (none)	In edge computing, a service may be deployed on multiple instances within one or more sites, called edge service. The edge service is associated with an ANYCAST address in the IP layer, and the route of it with potential service metadata will be distributed to the network. The Edge Service Metadata can be used by ingress routers to make path selections not only based on the routing cost but also the running environment of the edge services. The service route with metadata can be collected by a PCE(Path Compute Element) or an analyzer for calculating the best path to the best site/instance. This draft describes a mechanism to collect information of the service routes and related service metadata in BGP-LS.
	Selective Synchronization for RPKI to Router Protocol
	draft-geng-sidrops-rtr-selective-sync-05.txt   Date: 14/04/2025   Authors: Nan Geng, Shunwan Zhuang, Yu Fu, Mingqing(Michael) Huang   Working Group: Individual Submissions (none)	The RPKI-to-Router (RTR) protocol synchronizes all the verified RPKI data to routers. This document proposes to extend the existing RTR protocol to support selective data synchronization. Selective synchronization can avoid some unnecessary synchronizations. The router can obtain only the data that it really needs, and it does not need to save the data that are not needed.
	Structured Connection ID Carrying Metadata
	draft-shi-quic-structured-connection-id-04.txt   Date: 14/04/2025   Authors: Hang Shi, Mengyao Han   Working Group: Individual Submissions (none)	This document describes a mechanism to carry the metadata in the QUIC connection ID to communicate with the intermediary.
	Hybrid IANA Registration Policy
	draft-klensin-iana-consid-hybrid-04.txt   Date: 14/04/2025   Authors: John Klensin   Working Group: Individual Submissions (none)	The current Guidelines for Writing an IANA Considerations Section in RFCs specifies ten well-known registration policies. Since it was published in 2017, the IETF's focus for many registries has evolved away from the notion of strong IETF review and consensus toward trying to be sure names are registered to prevent conflicts. Several of the policies that were heavily used in the past appear to present too high a barrier to getting names into registries to prevent accidental reuse of the same strings. This specifies an eleventh well-known policy that avoids the implied tension, essentially combining two of the existing policies.
	BGP Flow Specification for Source Address Validation
	draft-geng-idr-flowspec-sav-05.txt   Date: 14/04/2025   Authors: Nan Geng, Dan Li, tongtian124, Mingqing(Michael) Huang   Working Group: Individual Submissions (none)	BGP FlowSpec reuses BGP route to distribute infrastructure and propagates traffic flow information with filtering actions. This document proposes some extensions to BGP FlowSpec for disseminating SAV rules.
	Client Authentication Recommendations for Encrypted DNS
	draft-jaked-cared-01.txt   Date: 14/04/2025   Authors: Tommy Jensen, Jessica Krynitsky, Jeffrey Damick, Matt Engskow, Joe Abley   Working Group: Individual Submissions (none)	Some encrypted DNS clients require anonymity from their encrypted DNS servers to prevent third parties from correlating client DNS queries with other data for surveillance or data mining purposes. However, there are cases where the client and server have a pre-existing relationship and each wants to prove its identity to the other. For example, an encrypted DNS server may only wish to accept queries from encrypted DNS clients that are managed by the same enterprise, and an encrypted DNS client may need to confirm the identity of the encrypted DNS server it is communicating with. This requires mutual authentication. This document discusses the circumstances under which client authentication is appropriate to use with encrypted DNS, the benefits and limitations of doing so, and recommends authentication mechanisms to be used when communicating with TLS-based encrypted DNS protocols.
	Neotec API Strategy and IETF Work Plan
	draft-discussion-neotec-api-strategy-00.txt   Date: 14/04/2025   Authors: Linda Dunbar, Nabeel Cocker, Chongfeng Xie   Working Group: Individual Submissions (none)	This document outlines a strategy for standardizing the Neotec (NetOps4Cloud) API through the IETF, modeled after the successful approach used in the GROW Working Group's Peering API draft. The objective is to define a vendor-neutral, cloud-provider-agnostic, and secure interface that enables real-time coordination between cloud service scaling events and dynamic network policy adjustments by network controllers.
	Options representation in SCHC YANG Data Models
	draft-toutain-schc-universal-option-01.txt   Date: 14/04/2025   Authors: Quentin Lampin, Ana Minaburo, Marco Tiloca, Laurent Toutain   Working Group: Static Context Header Compression (schc)	The idea of keeping option identifiers in SCHC Rules simplifies the interoperability and the evolution of SCHC compression, when the protocol introduces new options, that can be unknown from the current SCHC implementation. This document discuss the augmentation of the current YANG Data Model, in order to add in the Rule options identifiers used by the protocol.
	Profiles for Traffic Engineering (TE) Topology Data Model and Applicability to non-TE Use Cases
	draft-ietf-teas-te-topology-profiles-03.txt   Date: 14/04/2025   Authors: Italo Busi, Xufeng Liu, Igor Bryskin, Tarek Saad, Oscar de Dios   Working Group: Traffic Engineering Architecture and Signaling (teas)	This document describes how profiles of the Traffic Engineering (TE) Topology Model, defined in RFC8795, can be used to address applications beyond "Traffic Engineering".
	New Protocols Using TLS Must Require TLS 1.3
	draft-ietf-uta-require-tls13-12.txt   Date: 14/04/2025   Authors: Rich Salz, Nimrod Aviram   Working Group: Using TLS in Applications (uta)	TLS 1.3 use is widespread, it has had comprehensive security proofs, and it improves both security and privacy over TLS 1.2. Therefore, new protocols that use TLS must require TLS 1.3. As DTLS 1.3 is not widely available or deployed, this prescription does not pertain to DTLS (in any DTLS version); it pertains to TLS only. This document updates RFC9325 and discusses post-quantum cryptography and the security and privacy improvements over TLS 1.2 as a rationale for that update.

13/04/2025

	Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP)
	draft-ietf-lsr-isis-sr-vtn-mt-10.txt   Date: 13/04/2025   Authors: Chongfeng Xie, Chenhao Ma, Jie Dong, Zhenbin Li   Working Group: Link State Routing (lsr)	Enhanced VPNs aim to deliver VPN services with enhanced characteristics, such as guaranteed resources, latency, jitter, etc., so as to support customers requirements for connectivity services with these enhanced characteristics. Enhanced VPN requires integration between the overlay VPN connectivity and the characteristics provided by the underlay network. A Network Resource Partition (NRP) is a subset of the network resources and associated policies on each of a connected set of links in the underlay network. An NRP could be used as the underlay to support one or a group of enhanced VPN services. In some network scenarios, each NRP can be associated with a unique logical network topology. This document describes a mechanism to build the SR-based NRPs using IS-IS Multi-Topology together with other well-defined IS-IS extensions.
	Multiple Ethernet - IPv6 address mapping encapsulation - fixed prefix
	draft-matsuhira-me6e-fp-19.txt   Date: 13/04/2025   Authors: Naoki Matsuhira   Working Group: Individual Submissions (none)	This document specifies Multiple Ethernet - IPv6 address mapping encapsulation - fixed prefix (ME6E-FP) base specification. ME6E-FP makes expantion ethernet network over IPv6 backbone network with encapsuation technoogy. And also, E6ME-FP can stack multiple Ethernet networks. ME6E-FP work on own routing domain.
	Multiple Ethernet - IPv6 address mapping encapsulation - prefix resolution
	draft-matsuhira-me6e-pr-19.txt   Date: 13/04/2025   Authors: Naoki Matsuhira   Working Group: Individual Submissions (none)	This document specifies Multiple Ethernet - IPv6 address mapping encapsulation - Prefix Resolution (ME6E-PR) specification. ME6E-PR makes expantion ethernet network over IPv6 backbone network with encapsuation technoogy. And also, E6ME-PR can stack multiple Ethernet networks. ME6E-PR work on non own routing domain.
	Multi-Stage Transparent Server Load Balancing
	draft-matsuhira-mslb-18.txt   Date: 13/04/2025   Authors: Naoki Matsuhira   Working Group: Individual Submissions (none)	This document specifies Multi-Stage Transparent Server Load Balancing (MSLB) specification. MSLB makes server load balancing over Layer3 network without packet header change at client and server. MSLB makes server load balancing with any protocol and protocol with encryption such as IPsec ESP, SSL/TLS.
	Multiple Ethernet - IPv6 mapped IPv6 address (ME6A)
	draft-matsuhira-me6a-18.txt   Date: 13/04/2025   Authors: Naoki Matsuhira   Working Group: Individual Submissions (none)	This document specifies Multiple Ethernet - IPv6 mapped IPv6 address(ME6A) spefification. ME6A is an Ethernet-mapped IPv6 address with a plane ID. Unique allocation of plane id value enables duplicated MAC address unique in IPv6 address space. This address may use Ethernet over IPv6 encapsulation.
	Multi-Topology in PIM
	draft-xz-pim-flex-algo-04.txt   Date: 13/04/2025   Authors: Zheng Zhang, BenChong Xu, Stig Venaas, Zhaohui Zhang, Hooman Bidgoli   Working Group: Individual Submissions (none)	PIM usually uses the shortest path computed by routing protocols to build multicast tree. Multi-Topology Routing is a technology to enable service differentiation within an IP network. IGP Flex Algorithm provides a way to compute constraint-based paths over the network. This document defines the PIM message extensions to provide a way to build multicast tree through the specific topology and constraint-based path instead of the shortest path.
	Provider Independent Addresses Aggregation
	draft-matsuhira-pia-01.txt   Date: 13/04/2025   Authors: Naoki Matsuhira   Working Group: Individual Submissions (none)	This document proposes a discussion on whether PI address aggregation. More research, reviews, and discussions will be add in the future.
	Use of SLH-DSA in TLS 1.3
	draft-reddy-tls-slhdsa-01.txt   Date: 13/04/2025   Authors: Tirumaleswar Reddy.K, Tim Hollebeek, John Gray, Scott Fluhrer   Working Group: Individual Submissions (none)	This memo specifies how the post-quantum signature scheme SLH-DSA [FIPS205] is used for authentication in TLS 1.3.
	Intra-domain Source Address Validation (SAVNET) Architecture
	draft-ietf-savnet-intra-domain-architecture-02.txt   Date: 13/04/2025   Authors: Dan Li, Jianping Wu, Lancheng Qin, Nan Geng, Li Chen   Working Group: Source Address Validation in Intra-domain and Inter-domain Networks (savnet)	This document proposes the intra-domain SAVNET architecture, which achieves accurate source address validation (SAV) in an intra-domain network by an automatic way. Compared with uRPF-like SAV mechanisms [RFC3704] that only depend on routers' local routing information, SAVNET routers generate SAV rules by using both local routing information and SAV-specific information exchanged among routers, resulting in more accurate SAV validation in asymmetric routing scenarios. Compared with ACL-based ingress filtering [RFC2827] that entirely requires manual efforts to accommodate to network dynamics, SAVNET routers learn SAV rules automatically in a distributed way.

11/04/2025

	Kemeleon Encodings
	draft-irtf-cfrg-kemeleon-00.txt   Date: 11/04/2025   Authors: Felix Guenther, Douglas Stebila, Shannon Veitch   Working Group: Crypto Forum (cfrg)	This document specifies Kemeleon encoding algorithms for encoding ML- KEM encapsulation keys and ciphertexts as random bytestrings. Kemeleon encodings provide obfuscation of encapsulation keys and ciphertexts, relying on module LWE assumptions. This document specifies a number of variants of these encodings, with differing failure rates, output sizes, and performance profiles.
	Privacy Primer for vCon Developers
	draft-james-privacy-primer-vcon-01.txt   Date: 11/04/2025   Authors: Diana James, Thomas McCarthy-Howe   Working Group: Individual Submissions (none)	This document serves as a primer for technical professionals involved in managing personal data, including biometric information from audio and video recordings, and other sensitive information in messaging or personal communications. It outlines key concepts in data privacy and communications privacy, addressing the ethical and legal considerations surrounding the collection, processing, and disclosure of consumer data. The document covers fundamental privacy principles, defines important roles in data processing, and explains consumer rights regarding their personal information. It also discusses the scope of protected personal information, including sensitive data categories, and explores techniques like data aggregation and anonymization. While referencing existing IETF work on privacy in Internet communications, this draft extends beyond to address consumer data privacy in relation to organizations handling such data. The goal is to provide a comprehensive overview of privacy considerations, aligning with fair information practices and current regulatory frameworks, to guide professionals in implementing privacy-respecting data management practices.
	Handling inter-DC/Edge AI-related network traffic: Problem statement
	draft-aft-ai-traffic-01.txt   Date: 11/04/2025   Authors: Antoine Fressancourt, Luigi Iannone, David Lou, Dirk Trossen   Working Group: Individual Submissions (none)	The growth in terms of number of parameters of LLM models as well as the need to use or train those models with private or protected data will require service providers operating LLM-based services to cooperate to train, specialize or serve LLM-based services accross datacenters. Given their structure, the number of parameters they incorporate and the collective communication librairies they are built with, LLM training and inference (or serving) network traffic has specific characteristics. In that regard, understanding the specificities of AI-related workloads is critical to determine how to operate AI-based services in a federated setting across datacenters.

08/04/2025

	Multicast-only Fast Reroute Based on Topology Independent Loop-free Alternate (TI-LFA) Fast Reroute
	draft-ietf-pim-mofrr-tilfa-14.txt   Date: 08/04/2025   Authors: Yisong Liu, Mike McBride, Zheng Zhang, Jingrong Xie, Changwang Lin   Working Group: Protocols for IP Multicast (pim)	This document specifies the use of Topology Independent Loop-Free Alternate (TI-LFA) mechanisms with Multicast Only Fast ReRoute (MoFRR) for Protocol Independent Multicast (PIM). The TI-LFA provides fast reroute protection for unicast traffic in IP networks by precomputing backup paths that avoid potential failures. By integrating TI-LFA with MoFRR, this document extends the benefits of fast reroute mechanisms to multicast traffic, enabling enhanced resilience and minimized packet loss in multicast networks. The document outlines an optional approach to implement TI-LFA in conjunction with MoFRR for PIM, ensuring that multicast traffic is rapidly rerouted in the event of a failure.

04/04/2025

	Domain-based Message Authentication,Reporting,and Conformance (DMARC)
	draft-ietf-dmarc-dmarcbis-41.txt   Date: 04/04/2025   Authors: Todd Herr, John Levine   Working Group: Domain-based Message Authentication, Reporting & Conformance (dmarc)	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.
	Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing (SR) Policy Candidate Paths
	draft-ietf-pce-segment-routing-policy-cp-27.txt   Date: 04/04/2025   Authors: Mike Koldychev, Siva Sivabalan, Samuel Sidor, Colby Barth, Shuping Peng, Hooman Bidgoli   Working Group: Path Computation Element (pce)	A Segment Routing (SR) Policy is an ordered list of instructions, called "segments" that represent a source-routed policy. Packet flows are steered into an SR Policy on a node where it is instantiated. An SR Policy is made of one or more candidate paths. This document specifies the Path Computation Element Communication Protocol (PCEP) extension to signal candidate paths of an SR Policy. Additionally, this document updates RFC 8231 to allow delegation and setup of an SR Label Switched Path (LSP), without using the path computation request and reply messages. This document is applicable to both Segment Routing over MPLS (SR-MPLS) and Segment Routing over IPv6 (SRv6).

03/04/2025

	Applicability of Interfaces to Network Security Functions to Network-Based Security Services
	draft-ietf-i2nsf-applicability-19.txt   Date: 03/04/2025   Authors: Jaehoon Jeong, Sangwon Hyun, Tae-Jin Ahn, Sue Hares, Diego Lopez   Working Group: Interface to Network Security Functions (i2nsf)	This document describes the applicability of Interface to Network Security Functions (I2NSF) to network-based security services in Network Functions Virtualization (NFV) environments, such as firewall, deep packet inspection, or attack mitigation engines.
	Extensions to the Access Control Lists (ACLs) YANG Model
	draft-ietf-netmod-acl-extensions-17.txt   Date: 03/04/2025   Authors: Oscar de Dios, Samier Barguil, Mohamed Boucadair, Qin WU   Working Group: Network Modeling (netmod)	RFC 8519 defines a YANG data model for Access Control Lists (ACLs). This document specifies a set of extensions that fix many of the limitations of the ACL model as initially defined in RFC 8519. Specifically, it introduces augmentations to the ACL base model to enhance its functionality and applicability. The document also defines IANA-maintained modules for ICMP types and IPv6 extension headers.
	A Realization of Network Slices for 5G Networks Using Current IP/MPLS Technologies
	draft-ietf-teas-5g-ns-ip-mpls-18.txt   Date: 03/04/2025   Authors: Krzysztof Szarkowicz, Richard Roberts, Julian Lucek, Mohamed Boucadair, Luis Contreras   Working Group: Traffic Engineering Architecture and Signaling (teas)	Network slicing is a feature that was introduced by the 3rd Generation Partnership Project (3GPP) in mobile networks. Realization of 5G slicing implies requirements for all mobile domains, including the Radio Access Network (RAN), Core Network (CN), and Transport Network (TN). This document describes a Network Slice realization model for IP/MPLS networks with a focus on the Transport Network fulfilling 5G slicing connectivity service objectives. The realization model reuses many building blocks currently commonly used in service provider networks.
	TLS 1.2 is in Feature Freeze
	draft-ietf-tls-tls12-frozen-08.txt   Date: 03/04/2025   Authors: Rich Salz, Nimrod Aviram   Working Group: Transport Layer Security (tls)	Use of TLS 1.3, which fixes some known deficiencies in TLS 1.2, is growing. This document specifies that outside of urgent security fixes (as determine by TLS WG consensus), new TLS Exporter Labels, or new Application-Layer Protocol Negotiation (ALPN) Protocol IDs, no changes will be approved for TLS 1.2. This prescription does not pertain to DTLS (in any DTLS version); it pertains to TLS only.

---