IETF Daily Digest

Roughtime: A Protocol for Rough Time Synchronization

This document describes Roughtime, an experimental protocol that aims to achieve two things: secure, rough time synchronization - even for clients with no idea what time it is - and a format for clients to report any inconsistencies they observe between timeservers. It specifies the on-wire protocol required for these goals and discusses the ecosystem aspects needed for it to work. Roughtime trades the fine precision of NTP for strong cryptographic assurance and auditability of the time source. It is published on the Independent/experimental track.

The abstract for this revision could not be retrieved from the fast www.ietf.org/archive/id source, so this description is approximate and based on the draft name. By its name ('aer1'), it is probably an individual submission defining a specific mechanism or format abbreviated 'AER1'; the exact scope is uncertain. This appears to be an active revision (-11) of an ongoing individual effort. It will be grounded in its official Abstract on the next run.

Verifiable Voice Protocol (VVP) is a scheme for authenticating and authorizing the organizations and individuals that place and receive telephone calls. By cryptographically establishing who stands behind a call, VVP aims to eliminate the trust gaps that malicious parties exploit for impersonation and fraud. The draft targets the long-standing problem of caller-identity spoofing on the telephone network. This revision continues work on the call-time verification mechanisms.

This document provides updated guidance on how padding is generated within OpenPGP data streams. It does not define any new OpenPGP wire formats; instead it proposes higher-level best practices for adding padding. The goal is to reduce the information that message length can leak to an observer. It is a first (-00) individual submission establishing recommendations rather than new protocol syntax.

This is a deliberately self-referential document whose point is that anyone may publish an Internet-Draft, and that doing so does not mean 'the IETF thinks' or 'the IETF is planning' anything. It exists to illustrate and clarify the status of Internet-Drafts as individual contributions. Now at revision -26, it serves as a standing explainer and in-joke about what an I-D is and is not. It carries no protocol content.

This document defines the requirements for IPv6 nodes, so that IPv6 functions well and interoperates across the wide range of devices and deployment situations in which it is used. It obsoletes RFC 8504, and in turn RFC 6434 and its predecessor RFC 4294, folding their guidance into an updated baseline. As a 6MAN working-group '-bis' effort, it refreshes the node-requirements profile to reflect current practice. The specification consolidates mandatory and recommended IPv6 features for host and router implementers.

As operators move services to IPv6-only, planned IPv4 outages help surface remaining dependencies before permanent decommissioning. This draft defines HTTP signaling for an intentional, often time-bounded IPv4 outage: the existing 503 Service Unavailable status together with a mandatory Retry-Over-IPv6 response header (plus optional related fields) that tell aware clients to retry over IPv6 after closing the IPv4 connection. An optional correlation token lets clients confirm successful IPv6 recovery, so operators can distinguish soft from hard failures in centralized logs. Machine-readable bodies may use Problem Details (RFC 9457). Legacy clients simply treat the response as ordinary unavailability.

Network platforms use telemetry such as YANG-Push (RFC 8641) to continuously stream counters and state. This document describes the metadata needed to interpret collected data correctly, specifying a Data Manifest made of two YANG data models: the Platform Manifest and the non-normative Data Collection Manifest. Defined at the network level (for example, on network controllers), the manifest is streamed and stored alongside the data so that analytics systems and data scientists can keep it fully exploitable. The draft also augments the YANG-Push model to carry the actual collection period when it differs from the configured one.

Much has changed in the two decades since RFC 4086, 'Randomness Requirements for Security,' was published, and the need for good-quality randomness has grown as more IETF protocols rely on cryptography. This '-bis' effort revisits and updates that Best Current Practice guidance. It is an initial (-00) individual submission intended to modernize recommendations on generating and using unpredictable values. The work aims to reflect current hardware, operating-system, and cryptographic realities.

This document defines a set of Media Over QUIC Transport (MOQT) properties for carrying per-Object timestamps efficiently. The encoded timestamp is intended for use within MOQT but can also be referenced for application-specific purposes. It is a first (-00) individual submission adding a compact timing primitive to the MOQT object model. The goal is to let media objects carry accurate per-object time information with minimal overhead.

This document defines an RDAP (Registration Data Access Protocol) extension that represents entity contact information in JSON responses using JSContact. It lets RDAP servers express contact data in the JSContact model rather than the older jCard format. As a REGEXT working-group item now at revision -27, it is a mature specification nearing completion. The result is a more modern, consistent representation of registrant and contact details in RDAP.

This document defines a record format for AI agent authorization decisions, expressed as a single in-toto predicate type signed inside a DSSE envelope. The record carries the seven minimum audit fields required by the WIMSE AI Identity Management System framework, plus two properties that make them checkable: a canonicalization contract, and both the authorization decision and the observed effect, with a derived three-valued agreement between them. The WIMSE framework leaves the record format out of scope; this draft supplies it and defines no policy of its own. It is an individual submission at revision -02.

The official abstract could not be retrieved, so this description is approximate and drawn from the draft name. By its name, it probably relates to the CATS (Computing-Aware Traffic Steering) problem space and addresses 'agent state affinity' - likely steering or pinning requests to the compute instance holding an agent's state. As a -00 submission it is an initial individual proposal. It will be grounded in its official Abstract on the next run.

This document specifies the Agent Identity Document, a small JSON file served at a well-known URI on a hostname assigned to a single autonomous agent, along with the practices an identity provider follows when hosting such names for operators who do not run their own domain. It separates what the provider knows to be true (hostname, service endpoints, lifecycle status) from what the operator asserts (description, contact, homepage, public key), and publishes dated, expiring checks rather than a single trust level. Every identity is held by an accountable person or organization; an agent is never itself an account holder and is never given authority over DNS. The draft describes a practice already in production at one provider and requests a well-known URI suffix registration.

The DNS permits Delegation Signer (DS) records at delegation points; this document specifies protocol modifications to allow a wider range of Resource Record types there. The changes are designed to stay compatible with existing DNS resolution while providing a secure method for processing these records at delegation points. It updates RFCs 1034, 4035, 6672, 6840, 6895 and 9824. As a DNSOP working-group item at revision -12, it underpins newer delegation mechanisms.

This document specifies a new extensible method for delegating authority for a domain in the DNS using DELEG and DELEGPARAM records. Traditional NS-based delegation carries only server hostnames and no other parameters, and keeps copies in both parent and child zones that can fall out of sync. The new records are extensible, can be secured with DNSSEC, and remove the problem of two sources of truth for delegation information. It is a working-group effort (revision -12) aimed at modernizing how delegations are expressed and secured.

This draft has no retrievable Abstract on the fast source, so this description is approximate and based on its name and series. It is part of the ADEM (Authenticated Digital EMblem) 'diem' work and, by its name, probably specifies the DNS-related aspects of publishing or discovering a protective digital emblem. It is a companion to the ADEM core draft. It will be grounded in its official Abstract on the next run.

In armed conflict the protective emblems of the red cross, red crescent, and red crystal mark physical assets as respected and protected under international humanitarian law (IHL). This draft specifies the format and trust architecture of a protective digital emblem for network-connected infrastructure, marking assets as protected under IHL analogously to the physical emblems. It defines the core mechanism of the ADEM (Authenticated Digital EMblem) scheme. The aim is to let military and other actors identify protected digital infrastructure during conflict.

This document specifies a Pre-Shared Key (PSK) authentication method for the Lightweight Authenticated Key Exchange (LAKE / EDHOC) protocol. The PSK method provides mutual authentication, ephemeral key exchange, identity protection, and quantum resistance while costing less computation than LAKE's public-key methods. It suits systems where nodes share an out-of-band external PSK, and it enables efficient session resumption when the PSK comes from a previous LAKE session. The draft details the PSK message flow, key-derivation changes, message formats, processing, and security considerations.

This document defines how to subscribe to YANG Event Streams for Remote Attestation Procedures (RATS). It specifies a YANG module that augments the module for TPM-based Challenge-Response Remote Attestation (CHARRA), enabling subscription to RATS Conceptual Messages of the Evidence type and to auxiliary Event Logs that form part of that Evidence. The module requires at least one TPM 1.2 or 2.0 (or equivalent protected hardware) on the Attester running the YANG server. As a RATS working-group item at revision -14, it brings streaming subscriptions to attestation evidence.

The Identifier-Locator Network Protocol (ILNP) for IPv6 is described in Experimental RFCs 6740-6744. This document specifies how values for ILNP data types should be represented in textual form: the Locator (L64), the Node Identifier (NID), and the Identifier-Locator Vector (I-LV). It defines the notation formally and gives real-world use cases as examples. It updates RFCs 6740, 6741, and 6742.

Part of the ILNP-for-IPv6 series building on Experimental RFCs 6740-6744, this document clarifies how ILNP addressing uses Preference values together with Locator (L64) and Node Identifier (NID) values. It explains how Preference values form Identifier-Locator Vector (I-LV) values and how I-LVs are selected for use. The clarifications are intended to make ILNP's multihoming and locator-selection behavior precise. It updates RFCs 6740, 6741, 6742, and 6748.

ILNP packets for IPv6 are distinguished from ordinary IPv6 packets by the presence of the Nonce Destination Option Header (the 'Nonce Header') defined in RFC 6744. This document clarifies the use of that Nonce Header for ILNP. It is part of the ILNP clarification series building on Experimental RFCs 6740-6744. It updates RFCs 6740, 6741, and 6744.

Building on the ILNP-for-IPv6 Experimental RFCs 6740-6744, this document describes how unmodified IPv6 applications running on an ILNP-capable node can make use of ILNP. Although ILNP uses a different architecture from IPv6, it is implemented to interoperate with it, and this draft explains how existing applications benefit without changes. It is one of several ILNP clarification drafts. It updates RFCs 6740, 6741, and 6748.

ILNP uses an Identifier-Locator Vector with a zero-valued L64 and a relevant Node Identifier in place of an IPv6 address in the transport-checksum pseudo-header. Because TCP and UDP predate ILNP, this produces checksum values for ILNP flows that differ from the same flows over plain IPv6. This document changes the TCP and UDP checksum computation for ILNP so that the values match between ILNP and IPv6. It updates the checksum processing described in RFCs 6740 and 6741, and how it is applied for TCP and UDP in RFC 6748.

Publishers have begun serving curated plain-text summaries of a web origin for large language models and their crawlers, most visibly as 'llms.txt'. That informal practice has no media type, no rules bounding retrieval cost, and no reliable way for a consumer starting from robots.txt or a fixed location to learn the file exists. This document specifies discovery and retrieval for such publisher-curated context files, defining the well-known URI 'llm-context', a matching link relation, and a robots-exclusion extension record, plus a two-tier index/detail arrangement with conditional-request and size requirements. It also reports operational measurements showing crawlers repeatedly missing the context file for lack of a discovery mechanism.

LLM-driven autonomous agents execute multi-step runs in which the same conversational context is retransmitted to the model at every step, so resource consumption is dominated by repeated input and is reported today in incompatible vendor-specific shapes. This document defines Agent Run Metrics, a JSON interchange format describing the resource consumption of a single agent run and its constituent steps, plus a small set of precisely specified derived quantities. It states that one reported step equals one completed model invocation, and defines how delegated sub-run consumption is attributed without double counting. The format carries counters, timing, and cost attribution only, deliberately excluding prompt and completion content.

This document defines how to securely assign a candidate device (Pledge) to an owner using a digital artifact, the 'Voucher', signed directly or indirectly by the Pledge's manufacturer. It specifies the Voucher as a YANG-defined JSON or CBOR document signed with a variety of cryptographic systems, normally generated by the manufacturer's Authorized Signing Authority (MASA). It obsoletes RFC 8366, folding in several desired extensions, and also updates and incorporates the Voucher Request YANG module from RFC 8995 along with other needed extensions. As an ANIMA working-group item at revision -37, it is the maturing basis for BRSKI-style secure bootstrap.

This document defines JEP Receipt Profile 1 (JEP-RP-1), a minimal receipt and evidence profile for the Judgment Event Protocol (JEP). It binds a JEP event to one digest-addressed receipt record through a critical JEP extension, and defines a small behavior-record format, portable receipt manifests and bundles, and independent receipt-validation checks. JEP itself remains authoritative for event verbs, identity, hashing, signatures, references, extension processing, and acceptance semantics. The draft stresses that receipt records are technical evidence about observable behavior and do not assign legal liability, prove intent, or establish compliance.

The official abstract could not be retrieved from the fast source, so this description is approximate and based on the name. As a LISP working-group item, it probably specifies mechanisms for LISP (Locator/ID Separation Protocol) data and control traffic to traverse Network Address Translators. It is at revision -03, suggesting ongoing working-group development. It will be grounded in its official Abstract on the next run.

No Abstract could be retrieved from the fast source, so this description is approximate and drawn from the name. By its name it is an IPv6 Operations (v6ops) individual submission concerning something abbreviated 'EDS'; the precise meaning is uncertain without the abstract. It is at revision -02. It will be grounded in its official Abstract on the next run.

Large Language Models are increasingly used to assist network-management tasks such as troubleshooting, intent translation, and automation, but they must consume heterogeneous multi-vendor inputs (CLI output, configuration, telemetry, alarms, APIs). This document describes a framework for standardizing those inputs: an Input Classifier sorts each message into performance, configuration, or response categories using rules with escalation to a Small Language Model, then a matching Structurer produces a normalized representation. A Prompt Schema Generator turns that into a vendor-agnostic schema and schema-aligned prompts for a central LLM. It specifies architecture and component roles for informational purposes and defines no wire protocol.

This document specifies procedures for handling ICMP error messages in SRv6-based Virtual Private Networks (VPNs). It describes three methods to improve ICMP error handling for SRv6-VPNs, where encapsulation can otherwise make errors hard to deliver and interpret. It is a first (-00) individual submission in the 6MAN problem space. The goal is more reliable diagnostics such as Path MTU discovery and traceroute across SRv6 VPN paths.

Agent protocols often require a participant to establish a decision-time input before acting - issuer standing, key availability, delegated authority, policy availability, consumption state, revocation status, or a downstream outcome - and collapsing 'established but negative' with 'could not be established' into one failure value distorts retries, alerting, audit, and incident ownership. This document specifies requirements for preserving evaluation state across agent-protocol boundaries: the value of an input, whether it was established at decision time, the freshness of its source, and whether the resulting policy decision was actually evaluated. The requirements are stated independently of encoding so that authorization, revocation, routing, and audit documents can satisfy them in their own formats. A later revision will define concrete representations.

This document specifies an automatic configuration mechanism for email, calendar, and contact user-agent applications. Domain owners publish standardized configuration information that client applications retrieve to simplify server setup. As a MAILMAINT working-group item at revision -04, it aims to reduce manual account-setup friction for end users. The approach lets clients discover the correct server settings for a domain automatically.

This document specifies a data model for synchronizing calendar data with a server using JMAP. Clients can use it to efficiently read, write, and share calendars and events, receive push notifications for changes or event reminders, and track changes made by others in a multi-user environment. As a JMAP working-group item now at revision -32, it is a mature specification. It complements the JMAP core and brings modern calendar sync into the JMAP family.

This specification defines version 2.0 of JSCalendar, a data model and JSON representation of calendar data for storage and exchange in calendaring and scheduling environments. It obsoletes RFC 8984 (version 1.0) and aims to improve interoperability with existing iCalendar-based systems. Version 2.0 also aligns its definitions with JSContact, including the IANA registry policy, validation requirements, and versioning scheme. It is a CALEXT working-group item at revision -22.

This document defines an 'evidence layer': conformance requirements for a local evidence store that records evidence and the relationships between records, keeps digests committed while payloads are referenced separately, and preserves how each record came to be known so a later reader can tell an observation from a claim. It defines the record model, typed links, disclosure and retention semantics, the classes of index a store may keep, and the minimum interface a commitment substrate must supply. Conformance must not require any particular substrate: a Checkpointed Local Log, a SCITT Transparency Service, or any append-only transparency log can all qualify. It deliberately leaves out sufficiency policy, routing, settlement, and specific identity, signing, or storage mechanisms.

Delivering network services over a Layer 3 tunnel requires provisioning an attachment circuit (AC) over the links between customer termination points and the provider network, with the underlying link - here a Layer 3 UDP tunnel - acting as the 'bearer'. This document specifies an extension for a UDP tunnel as a Layer 3 bearer to the YANG service data model for attachment circuits. As a DMM working-group item at revision -02, it fits AC-as-a-Service modeling. It lets operators model and provision UDP-tunnel-based service attachment consistently.

The Cedulon core reconciles signed Spend Receipts against an authenticated extract of a payment rail; this document defines a second population on the same reconciler for agent action decisions. A Decision Record is signed by the party that decided whether an agent may act, and an Effect Extract is an authenticated list of effects that actually occurred on a channel: an 'allow' must match exactly one effect whose content hash the record named, and a 'refusal' must match none. The draft defines the Decision Record claim set, the Effect Extract shape, the finding codes, and one media type. This revision adds checkpoint signing under a separate key, clarifies single-row extracts, and records a second implementation plus outside test-vector runs.

This document specifies MARC, an experimental, vendor-neutral profile for control and uncertainty-disclosure metadata in generative models and agentic systems. It separates pre-decision capability assessment from post-decision answer confidence, identifies uncertainty sources and confidence targets, and defines a bounded set of primary actions and a minimal disclosure object. The experiment evaluates whether independently built components can exchange and interpret these metadata consistently across implementation and protocol boundaries. MARC specifies only externally observable semantics - not model internals, transport, authentication, authorization, or task execution - and does not define an Internet Standard.

This document describes an Extensible Provisioning Protocol (EPP) extension for setting and managing a registry lock on a domain object. A registry lock protects high-value domains against unauthorized changes such as transfers or deletions by requiring out-of-band steps to unlock. It is an individual submission at revision -01. The extension gives registrars and registries a standardized way to express and manage these locks.

This draft argues, with supporting research and artifacts, that early (pre-handshake) attestation fails in practice even without physical access to the target machine, and that because continuous attestation is generally required anyway, early attestation adds unnecessary complexity. It catalogues several CVEs and GitHub Security Advisories - including multiple high-severity entries - and backs its claims with ProVerif models released under Apache-2.0. It reports that most early-attestation implementations have since been archived, withdrawn, or moved to post-handshake attestation. Two remaining implementations are called out as still vulnerable, and operators are advised to evaluate their exposure.

Agent tasks are increasingly delegated across organizational boundaries, and existing work covers how agents are identified, discovered, and described but leaves expressing capability policy as a gap. This document defines four policy attributes for inter-domain agent delegation, the declarations each attribute carries, and a validity condition on delegation chains that no single party establishes by seeing the whole chain. Whether independently chosen policies converge is analyzed in separate work. It is an individual submission at revision -02.

The IANA 'Message Headers' registries record, for each registered header field, its protocol, status, trace classification, and specifying documents, but the metadata is less complete than the defining documents supplied - notably the roughly ninety fields that RFC 4021 bulk-registered, whose status and specification were never recorded. This document reviews the definition and every subsequent update of each registered header field and gives IANA a single consolidated set of instructions to complete and correct each entry, including filling the 'Trace' column left empty by the RFC 5322 revision. Each recommended change, and each decision to leave a non-obvious entry unchanged, is justified. It updates RFC 4021.

Autonomous agents can exchange offers and signatures without producing an artifact recording which parties reached which outcome, over which transcript digest and message count, and for how long it may be relied upon. This document defines JSON agreement-evidence objects for structured, multi-attribute negotiation; the core object is an agreement attestation that establishes only that a named set of parties jointly countersigned a stated outcome over a stated transcript digest and message count, with behavioral counters each accepted. It provides no member for a negotiated price, quantity, date, or principal identity, and a verifier cannot detect if a producer improperly places such values in free-text members. It defines every member, type, encoding, constraint, and the verification procedure, plus relying-side freshness obligations.

This short document updates RFC 6211 to correct errors in the definition of the id-aa-cmsAlgorithmProtect ASN.1 object identifier. The IANA registry entry for it has always been correct; the errors were in the RFC text. As a LAMPS working-group item at revision -04, it is an errata-style correction to the CMS Algorithm Protection attribute. It ensures implementers use the correct OID definition.

Consequential agent actions can produce many heterogeneous artifacts - identity, delegation, policy, permit, approval, transparency, capability, and execution - each of which can verify under its own spec while still referring to a different action or failing a relying party's binding requirements. This document defines the Authorization Evidence Chain (EP-AEC): a transport-agnostic composition object and a fail-closed evaluation algorithm that keeps native cryptographic verification separate from relying-party acceptance, enforces exact material-action matching, and evaluates a relying-party-pinned evidence requirement. It produces SATISFIED or UNSATISFIED plus a replayable evaluation record, where SATISFIED means only that the presented evidence met the named requirement at the stated time. The executor still makes the separate local AUTHORIZED decision.

This document catalogues cases of protocol ossification - the phenomenon in which a new protocol, version, or extension cannot traverse an existing Internet path because middleboxes or endpoints assume older behavior. It summarizes reported observations and their sources, discovered during protocol standardization and deployment, together with case-specific responses. It is a first (-00) individual submission intended as a reference collection. The aim is to help protocol designers anticipate and mitigate ossification.

This document specifies Deterministic Intent Verification (DIV), a transport-independent format for signed action approvals and their offline verification. A relying party reconstructs the signed payload from its expected execution parameters, verifies witnesses against locally selected trust anchors, and checks the signed approval requirement against any locally configured policy. It covers ordinary approvals, offline approvals, delegation, agent authority, and platform hash-only intents; cryptographic verification is stateless, while enforcing single-use execution requires stateful nonce redemption. A valid signature establishes approval of the signed bytes under the selected trust policy - not execution of the action or the approver's understanding of it. It is a first (-00) individual submission.

This document specifies the Deterministic Evidence and Witness Protocol (DEWP), a format for tamper-evident audit commitments and offline evidence verification. It defines canonical event preimages, domain-separated hashing, two-tier Merkle inclusion proofs, per-tenant sequence checks, checkpoint continuity, and independently verifiable anchor evidence, with verifiers reporting content, commitment, embedded-signature, and anchor verification separately. Completeness checks cover committed events within the evaluated range but cannot prove an event was never withheld before commitment or that a committed description matches a real-world action. It also defines a streaming format not yet implemented in the reference code. It is a first (-00) individual submission.

This document defines the Autonomous Agent Certification Protocol (AACP), a framework binding successful evaluation of an AI agent to cryptographically verifiable evidence of demonstrated capability. It introduces Evaluation Profiles defining the conditions under which an agent may be certified for a specific capability; an Agent Configuration that satisfies a profile may receive a short-lived Agent Certification Credential (ACC) bound to the evaluated configuration. An ACC does not grant resource access - it is verifiable evidence that an agent demonstrated a capability under defined conditions, which authorization systems may then require. AACP thus separates capability certification from identity, authentication, delegation, and authorization.

This document provides considerations to guide the implementation of the Lightweight Authenticated Key Exchange (LAKE / EDHOC) protocol. It collects practical guidance for implementers rather than defining new protocol mechanisms. As a LAKE working-group item at revision -08, it complements the core EDHOC specification. The goal is to help produce correct, secure, and interoperable EDHOC implementations.

This document specifies URICrypt, a deterministic, prefix-preserving encryption scheme for Uniform Resource Identifiers. URICrypt encrypts URI paths while preserving their hierarchical structure, so systems that rely on URI prefix relationships keep working with encrypted URIs. It provides authenticated encryption for each URI path component, preventing tampering, reordering, or mixing of encrypted segments. It is an individual submission at revision -05, aimed at privacy-preserving yet structure-aware URI handling.

This document describes extensions to YANG notification subscriptions so that metrics can be published directly from processors on line cards to target receivers, while the subscription itself is still maintained at the route processor in a distributed forwarding system. This offloads high-volume telemetry from the central processor and improves scalability on large network nodes. As a NETCONF working-group item at revision -23, it is a mature specification. It complements YANG-Push for distributed-hardware platforms.

This document defines a YANG module that extends the YANG-Push subscription mechanism to enforce that particular revisions or semantic versions are used when configuring or establishing a subscription. It also extends YANG-Push subscription state-change notifications to include additional context about the YANG schema associated with the subscription. As a NETCONF working-group item at revision -17, it helps clients and servers agree on schema versions for streamed data. The result is more robust telemetry across schema evolution.

EVPN is becoming pervasive for Network Virtualization Overlay services in data centers, enterprise, and service-provider networks. As providers transform their central offices toward SDN-based fabrics and NFV, they want to keep offering Multicast VPN (MVPN) service seamlessly between existing networks and new Service Provider Data Centers without gateway devices - reducing cost, optimizing forwarding, and simplifying provisioning. This document describes a unified solution based on RFCs 6513 and 6514 for seamless MVPN interoperability between EVPN and MVPN PEs, and shows how it can also serve as a routed multicast solution in data centers with only EVPN PEs. It is a BESS working-group item at revision -12.