IETF Internet-Drafts & RFCs

A YANG Data Model and RADIUS Extension for Policy-Based Network Access Control

Defines a YANG data model for policy-based network access control that enforces policies based on group identity, and extends Access Control Lists with date and time parameters for schedule-aware policy enforcement. For cases where user authentication triggers network access, it describes a way to simplify maintaining the mapping between a user group identifier and packet-header fields, and it defines a RADIUS attribute that carries the user group identifier as part of identification and authorization information.

By its short name (VLSMTRP), this individual submission probably concerns a routing-protocol topic related to variable-length subnet masking. The official Abstract could not be retrieved on this run (the document page returned a fetch error), so this note is based on the draft name alone and will be grounded from the Abstract on the next run.

Specifies PCEP extensions so a stateful Path Computation Element can control Traffic-Engineered LSPs in both RSVP-TE and Segment Routing TE, whether the PCE or the head-end initiates them. It updates RFC 8733 by adding a mechanism to explicitly remove an attribute identified by a sub-TLV, which RFC 8733 lacked. It also extends automatic bandwidth adjustment to SR-TE LSPs in the SR-MPLS and SRv6 data planes and to multiple segment lists within one SR LSP, reusing the PCE multipath extensions.

Defines the Network-infrastructure Hiding Protocol (NHP), a cryptography-based session-layer protocol that applies Zero Trust principles by hiding protected resources from unauthorized entities. Authentication is required before any connection, so IP addresses, ports and domain names stay invisible to unauthorized users. The document gives the architecture, cryptographic framework, message formats and workflow, and presents NHP as a third generation of network-hiding after port knocking and Single-Packet Authorization, with guidance for integrating SDP, DNS, FIDO and Zero Trust policy engines.

Defines the Secure Advertisement and Neighborhood Discovery (SAND) protocol for Bundle Protocol version 7 (BPv7) in delay-tolerant networks. It is a general-purpose advertisement mechanism with an initial set of message and data types that participating BPv7 nodes can advertise. The initial focus is advertisement to topological neighbors about local neighborhoods, with extension points left for future expansion.

Describes how multiple Security Event Tokens (SETs) can be delivered to a single intended recipient in one HTTP POST over TLS. The SETs are carried in the body of a POST to a recipient-operated endpoint, and the recipient signals success or failure of the delivery in its HTTP response.

By its name, this individual submission in the network-modeling (NETMOD) space probably extends a 'comparability scope' mechanism for YANG/network data models. The official Abstract could not be retrieved on this run (fetch error), so this note is based on the draft name alone and will be grounded on the next run. Two revisions (-01 and -02) were announced in the window.

Defines the DNS-SD Data Block (DDB), a compact Type-Length-Value (TLV) encoded container for conveying DNS-Based Service Discovery information over non-IP transports used by short-range, peer-to-peer or proximity-based discovery technologies. Examples given include the Bluetooth Low Energy Transport Discovery Service and NFC NDEF records.

By its name, this individual submission in the network-modeling (NETMOD) space probably extends a 'comparability scope' mechanism for YANG/network data models. The official Abstract could not be retrieved on this run (fetch error), so this note is based on the draft name alone and will be grounded on the next run. Two revisions (-01 and -02) were announced in the window.

Defines an aggregate performance report format for email messaging, a means to discover target destinations for such reports, and a method for delivering them. The goal is standardized, machine-readable reporting of email performance data.

Defines OAuth Actor-Signed Hop Proofs, an optional companion to the OAuth Actor Profile for Delegation. Each proof is a signed JWT recording an actor's participation and its authorized target for a single delegation hop. The 'actor_proofs' claim holds a hash-linked chain of proofs verified against trusted actor-key sources. The document covers how proofs are conveyed and validated, how they optionally link to Actor Receipts, and the related metadata parameters and introspection response members.

Describes an HTTP-based process in which automated clients such as crawlers and AI agents request content, receive a price offer specific to that request, accept it, and obtain a signed authorization bound to that single request. Resource owners can run this themselves or delegate to rights managers who set per-request terms. The protocol does not dictate pricing, payment methods or billing; each authorization is bound to a request identifier, the resource, the authenticated operator, the intended use and a validity window. It is an optional extension to UCAP and leaves access controls, copyright law and private business deals in place.

Proposes the Universal Crawler Accountability Protocol (UCAP), an opt-in HTTP interface for automated clients such as search crawlers, archivers and AI-assisted agents. It lets origin operators check individual requests via a per-request identifier tied to an authenticated client, file and track abuse reports, and ask a crawler operator to stop visiting an origin. It builds on HTTP Message Signatures, does not identify end users to the origin, and does not replace robots.txt or existing site access controls. The authors note that its privacy, authorization and operational trade-offs need further review.

Specifies how to proxy Ethernet frames in HTTP. It is analogous to IP proxying in HTTP but operates at Layer 2 rather than Layer 3, defining how an HTTP client can open a tunnel through an HTTP server attached to a physical or virtual Ethernet segment and exchange Layer 2 Ethernet frames through that tunnel.

Argues that network-management systems able to reason do not need a data model agreed in advance to interoperate: each system can lift its own data into a complete semantic model (ontology, lexicon, pragmatics and provenance), and two such models can then be reconciled ad hoc. It highlights pragmatics as easily overlooked but operationally important, and reports an empirical study across four network-management scenarios using independently built cases and several AI agent families. It is a research contribution and does not represent IETF or IRTF consensus.

Proposes adding deterministic state-integrity constraints to the IETF publication process in the Datatracker, including automated validation milestones and explicit access controls that block late technical changes after Working Group Last Call in order to protect rough consensus. The constraints are intended to apply across current and future processing streams. The document updates RFC 6359 and RFC 7841.

Proposes an archive profile for scientific and technical claims, covering sources, evidence tiers, falsifiers, tests, provenance, publication status and integrity manifests. Its stated purpose is to keep archival or mechanical integrity from being mistaken for empirical validity, novelty, peer review, standards approval or publication acceptance. The document notes it is an unsubmitted working document with no IETF standing unless separately submitted.

Defines nine post-quantum key-exchange algorithms for TLS 1.3, DTLS 1.3 and QUIC, all based on HQC-KEM, a code-based KEM selected by NIST for standardization in the forthcoming FIPS 207. The algorithms fall into four groups: three standalone HQC-KEM parameter sets; PQ/T hybrids with X25519 or X448; PQ/PQ hybrids with ML-KEM; and PQ/PQ/T hybrids combining HQC-KEM, ML-KEM and X25519 or X448. The rationale is algorithmic diversity: HQC-KEM rests on different hardness assumptions than lattice-based ML-KEM, limiting damage if lattice cryptography is later weakened.

Maps the list-pagination mechanism from its companion draft onto RESTCONF. It updates RFC 8040 to make 'list' and 'leaf-list' valid targets for the RESTCONF GET operation, adds GET query parameters for pagination, and defines a media type for XML-encoded lists.

Maps the companion draft's list-pagination mechanism onto NETCONF. It extends the <get> and <get-config> operations from RFC 6241 and the <get-data> operation from RFC 8526 with input parameters for paging through list entries.

Notes that instances of YANG-modeled 'list' and 'leaf-list' nodes can contain numerous entries, which strains servers, clients and the network when all are retrieved at once. It proposes a standard way to page through those entries, with optional filtering and sorting, for use with NETCONF and RESTCONF, and lets servers restrict queries on some read-only lists.

Describes how EST-coaps enrollment can work when a field device has no initial certificate usable for DTLS client authentication. Instead of a certificate, the device authenticates during the DTLS handshake with a device-unique symmetric key, used directly or as the basis for a derived pre-shared key. The profile targets already-registered operational devices, keeps EST enrollment semantics unchanged, and is framed as an alternative to the certificate-based client authentication of RFC 9148 in the certificate-less scenarios RFC 7030 allows.

Gives application developers and SaaS providers guidance on testing IPv6 in dual-stack and IPv6-only environments, including 'IPv6-only-strict' setups with no connectivity to any relevant IPv4 endpoint. It argues that operating systems and libraries abstract IPv6 issues away less than developers often assume, and describes common regressions to avoid when adding IPv6 support.

By its name, this IPPM working group draft probably defines a YANG data model for configuring and managing on-path telemetry (such as in-situ OAM style measurements). The official Abstract could not be retrieved on this run (fetch error), so this note is based on the draft name alone and will be grounded on the next run.

Addresses that when a software agent pays on an organization's behalf, the settling party usually cannot see the policy that allowed it. It describes a signed authorization verdict, a JWT signed with ES256, recording the outcome of checking one payment request (amount, currency, recipient) against the organization's spending policy; anyone holding the issuer's published public key can verify a verdict without contacting the issuer. It covers the claim set, key publication and rotation, a verification procedure and what a verdict does not assert, and is offered as input to IETF discussion rather than as a standardization proposal.

Updates the TLS Supported Groups registry (formerly the EC Named Curve Registry) in anticipation of cryptographically relevant quantum computers. Its main change removes the Recommended status from non-post-quantum key shares. A note explains the authors' use of 'key share' rather than 'group' as more accurate and better known in the TLS context.

Proposes a two-layer federated reference architecture for discovering agents (initially AI agents) across organizational boundaries, aligned with the DAWN effort. A Local Discovery Plane handles zero-configuration advertisement within a site without a specific link-local protocol, and a Federation Plane lets site gateways exchange lightweight metadata records across administrative domains, with full Capability Cards fetched on demand over authenticated unicast. It emphasizes data sovereignty via an Export Policy Engine, is Informational with no normative formats, and is designed to complement existing DAWN proposals and be reusable for other entity types.

Describes a protocol-neutral pattern for content-addressed research artifacts, an append-only evidence history, explicit epistemic classes and corrigible active scientific state. It separates byte integrity from numerical correctness, empirical adequacy, mechanism identification and release authority.

Defines a protocol-neutral receipt for explicit promotion across evidence and claim-authority boundaries. Its aim is to stop raw observations, model outputs or unreviewed evidence from being quietly treated as state that carries authorization.

Proposes a protocol-neutral design that separates holding a capability from controlling the boundaries where that capability can cause real external effects. It models authority as what can be reached through a graph of capabilities over time, defines commitment points and independently controlled revocation cuts that can stop access to them, and specifies that evidence, authorization, delegation and revocation closure should fail closed, so that uncertainty results in denial rather than permission.

Defines an informational research framework for describing anthropogenic perturbations: human-caused changes that shift when, how likely, how linked or how severe threshold transitions in Earth systems become. The framework applies even when human activity does not control the system's main energy source.

Defines MLKEM1024X448, a post-quantum/traditional hybrid key exchange for TLS 1.3 pairing ML-KEM-1024 with X448. It targets a higher security level than X25519MLKEM768, matching AES-256 and ChaCha20, arguing that a larger margin guards against future cryptanalysis, misuse and implementation errors. It notes X448 is faster and more robust than comparable P-curves, that a FIPS-validated implementation ensures the ML-KEM-1024 component is FIPS-validated, and that the algorithm is intended for TLS 1.3, DTLS 1.3 and QUIC.

Describes a proof-of-record package for source-grounded agentic outputs and scientific archives, covering structural validation, conformance evaluation, byte and sequence integrity, governance authorization and provenance recoverability. It states plainly that it does not prove scientific truth.

An unsubmitted working draft describing state-preservation semantics derived from UNISON-StateBench. It distinguishes a value from what is known about it, where it came from and who controls it, and bars systems from treating one workflow state as proof of another. It lists evaluation categories for testing these properties and states it is an archival working draft rather than an IETF submission.

Proposes, from a network operator's perspective, a framework for building IPv6-only core networks spanning multiple interconnected Autonomous Systems. Remaining IPv4 traffic is carried using stateless IPv4/IPv6 address mapping, with packets translated at the network edge and crossing the IPv6 core without per-flow state or gateways in the data path. It is a problem statement, guidance and requirements rather than a protocol spec, and addresses applicability, trust boundaries, IPv6 mapping-prefix allocation, and operational, manageability and security considerations.

The official Abstract could not be retrieved on this run (fetch error), and the short name (AER1) does not clearly indicate the topic, so no reliable summary can be given yet. It is listed here from the index only, and will be grounded from the Abstract on the next run. Three revisions (-13, -14, -15) were announced in the window.

Defines a trailer format for recording peer review in version-control and document metadata, extending an earlier identity-attributed-commit specification. It adds one required trailer, Reviewed-By, and three optional ones (Review-Stance, Review-Of, Witnessed-By), linking a reviewer's sovereign handle to an Ed25519-signed review of a specific artefact so that altering the role, stance or target invalidates the signature. It applies to git commits, manuscripts, preprints and patent disclosures, keeps reviews tied to the reviewer rather than a publisher, supports anonymous review via out-of-band key custody, and complements CRediT, ORCID and DOI rather than replacing them.

Defines a trailer format for git commit messages that attributes each commit to an identity, addressed with a '~handle' primitive from a companion DNS discovery draft. It sorts contributors into three tiers (human/organizational signers, delegated bots, and AI tools that cannot sign), each with its own trailer, and rejects a handle placed under the wrong tier. Optional trailers carry an Ed25519 signature, key identifier and transparency-log reference. The signature covers the commit's patch identifier, so it survives rebase, cherry-pick and amend as long as the change is unchanged; merge commits cannot be signed. It relies only on DNS, with no central authority.

Describes a discipline for how autonomous agents should handle their working beliefs. Each belief is held as a reference to a single named lowest authority and resolved live at the point of use; if the authority is unreachable or the value is stale, the belief enters an explicit uncertainty state rather than falling back on a cache. That uncertainty propagates to derived beliefs, and an uncertain belief feeding a costly or irreversible action should block or escalate it. Every reference chain must end at a single self-authorizing root. It is Informational and defines a vocabulary and practice, not a wire protocol.

Defines the 'alter' URI scheme as a dispatchable way to reference '~handle' identities published in DNS records. An alter: URI links a handle to a procedure that retrieves its envelope from a DNS zone, validates the signature chain and passes the result to an OS URI handler, verifying the envelope before acting. It can optionally name an organisation, a facet of the identity and an action surface, reuses the resolution semantics of the companion MCP discovery spec, introduces no new cryptographic primitive, and notes IANA provisionally registered the scheme on 5 October 2026.

Proposes a DNS-based way to discover Model Context Protocol (MCP) servers, identify the organisations that run them, and publish a signed identity envelope for an individual's handle. It defines three TXT records: one for an MCP server's endpoint and capabilities, one for the operator's organisational identity, and one for the signed individual envelope. The envelope requires DNSSEC, and a DANE TLSA pin is required when envelope resolution and opening an MCP session happen as one transaction. It positions itself as a complement to HTTPS-based discovery, following the design of DKIM and SPF.

Defines OAuth Actor Receipts, an optional companion to the OAuth Actor Profile for Delegation. Each receipt is a signed JWT recording which issuer added an actor hop and optionally that hop's historical presenter binding. Receipts are linked by hashes in an 'actor_receipts' claim, and recipients verify each one against the issuer that created it. The document specifies receipt processing rules, metadata parameters and introspection response members.

Defines a common representation of delegated actors in OAuth JWT assertion grants. It profiles the OAuth 'act' claim from RFC 8693, requires issuer-scoped actor identifiers, and uses a 'sub_profile' claim to classify each actor's entity type. It covers token processing, delegation-chain propagation, sender-constraint handling and discovery metadata so that issuers and resource servers across trust domains interpret delegated actors consistently.

Expands the IPv6 loopback space from the single address ::1 to a /48 prefix defined as Node-Local Unicast space, allowing many loopback addresses and internal virtual networks on one host for inter-process communication, local virtualization, container networking and diagnostics. It updates RFC 4291 to define the prefix and its semantics and RFC 4007 to integrate it into the scoped address architecture, and updates the IPv6 Address, IPv6 Special-Purpose Address and Locally-Served DNS Zone registries.

Describes performance-measurement procedures for SRv6 networks using the Simple Two-Way Active Measurement Protocol (STAMP), with the optional extensions of RFC 8972 and the SR-specific extensions of RFC 9503. The procedures measure links and SRv6 paths, including SRv6 Policy segment lists, IGP best paths and Flexible Algorithm paths, as well as the Layer-3 and Layer-2 services carried over them.

Describes how to measure performance in SR-MPLS networks using STAMP (RFC 8762) with its optional extensions (RFC 8972) and SR-specific extensions (RFC 9503). The procedures cover SR-MPLS policy segment lists, IGP best paths and Flex-Algo paths, as well as the Layer-3 and Layer-2 services carried over them.

Addresses resource servers that receive audience-restricted access tokens and need to call downstream services, requiring a token exchange so the audience fits the downstream service. It proposes anchoring the exchange authorization in the subject token's audience: the authorization server checks whether the requesting client is associated with the audience-restricted resource the token identifies, then applies its remaining policy. The association can be established by local policy, by validating a client JWT against the resource's jwks_uri, or via a new Protected Resource Metadata parameter listing the resource's token-exchange clients.

Defines YANG data models for performance monitoring and scaling intent on Traffic Engineering (TE) tunnels and Virtual Networks (VNs). The models let customers subscribe to and monitor key performance data for a TE tunnel or VN and configure autonomic scaling intent at both the tunnel and VN levels.

The official Abstract could not be retrieved on this run (fetch error), and the short name (AER1) does not clearly indicate the topic, so no reliable summary can be given yet. It is listed here from the index only, and will be grounded from the Abstract on the next run. Three revisions (-13, -14, -15) were announced in the window.

Observes that much has changed since RFC 4086 ('Randomness Requirements for Security') twenty years ago, and that facilities to generate high-quality random numbers are now widely available on most common computing platforms. Rather than repeating RFC 4086's detailed implementer guidance, the draft encourages implementers to use the facilities already available to them.

Explains how TLS 1.3 serves as a key-management method for the SCTP DTLS Chunk mechanism. An initial TLS handshake establishes the security context for an SCTP association, and later handshakes handle key updates and re-authentication, providing authenticated, confidential SCTP communication built on standard TLS 1.3 keying and rekeying.

Defines a way to add DTLS-based authentication and cryptographic protection to SCTP, giving applications communication privacy that prevents eavesdropping and detects tampering or forgery, covering both the payload and SCTP control information. Most SCTP features and extensions remain usable; the SCTP Authentication extension (RFC 4895) is incompatible and adds no further service, so Dynamic Address Reconfiguration (RFC 5061) may only be used as described. It obsoletes RFC 6083 and updates RFC 5061.

The official Abstract could not be retrieved on this run (fetch error), and the short name (AER1) does not clearly indicate the topic, so no reliable summary can be given yet. It is listed here from the index only, and will be grounded from the Abstract on the next run. Three revisions (-13, -14, -15) were announced in the window.

Defines the Walled Private Network (WPN) as a technology-neutral profile for a private IP network or service. A conforming WPN has a defined address space, explicit membership and member addresses that pass end to end without NAT between members, offering protocol-transparent IP connectivity among authorized members but not general Internet access. The public Internet may serve as the underlay, and networks behind individual members fall outside the base service. It specifies no new tunneling, routing or cryptographic protocol, and a VPN is not required for conformance.

Defines the 'linkid' URI scheme, a persistent, location-independent identifier made of the scheme name and a UUID. Resolvers map a LinkID to a current actionable URI, while names, locations, versions and operator relationships are stored as associated data rather than in the identifier. It covers syntax, comparison, resolution semantics and an HTTPS binding, and asks IANA to update the existing provisional registration for the scheme.

Notes that shortest-path routing is loop-free but feature-poor, ECMP adds resiliency and load distribution but stays limited, and Traffic Engineering offers rich control but typically one path per tunnel. It proposes multipath traffic engineering (MPTE), combining the strengths of both: multipaths need not be strictly equal-cost (some path-length 'slack' is allowed), load balancing is weighted per next hop, and traffic can enter and leave through multiple ingresses and egresses. It also describes several possible control- and data-plane designs.

Addresses EVPN deployments where sites of the same EVPN sit in different IGP domains or Autonomous Systems and must communicate, focusing on the widely used Inter-Domain Option-B model. It notes that although other documents cover particular aspects, none comprehensively explain how this model affects EVPN procedures; it examines those effects and proposes solutions to the issues it identifies.

Defines a zero-configuration protocol for dynamically assigning IPv6 multicast addresses that are unique at the link layer. Applications randomly choose multicast group IDs from a defined range and avoid collisions by publishing records through Multicast DNS under a new 'eth-addr.arpa' domain. The protocol meets all the criteria set out in RFC 10019.

Describes an evidence log that stores only salted digests of records (not the records themselves) as leaves in an RFC 9162 Merkle tree. It defines three constructions over that tree: completeness chains showing a set of records is whole; selective disclosure revealing one field of a sealed record while keeping others private; and spot checks that verify records were kept by testing an unpredictable random sample. It also profiles SCITT registration so the log keeps only a digest of each signed statement, and ships with running code and test vectors.

Specifies several updates and clarifications to the grammar and semantics of OpenPGP messages.

Describes how BGP Flow Specification (BGP-FS) distributes both traffic flow specifications and traffic filtering actions, and defines a new BGP-FS component type that matches on the BGP Community attribute associated with a destination IP address in the Flowspec NLRI. It is intended for use within a single administrative domain.

Describes how BGP Flow Specification (BGP-FS) distributes both traffic flow specifications and traffic filtering actions, and defines a new BGP-FS component type that matches on the BGP Community attribute associated with a destination IP address in the Flowspec NLRI. It is intended for use within a single administrative domain.

Proposes vendor-neutral, repeatable test methods for measuring Ethernet fabrics carrying AI inference traffic, targeting large language model deployments that split prefill and decode across many accelerators, where the network affects time to first token, inter-token latency and tokens-per-second throughput. The methods cover RDMA-based KV-cache transfers, Mixture-of-Experts AllToAll communication, request routing, congestion under bursty load, and scale and soak testing, enabling direct comparison of RoCEv2 and UET transport stacks. It is a companion to the AI training fabric benchmarking methodology.

Defines benchmarking terms, test methods and key performance indicators for Ethernet-based fabrics used in AI training. As training clusters grow to tens of thousands of accelerators, the backend network strongly affects job completion time, training throughput and accelerator utilization. It proposes vendor-neutral, repeatable procedures for realistic training workloads covering RoCEv2 and Ultra Ethernet Transport, congestion control, load balancing, collective communication patterns and scale/soak testing, to allow reproducible comparisons across switch chips, NIC transport stacks and fabric designs such as 2-tier Clos, 3-tier Clos and rail-optimized topologies.

Defines benchmarking terminology for Ethernet-based network fabrics that support distributed AI training and inference, building on RFC 1242 and RFC 8238. The terms cover collective communication operations, RDMA transports (RoCEv2 and Ultra Ethernet Transport), congestion-control behavior, AI-specific performance indicators and fabric topology. It is a companion to the AI fabric training and inference methodology documents; where definitions overlap with RFC 1242 or RFC 8238, those RFCs remain authoritative for general network benchmarking.

Specifies how JOSE and COSE serialize composite hybrid signatures that pair a post-quantum and a traditional algorithm. The composite schemes combine ML-DSA, a lattice-based post-quantum signature algorithm, with either ECDSA or EdDSA as the traditional component.

Provides guidance for adding post-quantum cryptography to low-resource devices such as IoT nodes and dedicated key-storage hardware that have tight limits on computing power, memory and sometimes battery life. Treating hardware-based security as the foundation, it covers techniques such as deriving keys from stored seeds to reduce persistent storage, handling temporary keys efficiently and offloading cryptographic work, and examines how post-quantum requirements affect firmware updates on these devices.

Defines a data structure that can be attached to certain ICMP messages, letting network operators see environmental data such as per-hop (per-node) power metrics and other current or future sustainability measures. The authors tie it to an objective of the IAB E-Impact workshop report. It works for one-off tools like traceroute and ping and for scheduled measurements run across a network's administrative domain.

Defines a content profile for AI output verification receipts, setting out the minimum fields, a classification scheme and the evidentiary properties a receipt needs to show that an AI output was checked before a person or another agent acted on it. The profile is meant to work over existing formats such as ACTA signed receipts, SCITT logs and JSON or CBOR payloads. Arguing that existing drafts cover signing and transport but not receipt content, it introduces a fourteen-category failure taxonomy, a verdict schema and evidentiary requirements tied to the EU AI Act, the Product Liability Directive and IDW PS 861.

Specifies the design for inter-domain multicast overlays using the Locator/ID Separation Protocol (LISP), defining how multicast traffic between sites is carried over LISP overlays running over either multicast or unicast underlay networks. It explains how PIM-based signaling can configure LISP encapsulators with a list of replication targets that may mix multicast and unicast locators. Once approved, it will replace RFC 6831.

Defines the PSEA Token Profile, an Entity Attestation Token (EAT) profile for signed proof tokens showing a person was present, verified at an authenticator and approved a specific action at execution time. It covers the encoding, claims, action-payload binding and an optional hash-chain integrity layer. It binds what is signed to what the Verifier executes, but does not bind what a human saw on a possibly compromised display to what was signed; the strength of the human-presence assurance depends on the authenticator's user-verification enforcement. It does not prove a specific human's identity and complements OAuth 2.0 Step-Up Authentication.

Presents a server-side model for paid, human-sourced asynchronous HTTP tasks that software agents start for a principal, where human contributors do the work. Clients may retry after uncertain outcomes and act under authority delegated in advance, and a payment or entitlement check precedes any fulfilment work. Under stated assumptions it guarantees that fulfilment never starts before the check passes, that each idempotency key maps to at most one task and that each payment requirement is accepted at most once, with a verifiable audit record. It defines no protocol, wire format or conformance requirements.

Specifies how IKEv2 peers can use Merkle Tree Certificates (MTCs) for authentication. An MTC replaces a directly-signed end-entity certificate and its CA chain with an inclusion proof, shrinking the IKE_AUTH exchange; the savings matter most for large post-quantum signatures such as ML-DSA and SLH-DSA. It also defines a CERTREQ certificate encoding that carries trust-anchor identifiers telling a peer which MTC CAs and landmarks the other side trusts.

Notes that entropy labels can improve load-balancing in SR-MPLS data planes and that several ELI/EL pairs can be inserted into the label stack under RFC 8662. It defines PCEP extensions that tell a router where in the label stack those pairs should be placed, which it calls Entropy Label Positions.

By its announcement title, 'Benchmarking Methodology for Segment Routing (SR) Forwarding', this BMWG working group draft probably specifies test procedures for benchmarking SR forwarding performance. The official Abstract could not be retrieved on this run (fetch error), so this note is based on the announcement title, and will be grounded from the Abstract on the next run.

The official Abstract could not be retrieved on this run (fetch error), and the short name (VDAC) does not clearly indicate the topic, so no reliable summary can be given yet. It is listed here from the index only, and will be grounded from the Abstract on the next run.

Gives application developers and SaaS providers guidance on testing IPv6 in dual-stack and IPv6-only environments, including 'IPv6-only-strict' setups with no connectivity to any relevant IPv4 endpoint. It argues that operating systems and libraries abstract IPv6 issues away less than developers often assume, and describes common regressions to avoid when adding IPv6 support.

The official Abstract could not be retrieved on this run (fetch error), and the short name (SAIP) does not clearly indicate the topic, so no reliable summary can be given yet. It is listed here from the index only, and will be grounded from the Abstract on the next run.

Notes that the IOAM Trace-Option data of RFC 9197 has variable length depending on how many IOAM-capable nodes a packet passes through and which fields each records. It proposes extending the Trace Option to carry fixed-size data whose length is set once each node's field selection is determined and stays the same regardless of how many nodes are traversed.

Proposes a QUIC extension that helps endpoints behind NATs set up a direct network path. Endpoints use an existing proxied QUIC connection to coordinate path-validation attempts, which create the needed NAT mappings and check that a direct path works, while application data keeps flowing over the proxied path. If a suitable direct path validates, the connection can migrate to it.

Introduces a new BGP Extended Community, the IFIT Action Specific Extended Community, for distributing In-situ Flow Information Telemetry (IFIT) actions, so that on-path flow telemetry can be deployed automatically across the IPv4 unicast, VPNv4 unicast and IPv6 address families. It builds on the BGP Flowspec mechanism that propagates flow specifications and traffic-filtering actions.

Specifies the Mail Action Protocol (MAP), which lets email offer actions such as approving an article for publication. Each decision has a type contract defining its meaning and effects, and a trusted service binding connects the decision to an existing service operation. Before acting, a client reads the current proposal and applies the user's policy; the service then checks permission and exact terms when recording the decision. MAP uses Structured Email's MIME and JSON-LD format, with the core independent of the calling interface, and defines an HTTP binding, registry discovery rules and an experimental capability binding for actions needing no service account.

Proposes a separate, versioned companion record that attaches named attribution to two already-fixed source hashes, leaving those artifacts unedited. It uses canonical JSON bytes, a fixed message prefix and pure Ed25519 signatures, and keeps integrity, signer authority, source equality, revision freshness and private reference resolution as separate checks. A public-safe record would require its own approved payload and signature. It presents an evidence-preservation practice rather than a new cryptographic primitive; trust provisioning, implementation tests and public reproducibility remain open.

Defines a new RPKI-to-Router Protocol PDU type, the 'IPv6 Mapping Prefix' PDU, that carries Mapping Origin Authorization (MOA) data from RPKI caches to routers, linking one or more IPv4 prefixes to the IPv6 mapping prefix authorized to originate them. With this data, routers can perform Mapping Origin Validation on IPv4-to-IPv6 mapping announcements in IPv6-only underlay networks, helping prevent IPv4 prefix hijacking.

Defines a YANG data model for BGP Flow Specification implementations, including both configuration data and state data.

Expands the IPv6 loopback space from the single address ::1 to a /48 prefix defined as Node-Local Unicast space, allowing many loopback addresses and internal virtual networks on one host for inter-process communication, local virtualization, container networking and diagnostics. It updates RFC 4291 to define the prefix and its semantics and RFC 4007 to integrate it into the scoped address architecture, and updates the IPv6 Address, IPv6 Special-Purpose Address and Locally-Served DNS Zone registries.

Observes that the CATS framework defines the C-SMA as the component that collects service capability and status data and reports it to C-PSes but leaves its observable behavior underspecified. It specifies that behavior, covering metric collection, validation against erroneous or malicious data, soft-state management for stale or failing Service Contact Instances, cache aging, policy enforcement, and recovery and reconciliation with the C-PS. It includes an illustrative, non-mandated internal component decomposition and positions itself as the operational layer complementing other CATS documents.

Defines learnlog, a log format for learning software in which each record holds typed events describing a learner's actions and other parties' responses. Entries are chained by hash and a producer can sign the chain, so a reader who trusts the signing key can detect unauthorized changes to signed entries; some changes cannot be detected and are listed in Security Considerations. An event can be redacted while the rest of the record still verifies. The format covers files, records, entries, events and registries for event schemas, but leaves subject-specific schemas out.

Describes a way to advertise the performance metrics for Traffic Engineering (TE) Policy using BGP Link State (BGP-LS).

Specifies the Sovereign Validation Protocol (SOVP), which lets a consumer check, before ingesting data, that a signed identity document came from the party controlling the Ed25519 key published in DNS for a host. The consumer fetches a JSON document from a well-known location, canonicalizes it and verifies the signature against the DNS-published key. It covers the signed scope, retrieval and key resolution, freshness checks, resource limits for unverified input and an optional extension binding a document to a deployment instance. It does not establish legal identity, content accuracy or the configuration of the serving system.