IETF Internet-Drafts & RFCs — last 48 hours

Defines the "internal" top-level domain reserved for use in private applications. It is intended as a name space that organizations can use internally without risk of collision with the public DNS, giving operators a stable, dedicated TLD for names that are never meant to resolve on the global Internet.

By its name, this is a PIM WG YANG data model that extends IGMP/MLD snooping configuration and state for use in L2VPN deployments, so that snooping behaviour on bridged/VPLS-style services can be managed through NETCONF/RESTCONF. The document's official abstract could not be retrieved on this run, so this description is approximate and will be grounded on the next execution.

Proposes a two-layer reference architecture for discovering the minimum public information needed to reach AI agents. The first (intra-domain) layer handles discovery inside a single organization using mDNS, DNS-SD or infrastructure-assisted methods. The second (inter-domain) layer handles cross-organization discovery, using DNS by default with gateways that filter what leaves a site, publish approved records in their own DNS zones, and fetch, validate and cache remote records. It also describes optional non-DNS mechanisms and mixed deployments adding proactive distribution, scoped sharing and directory lookup.

Describes a gateway capability-directory framework for Internet of Agents deployments that maintain persistent capability views and exchange selected information across gateways. It defines requirements for Agent Capability Specifications (ACSs), derived Capability Digests, lifecycle state, provenance, validation and synchronization, and clarifies authority-scoped revisions, remaining-lifetime preservation, withdrawal handling, partial views and recovery after disconnection or state loss. It distinguishes source descriptions from gateway-accepted objects and directory visibility from semantic compatibility, authorization and execution admission. It deliberately does not define a discovery query protocol, ranking algorithm, storage substrate, distributed lookup, synchronization wire format, orchestration or session protocol.

Defines an ontology-based semantic profile for expressing capabilities, intents, tasks and domain context in agent interactions. It specifies a core vocabulary, a JSON-LD serialization profile and processing rules for determining semantic compatibility using explicit identifiers, constraints and accepted alignment artifacts. Descriptive metadata and candidate mappings are kept separate from the semantic values used in decisions. The profile can ride on existing discovery and interaction mechanisms but does not define authorization, transport, session or directory synchronization, and deterministic processing is limited to the declared profile, versions, constraints and accepted mappings.

Specifies a centralized control-plane realization of Computing-Aware Traffic Steering (CATS). A logically centralized CATS Path Selector (C-PS) receives a service request from an ingress forwarder and selects an eligible service instance using both computing and network information; only then does it ask a path-computation function (PCE) for a path to the chosen destination. The C-PS returns a steering binding that ingress and egress forwarders use to redirect the first packet to the selected instance. Subsequent packets follow the installed binding and return traffic uses a matching reverse binding.

Specifies DKIM2, which lets a person, role or organization that owns a signing domain demonstrate that it handled an email. The signer hashes the message's current contents and signs those hashes together with transmission details, and verifiers fetch the public key from the signing domain's DNS. Systems that modify a message record their changes and add new hashes and signatures, forming a chain receivers can check so verifiers can see what intermediaries changed and assign reputation accordingly. DKIM2 also helps recipients detect unexpected replays and ensures delivery status notifications go only to entities involved in delivering the message.

A reference for multicast operators running different replication technologies, helping them compare options and trade-offs when configuring redundant ingress router failover. It notes that RFC 9026 covers the hot root standby approach for MVPN networks, and extends that discussion to other multicast deployments. It then compares cold, warm and hot standby modes, covering their benefits, drawbacks and deployment factors so operators can choose an approach suited to their network.

Defines a BIER proxy function to support a single BIER sub-domain spanning multiple underlay routing-protocol regions (Autonomous Systems or IGP areas). A new BIER proxy range sub-TLV is defined to redistribute BIER BFR-id information across those routing regions, allowing BIER multicast state to be stitched together where it would otherwise be confined to one region.

Updates DMARC (RFC 9989) to work with DKIM2, so that DKIM2 can validate email relayed and modified by multiple servers. It separates a domain's enforcement policy from the validation rules that are applied, and lets mail servers declare DKIM2 support in their DMARC DNS records to help prevent downgrade attacks against DKIM2-capable paths.

Extends STAMP (RFC 8762) and its optional extensions (RFC 8972) to measure the residual bit error rate on a path. It observes that networks can experience transmission bit errors and that some escape CRC and FEC detection and correction (residual bit errors). The document extends the RFC 8972 mechanism to carry and measure these errors within the "Extra Padding" TLV of STAMP-Test packets, giving operators an active-measurement view of residual errors.

Builds on the JMAP base protocol (RFC 8620), which lets clients upload and download arbitrary binary data called "blobs" usable by all other JMAP extensions. This extension adds a method to expose blobs as a filesystem, along with the kinds of metadata provided by other remote filesystem protocols, so that JMAP data can be navigated and manipulated with familiar file-and-folder semantics.

Defines the Custody Receipt Block, a Bundle Protocol Version 7 (BPv7) extension block that carries a chain of signed custody receipts inside the bundle they describe. Each node acting as a custodian adds one receipt recording that it held the bundle, which node it came from, and when it received and forwarded it; nodes that do not implement the block forward it unchanged. A verifier holding the custodians' public keys can later check the chain and report any segment of the route with no receipt. The receipts serve as evidence for accounting and dispute resolution between operators and are not BPv7 administrative records, nor do they replace or change custody-transfer signaling.

Defines FoodBlock, a compact data format and set of checking rules for food records covering what was made, moved, promised or allowed, and by whom. Each record is a signed block of three fields (type, state and refs) whose identity is the hash of its canonical bytes, produced under a strict canonicalization profile built on RFC 8785; authors link their blocks into per-key chains. This core document specifies the block, canonical form, signature suites, chain, messages and the validity check, while identity, consent, promises, privacy and node exchange are left to separate modules.

Addresses how hosts validate the quoted invoking packet in ICMP error messages, whose resistance to blind off-path forgery depends on the quoted information and receiver state. It proposes a Challenge-Confirm mechanism that, after an eligible error passes existing checks, marks the flow and adds an unpredictable token in an IPv4 option on a later packet; a subsequent ICMP error can return it by quoting it, with no immediate probe sent. The token is derived from a host-local secret, so no keys are shared and no per-challenge nonce cache is needed. Successful validation shows only possession of a valid token, not router authentication or the correctness of the error, and the document covers bounded triggering, replay limits and option-traversal concerns.

Defines FoodBlock, a compact data format and set of checking rules for food records covering what was made, moved, promised or allowed, and by whom. Each record is a signed block of three fields (type, state and refs) whose identity is the hash of its canonical bytes, produced under a strict canonicalization profile built on RFC 8785; authors link their blocks into per-key chains. This core document specifies the block, canonical form, signature suites, chain, messages and the validity check, while identity, consent, promises, privacy and node exchange are left to separate modules.

Defines the Custody Receipt Block, a Bundle Protocol Version 7 (BPv7) extension block that carries a chain of signed custody receipts inside the bundle they describe. Each node acting as a custodian adds one receipt recording that it held the bundle, which node it came from, and when it received and forwarded it; nodes that do not implement the block forward it unchanged. A verifier holding the custodians' public keys can later check the chain and report any segment of the route with no receipt. The receipts serve as evidence for accounting and dispute resolution between operators and are not BPv7 administrative records, nor do they replace or change custody-transfer signaling.

Notes that a request often traverses several services before reaching an API, and that OAuth Token Exchange can record that actor history in nested act claims but leaves open how to build the history, how much to disclose, and how to verify an actor's own signature. Actor Chain proposes rules for those gaps while keeping the Authorization Server in charge of issuing tokens and applying policy. The draft records that the work began in SPICE in February 2026, and that a companion protocol specification defines its wire formats and processing requirements.

Defines how to use the NIST Secure Hash Standard in HMAC mode for RSVP Cryptographic Authentication version 2. Together with draft-ietf-teas-rsvp-auth-v2, this work obsoletes RFC 2747 and RFC 3097, modernizing the integrity protection used for RSVP signaling.

Describes MUSUBI settlement as a deterministic function that takes a two-party contract, the signed records of an agent's actions under that contract, and a view of Bitcoin block headers, then determines whether the recorded actions stayed within the contract's grant. Anyone with the same inputs can recompute the result without trusting the party that produced it. The document specifies one part of this function, "settle core v0", in enough detail for a second implementation, and states that settlement is neither runtime enforcement nor a judgment of liability.

Observes that software agents act for people (buying, booking, cancelling) but the records of those actions sit with the payment rails and marketplaces, not with the person. It proposes the Agent Act Receipt, a per-act record the agent writes as digests tied to a continuity handle; a transparency service signs each record, chains it and publishes dated anchors, and the person can export the signed record to take to another agent. It makes no claim of trust, certification or adoption: a receipt shows only that the service's key signed a digest at a stated time, not that the act occurred as described.

Notes that advertising participation in IGP Flexible Algorithm (Flex-Algo) requires an associated dataplane context, and introduces a "soft dataplane" for cases where the existing defined dataplanes are not appropriate. The document defines how to advertise that soft-dataplane context in the IGP so that Flex-Algo can be used where no conventional dataplane identifier fits.

Addresses how HTTP transfers can be interrupted by cancelled requests or dropped connections. If the recipient can report how much data it processed before the interruption, the sender can resume from that point instead of resending everything. The document observes that HTTP range requests already allow resumable downloads from server to client, and defines a mechanism for resumable uploads from client to server.

Proposes a framework for hardware-rooted cryptographic attestation in the Precision Time Protocol (PTP). It argues that PTP's current symmetric keys let any node holding the shared secret impersonate a Grandmaster, undermining source non-repudiation. The tiered model uses a hardware root such as a TPM to establish a long-term post-quantum identity, while a workload-identity system such as SPIFFE/SPIRE rotates short-lived operational keys. Those keys sign batches of PTP messages via Merkle Trees, aiming to preserve wire-speed synchronization while providing verifiable provenance for regulated environments.

Introduces AER-1, a compact vocabulary for recording one AI agent tool call as a receipt that others can check independently. Each receipt identifies the execution, its timestamp, the canonical bytes behind the output commitment, the tool and caller scope, and a provenance class, and can be retrieved at a stable public URL. It also covers workflow receipts, which link ordered step receipts under a Merkle root, and hash-chained job timelines. The abstract notes that much of the document's remaining text is a revision-by-revision changelog rather than a description of the format.

Describes extensions to BGP for distributing a BIER-TE path, that is, a path for per-packet stateless point-to-multipoint multicast. It defines a new BGP Tunnel Type that carries the information needed to encode such a path, allowing BIER Tree Engineering paths to be advertised and installed through BGP.

Describes a mechanism for sending SR-MPLS Adjacency SIDs that are tied to a specific algorithm from controllers to headend routers. The distribution is carried out over BGP Link-State (BGP-LS), so that algorithm-specific adjacency segments can be learned by a controller and programmed onto the devices that originate SR paths.

Notes that the SR policy architecture defines the Prefix-SID algorithm, which carries an algorithm identifier in its advertisement, but does not cover cases where multiple algorithms share the same link resources. The draft therefore proposes including the algorithm identifier in Adjacency-SID advertisements, so that adjacency segments can be associated with a particular IGP algorithm.

Explains that Tree Engineering for BIER (BIER-TE) shares its architecture and packet formats with BIER, but that each bit position in a BIER-TE BitString maps to one or more network adjacencies, and that a Path Computation Element (PCE) can derive the BIER-TE path. The document specifies extensions to the Path Computation Element Protocol (PCEP) that let a PCE compute and initiate these BIER-TE paths.

Describes Bit Index Explicit Replication (BIER), which delivers multicast across a BIER domain without intermediate routers keeping per-flow state or running a tree-building protocol: ingress routers add a header whose bitstring marks the egress routers that should receive each packet. It notes that BGP Link-State lets a controller gather topology data, compute forwarding tables and push them to routers across inter-AS and intra-AS deployments. The document extends the BGP-LS address family to advertise BIER information.

Explains that Tree Engineering for BIER (BIER-TE) shares its architecture and packet formats with BIER and, like BIER, forwards and replicates packets using a BitString in the header, but with each bit position mapping to one or more adjacencies. The document specifies BGP extensions for advertising BIER-TE-specific information so that tree-engineered multicast paths can be distributed via BGP.

Defines a way to collect the configuration and state of SR Policies that include a candidate path's validity-control parameters, using BGP Link-State (BGP-LS) updates. External components could use this information for tasks such as path computation, re-optimization and service placement.

Introduces Path Computation Element Communication Protocol (PCEP) extensions that carry the validity-control settings for a candidate path belonging to a Segment Routing (SR) Policy. The abstract is a single sentence and does not describe the specific parameters or message formats.

Proposes enhancements to BGP for conveying the validity-control settings of an SR Policy's candidate path. The abstract is a single sentence and does not elaborate on the mechanism.

Extends the Path Computation Element Communication Protocol (PCEP) to support SID verification in SR-MPLS networks. It adds a flag to the SR-ERO subobject telling the Path Computation Client (PCC) that the Path Computation Element (PCE) has explicitly requested SID verification, and defines the associated capability-exchange mechanisms.

A single-sentence specification that defines the semantics of the 402 (Payment Required) HTTP status code, giving the long-reserved status code a concrete, interoperable meaning.

Explains that DKIM2 lets an organization controlling a signing domain claim responsibility for a message by attaching a digital signature that links the domain to it: the domain owner publishes a public key in DNS and the matching private key signs the messages, while verifiers query the signer's domain for the correct public key. The document describes the DKIM2 DNS record format and how to locate that record.

Defines a narrow, deterministic conformance profile called eqr-core-1, with test vectors, for Evidence Qualification Receipts. The profile checks receipt structure, digest and timestamp formatting, evidence-reference integrity and requirement-state derivation, producing a PASS, FAIL or INDETERMINATE result. Conformance does not establish that evidence is true, that a claim is scientifically valid, that an issuer is trustworthy, or that an action is authorized; the goal is interoperable checking of receipt semantics rather than proof of substantive truth.

Defines a narrow, deterministic conformance profile called eqr-core-1, with test vectors, for Evidence Qualification Receipts. The profile checks receipt structure, digest and timestamp formatting, evidence-reference integrity and requirement-state derivation, producing a PASS, FAIL or INDETERMINATE result. Conformance does not establish that evidence is true, that a claim is scientifically valid, that an issuer is trustworthy, or that an action is authorized; the goal is interoperable checking of receipt semantics rather than proof of substantive truth.

Presents the Zero Trust Intelligence Protocol (ZTIP), an open, transport-independent protocol for governing AI agent transactions. Each agent action must be authorized by policy before it runs, protected by a hash over a canonical form, and confirmed complete by an authority separate from the actor that performed the work; an executor's claim of success is treated as mere attestation that never alone satisfies a required check. This revision clarifies what integrity verification does not establish and sets fail-closed rules for verifying multiple envelopes together.