IETF Internet-Drafts & RFCs

Proposes an authority-centred model of digital sovereignty that separates a globally distributed Compute Plane from an independently governed Authority Plane. Computation may run in any jurisdiction, but a cross-jurisdiction operation is treated as a Candidate Act that stays non-effective until policy, identity, purpose, destination, jurisdiction, runtime and revocation predicates are validated. Only then is a scoped Finality Authority issued and re-verified at the Finality Sink, the first point where the effect would become externally visible. The aim is sovereignty without mandatory data localisation: the computation may happen elsewhere, but a protected external effect cannot occur without the required authority. It explicitly avoids standardising national policy or dictating where data must be stored.

Argues that TLS, OAuth, HTTPS and EMV each answer identity, channel or delegated-scope questions but none answers whether a specific machine-generated act, right now, is authorized to become externally effective. As agents and autonomous workloads collapse the gap between generating and firing a request to milliseconds, the draft specifies an 'execution finality' pattern: every operation is a Candidate Act held in a Non-Effective State until a Protected Enforcement Domain validates act-specific authority and issues a narrowly scoped, non-bearer Execution Handle bound to a Finality Sink. It defines vocabulary, a cold-path/hot-path split, a threat model and an incremental migration path that coexists with existing protocols. Offered to solicit IETF review of whether the gap is real and where it belongs.

Specifies ProtectChain, a permissioned, hash-chained and cryptographically signed ledger that produces verifiable evidence a digital work existed no later than a given time under an authorship claim by an identified account. Only cryptographic digests and pseudonymous identifiers are recorded; the work itself never enters the ledger. Because the initial authorities may all be run by one organisation, every block is anchored to independent public time references so the upper time bound does not rest on the operator's word. The draft is explicit about limits: an anchor shows data existed no later than an instant, but does not prove the exact moment of creation, authorship, or originality.

Presents a YANG data model for tracking and managing passive network inventory. The model augments the base network inventory model, extending it to cover passive elements. A short, tightly scoped first version (-00) within the IVY working group.

Defines a new PDU type for the RPKI-to-Router (RTR) protocol to convey Mapping Origin Authorization (MOA) information from RPKI caches to routers. The new 'IPv6 Mapping Prefix' PDU carries the authorization mapping between one or more IPv4 prefixes and their corresponding authorized IPv6 mapping prefix. This lets routers perform Mapping Origin Validation (MOV) for IPv4-to-IPv6 address-mapping announcements in IPv6-only underlay networks.

Discusses aspects of the documents describing the IETF standards process that have been overtaken by events, and identifies some gaps. It covers the six-month expiry of Internet-Drafts, the practical reality of the two-stage standards process, and various other issues. The draft is posted only to open a discussion rather than to propose a specific change.

Specifies encapsulations for the Simple Two-Way Active Measurement Protocol (STAMP, RFC 8762) and its extensions (RFC 8972) in MPLS networks. It covers STAMP test packets for point-to-point LSPs and single-segment pseudowires, with or without an IP/UDP header, so test packets follow the same forwarding and ECMP behaviour as the measured traffic, and defines two new MPLS G-ACh types. It updates RFC 8762 and RFC 8972 to allow STAMP without an IP/UDP header over MPLS LSPs and PWs, adjusting handling of the session identifier, IPv4 TTL / IPv6 Hop Limit and TLV extensions.

A small correction to RFC 6211. It fixes an error in the definition of the id-aa-CMSAlgorithmProtect ASN.1 object identifier. The draft notes that the corresponding IANA registry entry has always been correct, so only the RFC text needs updating.

Moves Virtual eXtensible Local Area Network (VXLAN) onto the IETF document stream. VXLAN addresses the need for overlay networks within virtualized, multi-tenant data centres. Bringing the specification into the IETF stream enables creation of extensions that require VXLAN header additions and IANA registration, while the packet format and processing remain fully compatible with the earlier RFC 7348.

Codifies a consistent, reversible convention used in the threat-intelligence community for sharing potentially malicious indicators of compromise (IOCs) such as URLs, IP addresses, email addresses and domain names. The obfuscation format reduces the risk of accidental execution or activation when IOCs are displayed or transmitted: it renders an indicator syntactically invalid as a URI while keeping it human-readable, and the original value can be recovered deterministically. Safe-IOC strings are a textual rendering convention, not URIs, and are not meant to be parsed by generic URI parsers. The goal is better interoperability among tools and feeds that exchange threat data.

Argues, with reference to CVE-2026-33697, EUVD-2026-16488 and several GitHub Security Advisories, that intra-handshake (early) attestation fails in practice even without physical access, and that because continuous attestation is generally required, early attestation adds unnecessary complexity. The claims are backed by formal analysis in ProVerif, with artifacts to be released under Apache-2.0 for reproducibility. The draft tallies multiple published CVEs and GHSAs of high CVSS severity against early attestation across the ecosystem up to the application layer, and states that some remaining implementations of early attestation are still vulnerable.

Defines two DNS resource record types, UNECE and ISO, that convey numeric values paired with codes drawn from registries maintained by external standards organizations (the UN Economic Commission for Europe and ISO). Neither RRTYPE duplicates the external registries into IANA; each carries codes verbatim and uses the external maintainer's semantics. The draft specifies presentation and wire formats for both, records the assignment of two decimal RRTYPE identifiers under BCP 42 Expert Review, and suggests a reusable design pattern for future RRTYPEs that make external registries usable from the DNS without duplication.

Defines RTCP messages that let receivers give feedback to senders, enabling short-term adaptation and feedback-based energy-efficient mechanisms. The messages have broad applicability in point-to-point real-time video communication. Specifically, they can convey video-decoder feedback metadata to the encoder to adapt decoder energy consumption, as defined in ISO/IEC 23001-11, the 'Green metadata' Energy Efficient Media Consumption standard from MPEG Systems (ISO/IEC JTC 1/SC29/WG3).

Defines the 'Payment' HTTP authentication scheme, letting an HTTP resource require a payment challenge to be fulfilled before granting access. The scheme extends HTTP Authentication and uses the HTTP 402 'Payment Required' status code. It is payment-method agnostic, supporting any payment network or currency through registered payment method identifiers, with the specific methods defined in separate payment-method specifications.

Describes best practices for the DomainKeys Identified Mail v2 (DKIM2) email authentication protocol. DKIM2 is designed to address shortcomings in earlier authentication mechanisms, specifically SPF (RFC 7208), DKIM (RFC 6376), DMARC (RFC 9989) and ARC (RFC 8617). This document discusses best practices for signing, handling and validating messages that carry DKIM2 signatures, and for interoperating with the authentication protocols and mechanisms that preceded DKIM2.

Extends STAMP for Edge-to-Edge active measurements by allowing it to reflect IP headers as well as IPv6 extension headers for hop-by-hop and end-to-end measurements, for example using IOAM data fields to record and collect operational and telemetry information. It also specifies the requirements for IPv6 STAMP in unauthenticated mode using a UDP zero-checksum, which deviates from the integrity requirement in RFC 6936.

Defines SRv6-INT, a protocol extension integrating In-band Network Telemetry (INT) with Segment Routing over IPv6 packet processing. It reuses the Segment List entry associated with each SRv6-INT endpoint to carry an equal-length telemetry record, so telemetry collection along the path does not further increase the packet header length. A collector obtains the resulting telemetry and feeds it to local and global controllers for closed-loop resource control. A first version (-00).

Addresses agents needing bounded authority to perform several consequential actions without a fresh human approval each time. A signed token alone cannot enforce a shared budget across replicas, survive retries safely, or tell an operation that never crossed an effect boundary from one whose outcome is unknown. The draft defines a bounded capability receipt and a durable reserve-admit-reconcile protocol that atomically refuses overspend and replay, fences concurrent owners, and charges indeterminate operations. Delegation transfers rather than copies authority, with narrowing-only delegation, revocation inheritance and an optional admission-control epoch. It explicitly does not turn a bearer token into human approval or provide cross-domain offline double-spend prevention.

Defines a Power Conserving Path Placement Strategy (PCPPS) for traffic-engineered networks. During periods of low demand, PCPPS concentrates traffic onto a small set of network resources, letting other resources become idle or nearly idle so they can be powered down. When demand increases again, PCPPS redistributes traffic as required. A concise energy-efficiency mechanism in the TEAS space.

Provides YANG data models for accessing and controlling CMIS to manage pluggable Digital Coherent Optics transceivers in a router or switch from outside the platform device. CMIS provides vendor-defined custom pages; these YANG modules allow those custom pages to be used as a generic control mechanism. The models complement abstracted data models for coherent pluggables, giving governed access to opaque, vendor-specific attributes and a transitional path for standardized features the host network OS does not yet support.

Describes the fundamentals of security operations to provide a foundation for protocol-design considerations and guidance. It notes that security operators, responsible for detecting malicious activity, responding to threats and defending networks, are a crucial part of network operation and management, and that their needs deserve consideration when new protocols are designed. Building on draft-ietf-opsawg-rfc5706bis, it explains how security-operations considerations can most usefully be included in other IETF documents.

Targets the problem that data collected for one stated purpose is routinely consumed by a second system for a different purpose because nothing in the protocol path can refuse it, and a self-asserted 'purpose' string is evidence of intent, not proof of authority. It specifies an execution-finality architecture where a Candidate Act to read, transmit or derive from a protected object stays non-effective until a Protected Enforcement Domain verifies caller identity, operation and destination against binding records and issues a scoped, non-bearer Execution Handle. A running example (a delivery address later targeted by advertising) makes the boundary concrete. It stresses that lawful cross-referencing is legitimate; the goal is to make an authorized combination verifiable at the moment it happens.

Specifies the use of KMAC128 and KMAC256 within IKEv2, ESP and AH. These algorithms can serve as integrity-protection algorithms for ESP, AH and IKEv2, and as Pseudo-Random Functions for IKEv2. The draft also specifies the requirements for supporting IKEv2 signature algorithms that use SHA3-256, SHA3-384, SHA3-512, SHAKE128 and SHAKE256, bringing the SHA-3 family into the IPsec suite.

Defines a YANG data model for power and energy monitoring of devices within, or connected to, communication networks. A compact model in the GREEN working group aimed at standardising how network devices report their power and energy metrics.

Specifies a hardware-rooted execution-finality architecture for neural and agentic AI systems, where a model output can become a tool call, API transaction, memory write, payment, file mutation, browser action or actuator signal. It argues that successful inference, sandbox containment, connector allowlisting or session permission does not itself establish authority for a particular consequence. A proposed operation is a Candidate Act held Non-Effective until a Protected Enforcement Domain validates act-specific predicates and an independent Finality Sink verifies scoped, non-bearer authority just before the effect. If that authority is absent, stale, replayed, revoked or mismatched, the act fails closed. It is model- and vendor-neutral, targeting MCP tool dispatch, computer use, connectors, memory writes and settlement.

Defines a strategy to securely assign a candidate device (Pledge) to an Owner using an artifact, called a Voucher, signed directly or indirectly by the Pledge's manufacturer. The artifact is a YANG-defined JSON or CBOR document signed using various cryptographic systems, normally generated by the Manufacturer Authorized Signing Authority (MASA). This document obsoletes RFC 8366 by folding desired extensions into the YANG module, and also updates and incorporates the Voucher Request YANG module from RFC 8995 along with other YANG extensions needed for RFC 8995 variants.

By its name and filename, this appears to be an individual submission about authorship of IETF documents — probably discussing how authors and contributors are identified or credited in IETF work. No official Abstract could be retrieved for this version (the fast source page returned 404), so this summary is written from the title and is approximate; it will be grounded from the document's Abstract on the next run.

Specifies an RTP payload format for transporting a video signal encoded with JPEG XS (ISO/IEC 21122), a low-latency, low-complexity coding system that keeps encode-decode latency to a fraction of a video frame. This is a necessary revision of RFC 9134 to add support for third-edition JPEG XS features, most notably the TDC coding mode. It obsoletes RFC 9134 while keeping existing compliant implementations valid, consolidates the RFC 9134 errata, and adds clarifications for implementers and users.

A very short specification defining an HTTP status code to indicate that the server is denying a request based upon its declared purpose. It complements purpose-declaration mechanisms by giving servers a standard way to signal a purpose-based refusal.

Notes that DNS resolution latency is widely used to evaluate recursive resolvers, authoritative servers and DNS infrastructure, but current implementations use different definitions, measurement scopes and methodologies, making results hard to compare. The draft identifies common sources of inconsistency, proposes a conceptual latency-decomposition model, and offers measurement considerations to improve comparability. It does not define protocol behaviour or introduce new protocol mechanisms. A first version (-00) in DNSOP.

Argues the Internet has protocols for moving data, securing channels, naming hosts and delegating identity, but none for the moment a machine-generated instruction becomes a real-world act — a gap that becomes a structural risk as AI systems move money, change databases and control physical systems. It specifies the DAS Candidate-Act Finality architecture: every effect-capable AI output becomes a non-effective Candidate Act, validated for output, provenance, factual support, consequence, jurisdiction, epoch and sink predicates by a Protected Enforcement Domain before a scoped non-bearer Execution Handle is released and verified at a Finality Sink. It supports graduated and escalated conditional finality and provides JSON Schema for the core protected objects.

Specifies the core of the AI Internet Protocol (AIIP) agent access plane: the AIID identity namespace, the aiip: URI scheme, and Resolve, Invoke, Receipt and delegation-grant operations. Underlay addresses are treated as disposable locators only, and agents must not use HTTP or HTTPS as their Invoke or Resolve path. Its 'independence doctrine' holds that underlay pipes and platforms are never authority and that mesh tip attestation is a trust layer, not a ledger. Access Fabric punch operations are Experimental. This revision derives from a running lab profile; it is an individual submission and claims no working-group adoption.

Defines the Identity Continuation Assertion, a short-lived, sender-constrained JWT used as an OAuth 2.0 Token Exchange subject token. It lets a workload acting on a user's behalf obtain an Identity Assertion JWT Authorization Grant (ID-JAG) for another service when it lacks a suitable credential, including when the user is no longer present. A trusted issuer attests that a resource authorization server accepted an earlier ID-JAG and that the authorization remains active and eligible for continuation; the workload exchanges the assertion at the identity provider for an onward ID-JAG. The profile supports multi-hop access across resource authorization servers that trust a common identity provider.

Defines the procedures for specifying and registering media types for use in HTTP, MIME and other Internet protocols. This revision obsoletes RFC 6838 and RFC 9694, consolidating and updating the media-type registration rules. A mature draft (-10) in the MEDIAMAN working group.

Defines a radio-side execution-finality profile for non-terrestrial networks and mega-constellation control. It observes that a LEO constellation can compute a transmit burst, beam command, inter-satellite forward or user-terminal PA enable faster than any ground reviewer can see it, and that authentication of TT&C, 3GPP NTN registration and operator allowlists decides who may talk to the vehicle, not whether this burst on this beam to this next hop over this territory may leave the aperture. A proposed RF, ISL, beam, gateway or payload act stays a Candidate Act; a Protected Enforcement Domain binds vehicle, beam, frequency, duration, next hop, overflight epoch and sink and issues scoped non-bearer authority verified at the PA enable, ISL switch or transmit path just before energy leaves the system.

Specifies generic security requirements for IP tunnel ingress, egress and relay nodes. It notes that IP tunnels hide passenger-packet fields from on-path devices and create a new forwarding and policy boundary at decapsulation, so a node that accepts delivery packets from an unauthorized source, or forwards a decapsulated packet without applying policy, can enable spoofing, unauthorized transit, policy bypass or resource exhaustion. Requirements cover explicit enablement, peer and passenger-packet authorization, source and forwarding-scope validation, nested tunnelling, IPv6 extension headers, ICMP and PMTUD, resource controls and telemetry, applying to IP-in-IP, IPv6 tunnelling, GRE and enabled transition mechanisms. It defines no new encapsulation.

Defines JavaScript Object eXchange (JSOX), a lightweight, text-based, language-independent data-interchange format derived from JSON and from ECMAScript object-literal syntax, in which every well-formed JSON text is also well-formed JSOX. JSOX extends JSON with unquoted identifiers, additional string quoting and escape forms, comments, extra number forms including dates and arbitrary-precision integers, binary typed arrays, user-defined types carried by a type tag, field-name macros that remove repeated keys, and references that allow shared and cyclic structures. The draft defines the JSOX grammar and registers the media type application/jsox.

Specifies a payment-side execution-finality profile. It argues payment rails know how to move money but not whether this generated instruction — this amount, beneficiary, rail, purpose, from this agent or worker — is the one that was authorized: a signed ISO 20022 message, OAuth token, stored mandate or 3-D Secure pass can be valid while the act is wrong. An instruction stays a Payment Candidate Act while a Protected Enforcement Domain binds principal, wallet or account, amount, currency, beneficiary, rail, purpose, policy epoch and settlement sink and commits evidence before issuing scoped non-bearer authority; the sink that would post, capture or release funds verifies and consumes that authority against the live instruction. A signed instruction is not settlement.

Specifies extensions to the Path Computation Element Communication Protocol (PCEP) that allow a stateful PCE to compute and initiate Point-to-Multipoint (P2MP) paths for SR-MPLS from a Root to a set of Leaf nodes. Segment Routing P2MP Policies enable an architecture for P2MP service delivery, and these PCEP extensions support that architecture. A mature draft (-21) in the PCE working group.

Describes a protocol by which on-path network elements can communicate their perspective on the maximum sustainable throughput for QUIC flows to the endpoints. This throughput advice suggests an upper bound on long-term average throughput; it is independent of and complementary to real-time congestion-control signals, giving endpoints a hint about what the path can sustain without replacing congestion control.

Specifies the External Verifier Contract (EVC), a small, testable, proof-system-agnostic boundary between a host (the program about to take a privileged action on an agent's behalf) and an external verifier subprocess that returns an allow/deny verdict on an opaque proof bundle. It governs transport and verdict envelopes: hosts hand JSON requests to verifiers over stdin, receive verdicts on stdout, and interpret exit codes under fail-closed semantics. Single-shot subprocess transport, independently testable host semantics and proof-system agnosticism (classical signatures, zero-knowledge proofs, third-party verdicts) enable standardization. EVC deliberately avoids governance frameworks, delegation models and policy languages, addressing only the narrow decision boundary.

Specifies the Attestation Reconciliation Protocol (ARP), a deterministic, bilateral, minimum-disclosure mechanism for reconciling verification claims against multiple sovereign authoritative registers without raw register records leaving their data-residency jurisdiction. ARP extends the SCITT architecture to cross-sovereign claim reconciliation: a reconciliation server canonicalises a claim, binds the requesting principal (including a friend-or-foe check for autonomous agents), projects the claim through register-specific functions, and aggregates partial attestations that disclose only a verdict and minimal metadata, committing contributions to a Merkle tree. An append-only settlement ledger records only digests. This revision adds a normative SCITT Reference APIs binding, register data-format profiles and a source-data version binding.

Defines Media over QUIC Transport (MOQT), a publish/subscribe protocol running over QUIC and WebTransport. MOQT leverages transport features such as streams, datagrams, priorities and partial reliability, and operates both point-to-point and through intermediate relays for scalable, low-latency delivery. Despite its name, MOQT is media-agnostic and can serve a wide range of use cases. A mature working-group draft (-21) in MOQ.

Defines the Secure Advertisement and Neighborhood Discovery (SAND) protocol for Bundle Protocol version 7 (BPv7) in delay-tolerant networks. SAND provides a general-purpose advertisement mechanism with an initial set of message and data types that participating nodes can advertise. The current focus is advertisement to topological neighbours about local neighbourhoods, with defined extension points so it can be expanded in future.

Presents a framework for network traffic classification and modality mapping based on large language models (LLMs), aiming to address the inefficiencies of traditional classification methods in dynamic network environments. An individual submission exploring how LLM-based techniques could improve traffic recognition and mapping.

Defines an aggregate performance report format for email messaging, along with the means to discover target destinations and a specified delivery method for the reports. It gives operators a standard way to exchange aggregated email performance data.

Defines the 'stage receipt', a small, canonically serialized JSON record that each stage of a staged pipeline — a document-ingestion flow, retrieval-augmented generation chain, agent workflow or benchmark — emits, describing exactly what went in, what came out, under which pinned instrument, with which outcome, linked by digest to the previous receipt. A chain of receipts lets a developer reproduce a run, diff two runs to the first differing stage, and localize a fault; it also lets an independent party later verify what the records assert without trusting the producer. The draft specifies the record, its canonical form, the chain manifest, coverage/emission and anchoring declarations, verifier behaviour, and golden conformance vectors. A first version (-00).

Specifies a Pre-Shared Key (PSK) authentication method for the Ephemeral Diffie-Hellman Over COSE (EDHOC) lightweight authenticated key exchange. The PSK method provides mutual authentication, ephemeral key exchange, identity protection and quantum resistance while costing less computationally than EDHOC's public-key methods. It suits systems where nodes share a PSK out-of-band (external PSK) and enables efficient session resumption with less overhead when the PSK comes from a previous EDHOC session (resumption PSK). The draft details the PSK message flow, key-derivation changes, message formatting, processing and security considerations.

Highlights the architectural need in Deepspace/TIPTOP interplanetary-networking protocols for an external, standardized reference framework for celestial objects — an equivalent of ISO 3166 for interplanetary networking. To avoid duplication, the framework defers the definition, naming and tracking of celestial entities to the International Astronomical Union and the Minor Planet Center, and outlines how those external identifiers guide hierarchical address allocation without IANA maintaining a dedicated astronomical nomenclature registry. The ultimate objective is a clear definition of what constitutes a valid Celestial Body for networking purposes.

Defines AIC-JWT, a JWT-based application-layer representation of the AI Agent Identity Certificate (AIC) data model, which binds an AI agent's cryptographic identity to a responsible principal together with capability containers, delegation modes, authorization constraints and principal-signed delegation evidence. AIC-JWT uses standard JWT and JWS mechanisms: the outer token is issuer-signed and carries the principal-signed DA JWT as the 'da' claim, preserving AIC's two-layer signature model. The draft specifies the mapping from X.509 AIC extension fields to JWT claims, representation and key-binding rules for the DelegationAuthorization, validation rules, and a thin OAuth 2.0 profile for presenting the DA as an RFC 7523 grant.

Profiles the WIMSE HTTP Message Signatures mechanism to protect a request that passes through a chain of workloads. In the base mechanism each workload signs independently, so an intermediary can remove a signature undetected and signatures accumulate on every hop. This draft combines the workloads' signatures into a single aggregate signature: removing a signature becomes detectable, and the signature material no longer grows with chain length — a significant saving for post-quantum signature algorithms, whose signatures are large. It works with any aggregate signature scheme. A first version (-00).

Gives an overview of 'pacing', the technique of evenly spacing out a data sender's traffic over a round-trip time to reduce burstiness that can cause unnecessary queuing and packet loss. It explains why applications and congestion-control mechanisms produce bursty traffic and how several known pacing implementations work. An IRTF ICCRG informational overview rather than a protocol specification.

Proposes updates to RFC 2289, which describes a One-Time Password (OTP) system. The draft adds an application programming interface to the newer Secure Hash Algorithms (SHA-256, SHA-384 and SHA-512), an algorithm for folding hashes to 64 bits, the use of alternate dictionaries, and automatic renewal of authentication parameters. A first version (-00) modernising the OTP system's hash support.

Describes how an Extensible Provisioning Protocol (EPP) connection is mapped onto HTTP. EPP over HTTP (EoH) requires the use of Transport Layer Security to secure EPP information — that is, HTTPS. A focused REGEXT working-group draft defining the EPP-over-HTTPS transport binding.

Defines a precision-bounded egress profile: a data-minimization mechanism applied at the point of external disclosure, on top of an execution-finality architecture, for both conventional apps and autonomous AI agents. It observes that OS permission to read a location fix does not decide whether that fix may leave the device at the requested precision, and that an app legitimately reading exact GPS often shares its process with an embedded SDK or sync path that can forward the exact coordinate onward. A location release is a Candidate Act that stays non-effective while a Protected Enforcement Domain evaluates purpose, requester, recipient, jurisdiction, required precision and cumulative disclosure, then issues authority for a specific precision ceiling; an egress Finality Sink verifies it against the outbound payload. The result may be exact data, a reduced representation, or denial.

An informational execution-finality profile for AI-native 5G, 5G-Advanced, IMT-2030/6G, O-RAN and AI-RAN environments. It argues that authenticating a network function or AI controller does not establish authority for every routing, signaling, session, resource-allocation, sensing or subscriber-specific consequence it can generate. A proposed operation is a Network Candidate Act held non-effective while a Protected Enforcement Domain validates act-specific predicates and commits evidence before releasing scoped non-bearer authority; a Network Finality Sink verifies it just before live network state changes. The governing rule is that network authentication is not network finality. This revision adds a JSON interoperability profile and positions the work as complementary to, and distinct from, industry AI-native 6G radio/platform roadmaps.

Proposes updating the AUTH48 (or equivalent) process by introducing deterministic state-integrity constraints within the IETF Datatracker architecture. It establishes automated validation milestones and explicit access controls to prevent late technical modifications after Working Group Last Call, thereby safeguarding the rough consensus. The draft updates RFC 7841.

Presents a two-layer federated architecture for the IETF DAWN (Discovery of Agents With Names) work, which addresses discovery of AI agents and their capabilities across organizational boundaries. Layer 1, the Local Discovery Plane, enables zero-configuration agent advertisement within a site; Layer 2, the Federation Plane, exchanges lightweight Federation Metadata Records among site gateways while full Capability Cards are retrieved on demand over authenticated unicast. The framework prioritizes data sovereignty via an Export Policy Engine and accommodates multiple federation synchronization strategies. As an informational document it shows how existing DAWN mechanisms can be composed at administrative boundaries rather than defining new normative protocol.

Describes an architecture in which first contact and future reachability are separate authorization events for map-based and marketplace discovery. After a user creates a map search, property inquiry, service request or booking inquiry, a platform can create a query-scoped, non-bearer communication reference and bounded preview authority so a real but limited first interaction can occur; continued communication is separately authorized and bound to the original query, business identity, purpose, channel, validity window, nonce, quota and revocation state. A Communication Authority Service creates the binding while an enforcement point reconstructs the attempted communication and consumes authority before releasing the communication-bearing resource. Named platforms are used only as illustrative examples, and the draft notes alignment with GDPR data-minimization and purpose-limitation principles.

Argues that many communication systems treat possession of a routable identifier — a phone number, SIP URI, messaging handle or relay address — as sufficient to attempt contact, so a handle disclosed for one purpose remains a reusable reachability path afterward. It contrasts this with STIR/SHAKEN (which attest originating identity, not current purpose-scoped permission), masked numbers, OAuth and spam scoring. The draft describes an authorization-to-reach model: a visible handle is not permission to create a communication effect, and a request is held as a candidate until current, purpose-scoped, revocable, optionally consumable authority is validated. It is informational and asks whether the IETF ART area should define interoperable semantics, motivated by the shift toward machine-originated signaling at 6G/IMT-2030 scale.

Specifies a protocol mechanism for embedding service-type identifiers into network packets to enable intelligent traffic recognition, policy-based forwarding and resource optimization by network devices. Standardized service-type labels can be carried in IPv4/IPv6 headers, MPLS labels or Ethernet frame headers. It targets a range of services including immersive VR (e.g. 1080p, 4K), scientific computing, real-time communications and IoT applications.

By its name (SOOS / 'acd'), this appears to be an individual submission in a service- or operations-oriented space, likely defining an autonomic or automated control/discovery mechanism. No official Abstract could be retrieved for this version (the fast source page returned 404), so this summary is written from the name and is approximate; it will be grounded from the document's Abstract on the next run.