IETF Internet-Drafts & RFCs

Describes the "internal" top-level domain, reserved for use in private applications. The TLD gives operators a dedicated namespace for names that should stay inside private networks and are not meant to be resolved in the global DNS, avoiding collisions with real delegated TLDs.

By its name, this PIM Working Group draft probably defines a YANG data model extending IGMP and MLD snooping configuration and operational state to Layer 2 VPN (L2VPN) deployments. The official abstract could not be retrieved on this run, so this description is based on the document name and is approximate; it will be grounded from the abstract on the next run.

Proposes a two-layer reference architecture for discovering the minimum public information needed to reach AI agents. The first layer handles discovery within a single organization using mDNS/DNS-SD or infrastructure-assisted methods; the second handles cross-domain discovery with DNS as baseline. Gateways apply export policies, publish permitted data in each organization's own DNS zones, and fetch, validate and cache remote data on demand. Optional non-DNS mechanisms and mixed-mode deployments add proactive distribution, recipient-specific sharing and directory lookup.

Describes a framework for gateway-managed capability directories in Internet of Agents deployments, where gateways keep persistent capability views and share selected information with each other. It sets requirements for Agent Capability Specifications, derived digests, lifecycle state, provenance, validation and synchronization, including scoped revisions, remaining validity, withdrawals, partial views and recovery. It separates raw source descriptions from gateway-accepted objects, and directory visibility from semantic fit, authorization and execution approval. Discovery queries, ranking, storage, wire formats and session protocols are explicitly out of scope.

Defines an ontology-based semantic profile for expressing capabilities, intents, tasks and domain context in agent interactions. It includes a core vocabulary, a JSON-LD serialization and rules for judging semantic compatibility using explicit identifiers, constraints and accepted alignment artifacts. It separates descriptive metadata and candidate mappings from the values actually used in decisions, and works alongside existing discovery and interaction mechanisms. It does not define an authorization, transport, session or directory synchronization protocol, and deterministic processing is limited to the declared profile rather than arbitrary natural language.

Describes a centralized control-plane design for Computing-Aware Traffic Steering (CATS). A logically centralized Path Selector (C-PS) works with ingress and egress forwarders, mapping a client's service request to a suitable service instance using computing and network data, then asking a path-computation function for a route to that instance. The C-PS returns a steering binding to the ingress forwarder, which rewrites the destination and encapsulates the first packet; the egress forwarder decapsulates and delivers it. Subsequent packets reuse the installed binding and return traffic follows a matching reverse binding.

By its name, this DKIM Working Group draft is probably the core specification of DKIM2, the next-generation evolution of DomainKeys Identified Mail designed to authenticate email that is relayed and modified across multiple mail servers. The official abstract could not be retrieved on this run, so this description is based on the document name and its companion DKIM2 drafts (DNS record and DMARC extensions) seen in this window; it will be grounded from the abstract on the next run.

A guide for multicast network operators, across different replication technologies, on the options and trade-offs of redundant ingress router failover. It notes that Section 5 of RFC 9026 covers hot root standby for MVPNs and extends the discussion to other multicast deployments. It compares cold, warm and hot standby modes, setting out their advantages, limitations and deployment considerations so operators can choose an approach suited to their network.

Defines a BIER proxy function that lets a single BIER sub-domain span multiple underlay routing 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, so that Bit Index Explicit Replication can operate end to end even when the underlying topology is partitioned into separate routing domains.

Updates DMARC (RFC 9989) to work with DKIM2. Because DKIM2 verification can handle email relayed and modified across multiple mail servers, the draft extends DMARC to cover those cases. It separates DMARC's enforcement policy from the validation rules, which currently center on From-header alignment, and lets mail servers declare DKIM2 support in their DMARC DNS records, providing a mechanism that helps protect DKIM2 against downgrade attacks.

Notes that STAMP (RFC 8762), with optional extensions in RFC 8972, supports active network measurement. Transmission bit errors, often caused by factors such as poor fibre quality, can escape CRC and FEC detection and correction and become residual bit errors. The document extends the RFC 8972 extensions so that residual bit error rate can be measured within the Extra Padding TLV of STAMP test packets.

Notes that the JMAP base protocol (RFC 8620) already supports uploading and downloading arbitrary binary data, called "blobs", which other JMAP extensions can use. This draft adds a method that presents those blobs as a filesystem, exposing the kinds of metadata that other remote filesystem protocols provide, so JMAP clients can browse and manage stored files in a familiar hierarchical way.

Defines the Custody Receipt Block, a BPv7 extension block that carries a chain of signed receipts inside the bundle it describes. Each node acting as a custodian adds a receipt recording that it held the bundle, where it came from, and when it received and forwarded it; nodes that do not implement the block pass it along unchanged. A verifier holding the custodians' public keys can later check the chain and report any part of the route with no receipt. The receipts serve as evidence for accounting and dispute resolution between operators, and are not BPv7 administrative records.

Describes FoodBlock, a small data format with rules for checking food records covering what was made, moved, promised or permitted, and who did it. Each record is a block of three parts (type, state and refs) signed by its author, and its identity is a hash of its canonical bytes following the JSON Canonicalization Scheme with a stricter profile. Authors link their blocks into per-key chains. The core specification covers the block, canonical form, signature suites, chains, messages and the validity check, while identity, rotation, consent, promises, privacy and node exchange are handled in separate modules.

Observes that ICMP error messages help hosts manage traffic, and that validating the quoted original packet matters but may not stop forged errors from off-path senders. It proposes a Challenge-Confirm mechanism: after an error passes existing validation, the host flags the flow and places an unpredictable token in an IPv4 option on a later outgoing packet. A subsequent ICMP error that quotes that packet can return the token, which the host verifies against a locally kept secret, with no shared keys or per-challenge state. A valid token only shows the sender had access to it; it does not verify the router's identity or the error's meaning.

Describes FoodBlock, a small data format with rules for checking food records covering what was made, moved, promised or permitted, and who did it. Each record is a block of three parts (type, state and refs) signed by its author, and its identity is a hash of its canonical bytes following the JSON Canonicalization Scheme with a stricter profile. Authors link their blocks into per-key chains. The core specification covers the block, canonical form, signature suites, chains, messages and the validity check, while identity, rotation, consent, promises, privacy and node exchange are handled in separate modules.

Defines the Custody Receipt Block, a BPv7 extension block that carries a chain of signed receipts inside the bundle it describes. Each node acting as a custodian adds a receipt recording that it held the bundle, where it came from, and when it received and forwarded it; nodes that do not implement the block pass it along unchanged. A verifier holding the custodians' public keys can later check the chain and report any part of the route with no receipt. The receipts serve as evidence for accounting and dispute resolution between operators, and are not BPv7 administrative records.

Notes that a request may pass through several services before reaching an API, and that OAuth Token Exchange can record a chain of actors in nested act claims but does not define how to build the chain, how much to reveal, or how to check each actor's own signature. This document gives an overview of the Actor Chain proposal that fills those gaps while leaving the Authorization Server in charge of issuing tokens and enforcing policy. A companion specification covers wire formats and processing rules; the work began in SPICE in early 2026.

Specifies use of the US NIST Secure Hash Standard in HMAC mode for RSVP message authentication. Together with draft-ietf-teas-rsvp-auth-v2, this document obsoletes RFC 2747 and RFC 3097, modernizing the cryptographic integrity and authentication mechanisms used to protect RSVP signaling.

Describes MUSUBI settlement as a deterministic function. It takes a contract signed by two parties, signed records of an agent's actions under that contract, and Bitcoin block header data, then checks whether the recorded actions stayed within the contract's grant. Because the computation is deterministic, anyone with the same inputs can reproduce the result without relying on the party that generated it. The document specifies one part, "settle core v0", in enough detail for a second implementation to be built from the text and test vectors, and states that settlement is neither runtime enforcement nor a judgement of liability.

Argues that software agents act for people (buying, booking, cancelling) but each payment rail or marketplace keeps its own record and the person has none. It proposes the Agent Act Receipt, a signed record with one entry per action: the agent writes the entry as digests tied to a continuity handle, a transparency service signs it, adds it to a hash chain and publishes dated anchors, and the person can export the record as a signed "switch pack" to carry to another agent. A receipt only shows that the service's key signed a digest at a stated time, not that the act happened as described.

Observes that advertising IGP Flex-Algo participation requires a dataplane context. It defines a "soft dataplane" for cases where the existing defined dataplanes are not suitable, giving Flexible Algorithm advertisements a usable dataplane identifier in those scenarios.

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

Proposes a scalable way to add hardware-rooted cryptographic attestation to the Precision Time Protocol. It argues that today's symmetric-key PTP security lets any node holding the shared secret pose as a Grandmaster clock, undermining auditability. The fix is a tiered trust model: a hardware root of trust holds a long-term post-quantum identity, a workload identity system rotates short-lived operational keys, and those keys sign batches of PTP messages through a Merkle tree. The aim is to keep synchronization at wire speed while providing verifiable time provenance for regulated environments.

Introduces AER-1, a small vocabulary for recording a single AI agent tool call as a portable receipt anyone can verify independently. Each receipt identifies the execution, records when it occurred, preserves the bytes used for the output commitment, names the tool and caller scope, carries a provenance class, and can be retrieved at a stable public URL. It keeps what the system observed separate from claims about the outside world, and who ran an action separate from the record itself. It also covers workflow receipts binding ordered step receipts to a goal via a Merkle root, and hash-chained job timelines; a reference implementation is deployed.

Describes extensions to BGP for distributing a Bit Index Explicit Replication Traffic/Tree Engineering (BIER-TE) path. A new Tunnel Type for a BIER-TE path is defined to encode the information about that path, letting controllers and routers advertise and install engineered BIER-TE trees through BGP.

Describes a mechanism to distribute SR-MPLS algorithm-related Adjacency SIDs from controllers to headend routers using BGP-LS, so that algorithm-specific adjacency segments can be advertised to the devices that need them for Segment Routing path computation and steering.

Notes that the Segment Routing policy architecture already carries an algorithm identifier in Prefix-SID advertisements, but this does not address scenarios where multiple algorithms share the same link resources. To close that gap, the draft proposes adding the algorithm identifier to Adjacency-SID advertisements in the IGP, so adjacency segments can be associated with a particular algorithm.

Introduces Tree Engineering for BIER-TE, which uses the same architecture and packet formats as BIER but maps each bit position to one or more network adjacencies instead of destinations, so a PCE can compute the resulting path. The document then defines PCEP extensions that let a PCE calculate and initiate these BIER-TE paths.

Extends the BGP Link-State (BGP-LS) address family so it can advertise BIER information. BIER delivers multicast traffic across a domain without intermediate routers keeping per-flow state or running a tree-building protocol; ingress routers attach a bitstring header where each bit identifies an egress router. With BGP-LS, a controller can gather topology data, compute forwarding tables and push them to routers, useful in both inter-AS and intra-AS networks.

Notes that BIER-TE shares its architecture and packet formats with BIER, forwarding and replicating packets using a BitString in which each BitPosition maps to one or more adjacencies. The document describes BGP extensions for advertising BIER-TE-specific information so that engineered BIER trees can be distributed via BGP.

Describes a way to collect the configuration and state of SR policies that carry candidate-path validity control parameters, using BGP Link-State (BGP-LS) updates. External components can then use this information for tasks such as path computation, re-optimization and service placement.

Defines PCEP extensions for signaling the validity control parameters of a candidate path for an SR Policy, so a PCE and PCC can exchange the conditions under which a candidate path is considered valid.

Defines extensions to BGP to distribute the validity control parameters of a candidate path for an SR Policy, allowing those validity conditions to be carried in BGP SR Policy advertisements.

Defines extensions to PCEP for SID verification in SR-MPLS networks. It adds a flag to the SR-ERO subobject that lets the PCE explicitly ask the PCC to verify SIDs, and defines capability-exchange mechanisms so the two ends can agree on support for this verification.

Defines semantics for the 402 (Payment Required) HTTP status code, giving a precise specification for a status code that has long been reserved but underspecified, so that payment-related interactions over HTTP can be expressed interoperably.

Introduces the updated DKIM2 standard, which lets an organization that owns a signing domain claim responsibility for a message by publishing a public key in DNS and signing messages with the matching private key; receivers verify by querying the signer's domain for that key. The document specifies the DKIM2 DNS record format and how to locate the record.

Defines a deterministic conformance profile and test-vector corpus for Evidence Qualification Receipts, called eqr-core-1. The profile makes checks such as strict JSON structure, SHA-256 digest encoding, UTC timestamp handling, evidence-reference integrity and requirement-state derivation reproducible through a closed algorithm returning PASS, FAIL or INDETERMINATE. It is intentionally narrow: conformance does not show that evidence is true, that a proposition is valid, that an issuer is trustworthy, or that an action is authorized. The goal is interoperable verification of receipt semantics, not promotion of conformance into substantive truth.

Defines a deterministic conformance profile and test-vector corpus for Evidence Qualification Receipts, called eqr-core-1. The profile makes checks such as strict JSON structure, SHA-256 digest encoding, UTC timestamp handling, evidence-reference integrity and requirement-state derivation reproducible through a closed algorithm returning PASS, FAIL or INDETERMINATE. It is intentionally narrow: conformance does not show that evidence is true, that a proposition is valid, that an issuer is trustworthy, or that an action is authorized. The goal is interoperable verification of receipt semantics, not promotion of conformance into substantive truth.

Describes the Zero Trust Intelligence Protocol (ZTIP), an open, transport-neutral protocol for governed AI agent transactions. It defines five immutable JSON envelope types and a transaction lifecycle in which each agent-initiated action must be authorized by policy before execution, protected by a hash over a canonical form, and verified as complete by an authority independent of the actor that did the work. An executor's claim of success counts only as attestation and never satisfies a required verification check. This revision clarifies what integrity verification does not establish and sets fail-closed rules for verifying envelopes together.

Proposes a companion format that links two fixed software-artifact commitments to attribution and versioned claims. It defines the exact bytes to be signed, keeps trust and freshness checks separate, and describes how claims are made, verified and bounded in operational state. It targets provenance maintainers, release operators and security reviewers, and relies on existing IETF canonicalization and signature standards rather than a new cryptographic primitive. The author notes that a complete operational profile, independently authenticated trust and current-state evidence, and a verified field deployment are still required before implementation readiness can be claimed.

Argues that a verifier result reports only what a check returned, not whether the check could have returned anything else; a check reading too few fields, or whose rejecting input never occurs, can produce the same accepting result as one that really discriminates, and a conformance matrix hides the difference. The document sets out two requirements: showing that a check has been exercised into its rejecting outcome, and completeness claims. A result must name the set of records it claims to cover and must not rely only on an interested party. It defines no wire format, token or test harness, but says a record must be able to express certain facts.

Points out that the IP mobility procedures in RFC 9721 for EVPN-IRB link IP and MAC mobility sequence numbers, so when one IP moves among several IPs bound to the same MAC this causes heavy control-plane churn. The authors propose separate sequence-number spaces for MAC-IP and MAC-only routes, so one IP move produces a constant number of BGP updates (from O(N) to O(1)) instead of one that grows with the number of IPs on the MAC. The approach stays compatible with RFC 9721 implementations and describes an upgrade path from RFC 7432 deployments.

Defines ASN.1 structures that can carry attestation data in PKCS#10 and CRMF certificate requests. Certification Authorities sometimes require certificate signing requests to include verifiable information showing policy compliance, such as proof that a private key is protected by a hardware security module and cannot be exported; gathering and checking that information is called remote attestation. The document supports both standard and long-used proprietary attestation formats, especially for private-key protection.

By its name, this individual draft probably discusses enterprise deployment considerations for machine-type communications (MTC), likely in the context of the PLANTS effort. The official abstract could not be retrieved on this run, so this description is based on the document name and is approximate; it will be grounded from the abstract on the next run.

Defines nine quantum-resistant key exchange algorithms for TLS 1.3 based on HQC-KEM, the code-based KEM NIST selected for standardization in FIPS 207: three standalone variants, two combined with X25519 or X448, two combined with ML-KEM, and two combined with both ML-KEM and X25519 or X448. Because HQC-KEM rests on different hardness assumptions than lattice-based ML-KEM, the algorithms add diversity that could limit damage from future lattice cryptanalysis or implementation flaws. They are intended for TLS 1.3, DTLS 1.3 and QUIC, with hybrids following the general hybrid key exchange construction for TLS 1.3.

Extends JMAP so clients and servers can attach metadata to objects of existing data types. For each listed type the server adds a shared property and a per-user property, whose keys are namespace names either registered with IANA or domain names owned by a vendor, letting vendors define their own schemas without prior coordination. Because metadata is an ordinary property of the object, existing JMAP methods handle reading, changing, syncing and searching it.

Introduces AER-1, a small vocabulary for recording a single AI agent tool call as a portable receipt anyone can verify independently. Each receipt identifies the execution, records when it occurred, preserves the bytes used for the output commitment, names the tool and caller scope, carries a provenance class, and can be retrieved at a stable public URL. It keeps what the system observed separate from claims about the outside world, and who ran an action separate from the record itself. It also covers workflow receipts binding ordered step receipts to a goal via a Merkle root, and hash-chained job timelines; a reference implementation is deployed.

Addresses freshness of attestation evidence carried in a Certificate Signing Request, which is usually established with a nonce the Attester includes in the Evidence, obtained from a Relying Party or Verifier. The document specifies how an end entity requests that nonce from an RA/CA through certificate lifecycle protocols, defining message formats and protocol bindings for CMP, EST and CMC, including optional type-specific information needed to produce fresh Evidence.

Introduces RepSec, a protocol that makes stolen or unauthorized data copies less useful. It operates independently of traditional perimeter and access-control security models, allowing data to function only when attestation and environment checks pass. The aim is to reduce misuse, resale value and damage from compromised data while keeping legitimate use unaffected.

Proposes a lab benchmarking method for checking whether an AI agent's persisted memory has been changed, removed, reordered, replayed or forged at the storage layer, and whether the agent then refuses or flags that memory before use. It defines nine storage-level edits, three verdict classes, a read-time versus audit-time distinction, three control cases and a scoring rule, modeled on RFC 2544 and RFC 8239, as a test method for a "Protection of Memory Data Integrity" metric. This revision adds a ninth edit (whole-store rollback to an older genuine copy), reports 31 result rows on released memory subsystems, and describes a machine-readable record that lets outside parties recompute results.

By its name, this individual draft is probably the architecture document of the DIEM (digital emblem) effort, a companion to the ADEM core and DNS drafts also posted in this window. The page returned no abstract on this run, so this description is based on the name and the related documents and is approximate; it will be grounded on the next run.

States that the ADEM Core Specification defines the message format and authorization model for digital, distinctive emblems. This document specifies how such emblems can be used to mark domain names and how they can be conveyed over the DNS, so that services protected under International Humanitarian Law can signal that status in a machine-verifiable way.

Notes that under International Humanitarian Law distinctive emblems such as the red cross, red crescent and red crystal mark physical assets so militaries can recognize protected sites during operations. The draft defines a message format and authorization model for a digital version of these emblems, signaling that network-connected services have IHL protections.

Explains that Segment Routing can steer packets through a network using source routing on both MPLS and IPv6 data planes, and describes how to measure performance in SRv6 networks using the STAMP protocol (RFC 8762), with optional extensions from RFC 8972 and SR-specific extensions from RFC 9503. The measurements cover links and SRv6 paths, including SRv6 Policy segment lists, IGP best paths and Flexible Algorithm paths, as well as Layer-3 and Layer-2 services carried over them.

Specifies HMTP, a protocol for submitting and transferring internet email over HTTPS. It keeps SMTP's core ideas (the message format, the envelope/message separation and delivery status notifications) while building in security and features SMTP offers only as add-ons or not at all, such as safe retries, structured per-recipient errors, declared extensions and large content sent by reference. Transport encryption is mandatory and every transfer request is signed on behalf of the sending domain. Servers are discovered through DNS and a well-known URI, domains can block downgrades to SMTP, and SMTP fallback is optional.

Observes that OAuth 2.0 can request and grant access and manage token lifecycle but has no common way to identify the work a user approved or to tie that work's bounds and end to the credentials issued for it. For AI agents acting on a user's behalf, authority should come from approval of a bounded piece of work, stay within the approved bounds, and end when the work finishes or the user withdraws it. The draft proposes a framework of three objects (a bounded work proposal, a governing authorization created on approval, and durable approval evidence) and is informational and direction-setting, specifying no wire formats and requesting no IANA actions.

Extends RFC 9340 with quantum-native architectural tenets for the Quantum Internet, treated as pragmatic guidelines rather than fixed rules, in keeping with the "constant change" principle of RFC 1958. The architecture uses an entanglement-packet-switching model, defines the role and structure of quantum packets, and separates the Quantum Data Plane from the Quantum Control Plane. It introduces two abstractions: Quantum Internet Addressing for control and coordination, and Generalized Quantum Forwarding for quantum-packet processing and manipulation of entanglement resources.

Defines a method for measuring a website's "agent-readiness": how well it supports autonomous AI agents and generative-search crawlers that read it without a human involved. It sorts observable server behavior into four pillars, each tied to published IETF RFCs or W3C specifications (agent discoverability, semantic entity grounding, content efficiency and ingestion, and transport) and computes a deterministic weighted score from 0 to 100. The authors say the score and its weights are a measurement convention, not a standard; the method is diagnostic only and changes no protocol. A running reference implementation exists.

Explains how an OAuth scope value that is an HTTPS URI can be dereferenced to retrieve a JSON document describing that scope. The document is informational only and does not change the scope's authorization meaning; retrieval follows the pattern and security rules of the OAuth Client ID Metadata Document.

Describes MUSUBI settlement as a deterministic function. It takes a contract signed by two parties, signed records of an agent's actions under that contract, and Bitcoin block header data, then checks whether the recorded actions stayed within the contract's grant. Because the computation is deterministic, anyone with the same inputs can reproduce the result without relying on the party that generated it. The document specifies one part, "settle core v0", in enough detail for a second implementation to be built from the text and test vectors, and states that settlement is neither runtime enforcement nor a judgement of liability.

Observes that DNSSEC validators rebuild the original owner name of a signed RRset from the RRSIG Labels field, and if that name falls outside the signing zone a valid signature can be wrongly treated as authorizing wildcard data in another zone; aggressive use of validated caches can spread the problem. The draft updates RFC 4035 to require the reconstructed owner stay within the signer's zone, and updates RFC 8198 to preserve that authenticated link when cached wildcard data is reused. It does not change wildcard matching or synthesis rules, or DNS message formats.

Introduces the Agent-to-Wallet Protocol (A2WP) for AI agents that encounter credential offers and presentation requests. Because an agent can be misled by the content it processes, it should not hold credentials or keys or decide what to disclose. Under A2WP the agent forwards the request unchanged to a Wallet, which decides whether to act, obtains the principal's approval when needed, and carries out issuance or presentation with the issuer or verifier. The agent then learns the outcome and receives any continuation so it can resume its task; credentials, presentations and keys never reach the agent.