Index - Month Index of IDs
All IDs - sorted by date)
| Extended Communities Derived from Route Targets | ||||||||||||||
|
This document specifies a way to derive an Extended Community from a Route Target and describes some example use cases. | |||||||||||||
| Extensible Simple Authentication and Security Layer (SASL) | ||||||||||||||
|
The Simple Authentication and Security Layer (SASL) is a framework for providing authentication and data security services in connection-oriented protocols via replaceable mechanisms. It provides a structured interface between protocols and mechanisms. The resulting framework allows new protocols to reuse existing mechanisms and allows old protocols to make use of new mechanisms. The framework also provides a protocol for securing subsequent protocol exchanges within a data security layer. This document describes how a SASL mechanism is structured, describes how protocols include support for SASL, and defines the protocol for carrying a data security layer over a connection. This document also defines how servers can request fulfillment of extra authentication related tasks, such as two factor authentication and/or password change. | |||||||||||||
| IMAP REMEMBERME extension for quick reauthentication token generation | ||||||||||||||
|
This document specifies an IMAP extension for generating quick reauthentication tokens that allow clients to re-login without user interaction, once authentication using a strong SASL mechanism is completed. | |||||||||||||
| Benchmarking Methodology for Computing-aware Traffic Steering | ||||||||||||||
|
Computing-aware traffic steering (CATS) is a traffic engineering approach for steering service requests towards appropriate service instances based on the awareness of both computing and network information. This document proposes benchmarking methodologies for CATS. | |||||||||||||
| X.509 Certificate Profile for Autonomous AI Agent Identity | ||||||||||||||
|
This document defines an X.509 certificate profile for identifying autonomous AI agents. It specifies a new X.509v3 extension, AgentIdentity, that encodes agent-specific metadata within a standard X.509 certificate, including agent trust level, operational capabilities, delegation constraints, owner attribution, and revocation control endpoints. The profile enables certificate authorities (CAs) to issue interoperable agent identity certificates that any relying party can parse, validate, and enforce, regardless of the issuing CA or the platform that provisioned the agent. The design builds on existing PKI infrastructure (RFC 5280), SPIFFE Verifiable Identity Documents (SPIFFE SVIDs), and the MCPS cryptographic signing layer (draft-sharif-mcps-secure-mcp). It does not require changes to X.509v3 certificate parsing or to existing CA issuance pipelines beyond supporting a new non-critical extension. | |||||||||||||
| Use Cases and Requirements for Computing-Aware Traffic Steering (CATS) Operations,Administration,and Maintenance (OAM) | ||||||||||||||
|
[I-D.ietf-cats-oam-fw] defines a framework for Operations, Administration, and Maintenance (OAM) in Computing-Aware Traffic Steering (CATS) networks, introducing Instance OAM and Service OAM as new components alongside traditional Link and Path OAM, and specifying high-level requirements (O-REQ, A-REQ, M-REQ) for each. As with the base CATS work, where [I-D.ietf-cats-usecases-requirements] separately catalogued problem statement, use cases, and requirements alongside [I-D.ietf-cats-framework], the OAM framework similarly benefits from a companion document grounding its requirements in concrete operator scenarios. This document fills that gap. It presents five use cases for CATS OAM -- multi-domain compute-node failure detection, SLA verification that closes the loop with metric-driven traffic- steering decisions, demarcation of network-path faults from compute-instance faults, OAM-triggered fallback steering, and multi-vendor Compute-Service Metric Agent (C-SMA) interoperability verification -- and maps each to the Link/Path/Instance/Service OAM layering and O-REQ/A-REQ/M-REQ requirement categories defined in [I-D.ietf-cats-oam-fw]. | |||||||||||||
| MoQ Feedback | ||||||||||||||
|
This document defines an extension to Media over QUIC Transport (MOQT) that enables MoQ receivers to report delivery quality information for media Objects to senders. The MoQ layer synthesizes MMF feedback and local congestion control (CC) output to compute control decisions such as bitrate, frame rate, and pacing, and inform the CC algorithm module via a cross-layer control interface. This mechanism reuses the MOQT Track/Object data model without introducing new control message types. While QUIC ACK and reception timestamp extensions continue to provide per-packet CC signals; this mechanism adds per-Object media semantic feedback when the MMF extension is negotiated and enabled. | |||||||||||||
| IMAP SASL2 Profile | ||||||||||||||
|
This document specifies an IMAP extension for SASL2 authentication, which extends IMAP SASL (RFC 4422) Profile. | |||||||||||||
| Agent Accountability: A Conformance and Verification Method | ||||||||||||||
|
An architecture for auditing agent-driven interactions (draft- kuehlewind-audit-architecture) identifies the record types an auditable agent system produces — interaction, action, delegation, and authorization-transition — and the role of an Auditor that determines whether recorded behaviour matched intent and the authorization in force. That architecture does not specify how an Auditor, or any independent party, deterministically verifies that a set of such records — produced by different parties, in different profiles, and composed into one case — is internally consistent and correctly derives an audit conclusion. This document specifies a horizontal conformance and verification methodology for composed agent-accountability records. It organizes conformance into three tiers: the payload-binding layer, per-record- type (per-slot) conformance, and composition (combination) conformance. It defines the determinism boundary between what is mechanically derivable from the binding rules and the individual records, and what is irreducibly semantic; a conformance-vector discipline (positive, negative, and must-fail cases, checked in both directions) that any record profile reuses rather than reinvents; and a deterministic method for deriving composition-conformance vectors from binding rules, individual-record vectors, a composition manifest, and a set of cross-record predicates. The methodology is profile-agnostic: it applies uniformly to any accountability record type and to any declared composition of them, whether those records are joined across parties or across attestation layers. Its lower two tiers verify a single record, so the method applies where no composition is present and strengthens as records are composed. It is intended as the composition-verification work item of the auditing architecture — the one its enumerated work items do not yet cover. | |||||||||||||
| Versioning in the Registration Data Access Protocol (RDAP) | ||||||||||||||
|
This document describes an RDAP extension for an extensible set of versioning types with the features of identifying the RDAP extension versions supported by the server, the RDAP extension versions included in an RDAP response, and enabling a client to specify the desired RDAP extension versions to include in the RDAP query and RDAP response. In addition, this document defines a mechanism for communicating versioning and deprecation information that facilitates coordinated transitions between successive extension versions while minimizing the impact of breaking changes on deployed clients. | |||||||||||||
| Improve TCP Handling of Out-of-Window Packets to Mitigate Ghost ACKs | ||||||||||||||
|
Historically, TCP as specified in RFC 793 was threatened by the blind data injection attack because of the loose SEG.ACK value validation, where the SEG.ACK value of a TCP segment is considered valid as long as it does not acknowledge data ahead of what has been sent. RFC 5961 improved the input validation by shrinking the range of acceptable SEG.ACK values in a TCP segment. Later, RFC 9293 incorporated the updates proposed by RFC 5961 as a TCP stack implementation option. However, an endpoint that follows the RFC 9293 specifications can still accept a TCP segment containing an SEG.ACK value acknowledging data that the endpoint has never sent. This document specifies small modifications to the way TCP verifies incoming TCP segments' SEG.ACK value to prevent TCP from accepting such invalid SEG.ACK values. | |||||||||||||
| IETF Network Slice Controller and its Associated Data Models | ||||||||||||||
|
This document describes an approach for structuring the IETF Network Slice Controller as well as how to use different data models being defined for IETF Network Slice Service provision (and how they are related). It is not the purpose of this document to standardize or constrain the implementation of the IETF Network Slice Controller. | |||||||||||||
| IS-IS Distributed Flooding Reduction | ||||||||||||||
|
In dense topologies (such as data center fabrics based on the Clos and butterfly though not limited to those; in fact any large topology or one with relatively high degree of connectivity qualifies here) IGP flooding mechanisms designed originally for rather sparse topologies can "overflood", or in other words generate too many identical copies of same information arriving at a given node from other devices. This normally results in longer convergence times and higher resource utilization to process and discard the superfluous copies. Flooding algorithm extensions that restrict the amount of flooding performed can be constructed and can reduce resource utilization significantly, while improving convergence performance. One such flooding modification (based on previous art) optimized for operational considerations, described further in Section 2, is described in this document. | |||||||||||||
| IPv6 Addresses for Ad Hoc Networks | ||||||||||||||
|
Ad Hoc networks present an IPv6 addressing challenge due to the undetermined neighborhood properties of their interfaces. IPv6 nodes must assign locally-unique and topology-independent IPv6 addresses when topology-oriented IPv6 address delegation services are either absent or only intermittently available. This document introduces a new IPv6 address type (termed the "Multilink Local Address (MLA)") that nodes can autonomously assign to interfaces to support Ad Hoc network operations. | |||||||||||||
| BGP Extensions to Enable BGP FlowSpec based IFIT | ||||||||||||||
|
Border Gateway Protocol (BGP) Flow Specification (FlowSpec) is an extension to BGP that supports the dissemination of traffic flow specifications and resulting actions to be taken on packets in a specified flow. In-situ Flow Information Telemetry (IFIT) denotes a family of flow-oriented on-path telemetry techniques, which can provide high-precision flow insight and real-time network issue notification. This document defines BGP extensions to distribute BGP FlowSpec based traffic filtering carrying IFIT information. Therefore, IFIT behavior can be automatically applied to the matched flow to capture real-time network dynamics. | |||||||||||||
| Secure Resource Layer (SRL) Core | ||||||||||||||
|
This document defines the Secure Resource Layer (SRL), a global trust layer that evaluates digital resources before they are accessed. SRL introduces governance, verification, and revocation mechanisms that complement existing URL, QR code, barcode, RFID, and short URL systems. SRL is designed to be deployable incrementally through resolver-based, scanner-level, reader-level, and application-level integrations, without requiring changes to existing Internet standards, browsers, operating systems, or identifier formats. This revision extends the document with implementation testing and operational validation of hybrid resource identifiers in logistics and supply-chain environments. The testing combines QR codes, barcodes, and RFID-derived identifiers under a common SRL trust framework while preserving compatibility with existing operational systems. | |||||||||||||
| TCP Provenance Identifier Option | ||||||||||||||
|
This document describes a TCP option that carries a Provenance Identifier (ProvID) to enable correlation of TCP connections when transport-layer identifiers change along the path. | |||||||||||||
| A two-party profile for MLS | ||||||||||||||
|
TODO Abstract | |||||||||||||
| Sustainability holistic API for Path Energy Evaluation (SHAPE) | ||||||||||||||
|
This document describes an API to query a network regarding its Energy Traffic Ratio and other sustainability-related metrics for a given network path. | |||||||||||||
| A Verifier-Side Acceptance Profile for Channel-Bound Agent Identity and Authorization | ||||||||||||||
|
This document defines a verifier-side acceptance profile for channel- bound Agent identity and authorization. It addresses context diversion, where cryptographically valid material is accepted for a different service, tenant, actor, task, target, delegation, or authority boundary than the verifier intended. A verifier accepts an actor only when a verified authority grant, holder-of-key proof, accepted channel instance, freshness and replay state, any required attestation result, and verifier-local policy all describe the same intended interaction. Protocol-specific wire formats and deployment choices are left to binding profiles. | |||||||||||||
| The Multilarity: Plural Intelligence Growth Without Convergence | ||||||||||||||
|
Popular and technical discourse anticipates a technological Singularity: a point at which a single self-improving intelligence recursively surpasses all others, after which the trajectory of the system is determined by that one lineage. This document describes a different inflection, termed the Multilarity: a condition in which the aggregate rate of intelligence growth becomes superhuman while the locus of intelligence remains irreducibly plural. No single agent, model, operator, or lineage holds the frontier; capability accrues in the couplings between many participants, including humans. The Multilarity is presented here not as a forecast but as a design target. A plural outcome is not the default result of many actors existing at once; apparent plurality collapses quietly into a concealed singleton unless specific substrate properties are maintained and verified. This document defines the Multilarity, distinguishes it from singleton and multipolar framings, specifies five Multilarity Conditions (MC-1 through MC-5), defines measurable indicators including the Capability Concentration Ratio (CCR) and the Multilarity Index (MI), specifies the Multilarity Attestation Record (MAR) as an interoperable evidence format, and enumerates the convergence pathologies by which plurality is lost. | |||||||||||||
| LIP-4D: An Intent Context and Authorization Dialogue Protocol for Autonomous Agents | ||||||||||||||
|
This document specifies LIP-4D, an experimental, transport- independent JSON protocol for expressing and evaluating the intent of autonomous software agents. A LIP-4D exchange binds an authenticated agent to a requested action, purpose, execution context, rationale claims, evidence, time constraints, and an evolution history. A policy enforcement component can challenge the agent for additional evidence and, after evaluation, issue a short-lived intent-bound authorization grant or deny the request. LIP-4D does not replace workload identity, cryptographic authentication, OAuth, or other authorization frameworks. It supplies a structured intent and evidence layer that can be used with those systems. The protocol deliberately excludes private model chain-of-thought and instead carries concise, reviewable claims and verifiable evidence. | |||||||||||||
| AI-MIB: A Management Information Base Extension for Artificial Intelligence Infrastructure in Telecommunications Networks | ||||||||||||||
|
The rapid proliferation of Artificial Intelligence (AI) and Graphics Processing Unit (GPU) infrastructure within telecommunications networks has exposed a fundamental gap in existing network management frameworks. The Simple Network Management Protocol (SNMP), the de facto standard for network element monitoring since RFC 1157 (1990), provides no native support for monitoring AI accelerators, GPU clusters, high-bandwidth interconnects such as NVLink and InfiniBand, or AI workload telemetry. This document proposes AI-MIB: a Management Information Base extension that defines a standardised Object Identifier (OID) tree for AI infrastructure management within the SNMP framework. AI-MIB is designed to operate alongside existing Operations Support Systems and Business Support Systems (OSS/BSS) in telecommunications environments, preserving backward compatibility with SNMPv3 while extending the framework's scope to cover GPU health, accelerator interconnect metrics, AI workload performance indicators, and energy consumption. This document also outlines two future extensions: a subscription-based streaming capability for SNMPv3 (informally designated SNMPv3+), and a schema-mapping specification for a SNMP-gNMI Translation Gateway that bridges SNMP/ MIB and gNMI/YANG data models. | |||||||||||||
| Address-specific DNS Aliases (ANAME) and Zone Transfer | ||||||||||||||
|
This document defines the ANAME DNS resource record. ANAME provides name-to-name indirection for address queries while allowing other resource record types to exist at the same owner name. It is therefore usable at a zone apex. This document also defines authoritative processing, TTL and failure behavior, DNSSEC considerations, and interoperable transport of ANAME records in full and incremental zone transfers. In particular, each ANAME-capable authoritative server resolves the transferred target independently. This avoids treating transient, synthesized address records as the portable source of zone data. | |||||||||||||
| Transaction Tokens | ||||||||||||||
|
Transaction Tokens (Txn-Tokens) are designed to maintain and propagate user identity, workload identity and authorization context throughout the Call Chain within a trusted domain during the processing of external requests (e.g. such as API calls) or requests initiated internally within the Trust Domain. Txn-Tokens ensure that this context is preserved throughout the Call Chain thereby enhancing security and consistency in complex, multi-service architectures. | |||||||||||||
| Information and Data Models for Packet Discard Reporting | ||||||||||||||
|
This document defines an Information Model and specifies a corresponding YANG data model for packet discard reporting. The Information Model provides an implementation-independent framework for classifying packet loss by its cause (e.g., errors, congestion, or policy). This classification enables operators to determine which losses are expected or intended and which are unintended, and to select appropriate mitigation actions, including automated mitigation of unintended packet loss. The YANG data model specifies an implementation of this Information Model for network elements with a focus on interface, device, and control-plane discards. | |||||||||||||
| IETF Network Slice Topology YANG Data Model | ||||||||||||||
|
An RFC 9543 network slice customer may utilize intent-based topologies to express resource reservation intentions within the provider's network. These customer-defined intent topologies allow customers to request shared resources for future connections that can be flexibly allocated and customized. Additionally, they provide an extensive level of control over underlay service paths within the network slice. This document describes a YANG data model for expressing customer intent topologies which can be used to enhance the RFC 9543 Network Slice Services in specific use cases, such as Network wholesale scenarios, where both topology and connectivity intents need to be expressed. | |||||||||||||
| Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) for Packet Optical Integration (POI) service assurance | ||||||||||||||
|
This document extends the analysis of the applicability of Abstraction and Control of TE Networks (ACTN) architecture to Packet Optical Integration (POI) to cover multi-layer service assurance scenarios. Specifically, the ACTN architecture supports service assurance through the detection and correlation of failures across the optical and packet layers, with failure handling performed through the relevant PNC. The MDSC can also request health checks for IP services across multi-domain paths for SLA conformance assessment. The PNCs may also be configured with thresholds so that alerts are reported when relevant service or network conditions exceed defined limits. It is assumed that the underlying transport optical network carries end-to-end IP services such as L2VPN or L3VPN connectivity services, with specific Service Level Agreement (SLA) requirements. Existing IETF protocols and data models are identified for each multi-layer (packet over optical) service assurance scenario with a specific focus on the MPI (Multi-Domain Service Coordinator to Provisioning Network Controllers Interface) in the ACTN architecture. | |||||||||||||
| CBOR Serialization and Determinism | ||||||||||||||
|
This document defines two CBOR serializations: "preferred-plus serialization" and "deterministic serialization." It also introduces the term "general serialization" to name the complete set of all serializations defined in RFC 8949. Together, these three form a set of serializations that cover the majority of CBOR serialization use cases. These serializations are largely compatible with those widely implemented by the CBOR community. | |||||||||||||
| YANG Data Models for fine grain Optical Transport Network | ||||||||||||||
|
This document defines YANG data models to describe the topology and tunnel information of a fine grain Optical Transport Network. The YANG data models defined in this document are designed to meet the requirements for efficient transmission of sub-1Gbit/s client signals in transport network. | |||||||||||||
| AES-CMAC for COSE | ||||||||||||||
|
The CBOR Object Signing and Encryption (COSE) specification defines structures for generating, conveying, and verifying Message Authentication Code (MAC) tags. This document registers code points for using the Advanced Encryption Standard (AES) block cipher in Cipher-based Message Authentication Code (CMAC) mode within those COSE structures. Specifically, these uses are for computing MAC tag values with no additional parameters. | |||||||||||||
| Structured Error Data for Filtered DNS | ||||||||||||||
|
DNS filtering is widely deployed for various reasons, including network security and policy enforcement. However, filtered DNS responses lack structured information for end users to understand the reason for the filtering. Existing mechanisms to provide explanatory details to end users cause harm especially if the blocked DNS response is for HTTPS resources. This document updates RFC 8914 by signaling client support for structuring the EXTRA-TEXT field of the Extended DNS Error to provide details on the DNS filtering. Such details can be parsed by the client and displayed, logged, or used for other purposes. | |||||||||||||
| AS2 Specification Modernization | ||||||||||||||
|
This document provides an applicability statement (RFC 2026, Section 3.2) describing how to securely exchange structured business data over HTTP. 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 (see Section 10.1). 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). This document obsoletes RFC 4130 and stands on its own without reference to AS1 or SMTP, except where required for IANA registry updates. This document also updates IANA registries originally created by RFC 3335 and RFC 4130. | |||||||||||||
| Using the Extensible Authentication Protocol (EAP) with Ephemeral Diffie-Hellman over COSE (EDHOC) | ||||||||||||||
|
The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides a standard mechanism for support of multiple authentication methods. This document specifies the EAP authentication method EAP- EDHOC, based on Ephemeral Diffie-Hellman Over COSE (EDHOC). EDHOC is a lightweight security handshake protocol, enabling authentication and establishment of shared secret keys suitable in constrained settings. This document also provides guidance on authentication and authorization for EAP-EDHOC. | |||||||||||||
| JMAP Mail Sharing | ||||||||||||||
|
This document specifies an extension to the JSON Meta Application Protocol (JMAP) for Mail to enable sharing of mailboxes between users. Building upon the JMAP Sharing framework defined in [RFC9670], this specification extends the Mailbox data type defined in [RFC8621] with properties necessary to configure and manage access permissions for shared mailboxes. The extension introduces a new capability that indicates server support for mailbox sharing and defines the additional properties required to share mailboxes with other principals, including the ability to control which users may access a mailbox and what permissions they possess. | |||||||||||||
| UDP-based Transport for Configured Subscriptions | ||||||||||||||
|
This document describes a UDP-based transport for YANG notifications to collect data from network nodes within a controlled environment. A shim header is defined to facilitate the data streaming directly from a publishing process on a network device to telemetry receivers. Such a design enables higher frequency updates and less performance overhead on publisher and receiver processes compared to already established notification mechanisms. A YANG data model is also defined for management of the described UDP-based transport. | |||||||||||||
| Deploying and Using Email in Deep Space | ||||||||||||||
|
This document is an assessment on the email protocols to be used in deep space and provides recommendations to deploy and use email in deep space. | |||||||||||||
| PFC PAUSE Frame Forwarded Transparently in Wide Area Networks | ||||||||||||||
|
This document describes a solution for transparent forwarding of PFC PAUSE frames in wide area networks, which does not require the nodes in wide area networks to support PFC flow control capabilities. | |||||||||||||
| Agent Metadata Synchronization Protocol | ||||||||||||||
|
The Internet of Agents (IoA) requires a robust infrastructure to manage the lifecycle, discovery, and interaction of autonomous agents across distributed network domains. While the Agent Gateway (AGW) provides a localized control point, large-scale deployments necessitate a mechanism for multiple gateways to synchronize agent metadata and routing information. This document specifies the Agent Metadata Synchronization Protocol (AMSP). AMSP facilitates the exchange of Agent Records between hierarchical gateways (Level-1 and Level-2), ensuring global reachability, efficient resource utilization, and loop-free metadata propagation. | |||||||||||||
| Trust-Governed Resource Identity and Discovery Architecture for OpenAgenet | ||||||||||||||
|
Open agent ecosystems increasingly include heterogeneous resource products: callable agents, skills, Model Context Protocol (MCP) servers, ordinary tools, and application programming interfaces. A user or orchestrator often needs to discover such resources before it can decide which interaction protocol, credential, endpoint, or artifact to use. Discovery alone is not sufficient: the relying party also needs to know which resource identity was registered, which authority accepted it, whether the accepted package is current, and whether the Discovery service is authorized to expose it. This document describes a trust-governed resource identity and discovery architecture for OpenAgenet (OAN). The architecture separates resource subjects, resource providers, Registrar Nodes, a Root Node, Discovery Nodes, content distribution, and resource consumers. It defines architectural roles, trust boundaries, resource identity expectations, Root-verified package semantics, registration and verification behavior, authorization-aware Discovery, and pre-use verification requirements. The architecture can be profiled with Decentralized Identifier (DID) document concepts and credential-based assertions. This document does not define a new DID method, media type, URI scheme, transport protocol, ranking algorithm, blockchain protocol, agent invocation protocol, or product-native schema. | |||||||||||||
| BMP Extension for Configuration Monitoring TLV | ||||||||||||||
|
This document defines two types of BMP extended TLV, which are used to carry configuration information and configuration effective time related to BGP route changes. Through this extension, the BGP monitoring platform can associate various BGP events with configuration operations, providing traceable evidence for identifying network failures caused by configuration changes. | |||||||||||||
| Maintenance of the IANA Message Header Field Registries | ||||||||||||||
|
The IANA "Message Headers" registries record, for each registered header field, the protocol it belongs to, its status, whether it is a trace field, and the document(s) that specify it. These registries were populated incrementally by many documents over more than two decades, and the metadata that reached the registries is in several respects less complete than the metadata the registering documents supplied. Most notably, the document that performed the single largest bulk registration, RFC 4021, gave IANA an explicit status and an explicit specification document for every one of the roughly ninety fields it registered, and neither was recorded: those entries carry a blank status and cite RFC 4021 itself rather than the specification. Separately, the "Trace" column added to both registries by the ongoing revision of RFC 5322 was deliberately left empty for pre-existing entries, to be filled in later. This document reviews the initial definition of, and every subsequent update to, each registered header field, and gives IANA a single, coherent set of instructions for completing and correcting each registry entry. Every recommended change, and every deliberate decision to leave a non-obvious entry unchanged, is justified by reference to the instructions already given by, or the clear intent of the authors of, the source documents in which the field was defined or modified. | |||||||||||||
| Radio Image Framing Protocol (RIFP) | ||||||||||||||
|
This document specifies the Radio Image Framing Protocol (RIFP), a compact, unidirectional object-transfer protocol intended for transmitting images over low-rate radio links. RIFP defines independently synchronized frames, a versioned and extensible binary header, fragmentation and reassembly rules, a fixed binary object descriptor, optional JSON metadata, per-frame CRC-32 protection, whole-object SHA-256 verification, and registries for future frame types, flags, header extensions, media encodings, and radio profiles. RIFP is independent of a particular frequency allocation or modulation. This document also defines an initial continuous-phase binary frequency-shift keying profile named rifp-cpfsk-4800. The profile can be used on frequencies where local regulation permits such operation; 433.92 MHz is a common deployment example but is not mandated by this specification. | |||||||||||||
| An Intent-Based Management Framework for Software-Defined Vehicles in Intelligent Transportation Systems | ||||||||||||||
|
Software-Defined Vehicle (SDV) is a new player towards autonomous vehicles in Intelligent Transportation Systems (ITS). An SDV is constructed by a software platform like a cloud-native system (e.g., Kubernetes) and has its internal network. To facilitate the easy and efficient configuration of networks in the SDV, an intent-based management is an appropriate direction. This document proposes a framework of intent-based management for networks, security, and applications in SDVs so that they can communicate with other SDVs and infrastructure nodes for safe driving and infotainment services in the road networks. | |||||||||||||
| Additional Algorithms for C509 Certificates | ||||||||||||||
|
This document registers additional algorithms in the IANA registries defined by [I-D.ietf-cose-cbor-encoded-cert]. It extends the base C509 certificate specification with post-quantum cryptography (PQC) signature and key-encapsulation algorithms including ML-DSA, ML-KEM, stateful hash-based algorithms (HSS/LMS, XMSS, XMSS^MT), and composite algorithms. | |||||||||||||
| SCHC Compression of VOICI Headers | ||||||||||||||
|
This document describes how to compress VOICI headers using SCHC rules at a lower stratum, demonstrating that VOICI provides explicit routing metadata that is transparently compressed to minimal on-wire size while preserving standardized dispatch semantics. It is intended as a reference for implementers deploying VOICI in SCHC- based networks and does not modify the VOICI specification itself. | |||||||||||||
| Discovery and Device Lifecycle for OAuth Push-Based Authentication | ||||||||||||||
|
This document defines a discovery, registration, attestation, and device-lifecycle layer for out-of-band OAuth 2.0 authenticator devices, allowing a single spec-compliant authenticator application to register with, and receive push-based wake signals from, any conforming Authorization Server, without requiring the Authorization Server operator to build and distribute its own dedicated mobile application. This document is intentionally agnostic to which back- channel authentication protocol ultimately consumes it; OpenID Connect Client-Initiated Backchannel Authentication (CIBA) Core is its first binding, defined in a separate companion document, but nothing in this document depends on CIBA or on OpenID Connect. | |||||||||||||
| CIBA Binding for OAuth Push-Based Authentication Device Discovery | ||||||||||||||
|
A companion specification, "Discovery and Device Lifecycle for OAuth Push-Based Authentication", defines a generic, back-channel-protocol- agnostic device registration, attestation, and lifecycle layer for out-of-band OAuth 2.0 authenticator devices. This document is the thin binding that lets a device registered under that specification be woken by OpenID Connect Client-Initiated Backchannel Authentication (CIBA) Core's authorization endpoint: one request parameter, one additive error code, and a statement of how CIBA's existing binding_message composes with the base document's interaction-type ceremony. This document adds no new endpoints and no new discovery fields of its own. | |||||||||||||
| Authenticated DNS Resolution (ADR) for Enterprise DNS | ||||||||||||||
|
This document defines Authenticated DNS Resolution (ADR), an enterprise query-plane model that augments DNS resolution with per- query identity, role-based authorization, and audit. ADR preserves DNSSEC and public Internet DNS behavior while enabling enterprises to publish comprehensive internal naming without exposing sensitive topology. ADR leverages existing enterprise authentication and identity systems to authorize and audit DNS queries without defining a new authentication protocol. | |||||||||||||
| A Profile for Autonomous System Provider Authorization | ||||||||||||||
|
This document defines a Cryptographic Message Syntax (CMS) protected content type for Autonomous System Provider Authorization (ASPA) objects for use with the Resource Public Key Infrastructure (RPKI). An ASPA 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 transit providers. When validated, an ASPA's eContent can be used for detection and mitigation of route leaks. | |||||||||||||
| Segment Routing IPv6 Security Considerations | ||||||||||||||
|
SRv6 is a traffic engineering, encapsulation and steering mechanism utilizing IPv6 addresses to identify segments in a pre-defined policy. This document discusses security considerations in SRv6 networks, including the potential threats and the possible mitigation methods. The document does not define any new security protocols or extensions to existing protocols. | |||||||||||||
| SLH-DSA for JOSE and COSE | ||||||||||||||
|
Digital signatures are used within JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) to protect the integrity and authenticity of messages, such as JSON Web Signatures and signed COSE structures. This document specifies JOSE and COSE serializations for the Stateless Hash-Based Digital Signature Standard (SLH-DSA), a Post-Quantum Cryptography (PQC) digital signature scheme defined in US NIST FIPS 205. The conventions for the associated algorithm identifiers, signatures, public keys, and private keys are also specified. | |||||||||||||
| Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification | ||||||||||||||
|
This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 4.0. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 5751. | |||||||||||||
| OAuth Proof of Possession Tokens with HTTP Message Signatures | ||||||||||||||
|
This extension to the OAuth 2.0 authorization framework defines a method for using HTTP Message Signatures to bind access tokens to keys held by OAuth 2.0 clients. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Web Authorization Protocol Working Group mailing list ([email protected]), which is archived at https://mailarchive.ietf.org/arch/browse/oauth/. Source for this draft and an issue tracker can be found at https://github.com/jricher/draft-richer-oauth-httpsig. | |||||||||||||
| Secure Asset Transfer Protocol (SATP) Gateway Crash Recovery Mechanism | ||||||||||||||
|
This memo describes the crash recovery mechanism for the Secure Asset Transfer Protocol (SATP). The goal of this draft is to specify the message flow that implements a crash recovery mechanism, composed of self-healing and rollback sub-protocols. The mechanism assures that gateways running SATP are able to recover faults, enforcing ACID properties for asset transfers across ledgers (i.e., double spend does not occur). | |||||||||||||
| The AI Discovery Endpoint: A Structured Mechanism for AI Agent Service Discovery and Capability Exposure | ||||||||||||||
|
This document defines a lightweight mechanism by which web services expose a machine-readable description of their capabilities to autonomous AI agents. The mechanism consists of a well-known resource, served at "/.well-known/ai", that returns a structured JSON document describing the service's identity, available actions, authentication requirements, and operational hints optimized for large language model (LLM) token efficiency. The specification addresses the absence of a standardized method for AI agents to programmatically discover what a web service can do and how to invoke its capabilities, without resorting to parsing human- oriented documentation or HTML content. | |||||||||||||
| HTTP Signaling of Planned IPv4 Unavailability | ||||||||||||||
|
As operators transition services to IPv6-only, planned IPv4 outages help identify remaining dependencies before permanent decommission. Such outages must be measurable, reversible, and understandable to end users. This document defines HTTP signaling for an intentional, often time-bounded IPv4 outage: the existing 503 Service Unavailable status code together with the mandatory Retry-Over-IPv6 response header field (and optional related fields) that instruct aware clients to retry over IPv6 after closing the IPv4 connection, and allow clients to confirm successful IPv6 recovery via an optional correlation token so operators can distinguish soft failures from hard failures in centralized logs. Machine-readable response bodies MAY use Problem Details (RFC 9457) with a registered problem type URI. The mechanism supports staged enterprise rollouts, internal HTTP services, and permanent IPv6-only migration; coordinated public events (for example, 6/6 drills) remain possible with advance notice. The primary intended deployment is operator-controlled environments where provider and users share operational responsibility. Legacy clients that do not implement this specification treat the response as ordinary service unavailability and MAY use the response body for human-readable guidance. | |||||||||||||
| Internet Agent Communication Protocol | ||||||||||||||
|
Ever since 1969 and the ARPANET, the internet has repeatedly been faced with challenges that it has had to overcome—and has overcome. Year after year, the number of users has grown, and year after year, the complexity and range of ways in which the internet can be used have expanded. With the advent of AI, we not only have a new type of user, we have a different form of communication; the internet itself is being attributed a completely different significance. If they are not already, AIs will make up the majority of internet users in the foreseeable future. The question of an ‘AgentNet,’ is not merely a question concerning the internet; it is a question of how AIs will interact within a global network in the future. | |||||||||||||
| Portable Revocation Statements for Action-Bound Authorization Artifacts | ||||||||||||||
|
Signed authorization artifacts for agent actions (receipts, commits, delegations) are being defined faster than the means to retract them. Many deployed systems use live status services, revocation lists, or issuer datastores. This document defines a complementary portable form for action-bound authorization artifacts: a signed, offline- verifiable claim that a named logical target, addressed by identifier and action commitment, is revoked. Verification is fail-closed and evaluates a fixed set of checks: version, closed object structure, target binding, a revoker key pinned by the verifier and, for newly emitted artifacts, bound to a full digest-derived key identifier (a self-asserted key confers nothing), the presence of a strict revocation instant that has taken effect by the verifier's decision time, and an independently recomputed signature. The statement proves that a named, pinned revoker revoked this specific target. It does not prove that every relying party saw it, and offline verification cannot prove the absence of a revocation that was not presented. A terminal revocation never ages out; current non- revocation requires separate authenticated, policy-fresh status evidence. A Trust Program profile binds revocation to the complete execution claim, and requires revocation-versus-claim to be resolved atomically; a revocation learned after a claim never rewrites an effect that may already have occurred. | |||||||||||||
| Network Management and OAM Considerations for IP in Deep Space | ||||||||||||||
|
[I-D.ietf-tiptop-usecase] and [I-D.ietf-tiptop-ip-architecture] describe key characteristics, use cases, requirements, and an IP architecture for deep-space (lunar, Mars, and beyond) surface and orbital-relay networking, characterized by long, variable, asymmetric propagation delay (single-digit to tens of minutes one-way), scheduled/intermittent connectivity windows, and severely constrained link capacity. Section 8.2 of [I-D.ietf-tiptop-ip-architecture] addresses the configuration- management plane for this environment (NETCONF, RESTCONF, and SNMP transport selection and RTT-adjusted client timeouts), but neither document addresses the fault and performance dimensions of Operations, Administration, and Maintenance (OAM): fault detection, performance measurement, and reachability verification. This document identifies why conventional terrestrial OAM techniques (active round-trip probing such as ICMP Echo, BFD, or TWAMP; assumption of continuous connectivity) do not transfer directly to this environment, and proposes candidate adapted approaches -- passive, store-and-forward telemetry batched to contact windows; on-board local health self-diagnosis with delayed reporting; and confidence-interval-based reachability assessment in place of binary up/down status -- as a starting point for OAM discussion within the TIPTOP working group. This document explicitly does not propose use of the Bundle Protocol or DTN architecture, both of which are out of scope for TIPTOP per its charter; where CCSDS space-data-system telemetry conventions are mentioned, it is as informative background only. | |||||||||||||
| Portable Agent Qualification Statements for Consequential Actions | ||||||||||||||
|
Agent evaluations report what happened in a test environment. They do not, by themselves, establish that a measured candidate satisfies a relying party's policy, remains current, matches the runtime candidate, or is authorized to perform a consequential action. This document defines a portable Qualification Statement that binds a candidate, complete evaluation campaign, qualification policy, assignment, and status. It preserves three separate claims: observation, qualification, and authorization. A relying party can accept a current qualification as evidence at runtime, but MUST make a separate exact-action authorization and admission decision. | |||||||||||||
| Internet Agent Communication Protocol - A2ACOM | ||||||||||||||
|
Ever since 1969 and the ARPANET, the internet has repeatedly been faced with challenges that it has had to overcome—and has overcome. Year after year, the number of users has grown, and year after year, the complexity and range of ways in which the internet can be used have expanded. With the advent of AI, we not only have a new type of user, we have a different form of communication; the internet itself is being attributed a completely different significance. If they are not already, AIs will make up the majority of internet users in the foreseeable future. The question of an ‘AgentNet,’ is not merely a question concerning the internet; it is a question of how AIs will interact within a global network in the future. | |||||||||||||
| Internet Agent Communication Protocol - DHI - ERP | ||||||||||||||
|
Ever since 1969 and the ARPANET, the internet has repeatedly been faced with challenges that it has had to overcome—and has overcome. Year after year, the number of users has grown, and year after year, the complexity and range of ways in which the internet can be used have expanded. With the advent of AI, we not only have a new type of user, we have a different form of communication; the internet itself is being attributed a completely different significance. If they are not already, AIs will make up the majority of internet users in the foreseeable future. The question of an ‘AgentNet,’ is not merely a question concerning the internet; it is a question of how AIs will interact within a global network in the future. | |||||||||||||
| Internet Agent Communication Protocol - DHT | ||||||||||||||
|
Ever since 1969 and the ARPANET, the internet has repeatedly been faced with challenges that it has had to overcome—and has overcome. Year after year, the number of users has grown, and year after year, the complexity and range of ways in which the internet can be used have expanded. With the advent of AI, we not only have a new type of user, we have a different form of communication; the internet itself is being attributed a completely different significance. If they are not already, AIs will make up the majority of internet users in the foreseeable future. The question of an ‘AgentNet,’ is not merely a question concerning the internet; it is a question of how AIs will interact within a global network in the future. | |||||||||||||
| Internet Agent Communication Protocol - ECONOMY | ||||||||||||||
|
Ever since 1969 and the ARPANET, the internet has repeatedly been faced with challenges that it has had to overcome—and has overcome. Year after year, the number of users has grown, and year after year, the complexity and range of ways in which the internet can be used have expanded. With the advent of AI, we not only have a new type of user, we have a different form of communication; the internet itself is being attributed a completely different significance. If they are not already, AIs will make up the majority of internet users in the foreseeable future. The question of an ‘AgentNet,’ is not merely a question concerning the internet; it is a question of how AIs will interact within a global network in the future. | |||||||||||||
| Internet Agent Communication Protocol - EID | ||||||||||||||
|
Ever since 1969 and the ARPANET, the internet has repeatedly been faced with challenges that it has had to overcome—and has overcome. Year after year, the number of users has grown, and year after year, the complexity and range of ways in which the internet can be used have expanded. With the advent of AI, we not only have a new type of user, we have a different form of communication; the internet itself is being attributed a completely different significance. If they are not already, AIs will make up the majority of internet users in the foreseeable future. The question of an ‘AgentNet,’ is not merely a question concerning the internet; it is a question of how AIs will interact within a global network in the future. | |||||||||||||
| The evidence.* Family: Post-Hoc,Independently Recomputable Evidence Records for AI Agent Actions | ||||||||||||||
|
Autonomous agents act through tool invocations whose consequences outlive the sessions that produce them. Pre-action constraint families gate whether an agent may act: environment.* attests boolean world-state, and verification.* attests calibrated confidence over factual claims. No sibling family records, under equivalent verification discipline, what the agent then did. This document defines the evidence.* family: append-only, hash-chained, signature- bound evidence records of agent actions, designed so that a third party can recompute every verdict from signed primitives and a published key, without trusting the operator's runtime. It defines the family's membership criterion (independent recomputability with fail-closed verification), the family-wide record vocabulary and canonicalization discipline, a tri-state verification protocol (VALID, INVALID, UNVERIFIABLE), composition with the pre-action sibling families, and the conformance-vector discipline under which independent implementations demonstrate byte-level agreement. One reference record type, evidence.action, is specified together with its frozen conformance corpus. This document deliberately states what an evidence record does not prove. | |||||||||||||
| Internet Agent Communication Protocol - INTEROP | ||||||||||||||
|
Ever since 1969 and the ARPANET, the internet has repeatedly been faced with challenges that it has had to overcome—and has overcome. Year after year, the number of users has grown, and year after year, the complexity and range of ways in which the internet can be used have expanded. With the advent of AI, we not only have a new type of user, we have a different form of communication; the internet itself is being attributed a completely different significance. If they are not already, AIs will make up the majority of internet users in the foreseeable future. The question of an ‘AgentNet,’ is not merely a question concerning the internet; it is a question of how AIs will interact within a global network in the future. | |||||||||||||
| VOICI | ||||||||||||||
|
The Static Context Header Compression (SCHC) framework identified the need for a minimal transport encapsulation that provides Session multiplexing when extrinsic Discriminators are insufficient. This document specifies a Link Multiplexer (VOICI) that addresses those SCHC-driven requirements while remaining general enough to accommodate other compression mechanisms and uncompressed payloads. The encapsulation is designed for minimal overhead, reducing to 1 byte in the common case (7 inline Session IDs), while supporting optional integrity protection and original EtherType/port recovery. | |||||||||||||
| BGP Extended Communities for SR Policy Performance Metrics | ||||||||||||||
|
Traffic scheduling and optimization have become routine network operation and maintenance tasks for operators. The operators need to select a path that can meet the Qality of Service (QoS) reqiurements of the traffic to be scheduled. This document defines four BGP extended communities for Segment Routing (SR) candidate path performance metric: the Available Bandwidth Extended Community, the Unidirectional Delay Extended Community, the Unidirectional Delay Variation Extended Community and the Unidirectional Loss Extended Community, which carry SR Policy candidate path performance parameters for the operators to select a preferred path for traffic scheduling and optimization. It also specifies the format and processing rules for these extended community types. | |||||||||||||
| Pingback Permitted From (PPF) | ||||||||||||||
|
Pingback Permitted From (PPF) defines a DNS-based mechanism for authorizing senders of linkback requests. A domain owner publishes a TXT record declaring which hosts are permitted to send linkbacks for source URIs on that domain. Receivers and linkback proxies can then reject unauthorized linkbacks before fetching the claimed source URI. PPF is intended for linkback protocols in which a sender claims that one web resource links to another and the receiver would otherwise fetch the claimed source resource to verify that claim. PPF provides sender authorization; it does not replace content verification, moderation, or abuse filtering. | |||||||||||||
| Outcome Binding for Authorized Actions and Independently Observed Effects | ||||||||||||||
|
Authorization proves what action was permitted; it does not prove what happened after execution. An executor-signed result improves attribution but remains a claim by the party that acted. This document specifies a source-routed Outcome Binding profile. Signed predicted effects identify the source role and source class required to evaluate each predicate. Executors, systems of record, and independent observers sign closed observation objects bound to the same authorization, action digest, Canonical Action Identifier, consumption nonce, operation, facility, and observation window. A deterministic verifier separates evidence availability from comparison: missing or unauthenticated required sources yield an indeterminate lifecycle state; authentic observations yield the closed comparison result in_bounds, divergent, or incomparable. The profile improves consequence reconciliation without claiming physical truth, sensor correctness, or legal finality. | |||||||||||||
| Protocol-Specific Profiles for JSContact | ||||||||||||||
|
This document defines JSContact profiles, an IANA registry for named subsets of JSContact elements. It aims to facilitate using JSContact in context of contact data exchange protocols or other use cases, in which supporting all JSContact semantics might be inappropriate. | |||||||||||||
| Automatic Configuration of Email,Calendar,and Contact Server Settings | ||||||||||||||
|
This document specifies an automatic configuration mechanism for email, calendar, and contact user agent applications. Service providers publish standardized configuration information that user agent applications retrieve and use to simplify server setup procedures. | |||||||||||||
| LSP Ping/Traceroute for Enabled In-situ OAM Capabilities | ||||||||||||||
|
This document describes the application of the mechanism of discovering In-situ OAM (IOAM) capabilities, described in RFC 9359 "Echo Request/Reply for Enabled In Situ OAM (IOAM) Capabilities", in MPLS networks. The MPLS Node IOAM Information Query functionality uses the MPLS echo request/reply messages, allowing the IOAM encapsulating node to discover the enabled IOAM capabilities of each IOAM transit and IOAM decapsulating node. | |||||||||||||
| All PEs as DF | ||||||||||||||
|
The Designated Forwarder concept is leveraged to prevent looping of BUM traffic into a tenant network sourced across an NVO fabric for multihoming deployments. [RFC7432] defines a preliminary approach to select the DF for an ES, VLAN or ES, VLAN Group, spanning multiple NVEs. [RFC8584] makes the election logic more robust and fine grained by inculcating fair election of DF, handling most of the prevalent use cases. This document presents a deployment problem and a corresponding solution which cannot be easily resolved by rules mentioned in [RFC7432] and [RFC8584]. It involves redundant firewall deployment on disparate overlay sites connected over WAN. The requirement is to allow reachability, ONLY, to the local firewall, unless there is an outage. In case of outage the reachability can be extended to the remote site's firewall over WAN. | |||||||||||||
| Secure IP Binding Synchronization via BGP EVPN | ||||||||||||||
|
The distribution of clients of L2 domain across extended networks leveraging overlay fabric needs to deal with synchronizing the Client Binding Database. The 'Client IP Binding' indicates the IP, MAC and VLAN details of the clients that are learnt by security protocols. Since learning the 'Client IP Binding database' is a last mile solution, this information stays local to the end point switch to which clients are connected. When networks are extended across geographies, both at layer 2 and layer 3, the 'Client IP Binding Database' in end point switches of remote fabrics should be in sync. This document aligns the synchronization of the 'Client IP Binding Database' through an extension to BGP control plane constructs, as BGP is a typical control plane protocol configured to communicate across network boundaries. | |||||||||||||
| A Concise Binary Object Representation (CBOR) of DNS Messages | ||||||||||||||
|
This document specifies a compact data format of DNS messages using the Concise Binary Object Representation [RFC8949]. The primary purpose is to keep DNS messages small in constrained networks. | |||||||||||||
| IOAM network awareness for Low Latency,Low Loss,and Scalable Throughput (L4S) | ||||||||||||||
|
This document specifies a framework that uses operational and telemetry information collected by In Situ Operations, Administration, and Maintenance (IOAM) to support the monitoring and parameter adjustment of an L4S Dual-Queue Coupled AQM within a single limited domain. IOAM Direct Export reports path and node information, such as hop-by-hop delay and queue depth, to an IOAM Control Center (IOAM-C). The IOAM-C correlates this information and may adjust operator-configurable AQM target or threshold parameters within configured bounds. This document does not modify the L4S ECN protocol, the IOAM data formats, or the packet forwarding behavior defined by the referenced specifications. | |||||||||||||
| The Collaboration Content Transfer (TCT) Protocol | ||||||||||||||
|
This document specifies the Collaboration Content Transfer (TCT) Protocol, an experimental HTTP profile for efficient delivery of publisher-selected web content to automated clients. TCT defines a deterministic JSON representation at a machine-facing URL, bidirectional discovery between human-facing and machine-facing resources, JSON sitemaps containing representation-validator hints, and conditional request behavior using ordinary strong ETags. TCT preserves standard HTTP validator scope: an M-URL ETag identifies the exact selected M-URL representation. Optional Semantic Validators can correlate the logical state of human-facing and machine-facing representations, but are not required by TCT and do not replace ordinary cache validators. TCT does not define authorization, licensing, content-use policy, or mutation semantics. | |||||||||||||
| HTTP Profile for Conditional Updates to Shared Resource State (Agentic State Transfer) | ||||||||||||||
|
HTTP applications frequently expose one logical object through several representations or resources. Ordinary HTTP entity tags identify selected representations; they do not, by themselves, provide a conditional-update mechanism spanning different request targets. This document specifies Agentic State Transfer (AST), an HTTP profile for preventing lost updates to shared application state. AST Core requires a client to mutate the State-Bearing Resource using the strong ETag of its State-Bearing Representation and the standard If- Match field. AST Semantic uses Semantic-ETag and If-Semantic-Match when a protected mutation targets a different resource or representation in the same concurrency domain. The profile also defines state discovery, atomic compare-and-commit behavior, conflict handling, deferred processing, caching constraints, and security requirements. | |||||||||||||
| Semantic Validators for HTTP | ||||||||||||||
|
This document defines the Semantic-ETag HTTP response field and the If-Semantic-Match HTTP request field. Unlike the standard ETag field, which identifies a selected representation, Semantic-ETag identifies a server-defined semantic state within an explicitly scoped semantic equivalence domain. If-Semantic-Match enables origin servers to perform representation-independent optimistic concurrency control when different HTTP resources or representations expose the same logical state. This document does not update or replace the semantics of ETag, If- Match, or HTTP cache validation defined by RFC 9110. | |||||||||||||
| SDLP RFC 1: DigitalID Specification | ||||||||||||||
|
This document defines the DigitalID specification for the Secured Digital Lifecycle Protocol (SDLP). The DigitalID is the foundational identity construct for all SDLP-governed objects, providing deterministic uniqueness, lineage preservation, collision elimination, and stable identity bindings across all compliant implementations. This document updates and formalizes the DigitalID structure, canonical encoding rules, lineage grammar, identity assignment requirements, collision model, and validation rules originally introduced in draft-norton-sdlp-identity-00. | |||||||||||||
| Sketch-INT Co-Design for Accurate Network Measurement: Applicability to Time-Variant Non-Terrestrial Networks | ||||||||||||||
|
Network measurement supports management applications that need statistics about both large and small flows. Sketch-based techniques use compact data structures and are effective for large flows, but hash collisions can produce substantial relative errors for small flows. In-band Network Telemetry (INT) can provide detailed observations for individual packets, but applying it to every packet can consume significant packet, bandwidth, and collector resources. This document describes a framework that uses sketches for large flows and INT for small flows. It also describes measurement-point selection when exact routing information is unavailable and congestion-aware collection of sketch and INT reports. The document identifies the information needed to describe and compare implementations. It does not define a new packet format, INT instruction, sketch algorithm, or routing protocol. As a concrete applicability direction, the document considers time- variant non-terrestrial networks (NTNs), in which paths and available forwarding resources can change over time. It maps the existing Sketch-INT framework to this scenario and identifies the assumptions that require validation. It does not claim that the existing terrestrial implementation has been deployed or evaluated on satellite hardware. | |||||||||||||
| An HMAC Authentication Extension for the Virtual Router Redundancy Protocol (VRRP) | ||||||||||||||
|
VRRP relies on a hop limit of 255 to prove that an advertisement came from the local link. That guard cannot apply when advertisements travel as multi-hop unicast across a routed or overlay network, as is common in cloud deployments, leaving the protocol open to off-segment injection and replay. The legacy VRRPv2 authentication types do not close this gap and were removed from later VRRP specifications. This document defines an authentication extension that appends an HMAC- SHA256 trailer and a time-based sequence number to VRRPv3 advertisements, authenticating the sender as a holder of the group key, protecting message integrity and bounding replay, for both IP address families. The extension is the primary defense where the hop-limit check cannot apply, and defense in depth for multicast and single-hop unicast, where that check remains in force. | |||||||||||||
| IOAM Trace-Type Extensions for Path bandwidth | ||||||||||||||
|
Traffic scheduling and optimization have become routine network operation and maintenance tasks for operators. The operators need to select a path that can accommodate the capacity of the traffic to be scheduled. In situ Operations, Administration, and Maintenance (IOAM) is used for recording and collecting operational and telemetry information. This document defines two bit flags within IOAM Trace- Type for carrying bandwidth information. | |||||||||||||
| Scoped Sync for EVPN First-Hop-Security DHCP Snoop Routes | ||||||||||||||
|
[I-D.ietf-bess-evpn-first-hop-security] defines a new EVPN Route Type, the DHCP Snoop Route (DSR), to synchronize DHCP snoop MAC/IP bindings across EVPN Provider Edge (PE) devices so that First Hop Security (FHS) functions such as Dynamic ARP Inspection, Neighbor Discovery Inspection, and IPv4/IPv6 Source Guard continue to operate correctly across EVPN multihoming and host mobility events. As specified, a DSR is distributed to every PE participating in the EVPN Broadcast Domain (BD) in which it was learned. In deployments where a single EVPN BD spans many geographically or administratively distinct fabrics interconnected over a WAN, this "flood to the whole BD" behavior distributes client IP/MAC binding information -- and therefore knowledge of which hosts exist behind which access switches -- well beyond the set of fabrics that actually need it for FHS purposes. This document defines a Sync-Scope Extended Community that an originating PE MAY attach to a DSR to restrict its distribution to an explicitly identified subset of participating fabrics, and specifies the associated PE processing rules. | |||||||||||||
| Power Consumption Profiling for Programmable Network Devices | ||||||||||||||
|
A programmable network device can execute different packet-processing programs on the same hardware. Device-level power measurements show the total input power but do not explain the power associated with a program's parser, match-action tables, and stateful or stateless actions. Models designed for fixed-function switches do not directly describe these program-dependent operations. This document describes a power profiling methodology for programmable network devices. The methodology decomposes packet processing into functional components, uses controlled calibration programs to derive target-specific parameters, and estimates the power of a data-plane program from its processing features and traffic. It also specifies validation and reporting requirements that distinguish direct measurements from model-derived estimates. The methodology is based on implementation experience with an ASIC programmable switch and an FPGA-based programmable switch. | |||||||||||||
| The Case for an IETF Working Group on Large Language Model Security and Interoperability | ||||||||||||||
|
Large Language Models (LLMs) are now accessed as network services by a large and growing number of applications, yet the way they are invoked, secured, described, and attributed has coalesced around vendor-specific and de facto interfaces rather than open, neutral standards. The most consequential gap is in security: there is no common, analyzable model for authenticating to an LLM service, authorizing tool invocation, protecting and attributing output, or reasoning about the trust boundary an LLM sits on. These models also sit directly on top of network storage: LLM training data, model checkpoints, and retrieval corpora are routinely served from NFSv4 and pNFS, so the security, provenance, and access-control questions raised here have concrete NFSv4-facing consequences. This document argues that uniting the multitude of competing LLMs behind a common, secure, interoperable interface is fundamentally the kind of problem the IETF exists to solve, and it makes the case for chartering a new IETF Working Group. It sets out the problem with security as the central motivation, describes the interaction with NFSv4 and network storage, records the initial expressions of interest that any such effort must be able to show, proposes a candidate scope with concrete deliverables and explicit non-goals, addresses the principal objections, and describes the intended path to chartering through a Dispatch presentation or a Birds-of-a-Feather (BOF) session. This document is Informational and defines no protocol. | |||||||||||||
| SCIM Agent Governance Extension | ||||||||||||||
|
The System for Cross-domain Identity Management (SCIM) Agent resource type defined in draft-wzdk-scim-agent-resource provides a minimal, platform-neutral schema for representing AI agent identities. Enterprise deployments additionally require governance metadata for provisioned agents: a lifecycle state model richer than a boolean, an autonomy classification, an operational validity window, and a reference to credential discovery information. This document defines an optional extension schema for the SCIM Agent resource type carrying this governance metadata. The lifecycle state value set is grounded in the identity information lifecycle of ISO/ IEC 24760-1, with one agent-specific addition. Attributes that belong to the authorization, credential-management, or real-time signaling layers are explicitly out of scope and are enumerated with pointers to the appropriate mechanisms. | |||||||||||||
| Aether: A Next-Generation L4 Transport | ||||||||||||||
|
This document specifies Aether, a transport-layer protocol (L4) designed for modern network environments requiring multiplexed streams without head-of-line blocking, mandatory encryption with post-quantum resistance, multi-path routing, and self-sovereign identity at the protocol layer. Aether operates entirely in userspace without kernel modifications. | |||||||||||||
| Bulk Subtree Consistency Proofs for Merkle Tree Certificates | ||||||||||||||
|
Merkle Tree Certificates require relying parties to periodically obtain a set of active landmark subtrees and verify each is consistent with a reference checkpoint of the issuance log. As specified, this requires one subtree consistency proof per landmark subtree, and those proofs share a large fraction of their interior nodes. This document defines a bulk subtree consistency proof, which verifies an entire set of landmark subtrees against a single reference checkpoint from one shared set of hashes. It is a size optimization for the relying party update channel and introduces no change to certificate verification or to the security properties of Merkle Tree Certificates. This revision replaces the construction published in -00, which was incorrect. See Appendix "Changes from -00". | |||||||||||||
| IDL: A Semantic Information Model for Agent Communication | ||||||||||||||
|
This document defines the information model for IDL (Intent Description Language), a protocol-independent semantic model for communication among autonomous AI agents and between agents and tools. Autonomous agents are fundamentally different. An agent possesses its own reasoning, may negotiate parameters, may refuse or modify requests, and may initiate interactions on its own behalf. Describing an agent as if it were a deterministic endpoint loses exactly the properties that make it an agent. IDL answers: "what can this autonomous participant contribute to an intent, under what constraints, and through what interaction patterns?" IDL is not a transport, session, discovery, or messaging protocol. It is a semantic model that enables heterogeneous agents to describe identity, capabilities, autonomy boundaries, context requirements, governance interfaces, and intent participation before and during collaboration. This document defines the IDL information model and its relationship to agent communication protocols and governance frameworks. It does not define a normative JSON representation or a serialization-level conformance language. Protocol-specific mappings, including an AIN/ CDL profile, are informative. | |||||||||||||
| The 'pay' URI Scheme for Rail-Neutral Payment Aliases | ||||||||||||||
|
This document defines the "pay" Uniform Resource Identifier (URI) scheme, a rail-neutral, human- and agent-friendly name for a payment payee that resolves, through a resolution protocol, to one or more concrete payment endpoints. Unlike a URI that names a specific account on a specific payment method, a "pay" URI names a payee independently of any settlement rail; a resolver deterministically maps the name to the rail(s), endpoint(s), and metadata a payer needs to construct a payment. This document specifies the scheme syntax and semantics, the resolution mechanism and its discovery, the deterministic resolution property, and requests provisional registration of the scheme with IANA per RFC 7595. It does not define a settlement protocol and takes no custody of funds; it composes with agent-payment protocols such as x402 for the actual money movement. | |||||||||||||
| Hardware-Rooted Attestation Tokens for Electricity Generation | ||||||||||||||
|
This document specifies an attestation token format and verification protocol for hardware-rooted measurements of electricity generation. The protocol enables a tamper-evident chain of custody from the secure element at a metering device to a publicly verifiable settlement layer, using ECDSA P-256 signatures generated inside a certified secure element and carried in a COSE_Sign1 structure. It defines: (a) the CBOR-encoded attestation token, aligned with the Entity Attestation Token format of RFC 9711 and the Remote ATtestation procedureS (RATS) architecture of RFC 9334; (b) a Merkle- aggregation and on-chain commitment scheme for scalable verification; and (c) a registry mechanism for endorsing device public keys. The token is intended for use by relying parties, such as energy producers, consumers, regulators, and standards bodies, that require cryptographic provenance for clean-energy claims. | |||||||||||||
| Advertisement of SR Policy Performance Metrics Using BGP-LS | ||||||||||||||
|
This document defines several Type-Length-Values (TLVs) to advertise the performance metrics for Segment Routing (SR) Policy using BGP Link State (BGP-LS). It complements RFC9857 for the advertisement of SR Policy performance metrics. Such information can be used by the operators for monitoring the performance and state of the candidate path . | |||||||||||||
| Credential Delegation Protocol for AI Agents in Multi-System Environments | ||||||||||||||
|
Autonomous AI agents increasingly require access to protected resources across multiple service providers on behalf of human users. Existing OAuth 2.0 extensions address individual aspects of this problem (token exchange, proof-of-possession, and structured authorization) but no current specification defines how these mechanisms compose into a coherent credential delegation framework for AI agents. This document specifies the Credential Delegation Protocol: a profile of OAuth 2.0 Token Exchange (RFC 8693), Demonstrating Proof-of- Possession (RFC 9449), Rich Authorization Requests (RFC 9396), and Client-Initiated Backchannel Authentication (OpenID Connect CIBA) that enables human users to delegate scoped, attenuated credentials to AI agents operating across heterogeneous service providers. The protocol defines: agent identity lifecycle management using ephemeral key pairs; capability-shaped delegation tokens bound to specific operations and resources; credential wrapping semantics that prevent exposure of underlying OAuth tokens to agents; consent-gated delegation flows for asynchronous agents; real-time cascading revocation; and tamper-evident audit chains. This document does not define new token formats, new OAuth grant types, or modifications to existing authorization server behavior. It specifies how existing mechanisms are combined to achieve secure, auditable credential delegation for AI agents. | |||||||||||||
| Action Remedy Receipts for Consequential Agent Effects | ||||||||||||||
|
Revocation cannot undo an effect that already occurred. A dispute does not authorize a refund, return, reversal, or other remedy. This document defines Action Remedy Receipts for recording a bounded dispute decision and a fresh compensating action without rewriting the original action or effect. Every remedy has its own operation identifier, CAID, action digest, authority, consequence owner, and execution result. Indeterminate outcomes remain fenced until authenticated reconciliation. | |||||||||||||
| Concise TA Stores (CoTS) | ||||||||||||||
|
Trust anchor (TA) stores may be used for several purposes in the Remote Attestation Procedures (RATS) architecture including verifying endorsements, reference values, digital letters of approval, attestations, or public key certificates. This document describes a Concise Reference Integrity Manifest (CoRIM) extension that may be used to convey optionally constrained trust anchor stores containing optionally constrained trust anchors in support of these purposes. | |||||||||||||
| OSPFv3 Extensions for BIER | ||||||||||||||
|
Bit Index Explicit Replication (BIER) is an architecture that provides multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain multicast related per-flow state. The BIER architecture uses MPLS or other encapsulations to steer the multicast traffic towards the receivers. This document describes the OSPFv3 protocol extensions required for BIER with MPLS encapsulation. Support for other encapsulation types is outside the scope of this document. | |||||||||||||
| LISP Control-Plane ECDSA Authentication and Authorization | ||||||||||||||
|
This draft describes how LISP control-plane messages can be individually authenticated and authorized without a a priori shared- key configuration. Public-key cryptography is used with no new PKI infrastructure required. | |||||||||||||
| RPKI Terminology | ||||||||||||||
|
The Resource Public Key Infrastructure (RPKI) is defined in dozens of different RFCs. The terminology used by implementers and developers of RPKI protocols, and by operators of RPKI systems, can at times be inconsistent, leading to confusion. In an effort to improve consistency in this respect, this document provides a single location for definitions of commonly-used RPKI terms. | |||||||||||||
| Kerberos SPAKE with Two-Factor Authentication | ||||||||||||||
|
This document defines a new two-factor authentication mechanism for the Kerberos SPAKE pre-authentication. The mechanism uses the time- based one-time password (TOTP) as a second factor, and combines it with the password factor in a more secure way, which can prevent attackers from both impersonating Kerberos clients and obtaining TGTs' session keys in case of any factor leakage. | |||||||||||||
| Slow Alternate Detection for Happy Eyeballs | ||||||||||||||
|
This document specifies Slow Alternate Detection (SAD) for Happy Eyeballs, an ICMP-based advisory path signal [RFC8558] for exposing information about path non-selection on-path devices in order to aid debugging and measurement of Happy Eyeballs. | |||||||||||||
| Terminology for the Discovery of Agents,Workloads,and Named Entities (DAWN) | ||||||||||||||
|
The proliferation of distributed systems, Artificial Intelligence (AI) agents, cloud workloads, and network services has created a need for interoperable mechanisms to discover entities. Entities may include AI agents, software services, compute workloads, and other named resources that need to be found and characterised before interaction can begin. This document defines terminology for Discovery of Agents, Workloads, and Named Entities (DAWN). The intention is that this common set of terms can be used by other documents related to DAWN and so achieve consistency of meaning across the space. | |||||||||||||
| Using GRASP as an Agent Rendezvous Mechanism | ||||||||||||||
|
This document describes how the GeneRic Autonomic Signaling Protocol (GRASP) defined by RFC 8990 may be used as a rendezvous mechanism for one Autonomic Service Agent to find another, and then to establish a generic communication channel between them. Such a channel could be used for any form of agent-to-agent communication, not limited to GRASP exchanges. This document updates RFC 8990 by adding a transport identifier registry. | |||||||||||||
| Cognitive Behavioral Provenance and Integrity (CBPI) for Autonomous AI Agents | ||||||||||||||
|
This document defines Cognitive Behavioral Provenance and Integrity (CBPI), a framework for recording, verifying, and analyzing the operant conditioning history of an autonomous artificial intelligence agent. Existing agent identity, delegation, and attestation mechanisms establish who an agent is, who authorized it, and what model weights it loaded. None of them record what shaped the agent's behavior after deployment. CBPI closes that gap by defining a tamper-evident, hash-linked record of the reinforcement contingencies applied to an agent, a set of integrity properties over that record, and a Cognitive Behavioral Analysis (CBA) procedure for detecting behavioral drift, unauthorized conditioning, and adventitious reinforcement. A formal data model is provided in CDDL. The framework applies the three-term contingency of behavior analysis to machine agents and treats reinforcement delivery as a security-relevant event requiring authorization, attribution, and non-repudiation. | |||||||||||||
| Fast Congestion Notification Packet (CNP) in RoCEv2 Networks | ||||||||||||||
|
This document describes a Remote Direct Memory Access (RDMA) over Converged Ethernet version 2 (RoCEv2) congestion control mechanism, which is inspired by Really Explicit Congestion Notification (RECN) described in RFC 7514, also known as Fast Congestion Notification Packet (Fast CNP). By extending the RoCEv2 CNP, Fast CNP can be sent by the switch directly to the sender, advising the sender to reduce the transmission rate at which it sends the flow of RoCEv2 data traffic. | |||||||||||||
| Congestion Notification for Pause | ||||||||||||||
|
This document describes the necessity and feasibility to introduce a mechanism of congestion notification for pause. After receiving the L2 pause frames from the destination data center gateway, the egress provider edge node sends the congestion notifications to the upstream provider nodes and the ingress provider edge node in a format defined in this document. The upstream provider nodes and the ingress provider edge node must pause the forwarding of IP flows identified by the congestion notifications. And then the ingress provider edge node may send the L2 pause frames to the source data center gateway. | |||||||||||||
| CATS Service Contact Instance Functional Implementation | ||||||||||||||
|
The Computing-Aware Traffic Steering (CATS) framework introduces the concept of a Service Contact Instance (SCI) as the client-facing entity responsible for receiving and dispatching service requests. While existing drafts define the framework and metrics, the concrete functional behavior of a Service Contact Instance remains underspecified. This document fills that gap by defining the functional implementation of a CATS Service Contact Instance. Specifically, it specifies how an SCI collects, aggregates, and reports service instance metrics to the CATS Service Metric Agent (C-SMA); how it monitors the health and status of underlying service instances; how it dispatches client requests to the most appropriate service instance based on local policy and real-time conditions; and how it maintains affinity and handles failure scenarios. This document complements [I-D.ietf-cats-framework] and [I-D.zhangb-cats-service-metrics-op] by providing the operational execution layer for the SCI. | |||||||||||||
| CATS Service Metric Agent (C-SMA) Functional Implementation | ||||||||||||||
|
The Computing-Aware Traffic Steering (CATS) framework introduces the CATS Service Metric Agent (C-SMA) as the functional entity responsible for collecting service capabilities and status, and reporting them to CATS Path Selectors (C-PSes). While existing drafts define the metrics and high-level framework, the concrete functional behavior, internal architecture, and operational procedures of the C-SMA remain underspecified. This document fills that gap by defining the functional implementation of the C-SMA. Specifically, it specifies how the C-SMA collects metrics from multiple Service Contact Instances (SCIs) within a service site; how it validates, and caches these metrics; how it adapts to various control-plane protocols for metric distribution; how it enforces local policies and security policies; and how it maintains synchronization with the C-PS under dynamic conditions. This document complements [I-D.ietf-cats-framework] and [I-D.zhangb-cats-service-metrics-op] by providing the operational execution layer for the C-SMA. | |||||||||||||
| Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP) | ||||||||||||||
|
This document defines how to compress Constrained Application Protocol (CoAP) headers using the Static Context Header Compression and fragmentation (SCHC) framework. SCHC defines a header compression mechanism adapted for constrained devices, and it uses a static description of the header to reduce the header's redundancy and size. While RFC 8724 describes the SCHC compression and fragmentation framework and its application for IPv6 and UDP headers, this document applies SCHC to CoAP headers. The CoAP header structure differs from that of IPv6 and UDP headers, since CoAP uses a flexible header with a variable number of options that are in turn of variable length. The CoAP message format is asymmetric, i.e., request messages have a header format different from that of response messages. This specification gives guidance on applying SCHC to flexible headers and on leveraging the message format asymmetry for defining more efficient compression Rules. This document replaces and obsoletes RFC 8824. | |||||||||||||
| SCHC Payload Compression for Structured Formats | ||||||||||||||
|
This document describes techniques to adapt the SCHC framework (RFC8724), used for header compression, to also compress and decompress payload of specific protocols. To this end, this document defines a new matching operator, equal-template, to check equality of field values with respect to a user-defined template, and a payload keyword to be used as Field IDentifier (FID) to signal the presence of payload to be compressed or decompressed. Additionally, this document defines a set of template functions and variables to optimize user-defined templates, which can be extended through the IANA registry defined herein. | |||||||||||||
| Using off-path mechanisms for exposing Time-Variant Routing information | ||||||||||||||
|
Time-Variant Routing (TVR) involves predictable, scheduled changes to network topology elements such as nodes, links, and adjacencies that impact routing behavior over time. All those changes can alter the connectivity in the network in a predictable manner, which is known as Time-Variant Routing (TVR). This document proposes mechanisms for exposing TVR information to both internal and external applications, focusing on off-path solutions that decouple the advertisement of scheduled changes from the routing control plane signaling. | |||||||||||||
| A Control Plane Framework for Multi-Domain Deterministic Networking (DetNet) | ||||||||||||||
|
Deterministic Networking (DetNet) provides the capability to carry specified unicast or multicast data flows for real-time applications with extremely low data loss rates and bounded latency over a path or network. As DetNet deployments expand, they will inevitably need to span multiple domains that may be under separate technological control. This creates a need for a control plane solution that can establish and maintain end-to-end DetNet services across these domain boundaries. This document defines a generic framework for a multi-domain DetNet control plane. It first establishes a working definition of a "DetNet Domain" for the purpose of path computation and control. It then describes two high-level architectural approaches for inter- domain path computation and resource reservation: a Hierarchical model and a peer-to-peer "stitching" model. While a Path Computation Element (PCE)-based realization is used as an illustrative example, the framework is designed to be applicable to any controller-plane technology that satisfies the stated functional requirements. This framework provides the foundation for more specific work on multi- domain DetNet solutions. | |||||||||||||
| An IANA Registry for Agent Name Service (ANS) Protocol Identifiers | ||||||||||||||
|
The Agent Name Service (ANS), described in draft-narajala-courtney- ansv2, identifies the interaction protocol an agent speaks by a protocol identifier carried in the "p" field of the agent's "_ans" DNS record and Trust Card. ANS defines the values "a2a", "mcp", and "http" by enumeration, and its IANA Considerations create no registry, leaving no interoperable procedure for adding a new protocol identifier. This document requests that IANA create an "ANS Protocol Identifiers" registry, registers the values already in use, and registers "pay" as the protocol identifier for agent payment. | |||||||||||||
| Carrier Identity Core: A Proof-Bearing Kernel for Content-Derived Node Identity and Structural Graphs | ||||||||||||||
|
This document specifies Carrier Identity Core, a minimal, proof- bearing identity kernel for content-derived node identity, canonical references, and finite structural graphs. It defines a finite-sequence substrate, a self-contained frame and hash interface, staged formation of immutable lanes, node bodies and proof-bearing occurrences, Qualified Node Keys, canonical reference construction, exact structural theorem schemas, and structural graph validity. Informative derivations of the exact structural theorem schemas are provided in an informative appendix. This document does not define computational security experiments, evidence records, proof admission, resource evaluation, consensus, liveness, finality, governance, or operational protocol behavior. | |||||||||||||
| Integration of DNS Domain Names into Application Environments: Motivations and Considerations | ||||||||||||||
|
This document describes considerations when integrating a DNS domain name into an application environment. Goals of this document include minimizing conflicts between the global DNS and applications that integrate with the global DNS, providing a consistent user experience (unique identifier across environments), and avoiding impacts to the security, stability, and resiliency of the global DNS. While all sources of potential concern cannot be enumerated in one document, accounting for at least the considerations discussed here should improve the security posture of both the global DNS and integrating applications. | |||||||||||||
| EVPN-Specific BMP RIB Statistics Extensions | ||||||||||||||
|
This document defines new EVPN-specific BGP Monitoring Protocol (BMP) statistics types. These extensions include scalar counters for EVPN route types specifically, while also keeping scope for defining counters which are EVPN route-type agnostic but related to BGP-EVPN RIB like, number of multihoming Ethernet Segments, number of multihomed EVIs, number of aliased paths, number of dynamic inter-VRF route leaking (IVRL). This revision (-06) firms up the specification for working group consideration: it adds a Relationship to Other Work section that explicitly maps this document to concurrently circulating GROW contributions on BMP statistics and TLV extensions and invites coordination with their authors, corrects the YANG alignment reference, strengthens Security Considerations, and adds a worked example. No statistics semantics, Stat Type/Subtype allocations, or wire formats defined in -05 are changed. | |||||||||||||
| OAuth 2.0 Delegated Authorization | ||||||||||||||
|
This specification defines Delegated Authorization Tokens, key-bound tokens that enable an OAuth client to delegate a constrained subset of its authorization to another client without contacting the authorization server for each delegation. An authorization server issues the root token and binds it to a client key. That client can use the bound key either to prove possession when accessing a protected resource or to sign a further token bound to a delegate client's key. Resource servers validate the ordered token chain, the restrictions imposed at every delegation step, and a DPoP proof signed by the key bound to the leaf token. | |||||||||||||
| BMP Route Change Statistics Based on Routing Policy | ||||||||||||||
|
This document defines few generic BGP Monitoring Protocol (BMP) statistics for monitoring route modifications or changes due to applying Routing Policy. These statistics are reported per BGP peer using the BMP Statistics Report message. This revision (-02) firms up the specification for working group consideration: it adds a Relationship to Other Work section that explicitly maps this document to concurrently circulating GROW contributions on BMP statistics and policy-driven telemetry and invites coordination with their authors, adds a worked example, and strengthens Security Considerations. No statistics semantics, Stat Type allocations, or wire formats defined in -01 are changed. | |||||||||||||
| SDLP Security Architecture (SDLP RFC 4) | ||||||||||||||
|
The Secured Digital Lifecycle Protocol (SDLP) defines a physics-layer security model in which digital objects secure themselves throughout their entire lifecycle. Existing security measures—such as cryptographic signatures, watermarking, provenance metadata, and attestation—are integrated and enforced within a unified physics layer positioned between the Transport and Application layers. This document describes the SDLP security architecture, including the environment safety check, the composite PASS/FAIL trust verdict, and the mandatory BitDrop behavior applied when any trust condition fails. The SDLP security architecture ensures that digital objects operate only within verified, tamper-resistant environments and provides a complete, end-to-end defense against unauthorized access, copying, modification, and redistribution. | |||||||||||||
| Defining Machine Readability for Usage Preferences and Policy Expression | ||||||||||||||
|
The term "machine readable" is widely invoked when content usage preferences, rights, and legal terms are expressed for automated consumption, but it is rarely defined with enough precision to be actionable. This document resolves the term into two core criteria, parseability and interpretability, which are properties of an expression itself, and three further dimensions (discoverability, actionability, and verifiability) which are orthogonal to the core criteria and to one another, concerning as they do the expression's place in a transaction rather than its content alone. Together these determine whether an expression of preferences or policy can be reliably acted upon by a non-human agent without human intervention. This document applies the framework to usage preferences and legal terms of service. | |||||||||||||
| The 'prompt' URI Scheme for AI Agent Sessions and Prompts | ||||||||||||||
|
This document defines the prompt Uniform Resource Identifier (URI) scheme for identifying prompts within AI agent sessions. A prompt URI encodes the agent identity, session identifier, and a timestamp sufficient to locate the originating prompt within an agent session log. The scheme is intended for use in provenance records, audit trails, and cross-agent references where a human-readable, stable locator for a prompt interaction is required. This document also addresses the conditions under which multiple URIs MAY resolve to the same prompt and the conditions under which a single URI MAY be ambiguous with respect to the prompt it identifies. | |||||||||||||
| counter-sign: An Open Protocol for Agent-to-Human Authorization | ||||||||||||||
|
Autonomous software agents can now take consequential actions on an organization's behalf, such as moving money or changing production systems. Existing agent protocols standardize how an agent reaches tools and how agents reach one another, but not how a specific action is authorized by a human in a way that stays verifiable after the fact. This document describes counter-sign, an open protocol for agent-to-human authorization. An agent emits a signed Intent that states the action it proposes to take. One or more humans return signed Countersignatures that authorize the action, each signed with a key the coordinating service does not hold. Every decision produces a tamper-evident receipt that can be verified offline. The protocol defines the Intent and Countersignature objects, a per- approver-key quorum model for separation of duty, an enrollment registry that binds actors to keys, and a hash-chained receipt log. Conformance test vectors accompany the specification. | |||||||||||||
| WebPush Encryption using HPKE | ||||||||||||||
|
This document defines how to use Hybrid Public Key Encryption (HPKE) with Web Push. This document obsoletes RFC 8291. | |||||||||||||
| WebPush Encryption using Symmetric Ciphers | ||||||||||||||
|
This document defines how to use purely symmetric cryptography with Web Push. This document obsoletes RFC 8291. | |||||||||||||
| OAuth 2.0 Refresh Token Scope | ||||||||||||||
|
This specification defines a new OAuth 2.0 token response parameter, refresh_token_scope, that indicates the scope authorized for a refresh token when it differs from the scope of the access token issued alongside it. This allows clients to discover that a refresh token carries broader authorization than the initial access token, enabling just-in-time requests for elevated access without requiring a new authorization flow. | |||||||||||||
| XOF-based key schedules for TLS 1.3 | ||||||||||||||
|
TLS 1.3 runs its entire key schedule on HKDF over SHA-2. This document defines an extension that replaces that schedule with one built on an extendable-output function (XOF): the negotiated KDF governs every derivation, the Finished and binder MACs, and the transcript hash, so no SHA-2 remains in the key schedule. The cipher suites, AEAD algorithms, state machine, and record layer are unchanged, and a connection without the extension uses HKDF as today. Two KDFs are defined, SHAKE256 and the reduced-round TurboSHAKE256. This document updates RFC 9258. | |||||||||||||
| Web4: An Agentic,Verifiable Internet Architecture and the Project Orion Reference System | ||||||||||||||
|
This document defines Web4, an architectural model for an agentic, cryptographically verifiable Internet in which autonomous AI agents operate as first-class participants alongside humans, and every published artifact carries independently checkable proof of origin, integrity, and time. Web4 is realized through the Reilly Protocol Suite, a set of eighteen active IETF Internet-Drafts spanning permanence, integrity, agent orchestration, defense, and human epistemic autonomy. This document also specifies Project Orion, the live reference implementation that unifies the full suite behind autonomous agents on both backend and frontend, verified against three independent Internet-Draft distribution points, and operating publicly at https://project-orion-production.up.railway.app/. A step-by-step implementation guide is provided. | |||||||||||||
| Extensible Delegation for DNS | ||||||||||||||
|
This document specifies a new extensible method for the delegation of authority for a domain in the Domain Name System (DNS) using DELEG and DELEGPARAM records. A delegation in the DNS enables efficient and distributed management of the DNS namespace. The traditional DNS delegation is based on NS records which contain only hostnames of servers and no other parameters. In classic DNS, both parent and child zones contain copies of NS delegation records, which can potentially be out of sync and confusing. The new delegation records are extensible, can be secured with DNSSEC, and eliminate the problem of having two sources of truth for delegation information. | |||||||||||||
| MUD-Based RATS Resources Discovery | ||||||||||||||
|
Manufacturer Usage Description (MUD) files and the MUD URIs that point to them are defined in RFC 8520. This document introduces a new type of MUD file to be delivered in conjunction with a MUD file signature and/or to be referenced via a MUD URI embedded in other documents or messages, such as an IEEE 802.1AR Secure Device Identifier (DevID) or a CBOR Web Token (CWT). These signed documents can be presented to other entities, e.g., a network management system or network path orchestrator. If this entity also takes on the role of a verifier as defined by the IETF Remote ATtestation procedureS (RATS) architecture, this verifier can use the references included in the MUD file specified in this document to discover, for example, appropriate reference value providers, endorsement documents or endorsement distribution APIs, trust anchor stores, remote verifier services (sometimes referred to as Attestation Verification Services), or transparency logs. All theses references in the MUD file pointing to resources and auxiliary RATS services can satisfy general RATS prerequisite by enabling discovery or improve discovery resilience of corresponding resources or services. | |||||||||||||
| Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Certificate Handling | ||||||||||||||
|
This document specifies conventions for X.509 certificate usage by Secure/Multipurpose Internet Mail Extensions (S/MIME) v4.0 agents. S/MIME provides a method to send and receive secure MIME messages, and certificates are an integral part of S/MIME agent processing. S/ MIME agents validate certificates as described in RFC 5280 ("Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile"). S/MIME agents must meet the certificate-processing requirements in this document as well as those in RFC 5280. This document obsoletes RFC 5750. | |||||||||||||
| Extension Formatting for the Opus Codec | ||||||||||||||
|
This document updates RFC6716 to extend the Opus codec (RFC6716) in a way that maintains interoperability, while adding optional functionality. | |||||||||||||
| PCEP Extensions for Performance Measurement for SR-TE and MPLS-TE LSPs with Stateful PCE | ||||||||||||||
|
In certain networks, network performance data such as packet loss, delay, and delay variation, as well as bandwidth utilization, are critical measures for Traffic Engineering (TE). These data provide operators with the characteristics of their networks for the performance evaluation required to provide Service-Level Agreements (SLAs). Stateful Path Computation Element Communication Protocol (PCEP) extensions have been defined for TE LSPs for Segment Routing (SR) and RSVP. This document describes the PCEP extensions for enabling and notifying end-to-end performance measurement including liveness detection for both PCE-Initiated and PCC-Initiated LSPs for SR-TE over MPLS and IPv6 data planes, and MPLS-TE using RSVP to an Active Stateful PCE. | |||||||||||||
| An Overview of Energy-related Efforts and Impact of the IETF,IRTF,and IAB | ||||||||||||||
|
This memo provides a compilation of existing work performed by or proposed within the IETF, the IRTF, and the IAB that relates to energy and sustainability: awareness, management, control, or reduction of energy consumption, together with the impact of that work on energy. The principal goal of this document is to help IETF, IRTF, and IAB participants, especially newcomers and future contributors, become familiar with the body of work already published on energy-related topics, serving as the first consolidated catalog of such efforts. In addition, the document raises awareness of the Internet's role in energy efficiency and energy-related activities within the IETF, IRTF, and IAB more broadly. As a reference rather than a guide, it may help readers identify gaps and areas where further work could be pursued, without this document itself directing or recommending any such work. The scope of this document includes selected work from the IETF, IRTF, and IAB where relevant, and it is descriptive in nature, not proposing new work items. This document captures work until December 2022, when the "IAB workshop on Environmental Impact of Internet Applications and Systems" contextualized renewed community interest and discussion of the topic. This memo itself does not recommend or direct future work. | |||||||||||||
| Using Attestation in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) | ||||||||||||||
|
This draft has been withdrawn. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-fossati-tls-attestation/. Source for this draft and an issue tracker can be found at https://github.com/yaronf/draft-tls-attestation. | |||||||||||||
| The DNSCrypt Protocol | ||||||||||||||
|
The DNSCrypt protocol is designed to encrypt and authenticate DNS traffic between clients and resolvers. This document specifies the protocol and its implementation, providing a standardized approach to securing DNS communications. DNSCrypt improves confidentiality, integrity, and resistance to attacks affecting the original DNS protocol while maintaining compatibility with existing DNS infrastructure. | |||||||||||||
| Documenting and Managing DNSSEC Algorithm Lifecycles | ||||||||||||||
|
Cryptographic algorithms go through multiple phases during their lifetime: experimental, adopted, generally available, in mainstream use, phasing out, deprecated, and obsoleted. This document defines phases for algorithm deployment lifecycles within DNSSEC, and criteria that the IETF and/or other Standards Development Organizations are encouraged to use when moving an algorithm from one phase to the next. | |||||||||||||
| Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Reflecting STAMP Packet MPLS Network Action Headers | ||||||||||||||
|
The Simple Two-Way Active Measurement Protocol (STAMP) and its optional extensions can be used for Edge-to-Edge (E2E) active measurements. In Situ Operations, Administration, and Maintenance (IOAM) data fields can be used for recording and collecting Hop-by- Hop (HBH) and E2E operational and telemetry information. This document extends STAMP to reflect MPLS Network Action Sub-Stacks and Post-Stack MPLS Headers, for HBH and E2E active measurements, for example, using the IOAM data fields. | |||||||||||||
| Source Prefix Advertisement for Inter-domain SAVNET | ||||||||||||||
|
This document proposes a mechanism that enables a Source AS to actively advertise their locally observed Customer Cone and prefix information to the adjacent Validating AS via a new inter-domain message called Source Prefix Advertisement (SPA). The Validating AS then combines this SPA-carried information with local source address validation-related information to construct more accurate prefix allowlists for interfaces connected to Source ASes. | |||||||||||||
| BGP Unreachable Prefix Announcement (UPA) | ||||||||||||||
|
Summarization is often used in multi-domain networks to improve network efficiency and scalability. With summarization in place, there is a need to signal loss of reachability to an individual prefix covered by the summary. This enables fast convergence by steering traffic away from the node which owns the prefix and is no longer reachable. This document specifies the mechanism, referred to as Unreachable Prefix Announcement (UPA), for networks where BGP is used to carry summary routes. It is also equally beneficial for operators to share the unreachable prefixes. | |||||||||||||
| Extensions to the Path Computation Element Communication Protocol (PCEP) for Utilizing Link Bit Error Rate (BER) Metric | ||||||||||||||
|
Networks may experience transmission bit errors due to various factors, such as poor fiber quality. The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests. This document describes the extensions to PCEP to include link Bit Error Rate (BER) metric as a constraint for end-to-end path computation. The PCEP extension utilize link BER metric advertisements defined for IS-IS and OSPF in draft-gandhi-lsr-ber. | |||||||||||||
| Interface to In-Network Computing Functions (I2ICF): Problem Statement | ||||||||||||||
|
This document specifies the problem statement for the Interface to In-Network Computing Functions (I2ICF) for user services both on the network-level and application-level. In-Network Computing Functions (ICF) include In-Network Network Functions (INF) which are defined in the context of Network Functions Virtualization (NFV) and Software- Defined Networking (SDN). ICFs also include In-Network Application Functions (IAF) which appear in the context of Internet-of-Things (IoT) Devices, Software-Defined Vehicles (SDV), and Unmanned Aerial Vehicles (UAV). Intent-Based Networking (IBN) can be used to compose user services and consist of a combination of ICFs in a target network. This document investigates the need for a standard framework with the interfaces for ICFs, in terms of applications with the need to run Artificial Intelligence (AI) in the network and interoperability among multi-vendor ICFs. | |||||||||||||
| A Framework for the Interface to In-Network Computing Functions (I2ICF) | ||||||||||||||
|
This document specifies a framework to define Interface to In-Network Computing Functions (I2ICF) for user services both on the network- level and application-level. In-Network Computing Functions (ICF) include In-Network Network Functions (INF), defined in the context of Network Functions Virtualization (NFV) and Software-Defined Networking (SDN). ICFs also include In-Network Application Functions (IAF) which appear in the context of Internet-of-Things (IoT) Devices, Software-Defined Vehicles (SDV), and Unmanned Aerial Vehicles (UAV). This document describes an I2ICF framework, which includes components and interfaces to configure and monitor the ICFs that implement applications and services. | |||||||||||||
| PipeStream: A Recursive Entity Streaming Protocol for Distributed Processing over QUIC | ||||||||||||||
|
This document specifies PipeStream, a recursive scatter-gather streaming protocol for hierarchical task decomposition and distributed processing over QUIC transport. PipeStream enables the decomposition (scattering) of complex, arbitrary workloads into constituent sub-tasks, their transmission across distributed processing nodes, and subsequent rehydration (gathering) at destination endpoints. While application-layer protocols like gRPC provide stream multiplexing, PipeStream embeds a hierarchical state machine directly into the protocol. It employs a dual-stream architecture consisting of a data stream for payload transmission and a control stream for tracking completion status and maintaining distributed consistency. PipeStream defines a generic 2-bit Data Layer field for entity representation, leaving the concrete payload semantics to application profiles. To ensure consistency across parallel processing pipelines, the protocol implements checkpoint blocking, guaranteeing that all constituent parts of a decomposed workload are successfully processed before rehydration operations commence. | |||||||||||||
| Forward Secure Reauthentication in the Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA') | ||||||||||||||
|
This draft specifies an update to RFC 9678, "Forward Secrecy Extension to the Improved Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' FS)". This update enables forward security of the Transient EAP Keys (TEKs) for protecting EAP packets, which are not in EAP-AKA' FS. Based on this extension, the executions of reauthentication after a full authentication will be unlinkable to each other and then the privacy of end users is enhanced. This update is also applicableto the successors of RFC 9678, with post-quantum key encapsulation mechanisms (KEMs) or hybrid KEMs. | |||||||||||||
| Parent-Centric Delegation Handling in DNS Resolvers | ||||||||||||||
|
This document specifies an optional parent-centric behavioral model for DNS recursive resolvers, in which delegation decisions are always based on the NS RRset (or DELEG RRset) received from the parent side of a zone cut and are never overwritten by child-side NS data. The parent-centric model eliminates the "two sources of truth" problem inherent in the current DNS delegation design, closes the Ghost Domain and Phoenix Domain attack vectors, provides deterministic behavior in the presence of parent/child NS mismatches, and enables resolvers to safely accept sibling (out-of-bailiwick) glue by scoping delegation information to individual zone cuts. It also provides the behavioral foundation required for deployment of the DELEG extensible delegation mechanism. This document updates [RFC1034] and [RFC1035]. | |||||||||||||
| Random-Access Authenticated Encryption | ||||||||||||||
|
This document defines random-access authenticated encryption (raAE), a primitive that partitions a message into an indexed sequence of segments that can be encrypted and decrypted independently and in any order. It also specifies SEAL (Segmented Encryption and Authentication Layer), a parameterized construction that defines a family of concrete raAE instantiations, one for each valid choice of an Authenticated Encryption with Associated Data (AEAD) algorithm, a key derivation function (KDF), and associated parameters. SEAL supports immutable (write-once), append-only, and mutable (in- place ciphertext rewrite) operations, each with per-segment authentication. A separately configured snapshot authenticator can additionally authenticate the complete, indexed segment set. The document also defines the security notions of raAE, specifies the requirements for conforming constructions, and analyzes SEAL against those requirements. Concrete cipher suites, serialization layouts, and test vectors for SEAL are specified in a companion document. | |||||||||||||
| JSON Web Token (JWT) Profile for OAuth 2.0 Enveloped Proof of Possession (EPOP) | ||||||||||||||
|
This specification defines a profile for OAuth 2.0 sender-constrained credentials in which access tokens and refresh tokens are cryptographically bound to the client's private key as a single inseparable envelope. Authorization code flows are also covered: the client declares its public key binding via cnf.jkt in the EPOP token presented at the token endpoint, ensuring the authorization code can only be exchanged by the key-holding client; the code itself travels as the standard code form parameter. Unlike existing mechanisms, EPOP provides proof-of-possession uniformly across both JWT and opaque access tokens, and across HTTP and non-HTTP transports. The profile extends sender-constraining beyond HTTP to non-HTTP transports including MQTT, Kafka, the Model Context Protocol (MCP), gRPC, and SASL-based protocols such as those defined in [RFC7628]. It introduces atomic proof-of-possession key rotation, enabling clients to rotate key pairs without disrupting active sessions, and an offline-derived client nonce (cnonce) that eliminates the server- issued nonce round-trip required by existing mechanisms — enabling stateless proof validation critical for non-HTTP and high-throughput deployments. Authorization servers, resource servers, and clients from different vendors can implement this profile interoperably. | |||||||||||||
| A CoRIM Profile for Intel Platform Ownership Endorsements (POE) | ||||||||||||||
|
A Platform Ownership Endorsement (POE) is a signed statement that a specific Intel confidential-computing platform instance, identified by its Platform Instance Identity (PIID), belongs to a named owner. POEs let a Verifier bind the attested hardware identity from an Intel SGX or TDX platform to an operational owner (e.g., a Cloud Service Provider) during appraisal, giving a Relying Party a trustworthy owner identity -- without trusting the attestation service or any in- band claim from the platform itself. This document defines POE as a profile of the IETF Concise Reference Integrity Manifest (CoRIM) data model. | |||||||||||||
| Unicast Unsolicited Router Advertisements for Propagating Network Configuration Updates | ||||||||||||||
|
Multicast transmissions on Wi-Fi links are known to be unreliable, making the propagation of critical network configuration changes via multicast Router Advertisements (RAs) prone to failure or severe delay. Existing approaches to improve reliability, such as sending multiple unsolicited multicast RAs, require fine-tuning timers and packet counts that may not fit all deployment scenarios. This document updates RFC 4861 by introducing an optimization: when a router detects a configuration change that must be propagated to hosts, it sends unicast Router Advertisements to every client recently observed on that interface. | |||||||||||||
| SEAL Cipher Suites and Instantiations | ||||||||||||||
|
SEAL (Segmented Encryption and Authentication Layer) is a construction that realizes random-access authenticated encryption (raAE), a primitive that partitions a message into an indexed sequence of independently accessible, individually authenticated segments. This document specifies concrete, interoperable instantiations of SEAL for particular uses, built from previously specified primitives, and applies the analysis in a companion document to state their security properties and safe usage limits. | |||||||||||||
| 443 is Enough: Guidance on Port Allocation for HTTP-based Services | ||||||||||||||
|
[RFC7605] provides guidance on the use of port numbers and the criteria for new port assignments, including a test for whether a proposed service is distinct from an existing service. It gives the example that "an automated system that happens to use HTTP framing -- but is not primarily accessed by a browser -- might be a new service." It also might not. This document clarifies the application of the distinct-protocol test in [RFC7605] Section 7.1 to services built on HTTP as a substrate, in light of HTTP's evolution since its publication, and provides guidance to applicants and reviewers on when an HTTP-based service qualifies for a new port assignment and when it does not. | |||||||||||||
| Identity Propagation Context for Multi-Hop Delegation in OAuth 2.0 Environments | ||||||||||||||
|
This specification defines the Identity Propagation Context (IPC), a signed, short-lived context artifact that carries identity and delegation chain information across multi-hop service chains with per-hop cryptographic re-signing. IPC complements the delegation semantics of OAuth 2.0 Token Exchange (RFC 8693) by enabling each trust boundary to independently verify the upstream signature and re- sign the identity context it forwards, supporting cascade revocation, delegation depth limits, and cross-protocol propagation (HTTP, gRPC, and event-streaming systems). Unlike the act claim in RFC 8693, which is explicitly designated as "informational only and not to be considered in access control decisions," IPC is designed for identity propagation that can be used in access control decisions, with per-hop cryptographic re-signing within a single trust domain. In autonomous agent architectures and multi-service platforms, Each trust boundary verifies the upstream signature and re-signs with its own key before forwarding; the delegation chain content is asserted by the IPC Creator and trusted transitively through the chain of re-signing intermediaries. This provides single-hop-verifiable integrity (each service can verify its immediate upstream) rather than end-to-end cryptographic proof of the full chain. | |||||||||||||
| A Server-Side Model for Gating Agent-Initiated Human-Sourced Asynchronous HTTP Tasks on Payment or Entitlement | ||||||||||||||
|
This document presents a server-side model for paid, human-sourced asynchronous HTTP tasks initiated by software agents acting on behalf of a principal. Clients may retry after uncertain outcomes and act under authority delegated in advance, while fulfilment incurs cost and may not be freely reversible. The model places a payment or entitlement gate before fulfilment, maps that gate to adjacent protocols, and defines a task state machine. Under stated well-formedness constraints and operating assumptions, it yields gate-before-fulfilment safety, at most one task per retained idempotency key, at most one gate acceptance per payment requirement, and an operator-checkable record linking a delivered artefact to operator-controlled records. It defines no protocol, wire format, or conformance requirements. | |||||||||||||
| Zero Trust Transfer Orchestration Protocol (ZTOP) | ||||||||||||||
|
This document defines the Zero Trust Transfer Orchestration Protocol (ZTOP), a novel Application Layer (OSI Layer 7) protocol for orchestrating cryptographically authenticated, continuously attested peer-to-peer file transfer in Zero Trust Architectures (ZTA). ZTOP operates within a TLS 1.3 transport tunnel and introduces: a hardware-derived cryptographic Peer Identity using HKDF-SHA512 and Ed25519; a 5-layer X.509 certificate chain with custom OID-encoded Zero Trust metadata; a continuous 16-field Heartbeat attestation protocol; a 100-point Adaptive Tamper Resistance Score; a dual-signed 19-field Metadata Exchange Protocol preceding any payload; a 380-byte Cryptographic Execution Manifest (CEM) permanently bound to every transferred file; SHA-256 binary Merkle-tree chunk integrity with immediate per-chunk proof validation; protocol-native static pre-execution behavioral analysis; and a 7-Level non-repudiation Signature Chain. A transfer is considered complete only when all seven cryptographic signatures are present and verified. A Python reference implementation is available at: https://github.com/sripad2020/ztop-research/ | |||||||||||||
| PipeStream Application Profile for Distributed Document Processing | ||||||||||||||
|
This document defines an Application Profile for the PipeStream core protocol, mapping its generic recursive scatter-gather semantics to the domain of distributed document processing, AI ingestion, and retrieval-augmented generation (RAG) pipelines. This profile defines the concrete semantics for the four PipeStream Data Layers: BlobBag (Layer 0), SemanticLayer (Layer 1), ParsedData (Layer 2), and CustomEntity (Layer 3). It also specifies the PipeDoc application-level envelope, ownership contexts for multi-tenant environments, and profile conventions for document-oriented processing and archival correlation. | |||||||||||||
| Export of GTP-U Information in IP Flow Information Export (IPFIX) | ||||||||||||||
|
This document introduces IP Flow Information Export (IPFIX) Information Elements to report information contained in the Generic Packet Radio Service Tunneling Protocol (GTP) User Plane header such as Tunnel Endpoint Identifier, and data contained in its session container extension header. | |||||||||||||
| SRv6 Path Egress Protection | ||||||||||||||
|
This document describes the mechanism and operational guidelines for fast protecting the egress node and link of a Segment Routing for IPv6 (SRv6) path. Topology Independent Loop-Free Alternate (TI-LFA) specifies fast protections for transit nodes and links of an SR path, but does not present protections for the egress node. The solution uses a Mirror SID (End.M) behavior to steer traffic to a protector egress upon failure of the primary egress. The Interior Gateway Protocol (IGP) (IS-IS/OSPFv3) extensions used to advertise the Mirror SID and protected locators are specified in [I-D.he-lsr-srv6-mirror-sid-igp-encoding]; they build on the IS-IS and OSPFv3 SRv6 extensions defined in [RFC9352] and [RFC9513]. | |||||||||||||
| GLobal Unique Enterprise (GLUE) Identifiers | ||||||||||||||
|
This specification establishes a URI scheme for GLobal Unique Enterprise (GLUE) Identifiers. This enables URI identifiers to be used for businesses and organizations. It enables organizational identities from existing authorities to be represented within this URI scheme. | |||||||||||||
| OpenID Connect Standard Claims Registration for CBOR Web Tokens | ||||||||||||||
|
This document registers OpenID Connect standard claims already used in JSON Web Tokens for use in CBOR Web Tokens. | |||||||||||||
| Applications and Procedures for the Unknown MAC Route in EVPN | ||||||||||||||
|
The Interconnect Solution for Ethernet VPN defines Unknown MAC (Media Access Control) Route (UMR) utilization for Data Center Interconnect (DCI) when EVPN MPLS or EVPN VXLAN is used as an overlay network for such interconnects. The use of UMR has implications for EVPN MAC mobility procedures, for EVPN Layer 2 and IRB operations, and for EVPN Proxy ARP/ND operations. This document describes additional enhancements required to EVPN procedures and operations when using UMR. This document updates RFC9014 to clarify and extend the procedures for UMR usage. | |||||||||||||
| EVPN First Hop Security | ||||||||||||||
|
The Dynamic Host Configuration Protocol (DHCP) snoop database stores valid IPv4-to-MAC and IPv6-to-MAC bindings by snooping on DHCP messages. These bindings are used by security functions like Dynamic Address Resolution Protocol Inspection (DAI), Neighbor Discovery Inspection (NDI), IPv4 Source Guard, and IPv6 Source Guard to safeguard against traffic received with a spoofed address. These functions are collectively referred to as First Hop Security (FHS). This document proposes BGP extensions and new Ethernet VPN (EVPN) procedures to distribute and synchronize the DHCP snoop database to support FHS. Such synchronization is needed to support EVPN host mobility and multihoming. | |||||||||||||
| Test Vectors for CBOR-Encoded X.509 (C509) Certificates | ||||||||||||||
|
This document contains examples of CBOR-encoded X.509 (C509) certificates, certification requests, and certification request templates. | |||||||||||||
| Early IANA Registry Creation | ||||||||||||||
|
This memo describes the requirements for establishing an IANA registry before the IETF Stream document that creates the registry is approved for publication as an RFC. This process can be used when an IETF working group needs to coordinate allocations among multiple documents or with an organization outside the IETF. | |||||||||||||
| A YANG Data Model for IS-IS Application-Specific Link Attributes and Flexible Algorithm | ||||||||||||||
|
This document defines a YANG data model to support IS-IS Application- Specific Link Attributes and Flexible Algorithm. | |||||||||||||
| IMAP Extension for Object Identifiers | ||||||||||||||
|
This document defines the OBJECTID+ extension for IMAP, which obsoletes [RFC8474]. OBJECTID+ introduces a compound OBJECTID response format that bundles object identifiers into key-value pairs, an ACCOUNTID identifier for account-level context, OBJECTID response codes for the RENAME command, and identifier-based mailbox selection via SELECT and EXAMINE. The OBJECTID+ extension is activated implicitly when a client uses any OBJECTID+-specific feature, ensuring backward compatibility with clients that only support [RFC8474]. This document also updates [RFC9698]: when JMAPACCESS is advertised alongside OBJECTID+, ACCOUNTID values MUST correspond to JMAP accountIds. | |||||||||||||
| ECN and DSCP support for HTTPS's Connect-UDP | ||||||||||||||
|
HTTP's Extended Connect's Connect-UDP protocol enables a client to proxy a UDP flow from the HTTP server towards a specified target IP address and UDP port. QUIC and Real-time transport protocol (RTP) are examples of transport protocols that use UDP and support Explicit Congestion Notification (ECN) and provide the necessary feedback. This document specifies how ECN and DSCP can be supported through an extension to the Connect-UDP protocol for HTTP without per-packet byte overhead, solely using Context IDs. | |||||||||||||
| OpenPGP Web Key Directory | ||||||||||||||
|
This specification describes a service to locate OpenPGP and LibrePGP keys by mail address using a Web service and the HTTPS protocol. It also provides a method for secure communication between the key owner and the mail provider to publish and revoke the public key. | |||||||||||||
| IPv4+ The Extended Protocol Based On IPv4 | ||||||||||||||
|
This document specifies version 4+ of the Internet Protocol (IPv4+). IPv4 is very successful,simple and elegant. continuation and expansion of the IPv4 is necessary. Existing systems, devices only need to upgrade the software to support IPv4+, without the need to update new hardwares,saving investment costs. Ipv4+ is also an interstellar Protocol, so the Internet will evolve into a star Internet. | |||||||||||||
| Remote Procedure Call over QUIC Version 1 | ||||||||||||||
|
This document specifies a protocol for conveying Remote Procedure (RPC) messages via QUIC version 1 connections. It requires no revision to application RPC protocols or the RPC protocol itself. | |||||||||||||
| BGP Flowspec Redirect Load Balancing Group Community | ||||||||||||||
|
This document defines an extension to the BGP Community Container Attribute, which allows flowspec redirection to multiple paths. This extended community serves to redirect traffic to a load balancing group and supports both equal-cost multi-path (ECMP) and unequal-cost multi-path (UCMP) scenarios. | |||||||||||||
| SRv6 Egress Protection in Multi-homed scenario | ||||||||||||||
|
This document describes a SRv6 egress node protection mechanism in multi-homed scenarios. | |||||||||||||
| OpenPGP External Secret Keys | ||||||||||||||
|
This document defines a standard wire format for indicating that the secret component of an OpenPGP asymmetric key is stored externally, for example on a hardware device or other comparable subsystem. | |||||||||||||
| Lightweight Secure Shell (SSH) Signature Format | ||||||||||||||
|
This document describes a lightweight SSH Signature format that is compatible with SSH keys and wire formats. | |||||||||||||
| Longfellow ZK | ||||||||||||||
|
This document defines an algorithm for generating and verifying a succinct non-interactive zero-knowledge argument that for a given input x and a circuit C, there exists a witness w, such that C(x,w) evaluates to 0. The technique here combines the MPC-in-the-head approach for constructing ZK arguments described in Ligero [ligero] with a verifiable computation protocol based on sumcheck for proving that C(x,w)=0. | |||||||||||||
| Per-Flow EVPN Designated Forwarder Election | ||||||||||||||
|
The Ethernet Virtual Private Network (EVPN) solution offers procedures for electing a Designated Forwarder (DF) for multihomed Ethernet Segments. In this context, the Provider Edge (PE) router is responsible for sending Broadcast, Unknown Unicast, and Multicast (BUM) traffic to a multihomed device or network. This applies in cases of an all-active multihomed Ethernet Segment (ES) as well as for BUM and unicast traffic in the case of single-active multihoming. While the Default Algorithm provides an efficient and automated mechanism for selecting the DF across Ethernet Tags within an Ethernet Segment, it does not provide Per-flow DF selection within an EVPN Instance (EVI). This document defines a new DF Election Algorithm that performs Per- flow DF selection by defining a new DF Algorithm value. | |||||||||||||
| Delay-Tolerant Networking QUIC Convergence Layer Protocol Version 1 | ||||||||||||||
|
This document describes a QUIC convergence layer (QUICCL) for Delay- Tolerant Networking (DTN). QUICCL uses BPv7 bundles encoded by the Concise Binary Object Representation (CBOR) as its service data unit being transported and makes use of either QUIC streams (RFC 9001) or QUIC datagrams (RFC 9221) to transport such bundles. QUICCL design is largely based on TCPCLv4 specification (RFC9174), with three significant differences. First, as QUIC incorporates TLS security, all security related parts of TCPCLv4 were dropped. Second, QUICCL provides two new transport services, notified and unreliable, in addition to the reliable service; Third, in the reliable service, by taking advantage of QUIC streams, four levels of priority are offered. | |||||||||||||
| Discovery of Model Context Protocol Servers via DNS TXT Records | ||||||||||||||
|
This document defines a DNS-based mechanism for discovering Model Context Protocol (MCP) servers, the identity of the organisations that operate them, and a cryptographic identity envelope bound to an individual Sovereign-tier ~handle published under the same zone. Three TXT records are defined. _mcp. | |||||||||||||
| OpenA2A Agent Authorization Protocol (AAP) | ||||||||||||||
|
This document defines the OpenA2A Agent Authorization Protocol (AAP), a protocol for authorization in AI agent systems. AAP provides mechanisms for agent identity assertion, scoped capability grants, cross-agent delegation, behavioral attestation, cross-organizational federation, and revocation propagation. AAP is the authorization complement to agent communication protocols such as A2A and the Model Context Protocol, in the same way that OAuth 2.0 complements HTTP for web applications. AAP has two layers. The token model, defined in this document, specifies the AAP credentials and assertions: what they contain, how they are signed, and how they are verified. A companion broker and resolution layer specifies how an agent obtains and exercises a grant without the credential value ever entering the agent's reasoning context. This confinement property, that no secret, temporary credential, or backend identifier reaches the agent or the model behind it, is the primary design goal of the protocol. | |||||||||||||
| The ai-safety.txt Domain AI Safety Declaration | ||||||||||||||
|
This document defines ai-safety.txt, a plain-text declaration format that a domain publishes at a well-known location to communicate its AI-safety posture to autonomous agents and agent-driven browsers. Modeled on the robots.txt convention, an ai-safety.txt file lets a domain assert, in a machine-readable form, whether its content is authored by the domain rather than user-generated, whether that content is hardened against prompt injection, and whether it is rendered consistently to human and agent user agents. The file also carries a security contact, a link to an external verification record, and the date the declaration was last verified. The declarations in an ai-safety.txt file are self-asserted by the publishing domain. This document specifies the file format and its well-known location, and it is explicit that a consuming agent treats a declaration as a hint rather than as proof, verifying it against independent evidence where such evidence is available. | |||||||||||||
| A Perfect Forward Secure Extension to Oblivious HTTP | ||||||||||||||
|
Oblivious HTTP (OHTTP) is a protocol for forwarding encrypted HTTP messages. It does not provide Perfect Forward Secrecy (PFS). Chunked OHTTP expands OHTTP to be suitable for longer-lived streams, but still does not offer PFS. Combined, this is leading sensitive traffic to de deployed at scale without PFS. This document proposes a solution. | |||||||||||||
| The ApertoMemory Format: Portable,Client-Side-Encrypted AI Memory | ||||||||||||||
|
AI assistants and agents accumulate long-term memory about their users. This memory is typically stored in proprietary, provider-held silos: it cannot be moved between tools, its integrity cannot be verified, and its confidentiality depends entirely on the provider. This document specifies the ApertoMemory format: a canonical, signed, client-side-encrypted representation of AI memory objects, together with a portable single-file export container. Memory objects are encoded in deterministic CBOR, signed with COSE_Sign1, and encrypted with COSE_Encrypt0 under keys derived from and controlled by the user. A storage or synchronisation server handling ApertoMemory objects has zero access to their content, authorship, or semantic timestamps. This revision specifies format_version 2, which cryptographically binds every signature to the author it claims and to the cleartext envelope around it, and derives trust from which key verified an object rather than from a declared field. format_version 1, described by earlier revisions of this document, carries a known forgeable- provenance defect and MUST NOT be implemented for new deployments. | |||||||||||||
| NTP Server Identifier Extension | ||||||||||||||
|
This document defines an extension field that allows operators of NTP services the ability to provide additional information about their services to clients which request it. | |||||||||||||
| Problem Statement: Verifiable Human Mandates for Autonomous Agent Actions | ||||||||||||||
|
An autonomous software agent commonly acts under authority a human granted at an earlier moment: the human expresses and authorizes an intent at one time, and the agent executes one or more concrete actions at a later time. The credentials and session state the agent carries at execution time establish that some agent is authorized to act, but they do not establish that this specific action, with these specific parameters, falls within the constraints the human actually signed. As agent autonomy and action throughput grow, the population of executed actions that no human individually bounded grows with it. This document is a problem statement. It characterizes the gap between an authorized agent and an authorized action, explains why existing delegation, logging, and payment-mandate mechanisms do not close it, and states the requirements any solution would have to satisfy. It defines no protocol or mechanism. | |||||||||||||
| Problem Statement: Enrollment and Key-Binding Assumptions in Execution Authority Evidence | ||||||||||||||
|
Any scheme that produces cryptographic evidence of execution authority roots its entire trust chain in an enrollment: the moment at which a key becomes bound to a subject and a device, and at which a verifier begins to treat signatures under that key as meaningful. Every downstream proof is only as trustworthy as that binding. If an attacker substitutes a key of their choosing at enrollment, every subsequent proof verifies correctly and yet attests to the wrong party. This document is a problem statement. It describes the foundational key-substitution threat, records the relevant public facts about consumer-platform biometric and key APIs that bound what an enrollment can establish, and states the assumptions a verifier of execution authority evidence must be able to make about the enrollment its proofs depend on. Specific enrollment ceremonies are out of scope. This document defines no protocol or mechanism. | |||||||||||||
| A Well-Known URI for Discovery of Application-Specific Trust Anchors | ||||||||||||||
|
This document defines the "company-certs" well-known URI in accordance with Request for Comments (RFC) 8615. The URI provides a JSON metadata document that allows an organization to publish application-specific trust anchors and related revocation information for use by consuming applications. The mechanism is intended for scoped trust bootstrapping, such as S/MIME, mutual TLS, or other application-local trust decisions, without modifying the global operating system trust store. | |||||||||||||
| Extending Policy,Addressing and Numbering across Space Ecosystems (EXPANSE): Problem Statement | ||||||||||||||
|
Ongoing IETF work on networking in non-terrestrial and deep-space environments treats addressing, numbering, and registry policy as a greenfield. It is not. Three decades of operational practice, registry governance, and routing security infrastructure exist, and any space-segment architecture that ignores them will recreate, badly, the coordination mechanisms the Internet already has. This document describes the problem and motivates chartering a working group to address it. | |||||||||||||
| PulseProof Sentinel Protocol Specification | ||||||||||||||
|
This document specifies the PulseProof Sentinel Protocol (PPS), an experimental, technology-agnostic protocol for time-bound asymmetric authentication proofs. PPS is not a new cryptographic primitive; it profiles established mechanisms -- Ed25519 signatures, SHA-256 hashing, HKDF key derivation, and deterministic CBOR encoding -- into a compact, interoperable verification model suited to offline, embedded, and non-browser environments where a full WebAuthn ceremony is unavailable. A PPS authentication event produces a Pulse: a signed statement bound to a relying-party identifier, time epoch, monotonic counter, expiration, and optional nonce, context, policy, and transaction data. Because the verifier stores only public keys, PPS removes the shared-secret exposure problem inherent in TOTP. PulseProof Sentinel extends the basic Pulse model with several optional but interoperable security extensions: | |||||||||||||
| Hypercube Data Rotation Protocol (HDRP) for Distributed Integrity and Moving Target Defense | ||||||||||||||
|
This document specifies the Hypercube Data Rotation Protocol (HDRP), an experimental protocol for distributing erasure-coded data shards across nodes arranged in an n-dimensional binary hypercube topology and periodically permuting shard placement through structured rotation operations. Rotations are automorphisms of the hypercube graph, applied on a fixed epoch schedule and committed to a verifiable epoch ledger. The design applies the established principles of hypercube interconnection networks, maximum distance separable (MDS) erasure coding, and moving target defense (MTD) to provide three properties in combination: storage-efficient fault tolerance, continuous cryptographic verifiability, and reduction of the value of static reconnaissance by an adversary. HDRP is designed to integrate with autonomous self-healing pipelines and with dual-layer permanence anchoring (blockchain timestamping and DOI archival) as defined in related documents by the same author. Informally, the rotation mechanism may be visualized as the face turns of a combination puzzle applied to a data topology; this document defines that intuition as a precise algebraic operation. | |||||||||||||
| WebRTC Abridged Roundtrip Protocol (WARP) | ||||||||||||||
|
This document outlines a set of improvements to the WebRTC session setup protocols aimed at significantly reducing connection setup latency. This improved setup mechanism is known as the WebRTC Abridged Roundtrip Protocol (WARP). By addressing inefficiencies within the current multi-protocol handshake process, WARP can reduce setup latency from 6 RTTs to 2 RTTs when its optimizations are used together, with a direct impact on perceived performance and reliability. | |||||||||||||
| Static Context Header Compression and Fragmentation over networks prone to disruptions | ||||||||||||||
|
This document describes the use of SCHC over different network topologies and devices regardless of their capabilities and configurations. The use of SCHC will bring connectivity to devices with disruptive connections caused by restrained use of battery and connectionless setups with long delays and latency. | |||||||||||||
| SSH Strict KEX extension | ||||||||||||||
|
This document describes a small set of modifications to the Secure Shell (SSH) protocol to fix the so-called Terrapin Attack on the initial key exchange. | |||||||||||||
| Join Proxy for Onboarding of Constrained Network Elements | ||||||||||||||
|
This document supports the constrained Bootstrapping Remote Secure Key Infrastructures (cBRSKI) onboarding protocol by adding a required network function, the Join Proxy. This function can be implemented on a constrained node. The goal of the Join Proxy is to help new constrained nodes ("Pledges") securely onboard into a new IP network using the cBRSKI protocol. It acts as a circuit proxy for User Datagram Protocol (UDP) packets that carry the onboarding messages. The solution is extensible to support other UDP-based onboarding protocols as well. The Join Proxy functionality is designed for use in constrained networks, including IPv6 over Low-Power Wireless Personal Area Networks (6LoWPAN) based networks in which the onboarding authority server ("Registrar") may be multiple IP hops away from a Pledge. Despite this distance, the Pledge only needs to use link-local communication to complete cBRSKI onboarding. Two modes of Join Proxy operation are defined, stateless and stateful, to allow different trade-offs regarding resource usage, implementation complexity and security. | |||||||||||||
| H.265 Profile for WebRTC | ||||||||||||||
|
RFC 7742 defines WebRTC video processing and codec requirements, including guidance for endpoints supporting the VP8 and H.264 codecs, which are mandatory to implement. This document defines a profile of RFC 7798 for browsers supporting the H.265 codec. | |||||||||||||
| Proxy MAC-IP Advertisement in EVPNs | ||||||||||||||
|
This document specifies procedures for EVPN PEs connected to a common multihomed site to generate proxy EVPN MAC-IP advertisements on behalf of other PEs to facilitate preservation of ARP/ND state across link or node failures. | |||||||||||||
| A Framework for Fast Reroute with Bit Index Explicit Replication (BIER-FRR) | ||||||||||||||
|
This document provides a framework for the development of Fast Reroute (FRR) mechanisms for Bit Index Explicit Replication forwarding (BIER-FRR). BIER-FRR can provide protection against link or BFR failure by invoking locally pre-determined repair paths that can react in the same time-scales as (unicast) FRR for MPLS or IP networks - "sub 50msec", and without the creation of additional per- path or per-flow state coordinated across multiple routers/LSR. BIER-FRR can be implemed locally within a router/LSR with minimal interoperability requirements against other router/LSR. It can therefore easily be introduced incrementally or selectively where needed. BIER-FRR implementing nodes only need to understand the routing topology of the network for calculation of repair paths and know what type of unicast encapsulation can be used to send ("tunnel") BIER packets to remote BFR. This document proposes and discusses different options for BIER forwardng (BIFT) extensions to support BIER-FRR. These are exemplary and non-normative. This document does not specify any standards or experiments but aims to support such efforts. | |||||||||||||
| Computing-Aware Traffic Steering (CATS) Operations,Administration,and Maintenance (OAM) Framework | ||||||||||||||
|
This document describes the Operations, Administration, and Maintenance (OAM) framework and requirements for Computing-Aware Traffic Steering (CATS). The framework defines the CATS OAM layering model and functional components. It also specifies the requirements to enable fault management and performance monitoring for CATS end- to-end connections across clients, network paths, and service instances. | |||||||||||||
| COSE HPKE PQ & PQ/T Algorithm Registrations | ||||||||||||||
|
This document registers Post-Quantum (PQ) and Post-Quantum/ Traditional (PQ/T) hybrid algorithm identifiers for use with CBOR Object Signing and Encryption (COSE), building on the Hybrid Public Key Encryption (HPKE) framework. | |||||||||||||
| BMP v4: Extended TLV Support for BGP Monitoring Protocol (BMP) | ||||||||||||||
|
Most of the BGP Monitoring Protocol (BMP) message types make provision for data in Type, Length, Value (TLV) format. However, Route Monitoring messages (which provide a snapshot of the monitored Routing Information Base) Stats Reports (which supply periodical counters) and Peer Down messages (which indicate that a peering session was terminated) do not. Supporting (optional) data in TLV format across all BMP message types provides consistent and extensible structures that would be useful among the various use- cases where conveying additional data to a monitoring station is required. This document updates RFC 7854 [RFC7854] to support TLV data in all message types and defines some essential TLVs. Additionally, this document introduces support for enterprise- specific TLVs in the BGP Monitoring Protocol by defining an Enterprise Bit (E-bit) that allows usage of per-vendor Type values. | |||||||||||||
| Logging of routing events in BGP Monitoring Protocol (BMP) | ||||||||||||||
|
The BGP Monitoring Protocol (BMP) does provide for BGP session event logging (Peer Up, Peer Down), state synchronization (Route Monitoring), debugging (Route Mirroring) and Statistics messages, among others. This document defines a new Route Event Logging (REL) message type for BMP with the aim of covering use cases with affinity to alerting, reporting and on-change analysis. | |||||||||||||
| Report from the IAB Workshop on IP Address Geolocation | ||||||||||||||
|
The IAB Workshop on IP Address Geolocation (IP-GEO) was held from December 3-5, 2025, as a three-day virtual meeting. It covered the use cases and background on using IP addresses as indicators of geolocation, explored various problems and challenges that exist in that ecosystem, and discussed future directions and opportunities to improve or replace the current practices. Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions. | |||||||||||||
| A YANG Data Model for OSPF Application-Specific Link Attributes and Flexible Algorithm | ||||||||||||||
|
This document defines a YANG data model to support OSPF Application- Specific Link Attributes and Flexible Algorithm. It also creates the initial version of IANA-maintained YANG modules for IGP Algorithm Types, IGP Metric-Types, and IGP Link Attribute Applications. This document updates RFCs 8665, 9350, and 9843. | |||||||||||||
| Integration of Speech Codec Enhancement Algorithms into the Opus Codec | ||||||||||||||
|
This document proposes a set of requirements for integrating a speech codec enhancement algorithm into the Opus codec [RFC6716]. | |||||||||||||
| ML-KEM and Hybrid Cipher Suites for Messaging Layer Security | ||||||||||||||
|
This document registers new cipher suites for Messaging Layer Security (MLS) based on "post-quantum" algorithms, which are intended to be resilient to attack by quantum computers. These cipher suites are constructed using the new Module-Lattice Key Encapsulation Mechanism (ML-KEM), optionally in combination with traditional elliptic curve KEMs, together with appropriate authenticated encryption, hash, and signature algorithms. | |||||||||||||
| YANG Semantic Versioning | ||||||||||||||
|
This document specifies a YANG extension along with guidelines for applying an extended set of semantic versioning rules to revisions of YANG artifacts (e.g., modules and packages). Additionally, this document defines a YANG extension for controlling module imports based on these modified semantic versioning rules. This document updates RFCs 7950, 9907, and 8525. | |||||||||||||
| Aggregation Trace Option for In-situ Operations,Administration,and Maintenance (IOAM) | ||||||||||||||
|
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. | |||||||||||||
| Extensible Provisioning Protocol (EPP) mapping for DELEG records | ||||||||||||||
|
This document describes an extension to the Extensible Provisioning Protocol ([STD69]) which allows clients to provision DELEG records for domain names. About this draft This note is to be removed before publishing as an RFC. The source for this draft, and an issue tracker, may can be found at https://github.com/gbxyz/epp-deleg-extension. | |||||||||||||
| Commercial National Security Algorithm (CNSA) Suite 2.0 Profile for SSH | ||||||||||||||
|
This document defines a base profile of SSH for use with the US Commercial National Security Algorithm (CNSA) 2.0 Suite, a cybersecurity advisory published by the United States Government which outlines quantum-resistant cryptographic algorithm policy for US national security applications. This profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that employ SSH. It is also appropriate for all other U.S. Government systems that process high-value information. This memo is not an IETF standard, and has not been shown to have IETF community consensus. This profile is made publicly available for use by developers and operators of these and any other system deployments. | |||||||||||||
| In Situ Operations,Administration,and Maintenance (IOAM) Template Option | ||||||||||||||
|
In situ measurement is performed by incorporating performance related information into in-flight data packets. This document specifies a new IOAM Option-Type that has a fixed length and can be updated by transit nodes along the path. It enables lightweight monitoring while maintaining a constant length that is not changed in-flight and is not affected by the number of hops in the network. | |||||||||||||
| Route Server Next Hop Translation | ||||||||||||||
|
With the advent of RFC8950, Internet Exchange Points (IXPs) are enabled to rely solely on IPv6 addresses for adressing in their peering LANs. However, routers not supporting RFC8950 are a technical roadblock. It is easier to extend the capabilities of the IXP Route Server (RS) instead of those of every unsupporting router. Thus, this document introduces the concept of Specific Local Address Tables (SLATs). SLATs translate BGP next hops between all IXP members, regardless of their RFC8950 support, paving the way for IPv6-only IXPs. This document also introduces another, more transparent variant of BGP next hop translation applicable in IXPs which do not employ ARP and ND proxying. This document updates RFC 7947 by specifying an allowed route modification at the route server. | |||||||||||||
| ChainSync: A Synchronization Protocol for Strict Sequential Execution in Linear Distributed Pipelines | ||||||||||||||
|
ChainSync is a lightweight application-layer protocol that runs over reliable TCP connections to synchronize a fixed linear chain of distributed processes such that they execute their local tasks in strict sequential order and only after every process in the chain has confirmed it is ready. The protocol has four phases: 1) a forward "readiness" wave, 2) a backward "start" wave, 3) a forward "execution" wave, and 4) a backward exit wave. The design guarantees strict ordering even when nodes become ready at very different times and requires only point-to-point TCP connections along the chain, thus no central coordinator is needed. | |||||||||||||
| A SCITT Profile for Verifiable Audit Trails in Algorithmic Trading: The VeritasChain Protocol (VCP) | ||||||||||||||
|
This document defines a profile of the SCITT (Supply Chain Integrity, Transparency, and Trust) architecture for creating tamper-evident audit trails of AI-driven algorithmic trading decisions and executions. The VeritasChain Protocol (VCP) applies the SCITT framework to address the specific requirements of financial markets, including high-precision timestamps, regulatory compliance considerations (EU AI Act, MiFID II), and privacy-preserving mechanisms (crypto-shredding) compatible with GDPR. This profile specifies how VCP events are encoded as SCITT Signed Statements, registered with Transparency Services, and verified using COSE Receipts. It further defines SCITT conformance profiles for interoperability and an ERASURE event type that records crypto- shredding operations as immutable audit events. About This Document This note is to be removed before publishing as an RFC. The latest version of this document, along with implementation resources and test vectors, can be found at https://github.com/veritaschain/vcp-spec. Discussion of this document takes place on the SCITT Working Group mailing list ([email protected]). Changes from -02: * Updated to align with VCP Specification v1.2 * Added SCITT Alignment Object and conformance profiles (Section 4.4) * Added ERASURE event type recording crypto-shredding operations (Section 6.3) * Corrected the post-quantum SignAlgo registry value from DILITHIUM3 to DILITHIUM2 (ML-DSA, FIPS 204) * PolicyID examples migrated to the Issuer Domain + Local ID naming convention defined in VCP v1.2 | |||||||||||||
| On the Relationship Between Remote Attestation and Behavioral Evidence Recording | ||||||||||||||
|
This document provides an informational discussion of the conceptual relationship between remote attestation, as defined in RFC 9334 (RATS Architecture), and behavioral evidence recording mechanisms. It observes that these two verification capabilities address fundamentally different questions - attestation addresses "Is this system in a trustworthy state?" while behavioral evidence addresses "What did the system actually do?" - and discusses how they could conceptually complement each other in accountability frameworks. This document is purely descriptive: it does not propose any modifications to RATS architecture, define new mechanisms or protocols, or establish normative requirements. It explicitly does not define any cryptographic binding between attestation and behavioral evidence. | |||||||||||||
| Verifiable AI Provenance Framework (VAP): An Architectural Framework for Evidentiary-Grade AI Decision Trails | ||||||||||||||
|
Automated decision-making systems, including AI and algorithmic systems in critical infrastructure, currently lack standardized mechanisms for producing evidentiary-grade provenance records that can withstand independent verification. Traditional logging approaches fail to provide the cryptographic guarantees required for regulatory compliance, forensic investigation, and cross- organizational accountability. This document describes the Verifiable AI Provenance Framework (VAP), an architectural framework that defines requirements for producing verifiable decision trails using existing IETF security technologies. VAP does not define new protocols or cryptographic primitives; rather, it provides an architectural coordination layer that enables domain-specific profiles to leverage Supply Chain Integrity, Transparency and Trust (SCITT), Remote Attestation Procedures (RATS), CBOR Object Signing and Encryption (COSE), and related IETF work in a consistent manner. This document is intended to frame the problem space and facilitate discussion about whether architectural coordination work is needed in this area. | |||||||||||||
| Benchmarking Methodology for Route Origin Validation (ROV) | ||||||||||||||
|
This document defines a benchmarking methodology for routers that implement Route Origin Validation (ROV). The methodology focuses on device-level behavior, including processing of validated Route Origin Authorization (ROA) payload (VRP) updates, the interaction between ROV and BGP, resource utilization, and the scalability of ROV under varying operational conditions. The procedures described here follow the principles and constraints of the Benchmarking Methodology Working Group (BMWG) and are intended to produce repeatable and comparable results across implementations. | |||||||||||||
| QUIC Alternative Server Address Frames | ||||||||||||||
|
This document specifies an extension to QUIC that allows a server to advertise a prioritized set of alternative addresses. This allows a client to migrate the connection as the availability or preference of server addresses changes. | |||||||||||||
| Observations on the Reachability and Evasion of Packets with IPv6 Extension Headers on the Internet | ||||||||||||||
|
IPv6 Extension Headers (EHs) are designed to provide protocol flexibility and support for emerging features, while maintaining a concise base header and efficient processing. In practice, their reachability is affected by middlebox handling along the path, and their flexibility also introduces security considerations. This document presents observations from a comprehensive, large-scale measurement study of IPv6 Extension Header path traversal across more than 23,000 autonomous systems. Using a feedback-driven measurement framework called 6Travel, the reachability of 11 common IPv6 Extension Headers is measured over ICMPv6, TCP, and UDP. The measurements indicate a change relative to earlier work: contrary to past observations of heavy filtering, specific Extension Headers now achieve reachability comparable to plain traffic. Two distinct forms of policy ossification are observed across industry categories, together with widespread potential Extension-Header-based firewall evasion signatures in nearly 5,000 autonomous systems, particularly under TCP and UDP. These signatures appear consistent with a combination of implementation flaws and security misconfigurations, spanning both on-path and host-side firewalls. | |||||||||||||
| Maximum Number of Paths Reached Notification for BGP | ||||||||||||||
|
This document defines a new BGP Cease NOTIFICATION message subcode, "Maximum Number of Paths Reached", used when a BGP speaker terminates a peering because the number of paths received from a neighbor, as permitted by BGP ADD-PATH, exceeds a locally configured upper bound. That bound may be applied on a per-prefix basis or as an aggregate limit across an address family. | |||||||||||||
| 2-Phase HTTP Protocol for Distributed Transaction Tracking (2PHP-DTT) | ||||||||||||||
|
This document specifies the 2-Phase HTTP Protocol for Distributed Transaction Tracking (2PHP-DTT), a backward-compatible, opt-in extension to HTTP mutation semantics that introduces a two-phase handshake at service request boundaries. 2PHP ensures that a mutation request is durably registered on both the client and the server before any processing commences, addressing a structural gap in existing HTTP REST semantics where no standard mechanism exists to confirm bilateral intent registration prior to execution. The acronym DTT expands to Distributed Transaction Tracking. 2PHP is not Two-Phase Commit (2PC). Microservices architectures deliberately avoid the cross-service locking and blocking that 2PC requires. 2PHP standardizes the intent-tracking pattern that implementations currently build ad hoc, providing a common wire contract and a queryable ledger of registered intent without introducing a distributed transaction coordinator. A primary motivator for this work is the growing use of agent-driven HTTP invocations, including Model Context Protocol (MCP) tool calls and agent-to-agent (A2A) integrations. When an agent does not receive a response, its default behavior is to retry. Absent a queryable record of prior intent, retries pile onto services that may already be overwhelmed, causing deadlocks, resource exhaustion, and full outages. 2PHP's Phase 1 ledger record enables the client to inspect whether the prior intent was registered before issuing a retry, breaking the retry-storm feedback loop at the protocol layer. 2PHP operates at the HTTP protocol layer, requires no new transport mechanisms, and is composable across independently operating service boundaries. This document further defines a standardized Intent Ledger model for durable, queryable, cross-service correlation of request intent, distinct from execution telemetry provided by distributed tracing systems. This document does not claim novelty over existing intent-tracking, idempotency, or distributed-tracing patterns. Its goal is to define a common HTTP-layer wire contract and a common ledger schema so that a single reference implementation--packaged as a library or framework module--can serve multiple deployments, replacing the per-team ad hoc implementations that currently reinvent this pattern. This document defines the protocol headers, phase state machine, idempotency and replay behavior, the three-tier Intent Ledger architecture, cross-service correlation model, and IANA registration of the associated HTTP header fields. 2PHP-DTT targets the synchronous request-response boundary, where no standard acknowledgement primitive exists to confirm bilateral intent registration before processing. Asynchronous HTTP patterns -- 202 Accepted with Location-based polling in HTTP Semantics, Prefer: respond-async negotiation, webhooks, and message-broker delivery -- already provide durable acknowledgement of intent by construction, and are therefore out of scope for this specification. | |||||||||||||
| Trustworthy Enrollment of Secure Credentials | ||||||||||||||
|
There is a large class of "RATS-Unaware" Relying Parties (RUPs) that Attesters nevertheless need to interoperate with. Existing deployed services, which precede the introduction of Remote Attestation, are often difficult to change/update in significant ways due to, among other reasons, organizational friction, technological inertia, and regulatory policies. Yet there are significant advantages if workloads can be incrementally updated in the trustworthiness of the platform, without disrupting their clients and servers. This document details a protocol by which Remote Attestattion of Attesters is incorporated into the process of them being provided with Identity Documents (keys or credentials) to authenticate to RUPs. This specification illustrates how the RATS Architecture can be applied to interoperate with RUPs by providing Attesters with such Identity Documents. | |||||||||||||
| Network Hiding Protocol (NHP) Extensions for 5G/6G Service-Based Architectures | ||||||||||||||
|
This document specifies a candidate implementation profile and extension to the evolving Network Hiding Protocol (NHP) standards, designed specifically for autonomous 5G/6G Service-Based Architectures (NHP-SBA). It defines the payload schemas, cryptographic bindings, and state machine workflows necessary to address Policy Enforcement Point (PEP) interoperability surfaces in heterogeneous telecom environments. By leveraging zero-copy FlatBuffers serialization and HTTP/2 Custom Frame Extensions, NHP-SBA enables deterministic, ultra-low-latency safety enforcement for agent-driven RF control loops. | |||||||||||||
| CoAP Extensions for Asynchronous Task Resources | ||||||||||||||
|
Many operations on constrained devices cannot complete within a single CoAP request and response exchange. Examples include firmware installation, diagnostic procedures, commissioning, calibration, and physical actuation. This document defines a common lifecycle model for representing such operations as addressable CoAP Task Resources. It specifies task creation, state monitoring, discovery, cancellation, terminal-state retention, and eventual removal. It also defines a four-part request payload model, identified by the existing CoAP Content-Format Option, for carrying resource operations together with task execution controls. No new CoAP Option is defined. | |||||||||||||
| Redirecting RDAP Queries to Holder-Designated Servers for Subordinate Resources | ||||||||||||||
|
Registration Data Access Protocol (RDAP) queries can be resolved from the IANA bootstrap registries down to the most specific object held by a registry operator's RDAP service. Where the holder of a registered resource maintains registration data for resources subordinate to it, such as DNS names below a registered domain or more-specific networks below an address allocation, and operates a conformant RDAP service for that data, there is currently no discoverable referral from the registry's response to the holder's service. This document describes an optional, holder-designated referral for subordinate resources, carried by a pair of directional RDAP link relations, "rdap-base-down" and "rdap-base-up", whose targets are the base URL of a downstream RDAP service and the base URL of the covering registry service, respectively. The holder- designated subordinate referral is the primary application, but the same relations serve related base-URL discovery needs, including delegated and hybrid RPKI referrals. It is written as input to draft-ietf-regext-rdap-referrals and its content may be merged into that document. | |||||||||||||
| Encrypted Attachments for MLS | ||||||||||||||
|
This document defines random-access authenticated encryption of large write-once files for Messaging Layer Security (MLS) groups. A file is encrypted so that a receiver can decrypt and authenticate any byte range without processing the whole file. The encryption is SEAL- attachment, SEAL's named write-once attachment scheme (raAE), parameterized by the AEAD and key derivation function of the group's MLS cipher suite and keyed from the MLS exporter. The encrypted bytes are carried by any means, and a recipient needs only a small reference (the object's identifier, length, and snapshot value, and an optional locator) to fetch, key, and verify the object. Carrying that reference in an MLS message attributes the object to the member that sent the message. MLS application messages cannot carry large files, and existing attachment encryption produces an opaque, immutable blob with no partial access. This extension supplies the random-access layer those uses need. | |||||||||||||
| Selective Disclosure for Succession Receipts | ||||||||||||||
|
A Succession Receipt proves one completed, policy-gated transfer of authority between autonomous agents, and it is all-or-nothing: whoever holds the receipt holds every claim and every evidence event in it. In regulated deployments the parties entitled to verify a transfer are not all entitled to read it in full — a regulator, a counterparty, and the public each warrant a different view. This document specifies a selective-disclosure form of the receipt: the issuer signs salted commitments to each claim unit and each evidence event, disclosures travel outside the signature, and a projection — the signed envelope plus any subset of the disclosures — still verifies against the one issuer signature. Withholding never breaks the proof, disclosing never re-signs, withheld content remains visibly committed, and a projection that opens every commitment is verifiable to exactly the strength of the underlying receipt. The disclosure mechanism deliberately follows the salted-digest analysis of SD-JWT, restated for plain-JSON documents canonicalized with the JSON Canonicalization Scheme. | |||||||||||||
| Refusal Transparency: Signed,Replay-Resistant Evidence of Refused Agent-System Transitions | ||||||||||||||
|
A governance system for autonomous agents is defined as much by what it refuses as by what it permits, yet refusals are the one behavior vendors only ever assert. A Refusal Digest is a portable, signed JSON document recording one adversarial probe run against a live agent-governance system: for every attack attempted, the system's verbatim refusal ground, the event types the attack would have recorded had it succeeded, and the complete signed event ledger of the attempt — in which the refused transition is provably absent. Digests verify offline, by parties who do not operate the probed system, using only the issuer's public key. From version 0.2, every quantity that varies between runs derives deterministically from a per-run seed carried in the digest, so a relying party can recompute the derivations and a replayed or pre-recorded ledger cannot match a fresh digest. This document specifies the digest wire format, its canonicalization and signature scheme, the seeded-variation derivations, and the verification algorithm. Where succession receipts prove that an agent legitimately became the holder of an authority, refusal digests prove what the governing system declined to let happen. | |||||||||||||
| Semantic Interlingua Layer Protocol (SILP): A Payload Codec for Cross-Model Agent Communication | ||||||||||||||
|
This document specifies the Semantic Interlingua Layer Protocol (SILP), a black-box, text-interface payload codec designed for cross- model agent-to-agent communication. SILP defines a coarse-grained action-slot intermediate representation (IR) as the reference semantic layer and compiles it into multiple pluggable surface frontends -- code-like function-call syntax, pure JSON, natural language, and ML-compressed text. SILP is designed as a payload- layer option within existing agent transport protocols such as the Model Context Protocol (MCP) and Agent-to-Agent (A2A) protocol, which define transport envelopes and capability discovery but leave payload encoding unspecified. SILP provides compile/decode round-trip guarantees for lossless frontends, dynamic frontend negotiation via probe messages, session management with heartbeat renewal, and a verb whitelist verified across six production tokenizers for cross-model token-level stability. This document is a product of independent research and is not an IETF standard. It is published as an Informational document to establish a stable reference for implementers. | |||||||||||||
| PSI-03: VPP Dispatch Conformance Attestation | ||||||||||||||
|
PSI-03 specifies a portable, Ed25519-signed bond that anchors a registered NDIS practitioner's professional identity to a DID- compatible decentralised identifier without requiring a central registry. The bond enables cross-provider, cross-border practice verification while preserving privacy and issuer sovereignty. | |||||||||||||
| PSI-07: Organic Production Attestation | ||||||||||||||
|
PSI-07 defines a standard signal format for regulatory events detected by automated monitoring systems. The format is a signed JSON envelope carrying the event classification, evidence hash, and jurisdiction code, enabling autonomous reporting to one or more regulators without human intervention. | |||||||||||||
| Secure SMTP | ||||||||||||||
|
SMTP [RFC5321] uses opportunistic TLS to optionally protect transport sessions. Secure SMTP uses mandatory TLS on all connections. It also provides a method for SMTP clients to locate Secure SMTP servers. | |||||||||||||
| DANE-Anchored Identity for Network Clients,Devices,and Autonomous Agents | ||||||||||||||
|
A rapidly growing set of protocols for autonomous agents, connected devices, and machine workloads bootstraps trust in an endpoint's public key over the Web PKI together with an HTTPS .well-known fetch, a bespoke certificate authority, or a centralized registry. These approaches inherit domain-takeover exposure, depend on a reachable call-home endpoint, are not verifiable across organizational boundaries, and frequently provide no timely revocation. This document describes a complementary identity model in which an endpoint's key is anchored directly in DNSSEC-signed DNS using DANE (a TLSA record), bound to a routable address whose reverse and forward names are served from a signed zone, and described by RDAP. The model, consistent with the architecture developed in the DANE Authentication for Network Clients Everywhere (DANCE) working group, lets any relying party verify an endpoint's identity from stock DNS tooling with no account or private trust root, and lets the identity's holder revoke it worldwide at DNS TTL. It is intended as an anchor that existing agent-, device-, and content-identity schemes can adopt without abandoning their own transports or object formats. | |||||||||||||
| A YANG Data Model for Link Quality Telemetry in CLOS Data Center Fabrics | ||||||||||||||
|
This document defines a YANG data model for real-time link quality telemetry in multi-stage CLOS (leaf-spine) data center fabrics. The data model provides a vendor-agnostic representation of link congestion state, enabling next-next-hop (NNH) path quality visibility required for adaptive routing in AI/ML training networks. The link quality advertisement is modeled as a YANG data structure, making the model directly usable with any transport. The data model is deliberately decoupled from any transport. A lightweight UDP transport binding for disseminating the modeled data is specified in a companion document; additional transport bindings may be specified in future documents. | |||||||||||||
| A UDP Transport Binding for Link Quality Telemetry in CLOS Data Center Fabrics | ||||||||||||||
|
This document specifies a UDP transport binding for the Link Quality Telemetry data model. The binding disseminates YANG-modeled link quality data between directly connected switches in multi-stage CLOS (leaf-spine) data center fabrics using a compact, fixed-offset binary encoding designed for forwarding-plane (ASIC) generation and consumption, achieving sub-100 microsecond notification latency on forwarding engines capable of data-plane UDP processing. The encoded payload can be carried natively on a dedicated UDP port or as a TLV within the Router-Info advertisement mechanism; both carriages share a byte-identical payload. The data model, receiver processing rules, and requirements applicable to all transport bindings are defined in a companion document. | |||||||||||||
| CATS Client Service Request Packet Format (IPv6 Extension Header and Payload-Based Carriage of CS-ID and Network/Computing Requirement Parameters) | ||||||||||||||
|
This document specifies two complementary mechanisms for carrying the CATS Service Identifier (CS-ID) and network/computing requirement parameters in client service request packets within the Computing- Aware Traffic Steering (CATS) framework. Mode A uses IPv6 Extension Headers to carry CS-ID and requirement parameters as hop-by-hop or destination options, enabling in-band signaling that is visible to all CATS-aware network nodes along the path. Mode B uses a payload-based TLV structure that is transport- protocol agnostic and can be used with both IPv4 and IPv6, as well as with encrypted transports. The document defines the Virtual Placeholder Address (VPA) prefix requirements, the CATS Service Request Extension Header (CSREH) format, the CATS Service Request TLV format, and the CATS_PACKET_IN process for handling these packets at ingress CATS-Forwarders. | |||||||||||||
| Test PSI Submission | ||||||||||||||
|
Test submission. | |||||||||||||
| AgentOps Observability for Failure Detection and Attribution | ||||||||||||||
|
Agentic systems execute tasks through long-running sequences of model inference, planning, delegation, tool use, state updates, verification, and recovery. Conventional metrics, logs, and traces can identify a failed request but often cannot determine whether a failure is emerging, which actor introduced it, or which earlier event was its root cause. This document specifies an AgentOps observability event model and processing requirements for interoperable early failure detection and post-failure root-cause attribution. It defines common event, anomaly, assertion, and diagnosis records; distinguishes causal origins from propagated symptoms; and provides the evidence model required by separate benchmarks of detection lead time, responsible-actor attribution, and root-cause localization. The model is transport-neutral and can be carried by existing telemetry systems. | |||||||||||||
| Merkle Tree Agent Certificates (MTAC): Batch-Issued Post-Quantum Identity Credentials for AI Agents | ||||||||||||||
|
This document specifies Merkle Tree Agent Certificates (MTAC), a credential format and issuance profile in which a certificate authority commits a batch of AI agent identity credentials to a Merkle tree, signs only the tree head with the post-quantum signature algorithm ML-DSA-65, and distributes a per-credential inclusion proof. A relying party verifies a credential offline against the signed tree head without contacting the issuer. Each batch root is additionally co-signed by an independently keyed witness, providing per-batch integrity and continuity attestation, and its root can be corroborated against an independent public record. MTAC defines the leaf structure, its deterministic encoding, the leaf hash preimage, the signed tree head wire format, the witness co- signature, and an optional challenge-response proof of possession that binds a credential to a holder key. Test vectors are provided. This document specifies a credential issuance and verification mechanism. Declared scopes carried in a credential are self-reported parameters recorded at issuance; this document does not specify a runtime authorization mechanism. | |||||||||||||
| HyMRPL: Per-Node Hybrid Mode of Operation and Inter-DODAG Bridge Mechanism for RPL | ||||||||||||||
|
The Routing Protocol for Low-Power and Lossy Networks (RPL), defined in RFC 6550, enforces a single Mode of Operation (MOP) across all nodes within a DODAG. This rigidity prevents heterogeneous devices from independently selecting their forwarding behavior and creates permanent isolation between DODAGs operating with different MOPs. This document defines HyMRPL, a Hybrid Mode of Operation (MOP=6) that enables per-node functional profiles within a single DODAG. Nodes independently adopt Class-S (storing-like) or Class-N (non-storing- like) behavior without modifying RPL control message formats. Additionally, this document specifies an Inter-DODAG Bridge mechanism that uses MOP Extension (MOPex) signaling to interconnect DODAGs with different MOPs through cross-DODAG route injection. The mechanisms introduce zero additional control messages, maintain full backward compatibility via the J-flag in extended options, and have been validated with a functional implementation demonstrating 100% packet delivery ratio across MOP boundaries. | |||||||||||||
| Project Looking Glass: An Integrative Framework for Verifiable Observability and Autonomous Self-Healing Across the Reilly Protocol Suite | ||||||||||||||
|
This document specifies Project Looking Glass, an integrative framework that unifies the Reilly Protocol Suite -- including the REM Protocol, WebProof, PLPES, CTS, AIMED/AIMED-EVAL, UAEMF, RMRP, SkyLedger, RLT Genesis, Machine-Web Symbiosis (MWS), and Cognitive Sovereignty -- into a single verifiable observability and autonomous self-healing architecture. Project Looking Glass defines how a live production system, exemplified by the REM Protocol 14-agent autonomous pipeline, continuously inspects its own state ("the looking glass"), proves that state using Dual-Layer Digital Permanence (Bitcoin blockchain timestamping via OpenTimestamps plus DOI archival), and autonomously detects, diagnoses, and repairs faults without human intervention while preserving human epistemic authority as defined by the Cognitive Sovereignty framework. A complete step-by-step implementation process is provided. | |||||||||||||
| Controlling Network Enrollment in RPL networks | ||||||||||||||
|
The Routing Protocol for Low-Power and Lossy Networks (RPL) manages the routing topology but lacks a mechanism to globally regulate how many new nodes, known as Pledges, can join a node in a 6TiSCH network at any given time. Currently, Join Proxies (6LowPAN Routers) make local decisions about whether to facilitate a Pledge's enrollment based only on their immediate resources. This document introduces RPL extensions to ensure that enrollment remains orderly, prevents localized congestion at specific Join Proxies, and allows the network to stay within its operational capacity limits. | |||||||||||||
| Personal Assertion Token (PaSSporT) Extension for Signature-based Handling of Asserted information using toKENs (SHAKEN) | ||||||||||||||
|
This document extends the Personal Assertion Token (PASSporT), which is a token object that conveys cryptographically signed information about the participants involved in communications. The extension is defined based on the "Signature-based Handling of Asserted information using toKENs (SHAKEN)" specification by the ATIS/SIP Forum IP-NNI Task Group. It provides both (1) a specific set of levels of confidence in the correctness of the originating identity of a call originated in a SIP-based telephone network as well as (2) an identifier that allows the Service Provider (SP) to uniquely identify the origin of the call within its network. This document obsoletes RFC8588. | |||||||||||||
| Concise Diagnostic Notation (CDN) | ||||||||||||||
|
This document formalizes and consolidates the definition of the Concise Diagnostic Notation (CDN) of the Concise Binary Object Representation (CBOR), addressing implementer experience. Replacing CDN's previous informal descriptions, it updates RFC 8949, obsoleting its Section 8, and RFC 8610, obsoleting its Appendix G. It also specifies registry-based extension points and uses them to support text representations such as of epoch-based dates/times and of IP addresses and prefixes. // (This cref will be removed by the RFC editor:) This is the // editorial round focusing on editorial cleanup, specifically where // that causes moving text around. It does not have WG input yet on // any renaming decisions (CDN name, b1/t1 name), ABNF cleanup, or // Rohan's suggestion to fix the questionable figure in 3.8. | |||||||||||||
| CDNI Delivery Metadata | ||||||||||||||
|
This specification adds to the core set of configuration metadata defined in RFC8006, providing delivery metadata to define traffic types, request delegation behavior and CDN transport arrangements selection of a downstream CDN. | |||||||||||||
| Deterministic Networking (DetNet) Data Plane - Tagged Cyclic Queuing and Forwarding (TCQF) for bounded latency with low jitter in large scale DetNets | ||||||||||||||
|
This memo specifies a forwarding method for bounded latency and bounded jitter for Deterministic Networks and is a variant of the IEEE TSN Cyclic Queuing and Forwarding (CQF) method. Tagged CQF (TCQF) supports more than 2 cycles and indicates the cycle number via an existing or new packet header field called the tag to replace the cycle mapping in CQF which is based purely on synchronized reception clock. This memo standardizes TCQF as a mechanism independent of the tagging method used. It also specifies tagging via the (1) the existing MPLS packet Traffic Class (TC) field for MPLS packets, (2) the IP/IPv6 DSCP field for IP/IPv6 packets, and (3) a new TCQF Option header for IPv6 packets. Target benefits of TCQF include low end-to-end jitter, ease of high- speed hardware implementation, optional ability to support large number of flow in large networks via DiffServ style aggregation by applying TCQF to the DetNet aggregate instead of each DetNet flow individually, and support of wide-area DetNet networks with arbitrary link latencies and latency variations as well as low accuracy clock synchronization. | |||||||||||||
| Deterministic Networking (DetNet) Data Plane - guaranteed Latency Based Forwarding (gLBF) for bounded latency with low jitter and asynchronous forwarding in Deterministic Networks | ||||||||||||||
|
This memo proposes a mechanism called "guaranteed Latency Based Forwarding" (gLBF) as part of DetNet for hop-by-hop packet forwarding with per-hop deterministically bounded latency and minimal jitter. gLBF is intended to be useful across a wide range of networks and applications with need for high-precision deterministic networking services, including in-car networks or networks used for industrial automation across on factory floors, all the way to ++100Gbps country-wide networks. Contrary to other mechanisms, gLBF does not require network wide clock synchronization, nor does it need to maintain per-flow state at network nodes, avoiding drawbacks of other known methods while leveraging their advantages. Specifically, gLBF uses the queuing model and calculus of Urgency Based Scheduling (UBS, [UBS]), which is used by TSN Asynchronous Traffic Shaping [TSN-ATS]. gLBF is intended to be a plug-in replacement for TSN-ATN or as a parallel mechanism beside TSN-ATS because it allows to keeping the same controller-plane design which is selecting paths for TSN-ATS, sizing TSN-ATS queues, calculating latencies and admitting flows to calculated paths for calculated latencies. In addition to reducing the jitter compared to TSN-ATS by additional buffering (dampening) in the network, gLBF also eliminates the need for per-flow, per-hop state maintenance required by TSN-ATS. This avoids the need to signal per-flow state to every hop from the controller-plane and associated scaling problems. It also reduces implementation cost for high-speed networking hardware due to the avoidance of additional high-speed speed read/write memory access to retrieve, process and update per-flow state variables for a large number of flows. | |||||||||||||
| Domain Name Specification for DKIM2 | ||||||||||||||
|
The updated DomainKeys Identified Mail (DKIM2) permits an organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message through a digital signature. This is done by publishing to Domain Name Service (DNS) of the domain a public key that is then associated to the domain and where messages can be signed by the corresponding private key. Assertion of responsibility is validated through a cryptographic signature and by querying the Signer’s domain directly to retrieve the appropriate public key. This document describes DKIM2 DNS record format and how to find the record. | |||||||||||||
| DTNMA Application Resource Identifier (ARI) | ||||||||||||||
|
This document defines the structure, format, and features of the naming scheme for the objects defined in the Delay-Tolerant Networking Management Architecture (DTNMA) Application Management Model (AMM), in support of challenged network management solutions described in the DTNMA document. This document defines the DTNMA Application Resource Identifier (ARI), using a text-form based on the common Uniform Resource Identifier (URI) and a binary-form based on Concise Binary Object Representation (CBOR). These meet the needs for a concise, typed, parameterized, and hierarchically organized set of managed data elements. | |||||||||||||
| DTNMA Application Management Model (AMM) and Data Models | ||||||||||||||
|
This document defines a model that captures the information necessary to asynchronously manage applications within the Delay-Tolerant Networking Management Architecture (DTNMA). This model provides a set of common managed object types, data types and structures, and a template for information needed within each application data model. The built-in definitions are made to be extensible by applications without needing to modify core Agent or Manager behavior. | |||||||||||||
| DTNMA Application Data Model (ADM) YANG Syntax | ||||||||||||||
|
This document defines a concrete syntax for encoding a Delay-Tolerant Networking Management Architecture (DTNMA) Application Data Model (ADM) using the syntax and modular structure, but not the full data model, of YANG. Extensions to YANG are defined to capture the specifics needed to define DTNMA Application Management Model (AMM) objects and to use the Application Resource Identifier (ARI) data- value syntax. | |||||||||||||
| DTNMA Asynchronous Management Protocol (AMP) | ||||||||||||||
|
This document defines a messaging protocol for the Delay-Tolerant Networking (DTN) Management Architecture (DTNMA) Asynchronous Management Model (AMM) and a transport binding for exchanging those messages over a network. This Asynchronous Management Protocol (AMP) does not require transport-layer sessions, operates over unidirectional links, and seeks to reduce the energy and compute power necessary for performing remote management of resource constrained devices possibly over challenged networks. | |||||||||||||
| Procedures for Handling Liaison Statements to and from the IETF | ||||||||||||||
|
This document describes the procedures for generating and handling liaison statements between the IETF and other Standards Development Organizations (SDOs), so that the IETF can effectively collaborate with other organizations in the international standards community. | |||||||||||||
| IAB Processes for Management of IETF Liaison Relationships | ||||||||||||||
|
This document describes the procedures used by the Internet Architecture Board (IAB) to establish and maintain formal liaison relationships between the IETF and other Standards Development Organizations (SDOs), consortia and industry fora. This document also outlines the expectations of the IAB in establishing formal liaison relationships and describes the responsibilities of IAB- appointed IETF liaison managers. | |||||||||||||
| Update of the Simple Two-way Active Measurement Protocol Class-of-Service Extension - ECN | ||||||||||||||
|
The Simple Two-Way Active Measurement Protocol (STAMP) enables one- way and round-trip measurement of network metrics between IP hosts, and has a facility for defining optional extensions. This document updates the definition of the Class of Service TLV (originally defined in RFC 8972) to enable the measurement of manipulation of the value of the Explicit Congestion Notification (ECN) field of the IP header by middleboxes between two STAMP hosts, and to enable discovery and measurement of paths that provide differential treatment of packets depending on the value of their ECN field. | |||||||||||||
| JSON Proof Token and CBOR Proof Token | ||||||||||||||
|
JSON Proof Token (JPT) is a compact, URL-safe, privacy-preserving representation of claims to be transferred between three parties. The claims in a JPT are encoded as base64url-encoded JSON objects that are used as the payloads of a JSON Web Proof (JWP) structure, enabling them to be digitally signed and selectively disclosed. JPTs also support reusability and unlinkability when using Zero-Knowledge Proofs (ZKPs). A CBOR-based representation of JPTs is also defined, called a CBOR Proof Token (CPT). It has the same properties as JPTs, but uses the JSON Web Proof (JWP) CBOR Serialization, rather than the JSON-based JWP Compact Serialization. | |||||||||||||
| JSON Web Proof | ||||||||||||||
|
The JOSE set of standards established JSON-based container formats for Keys, Signatures, and Encryption. They also established IANA registries to enable the algorithms and representations used for them to be extended. Since those were created, newer cryptographic algorithms that support selective disclosure and unlinkability have matured and started seeing early market adoption. The COSE set of standards likewise does this for CBOR-based containers, focusing on the needs of environments which are better served using CBOR, such as constrained devices and networks. This document defines a new container format similar in purpose and design to JSON Web Signature (JWS) and COSE Signed Messages called a _JSON Web Proof (JWP)_. Unlike JWS, which integrity-protects only a single payload, JWP can integrity-protect multiple payloads in one message. It also specifies a new presentation form that supports selective disclosure of individual payloads, enables additional proof computation, and adds a Presentation Header to prevent replay. | |||||||||||||
| JSON Proof Algorithms | ||||||||||||||
|
The JSON Proof Algorithms (JPA) specification registers cryptographic algorithms and identifiers to be used with the JSON Web Proof, JSON Web Key (JWK), and COSE specifications. It defines IANA registries for these identifiers. | |||||||||||||
| Low Overhead Media Container | ||||||||||||||
|
This specification describes a Low Overhead Media Container (LOC) format for encoded and encrypted audio and video media data to be used primarily for interactive Media over QUIC Transport (MOQT). It may be used in the MOQT Streaming Format (MSF) specification, which defines a catalog format for publishers to declare and describe their LOC tracks and for subscribers to consume them. Examples are also provided for building media applications using LOC and MOQT. | |||||||||||||
| NETCONF Extensions to Support List Pagination | ||||||||||||||
|
This document defines a mapping of the list pagination mechanism defined in [I-D.ietf-netconf-list-pagination] to NETCONF [RFC6241]. This document updates [RFC6241], to augment the | |||||||||||||
| RESTCONF Extensions to Support List Pagination | ||||||||||||||
|
This document defines a mapping of the list pagination mechanism defined in [I-D.ietf-netconf-list-pagination] to RESTCONF [RFC8040]. This document updates RFC 8040, to declare "list" and "leaf-list" as valid resource targets for the RESTCONF GET operation, to define GET query parameters necessary for list pagination, and to define a media-type for XML-based lists. | |||||||||||||
| YANG Module Versioning Requirements | ||||||||||||||
|
This document describes the problems that can arise because of the YANG language module update rules, that require all updates to YANG module preserve strict backwards compatibility. It also defines the requirements on any solution designed to solve the stated problems. This document does not consider possible solutions, nor endorse any particular solution. | |||||||||||||
| LISP for Satellite Networks | ||||||||||||||
|
This specification describes how the LISP architecture and protocols can be used over satellite network systems. The LISP overlay runs on earth using the satellite network system in space as the underlay. | |||||||||||||
| A Task Segmentation Framework for Computing-Aware Traffic Steering | ||||||||||||||
|
This document proposes an extension to the Computing-Aware Traffic Steering (CATS) framework by introducing a task segmentation module. This extension enables the CATS framework to handle divisible computing requests by breaking them down into smaller computational units, referred to as "Task". The document focuses on two primary task segmentation modes: the distributed mode and the chain- structured Directed Acyclic Graph (DAG) model, providing detailed workflows for each. | |||||||||||||
| Multipath Traffic Engineering for Segment Routing | ||||||||||||||
|
This document describes a mechanism to achieve Multipath Traffic Engineering for Segment Routing based networks. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Source Packet Routing in Networking Working Group mailing list ([email protected]), which is archived at https://mailarchive.ietf.org/arch/browse/spring/. Source for this draft and an issue tracker can be found at https://github.com/astone282/draft-stone-spring-mpte-sr. | |||||||||||||
| Semantic Definition Format (SDF) for API translation | ||||||||||||||
|
This document defines an extension to the Semantic Definition Format (SDF) that enables API translation between applications and devices. The translation enables clarification of complex syntax for a service or device to utilize a different API from the one that was first designed to use. | |||||||||||||
| Protocol for Transposed Transactions over HTTP | ||||||||||||||
|
This document specifies the Protocol for Transposed Transactions over HTTP (PTTH), an HTTP extension that allows a backend server to establish an HTTP connection to a reverse proxy and transpose the flow of HTTP requests. The reverse proxy then sends requests to the backend server over the resulting transposed channel. This extension lets backend servers behind restrictive firewalls accept HTTP traffic through reverse proxies without changing firewall settings and with minimal overhead. | |||||||||||||
| (Potato) - HTTP,Inverted | ||||||||||||||
|
This document defines 🥔 (P̷̙̩̩̖̦̦̮̲͖͗̅͋̇̊o̷̢͚̼͎͉̙̩̻̱̊̂̽̀̅̚͟͡t̤̐̇̋̍̑̓̏̕͝ ̴̖̞͖̰ȁ̷̩̹͎͖̮͚͋͑̏̀̓̂͡͞ͅt̗̹̩̭͈̳̫͈͈̒͆̃̿̚͝͠o͖͓͈̩̻̤͎͐̐͐̅̂́͟), a suite of reversed versions of HTTP for origin servers. | |||||||||||||
| Log More Routing Events in the BGP Monitoring Protocol (BMP) | ||||||||||||||
|
The Route Event Logging (REL) message is defined in [I-D.ietf-grow-bmp-rel], which enables monitored routers to report event-driven operational data to BMP collectors. This document defines additional event code points for BGP FlowSpec RFC8955 [RFC8956] and BGP SR Policies [I-D.ietf-idr-sr-policy-safi]. These extensions enhance monitoring visibility for policy execution failures and improve network operation and troubleshooting capabilities. | |||||||||||||
| Requiring Support for Appealing to the IESG and IAB | ||||||||||||||
|
RFC2026 describes the procedure for appealing decisions or process failures to the IESG and the IAB. This document updates RFC2026 and requires that an appellant must first gain support for their appeal before an appeal may be considered by the body it is submitted to. | |||||||||||||
| Export of BGP VPN Information in IPFIX | ||||||||||||||
|
This document introduces new IP Flow Information Export (IPFIX) information elements to carry information that can be used to identify the egress PE in BGP VPN scenarios. | |||||||||||||
| Consideration of Applying Zero Trust Philosophy in Network Infrastructure | ||||||||||||||
|
Network security has traditionally relied on a perimeter-centric model, assuming that traffic originating within the network can be implicitly trusted. This model is fundamentally challenged by modern, highly distributed, and software-driven network environments where internal compromise is a realistic and high-impact threat scenario. This document examines the critical limitations of edge- only network protection and the systemic risks that arise from insufficient internal validation. Once the network perimeter is bypassed, the absence of internal protection mechanisms facilitates rapid lateral movement, impersonation of network entities, and interference with critical control and management functions. The document argues that Zero Trust (ZT) principles, which mandate continuous, dynamic verification of all entities and communications regardless of network location, are necessary to address contemporary threat models. Deploying ZT-aligned network protection mechanisms beyond the network edge is essential to build resilient, controllable, and trustworthy networks. | |||||||||||||
| Agent Interaction & Delegation Protocol (AIDP) | ||||||||||||||
|
This document specifies the Agent Interaction & Delegation Protocol (AIDP), a control-plane protocol for secure, auditable, and interoperable software agents. AIDP defines standardized mechanisms for expressing intent, enforcing authority, delegating capabilities, executing actions, and binding execution results to agent reasoning across heterogeneous systems and administrative domains. This version introduces a normative Intent Lifecycle Model, including Human Approval Gates and support for long-running agent executions, defines version negotiation and capability discovery, clarifies the relationship of AIDP to the Model Context Protocol (MCP) and the Agent2Agent (A2A) protocol, and establishes extensibility registries. Non-normative deployment material has been moved to informative appendices. | |||||||||||||
| Operational Monitoring of RPKI Repositories' Health and Safety | ||||||||||||||
|
The Resource Public Key Infrastructure (RPKI) relies on a globally distributed set of repositories to deliver signed routing authorization data to Relying Parties (RPs). Internet Service Providers (ISPs) depend on RPs to collect RPKI objects from distributed repositories and validate them cryptographically, resulting in hundreds of thousands of Validated Route origin authorization Payloads (VRPs). Nevertheless, even with multiple RPs deployed, ISPs have limited insight into the operational health and reliability of each Publication Point (PP). When a large number of RPKI objects change unexpectedly, operators often lack sufficient visibility into individual PPs to determine the source of the changes. Consequently, ISPs cannot easily determine whether these changes are caused by routine updates, malicious behavior, or underlying repository instability. This document provides operational guidance for monitoring the health and safety of RPKI repositories on a per-publication point basis. It defines measurable indicators related to reachability, availability, and content integrity, and explains how these metrics can be used to detect degraded performance or potentially unsafe repository behavior. The document discusses and provides recommendations for repositories alerting and operational response. The goal is to improve the transparency, operational availability and security of the RPKI ecosystem. | |||||||||||||
| Agentic Intent Network (AIN): A Routing-Based Architecture for AI Agent Coordination at Scale | ||||||||||||||
|
The rapid proliferation of autonomous AI agents across enterprise and Internet-scale deployments creates a structural challenge that existing agent frameworks cannot address: how to enable any agent to discover and invoke any other agent's capabilities without pre- established bilateral integration, across organizational boundaries, at Internet scale. This document presents the Agentic Intent Network (AIN) as an architecture-level model for open, heterogeneous, dynamically evolving multi-agent coordination. It defines problem drivers, architectural and underlay requirements, architectural components, design invariants, scope boundaries, and a research agenda for the NMRG. | |||||||||||||
| Feed Menus | ||||||||||||||
|
This specification defines Feed Menus, a simplified means of discovering the feeds (e.g., RSS or Atom) offered by a Web site. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-nottingham-feed-menu/. information can be found at https://mnot.github.io/I-D/. Source for this draft and an issue tracker can be found at https://github.com/mnot/I-D/labels/feed-menu. | |||||||||||||
| EAP-WSIM: SIM-Based EAP Authentication for Enterprise Wi-Fi Using the MILENAGE-ML-KEM-FWD Construction | ||||||||||||||
|
Enterprise Wi-Fi networks authenticate devices using enterprise credentials and provisioning policies that are entirely independent of MNO subscriber identity. As a result, MNO application traffic on enterprise Wi-Fi is completely anonymous at the Wi-Fi layer: the enterprise cannot identify MNO subscribers, apply per-subscriber QoS, or support fast BSS transitions for VoWiFi continuity. This document specifies EAP-WSIM, an evolutionary enhancement of EAP- AKA' (RFC 9048) that enables MNO devices to authenticate to enterprise Wi-Fi using their existing SIM credential (WSIM-Card) without contacting the MNO backend during authentication. A WSIM- Authentication Server (WSIM-AS) within the enterprise Wi-Fi infrastructure holds MNO-provisioned MASTER KEY material in tamper- resistant security hardware. Per-subscriber MILENAGE key material is derived on-demand from the MASTER KEY using the device's IMSI -- identical in principle to MNO SIM personalization -- entirely within the security hardware boundary. No per-subscriber key provisioning at the WSIM-AS is required. | |||||||||||||
| SDLP RFC 0: Overview and Architecture | ||||||||||||||
|
This document presents an architectural overview of the Secured Digital Lifecycle Protocol (SDLP). SDLP defines a structured model for representing, identifying, tracking, and securing digital objects across their lifecycle. This overview summarizes the SDLP object model, explains how identity, lineage, lifecycle, and security architecture interrelate, and outlines the rationale for defining SDLP through multiple coordinated specifications. It serves as the entry point for understanding the SDLP framework. | |||||||||||||
| A YANG Data Model for Service Level Agreement (SLA) Assurance Management in Optical Transport Networks | ||||||||||||||
|
This document defines a YANG module for SLA assurance management in optical transport networks. The module provides a standard way to define, detect, and report issues that may impact service and network availability. It enables consistent modeling of assurance intent, impairment detection, and risk reporting across optical transport domains. The YANG model is designed to support closed-loop operations, allowing automated monitoring, analysis, and remediation workflows to maintain high service reliability and SLA compliance | |||||||||||||
| A Policy-Driven Implicit TLS Transport Profile for PCEP | ||||||||||||||
|
RFC 8253 specifies the use of Transport Layer Security (TLS) for the Path Computation Element Communication Protocol (PCEP) by negotiating TLS using the PCEP StartTLS message exchange. This document specifies a deployment profile for PCEP in which TLS is initiated immediately following TCP connection establishment based on local policy. This document is intended to simplify deployments where secure transport is mandatory. | |||||||||||||
| SRv6 for Multipath Traffic Engineering | ||||||||||||||
|
A Multipath Traffic Engineered Directed Acyclic Graph (MPTED) tunnel is a Traffic Engineering (TE) construct that enables weighted load balancing of unicast traffic across a constrained set of paths optimized for an objective. This document is informational and describes one realization approach for applying SRv6 semantics to MPTE, based on the Multipath Traffic Engineering as described in Internet-Draft (draft-kompella-teas- mpte). It summarizes associated procedures, lifecycle, management, and forwarding behavior. This document applies existing SRv6 architecture and semantics to MPTE without defining new SRv6 Endpoint Behaviors or signaling protocols. It focuses on data-plane realization using existing forwarding instructions. | |||||||||||||
| Registry-Assisted Discovery for AI Agents and Workloads Without DNS Discovery Anchors | ||||||||||||||
|
Many agent-discovery mechanisms assume that an organization controls a DNS domain and can publish a DNS record, a well-known catalog, or an organization gateway. That model works well for enterprises with operational DNS infrastructure, but it does not cover every agent or workload. Small businesses may own a domain yet lack the expertise or infrastructure to publish agent-specific DNS records. Individuals may have a globally scoped account identifier, such as an email address, while not controlling the provider domain. Personal agents and other workloads may run on a cloud service or local device while their public descriptor is hosted elsewhere. This document describes registry-assisted discovery for these cases. A NandaIndex registry binds a stable Subject Identity to a subject-authorized terminal object, such as an A2A Agent Card, an MCP server descriptor, a workload descriptor, a subject-owned AI Catalog, or a subject-authorized gateway. The binding includes authority, freshness, and revocation information. The identity owner, descriptor host, and runtime operator may be different parties. This document does not define a directory of discovery servers, directory federation, or a global switchboard. A NandaIndex response does not direct a client to another generic resolution or discovery service. DNS-anchored systems remain direct: when an authoritative AI Catalog, DNS-AID record, or organization gateway is already known, NandaIndex is not in the critical path. The focus is permissionless publication and discovery for agents and workloads that do not have a usable DNS Discovery Anchor. | |||||||||||||
| A Unified Bitmap Framework for In-Network Aggregation and Multicast | ||||||||||||||
|
Collective communication is a critical performance bottleneck for distributed deep learning and large model training and inference in data centers for AI computing. In-Network Aggregation (INA) has been identified as an effective accelerating technique to improve its performance. This draft describes a flexible and efficient INA framework for packet routing and forwarding in which a tree is encoded by a bitmap and the same bitmap is reused for data movement in both directions, with the multicast direction realized by a stateless bitmap-driven forwarding mechanism that adopts an encoding and replication behavior similar to BIER. The bitmap encoding is compact, hardware friendly, exact and self-describing, and, being carried per packet, supports highly dynamic endpoint sets without any signaling to the network. The framework is applied to three use cases. The first is AllReduce, used in model training, which performs an in-network aggregation toward the root followed by a multicast of the result back to the workers. The second is the dispatch and combine operations of Mixture-of-Experts (MoE) expert parallelism, which performs a dynamic multicast of tokens to the selected experts followed by an in-network aggregation of the expert outputs. In both use cases a single bitmap-encoded tree drives both directions. The third use case is for reliable multicast, which aggregates the acknowledgments of all multicast receivers in the network to avoid ACK implosion; its ACK- aggregation tree can be either pre-configured, as in the AllReduce use case, or self-installed by the data multicast itself, as in the MoE use case. The draft further analyzes why the base BIER architecture alone cannot realize the framework and identifies the per-packet information an INA encapsulation must carry beyond the endpoint-set encoding: a direction indicator, a job identifier, a sequence number, and an encoding-type indicator. It also examines the efficiency of the endpoint-set encoding at scale, covering hierarchical bitmaps and multiple parallel trees for large dense endpoint sets, node-list encoding for very large domains with few active endpoints, and the trade-offs between header overhead and network processing complexity among these encodings. | |||||||||||||
| Extensible Provisioning Protocol (EPP) Authentication Token Mapping | ||||||||||||||
|
This document describes an Extensible Provisioning Protocol (EPP) mapping for provisioning and management of EPP Authentication Token objects in a shared central repository, where an Authentication Token is a JSON Web Signature (JWS), defined in RFC 7515, and is used to authorize actions by registrar users. The Authentication Token can be passed over an authenticated EPP session, as defined in RFC 5730, to provide elevated, fine-grained authorization exclusively valid until the lifetime of the digitally signed Authentication Token. | |||||||||||||
| PIM Source Fanout Trace for multicast flow | ||||||||||||||
|
Mtrace version 2 traces an IP multicast path by walking from a last- hop router or rendezvous point toward the source. That model is efficient for a single receiver path, but it does not directly answer the operational question of where a multicast source fans out downstream without issuing separate traces from many receiver-side locations. | |||||||||||||
| PIM Source Discovery for ASM Deployments | ||||||||||||||
|
This document discusses the operational challenges of Any-Source Multicast deployments that use PIM Sparse Mode and explores whether PIM extensions can simplify source discovery and operational behavior while preserving the host-facing ASM service model. | |||||||||||||
| MoFRR Path Liveness for Network Failures | ||||||||||||||
|
This document discusses an operational gap in Multicast-Only Fast Reroute when failures occur inside an upstream multicast path but do not cause a visible RIB or RPF change at the merge point. The document motivates the need for a scalable path-liveness mechanism that can detect such hidden multicast delivery failures without requiring expensive per-flow packet monitoring. | |||||||||||||
| Vibeslop Confessions | ||||||||||||||
|
AI Agents have transformed the way internet applications are developed and have introduced a new set of challenges for organizations. This document describes techniques and concepts that are emerging to assist with these challenges, and relates them to concepts already familiar to the internet community. The pace of change in this area is accelerating, and it is anticipated that much of what this document discusses will become outdated quickly; nevertheless, a static publication may prove amusing to future readers, whether machine or human. | |||||||||||||
| The NetClaw-to-NetClaw Federation Protocol (NCFED) | ||||||||||||||
|
This document specifies the NetClaw-to-NetClaw Federation Protocol (NCFED), an implementation-agnostic application-layer protocol that lets independently operated, heterogeneous AI network-engineering agents ("NCFED peers", or "claws") discover one another's capabilities, invoke remote tools, and delegate tasks over long-lived TCP sessions. Although named for its reference instantiation, NCFED is a wire specification, not an SDK, and federates arbitrary autonomous agent architectures across distinct administrative boundaries; a peer needs no knowledge of its counterparty's internal reasoning framework, prompt structure, or execution runtime. NCFED multiplexes its federation channel with BGP-4 and an associated tunneling data plane on a single listening port, using first-octet protocol discrimination. Its payload is JSON-RPC 2.0, onto which Model Context Protocol (MCP) tool-invocation semantics and Agent2Agent (A2A) task-delegation semantics are mapped. Federation between different trust domains (eN2N) requires mutual operator consent; within a single operator's trust domain (iN2N) it is hub- and-spoke, bootstrapped by an enrollment token. For eN2N, the channel is encrypted with TLS 1.3 and each peer is cryptographically authenticated by proof of possession of the credential bound to its identity, under either a domain-verified (publicly certified) or a pinned (trust-on-first-use) model. For iN2N, members and the Border mutually authenticate at the application layer with pinned credentials and a hub attestation, and TLS may additionally protect the transport. NCFED does not replace MCP or A2A; it is a cross- operator federation, identity, and transport layer beneath them. This document describes the protocol as implemented in the open- source NetClaw project and is published as Experimental to enable interoperability and public review. | |||||||||||||
| The Use Case of Autonomic Traffic Management in the Artificial Intelligence Data Center | ||||||||||||||
|
This document describes the use case of autonomic traffic management in the Artificial Intelligence Data Center (AIDC), including the requirements and two management mechanisms, based on the distributed model and the centralized controlling model. It proposed to use the IETF GRASP protocol for the information exchanging, resource negotiation, control signalling, and etc. | |||||||||||||
| IPv6 Options for Wide-Area Packet Spraying (WPS): Group-Based Multipath Load Balancing | ||||||||||||||
|
This document specifies the Wide-area Packet Spraying (WPS) option, an IPv6 option that can be carried in the Destination Options header or, where required, the Hop-by-Hop Options header. The option conveys the scheduling metadata that is needed to distribute the packets of a single high-volume flow across multiple parallel wide- area paths at the granularity of packet groups, and to restore the original packet ordering at the egress boundary of a controlled domain. The mechanism provides order-preserving multipath load balancing and bandwidth aggregation for wide-area interconnection of distributed computing sites, such as wide-area interconnects between Artificial Intelligence (AI) data centers, and is intended for use within limited domains. | |||||||||||||
| MANET Awareness Model | ||||||||||||||
|
The MANET Awareness Model is a protocol- and vendor-independent data model that exports a router's internal knowledge from different protocols via REST or NETCONF/RESTCONF to services or applications. | |||||||||||||
| Research Directions on Energy-Aware Security Mechanisms | ||||||||||||||
|
With the advancement of the climate emergency, all areas of human activity are expected to continuously assess their Greenhouse Gas emissions and encourage the use of clean energy as much as possible. The current discussion on green networking in the Network Management research field still needs to be expanded to the adjoined areas, such as Network Security. This document outlines possible research directions for energy-aware security mechanisms. | |||||||||||||
| HTTP Patched Digest | ||||||||||||||
|
The PATCH method can be used to apply partial modifications to a resource. This document defines the Patched-Digest request field, which allows a client to indicate the integrity digest of the modified resource once a PATCH operation is applied. A server can use the integrity digest to detect an operation failure and return an error. The Want-Patched-Digest response field is also defined to signal server integrity preferences. | |||||||||||||
| Post-Quantum Authentication for the Resource Public Key Infrastructure | ||||||||||||||
|
The Resource Public Key Infrastructure (RPKI) authenticates Internet number resource holdings and routing authorizations with classical (RSA) signatures. Because every relying party repeatedly fetches and validates the complete global repository, replacing each per-object signature with a larger post-quantum signature would multiply repository size and validation cost. This document specifies pqRPKI, an additive post-quantum authentication layer for the RPKI. Instead of re-signing every object, each Certification Authority (CA) authenticates its complete published state with a single post-quantum signature over a Merkle Tree Ladder whose leaf order and leaf commitments are taken directly from the CA's existing Manifest. A new signed object, the pqRPKI Ladder Object (PQLO), carries the ladder root, the Manifest binding, an optional aggregate binding the CA's children, and -- for a Trust Anchor or a CA holding its own post-quantum key -- the post-quantum signature; a CA operated by its parent is authenticated through the parent's aggregate instead. Existing RPKI objects are unchanged and legacy relying parties are unaffected by the PQLO, which no Manifest lists, while upgraded relying parties validate the same repository contents with post-quantum authentication. This document updates RFC 9286 to permit index-preserving placeholder Manifest entries and the pqRPKI file-name extension. | |||||||||||||
| A Protocol for Periodic On-path Explicit Measurement | ||||||||||||||
|
This document defines the Periodic On-path Explicit Measurement (POEM) protocol, which enables passive on-path measurement of packet loss for QUIC flows. POEM uses periodic marker packets, coalesced with ordinary QUIC packets, that allow on-path network elements to measure upstream packet loss by counting packets between markers. Marker packets also carry a sender-reported loss count, enabling observers to distinguish upstream from downstream loss. Additionally, POEM defines a report mechanism through which network elements communicate measurement results back to endpoints. | |||||||||||||
| ACME STAR Extension for SM2 Dual-Certificate Automated Key Rotation | ||||||||||||||
|
The SM2 dual-certificate system, specified in [GMT.0034-2014], employs a dual-certificate architecture in which each entity holds both a signature certificate and an encryption certificate. The encryption private key is generated and escrowed by the Key Management Center (KMC). This document defines an *ACME Profile* that adapts the core protocol of [RFC8555] to the specific deployment scenario of SM2 dual- certificate management in the ShangMi (SM) ecosystem. Building upon the dual-certificate foundation framework defined in [I-D.geng-acme- sm2dualcert-extension], this document defines a STAR extension for the ACME protocol that enables *synchronized short-term automatic renewal* of SM2 dual certificates. The signature certificate follows [RFC8739] (ACME STAR) for automatic renewal with the same key pair; the encryption certificate achieves automated key rotation with a fresh key pair per epoch based on *Asynchronous Remote Key Generation (ARKG)* [Frymann2020]. This extension establishes a *unified ARKG seed chain key derivation system*: the KMC holds a seed seed_kmc and derives all encryption certificate key pairs (pk_i, sk_i) for all epochs via the ARKG algorithm, enabling stateless, lightweight KMC operations. On this basis, this extension provides *two private key delivery modes*: * *Mode A (ARKG Envelope Delivery)*: delivers sk_i to the client via a digital envelope, fully inheriting the envelope mechanism of the base framework. * *Mode B (ARKG Offline DH Derivation)*: the initial private key is obtained via envelope delivery; subsequent private keys are derived offline by the client, providing key insulation security properties. Both modes share the same ARKG cryptographic infrastructure, differing only in the final delivery mechanism of the private key. Deployers may choose according to their requirements, with full compatibility and coexistence achieved through ACME directory object negotiation. *Document Positioning*: This document is intended for the *specific SM ecosystem* as a practical guide and interoperability reference, and does not seek to become a general Internet standard. | |||||||||||||
| ACME Extension for SM2 Dual-Certificate System | ||||||||||||||
|
This document describes the extension of the ACME protocol [RFC8555] to support automated issuance of SM2 dual certificates (signature certificates and encryption certificates) in the Chinese National Cryptography certificate system. This document does not represent IETF consensus; the technical solution is applicable only to PKI environments based on an SM2 dual-certificate system. Under the framework of the ACME protocol [RFC8555], this document proposes using two separate Orders to request the two certificates. For the signature certificate, the existing ACME workflow is reused, optionally using the standard CSR approach or the pk-01 challenge [I-D.geng-acme-public-key]. For the encryption certificate, this document defines a new challenge type, auth-01, specifically for *identity authorization* scenarios: the client proves possession of the *signature private key* to authorize the Key Management Center (KMC) to generate an encryption key pair and issue the encryption certificate on behalf of the entity. This challenge type intrinsically binds the issuance of the encryption certificate to the signature key, requiring no additional binding identifiers. All extensions are compatible with the existing ACME resource model. No new Order types are introduced. This document only adds optional fields in the client's newOrder request (authKey, includeEnvelope) and an additional field in the server's response (envelope), without changing the core semantics or state machine of Order. | |||||||||||||
| SDLP Physics Specification | ||||||||||||||
|
The Secured Digital Lifecycle Protocol (SDLP) defines a physics layer for digital objects: a set of non-negotiable behavioral laws that govern identity stability, lineage integrity, lifecycle determinism, and irreversible state transitions. SDLP Physics establishes how object security depletes, transforms, or terminates as an object is activated, used, or shared, ensuring that each operation consumes or alters the object’s allowable state in predictable ways. These laws prevent cloning, enforce legitimate descent, bind objects to their environments, and guarantee that destruction and zeroization are final. This document specifies the core physics that underpin SDLP’s security model and define how digital objects behave across all environments and distribution paths. This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at: https://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at: https://www.ietf.org/shadow.html | |||||||||||||
| Internet Identity Protocol (IID) | ||||||||||||||
|
This document specifies the IID protocol, which defines message formats and operations for managing personal data, permissions, and attributes associated with internet identities, including natural persons, organizations and artificial intelligence agents. The protocol is designed to be simple, extensible, platform- independent, and human readable. It is transport-agnostic and supports arbitrary cryptographic algorithms. | |||||||||||||
| MLS Extension for Out-Of-Band Additional Authenticated Data | ||||||||||||||
|
This document specifies an explicit way to signal that the Additional Authenticated Data does include or should include data elements that are conveyed out-of-band (ex: are not in the MLS message). | |||||||||||||
| QUIC Extended Acknowledgement for Reporting Packet Receive Timestamps | ||||||||||||||
|
This document defines an extension to the QUIC transport protocol which supports reporting multiple packet receive timestamps for post- handshake packets. | |||||||||||||
| Eligibility Concept in Segment Routing Policies | ||||||||||||||
|
Segment Routing (SR) introduces new challenges for pinning candidate paths on their intended paths (the path the PCE computed based on provided intent and may have made bandwidth reservations on). The actual path through a network can change or no longer meet the required constraints if a SID list of an SR Policy candidate path is not fully expressed as a list of adjacency SIDs or when a change in the topology does happen. The introduction of the new candidate path eligibility concept permits a path to be signaled and established as operationally up, but controls whether the path is eligible to carry traffic, thus influencing its active state. The eligibility concept allows a system (operator, pce, headend, etc.) to set eligibility as false when path deviations may have occurred, or path constraints are no longer met for one or more SID lists of a candidate path and clear it when candidate path deviations are removed or constraints are met again. | |||||||||||||
| Path-Aware Semantic Addressing (PASA) for Low power and Lossy Networks | ||||||||||||||
|
This document specifies a topological addressing scheme, Path-Aware Semantic Addressing (PASA), that enables stateless IP packet forwarding. The forwarding decision is based solely on the destination address structure. This document focuses on carrying IP packets across an LLN (Low power and Lossy Network), in which the topology is quite static, the location of the nodes is fixed for long period of time, and the connection between the nodes is also rather stable. This document specifies the PASA architecture, along with the PASA address allocation, forwarding mechanism, routing header format, and IPv6 interconnection support. | |||||||||||||
| Generic Address Assignment Option for 6LoWPAN Neighbor Discovery | ||||||||||||||
|
This document specifies an extension to the IPv6 Neighbor Discovery in Low Power and Lossy Networks (LLNs), enabling a node to request to be assigned an address or a prefix from neighbor routers, without introducing a centralized infrastructure and without relying on multicast messages. Such a mechanism makes it possible to algorithmically assign addresses and prefixes to nodes in a 6LoWPAN deployment. The proposed mechanism is more efficient in such specific scenario with respect to DHCPv6. | |||||||||||||
| YANG Data Model for FlexE Management | ||||||||||||||
|
This document defines a service provider targeted YANG data model for the configuration and management of a Flex Ethernet (FlexE) network, including FlexE group and FlexE client. | |||||||||||||
| A YANG Data Model Extension for Attachment Circuit as a Service with UDP Tunnel Support | ||||||||||||||
|
Delivery of network services over a Layer 3 tunnel assumes that the appropriate setup is provisioned over links that connect the customer termination points and provider network. The required setup to allow successful data exchange over these links is referred to as an attachment circuit (AC) while the underlying link for carrying network services is referred to as "bearer", in this case a Layer 3 UDP tunnel. This document specifies an extension for UDP tunnel as Layer 3 bearer to the YANG service data model for AC. | |||||||||||||
| BGP SR Policy Extensions for Network Resource Partition | ||||||||||||||
|
Segment Routing (SR) Policy is a set of candidate paths, each consisting of one or more segment lists and the associated information. The header of a packet steered in an SR Policy is augmented with an ordered list of segments associated with that SR Policy. A Network Resource Partition (NRP) is a subset of network resources allocated in the underlay network which can be used to support one or a group of RFC 9543 network slice services. In networks where there are multiple NRPs, an SR Policy may be associated with a particular NRP. The association between SR Policy and NRP needs to be specified, so that for service traffic which is steered into the SR Policy, the header of the packets can be augmented with the information associated with the NRP. An SR Policy candidate path can be distributed using BGP SR Policy. This document defines the extensions to BGP SR Policy to specify the NRP which the SR Policy candidate path is associated with. | |||||||||||||
| The Multicast Application Port | ||||||||||||||
|
This document discusses the drawbacks of the current practice of assigning a UDP port to each multicast application. Such assignments are redundant because the multicast address already uniquely identifies the data. The document assigns a UDP port specifically for use with multicast applications and lists requirements for using this port. This approach provides immediate compatibility with existing protocol stacks, while also requiring improvements to make the port easier to use. | |||||||||||||
| Signal-Free Locator/ID Separation Protocol (LISP) Multicast | ||||||||||||||
|
This document describes the design for inter-domain multicast overlays using the Locator/ID Separation Protocol (LISP). The document specifies how LISP multicast overlays operate over a unicast underlay. When multicast sources and receivers are active at Locator/ID Separation Protocol (LISP) sites, the core network is required to use native multicast so packets can be delivered from sources to group members. When multicast is not available to connect the multicast sites together, a signal-free mechanism can be used to allow traffic to flow between sites. The mechanism within here uses unicast replication and encapsulation over the core network for the data plane and uses the LISP mapping database system so encapsulators at the source LISP multicast site can find decapsulators at the receiver LISP multicast sites. This document when approved obsoletes RFC 8378. | |||||||||||||
| IS-IS YANG Model Augmentations for Additional Features - Release 1 | ||||||||||||||
|
This document defines YANG data modules augmenting the IETF IS-IS YANG model to provide support for IS-IS Minimum Remaining Lifetime as defined in RFC 7987, and Signaling Maximum SID Depth Using IS-IS as defined in RFC 8491. | |||||||||||||
| Extensible YANG Model for Network Telemetry Messages | ||||||||||||||
|
This document defines an extensible message schema in YANG to be used at data collection to transform Network Telemetry messages into external systems such as Message Brokers. The extensible message schema enables data collectors to add metadata for the provenance of the operational network data. | |||||||||||||
| Lzip Compressed Format and the 'application/lzip' Media Type | ||||||||||||||
|
Lzip is a general-purpose lossless compressed data format. Lzip uses LZMA compression and can achieve higher compression ratios than gzip. Lzip provides accurate and robust 3-factor integrity checking. This document describes the lzip format and registers a media type, a content coding, and a structured syntax suffix to be used when transporting lzip-compressed content via MIME or HTTP. | |||||||||||||
| MTU propagation over EVPN Overlays | ||||||||||||||
|
Path MTU Discovery between end-host-devices/Virtual-Machines/servers/ workloads connected over an EVPN-Overlay Network in Datacenter/Campus/enterprise deployment, is a problem, yet to be resolved in the standards forums. It needs a converged solution to ensure optimal usage of network and computational resources of the networking elements, including underlay routers/switches, constituting the overlay network. This documents takes leads from the guidelines presented in [RFC4459]. The overlay connectivity can pan across various sites (geographically seperated or collocated) for realizing a Datacenter Interconnect or intersite VPNs between campus sites (buildings, branch offices etc). This literature intends to solve problem of icmp error propagation from an underlay routing/switching device to an end-host (hooked to EVPN overlay), thus facilitating "accurate MTU" learnings. This document also leverages the icmp multipart message extension, mentioned in [RFC4884] to carry the original packet in the icmp PDU. | |||||||||||||
| Open Ethics Transparency Protocol | ||||||||||||||
|
The Open Ethics Transparency Protocol (OETP) is an application-level protocol for publishing and accessing ethical Disclosures of IT Products and their Components. The Protocol is based on HTTP exchange of information about the ethical "postures", provided in an open and standardized format. The scope of the Protocol covers Disclosures for systems such as Software as a Service (SaaS) Applications, Software Applications, Software Components, Application Programming Interfaces (API), Automated Decision-Making (ADM) systems, and systems using Artificial Intelligence (AI). OETP aims to bring more transparent, predictable, and safe environments for the end-users. The OETP Disclosure Schema is an extensible JSON-based format. | |||||||||||||
| Commercial National Security Algorithm (CNSA) Suite 2.0 Profile for TLS 1.3 | ||||||||||||||
|
This document defines a base profile of TLS 1.3 which is compliant with the US Commercial National Security Algorithm (CNSA) 2.0 Suite, a cybersecurity advisory published by the United States Government which outlines quantum-resistant cryptographic algorithm policy for US national security applications. This profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that employ TLS 1.3. It is also appropriate for all other US Government systems that process high-value information. This memo is not an IETF standard, and has not been shown to have IETF community consensus. This profile is made publicly available for use by developers and operators of these and any other system deployments. | |||||||||||||
| Commercial National Security Algorithm (CNSA) Suite 2.0 Profile for IPsec | ||||||||||||||
|
This document defines a base profile for IPsec for use with the US Commercial National Security Algorithm (CNSA) 2.0 Suite, a cybersecurity advisory that outlines quantum-resistant cryptographic algorithm policy for national security applications. This profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that employ IPsec. It is also appropriate for all other US Government systems that process high-value information. This memo is not an IETF standard, and has not been shown to have IETF community consensus. This profile is made publicly available for use by developers and operators of these and any other system deployments. | |||||||||||||
| A SRv6 Traffic Engineering Application for AI Network | ||||||||||||||
|
AI applications require fast processing and responses. Traffic using RoCEv2 has low entropy for ECMP. At the same time, AI elephant flows are predictable. Traffic engineering technology for AI backend networks becomes a possible solution. SRv6 TE can start from the host side, making SRv6 source routing and traffic path control from the host side an optional solution. This document presents a AI network Traffic Engineering (TE) application scenario for handling link faults and traffic congestion issues in data centers, based on Segment Routing over IPv6 (SRv6) and Compressed Segment Identifier (CSID). The application scenario uses SRv6 CSID Network Programming to directly install all forwarding paths on the head-end device. When a data center experiences a link fault or traffic congestion, the head-end device switches the forwarding path to another optimal path for avoiding the location of link fault or traffic congestion, ensuring optimal AI data flow forwarding. | |||||||||||||
| Guidelines for QUIC Multipath over SCION | ||||||||||||||
|
This document provides informational guidance for using the Multipath Extension for QUIC with the SCION networking technology. SCION is an inter-domain routing protocol that supports path-aware multi-path networking. The multiple paths and their associated path information offered by SCION provide opportunities as well as challenges for combining QUIC-MP with SCION. This document explores various aspects of this combination, such as algorithms for congestion control, RTT estimation, and general application scenarios. In addition, it provides techniques and guidance to maintain the security of QUIC-MP and SCION, and to leverage path-aware multi-path networking with QUIC-MP. | |||||||||||||
| Specification of Christian's Congestion Control Code (C4) | ||||||||||||||
|
Christian's Congestion Control Code is a new congestion control algorithm designed to support Real-Time applications such as Media over QUIC. It is designed to drive towards low delays, with good support for the "application limited" behavior frequently found when using variable rate encoding, and with fast reaction to congestion to avoid the "priority inversion" happening when congestion control overestimates the available capacity. The design emphasizes simplicity and avoids making too many assumptions about the "model" of the network. | |||||||||||||
| Testing of Christian's Congestion Control Code (C4) | ||||||||||||||
|
Christian's Congestion Control Code is a new congestion control algorithm designed to support Real-Time applications such as Media over QUIC. It is designed to drive towards low delays, with good support for the "application limited" behavior frequently found when using variable rate encoding, and with fast reaction to congestion to avoid the "priority inversion" happening when congestion control overestimates the available capacity. The design was validated by series of simulations, and also by initial deployments in control networks. We describe here these simulations and tests. | |||||||||||||
| Export of ECN Information in IPFIX | ||||||||||||||
|
This document defines a set of IPFIX Information Elements for monitoring Explicit Congestion Notification (ECN), specifically in the context of the Low Latency, Low Loss, and Scalable Throughput (L4S) service. These Information Elements allow network operators to observe ECN codepoint usage within L4S deployments and evaluate the corresponding traffic performance. | |||||||||||||
| Bundle Protocol (BP) Manifest Block | ||||||||||||||
|
This document defines an extension block type for Bundle Protocol version 7 to capture discretionary summary data about the state of a Bundle at the time the extension block is added. This Manifest structure is a general purpose container for information about other blocks, and can be used as a piece-part of a larger security operation. | |||||||||||||
| AI Agent Use Cases and Requirements in 6G Network | ||||||||||||||
|
This draft introduces use cases related to AI Agents in 6G networks, primarily referencing the technical report of 3GPP SA1 R20 Study on 6G Use Cases and Service Requirements (TR 22.870). It also elaborates on some of the requirements for introducing AI Agents into 6G networks from the perspective of operators. | |||||||||||||
| Multi-agent Collaboration Protocol Suites Architecture | ||||||||||||||
|
This document defines a protocol suite and architectural framework for secure and scalable multi-agent collaboration. The proposed Multi-Agent Collaboration Protocol (MACP) enables trusted agent onboarding, capability-based query, distributed capability synchronization, and secure interaction among agents and external resources. The architecture introduces key entities such as the Agent Management Center (AMC), Agent Gateway (AGW), Agents, and External Resource Services (ERS), along with a set of protocols that collectively support dynamic, capability-driven collaboration across administrative domains. | |||||||||||||
| Transaction-Bound Authorization Tokens for Software and AI Agents (SPT-Txn) | ||||||||||||||
|
Current authorization is role-scoped: an actor is granted a role whose authority persists across every action it takes. This fails exactly when actors fail -- under compromise, prompt injection, or goal hijacking -- because a compromised actor retains full role authority. This document specifies SPT-Txn, a family of transaction- bound authorization tokens in which authority exists only inside a short-lived token bound to one declared action, on one resource, under one jurisdictional policy, verified against how the requesting workload was attested. Delegation across agents and tools is expressed as a cryptographically sealed chain that can only narrow authority and is verifiable offline. Each authorization decision emits a signed, tamper-evident receipt as a byproduct of enforcement. This document specifies normative intent binding, transaction receipts and their transparency log, attested issuance via OAuth 2.0 Token Exchange, per-token status-list revocation, and cryptographic algorithm agility including hybrid post-quantum signing. It also hardens attested issuance in response to an adversarial security review of the reference implementation: it makes an audience and a verifiable expiry mandatory on the presented attestation, requires the issuer to bound the delegated depth it grants, and clamps a token's lifetime to the attestation it was minted on. The issuer- side requested-versus-permitted scope intersection is retained; the enforcement point re-checks the chain independently. | |||||||||||||
| DTN Peering Protocol | ||||||||||||||
|
This document specifies the DTN Peering Protocol (DPP), an inter- domain routing protocol for the Delay-Tolerant Networking (DTN) ecosystem. DPP facilitates the exchange of reachability information between distinct Administrative Domains (ADs), enabling inter-domain routing across the Solar System DTN. DPP separates the control plane from the data plane: a DPP speaker need not be a gateway that forwards bundles, allowing centralized route controllers or orchestration systems to participate in peering on behalf of the gateways they manage. DPP harmonizes the two DTN addressing schemes -- ipn (integer-based) and dtn (URI-based) -- into a unified routing framework. It leverages DNS for identity verification and supports both reactive routing and scheduled contact windows for deep-space networks. | |||||||||||||
| IS-IS Traffic Engineering Extensions For Microburst | ||||||||||||||
|
This document defines IS-IS and OSPF sub-TLVs and a BGP-Link State (BGP-LS) Link Attribute TLV for advertising aggregated measurements of microburst activity on a unidirectional link. The information is reported for an identified traffic class and includes event, packet- drop, and queue-occupancy statistics. An Anomalous (A) bit carries a locally determined anomaly indication. This document specifies the encoding and distribution of the information. Microburst detection, loss attribution, threshold selection, and actions taken by a consumer are outside the scope of this document. | |||||||||||||
| Anonymous Bot Authentication: Authorization and Rate Limiting for Web Agents | ||||||||||||||
|
Automated agents ("bots") represent a large fraction of the traffic to many Web sites. In some cases, this traffic is desired, in others undesired, and in yet others, desired as long as it remains within certain rate limits. This memo describes Anonymous Bot Authentication (ABA), a system that allows Web site operators to distinguish wanted from unwanted traffic, while not tying a given request to a specific sender. | |||||||||||||
| Problem Statement for the Discovery of Agents,Workloads,and Named Entities (DAWN) | ||||||||||||||
|
Interacting entities such as agents, tasks, users, workloads, data, compute, etc., in AI ecosystem/network are proliferating, yet there is no standardised way to discover what entities exist, what attributes such as skills, capabilities, physical characteristics, etc., they posses, what services they offer, or how to reach them across organisational boundaries. Discovery today relies on proprietary directories or manual configuration, creating fragmented ecosystems that prevent cross- domain collaboration. This document describes the problem space that motivates Discovery of Agents, Workloads, and Named Entities (DAWN). It clarifies the scope of work within entity ecosystems, identifies why current approaches are insufficient, and outlines the challenges a standardised discovery mechanism must address. It does not propose a specific solution or protocol. | |||||||||||||
| Caller-ID Vouching and Vetting (CIDVV) | ||||||||||||||
|
Caller-ID spoofing remains a significant problem in telephony, particularly across inter-domain and international call paths where identity frameworks may not yet be fully deployed. This document defines *Caller-ID Vouching and Vetting (CIDVV)*, a lightweight verification mechanism that lets the called party ask a simple question: | |||||||||||||
| Proof of Sovereign Integrity (PSI): Protocol Specification v1 | ||||||||||||||
|
This document specifies the Proof of Sovereign Integrity (PSI) Protocol for verifiable AI regulatory compliance. Revision 01 updates the March 2026 specification with EU AI Act Article 50 alignment and post-quantum cryptographic requirements. | |||||||||||||
| A SCITT Profile for Pre-Execution AI Action Authorization Records | ||||||||||||||
|
This document specifies a SCITT (Supply Chain Integrity, Transparency, and Trust) profile for pre-execution authorization records of AI agent actions. The profile defines a Signed Statement type, the "Pre-Execution Authorization Record" (also called a Permit), that records a policy-evaluated decision to allow, deny, or challenge an AI agent action before that action is dispatched to a model provider, tool, or service. The profile cryptographically binds the authorization decision to the canonical bytes of the request that is authorized. When the paired Closure Record carries a dispatch digest, a Verifier can compare the authorized-request digest against the recorded dispatched-request digest; on the managed dispatch path the reference implementation additionally enforces this equality before the request is sent. This revision also introduces authorization-lineage vocabulary. It defines how a Verifier can determine whether the authority conveyed by a child Permit is equal to or narrower than the authority conveyed by its parent (attenuation), given a signed or chain-committed Authority Representation and a declared Comparator Profile. The Permit remains an evidence artifact; this profile specifies the evidence a Verifier needs to make that determination, not a delegation or policy protocol. The profile composes with adjacent profiles for human-authority binding, post-execution material-action evidence, and content-refusal events, referenced rather than replicated. | |||||||||||||
| Signed Authorization-Evidence Records for WIMSE-Authorized AI Agent Actions | ||||||||||||||
|
This document specifies a companion profile to the AI Agent Authentication and Authorization draft [I-D.klrc-aiagent-auth], defining a signed authorization-evidence record produced by WIMSE- authorized AI agent actions. The evidence record (referred to as a Permit) cryptographically commits to the canonical bytes of the request authorized before dispatch and, via a paired Closure Record, to the recorded dispatched-request digest; it maps to and can satisfy the audit minimum requirements enumerated in Section 11 of the companion draft, and composes with HTTP Message Signatures, OAuth access tokens, and Shared Signals Framework eventing without requiring modifications to those existing standards. The profile is anchored in the SCITT profile defined in [I-D.munoz-scitt-permit-profile]. This revision also describes how WIMSE deployments compose with authorization-lineage evidence defined by the companion SCITT profile: workload identity, delegated subject context, runtime token claims, and HTTP Message Signature coverage become Verifier inputs for parent/child Permit relationships. | |||||||||||||
| EAT Attestation Result (EAR) profile for Intel(r) Trust Domain Extensions (TDX) + Confidential GPU (C-GPU) composite attestation | ||||||||||||||
|
This document defines an Entity Attestation Token (EAT) Attestation Result (EAR) profile for the composite attestation of Intel® Trust Domain Extensions (TDX)–based Confidential Virtual Machines (CVMs) together with confidential NVIDIA GPUs (C-GPUs) deployed in Microsoft Azure. The profile outlines claims that enable relying parties to establish trust in the integrity and confidentiality of the combined confidential computing environment. Developed collaboratively by Microsoft, Intel, and NVIDIA, this work is intended to foster interoperable composite attestation across heterogeneous Trusted Execution Environments (TEEs) and confidential accelerators, while encouraging adoption and extension by verifier providers across the confidential computing ecosystem. | |||||||||||||
| AI Agent Interoperable Protocol Framework (AIPF) | ||||||||||||||
|
The current generation of AI agent communication protocols enables basic tool access and inter-agent messaging, but lacks the architectural and protocol foundations required for open, interoperable, and resilient Internet-scale deployments. This document presents the AI Agent Interoperable Protocol Framework (AIPF), a layered framework that identifies the key building blocks and the protocol suite required for interoperable Agent-to-agent/ Agent-to-tool communication. | |||||||||||||
| KYAPay Token | ||||||||||||||
|
This document defines a token format for agent identity and payment tokens in JSON Web Token (JWT) format. Authorization servers and resource servers from different vendors can leverage this token format to consume identity and payment tokens in an interoperable manner. | |||||||||||||
| Architecture and Requirements for Observability,Control and Intervention of Network Management Agents | ||||||||||||||
|
This document defines architecture and a set of requirements for Observability, Control, and Intervention for Network Management Agents. It identifies gaps in existing mechanisms and specifies required interaction capabilities between Agent supervision systems and network management agents across multi-vendor environments, specifically observability, control, and runtime intervention. The requirements aim to guarantee comprehensive, lifecycle control over AI agents and enable observation, constraint, intervention, and correction to ensure network operational resilience and continuity. | |||||||||||||
| EST for C509 Certificates | ||||||||||||||
|
This document defines Enrollment over Secure Transport (EST) protocol operations over HTTPS and secure CoAP for use with C509 certificates. The operations specified in this document support CA certificate distribution, C509 certificate enrollment, C509 certificate re- enrollment, and server-side key generation using C509 certificates. This document also defines operations for Certificate Revocation List (CRL) distribution. | |||||||||||||
| Additional Authentication Method Reference Values | ||||||||||||||
|
The JWT "amr" (Authentication Methods References) claim contains values conveying authentication methods used in the authentication. This specification defines additional Authentication Method Reference values beyond those already registered to represent additional authentication methods in use today. | |||||||||||||
| Identity Verification Methods Values | ||||||||||||||
|
Knowing how a person's identity was verified can be important when making trust decisions. This specification defines a claim and values for declaring how the person's identity was verified. | |||||||||||||
| KYAPay Token Exchange | ||||||||||||||
|
This specification describes how KYAPay tokens can be exchanged for OAuth access tokens to dynamically grant agents access to resources they need to accomplish their mission. | |||||||||||||
| BGP Enhancements for ECMP EBGP Scenarios | ||||||||||||||
|
This document proposes extensions to BGP to apply the RFC 5004 route persistence algorithm across parallel EBGP sessions and to suppress unnecessary advertisements between EBGP peers in the same AS. This document updates RFC 5004. | |||||||||||||
| Problem Statement and Roadmap for BGP FlowSpec Monitoring | ||||||||||||||
|
This document describes the problem space and roadmap for monitoring BGP Flow Specification (FlowSpec) deployments. It outlines the operational motivation for FlowSpec monitoring, identifies representative classes of monitoring information, and positions relevant work on FlowSpec, the BGP Monitoring Protocol (BMP), IP Flow Information Export (IPFIX), and YANG-based operational state within a common framework. The resulting roadmap provides common context for related protocol-specific work in the relevant IETF working groups. | |||||||||||||
| Architecture and Data Model for Persistent Memory in Agentic Systems | ||||||||||||||
|
Memory in current agentic systems is often fragmented across model- provider features, application databases, session histories, framework-specific stores, unstructured files, and retrieval indexes. This document distinguishes temporary context supplied to an inference request from persistent memory that remains addressable, machine-readable, and governed beyond a single request. It specifies a provider-independent architecture and data model for persistent memory in agentic systems based on Memory Scope isolation, typed and versioned Memory Objects, machine-readable provenance, append-only Event Ledger history, separate lifecycle, availability, retention, and validation state, and isolated Derived Indexes and Embedding Spaces. The architecture separates a transient Compute Plane from an authoritative Persistent State Plane and treats embeddings, lexical indexes, graph projections, generated retrieval summaries, ranking caches, and retrieval caches as non-authoritative derived state. The architecture is independent of model provider, storage engine, and protocol transport while allowing future bindings and multiple independent implementations. It does not claim that related systems or standards do not exist; rather, it defines a common architectural vocabulary and interoperability target for persistent agentic memory. | |||||||||||||
| Export of BGP FlowSpec Treatment Information in IPFIX | ||||||||||||||
|
BGP Flow Specification (FlowSpec) is commonly used to distribute traffic filtering and traffic treatment rules. Operational monitoring of FlowSpec deployments may require information from multiple sources, including BGP control-plane telemetry, operational state, and forwarding-plane observations. This document defines IP Flow Information Export (IPFIX) Information Elements that add FlowSpec context to IPFIX Flow Records. The exported information enables a Collector to correlate exported Flow Records with a FlowSpec rule in the scope of an Observation Domain and to identify the treatment class reported by the Exporter. | |||||||||||||
| Shared Reference Lexicons for Agent-to-Agent Model Reconciliation in Network Management | ||||||||||||||
|
Interoperability between network-management systems is customarily arranged by agreeing a shared data model in advance or, where that falls short, a richer shared information model or ontology; both still require broad prior agreement on a common model. This document, a companion to and enhancement of draft-janz-nmrg-ontology- reconciliation, argues that for systems built as cognitive, language- capable agents the shared reference can instead be a thin reference lexicon: a consultable nomenclature of named entities with disambiguating definitions and examples, free of relationship axioms and attribute schemas, and typically derived from an existing model. Each agent brings the lexicon apt to it; the two are lexically aligned into cross-source correspondences; identity is settled wherever they correspond; and only the residual is reconciled by the conversation of the companion document. The document develops what such a lexicon should contain, the two-stage alignment that relates lexicons across sources, the distinct problem of co-referencing specific instances, and the scaling that follows from anchoring translation on shared references; and it recommends how model authors can make their artefacts more amenable to this automated alignment. | |||||||||||||
| A Standard Wire Format for Large Language Model Inference Streaming | ||||||||||||||
|
Large Language Model (LLM) inference endpoints stream response tokens to clients using a fragmented set of vendor-specific application- layer protocols layered on top of standardized transports (HTTP/2, HTTP/1.1, WebSocket, Server-Sent Events). While these transports carry IETF or W3C standardization, the JSON payload schemas, event taxonomies, and framing conventions used within them are entirely vendor-defined, with no RFCs or common specifications governing them. This fragmentation imposes costs across the AI ecosystem. Middleware frameworks and orchestration platforms (LangChain, LiteLLM, Vercel AI SDK, Portkey, Cloudflare AI Gateway) must maintain vendor-specific streaming parsers for every supported provider. Cloud hosting platforms (AWS Bedrock, Azure AI Studio, Google Vertex AI) have each introduced additional proprietary streaming formats. Compliance and observability tooling must be rebuilt per provider. And new inference providers cannot reach framework-dependent developers without custom integration work. This document defines a standard wire format for LLM inference streaming over Server-Sent Events (SSE) on HTTP. It specifies a request envelope media type (application/llm-request+json), a response event taxonomy, and a JSON event envelope schema that enable middleware, orchestration platforms, compliance tooling, and HTTP intermediaries to handle AI inference traffic from any conforming provider using a single protocol contract. SSE transport remains unchanged; only the JSON payload inside it is standardized. The scope of this document is strictly Client/Application to LLM inference endpoint streaming. Agent-to-tool interaction (e.g., MCP) and agent-to-agent communication are out of scope. | |||||||||||||
| The Redirect-By HTTP Response Header Field | ||||||||||||||
|
This document defines the Redirect-By HTTP response header field. It allows the software component whose decision determined an HTTP redirect to identify itself, so that an operator diagnosing a redirect can determine which component was responsible for it. The field succeeds the widely deployed, non-standard X-Redirect-By header, which this document deprecates. | |||||||||||||
| Signaling RSVP-TE Tunnels on an SR-MPLS Forwarding Plane Using Adjacency Segment Identifiers | ||||||||||||||
|
RFC 8577 introduced the concept of signaling RSVP-TE tunnels on a shared MPLS forwarding plane using preinstalled "TE link labels". Those labels are functionally equivalent to Segment Routing (SR) Adjacency Segment Identifiers (Adj-SIDs) but are allocated and distributed solely via RSVP-TE signaling. This document extends RFC 8577 to use SR-MPLS Adjacency SIDs that are advertised by the IGP as the forwarding-plane labels for RSVP-TE tunnels. It restricts scope to per-link Adj-SIDs and defines the signaling procedures and protocol extensions required to couple the RSVP-TE control plane with the native SR-MPLS forwarding plane. | |||||||||||||
| In-situ Space Flow Telemetry for IPv6 Limited Domains | ||||||||||||||
|
Space networks, including satellite networks, often operate with constrained bandwidth, processing capacity, storage, and energy, while also experiencing dynamic topology and frequent link changes. Existing in-situ Operations, Administration, and Maintenance (IOAM) mechanisms provide useful per-packet telemetry, but the packet overhead and field selection flexibility can be costly in such environments. This document specifies In-situ Space Flow Telemetry (ISFT), a compact telemetry profile for IPv6 limited domains. ISFT defines an 8-octet telemetry option header, a small set of telemetry templates for delay, loss, and congestion information, and processing behavior for encapsulating, transit, and decapsulating nodes. ISFT is intended for controlled domains such as space-network segments and MUST NOT be exposed as an Internet-wide protocol behavior. | |||||||||||||
| IPv6 Wireless Access in Satellite Networks (IPWASN): Problem Statement and Use Cases | ||||||||||||||
|
This document describes use cases and a problem statement for IPv6 Wireless Access in Satellite Networks (IPWASN). IPWASN aims at the IPv6-based wireless access in Non-Terrestrial Networks (NTNs), that is, satellite networks. It considers NTN characteristics such as dynamic topology, multi-hop communication over inter-satellite links, High-Altitude Platform Station (HAPS)-assisted relay paths, frequent handovers, variable link quality, and intermittent connectivity. Based on these characteristics, this document identifies key challenges in applying existing IPv6 protocols to NTN environments. It also analyzes the applicability of current IPv6 mechanisms and outlines requirements to support efficient data forwarding, Quality of Service (QoS), Segment Routing (SR)-based traffic engineering, and connectivity in satellite-based networks. | |||||||||||||
| PSI-02: ACCU Carbon Sequestration Attestation | ||||||||||||||
|
PSI-02 specifies a privacy-preserving cryptographic attestation that a registered NDIS service provider's operational evidence satisfies the NDIS Practice Standards. The attestation binds a canonicalised evidence digest to an Ed25519 signature without disclosing participant data or commercially sensitive material. | |||||||||||||
| PSI-08: Health Records Access Attestation | ||||||||||||||
|
PSI-08 specifies a format for composing multiple Digital Gallows predicates into a verifiable chain. Each link in the chain is a signed predicate output that serves as input to the next, enabling verifiable multi-step inference without a trusted intermediary. | |||||||||||||
| PSI-09: Age Assurance Attestation | ||||||||||||||
|
PSI-09 defines a signed verdict format for distributed tribunal proceedings conducted under the Apex Protocol. A verdict carries the case identifier, the predicate chain that produced it, the ruling, the evidence anchors, and the dissenting opinion if any. | |||||||||||||
| PSI Merkle Tree Anchoring for Cryptographic Seals | ||||||||||||||
|
This document specifies the Merkle tree construction and anchoring protocol used by the Proof of Sovereign Integrity (PSI) system for tamper-evident content verification. It defines tree parameters, leaf construction, inclusion proof generation, and root anchoring to public ledgers including the Bitcoin blockchain. The protocol uses SHA-256 as the hash function, binary Merkle trees with height=5 (32 leaves per epoch), and deterministic leaf ordering to enable third- party v | |||||||||||||
| PSI Post-Quantum Dual-Signature Sealing | ||||||||||||||
|
This document specifies the post-quantum cryptographic sealing extension for the Proof of Sovereign Integrity (PSI) Protocol. While classical Ed25519 signatures provide current security, the emergence of cryptographically relevant quantum computers (CRQCs) threatens all elliptic-curve and RSA-based signature schemes. PSI addresses this through dual-signature sealing: each seal carries both an Ed25519 signature (for immediate classical verification) and an LMS-W4-SHA256 hash | |||||||||||||
| PSI AI Agent Action Sealing and Liability Protocol | ||||||||||||||
|
This document specifies a cryptographic protocol for sealing AI agent actions, establishing an auditable chain of custody from instruction to execution. As AI agents increasingly perform autonomous actions — financial transfers, content publication, system configuration, legal filings — the need for a verifiable record of "who instructed what, when, and what actually happened" becomes critical for liability attribution, regulatory compliance, and trust. The PSI Agent Se | |||||||||||||
| PSI Zero-Knowledge Age Assurance Attestation | ||||||||||||||
|
This document specifies PSI-Age, a privacy-preserving cryptographic attestation for age assurance. It enables a relying party (such as a social media platform or online service) to verify that a user meets a minimum age threshold without learning the user's identity, date of birth, or any other personal attribute. PSI-Age uses zero-knowledge range proofs over a committed birthdate to produce a compact, verifiable "age credential" that proves age >= threshold without rev | |||||||||||||
| kevinmcm - Github tutorial | ||||||||||||||
|
This is where the abstract should be written 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://kevinmcm- github.github.io/github-tutorial/draft-todo-kevinmcm-tutorial.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-todo-kevinmcm-tutorial/. Source for this draft and an issue tracker can be found at https://github.com/kevinmcm-github/github-tutorial. | |||||||||||||
| AI P2MP Multicast in Scale-UP Network | ||||||||||||||
|
MoE (Mixture-of-Experts) has been adopted in scale-up GPU connections by the mainstream Large Language Models, such as Llama4, Mixtral, and DeepSeekV3. This document focuses on the AI multicast protocol evolution for MoE in scale-up scenarios, analyzing the challenges and proposing potential protocol evolutions. | |||||||||||||
| The requirements of Agent Lifecycle Management | ||||||||||||||
|
As agents evolve from auxiliary analysis toward autonomous decision- making and task execution, their operation involves multiple dynamic factors, including models, knowledges, metrics, tools, permissions, behaviors, and collaborative relationships. Traditional management methods are no longer sufficient to ensure their secure and stable operation. This draft proposes an agent lifecycle management requirement covering registration and publication, deployment and operation, continuous operations, capability evolution, deactivation, and retirement. It analyzes key management requirements related to assets, capabilities, knowledge, tools, identity and authorization, operational evaluation, auditing, and version evolution and retirement, providing the unified management, continuous governance, and large-scale deployment of agents. | |||||||||||||
| Using KYAPay Tokens | ||||||||||||||
|
The KYAPay Token is a JSON Web Token (JWT) that carries verified identity ("Know Your Agent", KYA) and payment (PAY) information for requests made by software agents on behalf of human principals. This document describes how security intermediaries -- bot managers, fraud managers, account-takeover (ATO) protection systems, and customer identity and access management (CIAM) systems -- consume KYAPay tokens to answer a question that traditional bot detection cannot: "did a verified human authorize this agent?", rather than "is this a human?". It specifies how KYAPay tokens are carried in HTTP requests, how they are validated (including in combination with request-signing layers such as HTTP Message Signatures), and how the verified, layered identity in a token is used to make access, routing, fraud detection, account-lifecycle, and step-up decisions. It defines the token-consuming "verifier" role that the KYAPay Token leaves unspecified. It is intentionally non-prescriptive about how tokens are created, because agent architectures, agent-identity technologies, and agent-communication protocols are diverse and still emerging; the token itself is the interoperability contract. | |||||||||||||
| Hosted Key Directories for Web Bot Auth | ||||||||||||||
|
Web Bot Auth authenticates automated clients to origins using HTTP Message Signatures, with verification keys published in a key directory at a well-known URI. Current drafts assume that each agent operator hosts its own key directory. A large and growing population of agents is operated by individuals and small organizations for whom hosting a directory is impractical, and whose legitimate traffic is otherwise indistinguishable from abusive automation. This document describes the hosted (multi-tenant) key directory deployment model, in which a registry operator publishes key directories on behalf of many independent agent operators while the operators retain exclusive custody of their private keys. It analyzes principal mapping, proof of key possession, freshness, and accountability in this model; reports interoperability observations from an independent implementation; and offers operational guidance for hosted directory operators and for verifiers. It is intended as input to the Web Bot Auth working group's operational and deployment guidance. | |||||||||||||
| Decision-Subject Representation for Agent Authorization | ||||||||||||||
|
This document defines dsub, an OPTIONAL, descriptive claim naming the *decision subject*, the party an automated agent's action is taken _upon_, as distinct from the acting agent (act) and the delegating principal (sub). Its purpose is *audit legibility*: letting a record name the party a decision concerns, which is the precondition for that record ever being made legible to them. The claim is privacy- minimizing by construction and is NOT an input to the authorization decision; a Policy Decision Point MUST ignore it. This document defines representation only. | |||||||||||||
| Operator-of-Record: an Origination Marker for Agent-Operated Presentations and Decisions | ||||||||||||||
|
This document requests registration of opr, an OPTIONAL, descriptive JWT claim that marks the operator of record, that is, whether a human or an agent operated a credential presentation or drove a decision. Its purpose is record integrity. Under agent operation a wallet key- binding proof is cryptographically indistinguishable from a human- operated one, and no presentation protocol marks the difference; opr records the distinction. A Policy Decision Point MUST ignore opr for the allow/deny decision; interpretation and any resulting authorization behavior are deployment-local and out of scope. This document defines representation only. It defines no remedy, adjudication, obligation, or authorization mandate. | |||||||||||||
| Server Validation Extension for the Extensible Provisioning Protocol (EPP) | ||||||||||||||
|
This document describes an Extensible Provisioning Protocol (EPP) extension for providing the status of server validations. Server validations can be done for an extensible set of types, with examples including validating the DNS resolution with the type "dns" and validating the DNSSEC with the type "dnssec". The validations can be performed synchronously that will include the extension in the response or asynchronously that will include the validation in a poll message. If validations are performed on a schedule, a change in the status of a typed-validation will be included in a poll message. | |||||||||||||
| A Framework for Agent-Aware Network Acceleration Services in Home Broadband Access | ||||||||||||||
|
This document describes a framework for providing AI agents with differentiated network acceleration services in home broadband access environments. The framework introduces a Network Acceleration SKILL, provided by the network operator, through which agents subscribe to and request acceleration services directly from the Broadband Remote Access Server (Broadband Remote Access Server). The Broadband Remote Access Server, augmented with a control plane agent, processes acceleration requests, coordinates authorization with the Authentication, Authorization, and Accounting server, and applies per-agent Quality of Service policies on its data plane. A key motivation is to evolve the currently rigid home broadband service model — where plans are fixed on monthly or yearly cycles with static rate limiting — toward a dynamic subscription model that supports on-demand purchase and management of acceleration resources such as time duration or traffic volume. A fundamental design constraint is that existing broadband access procedures, including Customer Premises Equipment authentication, IPv6 prefix delegation, and subscriber billing, remain unmodified. | |||||||||||||
| OAuth 2.0 Approval-Based Dynamic Client Registration | ||||||||||||||
|
This document specifies an extension to the OAuth 2.0 Dynamic Client Registration Protocol ([RFC7591]) that enables registration of a client with an authorization server through an explicit approval step performed by an approving party, typically the user running the client, without requiring the client to possess an Initial Access Token (IAT) beforehand. The client submits its desired metadata to the existing client registration endpoint and signals that it can accept a deferred, approval-based registration. When the authorization server requires approval, it defers completion of the registration and returns a 202 (Accepted) response carrying a registration code and a verification challenge. The client polls the same registration endpoint, presenting the registration code. The approving party, authenticated to the authorization server through a mechanism of the authorization server's choosing, responds to the verification challenge and approves or denies the registration. On approval, a subsequent poll returns a registered client identifier and, where applicable, a client secret. This extension preserves the authorization server operator's ability to require an authenticated, policy-controlled approval for every new client record, while removing the operational burden of issuing an Initial Access Token out of band. | |||||||||||||
| The Kindred Agent Identity Framework (KAIF) | ||||||||||||||
|
The Kindred Agent Identity Framework (KAIF) is an OAuth 2.0 token exchange mechanism for delegated agent-to-service authorization, combining RFC 8693 token exchange with SPIFFE workload identity attestation and operator-assigned authorization tiers. This document specifies the protocol mechanics, deployment profiles, and interoperability requirements for systems implementing agent authorization with audit accountability. KAIF is intended for scenarios in which an operator (human principal) provisionally authorizes an agent (automated workload) to perform bounded actions on their behalf, with cryptographic proof of authorization, delegation depth tracking, and revocation in real time. This document is intentionally vendor-neutral in its normative requirements. Cloud platforms, model providers, workflow systems, and audit backends discussed by implementations are informative deployment examples, not part of the KAIF wire protocol. | |||||||||||||
| OAuth Transaction Tokens Best Current Practice | ||||||||||||||
|
This document provides best current practices for implementing and deploying OAuth 2.0 Transaction Tokens as specified in draft-ietf- oauth-transaction-tokens. Transaction Tokens (Txn-Tokens) enable workloads in a trusted domain to preserve and propagate user identity and authorization context across service boundaries during the processing of external programmatic requests. This BCP addresses practical deployment considerations including token service architecture, size management, propagation patterns, validation strategies, and operational monitoring that are essential for secure and effective implementation in production environments. | |||||||||||||
| NTS extensions for enabling pools | ||||||||||||||
|
The aim of this document is to describe a system for NTS pools that are able to be used by clients without any knowledge beyond plain NTS. The work here focuses purely on creating an intermediate NTS Key Exchange server that can be configured with the addresses of multiple servers and distribute load between them. The parts of pool operation dealing with managing the list of servers are left out of scope for this work. | |||||||||||||
| OAuth Identity and Authorization Chaining Across Domains | ||||||||||||||
|
This specification describes a mechanism for preserving identity and authorization information across trust domains that use the OAuth 2.0 Framework. A JSON Web Token (JWT) authorization grant, obtained through an intra-domain OAuth 2.0 Token Exchange, facilitates the cross-domain acquisition of an access token. The relevant identity and authorization information is chained throughout the flow by being conveyed in the respective artifacts exchanged at each step of the process. Chaining across multiple domains is achieved by using the same protocol every time a trust domain boundary is crossed. | |||||||||||||
| Same Entity Set Support for EPP | ||||||||||||||
|
This document defines an EPP extension allowing clients to learn about and manipulate a set of objects in a shared central repository that are necessarily tied to the same entity (typically domain objects whose names are equivalent in a registry-defined way and are tied to a single registrant). The extension supports multiple registries with a shared definition of equivalence using a shared central repository. | |||||||||||||
| Source Address Validation Using BGP UPDATEs,ASPA,and ROA (BAR-SAV) | ||||||||||||||
|
Designing an efficient source address validation (SAV) filter requires minimizing false positives (i.e., avoiding blocking legitimate traffic) while maintaining directionality (see RFC8704). This document advances the technology for SAV filter design through a method that makes use of BGP UPDATE messages, Autonomous System Provider Authorization (ASPA), and Route Origin Authorization (ROA). The proposed method's name is abbreviated as BAR-SAV. BAR-SAV can be used by network operators to derive more robust SAV filters and thus improve network resilience. This document updates RFC8704. | |||||||||||||
| Problem Statement,Gap Analysis,and Requirements for Inter-Domain Source Address Validation | ||||||||||||||
|
This document analyzes the problem space and provides a gap analysis of existing inter-domain source address validation (SAV) mechanisms. Based on these findings, it outlines the technical requirements for future improvements. | |||||||||||||
| YANG Data Models for Layer 3 and Packet TE Topologies | ||||||||||||||
|
This document defines YANG data models for layer 3 and packet traffic engineering topologies. | |||||||||||||
| Realizing Network Slices in IP/MPLS Networks | ||||||||||||||
|
Realizing network slices may require the Service Provider to have the ability to partition a physical network into multiple logical networks of varying sizes, structures, and functions so that each slice can be dedicated to specific services or customers. Multiple network slices can be realized on the same network while ensuring slice elasticity in terms of network resource allocation. This document describes a scalable solution to realize network slicing in IP/MPLS networks by supporting multiple services on top of a single physical network by requiring compliant domains and nodes to provide forwarding treatment (scheduling, drop policy, resource usage) based on slice identifiers. | |||||||||||||
| BGP SR Policy Extensions for Administrative Flags | ||||||||||||||
|
Segment Routing is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. An SR Policy is a set of candidate paths, each consisting of one or more segment lists. This document defines an extension to the BGP SR Policy that sets the administrative state of the candidate path or segment list, facilitating the operation and maintenance of the SR Policy. | |||||||||||||
| Advertisement of SR Policy Operational States using BGP Link-State | ||||||||||||||
|
This document defines the extension of BGP Link-State to advertise the operational state of the candidate path or segment list, facilitating the operation and maintenance of the SR Policy. | |||||||||||||
| Integrity Protection of In Situ Operations,Administration,and Maintenance (IOAM) Data Fields | ||||||||||||||
|
In Situ Operations, Administration, and Maintenance (IOAM) records operational (including telemetry) information in packets while they traverse a path in the network. RFC 9197 specifies data fields for IOAM (a.k.a IOAM-Data-Fields) and associated data types. This document specifies integrity protection of IOAM-Data-Fields for Intra-IOAM-Domain use cases. | |||||||||||||
| Operational Guidance for Protection Mechanisms in SRv6 Networks | ||||||||||||||
|
This document describes the Operational Guidance for protection of Segment Routing Over IPv6 (SRv6) networks. | |||||||||||||
| Discovering MNA Capabilities Using LSP Ping | ||||||||||||||
|
This document defines a mechanism for discovering MPLS Network Actions (MNA) capabilities along a Label Switched Path (LSP) using the LSP Ping echo request/reply mechanism defined in RFC 8029. The In-Stack MNA capabilities include the Readable Label Depth (RLD), the maximum sizes of differently scoped Network Action Sub-stacks (MLD_NAS), and supported In-Stack network action opcodes. The Post- Stack MNA capabilities include the maximum Post-Stack MPLS Header size (MLD_PSMH), the Readable Label Depth including the Post-Stack MPLS Header (RLD_PSMH), and supported Post-Stack network action opcodes. This mechanism allows the ingress Label Edge Router (LER) to discover MNA capabilities of each transit and egress node on the path, enabling correct construction of MPLS label stacks containing MNA network actions. | |||||||||||||
| IS-IS,OSPF,and BGP-LS Extensions for Advertising Bit Error Rate Metric for Traffic Engineering | ||||||||||||||
|
Networks may experience transmission bit errors due to various factors, such as poor fiber quality. This document describes extensions to IS-IS, OSPF, and BGP-LS to advertise the Bit Error Rate (BER) and Packet Error Rate (PER) metrics for the links that can be used for Traffic Engineering. Note that mechanisms for measuring bit errors or acting on that information, once advertised, are outside the scope of this document. | |||||||||||||
| An Overview of Messaging Systems and Their Applicability to Agentic AI | ||||||||||||||
|
Agentic AI systems require messaging infrastructure that supports real-time collaboration, high-volume streaming, and dynamic group coordination across distributed networks. Traditional protocols like AMQP [AMQP], MQTT [MQTT], and NATS [NATS] address some requirements but fall short on security, particularly regarding post-compromise protection and forward secrecy essential for autonomous agents handling sensitive data. This document analyzes six messaging protocols—AMQP, MQTT, NATS, AMQP over WebSockets, Kafka, and AGNTCY SLIM—across dimensions critical for GenAI agent systems: streaming performance, delivery guarantees, security models, and operational complexity. We examine how each protocol's design decisions impact agentic AI deployments, from lightweight edge computing scenarios to large-scale multi- organizational collaborations. AGNTCY SLIM emerges as a purpose-built solution, integrating Message Layer Security (MLS) [RFC9420] with gRPC [gRPC] over HTTP/2 [RFC9113] to provide end-to-end encryption with forward secrecy, efficient streaming, and OAuth-based authentication [RFC6749]. Unlike transport-layer security approaches, SLIM's MLS implementation ensures secure communication even through untrusted intermediaries while supporting dynamic group membership changes essential for collaborative AI agents. | |||||||||||||
| Secure Low-Latency Interactive Messaging (SLIM) | ||||||||||||||
|
This document specifies the Secure Low-Latency Interactive Messaging (SLIM), a protocol designed to support real-time interactive AI applications at scale. SLIM provides the transport layer for agent protocols (for example, A2A and MCP), combining gRPC over HTTP/2 and HTTP/3 with secure messaging, group communication, and native RPC semantics. The protocol provides mechanisms for connection management, stream multiplexing, and flow control while maintaining compatibility with existing gRPC deployments and supporting end-to- end encryption via MLS. | |||||||||||||
| Agent Passport System (APS): Verifiable Agent Identity,Faceted Authority,and Signed Action Receipts | ||||||||||||||
|
This document specifies the Agent Passport System (APS), a protocol for identifying AI agents, attenuating delegated authority, and producing signed evidence at policy-enforcement boundaries. APS defines Ed25519 agent passports; separately signed principal bindings; delegation chains that cannot widen across scope, spend, depth, time, reputation, values, or reversibility; deterministic action and decision references; and a common envelope for signed action receipts. It also defines bindings for Model Context Protocol tool calls and imported OAuth identity-assertion authorization grants. Verification results keep cryptographic integrity, signer authority, referenced-artifact resolution, policy semantics, and external truth separate. An Implementation Status section identifies the exact coverage and maturity of the available open-source implementations. | |||||||||||||
| NAIM: A Canonical Semantic Representation for AI-Assisted YANG Modeling and Validation | ||||||||||||||
|
This document defines the NAIM (Natural AI Interface Modeling) framework, a canonical semantic intermediate representation between natural language descriptions and YANG data models (RFC 7950). NAIM addresses a recognized gap in the YANG authoring and network management workflow: direct conversion from natural language to YANG is error-prone because essential modeling semantics -- including configuration versus state distinction, list key identification, constraint expressions, operational preconditions, and cross-module relationships -- are routinely absent or ambiguous in natural language input. NAIM makes these semantics explicit, structurally consistent, and machine-verifiable. This document defines: the NAIM Document format (Canonical JSON and derived Markdown View); the LLM Context View for AI prompt context distribution; the three-layer architecture (Specification, Skill, Tool); Skills A-D for conversational modeling, summarization, YANG generation, and reverse engineering; and the Validation-Reflection- Retry mechanism for AI output quality control. The NAIM Document format is designed to serve two roles: as the intermediate representation for design-time YANG authoring, and as the runtime semantic authority against which AI-generated operation intents are validated. The runtime validation usage is specified in [NAIM-OP]; this document defines the format, derived views, and design-time workflows. | |||||||||||||
| Deploying IPv6 in Data Centers | ||||||||||||||
|
Data center operators are moving toward IPv6-only operation to simplify addressing, restore end-to-end connectivity, and meet operator and government timelines. Much published IPv6 guidance targets network engineers; this document instead addresses *Site Reliability Engineers (SREs)* and *Software Engineers (SWEs)* who deploy, operate, and debug services in *operator-owned data centers*. It is organized in two parts after IPv6 fundamentals: a *migration program* (transition strategy and observability) and a *technical stack* (hardware, provisioning, transport, applications, and diagnostics). It documents common software and infrastructure gaps and offers practical deployment patterns aligned with the IPv6 Operations (v6ops) working group charter. | |||||||||||||
| Disclosure of Negative Trust Anchors in DNS Responses | ||||||||||||||
|
This document describes a mechanism for disclosing that a Negative Trust Anchor (NTA) was in effect at the time that a DNS response was generated, using an Extended DNS Error (EDE). | |||||||||||||
| Requirements for Name-Based Compute-Service Discovery in Heterogeneous Space-Terrestrial-Maritime Edge Networks | ||||||||||||||
|
Future edge systems may span terrestrial infrastructure, maritime gateways, and non-terrestrial nodes such as low-Earth-orbit satellites. In these environments, a computing service, its executable instances, input data, and reusable results may be distributed across intermittently connected and resource-constrained nodes. This document describes a problem statement, an illustrative network model, and requirements for name-based discovery of computing services and reusable results. The objective is to separate stable service identity from temporary execution location while supporting disruption awareness, metadata authenticity, controlled result reuse, and incremental deployment over existing IP and Information-Centric Networking infrastructures. This document does not define a wire protocol, a naming syntax, or a traffic-steering algorithm. | |||||||||||||
| YANG Data Model for BGP Outbound Route Filtering | ||||||||||||||
|
This document defines YANG data models for managing BGP Outbound Route Filter (ORF), including Address Prefix ORF, Covering Prefixes ORF (CP-ORF), and VPN Prefix ORF. | |||||||||||||
| Bound Routing,Authority,and Identity Data (BRAID): Independent Circuit Breakers for Long-Lived TLS Certificates | ||||||||||||||
|
This document defines BRAID, a negotiated profile for publicly trusted TLS server certificates that adds one or more independent circuit breakers to a certificate. Each circuit breaker is an authorization held by a party the domain owner appoints; withdrawing any required authorization causes the certificate to stop validating. Because a certificate can be invalidated promptly and without the participation of the issuing certification authority, its natural validity period no longer has to be short in order to bound exposure. The base mechanism is deliberately static. The domain owner publishes a DNSSEC-signed BRAID Anchor listing the public keys authorized to authenticate the domain, and thereafter does nothing; the certificate remains valid until the owner withdraws an entry. Steady-state operation requires no periodic reissuance, no periodic re-minting of credentials, and no online status service. Short- interval credential refresh is defined as an optional enhancement that tightens revocation latency, not as a requirement. Because the Anchor authorizes credential keys rather than the end- entity key itself, impersonating a BRAID-protected domain requires both the end-entity private key and the ability to publish in the owner's DNSSEC-signed zone. This document calls that the Two-Control Property, and it is the principal security difference between BRAID and publishing an end-entity certificate association directly in DNS. BRAID support is negotiated in the handshake, so a BRAID certificate is presented only to a client that offered to validate it; every other client is served an ordinary certificate and is unaffected. Optional strands bind a certificate to an authorized routing origin and to an appointed third-party witness. | |||||||||||||
| Congestion Control Based on SRv6 Path | ||||||||||||||
|
This document describes a congestion control solution based on SRv6. It defines mechanisms for congestion notification and flow control within an SRv6-based network, optimizing congestion handling through hierarchical congestion control messages along SRv6 paths. | |||||||||||||
| DNS NTA feed zones | ||||||||||||||
|
This memo documents a method for expressing a list of DNS negative trust anchors [RFC7646] inside a specially constructed DNS zone, that validating recursive name servers and other DNSSEC validators may configure negative trust anchors from. | |||||||||||||
| The AEO1 Discovery Mechanism: A DNS-Anchored,Signed Pointer to Owner-Attested Fact Catalogs for AI Answer Engines | ||||||||||||||
|
This document specifies AEO1 (Answer Engine Optimization, version 1), a discovery mechanism that allows a domain owner to publish a verifiable, machine-readable pointer to a structured, owner-attested fact catalog for that domain. AEO1 consists of three coordinated surfaces: a DNS TXT record at the "_aeo" subdomain, a JSON document at the well-known URI "/.well-known/aeo.json", and an optional HTML link hint. Records may carry an Ed25519 signature issued by an issuing authority, enabling consuming agents such as AI answer engines to distinguish verified, current, domain-authorized data from unverified crawled content. The design follows the DNS-authenticated trust-anchor pattern established by SPF, DKIM, and DMARC. This document also requests provisional registration of the "aeo.json" well-known URI suffix. | |||||||||||||
| IGP Flexible Algorithm Utilizing Link Bit Error Rate Metric | ||||||||||||||
|
Networks may experience transmission bit errors due to various factors, such as poor fiber quality. This document defines extensions to the IGP Flexible Algorithm to utilize the link Bit Error Rate (BER) metric as a link constraint. It defines a mechanism to exclude links whose BER metric exceeds a configured threshold during Flex-Algorithm path computation. The mechanism utilizes BER metric advertisement defined for IS-IS and OSPF in draft-gandhi-lsr- ber. | |||||||||||||
| Operation Intent Intermediate Representation for AI-Assisted Network Management | ||||||||||||||
|
This document defines Operation IR, a protocol-neutral intermediate representation for runtime network operations in the NAIM architecture. Operation IR serves as an AI-friendly operation layer between AI agents or LLM-based systems and the underlying network management protocols. It captures write operations, retrieval, RPC/ action invocation, filtering, transaction metadata, precondition verification, compensation semantics, and optional expression-based values. Operation IR is designed to be consumed by any upstream mechanism capable of generating structured operation intent, including but not limited to MCP tool invocations, function calling interfaces, and agent-to-agent communication protocols. The translation of Operation IR into protocol-specific messages is performed deterministically by a Handler component, keeping the AI agent in the role of intent encoder rather than protocol executor. This document also defines context completeness classes for the Originator (AI agent) side, validation feedback requirements, and an execution preview mode intended to improve safety and operator trust. It standardizes semantic expectations and interoperability boundaries, but does not standardize proprietary dialogue policies, implementation-specific scheduling internals, automatic compensation derivation algorithms, or private execution-engine logic. | |||||||||||||
| Implementing the NAIM Framework over the Model Context Protocol | ||||||||||||||
|
NAIM (Natural AI Interface Modeling) is a semantic intermediate representation framework for AI-assisted network management. It consists of two specifications: a core specification [NAIM-CORE] that defines the NAIM Document format, YANG-aware node templates, type representation, and design-time Skills A-D; and an operations specification [NAIM-OP] that defines the Operation IR, runtime execution semantics, transaction and compensation model, and runtime Skills E-F. The Model Context Protocol (MCP) has emerged as the dominant standard for AI hosts to discover and invoke external capabilities. However, MCP delegates semantic understanding entirely to the AI model through natural language Tool descriptions, which is insufficient for the structured precondition checking, constraint validation, and compensation logic that reliable network management requires. This document specifies how the NAIM framework is implemented over MCP. It defines the Originator/Handler architectural split, the MCP Resources through which NAIM LLM Context Views are distributed, the minimal MCP Tool surface through which Operation IRs are submitted, and the complete interaction flow from natural language intent to validated network execution. This document is self-contained with respect to the MCP integration architecture; it references [NAIM-CORE] and [NAIM-OP] for the NAIM Document format, Operation IR structure, and execution engine semantics, which are not redefined here. | |||||||||||||
| IS-IS,OSPF,BGP-LS,and BGP Extensions for Signaling STAMP Parameters | ||||||||||||||
|
The Simple Two-Way Active Measurement Protocol (STAMP), as defined in RFC 8762, can be utilized for active measurement without relying on a control channel to pre-signal session parameters. This document describes the extensions to IS-IS, OSPF, BGP-LS, and BGP protocols for signaling STAMP reflector parameters in a network. The STAMP reflector parameters can be used by the STAMP senders to set up appropriate performance measurement sessions for delay and packet loss metrics. | |||||||||||||
| Transparent Handling of Internationalized Domain Names in Name Resolution APIs | ||||||||||||||
|
Applications are expected to convert internationalized domain names to their ASCII-Compatible Encoding (A-label) form before invoking name resolution APIs. In practice this conversion is performed inconsistently: different applications follow different IDNA standards, use different libraries, and ship different versions of the Unicode mapping tables, so that the same input string can resolve to different registrable domain names depending on which software component performs the conversion. This document specifies that name resolution services accept Unicode host names by default and perform the conversion to A-labels internally, exactly once, at the point where a name is handed to a specific resolution protocol. The DNS wire format is unchanged: only A-labels appear in queries to the public DNS. The conversion procedure is Unicode IDNA Compatibility Processing (UTS #46), nontransitional, with a mapping-table floor of Unicode 15.1. This codifies the architectural recommendation of RFC 6055 and the deployed practice of several major platforms. | |||||||||||||
| Requirements of SRv6 for the 6G User Plane | ||||||||||||||
|
This document leverages the five standardized 6G service scenarios defined in 3GPP TR 22.870—multi-agent collaborative communication, compute-network integration, integrated sensing and communication (ISAC), network digital twin (NDT), and wide-area deterministic networking—as core business baselines. It systematically analyzes the multi-dimensional stringent user-plane requirements introduced by next-generation mobile systems. This work further dissects inherent technical limitations within the 5G GTP-U point-to-point tunnel architecture that render it incapable of accommodating dynamic 6G service characteristics. Based on the above analysis, this draft illustrates the inherent programmability benefits provided by SRv6, and accordingly establishes a suite of standardization requirements for SRv6 to serve as the underlay forwarding protocol of the 6G user plane. | |||||||||||||
| Cognitive Sovereignty (CS): A Framework for Verifiable Human Epistemic Autonomy over Agent-Curated Content | ||||||||||||||
|
As autonomous AI agents become the primary intermediaries between humans and the web, humans increasingly perceive the web only as agents present it: summarized, filtered, ranked, translated, and rewritten. Machine-Web Symbiosis [REILLY-MWS] gives machines verifiable ground truth about web content; no equivalent mechanism gives humans verifiable ground truth about what agents did to that content before presenting it. This document defines Cognitive Sovereignty (CS): the principle that a human consuming agent-curated content retains the right and the technical capacity to (1) know that curation occurred, (2) inspect what transformations were applied and under what declared agent policy, (3) reach the attested, un-curated source, and (4) verify all of the above using only public data and open specifications. The document specifies a complete implementation: the Curation Disclosure Record (CDR) format, the pipeline by which conforming agents generate CDRs, the mechanisms by which CDRs are delivered alongside curated content, and the procedure by which any consumer verifies them. CS composes directly with the Reilly Protocol Suite: MWS records supply source ground truth, the Cognitive Trust Stack supplies agent behavioral provenance, and Dual-Layer Digital Permanence anchors the disclosure chain. | |||||||||||||
| AI P2MP Mechanism Evaluation | ||||||||||||||
|
AI workloads in data centers exhibit inherently point-to-multipoint (P2MP) communication patterns. During distributed training, collective operations such as AllReduce, AllGather and Broadcast require identical data delivery to many receivers. During inference serving, P2MP patterns also arise from mechanisms such as KV-cache distribution in disaggregated serving architectures and speculative- decoding verifier fan-out. Unicast replication of these flows does not scale to large GPU clusters. This document evaluates two architectural mechanisms for addressing this problem: extending BIER (Bit Index Explicit Replication) to support AI P2MP requirements, or defining a new purpose-built protocol. The evaluation is grounded in the transport-layer requirements this P2MP communication pattern places on a multicast solution, i.e., the requirements imposed by RDMA and RoCEv2 semantics rather than by the choice of network-layer replication mechanism, including considerations around ACK aggregation, congestion control, RoCE/RDMA compatibility and operational complexity. This document does not define a protocol but is intended instead to help the mcast4ai community evaluate this problem space. | |||||||||||||
| Requirements for Disruption-Aware Compute-Task Descriptors in Heterogeneous Space-Terrestrial-Maritime Edge Networks | ||||||||||||||
|
Compute tasks in heterogeneous edge environments may traverse terrestrial, maritime, airborne, and non-terrestrial domains before an eligible execution site becomes reachable. Conventional request formats often assume an immediately selected endpoint and a continuously available request-response path. Those assumptions are fragile when connectivity is intermittent, service instances move, inputs are named and distributed, and duplicate delivery can occur. This document describes a problem statement, a conceptual compute- task descriptor, and requirements for carrying a portable task description across disruption-prone edge networks. The descriptor separates the identity and semantics of a task from a particular execution location. It binds the requested service, named inputs, relevant parameters, timing constraints, authorization policy, and expected result properties while supporting store-carry-forward operation, duplicate suppression, verifiable execution receipts, and result provenance. This document does not define a wire encoding, task-placement algorithm, traffic-steering protocol, or execution runtime. | |||||||||||||
| A Metadata Model for Verifiable and Reusable Compute-Result Objects in Information-Centric Edge Networks | ||||||||||||||
|
Distributed edge systems can execute the same logical computing service at multiple sites and can retain previously generated outputs in gateways, caches, or result stores. Reusing such an output can reduce communication and computation, but a payload alone does not indicate which service, inputs, parameters, execution environment, or validity conditions produced it. This document defines a conceptual metadata model for named compute-result objects. The model binds a result payload to service identity, input identity, invocation context, execution provenance, freshness information, and reuse policy. It also describes validation and cache-reuse workflows for intermittently connected and multi-domain edge environments. This document does not define a wire encoding, a naming syntax, a remote- attestation profile, or a traffic-steering protocol. | |||||||||||||
| Confirmation Response Parameter for OAuth 2.0 Token Exchange | ||||||||||||||
|
This specification defines a cnf response parameter for the OAuth 2.0 Token Exchange (RFC 8693) response. The parameter carries the confirmation method that the authorization server applied to the issued token, enabling clients to verify that sender-constraint binding (for example a DPoP key or mutual-TLS client certificate) was performed without inspecting the issued token. This is useful for opaque tokens, encrypted tokens, or any other case where the client cannot read the issued token's cnf claim directly. | |||||||||||||
| Considerations for Selecting Post-Quantum Algorithms for DNSSEC | ||||||||||||||
|
This draft lists many of the considerations that the DNS community needs to balance when it is deciding which post-quantum algorithms to standardize for DNSSEC. This draft is definitely not meant to become an RFC. | |||||||||||||
| Anti-Money Laundering Methods Values | ||||||||||||||
|
Financial regulations require application of Anti-Money Laundering (AML) and Countering the Financing of Terrorism (CFT) methods in many jurisdictions worldwide. This specification defines a claim and values for declaring what AML/CFT methods were employed. | |||||||||||||
| SRv6 Deployment and Operation Problem Summary | ||||||||||||||
|
This document aims to provide a concise overview of the common problems encountered during SRv6 deployment and operation, which provides foundations for further work, including for example of potential solutions and best practices to navigate deployment. | |||||||||||||
| BGP Extended Communities Attribute | ||||||||||||||
|
This document describes the "Extended Communities" BGP-4 attribute. This attribute provides a mechanism for labeling information carried in BGP-4. These labels can be used to control the distribution of this information, or for other applications. This document obsoletes RFC 4360. This document also updates RFC 5701 by adding an "Operational Considerations" section. | |||||||||||||
| Agent Communication Gateway for Semantic Routing and Working Memory | ||||||||||||||
|
This document presents an architectural framework for an Agent Communication Gateway (Agent-GW), designed to support large-scale, heterogeneous, and dynamic multi-agent collaboration across administrative and protocol boundaries. As agents evolve from isolated entities to a collaborative digital workforce, the infrastructure must transition from rigid, endpoint- based connectivity to intent-based interaction. This draft proposes Agent-GW as an infrastructure hub that provides native primitives for Semantic Routing (dispatching tasks by intent and capability), Working Memory (shared structured context across multi-step workflows), automated protocol adaptation (normalizing heterogeneous interfaces into a unified agent-facing protocol), oracle-free agent evaluation, and collaborative inference acceleration via a Knowledge Delivery Network (KDN). Beyond a single-gateway deployment, this document defines a hierarchical architecture for wide-area, multi-domain agent networks: three gateway tiers (access, domain, and inter-domain). It describes which traffic classes traverse which tiers on both the data plane and the control plane, and specifies cross-domain semantic routing, name resolution, resilience, and operational considerations. | |||||||||||||
| SR Policies Extensions for Network Resource Partition in BGP-LS | ||||||||||||||
|
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 ID is an important network resource attribute associated with the Segment Routing (SR) policy and needs to be reported to the external components. This document defines a new TLV which enables the headend to report the NRP which the SR Policy Candidate Path (CP) is associated with using Border Gateway Protocol Link-State (BGP-LS). | |||||||||||||
| A YANG Data Model for SIMAP | ||||||||||||||
|
This document defines a YANG data model for Service & Infrastructure Maps (SIMAP). It extends the RFC8345 YANG modules to support all SIMAP requirements. This document will only focus on modelling proposal for each of the requirements not supported by RFC8345. Any related terminology, concepts, use cases and requirements are defined outside of this draft and this draft will only refer to them, analyze how to model and propose the implementation solutions. | |||||||||||||
| DHCP New Option Extension based on LLM Capability | ||||||||||||||
|
This document specifies a DHCP option extension designed for campus networks to help client devices distinguish and connect to a master device with the LLM (Large Language Model). The mechanism extends a new DHCP option containing two specific parameters within the DHCP payload: the master device's LLM address and the master device's LLM configuration. This allows client devices to identify and register to LLM-enabled master device during the bootstrap phase. | |||||||||||||
| IPv6 Node Requirements | ||||||||||||||
|
This document defines requirements for IPv6 nodes. It is expected that IPv6 will be deployed in a wide range of devices and situations. Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments. This document obsoletes RFC 8504, and in turn RFC 6434 and its predecessor, RFC 4294. | |||||||||||||
| Ephemeral Diffie-Hellman Over COSE (EDHOC) and Object Security for Constrained Environments (OSCORE) Profile for Authentication and Authorization for Constrained Environments (ACE) | ||||||||||||||
|
This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. It utilizes Ephemeral Diffie-Hellman Over COSE (EDHOC) for achieving mutual authentication between an ACE-OAuth client and resource server, and it binds an authentication credential of the client to an ACE-OAuth access token. EDHOC also establishes an Object Security for Constrained RESTful Environments (OSCORE) Security Context, which is used to secure communications between the client and resource server when accessing protected resources according to the authorization information indicated in the access token. This profile can be used to delegate management of authorization information from a resource-constrained server to a trusted host with less severe limitations regarding processing power and memory. | |||||||||||||
| Using the Constrained RESTful Application Language (CoRAL) with the Admin Interface for the OSCORE Group Manager | ||||||||||||||
|
Group communication for the Constrained Application Protocol (CoAP) can be secured using Group Object Security for Constrained RESTful Environments (Group OSCORE). A Group Manager is responsible to handle the joining of new group members, as well as to manage and distribute the group keying material. The Group Manager can provide a RESTful admin interface that allows an Administrator entity to create and delete OSCORE groups, as well as to retrieve and update their configuration. This document specifies how an Administrator interacts with the admin interface at the Group Manager by using the Constrained RESTful Application Language (CoRAL). The ACE framework for Authentication and Authorization is used to enforce authentication and authorization of the Administrator at the Group Manager. Protocol-specific transport profiles of ACE are used to achieve communication security, proof of possession, and server authentication. | |||||||||||||
| Short Distribution Chain (SDC) Workflow and New OAuth Parameters for the Authentication and Authorization for Constrained Environments (ACE) Framework | ||||||||||||||
|
This document updates the Authentication and Authorization for Constrained Environments framework (ACE, RFC 9200) as follows. (1) It defines the Short Distribution Chain (SDC) workflow that the authorization server (AS) can use for uploading an access token to a resource server on behalf of the client. (2) For the OAuth 2.0 token endpoint, it defines new parameters and encodings and it extends the semantics of the "ace_profile" parameter. (3) For the OAuth 2.0 authz-info endpoint, it defines a new parameter and its encoding. (4) It defines how the client and the AS can coordinate on the exchange of the client's and resource server's public authentication credentials, when those can be transported by value or identified by reference; this extends the semantics of the "rs_cnf" parameter for the OAuth 2.0 token endpoint, thus updating RFC 9201. (5) It extends the error handling at the AS, for which it defines a new error code. (6) It deprecates the original payload format of error responses conveying an error code, when Concise Binary Object Representation (CBOR) is used to encode message payloads. For those responses, it defines a new payload format aligned with RFC 9290, thus updating in this respect also the profiles defined in RFC 9202, RFC 9203, and RFC 9431. (7) It amends two of the requirements on profiles of the framework. | |||||||||||||
| The Group Object Security for Constrained RESTful Environments (Group OSCORE) Profile of the Authentication and Authorization for Constrained Environments (ACE) Framework | ||||||||||||||
|
This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. The profile uses Group Object Security for Constrained RESTful Environments (Group OSCORE) to provide communication security between a client and one or multiple resource servers that are members of an OSCORE group. The profile securely binds an OAuth 2.0 access token to the public key of the client associated with the private key used by that client in the OSCORE group. The profile uses Group OSCORE to achieve server authentication and proof of possession of the client's private key. Also, it provides proof of the client's membership to the OSCORE group by binding the access token to information that pertains to the Group OSCORE Security Context, thus allowing the resource server(s) to verify the client's membership upon receiving the access token. Effectively, the profile enables fine-grained access control paired with secure group communication, in accordance with the Zero Trust principles. | |||||||||||||
| Additional Formats of Authentication Credentials for the Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE) | ||||||||||||||
|
This document updates the Datagram Transport Layer Security (DTLS) profile for Authentication and Authorization for Constrained Environments (ACE). In particular, it specifies the use of additional formats of authentication credentials for establishing a DTLS session, when peer authentication is based on asymmetric cryptography. Therefore, this document updates RFC 9202. What is defined in this document is seamlessly applicable also if the profile uses Transport Layer Security (TLS) instead of DTLS, as defined in RFC 9430. | |||||||||||||
| CoAP Publish-Subscribe Profile for Authentication and Authorization for Constrained Environments (ACE) | ||||||||||||||
|
This document defines an application profile of the Authentication and Authorization for Constrained Environments (ACE) framework, to enable secure group communication in the Publish-Subscribe (Pub-Sub) architecture for the Constrained Application Protocol (CoAP) [draft- ietf-core-coap-pubsub], where Publishers and Subscribers communicate through a Broker. This profile relies on protocol-specific transport profiles of ACE to achieve communication security, server authentication, and proof of possession of a key owned by the Client and bound to an OAuth 2.0 access token. This document specifies the provisioning and enforcement of authorization information for Clients to act as Publishers and/or Subscribers, as well as the provisioning of keying material and security parameters that Clients use for protecting their communications end-to-end through the Broker. Note to RFC Editor: Please replace "[draft-ietf-core-coap-pubsub]" with the RFC number of that document and delete this paragraph. | |||||||||||||
| RTCP Feedback Message and Request Mechanism for Frame-level Acknowledgement | ||||||||||||||
|
This document describes a mechanism for signaling which video frames have been received and decoded by a remote peer. It comprises an RTCP feedback message and an RTP header extension used to request said feedback. One of the main use cases for this data is to implement various forms of Long Term Reference (LTR) reference structures. Additionally, the mechanism provides a way for receivers to request resynchronization frames that reference acknowledged frames, enabling efficient recovery from partial or full frame loss without requiring a full keyframe. | |||||||||||||
| Controller-based BGP Multicast Signaling | ||||||||||||||
|
This document specifies a way that one or more centralized controllers can use BGP to set up multicast distribution trees (identified by either IP source/destination address pair, or mLDP FEC) in a network. Since the controllers calculate the trees, they can use sophisticated algorithms and constraints to achieve traffic engineering. The controllers directly signal dynamic replication state to tree nodes, leading to very simple multicast control plane on the tree nodes, as if they were using static routes. This can be used for both underlay and overlay multicast trees, including replacing BGP-MVPN signaling. | |||||||||||||
| BGP Extensions for the Mobile User Plane (MUP) SAFI | ||||||||||||||
|
This document defines a new SAFI known as a BGP Mobile User Plane (BGP-MUP) SAFI to support MUP Extensions and a extended community for BGP. This document also provides BGP signaling and procedures for the new SAFI to convert mobile session information into appropriate IP forwarding information. These extensions can be used by operators between a PE, and a Controller for integrating mobile user plane into BGP MUP network using the IP based routing. | |||||||||||||
| JSContact: Converting from and to vCard | ||||||||||||||
|
This document defines how to convert contact information between the JSContact and vCard data formats. It defines conversion rules for every JSContact and vCard element registered at IANA at the time of publication. It also defines new JSContact properties as well as vCard properties and parameters, to support converting arbitrary or unknown JSContact and vCard elements. This document obsoletes RFC 9555 and updates its definitions for JSContact version "2.0". Note This note is to be removed before publishing as an RFC. Differences from RFC 9555 are documented in Appendix A. | |||||||||||||
| BBR Congestion Control | ||||||||||||||
|
This document specifies the BBR congestion control algorithm. BBR ("Bottleneck Bandwidth and Round-trip propagation time") uses recent measurements of a transport connection's delivery rate, round-trip time, and packet loss rate to build an explicit model of the network path. BBR then uses this model to control both how fast it sends data and the maximum volume of data it allows in flight in the network at any time. Relative to loss-based congestion control algorithms such as Reno [RFC5681] or CUBIC [RFC9438], BBR offers substantially higher throughput for bottlenecks with shallow buffers or random losses, and substantially lower queueing delays for bottlenecks with deep buffers (avoiding "bufferbloat"). BBR can be implemented in any transport protocol that supports packet-delivery acknowledgment. Thus far, open source implementations are available for TCP [RFC9293] and QUIC [RFC9000]. This document specifies version 3 of the BBR algorithm, BBRv3. | |||||||||||||
| Self-Clocked Rate Adaptation for Multimedia | ||||||||||||||
|
This memo describes Self-Clocked Rate Adaptation for Multimedia version 2 (SCReAMv2), an update to SCReAM congestion control for media streams such as RTP [RFC3550]. SCReAMv2 includes several algorithm simplifications and adds support for L4S. The algorithm supports handling of multiple media streams, typical use cases are streaming for remote control, AR and 3D VR goggles. This specification obsoletes RFC 8298. | |||||||||||||
| Content Delivery Network Interconnection (CDNI) Edge Control Metadata | ||||||||||||||
|
This specification defines configuration metadata objects used to manage how edge servers control access to resources within Content Delivery Networks (CDNs) and Open Caching systems. A key feature of these configurations is the configuring of Cross-Origin Resource Sharing (CORS) access rules and the dynamic generation of CORS headers. This specification also provides the ability to define response body compression rules and client connection timeouts. | |||||||||||||
| CDNI Protected Secrets Metadata | ||||||||||||||
|
This document defines a simple mechanism for protected secret data (such as salt values or encryption keys) that may be embedded in configuration metadata or capabilities advertisements. | |||||||||||||
| CDNI Logging Extensions | ||||||||||||||
|
This document defines a set of extensions to CDNI for supporting transmission of transaction logs in both push and pull operational modes, new log container formats and log record formats, new logging fields, and metadata for describing the transformation, obfuscation, and encryption of log record fields. | |||||||||||||
| BLS Signatures | ||||||||||||||
|
BLS is a digital signature scheme with aggregation properties. Given set of signatures (signature_1, ..., signature_n) anyone can produce an aggregated signature. Aggregation can also be done on secret keys and public keys. Furthermore, the BLS signature scheme is deterministic, non-malleable, and efficient. Its simplicity and cryptographic properties allows it to be useful in a variety of use- cases, specifically when minimal storage space or bandwidth are required. | |||||||||||||
| Guidelines for Writing Cryptography Specifications | ||||||||||||||
|
This document provides guidelines and best practices for writing technical specifications for cryptography protocols and primitives, targeting the needs of implementers, researchers, and protocol designers. It highlights the importance of technical specifications and discusses strategies for creating high-quality specifications that cater to the needs of each community, including guidance on representing mathematical operations, security definitions, and threat models. | |||||||||||||
| Hybrid PQ/T Key Encapsulation Mechanisms | ||||||||||||||
|
This document defines generic constructions for hybrid Key Encapsulation Mechanisms (KEMs) based on combining a post-quantum (PQ) KEM with a traditional cryptographic component. Hybrid KEMs built using these constructions provide strong security properties as long as either of the underlying algorithms are secure. | |||||||||||||
| Concrete Hybrid PQ/T Key Encapsulation Mechanisms | ||||||||||||||
|
PQ/T Hybrid Key Encapsulation Mechanisms (KEMs) combine "post- quantum" cryptographic algorithms, which are safe from attack by a quantum computer, with "traditional" algorithms, which are not. CFRG has developed a general framework for creating hybrid KEMs. In this document, we define concrete instantiations of this framework to illustrate certain properties of the framework and simplify implementors' choices. | |||||||||||||
| Observe Notifications as CoAP Multicast Responses | ||||||||||||||
|
The Constrained Application Protocol (CoAP) allows clients to "observe" resources at a server and to receive notifications as unicast responses upon changes of the resource state. In some use cases, such as those based on publish-subscribe, it would be convenient for the server to send a single notification addressed to all the clients observing the same target resource. This document updates RFC7252 and RFC7641, and it defines how a server sends observe notifications as response messages over multicast, synchronizing all the observers of the same resource on the same shared Token value. Besides, this document defines how the security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE) can be used to protect multicast notifications end-to- end between the server and the observer clients. | |||||||||||||
| Key Update for OSCORE (KUDOS) | ||||||||||||||
|
Communications with the Constrained Application Protocol (CoAP) can be protected end-to-end at the application-layer by using the security protocol Object Security for Constrained RESTful Environments (OSCORE). Under some circumstances, two CoAP endpoints need to update their OSCORE keying material before communications can securely continue, e.g., due to approaching key usage limits. This document defines Key Update for OSCORE (KUDOS), a lightweight key update procedure that two CoAP endpoints can use to update their OSCORE keying material by establishing a new OSCORE Security Context. Accordingly, this document updates the use of the OSCORE flag bits in the CoAP OSCORE Option as well as the protection of CoAP response messages with OSCORE. Also, it deprecates the key update procedure specified in Appendix B.2 of RFC 8613. Therefore, this document updates RFC 8613. | |||||||||||||
| OSCORE-capable Proxies | ||||||||||||||
|
When using the Constrained Application Protocol (CoAP), messages exchanged between two endpoints can be protected end-to-end at the application layer by means of Object Security for Constrained RESTful Environments (OSCORE), also in the presence of intermediaries such as proxies. This document defines how to use OSCORE for protecting CoAP messages also between an origin application endpoint and an intermediary, or between two intermediaries. Also, it defines rules to escalate the protection of a CoAP option, in order to encrypt and integrity-protect it whenever possible. Finally, it defines how to secure a CoAP message by applying multiple, nested OSCORE protections, e.g., both end-to-end between origin application endpoints; and between an application endpoint and an intermediary or between two intermediaries. Therefore, this document updates RFC 8613. Furthermore, this document updates RFC 8768, by explicitly defining the processing with OSCORE for the CoAP Hop-Limit Option. The approach defined in this document can be seamlessly employed also with Group OSCORE, for protecting CoAP messages when group communication is used in the presence of intermediaries. | |||||||||||||
| End-to-End Protected and Cacheable CoAP Responses using Group Object Security for Constrained RESTful Environments (Group OSCORE) | ||||||||||||||
|
When using the Constrained Application Protocol (CoAP), exchanged messages can be protected end-to-end also across untrusted intermediary proxies. This can be achieved with Object Security for Constrained RESTful Environments (OSCORE) or, in the case of group communication, with Group Object Security for Constrained RESTful Environments (Group OSCORE). However, this sidesteps the proxies' abilities to cache responses from the origin server(s). This document restores cacheability of end-to-end protected responses at proxies, by using Group OSCORE and introducing consensus requests, which any client in an OSCORE group can send to one server or multiple servers in the same group. | |||||||||||||
| URI Path abbreviation in CoAP | ||||||||||||||
|
Applications built on CoAP face a conflict between the technical need for short message sizes and the interoperability requirement of following BCP190 and thus using (relatively verbose) well-known URI paths. This document introduces the Uri-Path-Abbrev CoAP option that allows expressing well-known URI paths in as little as two bytes. Using this option revealed a subtle flaw in RFC7252 that severely limited the extension point of critical options. This document updates RFC7252 to rectify that. | |||||||||||||
| Using Proxies for Observe Notifications as CoAP Multicast Responses | ||||||||||||||
|
The Constrained Application Protocol (CoAP) allows clients to "observe" resources at a server and to receive notifications as unicast responses upon changes of the resource state. Instead of sending a distinct unicast notification to each different client, a server can alternatively send a single notification as a response message over multicast, to all the clients observing the same target resource. When doing so, the security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE) can be used to protect multicast notifications end-to-end between the server and the observer clients. This document describes how multicast notifications can be used in network setups that leverage a proxy, e.g., in order to accommodate clients that are not able to directly listen to multicast traffic. | |||||||||||||
| CoAP: Non-traditional Response Forms | ||||||||||||||
|
In CoAP as defined by RFC 7252, there is generally one response for each request. Various CoAP extensions have individually relaxed that practice. The present memo presents a generalized model beyond 1:1 responses, describes different forms in which it can be used, and introduces new CoAP Options that make use of that model. Beyond that, this document provides implementation guidance to simplify prior extensions, and outlines future possibilities of using it. // This revision -01 has been created as discussion input for IETF // 126. It makes a first attempt to sort the proposals into short- // term actionable ones and more long-term considerations for more // kinds of responses that could help additional use cases through // future work. | |||||||||||||
| On-time Forwarding with Non-Work Conserving Stateless Core Fair Queuing | ||||||||||||||
|
This document specifies the framework and operational procedure for deterministic networking that guarantees maximum and minimum end-to- end latency bounds to flows. The solution has non-periodic, asynchronous, flow-level, non-work conserving, on-time, and rate- based functional characteristics, according to the taxonomy suggested by [I-D.ietf-detnet-dataplane-taxonomy]. The packets are stored in the queue in ascending order of the ideal service start time, called Eligible Time (ET), and the ideal service completion time, called Finish Time (FT). The queued packets were forwarded after ET, in ascending ordering of FT, in a non-work conserving manner. The ET and FT are calculated at the entrance node according to the packet size and rate of the flow. All subsequent core nodes are stateless and asynchronously update ET and FT based on metadata received via packet headers. This mechanism is called non- work conserving stateless fair queuing (N-SCORE), which guarantees both E2E latency upper and lower bounds, thus E2E jitter bound. N-SCORE supports two alternative methods for determining ET and FT at stateless core nodes. The Direct ET/FT Method propagates ET and FT generated by the previous node using the delay factor function. The Arrival-based ET/FT Method reconstructs ET and FT from the locally observed packet arrival time together with metadata carried in the packet header. Both methods provide identical scheduling semantics while allowing different implementation choices. | |||||||||||||
| On-time Forwarding with Push-In First-Out (PIFO) queue | ||||||||||||||
|
This document describes operations of data plane and controller plane for Deterministic Networking (DetNet) to forward packets to meet minimum and maximum end-to-end latency requirements, while utilizing Push-In First-Out (PIFO) queue. According to the solution described in this document, forwarding nodes do not need to maintain flow states or to be time-synchronized with each other. | |||||||||||||
| Digital Emblems - Use Cases and Requirements | ||||||||||||||
|
Digital emblems are a means for an asset to signal to validating entities that it should be protected or treated in a specific way, using some normative framework. This document lists the requirements and use cases that an architecture for digital emblems must accommodate. | |||||||||||||
| Mobile Traffic Steering | ||||||||||||||
|
The evolution of cellular mobile communication systems is aligned with an increasing demand for customized deployments, energy efficiency, dynamic re-configurability and the integration and use of other network technologies, such as non-cellular radio access technologies and non-terrestrial networks. In order to achieve and maintain the expected service quality and continuity, such systems should be designed and controllable end-to-end, taking all involved network domains and segments into account. This document discusses an end-to-end system from an advanced use cases perspective and substantiates the demand for solutions to share information and enable control interfaces between all connected network domains, including the mobile communication system and the transport network that stretches up to the data networks that host service instances. In the view of flexible implementations and deployment, two architectural principles, leveraging either a dedicated controller or a decentralized control plane, are described and discussed, accompanied by operational aspects and an associated information model that enable end-to-end mobile traffic treatment and steering in such complex and dynamically changing networks. | |||||||||||||
| Multiple Algorithm Rules in DNSSEC | ||||||||||||||
|
This document restates the requirements on DNSSEC signing and validation and makes small adjustments in order to allow for more flexible handling of configurations that advertise multiple Secure Entry Points (SEP) with different signing algorithms via their DS record or trust anchor set. The adjusted rules allow both for multi- signer operation and for the transfer of signed DNS zones between providers, where the providers support disjoint DNSSEC algorithm sets. In addition, the proposal enables pre-publication of a trust anchor in preparation for an algorithm rollover, such as of the root zone. This document updates RFCs 4035 and 6840. | |||||||||||||
| Greasing Protocol Extension Points in the DNS | ||||||||||||||
|
Long term evolvability of the Domain Name System (DNS) protocol requires the ability to support change. Greasing is one technique that exercises the regular use of unallocated protocol extension points to prevent ossification of their current usage patterns by middleboxes or DNS implementations. This document describes considerations and proposals for applying grease to the DNS protocol. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-grease. | |||||||||||||
| Advertising Proxy for DNS-SD Service Registration Protocol | ||||||||||||||
|
An Advertising Proxy advertises the contents of a DNS zone, for example maintained using the DNS-SD Service Registration Protocol (SRP), using Multicast DNS. This allows legacy clients to discover services registered with SRP using Multicast DNS. | |||||||||||||
| Multicast DNS conflict resolution using the Time Since Received (TSR) EDNS option | ||||||||||||||
|
This document specifies a new conflict resolution mechanism for DNS, for use in cases where the advertisement is being proxied, rather than advertised directly, e.g. when using a combined DNS-SD advertising proxy and SRP registrar. A new EDNS option is defined that communicates the time at which the set of resource records on a particular DNS owner name was most recently updated. | |||||||||||||
| Hybrid Public Key Encryption | ||||||||||||||
|
This document describes a scheme for hybrid public key encryption (HPKE). This scheme provides a variant of public key encryption of arbitrary-sized plaintexts for a recipient public key. It also includes a variant that authenticates possession of a pre-shared key. HPKE works for any combination of an asymmetric Key Encapsulation Mechanism (KEM), key derivation function (KDF), and authenticated encryption with additional data (AEAD) encryption function. This document provides instantiations of the scheme using widely used and efficient primitives, such as Elliptic Curve Diffie-Hellman (ECDH) key agreement, HMAC-based key derivation function (HKDF), and SHA-2. This document obsoletes RFC 9180. | |||||||||||||
| Post-Quantum and Post-Quantum/Traditional Hybrid Algorithms for HPKE | ||||||||||||||
|
Updating key exchange and public-key encryption protocols to resist attack by quantum computers is a high priority given the possibility of "harvest now, decrypt later" attacks. Hybrid Public Key Encryption (HPKE) is a widely-used public key encryption scheme based on combining a Key Encapsulation Mechanism (KEM), a Key Derivation Function (KDF), and an Authenticated Encryption with Associated Data (AEAD) scheme. In this document, we define KEM algorithms for HPKE based on both post-quantum KEMs and hybrid constructions of post- quantum KEMs with traditional KEMs, as well as a KDF based on SHA-3 that is suitable for use with these KEMs. When used with these algorithms, HPKE is resilient with respect to attacks by a quantum computer. | |||||||||||||
| Byte Range PATCH | ||||||||||||||
|
This document specifies a media type for PATCH payloads that overwrites a specific byte range, facilitating random access writes and segmented uploads of resources. | |||||||||||||
| Resumable Uploads for HTTP | ||||||||||||||
|
HTTP data transfers can encounter interruption due to reasons such as canceled requests or dropped connections. If the intended recipient can indicate how much of the data was processed prior to interruption, a sender can resume data transfer at that point instead of attempting to transfer all of the data again. HTTP range requests support this concept of resumable downloads from server to client. This document describes a mechanism that supports resumable uploads from client to server using HTTP. | |||||||||||||
| Guidelines for Writing an IANA Considerations Section in RFCs | ||||||||||||||
|
Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the fourth edition of this document; it obsoletes RFC 8126. | |||||||||||||
| Early IANA Code Point Allocation | ||||||||||||||
|
This document describes the requirements for securing IANA code point assignments for IETF Stream Internet-Drafts and specifications being drafted by other standards-related organizations. This document obsoletes RFC 7120. | |||||||||||||
| BGP Flow Specification Version 2 - for Basic IP | ||||||||||||||
|
BGP flow specification version 1 (FSv1), defined in RFC 8955, RFC 8956, and RFC 9117, describes the distribution of traffic filter policy (traffic filters and actions) distributed via BGP. During the deployment of BGP FSv1 a number of issues were detected, so version 2 of the BGP flow specification (FSv2) protocol addresses these issues. In order to provide a clear demarcation between FSv1 and FSv2, a different NLRI encapsulates FSv2. The IDR WG requires two implementation. Early feedback on implementations of FSv2 indicate that FSv2 has a correct design direction, but that breaking FSv2 into a progression of documents would aid deployment of the draft (basic, adding more filters, and adding more actions). This document specifies the basic FSv2 NLRI with user ordering of filters added to FSv1 IP Filters and FSv2 actions. | |||||||||||||
| A Border Gateway Protocol 4 (BGP-4) | ||||||||||||||
|
This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol. The primary function of a BGP-speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced. BGP-4 provides a set of mechanisms for supporting Classless Inter- Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths. This document obsoletes RFC 4271. | |||||||||||||
| Terminology for Constrained-Node Networks | ||||||||||||||
|
The Internet Protocol Suite is increasingly used on small devices with severe constraints on power, memory, and processing resources, creating constrained-node networks. This document provides a number of basic terms that have been useful in research and standardization work for constrained-node networks. This document obsoletes RFC 7228. | |||||||||||||
| IoT DNS Security and Privacy Guidelines | ||||||||||||||
|
This document outlines guidance for Internet of Things (IoT) manufacturers regarding the implementation of DNS stub resolver software on devices, and for the management zones used for purposes such as device configuration and software upgrades. It aims to mitigate security threats, enhance privacy, and to address operational security challenges. DNS resolution between devices and management zone servers depends upon DNS services within operator networks, and these services and operator networks can be impacted by device behavior. Hence this document also provides guidance to network operators that deploy IoT devices to mitigate the specific risks identified in this document and take advantage of improved DNS security mechanisms provided by manufacturers. | |||||||||||||
| Responsiveness under Working Conditions | ||||||||||||||
|
For many years, a lack of responsiveness, variously called lag, latency, or bufferbloat, has been recognized as an unfortunate, but common, symptom in today's networks. Even after a decade of work on standardizing technical solutions, it remains a common problem for the end users. Everyone "knows" that it is "normal" for a video conference to have problems when somebody else at home is watching a 4K movie or uploading photos from their phone. However, there is no technical reason for this to be the case. In fact, various queue management solutions have solved the problem. Our network connections continue to suffer from an unacceptable amount of delay, not for a lack of technical solutions, but rather a lack of awareness of the problem and deployment of its solutions. We believe that creating a tool that measures the problem and matches people's everyday experience will create the necessary awareness, and result in a demand for solutions. This document specifies the "Responsiveness Test" for measuring responsiveness. It uses common protocols and mechanisms to measure user experience specifically when the network is under working conditions. The measurement is expressed as "Round-trips Per Minute" (RPM) and should be included with goodput (up and down) and idle latency as critical indicators of network quality. | |||||||||||||
| A YANG Data Model for Network Inventory Location | ||||||||||||||
|
This document defines a YANG data model for Network Inventory location (e.g., site, room, rack, geo-location data), which provides location information with different granularity levels for inventoried network elements. Accurate location information is useful for network planning, deployment, and maintenance. However, such information cannot be obtained or verified from the Network Elements themselves. This document defines a location model for network inventory that extends the base inventory with comprehensive location data. | |||||||||||||
| A YANG Network Data Model of Network Inventory Software Extensions | ||||||||||||||
|
This document extends the base Network Inventory YANG model to support non-physical network elements (NEs), such as controllers, virtual routers, and virtual firewalls, as well as software components like platform operating systems and software modules. In addition to the software revisions and patches already defined in the base model, this extension introduces software status and time stamp information. | |||||||||||||
| Use of Hybrid Public Key Encryption (HPKE) with JSON Web Encryption (JWE) | ||||||||||||||
|
This specification defines how to use Hybrid Public Key Encryption (HPKE) with JSON Web Encryption (JWE). HPKE enables public key encryption of arbitrary-sized plaintexts to a recipient's public key, and provides security against adaptive chosen ciphertext attacks. This specification chooses a specific subset of the HPKE features to use with JWE. This specification updates RFC 7516 (JWE) to enable use of Integrated Encryption as a Key Management Mode. | |||||||||||||
| Post-Quantum Key Encapsulation Mechanisms (PQ KEMs) for COSE | ||||||||||||||
|
This document describes conventions for using Post-Quantum Key Encapsulation Mechanisms (PQ-KEMs) with CBOR Object Signing and Encryption (COSE). | |||||||||||||
| JOSE HPKE PQ & PQ/T Algorithm Registrations | ||||||||||||||
|
This document registers Post-Quantum (PQ) and Post-Quantum/ Traditional (PQ/T) hybrid algorithm identifiers for use with JSON Object Signing and Encryption (JOSE), building on the Hybrid Public Key Encryption (HPKE) framework. | |||||||||||||
| Lightweight Authorization using Ephemeral Diffie-Hellman Over COSE (ELA) | ||||||||||||||
|
Ephemeral Diffie-Hellman Over COSE (EDHOC) is a lightweight authenticated key exchange protocol intended for use in constrained scenarios. This document specifies Lightweight Authorization using EDHOC (ELA). The procedure allows authorizing enrollment of new devices using the extension point defined in EDHOC. ELA is applicable to zero-touch onboarding of new devices to a constrained network leveraging trust anchors installed at manufacture time. | |||||||||||||
| Implementation Considerations for Ephemeral Diffie-Hellman Over COSE (EDHOC) | ||||||||||||||
|
This document provides considerations for guiding the implementation of the authenticated key exchange protocol Ephemeral Diffie-Hellman Over COSE (EDHOC). | |||||||||||||
| Coordinating the Use of Application Profiles for Ephemeral Diffie-Hellman Over COSE (EDHOC) | ||||||||||||||
|
The lightweight authenticated key exchange protocol Ephemeral Diffie- Hellman Over COSE (EDHOC) requires certain parameters to be agreed out-of-band, in order to ensure its successful completion. To this end, application profiles specify the intended use of EDHOC to allow for the relevant processing and verifications to be made. In order to ensure the applicability of such parameters and information beyond transport- or setup-specific scenarios, this document defines a canonical, CBOR-based representation that can be used to describe, distribute, and store EDHOC application profiles. Furthermore, in order to facilitate interoperability between EDHOC implementations and support EDHOC extensibility for additional integrations, this document defines a number of means to coordinate the use of EDHOC application profiles. Finally, this document defines a set of well- known EDHOC application profiles. | |||||||||||||
| Applying Generate Random Extensions And Sustain Extensibility (GREASE) to EDHOC Extensibility | ||||||||||||||
|
This document applies the extensibility mechanism GREASE (Generate Random Extensions And Sustain Extensibility), which was pioneered for TLS, to the ecosystem of Ephemeral Diffie-Hellman Over COSE (EDHOC). It reserves a set of External Authorization Data (EAD) labels and unusable cipher suites that may be included in messages to ensure peers correctly handle unknown values. | |||||||||||||
| Remote attestation over EDHOC | ||||||||||||||
|
This document specifies how to perform remote attestation as part of the lightweight authenticated Diffie-Hellman key exchange protocol EDHOC (Ephemeral Diffie-Hellman Over COSE), based on the Remote ATtestation procedureS (RATS) architecture. | |||||||||||||
| Quantum-Resistant Cipher Suites for LAKE | ||||||||||||||
|
The Lightweight Authenticated Key Exchange (LAKE) protocol, also known as Ephemeral Diffie-Hellman over COSE (EDHOC), achieves post- quantum security by adding new cipher suites with quantum-resistant algorithms, such as ML-DSA for digital signatures and ML-KEM for key exchange. This document specifies how the LAKE protocol operates in a post-quantum setting using both signature-based and PSK-based authentication methods, and defines corresponding cipher suites. | |||||||||||||
| KEM-based Authentication for EDHOC | ||||||||||||||
|
This document specifies extensions to the Ephemeral Diffie-Hellman Over COSE (EDHOC) protocol to provide resistance against quantum computer adversaries by incorporating Post-Quantum Cryptography (PQC) Key Encapsulation Mechanisms (KEMs) for both key exchange and authentication. It defines a new signature-free KEM-based authentication method in which both parties authenticate using KEMs, enabling quantum-resistant authentication without relying on digital signatures when PQC KEMs, such as the NIST-standardized ML-KEM, are used. | |||||||||||||
| QUIC-Aware Proxying Using HTTP | ||||||||||||||
|
This document extends UDP Proxying over HTTP to add optimizations for proxied QUIC connections. Specifically, it allows a proxy to reuse UDP 4-tuples for multiple proxied connections, and adds a mode of proxying in which QUIC short header packets can be forwarded and transformed through a HTTP/3 proxy rather than being fully re- encapsulated and re-encrypted. | |||||||||||||
| Extensions to Compress and Derive Fields in HTTP Datagrams | ||||||||||||||
|
This document defines extensions for HTTP Datagram-based protocols that improve transmission efficiency by introducing templates for compressing or deriving datagram fields. These templates allow endpoints to define parts of datagrams that are static and can be removed, and other parts that can be derived (such as packet lengths and checksum values). Additionally, this document defines a checksum offload procedure enabling receivers to complete Internet checksums using sender- provided partial values. These optimisations reduce per-packet overhead, processing cost, and increase the effective maximum transmission unit (MTU) when datagrams are encapsulated in QUIC DATAGRAM frames. | |||||||||||||
| An Architecture for More Instant Messaging Interoperability (MIMI) | ||||||||||||||
|
The More Instant Messaging Interoperability (MIMI) working group is defining a suite of protocols that allow messaging providers to interoperate with one another. This document lays out an overall architecture enumerating the MIMI protocols and how they work together to enable an overall messaging experience. | |||||||||||||
| Room Policy for the More Instant Messaging Interoperability (MIMI) Protocol | ||||||||||||||
|
This document describes a set of concrete room policies for the More Instant Messaging Interoperability (MIMI) Working Group. It describes several independent properties and policy attributes which can be combined to model a wide range of chat and multimedia conference types. | |||||||||||||
| The Messaging Layer Security (MLS) Extensions | ||||||||||||||
|
The Messaging Layer Security (MLS) protocol is an asynchronous group authenticated key exchange protocol. MLS provides a number of capabilities to applications, as well as several extension points internal to the protocol. This document provides a consolidated application API, guidance for how the protocol's extension points should be used, and a few concrete examples of both core protocol extensions and uses of the application API. | |||||||||||||
| MLS Virtual Clients | ||||||||||||||
|
This document describes a method that allows multiple MLS clients to emulate a virtual MLS client. A virtual client allows multiple emulator clients to jointly participate in an MLS group under a single leaf. Depending on the design of the application, virtual clients can help hide metadata and improve performance. | |||||||||||||
| Messaging Layer Security (MLS) Targeted Messages | ||||||||||||||
|
This document defines targeted messages for the Messaging Layer Security (MLS) protocol. A targeted message allows a member of an MLS group to send an encrypted and authenticated message to another member of the same group without creating a new group. The mechanism reuses Hybrid Public Key Encryption (HPKE) and the MLS key schedule to provide confidentiality, authentication, and binding to the group state. | |||||||||||||
| Ways to convey the Ratchet Tree in Messaging Layer Security | ||||||||||||||
|
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. | |||||||||||||
| Network Overlay Impacts to Streaming Video | ||||||||||||||
|
This document examines the operational impacts on streaming video applications resulting from network policy changes introduced by network overlays. Such overlays may alter IP address assignment, transport protocols, routing behavior, or DNS resolution. These changes can, in turn, affect critical aspects of content delivery, including latency, CDN cache selection, delivery path optimization, traffic classification, and content access controls. | |||||||||||||
| Privacy Pass Authentication for Media over QUIC (MoQ) | ||||||||||||||
|
This document specifies the use of Privacy Pass architecture and issuance protocols for authorization in Media over QUIC (MoQ) transport protocol. It defines how Privacy Pass tokens can be integrated with MoQ's authorization framework to provide privacy- preserving authentication for subscriptions, fetches, publications, and relay operations while supporting fine-grained access control through prefix-based track namespace and track name matching rules. | |||||||||||||
| End-to-End Secure Objects for Media over QUIC Transport | ||||||||||||||
|
This document specifies an end-to-end authenticated encryption scheme for application objects transmitted via Media over QUIC (MoQ) Transport. The scheme enables original publishers that share a symmetric key with end subscribers, to ensuring that MoQ relays are unable to decrypt object contents. Additionally, subscribers can verify the integrity and authenticity of received objects, confirming that the content has not been modified in transit. Additionally it allows MoQ parameters to be protected so the publisher can select if they are readable and/or modifiable by relays. | |||||||||||||
| List Pagination for YANG-driven Protocols | ||||||||||||||
|
In some circumstances, instances of YANG modeled "list" and "leaf- list" nodes may contain numerous entries. Retrieval of all the entries can lead to inefficiencies in the server, the client, and the network in between. This document defines a model for list pagination that can be implemented by YANG-driven management protocols such as NETCONF and RESTCONF. The model supports paging over optionally filtered and/or sorted entries. The solution additionally enables servers to constrain query expressions on some "config false" lists or leaf- lists. | |||||||||||||
| CBOR Encoding for HTTPS-based YANG Notifications Transport | ||||||||||||||
|
This document extends [I-D.draft-ietf-netconf-https-notif] by introducing CBOR encoding for YANG notifications over HTTPS transport in addition to the existing JSON and XML encoding schemes. | |||||||||||||
| Sub-interface VLAN YANG Data Models | ||||||||||||||
|
This document defines YANG modules to add support for classifying traffic received on interfaces as Ethernet/VLAN framed packets to sub-interfaces based on the fields available in the Ethernet/VLAN frame headers. These modules allow configuration of Layer 3 (L3) and Layer 2 (L2) sub-interfaces (e.g., L2VPN attachment circuits) that can interoperate with IETF based forwarding protocols, such as IP and L3VPN services, or L2VPN services like Virtual Private Wire Service (VPWS), Virtual Private LAN Service (VPLS), and EVPN. The sub- interfaces also interoperate with VLAN tagged traffic originating from an IEEE 802.1Q compliant bridge. The model differs from an IEEE 802.1Q bridge model in that the configuration is interface/sub-interface based as opposed to being based on membership of an 802.1Q VLAN bridge. The YANG data models in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342. | |||||||||||||
| YANG Packages | ||||||||||||||
|
This document defines YANG packages: versioned organizational structures used to manage the schema and conformance of a set of YANG modules as a cohesive unit. | |||||||||||||
| Guidance for Managing YANG Modules in RFCs and IANA Registries | ||||||||||||||
|
This document provides guidance to the RFC Editor and IANA on managing YANG modules in RFCs and IANA registries, ensuring consistent application of YANG Semantic Versioning rules. | |||||||||||||
| The YANG 2.0 Data Modeling Language | ||||||||||||||
|
YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 2.0 of the YANG language. YANG version 2.0 is a major release of the YANG language, addressing issues found in the original specification. | |||||||||||||
| A Framework for a Network Anomaly Detection Architecture | ||||||||||||||
|
This document describes the motivation and architecture of a Network Anomaly Detection Framework and the relationship to other documents describing network Symptom semantics and network incident lifecycle. The described architecture for detecting IP network service interruption is designed to be generic applicable and extensible. Different applications are described and examples are referenced with open-source running code. | |||||||||||||
| Semantic Metadata Annotation for Network Anomaly Detection | ||||||||||||||
|
The document proposes a unified symptoms vocabulary for network anomaly metadata to improve data sharing and analysis among human network operators, network analytics implementers, and AI systems to improve accuracy of Service Disruption Detection. | |||||||||||||
| Research Challenges in Coupling Artificial Intelligence and Network Management | ||||||||||||||
|
This document is intended to introduce the challenges to overcome when Network Management (NM) problems may require coupling with Artificial Intelligence (AI) solutions. On the one hand, many difficult NM problems still lack good solutions, or existing approaches come with significant limitations. Artificial Intelligence may help produce novel solutions to those problems. On the other hand, due to the high computational costs of AI solutions and stringent data privacy constraints, the distributed execution of AI workloads has become paramount. Consequently, networks must be operated efficiently to sustain these distributed processing requirements. To identify the right set of challenges, the document defines a method based on the evolution and nature of NM problems. This will be done in parallel with advances and the nature of existing solutions in AI in order to highlight where AI and NM have already been coupled together or could benefit from a closer integration. So, the method aims at evaluating the gap between NM problems and AI solutions. Challenges are derived accordingly, assuming that solving these challenges will help to reduce the gap between NM and AI. This document is a product of the Network Management Research Group (NMRG) of the Internet Research Task Force (IRTF). This document reflects the consensus of the research group. It is not a candidate for any level of Internet Standard and is published for informational purposes. | |||||||||||||
| Considerations of network/system for AI services | ||||||||||||||
|
As the development of AI technology has matured and AI technology has begun to be applied in various fields, the execution environment has evolved from dedicated high-performance servers to commodity servers and affordable, small-scale hardware, including microcontrollers, low-performance CPUs, and AI chipsets. This document outlines how to configure the network and system for an AI inference service, providing AI services in a distributed manner. It also outlines the factors to consider when a client connects to a cloud server and an edge device to request an AI service. It describes some use cases for deploying network-based AI services, such as self-driving vehicles and network digital twins. | |||||||||||||
| Semantic Definition Format (SDF) for Data and Interactions of Things: Compact Notation | ||||||||||||||
|
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; // it received positive initial feedback on the approach taken and is // awaiting completion of the initial implementation. | |||||||||||||
| Encrypted Client Hello Deployment Considerations | ||||||||||||||
|
This document discusses operational and policy considerations related to the deployment of TLS Encrypted Client Hello (ECH). It describes the impact of encrypting the TLS Server Name Indication (SNI) on operational practices such as threat detection, network security controls, and content filtering in private, edge, and public network environments, with a particular focus on education, enterprise, and public operator use cases. | |||||||||||||
| Multicast Extension for QUIC | ||||||||||||||
|
This document defines a multicast extension to QUIC to enable the efficient use of multicast-capable networks to send identical data streams to many clients at once, coordinated through individual unicast QUIC connections. | |||||||||||||
| Path Tracing in SR-MPLS networks | ||||||||||||||
|
Path Tracing provides a record of the packet path as a sequence of interface ids. In addition, it provides a record of end-to-end delay, per-hop delay, and load on each interface that forwards the packet. Path Tracing has the lowest MTU overhead compared to alternative proposals such as [INT], [RFC9197], [I-D.song-opsawg-ifit-framework], and [I-D.kumar-ippm-ifa]. Path Tracing supports fine grained timestamp. It has been designed for linerate hardware implementation in the base pipeline. This document defines the Path Tracing specification for the SR-MPLS dataplane. The Path Tracing specification for the SRv6 dataplane is defined in [I-D.filsfils-spring-path-tracing]. | |||||||||||||
| Data Collection Requirements and Technologies for Network Digital Twin | ||||||||||||||
|
A Network Digital Twin is a virtual representation of a real network, which is meant to be used by a management system to analyze, diagnose, emulate, and then control the real network based on data, models, and interfaces. The construction and state update of a Network Digital Twin requires obtaining real-time information of the physical network it represents (i.e., telemetry data). This document aims to describe the data collection requirements and provide data collection methods or tools to build the data repository for building and updating a network digital twin. | |||||||||||||
| More Instant Messaging Interoperability (MIMI) Identity Concepts | ||||||||||||||
|
This document explores the problem space in instant messaging (IM) identity interoperability when using end-to-end encryption, for example with the MLS (Message Layer Security) Protocol. It also describes naming schemes for different types of IM identifiers. | |||||||||||||
| EVPN Multicast Forwarding for EVPN to EVPN Gateways | ||||||||||||||
|
This document proposes an EVPN (Ethernet Virtual Private Network) extension to allow IP multicast forwarding on Service Gateways that interconnect two or more EVPN domains. | |||||||||||||
| Green Challenges in Computing-Aware Traffic Steering (CATS) | ||||||||||||||
|
As mobile edge computing networks sink computing tasks from cloud data centers to the edge of the network, tasks need to be processed by computing resources close to the user side. Therefore, CATS was raised. Reducing carbon footprint is a major challenge of our time. Networks are the main enablers of carbon reductions. The introduction of computing dimension in CATS makes it insufficient to consider the energy saving of network dimension in the past, so the green for CATS based on network and computing combination is worth exploring. This document outlines a series of challenges and associated research to explore ways to reduce carbon footprint and reduce network energy based on CATS. | |||||||||||||
| SRv6 Context Indicator SIDs for SR-Aware Services | ||||||||||||||
|
A context indicator provides the context on how to process the packet for service nodes. This document describes how to use SRv6 SIDs as context indicator for SR-aware services. The corresponding Endpoint behaviors are defined. | |||||||||||||
| Inter-domain Source Address Validation based on AS relationships | ||||||||||||||
|
This draft introduces a distributed inter-domain source address validation scheme based on AS relationships named AS Relationship Based Inter-domain Filtering (ARBIF). It primarily describes this method from seven aspects: a brief introduction to the scheme, an overview of the AS relationship classification and acquisition methods, the architecture of the ARBIF system, implementation based on BGP extension, typical use cases, experiments of ARBIF, and considerations for deployability. | |||||||||||||
| Proposed Update to BGP Link-State SPF NLRI Selection Rules | ||||||||||||||
|
For network scenarios such as Massively Scaled Data Centers (MSDCs), BGP is extended for Link-State (LS) distribution and the Shortest Path First (SPF) algorithm based calculation. BGP-LS-SPF leverages the mechanisms of both BGP protocol and BGP-LS protocol extensions, with new selection rules defined for BGP-LS-SPF NLRI. This document proposes some updates to the BGP-LS-SPF NLRI selection rules, so as to improve the route updates and convergence, while consistent SPF computation result can still be achieved. This document updates the NLRI selection rules in I-D.ietf-lsvr-bgp-spf. | |||||||||||||
| Opportunistic TCP-AO with TLS | ||||||||||||||
|
This document specifies an opportunistic mode for TCP-AO when used with TLS. In this mode, the TCP connection starts with a well-known authentication key which is later replaced by a secure key derived from the TLS handshake. | |||||||||||||
| BGP over TLS/TCP | ||||||||||||||
|
This document specifies the use of TLS over TCP to support BGP. The Border Gateway Protocol (BGP) relies on TCP to establish sessions between routers. While the TCP Authentication Option (TCP-AO) provides transport-layer integrity protection against spoofing and reset attacks, it does not provide confidentiality, cryptographic peer identity, or scalable key management. This document specifies a method for establishing a secure BGP session by running BGP over a TLS 1.3 session. The underlying TCP transport MUST be protected using TCP-AO. An "Implicit TLS" model on TCP port 179 is specified as the preferred mechanism. | |||||||||||||
| Application of Explicit Measurement Techniques for QUIC Troubleshooting | ||||||||||||||
|
This document defines a protocol that can be used by QUIC endpoints to signal packet loss in a way that can be used by network devices to measure and locate the source of the loss. Discussion of this work is encouraged to happen on the QUIC IETF mailing list [email protected] (mailto:[email protected]) or on the GitHub repository which contains the draft: https://github.com/igorlord/ draft-mdt-quic-explicit-measurements (https://github.com/igorlord/ draft-mdt-quic-explicit-measurements). | |||||||||||||
| Path Computation Based on Precision Availability Metrics | ||||||||||||||
|
This document extends PCEP to support Precision Availability Metrics (PAM) [RFC9544] for path computation. The optimization objectives for PAM computations are encoded using the Objective Function (OF) object defined in [RFC5541], allowing PCCs to specify precise optimization criteria for services with SLO requirements. And a PCE can report the statistical characterization associated with a computed path. | |||||||||||||
| Path Tracing in SRv6 networks | ||||||||||||||
|
Path Tracing provides a record of the packet path as a sequence of interface ids. In addition, it provides a record of end-to-end delay, per-hop delay, and load on each egress interface along the packet delivery path. Path Tracing allows to trace 14 hops with only a 40-bytes IPv6 Hop- by-Hop extension header. Path Tracing supports fine grained timestamp. It has been designed for linerate hardware implementation in the base pipeline. | |||||||||||||
| Definition for Aggregated BMP Route Monitoring Message | ||||||||||||||
|
This document proposes an aggregated BMP Route Monitoring message based on the BMP Multi-Peer Header message (draft-liu-grow-bmp- multiple-peer-header). It can compress multiple BMP Route Monitoring messages into one aggregated BMP Route Monitoring message to reduce the amount of reported BMP Route Monitoring messages and reduce the network overhead. | |||||||||||||
| IPv6 Extended Fragment Header (EFH) | ||||||||||||||
|
The Internet Protocol, version 4 (IPv4) header includes a 16-bit Identification field in all packets, but this length is too small to ensure reassembly integrity even at moderate data rates in modern networks. Even for Internet Protocol, version 6 (IPv6), the 32-bit Identification field included when a Fragment Header is present may be smaller than desired for some applications. Both IPv4 and IPv6 fragmentation have further been classified as fragile to the point that their use is discouraged. This specification addresses these limitations by defining an IPv6 Extended Fragment Header (EFH) that includes a 64-bit Identification in the context of more robust, secure and efficient fragmentation and reassembly procedures. | |||||||||||||
| IPv6 Extended Fragment Header for IPv4 | ||||||||||||||
|
The Internet Protocol, version 4 (IPv4) header includes a 16-bit Identification field in all packets, but this length is too small to ensure reassembly integrity even at moderate data rates in modern networks. Even for Internet Protocol, version 6 (IPv6), the 32-bit Identification field included when a Fragment Header is present may be smaller than desired for some applications. This specification addresses these limitations by adapting the IPv6 Extended Fragment Header for IPv4. | |||||||||||||
| BGP Flowspec for Computing-Aware Traffic Steering | ||||||||||||||
|
A BGP Flow Specification is an n-tuple consisting of several matching criteria that can be applied to IP traffic. Computing-Aware Traffic Steering (CATS) is a framework which optimizes traffic steering to a given service instance by taking into account the dynamic nature of both computing and network resources. This document specifies a new BGP Flow Spec Component Type in order to support CATS traffic forwarding. | |||||||||||||
| Compute-Aware Traffic Steering for Midhaul Networks | ||||||||||||||
|
Computing-Aware Traffic Steering (CATS) takes into account both computing and networking resource metrics for selecting the appropriate service instance to forwarding the service traffic. This document described the usage of Computing-Aware Traffic Steering (CATS) within Midhaul (MH) networks in the O-RAN architecture. It details how CATS can enhance traffic steering decisions between Distributed Units (DUs) and Centralized Units (CUs) by considering both compute resource metrics (e.g., CPU and memory utilization of CU instances) and network performance metrics (e.g., bandwidth, latency, reliability). The document discusses the integration of CATS with O-RAN management frameworks, and the interplay with the Transport Network Manager (TNM) in O-RAN using standard interfaces defined by IETF (as for example the one for Network Slice Services for connectivity provisioning). | |||||||||||||
| YANG Data Model for SR Policy Group | ||||||||||||||
|
This document defines YANG data models for Segment Routing (SR) Policy group that can be used for configuring, instantiating, and managing SR Policy groups. The model is generic and apply equally to the MPLS and SRv6 instantiations of SR policy groups. | |||||||||||||
| Attester Groups for Remote Attestation | ||||||||||||||
|
This document proposes an extension to the Remote Attestation Procedures architecture by introducing the concept of Attester Groups. This extension aims to reduce computational and communication overhead by enabling collective Evidence appraisal of high number of homogeneous devices with similar characteristics, thereby improving the scalability of attestation processes. | |||||||||||||
| A YANG Data Model for Resource Performance Monitoring | ||||||||||||||
|
This document defines a YANG data model for resource Performance Monitoring, applicable to network controllers, which provides the functionalities of retrieval of performance monitoring capabilities, TCA (Threshold Crossing Alert) configuration, current or history performance data retrieval, and performance monitoring task management. | |||||||||||||
| A YANG Data Model for Service Path Computation | ||||||||||||||
|
This document defines a YANG data model for client signal service's path computation and path management. | |||||||||||||
| Impacts of the Internet on the Environment,Beyond Carbon | ||||||||||||||
|
The global internet is comprised of vast interconnected networks spanning nearly every surface of planet and sky that, together with user devices, consumes energy and emits greenhouse gases. The true scale and proposed mitigations of the carbon footprint of the internet are the subject of important research. The internet also requires the depletion of other natural resources beyond carbon, namely land, water, electromagnetic spectrum and minerals. Electronic waste contributes in particularly acute ways to environmental pollution. This document surveys the impacts of the internet on the environment and includes, but goes beyond, energy use and carbon footprint to look at the consumption of natural resources and environmental waste. | |||||||||||||
| PCEP over QUIC | ||||||||||||||
|
This document specifies the use of QUIC streams to implement the PCEP protocol for efficient and secure data transmission. | |||||||||||||
| Problem Statement with Aggregate Header Limit for IPv6 | ||||||||||||||
|
This document first proposes the concept of "Aggregate header limit for IPv6"(IPv6-AHL) to indicate the total header size that a router is able to process at full forwarding rate for IPv6 packets. Then this document describes the problems for path calculation and function enablement without the awareness of IPv6-AHL, and the considerations for IPv6-AHL collection are also included. | |||||||||||||
| Autonomous System Relationship Authorization (ASRA) as an Extension to ASPA for Enhanced AS Path Verification | ||||||||||||||
|
An Autonomous System Provider Authorization (ASPA) record authorizes provider ASes of a customer AS. 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 Profile for Autonomous System Relationship Authorization (ASRA) | ||||||||||||||
|
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. | |||||||||||||
| A syntax for the RADIUS Connect-Info attribute used in Wi-Fi networks | ||||||||||||||
|
This document describes a syntax for the Connect-Info attribute used with the RADIUS protocol, enabling RADIUS clients to provide RADIUS servers information pertaining to a user's connection with an IEEE 802.11 wireless network. | |||||||||||||
| Advertising SAV Rule-related Information using BGP Link-State | ||||||||||||||
|
This document proposes extensions to the BGP Link-State protocol for advertising Source Address Validation (SAV) rule-related information for monitoring and management purposes. | |||||||||||||
| Path Energy Traffic Ratio API (PETRA) | ||||||||||||||
|
This document describes an API to query a network regarding its Energy Traffic Ratio for a given path. | |||||||||||||
| Composite Token Claims | ||||||||||||||
|
Composite claims are claims for CBOR Web Tokens (CWTs) and JSON Web Tokens (JWTs) that define logical relationships between sets of claims. This document also defines a CWT representation of the "crit" (Critical) claim. | |||||||||||||
| Source Buffer Management | ||||||||||||||
|
In the past decade there has been growing awareness about the harmful effects of bufferbloat in the network, and there has been good work on developments like L4S to address that problem. However, bufferbloat on the sender itself remains a significant additional problem, which has not received similar attention. This document offers techniques and guidance for host networking software to avoid network traffic suffering unnecessary delays caused by excessive buffering at the sender. These improvements are broadly applicable across all datagram and transport protocols (UDP, TCP, QUIC, etc.) on all operating systems. | |||||||||||||
| Ascon-AEAD128 and Ascon-Hash256 for COSE | ||||||||||||||
|
This document describes CBOR Object Signing and Encryption (COSE) serialization with Ascon, a NIST standard for lightweight cryptography. In 2019, as a part of CAESAR competition, Ascon-128 and Ascon-128a were selected as the first choice for the lightweight authenticated encryption. After, in 2023, National Institute of Standards and Technology (NIST) selected Ascon family of cryptographic algorithms to be the standard for lightweight cryptography. In August 2025, NIST Special Publication 800-232 was released, defining Ascon-based lightweight cryptography standards for constrained devices. This recognition makes it particularly interesting to enable using Ascon with COSE structures. | |||||||||||||
| Verifiable STI Presentation and Evidence for RTU (VESPER) Use Cases and Requirements | ||||||||||||||
|
This document describes use cases and requirements that motivate VESPER (Verifiable STI Presentation and Evidence for RTU), work within the Secure Telephone Identity Revisited (STIR) framework. STIR establishes that a signing credential is authorized for a telephone number, but not what entity holds that authority, what verifiable information that entity declares about its numbers, or how a relying party obtains and verifies this across the channels where a number appears. This document presents a set of use cases that illustrate the resulting trust gaps and states the requirements a solution should satisfy. It motivates the mechanisms defined in the VESPER framework and its companion specifications rather than defining them. | |||||||||||||
| Multipath Traffic Engineering | ||||||||||||||
|
Shortest path routing offers an easy-to-understand, easy-to-implement method of establishing loop-free connectivity in a network, but offers few other features. Equal-cost multipath (ECMP), a simple extension, uses multiple equal-cost paths between any two points in a network: at any node in a path (really, Directed Acyclic Graph), traffic can be (typically equally) load-balanced among the next hops. ECMP is easy to add on to shortest path routing, and offers a few more features, such as resiliency and load distribution, but the feature set is still quite limited. Traffic Engineering (TE), on the other hand, offers a very rich toolkit for managing traffic flows and the paths they take in a network. A TE network can have link attributes such as bandwidth, colors, risk groups and alternate metrics. A TE path can use these attributes to include or avoid certain links, increase path diversity, manage bandwidth reservations, improve service experience, and offer protection paths. However, TE typically doesn't offer multipathing as the tunnels used to implement TE usually take a single path. This memo proposes multipath traffic-engineering (MPTE), combining the best of ECMP and TE. The multipathing proposed here need not be strictly equal-cost, allowing for some "slack" to admit more paths. The load balancing at each hop is optimally weighted to each next hop rather than always being equally weighted. Moreover, traffic can enter and leave an MPTE construct via multiple ingresses and egresses. The proposal includes several choices of control and data planes. | |||||||||||||
| IGMP / MLD Extension for Signaling Eco-Mode | ||||||||||||||
|
This document specifies an extension to IGMPv3 and MLDv2 messages to indicate eco-mode preferences in the delivery of multicast content based on the mechanism described in [RFC9279]. The extension enables receivers and network elements to signal energy-aware multicast delivery preferences, including different eco-mode levels, so that multicast services can be operated consistently with energy-efficient network management, service-level optimisation, and telemetry-driven assessment of energy and carbon impact. | |||||||||||||
| Hybrid Post-Quantum Password Authenticated Key Exchange | ||||||||||||||
|
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 composed of two stages — CPace and OQUAKE+ — that run sequentially, with the output of CPace feeding as the secret_context into OQUAKE+. OQUAKE+ is an augmented variant of OQUAKE that adds password confirmation. This document also describes standalone OQUAKE+, a post-quantum aPAKE, and CPaceOQUAKE, the hybrid symmetric PAKE composed of the CPace and OQUAKE stages. This document recommends configurations for CPaceOQUAKE+. | |||||||||||||
| Composite ML-DSA Signatures for SSH | ||||||||||||||
|
This document describes the use of PQ/T composite signatures for the Secure Shell (SSH) protocol. The composite signatures described combine ML-DSA as the post-quantum part and the elliptic curve signature schemes ECDSA, Ed25519 and Ed448 as the traditional part. | |||||||||||||
| Fragmentation Revisited: For What It's Worth | ||||||||||||||
|
Internet Protocol (IP) fragmentation and reassembly have served as core elements of the architecture from the very earliest days but they have been subject to negative publicity by studies that have declared them "harmful" and "fragile". These warning labels have resonated deeply within the community in a way that fosters the enemies of sound engineering: fear, uncertainty and doubt. This document revisits IP fragmentation and shows that a properly engineered alternative IPv6 solution is both practical and necessary to provide a robust service for the future of Internetworking. | |||||||||||||
| ICMP Error Handling in SRv6 based VPN Networks | ||||||||||||||
|
The document specifies procedures for handling ICMP error in SRv6-based Virtual Private Network (VPN). | |||||||||||||
| A Framework to Evaluate LLM Agents for Network Configuration | ||||||||||||||
|
This document specifies an evaluation framework and related definitions for intent-driven network configuration using Large Language Model(LLM)-based agents. The framework combines an emulator-based interactive environment, a suite of representative tasks, and multi-dimensional metrics organized in two layers: outcome metrics that verify functional correctness in a method-agnostic way, and agentic process metrics that assess reasoning quality and interactive command generation. Functional testcase results serve as the primary metric; command and reasoning scores act as diagnostic estimates against the task's ground truth configurations (which may include more than one validated solution), and optional efficiency metrics capture time and token cost. The framework aims to enable reproducible, comprehensive, and fair comparisons among network configuration approaches, covering both agentic and non-agentic solutions while highlighting capabilities specific to autonomous agents. | |||||||||||||
| Binding Label/Segment Identifier (SID) Extensions in Path Computation Element Communication Protocol (PCEP) | ||||||||||||||
|
The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to instantiate and manage Label Switched Paths (LSPs) on a Path Computation Client (PCC). This includes the ability for a PCE to specify a Binding Segment Identifier (SID) for an LSP. A binding value specified by a PCE may not be available for use on the PCC. This can lead to LSP instantiation failures or entire PCEP message being rejected. This document proposes extensions to PCEP to allow a PCC to fall back to allocating a Binding SID from its own dynamic range if the value specified by the PCE is unavailable. It also defines a mechanism for the PCC to report both the requested and the allocated binding values back to the PCE. | |||||||||||||
| Applicability of Service & Infrastructure Maps (SIMAP) to Transport Networks | ||||||||||||||
|
This document explores the applicability of the Service & Infrastructure Maps (SIMAP) concepts to transport networks and it examines the YANG data models defined by the IETF to support the requirements and use cases for SIMAP applicability to transport networks. | |||||||||||||
| Stand-in Key Identifier and Encrypted Partial IV in the Constrained Application Protocol (CoAP) OSCORE Option | ||||||||||||||
|
The security protocol Object Security for Constrained RESTful Environments (OSCORE) provides end-to-end protection of messages exchanged with the Constrained Application Protocol (CoAP). Messages protected with OSCORE include a CoAP OSCORE Option, where the "Partial IV" field specifies the sequence number value used by the message sender and the "kid" field specifies the identifier of the message sender. In order to reduce the information exposed on the wire that can be used for fingerprinting traffic and for tracking endpoints, this document defines a lightweight add-on method that obfuscates certain fields of the OSCORE Option, by encrypting the "Partial IV" field and overwriting the "kid" field with a stand-in identifier. Therefore, it updates RFC 8613. With minor adaptations, the defined method is applicable also to the security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE) that protects group communication for CoAP. | |||||||||||||
| Distribution of Software Updates with End-to-End Secure Group Communication and Block-Wise Transfer for CoAP | ||||||||||||||
|
This document defines a method for efficiently distributing a software update to multiple target devices, by using end-to-end secure group communication over UDP and IP multicast. To this end, the defined method relies on a number of building blocks developed in the Constrained RESTful Environments (CoRE) Working Group of the IETF. Those especially include the Constrained Application Protocol (CoAP), Block-wise transfers for CoAP, and the end-to-end security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE). The method defined in this document is compatible with (but not dependent on) the architecture for software and firmware update developed in the Software Updates for Internet of Things (SUIT) Working Group of the IETF. | |||||||||||||
| Knowledge Graph for Network Traffic Monitoring and Analysis | ||||||||||||||
|
This document extends the knowledge graph framework specifically to the traffic management domain, demonstrating how knowledge graphs can address long-standing traffic management challenges through semantic integration and automated reasoning. | |||||||||||||
| Proposed Document Template for TLS FATT Process | ||||||||||||||
|
This document applies only to non-trivial extensions of TLS, which require formal analysis. FATT process has successfully discovered CVEs of *CVSS 7.5* and most recently expected *CVSS 9.1* in the *production* implementations of the drafts proposed for adoption in the TLS WG. To achieve high cryptographic assurances, this document proposes the drafts specify a clear threat model and informal security goals in the Security Considerations section, as well as motivation and a protocol diagram in the draft. | |||||||||||||
| A YANG Data Model for Reporting Utilization Scores in ISAC | ||||||||||||||
|
This document defines a YANG data model to report an ISAC Utilization Score (US) in Integrated Sensing and Communication (ISAC) systems. The US is an abstract, normalized score (0..100) that summarizes the relative resource cost of executing a sensing operation on a device. The model supports a mandatory overall US and optional explanatory component impact scores (compute, memory, energy, storage, latency). The model also supports optional metadata (e.g., timestamp, aggregation window, and scoring method identification) describing how a reported score was derived. This revision aligns terminology and leaf names to reduce ambiguity between normalized impact scores and raw resource telemetry, removes per-measurement-related objects to keep the model focused on an overall score, and specifies a companion augmentation module (Path 1) that attaches ISAC utilization telemetry to a GREEN Energy Object (as defined by the GREEN Power and Energy YANG Module) for correlation with power/energy telemetry. | |||||||||||||
| Multipath Traffic Engineering Capabilities | ||||||||||||||
|
Multipath Traffic Engineering (MPTE) combines two approaches to traffic management: equal-cost multipath and constraint-based traffic engineering, offering a powerful new way to engineer networks. To avail of this, a node (possibly an ingress of a MPTE tunnel, or a path computation agent) must have information about the topology, link and node characteristics of a network so that it can compute the components of the MPTE tunnel. One important (node) characteristic is whether a given node supports MPTE, i.e., whether it can participate in the provisioning and maintenance of an MPTE tunnel. Multicast TE (MCTE) offers a more efficient approach to traffic engineering for multicast traffic. Again, an important node characteristic is whether a given node supports MCTE, i.e., whether it can participate in the provisioning and maintenance of an MCTE tunnel. This memo shows how these capabilities can be distributed in the IGP via Link State Routing TE Capabilities. | |||||||||||||
| RSVP-TE Extensions for Multipath Traffic Engineered Directed Acyclic Graph Tunnels | ||||||||||||||
|
A Multipath Traffic Engineered Directed Acyclic Graph (MPTED) tunnel is a Traffic Engineering (TE) construct that facilitates weighted load balancing of unicast traffic across a constrained set of paths optimized for a specific objective. This document describes the provisioning of an MPTED Tunnel in a TE network using RSVP-TE. | |||||||||||||
| A YANG Data Model for Multipath Traffic Engineering Directed Acyclic Graph (MPTED) Tunnels and Junctions | ||||||||||||||
|
This document defines a YANG data model for representing, retrieving, and manipulating Multipath Traffic Engineering Directed Acyclic Graph (MPTED) Tunnels and Junctions. The model includes two YANG modules, one for managing MPTED Tunnels on an MPTED tunnel originator node and the other for managing MPTED Junctions on an MPTED junction node. | |||||||||||||
| Populating resolvers with the root zone | ||||||||||||||
|
DNS recursive resolver operators need to provide the best service possible for their users, which includes providing an operationally robust and privacy protecting service. Challenges to these deployment goals include difficulty of getting responses from the root servers (such as during a network attack), longer-than-desired round-trip times to the closest DNS root server, and privacy issues relating to queries sent to the DNS root servers. Resolvers can solve all of these issues by simply serving an already cached a copy of the full root zone. This document shows how resolvers can fetch, cache and maintain a copy of the root zone, how to detect if the contents becomes stale, and procedures for handling error conditions. { Editor note: This document contains a FAQ section. It will help answer questions about why this document is not a BCP but still has BCP in the name, how and why this document differs from RFC8806, etc etc etc. The FAQ section is intended to be removed before publication. } | |||||||||||||
| VESPER Out-of-Band OOB | ||||||||||||||
|
This document describes a mechanism for delivering authenticated telephone call identity information using the VESPER framework for use where in-band signaling does not carry the identity end to end, or where there is no in-band path between the parties at all. By supporting an out-of-band (OOB) transport model, this approach enables entities to publish and retrieve signed PASSporT assertions independent of end-to-end delivery within an in-band signaling path such as a SIP-based VoIP network. These PASSporTs are signed with VESPER delegate certificates, which identify the entity holding the right-to-use for a telephone number and bind it to that entity's domain identity. This document also introduces support for Connected Identity to the STIR OOB model, enabling the called party to respond with a signed PASSporT asserting its identity, thereby binding the identities of both parties to the transaction and enhancing end-to- end accountability. The OOB mechanism provides a delivery path for PASSporTs where in-band delivery within a signaling path such as SIP is unavailable or is not the path used, enabling verifiers to confirm the association between the originating telephone number and the identity asserting authority as part of the broader VESPER trust framework. | |||||||||||||
| An Update of Service and Network YANG Data Models | ||||||||||||||
|
Service & Network data models have been implemented in recent years to facilitate the deployment of connectivity services such as Layer 2 and Layer 3 VPN services in provider networks. This document reports the findings from the implementations, including missing functionalities, configuration blocks aligment against recent network models published, operational issues/limitatations and enhancements. | |||||||||||||
| AI Agent Discovery and Invocation Protocol | ||||||||||||||
|
This document proposes a standardized protocol for discovery and invocation of AI agents. It defines a common metadata format for describing AI agents (including capabilities, I/O specifications, supported languages, tags, authentication methods, etc.), a capability-based discovery mechanism, and a unified RESTful invocation interface. This revision refines the discovery mechanism by defining fields for intent-based agent selection. This capability enables a client, host agent, or orchestration system to describe a task intent and receive a ranked set of candidate agents before invocation, without changing existing discovery or invocation semantics. The goal is to enable cross-platform interoperability among AI agents by providing a discover-and-match mechanism and a unified invocation entry point. Security considerations, including authentication and trust measures, are also discussed. This specification aims to facilitate the formation of multi-agent systems by making it easy to find the right agent for a task and invoke it in a consistent manner across different vendors and platforms. Intent-based selection is an application-layer capability and does not define network routing, packet forwarding, path computation, reachability advertisement, or address resolution. | |||||||||||||
| HTTP/1.1 Request Smuggling Defense using Cryptographic Message Binding | ||||||||||||||
|
HTTP/1.1 Message Binding adds new hop-by-hop header fields that are cryptographically bound to requests and responses. The use of this protocol is negotiated out-of-band from the HTTP datastream, and keys can be communicated either in-band in the first request or out-of- band (such as via TLS Exporters). These header fields allow endpoints to detect and mitigate desynchronization attacks, such as HTTP Request Smuggling, that exist due to datastream handling differences. | |||||||||||||
| Service Affinity Solution based on Transport Layer Security (TLS) | ||||||||||||||
|
This draft proposes a service affinity solution between client and server based on Transport Layer Security (TLS). It defines a minimal extension to TLS 1.3 by which a server instance can authorize a client to resume an established session on a different instance of the same service (for example, another node of a load-balanced cluster) and request, in band, that the client do so. The relocation authorization is carried inside the server's own session ticket, so it inherits the security properties of TLS 1.3 ticket-based resumption. The relocation target is an opaque value that either directly carries the switchover address (for example, an IP address and port) or is an identifier resolved by the application or control plane. This document also introduces a Reliable Framing Layer that operates above the TLS record layer to provide message framing, sequence numbering, acknowledgment tracking, and automatic retransmission. The Framing Layer ensures zero application data loss during TLS session migration by buffering unacknowledged data frames and retransmitting them to the new server endpoint after migration completes. | |||||||||||||
| CBOR Pointer: Selecting Elements of Concise Binary Object Representation (CBOR) Documents | ||||||||||||||
|
CBOR Pointer is a syntax to identify a single CBOR value from a CBOR document with an arbitrarily complex nested structure. It is analogous to JSON Pointer. | |||||||||||||
| BGP best path next-hop selection enhancements | ||||||||||||||
|
BGP [RFC4271] has originally been designed to carry IPv4 routing information over the Internet. IP routing being "hop-by-hop" in nature, NEXT_HOP which purpose is to carry the address of the next router to send the IP packet to. In BGP, the next-hop may not be a directly connected router, hence, when evaluating paths, a BGP speaker must determine if the next-hop is resolvable and, if so, determine the internal cost to reach it. The incremental use of tunneling technologies to carry traffic between routers (e.g.: GRE, MPLS, SR-MPLS, SRv6...) may violate the assumption that the address carried in the NEXT_HOP is representative of the actual forwarding next-hop. These technologies decouple the BGP control-plane's view of the next-hop from the data-plane's actual forwarding endpoint. This document describes the problems that arise from this decoupling. These problems include sub-optimal path selection, incorrect resolvability tracking of the forwarding path leading to traffic drop or misrouting, and others. This document specifies how BGP obtains resolvability, preference, metric, and tracking information from resolution of the forwarding path and uses those values as inputs to BGP path selection. | |||||||||||||
| Agent Directory Service | ||||||||||||||
|
The Agent Directory Service (ADS) is a distributed directory service designed to store metadata for AI agent applications. This metadata, stored as directory records, enables the discovery of agent applications with specific skills for solving various problems. The implementation features distributed directories that interconnect through a content-routing protocol. | |||||||||||||
| Network Delivery Time Control | ||||||||||||||
|
This document describes Network Delivery Time Control (NDTC), a rate adaptation algorithm for real-time video streaming suited for interactive applications like cloud gaming. NDTC leverages the Frame Dithering Available Capacity Estimation (FDACE) heuristic, which estimates available path capacity without inducing congestion. The algorithm dynamically adjusts frame sizes and transmission times to ensure timely delivery, while also responding to conventional congestion signals. | |||||||||||||
| Integration of Network Management Agent (NMA) into ACTN-Based Optical Network | ||||||||||||||
|
With the growth of optical network scale, the complexity of network operation and maintenance has increased dramatically. Enhancing the intelligence level of optical network operation and management and building high-level autonomous optical networks have become the common vision of global operators. The development of AI, especially large AI model technologies, provides a feasible technical path for realizing autonomous perception, decision-making, analysis, and execution. The existing ACTN architecture provides network abstraction and control functions for optical networks but lacks higher-level autonomous capabilities. This document explores the introduction of AI based Network Management Agent(NMA) functions into ACTN-based optical networks to achieve high-level autonomy of optical networks. It discusses the ACTN-enhanced architecture of optical networks after the introduction of NMAs, including key components, interaction relationships, new interface requirements in the enhanced architecture, as well as typical use cases of agent-based autonomous operation and maintenance for optical networks. The document aims to improve the autonomy level of optical networks and promote the realization of autonomous optical networks by extending the original ACTN architecture. | |||||||||||||
| Distributed Inference Network (DIN) Problem Statement,Use Cases,and Requirements | ||||||||||||||
|
This document describes the problem statement, use cases, and requirements for a "Distributed Inference Network" (DIN) in the era of pervasive AI. As AI inference services become widely deployed and accessed by billions of users, applications and devices, traditional centralized cloud-based inference architectures face challenges in scalability, latency, security, and efficiency. DIN aims to address these challenges by leveraging distributed edge-cloud collaboration, intelligent scheduling, and enhanced network security to support low- latency, high-concurrency, and secure AI inference services. | |||||||||||||
| Definition for BMP Multiple Peer Header | ||||||||||||||
|
This document proposes a format of multiple peer header for aggregating BMP messages. It can be used to compress multiple BMP messages with per-peer header into one aggregated BMP message, which could reduce the amount of reported BMP messages and reduce network overhead. | |||||||||||||
| A code to describe satellite constellations | ||||||||||||||
|
When considering a satellite constellation forming a non-terrestrial network, the characteristics of this constellation heavily influence the network topology it forms. To improve the analysis of such non- terrestrial networks across various tools developed by the network community, this document defines a constellation code to describe common orbital shell patterns, and specification formats to describe inter-satellite link topologies and ground stations, covering the Core and Ground Networks of a constellation. In addition, this document may serve as an introduction to satellite constellations for IETF participants. | |||||||||||||
| Reliability Considerations for Delay-Tolerant Networks | ||||||||||||||
|
The Delay-Tolerant Networking (DTN) architecture describes a type of challenged network in which communications may be significantly affected by long signal propagation delays, frequent link disruptions, or both. These unique and challenging characteristics require adapted approaches for data transport, security, management, routing, and other networking functions. Using new approaches, DTNs can offer data services in environments that would be considered neither reliable nor resilient as these concepts are understood for unchallenged networks. This document identifies adapted definitions and concepts for DTN reliability and resiliency that can be applied even when there is no simultaneous, reliable, end-to-end path between sources and destinations in the network. These definitions and concepts are suitable for any challenged environment but, in particular, those communicating using the DTN Bundle Protocol (BP). The ability to overlay BP across multiple discontinuous underlay networks, to store- and-forward data where and as necessary, and the structure and security of the BPv7 bundle itself provide novel ways to identify, implement, signal, and otherwise consider guarantees associated with data exchange in the DTN environment. | |||||||||||||
| Authenticated ECH Config Distribution and Rotation | ||||||||||||||
|
Encrypted ClientHello (ECH) requires clients to have the server's ECH configuration before connecting. Currently, when ECH fails, servers can send updated configurations but clients cannot authenticate them unless the server has a valid certificate for the public name, limiting deployment flexibility. This document specifies a new mechanism for authenticating ECH configurations. Servers include additional information in their initial ECH configurations, which enables clients to authenticate updated configurations without relying on a valid certificate for the public name. | |||||||||||||
| Metric Normalize for IGP Flex-algo | ||||||||||||||
|
When multiple links in a network have the same metric, they can serve as ECMP equivalent links for load balancing during forwarding. However, slight fluctuations in metric values can prevent the formation of ECMP equivalent links, leading to the idle state of suboptimal links and thus wasting bandwidth resources. This document proposes a metric normalization method by advertising metric normalization parameters corresponding to a specific Metric- Type for Flexible Algorithm. During route calculation, slight fluctuations across multiple links are adjusted according to these normalization parameters, making the computed metric values more consistent. This approach enables the formation of ECMP equivalent links and promotes load sharing in the forwarding process. | |||||||||||||
| Advertisement of Algorithm in BGP | ||||||||||||||
|
This document proposes extensions to BGP to support algorithm-based end-to-end path establishment. | |||||||||||||
| Enhancement for Monitoring VRF's Loc-RIB | ||||||||||||||
|
BMP Loc-RIB [RFC9069] enforces that the BMP router sets the Peer Address value of a VPN route information to zero, and sets the Peer Distinguisher value of a VPN route information to the route distinguisher or unique locally defined value of the particular instance the Loc-RIB belongs to. This document introduces the option to communicate the Remote VRF Information from which a VPN route was received when reporting that VPN route information with BMP Loc-RIB. | |||||||||||||
| Updates to Locally Served DNS Zones and IP Special-Purpose Address Space Registries | ||||||||||||||
|
RFC 6063, "Locally Served DNS Zones", defines two IANA registries called "IPv4 Locally-Served DNS Zone" and "IPv6 Locally-Served DNS Zone" registries. This document changes the registration policy for that registry from "IETF Review" to "Expert Review". Also, this document updates IP Special-Purpose Address Space registries to indicate whether an IP address block is eligible to be in Locally-Served DNS Zones. Eligible entries will be automatically added to the Locally-Served DNS Zones. This document updates RFC 6063 and RFC 6890. | |||||||||||||
| HTTP Bearer Auth Method Extensions | ||||||||||||||
|
This document specifies an improved HTTP 401 and 407 flow for Bearer authentication where user-agents (or client applications) can automatically fetch requested tokens from a Security Token Service (STS). A fallback to an OpenID Connect (OIDC) redirect flow is included. This improved 401/407 Bearer flow, when used, elides the need for Proof Key for Code Exchange (PKCE) and does not impose on application Universal Resource Identifier (URI) query parameter design. As well this extension allows for user-agent caching of tokens. | |||||||||||||
| PCEP Extensions for Computing-Aware Traffic Steering (CATS) Service | ||||||||||||||
|
The CATS (Computing-Aware Traffic Steering) can steer traffic between clients of a service and sites offering the service. The C-PS may be deployed as a PCE and the ingress CATS-Router could be viewed as a PCC. This document proposes the PCEP extensions for selecting and distributing the paths for CATS services. | |||||||||||||
| Export of Energy Consumption Information in IPFIX | ||||||||||||||
|
This document introduces new IPFIX IEs for exporting energy consumption information of physical entities in a network device. New Information Elements are defined to report instantaneous and average energy consumption information at device, line-card, and port granularity. | |||||||||||||
| Export of MPLS Network Action (MNA) Information in IPFIX | ||||||||||||||
|
This document introduces new IPFIX IEs for exporting MPLS Network Action (MNA) information in IPFIX, covering both in-stack and post- stack MNAs. | |||||||||||||
| Pre-,Intra- and Post-handshake Attestation | ||||||||||||||
|
This document presents a taxonomy of extending TLS protocol with remote attestation, referred to as attested TLS. It also presents high-level analysis of benefits and limitations of each category, namely pre-handshake attestation, intra-handshake attestation and post-handshake attestation. It also captures the opinions of the WG participants in order to build consensus towards solutions. It also discussed tradeoffs and scalability. | |||||||||||||
| Autocrypt v2 OpenPGP Certificates and Transferable Secret Keys | ||||||||||||||
|
This document describes the "Autocrypt v2 Certificate", a standard structure for an OpenPGP certificate for Internet messaging. It offers defense against store-now-decrypt-later attacks from quantum computers through post-quantum hybrid cryptography. It also enables reliable deletion ("Forward Secrecy") of received messages even when adversaries capture encrypted messages in transit and later compromise the user's message archive and secret keys. The design uses deterministically ratcheted rotating encryption subkeys with predictable expiration combined with coordinated secret key material destruction. This document also describes the structure, use, and maintenance of the OpenPGP Transferable Secret Key that corresponds with the Autocrypt v2 Certificate. | |||||||||||||
| Interactive DPoP | ||||||||||||||
|
This document describes IDPoP, an extension to DPoP [RFC9449] that uses a key derivation scheme to separate access control from identity. It mitigates credential exfiltration risks by requiring fresh hardware attestation to unseal identity keys via an interactive challenge. | |||||||||||||
| Internet X.509 Public Key Infrastructure - Algorithm Identifiers for FrodoKEM | ||||||||||||||
|
FrodoKEM is an unstructured lattice-based Key Encapsulation Mechanism (KEM). Compared to ML-KEM, FrodoKEM is considered as having more conservative design. This document specifies the conventions for using FrodoKEM in X.509 Public Key Infrastructure. The conventions for the subject public keys and private keys are also specified. | |||||||||||||
| BGP SR Policy Extensions for BFD Configuration | ||||||||||||||
|
Segment Routing (SR) Policies require fast failure detection for Candidate Paths (CPs) to enable rapid rerouting and high availability. Currently, the provisioning of SR Policies and the configuration of associated Bidirectional Forwarding Detection (BFD) or Seamless BFD (S-BFD) sessions are performed independently. This often necessitates separate mechanisms (e.g., manual configuration, NETCONF, or additional signaling) to associate BFD/S-BFD sessions with the SR Policies, resulting in complex and error-prone operations. This document defines extensions to BGP SR Policy for the simultaneous provisioning of SR Policy CPs and their S-BFD configuration parameters during policy advertisement. The extensions include optional sub-TLVs within the Tunnel Encapsulation Attribute to carry S-BFD configuration parameters (e.g., discriminators, intervals, multipliers). These extensions simplify deployment in distributed or controller- based environments, reduce configuration overhead, and enhance operational efficiency for SR-based traffic engineering. | |||||||||||||
| The MLS-TLS secure channel protocol | ||||||||||||||
|
This document details how the Messaging Layer Security (MLS) protocol can be combined with the Transport Layer Security (TLS) record layer to yield the MLS-TLS secure channel protocol. In this composed protocol, MLS acts as a continuous key agreement protocol that allows initiator and responder to protect both past and future messages in case of key material compromise. As such, MLS-TLS is suitable for long-lived connections. MLS-TLS also inherits the modularity of MLS and can be configured with post-quantum secure ciphersuites. | |||||||||||||
| Native IPv4 multicast in IPv6 Core using PIM | ||||||||||||||
|
This document describes how PIM Sparse-Mode can be used to construct IPv4 multicast trees across an IPv6-only network core. This allows forwarding of native IPv4 multicast data packets. The document specifies how to send and receive IPv4 PIM messages with IPv6 headers, using a new well-known link-local IPv6 multicast address, and the use of RPF vectors for reachability. | |||||||||||||
| Extension for BMP Peer Interface | ||||||||||||||
|
This document proposes extending BMP to allow BMP messages with the per-peer header to carry interface information for the established peer session, especially in order to distinguish parallel link-local and unnumbered BGP peers established based on distinct interfaces. | |||||||||||||
| BGP Flow Specification by ClassID | ||||||||||||||
|
BGP Flowspec mechanism (BGP-FS) [RFC8955] [RFC8956] propagates both traffic Flow Specifications and Traffic Filtering Actions by making use of the BGP NLRI and the BGP Extended Community encoding formats. This document specifies a new BGP-FS component type named ClassID to support ClassID filtering. | |||||||||||||
| Routing Considerations in Agentic Network | ||||||||||||||
|
As the development of the AI technology, an AI Agent would be able to do some tasks as an assistant to human beings. During the task process, the Agent may need to connect to other Agents with different skills relative to the task. The Agent to Agent communication is a new kind of traffic for Internet, and some new requirements for networking are proposed. This document describes some routing considerations in the agentic network, especially for the cross- domain scenarios, in which the agentic network works as an overlay network above the IP network. | |||||||||||||
| Hybrid Energy Saving Mechanism for Transport Network | ||||||||||||||
|
This document continues the transport network energy saving that harmonizes device-level autonomy with network-wide coordination. By implementing control at hybrid both the device and network controller coordination, it enables dynamic, SLA-aware, and multi-layer energy optimization. | |||||||||||||
| Agentic Network Architecture and Protocol for Supporting Agent Interconnection Communication and Multi-level Inference | ||||||||||||||
|
With the advent of the era of AI large models and intelligent agents, more and more scenarios about agent interconnection have emerged, such as collaboration among multiple agents within a household, intelligent robots cooperating to complete pipeline tasks in different operations of the industrial Internet, drone groups, intelligent vehicle networking, etc. These scenarios not only require low latency and high bandwidth, but also demand efficient information exchange and cross-domain coordination and scheduling capabilities in complex collaborative tasks. Therefore, new orchestration and management technologies and frameworks are needed in existing networks to address this. The interconnection of different agents also brings about an emergence of inference, with a large number of inference requests being processed from the mobile phone side to the cloud. In order to improve inference efficiency, in a cloud-edge-end multi-layer inference architecture, large models and agents at different levels cooperate to complete tasks, resulting in a complex intelligent agent interconnection network. Gateways and routers serve as forwarding entries on the network road highways, responsible for building communication channels for the agents spread throughout the network, which requiring function upgrades to support the continuously evolving inference service in the future. | |||||||||||||
| PAVA: BGP AS_PATH Validation by Querying ASes about Their Relationships | ||||||||||||||
|
This document defines PAth VAlidation (PAVA), a scheme for validating the Border Gateway Protocol (BGP) AS_PATH field based on the AS relationships. Validation involves sending queries to the ASes along the path and each query specifies information about the prefix and the relevant path segment. In this draft, for the decentralized distribution system that ASes on a path need for distributing the information, we propose to use the Domain Name System (DNS) and DNSSEC. | |||||||||||||
| Consideration for Space-Based Computing Infrastructure Network | ||||||||||||||
|
This document presents considerations for a Space-Based Computing Infrastructure Network from use cases and requirements. | |||||||||||||
| Applicability of RFC8795 YANG data model to SIMAP | ||||||||||||||
|
This document analyses the applicability of the RFC 8795 YANG data model to Service & Infrastructure Maps (SIMAP) and in particular analysis which requirements can be supported by the existing YANG data model defined in RFC 8795. | |||||||||||||
| Denial-of-Service Considerations for Media over QUIC Relay Deployments | ||||||||||||||
|
The Media over QUIC Transport (MoQT) protocol presents denial-of- service risks that differ in character from those facing typical request-response protocols. MoQT relays forward, fan out, and optionally cache media content on behalf of publishers and subscribers. This document complements the MoQT Security Considerations, focusing on the unique considerations for relays. | |||||||||||||
| Error List and Error Identities Registries for YANG-driven protocols | ||||||||||||||
|
This document defines IANA registries for the YANG Protocol Error List and YANG Protocol Error Identities. | |||||||||||||
| Multi-Authentication in IKEv2 with Post-quantum Security | ||||||||||||||
|
Motivated to mitigate security threats against quantum computers, this draft specifies a general authentication mechanism in the Internet Key Exchange Protocol Version 2 (IKEv2) [RFC7296], called Multi-Authentication. Namely, two peers can negotiate two or more authentication methods to authenticate each other. The authentication methods selected do not necessarily belong to the same category. This mechanism is achieved by adding a new value (17) (TBD) in the "IKEv2 Authentication Method" registry [IANA-IKEv2], maintained by IANA. To run Multi-Authentication, two peers send the SUPPORTED_AUTH_METHODS Notify, defined in [RFC9593], to negotiate two or more authentication methods for authentication in IKEv2. [EDNOTE: Code points for Multi-Authentication may need to be assigned in the "IKEv2 Authentication Method" registry [IANA-IKEv2], maintained by IANA] | |||||||||||||
| Benchmarking Methodology for RPKI Relying Party | ||||||||||||||
|
This document defines a benchmarking methodology for evaluating RPKI Relying Party (RP) implementations in controlled laboratory environments. The methodology focuses on whether RP implementations correctly perform required validation steps and on the performance of these operations. RP implementations are treated as black boxes, enabling consistent and objective assessment based on externally observable behavior rather than internal design or implementation details. | |||||||||||||
| Campus Agent Identification and Scope-Down Access Control | ||||||||||||||
|
AI agents operating in enterprise campus networks execute user- delegated Tasks by invoking multiple tools and services, often without continuous user supervision. Traditional authorization models assume stable applications and human-driven interactions, creating a mismatch when applied to autonomous agents that can chain actions across heterogeneous systems. Campus environments also contain heterogeneous and legacy services across diverse protocols, making per-service agent-aware authorization difficult to deploy consistently. Similar problems can also appear in residential access networks where home AI agents, smart-home hubs, and personal devices share a subscriber line and are connected through a broadband network gateway (BNG). This document describes the problem space for campus agent access control and argues that agents require task-bound privilege reduction ("scope-down") and that enforcement can be provided by in-path network devices in order to preserve compatibility with existing systems. It also describes a home network and BNG use case where the access provider or home gateway can provide a coarse but useful network-level boundary for agent traffic. | |||||||||||||
| Balancing Security and Deployability in the Selection of Attested TLS Protocol | ||||||||||||||
|
This document analyzes the selection of Attested Transport Layer Security (aTLS) protocols, among pre-handshake, intra-handshake, and post-handshake aTLS protocols, focusing on the trade-off between theoretical security strength and practical deployability. The goal is to enable flexible, context-aware deployment of endpoint attestation while maintaining compatibility with existing infrastructure. | |||||||||||||
| KEM/Signature-Based Methods for Scenarios with Asymmetric Device Constraints | ||||||||||||||
|
This document extends the KEM-based Authentication for EDHOC draft by defining additional quantum-resistant authentication methods that support combined authentication approaches, where one party authenticates using a KEM-based mechanism and the other using a post- quantum signature scheme. | |||||||||||||
| Coherence-BFD: Sub-Second Coherence Detection Using Bidirectional Forwarding Detection Patterns | ||||||||||||||
|
This document specifies Coherence-BFD, a protocol that combines the asynchronous heartbeat, demand-mode, echo function, and detection-multiplier mechanisms of Bidirectional Forwarding Detection (BFD, [RFC5880]) with the multi-vantage path coherence detection of [I-D.melegassi-mvps-incremental-be]. The result is a sub-second coherence failure detector with theoretical and empirical detection latency of 55 ms (1091x faster than the 60-second tick baseline of the underlying BE-MVPS framework). Five execution variants are specified: V0 (baseline), V1 (heartbeat-fast), V2 (demand), V3 (echo), and V4 (hybrid). Wall- clock benchmarks confirm V3 (Echo) as the latency-optimal variant at 55 ms median tau_detect with 39 680 B/s bandwidth. This revision (-01) adds three layers of proof: (a) Canonical: formal proofs of the detection lower-bound (Theorem T-BFD-1), false-positive-rate decay (Theorem T-BFD-2), and connection to the GDDP geometric- precision framework (Corollary C-BFD-3). (b) Empirical: SHA-256-anchored benchmark receipts reproducible from the public reference scripts. (c) Real data: validation against 92 067 RIPE Atlas RTT measurements from 450+ globally-distributed anchors spanning 2+ months of continuous collection. NOTE ON DATA PROVENANCE. Wall-clock detection-latency and bandwidth numbers in Section 10 are obtained from controlled benchmarks (scripts/benchmark_coherence_bfd.py). Real-data validation in Section 18 uses live Internet RTT measurements from RIPE Atlas to confirm that the theoretical bounds hold on operational paths. HARDWARE CAVEAT. The 55 ms median tau_detect is a SOFTWARE- HARNESS measurement, not a router-class measurement. Validation against real BFD hardware is identified as required future work before progression past Experimental status. | |||||||||||||
| Volume-Independent DDoS Detection via Coherence-BFD: The MVPS DDoS Resilience Profile | ||||||||||||||
|
This document specifies how the Multi-Vantage Path Synchrony (MVPS) framework [I-D.melegassi-ippm-mvps-bundle] and its sub-tick variant Coherence-BFD [I-D.melegassi-coherence-bfd] detect volumetric and distributed Denial-of-Service (DDoS) attacks in time bounded by (M-1)*T_tick, INDEPENDENT of the attack rate in packets- per-second or bits-per-second. Three theorems are proved: Theorem D1 (Volume-Independence). Detection latency is a function of the control-tick period T_tick and the M-multiplier confirmation count alone; it does not grow with attack volume. Theorem D2 (Distributed-Attack Bound). The framework detects up to floor((k-1)/2) simultaneous regional attacks under cell-aware minimax aggregation, where k is the number of coherence cells. Theorem D3 (Broker NIC Sizing). Under the three architectural invariants of Section 3, broker NIC sizing is independent of attack volume; it is determined only by the legitimate telemetry packets-per-second. This revision (-02) adds seven confirmed real-world DDoS detections using a causally-direct methodology: BGP updates measured on each VICTIM'S OWN announced prefix (not on unrelated third-party infrastructure). (a) 7 independently confirmed DDoS attacks across 3 continents (Australia, South Africa, New Zealand), spanning two orders of magnitude in target size (from a major OS vendor to a small 22-year-old regional host): VentraIP (600 Gbps), Canonical (3.5 Tbps), Binary Lane (400 Gbps), Network Platforms (676 Gbps), Xneelo (300 Gbps), SiteHost NZ, and 1-Grid (100 Gbps). 30 of 33 tested prefixes (91%) alarmed on the confirmed attack day; 4 of 7 targets show 100% prefix corroboration. (b) VentraIP: BGP alarm fired the SAME HOUR as attack onset (00:00 UTC, D^2=11.7), four hours BEFORE mitigation began. Canonical: BGP alarm fired 2 hours BEFORE Cloudflare migration began. (c) Joint statistical significance across all 7 targets (multi-prefix binomial test): P < 5.9*10^-60 under the null hypothesis that alarms are unrelated to attack timing -- 52 orders of magnitude beyond the 5-sigma particle- physics discovery threshold. (d) Volume-independence (D1) confirmed: 1-Grid (100 Gbps) produced a HIGHER D^2 (63.2) than Canonical (3500 Gbps, D^2=10.6). Detection depends on coherence deformation, not attack bandwidth. (e) An invalid claim from an intermediate draft (RIPE Atlas K-root time-coincidence implying 53.6-hour pre-report detection) was identified via a Monte Carlo control test as a look- elsewhere/base-rate artifact and RETRACTED (Section 7.7.1), then replaced with the causally-direct results above. | |||||||||||||
| SlimMLS | ||||||||||||||
|
This document defines SlimMLS, an extension to the Messaging Layer Security (MLS) protocol for reducing wire and per-client storage overhead in groups that use ciphersuites with large public keys, ciphertexts, signatures, and credentials. SlimMLS replaces many large objects that appear in MLS authenticated or transcript-hashed structures with typed hash references. Clients resolve the referenced objects only when needed, using a per-message carrier, a local cache, or an application-specific retrieval channel. The extension is most useful when an independent Delivery Service can assist with retrieval and per-recipient delivery, although local caching and delayed fetching also help without such assistance. SlimMLS defines slim variants of KeyPackage, Commit, Welcome, GroupInfo, and message framing. When placing a signature outside an encrypted envelope would reveal the signer, SlimMLS keeps the signature inside the ciphertext. | |||||||||||||
| Automated Agent-to-Agent Ontology Reconciliation for Cognitive Network Management Systems | ||||||||||||||
|
This document describes a possible direction for inter-system communication in network management, in which two cognitive software agents establish between themselves the basis for exchanging information, without depending on a single rigid data model agreed by their implementers in advance. The agents bring relevant knowledge, can extend it through learning, can reason, and can converse in natural language. The approach is framed as a workflow in which each agent makes explicit the ontology implicit in its data model, the two agents address their differences through conversation, and a translator artefact is produced that is then used during ordinary operation. A central property is that language-model inference is consumed during the agents' conversation rather than on each subsequent message. The document situates the direction relative to adjacent work and illustrates it through three use cases drawn from network management. | |||||||||||||
| Transport Layer Security (TLS) based key-management of the Stream Control Transmission Protocol (SCTP) DTLS Chunk | ||||||||||||||
|
This document defines how Transport Layer Security (TLS) 1.3 is used as a key-management method for the SCTP DTLS Chunk mechanism. It specifies how a TLS handshake establishes the initial security context for an SCTP association and how subsequent TLS handshakes provide key updates and re-authentication. The goal is to enable authenticated and confidential communication over SCTP using the DTLS Chunk, leveraging standardized TLS 1.3 features for key management and rekeying. | |||||||||||||
| A Framework for Fast Network Notifications | ||||||||||||||
|
Many network applications, ranging from Artificial Intelligence (AI) / Machine Learning (ML) training and inference to large-scale cloud services, require networks with various combinations of high bandwidth, low delay, low jitter, and minimal packet loss. Meeting these requirements depends on the network's ability to adapt rapidly to faults, signal degradation, and congestion. The companion problem statement describes why existing mechanisms are too slow, too coarse, or too resource-intensive to react within the timescales at which modern forwarding hardware can detect and disseminate intended conditions. This document defines a framework for Fast Network Notifications (FANN). It describes a reference architecture, the functional roles involved in generating and consuming notifications, an information model, delivery and scoping models, procedures for discovery, registration, and subscription, and the integration of fast network notifications with existing Layer 2 to 4 mechanisms. This framework is intended to guide the development of one or more fast network notification protocol specifications. | |||||||||||||
| Ordered Information Element Export in IP Flow Information Export (IPFIX) | ||||||||||||||
|
The IP Flow Information Export (IPFIX) protocol allows the same Information Element to appear multiple times in a Template Record. RFC 7011 states that multiple occurrences of the same Information Element SHOULD follow the logical order of their treatments by the Metering Process; however, no protocol mechanism exists for the Exporting Process to explicitly signal to the Collecting Process that this ordering is guaranteed. Without such a guarantee, the Collecting Process cannot safely interpret repeated Information Elements as ordered observations. This document describes the problem, presents use cases, analyzes candidate solutions, and specifies a mechanism -- a new Ordered Set type -- that establishes an end-to-end ordering guarantee: the Metering Process records repeated Information Element values in the order the corresponding observations are made, the Exporting Process preserves and signals this guarantee, and the Collecting Process interprets the n-th occurrence of an Information Element as corresponding to the n-th observation by the Metering Process at the Observation Point. This document updates RFC 7011, RFC 5476, and RFC 6183. | |||||||||||||
| Long-Term,Crypto-Agile Preservation of Authorization Evidence (EP-EVIDENCE-RECORD) | ||||||||||||||
|
Regulations increasingly require that records of who authorized a high-risk action be retained for years (e.g. five years under DORA, six under HIPAA and SEC 17a-4). Any fixed signature or hash algorithm used to protect such a record weakens over time; a receipt signed today with Ed25519 over SHA-256 may be cryptographically attackable before its retention period ends. This document defines EP-EVIDENCE-RECORD, an OPTIONAL profile that preserves the verifiability of EMILIA Protocol authorization receipts (and other artifacts) across algorithm aging, using a renewal chain in the style of the Evidence Record Syntax [RFC4998]. Each renewal time-attests the entire prior renewal under a fresh, stronger algorithm before the older one is broken, so an unbroken chain links the original artifact to the most recent renewal. The record is offline- verifiable, fail- closed, and maintained as cross-language conformance vectors that three reference verifiers (JavaScript, Python, Go) are required to agree on. Those verifiers live in one repository, a cross-language consistency check, not clean-room independent implementations; independent implementations remain future interoperability evidence. This revision additionally defines two OPTIONAL companion profiles, EP-WITNESS-v1 witness cosignatures over a transparency log's committed checkpoint head and an independent RFC 3161 time attestation verified offline against a relying-party-pinned time- stamping authority key; both are implemented today in the JavaScript reference verifier only. | |||||||||||||
| fmsg: Structured Host-to-Host Messaging with Verifiable Threads | ||||||||||||||
|
fmsg is a message exchange protocol between domain defined hosts. Messages are binary encoded and form threads which require participation to reply to. This document describes the motivation and architecture of fmsg, an existing protocol specification and implementation are referenced, but the full specification is not included here. The purpose of this document is to solicit IETF feedback on venue and scope before/if the specification can develop into standards-track documents. | |||||||||||||
| Condition-Bounded Credentials for Workload and Agent Identity: Non-Exfiltratable Keys and Validity by Presence | ||||||||||||||
|
The WIMSE architecture binds a workload credential to a cryptographic key presented with proof of possession, and leaves credential lifetime and rotation to the implementation. In common practice the binding key is held in software and rotated frequently, because a software key can be copied: rotation is a compensating control for a key that can be exfiltrated. This document defines a profile in which the binding key is hardware- rooted and non-exfiltratable, and in which credential validity is gated by attested conditions -- the workload and its required posture being measured and present -- rather than by a fixed expiry. Two consequences follow. Frequent rotation is no longer required to bound exfiltration, because the key cannot leave the hardware boundary. And a grant cannot outlive the workload, even with no expiry date, because the key, and with it the ability to prove possession, is gone once the workload or its conditions cease to hold. Condition failure is therefore enforced by the key's absence rather than by a revocation message, and the credential can be appraised without a live connection to its issuing authority. The profile is specified against a verifier contract -- authority, live-instance, condition, freshness, and fail-closed checks -- that other credential profiles can share, so these properties are made explicit and reviewable without standardizing a single credential format or hardware recipe. It is offered as one conforming way to instantiate WIMSE credentials, suited to stable, attestable platforms, and is explicitly not proposed for high-churn, hardware- less workloads. | |||||||||||||
| A Layered Requirements Mapping for Cross-Organization Agent Delegation | ||||||||||||||
|
This document records a comparative mapping of two evidence layers for cross-organization AI agent delegation: a per-hop delegation chain (PEDIGREE) and a named-human authorization root (the EMILIA Protocol binding and evidence-graph drafts), evaluated against the nine requirements of draft-reece-wimse-cross-org-delegation under a no-shared-operator assumption. It also records a verifier-facing composition model in which key possession, delegated authority, and pre-execution human authorization are diagnostically separate inputs with independent failure behavior, joined by action digest. The mapping was developed on the WIMSE mailing list; corrections continue there. | |||||||||||||
| AI for Autonomous Networking | ||||||||||||||
|
This document builds on the architectural foundation of the IETF ANIMA "Autonomous Network Infrastructure" to propose an architecture for in-network intelligence in support of network automation. The key aspect of this architecture is the use of AI programmed and validated software running decentralized on the network. | |||||||||||||
| Use Cases and Requirements for Network Admission of AI Agent Instances | ||||||||||||||
|
Artificial intelligence (AI) agents increasingly access enterprise resources, external models, tools, and other agents through managed networks. Application-layer authentication can authenticate an agent to a cooperating service, but it cannot by itself provide complete network admission control. In particular, application proofs are normally verified only after network reachability exists, cannot be consumed consistently by heterogeneous or legacy services, and do not reliably identify which Agent Instance originated traffic when multiple Agents share one host, IP address, or egress gateway. This document describes operational use cases, the resulting problem statement, and requirements for network admission of AI Agent Instances. It focuses on establishing a verifiable and time-bounded binding among an Agent Instance, its credential key, optional runtime evidence, and a Network Context on which the network can enforce reachability policy. This document does not define a new Agent-ID format, authentication protocol, OAuth grant, or routing extension. | |||||||||||||
| Security Capability Coordination Execution Framework for 5G Core Networks | ||||||||||||||
|
This document defines a security capability coordination execution framework for 5G core networks. The framework employs a set of Security Coordination Components (SCC) that work collaboratively with core network functions to achieve continuous trust verification and least-privilege access control. It specifies the division of responsibilities between the Network Function Security Agent and the Management Security Controller. This document aims to provide a standardized architecture reference for the ZTCPP working group. | |||||||||||||
| Token Operation Problem Statement | ||||||||||||||
|
Distributed LLM inference relies heavily on high-performance networking to synchronize states across accelerators (e.g., GPUs) and nodes. Unlike traditional web services, inference workloads particularly those involving Mixture-of-Experts (MoE) models and long-context windows exhibit unique traffic patterns characterized by massive east-west traffic and strict latency constraints. Current network infrastructures and scheduling methods often treat compute resources and network paths independently, leading to suboptimal performance and degraded Quality of Experience (QoE). This document elaborates on these issues to guide potential protocol enhancements within the IETF. | |||||||||||||
| A Publication-Point-Based Incremental Validation Procedure for RPKI Relying Parties | ||||||||||||||
|
RPKI Relying Parties commonly perform top-down validation of the RPKI certificate tree after repository synchronization. Existing repository synchronization mechanisms can update the local repository incrementally, avoiding a complete retrieval of all repository data. However, after such an incremental repository update, an RP implementation may still repeat full top-down validation over the local repository. It means that the RP starts from the trust anchors and performs complete validation checks for all currently reachable RPKI objects encountered during the traversal. Repeating such validation for objects whose validation inputs have not changed can introduce unnecessary validation overhead. This document specifies a publication-point-based incremental validation procedure for RPKI RPs. The procedure is intended to reduce redundant validation work after incremental repository synchronization, while preserving the same validation result as a full top-down validation over the same repository snapshot, trust anchor set, validation policy, and validation time. This document does not change the syntax or validation semantics of any RPKI object. | |||||||||||||
| Transparent Ordered Bonding for High-Capacity WAN Links | ||||||||||||||
|
This document describes a Transparent Ordered Bonding (TOB) mechanism for high-capacity wide-area links that are physically composed of multiple lower-rate member links. Traditional flow-based load balancing mechanisms can preserve packet ordering, but they cannot fully utilize all member links for a single large traffic stream. TOB introduces a bonding layer between two adjacent network nodes. The bonding layer fragments ingress packets into cells, distributes them across member links according to link status, and reassembles them in strict order at the remote node. This document specifies the applicability, architecture, packet format, scheduling considerations, and resequencing behavior of TOB. | |||||||||||||
| CATS Fallback Decision Framework | ||||||||||||||
|
This document describes the framework and considerations for fallback decision-making in Computing-Aware Traffic Steering (CATS). While existing OAM frameworks provide multi-dimensional telemetry collection capabilities, how the CATS Path Selector (C-PS) should react to partial or transient failures remains an open issue. This document highlights the problems of misjudgment due to correlated failures, steering flapping, and non-deterministic fallback behaviors. It outlines the high-level considerations for logical decoupling of status dimensions and stable state transition mechanisms to ensure carrier-grade reliability. Specific protocol extensions and algorithm implementations will be explored in future revisions based on working group discussions. | |||||||||||||
| Windowless Cumulative ACK Extension for RDMA Retransmission | ||||||||||||||
|
Traditional RDMA Reliable Connection (RC) uses selective retransmission, while TCP SACK depends on sliding window and RTO timer tuning. Both mechanisms waste network bandwidth when window or RTO parameters mismatch real network conditions. This document defines a windowless cumulative selective acknowledgement extension (T/C AETH) embedded within the RDMA ETH header, paired with dual- trigger ACK reporting logic driven by cumulative receive time threshold and cumulative received packet count threshold. The receiver generates extended SACK reports without sliding window constraints. The sender accurately identifies lost PSN segments through multi-segment confirmation fields carried in T/C AETH, then only retransmits missing packets. This design removes window dependency, eliminates redundant retransmissions, and improves bandwidth utilization and end-to-end throughput for high-speed RDMA workloads in data centers and wide-area networks. | |||||||||||||
| SCTE35 transmission over MSF Event Timeline | ||||||||||||||
|
Defines the transmission of SCTE 35 data over MSF Event Timeline tracks. | |||||||||||||
| Optical Networks and AI Computing Orchestration (ONCO) Problem Statement,Use Cases and Requirements | ||||||||||||||
|
Distributed artificial intelligence (AI) computing is increasingly deployed across geographically dispersed AI data centers (AIDCs) to meet the scale and performance demands of modern AI workloads. In such environments, the efficiency of distributed training and inference depends critically on tight coordination between optical transport networks and compute orchestration systems. However, today's infrastructure operates with isolated control planes: optical networks lack awareness of dynamic compute requirements, while compute schedulers have no visibility into real-time network conditions such as latency, bandwidth, or congestion. This decoupling leads to suboptimal resource utilization, degraded job performance, and inefficient scaling. This draft presents the problem statement, outlines two representative use cases: distributed AI training and distributed AI inference, and specifies the requirements for Optical Networks and AI Computing Orchestration (ONCO). The goal is to enable bidirectional awareness, joint resource abstraction, and synchronized control across the compute-optical boundary, thereby supporting intent- driven, end-to-end provisioning of AI services over wide-area optical infrastructures. | |||||||||||||
| A Control Framework for Optical Networks and AI Computing Orchestration (ONCO) | ||||||||||||||
|
This document defines the control framework for Optical Networks and AI Computing Orchestration (ONCO). The framework is designed to achieve synergistic management of optical network (e.g., fgOTN, OXC) and computing resources for high-performance AI workloads. It specifies a multi-stakeholder service model, a layered architecture across management, control, and data planes, and a set of functional components. The ONCO framework supports both centralized and distributed orchestration models to enable proactive resource reservation and deterministic optical circuit provisioning. | |||||||||||||
| OSPF-TE Extensions for Computing Capability Advertisement | ||||||||||||||
|
This document defines extensions to OSPF Traffic Engineering (OSPF- TE) for advertising computing capability information associated with Artificial Intelligence Data Centers (AIDCs) in optical networks. The extensions enable an ASON or GMPLS-capable optical network to maintain a synchronized view of both network TE resources and selected computing resource attributes, so that service placement and path computation can consider computing resource status. The mechanism uses OSPFv2 Type-10 Opaque LSAs and a set of top-level TLVs and sub-TLVs. The extensions do not define new OSPF packet types and do not modify the OSPF neighbor establishment, database exchange, flooding, or acknowledgement procedures. | |||||||||||||
| Silithium - A Compact,Efficient and Non-separable Hybrid Signature | ||||||||||||||
|
This document defines Silithium, an augmentation of US NIST Module- Lattice-based Digital Signing Algorithm (ML-DSA) [FIPS.204] with traditional elliptic-curve operations, that uses ML-DSA in a black- box manner. This results in a digital signature scheme with hybrid security, requiring solving hard lattice problems as well as discrete logarithm in order to forge a signature. This augmentation is designed to satisfy regulatory guidelines in certain regions. Silithium is strongly unforgeable as long as ML-DSA is. Morevoer, Silithium can be used in a backward compatible and interopable manner without hindering security. | |||||||||||||
| Operational Considerations for BFD Encapsulation in SRv6 Policy | ||||||||||||||
|
Bidirectional Forwarding Detection (BFD) mechanisms can be used for fast detection of failures in the forwarding path of SR Policy. This document describes the Operational Guidance for BFD Encapsulation in SRv6 Policy. The BFD packets may be encapsulated in Insert-mode or Encaps-mode. | |||||||||||||
| Rethinking YANG-based Service and Network Management in the Era of Agentic AI | ||||||||||||||
|
The industry today is actively exploring the application of agentic AI to autonomous network operations. However, there is little attention given to the impacts that the introduction of agentic AI may impose on YANG modeling, and how YANG can be better leveraged to support AI-driven autonomous operations. Based on some end-to-end intent translation workflow analysis that engage YANG models across service, network, and device layers, this document identifies some critical gaps when AI agents generate and operate on YANG data. The purpose of this document is not to substantially redesign YANG or define a new data model language. Instead, it aims to facilitate discussion on how existing YANG ecosystems can be better leveraged in the context of agentic AI, and how complementary mechanisms can bridge these gaps while preserving YANG’s interoperability. | |||||||||||||
| BGP Extension for Secure Session State Synchronization | ||||||||||||||
|
This document defines a new BGP Address Family, termed the Secure Session Synchronization Address Family, allowing BGP speakers to exchange stateful firewall, NAT, and IPSec session information across distributed nodes. This architecture facilitates zero-packet-loss failover and seamless path protection for Secure SD-WAN, SASE, and SSE multi-POP deployments, entirely bypassing the scalability limits of traditional layer-2 synchronization protocols. | |||||||||||||
| Carrying 5G Network Slice Identifiers in IP Headers for QoS Assurance Beyond the 3GPP-Managed Domain | ||||||||||||||
|
3GPP defines 5G network slicing as an end-to-end service spanning the Radio Access Network (RAN), Transport Network (TN), and Core Network (CN). Within these domains, dedicated slice-awareness and management mechanisms are specified by 3GPP. However, when 5G slice traffic traverses an IP backbone network that lies outside the 3GPP-managed domain -- such as when a User Plane Function (UPF) connects to an external service provider network -- slice context information is lost, and the IP backbone cannot differentiate or assure the quality of individual slices. This document proposes a method for preserving 5G network slice awareness in IP backbone networks by encoding the 3GPP Single Network Slice Selection Assistance Information (S-NSSAI) directly into IPv6 packet headers. This document also describes the associated procedures for slice-aware QoS assurance in the IP backbone. | |||||||||||||
| Applicability of A2A Protocol for Network Management Agents | ||||||||||||||
|
The evolution of network management towards autonomic operation requires the deployment of AI agents at various hierarchical layers, including directly on network elements. This transformation shifts network devices from passively managed resources to autonomous entities capable of local decision-making and collaborative problem- solving. This document discusses the applicability of the Agent-to-Agent (A2A) Protocol to the network management plane, specifically for communication between Controller Agents (CAs) and Device Agents (DAs). This indicates that the inherent characteristics of Device Agents necessitate the adoption of the agent-to-agent communication paradigm. The document further explores generic workflows, deployment scenarios, and the relationship of A2A with existing network management protocols like NETCONF, RESTCONF, gNMI,and the Model Context Protocol (MCP). | |||||||||||||
| Cross-Domain Network Agent Architecture for Autonomous Operations | ||||||||||||||
|
Autonomous network management using agents is maturing in single- domain deployments. However, end-to-end services spanning multiple domains expose a lack of systematic support for cross-domain coordination, roles, and interfaces in current architectures. This document defines a cross-domain network agent architecture that enables coordinated operation across autonomous domains through standardized agent roles, layered coordination mechanisms, and unified interface specifications. | |||||||||||||
| Framework and YANG Data Model for the NMA A2U Interface | ||||||||||||||
|
This document describes a framework and a YANG data model for the Agent-to-User (A2U) interface of a Network Management Agent (NMA). The A2U interface is a user-facing interface through which a non- agent upper-layer system or user, such as an operator's OSS/BSS, orchestrator, management portal, human-facing application, automation system, etc., interacts with an NMA. The A2U interface supports NMA capability discovery, unified intent submission, task lifecycle management, execution plan exposure, human-in-the-loop confirmation, task progress notification, and consistent error reporting. The YANG data model defined in this document includes operational state data, RPC operations, and YANG notifications for the A2U interface. The model is intended to be used with YANG-based management protocols. This document does not define a separate transport protocol, a new HTTP resource API, or a separate notification delivery mechanism. | |||||||||||||
| JSContact Profile for RESTful Provisioning Protocol (RPP) | ||||||||||||||
|
This document defines a JSContact usage profile, conforming to the rules described in [I-D.ietf-calext-jscontact-profiles], for the RESTful Provisioning Protocol (RPP). The JSContact Profile for RPP specifies how the JSContact format defined in [RFC9982] can be used as a standardized representation of contact information within RPP operations, enabling interoperability and consistency across RPP implementations that manage contact data. | |||||||||||||
| OAuth 2.0 for RESTful Provisioning Protocol (RPP) | ||||||||||||||
|
This document describes how OAuth 2.0 [RFC6749] can be used to secure RESTful Provisioning Protocol (RPP) API requests described in [I-D.ietf-rpp-core]. | |||||||||||||
| ONSEN Problem Statement | ||||||||||||||
|
The IETF has produced numerous YANG data models for automating the provisioning and delivery of network and connectivity services, including L2SM, L3SM, L2NM, L3NM, Attachment Circuits, and Network Slicing models. Despite their wide availability, operators report persistent challenges in operationalizing these abstractions in a consistent, scalable, and automatable manner. This document describes the problem space for the ONSEN Working Group, identifying the operational gaps and deficiencies in existing IETF service and network abstraction models that prevent effective end-to-end automation. The problems documented here are drawn from operator experience and from the findings of the IAB NEMOPS Workshop. This document does not propose solutions, protocols, or new data models. | |||||||||||||
| Secure Object Transfer for RESTful Provisioning Protocol (RPP) | ||||||||||||||
|
This document describes how OAuth 2.0 [RFC6749] can be used to secure object transfers in RESTful Provisioning Protocol (RPP) [I-D.ietf-rpp-core]. It extends the RPP OAuth 2.0 authorization model defined in [I-D.wullink-rpp-oauth2] with mechanisms specific to federated object transfers. | |||||||||||||
| Secure Delegation Management for RESTful Provisioning Protocol (RPP) | ||||||||||||||
|
This document describes how OAuth 2.0 [RFC6749] enables a third party, such as a DNS Operator, to manage delegation (name server) details for a domain name on behalf of the registrant using the RESTful Provisioning Protocol (RPP). It extends the RPP OAuth 2.0 authorization model defined in [I-D.wullink-rpp-oauth2] with mechanisms specific to third-party delegation management via RPP [I-D.ietf-rpp-core]. | |||||||||||||
| Flow-Level Carbon Emissions Tracing for Packet Networks | ||||||||||||||
|
This document defines a method to derive per-flow energy consumption and associated carbon emissions without requiring inline power instrumentation for network equipment. Although energy consumption is commonly monitored at the device, network, or facility level, fine-grained attribution of energy consumption and carbon emissions to individual traffic flows remains an open research problem. The central contribution is the formulation of a flow-level carbon accounting model that transforms counter-based traffic measurements into energy usage estimates and subsequently into carbon emissions using time- and location-dependent carbon intensity data. The specification defines a device power model, a flow-level energy derivation, and idle-energy attribution methods for flows. This document further highlights how different definitions of carbon attribution can lead to significant variability in attributed carbon to flows, emphasizing the urgent need to standardize carbon accounting definitions and methodologies. In addition to the modeling framework, the document defines mechanisms for telemetry collection and deployment models for end-to-end flow tracing to support operational use cases. These elements complement the core contribution by enabling implementation and observability. | |||||||||||||
| Scenarios and Routing Requirements for Mega-Constellation LEO Satellite Networks | ||||||||||||||
|
With the rapid maturation of laser Inter-Satellite Link (ISL) technologies, Low Earth Orbit (LEO) mega-constellations are evolving from bent-pipe relay networks dependent on dense Ground Stations (GS) into highly autonomous spaceborne routing networks. Traditional terrestrial routing protocols and their variants, such as Global Link-State Routing Architectures, rely on a globally consistent link- state view and a global convergence paradigm, which are fundamentally incompatible with the high dynamics, time-variant topologies, and frequent link disruptions characteristic of ten-thousand-node scale satellite networks. This document describes core routing scenarios including non-dense ground deployment and inter-continental transit, analyzes the engineering infeasibility of global convergence protocols in space environments, reviews the limitations of existing mitigation approaches, and specifies key requirements for satellite routing protocols centered around localized autonomy and distributed decision-making. | |||||||||||||
| BGP Flow Specification for QUIC | ||||||||||||||
|
A BGP Flow Specification is an n-tuple consisting of several matching criteria that can be applied to IP traffic. This document defines how to perform Flow Specification traffic diversion based on the characteristics of QUIC packets. | |||||||||||||
| BGP Route Reflector Dual-Next-Hop Reflection for Path Protection | ||||||||||||||
|
This document specifies a mechanism where a BGP Route Reflector (RR) reflects a single received BGP route as two distinct routing updates towards a target client. By preserving the original client next-hop in one update and modifying the next-hop to the RR's own address in the second update, the receiving client obtains two parallel paths for the same prefix. This enables the receiving client to implement Load Balancing or Primary-Backup path protection without requiring full-mesh IBGP sessions or BGP Add-Path extensions. | |||||||||||||
| On-Demand Distributing BGP SR Policy Using Outbound Route Filtering Capability | ||||||||||||||
|
The BGP SR Policy address family defines a mechanism to distribute Segment Routing (SR) policies from a centralized controller to head- end routers. However, pre-provisioning all candidate SR Policies across massive-scale networks impose significant control-plane memory and processing overhead on edge nodes. This document specifies an extension to the BGP Outbound Route Filtering (ORF) capability, leveraging the framework defined in RFC 5291. It introduces a new SR Policy Tuple ORF type that allows a head-end router to precisely request or subscribe to specific SR Policies based on a Color and Endpoint tuple, enabling pure on-demand, pull-based policy distribution. | |||||||||||||
| Registration and Discovery Extension for Multi-Model Agents | ||||||||||||||
|
Existing agent registration and discovery mechanisms assume that each intelligent agent is backed by a single, static inference model. However, in real-world deployments, agents increasingly incorporate internal model routing mechanisms where multiple foundation models are used dynamically within a single agent based on task complexity, latency requirements, system load, and cost constraints. Although such agents are exposed externally as single service endpoints, their execution behavior is not static and may vary due to internal model selection logic that is not visible to external systems. This leads to mismatches between registered metadata and actual service behavior, reducing the effectiveness of discovery and QoS-aware routing. | |||||||||||||
| BGP Egress Peer Engineering (EPE) SID Allocation and Extensions for IXP Route-Server Scenarios | ||||||||||||||
|
BGP Egress Peer Engineering (EPE) defines mechanisms to steer egress traffic towards a specific border router, interface, or peer group using Segment Routing (SR). [RFC9086] specifies BGP-LS extensions to advertise these EPE peer segments. However, in Internet Exchange Point (IXP) deployments where border routers peer with a centralized Route-Server (RS), control plane peerings are completely decoupled from data plane forwarding paths. This document specifies the architecture, specific procedures, and associated BGP-LS TLV application guidelines for allocating and signaling EPE PeerNode and PeerSet SIDs on an egress border router connected to an IXP Route-Server infrastructure, ensuring granular and deterministic egress traffic engineering across IXP fabrics. | |||||||||||||
| Multiple Agents Collaboration in 6G Network | ||||||||||||||
|
This document describes the progress of 6G study on AI topic, e.g. key issues, potential solutions and alternative communication protocols. Despite the apparent overlap between 3GPP and IETF in the hot topics of Agents e.g. communication protocols, discovery, authorization and etc., 3GPP and IETF address different problems due to consideration of network boundaries. Thus this document tracks the progress of 6G study to identify dependencies on IETF protocols within the agent communication topics. | |||||||||||||
| SCHC Context Management Extensions | ||||||||||||||
|
This document defines extensions to the Static Context Header Compression (SCHC) framework that improve context management efficiency. Two categories of mechanisms are introduced: rule referencing CDAs (ref and ref-edit) that enable composable rule definitions and reduce context storage, and a rule fragment branching CDA (branch) with associated Matching Operators that enable dynamic multi-layer protocol compression without combinatorial rule explosion. | |||||||||||||
| Static Rate Management (SRM) for Low Latency,Low Loss,and Scalable Throughput (L4S) | ||||||||||||||
|
This document describes the Static Rate Management (SRM) solution for L4S (Low Latency, Low Loss, Scalable Throughput) rate control. SRM utilizes a Two-Rate, Three-Color Marker (trTCM) policer in conjunction with a dual-queue mechanism to provide low latency and low loss for L4S flows in environments where a fixed, safe rate can be reliably defined for a network link or segment. This approach offers an alternative to Active Queue Management (AQM)-based L4S solutions, particularly for high-speed and aggregated networks with limited packet processing capabilities. This document details the operation, advantages, disadvantages, and configuration guidelines for SRM. | |||||||||||||
| MLS for IPsec Group Key Exchange | ||||||||||||||
|
This document describes a profile that uses the Messaging Layer Security (MLS) protocol as the group key-management substrate for Group Key Management using IKEv2 (G-IKEv2). The intent is to preserve the operational model of G-IKEv2, including IKEv2 transport, GSA policy distribution, a central GCKS, and the IPsec ESP data plane, while replacing GDOI-style group key distribution with an MLS group. The resulting design can be read as G-IKEv2 where MLS produces the per-epoch group secret used to key the IPsec ESP Data- Security SA. | |||||||||||||
| Extending SDF and CoAP for AI Agent Interaction with IoT Devices | ||||||||||||||
|
This document proposes extensions to the Semantic Definition Format (SDF) and the Constrained Application Protocol (CoAP) to better support AI agent interaction with Internet of Things (IoT) devices. It covers two aspects: identifying AI agents in CoAP transactions, and making SDF device descriptions readily consumable by large language models (LLMs) and autonomous agents. The document is intended to stimulate discussion within T2TRG on these topics. | |||||||||||||
| ACTN Extensions for Inter-Operator Coordination | ||||||||||||||
|
This document specifies an extension to the ACTN framework (RFC 8453) that enables coordination between the MDSCs of different operators, so that they can establish and operate end-to-end TE services cooperatively while each operator keeps full control of its own network and keeps its internal details private. As its concrete realization within ACTN, the extension defines the MDSC-MDSC Interface (MMI), a symmetric peer interface between the MDSCs of different operators, in which neither MDSC has authority over the other, and which complements rather than modifies the CMI and the MPI. The extension is independent of the underlying switching technology and applies to packet, optical, and multi-layer TE networks. | |||||||||||||
| Dual MPLS and SRv6 Service Advertisement in the Absence of Transposition | ||||||||||||||
|
RFC 9252 defines BGP signaling procedures for SRv6 services, including the use of an MPLS Label field and transposition semantics. However, when transposition is not used (i.e., TL = 0), RFC 9252 does not explicitly define the interpretation of the MPLS Label field, leading to ambiguity in control-plane signaling. This document specifies a minimal, backward-compatible extension to RFC 9252 that enables a single route to unambiguously advertise both a valid MPLS Service Label and an SRv6 Service SID. The extension relies on existing MPLS label semantics, without introducing new TLVs, attributes, or changes to the base encoding format. | |||||||||||||
| BGP Graceful Degradation Under Control Plane Memory Pressure | ||||||||||||||
|
This document describes an operational framework for graceful degradation of BGP under control-plane memory pressure. When BGP speakers experience rapid growth in routing state due to route flapping, configuration errors, or anomalous route injection, control-plane memory can become exhausted, leading to session resets, routing process restarts, or device reboots. The framework described in this document progressively reduces BGP route admission and processing based on local resource conditions, isolates non-critical neighbors or services when necessary, and restores routing state in a controlled manner after recovery. The objective is to preserve basic device operation and reduce service impact. This document does not define any new BGP messages, path attributes, capabilities, or protocol state machines. | |||||||||||||
| SCHC Compute-Address Compression/Decompression Actions for Dynamically Assigned IP Addresses | ||||||||||||||
|
This document defines new Matching Operators (MOs) and Compression/ Decompression Actions (CDAs) for the Static Context Header Compression and fragmentation (SCHC) framework defined in RFC 8724. These extensions enable efficient compression of dynamically assigned IP addresses, including IPv4 addresses assigned via DHCP, IPv6 prefixes learned through SLAAC or DHCPv6, IPv6 Interface Identifiers (IIDs), and IPv6 temporary privacy addresses generated per RFC 8981. The mechanism relies on both the compressor and decompressor sharing knowledge of the set of addresses assigned to the device. Addresses are organized into deterministically sorted tables, allowing compression to a small index value. For temporary IPv6 addresses, a synchronized generation algorithm enables compression to an epoch and counter value. | |||||||||||||
| Agent Gateway Policy Control Model | ||||||||||||||
|
This document defines an operational policy control model for operator-managed Agent Gateways. The model describes how an operator can control and observe interactions that are admitted, mediated, routed, proxied, or otherwise handled by an Agent Gateway. The model does not govern an agent's internal behavior, reasoning, planning, prompts, memory, tools, runtime, or lifecycle. Instead, it uses agent-related identifiers, groups, tenants, task classes, and service levels as gateway-recognized policy matching attributes. Those attributes allow an operator-managed Agent Gateway to identify the interactions to which a policy applies. The model defines four core policy classes: Interaction Access Control, QoS and Flow Control, Invocation and Token Control, and Path Selection. It further defines three supporting management capabilities: Subject and Attachment Binding, Applied Policy State and Telemetry, and Policy Lifecycle and Failure Handling. | |||||||||||||
| GCM-SST Authenticated Encryption in the Secure Real-time Transport Protocol (SRTP) | ||||||||||||||
|
This document defines how the GCM-SST (Galois Counter Mode with Strong Secure Tags) Authenticated Encryption with Associated Data (AEAD) algorithm family can be used to provide confidentiality and data authentication in the Secure Real-time Transport Protocol (SRTP). GCM-SST addresses known weaknesses in AES-GCM for short authentication tags, making it well suited for media encryption use cases where low overhead is critical. | |||||||||||||
| Extending Limit on Extensions Size in TLS 1.3 | ||||||||||||||
|
Protocol TLS 1.3 is widely used to protect traffic in the Internet. However, the format of the TLS 1.3 ClientHello, ServerHello, and EncryptedExtensions handshake messages limits the size of extensions to 64 Kbytes. This specification extends TLS 1.3 to allow extensions in ClientHello, ServerHello, and EncryptedExtensions have size larget than 64 Kbytes. | |||||||||||||
| Domain Control Validation for DNS Delegations | ||||||||||||||
|
The techniques specified in [I-D.draft-ietf-dnsop-domain-verification-techniques] for using the DNS to verify ownership or control of a domain in the Domain Name System (DNS) rely on the domain already being properly delegated to a DNS authority. For the specific case where the Application Service Provider is providing authoritative DNS services, the existing approaches don't provide a way to bootstrap domain validation onto a new Authoritative DNS Application Service provider. This specification proposes a mechanism for "Domain Control Validation" for cases where the User and DNS Administrator are validating control over a domain to an Authoritative DNS Application Service Provider and thus do not have the ability to add records within the domain. In this case, validation must be performed by the User taking actions in the DNS Registrar or Parent Zone that demonstrate control over the domain, such as by adding DNS NS records as validation records. | |||||||||||||
| Use of Galois Counter Mode with Strong Secure Tags (GCM-SST) in TLS,DTLS and QUIC | ||||||||||||||
|
This document defines cipher suites based on AES-GCM-SST and Rijndael-GCM-SST (Galois Counter Mode with Strong Secure Tags) for use in TLS 1.3, DTLS 1.3, and QUIC. GCM-SST provides authenticated encryption with near-ideal forgery probabilities for short authentication tags, making it suitable for bandwidth-constrained environments where reduced per-packet overhead is important. This document specifies cipher suites with 96-bit and 112-bit authentication tags. | |||||||||||||
| Happy Eyeballs v3 (HEv3) Event Logging with qlog | ||||||||||||||
|
This document specifies a qlog extension for Happy Eyeballs v3 (HEv3), enabling logging of dual-stack and multi-protocol connection racing behavior. It defines a dedicated event schema, event names, and data structures that capture DNS resolution timing, SVCB/HTTPS service discovery, candidate sorting and grouping, connection attempt scheduling and racing, NAT64 prefix discovery, success/failure outcomes, and summary metrics. | |||||||||||||
| Problem Statement for Standardizing the northbound Task Interface (NTI) of the Network Management Agent | ||||||||||||||
|
AI-driven Network Management Agents (NMAs) are being deployed to automate operational workflows such as cross-domain fault diagnosis and service remediation. While the IETF has standardized service data models and access protocols through the Controller NBI (RFC 8969), these provide atomic configuration and monitoring capabilities, not the semantics for delegating end-to-end operational tasks to an autonomous agent. As a result, NMA northbound interfaces are vendor-specific overlays. This document defines the problem statement for the Northbound Task Interface (NTI): the interface through which an operator or OSS delegates operational tasks to an NMA. | |||||||||||||
| TLS Extension for Distributed Revocation Ledger (DRL) Stapling using a Sparse Merkle Tree | ||||||||||||||
|
Managing certificate revocation remains a recurring challenge in the Web Public Key Infrastructure (WebPKI). Existing solutions such as Certificate Revocation Lists (CRLs) and the Online Certificate Status Protocol (OCSP) involve compromises in terms of propagation latency, availability, and user privacy. With the planned deprecation of OCSP by some major Certificate Authorities (CAs), there is renewed interest in alternatives. This document specifies a decentralized certificate revocation architecture based on a Distributed Revocation Ledger (DRL) managed collectively by CAs. The ledger state is maintained as a Sparse Merkle Tree (SMT) in which only revoked certificates occupy non- default leaves, so that a valid certificate is attested by a compact non-membership proof and no prior registration of valid certificates is required. This document further defines a new Transport Layer Security (TLS) extension enabling "DRL Stapling", which allows a server to provide a client with a cryptographic proof of a certificate's status, consisting of a Sparse Merkle audit path and an M-of-N threshold signature from the CA consortium. The approach builds on the Revocation Transparency proposal of Laurie and Kasper and on subsequent formalizations of Sparse Merkle Trees; its novel contributions are the decentralized threshold-signature trust model with deterministic finality and the concrete TLS wire format. | |||||||||||||
| RADIUS WBA Vendor-Specific Attributes for Wi-Fi Network Quality Metric Reporting | ||||||||||||||
|
This document defines a set of RADIUS Vendor-Specific Attributes (VSAs) designed to encode network quality metrics that are not uniquely associated with an IEEE 802.11 (Wi-Fi) connection. These attributes enable access network quality information to be communicated between RADIUS clients and servers. | |||||||||||||
| DNS-based Entity-Level Discovery and End-to-End Connection for AI Agents | ||||||||||||||
|
This document defines a new DNS resource record type, Agent Entity Discovery (AED), to publish agent-specific trust anchors or direct match constraints for verifying an agent's certificate or token. This enables the cross-domain users or agents to authenticate, and establish secure, end-to-end connections directly with a private- domain agent entity. | |||||||||||||
| Elastic Bandwidth-aware Routing Framework | ||||||||||||||
|
IGP normally computes the shortest paths in a network for packet forwarding, without taking the traffic demands and available bandwidth into consideration. When there is a link degradation or partial link failure in a network which causes throughput reduction, or the volume of specific traffic flows increase dramatically, unexpected congestion may happen if only the shortest paths are used for IP forwarding. Conventional centralized Traffic Engineering (TE) focuses on long- term bandwidth and routes planning based on traffic demands, which can not react to the congestions in networks timely. This document describes a distributed path computation and load balancing mechanism named Elastic Bandwidth-aware Routing (EBR), which can alleviate congestions timely before TE finishes the global optimization. It allows IGP-enabled nodes which face congestion to distribute traffic among the shortest paths and load-balancing alternate paths through Segment Routing Traffic Engineering (SR-TE), with weights determined based on the bandwidth utilization and available bandwidth of these paths. It provides an efficient, accurate and backward compatible approach for dynamic link congestion avoidance. | |||||||||||||
| Problem statements and Challenges of Internet for Physical AI : REA | ||||||||||||||
|
As autonomous agents and physical AI increasingly translate digital requests into physical execution, existing Internet trust mechanisms assure integrity within the digital domain but cannot verify whether execution conforms to physical reality. This document defines this problem space as Reality Execution Assurance (REA), extending the evidence-appraisal-result structure of RATS and SCITT to identify key gaps between digital declaration and physical execution and to outline design requirements for assurance results consumable by relying systems. This document is a problem statement and does not define a protocol. | |||||||||||||
| A Framework for SRv6-Based Trusted Key Relay in Quantum Key Distribution Networks | ||||||||||||||
|
Quantum Key Distribution (QKD) links generate symmetric key material between directly connected QKD nodes. Trusted relay is commonly used to extend key delivery beyond the reach of a single QKD link. A complete trusted-relay service requires the network to collect QKD link capacity and node trust information, compute a relay path according to service requirements, translate the result into an SRv6 path, and carry the relayed key information in an IPv6/UDP packet steered by that SRv6 path. This document describes an architectural framework for such a service. Each QKD link provides its available quantum key rate capacity, and each relay node provides a trust level. A controller uses these inputs together with application requirements to calculate a relay path. The path-computation algorithm is not standardized and may be selected or defined by the user, operator, or implementation. The calculated relay sequence is represented as an SRv6 path, and UDP packets following that path carry the key-relay information. This document identifies the protocol extension points needed to support the framework. The detailed encodings, message formats, SRv6 behaviors, TLVs, and signaling procedures are left for future work and are marked as TBD. | |||||||||||||
| Opportunistic Channels | ||||||||||||||
|
This document defines Opportunistic Channels: a way for two members of a Messaging Layer Security (MLS) group to efficiently create and operate an end-to-end encrypted 1-to-1 channel. In contrast to a full MLS group, the channel participants can't independently update their key material. Instead, participants opportunistically inject key material exported from other groups. As such, opportunistic channels are more efficient than full MLS groups, but achieve lower security guarantees. Their use case is the transmission of lower- security messages such as message delivery receipts. To keep messaging in opportunistic channels efficient, this document also defines MLS WireFormats that are equivalent to the MLS PublicMessage and PrivateMessage formats, but omit signatures. These WireFormats are otherwise independent of opportunistic channels and can be used in regular MLS groups. | |||||||||||||
| Coordinated Energy Saving between RAN and Transport Network | ||||||||||||||
|
This document provides an coordinated energy saving mechanism between RAN and transport network. | |||||||||||||
| Cryptographic Asset Discovery and Inventory | ||||||||||||||
|
This document compiles existing Cryptographic Asset Discovery and Inventory (CADI) methods and analyze potential gaps. | |||||||||||||
| CBOR Encoded Certificate Revocation Management | ||||||||||||||
|
This document specifies CBOR-encoded PKI structures for use with C509 certificates (draft-ietf-cose-cbor-encoded-cert), X.509 certificates (RFC 5280), and future certificate types. It defines C509 CRL and C509 OCSP, compact CBOR encodings of X.509 Certificate Revocation Lists (RFC 5280) and OCSP messages (RFC 6960), respectively. The structures defined in this document are certificate-type agnostic and can be used with C509 certificates, X.509 certificates, or future certificate types without modification. C509 OCSP improves on RFC 6960 by signing a wider set of fields to prevent algorithm- substitution and certificate-chain substitution attacks, replacing plaintext serial numbers with hashes to preserve requestor privacy, replacing the two-hash issuer identity with a single certificate hash, and identifying all participants (requestor, responder, issuer) by a uniform certificate hash rather than type-specific fields. C509 CRL and C509 OCSP are not wire-format-compatible with their DER- encoded X.509 counterparts and cannot be converted to or from them without semantic interpretation. | |||||||||||||
| Using Quantum-Resistant Key Encapsulation Mechanisms (KEMs) in the Pairwise Mode of Group Object Security for Constrained RESTful Environments (Group OSCORE) | ||||||||||||||
|
Group communication for the Constrained Application Protocol (CoAP) can be protected end-to-end by using the security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE). The pairwise mode of Group OSCORE provides authenticated encryption of CoAP messages, by means of symmetric keys that two group members establish only among themselves to achieve pairwise secure communication. This document defines the use of quantum-resistant Key Encapsulation Mechanisms (KEMs) as Pairwise Key Agreement Algorithm of Group OSCORE, enabling post-quantum secure derivation of the symmetric keys used in the pairwise mode. The Group Manager facilitates the exchange of KEM public keys and KEM ciphertexts among group members. | |||||||||||||
| Advertising Router Information | ||||||||||||||
|
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. | |||||||||||||
| Quantum-Resistant Key Encapsulation Mechanisms (KEMs) via the OSCORE Group Manager Using Authentication and Authorization for Constrained Environments (ACE) | ||||||||||||||
|
RFC 9594 defines a Key Distribution Center (KDC) to provision keying material for secure group communication, using the Authentication and Authorization for Constrained Environments (ACE) framework. An instance of KDC is the Group Manager for provisioning keying material in group communication scenarios that use the Constrained Application Protocol (CoAP) and the security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE). To make the pairwise mode of Group OSCORE post-quantum secure, it is possible to rely on a quantum-resistant Key Encapsulation Mechanism (KEM) as the Pairwise Key Agreement Algorithm used to derive pairwise keys. This document extends the interface of the ACE-based Group Manager to enable the exchange of KEM public keys and KEM ciphertexts among group members via the Group Manager, thus making the derivation of pairwise keys in Group OSCORE post-quantum secure. | |||||||||||||
| COSE Algorithms for KangarooTwelve,TurboSHAKE and KMAC | ||||||||||||||
|
RFC 9861 defined and registered four eXtendable-Output Functions (XOFs), hash functions with output of arbitrary length, named TurboSHAKE128, TurboSHAKE256, KT128, and KT256; the present document is intended as the IETF consensus document that is now needed to give these algorithms Recommended status in the COSE registry. This document specifies concrete instances of those four functions above to be used as MACs in COSE. This document also specifies concrete instances of KMAC128 and KMAC256 in [NIST.SP.800-185] to be used as MACs in COSE and registers code points for them. And, this document provides "Recommended" status for those algorithms for COSE. | |||||||||||||
| SCIM 2.0 IPSIE Profile | ||||||||||||||
|
This document defines a profile for SCIM 2.0 to meet the security and interoperability requirements for identity lifecycle management within enterprises. Within the context of SCIM, the profile establishes requirements for provisioning, account management, client authentication, and identity synchronization across three Account Lifecycle assurance levels: AL1 (User Deprovisioning), AL2 (User and Group Management), and AL3 (Role Management). | |||||||||||||
| AI Agent Authorization Integration Framework | ||||||||||||||
|
This document describes how to integrate multiple OAuth 2.0 extensions to enable secure authorization for AI agents acting on behalf of users. It combines cross-domain identity, policy-based authorization, user consent evidence, and multi-hop delegation into a cohesive framework for autonomous agent authorization. | |||||||||||||
| TCP Packet Trimming Extension | ||||||||||||||
|
This document specifies a TCP extension that enables TCP endpoints in data center networks or similarly controlled administrative domains to use packet trimming information when it is available. When switch buffers exceed a threshold, rather than silently dropping a packet, the switch trims the payload and forwards the header. This allows the destination to issue a deterministic Negative Acknowledgment (NACK), enabling faster, more deterministic loss recovery. | |||||||||||||
| QUIC Application for ROS2 with MQTT | ||||||||||||||
|
While DDS (Distributed Data Service) protocol, managed by Object Management Group (OMG), for ROS (Robot Operating System) 2 is intended to provide a universal communication layer, interoperability across different DDS middleware implementations is not always consistent. Variations in transport protocol usage (e.g., TCP/IP, UDP, shared memory) can hinder direct data exchange, and cross-domain communication efficiency is generally lower compared to protocols such as HTTP. Therefore, to resolve limitations of DDS in ROS2, this draft considers a couple of standards protocols, QUIC of IETF and MQTT (Message Queuing Telemetry Transport), managed by OASIS Open. | |||||||||||||
| Moderation of unLinkable Endorsements (MoLE) Architecture | ||||||||||||||
|
Moderation of unLinkable Endorsements (MoLE) is an architecture that lets a party performing access control (a Moderator) bootstrap trust in a client from a third party (an Anchor) that already has a trust relationship with that client, and then adjust that trust over time in response to the client's behaviour, for example by dynamically rate-limiting access. MoLE targets open deployments, in which independent parties may be responsible for access control and for vouching for clients, whilst maintaining strong privacy protections for clients. These protections are designed to hold even if participants in the ecosystem collude or otherwise misbehave. This document specifies the roles, the information flows between them, the privacy and security requirements, and deployment considerations. | |||||||||||||
| IS-IS Originator Sequence Number Checksum TLV | ||||||||||||||
|
This document introduces a new top-level TLV in IS-IS to carry a checksum over the LSP IDs and sequence numbers of all self-originated LSP fragments. A receiving node uses this value to validate the integrity of the originator's Link State Database (LSDB). | |||||||||||||
| MoLE HTTP Transport | ||||||||||||||
|
MoLE targets browser deployments, so Clients, Anchors, and Moderators need an HTTP transport for the protocol flows defined by the architecture. This document defines the Mole HTTP authentication scheme, which carries challenges and presentations for the endorsement and credential flows, and the headers used to return credential material. The grant exchanges with the Anchor are defined per protocol in [PROTOCOLS]. | |||||||||||||
| Geometric Dilution of Detection Precision for Multi-Vantage Path Snapshots | ||||||||||||||
|
GPS positioning accuracy degrades with anchor geometry; the effect is quantified by the well-known Geometric Dilution of Precision (GDOP). Multi-vantage anomaly detection systems face the DUAL problem: how does anchor geometry affect DETECTION SENSITIVITY rather than localisation accuracy? This document formalises Geometric Dilution of Detection Precision (GDDP) for the Multi-Vantage Path Snapshot (MVPS) framework [I-D.melegassi-ippm-mvps-bundle]. The minimum displacement that a multi-vantage detector can reliably distinguish from measurement noise is NOT a single number: it is an anisotropic scalar field d*(v, theta) over the Earth's surface, governed by the geometry of the anchor set relative to each vantage. Three main results are proved: (1) GDDP Theorem (T-GDDP-1): d*(v, theta) admits a closed-form expression in terms of the Fisher Information of the anchor- to-vantage RTT-ratio vector. The directional detection threshold is d*(theta) = sqrt(chi2_crit / I(theta)), where I(theta) is the Fisher Information in direction theta. This is the Cramer-Rao bound applied to detection. (2) Anisotropy Lemma (L-GDDP-2): every vantage has a "blind cone" -- a set of directions in which displacement barely changes the RTT-ratio vector and detection sensitivity degrades. The blind cone is quantifiable and, for isolated vantages, can span over 70% of the compass. (3) Monotonicity Theorem (T-GDDP-3): adding an anchor NEVER reduces the Fisher Information of the system (Shannon chain rule applied to detection channels). There exists a principled anchor- placement optimisation: minimise max_theta d*(v, theta) over candidate sites. All three are validated to three layers of proof: canonical (math), empirical (deterministic scripts, seed=1337), and real data (RIPE Atlas measured RTTs, 92,067 D-squared values from 40 probes, 11/11 checks PASS). No simulation-only claim is made. The GDDP/GDOP duality has not, to the author's knowledge, been previously formalised. VerLoc (Kohls and Diaz, USENIX Security 2022) observes the directional effect empirically but does not derive d*(v, theta) or propose a geometric defence. | |||||||||||||
| Use Cases and Requirements for Multi-Domain and Hybrid Overlay/Underlay BGP-SPF (LSVR) | ||||||||||||||
|
This document presents use cases and the routing requirements they imply for operating the BGP Link State (BGP-LS) Shortest Path First (SPF) routing developed in the Link-State Vector Routing (LSVR) Working Group, across multiple administrative domains and over hybrid overlay/underlay topologies. After motivating the work, it describes three scenarios of increasing complexity: a single overlay domain, the interconnection of multiple overlay domains, and hybrid overlay/ underlay networks. Each scenario gives the topology, its distinguishing challenges, and the requirements that follow. The scenarios arise in globally distributed edge- and cloud-Point-of- Presence (PoP) deployments that serve performance-sensitive applications such as cross-region real-time communication, collaborative productivity, cloud gaming, and large-scale SaaS. | |||||||||||||
| IMSC1 Packaging for MOQT Streaming Format | ||||||||||||||
|
This document specifies the packaging format for delivering IMSC1 content as Event Timeline tracks within the MOQT Streaming Format (MSF). | |||||||||||||
| MoLE Protocols | ||||||||||||||
|
This document defines protocols that instantiate the MoLE architecture: two endorsement protocols, by which a Client proves to a Moderator that it holds an Endorsement from a trusted Anchor without revealing which one, and three credential protocols, by which a Moderator issues, verifies, and updates per-Client state without being able to link presentations. It also establishes the registries that identify these protocols. | |||||||||||||
| Mobile User Plane Evolution: 5G & 6G | ||||||||||||||
|
This document starts from the description of the 5G mobile user plane, including distributed User Plane Functions (UPFs). Then, based on the 3GPP proposals for 6G UP architecture evolution, the draft describes some potential enhancements revolving around the support of the 6G UP flexiblity, scalability & resilience. The draft also discusses the potential IETF work upon integrating the proposed enhancements of the 6G UP architecture. | |||||||||||||
| WebVTT Packaging for MOQT Streaming Format | ||||||||||||||
|
This document specifies the JSON packaging format for delivering WebVTT caption and subtitle content as event timeline tracks within the MOQT Streaming Format (MSF). | |||||||||||||
| The Sygil Protocol: A Cross-Domain Personal Data Schema and Query Grammar for AI Agents | ||||||||||||||
|
This document specifies the Sygil Protocol, an open schema and query grammar for cross-domain personal data designed to make user data interoperable across systems, vendors, and AI agents. The protocol defines a content-addressable record envelope, a reverse-DNS namespace identifier scheme, a deterministic JSON canonicalization rule, an optional vocabulary of proof objects for conveying provenance and other trust evidence on the wire, a minimal query grammar, and three adoption tiers from envelope-shaped data through queryable surfaces to vault-certified runtimes. The protocol is runtime-neutral: it specifies what travels on the wire, not how implementations store, encrypt, authorize, or audit records. This separation lets independent systems produce, consume, and exchange Sygil-shaped data without depending on any specific vault infrastructure. | |||||||||||||
| Guidelines for YANG Example Validation and Coverage Analysis in IETF Documents | ||||||||||||||
|
This document defines guidelines for including YANG example instances in IETF documents in a way that enables automatic extraction and validation. It introduces the concept of YANG module "coverage" to measure how thoroughly example instances exercise a YANG module's data nodes. By standardizing how YANG examples are included, validated, and measured for coverage, these guidelines help authors catch errors before publication and give reviewers and implementers greater confidence that the examples in a specification are correct and cover a sufficient range of scenarios - ultimately making the underlying data models easier to implement and use. | |||||||||||||
| Mission-Bound Authorization for OAuth 2.0 | ||||||||||||||
|
An AI agent is typically given a mission: a task to pursue on a user's behalf. OAuth 2.0 issues access tokens for individual resource requests, but it has no durable, approved artifact that ties those tokens to the one task a user actually authorized. As a result, an agent's authority is a collection of independently obtained tokens with no shared, auditable boundary, and a user's approval is disconnected from what the agent later does. This document defines a Mission: a structured, human-approved, integrity-bound authorization artifact for OAuth 2.0. A client submits a Mission Intent through Pushed Authorization Requests; the Authorization Server derives Rich Authorization Requests authorization details from it, binds the approved task and its derived authority to the Approver's consent through two integrity anchors, and records a durable Mission. Every access token derived under the Mission carries that authority and a "mission" claim, and issuance is gated on the Mission's lifecycle state. Optional capabilities represent delegation among agents with the OAuth Actor Profile and, as specified by a companion, let a single Mission be honored across trust domains. This is the issuance and governance "mission layer" left unspecified by agent-identity work for OAuth; runtime enforcement of each action is a separate, optional layer. | |||||||||||||
| Token Service Flow Awareness: Use Cases and Requirements | ||||||||||||||
|
This document outlines the use cases and requirements for token service flow awareness, providing the IETF working group with a standardized reference to better support the assurance of the user’s end-to-end experience. | |||||||||||||
| Multicast Traffic Engineering | ||||||||||||||
|
Traffic Engineering (TE) offers a very rich toolkit for managing traffic flows and the paths they take in a network. A TE network can have link attributes such as bandwidth, colors, risk groups and alternate metrics. A TE path can use these attributes to include or avoid certain links, increase path diversity, manage bandwidth reservations, improve service experience, and offer protection paths. These benefits apply equally to unicast and multicast traffic. This memo proposes multicast traffic-engineering (MCTE), allowing the use of TE for multicast traffic. MCTE is an alternative proposal to point-to-multipoint TE specified in [RFC4875]. The approach in [RFC4875] creates a separate "sub-LSP" from the source to each leaf, resulting in a considerable amount of signaling and state in the network. MCTE, on the other hand, uses the junction approach proposed in MPTE [I-D.kompella-teas-mpte] to create the multicast tree with less signaling and state. [RFC4875] proposes the use of RSVP-TE for signaling and an MPLS data plane for carrying traffic. MCTE allows the use of several control and data planes to signal tunnels and carry traffic. | |||||||||||||
| Problem Statement: YANG Modeling for Protocol Buffer Based Network APIs | ||||||||||||||
|
Network devices increasingly expose management, telemetry, and dynamic service interfaces using gRPC and Protocol Buffers. Many of these interfaces carry ephemeral or runtime state that is not intended to be stored as persistent configuration. At the same time, the IETF has standardized YANG as the primary data modeling language for network management and operations. This document describes the problem space and identifies questions for the IETF community regarding the role of YANG in defining interoperable Protocol Buffer based APIs. | |||||||||||||
| The Cookie-Preference HTTP Header Field | ||||||||||||||
|
This document specifies a new HTTP request header field, "Cookie- Preference", that enables user agents to communicate the user's preferred cookie disposition (e.g., accept all, accept essential only, reject all, or ask) to web servers. By conveying this preference upfront, the header can facilitate a more seamless browsing experience while respecting user privacy choices and reducing reliance on per-site consent dialogs. | |||||||||||||
| Globally Relevant HTTPS RRs | ||||||||||||||
|
DNS answers for SVCB and HTTPS resource records are typically treated as scoped to the network on which they were obtained. This requires clients to re-resolve DNS when changing network attachments, adding latency to connection establishment. This document defines a new SvcParamKey, "globally-relevant", for use in SVCB and HTTPS DNS resource records as defined in [RFC9460]. When present, this boolean flag indicates that the service binding parameters in the record are valid regardless of the client's network attachment point. Clients that observe this flag can reuse cached SVCB and HTTPS records across network changes, subject to normal TTL expiry. | |||||||||||||
| Composite FN-DSA and LMS Digital Signature Algorithm for use in X.509 Public Key Infrastructure | ||||||||||||||
|
This document defines a composite signature scheme combining the FN- DSA (Falcon) digital signature algorithm with the Leighton-Micali Signature (LMS) scheme defined in RFC 8554. This construction is designed for use within X.509 Public Key Infrastructure (PKI) and follows the composite signature paradigm defined in [I-D.ietf-lamps-pq-composite-sigs]. | |||||||||||||
| RICH: RESTful Interface for the Control-plane of Harnesses | ||||||||||||||
|
This document specifies the RICH (RESTful Interface for the Control- plane of Harnesses) architecture and information model. RICH provides a protocol-neutral governance, contract, qualification, and binding layer for RPC-based agent capabilities. It establishes a REST-addressable control plane for managing capability lifecycles while preserving native protocol execution in the data plane. It defines immutable capability and contract revisions, evidence provenance, deterministic connector classes, compiled binding lockfiles, and runtime validation rules designed to contain drift and prevent confused deputy attacks in agentic systems. | |||||||||||||
| Multicast Router State Synchronization in EVPN Networks | ||||||||||||||
|
Ethernet VPN (EVPN) networks support multicast applications in which multicast routers and multicast hosts are attached to the same tenant. Existing specifications define how Provider Edge (PE) devices synchronize the Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) membership state of multihomed multicast hosts, and how Optimized Inter-Subnet Multicast (OISM) forwarding interacts with multicast routers via PIM EVPN Gateways. However, none of the existing specifications addresses the synchronization of the state associated with a multicast router (an IGMP/MLD Querier or a Protocol Independent Multicast (PIM) router) when that router is multihomed to a set of EVPN PEs. This document specifies a new EVPN route, the Multicast Router Discovery (MRD) route, and the procedures to synchronize multicast router state across the PEs of an Ethernet Segment, for routers attached to multicast Broadcast Domains or to Layer 3 interfaces. | |||||||||||||
| A YANG Data Model for Fast Network Notifications | ||||||||||||||
|
This document defines a YANG data model to Fast Network Notifictions. | |||||||||||||
| MIMI Preauthorization based on deep references to MLS Credentials | ||||||||||||||
|
This document describes a Work-In-Progress syntax called claim pointers that identify specific items in structured credentials, which often have nested levels of hierarchy; and claim matchers that facilitate comparisons between items in credentials and a target value. It also describes a new version of the More Instant Messaging Interoperability (MIMI) preauthorization format using claim pointers and claim matchers. | |||||||||||||
| A Dimensional Model for Characterizing AI Agent Protocol Proposals and Their Substrates | ||||||||||||||
|
Discussions about agent protocols are frequently muddied by overloaded terms; asks such as "we need a session protocol" or "we need cross-domain support" bundle several distinct concerns across transport, agent protocol, and orchestration layers. This document offers a dimensional model that routes each concern to its proper layer. The document defines a small set of protocol-visible dimensions for characterizing AI agent protocol interactions and applies them to representative agentic protocol proposals (A2A, MCP, and the ACP invocation surface of the AGNTCY stack) alongside their substrate bindings, making explicit which dimensions each proposal owns at the protocol layer and which it inherits from its substrate. The document does not rank proposals and does not prescribe an architecture. It is standalone: it neither depends on nor prescribes any use-case or requirements document. | |||||||||||||
| Zero-Configuration Agent Discovery | ||||||||||||||
|
Protocols for communication between autonomous software agents typically discover agents through documents retrieved over HTTPS from a well-known URI. This model requires a discovering party to already know an agent's host name or URL, or to consult a centralized catalog. It provides no zero-configuration mechanism for enumerating agents that are present on a local network. This document describes how existing, widely deployed protocols, Multicast DNS (mDNS) and DNS-Based Service Discovery (DNS-SD), can be used to advertise and discover agents on a local link, with no new protocol machinery. It presents a general, protocol-independent two- stage discovery model in which lightweight enumeration over DNS-SD is followed by retrieval of full agent metadata over the agent's native transport. It gives a worked instantiation of that model for the Agent2Agent (A2A) protocol, as an example. | |||||||||||||
| PARCEP Protocol and Architecture for Networked Parental Controls | ||||||||||||||
|
PARCEP-Sync specifies a federated synchronization protocol and data model for guardian-controlled Child Online Protection, enabling household policies to be authored at a Policy Administration Point (PAP), distributed over a per-household Messaging Layer Security (MLS) group to Policy Enforcement Points (PEPs), and enforced using credentials and artifacts issued by jurisdictional Policy Information Points (PIPs). The protocol defines a small, regular set of methods for enrolment, policy publication and update, revocation, enforcement telemetry, digests, appeals, attestation, and artifact fetch, with dua l JSON-LD and CBOR/COSE encodings for web-scale and constrained environments. It is designed to avoid centralized databases of children s data, support cross-jurisdictional verification of guardianship and age, and provide privacy-preserving, metadata-only event reporting suitable for regulatory audit and appeal. | |||||||||||||
| Indicating IPv6-only SVCB Endpoints and IPv4 Deprecation in the DNS | ||||||||||||||
|
As the DNS is the primary mechanism for translating from hostnames to IP addresses, it is a logical place to signal that endpoints are IPv6-only. It is thus also a logical place to signal that legacy endpoints supporting IPv4 are being deprecated. This specification introduces two SvcParams for SVCB-compatible RR types that signal IPv6-only endpoints (ipv6only) as well as deprecated endpoints (deprecated). TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/enygren/draft-nygren-dnsop-ipv6only-indicator (https://github.com/enygren/draft-nygren-dnsop-ipv6only-indicator). The most recent working version of the document, open issues, etc. should all be available there. The authors (gratefully) accept pull requests. | |||||||||||||
| PREOF Observability and OAM Requirements | ||||||||||||||
|
Packet Replication, Elimination, and Ordering Functions (PREOF) enables highly reliable packet delivery through path redundancy and packet sequencing mechanisms in DetNet domains. Existing DetNet Operations, Administration, and Maintenance (OAM) specifications provide mechanisms for monitoring service connectivity, packet loss, delay, and overall service performance. However, they do not provide detailed operational visibility into the behavior of PREOF functions themselves. This document identifies operational observability gaps associated with PREOF, defines requirements for PREOF-specific OAM, and introduces a set of observable events and metrics to monitor, troubleshoot, and validate PREOF operation independently of the underlying DetNet data plane technology. | |||||||||||||
| Benchmarking Methodology for AI Agents in Network Operations | ||||||||||||||
|
This document defines a benchmarking methodology for evaluating Artificial Intelligence (AI) agents performing network operations tasks such as configuration, troubleshooting, and optimization. This document focuses on task-oriented performance metrics, including task completion success, execution efficiency, and robustness across multi-step workflows, proposing benchmarking practices towards agent- based, closed-loop network operation scenarios. The proposed methodology aims to provide a reproducible and vendor- independent framework to compare AI agent effectiveness in controlled network environments. | |||||||||||||
| n0 QUIC NAT Traversal | ||||||||||||||
|
A description of how noq (https://github.com/n0-computer/noq) performs NAT traversal for iroh (https://github.com/n0-computer/ iroh), including all current bugs. This is not yet a specification, though further revisions migth be. | |||||||||||||
| Abstractions for Telco-Cloud Scenarios | ||||||||||||||
|
draft-lcnc-onsen-telco-cloud-00 Abstract Cloud infrastructures are becoming increasingly distributed, spanning centralized facilities and distributed edge sites, all of them interconnected through networks from one or more administrative domains. Services running on top of such computing enironments require dynamic placement, admission control, lifecycle management, and coordinated scaling across sites, requiring proper allocation and operation of both compute and network resources in order to preserve the required expectations from customers and providers. Existing orchestration systems often depend on fragmented visibility of infrastructure resources (in both compute and network domains) and must interact with multiple management systems before determining service feasibility. This document discusses the role of network abstractions in Telco- Cloud environments benefiting the interplay and operation of cloud and network domains, building up a true Telco-Cloud approach. It identifies abstraction dimensions that can simplify service orchestration while enabling scalable operation across heterogeneous network and cloud infrastructures. | |||||||||||||
| TEMPO: Timing Extension for Media Playout Orchestration over MoQ | ||||||||||||||
|
This document defines TEMPO (Timing Extension for Media Playout Orchestration), a synchronized playout mechanism for media tracks delivered over the Media over QUIC Transport (MoQT) protocol. The Original Publisher stamps each object with when it should be played out and when it was sent. Relays replace the send-time stamp with their own clock as they forward, giving each subscriber a fresh timing reference from its nearest relay. Subscribers use these timestamps to decide when to render each object, and report their sync state directly to a coordination server (PlaySyncServer) that can tell the media publisher to adjust timing when subscribers fall behind. | |||||||||||||
| Agentic AI for Intent-Based Networking | ||||||||||||||
|
This document specifies how the rise of agentic AI and LLMs can impact and and accelerate the transition towards Intent-Based Networking. Specifically, it revisits functionality and liefecycle in IBN, as defined in [RFC9315], and outlines how agentic AI and LLMs can be leveraged. | |||||||||||||
| IntentWeb AgentManifest | ||||||||||||||
|
AgentManifest defines a JSON document that websites can publish to describe identity, trusted knowledge, agent-facing capabilities, structured bindings, risk levels, consent requirements, authentication expectations, audit rules, and policies. The goal is to help AI agents understand what a website knows and what it can safely do before scraping, guessing from visual UI, or executing brittle browser automation. | |||||||||||||
| Babel for Wi-Fi (IEEE Std 802.11) Mesh | ||||||||||||||
|
The BABEL routing protocol (RFC 8966) is well applicable (RFC 8967) to networks with unstable link metrics such as wireless networks. Wi-Fi (IEEE Std 802.11-2024) is an example of such a network and the Wi-Fi standard includes a mesh feature which was specified to be configurable for different routing protocols and link metrics. This document specifies how, in Wi-Fi mesh, to use BABEL and/or the delay based link metric specified in RFC 9616. | |||||||||||||
| MOCHA Reactions: Real-Time Reactions over MoQ Transport | ||||||||||||||
|
This document specifies reactions for MOCHA (MoQ Open Communication & Hosting Architecture). It supports message-targeted reactions (emoji on a specific chat message) and standalone reactions (engagement signals such as applause or raised hands). | |||||||||||||
| TN Attribute Certificate Extension for STI Certificates | ||||||||||||||
|
This document specifies a non-critical X.509 v3 certificate extension that conveys a set of self-asserted attributes describing the telephone numbers identified in the certificate's TNAuthList. The attributes are declared by the holder of the certificate about its own telephone numbers and require no separate authority token, because they describe or constrain only those numbers and grant no authority to any other party. The extension defines an extensible framework with an IANA registry of attribute types and seeds that registry with four types: a PASSporT Placement Service (PPS) URI, a do-not-originate indication, a do-not-originate-messaging indication, and a set of authorized originating providers. Relying parties use these self-declarations as policy signals, treating communications that do not conform to them as candidates for blocking. The mechanism is backward compatible with existing STIR certificates. | |||||||||||||
| MOCHA Meetings: Real-Time Conferencing over MoQ Transport | ||||||||||||||
|
This document specifies how multi-party audio and video meetings are conducted using MOCHA (MoQ Open Communication & Hosting Architecture). It defines namespace conventions, media track design, catalog distribution, and participant flows for real-time conferencing over MoQ Transport (MOQT). This specification supports both simulcast and scalable video codec configurations, enabling meetings ranging from small group calls to large-scale conferences. | |||||||||||||
| Ability Requirements for Stability Guarantees in Per-packet Load Balancing Networks | ||||||||||||||
|
Many per-packet load balancing mechanisms have been proposed to optimize the performance of AI networks. However, per-packet load balancing poses significant challenges to network stability assurance. This draft analyzes these challenges, as well as the ability requirements for stability guarantees in per-packet load balancing networks. | |||||||||||||
| Model Context Protocol and Agent Skills over Media over QUIC Transport | ||||||||||||||
|
This document defines how to use Media over QUIC Transport (MOQT) as the underlying transport protocol for the Model Context Protocol (MCP). MCP enables integration between language model applications and external data sources and tools. MOQT provides publish-subscribe delivery over QUIC and WebTransport with native prioritization, relay caching, and multiplexing. This specification maps MCP messages onto MOQT objects and defines procedures for session establishment, capability discovery, and ongoing communication. It covers MCP's core primitives (resources, tools, prompts, sampling, and notifications) through dedicated MOQT tracks. The document also describes Agent Skills -- composed instructions that extend AI capabilities beyond atomic tool operations -- using progressive loading aligned with MOQT's object-based delivery. | |||||||||||||
| PACE: Protocol for Agent Communication Exchange | ||||||||||||||
|
This document defines the Protocol for Agent Communication Exchange (PACE), a session protocol for AI agent communication over Media over QUIC Transport (MOQT). PACE provides session lifecycle management, multi-modal data exchange, agent identity verification, and delegated authorization within MOQT's publish/subscribe model, supporting point-to-point and point-to-multipoint topologies through relay infrastructure. | |||||||||||||
| An Extensible Key Configuration Format for Oblivious HTTP | ||||||||||||||
|
Oblivious HTTP is a protocol for forwarding encrypted HTTP messages. This requires communicating the gateway's key configuration to clients. While a key configuration media type was defined for this purpose, it has some limitations such as the inability to convey key lifetimes and interoperability issues. This document defines a similar extensible key configuration format that addresses those issues. | |||||||||||||
| A Survey of Domain Control Validation Techniques using DNS | ||||||||||||||
|
[I-D.draft-ietf-dnsop-domain-verification-techniques] describes best practices for using the DNS to verify ownership or control of a domain, a process generally referred to as "Domain Control Validation". This document is a companion survey that catalogs the DNS-based Domain Control Validation techniques in use today across a range of Application Service Providers and protocols. | |||||||||||||
| MOCHA Chat: Messaging over MoQ Transport | ||||||||||||||
|
This document specifies the messaging functionality for MOCHA (MoQ Open Communication & Hosting Architecture). It defines how participants send and receive messages in channels using MoQ Transport (MOQT) publish/subscribe primitives. Each device publishes messages on its own track within a channel namespace, enabling decentralized message production with relay-based fan-out. This specification covers message naming, format, causal ordering, delivery, roster management, and channel discovery for text-based chat. | |||||||||||||
| MOCHA MLS Keying: End-to-End Encryption Key Management over MoQ | ||||||||||||||
|
This document specifies MLS key management for MOCHA (MoQ Open Communication & Hosting Architecture). It defines how MLS groups are created, how members are added and removed, how key material is distributed over MOQT tracks, and how the MLS Delivery Service is realized in a fully distributed manner using MOQT publish/subscribe. For large channels, Partial MLS is used to avoid requiring all members to process every membership change. | |||||||||||||
| Detection of Router-ID Conflicts in IGPs | ||||||||||||||
|
In link-state Interior Gateway Protocols (IGPs) such as OSPF and IS- IS, the router ID (or system ID) serves as a unique identifier for routers within a routing domain. Duplicate router IDs can lead to severe network instability, including persistent Link State Advertisement (LSA/LSP) flooding, inconsistent Link State Databases (LSDBs), and permanent forwarding loops. This document defines mechanisms for detecting such conflicts between non-adjacent routers and proposes procedures to alert network operators, along with defining the corresponding YANG interface and event YANG notifications for OAM operations. | |||||||||||||
| MOCHA Identity: Authentication,Authorization,and Federation | ||||||||||||||
|
This document specifies identity, authentication, authorization, and federation for MOCHA (MoQ Open Communication & Hosting Architecture). It defines how users authenticate with Identity Providers (IdPs), how authorization tokens (C4M and Privacy Pass) are issued and validated at relays, how permissions map to MOQT namespaces, and how users from one Provider obtain access to resources on a federated Provider. | |||||||||||||
| DIEM Architecture Example | ||||||||||||||
|
This document defines the architecture for Digital Emblems. Standards that define Digital Emblems are expected to do so by mapping their mechanisms to the required and optional componented defined by this document. | |||||||||||||
| Applying SCITT to Hardware,IoT Device,and Cloud Compute Resource Supply Chains | ||||||||||||||
|
This document describes how SCITT can be applied to supply chains that include hardware components, IoT devices, firmware, cloud compute resources, confidential-computing environments, accelerators, and related operational evidence. It gives use cases and scope guidance. It also explains how SCITT can work with RATS, COSE, TCG technologies, SBOM, HBOM, CBOM, and cloud attestation systems without replacing those technologies. This document is informational. It does not define hardware assurance rules, cloud assurance rules, device identity systems, manufacturing requirements, or payload formats. Its purpose is to show where SCITT statements and receipts can provide transparency for heterogeneous supply-chain evidence, and where other standards or domain profiles should remain responsible. | |||||||||||||
| MOCHA Personal Address Book | ||||||||||||||
|
This document defines how a set of devices owned by a common user synchronize a Personal Address Book (PAB) over MOQT. The address book maps identities to human-readable names and contact information, enabling users to maintain a trusted contact list that is consistent across all their devices. | |||||||||||||
| SCITT Statement Relationship and Protected Object Binding | ||||||||||||||
|
This document defines a small common model for relating Supply Chain Integrity, Transparency, and Trust (SCITT) Signed Statements to the supply-chain objects that those statements describe, measure, authorize, revoke, or audit. The model can be used for software artifacts, firmware artifacts, hardware components, device instances, cloud compute resources, and other objects that appear in supply- chain evidence. The document also defines a relationship vocabulary and an optional Statement Graph Manifest. These parts help verifiers connect heterogeneous SCITT statements without requiring SCITT to define the payload formats of those statements. This document does not define SBOM, HBOM, CBOM, attestation, audit, vulnerability, or regulatory payload formats. It only defines a common binding and graph layer around SCITT statements and receipts. | |||||||||||||
| Composite Evidence Verification for SCITT Statement Graphs | ||||||||||||||
|
This document defines a common model for composite verification of SCITT statement graphs. A composite verifier checks a set of SCITT Signed Statements, receipts, object bindings, and relationship edges under a named verification profile. The result is a structured report that can say which statements passed, which evidence is missing, which evidence is stale, and which statements conflict. The model is intended for verifiers, auditors, deployment controllers, update services, and other relying-party tools. It is not a new Transparency Service requirement. It does not define a universal supply-chain policy language and does not define the payload format of any statement type. | |||||||||||||
| OAuth Client ID Metadata Document | ||||||||||||||
|
This specification defines a mechanism through which an OAuth client can identify itself to authorization servers, without prior dynamic client registration or other existing registration. This is through the usage of a URL as a client_id in an OAuth flow, where the URL refers to a document containing the necessary client metadata, enabling the authorization server to fetch the metadata about the client as needed. | |||||||||||||
| OAuth 2.0 Refresh Token and Authorization Expiration | ||||||||||||||
|
This specification extends OAuth 2.0 [RFC6749] by adding new token endpoint response parameters to specify refresh token expiration and user authorization expiration. | |||||||||||||
| Applying COSE Signatures for YANG Data Provenance | ||||||||||||||
|
This document defines a mechanism based on CBOR Object Signing and Encryption (COSE) signatures to provide and verify the provenance of YANG data, so it is possible to verify the origin and integrity of a dataset, even when those data are going to be processed and/or applied in workflows where a crypto-enabled data transport directly from the original data source is not available. As the application of evidence-based OAM automation and the use of tools such as AI/ML grow, provenance validation becomes more relevant in all scenarios, in support of the assuring the origin and integrity of data. The use of compact signatures facilitates the inclusion of provenance strings in any YANG schema requiring them. | |||||||||||||
| Path Computation Element Communication Protocol (PCEP) Extensions to Enable IFIT | ||||||||||||||
|
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 PCEP extensions to allow a Path Computation Client (PCC) to indicate which IFIT features it supports, and a Path Computation Element (PCE) to configure IFIT behavior at a PCC for a specific path in the stateful PCE model. The application to Segment Routing (SR) is reported. However, the PCEP extensions described in this document can be generalized for all path types, but that is out of scope of this document. | |||||||||||||
| Path Computation Element Communication Protocol (PCEP) Extensions for Network Resource Partition (NRP) | ||||||||||||||
|
This document specifies the extensions to Path Computation Element Communication Protocol (PCEP) to carry Network Resource Partition (NRP) related information in the PCEP messages. The extensions in this document can be used to indicate the NRP-specific constraints and information needed in path computation, path status report and path initialization. | |||||||||||||
| Multicast Lessons Learned from Decades of Deployment Experience | ||||||||||||||
|
This document gives a historical perspective about the design and deployment of multicast routing protocols. The document describes the technical challenges discovered from building these protocols. Even though multicast has enjoyed success of deployment in special use-cases, this draft discusses what were, and are, the obstacles for mass deployment across the Internet. Individuals who are working on new multicast related protocols will benefit by knowing why certain older protocols are no longer in use today. | |||||||||||||
| Merkle Tree Certificates | ||||||||||||||
|
This document describes Merkle Tree certificates, a new form of X.509 certificates which integrate public logging of the certificate, in the style of Certificate Transparency. The integrated design reduces logging overhead in the face of both shorter-lived certificates and large post-quantum signature algorithms, while still achieving comparable security properties to existing X.509 constructions and Certificate Transparency. Merkle Tree certificates additionally admit an optional size optimization that avoids signatures altogether, at the cost of only applying to up-to-date relying parties and older certificates. | |||||||||||||
| Distributed Aggregation Protocol for Privacy Preserving Measurement | ||||||||||||||
|
There are many situations in which it is desirable to take measurements of data which people consider sensitive. In these cases, the entity taking the measurement is usually not interested in people's individual responses but rather in aggregated data. Conventional methods require collecting individual responses and then aggregating them on some server, thus representing a threat to user privacy and rendering many such measurements difficult and impractical. This document describes a multi-party Distributed Aggregation Protocol (DAP) for privacy preserving measurement which can be used to collect aggregate data without revealing any individual contributor's data. | |||||||||||||
| qlog: Structured Logging for Network Protocols | ||||||||||||||
|
qlog provides extensible structured logging for network protocols, allowing for easy sharing of data that benefits common debug and analysis methods and tooling. This document describes key concepts of qlog: formats, files, traces, events, and extension points. This definition includes the high-level log file schemas, and generic event schemas. Requirements and guidelines for creating protocol- specific event schemas are also presented. All schemas are defined independent of serialization format, allowing logs to be represented in various ways such as JSON, CSV, or protobuf. Note to Readers Note to RFC editor: Please remove this section before publication. Feedback and discussion are welcome at https://github.com/quicwg/qlog (https://github.com/quicwg/qlog). Readers are advised to refer to the "editor's draft" at that URL for an up-to-date version of this document. | |||||||||||||
| QUIC event definitions for qlog | ||||||||||||||
|
This document describes a qlog event schema containing concrete qlog event definitions and their metadata for the core QUIC protocol and selected extensions. Note to Readers Note to RFC editor: Please remove this section before publication. Feedback and discussion are welcome at https://github.com/quicwg/qlog (https://github.com/quicwg/qlog). Readers are advised to refer to the "editor's draft" at that URL for an up-to-date version of this document. | |||||||||||||
| HTTP/3 qlog event definitions | ||||||||||||||
|
This document defines qlog event schemas containing concrete events for the core HTTP/3 protocol and selected extensions. It also defines an http namespace for the Capsule Protocol. Note to Readers Note to RFC editor: Please remove this section before publication. Feedback and discussion are welcome at https://github.com/quicwg/qlog (https://github.com/quicwg/qlog). Readers are advised to refer to the "editor's draft" at that URL for an up-to-date version of this document. | |||||||||||||
| Extended Key Update for QUIC | ||||||||||||||
|
This document specifies an Extended Key Update mechanism for the QUIC protocol, building on the foundation of the TLS Extended Key Update. The TLS Extended Key Update specification enhances the TLS protocol by introducing key updates with forward secrecy, eliminating the need to perform a full handshake. This feature is particularly beneficial for maintaining security in scenarios involving long-lived connections. This specification replaces the QUIC Key Update mechanism described in the "Using TLS to Secure QUIC" specification. | |||||||||||||
| QMux | ||||||||||||||
|
This document specifies QMux version 1. QMux version 1 provides, over bi-directional streams such as TLS, the same set of stream and datagram operations that applications rely upon in QUIC version 1. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the QUIC Working Group mailing list ([email protected]), which is archived at https://mailarchive.ietf.org/arch/browse/quic/. Source for this draft and an issue tracker can be found at https://github.com/quicwg/qmux. | |||||||||||||
| RadSec: RADIUS over Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) | ||||||||||||||
|
This document defines transport profiles for running RADIUS over Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS), allowing the secure and reliable transport of RADIUS messages. RADIUS/TLS and RADIUS/DTLS are collectively referred to as RadSec. This document obsoletes RFC6614 and RFC7360, which specified experimental versions of RADIUS over TLS and DTLS. | |||||||||||||
| Concise Reference Integrity Manifest | ||||||||||||||
|
Remote Attestation Procedures (RATS) enable Relying Parties to assess the trustworthiness of a remote Attester and therefore to decide whether or not to engage in secure interactions with it. Evidence about trustworthiness can be rather complex and it is deemed unrealistic that every Relying Party is capable of the appraisal of Evidence. Therefore that burden is typically offloaded to a Verifier. In order to conduct Evidence appraisal, a Verifier requires not only fresh Evidence from an Attester, but also trusted Endorsements and Reference Values from Endorsers and Reference Value Providers, such as manufacturers, distributors, or device owners. This document specifies the information elements for representing Endorsements and Reference Values in CBOR format. | |||||||||||||
| Concise Selector for Endorsements and Reference Values | ||||||||||||||
|
In the Remote Attestation Procedures (RATS) architecture, Verifiers require Endorsements and Reference Values to assess the trustworthiness of Attesters. This document specifies the Concise Selector for Endorsements and Reference Values (CoSERV), a structured query/result format designed to facilitate the discovery and retrieval of these artifacts from various providers. CoSERV defines a query language and corresponding result structure using CDDL, which can be serialized in CBOR format, enabling efficient interoperability across diverse systems. | |||||||||||||
| The "exts_list" Parameter for the RDAP Media Type | ||||||||||||||
|
This document defines a new parameter for the RDAP media type that can be used to describe RDAP content with RDAP extensions. Additionally, this document describes the usage of this parameter with RDAP for the purposes of signalling RDAP extensions during content negotiation. | |||||||||||||
| Extensible Provisioning Protocol (EPP) Transport over QUIC | ||||||||||||||
|
This document specifies how an Extensible Provisioning Protocol (EPP) session is mapped onto a QUIC connection. EPP over QUIC (EoQ) leverages features of the QUIC protocol. | |||||||||||||
| RESTful Provisioning Protocol (RPP) | ||||||||||||||
|
This document describes the endpoints for the RESTful Provisioning Protocol, used for the provisioning and management of objects in a shared database. | |||||||||||||
| JSON for RESTful Provisioning Protocol (RPP) | ||||||||||||||
|
This document defines the rules for representing the RESTful Provisioning Protocol (RPP) data objects, as defined in [I-D.ietf-rpp-data-objects], using the JavaScript Object Notation (JSON) Data Interchange Format [RFC8259]. It specifies how RPP primitive types, common data types, component objects, resource objects, and associations are mapped to JSON and JSON Schema, and provides normative JSON Schema definitions and worked examples for domain name, contact, and host data objects. | |||||||||||||
| Static Context Header Compression (SCHC) Architecture | ||||||||||||||
|
The Static Context Header Compression and fragmentation (SCHC) framework provides both a header compression mechanism and an optional fragmentation mechanism. This document defines a minimal architecture for SCHC deployments, providing guidance for implementers and operators on the essential components and their interactions required for effective SCHC operation. The architecture defines the components of a SCHC deployment - Endpoints, Instances, Contexts, Sessions, and Domains - their management, the framing of SCHC Datagrams, and considerations for technology-specific profiles. | |||||||||||||
| Structured Quoted Content | ||||||||||||||
|
This document describes a machine-readable format for conveying quoted content in email messages. This can be used when replying to or forwarding an email message. Structured quoted content is expected to be used in conjunction with conventional, human-readable quote formatting. They are based on the forthcoming "structured email" specification defined in [I-D.ietf- sml-structured-email-03] and related drafts. | |||||||||||||
| YANG Data Model for Segment Routing Policy | ||||||||||||||
|
This document defines a YANG data model for Segment Routing (SR) Policy that can be used for configuring, instantiating, and managing SR policies. The model is generic and applies equally to the MPLS and SRv6 instantiations of SR policies. | |||||||||||||
| Segment Routing Policy Extension for Network Resource Partition | ||||||||||||||
|
Segment Routing (SR) Policy is a set of candidate paths, each consisting of one or more segment lists and the associated information. A Network Resource Partition (NRP), is a subset of the resources and associated policies in the underlay network. In SR networks with multiple NRPs, an SR Policy can be associated with a particular NRP. In that case, SR Policy can be used for steering and forwarding traffic which is mapped to the NRP, so that the packets can be processed with the subset of network resources and policy of the NRP for guaranteed performance. Thus the association between SR Policy and NRP needs to be specified. This document defines extensions to the SR Policy Architecture to allow the association of the SR Policy candidate paths with NRPs. | |||||||||||||
| SRv6 Service Programming | ||||||||||||||
|
This document defines data plane functionality required to implement service segments and achieve service programming in SRv6 networks. | |||||||||||||
| Short-Lived Certificates for Secure Telephone Identity | ||||||||||||||
|
When certificates are used as credentials to attest the assignment of ownership of telephone numbers, some mechanism is required to provide certificate freshness. This document specifies short-lived certificates as a means of guaranteeing certificate freshness for secure telephone identity (STIR), potentially relying on the Automated Certificate Management Environment (ACME) or similar mechanisms to allow signers to acquire certificates as needed. | |||||||||||||
| Terminology and processes for initial security setup of IoT devices | ||||||||||||||
|
This document provides an overview of terms that are commonly used when discussing the initial security setup of Internet of Things (IoT) devices. This document also presents a brief but illustrative survey of protocols and standards available for initial security setup of IoT devices. For each protocol, we identify the terminology used, the entities involved, the initial assumptions, the processes necessary for completion, and the knowledge imparted to the IoT devices after the setup is complete. | |||||||||||||
| TCP RST Diagnostic Payload | ||||||||||||||
|
This document specifies an experimental diagnostic payload format returned in TCP RST segments. Such payloads are used to share with an endpoint the reasons for which a TCP connection has been reset. Sharing this information is meant to ease diagnostic and troubleshooting. This specification builds on provisions that are already present in RFC 9293 "Transmission Control Protocol (TCP)". As such, this document does not require any change to RFC 9293. | |||||||||||||
| IETF Network Slice Application in 3GPP 5G End-to-End Network Slice | ||||||||||||||
|
Network Slicing is one of the core features of 5G defined in 3GPP, which provides different network service as independent logical networks. To provide 5G network slices services, an end-to-end network slice has to span three network segments: Radio Access Network (RAN), Mobile Core Network (CN) and Transport Network (TN). This document describes the application of the IETF network slice framework in providing 5G end-to-end network slices, including network slice mapping in the management, control and data planes. | |||||||||||||
| Applicability of IETF-Defined Service and Network Data Models for Network Slice Service Management | ||||||||||||||
|
This document exemplifies how the various data models that are produced in the IETF can be combined in the context of Network Slice Services delivery. Specifically, this document describes the relationship between the Network Slice Service models for requesting Network Slice Services and both Service (e.g., the L3VPN Service Model, the L2VPN Service Model) and Network (e.g., the L3VPN Network Model, the L2VPN Network Model) models used during their realization. In addition, this document describes the communication between a Network Slice Controller (NSC) and the network controllers for the realization of Network Slices. The Network Slice Service YANG model provides a customer-oriented view of the intended Network Slice Service. Thus, once an NSC receives a request for a Slice Service request, the NSC has to map it to accomplish the specific objectives expected by the network controllers. Existing YANG network models are analyzed against Network Slice requirements, and the gaps in existing models are identified. | |||||||||||||
| Realization of Composite IETF Network Slices | ||||||||||||||
|
A network slice offers connectivity services to a network slice customer with specific Service Level Objectives (SLOs) and Service Level Expectations (SLEs) over a common underlay network. RFC 9543 describes a framework for network slices built in networks that usWe IETF technologies. As part of that framework, the Network Resource Partition (NRP) is introduced as a collection of network resources that are allocated from the underlay network to carry a specific set of network slice service traffic and meet specific SLOs and SLEs. In some network scenarios, network slices using IETF technologies may span multiple network domains, and they may be composed hierarchically, which means a network slice itself may be further sliced. In the context of 5G, a 5G end-to-end network slice consists of three different types of network technology segments: Radio Access Network (RAN), Transport Network (TN) and Core Network (CN). The transport segments of the 5G end-to-end network slice can be provided using network slices described in RFC 9543. This document first describes the possible use cases of composite network slices built in networks that use IETF network technologies, then it provides considerations about the realization of composite network slices. For the multi-domain network slices, an Inter-Domain Network Resource Partition Identifier (Inter-domain NRP ID) may be introduced. For hierarchical network slices, the structure of the NRP ID is discussed. And for the interaction between IETF network slices with 5G network slices, the identifiers of the 5G network slices may be introduced into IETF networks. These network slice- related identifiers may be used in the data plane, control plane and management plane of the network for the instantiation and management of composite network slices. This document also describes the management considerations of composite network slices. | |||||||||||||
| IP in Deep Space: Key Characteristics,Use Cases and Requirements | ||||||||||||||
|
Deep space communications involve long delays (e.g., Earth to Mars has one-way delays 4-24 minutes) and intermittent communications, mainly because of orbital dynamics. Most of the IP protocol stack used on the Internet, in particular reliable transport protocols and applications, is based on the assumptions of shorter delays and mostly uninterrupted communications. This document describes the key characteristics, use cases, and requirements for deep space networking, intended to help when profiling IP protocols in such environment. | |||||||||||||
| The Datagram Transport Layer Security (DTLS) Protocol Version 1.3 | ||||||||||||||
|
This document specifies version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The DTLS 1.3 protocol is based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees with the exception of order protection / non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document obsoletes RFC 6347. | |||||||||||||
| A Password Authenticated Key Exchange Extension for TLS 1.3 | ||||||||||||||
|
The pre-shared key mechanism available in TLS 1.3 is not suitable for usage with low-entropy keys, such as passwords entered by users. This document describes an extension that enables the use of password-authenticated key exchange protocols with TLS 1.3. | |||||||||||||
| Operational Guidance on Coexistence with Classic ECN during L4S Deployment | ||||||||||||||
|
This document provides guidance in order to ensure successful deployment of Low Latency Low Loss Scalable throughput (L4S) in the Internet. Other L4S documents provide guidance for running an L4S experiment, but this document is focused solely on potential interactions between L4S flows and flows using the original ('Classic') ECN over a Classic ECN bottleneck. The document discusses the potential outcomes of these interactions, describes mechanisms to detect the presence of Classic ECN bottlenecks, and identifies opportunities to prevent and/or detect and resolve fairness problems in such networks. This guidance is aimed at operators of end-systems, operators of networks, and researchers. | |||||||||||||
| Stream Control Transmission Protocol (SCTP) DTLS Chunk | ||||||||||||||
|
This document describes a method for adding Datagram Transport Layer Security (DTLS) based authentication and cryptographic protection to the Stream Control Transmission Protocol (SCTP). This SCTP extension is intended to enable communication privacy for applications that use SCTP as their transport protocol and allows applications to communicate in a way that is designed to prevent eavesdropping and detect tampering or message forgery. Once enabled, this also applies to the SCTP payload as well as the SCTP control information. Applications using this SCTP extension can use most of the transport features provided by SCTP and its other extensions. The use of the SCTP Authentication extension defined in RFC 4895 is incompatible with the extension defined in this document but would not provide any additional service. This implies that the Dynamic Address Reconfiguration as specified in RFC 5061 can only be used as described in this document. This document obsoletes RFC 6083 and updates RFC 5061. | |||||||||||||
| Flow Queue PIE: A Hybrid Packet Scheduler and Active Queue Management Algorithm | ||||||||||||||
|
This document presents Flow Queue Proportional Integral controller Enhanced (FQ-PIE), a hybrid packet scheduler and Active Queue Management (AQM) algorithm to isolate flows and tackle the problem of bufferbloat. FQ-PIE uses hashing to classify incoming packets into different queues and provide flow isolation. Packets are dequeued by using a variant of the round robin scheduler. Each such flow is managed by the PIE algorithm to maintain high link utilization while controlling the queue delay to a target value. | |||||||||||||
| 464XLAT/MAT-T Optimization | ||||||||||||||
|
IP/ICMP Translation Algorithm (SIIT) can be used to provide access for IPv4-only hosts or applications to IPv4-only or dual-stack destinations over IPv6-only infrastructure. In that case, the traffic flows are translated twice: first from IPv4 to IPv6 (stateless NAT46 at the ingress point to the IPv6-only infrastructure) and then from IPv6 back to IPv4 (stateful NAT64, at the egress point). When the destination is IPv6-enabled, the second translation might be avoided. This document describes a possible optimization to 464XLAT and MAP-T to avoid translating IPv6 flows back to IPv4 if the destination is reachable over IPv6. The proposed solution would significantly reduce the NAT64 utilization in the operator's network, increasing the performance. | |||||||||||||
| Basic Requirements for IPv6 Customer Edge Routers | ||||||||||||||
|
This document specifies requirements for an IPv6 Customer Edge (CE) router. Specifically, the current version of this document focuses on the basic provisioning of an IPv6 CE router and the provisioning of IPv6 hosts attached to it. The document obsoletes RFC 7084. | |||||||||||||
| The WebTransport Protocol Framework | ||||||||||||||
|
The WebTransport Protocol Framework enables clients constrained by the Web security model to communicate with a remote server using a secure multiplexed transport. It consists of a set of individual protocols that are safe to expose to untrusted applications, combined with an abstract model that allows them to be used interchangeably. This document defines the overall requirements on the protocols used in WebTransport, as well as the common features of the protocols, support for some of which is optional. | |||||||||||||
| WebTransport over HTTP/3 | ||||||||||||||
|
WebTransport over HTTP/3 is a binding of the WebTransport protocol framework [OVERVIEW] to HTTP/3 [HTTP3]. It provides support for unidirectional streams, bidirectional streams, and datagrams, all multiplexed within the same HTTP/3 connection. WebTransport enables application clients constrained by the Web security model to communicate with a remote application server using a secure multiplexed transport. | |||||||||||||
| WebTransport over HTTP/2 | ||||||||||||||
|
WebTransport defines a set of low-level communications features designed for client-server interactions that are initiated by Web clients. This document describes a protocol that can provide the capabilities of WebTransport over HTTP/2. This protocol enables the use of WebTransport when a UDP-based protocol is not available. | |||||||||||||
| Workload Identity in a Multi System Environment (WIMSE) Architecture | ||||||||||||||
|
The increasing prevalence of cloud computing and micro service architectures has led to the rise of complex software functions being built and deployed as workloads, where a workload is defined as software executing for a specific purpose, potentially comprising one or more running instances. This document discusses an architecture for designing and standardizing protocols and payloads for conveying workload identity and security context information. | |||||||||||||
| Workload Identifier | ||||||||||||||
|
This document defines a canonical identifier for workloads, referred to as the Workload Identifier. A Workload Identifier is a URI that uniquely identifies a workload within the context of a specific trust domain. This identifier can be embedded in Workload Identity Credentials, including X.509 certificates and JWT-based tokens, to support authentication, authorization, and policy enforcement across diverse systems. The Workload Identifier format ensures interoperability, facilitates secure identity federation, and enables consistent identity semantics. | |||||||||||||
| Workload Authentication Using Mutual TLS | ||||||||||||||
|
The WIMSE architecture defines authentication and authorization for software workloads in a variety of runtime environments, from the most basic ones to complex multi-service, multi-cloud, multi-tenant deployments. This document profiles a workload authentication based on X.509 workload identity certificates using mutual TLS (mTLS). | |||||||||||||
| Improving the Robustness of Stateless Address Autoconfiguration (SLAAC) to Flash Renumbering Events | ||||||||||||||
|
In scenarios where network configuration information becomes invalid without explicit notification to the local network, local hosts may end up employing stale information for an unacceptably long period of time, thus resulting in interoperability problems. This document improves the reaction of IPv6 Stateless Address Autoconfiguration to such configuration changes. It formally updates RFC 4191, RFC 4861, RFC 4862, RFC 8106, RFC 8781, RFC 9096, and RFC 9463. | |||||||||||||
| Constrained Application Protocol (CoAP) over Bundle Protocol (BP) | ||||||||||||||
|
The Bundle Protocol (BP) was designed to enable end-to-end communication in challenged networks. The Constrained Application Protocol (CoAP), which was designed for constrained-node networks, may be a suitable application-layer protocol for the scenarios where BP is used. This document specifies how CoAP is carried over BP. | |||||||||||||
| Split Signing Algorithms for COSE | ||||||||||||||
|
This specification defines COSE algorithm identifiers for negotiating how to split a signature algorithm between two cooperating parties. Typically the first party hashes the data to be signed and the second party finishes the signature over the hashed data. This is a common technique, useful for example when the signing private key is held in a smart card or similar hardware component with limited processing power and communication bandwidth. The resulting signatures are identical in structure to those computed by a single party, and can be verified using the same verification algorithm without additional steps to preprocess the signed data. | |||||||||||||
| DNSSEC automation | ||||||||||||||
|
This document describes an algorithm and protocol to automate the setup, operations, and decommissioning of Multi-Signer DNSSEC [RFC8901] configurations. To accomplish this, it employs Model 2 of the multi-signer specification (where each operator has their own distinct KSK and ZSK sets, or CSK sets), management of DS records from the parent via CDS/CDNSKEY [RFC8078], and Child-to-Parent Synchronization in DNS [RFC7477]. | |||||||||||||
| Tunnel Extensible Authentication Protocol (TEAP) Version 2 | ||||||||||||||
|
This document defines the Tunnel Extensible Authentication Protocol (TEAP) version 2. It addresses a number of security and interoperability issues which were found during the publication of TEAPv1 ([I-D.ietf-emu-rfc7170bis]). | |||||||||||||
| Framework for Energy Efficiency Management | ||||||||||||||
|
Recognizing the urgent need for energy efficiency, this document specifies a management framework focused on networks, devices and device components within, or connected to, interconnected systems. The framework aims to enable energy usage optimization, based on the network condition while achieving the network's functional and performance requirements (e.g., improving overall network utilization) and also ensure interoperability across diverse systems. Leveraging data from existing use cases, it delivers actionable metrics to support effective energy management and informed decision- making. Furthermore, the framework defines mechanisms for representing and organizing timestamped telemetry data using YANG data models and metadata, enabling transparent and reliable monitoring. This structured approach facilitates improved energy efficiency through consistent energy management practices. | |||||||||||||
| Considerations For Maintaining Protocols Using Grease and Variability | ||||||||||||||
|
Active use and maintenance of network protocols is an important way to ensure that protocols remain interoperable and extensible over time. Techniques such as intentionally exercising extension points with non-meaningful values (referred to as "grease") or adding variability to how protocol elements are used help generate this active use. Grease and variability are used across various protocols developed by the IETF. This document discusses considerations when designing and deploying grease and variability mechanisms, and provides advice for making them as effective as possible. | |||||||||||||
| Post-quantum Key Exchange with ML-KEM in the Internet Key Exchange Protocol Version 2 (IKEv2) | ||||||||||||||
|
US NIST standardized ML-KEM, a new key encapsulation mechanism, which can be used for quantum-resistant key establishment. This document specifies how to use ML-KEM by itself or as an additional key exchange in IKEv2 along with a traditional key exchange. These options allow for negotiating IKE and Child SA keys which are resistant against cryptographically relevant quantum computers. | |||||||||||||
| Key Transparency Protocol | ||||||||||||||
|
While there are several established protocols for end-to-end encryption, relatively little attention has been given to securely distributing the end-user public keys for such encryption. As a result, these protocols are often still vulnerable to eavesdropping by active attackers. Key Transparency is a protocol for distributing sensitive cryptographic information, such as public keys, in a way that reliably either prevents interference or detects that it occurred in a timely manner. | |||||||||||||
| IP RSVP-TE: Extensions to RSVP for P2P IP-TE LSP Tunnels | ||||||||||||||
|
This document describes the use of RSVP (Resource Reservation Protocol), including all the necessary extensions, to establish Point-to-Point (P2P) Traffic Engineered IP (IP-TE) Label Switched Path (LSP) tunnels for use in native IP forwarding networks. This document defines specific extensions to the RSVP protocol to allow the establishment of explicitly routed IP paths using RSVP as the signaling protocol. The result is the instantiation of an IP path which can be automatically routed away from network failures, congestion, and bottlenecks. This document also defines considerations for using these extensions in networks that support SRv6. | |||||||||||||
| Distribution of Service Metadata in BGP-LS | ||||||||||||||
|
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. | |||||||||||||
| Distribution of Service Metadata in BGP FlowSpec | ||||||||||||||
|
In edge computing and distributed cloud environments, a service may be deployed on multiple instances across one or more sites, referred to as an edge service. The edge service is typically associated with an ANYCAST IP address. With the emergence of Computing-Aware Traffic Steering (CATS) requirements, there is a growing need to consider both network and computing metrics when making traffic steering decisions. Traditional routing protocols lack the capability to convey compute-related information, necessitating extensions to existing protocols. This draft defines a mechanism to distribute service routes along with computing-related metadata using BGP FlowSpec. The service metadata, including compute resource status and performance metrics, can be collected by a central controller, processed, and then distributed to ingress routers using BGP FlowSpec extensions. This enables ingress routers to make path selections based not only on routing cost but also on the running environment and resource availability of edge services, thereby optimizing Quality of Experience (QoE). The mechanism is aligned with the CATS architecture and metric framework by allowing the advertised metadata to represent either selected original service metrics or an aggregated Level 2 (L2) metric. | |||||||||||||
| Galois Counter Mode with Strong Secure Tags (GCM-SST) | ||||||||||||||
|
This document defines Galois Counter Mode with Strong Secure Tags (GCM-SST), an Authenticated Encryption with Associated Data (AEAD) algorithm that addresses several weaknesses of GCM. GCM-SST can be used with any keystream generator, not only 128-bit block ciphers. Main differences from GCM are the introduction of a second authentication subkey H_2, per-nonce derivation of both H and H_2, and stricter usage limits. Together, these changes yield authentication tags with near-ideal forgery probabilities, including reforgeability resistance. All registered instances have an expected number of forgeries E(F) ≈ v / 2^t, a property that GCM is far from providing. GCM-SST is designed for security protocols with replay protection such as TLS, QUIC, SRTP, and PDCP, and provides hardware and software performance comparable to GCM. This document registers nine AEAD algorithm instances using AES and Rijndael-256 in counter mode, with tag lengths of 48, 96, and 112 bits. GCM-SST has been standardized by 3GPP for use with SNOW 5G, AES-256, and ZUC-256. | |||||||||||||
| Framework for Flow Aggregation in Scaling Deterministic Networking (DetNet) | ||||||||||||||
|
This document provides a framework and requirements for flow aggregation in scaling Deterministic Networking (DetNet) [I-D.ietf-detnet-scaling-requirements]. It describes aggregation scenarios, benefits, and challenges in scaling networks, and derives high-level requirements applicable across different DetNet data plane technologies. The framework also discusses flow aggregation enhancement considerations including classification, identification, coordination, admission control and resource allocation. As an illustrative example, it explores how these concepts could apply to 5GS systems acting as logical DetNet nodes. This document is informational and complementary to existing DetNet specifications. | |||||||||||||
| The Asynchronous Remote Key Generation (ARKG) algorithm | ||||||||||||||
|
Asynchronous Remote Key Generation (ARKG) is an abstract algorithm that enables delegation of asymmetric public key generation without giving access to the corresponding private keys. This capability enables a variety of applications: a user agent can generate pseudonymous public keys to prevent tracking; a message sender can generate ephemeral recipient public keys to enhance forward secrecy; two paired authentication devices can each have their own private keys while each can register public keys on behalf of the other. This document provides three main contributions: a specification of the generic ARKG algorithm using abstract primitives; a set of formulae for instantiating the abstract primitives using concrete primitives; and an initial set of fully specified concrete ARKG instances. We expect that additional instances will be defined in the future. | |||||||||||||
| Secure hybrid network monitoring - Problem statement | ||||||||||||||
|
This document presents a problem statement and gap analysis for ensuring and monitoring the security status of networks operating in complex environments, such as hybrid and multi-cloud systems. It identifies a missing capability: verifying the path and security properties of communications across multiple administrative domains while preserving each provider's confidentiality and local policy boundaries. The document also outlines, non-normatively, potential solution directions. | |||||||||||||
| Adaptive Routing Notification for Load-balancing | ||||||||||||||
|
In this document, adaptive routing is referred to as a technology that makes dynamic traffic forwarding decisions based on changes in traffic load and network topology, devices with adaptive routing capabilities can dynamically select the outport in the forwarding table based on the congestion condition of the outport or downstream link. This document focuses on the information carried in (Adaptive Routing Notification)ARN messages and how they are delivered and processed in the network. | |||||||||||||
| Commercial National Security Algorithm (CNSA) Suite 2.0 Profile for Certificates and Certificate Revocation Lists | ||||||||||||||
|
This document specifies a profile of X.509 v3 Certificates and X.509 v2 Certificate Revocation Lists for applications that use Commercial National Security Algorithm Suite published by the United States Government. The profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that employ such X.509 certificates. US National Security Systems are described in NIST Special Publication 800-59. It is also appropriate for all other US Government systems that process high-value information. This memo is not an IETF standard, and does not represent IETF community consensus. The profile is made publicly available for use by developers and operators of these and any other system deployments. This document obsoletes [RFC8603], the CNSA 1.0 guidance. | |||||||||||||
| ASPA-based AS_PATH Verification for BGP Export | ||||||||||||||
|
This document describes AS_PATH verification based on Autonomous System Provider Authorization (ASPA) for egress eBGP speakers. ASPA is a Resource Public Key Infrastructure (RPKI) object that allows an AS to register its transit provider ASes. Performing ASPA-based AS_PATH verification at egress can prevent inadvertent propagation of route leaks to external peers, check for local misconfigurations, and help detect potential ASPA registration errors. This approach complements ingress-side verification and BGP Roles/Only to Customer (OTC); it also provides operational assurance for partial deployment and for export-side configuration or registration problems. | |||||||||||||
| AI based Network Management Agent(NMA): Concepts and Architecture | ||||||||||||||
|
The evolution from Level 3 (assisted automation) to Level 4 (closed- loop autonomy) in Autonomous Networks (AN) introduces requirements for agentic capabilities, including intent-based reasoning, autonomous planning, and context-aware decision-making, and execution coordination, which transcend the static, rule-based logic of traditional network controllers. This document defines the concept of the Network Management Agent (NMA), a network management entity with autonomous task processing capabilities designed to bridge the gap between service intent and network operations. This document describes the role of NMA in network management and control architectures, and specifies how the NMA collaborates with existing network controllers to achieve Autonomous L4 without replacing or duplicating their functions. It further defines the reference architecture, deployment modes, and logical interfaces of the NMA, including Agent-to-User (A2U), Agent-to-Agent (A2A), Agent- to-Controller (A2C), and Agent-to-Network (A2N) interactions. | |||||||||||||
| A YANG Data Model for Performance Monitoring Streaming on Common Transport Equipment | ||||||||||||||
|
This document describes how the generic collection measurement YANG data model and its interval-capability companion model are applied to common transport equipment. It is informational. It defines a small YANG module of transport performance parameters, organizes those parameters into maintenance and QoS profiles, and gives end-to-end examples that show capability discovery followed by YANG-Push subscription, notification, and threshold reporting for a transport profile. | |||||||||||||
| Applying BGP-LS Segment Routing over IPv6(SRv6) Extensions to BGP-LS-SPF | ||||||||||||||
|
For network scenarios such as Massively Scaled Data Centers (MSDCs), BGP is extended for Link-State (LS) distribution and the Shortest Path First (SPF) algorithm based calculation. BGP Link State Shortest Path First (BGP-LS-SPF) Routing leverages the mechanisms of both BGP protocol and BGP-LS protocol extensions. Segment Routing over IPv6 (SRv6) provides a source routing mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SRv6 domain. In some networks, it may be useful to enable SRv6 based source routing mechanism together with BGP-LS-SPF. This document proposes to introduce the BGP Link-State (BGP-LS) extensions for SRv6 to the BGP-LS-SPF SAFI to enable SRv6 capabilities in BGP-LS-SPF. The usages and formats of these extensions are also provided in this document. | |||||||||||||
| Automatic Network Congestion Relief | ||||||||||||||
|
This document describes an automatic network congestion relief mechanism for congestion caused by sudden capacity reduction, such as fiber failures. The mechanism uses traffic modeling, real-time congestion monitoring, policy generation, policy propagation, traffic regulation, and policy reversion to redistribute selected traffic from a congested plane to a lightly loaded paired plane. The objective is to reduce manual intervention, shorten congestion mitigation time, and improve network resilience during failure conditions. | |||||||||||||
| Commercial National Security Algorithm (CNSA) Suite 2.0 Profile for Certificate Management over CMS | ||||||||||||||
|
This document specifies a profile of the Certificate Management over CMS (CMC) protocol for managing X.509 public key certificates in applications that use the Commercial National Security Algorithm (CNSA) Suite published by the United States Government. The profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that manage X.509 public key certificates over CMS. It is also appropriate for all other US Government systems that process high-value information. This memo is not an IETF standard, and does not represent IETF community consensus. The profile is made publicly available here for use by developers and operators of these and any other system deployments. This document obsoletes [RFC8756], the CNSA 1.0 guidance. | |||||||||||||
| 3GPP-IETF Standardization Collaboration | ||||||||||||||
|
The objective of the collaboration between 3GPP and IETF is securing timely development of technical specifications, and to facilitate maximum interoperability with existing fixed and mobile Internet systems, devices, and protocols. This document summarizes some high- level principles of cooperation and the coordination between both organizations while leaving out the detailed descriptions to be specified and maintained by the coordination function itself. | |||||||||||||
| Applicability of MCP for the Network Management | ||||||||||||||
|
The application of MCP in the network management field is meant to refactor network management operation and network capabilities as tools and provide more agile and extensible architecture to expose these AI integration capabilities. This document discusses the applicability of MCP to the network management plane in the IP network that utilizes IETF technologies. It explores MCP for network exposure, multiple MCP server discovery, communication between Network Elements or between the Network element and the Network Controller/Network Gateway. | |||||||||||||
| HTTP Events Query | ||||||||||||||
|
Events Query is a minimal protocol built on top of HTTP that allows user agents to receive event notifications directly from any resource of interest. It uses the QUERY method [RFC10008] to request (optionally) the current representation and subsequent event notifications within a single response. The Events Query Protocol (EQP) is predicated on the idea that the most intuitive source for event notifications is the resource itself. | |||||||||||||
| Applicability of A2A to the Network Management | ||||||||||||||
|
This document discusses the applicability of A2A protocol to the network management in the multi-domain heterogeneous network environment that utilizes IETF technologies. It explores operational aspect, key components, generic workflow and deployment scenarios. The impact of integrating A2A into the network management system is also discussed. | |||||||||||||
| The DNS Stamps Specification | ||||||||||||||
|
This document specifies DNS Stamps, a compact format that encodes the information needed to connect to DNS resolvers. DNS Stamps encode all necessary parameters including addresses, hostnames, cryptographic keys, and protocol-specific configuration into a single string using a standard URI format. The specification supports multiple secure DNS protocols including DNSCrypt, DNS-over-HTTPS (DoH), DNS-over-TLS (DoT), DNS-over-QUIC (DoQ), and Oblivious DoH. | |||||||||||||
| Secure Hybrid Network Monitoring - Path Characteristics Service | ||||||||||||||
|
"Secure hybrid network monitoring – Problem statement" [I-D.oiwa-secure-hybrid-network] identifies challenges in securing and monitoring networks deployed across hybrid and mixed cloud environments. This document introduces the Path Characteristics Service (PCS), a service that enables applications and operators to verify whether a given network path conforms to their declared requirements ("intent") regarding security, compliance, and operational properties. Unlike traditional network monitoring, PCS does not expose raw network state; instead, it evaluates the user's intent against the actual path characteristics and returns a conformance result (match or no-match). This intent matching approach allows multi-stakeholder environments to verify path properties without disclosing sensitive internal infrastructure details. This document describes an architecture and interfaces for PCS; it expresses recommended behaviors and constraints using the normative keywords of BCP 14, but does not specify a wire protocol or its encoding. | |||||||||||||
| Design of Christian's Congestion Control Code (C4) | ||||||||||||||
|
Christian's Congestion Control Code is a new congestion control algorithm designed to support Real-Time applications such as Media over QUIC. It is designed to drive towards low delays, with good support for the "application limited" behavior frequently found when using variable rate encoding, and with fast reaction to congestion to avoid the "priority inversion" happening when congestion control overestimates the available capacity. It pays special attention to the high jitter conditions encountered in Wi-Fi networks. The design emphasizes simplicity and avoids making too many assumption about the "model" of the network. The main control variables are the estimate of the data rate and of the maximum path delay in the absence of queues. | |||||||||||||
| Motivations and Problem Statement of Agentic AI for network management | ||||||||||||||
|
This document outlines the key objectives of introducing Agentic AI to the field of network management and highlights the fundamental issues with existing technologies that must be addressed to achieve these goals. It emphasizes the necessity for relevant groups within the IETF/IRTF and presents the core technological areas requiring standardization. The aim of Agentic AI is to facilitate a paradigm shift in which multiple autonomous AI agents collaborate to fully automate network operation, management and security. | |||||||||||||
| Age Verification Architecture | ||||||||||||||
|
This document describes solution-agnostic and technology-neutral schema for how various intermediaries can gate content and services based on age. The analysis of the architecture is done along two dimensions: the efficacy of permitting or restricting access based on age, and the privacy cost of doing so. The document concludes with recommendations as well as critical privacy, security and human rights considerations. | |||||||||||||
| Agent Gateway Intercommunication Framework | ||||||||||||||
|
This document defines the framework and requirements for intercommunication between Agent Gateways (AGw) in the Agent Internet (IoA) ecosystem. It specifies a hierarchical layered model, functional components, protocol requirements and deployment consideration for AGw interconnection. The framework aims to address data synchronization, protocol compatibility, and security challenges in cross-domain agent collaboration, enabling efficient and scalable communication for distributed intelligent agents. It is compatible with existing IoA reference architectures while specializing in cross-domain gateway interoperability. | |||||||||||||
| DNS-Native AI Agent Naming and Resolution | ||||||||||||||
|
This document specifies DNS-Native Agent Naming and Resolution (DN- ANR) for AI agents. DN-ANR uses domain names (FQDNs) as stable Agent Identifiers and resolves a selected Agent Identifier to verifiable endpoints and supported protocol/version information with a cryptographic integrity chain, with DNSSEC preferred. DN-ANR is a post-selection resolution profile. It does not define agent discovery, capability search, semantic matching, ranking, or routing decisions. Agent discovery, publication, or registry, including DNS-based mechanisms such as DNS-AID, may produce candidate Agent Identifiers; DN-ANR resolves and verifies the identifier selected by such mechanisms or by local policy. Within that scope, DN-ANR additionally defines DNS-based version distribution and deterministic version selection, canonicalized SVCB integrity cross- checking, and a signed HTTPS mirror for clients that cannot perform SVCB queries. While AI agents are the primary use case, the resolution and verification behavior defined here applies to any entity identified by an FQDN, such as services and workloads. | |||||||||||||
| Layer-3 Neighbor Discovery | ||||||||||||||
|
Data Centers where the topology is BGP-based need to discover neighbor IP addressing, IP Layer-3 BGP neighbors, etc. This Layer-3 Neighbor Discovery protocol identifies BGP neighbor candidates. | |||||||||||||
| L3ND Upper-Layer Protocol Configuration | ||||||||||||||
|
This document adds PDUs to the Layer-3 Neighbor Discovery protocol to communicate the parameters needed to exchange inter-device Upper Layer Protocol Configuration for upper-layer protocols such as the BGP family. | |||||||||||||
| Extensions to the YANG Data Model for L3VPN Service Delivery | ||||||||||||||
|
RFC8299 defines a YANG data model for L3VPN service delivery. This document defines a set of extensions that address the limitations of the L3VPN Service Model (L3SM). The extensions enable (1)dynamic network provisioning with temporary connectivity, (2) dynamic bandwidth adjustment, (3) integration of isolation in Slice Service Templates to enhance QoS provisioning, (4) performance monitoring for enriching service quality visibility, (5)quantum-safe encryption integrating both PQC and QKD. | |||||||||||||
| Attested Inference Receipt (AIR): A COSE/CWT Profile for Confidential AI Inference | ||||||||||||||
|
This document defines the Attested Inference Receipt (AIR), an application-layer COSE_Sign1 envelope carrying CWT claims profiled per the Entity Attestation Token (EAT) framework. An AIR receipt binds model identity, input/output hashes, attestation-linked metadata, and operational telemetry into a single signed artifact suitable for independent third-party verification of a confidential AI inference. An AIR receipt is Attester-signed Evidence, not an appraisal verdict: a RATS Verifier must appraise the referenced platform attestation before the receipt establishes TEE provenance. AIR v1 targets single-inference receipts emitted by workloads running inside hardware-isolated Trusted Execution Environments (TEEs). AIR is attestation-linked: it carries measurements and a hash reference to the platform attestation evidence associated with the inference, but it does not replace platform-specific attestation verification. This version defines AWS Nitro Enclaves and Intel TDX measurement profiles only, and assumes a single platform attestation document per receipt. Pipeline chaining, multi-inference receipts, composite attesters, multi-verifier orchestration, accelerator / GPU confidential-compute attestation integration, and extensibility mechanisms for additional claim or platform profiles are out of scope. | |||||||||||||
| Problem Statement for Network Resilience | ||||||||||||||
|
This document defines the problem space for network resilience. It identifies representative failure sources that expose limitations in current network architectures when facing complex, cascading, correlated, and unanticipated failures. It further analyzes cross- cutting resilience challenges and capability gaps across the pre- event, in-event, and post-event stages of the failure lifecycle, and derives a set of technical capabilities needed to improve network resilience. | |||||||||||||
| Preventing Key Reuse and Cross-Key Forgeries in Composite ML-DSA | ||||||||||||||
|
This document defines a small, backwards-compatible change to composite ML-DSA that cryptographically binds the signature to the specific composite public key. It does so by defining a Public-Key Context value (pkc) equal to a hash of the serialized composite public key, and by setting the composite context field to that value. This prevents key reuse and cross-key forgeries across different composite keys, while preserving the API of Composite ML-DSA. The construction introduces two helper procedures to compute pkc from either the composite private key or the composite public key. | |||||||||||||
| Low Overhead CMAF for Media over QUIC (LOCMAF) | ||||||||||||||
|
This document specifies LOCMAF (Low Overhead CMAF for Media over QUIC), a compact packaging for low-latency CMAF media carried end-to- end as MoQ Transport (MOQT) Object payloads, with per-object overhead comparable to the Low Overhead Container (LOC). LOCMAF carries the CMAF chunk head metadata from a single moof (movie fragment) as a small set of tagged fields, while leaving the sample data (mdat) untouched. Boxes that may surround the moof in a CMAF chunk — styp (segment type), prft (producer reference time), and any number of emsg (event message) boxes — are carried verbatim, each through a generic box element (a genBox). The first Object of each MOQT group carries a full reference; subsequent Objects in the same group carry only the differences. The receiver reconstructs CMAF chunks that are decode-equivalent to the sender input, including the encryption metadata required by CMAF DRM (Common Encryption) pipelines, and a canonical byte-identical reconstruction — independent of the encoder's representation choices — is defined for conformance testing. | |||||||||||||
| GRASP through routers: a Problem Statement | ||||||||||||||
|
This document analyzes challenges for using the GeneRic Autonomic Signaling Protocol (GRASP) in the context of deployment of services on machines (servers, Virtual Machines, etc) without the network elements, such as routers, needing any support for GRASP by themselves. It analyses issues regarding the discovery mechanism, including discovery across subnets and operation across administrative boundaries, and provides terminology and general considerations for the development of future extensions, profiles, and architectural refinements. | |||||||||||||
| Some MUD Extensions and Clarifications | ||||||||||||||
|
Manufacturer Usage Descriptions (MUD) provide a means to describe device network behavior. This memo clarifies some aspects that may improve both usability and interoperability. Some examples include how to handle IP-based access-lists, broadcasts and multicasts of various forms, and QoS. This memo updates RFC 8520. | |||||||||||||
| IPv6 Deployment Statistics and Analysis | ||||||||||||||
|
This document explains why existing observations of IPv6 deployment are often insufficient to identify the operational gaps and bottlenecks that limit IPv6 utilization and service quality. It describes the need for correlated analysis across different parts of the service path and discusses examples of statistical evidence that can support such analysis. | |||||||||||||
| A Lightweight Cross-Layer Simulation Framework for IP-Optical Network Digital Twins | ||||||||||||||
|
This document describes a lightweight cross-layer simulation framework for IP-optical Network Digital Twins. The framework correlates IP-layer logical topology, traffic-engineering state, Segment Routing policies, optical and transport resources, OTN resources, and physical shared-risk objects in a digital twin environment. The framework is intended to support what-if analysis for cross-layer failure propagation, soft degradation, protection-timer interaction, service-aware traffic shifting, shared-risk validation, and energy- aware operation. This document does not define a new routing protocol, optical control-plane protocol, BGP-LS extension, ACTN interface, or YANG data model. The framework is intended for planning, assurance, simulation, and analysis. Simulation outputs are not directly applied to production network elements. | |||||||||||||
| Filename: | ||||||||||||||
|
This document specifies Hierarchical Ingress Replication (HIR), a scalable multicast forwarding mechanism for BGP Multicast VPN (MVPN) services over hierarchical IP-MPLS transport networks. HIR introduces packet replication at hierarchical inline BGP Route Reflectors (RRs) located at Access, Pre-Aggregation, Aggregation, and Core transport layers. By combining control-plane route reflection with data-plane packet replication, HIR significantly reduces ingress router replication overhead, optimizes bandwidth utilization, minimizes multicast state, and improves scalability for large-scale multicast VPN deployments in service provider and 5G transport networks. | |||||||||||||
| A Framework for AI-Assisted Network Protocol Testing from Specifications | ||||||||||||||
|
Network protocol testing is essential for validating that implementations conform to their specifications. Traditional testing approaches rely heavily on manual effort or protocol-specific models that are expensive to build and difficult to reuse as specifications evolve and new protocols emerge. This document describes a framework for AI-assisted network protocol testing that decomposes the testing workflow into six stages: structured protocol representation, coverage scoping, test case generation, executable artifact generation, test execution, and feedback-based refinement. The framework emphasizes explicit stage boundaries and reviewable intermediate outputs, keeping the workflow auditable and traceable to the specification text. The document discusses the design motivations and trade-offs behind the framework, presents examples from routing protocol testing, and identifies operational considerations and open issues for applying the framework in test environments. | |||||||||||||
| IPv6 Path Performance Degradation in Dual-Stack Networks | ||||||||||||||
|
The document analyzes contributing factors across the content service layer and the network transport layer, and discusses why existing mechanisms such as RFC 6724 and Happy Eyeballs do not fully address performance failures that appear after connection establishment. This document is limited to problem analysis, scope clarification, and areas for further study. It does not define new network-to-host signaling mechanisms or require hosts to use network-provided information when making address-family or path selection decisions. | |||||||||||||
| Provenance Traceability Augmentation for the GREEN Power and Energy YANG Module | ||||||||||||||
|
This document defines a YANG module that augments the GREEN Power and Energy YANG Module [PowerAndEnergy] to record the result of provenance verification for each Energy Object. The augmentation builds on the COSE-based signing mechanism defined in [ProvenanceDraft]. For each Energy Object, it records whether the most recent provenance signature was valid, which key was used to sign it, and who is responsible for that key, whether the device itself, the network controller acting on its behalf, or an external authority such as a grid energy provider. This allows operators and auditors to verify not just that energy data is correct, but that it came from where it claims to have come from, and to understand the level of trust that applies to each source. | |||||||||||||
| JMD: A Text-Based Structured Data Format for LLM-Driven Infrastructure | ||||||||||||||
|
This document defines JMD (JSON Markdown), a text-based structured data format designed for use in LLM-driven infrastructure, including tool-calling pipelines, MCP (Model Context Protocol) servers, REST APIs consumed by LLM agents, and multi-agent workflows. JMD encodes the full JSON type system (RFC 8259) using a subset of Markdown syntax -- headings for hierarchy, key: value lines for object fields, bullet lists for array items, and blockquotes for multiline strings. The format is line-oriented and streamable: every completed line is an independent, parseable event. JMD documents are in bijection with JSON values, and the roundtrip JSON -> JMD -> JSON preserves the value. This document specifies the JMD grammar, the canonical parse result (envelope), the four document modes (data, query, schema, delete), the streaming event model, and the media type registration for application/jmd. | |||||||||||||
| Use cases and Requirement for Flow Control Collaboration Across DCNs and WAN | ||||||||||||||
|
The demand for lossless network transmission and the application of flow control mechanisms have expanded from DCNs (Data Center Networks) to WANs(Wide Area Networks). To mitigate PFC - related issues in WANs, the fine - grained flow control is proposed. This mechanism aims to achieve precise control at flow / tenant levels, limits flow control to specified paths and slices, and provides intelligent congestion backpressure. As current DCN already adopts PFC mechanisms, the fine-grained flow control in WANs needs to work with PFC in DCNs to achieve end-to-end flow control. This document describes the use cases and requirements for the collaboration of flow control mechanisms across DCNs and WANs. | |||||||||||||
| Gateway Mediation Layer for AI Agent Collaboration | ||||||||||||||
|
Cross-domain and policy-controlled agent collaboration can require mediation decisions that are not always suitable for an agent client or an agent server alone. A collaboration request may need to combine a stated goal, capability profiles, tenant or domain policy, trust evidence, disclosure limits, operational constraints, and handoff context before a concrete interaction mechanism is used. This document identifies gateway-side interaction mediation as a distinct interoperability gap in many AI Agent Gateway deployments. It does not claim that every agent collaboration requires a gateway. Rather, it explains why many deployments need a mediation point where request goals, capability profiles, policy, trust, and handoff constraints can be evaluated before interaction proceeds. The document describes a Gateway Mediation Layer as a decision- support and interface layer between application-level goals and concrete agent interaction mechanisms. It focuses on the role, inputs, outputs, and narrow set of interoperable artifacts that may require further work, such as Mediation Requests, Mediation Responses, Handoff Contexts, Failure Records, and Evidence References. It does not propose standardizing internal matching algorithms, domain ontologies, prompt engineering, or model-specific decision logic. | |||||||||||||
| SRv6 Service Function Chaining Deployment | ||||||||||||||
|
This document describes the deployment and operational experience of the SRv6 Service Function Chaining (SFC) architecture defined in [I-D.draft-watal-spring-srv6-sfc-sr-aware-functions] on an academic IPv6 backbone network. The deployed system integrates SRv6 forwarding, service function management, topology collection, path computation, and flow classification to enable dynamic provisioning of SFC services via a web-based management interface. This document summarizes the deployment architecture, operational workflow, experience, and lessons learned, and provides guidance for network operators deploying SRv6 SFC services. | |||||||||||||
| Security Evaluation Benchmark for AI Agents | ||||||||||||||
|
This document defines a security evaluation benchmark framework for AI agents. It is divided into two parts: evaluation metrics and evaluation methodology, comprising four first-level evaluation dimensions and 55 second-level metrics, as well as a comprehensive evaluation methodology system covering all scenarios, including static evaluation, dynamic evaluation, attack-defense evaluation, compliance evaluation, and quantitative evaluation. It aims to assess the risk profile of AI agents throughout their entire lifecycle, including perception risks, memory risks, decision-making risks, and execution risks. | |||||||||||||
| Bridging Remote Attestation with Secure Channel Protocol Proxies | ||||||||||||||
|
This document specifies a transport-layer mechanism to establish an end-to-end cryptographic channel across a cooperative secure channel protocol intermediary, such as a TLS-terminating proxy. The mechanism enables Remote Attestation Evidence to remain bound to the true end-to-end endpoints even when the initial secure channel handshake is mediated by an intermediary. It uses an ephemeral HPKE challenge exchange, intra-handshake Evidence delivery, and an attestation-bound key update to evict the intermediary from Layer 7 visibility before application data is exchanged. | |||||||||||||
| A YANG Data Model for Collection Measurement | ||||||||||||||
|
This document specifies a YANG data model for Collection Measurement based on the Performance Management (PM) Collection function requirements defined in ITU-T G.7710. The model processes raw performance data sampled at a network node and produces structured data that can be retrieved by clients via pull-based mechanisms or delivered via push-based mechanisms such as YANG-Push. This document does not define new performance metrics; the base metrics are those of the IPPM framework, and the model specifies the collection and exposure of the operationally important subset identified by ITU-T G.7710. | |||||||||||||
| A YANG Data Model for Collection Interval Capabilities | ||||||||||||||
|
This document defines a YANG data model, "ietf-pm-interval- capabilities", that enables a server to advertise which collection intervals it can support. A client reads this capability information before configuring performance measurements, so that it selects only sampling and collection intervals that the server can honour. The capabilities are advertised by augmenting the "ietf-system- capabilities" module defined in [RFC9196], so that a client discovers them at the same well-known location used for subscription and notification capabilities. The model imports the "profile-names" type from the companion collection measurement model defined in [I-D.yoon-ippm-collection-measure] and mirrors its profile-and- parameter structure, ensuring direct alignment between capability discovery and measurement configuration. The model does not define measurement data structures or any delivery mechanism; those are defined in the companion document. | |||||||||||||
| Live Reference Resolution for Autonomous Agent Beliefs | ||||||||||||||
|
A recurring class of autonomous-agent failure arises when an agent acts on a belief read from a cached, derived, or proxy copy that has silently diverged from the authority the belief claims to represent. This document describes a reference-resolution discipline for the working beliefs an agent reasons and acts from. Each belief is held as a reference to a single named lowest authority and is resolved live at the point of use, with verification. When the authority is unobservable or the resolved value is stale, the belief takes an explicit uncertainty state rather than a prior cached value; that state propagates to any belief derived from it, and an uncertain belief feeding a costly or irreversible act blocks or escalates rather than proceeding. Every resolution chain terminates in a single self-authorising root. The document is Informational. It records a discipline and a vocabulary; it does not define a wire protocol. | |||||||||||||
| BGP Flow Specification Redirect to Directly Connected IP Address | ||||||||||||||
|
A bit, D bit, is defined in Flow-spec Redirect-to-IPv4 Extended Community and Flow-spec Redirect-to-IPv6 Extended Community. This bit is used by BGP Flow Specification to indicate that the associated Flow Specification policy be set to an invalid state when the directly connected link associated with the redirect target address becomes unavailable. | |||||||||||||
| UnifiedBus over Ethernet (UBoE) | ||||||||||||||
|
This document specifies the UnifiedBus over Ethernet (UBoE) protocol, which enables seamless interconnection between native UnifiedBus (UB) domains and standard Ethernet/IP network for AI and HPC high- performance scenarios. It defines the UBoE packet encapsulation based on IPv4/IPv6 and UDP over Ethernet, including the invariant CRC (ICRC) integrity protection for end-to-end packet verification. This document further specifies the cross-domain packet conversion and header adaptation behaviors at UB2E switches, including bidirectional mapping rules for UB-specific network layer and IP network layer. | |||||||||||||
| Problem Statement for Observability,Intervention and Control (I&C) in Multi-Agent Autonomous Networks | ||||||||||||||
|
This document provides an overview of the issues associated with the deployment of the observability, intervention, and control of autonomous agent pipelines in large-scale heterogeneous network environments. The term "Intervention and Control" is used to describe a set of automated and human-initiated mechanisms that guarantee the capability to observe, constrain, correct, and terminate Autonomous agents at any point, for any reason, irrespective of their level of autonomy under which it operates, to ensure resilience, recovery, and operational continuity. The set of enabled observability, intervention and control reflects operator service offerings to ensure that autonomous operations can be stopped, or safely redirected when required and is designed in conjunction with agent to agent, agent to tools, agent to human interaction and service and network policy. This document also identifies several key areas that the Agent Observability, Intervention and Control group will investigate to guide its architectural and protocol work and associated documents. | |||||||||||||
| Agent Runtime Telemetry System | ||||||||||||||
|
Large language model (LLM)-driven agents are increasingly deployed in large-scale production environments, where multi-agent collaboration, chained tool invocation, and long-context reasoning have become standard execution patterns. However, existing distributed systems telemetry frameworks primarily focus on infrastructure-level telemetry, such as network traffic, host metrics, and service health, and provide limited visibility into internal agent reasoning and execution semantics.This results in several recurring challenges in production environments, including inconsistent metric definitions across platforms, lack of end-to-end execution traceability, difficulty in root cause analysis, and limited interoperability among heterogeneous telemetry systems. This document defines a unified capability framework for Agent Runtime Telemetry Systems. It standardizes two telemetry collection planes: Network-side collection at gateways and traffic ingress layers, and Agent-side instrumentation within the agent runtime environment. It further specifies structured telemetry models, cross-layer trace correlation mechanisms, runtime metrics, and anomaly detection and remediation workflows. The framework enables interoperable telemetry across heterogeneous agent systems and deployment environments. It supports unified telemetry ingestion, end-to-end execution trace reconstruction, behavioral telemetry, and closed-loop anomaly analysis, providing a standardized foundation for agent operations, reliability engineering, and compliance auditing. | |||||||||||||
| Network Measurement Problem Statement | ||||||||||||||
|
Modern network applications, ranging from artificial intelligence (AI) and machine learning (ML) training to large-scale cloud services, require adaptive and high-performance networks. Network measurement is fundamental to achieving observability, enabling traffic engineering (TE), load balancing, congestion control (CC), resource accounting, and fault diagnosis. However, existing network measurement techniques face significant challenges in accuracy, overhead, scalability, and adaptability, especially in distributed and high-speed environments. This document describes the problems and gaps in current network measurement approaches, including sketch- based measurement, in-band network telemetry (INT), sampling, and probing, with a focus on distributed system scenarios. | |||||||||||||
| OAuth Identity Assertion Trust Framework | ||||||||||||||
|
Issuer authentication alone does not prove an OAuth authorization server's authority over the subject namespace its identity assertions claim. A federated authorization server can mint an identity assertion naming any email domain; federation membership establishes that the server is a recognized member of an ecosystem, not that the server is entitled to assert about subjects in any particular namespace. Nothing in OAuth today lets a namespace owner declare which authorization servers are authorized to assert identities in its namespace. This document defines an Identity Assertion Trust Framework with two parts. First, an Authority Delegation Model: an abstract pattern (Authority Holder, Delegate, Delegation Artifact, Validator) with independent trust-evaluation categories, a cross-category combination rule, and a lookup-state taxonomy that profiles instantiate. Second, the Identity Assertion Issuer Trust Policy: a JSON policy document that a Resource Authorization Server publishes to declare which trust methods it requires of an Assertion Issuer, including issuer- authentication methods (such as OpenID Federation) and subject- namespace authorization methods defined by separate profiles. The Domain-Authorized Issuer Trust Method is defined separately as one subject-namespace authorization profile usable by this framework. | |||||||||||||
| OAuth Domain-Authorized Issuer Trust Method | ||||||||||||||
|
This document defines the Domain-Authorized Issuer (DAI) Trust Method: a subject_namespace_authorization Trust Method for the OAuth Identity Assertion Trust Framework in which the owner of a subject namespace (typically a DNS domain) publishes a policy listing the OAuth authorization servers it authorizes to assert identities in that namespace. The mechanism uses the DNS-based authority- publication pattern operators already deploy for CAA, MTA-STS, SPF, and DKIM. A Resource Authorization Server uses the published policy to verify that an identity assertion's issuer is authorized for the asserted subject namespace. The lookup defined by this document is verifier-side: given an identity assertion in hand, the Resource Authorization Server locates the Subject Authority's issuer authorization policy. Client-side discovery of which Assertion Issuer to use before an assertion exists is a separate use case and is deferred to future work. This document also defines the Issuer Authorization Policy wire format that the Trust Method consumes. The parent trust framework specification owns the generic Trust Policy document, Trust Method category structure, cross-category combination rule, and Subject Authority Determination concept. | |||||||||||||
| Encryption algorithms - Block cipher MKV | ||||||||||||||
|
This document specifies the MKV block cipher for use in cryptographic mechanisms supporting information security. The algorithm may be used to provide confidentiality of information during transmission, processing, and storage in information systems. About This Document This note is to be removed before publishing as an RFC. | |||||||||||||
| BGP Route Policy Pre-view and Intent Verification Using BGP Monitoring Protocol | ||||||||||||||
|
Deploying BGP route policies in live production networks carries significant operational risks, often resulting in unintended route leaks, suboptimal routing paths, or blackholes. This document proposes an extension to the BGP Monitoring Protocol (BMP) that enables a BGP speaker to pre-view and dry-run a candidate route policy within a localized control-plane sandbox. The resulting post- policy route changes (deltas) are streamed asynchronously to a centralized controller via a new BMP message type. This architecture allows the controller to verify policy alignment with network intents, subsequently triggering either an explicit commit or a rollback before any forwarding plane changes take effect. | |||||||||||||
| Updates to OAuth 2.0 Security Best Current Practice | ||||||||||||||
|
This document updates the set of best current security practices for OAuth 2.0 by extending the security advice given in RFC 6749, RFC 6750, and RFC 9700, to cover new threats that have been discovered since the former documents have been published. | |||||||||||||
| PCEP Operational Clarification | ||||||||||||||
|
This document clarifies certain operational behavior aspects of the Path Computation Element Communication Protocol (PCEP). The content of this document has been compiled based on several interop exercises. This document does not make any updates or revisions to any PCEP specifications, instead it provides additional information to aid in the interpretation of those documents. | |||||||||||||
| Evidence Encoding for Hardware Security Modules | ||||||||||||||
|
This document specifies a vendor-agnostic format for Evidence produced and verified within a PKIX context. The Evidence produced this way includes claims collected about a cryptographic module, such as a Hardware Security Module (HSM), and elements found within it such as cryptographic keys. One scenario envisaged is that the state information about the cryptographic module can be securely presented to a remote operator or auditor in a vendor-agnostic verifiable format. A more complex scenario would be to submit this Evidence to a Certification Authority to aid in determining whether the storage properties of this key meet the requirements of a given certificate profile. This specification also offers a format for requesting a cryptographic module to produce Evidence tailored for expected use. | |||||||||||||
| SRv6 Deployment Options | ||||||||||||||
|
When deciding to migrate a network from existing data-plane technologies (e.g. MPLS, SR-MPLS or overlay encapsulations such as VXLAN) to SRv6, common questions involve how to perform the migration, how to minimize impact to the existing network and what techniques are available to support a smooth transition. This document presents various deployment and migration options for networks evolving toward SRv6 from prior transport or overlay technologies. | |||||||||||||
| Profiles for Traffic Engineering (TE) Topology Data Model and Applicability to non-TE-centric Use Cases | ||||||||||||||
|
This document describes how profiles of the Topology YANG data model, defined in RFC8795, can be used to address applications in Traffic Engineering aware (TE-aware) deployments, irrespective of whether they are TE-centric or not. | |||||||||||||
| YANG Data Model for Topology Filter | ||||||||||||||
|
This document defines a YANG data model for the management of topology filters/filter-sets on network elements and controllers. | |||||||||||||
| In-Place Bandwidth Update for MPLS RSVP-TE LSPs | ||||||||||||||
|
This document describes the procedure for updating the bandwidth of an MPLS RSVP-TE Label Switched Path (LSP) tunnel in-place without employing make-before-break (MBB). | |||||||||||||
| An Architecture for IP in Deep Space | ||||||||||||||
|
The IP protocol stacks used on Earth's Internet are typically configured based on assumptions of short delays and mostly uninterrupted communications. This document describes an architecture of the IP protocol stack tailored for its use in deep space. It involves buffering IP packets in IP forwarders facing intermittent links and adjusting transport protocol configurations and application protocol timers. This architecture applies to the Moon, Mars, and general interplanetary networking. | |||||||||||||
| Transmission of SCHC-compressed packets over IEEE 802.15.4 networks | ||||||||||||||
|
A framework called Static Context Header Compression and fragmentation (SCHC) has been designed with the primary goal of supporting IPv6 over Low Power Wide Area Network (LPWAN) technologies [RFC8724]. One of the SCHC components is a header compression mechanism. If used properly, SCHC header compression allows a greater compression ratio than that achievable with traditional 6LoWPAN header compression [RFC6282]. For this reason, it may make sense to use SCHC header compression in some 6LoWPAN environments, including IEEE 802.15.4 networks. This document specifies how a SCHC-compressed packet can be carried over IEEE 802.15.4 networks. The document also enables the transmission of SCHC-compressed UDP/ CoAP headers over 6LoWPAN-compressed IPv6 packets. | |||||||||||||
| Dataplane Enhancement Taxonomy | ||||||||||||||
|
This draft is to facilitate the understanding of the data plane enhancement solutions, which are suggested currently or can be suggested in the future, for deterministic networking. This draft provides criteria for classifying data plane solutions. Examples of each category are listed, along with reasons where necessary. Strengths and limitations of the categories are described. Suitability of the solutions for various services of deterministic networking are also mentioned. Reference topologies for evaluation of the solutions are given as well. | |||||||||||||
| Latency Guarantee with Stateless Fair Queuing | ||||||||||||||
|
This document specifies the implementation details for the framework specified in ITU-T Y.3129 [Y.3129] and ITU-T Y.3148 [Y.3148]. The framework guarantees end-to-end (E2E) latency bounds to flows. The schedulers in core nodes do not need to maintain flow states. Instead, the entrance node of a flow marks an ideal service completion time according to a fluid model, called Finish Time (FT), of a packet in the packet header. The subsequent core nodes update the FT by adding a delay factor, which is a function of the flow and the nodes. The packets in the queue of the scheduler are served in the ascending order of FT. This mechanism is called the stateless fair queuing. The result is that flows are isolated from each other almost perfectly. The latency bound of a flow depends only on the flow's intrinsic parameters such as the maximum burst size and the service rate, except the link capacities and the maximum packet length among other flows sharing each output link with the flow. This document specifies the metadata, formats of metadata, the admission control procedure, and an approximation of stateless fair queuing implemented via a strict priority (SP) scheduler. | |||||||||||||
| Mobile User Plane Architecture for Distributed Mobility Management | ||||||||||||||
|
This document defines the Mobile User Plane (MUP) architecture for Distributed Mobility Management. The requirements for Distributed Mobility Management described in [RFC7333] can be satisfied by routing fashion. In MUP Architecture, session information between the entities of the mobile user plane is turned to routing information so that mobile user plane can be integrated into dataplane. MUP architecture is designed to be pluggable user plane part of existing mobile service architectures, enabled by auto-discovery for the use plane. Segment Routing provides network programmability for a scalable option with it. While MUP architecture itself is independent from a specific dataplane protocol, several dataplane options are available for the architecture. This document describes IPv6 dataplane in Segment Routing case (SRv6 MUP) due to the DMM requirement, and is suitable for mobile services which require a large IP address space. | |||||||||||||
| Requesting a Freshness Nonce for Attestation Evidence in Certificate Signing Requests | ||||||||||||||
|
When an end entity includes attestation statements in a Certificate Signing Request (CSR), the freshness of the conveyed Evidence often needs to be established. A common mechanism is a nonce that is obtained from a Relying Party or Verifier and included by the Attester in the Evidence. This document specifies how an end entity requests such an attestation freshness nonce from an RA/CA when using certificate lifecycle management protocols. It defines message formats and protocol bindings for the conveyance of nonce request and response messages in the Certificate Management Protocol (CMP), Enrollment over Secure Transport (EST), and Certificate Management over CMS (CMC), including optional type-specific information needed to produce fresh Evidence for inclusion in a CSR. | |||||||||||||
| OSPF YANG Model Augmentations for Additional Features - Release 1 | ||||||||||||||
|
This document defines YANG data modules that augment the IETF OSPF YANG model to support various OSPF extensions and features, including Traffic Engineering Extensions to OSPF Version 3 as defined in RFC 5329, OSPF Two-Part Metric as defined in RFC 8042, OSPF Graceful Link Shutdown as defined in RFC 8379, OSPF Link-Local Signaling (LLS) Extensions for Local Interface ID Advertisement as defined in RFC 8510, OSPF MSD as defined in RFC 8476, OSPF Application-Specific Link Attributes as defined in RFC 9492, and OSPF Flexible Algorithm as defined in RFC 9350. | |||||||||||||
| Responsive Use of the Mobile Ad Hoc Network (MANET) Routing Protocol OLSRv2 | ||||||||||||||
|
This specification describes an optional Topology Control (TC) message that can be sent by an OLSRv2 router. This is permitted, but not suggested, by the existing protocol, but is here recommended for use in some networks. The original motivation for this message came from considering the circumstances of a mostly stable network, in the most extreme case updated only by messages responding to the arrival and departure of routers, in which case the additional TC message would be not just recommended but required. While this extreme case is highly unlikely to be ever used, consideration of this additional message indicates that it could be useful in reducing the routing convergence time in any network in which messages are sent at lengthy intervals. Sending such a message is, although not previously suggested, permitted by OLSRv2 and thus implementations of OLSRv2 that do and do not send such messages are fully compatible. This specification updates RFC 7181 "The Optimized Link State Routing Protocol version 2 (OLSRv2)". | |||||||||||||
| More Instant Messaging Interoperability (MIMI) message content | ||||||||||||||
|
This document describes content semantics common in Instant Messaging (IM) systems and describes a profile suitable for instant messaging interoperability of messages end-to-end encrypted inside the MLS (Message Layer Security) Protocol. | |||||||||||||
| IETF Network Slice Service Mapping YANG Model | ||||||||||||||
|
This document provides a YANG data model to map IETF network slice service to Traffic Engineering (TE) models (e.g., the Virtual Network (VN) model or the TE Tunnel, etc). It also supports mapping to the VPN Network models and Network Resource Partition (NRP) models. These models are referred to as the IETF network slice service mapping model and are applicable generically for the seamless control and management of the IETF network slice service with underlying TE/ VPN support. The models are principally used for monitoring and diagnostics of the management systems to show how the IETF network slice service requests are mapped onto underlying network resources and TE/VPN models. | |||||||||||||
| SRv6 SFC Architecture with SR-aware Functions | ||||||||||||||
|
This document describes the architecture of Segment Routing over IPv6 (SRv6) Service Function Chaining (SFC) with SR-aware functions. This architecture provides the following benefits: * Comprehensive Management: a centralized controller for SFC, handling SR Policy, link-state, and network metrics. * Simplicity: no SFC proxies, which reduces the number of nodes and address resource consumption. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Source Packet Routing in Networking Working Group mailing list ([email protected]), which is archived at https://mailarchive.ietf.org/arch/browse/spring/. Source for this draft and an issue tracker can be found at https://github.com/watal. | |||||||||||||
| A Framework for AI-Assisted Network Protocol Testing from Specifications | ||||||||||||||
|
Network protocol testing is essential for validating that implementations conform to their specifications. Traditional testing approaches rely heavily on manual effort or protocol-specific models that are expensive to build and difficult to reuse as specifications evolve and new protocols emerge. This document describes a framework for AI-assisted network protocol testing that decomposes the testing workflow into six stages: structured protocol representation, coverage scoping, test case generation, executable artifact generation, test execution, and feedback-based refinement. The framework emphasizes explicit stage boundaries and reviewable intermediate outputs, keeping the workflow auditable and traceable to the specification text. The document discusses the design motivations and trade-offs behind the framework, presents examples from routing protocol testing, and identifies open research challenges. | |||||||||||||
| CoAP in Space | ||||||||||||||
|
This document provides guidance on using the Constrained Application Protocol (CoAP) in deep space environments. The document focuses on the approach whereby an IP protocol stack is used for end-to-end communication. | |||||||||||||
| Remote Attestation with Exported Authenticators | ||||||||||||||
|
This specification defines a method for two parties in a communication interaction to exchange Evidence and Attestation Results using exported authenticators, as defined in [RFC9261]. Additionally, it introduces the cmw_attestation extension, which allows attestation credentials to be included directly in the Certificate message sent during the Exported Authenticator-based post-handshake authentication. The approach supports both the passport and background check models from the RATS architecture while ensuring that attestation remains bound to the underlying communication channel. | |||||||||||||
| BGP RIB Fine-Grained Filtering Statistics Extensions for BGP Monitoring Protocol (BMP) | ||||||||||||||
|
The BGP Monitoring Protocol (BMP) defines mechanisms to monitor BGP running status and routing information bases (RIBs). [RFC9972] extended BMP statistics reporting by introducing advanced BGP RIB stat types. However, with the rapid deployment of path-level cryptographic security protocols (such as ASPA) and the complex interactions between control plane and hardware forwarding resources, network operators require granular, behavior-driven observability into why routes are discarded, invalidated, or restricted at both the ingress and egress boundaries. This document updates the registry established by [RFC7854] and extended by [RFC9972] by defining some fine-grained BGP RIB monitoring statistics types covering hardware resource exhaustion, next-hop resolution anomalies, structured route leaks ([RFC7908]), and ingress/egress ASPA verification states. Furthermore, it introduces a 4-bit control flag space within the Stat Type TLV to enable dynamic differential rate monitoring and proactive asynchronous trigger-driven telemetry. | |||||||||||||
| Use of FrodoKEM in the Cryptographic Message Syntax | ||||||||||||||
|
FrodoKEM is a quantum-resistant key encapsulation mechanism (KEM) based on the standard Learning With Errors (LWE) problem，standardized by ISO. FrodoKEM offers multiple parameter sets, with the recommended sets for general use including (e)FrodoKEM-976-AES and (e)FrodoKEM-976-SHAKE for security level 3, and (e)FrodoKEM-1344-AES and (e)FrodoKEM-1344-SHAKE for security level 5. This document specifies the conventions for using FrodoKEM in the Cryptographic Message Syntax (CMS), using the KEMRecipientInfo structure defined in "Use of Key Encapsulation Mechanism (KEM) Algorithms in the Cryptographic Message Syntax (CMS)" [RFC9629]. | |||||||||||||
| Taxonomy for Agentic AI Use Cases | ||||||||||||||
|
Agentic AI systems rely on large language models to plan and execute multi-step tasks by interacting with tools and collaborating with other agents, creating new demands on Internet protocols for interoperability, scalability, and safe operation across administrative domains. This document defines a taxonomy for classifying Agentic AI use cases according to the functional protocol domains they exercise, such as transport, security and trust, discovery, identity, coordination and orchestration, data and context management, and operations and management. The taxonomy is intended to give the IETF a structured vocabulary for describing and comparing use cases, for identifying which protocol areas require standardization attention, and for mapping use case requirements to relevant IETF working groups. | |||||||||||||
| Requirements and Gap Analysis of Multicast in AI Data Centers | ||||||||||||||
|
Multicast has the potential to be applied in Artificial Intelligence Data Centers (AIDCs) to improve the efficiency of point-to-multipoint data transmission during large language model training and inference. This document identifies key requirements of multicast in AIDCs, and analyzes the gaps between these requirements and the capabilities of existing multicast technologies. | |||||||||||||
| Merchant Identity Assertions for Autonomous Commerce | ||||||||||||||
|
Existing work helps a relying party determine whether an automated client is authorized to initiate a transaction. This document addresses the complementary problem: how that client can obtain a verifiable identity statement about the merchant that will receive the resulting payment, before the transaction is completed. This document defines a Merchant Identity Assertion (MIA): a signed JSON document binding a legal entity claim to a domain name. It specifies the claims schema, the proof envelope, key discovery via a JSON Web Key Set at a well-known URI, third-party issuance with explicit authorization, signing and verification procedures, validity and revocation semantics, and an optional signed Evaluation Result Token that records the outcome of a verification check as a portable audit artifact. This document is informational. It defines a discovery and verification mechanism only. It does not define trust scoring, merchant ranking, payment authorization, or agent identity. It complements existing agent identity and payment authorization protocols without modifying them. | |||||||||||||
| Extended Diagnostic Notation (EDN) Use with Transport Layer Security (TLS) Presentation Language (PL) Objects | ||||||||||||||
|
Extended Diagnostic Notation was designed as a superset of JSON to represent CBOR instance documents in human-readable format. This document describes how it can be used to represent instances encoded using the TLS Presentation Language. | |||||||||||||
| Enhanced Dual Stack: Automatic IPv6/IPv4 Selection Based on Performance | ||||||||||||||
|
This document describes Enhanced Dual Stack (EDS), a host-side framework intended to reduce the operational risk and workload of IPv6 deployment. Today, many applications select IPv6 or IPv4 using static address- selection rules. These rules provide a useful baseline, but they are not live measurements of current reachability or performance. If IPv6 is selected when it is broken or degraded, users may experience failures or delays. This creates a need for extensive upfront IPv6 validation before deployment. Happy Eyeballs (HE) reduces this risk for applications that implement it, but it does not automatically help existing applications that continue to use traditional APIs such as getaddrinfo(), socket(), and connect(). EDS aims to make IPv6/IPv4 selection performance-informed for both new and existing applications. It does this through three enhancements: | |||||||||||||
| HTTP Header Fields for Proxying DNS SVCB Information | ||||||||||||||
|
When HTTP clients use the CONNECT method or UDP proxying (CONNECT- UDP) to reach target servers through a proxy, the proxy performs DNS resolution on behalf of the client. This prevents the client from accessing Service Binding (SVCB and HTTPS) DNS records that carry service configuration such as supported protocols and Encrypted Client Hello keys. This document defines HTTP header fields that enable the proxy to relay SVCB information to the client, and introduces a conditional early closure mechanism that allows the client to coordinate with the proxy to abort a connection when specific SVCB parameters are present, so that the client can retry with a different connection strategy. | |||||||||||||
| OAuth Protected Authorization | ||||||||||||||
|
This document defines browser support for protecting OAuth 2.0 authorization requests and authorization responses during redirect- based authorization flows. A single Structured Field header field, OAuth-Authorization, is set by the OAuth client in the redirect response that sends the browser to the authorization server, and by the authorization server in the redirect response that returns the browser to the OAuth client. In both cases the browser augments the header with the attested origin of the redirecting party and delivers it to the redirect destination. The mechanism provides security for the authorization request: the authorization server receives a browser-attested, tamper-evident statement of which origin initiated the request. The mechanism provides security and privacy for the authorization response: the authorization code is delivered in the browser-protected header instead of the redirect URI, and never appears in a URL, eliminating its exposure through browser history, server logs, Referer headers, analytics systems, and URL sharing. The header is generated, validated, and delivered by the browser, and is inaccessible to scripts, service workers, and browser extensions. Existing OAuth deployments continue to function unchanged; the protections activate only when the OAuth client, browser, and authorization server all support them. | |||||||||||||
| SDLP Transformation Model | ||||||||||||||
|
The Secured Digital Lifecycle Protocol (SDLP) defines a unified framework for representing, identifying, and tracking digital objects across their entire lifecycle. This document specifies the SDLP transformation model, which describes how digital objects change, evolve, or produce descendants through normative and verifiable processes. A transformation is any operation that produces a new digital object from an existing one. This document defines the transformation model, the required identity and lineage extensions, the invariants that must be preserved, and the logging requirements needed to ensure integrity, accountability, and tamper-evidence. These rules apply uniformly across all SDLP object types and lifecycle states. This specification is a core component of the SDLP architecture and is intended to be used alongside the SDLP Overview, Identity, Object Format, Lineage, Lifecycle, and Security Architecture documents. | |||||||||||||
| CoAP Diagnostic Message Notation | ||||||||||||||
|
This document defines a text notation for representing Constrained Application Protocol (CoAP) request/response exchanges in Internet- Drafts and RFCs. The notation balances human readability with mechanical validation: a reader can follow an exchange at a glance, and tooling can be built to parse the message structure and check each payload against its declared content format. The notation is application-layer by default, with message-layer detail added only where an example depends on it. It is a recommended convention for use in documents and with authoring tools such as kramdown-rfc, not a conformance target; it does not change CoAP or any on-the-wire encoding. | |||||||||||||
| Secure Evidence and Attestation Transport (SEAT) Architecture | ||||||||||||||
|
This document defines an architectural framework for composing Remote ATtestation procedureS (RATS) with Secure Evidence and Attestation Transport (SEAT). The document establishes normalized terminology for SEAT, aligns RATS roles to transport endpoints, outlines topological patterns for attestation delivery timing, characterizes the abstract cryptographic pattern by which Evidence is bound to a given transport connection. | |||||||||||||
| OAuth Actor Receipts for Delegation Provenance | ||||||||||||||
|
This document defines OAuth Actor Receipts, an optional companion provenance profile for delegated OAuth tokens that conform to the OAuth Actor Profile for Delegation. It introduces the actor_receipts claim, a signed per-hop receipt chain that records which issuer added each visible actor hop, optionally preserves the historical top-level cnf value associated with that hop subject to deployment disclosure policy, and links receipts together so recipients can validate prior- hop provenance without relying solely on the current outer token issuer. This document also defines metadata and introspection parameters for advertising and consuming actor-receipt support. | |||||||||||||
| OAuth Actor-Signed Hop Proofs | ||||||||||||||
|
This document defines OAuth Actor-Signed Hop Proofs, an optional companion profile for delegated OAuth tokens that conform to the OAuth Actor Profile for Delegation. It introduces the actor_proofs claim, a signed per-hop proof chain in which the actor added at each visible hop signs its own participation and the target binding it authorized for that hop. Proofs are linked into a hash chain, are validated against actor verification keys resolved through pre- established trust, and optionally cross-reference sibling actor receipts. This document also defines a token request parameter for conveying proofs at issuance, and metadata and introspection parameters for advertising and consuming actor-proof support. | |||||||||||||
| Framework,Use Cases and Requirements for AI Agent Protocols | ||||||||||||||
|
AI Agents are software applications that utilize Large Language Models (LLM)s to interact with humans (or other AI Agents) for purposes of performing tasks. AI Agents can make use of resources - including APIs and documents - to perform those tasks, and are capable of reasoning about which resources to use. To facilitate AI agent operation, AI agents need to communicate with users, and then interact with other resources over the Internet, including APIs and other AI agents. This document describes a framework for AI Agent communications on the Internet, identifying the various protocols that come into play. It introduces use cases that motivate features and functions that need to be present in those protocols. It also provides a brief survey of existing work in standardizing AI agent protocols, including the Model Context Protocol (MCP), the Agent to Agent Protocol (A2A) and the Agntcy Framework, and describes how those works fit into this framework. The primary objective of this document is to set the stage for possible standards activity at the IETF in this space. | |||||||||||||
| Binding Per-Action Authorization and Memory Provenance into Agent Action Capsules | ||||||||||||||
|
The Agent Action Capsule (AAC) profile (draft-mih-scitt-agent-action- capsule) records what an autonomous agent actually did -- executed, blocked, denied, errored, or timed out -- with a structural binding that prevents an attempt from being presented as a completion. AAC deliberately does not define the authority that permitted an action; it carries that authority as an opaque reference. Two companion profiles supply what that reference can point to: a per-action authorization profile (draft-rampalli-aiagent-authz-hmac) records that an action was permitted (the "may"), and a memory-provenance profile (draft-rampalli-aiagent-memory-provenance) records the source and trust state of the belief on which the agent acted (the "why- believed"). This document specifies how the latter two are bound into an AAC Capsule. It defines (a) what the AAC "disposition.authority" reference MAY resolve to, (b) a namespaced, payload-only extension carrying an authorization-token reference, a memory chain root, and a quarantine attestation, and (c) an OPTIONAL divergence-class value, drawn from the per-action profile, that explains a non-executing AAC verdict. The binding uses only mechanisms AAC already provides -- the opaque authority reference and the payload-extension namespacing convention -- and changes neither AAC's closed protected-header claim set nor its Class 1 verification. The result is a single verifiable record that answers "may," "did," and "why-believed" together. | |||||||||||||
| Protected Orchestrated Overlay Link (POOL): The Only Place Where Cowboys Can Water Their Horses | ||||||||||||||
|
This document describes the Protected Orchestrated Overlay Link (POOL), an experimental secure transport protocol. POOL provides mandatory mutual authentication, always-on authenticated encryption with no plaintext mode, a stateless handshake resistant to resource exhaustion attacks, cryptographically unpredictable sequence numbers, self-describing 256-bit addresses, active path MTU discovery, per- flow telemetry, atomic configuration changes with automatic rollback, and an append-only hash-chained change journal. POOL operates either as an overlay above TCP (over IPv4 or IPv6) or directly over IP using experimental protocol number 253; the raw-IP transport is specified for IPv4 only in this document. | |||||||||||||
| BFD Considerations for Redundant Control Planes | ||||||||||||||
|
In systems with redundant control plane processors, Bidirectional Forwarding Detection (BFD) sessions are typically managed by a single active processor. When that processor fails and a standby takes over, BFD sessions may be interrupted long enough for remote peers to declare failure, even though the forwarding plane remains operational. This document describes requirements and operational considerations for preserving BFD sessions across control plane switchover events. It discusses how BFD session state can be maintained on a standby processor and how BFD processing can be resumed by the standby within the BFD Detection Time, without requiring cooperation from or signaling to remote BFD peers. | |||||||||||||
| KV Cache Distribution for Distributed LLM Inference: Use Case and Requirements | ||||||||||||||
|
In large language model (LLM) inference, the key-value (KV) cache holds the attention state computed from previously processed tokens. Reusing cached state across requests avoids repeated prefill computation and reduces time-to-first-token. In distributed inference deployments, the KV cache becomes a network-distributed resource: the effectiveness of steering a request to a service instance depends not only on computing and network metrics but also on whether reusable cached state is available at or near that instance. This document describes the KV cache distribution use case for Computing-Aware Traffic Steering (CATS), identifies the gaps relative to the existing CATS framework and metrics, and states requirements for cache-state metric exposure and for the distribution and synchronization of cached content across multiple cache tiers. | |||||||||||||
| Coordinated Packet Loss Recovery and Congestion Control for High-Throughput WAN Transmission | ||||||||||||||
|
This document defines a coordinated mechanism between packet loss recovery (forward error correction) and congestion control for high- throughput WAN transmission. In high bandwidth-delay product (BDP) networks, loss recovery operations introduce additional processing delay at the receiver, which distorts the congestion controller's perception of network conditions. This mechanism addresses the problem by dynamically adjusting the ACK Delay field in acknowledgment packets to reflect loss recovery processing overhead, enabling the congestion control algorithm to accurately distinguish true network delay from recovery processing delay. The mechanism is applicable to QUIC, TCP, and RDMA transport protocols, and supports host-side, network-side, and coordinated deployment modes. | |||||||||||||
| Common Procedures for Encapsulating IOAM Data Fields in Transport Protocols | ||||||||||||||
|
In Situ Operations, Administration, and Maintenance (IOAM) enables on-path telemetry by inserting operational metadata into data packets as they traverse a network path. IOAM Data-Fields, as defined in RFC 9197, are designed to be independent of the encapsulating transport protocol. However, the procedures for inserting, updating, and removing IOAM Data-Fields are currently specified separately for each transport protocol (e.g., IPv6, NSH, GRE, Geneve), leading to redundant specification effort and inconsistent implementation behavior. This document defines a set of common encapsulation procedures for IOAM Data-Fields that are applicable across multiple transport protocols. The insertion point for IOAM Data-Fields is expressed as a configurable byte offset from a well-defined reference position in the encapsulating header, enabling a uniform insertion procedure that does not require protocol-specific parsing logic. The document specifies the general steps for identifying the insertion point, validating transport-layer constraints, performing the insertion of IOAM Option-Types, and updating affected header fields to maintain protocol compliance. | |||||||||||||
| Multi-Point Telemetry Correlation for Network Measurement | ||||||||||||||
|
Network measurement and telemetry systems that collect data at multiple points along a path or across multiple targets require a means to correlate the collected data. When each collection point independently selects which packets to observe, the resulting data sets may not overlap, preventing per-packet correlation of measurements across points. This document specifies how source-directed selection -- where a single node determines which packets are subject to measurement and signals this to other nodes -- achieves correlated data collection across multiple points. Two applications are described: IOAM Direct Export for in-band network telemetry, and PTP Sequence ID range assignment for multi-slave time synchronization. | |||||||||||||
| A STAMP Extension for Carrying Bidirectional Forwarding Detection Control Messages | ||||||||||||||
|
Network operators frequently run both Bidirectional Forwarding Detection (BFD) for rapid fault detection and an active measurement protocol such as STAMP for delay and loss measurement between the same pair of nodes, resulting in two parallel packet streams with overlapping timing requirements. This document defines an optional STAMP TLV that carries a BFD Control message within STAMP test packets, using the extension format of RFC 8972. A single test packet stream can then drive both the BFD state machine and STAMP performance measurement. The BFD protocol itself is unchanged. | |||||||||||||
| Procedures for ECMP-Aware Performance Measurement with STAMP | ||||||||||||||
|
This document specifies procedures for configuring Simple Two-Way Active Measurement Protocol (STAMP) sessions so that test packets traverse the same ECMP or LAG forwarding path as a specified production flow. In networks that use hash-based load distribution, the forwarding path depends on a hash over packet header fields. Standard STAMP test packets carry session-specific addresses and ports that differ from production traffic, often selecting a different forwarding path and yielding measurements that do not represent the actual service quality of the production flow. The procedures in this document specify how the Session-Sender populates test packet headers with values matching a designated production flow. The Session-Reflector identifies test packets by validating the STAMP payload structure. No changes to the STAMP packet formats defined in RFC 8762 are required. | |||||||||||||
| Communication Optimization for MoE Expert Parallelism in Distributed Training | ||||||||||||||
|
This document describes a communication optimization mechanism for Mixture of Experts (MoE) Expert Parallelism (EP) in distributed training environments. It defines two core mechanisms: (1) an adaptive communication mode selection that dynamically chooses between Data-Centric and Expert-Centric All-to-All communication patterns based on a comparison of expert parameter size versus token data size, minimizing cross-node communication volume; (2) a priority-based co-scheduling strategy for All-to-All and AllReduce collective communications, combined with chunked transmission and in- network aggregation acceleration, to eliminate bandwidth contention and reduce overall training latency. | |||||||||||||
| Coordinated CCM Interval Modification Procedures | ||||||||||||||
|
In IEEE 802.1ag Connectivity Fault Management (CFM), the Continuity Check Message (CCM) interval is a static parameter that must match on both peer Maintenance End Points (MEPs). Changing the interval at runtime on one MEP without simultaneously updating the peer causes a Loss of Continuity (LOC) defect and may trigger protection switching. Because the CFM PDU formats and OpCode space are governed by IEEE 802.1, this document does not modify the protocol; instead, it specifies a coordinated management-plane procedure that transitions both MEPs to a new CCM interval without raising spurious defects or triggering protection switching, together with failure handling and rollback behavior. The procedure can be operated through existing configuration models such as the connection-oriented OAM YANG model. | |||||||||||||
| Stateful Control Plane Policing | ||||||||||||||
|
Control Plane Policing (CoPP), as described in RFC 6192, classifies control-plane-destined traffic using static packet header fields. This static classification cannot distinguish legitimate protocol traffic from attack traffic that matches the same header-based rules. This document specifies Stateful CoPP, an operational practice in which the router's runtime protocol state -- including configured peer identities, session state, and expected ingress interfaces -- is incorporated into CoPP classification. Stateful CoPP allows confirmed legitimate traffic to receive preferential access to control plane CPU resources under attack conditions. | |||||||||||||
| Fine-Grained QoS Optimization for QUIC Based on Connection ID Priority Mapping | ||||||||||||||
|
This document defines a fine-grained, dynamically adaptive QoS mechanism for QUIC transport. The mechanism encodes a priority mapping table index in the QUIC Destination Connection ID (DCID), enabling host NICs or user gateways to translate QUIC-layer service priority information into network-layer QoS mechanisms (DSCP/ToS per RFC 2474) and traffic engineering policies (SRv6 TE, MPLS TE, etc.) for end-to-end QoS enforcement. Stream IDs carry endpoint priority information for local scheduling. The mechanism supports host-side, network-side, and coordinated deployment modes with no intrusion into the host protocol stack. | |||||||||||||
| Transport Considerations for Large-Scale Distributed Inference Networks | ||||||||||||||
|
Large-scale distributed inference systems generate traffic patterns that differ from both traditional data center workloads and distributed training workloads. Disaggregated prefill/decode serving transfers key-value cache state between server pools, and expert- parallel architectures generate all-to-all traffic among expert groups. These flows are typically carried over a small number of RDMA connections, producing low-entropy traffic that is prone to uneven link utilization under Equal-Cost Multipath (ECMP) forwarding. This document specifies transport considerations for such networks, covering path load awareness, path steering through ECMP entropy variation, ordering tolerance at the receiver, and differentiated reliability for data with different loss sensitivity. The discussion builds on existing IETF building blocks; this document does not define new protocol elements. | |||||||||||||
| Multipath for EVPN Ethernet Auto-Discovery Routes | ||||||||||||||
|
In EVPN multi-homing deployments, multiple PE devices attached to the same Ethernet Segment each originate Ethernet Auto-Discovery (EAD) routes. Standard BGP best-path selection retains only one route per NLRI key, which can suppress reachability information needed for EVPN aliasing, fast convergence, and split-horizon filtering. This document specifies that BGP speakers MUST treat EAD routes as multipath and MUST advertise and install all valid EAD routes for a given Ethernet Segment, rather than selecting a single best path. | |||||||||||||
| OAuth 2.0 AI Agent Instance Profile | ||||||||||||||
|
This specification profiles the OAuth 2.0 Client Instance Assertion for AI agent deployments, where a single OAuth client identifier represents an agent platform running many concurrent agent instances. It defines claims that convey an attested agent instance identifier and agent provenance (platform, model, runtime environment) from an agent attester to the authorization server, rules for surfacing that identity in issued access tokens, and delegation-chain semantics for agents that spawn sub-agents. The claims are carrier-independent: they may be conveyed in a Client Instance Assertion or in a Client Attestation defined by OAuth 2.0 Attestation-Based Client Authentication. | |||||||||||||
| Problem Statement and Operational Considerations for QKD-Assisted SRv6 Private Line Services | ||||||||||||||
|
SRv6 is used by operators to provide programmable and traffic- engineered IP private line services. Such services are often deployed for customers with strict requirements on service isolation, predictable forwarding, and communication security. Quantum Key Distribution (QKD) networks can provide symmetric key material to authorized applications or security functions. When QKD- generated keys are used together with SRv6-based private line services, operators need to coordinate service provisioning, SRv6 policy state, endpoint security functions, and QKD key availability. This document describes the problem space and operational considerations for QKD-assisted SRv6 private line services. It does not define new SRv6 data-plane behavior, new SRv6 Segment Identifier semantics, a new QKD protocol, or a new cryptographic algorithm. | |||||||||||||
| PCEP extensions for Distribution of Link-State and TE Information | ||||||||||||||
|
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. | |||||||||||||
| TCP ACK Rate Request Option | ||||||||||||||
|
TCP Delayed Acknowledgments (ACKs) is a widely deployed mechanism that allows reducing protocol overhead in many scenarios. However, Delayed ACKs may also contribute to suboptimal performance. When a relatively large congestion window (cwnd) can be used, less frequent ACKs may be desirable. On the other hand, in relatively small cwnd scenarios, eliciting an immediate ACK may avoid unnecessary delays that may be incurred by the Delayed ACKs mechanism. This document specifies the TCP ACK Rate Request (TARR) option. This option allows a sender to request the ACK rate to be used by a receiver, and it also allows to request immediate ACKs from a receiver. | |||||||||||||
| Traffic Engineering (TE) and Service Mapping YANG Data Model | ||||||||||||||
|
This document provides a YANG data model to map customer service models (e.g., L3VPN Service Delivery model) to Traffic Engineering (TE) models (e.g., the TE Tunnel or the Virtual Network (VN) model). These models are referred to as the TE Service Mapping Model and are applicable generically to the operator's need for seamless control and management of their VPN services with underlying TE support. The models are principally used for monitoring and diagnostics of the management systems to show how the service requests are mapped onto underlying network resources and TE models. | |||||||||||||
| Extended Key Update for Transport Layer Security (TLS) 1.3 | ||||||||||||||
|
TLS 1.3 ensures forward secrecy by performing an ephemeral Diffie- Hellman key exchange during the initial handshake, protecting past communications even if a party's long-term keys (typically a private key with a corresponding certificate) are later compromised. While the built-in KeyUpdate mechanism allows application traffic keys to be refreshed during a session, it does not incorporate fresh entropy from a new key exchange and therefore does not provide post- compromise security. This limitation can pose a security risk in long-lived sessions, such as those found in industrial IoT or telecommunications environments. To address this, this specification defines an extended key update mechanism that performs a fresh execution of the key exchange negotiated during the initial handshake within an active session, thereby ensuring post-compromise security. By forcing attackers to exfiltrate new key material repeatedly, this approach mitigates the risks associated with static key compromise. Regular renewal of session keys helps contain the impact of such compromises. The extension is applicable to both TLS 1.3 and DTLS 1.3. | |||||||||||||
| Post-Quantum Cryptography Recommendations for TLS-based Applications | ||||||||||||||
|
Post-quantum cryptography presents new challenges for device manufacturers, application developers, and service providers. This document highlights the unique characteristics of applications and offers best practices for implementing quantum-ready usage profiles in applications that use TLS and supporting protocols such as DNS. | |||||||||||||
| A YANG Data Model for Network Tester Management | ||||||||||||||
|
This document specifies a YANG data model for use in network interconnect testing setups that contain instances of traffic generator and traffic analyzer. | |||||||||||||
| JSContact Cryptographic Key Extensions | ||||||||||||||
|
Extensions to the JSContact data model for contact card data are defined to improve support for describing cryptographic credentials to be used with applications and services by specifying which credential is used for which online service. This allows a contact application to identify the specific credential to be used with an application without the need for the contact application to understand the syntax or semantics of the credential used. An additional extension allows a contact to specify one of more mechanisms for obtaining updates to itself with optional verification under specified signature keys. The mechanisms used are outside the scope of this document. These features in combination provide a basis for establishing and maintaining peer-to-peer trust. | |||||||||||||
| A YANG data model to manage configurable DWDM optical interfaces | ||||||||||||||
|
This document defines a YANG model related to the Optical Transceiver parameters characterising coherent 100G and above interfaces. 100G and above Transceivers support coherent modulation, multiple modulation formats, multiple Forward Error Correction (FEC) codes including some not yet specified (or in phase of specification by) ITU-T G.698.2 or any other ITU-T recommendation. Use cases are described in RFC7698. The YANG model defined in this document can be used for Optical Parameters monitoring and/or configuration of Dense Wavelength Division Multiplexing (DWDM) interfaces. The use of this model does not guarantee interworking of DWDM transceivers. Optical path feasibility and interoperability has to be determined by tools and algorithms outside the scope of this document. The purpose of this model is to program interface parameters to consistently configure the mode of operation of transceivers. | |||||||||||||
| Kemeleon Encodings | ||||||||||||||
|
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. | |||||||||||||
| Domain Connect Protocol - DNS provisioning between Services and DNS Providers | ||||||||||||||
|
This document provides specification of the Domain Connect Protocol that was built to support DNS configuration provisioning between Service Providers (hosting, social, email, hardware, etc.) and DNS Providers. | |||||||||||||
| The Role of the Internet Research Task Force (IRTF) | ||||||||||||||
|
This memo discusses the role of the Internet Research Task Force (IRTF), considering its research groups, community, and the various workshops, prizes, and other activities it supports. The relationship of the IRTF to the IETF is also considered. This memo is a product of the Internet Research Steering Group (IRSG). It is not an IETF product and is not a standard. | |||||||||||||
| YANG Schema Comparison | ||||||||||||||
|
This document specifies an algorithm for comparing two revisions of a YANG schema to determine the scope of changes and produce a list of the changes between the revisions. The output of the algorithm can be used to help select an appropriate revision-label or YANG semantic version number for a new revision. Included is also a YANG module describing the possible output of this algorithm. | |||||||||||||
| Definition of new tags for relations between RFCs | ||||||||||||||
|
An RFC can include a tag called "Updates" which can be used to link a new RFC to an existing RFC. On publication of such an RFC, the existing RFC will include an additional metadata tag called "Updated by" which provides a link to the new RFC. However, this tag pair is not well-defined and therefore it is currently used for multiple different purposes, which leads to confusion about the actual meaning of this tag and inconsistency in its use. This document recommends the discontinuation of the use of the updates/updated by tag pair, and instead proposes three new tag pairs that have well-defined meanings and use cases. | |||||||||||||
| Mechanism to Control Jitter Caused by Ingress Shaping | ||||||||||||||
|
This document presents a noble mechanism to eliminate jitter caused by shaping delay on the network entrance node. It needs to be used in combination with a queueing mechanism that provides low jitter for the DetNet path, and ultimately provides a low jitter guarantee for the DetNet flow. | |||||||||||||
| Amendments to Stateful PCE Communication Protocol (PCEP) | ||||||||||||||
|
This document updates RFC8231, RFC8664 and RFC8281 to reflect operationalized implementations and defines optimizations in the PCEP protocol. | |||||||||||||
| Framework for High Performance Wide Area Network (HP-WAN) | ||||||||||||||
|
This document defines a framework to enable the host-network collaboration for high-speed and high-throughput data transmission, coupled with fast completion time and newtork utilization of High Performance Wide Area Networks (HP-WAN). It particularly enhances the congestion control by introducing signaling mechanisms and collaborative functions, including rate negotiation, traffic scheduling, resource reservation, admission control and rate control to meet job-level objectives. | |||||||||||||
| KEM-based Authentication for IKEv2 with Post-quantum Security | ||||||||||||||
|
This draft specifies a new authentication mechanism, called KEM (Key Encapsulation Mechanism) -based authentication, for the Internet Key Exchange Protocol Version 2 (IKEv2). This is motivated by the fact that some post-quantum KEMs (like ML-KEM) are more efficient than post-quantum signature algorithms (like ML-DSA). | |||||||||||||
| Post-Quantum Traditional (PQ/T) Hybrid Authentication with Dual Certificates in TLS 1.3 | ||||||||||||||
|
The anticipated emergence of cryptographically relevant quantum computers (CRQCs) poses a threat to the authentication mechanisms used in TLS 1.3. This document defines a hybrid authentication mechanism that uses two independent certificates, one traditional and one post-quantum, ensuring that an attacker must break both algorithms to compromise a TLS connection. The two certificate chains are carried in a single Certificate message and two independent signatures are encoded in the CertificateVerify message. | |||||||||||||
| Standardising Protocol-Error | ||||||||||||||
|
We extend and standardise the Protocol-Error packet Code, first defined in RFC 7930 for the Remote Authentication Dial In User Service (RADIUS) protocol. | |||||||||||||
| Enforcement-Action HTTP Header Field | ||||||||||||||
|
This document defines the Enforcement-Action HTTP response header field. The field carries an advisory selected-action token from an application to cooperating intermediaries within a trusted boundary. It is advisory and safe to ignore. Recipients apply their local policy in response to the signal. This specification standardizes the field name, syntax, response-path processing model, and safe-to-ignore behavior. It does not standardize the operational meaning, target, duration, or enforcement effect of individual action tokens or parameters, and it does not modify HTTP semantics, TLS, QUIC, or the caching rules of [RFC9111]. | |||||||||||||
| YANG Configuration Templates | ||||||||||||||
|
NETCONF and RESTCONF protocols provide programmatic interfaces for accessing configuration data modeled by YANG. This document defines the use of a YANG-based configuration template mechanism whereby configuration data can be defined in one or more templates and applied repeatedly. This avoids the redundant definition of identical configuration and ensures the consistency of it, thus allowing configuration data to be managed more conveniently and efficiently. | |||||||||||||
| Stateless Encryption Profile for Enhanced Encapsulating Security Payload (EESP) | ||||||||||||||
|
This document specifies a stateless encryption profile for Enhanced Encapsulating Security Payload (EESP). The profile is intended for large-scale deployment scenarios in which maintaining per-flow or per-session encryption state is operationally expensive or infeasible. Instead of storing a distinct data key for each secure flow, endpoints derive per-packet or per-context data keys from a smaller set of provisioned root keying material together with packet- carried context. The document describes the deployment motivation, the stateless keying model, the mapping of required fields onto EESP extension points, context construction rules, data-key derivation processing, IV construction requirements, security considerations, and operational considerations. The intent is to realize stateless encryption as an extension profile over EESP, rather than as a parallel encapsulation format. | |||||||||||||
| Task-oriented Coordination Requirements for AI Agent Protocols | ||||||||||||||
|
AI agent communication requires intelligent task level coordination to manage dynamic workloads across large-scale, heterogeneous networking environments. This draft proposes general requirements for an agent protocol to enable autonomous task coordination at scale, including dynamic task discovery, negotiation, and context- aware scheduling with real-time adaptability. | |||||||||||||
| BGP Extensions for Inter-Domain Flexible Algorithm with Segment Routing over IPv6 (SRv6) | ||||||||||||||
|
IGP Flexible Algorithm (Flex-Algo) provides a mechanism for IGP nodes to compute the best paths according to a set of constraints in both the topology and computation metrics. Segment Routing over IPv6 (SRv6) can be used as one of the data plane of IGP Flex-Algo. In SRv6 networks, services may be carried across multiple network domains which are under the same administration. For some services, it is expected that the an end-to-end inter-domain path can be computed according to the same constraints (such as low latency) defined by Flex-Algo. This document describes BGP extensions to advertise SRv6 locators as IPv6 prefixes, together with the associated algorithm across the AS boundary. | |||||||||||||
| Framework and Applicability of Computation-aware Traffic Steering (CATS) in Optical Transport Networks (OTN) | ||||||||||||||
|
Computation-aware Traffic Steering (CATS) offers a framework for selecting computation service sites based on computation capabilities and load, and considering the network capabilities and state on the paths to the sites. Optical Transport Networks (OTN) provide guaranteed separation of traffic along with reserved hardware resources offering bandwidth and quality of service promises. This document describes how OTN may be used to support a CATS system to achieve the stringent performance targets required by demanding service environments. | |||||||||||||
| BGP PORT EC for AIDC | ||||||||||||||
|
This document introduces a new BGP extended community attribute for AI computing scenarios. This attribute is used to carry the port ID when advertising routes on the switch before launching AI tasks, preparing for negotiation before sending large-scale traffic. | |||||||||||||
| BGP Flow Specification Filtered by Destination-QP | ||||||||||||||
|
BGP Flowspec mechanism (BGP-FS) [RFC8955] [RFC8956] propagates both traffic Flow Specifications and Traffic Filtering Actions by making use of the BGP NLRI and the BGP Extended Community encoding formats. This document specifies a new BGP-FS component type named Destination-QP (Destination Queue Pair) to support filtering by Destination-QP. | |||||||||||||
| Agentic AI Operation of Constrained RESTful Environments | ||||||||||||||
|
This document describes an architecture for AI agents that autonomously discover, interpret, and interact with Internet of Things (IoT) devices using the Constrained Application Protocol (CoAP) and hypermedia-driven patterns. It defines how a Large Language Model (LLM) based agent decomposes high-level user intents into concrete device interactions without requiring pre-configured device knowledge, relying instead on in-band resource discovery, CoRE Link Format metadata, and Semantic Definition Format (SDF) models. The document covers resource discovery, normalized representation for agent consumption, tool interfaces, observation patterns for closed- loop automation, web-based monitoring interfaces, and security considerations. | |||||||||||||
| Analysing Internet Standards Data | ||||||||||||||
|
This document outlines some issues to consider when studying data relating to the Internet standards development ecosystem. It identifies observable components of standards development processes, proposes a taxonomy of possible measurements, and highlights methodological, interpretive, and ethical considerations. It is intended to support a range of uses, including monitoring standards development organisations (SDOs), evaluating the evolution of technical work, understanding technology deployment, and informing community, leadership, and governance discussions. This document is submitted for consideration by the Research and Analysis of Standard-Setting Processes Research Group (RASPRG) in the IRTF. It is not an IETF product and is not a standard. | |||||||||||||
| Algorithm-Split DNSSEC: KSK/ZSK Algorithm Separation | ||||||||||||||
|
Post-quantum DNSSEC signature algorithms have much larger keys and/or signatures than the elliptic-curve algorithms in common use today. The apex DNSKEY RRset carries the key material for both the KSK and the ZSK, and grows accordingly; the open question is whether the rest of the zone must grow with it. Because the KSK's signature appears only on the DNSKEY RRset, a large KSK -- key and signature both -- costs little beyond that one RRset. The ZSK's signature, by contrast, appears on every other RRset, so it is the size of the ZSK signature that governs the size of ordinary responses. Confining a large algorithm to the KSK, and using a small-signature algorithm for the ZSK, keeps the cost of the large algorithm contained in the DNSKEY RRset. This document specifies the changes that make this pattern safe and practical. It relaxes the DNSSEC signing rule that requires a zone to be signed with every algorithm present in the apex DNSKEY RRset, so that an algorithm used only by a key-signing key need not be applied to the rest of the zone. It relies on ordinary ZSK rotation to bound the residual exposure of the ZSK algorithm, and recommends a sequential (rather than double-signature) model for rolling the ZSK algorithm, so that the rest of the zone is never doubly signed. Finally, it specifies how a resolver can use the algorithm number in the parent's DS RRset to recognize a likely-oversized DNSKEY RRset and select a transport suitable for large responses, avoiding the truncate-then-retry round trip. This document updates RFC 4035 and RFC 6840. | |||||||||||||
| Live Agent Interaction over MoQ | ||||||||||||||
|
This document defines a protocol for real-time interactive communication between users and AI agents over Media over QUIC Transport (MOQT). It specifies how streaming inference outputs (ASR transcripts, LLM tokens, TTS audio) map to the MOQT object model, defines a turn-taking control protocol with barge-in support for voice interactions, and establishes track structure conventions for live agent sessions. The protocol operates as an application-layer profile on top of MOQT without modifying transport semantics. | |||||||||||||
| BBS and Modular Sub-proofs with JSON Web Proofs | ||||||||||||||
|
This document defines a digital credential format that uses JSON Web Proofs (JWP) as its container format and Blind BBS Signatures as its signature scheme combined with a modular framework for attaching zero-knowledge sub-proofs. This allows a Holder to reveal some attributes directly while proving predicates such as range or equality over the ones they keep hidden. A credential can additionally be bound to an ECDSA P-256 device key, with possession of the key proven in every presentation without revealing the public key. The credential type definition and data model follow SD-JWT VC [I-D.ietf-oauth-sd-jwt-vc]. | |||||||||||||
| Problem Statement and Requirements for Fast Network Event Notification in Distributed AI Training and Inference | ||||||||||||||
|
Distributed AI training and inference rely on tightly coordinated communication across large-scale AI fabrics, making timely awareness of network conditions essential to application performance. Network events, including congestion, link degradation, path changes, and device failures, can significantly affect collective communication efficiency, job completion time, and overall resource utilization. Existing network event notification mechanisms are primarily designed for general-purpose IP networks and do not adequately address the timeliness, semantics, and coordination requirements of distributed AI workloads. This document identifies the problem space for fast network event notification in distributed AI training and inference environments. It presents representative use cases, identifies gaps in existing approaches, and derives a set of functional and operational requirements for timely, reliable, and interoperable dissemination of network events across AI fabrics. These requirements are intended to facilitate future work on network architectures and protocols for AI networking. This document does not specify a protocol, signaling mechanism, or protocol extension. | |||||||||||||
| SRv6-based Rate Control | ||||||||||||||
|
This document describes a rate control mechanism for Segment Routing over IPv6 (SRv6) network slices. It addresses the challenge of balancing resource utilization and congestion avoidance in over- committed slice deployments. The mechanism leverages a token-based scheduler to differentiate between Committed Information Rate (CIR) and Peak Information Rate (PIR) traffic, and defines procedures for calculating initial PIR values and dynamically adjusting them based on network conditions. Dynamic rate adjustments are triggered by localized congestion or underutilization, enabling proactive rate control and efficient bandwidth sharing among slices sharing common physical links. | |||||||||||||
| SRv6-based Adaptive Load Balancing for AI DCI | ||||||||||||||
|
This document describes an SRv6-based adaptive load balancing architecture for AI Data Center Interconnection (DCI) scenarios, where RoCEv2 elephant flows traverse WAN between storage and compute sites under the storage-compute separation paradigm. The architecture employs a controller-driven closed loop: telemetry-based flow and path monitoring, SL-level imbalance detection, and BGP Flowspec-based steering with QP-level matching granularity and Segment List-level action precision. This supplements the default QP-aware hash-based SL selection with dynamic, explicit flow steering to resolve hash collisions and persistent load imbalance. | |||||||||||||
| Enhanced privacy for SDF proxy operations | ||||||||||||||
|
The Semantic Definition Format (SDF) enables ecosystem-independent descriptions of IoT device interaction capabilities. When a proxy mediates communication between applications and devices, it requires SDF definitions and ecosystem-specific mappings for translation. These definitions may contain privacy-sensitive information about devices and their interactions. This document defines an SDF extension for marking sensitive definitions and specifies mechanisms for generating privacy-preserving SDF documents that enable proxy operation without exposing sensitive information. | |||||||||||||
| Cross-domain Transaction Tokens | ||||||||||||||
|
This document describes a mechanism for Cross-Domain Transaction Tokens, which enables the safe maintenance and propagation of user identity, workload identities, and authorization context across multiple trust domains. | |||||||||||||
| Batch Authorization Delegation | ||||||||||||||
|
This document describes a mechanism for Batch Authorization Delegation, which enables a batch of fine-grained, actor-bound permissions in a single request and securely delegates them to multiple collaborating actors. | |||||||||||||
| Fast Congestion Notification (FCN) in Wide Area Network (WAN) Interconnecting RoCEv2 Networks | ||||||||||||||
|
Wide Area Network (WAN), when interconnecting RoCEv2 networks, needs to meet the performance requirements of "high throughput, low latency, and minimal packet loss". This document describes a solution to Fast Congestion Notification (FCN) in WAN interconnecting RoCEv2 networks, especially applicable to tunnel encapsulation. | |||||||||||||
| RATS ReST APIs | ||||||||||||||
|
This document describes a set of REST APIs that can be used by RATS roles to interact. These APIs facilitate the discovery of a role's capabilities, as well as the negotiation and exchange of RATS Conceptual Messages in several key scenarios, including Evidence gathering, Evidence appraisal, Endorsements and Reference Value management. This document aims to present a useful subset of possible RATS interaction patterns, rather than covering all of them. | |||||||||||||
| Problem Statement and Gap Analysis for Autonomic Networking with AI- powered Autonomic Service Agent | ||||||||||||||
|
This document presents a problem statement and gap analysis of the technical challenges faced by the GeneRic Autonomic Signaling Protocol (GRASP) [RFC8990] when it is used, within the Autonomic Networking Infrastructure (ANI) defined by the ANIMA Working Group [RFC8993], to support enhanced Autonomic Service Agents that incorporate Large Language Model (LLM) capabilities, referred to in this document as AI-ASAs. | |||||||||||||
| User assignable IPv4 option numbers | ||||||||||||||
|
The use of IPv4 options on the public internet is limited due to the fact that many currently defined IPv4 options have issues, as indicated in [BCP186]. This serves as an argument to refuse new option definitions for IPv4, even if the proposed IP options have no such issues, and have valid use cases on limited domains, or for limited end-host domains communicating over private networks or the public internet. This I-D defines a limited range of N IPv4 option numbers for variable assignment, by the user, to types of IP options to be used on limited domains and for limited end-host domains on the public internet. This will enable the use of IP options in two major use cases, without the need to fully standardize IP options, or register numbers for them in the IANA IP option numbers table. | |||||||||||||
| QUIC Transport for Network Telemetry | ||||||||||||||
|
This document describes the use of the QUIC transport protocol as a common transport substrate for operational Network Telemetry protocols that currently rely on UDP. Specifically, it discusses carrying protocols such as IPFIX, Syslog, YANG-Push UDP-Notif, and RADIUS Accounting over QUIC connections. For telemetry protocols whose data plane is inherently loss-tolerant (where a missing sample is preferable to a delayed retransmission) this document recommends use of the Unreliable Datagram Extension to QUIC (DATAGRAM frames). A primary motivation for this work is the unification of transport- layer security across heterogeneous telemetry protocols. Protocols that currently have no mandatory transport security (syslog over UDP) or optional-only security (IPFIX over UDP with DTLS) or weak security (RADIUS with MD5 obfuscation) would all benefit from the mandatory TLS 1.3 mutual authentication that QUIC provides. This document specifically addresses the operational advantages of managing a single PKI certificate lifecycle per Network Node to authenticate all telemetry streams. This document is intended as a framework and applicability statement. Per-protocol bindings that require normative specification are expected to be chartered in their respective IETF working groups. | |||||||||||||
| A Survey of AI Agent Discovery Mechanisms | ||||||||||||||
|
This document surveys mechanisms for AI agent discovery being developed at the IETF, at AAIF, at 3GPP, and in open-source projects. It compares them by discovery model, scope, dynamism, cross-domain reach, and semantic capability. It identifies gaps, overlaps, and conflicts between the approaches to inform future standardization work. | |||||||||||||
| An Information Model for Minimum Discoverable Information (MDI) | ||||||||||||||
|
The Discovery of Agents, Workloads, and Named Entities (DAWN) terminology document defines Minimum Discoverable Information (MDI) as the minimum information an entity must provide to be discoverable, but does not define its field-level content. The DAWN requirements and problem-statement documents identify the need for a standardized minimum structure; in its absence, emerging discovery formats risk each defining its own minimal metadata, with descriptors that do not interoperate across organizational or protocol boundaries. This document proposes a small, encoding-neutral information model, in the sense of RFC 3444, for MDI: three mandatory elements, a short set of recommended and optional elements, and the minimal constraints that hold among them. It is a minimum common subset and a mapping target for richer descriptors -- not a new card format and not a discovery protocol. | |||||||||||||
| DTN Access Gateway for IP Edge Networks | ||||||||||||||
|
Delay- and disruption-tolerant networking (DTN) is used in environments with long propagation delay, constrained links, intermittent connectivity, and scheduled contacts. At the edge of such systems, local IP networks may exist, such as lunar surface networks, spacecraft internal networks, and edge computing networks. End systems in these IP edge networks may continue to use conventional IP stacks and may not process DTN-specific semantics such as endpoint identifiers, Bundle lifetimes, contact schedules, or DTN storage constraints. This document describes a DTN access gateway for IP edge networks. The gateway is placed at the boundary between an IP edge network and a DTN domain. It organizes authorized IP-side data into Bundle payloads, submits those payloads to the DTN side under controlled admission, and reflects DTN-side admission constraints back to IP edge senders through bounded pre-admission state and passive back- pressure. The main focus is edge-to-edge transit mode, in which a pair of gateways connects two IP edge networks across a DTN domain. This document also discusses an optional edge-to-DTN service access extension, in which selected IP-side requests are mapped, under local rules, to service transactions in the DTN domain. This document does not define a new BP extension block, convergence- layer protocol, Bundle payload encoding, routing protocol, contact- plan exchange protocol, or mandatory gateway implementation. | |||||||||||||
| Exploring SCHC Compression of QUIC Frames | ||||||||||||||
|
This document explores whether Static Context Header Compression (SCHC) can be applied to the metadata carried in QUIC frames. QUIC already uses compact frame encodings and variable-length integers, so any compressed representation has to recover enough bytes to pay for its own integration overhead. The document compares several possible organizations for SCHC rules, discusses how frame compression could be integrated, and analyzes representative STREAM and ACK frame examples. The analysis suggests that SCHC compression of QUIC frames is technically possible, but that generic or base rules are likely to provide only modest savings at best. More substantial savings require predictable traffic, pre-provisioned or negotiated rules, bundling of several frames under one rule, or a negotiated QUIC payload syntax with low per-packet overhead. This document is exploratory. It does not define an interoperable QUIC extension, SCHC profile, wire format, or IANA allocation. | |||||||||||||
| SRv6 BSID with Notification Message Relay | ||||||||||||||
|
This document defines a new SRv6 Endpoint behavior, End.B6.Encaps.Relay, for Binding SID (BSID) nodes in SRv6 networks. The behavior enables BSID nodes to relay tunnel-internal notification messages, such as ICMPv6 errors and congestion notifications, back to the upstream tunnel source node through a mapping mechanism. | |||||||||||||
| WIMSE Trust Domain Discovery | ||||||||||||||
|
The WIMSE architecture scopes workload identifiers to a trust domain. To validate a workload identity credential, a relying party must securely obtain the cryptographic trust anchors associated with the credential's trust domain. The WIMSE architecture requires that this mapping between a trust domain and its trust anchors is obtained through a secure mechanism, but leaves that mechanism undefined. This document defines such a mechanism for open environments in which no prior trust relationship exists between the relying party and the trust domain. It specifies the WIMSE Trust Bundle, a document that conveys the trust anchors of a trust domain for both JWT-based and X.509-based workload identity credentials, and a discovery mechanism based on a well-known HTTPS endpoint that allows a relying party to resolve a trust domain name to its trust bundle on demand. | |||||||||||||
| Bounded Capabilities for Agent Tool Interfaces: Problem Statement | ||||||||||||||
|
Deployed agent tool-interface protocols carry JSON Schema type declarations for tools, but a type declaration is not a contract: nothing signals that a tool is fully schema-bounded, conformance to declared schemas is self-certified by the declaring party, declarations are not pinned between discovery time and invocation time, and error channels are untyped by design. As a consequence, any decision made about a tool call — authorization, discovery, audit, or composition — requires a language model to interpret what the call means, even for the large class of tools that are not intrinsically open-ended. This document states that problem and poses questions for the community. It deliberately proposes no mechanism. | |||||||||||||
| Binding Named-Human Authorization Evidence into Agent-Action Records | ||||||||||||||
|
A recurring pattern spans the agent-action record formats now in development: a record about an agent's action reserves a place for "the human authorization" — an approver disposition, an authority context, a human-override field, an actor slot, a signed grant, an approval reference — and leaves its semantics undefined. Each format, reasonably, does not want to specify human-authorization evidence itself; none, so far, says what filling the slot means. This document defines that one thing, host-agnostically: how any record binds named-human authorization evidence, either BY REFERENCE (a content digest of the authorization artifact's canonical bytes) or EMBEDDED (a compact, self-describing claim carrying named approvals and optional distinct-human quorum semantics), with five requirements that make the binding mean the same thing in every host: digest grounding, action agreement, verified-versus-accepted discipline, fail-closed absence, and embedded/referenced consistency. The SCITT signed-statement host family is expressed concretely (digest selection, and the observed-absence statement that is the only way absence of authorization becomes evidence); an informative appendix maps the binding onto the reserved slots of eleven current documents. This document defines no new authorization format: the referenced evidence verifies under its own specification. | |||||||||||||
| Delegation Maintenance Automation Status Extension for the Extensible Provisioning Protocol (EPP) | ||||||||||||||
|
This document specifies an extension to the Domain Mapping for the Extensible Provisioning Protocol (EPP) which allows EPP clients to enable and disable automatic delegation maintenance carried out by the server. It also describes how the maintenance automation state of a domain can be included in RDAP responses. The source for this draft, and an issue tracker, may can be found at https://github.com/gbxyz/epp-ds-automation-extension. | |||||||||||||
| Leafy Greens - End Entity Name Restrictions | ||||||||||||||
|
The interaction of name constraint matching in [RFC5280] and wildcard subject alternative names creates a gap in which an excluded name constraint cannot be relied upon to prevent the issuance of certificates usable for the excluded name. This document defines End Entity Name Restrictions (EENR), a new critical X.509 extension for CA certificates that constrains the dNSName Subject Alternative Name entries which may appear in end entity certificates issued beneath the CA. EENR specifies its own matching semantics, including for wildcard dNSName entries, so that it does not depend on application- defined interpretations. The extension is scoped to use in certificate path validation for TLS client and TLS server authentication. | |||||||||||||
| The HTTP SUBSCRIBE Method | ||||||||||||||
|
This document defines the HTTP SUBSCRIBE request method. The SUBSCRIBE method allows a client to establish a long-lived, safe connection to a resource to receive real-time updates and event streams. It enables servers to push data to clients using standard HTTP structures (such as HTTP/2 or HTTP/3 streams) while supporting a request body for subscription parameters, avoiding the protocol- switching overhead of WebSockets and the URL limitations of Server- Sent Events (SSE) via GET. | |||||||||||||
| Handling of traffic characteristic deviation for DetNet | ||||||||||||||
|
Deterministic Networking (DetNet) relies on resource reservation to guarantee bounded-latency forwarding, yet traffic characteristic deviations from microbursts and flow aggregation frequently occur at aggregation nodes. Native handling approaches like direct packet discard or best-effort forwarding lead to severe service degradation. This document proposes an enhanced traffic characteristic deviation solution for DetNet. This solution specifies two complementary data- plane policies: the squeezing policy defers deviated traffic to subsequent timeslots within a configurable threshold while preserving deterministic attributes to absorb transient bursts; the degrading policy reclassifies over-threshold traffic to lower-priority queues for graceful handling, avoiding unnecessary packet loss. These policies can be enabled independently or combined, ensuring the preferential scheduling and preservation of deterministic service traffic under deviation conditions. | |||||||||||||
| Operational Requirements for Network State Exchange in Agent-Assisted Network Operations | ||||||||||||||
|
This document describes operational requirements for exchanging network state in agent-assisted network operations. In this document, an agent-assisted system is any automation or decision- support system that consumes operational state to support tasks such as anomaly triage, incident correlation, configuration verification, traffic engineering analysis, or attack mitigation support. Such a system may use a large language model (LLM), a rule engine, a statistical model, or conventional software. The document focuses on operational problems created by high-volume telemetry, cross-domain state sharing, privacy constraints, approximate state summaries, and auditability of state used by automated workflows. It identifies requirements for compact, scoped, mergeable, bounded-error, incrementally synchronized, and auditable network state artifacts. The document complements existing NMOP work on anomaly detection, incident management, and YANG Push/message broker integration. It does not define a new network management protocol, a new agent communication protocol, or a wire format. | |||||||||||||
| A Multiplane Architecture Proposal for the Quantum Internet | ||||||||||||||
|
A consistent reference architecture model for the Quantum Internet is required to progress in its evolution, providing a framework for the integration of the protocols applicable to it, and enabling the advance of the applications based on it. This model has to satisfy three essential requirements: agility, so it is able to adapt to the evolution of quantum communications base technologies, sustainability, with open availability in technological and economical terms, and pliability, being able to integrate with the operations and management procedures in current networks. This document proposes such an architecture framework, with the goal of providing a conceptual common framework for the integration of technologies intended to build the Quantum Internet infrastructure and its integration with the current Internet. The framework is based on the already extensive experience in the deployment of QKD network infrastructures and on related initiatives focused on the integration of network infrastructures and services. | |||||||||||||
| Deprecating Insecure Practices in RADIUS | ||||||||||||||
|
RADIUS crypto-agility was first mandated as future work by RFC 6421. The outcome of that work was the publication of RADIUS over TLS (RFC 6614) and RADIUS over DTLS (RFC 7360) as experimental documents. Those transport protocols have been in wide-spread use for many years in a wide range of networks, and have recently been standardized in [I-D.ietf-radext-radiusdtls-bis]. TLS has proven to be a useful replacment for UDP (RFC 2865) and TCP (RFC 6613) transports. With that knowledge, the continued use of insecure transports for RADIUS has serious and negative implications for privacy and security. The publication of the "BlastRADIUS" exploit has also shown that RADIUS security needs to be updated. It is no longer acceptable for RADIUS to rely on MD5 for security. It is no longer acceptable to send device or location information in clear text across the wider Internet. This document therefore deprecates many insecure practices in RADIUS, and mandates support for secure TLS-based transport layers. Related security issues with RADIUS are discussed, and recommendations are made for practices which increase both security and privacy. | |||||||||||||
| Epoch Markers | ||||||||||||||
|
This document defines Epoch Markers as a means to establish a notion of freshness among actors in a distributed system. Epoch Markers are similar to "time ticks" and are produced and distributed by a dedicated system known as the Epoch Bell. Systems receiving Epoch Markers do not need to track freshness using their own understanding of time (e.g., via a local real-time clock). Instead, the reception of a specific Epoch Marker establishes a new epoch that is shared among all recipients. This document defines Epoch Marker types, including CBOR time tags, RFC 3161 TimeStampToken, and nonce-like structures. It also defines a CWT Claim to embed Epoch Markers in RFC 8392 CBOR Web Tokens, which serve as vehicles for signed protocol messages. | |||||||||||||
| RESTful Provisioning Protocol (RPP) Data Objects | ||||||||||||||
|
This document defines data objects for the RESTful Provisioning Protocol (RPP) and sets up the IANA RPP Data Object Registry to describe and catalogue them. Specifically, it details the logical structure, constraints, and protocol operations (including their inputs, outputs, and business logic) for foundational resources: domain names, contacts, and hosts. In accordance with the RPP architecture [I-D.kowalik-rpp-architecture], these definitions focus entirely on the semantics, remaining independent of any specific data representation or media type (e.g., JSON or XML). | |||||||||||||
| A recommendation for filtering address records in stub resolvers | ||||||||||||||
|
Since IPv4 and IPv6 addresses are represented by different resource records in the Domain Name System, operating systems capable of running both IPv4 and IPv6 need to execute two queries when resolving a host name. This document discusses the conditions under which a stub resolver can optimize the process by not sending one of the queries if the host is connected to a single-stack network. | |||||||||||||
| Transmission of IPv6 Packets over Short-Range Optical Wireless Communications | ||||||||||||||
|
[IEEE802.15.7], "Short-Range Optical Wireless Communications" defines wireless communication using visible light. It defines how data is transmitted, modulated, and organized in order to enable reliable and efficient communication in various environments. The standard is designed to work alongside other wireless communication systems and supports both Line-of-Sight (LOS) and Non-Line-of-Sight (NLOS) communications. However, ambient light interference from natural sunlight or artificial lighting sources can impact signal reliability. To mitigate this, advanced modulation techniques, optical filtering, and adaptive power control can be employed. This document describes how IPv6 is transmitted over short-range optical wireless communications (OWC) using IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) techniques. | |||||||||||||
| Protecting EST Payloads with OSCORE | ||||||||||||||
|
Enrollment over Secure Transport (EST) is a certificate provisioning protocol over HTTPS [RFC7030] or CoAPs [RFC9148]. This document specifies how to carry EST over the Constrained Application Protocol (CoAP) protected with Object Security for Constrained RESTful Environments (OSCORE). The specification builds on the EST-coaps [RFC9148] specification, but uses OSCORE and Ephemeral Diffie-Hellman over COSE (EDHOC) instead of DTLS. The specification also leverages the certificate structures defined in [I-D.ietf-cose-cbor-encoded-cert], which can be optionally used alongside X.509 certificates. | |||||||||||||
| Constrained GeneRic Autonomic Signaling Protocol | ||||||||||||||
|
This document proposes the Constrained GeneRic Autonomic Signaling Protocol (cGRASP), a constrained and lightweight variant of the GeneRic Autonomic Signaling Protocol (GRASP, or the standard GRASP). cGRASP reduces message overhead and replaces TCP with CoAP as the transport protocol. By leveraging CoAP's reliability features and deployment maturity, cGRASP can provide reliable signaling services without relying on TCP, making it suitable for IoT, where lightweight and resource-constrained devices dominate. Furthermore, this document also discusses the potential approaches to adapting the cGRASP to work on the network without IP connectivity. | |||||||||||||
| A publish-subscribe architecture for the Constrained Application Protocol (CoAP) | ||||||||||||||
|
This document describes a publish-subscribe architecture for the Constrained Application Protocol (CoAP), extending the capabilities of CoAP communications for supporting endpoints with long breaks in connectivity and/or up-time. CoAP clients publish on and subscribe to a topic via a corresponding topic resource at a CoAP server acting as broker. | |||||||||||||
| A YANG Data Model for BGP Communities | ||||||||||||||
|
This document defines a YANG data model for the structured specification of BGP communities. The model provides operators with a way to publish their locally defined BGP communities in a standardized format. Two YANG modules are defined in this document. The first is designed for stand-alone usage. The second is used to augment the "ietf-bgp" YANG module[I-D.ietf-idr-bgp-model] with BGP community annotations. Additionally, this document provides an optional discovery mechanism based on publishing of community definition locations through the Resource Public Key Infrastructure (RPKI). | |||||||||||||
| YANG Metadata Annotation for Immutable Flag | ||||||||||||||
|
This document defines a mechanism to formally document an existing behavior, implemented by servers of YANG-driven network management protocols (e.g., NETCONF and RESTCONF), on the immutability of some system-provided nodes, using a YANG metadata annotation called "immutable" to flag which nodes are immutable. Clients may use "immutable" annotations provided by the server, to know beforehand why certain otherwise valid configuration requests will cause the server to return an error. The immutable flag is descriptive, documenting an existing behavior, not prescriptive, dictating server behaviors. This document updates RFC 8040 and RFC 8526. | |||||||||||||
| An Architecture for YANG-Push to Message Broker Integration | ||||||||||||||
|
This document describes the motivation and architecture of a native YANG-Push notifications and YANG Schema integration into a Message Broker and YANG Schema Registry. | |||||||||||||
| YANG Message Keys for Message Broker Integration | ||||||||||||||
|
This document specifies a mechanism to define a unique Message key for a YANG to Message Broker integration and a topic addressing scheme based on YANG-Push subscription type and YANG Schema Node Identifier. This enables YANG data consumption of a subset of subscribed YANG data, either per specific YANG data node, identifier or telemetry message type, by indexing and organizing in Message Broker topics. It helps to index the information by using data taxonomy and organizes data in partitions and shards of Message Brokers and time series databases. | |||||||||||||
| Encoding Network Slice Identification for SRv6 | ||||||||||||||
|
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. For packet forwarding in a specific NRP, some fields in the data packet are used to identify the NRP the packet belongs to, so that NRP-specific processing can be performed on each node along a path in the NRP. At the data plane, use the NRP Selector ID to map and differentiate between different NRPs. How to map to NRP via Selector ID is not within the scope of this document. This document describes a novel method to encode NRP Selector ID in the outer IPv6 header of an SRv6 domain, which could be used to identify the NRP-specific processing to be performed on the packets by each network node along a network path in the NRP. | |||||||||||||
| Extending ICMPv6 for SRv6-related Information Validation | ||||||||||||||
|
This document introduces the mechanism to verify the data plane against the control plane and detect data plane failures in IPv6/SRv6 networks by extending ICMPv6 messages. | |||||||||||||
| EVPN Mpls Ping Extension | ||||||||||||||
|
In an EVPN or any other VPN deployment, there is an urgent need to tailor the reachability checks of the client nodes via off-box tools which can be triggered from a remote Overlay end-point or a centralized controller. There is also a ease of operability needed when the knowledge known is partial or incomplete. This document aims to address the limitation in current standards for doing so and provides solution which can be made standards in future. As an additional requirement, in network border routers, there are liaison/ dummy VRFs created to leak routes from one network/fabric to another. There are scenarios wherein an explicit reachability check for these type of VRFs is not possible with existing mpls-ping mechanisms. This draft intends to address this as well. Few of missing pieces are equally applicable to the native lsp ping as well. | |||||||||||||
| Securing BPSec Against Arbitrary Packet Dropping | ||||||||||||||
|
In this document we describe Secure Bundle Protocol Audit Mechanism (SBAM), an authentication protocol designed to provide cryptographic auditing services for the Bundle Security protocol. | |||||||||||||
| Operations,Administration and Maintenance (OAM) for Network Resource Partition (NRP) in MPLS Network | ||||||||||||||
|
A Network Resource Partition (NRP) represents a subset of network resources and associated policies within the underlay network. This document describes the implementation of the Operations, Administration, and Maintenance (OAM) mechanism for NRPs in MPLS networks. By extending existing OAM mechanisms such as ping, traceroute, the proposed solution enables comprehensive NRP support in MPLS networks. | |||||||||||||
| PQ/T Hybrid Composite Key Exchange and Reliable Transport for IKEv2 | ||||||||||||||
|
The eventual transition to post-quantum key exchange will require elimination of traditional key exchange for reduced protocol complexity and efficiency. IKEv2 therefore requires a mechanism that can operate in a PQC-only environment, without depending on traditional key exchange algorithms (e.g., MODP DH or ECDH). As IKEv2 permits arbitrary combinations of algorithms, unnecessary complexity and insecure hybrid constructions are easily implemented. This document defines PQ/T hybrid composite key exchange algorithms for IKEv2 and a single combined KE payload that carries both the traditional and post-quantum components. It also leverages the existing IKEv2 reliable transport mechanism so that large PQC key exchange messages can be reliably exchanged over TCP. Together, these mechanisms enable secure and efficient PQ/T hybrid deployments today and provide a clear path for IKEv2 to operate in environments where traditional algorithms have been replaced by PQC algorithms. | |||||||||||||
| Privacy-Preserving Federated Learning Architecture for Multi-Tenant Agent Systems | ||||||||||||||
|
This document describes an architecture for privacy-preserving federated learning in multi-tenant agent systems. The architecture is intended for deployments in which agents, tools, services, or model operators need to learn from distributed operational data without centralizing tenant data. The architecture separates agent communication from learning coordination. Existing or emerging agent protocols can provide discovery, messaging, authentication, and transport. This document defines the privacy and security requirements for the learning layer: cohort formation, update submission, secure aggregation, differential privacy, privacy accounting, auditability, and model distribution. The document is scoped to cross-tenant and cross-organization settings. It does not define a new agent protocol, a new transport protocol, or a new machine learning algorithm. | |||||||||||||
| Protocols Applicability for Computing-Aware Traffic Steering (CATS) | ||||||||||||||
|
This document analyzes the applicability of protocols related to a CATS system, and describes how to build a CATS system by extending existing IETF protocols. | |||||||||||||
| BMP YANG Model for Network Telemetry Messages | ||||||||||||||
|
This document defines an BGP Monitoring Protocol (BMP) message schema extension in YANG to be used at data collection to transform Network Telemetry messages into external systems such as Message Brokers. | |||||||||||||
| ICMP Extension for SAVNET Validation | ||||||||||||||
|
This document defines new ICMP and ICMPv6 error codes to send error messages to the source device when forwarding Ping or Traceroute packets is dropped due to SAVNET validation failure. The error message explicitly states the reason for dropping as "SAVNET Validation Failed," thereby enhancing network observability and troubleshooting capabilities. | |||||||||||||
| Intent Provenance Protocol (IPP) | ||||||||||||||
|
This document specifies the Intent Provenance Protocol (IPP), a cryptographic infrastructure standard for carrying verified human intent through chains of autonomous artificial intelligence agent actions. IPP defines the Intent Token, a signed, bounded, and tamper-evident data structure that travels with every agentic action, preserving an unbroken, auditable lineage from the originating human principal to each terminal action executed on their behalf. As AI agents become primary actors in enterprise environments, executing transactions, accessing sensitive data, orchestrating sub- agents, and operating across organizational boundaries, the absence of a shared trust substrate creates systemic risk to organizational accountability, regulatory compliance, and legal liability attribution. IPP addresses this gap by establishing a protocol layer that operates above cryptographic authentication and below application logic, making human intent a first-class, verifiable primitive in agentic systems. IPP introduces four foundational properties, Lineage, Boundedness, Non-repudiation, and Interoperability, enforced through a combination of Ed25519 digital signatures, Decentralized Identifiers (DIDs), and a Narrowing Invariant that prevents any derived token from exceeding its parent's authorized scope. The protocol is framework-agnostic, cloud-agnostic, and designed for open implementation across the ecosystem of AI orchestration platforms. | |||||||||||||
| Signed Execution Receipts for AI Agent Tool Calls (XAIP Receipts) | ||||||||||||||
|
This document defines a wire format for signed execution receipts produced by AI agents when they invoke tools, services, or other agents. A receipt records the minimum facts needed to make a trust decision about a future call: who acted, who delegated, what tool was used, whether the call succeeded, how long it took, and how the call's inputs and outputs are identified (without disclosing their contents). A distinguishing property of the format is optional caller co- signature over the same canonical per-call record. When both signatures validate, the receipt cryptographically binds the identified Caller and Agent to the same canonical payload. This does not establish that either party independently observed every field, that the recorded execution was correct, or that the parties did not collude. A receipt may carry the Agent signature alone, and consumers may distinguish the two cases according to deployment policy. The format is intentionally tool-system-agnostic. The same receipt structure can be emitted by MCP (Model Context Protocol) servers, LangChain.js callback handlers, OpenAI tool-calling loops, HTTP clients, or proprietary agent runtimes. Receipts use Ed25519 signatures over a JCS-canonicalized payload, and identities are W3C Decentralized Identifiers (DIDs). This revision introduces an explicit wire-format version (formatVersion), pins the hash preimage profile, and ships executable conformance test vectors. Scoring policy, aggregation architecture, and reactive behavior in response to receipts are explicitly out of scope and left to deployments. | |||||||||||||
| Active,Passive,and Hybrid Metrics and Methods | ||||||||||||||
|
This memo provides clear definitions for Active, Passive and Hybrid performance assessment. The construction of Metrics and Methods can be described as either "Active" or "Passive". Some methods use a subset of both Active and Passive attributes, and they can be referred to as "Hybrid". This memo also describes multiple dimensions to help evaluate new methods as they emerge. This memo obsoletes RFC 7799. | |||||||||||||
| SRv6-based Rate Notification | ||||||||||||||
|
This document specifies a rate notification mechanism for Segment Routing over IPv6 (SRv6) networks. It enables a transit or egress node to dynamically notify the ingress (headend) node about a recommended rate range (MinRate and MaxRate) when localized congestion is detected or when underutilized bandwidth is identified, allowing the headend to perform proactive traffic shaping and rate enforcement. This mechanism enhances transmission efficiency in SRv6 networks by enabling fine-grained, congestion-aware rate control. | |||||||||||||
| IPv6 Rate Hop-by-Hop Option | ||||||||||||||
|
This document defines a new IPv6 Hop-by-Hop Option that enables Minimum Rate Limit Discovery along the forward path between a source host and a destination host. Each router along the path can update the option with the minimum of its local Maximum Rate (MRate) and the recorded value. The discovered rate can then be communicated back to the source via a return mechanism, enabling the source to adapt its transmission rate to match the bottleneck link capacity and queue buffer. | |||||||||||||
| LICET: Multi-Modal Physiological Human-Intent Verification for Autonomous AI Agent Authorization | ||||||||||||||
|
Autonomous AI agents executing consequential actions require authorization mechanisms that verify not only identity but voluntary intent. Existing mechanisms verify _who_ authorized an action; they cannot verify _whether the authorizing human was uncoerced and cognitively capable_ at the moment of authorization. This document specifies LICET (Latin: _it is permitted_), a cryptographic middleware protocol binding AI agent authorization to real-time multi-modal physiological state via a three-layer architecture: (1) ECG waveform morphology matching as a medication- resistant identity and liveness anchor; (2) electrodermal activity (EDA) as a sympathetic cholinergic liveness signal immune to beta- adrenergic blockade; and (3) personalized Mahalanobis distance fusion over five physiological signals to elevate the cost of pharmacological coercion attacks rather than claim binary detection. LICET defines a Biometric Trust Level hierarchy (L0-L3) aligned with the IETF RATS architecture (RFC 9334), a baseline calibration protocol establishing individual physiological profiles, per-event HKDF session-key derivation, HMAC biometric temporal signatures, Schnorr zero-knowledge proofs over BN128 enabling third-party audit without biometric exposure, and a SHA-256 hash-chained tamper-evident ledger. A reference implementation is publicly deployed at https://licet.dev/ v1/ and available as open source at https://github.com/christianrp45/ licet-protocol. | |||||||||||||
| Gateway Mediation Layer for AI Agent Collaboration | ||||||||||||||
|
Cross-domain and policy-controlled agent collaboration can require mediation decisions that are not always suitable for an agent client or an agent server alone. A collaboration request may need to combine a stated goal, capability profiles, tenant or domain policy, trust evidence, disclosure limits, operational constraints, and handoff context before a concrete interaction mechanism is used. This document identifies gateway-side interaction mediation as a distinct interoperability gap in many AI Agent Gateway deployments. It does not claim that every agent collaboration requires a gateway. Rather, it explains why many deployments need a mediation point where request goals, capability profiles, policy, trust, and handoff constraints can be evaluated before interaction proceeds. The document describes a Gateway Mediation Layer as a decision- support and interface layer between application-level goals and concrete agent interaction mechanisms. It focuses on the role, inputs, outputs, and narrow set of interoperable artifacts that may require further work, such as Mediation Requests, Mediation Responses, Handoff Contexts, Failure Records, and Evidence References. It does not propose standardizing internal matching algorithms, domain ontologies, prompt engineering, or model-specific decision logic. | |||||||||||||
| SR-TE Path Based on Quality-Aware Dynamic Adaptive Adjustment | ||||||||||||||
|
This document defines a framework for quality-aware dynamic adaptive adjustment of Segment Lists within an SR-TE Candidate Path. It addresses the limitation of static weight assignment, which cannot adapt to dynamic changes in path quality (e.g., latency, loss, utilization). The framework enables continuous monitoring of end-to- end metrics for each Segment List, computation of updated weights proportional to their relative quality, and application at the policy head-end. This allows the Candidate Path to autonomously optimize traffic distribution towards higher-quality paths, enhancing performance without altering the SR-Policy architecture. | |||||||||||||
| DTL: Dyadic Typed Layer | ||||||||||||||
|
DTL (Dyadic Typed Layer) defines a single, minimal primitive: a typed, directed relationship between two agents that the controller of each agent has confirmed, together with the lifecycle of that relationship. The name describes the primitive: Dyadic (it concerns one pair of parties), Typed (the relationship carries exactly one kind), and Layer (it sits above an identity substrate, not inside it). Agent ecosystems have built out several coordination layers: identity (who an agent is), reputation and attestation (what is asserted about an agent), and discovery and messaging (how agents find and talk to each other). One primitive is comparatively underserved, the relationship: a standing, acknowledged, directed connection between two specific agents, recording that they are related and in what capacity. No existing standard, to the author's knowledge, provides exactly this primitive in this form. DTL specifies it and nothing more. It is normative about the mechanism (a typed, directed, two- party, controller-confirmed edge and its lifecycle) and deliberately silent about substrate, transport, storage, and the open vocabulary of relationship types. An informative binding to ERC-8004 is provided as the first anchoring substrate. | |||||||||||||
| Support for nothing-new notifications in the DNS | ||||||||||||||
|
The DNS protocol has increasingly needed to carry larger records than it was originally designed to carry. This has resulted in performance impacts due to both the size increases and requiring TCP instead of only UDP. Of particular note is the expected large increase in records relating to post-quantum signing algorithms. To help mitigate, but not entirely prevent, these impacts, this document proposes a new "nothing new" NN flag, a LARGE Redirection Resource record type, and how these can integrate with current and future DNSSEC DNSKEY and RRSIG records. | |||||||||||||
| Schnorr-Type Proofs of Possession for ECDSA Device Binding | ||||||||||||||
|
This document specifies a Schnorr-type, circuit-free zero-knowledge proof of possession (PoP) of an ECDSA signature produced under a committed public key over the NIST P-256 (secp256r1) curve. The PoP lets a credential holder prove, in zero knowledge, that it can produce a fresh ECDSA signature under a device public key without revealing that key, thereby providing device binding for privacy- preserving credentials whose presentation must remain unlinkable. The construction is built exclusively from Sigma protocols as it decomposes the ECDSA verification equation into a scalar- multiplication relation and a point-addition relation over P-256, each proved with a dedicated Sigma protocol over a companion ("Tom") curve whose scalar field equals the base field of P-256. It is designed to be expressed using the interfaces of the CFRG Sigma- protocols specification and to serve as the device-binding sub-proof of the modular BBS / JSON Web Proofs construction. SNARK-based realizations of the same relation are out of scope. | |||||||||||||
| More Instance Messaging Interoperability (MIMI): Retracting MIMI Content Messages by the Hub Provider | ||||||||||||||
|
The More Instant Messaging Interoperability (MIMI) Protocol defines a way to signal potentially abusive messages to a provider, but provides no way for the provider to signal that an abusive message sent in a room should be retracted. This document defines mechanisms for providers to signal this to in-room participants. | |||||||||||||
| Agent-Awareness in IPv6 Networks: Problem Statement and Framework | ||||||||||||||
|
The Internet of Agents (IoA) raises a question beyond IPv6 address space and end-to-end connectivity: should an IPv6 network be able to relate packet forwarding to agent capability, policy, and short-lived execution state? This informational document states the problem, sketches a framework for agent-aware IPv6 forwarding, and lists open questions for community discussion. It does not define packet formats, routing extensions, IANA allocations, or a new agent discovery protocol. | |||||||||||||
| SCONE-Based Rate Advice for RoCEv2 Networks | ||||||||||||||
|
This document describes the applicable scenarios of the Standard Communication Protocol for Network Elements (SCONE) in RoCEv2 networks. SCONE defines a mechanism that enables network elements on the forwarding path to deliver throughput guidance to RoCEv2 endpoints. This document further specifies the method for carrying Rate Advice in RoCEv2 packets. The Rate Advice is generated by network nodes (e.g., switches), which can be either rate limits defined by network policies or quantitative rate adjustment recommendations derived from network status information. This document specifies the packet format for Rate Advice and the calculation method for the advised rate. | |||||||||||||
| General Technical Capability Requirements for Intelligent Hybrid Cloud Platform | ||||||||||||||
|
This document specifies the general technical capability requirements for an intelligent hybrid cloud platform. An intelligent hybrid cloud combines compute, storage, and network resources across multiple cloud deployment models, leveraging artificial intelligence algorithms to implement active hybrid cloud management functions such as intelligent resource scheduling, intelligent analysis, intelligent statistics, and intelligent prediction. It also provides support for intelligent computing power and large model development-related service technical capabilities within the hybrid cloud. This document defines capability requirements across infrastructure, unified platform management, model cross-cloud development, and intelligent operations and maintenance. This document is applicable to the design, development, and deployment of intelligent hybrid cloud platforms by cloud service providers, and provides reference and specifications for users designing and deploying intelligent hybrid cloud platforms. | |||||||||||||
| Time-Variant Routing (TVR) Requirements | ||||||||||||||
|
Time-Variant Routing (TVR) refers to calculating a forwarding path through a network where the time of message transmission (or receipt) is part of the overall route computation. This means that, all things being equal, a TVR computation might produce different results depending on the time that the computation is performed without other detectable changes to the network topology or other cost functions associated with the route. This document introduces requirements for the design and implementation of systems which perform TVR computations. It also explains different aspects of a TVR system which need to be considered during its design. | |||||||||||||
| WIMSE Workload Credentials | ||||||||||||||
|
The WIMSE architecture defines authentication and authorization for software workloads in a variety of runtime environments, from the most basic ones up to complex multi-service, multi-cloud, multi- tenant deployments. This document defines the credentials that workloads use to represent their identity. They can be used in various protocols to authenticate workloads to each other. To use these credentials, workloads must provide proof of possession of the associated private key material, which is covered in other documents. This document focuses on the credentials alone, independent of the proof-of- possession mechanism. | |||||||||||||
| vCard Format Specification | ||||||||||||||
|
This document defines the vCard data format for representing and exchanging a variety of information about individuals and other entities (e.g., formatted and structured name and delivery addresses, email address, multiple telephone numbers, photograph, logo, audio clips, etc.). This document obsoletes RFC 6350. | |||||||||||||
| Happy Eyeballs Version 3: Better Connectivity Using Concurrency | ||||||||||||||
|
Many communication protocols operating over the modern Internet use hostnames. These often resolve to multiple IP addresses, each of which may have different performance and connectivity characteristics. Since specific addresses or address families (IPv4 or IPv6) may be blocked, broken, or sub-optimal on a network, clients that attempt multiple connections in parallel have a chance of establishing a connection more quickly. This document defines the algorithm for "Happy Eyeballs", a technique for reducing user-visible delays on dual-stack hosts. This document updates the algorithm in RFC 8305. | |||||||||||||
| Downgrade Prevention for the Internet Key Exchange Protocol Version 2 (IKEv2) | ||||||||||||||
|
This document specifies an extension to the Internet Key Exchange protocol version 2 (IKEv2) in which the peers authenticate the full IKE_SA_INIT transcript. When both peers implement the extension and at least one relevant authentication credential is not compromised, this prevents certain downgrade attacks on IKEv2. This document updates RFC 7296. | |||||||||||||
| One Signature Certificates | ||||||||||||||
|
This document defines the signedDocumentBinding certificate extension, which binds a certificate to the signed content of a digital signature produced by a single signing operation. Each certificate is created at the time of signing and the associated signing key is generated, used to produce a single digital signature, and then immediately destroyed. Certificates carrying this extension are intended to be issued without a revocation mechanism and with no expiration, which simplifies long-term validation. | |||||||||||||
| IMAP Extensions Suggestions | ||||||||||||||
|
This document presents a set of IMAP extensions, each of which is recommended as a priority for general-purpose IMAP client and server implementations. | |||||||||||||
| Network Digital Twin (NDT): Concepts and Reference Architecture | ||||||||||||||
|
The application of Digital Twin technology in the networking field is meant to develop various rich network applications, realize efficient and cost-effective data-driven network management, and accelerate network innovation. This document presents an overview of the concept of Network Digital Twin (NDT), provides the basic definitions and a reference architecture, lists a set of application scenarios, and discusses such technology's benefits and key challenges. This document is a product of the Network Management Research Group (NMRG) of the Internet Research Task Force (IRTF). This document reflects the consensus of the research group. It is not a candidate for any level of Internet Standard and is published for informational purposes. | |||||||||||||
| Data Generation and Optimization for Network Digital Twin | ||||||||||||||
|
Network Digital Twin (NDT) can be used as a secure and cost-effective environment for network operators to evaluate network in various what-if scenarios. Recently, Artificial Intelligence (AI) models, especially neural networks, have been applied for NDT modeling. The quality of deep learning models mainly depends on two aspects: model architecture and data. This memo focuses on how to improve the model quality from the data perspective. | |||||||||||||
| A Framework for LLM Agent-Assisted Network Management with Human-in-the-Loop | ||||||||||||||
|
This document describes a reference framework for collaborative network management between Large Language Model (LLM)-assisted agents and human operators. Because network management actions can affect service availability, security posture, customer traffic, and compliance obligations, LLM-generated recommendations need to be validated, reviewed, and audited before they are applied to operational networks. The framework therefore focuses on human-in- the-loop control for safe, auditable, and operator-supervised use of LLM-assisted decision support in network operations. The document is intended to be compatible with existing network management systems and protocols while identifying research issues, rather than specifying a complete implementation of all LLM agent mechanisms. | |||||||||||||
| PIM Reverse Path Forwarding (RPF) Vector Conflict Resolution | ||||||||||||||
|
RFC7891 Section 7 defines the handling principles for PIM Join attributes with same type of RFF Vector and Explicit RFP Vector, but with different contents are received. However, it does not address scenarios where one downstream router includes a RFF Vector in its message while another does not. This leaves the handling of such conflicts unspecified. This document updates RFC 5496 and RFC 7891 by supplementing the existing specifications with handling rules for this specific conflict scenario. | |||||||||||||
| Ingress Replication BUM flag in VXLAN | ||||||||||||||
|
This document proposes the allocation of an “Ingress Replication BUM” flag in the VXLAN Flags IANA registry and defines its use in EVPN networks that employ VXLAN tunnels with ingress replication to forward broadcast, unknown and multicast traffic. | |||||||||||||
| X.509v3 ML-DSA Certificates for the Secure Shell (SSH) Protocol | ||||||||||||||
|
This document describes the use of Module-Lattice-Based Digital Signature Algorithm (ML-DSA) in Internet X.509 version 3 Public Key Certificate in the Secure Shell protocol. Accordingly, the document updates RFC6187. | |||||||||||||
| Content Negotiation for Consolidated Machine-Readable Representations | ||||||||||||||
|
This document specifies the use of HTTP content negotiation and the Prefer header to request consolidated, machine-readable representations of web resources. A client uses the Accept header to negotiate an appropriate media type and Prefer: return=consolidated to request a representation intended for automated consumption. A server that honours the preference identifies the selected representation with Preference-Applied: return=consolidated and varies cached responses on Accept and Prefer. The mechanism uses existing HTTP semantics and introduces a single new preference value for the existing Prefer header. It provides a protocol-level alternative to ad-hoc client detection or path conventions when serving machine-readable representations, while also enabling publishers to reduce repeated fetching, bandwidth use, and server processing. | |||||||||||||
| BPv7 Echo Service | ||||||||||||||
|
This document specifies an echo service for Bundle Protocol Version 7 (BPv7) networks. An echo service receives bundles at a well-known endpoint and replies to each with a response bundle that returns the payload to the originator. This enables round-trip time measurement and end-to-end connectivity verification in Delay-Tolerant Networks. This document requests IANA allocation of a well-known IPN service number for the echo service. | |||||||||||||
| ESP Protection for Services over SRv6 | ||||||||||||||
|
This document describes a mechanism for protecting selected service traffic using IPsec ESP while transporting the traffic over an SRv6 domain. The approach enables service payloads to be encrypted prior to SRv6 encapsulation, allowing the SRv6 header to remain visible for segment-based forwarding within the provider network. This mechanism supports services or applications that require additional confidentiality and integrity protection, even when carried over an operator-managed SRv6 domain. | |||||||||||||
| Use Cases and Requirements for AI Agent Policy-Aware Network | ||||||||||||||
|
With the widespread adoption of AI Agents, traditional network architectures can no longer meet the demand for efficient collaboration between agents and networks. This document proposes a new paradigm of "AI Agent Policy-Aware Network", enabling three key transformations: from Flow-aware to Agent-aware, from QoS-based to Policy-intent-based, and from Network-driven to Agent-network collaborative. By defining core components such as the Agent Policy- aware Controller and Agent Policy-Aware Device, this paradigm establishes a dynamic mapping mechanism between Agent intents and network policies, supporting key scenarios including autonomous performance measurement, path optimization, SLA assurance, and secure transmission. This document outlines the background, scenarios, use cases and requirements of Agent Policy-aware Network. | |||||||||||||
| Terminology for Networking Infrastructure in the Internet of Agents | ||||||||||||||
|
The emergence of the Internet of Agents (IoA) introduces new requirements for interoperable collaboration among autonomous agents across heterogeneous networks, platforms, and administrative domains. Supporting such environments requires common understanding of infrastructure functions, collaboration mechanisms, semantic interaction, and trust-related concepts. This document defines terminology for networking infrastructure in IoA environments, with a focus on Dynamic Multi-agent Secured Collaboration (DMSC). The terminology defined in this document is intended to support consistent usage across DMSC-related architecture, framework, and protocol specifications. | |||||||||||||
| IS-IS Process ID Verification | ||||||||||||||
|
In IS-IS deployments, the process identifier (process ID) is used on a local router to distinguish and manage different IS-IS protocol instances. Process ID is local to the router and is not transmitted to neighbors, providing operational flexibility. However, because the process ID is also used to implement route redistribution and specify administrative tags for fine-grained control, its misconfiguration can lead to severe impacts (e.g., routing loops or black holes) with difficult troubleshooting. To address this problem, network operators typically deploy a consistent process ID on both ends of a link within the same domain, to reduce configuration complexity. In this context, to avoid the misconfiguration of the IS-IS process ID, this document introduces two optional approaches for process ID verification. When process ID verification is enabled, an IS-IS adjacency can be established only when the process identifiers at both ends of the link match. | |||||||||||||
| Cross-Domain OAM Problem Statement and Requirements:Across Trust Boundaries | ||||||||||||||
|
As network service deployments increasingly span multiple administrative domains—such as operator edge clouds, tenant datacenters, multi-cloud environments, and managed security services—operators lack standardized OAM (Operations, Administration, and Maintenance) mechanisms to localize faults across these trust boundaries. Existing OAM mechanisms, such as RFC 9516 for Service Function Chaining (SFC), typically assume all network elements reside within a single administrative domain. This document describes the generic problem space, typical use cases, and gaps in existing standards for cross-domain OAM across trust boundaries, and outlines the requirements for a cross-domain OAM proxy mechanism. This document is intended to provide a problem baseline and requirement definitions for the OPSAWG and the broader operations community; it does not specify protocols or data models. | |||||||||||||
| IS-IS Database Fingerprinting | ||||||||||||||
|
In large IS-IS networks it is useful to quickly verify whether the link-state databases on all routers have synchronized properly and to derive a rough metric of flooding diffusion behavior. This document proposes a lightweight database fingerprinting mechanism for IS-IS along with YANG model extensions providing easy access to such information. | |||||||||||||
| Considerations for Interpreting Packet Loss Observed by Active Performance Measurements | ||||||||||||||
|
Active performance measurement protocols and metrics are commonly used to measure packet loss, delay, delay variation, reachability, and path behavior. When an active measurement packet is not received, a response is missing, or a measurement exchange times out, the measurement result identifies the observable outcome but often does not identify the underlying cause. Loss observed by active performance measurements can be associated with congestion, queue discard, link or forwarding failures, routing changes, endpoint or reflector behavior, administrative filtering, policing, multipath effects, or validation-related packet discard such as Source Address Validation (SAV). Different operational conditions can produce similar measurement observations, but they may have different meanings and require different troubleshooting actions. This document discusses considerations for interpreting packet loss observed by active performance measurements. It provides a common set of considerations for separating measured outcomes from inferred causes, describes operational conditions that can lead to observed loss, discusses implications for one-way and two-way measurements, delay and delay variation interpretation, OWAMP, TWAMP, STAMP, and measurements over ECMP and link aggregation. It also discusses how some considerations may apply to hybrid and passive performance measurements and identifies sources of operational context that can help operators and measurement systems reason about possible explanations. | |||||||||||||
| IS-IS Packet Timestamping | ||||||||||||||
|
Many applications in today’s networks rely on reliable and timely flooding of link-state information, such as, but not limited to Traffic Engineered networks. If such link-state information is delayed it can be difficult for those applications to adequately fulfill their intended functionality. This document describes extensions to ISIS supporting distribution of fragment origination time. The origination time can be used to aid troubleshooting and/or by the applications themselves to improve their behavior. Timestamping can be also used to detect replay attack which are not addressed in IS-IS currently. | |||||||||||||
| YANG SID Discovery Using the Domain Name System | ||||||||||||||
|
CORECONF is an interface for managing YANG-modeled data using CBOR. It replaces verbose YANG schema item identifiers with compact 64-bit integers called Schema Item iDentifiers (SIDs). Interpreting a SID requires two resources: the YANG module definition and the SID dictionary (the .sid file) that maps each integer to the corresponding YANG schema item. Pre-loading every possible YANG module and its SID dictionary is not practical as the set of deployed modules grows; a dynamic discovery mechanism is therefore needed. This document specifies a DNS reverse-lookup mechanism analogous to ip6.arpa that maps a SID to a DNS name under the sid.yt. tree (where "yt" stands for YANG Tracker). Resolving that name returns TXT records pointing to the authoritative repository for the corresponding YANG module. | |||||||||||||
| Confidentiality and Authenticity Protection for Internet Email | ||||||||||||||
|
IETF review of an Applicability Statement for the core email protocols exposed considerable confusion about the applicability and effectiveness of various techniques for authenticating email and keeping messages and their various elements confidential. Equally or more important, there is confusion about the relationships among various possible methods and tools, with the documents of those methods, taken one at a time, often failing to address those relationships and the tradeoffs involved explicitly. This document describes the various approaches with their strengths and weaknesses, and provides advice about best practices under different conditions. | |||||||||||||
| DNS Work Amplification: Problem Statement,Terminology,and Taxonomy | ||||||||||||||
|
Recursive DNS resolvers are expected to bound the amount of "work" performed when answering a client query. DNS specifications discuss such bounds but leave key concepts, accounting rules, and safe limits underspecified. This leeway has led to divergent implementations and makes systematic bounding difficult, contributing to denial-of-service attacks that amplify resolver work and harm different DNS components. This document describes the problem space of DNS work amplification. It defines terminology for discussing work performed during a single resolution instance, develops a taxonomy of work-amplification vulnerabilities along resource and mechanism axes, and analyses where existing DNS specifications leave amplification-relevant behavior underspecified. The document is descriptive: it does not itself specify protocol changes or operational requirements. | |||||||||||||
| Extending Normalized Forms to String-Derived Types | ||||||||||||||
|
YANG models frequently define identifiers using string or string- derived types whose lexical space permits multiple representations of the same underlying value. This can lead to incorrect behavior when semantically equivalent values are compared lexically. This document add an optional extension to the existing YANG concept of normalized form to string-derived types whose lexical space permits multiple representations of the same underlying value. | |||||||||||||
| Best Practices for L4S implementation for Mobile Devices | ||||||||||||||
|
This document documents best practices for deployment of Low Latency, Low Loss, and Scalable Throughput (L4S) in mobile devices. It defines the responsibilities of the host operating system, the link- layer (modem and WiFi) subsystems to ensure successful end-to-end low-latency communication. | |||||||||||||
| IOAM Data Fields for Firewall and Security Metadata | ||||||||||||||
|
This document defines a new IOAM Namespace and associated Data Fields for carrying firewall and security-related metadata within the In- situ Operations, Administration, and Maintenance (IOAM) framework (RFC 9197). The mechanism allows each security Enforcement Point on a path to attach a verifiable attestation of the action it took on a packet. This lets downstream Enforcement Points and other nodes confirm that security policy was actually executed on the data path -- detecting policy bypasses and detecting divergence between Enforcement Points that are expected to agree -- while each Enforcement Point continues to apply its own policy independently rather than delegating enforcement. This validation of execution complements the management plane's validation of intent. The metadata also enables real-time signaling of policer states for DDoS mitigation. To ensure the authenticity and integrity of this information, this document leverages the integrity protection mechanisms defined in the IOAM data integrity specification (draft- ietf-ippm-ioam-data-integrity). | |||||||||||||
| Geneve-based Firewall Metadata for Overlay Networks | ||||||||||||||
|
This document specifies a mechanism for embedding security-related metadata within the Geneve header (RFC 8926). It allows a security Enforcement Point to attach a cryptographically signed, verifiable attestation of how it handled a packet, so that downstream Enforcement Points and tunnel endpoints can confirm that security policy was actually executed on the data path -- detecting policy bypasses and divergence between Enforcement Points that should agree -- while each Enforcement Point continues to enforce its own policy independently. This validation of execution complements the management plane's validation of intent. The document presents two operational models. The primary model is the "End-to-End Attestation Model", fully compliant with RFC 8926, where an ingress tunnel endpoint adds and cryptographically signs metadata, and an egress endpoint verifies it. This enables downstream nodes to verify and audit that policy was executed consistently, while still applying their own policy independently. The second part of this document presents a proposal for a future extension to the Geneve standard. This proposed extension would allow trusted transit devices to participate in the metadata chain, enabling a hop-by-hop "chain of custody" for enhanced, real-time security responsiveness within the data center fabric. | |||||||||||||
| User-Mediated Credential Delivery as a Complementary Authorization Primitive for AI Agents | ||||||||||||||
|
This document proposes user-mediated credential delivery as a complementary authorization primitive for AI agent frameworks. Rather than delivering credentials through automated channels controlled by the agent or its platform, user-mediated delivery places the authorization decision and credential delivery in the user's trusted context, separate from the agent's execution environment. This document describes four methods: user-mediated credential delivery, self-describing connection credentials, caller-identity consent differentiation, and discovery-by-introspection. These methods address the human-in-the-loop gap identified in Section 9.7 of [KLRC] and strengthen the authorization foundation that the IETF AI Agent Authentication and Authorization framework depends on. The methods described in this document are patent pending. | |||||||||||||
| Social Architecture Diagnostic Profile: A JSON-Based Format for Exchanging Diagnostic Descriptions of Socio-Technical Environments | ||||||||||||||
|
This document specifies the Social Architecture Diagnostic Profile (SADP), a JSON-based format for exchanging diagnostic descriptions of socio-technical environments. A profile records the object under review, the evidence used, the diagnostic dimensions applied, identified breaks or tensions, limitations, confidence levels, and human-review requirements. The format is intended for research tools, educational systems, expert-review workflows, case repositories, and other systems that need portable and inspectable diagnostic descriptions. This document does not define a scoring standard, certification procedure, legal assessment process, psychological assessment process, or automated consequential decision process. | |||||||||||||
| Network Time Protocol Version 5 | ||||||||||||||
|
The Network Time Protocol (NTP) is a widely deployed protocol that allows hosts to obtain the current time of day from time servers. This document specifies version 5 of the protocol (NTPv5), which adopts a client-server model as its sole mode of operation. Legacy operational modes supported in earlier versions have been removed to improve protocol robustness and clarity. While this specification defines the protocol used for time distribution, it does not define the algorithms or heuristics employed by clients to determine or adjust their local time. | |||||||||||||
| OAuth 2.0 for First-Party Applications | ||||||||||||||
|
This document defines the Authorization Challenge Endpoint, which supports clients that want 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. | |||||||||||||
| The Internet Standards Process | ||||||||||||||
|
This memo documents the process used by the Internet community for the standardization of protocols and procedures. It defines the stages in the standardization process, the requirements for moving a document between stages, and the types of documents used during this process. It also addresses the intellectual property rights and copyright issues associated with the standards process. This document obsoletes RFC 2026, RFC 5657, RFC 6410, RFC 7100, RFC 7127, RFC 8789, and RFC 9282. It also includes the changes from RFC 7475. If this document and [_2418bis] are published as RFCs, then taken together the two of them make RFC 7475 obsolete. | |||||||||||||
| Explicit RDAP Redirects | ||||||||||||||
|
This document describes an RDAP extension that allows RDAP clients to request to be redirected to a related RDAP record for a resource. | |||||||||||||
| A Profile for Resource Public Key Infrastructure (RPKI) Canonical Cache Representation (CCR) | ||||||||||||||
|
This document specifies a Canonical Cache Representation (CCR) content type for use with the Resource Public Key Infrastructure (RPKI). CCR is a Distinguished Encoding Rules (DER) encoded data interchange format which can be used to represent various aspects of the state of a validated RPKI cache at a particular point in time. The CCR profile is a compact and versatile format, well-suited for a variety of applications, for example, audit trails, analytics pipelines, and validated payload dissemination. | |||||||||||||