IETF Internet-Drafts & RFCs — Daily Digest

Window: last 48 hours (Oct 3–Oct 5, 2026) · Generated 2026-10-05 05:19 UTC · 100% working-group coverage

13 drafts0 RFCs10/13 drafts with official abstractPublished at ietf-drafts-ok.pages.dev

Newly published RFCs

No RFCs were announced in the last 48 hours.

Drafts

2026-10-04

EVPN has become pervasive for Network Virtualization Overlay (NVO) services across data-center, enterprise, and service-provider networks. This document describes a unified solution that enables seamless multicast VPN interoperability between EVPN and MVPN Provider Edges without requiring dedicated gateway devices. Removing the gateway reduces cost, optimizes forwarding paths, and simplifies provisioning. The same mechanism also works as an optimized multicast routing scheme inside data centers that contain only EVPN PEs.

2026-10-03
draft-sweet-settle-requirements-00Individualnew -00abstract

This document defines the problem statement, common terminology, security models, and technical requirements for identifying, validating, and establishing secure connections with local network devices. It outlines the challenge of extending the Web's Public Key Infrastructure (PKI) to local, offline, or 'limited domain' environments. The requirements cover privacy-preserving discovery, generating and distributing local trust anchors, and establishing mutually authenticated secure contexts without relying on global certificate authorities or on problematic Trust On First Use (TOFU) mechanisms.

This document extends the existing limit on NomCom representation by organization (RFC 8713, Section 4.17) so that not all voting members of the IETF Nominating Committee belong to the same gender. It guarantees up to three voting seats to volunteers who opt into a self-declared pool, and changes the selection only in years when a plain random draw would otherwise seat fewer of those volunteers. The mechanism is intended to improve gender balance on the committee while preserving the random-selection process in all other cases.

The official abstract could not be retrieved for this run (the archived HTML returned 404), so this summary is approximate and based on the name only. By its title, the draft probably defines a 'typed evidence record' — a structured, typed format for carrying evidence, likely in a security, attestation, or audit context. Exact scope, data model, and mechanisms are not confirmed here and will be grounded from the official Abstract on the next run.

draft-ietf-lisp-rfc6831bis-10WG LISPrev -10abstract

This document specifies the design for inter-domain multicast overlays using the Locator/ID Separation Protocol (LISP) architecture and protocols. It describes how LISP multicast overlays operate over both multicast and unicast underlays. A signal-based approach using PIM is used to program LISP encapsulators with a replication list within a locator-set, where that list can mix multicast and unicast locators. When approved, this document obsoletes RFC 6831.

draft-munro-cips-00Individualnew -00abstract

This document defines Contextual IP Prefix Semantics (CIPS), a model that distinguishes addresses, canonical prefixes, addresses with prefix context, and prefix selectors, and describes how these forms are qualified by operational context. It provides a taxonomy of operational contexts and a vocabulary for stating implementation support. In that vocabulary, 'canonical-prefix support' means the canonical prefix form is preserved as its own identity — accepting slash-qualified text is not the same capability. The model helps specification authors, API and schema designers, tool authors, and operators preserve semantic distinctions when prefix-bearing values cross interchange boundaries.

draft-zambo-aer1-10Individualrev -10

The official abstract could not be retrieved for this run (the archived HTML returned 404), so this summary is approximate and based on the name only. The short, individually submitted name ('aer1') does not clearly reveal its subject, and no scope, mechanism, or protocol is assumed here. The description will be grounded from the official Abstract on the next run.

The official abstract could not be retrieved for this run (the archived HTML returned 404), so this summary is approximate and based on the name only. By its name, the draft probably defines a 'content profile' — a constrained set of rules or parameters for some content format or exchange. The exact subject matter and the meaning of the 'eu2122' token are not confirmed here and will be grounded from the official Abstract on the next run.

draft-intra-handshake-fail-54Individualrev -54abstract

This draft argues, with technical detail, that intra-handshake (early) attestation fails in practice. It references a series of CVEs, EUVD entries, and GitHub Security Advisories (GHSAs) as evidence that early attestation can be defeated even without physical access to the target machine. It contends that intra-handshake attestation adds unnecessary complexity given that continuous (post-handshake) attestation is generally required anyway. The work is supported by formal analysis using ProVerif. The draft reports that most early-attestation implementations have been archived or migrated to post-handshake approaches, and recommends careful evaluation of the remaining ones.

This document describes extensions to YANG notification subscriptions that allow metrics to be published directly from processors on line cards to target receivers, while the subscription itself is still maintained at the route processor. This supports distributed forwarding systems within a single network node, improving scalability and offloading the main processor for high-volume telemetry.

This document adds selective disclosure to JWT access tokens without changing the form of the Authorization header or how the token is validated. An RFC 9068 access token is sent as it is today, but some of its claims are made selectively disclosable as defined by SD-JWT (RFC 9901); the Disclosures and an optional Key Binding JWT travel in two new HTTP fields. A recipient that does not implement this profile simply ignores those fields and processes the token as an ordinary JWT access token. The token itself carries no selectively disclosable value, and the holder chooses, per request, which values to reveal.

draft-palanisamy-scitt-aac-runtime-00Individualnew -00abstract

This document defines the 'model_attestation' block of the Agent Action Capsule (AAC) profile — referenced twice by the base profile but never defined there — and, within it, the 'compute_attestation' container that already carries runtime extensions in the field: the model-serving runtime, the agent's own execution environment (architectural pattern, orchestration framework, sandbox confinement, invoked tool version), and host hardware, together with model and weights claims. Every claim carries an explicitly declared source; a verifier grades claims by how they were observed and never infers a stronger grade than the evidence supports. Hardware or platform attestation, when present, is cited by content-addressed reference to a foreign attestation record and verified with that record's own verifier.

draft-palanisamy-scitt-aac-otel-00Individualnew -00abstract

This document defines 'org.agentactioncapsule.otel', a namespaced payload extension for the Agent Action Capsule profile. The extension carries OpenTelemetry trace and span context alongside a sealed agent-action record so that the Capsule and the observability spans describing the same action can be joined after the fact. It maps the OpenTelemetry Generative-AI semantic conventions onto Capsule fields where a mapping is well defined, and states which OpenTelemetry values MUST NOT enter a Capsule at all. The extension does not alter Capsule verification: a verifier that does not implement it treats the block as informational.