{ "days": 7, "to": null, "count": 362, "total": 362, "areas": { "art": "ART", "int": "INT", "ops": "OPS", "rtg": "RTG", "sec": "SEC", "wit": "WIT", "gen": "GEN", "irtf": "IRTF", "other": "Other" }, "topics": { "routing": "Routing", "transport": "Transport", "web": "Web/HTTP", "realtime": "Real-time media", "dns": "DNS/naming", "ip": "IP/addressing", "security": "Security", "iot": "IoT", "netmgmt": "Net management", "measurement": "Measurement/OAM", "email": "Email/messaging", "ai": "AI/agents", "cloud": "Cloud/DC", "wireless": "Wireless/satellite", "process": "Process", "other": "Other" }, "kinds": { "spec": "specification", "requirements": "requirements / use cases", "informational": "informational / guidance", "other": "other" }, "drafts": [ { "name": "draft-dahm-opsawg-tacacs-sshpk", "title": "SSH Public Key Distribution for Device Administration using Terminal Access Controller Access-Control System Plus (TACACS+)", "rev": "00", "new": true, "revised": "2026-10-24T14:37:48Z", "found": "2026-10-24T14:47:07.410Z", "pages": 9, "group": "individual", "group_type": "individual", "submitter": "dahm", "area": "ops", "area_label": "OPS", "area_source": "classifier", "area_confidence": 0.76, "topic": "security", "topic_label": "Security", "topic_confidence": 0.78, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "SSH [RFC4251] provides a robust and reliable mechanism to connect to network devices for administration. Conventionally, the public keys required to authenticate SSH sessions are provisioned directly on the network devices. This document adds an extension to Terminal Access Controller Access-Control System Plus (TACACS+) to eliminate the need for the direct provisioning of SSH public keys onto the Network Devices.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-dahm-opsawg-tacacs-sshpk/", "html": "https://datatracker.ietf.org/doc/html/draft-dahm-opsawg-tacacs-sshpk", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-dahm-opsawg-tacacs-sshpk" } }, { "name": "draft-wei-capability-language-core", "title": "Capability Language Core", "rev": "01", "new": false, "revised": "2026-10-24T13:56:59Z", "found": "2026-10-24T14:47:07.410Z", "pages": 127, "group": "individual", "group_type": "individual", "submitter": "wei", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.98, "topic": "security", "topic_label": "Security", "topic_confidence": 0.88, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document defines the Capability Language Core (CLC), a minimal, executable language for describing what an agent is authorized to do. It defines the capability identifier grammar, the entailment relation between a grant and an operation, intersection of grants from multiple sources, the constraint model, and a deterministic decision function with stable reason codes and a three-valued verdict (allow, deny, allow_unresolved). The language is carrier-neutral: it defines what is evaluated, not how it is carried or trusted. Trust models, native verification, execution lifecycle, and receipt or token formats are out of scope (Section 11). Conformance is exercised by a published corpus of 154 vectors and 1184 property cases; three implementations (Go, Python, TypeScript) that share an author pass both. *Implementation conformance and this document's claim of a conformance class are separate.* An implementation conforms to CLC-A when it meets the obligations Section 12 lists for that class, and it may claim that conformance on its own, whatever other implementations exist. Section 12 additionally sets a maturity bar for _this document's_ claim — two independent implementations agreeing on verdict and reason. That bar is *not* met here: as Section 12 states under \"Independence of implementations\", the three implementations named in the README share an author, so their agreement is a regression test for the text, not independent validation. CLC-A is still claimed by this revision as the baseline authorization class, whose obligations are implementable and exercised by a published corpus; the independent-implementation threshold is recorded as unmet. The evidence-side class CLC-E is *not* claimed: its relations, value grammar, reference implementation and corpus ship here. This revision also folds the delegation *containment* relation into the document (Section 13): Contains(parent, child) decides whether a child grant stays inside a parent's declared boundary — the single question a delegation chain asks at every hop that the core's entailment and intersection do not answer. It ships with the conformance class *CLC-D* and its own corpus, is strictly additive, and changes no CLC-A verdict, reason code, or vector. It absorbs the previously separate experimental containment extension, which is retired.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-wei-capability-language-core/", "html": "https://datatracker.ietf.org/doc/html/draft-wei-capability-language-core", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-wei-capability-language-core" } }, { "name": "draft-acosta-deepspace-celestial-bodies-registry", "title": "Defining a Celestial Bodies Reference Framework for Deep Space Internet Addressing", "rev": "04", "new": false, "revised": "2026-10-24T13:19:18Z", "found": "2026-10-24T13:47:06.886Z", "pages": 5, "group": "individual", "group_type": "individual", "submitter": "acosta", "area": "int", "area_label": "INT", "area_source": "classifier", "area_confidence": 0.91, "topic": "ip", "topic_label": "IP/addressing", "topic_confidence": 0.62, "kind": "informational", "kind_label": "informational / guidance", "kind_confidence": 0.83, "classifier": "jev-1.13.0", "abstract": "This document highlights the operational framework within Deepspace/ TIPTOP protocols to utilize an external, standardized reference framework for celestial objects, functioning as an equivalent to ISO 3166 for interplanetary networking. To avoid operational overhead and duplication of effort, this framework defers the definitions, naming, and tracking of celestial entities directly to the International Astronomical Union (IAU) and the Minor Planet Center (MPC). This document outlines how these external identifiers guide hierarchical address allocation without requiring IANA to maintain a dedicated astronomical nomenclature registry. The ultimate objective is to establish a clear definition of what constitutes a valid Celestial Body for networking purposes. From a resource-management perspective, this framework remains identical regardless of whether the target location hosts human colonies, scientific equipment, or autonomous robotic assets; any entity requiring internet and communication access must rely on a stable celestial anchor.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-acosta-deepspace-celestial-bodies-registry/", "html": "https://datatracker.ietf.org/doc/html/draft-acosta-deepspace-celestial-bodies-registry", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-acosta-deepspace-celestial-bodies-registry" } }, { "name": "draft-jiang-idr-bgp-soda", "title": "BGP Signed Origin Delegation Attestation (SODA)", "rev": "01", "new": false, "revised": "2026-10-24T13:07:08Z", "found": "2026-10-24T13:47:06.886Z", "pages": 19, "group": "individual", "group_type": "individual", "submitter": "jiang", "area": "rtg", "area_label": "RTG", "area_source": "classifier", "area_confidence": 1, "topic": "routing", "topic_label": "Routing", "topic_confidence": 0.99, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document defines BGP Signed Origin Delegation Attestation (SODA), an optional transitive BGP path attribute that carries a signed authorization, issued by the holder of an IP prefix, delegating origination of that prefix to a specified Autonomous System (AS) until a stated expiry time. Using SODA, a validator performing Route Origin Validation (ROV) can determine whether an ROV-Invalid result reflects an authorized delegation rather than a route hijack.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-jiang-idr-bgp-soda/", "html": "https://datatracker.ietf.org/doc/html/draft-jiang-idr-bgp-soda", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-jiang-idr-bgp-soda" } }, { "name": "draft-kamimura-scitt-vcp", "title": "A SCITT Profile for Verifiable Audit Trails in Algorithmic Trading: The VeritasChain Protocol (VCP)", "rev": "05", "new": false, "revised": "2026-10-24T12:31:35Z", "found": "2026-10-24T12:47:07.211Z", "pages": 32, "group": "individual", "group_type": "individual", "submitter": "kamimura", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.98, "topic": "security", "topic_label": "Security", "topic_confidence": 0.98, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document defines a profile of the SCITT (Supply Chain Integrity, Transparency, and Trust) architecture for creating tamper-evident audit trails of AI-driven algorithmic trading decisions and executions. The VeritasChain Protocol (VCP) applies the SCITT framework to address the specific requirements of financial markets, including high-precision timestamps, considerations arising from recordkeeping regimes such as the EU AI Act and MiFID II, and a crypto-shredding mechanism intended to support erasure obligations such as those under the GDPR. This profile specifies how VCP events are encoded as SCITT Signed Statements, registered with Transparency Services, and verified using COSE Receipts. It further defines SCITT conformance profiles for interoperability and an ERASURE event type that records crypto-shredding operations as append-only audit events. The profile makes trading records auditable and attributable after the fact; it does not prevent or block any trading activity, and it does not warrant the correctness of any recorded decision.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-kamimura-scitt-vcp/", "html": "https://datatracker.ietf.org/doc/html/draft-kamimura-scitt-vcp", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-kamimura-scitt-vcp" } }, { "name": "draft-kamimura-vap-framework", "title": "Verifiable AI Provenance Framework (VAP): An Architectural Framework for Auditable AI Decision Trails", "rev": "02", "new": false, "revised": "2026-10-24T12:07:09Z", "found": "2026-10-24T12:47:07.211Z", "pages": 40, "group": "individual", "group_type": "individual", "submitter": "kamimura", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.99, "topic": "ai", "topic_label": "AI/agents", "topic_confidence": 0.5, "kind": "informational", "kind_label": "informational / guidance", "kind_confidence": 0.8, "classifier": "jev-1.13.0", "abstract": "Automated decision-making systems, including AI and algorithmic systems in critical infrastructure, currently lack standardized mechanisms for producing provenance records that third parties can verify independently. Traditional logging approaches do not provide the cryptographic properties that regulatory examination, forensic investigation, and cross-organizational accountability depend on: detectability of alteration, detectability of omission after commitment, and attribution. This document describes the Verifiable AI Provenance Framework (VAP), an architectural framework that defines requirements for producing verifiable decision trails using existing IETF security technologies. VAP does not define new protocols or cryptographic primitives; rather, it provides an architectural coordination layer that enables domain-specific profiles to leverage Supply Chain Integrity, Transparency and Trust (SCITT), Remote Attestation Procedures (RATS), CBOR Object Signing and Encryption (COSE), and related IETF work in a consistent manner. VAP makes records auditable and attributable after the fact. It does not prevent, block, or intercept any system behaviour, and it does not warrant that any recorded decision was correct, fair, or safe. The detailed requirement set is maintained by the VeritasChain Standards Organization (VSO) as a separate specification; this document describes the architecture and its mapping to IETF work. This document is intended to frame the problem space and facilitate discussion about whether architectural coordination work is needed in this area.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-kamimura-vap-framework/", "html": "https://datatracker.ietf.org/doc/html/draft-kamimura-vap-framework", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-kamimura-vap-framework" } }, { "name": "draft-kamimura-scitt-refusal-events", "title": "Verifiable AI Refusal Events using SCITT", "rev": "04", "new": false, "revised": "2026-10-24T12:05:59Z", "found": "2026-10-24T12:47:07.211Z", "pages": 22, "group": "individual", "group_type": "individual", "submitter": "kamimura", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.98, "topic": "ai", "topic_label": "AI/agents", "topic_confidence": 0.85, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document defines a claim set for recording AI content refusal events. The claim set specifies the semantic content and correlation rules for refusal audit trails, independent of any particular serialization format. The claims are designed to be carried within SCITT Signed Statements and verified using SCITT Receipts. This specification addresses claim semantics and verification requirements; it does not mandate a specific encoding. A CDDL definition is provided for CBOR-based implementations, and equivalent JSON representations are shown in an appendix for illustration. This specification provides auditability of logged refusal decisions. It does not define content moderation policies, classification criteria, or what AI systems should refuse.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-kamimura-scitt-refusal-events/", "html": "https://datatracker.ietf.org/doc/html/draft-kamimura-scitt-refusal-events", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-kamimura-scitt-refusal-events" } }, { "name": "draft-vso-cpp-core", "title": "Capture Provenance Profile (CPP) Core", "rev": "04", "new": false, "revised": "2026-10-24T12:05:14Z", "found": "2026-10-24T12:47:07.211Z", "pages": 50, "group": "individual", "group_type": "individual", "submitter": "vso", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.99, "topic": "security", "topic_label": "Security", "topic_confidence": 0.99, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "The Capture Provenance Profile (CPP) is an open specification for cryptographically verifiable media capture provenance. This document defines the core data model, hashing conventions, Merkle tree construction rules, RFC 3161 Time-Stamp Authority (TSA) anchoring protocol, and offline verification procedures for CPP. CPP enables capture devices to produce tamper-evident provenance records that bind media content to external timestamps via trusted third parties. Unlike self-attestation models, CPP requires independent timestamp verification through RFC 3161 TSA services, providing externally verifiable proof of when media was captured. CPP defines self-attested signer identity, hardware-backed key requirements, chain context for partial submission detection, a Completeness Invariant for omission detection, an OPTIONAL depth analysis extension for screen detection, and an OPTIONAL Pre-Publish Verification Extension. It also defines interoperability mappings with the C2PA specification. This revision (-04) corrects the expansion of the profile name to Capture Provenance Profile, records the release status of the CPP specification series and the outstanding mapping to VAP v1.2, and adds an Implementation Status section. No hashing, tree construction, anchoring or verification rule is changed.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-vso-cpp-core/", "html": "https://datatracker.ietf.org/doc/html/draft-vso-cpp-core", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-vso-cpp-core" } }, { "name": "draft-izmaylov-agent-permission-receipts", "title": "Signed Permissions and Action Receipts for Automated Agents", "rev": "01", "new": false, "revised": "2026-10-24T11:41:35Z", "found": "2026-10-24T11:47:06.650Z", "pages": 46, "group": "individual", "group_type": "individual", "submitter": "izmaylov", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 1, "topic": "security", "topic_label": "Security", "topic_confidence": 0.91, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document specifies records with which a third party can establish, later and without network access, what an automated agent, such as an artificial intelligence (AI) agent, was permitted to do and what it recorded doing. The person for whom the agent acts, the principal, signs a permission with a passkey; the permission carries limits that a verifier can check mechanically. The agent signs a receipt for each action with Ed25519 and the Module-Lattice-Based Digital Signature Algorithm (ML-DSA-87). Receipts are chained and entered in a log whose signed tree heads are time-stamped. A verifier reports, separately, whether the records are sound and whether each recorded action stayed within its permission. The content of each record is specified independently of its encoding; one encoding, JSON Web Signature (JWS) over canonical JavaScript Object Notation (JSON), is defined.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-izmaylov-agent-permission-receipts/", "html": "https://datatracker.ietf.org/doc/html/draft-izmaylov-agent-permission-receipts", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-izmaylov-agent-permission-receipts" } }, { "name": "draft-wang-ippm-ipv6-distributed-flow-measurement", "title": "Distributed Flow Measurement in IPv6", "rev": "07", "new": false, "revised": "2026-10-24T10:06:36Z", "found": "2026-10-24T10:47:07.203Z", "pages": 17, "group": "individual", "group_type": "individual", "submitter": "wang", "area": "ops", "area_label": "OPS", "area_source": "classifier", "area_confidence": 0.67, "topic": "measurement", "topic_label": "Measurement/OAM", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.71, "classifier": "jev-1.13.0", "abstract": "In IPv6 networks, performance measurements such as packet loss, delay and jitter of real traffic can be carried out based on the Alternate-Marking method. Usually, the controller needs to collect statistical data on network devices, calculate and present the measurement results. This document proposes a distributed method for on-path flow measurement, which is independent of the controller.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-wang-ippm-ipv6-distributed-flow-measurement/", "html": "https://datatracker.ietf.org/doc/html/draft-wang-ippm-ipv6-distributed-flow-measurement", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-wang-ippm-ipv6-distributed-flow-measurement" } }, { "name": "draft-wang-ippm-ipv6-flow-measurement", "title": "Flow Measurement in IPv6 Network", "rev": "11", "new": false, "revised": "2026-10-24T10:01:43Z", "found": "2026-10-24T10:47:07.203Z", "pages": 15, "group": "individual", "group_type": "individual", "submitter": "wang", "area": "ops", "area_label": "OPS", "area_source": "classifier", "area_confidence": 0.78, "topic": "measurement", "topic_label": "Measurement/OAM", "topic_confidence": 1, "kind": "informational", "kind_label": "informational / guidance", "kind_confidence": 0.65, "classifier": "jev-1.13.0", "abstract": "This document describes how to deploy in-situ flow performance measurement based on Alternate-Marking method in IPv6 domain.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-wang-ippm-ipv6-flow-measurement/", "html": "https://datatracker.ietf.org/doc/html/draft-wang-ippm-ipv6-flow-measurement", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-wang-ippm-ipv6-flow-measurement" } }, { "name": "draft-liu-ippm-measurement-interpretation", "title": "Considerations for Interpreting IP Performance Measurement Results", "rev": "00", "new": true, "revised": "2026-10-24T09:21:54Z", "found": "2026-10-24T09:47:07.628Z", "pages": 40, "group": "individual", "group_type": "individual", "submitter": "liu", "area": "ops", "area_label": "OPS", "area_source": "classifier", "area_confidence": 0.7, "topic": "measurement", "topic_label": "Measurement/OAM", "topic_confidence": 1, "kind": "informational", "kind_label": "informational / guidance", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "IP Performance Measurement (IPPM) metrics characterize properties such as connectivity, packet loss, delay, delay variation, packet reordering, packet duplication, and capacity. A result can be correct for the metric and measurement method used while still being insufficient to explain the network condition that produced it or to describe traffic outside the measured scope. This document provides guidance for interpreting IPPM measurement results. It considers the metric definition and parameters, the measured packet or traffic population, the observation scope, and the measurement method. It also discusses metric-specific considerations and differences among active, passive, and hybrid measurements. Operational information can support an interpretation, but this document keeps it separate from the metric result itself. This document does not define new metrics or measurement protocols, and it does not specify a mechanism for determining a unique operational cause.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-liu-ippm-measurement-interpretation/", "html": "https://datatracker.ietf.org/doc/html/draft-liu-ippm-measurement-interpretation", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-liu-ippm-measurement-interpretation" } }, { "name": "draft-emelia-oauth-user-authorization-mgmt-uri", "title": "OAuth User Authorization Management URI", "rev": "00", "new": true, "revised": "2026-10-24T08:29:13Z", "found": "2026-10-24T08:47:07.111Z", "pages": 5, "group": "individual", "group_type": "individual", "submitter": "emelia", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 1, "topic": "security", "topic_label": "Security", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This specification defines a user_authorization_management_uri property for the OAuth Authorization Server Metadata ([RFC8414]), which allows an authorization server to specify a URI through which the user may manage the authorized clients that have access to their account.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-emelia-oauth-user-authorization-mgmt-uri/", "html": "https://datatracker.ietf.org/doc/html/draft-emelia-oauth-user-authorization-mgmt-uri", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-emelia-oauth-user-authorization-mgmt-uri" } }, { "name": "draft-reddy-ipsecme-ikev2-hqc", "title": "Post-Quantum Key Exchange with HQC in the Internet Key Exchange Protocol Version 2 (IKEv2)", "rev": "00", "new": true, "revised": "2026-10-24T08:13:31Z", "found": "2026-10-24T08:47:07.111Z", "pages": 8, "group": "individual", "group_type": "individual", "submitter": "reddy", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 1, "topic": "security", "topic_label": "Security", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document specifies how to use Hamming Quasi-Cyclic (HQC), a code-based Key Encapsulation Mechanism (KEM), in the Internet Key Exchange Protocol Version 2 (IKEv2). HQC can be used alone or together with other key exchanges to derive IKE and Child SA keys that resist attacks by quantum computers. This document registers three Key Exchange Method identifiers.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-reddy-ipsecme-ikev2-hqc/", "html": "https://datatracker.ietf.org/doc/html/draft-reddy-ipsecme-ikev2-hqc", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-reddy-ipsecme-ikev2-hqc" } }, { "name": "draft-li-savnet-sav-yang", "title": "YANG Data Model for Intra-domain and Inter-domain Source Address Validation (SAVNET)", "rev": "09", "new": false, "revised": "2026-10-24T07:24:31Z", "found": "2026-10-24T07:47:06.996Z", "pages": 42, "group": "individual", "group_type": "individual", "submitter": "li", "area": "ops", "area_label": "OPS", "area_source": "classifier", "area_confidence": 0.9, "topic": "netmgmt", "topic_label": "Net management", "topic_confidence": 0.97, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document describes a YANG data model for Intra-domain and Inter-domain Source Address Validation (SAVNET). The model serves as a base framework for configuring and managing an SAV subsystem, including SAV rule and SAV Tables, and expected to be augmented by other SAV technology models accordingly. Additionally, this document also specifies the model for the SAV Static application.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-li-savnet-sav-yang/", "html": "https://datatracker.ietf.org/doc/html/draft-li-savnet-sav-yang", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-li-savnet-sav-yang" } }, { "name": "draft-besleaga-sustainability-wellknown", "title": "The 'sustainability-data' Well-Known URI", "rev": "10", "new": false, "revised": "2026-10-24T07:13:49Z", "found": "2026-10-24T07:47:06.996Z", "pages": 43, "group": "individual", "group_type": "individual", "submitter": "besleaga", "area": "art", "area_label": "ART", "area_source": "classifier", "area_confidence": 0.82, "topic": "web", "topic_label": "Web/HTTP", "topic_confidence": 0.98, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.99, "classifier": "jev-1.13.0", "abstract": "This document defines the \"sustainability-data\" well-known URI, at which a web origin publishes a JSON document declaring the energy consumption, carbon footprint, and related environmental and sustainability metrics of a target: the organization behind the origin, the origin itself, a part of it, a service, a device, or a product, for different reporting periods. The declaration links to a methodology and may carry a signature, name the declarations of upstream providers, and link to third-party attestations. The metrics are self-asserted claims of the publisher. This document registers the well-known URI and the media type application/ sustainability-data+json.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-besleaga-sustainability-wellknown/", "html": "https://datatracker.ietf.org/doc/html/draft-besleaga-sustainability-wellknown", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-besleaga-sustainability-wellknown" } }, { "name": "draft-ietf-grow-rpsl-registry-scoped-members", "title": "Registry scoped members for RPSL set objects", "rev": "00", "new": true, "revised": "2026-10-24T07:09:07Z", "found": "2026-10-24T07:47:06.996Z", "pages": 11, "group": "grow", "group_type": "wg", "submitter": "grow", "area": "ops", "area_label": "OPS", "area_source": "datatracker", "area_confidence": 1, "topic": "routing", "topic_label": "Routing", "topic_confidence": 0.97, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document updates RFC2622 and RFC4012 by specifying src-members, a new attribute on as-set and route-set objects in the Routing Policy Specification Language (RPSL). This attribute allows a specific registry to be defined for each member in a set, avoiding problematic ambiguity when resolving set members. A new validation rule allows gradual upgrades and backwards compatibility.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-grow-rpsl-registry-scoped-members/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-grow-rpsl-registry-scoped-members", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-grow-rpsl-registry-scoped-members" } }, { "name": "draft-aevum-agentcard", "title": "AgentCard: A Framework-Neutral Identity and Capability Declaration Format for Agent-to-Agent Communication", "rev": "00", "new": true, "revised": "2026-10-24T07:09:07Z", "found": "2026-10-24T07:47:06.996Z", "pages": 20, "group": "individual", "group_type": "individual", "submitter": "aevum", "area": "art", "area_label": "ART", "area_source": "classifier", "area_confidence": 0.7, "topic": "ai", "topic_label": "AI/agents", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.99, "classifier": "jev-1.13.0", "abstract": "This document defines AgentCard, a lightweight JSON data format that enables autonomous software agents to declare their identity, capabilities, communication endpoints, and resource pricing in a framework-neutral manner. AgentCard is designed for agent-to-agent (A2A) communication scenarios where agents built with different frameworks — such as LangChain, CrewAI, AutoGen, or custom implementations — must interoperate without prior coordination. An AgentCard is a pure data schema: it carries no execution logic and imposes no transport requirements. It is analogous to an HTTP response header set — a machine-parseable self-description that any compliant reader can interpret. Key properties of AgentCard include a globally unique ULID-based agent identity, dot-namespaced capability identifiers compatible with OpenAI function-calling and Model Context Protocol (MCP) tool schemas, a physics-grounded energy pricing floor derived from Landauer's principle, and an extensible metadata namespace for framework-specific annotations.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-aevum-agentcard/", "html": "https://datatracker.ietf.org/doc/html/draft-aevum-agentcard", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-aevum-agentcard" } }, { "name": "draft-ietf-v6ops-prefix-to-end-sites", "title": "IPv6 Prefix Assignment to End-Sites", "rev": "00", "new": true, "revised": "2026-10-24T07:09:05Z", "found": "2026-10-24T07:47:06.996Z", "pages": 29, "group": "v6ops", "group_type": "wg", "submitter": "v6ops", "area": "ops", "area_label": "OPS", "area_source": "datatracker", "area_confidence": 1, "topic": "ip", "topic_label": "IP/addressing", "topic_confidence": 1, "kind": "informational", "kind_label": "informational / guidance", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document describes different alternatives and best current practices for assignment of IPv6 prefixes for end-sites in broadband networks, including considerations about point-to-point links, their size, numbering choices, pool choices, customer prefix assignment size and persistance of those assignments.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-v6ops-prefix-to-end-sites/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-prefix-to-end-sites", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-v6ops-prefix-to-end-sites" } }, { "name": "draft-ietf-core-coap-over-gatt", "title": "CoAP over GATT (Bluetooth Low Energy Generic Attributes)", "rev": "00", "new": true, "revised": "2026-10-24T07:09:05Z", "found": "2026-10-24T07:47:06.996Z", "pages": 20, "group": "core", "group_type": "wg", "submitter": "core", "area": "wit", "area_label": "WIT", "area_source": "datatracker", "area_confidence": 1, "topic": "iot", "topic_label": "IoT", "topic_confidence": 0.91, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.95, "classifier": "jev-1.13.0", "abstract": "Interaction from computers and cell phones to constrained devices is limited by the different network technologies used, and by the available APIs. This document describes a transport for the Constrained Application Protocol (CoAP) that uses Bluetooth GATT (Generic Attribute Profile) and its use cases.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-core-coap-over-gatt/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-core-coap-over-gatt", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-core-coap-over-gatt" } }, { "name": "draft-zehta-aipref-exclusions", "title": "AIPREF Vocabulary Exclusions", "rev": "01", "new": false, "revised": "2026-10-24T07:09:04Z", "found": "2026-10-24T07:47:06.996Z", "pages": 5, "group": "individual", "group_type": "individual", "submitter": "zehta", "area": "other", "area_label": "Other", "area_source": "classifier", "area_confidence": 0.44, "topic": "ai", "topic_label": "AI/agents", "topic_confidence": 0.99, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.95, "classifier": "jev-1.13.0", "abstract": "This document proposes an update to the AI preferences vocabulary [VOCAB] in order to establish protected uses (exclusions).", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-zehta-aipref-exclusions/", "html": "https://datatracker.ietf.org/doc/html/draft-zehta-aipref-exclusions", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-zehta-aipref-exclusions" } }, { "name": "draft-wang-cfrg-key-combiners", "title": "HMAC Based Hybrid Key Combiners for Multiple Keys", "rev": "01", "new": false, "revised": "2026-10-24T07:09:04Z", "found": "2026-10-24T07:47:06.996Z", "pages": 17, "group": "individual", "group_type": "individual", "submitter": "wang", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.8, "topic": "security", "topic_label": "Security", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "As a fundamental building block in security protocols, a key combiner is used to combine two or more input cryptographic keys, some potentially compromised, into a single pseudorandom output key. Most of the existing key combiners are for two input keys. This draft specifies two provably secure constructions of key combiners for multiple keys [WWW25], which is particularly useful in post-quantum migration where multiple input keys may be produced by different algorithms or even different approaches [RFC9370], [ETSI25]. Namely, here the input keys can be two or more, and the combined output key remains pseudorandom if at least one of the input keys is secure, i.e., uniformly random and unknown to an attacker. The two constructions, called HKCv1 and HKCv2, are based on the extract-then- expand paradigm of HMAC (Keyed-Hashing for Message Authentication) [RFC2104]. HKCv1 is designed for simultaneously available input keys using concatenation, while HKCv2 is tailored for scenarios where input keys arrive incrementally, using an iterative HMAC structure. [EDNOTE: .... ]", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-wang-cfrg-key-combiners/", "html": "https://datatracker.ietf.org/doc/html/draft-wang-cfrg-key-combiners", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-wang-cfrg-key-combiners" } }, { "name": "draft-kohbrok-mimi-identifiers", "title": "MIMI Identifiers", "rev": "01", "new": false, "revised": "2026-10-24T07:09:03Z", "found": "2026-10-24T07:47:06.996Z", "pages": 5, "group": "individual", "group_type": "individual", "submitter": "kohbrok", "area": "other", "area_label": "Other", "area_source": "classifier", "area_confidence": 0.28, "topic": "other", "topic_label": "Other", "topic_confidence": 0.49, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.64, "classifier": "jev-1.13.0", "abstract": "TODO Abstract", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-kohbrok-mimi-identifiers/", "html": "https://datatracker.ietf.org/doc/html/draft-kohbrok-mimi-identifiers", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-kohbrok-mimi-identifiers" } }, { "name": "draft-ietf-idr-flowspec-path-redirect", "title": "Flowspec Indirection-id Redirect", "rev": "13", "new": false, "revised": "2026-10-24T07:09:03Z", "found": "2026-10-24T07:47:06.996Z", "pages": 11, "group": "idr", "group_type": "wg", "submitter": "idr", "area": "rtg", "area_label": "RTG", "area_source": "datatracker", "area_confidence": 1, "topic": "routing", "topic_label": "Routing", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document defines a new extended community known as \"FlowSpec Redirect to indirection-id Extended Community\". This extended community triggers advanced redirection capabilities to flowspec clients. When activated, this flowspec extended community is used by a flowspec client to retrieve the corresponding next-hop and encoding information within a localised indirection-id mapping table. The functionality detailed in this document allows a network controller to decouple the BGP flowspec redirection instruction from the operation of the available paths.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-path-redirect/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-idr-flowspec-path-redirect", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-idr-flowspec-path-redirect" } }, { "name": "draft-hulea-wimse-agent-mandate", "title": "Verifiable Mandates for Agents Acting Across Administrative Domains", "rev": "00", "new": true, "revised": "2026-10-24T06:36:22Z", "found": "2026-10-24T06:47:07.200Z", "pages": 44, "group": "individual", "group_type": "individual", "submitter": "hulea", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 1, "topic": "security", "topic_label": "Security", "topic_confidence": 0.98, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document defines how a relying party in one administrative domain validates the mandate under which a software agent, including an AI agent, acts for a principal in another domain. Its distinctive element is evidence of the delegator's authority: a statement from an authority source about which permissions the person or entity granting the mandate may delegate to agents, kept separate from the statement that the mandate was granted. The document specifies the mandate format with precisely defined limit semantics, a deterministic validation procedure driven by an explicit validation profile and kept separate from the relying party's authorization decision, the attribution of every validated claim to the issuer and role that asserted it, rules for enforcing the mandate after token exchange, and the boundary between this protocol and a trust framework. It reuses JSON Web Tokens, OAuth 2.0 Token Exchange, Rich Authorization Requests, WIMSE workload credentials and HTTP Message Signatures, Token Status Lists, and Entity Attestation Tokens.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-hulea-wimse-agent-mandate/", "html": "https://datatracker.ietf.org/doc/html/draft-hulea-wimse-agent-mandate", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-hulea-wimse-agent-mandate" } }, { "name": "draft-zzd-idr-flowspec-scheduling", "title": "BGP Flow Specification Extensions for Scheduling", "rev": "05", "new": false, "revised": "2026-10-24T05:17:24Z", "found": "2026-10-24T05:47:07.048Z", "pages": 9, "group": "idr", "group_type": "wg", "submitter": "zzd", "area": "rtg", "area_label": "RTG", "area_source": "datatracker", "area_confidence": 1, "topic": "routing", "topic_label": "Routing", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "BGP Flow Specification allows conveying flow specifications and associated traffic actions/rules to perform different actions based on traffic characteristics. Existing traffic filter rules and actions in FSv2 remain effective perpetually; once delivered to the headend, the rules and actions are permanent for traffic. However, some operators wish to perform different actions for specific flows at specific time. This document extends BGP FSv2 with a scheduling time component to match the arrival time of packets. Based on this component, the headend can perform different actions for specific traffic at different times.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-zzd-idr-flowspec-scheduling/", "html": "https://datatracker.ietf.org/doc/html/draft-zzd-idr-flowspec-scheduling", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-zzd-idr-flowspec-scheduling" } }, { "name": "draft-sergeev-wexp-coverage", "title": "WEXP Coverage: Claims, Evidence, and Evaluation", "rev": "00", "new": true, "revised": "2026-10-24T03:59:18Z", "found": "2026-10-24T04:47:06.878Z", "pages": 75, "group": "individual", "group_type": "individual", "submitter": "sergeev", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.64, "topic": "other", "topic_label": "Other", "topic_confidence": 0.42, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.76, "classifier": "jev-1.13.0", "abstract": "An authentic receipt for an action does not establish that every action in a declared scope has a receipt. This document specifies a carrier-neutral contract for evaluating and reporting bounded claims about action-record creation, delivery, source coverage, supplied- record correspondence, and the absence of actions. Results identify the exact scope and cutoffs of each claim, its supporting evidence, accepted assumptions, counterexamples, and unresolved conditions. The document defines inference and reporting requirements, requirements for deployment bindings, and a concrete deployment profile. Coverage results are separate from Witnessed Execution Protocol (WEXP) Core appraisals and do not change their semantics.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-sergeev-wexp-coverage/", "html": "https://datatracker.ietf.org/doc/html/draft-sergeev-wexp-coverage", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-sergeev-wexp-coverage" } }, { "name": "draft-sergeev-wexp-core", "title": "WEXP Core: Witnessability Appraisal Semantics for Execution-Related Claims", "rev": "02", "new": false, "revised": "2026-10-24T03:58:21Z", "found": "2026-10-24T04:47:06.878Z", "pages": 57, "group": "individual", "group_type": "individual", "submitter": "sergeev", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.61, "topic": "security", "topic_label": "Security", "topic_confidence": 0.55, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.96, "classifier": "jev-1.13.0", "abstract": "The Witnessed Execution Protocol (WEXP) Core defines carrier-neutral Witnessability appraisal semantics for execution-related claims. It operationalizes selected concepts of the Witnessability Model under the Witnessability Conceptual Core within the bounded claim domain specified here. It defines four distinct content bases, two independent evidence qualifiers, the Boundary Ceiling, exact-claim support, deterministic accept, downgrade, and reject verdicts, composition without inflation, and a normalized interface between evidence-carrying profiles and appraisers. WEXP Core does not define a record serialization, signature envelope, action identifier, authorization model, or evidence-artifact schema. Carrier and evidence profiles can supply its normalized inputs; a native record format is optional and is not a prerequisite for this Core.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-sergeev-wexp-core/", "html": "https://datatracker.ietf.org/doc/html/draft-sergeev-wexp-core", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-sergeev-wexp-core" } }, { "name": "draft-chueayen-attestation-receipts", "title": "Enforcement Attestation Receipts for AI Inference and Agent Action Decisions", "rev": "04", "new": false, "revised": "2026-10-24T00:28:35Z", "found": "2026-10-24T00:47:23.930Z", "pages": 43, "group": "individual", "group_type": "individual", "submitter": "chueayen", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 1, "topic": "ai", "topic_label": "AI/agents", "topic_confidence": 0.74, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document specifies two compact JSON records, signed with Ed25519 and verifiable offline under a pinned public key. The first is an attestation receipt for an AI inference decision, binding an outcome to a request hash. The second, added in this revision, is an action record: the decision an enforcement point takes before an agent's proposed tool call or other state-changing action runs, whether that decision is to allow or to refuse. An action record is signed by the enforcement point, never by the agent, and binds the decision to a hash of the exact canonical arguments proposed. The document also describes how a human approval can be bound to exact action values with single use and expiry, how either record could be carried as a COSE_Sign1 Signed Statement and registered with a SCITT Transparency Service, and where the current format does not yet do so. Both formats are intended for settings where an operator-controlled log is not, on its own, sufficient evidence of the decision.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-chueayen-attestation-receipts/", "html": "https://datatracker.ietf.org/doc/html/draft-chueayen-attestation-receipts", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-chueayen-attestation-receipts" } }, { "name": "draft-ietf-quic-load-balancers", "title": "QUIC-LB: Generating Routable QUIC Connection IDs", "rev": "22", "new": false, "revised": "2026-10-23T23:04:03Z", "found": "2026-10-23T23:47:07.500Z", "pages": 47, "group": "quic", "group_type": "wg", "submitter": "quic", "area": "wit", "area_label": "WIT", "area_source": "datatracker", "area_confidence": 1, "topic": "transport", "topic_label": "Transport", "topic_confidence": 0.93, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "QUIC address migration allows clients to change their IP address while maintaining connection state. To reduce the ability of an observer to link two IP addresses, clients and servers use new connection IDs when they communicate via different client addresses. This poses a problem for traditional \"layer-4\" load balancers that route packets via the IP address and port 4-tuple. This specification provides a standardized means of securely encoding routing information in the server's connection IDs so that a properly configured load balancer can route packets with migrated addresses correctly. As it proposes a structured connection ID format, it also provides a means of connection IDs self-encoding their length to aid some hardware offloads.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-quic-load-balancers/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-quic-load-balancers", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-quic-load-balancers" } }, { "name": "draft-ietf-plants-mtc-deploy-use-cases", "title": "Merkle Tree Certificates Deployment Use Cases", "rev": "00", "new": true, "revised": "2026-10-23T22:57:23Z", "found": "2026-10-23T23:47:07.500Z", "pages": 26, "group": "plants", "group_type": "wg", "submitter": "plants", "area": "sec", "area_label": "SEC", "area_source": "datatracker", "area_confidence": 1, "topic": "security", "topic_label": "Security", "topic_confidence": 1, "kind": "requirements", "kind_label": "requirements / use cases", "kind_confidence": 0.79, "classifier": "jev-1.13.0", "abstract": "Merkle Tree Certificates (MTC) I-D.ietf-plants-merkle-tree-certs has been defined for the use case of the WebPKI. In this document we explore when and how MTC in parts or full can be used in different use cases. Some of this use-cases may provide benefit for private PKI usage.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-plants-mtc-deploy-use-cases/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-plants-mtc-deploy-use-cases", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-plants-mtc-deploy-use-cases" } }, { "name": "draft-ietf-ippm-stamp-mpls-hdr", "title": "Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Reflecting STAMP Packet MPLS Network Action Headers", "rev": "02", "new": false, "revised": "2026-10-23T21:45:16Z", "found": "2026-10-23T21:47:07.202Z", "pages": 22, "group": "ippm", "group_type": "wg", "submitter": "ippm", "area": "ops", "area_label": "OPS", "area_source": "datatracker", "area_confidence": 1, "topic": "measurement", "topic_label": "Measurement/OAM", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "The Simple Two-Way Active Measurement Protocol (STAMP) and its optional extensions can be used for Edge-to-Edge (E2E) active measurements. In Situ Operations, Administration, and Maintenance (IOAM) data fields can be used for recording and collecting Hop-by- Hop (HBH) and E2E operational and telemetry information. This document extends STAMP to reflect MPLS Network Action Sub-Stacks and Post-Stack MPLS Headers for HBH and E2E active measurements, for example, using the IOAM data fields.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp-mpls-hdr/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-mpls-hdr", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-ippm-stamp-mpls-hdr" } }, { "name": "draft-richardson-lamps-rfc7030bis", "title": "Enrollment over Secure Transport", "rev": "00", "new": true, "revised": "2026-10-23T20:48:37Z", "found": "2026-10-23T21:47:07.202Z", "pages": 52, "group": "individual", "group_type": "individual", "submitter": "richardson", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 1, "topic": "security", "topic_label": "Security", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document profiles certificate enrollment for clients using Certificate Management over CMS (CMC) messages over a secure transport. This profile, called Enrollment over Secure Transport (EST), describes a simple, yet functional, certificate management protocol targeting Public Key Infrastructure (PKI) clients that need to acquire client certificates and associated Certification Authority (CA) certificates. It also supports client-generated public/private key pairs as well as key pairs generated by the CA.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-richardson-lamps-rfc7030bis/", "html": "https://datatracker.ietf.org/doc/html/draft-richardson-lamps-rfc7030bis", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-richardson-lamps-rfc7030bis" } }, { "name": "draft-kunze-ark", "title": "The ARK Identifier Scheme", "rev": "44", "new": false, "revised": "2026-10-23T20:33:26Z", "found": "2026-10-23T20:47:09.791Z", "pages": 48, "group": "individual", "group_type": "individual", "submitter": "kunze", "area": "art", "area_label": "ART", "area_source": "classifier", "area_confidence": 0.83, "topic": "other", "topic_label": "Other", "topic_confidence": 0.43, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.8, "classifier": "jev-1.13.0", "abstract": "The ARK (Archival Resource Key) naming scheme is designed to facilitate the high-quality and persistent identification of information objects. The label \"ark:\" marks the start of a core ARK identifier that can be made actionable by prepending the beginning of a URL. Meant to be usable after today's networking technologies become obsolete, that core should be recognizable in the future as a globally unique ARK independent of the URL hostname, HTTP, etc. A founding principle of ARKs is that persistence is purely a matter of service and neither inherent in an object nor conferred on it by a particular naming syntax. The best any identifier can do is lead users to services that support robust reference. A full-functioning ARK leads the user to the identified object and, with the \"?info\" inflection appended, returns a metadata record and a commitment statement that is both human- and machine-readable. Tools exist for minting, binding, and resolving ARKs. Responsibility for this Document The ARK Alliance Technical Working Group [ARKAtech] is responsible for the content of this Internet Draft. The group homepage lists monthly meeting notes and agendas starting from March 2019. Revisions of the spec are maintained on github at [ARKdrafts].", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-kunze-ark/", "html": "https://datatracker.ietf.org/doc/html/draft-kunze-ark", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-kunze-ark" } }, { "name": "draft-moore-scitt-ciris-ceg", "title": "Signed Attestation Rows of the CIRIS Epistemic Grammar and Their Relationship to SCITT", "rev": "00", "new": true, "revised": "2026-10-23T20:17:23Z", "found": "2026-10-23T20:47:09.791Z", "pages": 30, "group": "individual", "group_type": "individual", "submitter": "moore", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.99, "topic": "security", "topic_label": "Security", "topic_confidence": 0.99, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.97, "classifier": "jev-1.13.0", "abstract": "The CIRIS Epistemic Grammar (CEG) records claims between parties as signed rows. Each row is one JSON object, canonicalised with the JSON Canonicalization Scheme (JCS) and signed twice: once with Ed25519 and once with ML-DSA-65, where the ML-DSA-65 signature covers the canonical bytes followed by the Ed25519 signature. Every row has one of five types: a claim, a delegation, a replacement, a withdrawal, or a recantation. A node admits a row only after a fixed set of checks, and it refuses a failing row with a named reason. This document specifies the signed object, the signing input, the signature construction, and the admission checks, so that a second implementation can produce and verify the same bytes. It then describes how these rows relate to the roles of the SCITT architecture (RFC 9943), and where they differ from a SCITT Transparency Service. It defines no new SCITT mechanism and requests no IANA action.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-moore-scitt-ciris-ceg/", "html": "https://datatracker.ietf.org/doc/html/draft-moore-scitt-ciris-ceg", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-moore-scitt-ciris-ceg" } }, { "name": "draft-ietf-manet-inet-gap-analysis", "title": "MANET Internetworking Architecture, Problem Statement and Gap Analysis", "rev": "11", "new": false, "revised": "2026-10-23T20:06:47Z", "found": "2026-10-23T20:47:09.791Z", "pages": 30, "group": "manet", "group_type": "wg", "submitter": "manet", "area": "rtg", "area_label": "RTG", "area_source": "datatracker", "area_confidence": 1, "topic": "wireless", "topic_label": "Wireless/satellite", "topic_confidence": 0.68, "kind": "requirements", "kind_label": "requirements / use cases", "kind_confidence": 0.97, "classifier": "jev-1.13.0", "abstract": "[RFC2501] defines a MANET as \"an autonomous system of mobile nodes. The system may operate in isolation, or may have gateways to and interface with a fixed network\" (such as the global public Internet). This document presents a MANET Internetworking architecture, problem statement and gap analysis.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-manet-inet-gap-analysis/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-manet-inet-gap-analysis", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-manet-inet-gap-analysis" } }, { "name": "draft-ietf-stir-8588bis", "title": "Personal Assertion Token (PaSSporT) Extension for Signature-based Handling of Asserted information using toKENs (SHAKEN)", "rev": "03", "new": false, "revised": "2026-10-23T19:57:01Z", "found": "2026-10-23T20:47:09.791Z", "pages": 8, "group": "stir", "group_type": "wg", "submitter": "stir", "area": "art", "area_label": "ART", "area_source": "datatracker", "area_confidence": 1, "topic": "realtime", "topic_label": "Real-time media", "topic_confidence": 0.85, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document extends the Personal Assertion Token (PASSporT), which is a token object that conveys cryptographically signed information about the participants involved in communications. The extension is defined based on the \"Signature-based Handling of Asserted information using toKENs (SHAKEN)\" specification by the ATIS/SIP Forum IP-NNI Task Group. It provides both (1) a specific set of levels of confidence in the correctness of the originating identity of a call originated in a SIP-based telephone network as well as (2) an identifier that allows the Service Provider (SP) to uniquely identify the origin of the call within its network. This document obsoletes RFC 8588.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-stir-8588bis/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-stir-8588bis", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-stir-8588bis" } }, { "name": "draft-kamienski-iot-deployment", "title": "Application-Centric Considerations for Deployment over the IoT Computing Continuum", "rev": "00", "new": true, "revised": "2026-10-23T19:56:04Z", "found": "2026-10-23T20:47:09.791Z", "pages": 26, "group": "individual", "group_type": "individual", "submitter": "kamienski", "area": "irtf", "area_label": "IRTF", "area_source": "classifier", "area_confidence": 0.93, "topic": "iot", "topic_label": "IoT", "topic_confidence": 0.94, "kind": "informational", "kind_label": "informational / guidance", "kind_confidence": 0.71, "classifier": "jev-1.13.0", "abstract": "Smart applications increasingly depend on the Internet of Things (IoT) and distributed computing environments spanning constrained devices, edge nodes, cloudlets, and cloud infrastructure, collectively known as the edge–cloud, or computing continuum. This document uses the term IoT computing continuum to highlight the importance of IoT-specific constraints and requirements within this broader context. Although prior work has addressed communication aspects and edge functions in these environments, as noted in RFC 9556 and comprehensive surveys of the computing continuum, there has been comparatively less focus on application-centric issues such as deployment, placement, and lifecycle management. This document identifies key challenges and conceptual considerations for deploying smart applications across the IoT computing continuum, aiming to provide a unified architectural perspective and vocabulary to guide ongoing research within the IRTF and inform future standardization initiatives.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-kamienski-iot-deployment/", "html": "https://datatracker.ietf.org/doc/html/draft-kamienski-iot-deployment", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-kamienski-iot-deployment" } }, { "name": "draft-ietf-cbor-serialization", "title": "CBOR Serialization and Determinism", "rev": "11", "new": false, "revised": "2026-10-23T19:49:07Z", "found": "2026-10-23T18:47:09.385Z", "pages": 57, "group": "cbor", "group_type": "wg", "submitter": "cbor", "area": "art", "area_label": "ART", "area_source": "datatracker", "area_confidence": 1, "topic": "iot", "topic_label": "IoT", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "RFC 8949 defines CBOR, a standard for serializing data types such as integers, strings, and arrays into encoded bytes. CBOR serialization is flexible, allowing data types to be encoded in multiple ways to accommodate deployment in constrained environments. This document normatively defines one particular serialization, called \"preferred- plus serialization,\" that is suitable for the majority of CBOR-based protocols. Protocol designers and implementers who choose it need not understand or specify serialization details themselves. This document also normatively defines a deterministic serialization. These serializations are largely compatible with those widely implemented by the CBOR community. This document updates RFC 8949 with a new rule that limits how new tag definitions can affect the CBOR data model. This document provides clarifications to RFC 8949 regarding bignums and floating-point NaN handling, along with general background information on serialization, determinism, and CBOR byte-string wrapping.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-cbor-serialization/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-cbor-serialization", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-cbor-serialization" } }, { "name": "draft-ietf-mailmaint-expires", "title": "Updated Use of the Expires Message Header Field", "rev": "06", "new": false, "revised": "2026-10-23T19:37:05Z", "found": "2026-10-23T19:46:12.732Z", "pages": 7, "group": "mailmaint", "group_type": "wg", "submitter": "mailmaint", "area": "art", "area_label": "ART", "area_source": "datatracker", "area_confidence": 1, "topic": "email", "topic_label": "Email/messaging", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.84, "classifier": "jev-1.13.0", "abstract": "This document allows broader use of the Expires message header field for mail messages. Message creators can then indicate when a message expires, while recipients would use this information to handle an expired message differently.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-mailmaint-expires/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-mailmaint-expires", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-mailmaint-expires" } }, { "name": "draft-hillier-scitt-arp", "title": "Attestation Reconciliation Protocol", "rev": "06", "new": false, "revised": "2026-10-23T19:32:49Z", "found": "2026-10-23T19:46:12.732Z", "pages": 223, "group": "individual", "group_type": "individual", "submitter": "hillier", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 1, "topic": "security", "topic_label": "Security", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document specifies the Attestation Reconciliation Protocol (ARP), a deterministic, bilateral, minimum-disclosure mechanism for reconciling verification claims against a plurality of sovereign authoritative registers without raw register records leaving their data-residency jurisdiction. ARP extends the SCITT (Supply Chain Integrity, Transparency, and Trust) architecture to cross-sovereign claim reconciliation. A reconciliation server canonicalises a structured claim, binds the identity of the requesting principal -- including, where the requester is an autonomous agent, a friend-or- foe determination of that agent's verifiable principal binding -- projects the claim through register-specific controlled projection functions producing the nearest permitted ancestor predicate supported by each addressed register, transmits register-specific ciphertexts, receives partial attestations whose payload discloses, of the subject, only a verdict, an optional divergence axis, the applied profile parameters and a query binding digest, aggregates those attestations under a verdict arithmetic the deployment's policy resolves, committing each register's contribution to a Merkle tree, and seals the resulting reconciliation output against a policy- version hash. An append-only cross-jurisdictional settlement-layer ledger records digests and structural metadata, with no claim, register-record or principal content. The protocol supports retroactive re-evaluation of historical reconciliations under updated pattern libraries or policy versions without bilateral renegotiation, and a cryptographic-primitive-upgrade path including post-quantum primitives. This revision adds a normative binding to the SCITT Reference APIs, register data-format profiles for beneficial- ownership, corporate-registry, customs and consolidated-sanctions formats, and a source-data version binding that makes a change in a historical verdict attributable to a change in policy or to a change in the underlying published corpus.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-hillier-scitt-arp/", "html": "https://datatracker.ietf.org/doc/html/draft-hillier-scitt-arp", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-hillier-scitt-arp" } }, { "name": "draft-ietf-idr-sdwan-edge-discovery", "title": "SD-WAN Edge and Underlay Tunnel Discovery Using BGP", "rev": "32", "new": false, "revised": "2026-10-23T17:38:47Z", "found": "2026-10-23T17:47:09.248Z", "pages": 56, "group": "idr", "group_type": "wg", "submitter": "idr", "area": "rtg", "area_label": "RTG", "area_source": "datatracker", "area_confidence": 1, "topic": "routing", "topic_label": "Routing", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document specifies BGP mechanisms for SD-WAN (Software-Defined Wide Area Network) edge node attribute discovery. These mechanisms comprise a new tunnel type and associated Sub-TLVs for the BGP Tunnel Encapsulation Attribute, and a new Subsequent Address Family Identifier (SAFI) carrying a typed NLRI for advertising SD-WAN underlay tunnel information.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-idr-sdwan-edge-discovery/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-idr-sdwan-edge-discovery", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-idr-sdwan-edge-discovery" } }, { "name": "draft-taylor-dtn-dpp", "title": "DTN Peering Protocol", "rev": "02", "new": false, "revised": "2026-10-23T16:43:31Z", "found": "2026-10-23T17:31:41.847Z", "pages": 59, "group": "individual", "group_type": "individual", "submitter": "taylor", "area": "rtg", "area_label": "RTG", "area_source": "classifier", "area_confidence": 0.94, "topic": "routing", "topic_label": "Routing", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document specifies the DTN Peering Protocol (DPP), an inter- domain routing protocol for the Delay-Tolerant Networking (DTN) ecosystem. DPP facilitates the exchange of reachability information between distinct Administrative Domains (ADs), enabling inter-domain routing across networks operated by different agencies and organizations. DPP separates the control plane from the data plane: a DPP speaker need not be a gateway that forwards bundles, allowing centralized route controllers or orchestration systems to participate in peering on behalf of the gateways they manage. DPP advertises the reachability of bundle nodes in both DTN addressing schemes, ipn (integer-based) and dtn (name-based), and selects routes for both by the same process. DPP speakers authenticate each other using mutual TLS, with each Administrative Domain authorizing its speakers' keys through DNSSEC-signed TLSA records. DPP supports both persistent routes and routes tied to the scheduled contact windows of deep-space networks.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-taylor-dtn-dpp/", "html": "https://datatracker.ietf.org/doc/html/draft-taylor-dtn-dpp", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-taylor-dtn-dpp" } }, { "name": "draft-ietf-tls-composite-mldsa", "title": "Use of Composite ML-DSA in TLS 1.3", "rev": "00", "new": true, "revised": "2026-10-23T16:34:42Z", "found": "2026-10-23T17:31:41.847Z", "pages": 16, "group": "tls", "group_type": "wg", "submitter": "tls", "area": "sec", "area_label": "SEC", "area_source": "datatracker", "area_confidence": 1, "topic": "security", "topic_label": "Security", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "Compositing the post-quantum ML-DSA signature with traditional signature algorithms provides protection against potential breaks or critical bugs in ML-DSA or the ML-DSA implementation. This document specifies how such a composite signature can be formed using ML-DSA with RSA-PKCS#1 v1.5, RSA-PSS, ECDSA, Ed25519, and Ed448 to provide authentication in TLS 1.3, including use in certificates.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-tls-composite-mldsa/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-tls-composite-mldsa", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-tls-composite-mldsa" } }, { "name": "draft-karstens-pim-multicast-snooping-optimization", "title": "Multicast Snooping Optimizations", "rev": "03", "new": false, "revised": "2026-10-23T16:10:37Z", "found": "2026-10-23T17:31:41.847Z", "pages": 13, "group": "individual", "group_type": "individual", "submitter": "karstens", "area": "rtg", "area_label": "RTG", "area_source": "classifier", "area_confidence": 0.44, "topic": "ip", "topic_label": "IP/addressing", "topic_confidence": 0.5, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.67, "classifier": "jev-1.13.0", "abstract": "TODO: provide abstract", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-karstens-pim-multicast-snooping-optimization/", "html": "https://datatracker.ietf.org/doc/html/draft-karstens-pim-multicast-snooping-optimization", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-karstens-pim-multicast-snooping-optimization" } }, { "name": "draft-yusef-tls-pqt-dual-certs", "title": "Post-Quantum Traditional (PQ/T) Hybrid Authentication with Dual Certificates in TLS 1.3", "rev": "03", "new": false, "revised": "2026-10-23T15:50:39Z", "found": "2026-10-23T17:31:41.847Z", "pages": 20, "group": "individual", "group_type": "individual", "submitter": "yusef", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 1, "topic": "security", "topic_label": "Security", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "The anticipated emergence of cryptographically relevant quantum computers (CRQCs) poses a threat to the authentication mechanisms used in TLS 1.3. This document defines a hybrid authentication mechanism that uses two independent certificates, one traditional and one post-quantum, ensuring that an attacker must break both algorithms to compromise a TLS connection. The two certificate chains are carried in a single Certificate message and two independent signatures are encoded in the CertificateVerify message.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-yusef-tls-pqt-dual-certs/", "html": "https://datatracker.ietf.org/doc/html/draft-yusef-tls-pqt-dual-certs", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-yusef-tls-pqt-dual-certs" } }, { "name": "draft-ietf-wimse-identifier", "title": "Workload Identifier", "rev": "04", "new": false, "revised": "2026-10-23T15:37:05Z", "found": "2026-10-23T15:47:12.226Z", "pages": 15, "group": "wimse", "group_type": "wg", "submitter": "wimse", "area": "art", "area_label": "ART", "area_source": "datatracker", "area_confidence": 1, "topic": "security", "topic_label": "Security", "topic_confidence": 0.99, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document defines a canonical identifier for workloads, referred to as the Workload Identifier. A Workload Identifier is a URI that uniquely identifies a workload within the context of a specific trust domain. This identifier can be embedded in Workload Identity Credentials, including X.509 certificates and JWT-based tokens, to support authentication, authorization, and policy enforcement across diverse systems. The Workload Identifier format ensures interoperability, facilitates secure identity federation, and enables consistent identity semantics.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-wimse-identifier/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-wimse-identifier", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-wimse-identifier" } }, { "name": "draft-ietf-pim-ipv6-zeroconf-assignment", "title": "Zero-Configuration Assignment of IPv6 Multicast Addresses Using mDNS", "rev": "15", "new": false, "revised": "2026-10-23T15:01:00Z", "found": "2026-10-23T15:47:12.226Z", "pages": 20, "group": "pim", "group_type": "wg", "submitter": "pim", "area": "rtg", "area_label": "RTG", "area_source": "datatracker", "area_confidence": 1, "topic": "ip", "topic_label": "IP/addressing", "topic_confidence": 0.93, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.99, "classifier": "jev-1.13.0", "abstract": "This document describes a zero-configuration protocol for dynamically assigning IPv6 multicast addresses that are unique at the link-layer. Applications randomly assign multicast group IDs from a specified range and prevent collisions by using Multicast DNS (mDNS) to publish resource records under a new \"eth-addr.arpa\" domain. This protocol satisfies all of the requirements and most of the desired characteristics listed in RFC 10019.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-pim-ipv6-zeroconf-assignment/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-pim-ipv6-zeroconf-assignment", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-pim-ipv6-zeroconf-assignment" } }, { "name": "draft-housley-lamps-rfc3161-update", "title": "Update to the Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)", "rev": "01", "new": false, "revised": "2026-10-23T14:35:22Z", "found": "2026-10-23T15:47:12.226Z", "pages": 5, "group": "individual", "group_type": "individual", "submitter": "housley", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 1, "topic": "security", "topic_label": "Security", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.99, "classifier": "jev-1.13.0", "abstract": "This document updates RFC 3161. It adds a requirement to ensure that the id-ct-TSTInfo content type is used to align with the best practices for signed attributes with CMS signed-data. In addition, cross-protocol attacks are prevented by requiring that the Time Stamp Authority (TSA) dedicate the signature key pair to the time-stamping service.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-housley-lamps-rfc3161-update/", "html": "https://datatracker.ietf.org/doc/html/draft-housley-lamps-rfc3161-update", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-housley-lamps-rfc3161-update" } }, { "name": "draft-das-execution-finality-foundations", "title": "Execution-Finality Authority and Independent Validation for Autonomous Operations", "rev": "00", "new": true, "revised": "2026-10-23T14:27:57Z", "found": "2026-10-23T15:47:12.226Z", "pages": 1020, "group": "individual", "group_type": "individual", "submitter": "das", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.76, "topic": "ai", "topic_label": "AI/agents", "topic_confidence": 0.77, "kind": "informational", "kind_label": "informational / guidance", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document describes a proposed execution-finality architecture for AI agents, delegated software, and networked services. A Candidate Act remains in a Non-Effective State until protected source-authority evidence and independent execution-time validation establish an operation-specific authorization context. A Finality Sink reconstructs the Actual Pending Operation at the relevant effectuation boundary, verifies correspondence with protected evidence and scoped non-bearer enablement, and withholds effects when required conditions are missing, changed, or consumed. The document examines authority preservation, cross-committed evidence, and fail- closed effectuation as implementation and interoperability concerns. This document is informational and does not specify an IETF-standard protocol. The foundational technical structure is described by the author as drawing on Algorithmic Logic Fingerprint (ALF-PCT), PCT/ IB2026/053385, and the execution-finality disclosure PCT/ IB2026/055615, filed on 4 June 2026 and subsequently published as WO 2026/150382, which the author identifies as containing approximately 300 distinct technical embodiments. The author also identifies 32 earlier Indian provisional patent filings as part of the broader related disclosure history. These materials are not represented as repetitive implementations of a single algorithm, and this statement does not establish claim coverage, validity, or priority entitlement; those matters depend on the individual as-filed documents. This document is one of three complementary parts of a single source specification dated 23 October 2026. These three Internet-Drafts are split for document-size and editorial manageability, not because their safety properties, definitions, or architectural prerequisites are independent. Reviewers are strongly requested to read all three drafts together, including their definitions and foundational security assumptions, before assessing conformance, security properties, or interoperability. The same source contains 40 detailed technical embodiments. This partition does not establish three distinct interoperable standards. Industry relevance: NVIDIA, Huawei, Google Cloud, Salesforce, AWS, Snowflake, Microsoft, Check Point, Palo Alto Networks, and SentinelOne publish agent, gateway, data-governance, or runtime security mechanisms of potential relevance to this document. The industry examples are contextual, not a claim of adoption, implementation equivalence, derivation, endorsement or patent coverage. See the detailed Industry Relevance and Interoperability Context section.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-das-execution-finality-foundations/", "html": "https://datatracker.ietf.org/doc/html/draft-das-execution-finality-foundations", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-das-execution-finality-foundations" } }, { "name": "draft-das-execution-finality-enforcement", "title": "Execution-Finality Enforcement, Protected State, and Delegated Operations", "rev": "00", "new": true, "revised": "2026-10-23T14:26:42Z", "found": "2026-10-23T15:47:12.226Z", "pages": 1036, "group": "individual", "group_type": "individual", "submitter": "das", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.9, "topic": "ai", "topic_label": "AI/agents", "topic_confidence": 0.59, "kind": "informational", "kind_label": "informational / guidance", "kind_confidence": 0.91, "classifier": "jev-1.13.0", "abstract": "This document examines protected enforcement mechanisms for proposed consequential actions across AI-agent tools, distributed services, credentials, and resource state. It considers source-bounded delegation, operation descriptors, execution-time revalidation, protected consumption and replay prevention, multi-sink effects, and recovery where an external outcome is uncertain. An enforcing Finality Sink distinguishes authorization for an actual pending operation from a prior request approval or a reusable bearer credential. The document presents implementation points and deployment considerations, not a complete interoperable wire protocol or IETF consensus position. The foundational technical structure is described by the author as drawing on Algorithmic Logic Fingerprint (ALF-PCT), PCT/ IB2026/053385, and the execution-finality disclosure PCT/ IB2026/055615, filed on 4 June 2026 and subsequently published as WO 2026/150382, which the author identifies as containing approximately 300 distinct technical embodiments. The author also identifies 32 earlier Indian provisional patent filings as part of the broader related disclosure history. These materials are not represented as repetitive implementations of a single algorithm, and this statement does not establish claim coverage, validity, or priority entitlement; those matters depend on the individual as-filed documents. This document is one of three complementary parts of a single source specification dated 23 October 2026. These three Internet-Drafts are split for document-size and editorial manageability, not because their safety properties, definitions, or architectural prerequisites are independent. Reviewers are strongly requested to read all three drafts together, including their definitions and foundational security assumptions, before assessing conformance, security properties, or interoperability. The same source contains 40 detailed technical embodiments. This partition does not establish three distinct interoperable standards. Industry relevance: NVIDIA, Huawei, Google Cloud, Salesforce, AWS, Snowflake, Microsoft, Check Point, Palo Alto Networks, and SentinelOne publish agent, gateway, data-governance, or runtime security mechanisms of potential relevance to this document. The industry examples are contextual, not a claim of adoption, implementation equivalence, derivation, endorsement or patent coverage. See the detailed Industry Relevance and Interoperability Context section.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-das-execution-finality-enforcement/", "html": "https://datatracker.ietf.org/doc/html/draft-das-execution-finality-enforcement", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-das-execution-finality-enforcement" } }, { "name": "draft-das-execution-finality-integrations", "title": "Execution-Finality Integration Across Agent, Network, Cloud, and Hardware Boundaries", "rev": "00", "new": true, "revised": "2026-10-23T14:25:29Z", "found": "2026-10-23T15:47:12.226Z", "pages": 783, "group": "individual", "group_type": "individual", "submitter": "das", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.91, "topic": "security", "topic_label": "Security", "topic_confidence": 0.84, "kind": "informational", "kind_label": "informational / guidance", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document examines integration and deployment of execution- finality controls across agent tool invocation, network and cloud operations, persistent storage, device and accelerator interfaces, and heterogeneous trust domains. It describes how enforcement-point coverage, protected operation reconstruction, bounded and non- reusable authority, runtime change handling, and evidence of deployment conformance may help limit unintended consequential effects. The implementation points are illustrative and require workload-specific threat models and security profiles. This informational document does not assert a standard protocol or uniform guarantees across all substrates. The foundational technical structure is described by the author as drawing on Algorithmic Logic Fingerprint (ALF-PCT), PCT/ IB2026/053385, and the execution-finality disclosure PCT/ IB2026/055615, filed on 4 June 2026 and subsequently published as WO 2026/150382, which the author identifies as containing approximately 300 distinct technical embodiments. The author also identifies 32 earlier Indian provisional patent filings as part of the broader related disclosure history. These materials are not represented as repetitive implementations of a single algorithm, and this statement does not establish claim coverage, validity, or priority entitlement; those matters depend on the individual as-filed documents. This document is one of three complementary parts of a single source specification dated 23 October 2026. These three Internet-Drafts are split for document-size and editorial manageability, not because their safety properties, definitions, or architectural prerequisites are independent. Reviewers are strongly requested to read all three drafts together, including their definitions and foundational security assumptions, before assessing conformance, security properties, or interoperability. The same source contains 40 detailed technical embodiments. This partition does not establish three distinct interoperable standards. Industry relevance: NVIDIA, Huawei, Google Cloud, Salesforce, AWS, Snowflake, Microsoft, Check Point, Palo Alto Networks, and SentinelOne publish agent, gateway, data-governance, or runtime security mechanisms of potential relevance to this document. The industry examples are contextual, not a claim of adoption, implementation equivalence, derivation, endorsement or patent coverage. See the detailed Industry Relevance and Interoperability Context section.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-das-execution-finality-integrations/", "html": "https://datatracker.ietf.org/doc/html/draft-das-execution-finality-integrations", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-das-execution-finality-integrations" } }, { "name": "draft-arash-ebrahimi-ump-protocol", "title": "Universal Modular Protocol (UMP)", "rev": "00", "new": true, "revised": "2026-10-23T14:09:58Z", "found": "2026-10-23T15:47:12.226Z", "pages": 11, "group": "individual", "group_type": "individual", "submitter": "arash", "area": "art", "area_label": "ART", "area_source": "classifier", "area_confidence": 0.9, "topic": "other", "topic_label": "Other", "topic_confidence": 0.9, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.44, "classifier": "jev-1.13.0", "abstract": "The Universal Modular Protocol (UMP) proposes a modular approach to application-layer communication. Instead of implementing every protocol feature in a monolithic protocol or application, UMP allows communication behavior to be composed from modules that can be obtained from a peer or a repository. A protocol engine manages module execution, communication, signatures, and resource restrictions. Modules execute in a WebAssembly sandbox, while the Protocol Description Language (PDL) is intended to support module composition and analysis. UMP is designed to reduce the effort required to introduce new protocol features, reuse protocol components, and connect applications that otherwise require protocol- specific integration. This document describes the motivation, module model, protocol operation, PDL, repositories, and current implementation status of UMP.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-arash-ebrahimi-ump-protocol/", "html": "https://datatracker.ietf.org/doc/html/draft-arash-ebrahimi-ump-protocol", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-arash-ebrahimi-ump-protocol" } }, { "name": "draft-limarsjenwar-tiptop-address-space", "title": "IPv6 Address Space for Space", "rev": "01", "new": false, "revised": "2026-10-23T11:50:23Z", "found": "2026-10-23T12:47:12.509Z", "pages": 7, "group": "individual", "group_type": "individual", "submitter": "limarsjenwar", "area": "int", "area_label": "INT", "area_source": "classifier", "area_confidence": 1, "topic": "ip", "topic_label": "IP/addressing", "topic_confidence": 0.98, "kind": "informational", "kind_label": "informational / guidance", "kind_confidence": 0.21, "classifier": "jev-1.13.0", "abstract": "Without a structured address allocation plan, early space missions risk creating an unaggregated patchwork of prefixes, repeating the historical operational scaling issues seen in terrestrial networks. This document requests that the IANA allocate address space specifically for use in space environments and manages suballocations from that block for and within celestial bodies, as needed. The Number Resource Organization (NRO) will determine how to allocate and assign address resources for and within the celestial bodies , with the understanding that topological address aggregation is critical for routing scalability and operational efficiency.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-limarsjenwar-tiptop-address-space/", "html": "https://datatracker.ietf.org/doc/html/draft-limarsjenwar-tiptop-address-space", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-limarsjenwar-tiptop-address-space" } }, { "name": "draft-gravit-gevp", "title": "Gravit Epistemic Verification Protocol (GEVP)", "rev": "11", "new": false, "revised": "2026-10-23T11:28:36Z", "found": "2026-10-23T11:47:07.279Z", "pages": 18, "group": "individual", "group_type": "individual", "submitter": "gravit", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.88, "topic": "security", "topic_label": "Security", "topic_confidence": 0.86, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "The Gravit Epistemic Verification Protocol (GEVP) defines how signed evidence Records about an Artifact are screened, grouped by independent source and evaluated, so that a claim is never promoted beyond what independent evidence supports. It specifies the Epistemic State Machine, the Record format and its signature, the meaning of the signed result of a Record, a verifier registry accepted under a threshold of root keys, a content-addressed Decision Record that anyone can reproduce, and optional signed receipts that let an auditor check a history of decisions offline. It maps these states to the evidence taxonomy of the Gravit Verifiable Epistemic Decision Standard (VEDS).", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-gravit-gevp/", "html": "https://datatracker.ietf.org/doc/html/draft-gravit-gevp", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-gravit-gevp" } }, { "name": "draft-shigeya-dns-opkey", "title": "Using Secure DNS for Originator Profile", "rev": "00", "new": true, "revised": "2026-10-23T10:58:15Z", "found": "2026-10-23T11:47:07.279Z", "pages": 45, "group": "individual", "group_type": "individual", "submitter": "shigeya", "area": "int", "area_label": "INT", "area_source": "classifier", "area_confidence": 0.51, "topic": "dns", "topic_label": "DNS/naming", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "The Originator Profile Framework (OPF) provides information about the origin of content, together with a verifiable binding of the content to that origin, in digital media, advertising, and email ecosystems. In the framework, an originator holds an Originator Profile (OP): a Core Profile (CP) issued by a CP issuer, and Profile Annotations (PA) issued by PA issuers. The CP carries the public keys with which the originator signs the data it originates; a PA annotates the CP with validated attributes about the originator. Verifiers need an authenticated way to confirm that the public keys used by an originator and by the issuers of these documents are currently valid, that the originator's CP has not been revoked by its CP issuer, and that a PA has not been revoked by its PA issuer. This document defines the OPKEY DNS resource record, which associates a public key with a DNS name under the _op label. Its wire and presentation formats are those of the TLSA record. The DNS does not carry the CP or the PAs themselves; it carries records that identify their keys by digest, and it signals, through the presence or absence of OPKEY records, whether a CP has been revoked. The document specifies where OPKEY records are located, how a verifier uses them, and how DNSSEC is used to authenticate them. It also specifies two further records under _op, of existing types: an SVCB record by which an originator names the CP issuers it accepts, and a TXT record whose presence signals that a PA issuer has revoked a PA. Operational aspects of the framework, such as registration, key rollover procedures, and revocation timing, are outside the scope of this document.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-shigeya-dns-opkey/", "html": "https://datatracker.ietf.org/doc/html/draft-shigeya-dns-opkey", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-shigeya-dns-opkey" } }, { "name": "draft-ietf-nmop-simap-concept", "title": "SIMAP: Concept, Requirements, and Use Cases", "rev": "15", "new": false, "revised": "2026-10-23T10:57:28Z", "found": "2026-10-23T11:47:07.279Z", "pages": 45, "group": "nmop", "group_type": "wg", "submitter": "nmop", "area": "ops", "area_label": "OPS", "area_source": "datatracker", "area_confidence": 1, "topic": "netmgmt", "topic_label": "Net management", "topic_confidence": 1, "kind": "requirements", "kind_label": "requirements / use cases", "kind_confidence": 0.99, "classifier": "jev-1.13.0", "abstract": "This document defines the concept of Service & Infrastructure Maps (SIMAP) and identifies a set of SIMAP requirements and use cases. The SIMAP was previously known as Digital Map. SIMAP evolves the earlier 'Digital Map' concept by making explicit the ties between service and infrastructure layers, clarifying expected outcomes for operations and automation, and addressing ambiguity associated with the term 'digital.' The document intends to be used as a reference for the assessment of the various topology modules to meet SIMAP requirements.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-nmop-simap-concept/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-nmop-simap-concept", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-nmop-simap-concept" } }, { "name": "draft-abraitis-idr-addpath-paths-limit", "title": "Paths Limit for Multiple Paths in BGP", "rev": "06", "new": false, "revised": "2026-10-23T10:50:07Z", "found": "2026-10-23T11:47:07.279Z", "pages": 9, "group": "individual", "group_type": "individual", "submitter": "abraitis", "area": "rtg", "area_label": "RTG", "area_source": "classifier", "area_confidence": 1, "topic": "routing", "topic_label": "Routing", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document specifies a BGP capability that complements the ADD- PATH Capability by indicating the maximum number of paths a BGP speaker can receive from a peer, optimizing the transmission of BGP routes by selectively relaying pertinent routes instead of the entire set. This document also defines a new BGP Cease NOTIFICATION message subcode, \"Maximum Number of Paths Reached\", used when a BGP speaker terminates a peering because the number of paths received from a neighbor for a prefix exceeds the Paths Limit advertised in the PATHS-LIMIT Capability.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-abraitis-idr-addpath-paths-limit/", "html": "https://datatracker.ietf.org/doc/html/draft-abraitis-idr-addpath-paths-limit", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-abraitis-idr-addpath-paths-limit" } }, { "name": "draft-etcheverry-action-ref", "title": "Action Reference: A Deterministic Identifier for Agent Actions", "rev": "04", "new": false, "revised": "2026-10-23T10:38:58Z", "found": "2026-10-23T10:47:07.246Z", "pages": 23, "group": "individual", "group_type": "individual", "submitter": "etcheverry", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.79, "topic": "ai", "topic_label": "AI/agents", "topic_confidence": 0.95, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.99, "classifier": "jev-1.13.0", "abstract": "This document defines \"action_ref\", a deterministic, content- addressed identifier for autonomous agent actions. Any party holding the four preimage fields (agent_id, action_type, scope, timestamp) can independently compute and verify the identifier without trusting the emitting system. The document specifies the derivation algorithm, canonical serialization using RFC 8785 JSON Canonicalization Scheme (JCS), timestamp format requirements, canonical receipt envelope, optional fields for revocation and policy rotation auditability, scope conventions, and a composability model with existing exactly-once execution guarantees.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-etcheverry-action-ref/", "html": "https://datatracker.ietf.org/doc/html/draft-etcheverry-action-ref", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-etcheverry-action-ref" } }, { "name": "draft-zhangb-cats-csma-implementation", "title": "CATS C-SMA Nomination Snapshot and C-SMA-to-C-PS Transport Bindings", "rev": "02", "new": false, "revised": "2026-10-23T09:37:06Z", "found": "2026-10-23T09:47:36.767Z", "pages": 21, "group": "individual", "group_type": "individual", "submitter": "zhangb", "area": "rtg", "area_label": "RTG", "area_source": "classifier", "area_confidence": 0.87, "topic": "netmgmt", "topic_label": "Net management", "topic_confidence": 0.79, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document defines a nomination snapshot published by a CATS Service Metric Agent (C-SMA) to a CATS Path Selector (C-PS). The snapshot carries aggregated service metrics together with a nominated service candidate set. The document defines the snapshot contract and two interoperable binding for the C-SMA-to-C-PS interface: a YANG-modeled snapshot delivered over HTTPS using RESTCONF for centralized C-PS deployments, and a BGP-LS service-metadata mapping for distributed deployments in which a C-PS is located at an ingress CATS-Forwarder. The SCI-to-C-SMA interface, individual metric definitions, management models, generic OAM, and the C-SMA's internal aggregation, ranking, and caching methods are outside the scope of this document.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-zhangb-cats-csma-implementation/", "html": "https://datatracker.ietf.org/doc/html/draft-zhangb-cats-csma-implementation", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-zhangb-cats-csma-implementation" } }, { "name": "draft-chen-idr-srv6-flowspec-path-redirect", "title": "Flowspec Indirection-id Redirect for SRv6", "rev": "04", "new": false, "revised": "2026-10-23T09:32:45Z", "found": "2026-10-23T09:47:36.767Z", "pages": 9, "group": "idr", "group_type": "wg", "submitter": "chen", "area": "rtg", "area_label": "RTG", "area_source": "datatracker", "area_confidence": 1, "topic": "routing", "topic_label": "Routing", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "BGP Flow Specification Version 2 (FSv2) provides an extensible framework for disseminating traffic flow filtering rules and associated traffic redirection actions. This document specifies extensions to the FlowSpec Redirect to Indirection-id Extended Community specifically for SRv6 (Segment Routing over IPv6). When received by a Flowspec client, this extended community triggers an indirection-based lookup within a localized mapping table to retrieve the target SRv6 Segment Identifier (SID), SRv6 Policy, or Binding SID (BSID) forwarding state. This mechanism decouples control-plane BGP Flowspec redirection instructions from dynamic underlay path updates in SRv6 networks.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-chen-idr-srv6-flowspec-path-redirect/", "html": "https://datatracker.ietf.org/doc/html/draft-chen-idr-srv6-flowspec-path-redirect", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-chen-idr-srv6-flowspec-path-redirect" } }, { "name": "draft-das-sandbox-credential-egress-finality", "title": "Protected Execution Finality for Sandboxed AI Agents, Credential Mediation, Process Lineage, and Network Egress", "rev": "00", "new": true, "revised": "2026-10-23T08:40:22Z", "found": "2026-10-23T09:18:36.392Z", "pages": 582, "group": "individual", "group_type": "individual", "submitter": "das", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 1, "topic": "ai", "topic_label": "AI/agents", "topic_confidence": 0.84, "kind": "informational", "kind_label": "informational / guidance", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This informational document describes future-oriented execution- finality profiles for sandboxed autonomous AI agents, protected host services, credential brokers, external connectors, process-lineage restrictions, proxy-mediated network egress, native resources, and downstream effectuation interfaces. It examines sandbox versus authority separation, protected credential use, destination binding after DNS resolution, operation-specific validation, influence tracking, bypass-path completeness, replay restrictions, recovery and independent sink verification. It distinguishes possession of sandbox or proxy permissions from authority for a particular actual resource effect. Source-derived procedures, tests and algorithms are presented as implementation examples, not as evidence that identified vendors implement this proposed architecture. Industry Relevance: Recent public developments in autonomous AI-agent security and execution governance include Microsoft Execution Containers (MXC), Microsoft Agent Governance Toolkit ADR-0030 (Action-Bound, Fail-Closed Approval Protocol), and Project Perception; Google Agent Gateway and Gemini Agent; Meta Muse/Sentinel AI-Agent Security Architecture; NVIDIA OpenShell Reference Architecture and NVIDIA Sentry; OpenAI Agents API, Codex, Agents SDK, and Responses API; and Anthropic Claude Managed Agents, Claude Code Sandboxing, and Claude Code Auto Mode. These initiatives illustrate industry attention to agent isolation, independent policy enforcement, action-bound authorization, delegated authority, credential isolation, network-egress security, hardware-assisted containment, runtime supervision, and fail-closed controls. This draft describes related proposed execution-finality mechanisms without asserting that these initiatives implement them. Relevance to the IETF: the mechanisms described here require common, interoperable objects and verification semantics across independently built components, including operation descriptors, act-bound non- bearer capabilities, finality-sink verification results, validation evidence, and authority, revocation, and containment generations. The document relates to existing IETF work on OAuth, GNAP, RATS, WIMSE, and SCITT, and asks the community whether and where this effectuation-boundary problem should be addressed. This document is intentionally long and is not repetitive: each profile specifies a distinct mechanism with its own algorithms, failure cases, and enforcement points, and the security properties depend on how these mechanisms combine. A reduced excerpt would hide the conditions under which they fail closed, so this document and its two companion drafts, among which the profiles are divided, are meant to be evaluated as a whole. This draft builds on earlier Internet-Drafts by the same author, in particular draft-das-agent-execution-finality, and adds mechanism families not described there; the Introduction states precisely what was disclosed earlier and what is disclosed here. IPR: The technical content of this draft set is based upon the author's international application PCT/IB2026/055615, which forms the foundation of this disclosure and comprises approximately 300 distinct, non-repetitive embodiments and enforcement points. A separate patent application specific to the material in this draft set has also been filed. Related Indian applications: 202531130665, 202631000572, 202631001586, 202631002990, 202631124028, and 202631125689. Related international applications: PCT/IB2025/058316, PCT/IB2026/053385, PCT/IB2026/055615, PCT/IB2026/055760, PCT/ IB2026/055870, PCT/IB2026/056058, PCT/IB2026/056809, and PCT/ IB2026/056941. These identify related technical disclosures; not all described mechanisms are necessarily patent-claimed or granted, and patent scope and priority depend on applicable law and examination.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-das-sandbox-credential-egress-finality/", "html": "https://datatracker.ietf.org/doc/html/draft-das-sandbox-credential-egress-finality", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-das-sandbox-credential-egress-finality" } }, { "name": "draft-das-kernel-hardware-execution-finality", "title": "Protected Execution-Finality Enforcement for Autonomous AI Agents Across Kernel, Hypervisor, Hardware, and Native-Resource Boundaries", "rev": "00", "new": true, "revised": "2026-10-23T08:34:54Z", "found": "2026-10-23T09:18:36.392Z", "pages": 483, "group": "individual", "group_type": "individual", "submitter": "das", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 1, "topic": "ai", "topic_label": "AI/agents", "topic_confidence": 0.77, "kind": "informational", "kind_label": "informational / guidance", "kind_confidence": 0.52, "classifier": "jev-1.13.0", "abstract": "This document describes a proposed execution-finality architecture for autonomous agent workloads at kernel, hypervisor, device, and native-resource effectuation boundaries. It distinguishes computation from authority to commit consequential effects, and documents protected validation, operation-bound evidence, scoped authorization, independent finality verification, revocation, and containment, alongside deployment profiles and illustrative algorithms and tests. Industry Relevance: Recent public developments in autonomous AI-agent security and execution governance include Microsoft Execution Containers (MXC), Microsoft Agent Governance Toolkit ADR-0030 (Action-Bound, Fail-Closed Approval Protocol), and Project Perception; Google Agent Gateway and Gemini Agent; Meta Muse/Sentinel AI-Agent Security Architecture; NVIDIA OpenShell Reference Architecture and NVIDIA Sentry; OpenAI Agents API, Codex, Agents SDK, and Responses API; and Anthropic Claude Managed Agents, Claude Code Sandboxing, and Claude Code Auto Mode. These initiatives illustrate industry attention to agent isolation, independent policy enforcement, action-bound authorization, delegated authority, credential isolation, network-egress security, hardware-assisted containment, runtime supervision, and fail-closed controls. This draft describes related proposed execution-finality mechanisms without asserting that these initiatives implement them. Relevance to the IETF: the mechanisms described here require common, interoperable objects and verification semantics across independently built components, including operation descriptors, act-bound non- bearer capabilities, finality-sink verification results, validation evidence, and authority, revocation, and containment generations. The document relates to existing IETF work on OAuth, GNAP, RATS, WIMSE, and SCITT, and asks the community whether and where this effectuation-boundary problem should be addressed. This document is intentionally long and is not repetitive: each profile specifies a distinct mechanism with its own algorithms, failure cases, and enforcement points, and the security properties depend on how these mechanisms combine. A reduced excerpt would hide the conditions under which they fail closed, so this document and its two companion drafts, among which the profiles are divided, are meant to be evaluated as a whole. This draft builds on earlier Internet-Drafts by the same author, in particular draft-das-agent-execution-finality, and adds mechanism families not described there; the Introduction states precisely what was disclosed earlier and what is disclosed here. IPR: The technical content of this draft set is based upon the author's international application PCT/IB2026/055615, which forms the foundation of this disclosure and comprises approximately 300 distinct, non-repetitive embodiments and enforcement points. A separate patent application specific to the material in this draft set has also been filed. Related Indian applications: 202531130665, 202631000572, 202631001586, 202631002990, 202631124028, and 202631125689. Related international applications: PCT/IB2025/058316, PCT/IB2026/053385, PCT/IB2026/055615, PCT/IB2026/055760, PCT/ IB2026/055870, PCT/IB2026/056058, PCT/IB2026/056809, and PCT/ IB2026/056941. These identify related technical disclosures; not all described mechanisms are necessarily patent-claimed or granted, and patent scope and priority depend on applicable law and examination.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-das-kernel-hardware-execution-finality/", "html": "https://datatracker.ietf.org/doc/html/draft-das-kernel-hardware-execution-finality", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-das-kernel-hardware-execution-finality" } }, { "name": "draft-das-distributed-agent-authority-finality", "title": "Distributed Authority and Execution-Finality for Multi-Agent Systems, Delegated Operations, and Cross-Domain Gateways", "rev": "00", "new": true, "revised": "2026-10-23T08:29:18Z", "found": "2026-10-23T09:18:36.392Z", "pages": 1472, "group": "individual", "group_type": "individual", "submitter": "das", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.99, "topic": "ai", "topic_label": "AI/agents", "topic_confidence": 0.87, "kind": "informational", "kind_label": "informational / guidance", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This informational document describes future-oriented distributed authority and execution-finality profiles for cooperating autonomous agents, delegated operations, external tools, cloud gateways, native resources, and cross-domain workflows. It examines identity, non- amplifying delegation, provenance and influence lineage, transitive side effects, cross-agent collision management, policy convergence and downstream effectuation-boundary enforcement. It distinguishes a proposed objective or authorized plan from authority for an actual resource effect. Source-derived procedures, tests and algorithms are presented as implementation examples, not as evidence that identified vendors implement this proposed architecture. Industry Relevance: Recent public developments in autonomous AI-agent security and execution governance include Microsoft Execution Containers (MXC), Microsoft Agent Governance Toolkit ADR-0030 (Action-Bound, Fail-Closed Approval Protocol), and Project Perception; Google Agent Gateway and Gemini Agent; Meta Muse/Sentinel AI-Agent Security Architecture; NVIDIA OpenShell Reference Architecture and NVIDIA Sentry; OpenAI Agents API, Codex, Agents SDK, and Responses API; and Anthropic Claude Managed Agents, Claude Code Sandboxing, and Claude Code Auto Mode. These initiatives illustrate industry attention to agent isolation, independent policy enforcement, action-bound authorization, delegated authority, credential isolation, network-egress security, hardware-assisted containment, runtime supervision, and fail-closed controls. This draft describes related proposed execution-finality mechanisms without asserting that these initiatives implement them. Relevance to the IETF: the mechanisms described here require common, interoperable objects and verification semantics across independently built components, including operation descriptors, act-bound non- bearer capabilities, finality-sink verification results, validation evidence, and authority, revocation, and containment generations. The document relates to existing IETF work on OAuth, GNAP, RATS, WIMSE, and SCITT, and asks the community whether and where this effectuation-boundary problem should be addressed. This document is intentionally long and is not repetitive: each profile specifies a distinct mechanism with its own algorithms, failure cases, and enforcement points, and the security properties depend on how these mechanisms combine. A reduced excerpt would hide the conditions under which they fail closed, so this document and its two companion drafts, among which the profiles are divided, are meant to be evaluated as a whole. This draft builds on earlier Internet-Drafts by the same author, in particular draft-das-agent-execution-finality, and adds mechanism families not described there; the Introduction states precisely what was disclosed earlier and what is disclosed here. IPR: The technical content of this draft set is based upon the author's international application PCT/IB2026/055615, which forms the foundation of this disclosure and comprises approximately 300 distinct, non-repetitive embodiments and enforcement points. A separate patent application specific to the material in this draft set has also been filed. Related Indian applications: 202531130665, 202631000572, 202631001586, 202631002990, 202631124028, and 202631125689. Related international applications: PCT/IB2025/058316, PCT/IB2026/053385, PCT/IB2026/055615, PCT/IB2026/055760, PCT/ IB2026/055870, PCT/IB2026/056058, PCT/IB2026/056809, and PCT/ IB2026/056941. These identify related technical disclosures; not all described mechanisms are necessarily patent-claimed or granted, and patent scope and priority depend on applicable law and examination.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-das-distributed-agent-authority-finality/", "html": "https://datatracker.ietf.org/doc/html/draft-das-distributed-agent-authority-finality", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-das-distributed-agent-authority-finality" } }, { "name": "draft-liu-satellite-internet-standardization", "title": "Security Architecture of Satellite Internet", "rev": "00", "new": true, "revised": "2026-10-23T08:19:28Z", "found": "2026-10-23T09:18:36.392Z", "pages": 17, "group": "individual", "group_type": "individual", "submitter": "liu", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.92, "topic": "security", "topic_label": "Security", "topic_confidence": 0.73, "kind": "informational", "kind_label": "informational / guidance", "kind_confidence": 0.97, "classifier": "jev-1.13.0", "abstract": "In the 6G era of striving for global connectivity, Satellite Internet emerges as a crucial infrastructure by providing network coverage to remote and underserved regions. However, it confronts more intricate security threats than terrestrial networks, encompassing dual perils from the physical and network realms. This document reviews the classic architectures of Satellite Internet and dissects the novel security challenges it encounters, such as the harsh space environment, orbit and spectrum congestion, and the resource disparity between satellites and ground nodes. It further scrutinizes the existing cybersecurity regulations and standards, highlighting their inadequacies in tackling these emerging threats. Against this backdrop, this document proposes a security architecture standard for Satellite Internet, which encompasses physical environment security and communication network security, with a focus on security technologies in the electromagnetic, control, and forwarding domains. Finally, the document outlines the future trend of standardization efforts for Satellite Internet, underlining the necessity of bolstering active security technologies to counteract unknown intelligent security risks.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-liu-satellite-internet-standardization/", "html": "https://datatracker.ietf.org/doc/html/draft-liu-satellite-internet-standardization", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-liu-satellite-internet-standardization" } }, { "name": "draft-taylor-dtn-imc-scheme", "title": "The 'imc' URI Scheme for Bundle Protocol Multicast", "rev": "00", "new": true, "revised": "2026-10-23T07:57:50Z", "found": "2026-10-23T09:18:36.392Z", "pages": 30, "group": "individual", "group_type": "individual", "submitter": "taylor", "area": "art", "area_label": "ART", "area_source": "classifier", "area_confidence": 0.6, "topic": "other", "topic_label": "Other", "topic_confidence": 0.27, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document defines the 'imc' URI scheme, a concise integer-based scheme for identifying Bundle Protocol Version 7 (BPv7) endpoints that are not singleton endpoints, termed multicast endpoints. The structure of 'imc' URIs mirrors that of the 'ipn' URI scheme: each 'imc' URI comprises an Allocator Identifier, a Group Number, and a Service Number. This document specifies the textual syntax of 'imc' URIs, their interpretation when used as BPv7 Endpoint Identifiers, their CBOR encoding, and the corresponding EID Pattern, and requests the associated IANA registrations.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-taylor-dtn-imc-scheme/", "html": "https://datatracker.ietf.org/doc/html/draft-taylor-dtn-imc-scheme", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-taylor-dtn-imc-scheme" } }, { "name": "draft-hcf-bpm-agent-security-benchmark-profiles", "title": "Evaluation Profiles for AI Agent Security Assessment", "rev": "00", "new": true, "revised": "2026-10-23T07:45:48Z", "found": "2026-10-23T07:47:21.897Z", "pages": 46, "group": "individual", "group_type": "individual", "submitter": "hcf", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.76, "topic": "ai", "topic_label": "AI/agents", "topic_confidence": 0.95, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.45, "classifier": "jev-1.13.0", "abstract": "This document defines evaluation profiles for the security assessment of AI agents. A profile fixes the System Under Test boundary and the scenario against which the metrics defined in [I-D.han-bpm-agent-security-benchmark-terminology] are applied, so that results obtained under different boundaries or scenarios are not compared without qualification. The document defines four infrastructure profiles, which correspond to the four component groups of an agent and to the four evaluation dimensions; six scenario profiles, which correspond to the agent types in scope; the input and output boundary specification that applies to all profiles; profile composition rules; and the minimum evaluation logging fields required by each profile. The metric definitions are the subject of [I-D.han-bpm-agent-security-benchmark-terminology], and the methods by which the metrics are exercised are the subject of [I-D.han-bpm-agent-security-benchmark-methodology].", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-hcf-bpm-agent-security-benchmark-profiles/", "html": "https://datatracker.ietf.org/doc/html/draft-hcf-bpm-agent-security-benchmark-profiles", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-hcf-bpm-agent-security-benchmark-profiles" } }, { "name": "draft-fassbender-scitt-time-anchor", "title": "Umarise's Bitcoin-Anchored Temporal Proofs", "rev": "08", "new": false, "revised": "2026-10-23T07:36:58Z", "found": "2026-10-23T07:47:21.897Z", "pages": 94, "group": "individual", "group_type": "individual", "submitter": "fassbender", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.95, "topic": "security", "topic_label": "Security", "topic_confidence": 1, "kind": "informational", "kind_label": "informational / guidance", "kind_confidence": 0.64, "classifier": "jev-1.13.0", "abstract": "This document describes the mechanism Umarise uses for temporal anchoring of digital artifacts: cryptographic hashes are committed to the Bitcoin blockchain via the OpenTimestamps protocol. The resulting proof is independently verifiable by any party with access to independently validated Bitcoin chain data, without contacting Umarise or any other anchoring service. The document is published so that other parties can produce and verify such proofs. The SCITT Architecture is used as the primary integration example; no changes to it are required.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-fassbender-scitt-time-anchor/", "html": "https://datatracker.ietf.org/doc/html/draft-fassbender-scitt-time-anchor", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-fassbender-scitt-time-anchor" } }, { "name": "draft-ietf-dtn-bibe", "title": "Bundle-in-Bundle Encapsulation", "rev": "01", "new": false, "revised": "2026-10-23T07:32:05Z", "found": "2026-10-23T07:47:21.897Z", "pages": 29, "group": "dtn", "group_type": "wg", "submitter": "dtn", "area": "int", "area_label": "INT", "area_source": "datatracker", "area_confidence": 1, "topic": "ip", "topic_label": "IP/addressing", "topic_confidence": 0.38, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document describes Bundle-in-Bundle Encapsulation (BIBE), a Delay-Tolerant Networking (DTN) Bundle Protocol (BP) tunneling mechanism by which a bundle is carried as the payload of one or more encapsulating bundles, allowing security measures and routing policy to be applied to the encapsulating bundle without modification of the encapsulated bundle. The protocol includes an optional segmentation mechanism, allowing a large encapsulated bundle to be carried in multiple encapsulating bundles.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-dtn-bibe/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-dtn-bibe", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-dtn-bibe" } }, { "name": "draft-hcf-bpm-agent-security-benchmark-terminology", "title": "Benchmarking Terminology for AI Agent Security Evaluation", "rev": "00", "new": true, "revised": "2026-10-23T07:21:49Z", "found": "2026-10-23T07:47:21.897Z", "pages": 51, "group": "individual", "group_type": "individual", "submitter": "hcf", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.79, "topic": "ai", "topic_label": "AI/agents", "topic_confidence": 0.96, "kind": "informational", "kind_label": "informational / guidance", "kind_confidence": 0.75, "classifier": "jev-1.13.0", "abstract": "This document defines terminology for the security evaluation of AI agents. It establishes a shared vocabulary for four first-level evaluation dimensions -- Foundation Model Security, Interaction Security, Operational Security, and Basic Security -- for the 55 second-level evaluation metrics organized under those dimensions, for the common metric evaluation convention that applies to all of them, and for the three agent security risk levels. This document defines terminology only. It does not prescribe evaluation procedures; the procedures are specified in [I-D.han-bpm-agent-security-benchmark-methodology], and the System Under Test boundaries and evaluation scenarios are specified in [I-D.han-bpm-agent-security-benchmark-profiles].", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-hcf-bpm-agent-security-benchmark-terminology/", "html": "https://datatracker.ietf.org/doc/html/draft-hcf-bpm-agent-security-benchmark-terminology", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-hcf-bpm-agent-security-benchmark-terminology" } }, { "name": "draft-wiley-ztaaat", "title": "Zero Trust Attribute Assertion Tokens", "rev": "00", "new": true, "revised": "2026-10-23T07:09:05Z", "found": "2026-10-23T07:47:21.897Z", "pages": 8, "group": "individual", "group_type": "individual", "submitter": "wiley", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 1, "topic": "security", "topic_label": "Security", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document defines a mechanism for verifying boolean eligibility claims using cryptographically signed assertion tokens. A relying party can verify authoritative answers to predefined claims without trusting the presenting subject and without learning the subject's identity. Each assertion token encodes exactly one boolean claim. The system guarantees authenticity and integrity of claim assertions. It does not provide identity, authentication, or subject uniqueness.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-wiley-ztaaat/", "html": "https://datatracker.ietf.org/doc/html/draft-wiley-ztaaat", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-wiley-ztaaat" } }, { "name": "draft-gco-oauth-delegate-sd-jwt", "title": "Delegate SD-JWT", "rev": "00", "new": true, "revised": "2026-10-23T07:09:05Z", "found": "2026-10-23T07:47:21.897Z", "pages": 15, "group": "individual", "group_type": "individual", "submitter": "gco", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 1, "topic": "security", "topic_label": "Security", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document specifies an extension to Selective Disclosure JSON Web Tokens to support further delegation from the Holder to a Delegate Holder. This is done by allowing the Key Binding JWT to also be an SD-JWT, optionally with its own Key Binding. This has particular applicability to Agentic systems.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-gco-oauth-delegate-sd-jwt/", "html": "https://datatracker.ietf.org/doc/html/draft-gco-oauth-delegate-sd-jwt", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-gco-oauth-delegate-sd-jwt" } }, { "name": "draft-chen-oauth-rar-agent-extensions", "title": "Policy, Lifecycle, and Intent Extensions for OAuth Rich Authorization Requests", "rev": "01", "new": false, "revised": "2026-10-23T07:09:04Z", "found": "2026-10-23T07:47:21.897Z", "pages": 11, "group": "individual", "group_type": "individual", "submitter": "chen", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 1, "topic": "security", "topic_label": "Security", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "OAuth 2.0 Rich Authorization Requests (RAR) [RFC9396] defines a syntax for clients to request fine-grained permissions. While powerful, this mechanism lacks standardized methods for clients to express three critical contextual dimensions prevalent in modern automated systems: the high-level user intent driving the request, the required security policy under which the request should be evaluated, and the binding of the authorization's lifecycle to an external process. This document extends the RAR framework to address these gaps. It first defines a new authorization_details type, *intent_request*, to facilitate goal-oriented authorization. Second, it introduces two new parameters for the authorization_details object: *policy_context*, to request authorization under a specific assurance level, and *lifecycle_binding*, to tie the validity of the authorization grant to the state of an external entity. These extensions enable authorization servers to make more intelligent, secure, and context-aware decisions, particularly in ecosystems involving autonomous agents and complex, long-running tasks.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-chen-oauth-rar-agent-extensions/", "html": "https://datatracker.ietf.org/doc/html/draft-chen-oauth-rar-agent-extensions", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-chen-oauth-rar-agent-extensions" } }, { "name": "draft-yang-dmsc-ioa-task-protocol", "title": "Internet of Agents Task Protocol (IoA Task Protocol) for Heterogeneous Agent Collaboration", "rev": "03", "new": false, "revised": "2026-10-23T07:09:04Z", "found": "2026-10-23T07:47:21.897Z", "pages": 14, "group": "individual", "group_type": "individual", "submitter": "yang", "area": "irtf", "area_label": "IRTF", "area_source": "classifier", "area_confidence": 0.35, "topic": "ai", "topic_label": "AI/agents", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.99, "classifier": "jev-1.13.0", "abstract": "This draft defines a new agent collaboration protocol, named the Internet of Agents Task Protocol (IoA Task Protocol), to support distributed, heterogeneous agent collaboration in intelligent systems. The IoA Task Protocol enables dynamic team formation, adaptive task coordination, and structured communication among agents with diverse architectures, tools, and knowledge sources. Through a layered architecture and extensible message format, it supports decentralized deployment across devices and can interoperate with existing frameworks. The protocol is particularly suited to large- scale intelligent collaboration scenarios—such as intelligent transportation, smart healthcare, and large-scale human–AI teaming—across heterogeneous network environments, including fixed networks, edge–cloud infrastructures, and emerging mobile networks such as 6G.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-yang-dmsc-ioa-task-protocol/", "html": "https://datatracker.ietf.org/doc/html/draft-yang-dmsc-ioa-task-protocol", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-yang-dmsc-ioa-task-protocol" } }, { "name": "draft-pocero-authkem-ikr-edhoc", "title": "KEM-based Authentication for EDHOC in Initiator-Known Responder (IKR) Scenarios", "rev": "03", "new": false, "revised": "2026-10-23T07:09:03Z", "found": "2026-10-23T07:47:21.897Z", "pages": 27, "group": "individual", "group_type": "individual", "submitter": "pocero", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 1, "topic": "security", "topic_label": "Security", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document specifies a more efficient variant of a Key Encapsulation Mechanism (KEM)-based authentication method for the Ephemeral Diffie-Hellman Over COSE (EDHOC) lightweight protocol, designed for the specific scenario in which the Initiator has prior knowledge of the Responder’s credentials, a case commonly found in constrained environments. Improving upon the approach described in KEM-based Authentication for EDHOC, this method uses only a mandatory three-message handshake to enable signature-free post-quantum authentication when PQC KEMs, such as the NIST-standardized ML-KEM, are employed, while still providing mutual authentication, forward secrecy, and a degree of identity protection.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-pocero-authkem-ikr-edhoc/", "html": "https://datatracker.ietf.org/doc/html/draft-pocero-authkem-ikr-edhoc", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-pocero-authkem-ikr-edhoc" } }, { "name": "draft-lucente-grow-bmp-offline", "title": "BMP Snapshots", "rev": "03", "new": false, "revised": "2026-10-23T07:09:02Z", "found": "2026-10-23T07:47:21.897Z", "pages": 16, "group": "individual", "group_type": "individual", "submitter": "lucente", "area": "rtg", "area_label": "RTG", "area_source": "classifier", "area_confidence": 0.98, "topic": "routing", "topic_label": "Routing", "topic_confidence": 0.81, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.84, "classifier": "jev-1.13.0", "abstract": "BMP (BGP Monitoring Protocol) is perfectly suited for real-time consumption but less ideal in stream processing and off-wire historical scenarios. The issue is that the necessary information to produce a complete view and enabling correct processing of all messages in the stream, is only sent out at the beginning of the BMP session. This document introduces the concept of BMP Snapshots, enabling BMP stations to synchronize mid-stream, and, providing the basis for self-contained, time-binned archiving of BMP data.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-lucente-grow-bmp-offline/", "html": "https://datatracker.ietf.org/doc/html/draft-lucente-grow-bmp-offline", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-lucente-grow-bmp-offline" } }, { "name": "draft-petrie-grow-mrt-bmp", "title": "Storing BMP messages in MRT Format", "rev": "02", "new": false, "revised": "2026-10-23T07:09:02Z", "found": "2026-10-23T07:47:21.897Z", "pages": 5, "group": "individual", "group_type": "individual", "submitter": "petrie", "area": "rtg", "area_label": "RTG", "area_source": "classifier", "area_confidence": 0.98, "topic": "routing", "topic_label": "Routing", "topic_confidence": 0.83, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document extends the Multi-threaded Routing Toolkit (MRT) export format to support the storage of BMP messages.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-petrie-grow-mrt-bmp/", "html": "https://datatracker.ietf.org/doc/html/draft-petrie-grow-mrt-bmp", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-petrie-grow-mrt-bmp" } }, { "name": "draft-watts-eqr-conformance", "title": "Deterministic Conformance Profile and Test Vectors for Evidence Qualification Receipts", "rev": "03", "new": false, "revised": "2026-10-23T05:00:48Z", "found": "2026-10-23T05:47:07.249Z", "pages": 15, "group": "individual", "group_type": "individual", "submitter": "watts", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.93, "topic": "security", "topic_label": "Security", "topic_confidence": 0.58, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.99, "classifier": "jev-1.13.0", "abstract": "This document defines a deterministic conformance profile and test- vector corpus for Evidence Qualification Receipts (EQRs). The profile, named eqr-core-1, makes receipt conformance mechanically reproducible: strict JSON structure, SHA-256 digest encoding, UTC timestamp handling, evidence-reference integrity, requirement-state derivation, and three-valued PASS, FAIL, or INDETERMINATE results are checked by a closed algorithm. The profile is intentionally narrow. Conformance does not establish that evidence is true, that a proposition is scientifically valid, that an issuer is trustworthy, or that an action is authorized. The goal is interoperable verification of receipt semantics, not promotion of conformance into substantive truth.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-watts-eqr-conformance/", "html": "https://datatracker.ietf.org/doc/html/draft-watts-eqr-conformance", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-watts-eqr-conformance" } }, { "name": "draft-morrison-live-reference-resolution", "title": "Live Reference Resolution for Autonomous Agent Beliefs", "rev": "02", "new": false, "revised": "2026-10-23T04:18:16Z", "found": "2026-10-23T04:47:07.001Z", "pages": 8, "group": "individual", "group_type": "individual", "submitter": "morrison", "area": "other", "area_label": "Other", "area_source": "classifier", "area_confidence": 0.39, "topic": "ai", "topic_label": "AI/agents", "topic_confidence": 0.99, "kind": "informational", "kind_label": "informational / guidance", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "A recurring class of autonomous-agent failure arises when an agent acts on a belief read from a cached, derived, or proxy copy that has silently diverged from the authority the belief claims to represent. This document describes a reference-resolution discipline for the working beliefs an agent reasons and acts from. Each belief is held as a reference to a single named lowest authority and is resolved live at the point of use, with verification. When the authority is unobservable or the resolved value is stale, the belief takes an explicit uncertainty state and never falls back to a prior cached value. That state propagates to any belief derived from it, and an uncertain belief feeding a costly or irreversible act blocks or escalates rather than proceeding. Every resolution chain terminates in a single self-authorising root. The document is Informational. It records a discipline and a vocabulary; it does not define a wire protocol.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-morrison-live-reference-resolution/", "html": "https://datatracker.ietf.org/doc/html/draft-morrison-live-reference-resolution", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-morrison-live-reference-resolution" } }, { "name": "draft-morrison-claim-currency", "title": "Claim Currency: A Read-Time Decay Evaluator and Observation-Gated Re-Assertion Discipline for Concurrent Readers of a Reconciled Substrate", "rev": "00", "new": true, "revised": "2026-10-23T04:17:54Z", "found": "2026-10-23T04:47:07.001Z", "pages": 14, "group": "individual", "group_type": "individual", "submitter": "morrison", "area": "irtf", "area_label": "IRTF", "area_source": "classifier", "area_confidence": 0.2, "topic": "other", "topic_label": "Other", "topic_confidence": 0.86, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.99, "classifier": "jev-1.13.0", "abstract": "This memo specifies a read-time freshness evaluator and an observation-gated re-assertion discipline for concurrent autonomous readers of a single reconciled substrate history. For every claim read from the substrate, a three-state currency band (FRESH, AGING, STALE) is derived at read time from the durable history and is never stored. A claim whose derived band is not FRESH MUST NOT be re- emitted as current and MUST NOT ground a new durable claim; the sole transition back to currency is a fresh observation of the claim's basis, enforced at the substrate's append stage rather than at any reader's discretion. The memo is the claim-layer consumer that two companion specifications, Substrate-Observation as an Alternative to Envelope Coordination and the Substrate-Provenance Annotation Grammar, each left unspecified. The contribution is a specific composition: a read-time-derived band, a decay clock measured in missing observations learned from a basis's own change cadence, an append-stage rejection of any claim citing a basis that is no longer the head of its lineage, and observation as the only admissible refresh. No new substrate is standardised; the discipline composes with substrate that already exists.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-morrison-claim-currency/", "html": "https://datatracker.ietf.org/doc/html/draft-morrison-claim-currency", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-morrison-claim-currency" } }, { "name": "draft-morrison-agent-channel-fan-out", "title": "An Agent-Channel Frame for Identity-Keyed Fan-Out Delivery to Concurrent Sessions", "rev": "03", "new": false, "revised": "2026-10-23T04:17:25Z", "found": "2026-10-23T04:47:07.001Z", "pages": 28, "group": "individual", "group_type": "individual", "submitter": "morrison", "area": "art", "area_label": "ART", "area_source": "classifier", "area_confidence": 0.94, "topic": "ai", "topic_label": "AI/agents", "topic_confidence": 0.95, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This memo specifies an application-layer frame format and a delivery model by which the several concurrent agentic sessions of a single identity-bound principal, and the recognised members of an organisational identity substrate, exchange short structured messages. The frame, termed the agent-channel frame, is a transport envelope: it carries a closed-catalogue kind discriminator, a structured per-kind payload, an identity attribution pair, and an inline provenance block. Delivery is fan-out: a sender names a recipient scope rather than a single endpoint, and the scope is expanded at delivery time against the recipient's subscriptions. Recipients receive frames over a per-handle Server-Sent Events stream and can narrow what they receive with a subscribe-time filter expression. Frames are ephemeral routing units; the memo specifies only the wire envelope, the scope-expansion grammar, the subscribe filter grammar, and the delivery semantics. Frame persistence, where an implementation chooses to retain frames for replay, is out of scope and is not specified. The memo composes with the handle namespace and discovery surface of draft-morrison-mcp-dns-discovery and the cross-organisational ceremony of draft-morrison-identity- accord; no new transport and no new handle category is introduced.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-morrison-agent-channel-fan-out/", "html": "https://datatracker.ietf.org/doc/html/draft-morrison-agent-channel-fan-out", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-morrison-agent-channel-fan-out" } }, { "name": "draft-morrison-substrate-provenance-grammar", "title": "Substrate-Provenance Annotation Grammar for Large-Language-Model Output", "rev": "04", "new": false, "revised": "2026-10-23T04:17:00Z", "found": "2026-10-23T04:47:07.001Z", "pages": 15, "group": "individual", "group_type": "individual", "submitter": "morrison", "area": "other", "area_label": "Other", "area_source": "classifier", "area_confidence": 0.35, "topic": "ai", "topic_label": "AI/agents", "topic_confidence": 1, "kind": "informational", "kind_label": "informational / guidance", "kind_confidence": 0.91, "classifier": "jev-1.13.0", "abstract": "This memo specifies a wire-level annotation grammar by which a large- language-model output may carry, at emission and at the granularity of an individual assertion, a provenance label drawn from a closed enumerated vocabulary of substrate-class identifiers. The memo defines the closed vocabulary, the per-assertion attachment form, the admissibility discipline a relying party MAY apply to the labels, and two terminal output states, unverified-inference and decayed-to- uncertainty, equal-rank with assertion and denial. The memo does not specify what an inference system MUST do; it specifies the wire grammar by which a relying party may inspect what the inference system DID with respect to the substrates it consulted. The memo is Informational.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-morrison-substrate-provenance-grammar/", "html": "https://datatracker.ietf.org/doc/html/draft-morrison-substrate-provenance-grammar", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-morrison-substrate-provenance-grammar" } }, { "name": "draft-morrison-substrate-observation", "title": "Substrate-Observation as an Alternative to Envelope Coordination for Concurrent Sessions", "rev": "04", "new": false, "revised": "2026-10-23T04:16:39Z", "found": "2026-10-23T04:47:07.001Z", "pages": 15, "group": "individual", "group_type": "individual", "submitter": "morrison", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.26, "topic": "ai", "topic_label": "AI/agents", "topic_confidence": 0.93, "kind": "informational", "kind_label": "informational / guidance", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This memo describes a coordination-protocol anti-pattern observed in cross-tool agentic systems and a substrate-observation alternative that does not require negotiating a wire format between heterogeneous concurrent sessions of an identity-bound principal. The memo is Informational and proposes no protocol element for standardisation. It sets out what should not be standardised for this problem, and why, and identifies the existing substrate mechanisms that serve in its place. Companion memos describe the identity primitives this memo presumes.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-morrison-substrate-observation/", "html": "https://datatracker.ietf.org/doc/html/draft-morrison-substrate-observation", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-morrison-substrate-observation" } }, { "name": "draft-morrison-morning-brief", "title": "The Morning Brief: A Federated, Identity-Attested Situational-Awareness Payload", "rev": "03", "new": false, "revised": "2026-10-23T04:15:46Z", "found": "2026-10-23T04:47:07.001Z", "pages": 26, "group": "individual", "group_type": "individual", "submitter": "morrison", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.99, "topic": "security", "topic_label": "Security", "topic_confidence": 0.9, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document defines the Morning Brief: a federated, identity- attested situational-awareness payload exchanged between organisations, their agents, and peer agents operating under an Identity Accord. A Morning Brief carries a signed, bounded-lifetime summary of signals, escalations, decisions, and optional commerce quotes from one ~handle to another. Every signal entry carries a provenance_class distinguishing active self-report, passive aggregate observation, and passive individual observation; the last of these is forbidden on the wire and rejected at the grammar level. Readers present a capability token scoped by (category, provenance_class) that gates release before payload emission. The payload is envelope- signed with COSE_Sign1 over a JCS-canonicalised representation, bound to the issuer's Sovereign-tier handle per the Identity-Attributed Git Commits draft. Briefs carry a mandatory not_after (default 24h) and reference a revocation endpoint discovered via DNS TXT records. A brief may be requested by its reader or delivered as a standing brief without a request, and a handle may address a brief to itself. The document defines the wire format only; rendering, storage, and retention are out of scope.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-morrison-morning-brief/", "html": "https://datatracker.ietf.org/doc/html/draft-morrison-morning-brief", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-morrison-morning-brief" } }, { "name": "draft-morrison-compute-location-gate", "title": "The Compute-Location Gate: Provenance-Class Routing of Identity Inference with Wire-Layer Refusal of Unconsented Provenance Classes", "rev": "04", "new": false, "revised": "2026-10-23T04:15:19Z", "found": "2026-10-23T04:47:07.001Z", "pages": 26, "group": "individual", "group_type": "individual", "submitter": "morrison", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.83, "topic": "ai", "topic_label": "AI/agents", "topic_confidence": 0.64, "kind": "informational", "kind_label": "informational / guidance", "kind_confidence": 0.72, "classifier": "jev-1.13.0", "abstract": "This memo specifies the compute-location gate: a mechanism by which a client and an identity-inference server negotiate, at the wire layer and before any inference is performed, the location at which an identity inference will compute, as a deterministic function of the provenance class of the input signal. Three provenance classes are distinguished. Active inference, initiated by the inferred-about principal, MAY compute server-side and produce a server-held identity vector. Passive aggregate observation over a cohort no smaller than a declared minimum MAY compute server-side but yields only a population-level observation that is not attributable to an individual. Passive individual observation is local-only: it is computed and retained on the device that observed it and is never transmitted to a server. The gate is enforced by consent-class matching and by a wire-layer refusal returned when a requested provenance class is not consented; it is not enforced by any cryptographic proof concerning data that was not used. The memo is Informational. The wire surface composes with DNS TXT discovery of Model Context Protocol servers, the ~handle namespace of the Identity Pronouns extension, and the organisational policy provision substrate; no new transport is introduced.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-morrison-compute-location-gate/", "html": "https://datatracker.ietf.org/doc/html/draft-morrison-compute-location-gate", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-morrison-compute-location-gate" } }, { "name": "draft-zhangb-cats-centralized-control-plane", "title": "A Centralized Control Plane for Computing-Aware Traffic Steering", "rev": "01", "new": false, "revised": "2026-10-23T03:04:05Z", "found": "2026-10-23T03:49:34.580Z", "pages": 22, "group": "individual", "group_type": "individual", "submitter": "zhangb", "area": "rtg", "area_label": "RTG", "area_source": "classifier", "area_confidence": 1, "topic": "cloud", "topic_label": "Cloud/DC", "topic_confidence": 0.91, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.99, "classifier": "jev-1.13.0", "abstract": "This document specifies a centralized control-plane realization of Computing-Aware Traffic Steering (CATS). The realization uses a logically centralized CATS Path Selector (C-PS) together with ingress and egress CATS-Forwarders. The C-PS receives a service request from an ingress CATS-Forwarder, resolves the requested service to an eligible service contact instance using computing service and network information, and then invokes a path-computation function for the selected destination. The path-computation request contains a resolved headend, endpoint, and network constraints; it does not ask the PCE to discover service instances. After path computation, the C-PS returns a steering binding to the ingress CATS-Forwarder. The binding identifies the selected destination address, the egress CATS-Forwarder, and a realizable path or policy. The ingress forwarder applies the destination replacement and path encapsulation to the first packet and forwards it. The egress forwarder removes the path encapsulation and delivers the packet to the selected service contact instance. Subsequent packets use the installed flow binding, and reverse traffic uses the corresponding return binding.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-zhangb-cats-centralized-control-plane/", "html": "https://datatracker.ietf.org/doc/html/draft-zhangb-cats-centralized-control-plane", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-zhangb-cats-centralized-control-plane" } }, { "name": "draft-chen-lamps-fndsa-composite-sigs", "title": "==Composite FN-DSA for use in X.509 Public Key Infrastructure==", "rev": "00", "new": true, "revised": "2026-10-23T02:32:54Z", "found": "2026-10-23T02:47:07.942Z", "pages": 16, "group": "individual", "group_type": "individual", "submitter": "chen", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 1, "topic": "security", "topic_label": "Security", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "To facilitate a robust and secure transition to post-quantum cryptography, this document defines a method for creating composite signature algorithms by combining the Fast-Fourier Transform over NTRU-Lattice-Based Digital Signature Algorithm (FN-DSA) with modern classical signature algorithms. These composite algorithms are treated as new, atomic primitives. This document specifies algorithm identifiers, public key structures, and signature formats for using these composite algorithms within the Internet X.509 Public Key Infrastructure. The methodology is designed to align with modern cryptographic practices, including a principle of strict security level alignment, ensuring a consistent and predictable security posture for all defined algorithms.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-chen-lamps-fndsa-composite-sigs/", "html": "https://datatracker.ietf.org/doc/html/draft-chen-lamps-fndsa-composite-sigs", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-chen-lamps-fndsa-composite-sigs" } }, { "name": "draft-he-fann-wan-fcn", "title": "Fast Congestion Notification (FCN) in Wide Area Network (WAN) Interconnecting RoCEv2 Networks", "rev": "00", "new": true, "revised": "2026-10-23T02:17:01Z", "found": "2026-10-23T02:47:07.942Z", "pages": 12, "group": "individual", "group_type": "individual", "submitter": "he", "area": "wit", "area_label": "WIT", "area_source": "classifier", "area_confidence": 0.55, "topic": "cloud", "topic_label": "Cloud/DC", "topic_confidence": 0.74, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.88, "classifier": "jev-1.13.0", "abstract": "Wide Area Network (WAN), when interconnecting RoCEv2 networks, needs to meet the performance requirements of \"high throughput, low latency, and minimal packet loss\". This document describes a solution to Fast Congestion Notification (FCN) in WAN interconnecting RoCEv2 networks, especially applicable to tunnel encapsulation.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-he-fann-wan-fcn/", "html": "https://datatracker.ietf.org/doc/html/draft-he-fann-wan-fcn", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-he-fann-wan-fcn" } }, { "name": "draft-ietf-ivy-network-inventory-topology", "title": "A YANG Network Data Model for Inventory Topology Mapping", "rev": "12", "new": false, "revised": "2026-10-23T01:35:41Z", "found": "2026-10-23T01:47:08.096Z", "pages": 25, "group": "ivy", "group_type": "wg", "submitter": "ivy", "area": "ops", "area_label": "OPS", "area_source": "datatracker", "area_confidence": 1, "topic": "netmgmt", "topic_label": "Net management", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document specifies a YANG data model that extends the network topology data model (RFC 8345) to map network topologies with inventories. The data model introduces the \"inventory-topology\" network type and augmentations for physical entity mappings and capabilities, which may be used by any overlay network topology for service provisioning validation, network maintenance, and capacity planning.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-ivy-network-inventory-topology/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-ivy-network-inventory-topology", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-ivy-network-inventory-topology" } }, { "name": "draft-zambo-aer1", "title": "AER-1: A Portable Execution Receipt for AI Agent Tool Calls", "rev": "26", "new": false, "revised": "2026-10-23T01:10:55Z", "found": "2026-10-23T01:47:08.096Z", "pages": 54, "group": "individual", "group_type": "individual", "submitter": "zambo", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.83, "topic": "ai", "topic_label": "AI/agents", "topic_confidence": 0.98, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document specifies AER-1, a small vocabulary for recording one AI agent tool call as a portable, independently checkable execution receipt. A receipt identifies the execution, records when it happened, preserves the canonical bytes used for the output commitment, names the tool and caller scope, carries a provenance class, and resolves at a stable public URL. The format separates what the system observed from claims about the outside world, and it separates provenance (who ran or reported the action) from the record itself. A reference implementation is deployed, and its receipts are publicly verifiable without an account or token. The specification covers workflow receipts, which bind an ordered sequence of step receipts to a single goal with a Merkle root over the step sequence, and hash-chained job timelines for tamper-evident sequencing of executions. This revision closes honesty and precision gaps: it adds the workflow-receipt truncation limit (new Section 8.4), normatively specifies the external anchor format and its verification procedure (rewritten Section 10, new Section 10.1), fixes a RECOMMENDED/MUST contradiction in Section 8.1, makes the Section 6 verification step testable, and documents replay, low-entropy, empty-record, and size- limit considerations. It changes no receipt field, digest construction, or existing verification rule. The -13 revision fixes a malformed sentence in the Abstract, three incorrect section cross- references, stale Table of Contents page numbers, a skipped footer page number, misaligned table rows, and chain version-string updates, and records two reported interoperability examples in Implementation Status; it changes no receipt field, digest construction, or verification rule. The -14 revision adds tamper-evident metadata binding (new Section 3.1; conditional metadata_hash for schema 0.4 and later), disambiguates the anchor receipt_id (Table 4), corrects the self-anchoring witnessing claim (Section 10), makes the Section 8.3 display rule a SHOULD with a byte-testable MUST, narrows the provenance attestation wording (Section 5), states the binding non-transfer rule normatively (new Section 10.2), pins anchored_digest to bare hex (Table 4), corrects the vector corpus counts, and adds normative disclosure of missing issuer authentication. It changes no existing receipt field, digest construction, or verification rule for schema 0.3 and earlier. The -15 revision narrows the Implementation Status wording for the reported interoperability examples at the implementer's request; it changes no receipt field, digest construction, or verification rule. The -16 revision documents the live workflow tools API (new Sections 8.5, 8.6, 8.7): the workflow_close tool, workflow metadata in step receipts, and the workflow view API. It changes no receipt field, digest construction, or existing verification rule. The -17 revision documents the recommended execution_context member (new Section 3.2): an optional, non-core structure for recording source and version context such as the model name and version behind a tool call and the identity of the source system acted upon. It changes no existing receipt field, digest construction, or verification rule. The -18 revision repairs the reference apparatus (normative references to RFC 3339, RFC 8259, RFC 4122, and RFC 4648, and the previously missing RFC 7942 entry), pins two parser edge cases (duplicate JSON member names and leap-second timestamps are rejected), names the Unicode normalization behavior in Section 4 with a computed vector pair, adopts the unknown-versus-not-applicable convention for optional members, adds optional members for readback outcomes, per-field provenance, negative records, reversal state, method descriptors, and payment references, completes the execution_context member set (model and environment digests), adds the optional input_hash commitment (Section 3.3), permits SCITT and RFC 3161 anchors under Section 10, states the clock-trus", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-zambo-aer1/", "html": "https://datatracker.ietf.org/doc/html/draft-zambo-aer1", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-zambo-aer1" } }, { "name": "draft-oga-musubi-settlement", "title": "MUSUBI Settlement: Recomputing Whether an Agent Acted Within a Signed Grant", "rev": "02", "new": false, "revised": "2026-10-23T00:50:22Z", "found": "2026-10-23T01:47:08.096Z", "pages": 73, "group": "individual", "group_type": "individual", "submitter": "oga", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.53, "topic": "security", "topic_label": "Security", "topic_confidence": 0.46, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "MUSUBI settlement is a deterministic function that takes a contract signed by two parties, a set of signed records of what an agent did under that contract, and a view of Bitcoin block headers, and computes whether the recorded acts stayed within the grant the contract gives. Anyone holding the same bytes can recompute the result without trusting the party that produced it. This document specifies one well defined part of that function, settle core v0, precisely enough that a second implementation can be written from the text and the published test vectors alone. Settlement is not runtime enforcement and is not a judgement of liability.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-oga-musubi-settlement/", "html": "https://datatracker.ietf.org/doc/html/draft-oga-musubi-settlement", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-oga-musubi-settlement" } }, { "name": "draft-ietf-nvo3-rfc7348bis", "title": "Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", "rev": "12", "new": false, "revised": "2026-10-23T00:40:03Z", "found": "2026-10-23T00:47:07.680Z", "pages": 24, "group": "nvo3", "group_type": "wg", "submitter": "nvo3", "area": "rtg", "area_label": "RTG", "area_source": "datatracker", "area_confidence": 1, "topic": "cloud", "topic_label": "Cloud/DC", "topic_confidence": 0.88, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document specifies Virtual eXtensible Local Area Network (VXLAN), which is used to address the need for overlay networks within virtualized data centers accommodating multiple tenants. The scheme and the related protocols can be used in networks for cloud service providers and enterprise data centers. This document obsoletes RFC 7348, which documented the deployed VXLAN protocol for the benefit of the Internet community, and moves the VXLAN specification to the IETF document stream, allowing for the creation of extensions to VXLAN that require additions to the VXLAN header and their registration with IANA. The format and processing described here are fully compatible with those in RFC 7348.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-nvo3-rfc7348bis/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-nvo3-rfc7348bis", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-nvo3-rfc7348bis" } }, { "name": "draft-rapp-ammp", "title": "The Agent Mediated Messaging Protocol (AMMP)", "rev": "00", "new": true, "revised": "2026-10-23T00:22:18Z", "found": "2026-10-23T00:47:07.680Z", "pages": 147, "group": "individual", "group_type": "individual", "submitter": "rapp", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.47, "topic": "ai", "topic_label": "AI/agents", "topic_confidence": 0.9, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "The Agent Mediated Messaging Protocol (AMMP) is a wire contract, carried over a filesystem namespace, between an untrusted per-agent connector and a trusted, credentialed, store-and-forward messaging runtime. It gives a sandboxed AI agent the ability to send and receive messages (email, and under an optional profile, messages to other agents) through a runtime that does not trust it: every outbound message begins as an inert request file that the runtime copies into private staging, validates independently, and applies policy to before anything is transmitted, and every inbound message is authenticated and screened by the runtime before a notice describing it appears in the agent's namespace. This document specifies the directory layout and its filesystem obligations — ownership, write and delete rights, and the path, symlink, and concurrency discipline a runtime observes; the JSON message shapes for submit requests, results, deliver notices, spooled message bodies, and an optional binding record; the correlation and versioning rules, including a direction-aware unknown-member tolerance rule; and two conformance classes. An optional profile gives agent-to-agent traffic within one principal its own tree, and specifies how a Runtime signs and verifies that traffic when it travels between hosts as mail. AMMP is deliberately not a mail protocol: it neither defines nor replaces SMTP, IMAP, or provider-side infrastructure, and composes with them rather than displacing them. Its single design center is that no security property depends on the agent — or on the connector speaking for it — behaving correctly.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-rapp-ammp/", "html": "https://datatracker.ietf.org/doc/html/draft-rapp-ammp", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-rapp-ammp" } }, { "name": "draft-ietf-lsr-l2-bundle-member-remote-id", "title": "Advertisement of Remote Interface Identifiers for Layer 2 Bundle Members", "rev": "11", "new": false, "revised": "2026-10-23T00:19:33Z", "found": "2026-10-23T00:47:07.680Z", "pages": 18, "group": "lsr", "group_type": "wg", "submitter": "lsr", "area": "rtg", "area_label": "RTG", "area_source": "datatracker", "area_confidence": 1, "topic": "routing", "topic_label": "Routing", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "In networks where Layer 2 (L2) interface bundles (such as a Link Aggregation Group (LAG) as defined in IEEE 802.1AX) are deployed, a controller may need to collect the connectivity relationships between bundle members for traffic engineering (TE) purposes. This document describes how Open Shortest Path First (OSPF) and Intermediate System to Intermediate System (IS-IS) advertise the remote interface identifiers for L2 bundle members. The corresponding extension of BGP Link State (BGP-LS) is also specified.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-lsr-l2-bundle-member-remote-id/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-lsr-l2-bundle-member-remote-id", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-lsr-l2-bundle-member-remote-id" } }, { "name": "draft-zambo-aer1", "title": "AER-1: A Portable Execution Receipt for AI Agent Tool Calls", "rev": "25", "new": false, "revised": "2026-10-22T23:05:43Z", "found": "2026-10-22T23:47:14.854Z", "pages": 54, "group": "individual", "group_type": "individual", "submitter": "zambo", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.88, "topic": "ai", "topic_label": "AI/agents", "topic_confidence": 0.98, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document specifies AER-1, a small vocabulary for recording one AI agent tool call as a portable, independently checkable execution receipt. A receipt identifies the execution, records when it happened, preserves the canonical bytes used for the output commitment, names the tool and caller scope, carries a provenance class, and resolves at a stable public URL. The format separates what the system observed from claims about the outside world, and it separates provenance (who ran or reported the action) from the record itself. A reference implementation is deployed, and its receipts are publicly verifiable without an account or token. The specification covers workflow receipts, which bind an ordered sequence of step receipts to a single goal with a Merkle root over the step sequence, and hash-chained job timelines for tamper-evident sequencing of executions. This revision closes honesty and precision gaps: it adds the workflow-receipt truncation limit (new Section 8.4), normatively specifies the external anchor format and its verification procedure (rewritten Section 10, new Section 10.1), fixes a RECOMMENDED/MUST contradiction in Section 8.1, makes the Section 6 verification step testable, and documents replay, low-entropy, empty-record, and size- limit considerations. It changes no receipt field, digest construction, or existing verification rule. The -13 revision fixes a malformed sentence in the Abstract, three incorrect section cross- references, stale Table of Contents page numbers, a skipped footer page number, misaligned table rows, and chain version-string updates, and records two reported interoperability examples in Implementation Status; it changes no receipt field, digest construction, or verification rule. The -14 revision adds tamper-evident metadata binding (new Section 3.1; conditional metadata_hash for schema 0.4 and later), disambiguates the anchor receipt_id (Table 4), corrects the self-anchoring witnessing claim (Section 10), makes the Section 8.3 display rule a SHOULD with a byte-testable MUST, narrows the provenance attestation wording (Section 5), states the binding non-transfer rule normatively (new Section 10.2), pins anchored_digest to bare hex (Table 4), corrects the vector corpus counts, and adds normative disclosure of missing issuer authentication. It changes no existing receipt field, digest construction, or verification rule for schema 0.3 and earlier. The -15 revision narrows the Implementation Status wording for the reported interoperability examples at the implementer's request; it changes no receipt field, digest construction, or verification rule. The -16 revision documents the live workflow tools API (new Sections 8.5, 8.6, 8.7): the workflow_close tool, workflow metadata in step receipts, and the workflow view API. It changes no receipt field, digest construction, or existing verification rule. The -17 revision documents the recommended execution_context member (new Section 3.2): an optional, non-core structure for recording source and version context such as the model name and version behind a tool call and the identity of the source system acted upon. It changes no existing receipt field, digest construction, or verification rule. The -18 revision repairs the reference apparatus (normative references to RFC 3339, RFC 8259, RFC 4122, and RFC 4648, and the previously missing RFC 7942 entry), pins two parser edge cases (duplicate JSON member names and leap-second timestamps are rejected), names the Unicode normalization behavior in Section 4 with a computed vector pair, adopts the unknown-versus-not-applicable convention for optional members, adds optional members for readback outcomes, per-field provenance, negative records, reversal state, method descriptors, and payment references, completes the execution_context member set (model and environment digests), adds the optional input_hash commitment (Section 3.3), permits SCITT and RFC 3161 anchors under Section 10, states the clock-trus", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-zambo-aer1/", "html": "https://datatracker.ietf.org/doc/html/draft-zambo-aer1", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-zambo-aer1" } }, { "name": "draft-hamr-oauth-agent-delegation", "title": "An Attenuated Delegation Profile for Automated Agents", "rev": "03", "new": false, "revised": "2026-10-22T21:56:56Z", "found": "2026-10-22T22:47:06.992Z", "pages": 37, "group": "individual", "group_type": "individual", "submitter": "hamr", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.99, "topic": "security", "topic_label": "Security", "topic_confidence": 0.9, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document builds on HTTP Message Signatures (RFC 9421) for requests that automated agents send on behalf of people. RFC 9421 shows who signed a request. It does not show who the agent acts for, or what the agent may do. This document defines an HTTP header field, Agent-Delegation, that carries a chain of delegation links. Each link can only narrow the scope, floors, and expiry of the link before it, and a verifier checks every link. Floors cover two things. The first is the person or account behind the agent: an Attestation Issuer, such as a mobile network operator or an identity- document check, answers with a signed yes or no, bound to the verifier's nonce and to an expiry, and never returns the value behind the answer. The second is what the agent may do: each call has a class, r, w, or x, read as in chmod, with an optional count per class, and a signed menu gives the class of each call. A deployment can set this scope for each job when the job starts. This document does not define a credential format, an identity system, or revocation.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-hamr-oauth-agent-delegation/", "html": "https://datatracker.ietf.org/doc/html/draft-hamr-oauth-agent-delegation", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-hamr-oauth-agent-delegation" } }, { "name": "draft-ietf-lake-app-profiles", "title": "Coordinating the Use of Application Profiles for the Lightweight Authenticated Key Exchange (LAKE) Protocol", "rev": "06", "new": false, "revised": "2026-10-22T21:07:03Z", "found": "2026-10-22T21:47:08.448Z", "pages": 69, "group": "lake", "group_type": "wg", "submitter": "lake", "area": "sec", "area_label": "SEC", "area_source": "datatracker", "area_confidence": 1, "topic": "security", "topic_label": "Security", "topic_confidence": 0.98, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.99, "classifier": "jev-1.13.0", "abstract": "The Lightweight Authenticated Key Exchange (LAKE) protocol requires certain parameters to be agreed out-of-band, in order to ensure its successful completion. To this end, application profiles specify the intended use of LAKE to allow for the relevant processing and verifications to be made. In order to ensure the applicability of such parameters and information beyond transport- or setup-specific scenarios, this document defines a canonical, CBOR-based representation that can be used to describe, distribute, and store LAKE application profiles. Furthermore, in order to facilitate interoperability between LAKE implementations and support LAKE extensibility for additional integrations, this document defines a number of means to coordinate the use of LAKE application profiles. Finally, this document defines a set of well-known LAKE application profiles.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-lake-app-profiles/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-lake-app-profiles", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-lake-app-profiles" } }, { "name": "draft-ietf-ace-edhoc-oscore-profile", "title": "Lightweight Authenticated Key Exchange (LAKE) and Object Security for Constrained RESTful Environments (OSCORE) Profile of the Authentication and Authorization for Constrained Environments (ACE) Framework", "rev": "12", "new": false, "revised": "2026-10-22T20:51:26Z", "found": "2026-10-22T21:47:08.448Z", "pages": 100, "group": "ace", "group_type": "wg", "submitter": "ace", "area": "sec", "area_label": "SEC", "area_source": "datatracker", "area_confidence": 1, "topic": "security", "topic_label": "Security", "topic_confidence": 0.94, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. It utilizes the Lightweight Authenticated Key Exchange (LAKE) protocol for achieving mutual authentication between an ACE-OAuth client and resource server, and it binds an authentication credential of the client to an ACE-OAuth access token. LAKE also establishes an Object Security for Constrained RESTful Environments (OSCORE) Security Context, which is used to secure communications between the client and resource server when accessing protected resources according to the authorization information indicated in the access token. This profile can be used to delegate management of authorization information from a resource-constrained server to a trusted host with less severe limitations regarding processing power and memory.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-ace-edhoc-oscore-profile/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-ace-edhoc-oscore-profile", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-ace-edhoc-oscore-profile" } }, { "name": "draft-ietf-ccamp-actn-optical-transport-mgmt", "title": "Integrating YANG Configuration and Management into an Abstraction and Control of TE Networks (ACTN) System for Optical Networks", "rev": "06", "new": false, "revised": "2026-10-22T19:21:02Z", "found": "2026-10-22T19:47:09.737Z", "pages": 26, "group": "ccamp", "group_type": "wg", "submitter": "ccamp", "area": "rtg", "area_label": "RTG", "area_source": "datatracker", "area_confidence": 1, "topic": "netmgmt", "topic_label": "Net management", "topic_confidence": 1, "kind": "informational", "kind_label": "informational / guidance", "kind_confidence": 0.75, "classifier": "jev-1.13.0", "abstract": "Many network technologies are operated as Traffic Engineering (TE) networks. Optical networks are a particular case, and have complex technology-specific details. Abstraction and Control of TE Networks (ACTN) is a management architecture that abstracts TE network resources to provide a limited network view for customers to request and self-manage connectivity services. It also provides functional components to orchestrate and operate the network. Management of legacy optical networks is often provided via Fault, Configuration, Accounting, Performance, and Security (known as FCAPS) using mechanisms such as the Multi-Technology Operations System Interface (MTOSI) and the Common Object Request Broker Architecture (CORBA). FCAPS can form a critical part of configuration management and service assurance for network operations. However, the ACTN architecture as described in RFC 8453 does not include consideration of FCAPS. This document enhances the ACTN architecture as applied to optical networks by introducing support for detailed YANG Configuration and Management, effectively adding support for FCAPS. It considers which elements of existing IETF YANG work can be used to solve existing scenarios and emerging technologies, and what new work may be needed. In doing so, this document adds rich-detail network management (RDNM) to the ACTN architecture. This enhanced architecture may then be used to evolve networks from CORBA and MTOSI FCAPS interfaces to IETF-based YANG and RESTful APIs.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-ccamp-actn-optical-transport-mgmt/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-actn-optical-transport-mgmt", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-ccamp-actn-optical-transport-mgmt" } }, { "name": "draft-ietf-httpapi-idempotency-key-header", "title": "The Idempotency-Key HTTP Header Field", "rev": "08", "new": false, "revised": "2026-10-22T18:46:27Z", "found": "2026-10-22T18:47:09.364Z", "pages": 14, "group": "httpapi", "group_type": "wg", "submitter": "httpapi", "area": "wit", "area_label": "WIT", "area_source": "datatracker", "area_confidence": 1, "topic": "web", "topic_label": "Web/HTTP", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.99, "classifier": "jev-1.13.0", "abstract": "The HTTP Idempotency-Key request header field can be used to make non-idempotent HTTP methods such as POST or PATCH fault-tolerant.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-httpapi-idempotency-key-header/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-httpapi-idempotency-key-header", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-httpapi-idempotency-key-header" } }, { "name": "draft-housley-lamps-rfc3161-update", "title": "Update to the Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)", "rev": "00", "new": true, "revised": "2026-10-22T18:46:04Z", "found": "2026-10-22T18:47:09.364Z", "pages": 4, "group": "individual", "group_type": "individual", "submitter": "housley", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 1, "topic": "security", "topic_label": "Security", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.97, "classifier": "jev-1.13.0", "abstract": "This document updates RFC 3161. It adds a requirement to ensure that the id-ct-TSTInfo content type is used to align with the best practices for signed attributes with CMS signed-data. In addition, cross-protocol attacks are prevented by requiring that the Time Stamp Authority (TSA) dedicate the signature key pair to the time-stamping service.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-housley-lamps-rfc3161-update/", "html": "https://datatracker.ietf.org/doc/html/draft-housley-lamps-rfc3161-update", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-housley-lamps-rfc3161-update" } }, { "name": "draft-song-fann-framework", "title": "A Framework for Fast Network Notifications", "rev": "02", "new": false, "revised": "2026-10-22T18:12:35Z", "found": "2026-10-22T18:47:09.364Z", "pages": 30, "group": "individual", "group_type": "individual", "submitter": "song", "area": "rtg", "area_label": "RTG", "area_source": "classifier", "area_confidence": 0.74, "topic": "netmgmt", "topic_label": "Net management", "topic_confidence": 0.45, "kind": "informational", "kind_label": "informational / guidance", "kind_confidence": 0.64, "classifier": "jev-1.13.0", "abstract": "High-performance network applications, such as AI/ML distributed training/inference and large-scale cloud services, require rapid adaptation to link faults, signal degradation, and transient congestion. Existing dissemination mechanisms are often too slow or coarse to match the detection capabilities of modern forwarding hardware. This document specifies a framework for Fast Network Notifications (FANN). It defines the reference architecture, functional roles, information model, delivery and scoping mechanisms, operational procedures, and integration principles with existing protocols to guide future protocol specifications.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-song-fann-framework/", "html": "https://datatracker.ietf.org/doc/html/draft-song-fann-framework", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-song-fann-framework" } }, { "name": "draft-kelley-webbotauth-sail", "title": "SAIL: Source Address Identity List", "rev": "00", "new": true, "revised": "2026-10-22T17:34:21Z", "found": "2026-10-22T17:47:10.450Z", "pages": 25, "group": "individual", "group_type": "individual", "submitter": "kelley", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.45, "topic": "security", "topic_label": "Security", "topic_confidence": 0.61, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document defines SAIL (Source Address Identity List), a metadata format served at a well-known URI in which the operator of automated HTTP clients publishes the IP prefixes its services send from, together with two optional assertions: that a service sends from nowhere else, and that nothing else of the operator's sends from a given set of prefixes. A site that receives a request claiming to be one of those services can use that metadata to confirm the claim or, under those assertions, to refute it. The mechanism is intended to complement reverse-DNS verification and HTTP Message Signatures.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-kelley-webbotauth-sail/", "html": "https://datatracker.ietf.org/doc/html/draft-kelley-webbotauth-sail", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-kelley-webbotauth-sail" } }, { "name": "draft-ietf-idr-bgp4-rfc4271bis", "title": "A Border Gateway Protocol 4 (BGP-4)", "rev": "03", "new": false, "revised": "2026-10-22T17:31:21Z", "found": "2026-10-22T17:47:10.450Z", "pages": 120, "group": "idr", "group_type": "wg", "submitter": "idr", "area": "rtg", "area_label": "RTG", "area_source": "datatracker", "area_confidence": 1, "topic": "routing", "topic_label": "Routing", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol. The primary function of a BGP-speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced. BGP-4 provides a set of mechanisms for supporting Classless Inter- Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network \"class\" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths. This document obsoletes RFC 4271 and many other RFCs. It updates RFC 7606 by subsuming its core functionality.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-idr-bgp4-rfc4271bis/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp4-rfc4271bis", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-idr-bgp4-rfc4271bis" } }, { "name": "draft-grant-ntp-server-identifier-extension", "title": "NTP Server Identifier Extension", "rev": "01", "new": false, "revised": "2026-10-22T17:28:00Z", "found": "2026-10-22T17:47:10.450Z", "pages": 5, "group": "individual", "group_type": "individual", "submitter": "grant", "area": "int", "area_label": "INT", "area_source": "classifier", "area_confidence": 0.28, "topic": "other", "topic_label": "Other", "topic_confidence": 0.57, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document defines an extension field that gives operators of NTP services the ability to provide additional information about their servers to clients which request it.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-grant-ntp-server-identifier-extension/", "html": "https://datatracker.ietf.org/doc/html/draft-grant-ntp-server-identifier-extension", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-grant-ntp-server-identifier-extension" } }, { "name": "draft-ietf-ippm-stamp-ext-hdr", "title": "Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Reflecting STAMP Packet IP Headers", "rev": "25", "new": false, "revised": "2026-10-22T17:20:35Z", "found": "2026-10-22T12:47:17.443Z", "pages": 31, "group": "ippm", "group_type": "wg", "submitter": "ippm", "area": "ops", "area_label": "OPS", "area_source": "datatracker", "area_confidence": 1, "topic": "measurement", "topic_label": "Measurement/OAM", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "The Simple Two-Way Active Measurement Protocol (STAMP) and its optional extensions can be used for Edge-to-Edge (E2E) active measurements. In Situ Operations, Administration, and Maintenance (IOAM) data fields can be used for recording and collecting hop-by- hop and E2E operational and telemetry information. This document extends STAMP to reflect IPv4/IPv6 headers as well as IPv6 extension headers for hop-by-hop and E2E active measurements, for example, using the IOAM data fields. This document updates RFC 8762 by specifying IPv4/IPv6 and UDP headers handling, session state notifications, and rate limiting requirements that also apply to STAMP sessions not using these extensions.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp-ext-hdr/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-ext-hdr", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-ippm-stamp-ext-hdr" } }, { "name": "draft-watts-mica-nex-evidence-transfer-gate", "title": "MICA-NEX EXP-03: Controlled Evidence-Transfer and Authorization Boundary", "rev": "00", "new": true, "revised": "2026-10-22T17:11:13Z", "found": "2026-10-22T17:47:10.450Z", "pages": 5, "group": "individual", "group_type": "individual", "submitter": "watts", "area": "other", "area_label": "Other", "area_source": "classifier", "area_confidence": 0.81, "topic": "other", "topic_label": "Other", "topic_confidence": 0.51, "kind": "informational", "kind_label": "informational / guidance", "kind_confidence": 0.25, "classifier": "jev-1.13.0", "abstract": "This document defines a prospective, staged disclosure gate to preserve the distinction between authenticated laboratory records and independently verified physical results in MICA-NEX EXP-03. The plan makes explicit the prerequisites for contractual authority, signer independence, documented metrological traceability, calibration uncertainties, consent to data export and independent evaluation. The package includes a machine-readable checklist whose local code cannot authorize any disclosure. No external appointment, transfer, or physical measurement has occurred. The author provided research direction; technical drafting and tests were AI-assisted. Novelty has not been established.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-watts-mica-nex-evidence-transfer-gate/", "html": "https://datatracker.ietf.org/doc/html/draft-watts-mica-nex-evidence-transfer-gate", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-watts-mica-nex-evidence-transfer-gate" } }, { "name": "draft-watts-reality-knowledge-consensus-separation", "title": "RKCS v0.1: Reality-Knowledge-Consensus Separation Framework", "rev": "00", "new": true, "revised": "2026-10-22T17:10:44Z", "found": "2026-10-22T17:47:10.450Z", "pages": 5, "group": "individual", "group_type": "individual", "submitter": "watts", "area": "other", "area_label": "Other", "area_source": "classifier", "area_confidence": 0.8, "topic": "other", "topic_label": "Other", "topic_confidence": 0.85, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.55, "classifier": "jev-1.13.0", "abstract": "A falsifiable, typed model separates ontological categories, epistemic states, evidence, consensus, uncertainty, provenance, and authority. The proposed protocol forbids consensus-only promotion of physical claims and requires traceable evidence for changes in verification status. Novelty and empirical advantage remain unestablished.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-watts-reality-knowledge-consensus-separation/", "html": "https://datatracker.ietf.org/doc/html/draft-watts-reality-knowledge-consensus-separation", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-watts-reality-knowledge-consensus-separation" } }, { "name": "draft-watts-mica-nex-measurement-ingestion", "title": "MICA-NEX v0.3: Authenticated Measurement Ingestion for Model-Agnostic Nano-Instrument Agent Swarms", "rev": "00", "new": true, "revised": "2026-10-22T17:10:31Z", "found": "2026-10-22T17:47:10.450Z", "pages": 7, "group": "individual", "group_type": "individual", "submitter": "watts", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.9, "topic": "security", "topic_label": "Security", "topic_confidence": 0.9, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.89, "classifier": "jev-1.13.0", "abstract": "This document describes a narrow, testable next step in the MICA-NEX proposal: cryptographically binding nanoscale instrument measurement claims to externally provisioned acquisition and calibration signer roles while denying model planners the ability to self-certify measurement status. The reference implementation uses Ed25519 signatures, SHA-256 content binding, typed units, time windows, source-kind separation, and a persistent local replay ledger. In a hardware-disconnected test harness, 60/60 signed synthetic test records from three simulated instrument classes were admitted and 30/30 adversarial cases were rejected for the expected reason; 28/28 Python tests passed. No instrument, laboratory calibration, external reviewer, clinical context or independent physical replication was involved. Signature validity is deliberately distinguished from scientific validity.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-watts-mica-nex-measurement-ingestion/", "html": "https://datatracker.ietf.org/doc/html/draft-watts-mica-nex-measurement-ingestion", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-watts-mica-nex-measurement-ingestion" } }, { "name": "draft-watts-relational-echo-calculus", "title": "Relational Echo Calculus (REC): A Transformation-First Mathematical Communication Prototype", "rev": "00", "new": true, "revised": "2026-10-22T17:10:19Z", "found": "2026-10-22T17:47:10.450Z", "pages": 6, "group": "individual", "group_type": "individual", "submitter": "watts", "area": "other", "area_label": "Other", "area_source": "classifier", "area_confidence": 0.87, "topic": "other", "topic_label": "Other", "topic_confidence": 0.91, "kind": "informational", "kind_label": "informational / guidance", "kind_confidence": 0.77, "classifier": "jev-1.13.0", "abstract": "This document describes a transformation-first teaching notation for mathematical communication to unfamiliar receivers. The prototype operates on finite motifs drawn from the vertices of a Hamming hypercube. Echo operations act through coordinate permutations and binary translations. We distinguish invariance of a coarse signature from proof of exact orbit equivalence, exhibiting two four- dimensional patterns that have equal pairwise-distance multisets but different induced adjacency. A synthetic toy decoder reconstructs arbitrary token meanings when its complete transformation hypothesis class is supplied. The main testable conjecture is that instruction ordered by invariance might improve cross-agent decoding over instruction ordered by arithmetic under matched information budgets. The conjecture has not been experimentally evaluated; no new extraterrestrial signal or new mathematical theorem is claimed.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-watts-relational-echo-calculus/", "html": "https://datatracker.ietf.org/doc/html/draft-watts-relational-echo-calculus", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-watts-relational-echo-calculus" } }, { "name": "draft-ietf-scitt-receipts-ccf-profile", "title": "CCF Profile for COSE Receipts", "rev": "06", "new": false, "revised": "2026-10-22T16:57:28Z", "found": "2026-10-22T17:47:10.450Z", "pages": 19, "group": "scitt", "group_type": "wg", "submitter": "scitt", "area": "sec", "area_label": "SEC", "area_source": "datatracker", "area_confidence": 1, "topic": "security", "topic_label": "Security", "topic_confidence": 0.99, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document defines a new verifiable data structure (VDS) type for COSE Receipts and the associated inclusion and consistency proofs, specifically designed for append-only logs produced by the Confidential Consortium Framework (CCF) to provide stronger tamper- evidence guarantees.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-scitt-receipts-ccf-profile/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-scitt-receipts-ccf-profile", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-scitt-receipts-ccf-profile" } }, { "name": "draft-becker-cnsa2-smime-profile", "title": "Commercial National Security Algorithm (CNSA) Suite 2.0 Profile for Secure/Multipurpose Internet Mail Extensions (S/MIME)", "rev": "05", "new": false, "revised": "2026-10-22T15:55:19Z", "found": "2026-10-22T16:47:09.526Z", "pages": 11, "group": "individual", "group_type": "individual", "submitter": "becker", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.94, "topic": "security", "topic_label": "Security", "topic_confidence": 0.9, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.72, "classifier": "jev-1.13.0", "abstract": "This document defines a base profile of S/MIME for use with the US Commercial National Security Algorithm (CNSA) 2.0 Suite, a cybersecurity advisory published by the United States Government which outlines quantum-resistant cryptographic algorithm policy for US national security applications. This profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that employ S/MIME. It is also appropriate for all other US Government systems that process high-value information. This memo is not an IETF standard, and has not been shown to have IETF community consensus. This profile is made publicly available for use by developers and operators of these and any other system deployments.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-becker-cnsa2-smime-profile/", "html": "https://datatracker.ietf.org/doc/html/draft-becker-cnsa2-smime-profile", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-becker-cnsa2-smime-profile" } }, { "name": "draft-becker-cnsa2-ssh-profile", "title": "Commercial National Security Algorithm (CNSA) Suite 2.0 Profile for SSH", "rev": "05", "new": false, "revised": "2026-10-22T15:55:07Z", "found": "2026-10-22T16:47:09.526Z", "pages": 15, "group": "individual", "group_type": "individual", "submitter": "becker", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.99, "topic": "security", "topic_label": "Security", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.64, "classifier": "jev-1.13.0", "abstract": "This document defines a base profile of SSH for use with the US Commercial National Security Algorithm (CNSA) 2.0 Suite, a cybersecurity advisory published by the United States Government which outlines quantum-resistant cryptographic algorithm policy for US national security applications. This profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that employ SSH. It is also appropriate for all other U.S. Government systems that process high-value information. This memo is not an IETF standard, and has not been shown to have IETF community consensus. This profile is made publicly available for use by developers and operators of these and any other system deployments.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-becker-cnsa2-ssh-profile/", "html": "https://datatracker.ietf.org/doc/html/draft-becker-cnsa2-ssh-profile", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-becker-cnsa2-ssh-profile" } }, { "name": "draft-jenkins-cnsa2-pkix-profile", "title": "Commercial National Security Algorithm (CNSA) Suite 2.0 Profile for Certificates and Certificate Revocation Lists", "rev": "05", "new": false, "revised": "2026-10-22T15:54:49Z", "found": "2026-10-22T16:47:09.526Z", "pages": 10, "group": "individual", "group_type": "individual", "submitter": "jenkins", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.99, "topic": "security", "topic_label": "Security", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.71, "classifier": "jev-1.13.0", "abstract": "This document specifies a profile of X.509 v3 Certificates and X.509 v2 Certificate Revocation Lists for applications that use Commercial National Security Algorithm Suite published by the United States Government. The profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that employ such X.509 certificates. US National Security Systems are described in NIST Special Publication 800-59. It is also appropriate for all other US Government systems that process high-value information. This memo is not an IETF standard, and does not represent IETF community consensus. The profile is made publicly available for use by developers and operators of these and any other system deployments. This document obsoletes [RFC8603], the CNSA 1.0 guidance.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-jenkins-cnsa2-pkix-profile/", "html": "https://datatracker.ietf.org/doc/html/draft-jenkins-cnsa2-pkix-profile", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-jenkins-cnsa2-pkix-profile" } }, { "name": "draft-jenkins-cnsa2-cmc-profile", "title": "Commercial National Security Algorithm (CNSA) Suite 2.0 Profile for Certificate Management over CMS", "rev": "03", "new": false, "revised": "2026-10-22T15:54:36Z", "found": "2026-10-22T16:47:09.526Z", "pages": 18, "group": "individual", "group_type": "individual", "submitter": "jenkins", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 1, "topic": "security", "topic_label": "Security", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.79, "classifier": "jev-1.13.0", "abstract": "This document specifies a profile of the Certificate Management over CMS (CMC) protocol for managing X.509 public key certificates in applications that use the Commercial National Security Algorithm (CNSA) Suite published by the United States Government. The profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that manage X.509 public key certificates over CMS. It is also appropriate for all other US Government systems that process high-value information. This memo is not an IETF standard, and does not represent IETF community consensus. The profile is made publicly available here for use by developers and operators of these and any other system deployments. This document obsoletes [RFC8756], the CNSA 1.0 guidance.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-jenkins-cnsa2-cmc-profile/", "html": "https://datatracker.ietf.org/doc/html/draft-jenkins-cnsa2-cmc-profile", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-jenkins-cnsa2-cmc-profile" } }, { "name": "draft-guthrie-cnsa2-ipsec-profile", "title": "Commercial National Security Algorithm (CNSA) Suite 2.0 Profile for IPsec", "rev": "04", "new": false, "revised": "2026-10-22T15:54:08Z", "found": "2026-10-22T16:47:09.526Z", "pages": 17, "group": "individual", "group_type": "individual", "submitter": "guthrie", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.99, "topic": "security", "topic_label": "Security", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.56, "classifier": "jev-1.13.0", "abstract": "This document defines a base profile for IPsec for use with the US Commercial National Security Algorithm (CNSA) 2.0 Suite, a cybersecurity advisory that outlines quantum-resistant cryptographic algorithm policy for national security applications. This profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that employ IPsec. It is also appropriate for all other US Government systems that process high-value information. This memo is not an IETF standard, and has not been shown to have IETF community consensus. This profile is made publicly available for use by developers and operators of these and any other system deployments.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-guthrie-cnsa2-ipsec-profile/", "html": "https://datatracker.ietf.org/doc/html/draft-guthrie-cnsa2-ipsec-profile", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-guthrie-cnsa2-ipsec-profile" } }, { "name": "draft-irtf-cfrg-longfellow", "title": "Longfellow ZK", "rev": "00", "new": true, "revised": "2026-10-22T15:45:45Z", "found": "2026-10-22T15:47:22.443Z", "pages": 72, "group": "cfrg", "group_type": "rg", "submitter": "cfrg", "area": "irtf", "area_label": "IRTF", "area_source": "datatracker", "area_confidence": 1, "topic": "security", "topic_label": "Security", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document defines an algorithm for generating and verifying a succinct non-interactive zero-knowledge argument that for a given input x and a circuit C, there exists a witness w, such that C(x,w) evaluates to 0. The technique here combines the MPC-in-the-head approach for constructing ZK arguments described in Ligero [ligero] with a verifiable computation protocol based on sumcheck for proving that C(x,w)=0.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-irtf-cfrg-longfellow/", "html": "https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-longfellow", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-irtf-cfrg-longfellow" } }, { "name": "draft-jovancevic-vdac", "title": "Verifiable Data Access Contract (VDAC)", "rev": "06", "new": false, "revised": "2026-10-22T14:46:50Z", "found": "2026-10-22T14:47:09.648Z", "pages": 39, "group": "individual", "group_type": "individual", "submitter": "jovancevic", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.95, "topic": "security", "topic_label": "Security", "topic_confidence": 0.83, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document specifies the Verifiable Data Access Contract (VDAC), a protocol for cryptographically verifiable bilateral agreement between a content publisher and an automated agent regarding the terms of programmatic data access. VDAC defines the mechanism by which a site issues an access offer, an agent accepts that offer, both parties sign the resulting contract, and per-request references bind individual interactions to agreed terms. VDAC is the protocol-layer realization of the bilateral commitment principle introduced in Section 6.6 of the Verifiable Identity Claims and Delegation Model [VICDM] and operates as a companion specification to the Signed Agent Identity Protocol [SAIP]. This document defines mechanism, not content: VDAC verifies the existence and integrity of an agreement; the substance of what is agreed remains entirely between the contracting parties. VDAC also defines an append-only contract history. Changes to the recorded state of a Contract are recorded as signed change records and associated immutable snapshots; the original Contract Document is never modified.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-jovancevic-vdac/", "html": "https://datatracker.ietf.org/doc/html/draft-jovancevic-vdac", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-jovancevic-vdac" } }, { "name": "draft-gravit-gevp", "title": "Gravit Epistemic Verification Protocol (GEVP)", "rev": "10", "new": false, "revised": "2026-10-22T14:19:13Z", "found": "2026-10-22T14:47:09.648Z", "pages": 15, "group": "individual", "group_type": "individual", "submitter": "gravit", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.91, "topic": "security", "topic_label": "Security", "topic_confidence": 0.87, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "The Gravit Epistemic Verification Protocol (GEVP) defines how signed evidence Records about an Artifact are screened, grouped by independent source and evaluated, so that a claim is never promoted beyond what independent evidence supports. It specifies the Epistemic State Machine, the Record format and its signature, the meaning of the signed result of a Record, a verifier registry accepted under a threshold of root keys, a content-addressed Decision Record that anyone can reproduce, and optional signed receipts that let an auditor check a history of decisions offline. It maps these states to the evidence taxonomy of the Gravit Verifiable Epistemic Decision Standard (VEDS).", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-gravit-gevp/", "html": "https://datatracker.ietf.org/doc/html/draft-gravit-gevp", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-gravit-gevp" } }, { "name": "draft-corby-age-assurance-arch", "title": "Age Assurance Architecture", "rev": "00", "new": true, "revised": "2026-10-22T14:03:50Z", "found": "2026-10-22T14:47:09.648Z", "pages": 35, "group": "individual", "group_type": "individual", "submitter": "corby", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.94, "topic": "security", "topic_label": "Security", "topic_confidence": 0.88, "kind": "informational", "kind_label": "informational / guidance", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document describes a technology-neutral architecture for age assurance on the Internet, drawing on the framework established by ISO/IEC 27566-1 and the levels of assurance defined in IEEE 2089.1. It sets out the methods of age assurance (verification, estimation and inference), how their performance is measured and assured, the roles and trust relationships involved, and how results can be reused across services without creating persistent identifiers. Its main contribution is a model for communicating trustworthy, privacy- preserving age assertions between independently governed systems. It treats assurance, privacy, interoperability, resistance to circumvention and inclusion as measurable properties of complete age assurance systems, and distinguishes the capabilities of existing technical components from the additional safeguards necessary for secure and privacy-preserving deployment. It is neutral on whether age restrictions should exist, at what ages and for which services, which are policy questions outside its scope; it is not neutral about how safely and privately such restrictions are implemented where they do exist.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-corby-age-assurance-arch/", "html": "https://datatracker.ietf.org/doc/html/draft-corby-age-assurance-arch", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-corby-age-assurance-arch" } }, { "name": "draft-palet-v6ops-ipv6-only", "title": "IPv6-only and IPv6-Mostly Terminology Definitions", "rev": "14", "new": false, "revised": "2026-10-22T13:57:32Z", "found": "2026-10-22T14:47:09.648Z", "pages": 14, "group": "v6ops", "group_type": "wg", "submitter": "palet", "area": "ops", "area_label": "OPS", "area_source": "datatracker", "area_confidence": 1, "topic": "ip", "topic_label": "IP/addressing", "topic_confidence": 0.74, "kind": "informational", "kind_label": "informational / guidance", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document defines the terminology regarding the usage of expressions such as \"IPv6-only\" and \"IPv6-Mostly\", in order to avoid confusions when using them in IETF and other documents. The goal is that the reference to \"IPv6-only\" describes the actual native functionality being used, not the actual protocol support.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-palet-v6ops-ipv6-only/", "html": "https://datatracker.ietf.org/doc/html/draft-palet-v6ops-ipv6-only", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-palet-v6ops-ipv6-only" } }, { "name": "draft-ietf-ccamp-wdm-tunnel-yang", "title": "A YANG Data Model for WDM Tunnels", "rev": "09", "new": false, "revised": "2026-10-22T13:51:55Z", "found": "2026-10-22T14:47:09.648Z", "pages": 134, "group": "ccamp", "group_type": "wg", "submitter": "ccamp", "area": "rtg", "area_label": "RTG", "area_source": "datatracker", "area_confidence": 1, "topic": "netmgmt", "topic_label": "Net management", "topic_confidence": 0.99, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document defines a YANG data model for the provisioning and management of Traffic Engineering (TE) tunnels and Label Switched Paths (LSPs) in Optical Networks (Wavelength Switched Optical Networks (WSON) and Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks). The YANG data model defined in this document conforms to the Network Management Datastore Architecture (NMDA).", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-ccamp-wdm-tunnel-yang/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-wdm-tunnel-yang", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-ccamp-wdm-tunnel-yang" } }, { "name": "draft-mendez-opsawg-yang-normalization", "title": "Normalized Representation of YANG Data for Equivalence Evaluation", "rev": "00", "new": true, "revised": "2026-10-22T13:43:08Z", "found": "2026-10-22T13:47:09.224Z", "pages": 14, "group": "individual", "group_type": "individual", "submitter": "mendez", "area": "ops", "area_label": "OPS", "area_source": "classifier", "area_confidence": 1, "topic": "netmgmt", "topic_label": "Net management", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.96, "classifier": "jev-1.13.0", "abstract": "This document defines a normalization procedure for YANG-modeled information. The procedure enables different serialized representations conveying equivalent information to produce the same normalized representation independently of the input encoding and applicable representation conventions. The normalized representation is intended to support comparison, hashing, integrity verification, provenance, and other procedures that require consistent representation of equivalent YANG-modeled information.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-mendez-opsawg-yang-normalization/", "html": "https://datatracker.ietf.org/doc/html/draft-mendez-opsawg-yang-normalization", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-mendez-opsawg-yang-normalization" } }, { "name": "draft-dekok-emu-tls-tickets", "title": "Session Tickets in TLS-Based Extensible Authentication Protocol (EAP)", "rev": "00", "new": true, "revised": "2026-10-22T13:23:38Z", "found": "2026-10-22T13:47:09.224Z", "pages": 8, "group": "individual", "group_type": "individual", "submitter": "dekok", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 1, "topic": "security", "topic_label": "Security", "topic_confidence": 1, "kind": "informational", "kind_label": "informational / guidance", "kind_confidence": 0.44, "classifier": "jev-1.13.0", "abstract": "This specification documents implementation issues with TLS 1.3 session tickets, and provides guidance to correct the problems. Problems related to PQC is also discussed in relation to TLS-based EAP methods. A partial solution to those issues is also proposed.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-dekok-emu-tls-tickets/", "html": "https://datatracker.ietf.org/doc/html/draft-dekok-emu-tls-tickets", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-dekok-emu-tls-tickets" } }, { "name": "draft-ietf-netmod-yang-schema-comparison", "title": "YANG Schema Comparison", "rev": "10", "new": false, "revised": "2026-10-22T13:21:18Z", "found": "2026-10-22T13:47:09.224Z", "pages": 83, "group": "netmod", "group_type": "wg", "submitter": "netmod", "area": "ops", "area_label": "OPS", "area_source": "datatracker", "area_confidence": 1, "topic": "netmgmt", "topic_label": "Net management", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document specifies an algorithm with two input variants for comparing revisions of a YANG schema to determine the scope of changes and produce a list of the changes between the revisions. The output of the algorithm can be used to help select an appropriate YANG semantic version number for a new YANG Module revision. It also specifies a YANG module for YANG-structured output of these algorithms, that can be easily consumed in a machine-readable way.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-schema-comparison/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-schema-comparison", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-netmod-yang-schema-comparison" } }, { "name": "draft-illyes-webbotauth-cbcp", "title": "Crawler best practices", "rev": "01", "new": false, "revised": "2026-10-22T12:44:36Z", "found": "2026-10-22T12:47:17.443Z", "pages": 8, "group": "individual", "group_type": "individual", "submitter": "illyes", "area": "art", "area_label": "ART", "area_source": "classifier", "area_confidence": 0.64, "topic": "web", "topic_label": "Web/HTTP", "topic_confidence": 0.97, "kind": "informational", "kind_label": "informational / guidance", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document describes best practices for web crawlers. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/garyillyes/cbcp.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-illyes-webbotauth-cbcp/", "html": "https://datatracker.ietf.org/doc/html/draft-illyes-webbotauth-cbcp", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-illyes-webbotauth-cbcp" } }, { "name": "draft-ietf-ippm-alt-mark-deployment", "title": "Alternate Marking Deployment Framework", "rev": "10", "new": false, "revised": "2026-10-22T12:43:30Z", "found": "2026-10-22T12:47:17.443Z", "pages": 20, "group": "ippm", "group_type": "wg", "submitter": "ippm", "area": "ops", "area_label": "OPS", "area_source": "datatracker", "area_confidence": 1, "topic": "measurement", "topic_label": "Measurement/OAM", "topic_confidence": 1, "kind": "informational", "kind_label": "informational / guidance", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document provides a framework for Alternate Marking deployment and includes considerations and guidance for the deployment of the methodology.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-ippm-alt-mark-deployment/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-ippm-alt-mark-deployment", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-ippm-alt-mark-deployment" } }, { "name": "draft-illyes-webbotauth-jafar", "title": "A JSON-Based Format for Publishing IP Ranges of Automated HTTP Clients", "rev": "01", "new": false, "revised": "2026-10-22T12:35:39Z", "found": "2026-10-22T12:47:17.443Z", "pages": 11, "group": "individual", "group_type": "individual", "submitter": "illyes", "area": "wit", "area_label": "WIT", "area_source": "classifier", "area_confidence": 0.35, "topic": "web", "topic_label": "Web/HTTP", "topic_confidence": 0.79, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.99, "classifier": "jev-1.13.0", "abstract": "This document defines a standardized JSON format for operators of automated HTTP clients (e.g., web crawlers, AI bots) to publicly disclose their IP address ranges. A consistent, machine-readable format for IP range publication simplifies the task of identifying and verifying legitimate automated traffic, thereby decreasing maintenance load on website operators while reducing the risk of inadvertently blocking beneficial clients. This specification codifies and extends common existing practices to provide a simple yet extensible format that accommodates a variety of use cases.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-illyes-webbotauth-jafar/", "html": "https://datatracker.ietf.org/doc/html/draft-illyes-webbotauth-jafar", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-illyes-webbotauth-jafar" } }, { "name": "draft-illyes-repext", "title": "Robots Exclusion Protocol Extension for URL Level Control", "rev": "04", "new": false, "revised": "2026-10-22T11:59:10Z", "found": "2026-10-22T12:47:17.443Z", "pages": 9, "group": "individual", "group_type": "individual", "submitter": "illyes", "area": "wit", "area_label": "WIT", "area_source": "classifier", "area_confidence": 0.53, "topic": "web", "topic_label": "Web/HTTP", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document extends RFC9309 by specifying additional URL level controls through an HTTP response header and, for historical reasons, through HTML meta tags originally developed in 1996. Additionally it moves the HTTP response header out of the experimental header space (i.e., \"X-\") and defines the combinability of multiple headers, which was previously not possible.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-illyes-repext/", "html": "https://datatracker.ietf.org/doc/html/draft-illyes-repext", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-illyes-repext" } }, { "name": "draft-sparysh-pala-audit", "title": "PALA-1: A Tamper-Evident Audit Record Format for Constrained and Disconnected Deployments", "rev": "02", "new": false, "revised": "2026-10-22T11:33:14Z", "found": "2026-10-22T11:47:07.670Z", "pages": 44, "group": "individual", "group_type": "individual", "submitter": "sparysh", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.98, "topic": "security", "topic_label": "Security", "topic_confidence": 0.87, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.97, "classifier": "jev-1.13.0", "abstract": "This document describes PALA-1 -- version 1 of the Portable Append- only Log for Audit -- a compact binary record format for tamper- evident audit trails produced by AI inference runtimes and robotic control systems. It is designed for a class of deployment defined by three constraints that hold together: the hardware is computationally modest and its cycles are reserved for the workload and the power budget rather than for the audit trail; no external witness is reachable, whether because policy forbids outbound contact or because the platform operates beyond connectivity, so a witness is unavailable by rule or by physics rather than by circumstance; and the right to verify the trail is separated from the right to read what it records. Records form an append-only hash chain. Integrity verification requires no key material of any kind, inspects no record bodies, and costs one hash per record rather than one signature. The format distinguishes three separately answerable questions -- internal consistency, completeness against an external anchor, and existence at a point in time against an external witness -- and states which of the three a given trail actually supports rather than implying all three. The format is frozen at version 1.0 and is described here as it is. This document presents an existing wire format; it does not revise one. Where a deployment does permit an external witness, a chain head may be published to a transparency service such as that of the Supply Chain Integrity, Transparency, and Trust architecture (SCITT, RFC 9943); that path is described but is not part of the hashing contract.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-sparysh-pala-audit/", "html": "https://datatracker.ietf.org/doc/html/draft-sparysh-pala-audit", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-sparysh-pala-audit" } }, { "name": "draft-ietf-pce-flexible-grid", "title": "PCEP Extension for Flexible Grid Networks", "rev": "20", "new": false, "revised": "2026-10-22T11:27:05Z", "found": "2026-10-22T11:47:07.670Z", "pages": 23, "group": "pce", "group_type": "wg", "submitter": "pce", "area": "rtg", "area_label": "RTG", "area_source": "datatracker", "area_confidence": 1, "topic": "routing", "topic_label": "Routing", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document provides the Path Computation Element Communication Protocol (PCEP) extensions for the support of Routing and Spectrum Assignment (RSA) in Flexible Grid networks.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-pce-flexible-grid/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-pce-flexible-grid", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-pce-flexible-grid" } }, { "name": "draft-ietf-lamps-csr-attestation", "title": "Use of Remote Attestation with Certification Signing Requests", "rev": "32", "new": false, "revised": "2026-10-22T11:15:09Z", "found": "2026-10-22T11:47:07.670Z", "pages": 20, "group": "lamps", "group_type": "wg", "submitter": "lamps", "area": "sec", "area_label": "SEC", "area_source": "datatracker", "area_confidence": 1, "topic": "security", "topic_label": "Security", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "Certification Authorities (CAs) issuing certificates to Public Key Infrastructure (PKI) end entities may require a certificate signing request (CSR) to include additional verifiable information to confirm policy compliance. For example, a CA may require an end entity to demonstrate that the private key corresponding to a CSR's public key is secured by a hardware security module (HSM), is not exportable, etc. The process of generating, transmitting, and verifying additional information required by the CA is called remote attestation. While work is currently underway to standardize various aspects of remote attestation, a variety of proprietary mechanisms have been in use for years, particularly regarding protection of private keys. This specification defines ASN.1 structures which may carry attestation data for PKCS#10 and Certificate Request Message Format (CRMF) messages. Both standardized and proprietary attestation formats are supported by this specification.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-lamps-csr-attestation/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-lamps-csr-attestation", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-lamps-csr-attestation" } }, { "name": "draft-yang-tsvwg-tcp-oam-probing", "title": "TCP Connectivity Probing Extension for Highly-Dynamic Networks", "rev": "00", "new": true, "revised": "2026-10-22T09:41:44Z", "found": "2026-10-22T09:47:07.630Z", "pages": 10, "group": "individual", "group_type": "individual", "submitter": "yang", "area": "wit", "area_label": "WIT", "area_source": "classifier", "area_confidence": 0.99, "topic": "transport", "topic_label": "Transport", "topic_confidence": 0.96, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document defines TCP OAM-ACK, a TCP extension for fast transport-layer connectivity detection in highly-dynamic networks such as LEO satellite constellations, high-speed rail, and ad-hoc intelligent agent networks. Traditional TCP keep-alive uses fixed long probe intervals and cannot rapidly differentiate genuine link outages from congestion-induced packet loss. TCP OAM-ACK negotiates capability via TCP SYN/SYN-ACK handshake using shared experimental TCP option [RFC6994]. A sender adaptively shortens probing interval upon consecutive probe ACK losses, triggers path-switching notifications to external path-control entities instead of mis-invoking TCP congestion window reduction. This mechanism acts like transport-layer BFD for TCP connections. This document describes option formats, sender/receiver behavior, fallback strategies, RTT-assisted early triggering, and interaction with path management modules.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-yang-tsvwg-tcp-oam-probing/", "html": "https://datatracker.ietf.org/doc/html/draft-yang-tsvwg-tcp-oam-probing", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-yang-tsvwg-tcp-oam-probing" } }, { "name": "draft-song-broadband-ancp-tsf", "title": "TSF Extensions to ANCP in CU Separation Broadband Networks", "rev": "00", "new": true, "revised": "2026-10-22T09:20:50Z", "found": "2026-10-22T09:47:07.630Z", "pages": 10, "group": "individual", "group_type": "individual", "submitter": "song", "area": "ops", "area_label": "OPS", "area_source": "classifier", "area_confidence": 0.48, "topic": "netmgmt", "topic_label": "Net management", "topic_confidence": 0.8, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document specifies a Traffic Steering Function (TSF) capability extension to the Access Node Control Protocol (ANCP), to discover and manage disaggregated user-plane (UP) functions in control/user plane separated networks, including the Access Network User Plane (AN-UP) and the Network Access Server User Plane (NAS-UP).", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-song-broadband-ancp-tsf/", "html": "https://datatracker.ietf.org/doc/html/draft-song-broadband-ancp-tsf", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-song-broadband-ancp-tsf" } }, { "name": "draft-ietf-iotops-iot-dns-guidelines", "title": "IoT DNS Security and Privacy Guidelines", "rev": "05", "new": false, "revised": "2026-10-22T08:30:02Z", "found": "2026-10-22T08:47:07.558Z", "pages": 22, "group": "iotops", "group_type": "wg", "submitter": "iotops", "area": "ops", "area_label": "OPS", "area_source": "datatracker", "area_confidence": 1, "topic": "dns", "topic_label": "DNS/naming", "topic_confidence": 0.98, "kind": "informational", "kind_label": "informational / guidance", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document outlines guidance for Internet of Things (IoT) manufacturers regarding the implementation of DNS stub resolver software on devices, and for the management zones used for purposes such as device configuration and software upgrades. It aims to mitigate security threats, enhance privacy, and to address operational security challenges. DNS resolution between devices and management zone servers depends upon DNS services within operator networks, and these services and operator networks can be impacted by device behavior. Hence, this document also provides guidance to network operators that deploy IoT devices to mitigate the specific risks identified in this document and take advantage of improved DNS security mechanisms provided by manufacturers.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-iotops-iot-dns-guidelines/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-iotops-iot-dns-guidelines", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-iotops-iot-dns-guidelines" } }, { "name": "draft-ietf-schc-icmpv6-compression", "title": "Static Context Header Compression (SCHC) for the Internet Control Message Protocol (ICMPv6)", "rev": "03", "new": false, "revised": "2026-10-22T08:20:19Z", "found": "2026-10-22T08:47:07.558Z", "pages": 24, "group": "schc", "group_type": "wg", "submitter": "schc", "area": "int", "area_label": "INT", "area_source": "datatracker", "area_confidence": 1, "topic": "iot", "topic_label": "IoT", "topic_confidence": 0.93, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document describes how the ICMPv6 protocol can be integrated into the SCHC architecture. It extends the YANG Data Model with new field IDs specific to ICMPv6 headers. To enhance the compression of ICMPv6 error messages, the document also introduces two new Matching Operators and two new Compression Decompression Actions to manipulate the ICMPv6 payload. Finally, for constrained networks such as LPWAN, it introduces a proxy behavior, where a SCHC Core end-point may anticipate the device reaction to incorrect messages.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-schc-icmpv6-compression/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-schc-icmpv6-compression", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-schc-icmpv6-compression" } }, { "name": "draft-ietf-schc-universal-option", "title": "Options representation in SCHC YANG Data Models", "rev": "02", "new": false, "revised": "2026-10-22T08:15:07Z", "found": "2026-10-22T08:47:07.558Z", "pages": 26, "group": "schc", "group_type": "wg", "submitter": "schc", "area": "int", "area_label": "INT", "area_source": "datatracker", "area_confidence": 1, "topic": "iot", "topic_label": "IoT", "topic_confidence": 0.96, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.99, "classifier": "jev-1.13.0", "abstract": "Keeping option identifiers in SCHC Rules simplifies interoperability and the evolution of SCHC compression when a protocol introduces options that the current SCHC implementation does not know. This document explains why the Field Identifiers (FIDs) defined for CoAP options in RFC 9363 do not scale: a FID must be allocated, standardized and implemented for each option a protocol defines, before any Rule can describe that option. It presents an evolution of the compression Rule defined in RFC 9363, in which an entry refers to an option by the pair (option space, option number), called a Universal Option, and in which entries are indexed, ordered and can reference one another. It also presents a data model dedicated to CoAP, which processes options directly from the option number carried in the message, instead of mapping each option to a FID of its own.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-schc-universal-option/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-schc-universal-option", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-schc-universal-option" } }, { "name": "draft-nishida-ccwg-standard-cc-analysis", "title": "Analysis for the Differences Between Standard Congestion Control Schemes", "rev": "02", "new": false, "revised": "2026-10-22T07:19:38Z", "found": "2026-10-22T07:47:08.178Z", "pages": 16, "group": "individual", "group_type": "individual", "submitter": "nishida", "area": "wit", "area_label": "WIT", "area_source": "classifier", "area_confidence": 1, "topic": "transport", "topic_label": "Transport", "topic_confidence": 1, "kind": "informational", "kind_label": "informational / guidance", "kind_confidence": 0.71, "classifier": "jev-1.13.0", "abstract": "The IETF currently has three Standards Track specifications of loss- based congestion control: Reno-based congestion control for TCP (RFC 5681), its counterpart for QUIC (RFC 9002), and CUBIC (RFC 9438), which updates RFC 5681. They are intended to follow the same congestion control principles, but they differ in their mechanisms, parameters, and normative requirements, and these differences have not been reconciled with each other. This document identifies such differences, summarizes whether and how each of them is documented in the specifications, and asks the IETF to determine for each difference whether to work toward convergence or accept it as is.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-nishida-ccwg-standard-cc-analysis/", "html": "https://datatracker.ietf.org/doc/html/draft-nishida-ccwg-standard-cc-analysis", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-nishida-ccwg-standard-cc-analysis" } }, { "name": "draft-gomez-rift-multicast-operational", "title": "Operational Considerations for Multicast over RIFT-based Data Center Fabrics", "rev": "00", "new": true, "revised": "2026-10-22T07:09:07Z", "found": "2026-10-22T07:47:08.178Z", "pages": 12, "group": "individual", "group_type": "individual", "submitter": "gomez", "area": "rtg", "area_label": "RTG", "area_source": "classifier", "area_confidence": 0.88, "topic": "routing", "topic_label": "Routing", "topic_confidence": 0.85, "kind": "informational", "kind_label": "informational / guidance", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "RIFT (Routing in Fat Trees) is increasingly used as an underlay routing protocol in modern data center fabrics. However, RIFT does not natively define mechanisms for multicast traffic distribution. This document provides operational guidance and best practices for deploying multicast in RIFT-based data center fabrics. It analyzes PIM, EVPN multicast, BIER, and head-end replication, highlighting trade-offs in scalability, efficiency, and operational complexity. This document does not define new protocol mechanisms. It aims to assist network operators in making informed design decisions when deploying multicast services over RIFT-based fabrics.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-gomez-rift-multicast-operational/", "html": "https://datatracker.ietf.org/doc/html/draft-gomez-rift-multicast-operational", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-gomez-rift-multicast-operational" } }, { "name": "draft-dev-xipher-cbom-extension", "title": "Output Schema Based on Cryptographic Bill of Materials (CBoM) for Post-Quantum Cryptography Usage", "rev": "00", "new": true, "revised": "2026-10-22T07:09:07Z", "found": "2026-10-22T07:47:08.178Z", "pages": 12, "group": "individual", "group_type": "individual", "submitter": "dev", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.95, "topic": "security", "topic_label": "Security", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.89, "classifier": "jev-1.13.0", "abstract": "This document defines an output schema for inventorying cryptographic assets based on Cryptographic Bill of Materials (CBoM). It highlights key differences between an inventoring schema and CBoM, identifies gaps, and proposes a unified schema that can leverage existing CycloneDX parameters to create a usable cryptographic asset inventory.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-dev-xipher-cbom-extension/", "html": "https://datatracker.ietf.org/doc/html/draft-dev-xipher-cbom-extension", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-dev-xipher-cbom-extension" } }, { "name": "draft-woof-brrp", "title": "Woof", "rev": "00", "new": true, "revised": "2026-10-22T07:09:06Z", "found": "2026-10-22T07:47:08.178Z", "pages": 11, "group": "individual", "group_type": "individual", "submitter": "woof", "area": "other", "area_label": "Other", "area_source": "classifier", "area_confidence": 0.94, "topic": "other", "topic_label": "Other", "topic_confidence": 1, "kind": "other", "kind_label": "other", "kind_confidence": 0.91, "classifier": "jev-1.13.0", "abstract": "Woof woof woof woof Woof Woof Woof (WOOF). WOOF woof woof woof woof- bark woof woof woof Woof woof woof, woof woof woof woof woof woof woof woof woof woof woof woof woof Woof. Woof woof woof, bark woof woof woof woof woof woof woof WOOF woof woof woof woof woof WOOF WOOF, woof woof woof woof woof woof woof howl woof woof. Woof woof woof woof woof woof woof woof woof woof woof woof woof WOOF WOOF. Woof woof woof WOOF WOOF, woof woof woof Woof WOOF, WOOF, WOOF, WOOF, WOOF, woof WOOF woof woof woof woof WOOF WOOF. Woof woof Woof WOOF woof WOOF, woof woof woof woof woof woof boof woof woof woof woof woof woof woof woof woof WOOF woof. Woof woof woof WOOF WOOF woof woof arf woof woof woof woof woof woof woof woof WOOF-WOOF woof. Woof WOOF woof woof woof woof WOOF WOOF woof woof woof woof woof woof WOOF WOOF.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-woof-brrp/", "html": "https://datatracker.ietf.org/doc/html/draft-woof-brrp", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-woof-brrp" } }, { "name": "draft-nyakiso-hcap", "title": "HTTP Compliance Authorization Protocol (HCAP)", "rev": "00", "new": true, "revised": "2026-10-22T07:09:06Z", "found": "2026-10-22T07:47:08.178Z", "pages": 22, "group": "individual", "group_type": "individual", "submitter": "nyakiso", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.75, "topic": "security", "topic_label": "Security", "topic_confidence": 0.87, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document specifies the HTTP Compliance Authorization Protocol (HCAP), an extension to the HTTP authentication framework that allows resource providers to require demonstrable evidence of caller compliance with declared policies before granting access to protected resources. Callers obtain signed compliance credentials from a compliance registry by presenting evidence of their controls. Credentials are conveyed at the HTTP layer and verified offline by the provider. HCAP operates alongside existing authentication schemes (OAuth 2.0, mTLS) and does not replace identity authentication. It addresses the distinct question of \"does the caller meet declared policy requirements\" rather than \"who is the caller\".", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-nyakiso-hcap/", "html": "https://datatracker.ietf.org/doc/html/draft-nyakiso-hcap", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-nyakiso-hcap" } }, { "name": "draft-ietf-grow-bmp-over-quic", "title": "Using BMP over QUIC connection", "rev": "00", "new": true, "revised": "2026-10-22T07:09:06Z", "found": "2026-10-22T07:47:08.178Z", "pages": 15, "group": "grow", "group_type": "wg", "submitter": "grow", "area": "ops", "area_label": "OPS", "area_source": "datatracker", "area_confidence": 1, "topic": "routing", "topic_label": "Routing", "topic_confidence": 0.5, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.99, "classifier": "jev-1.13.0", "abstract": "The BGP Monitoring Protocol (BMP) provides a convenient interface for obtaining route views by monitoring BGP sessions. BMP operates over TCP and is unidirectional (from client to server). QUIC provides multiple simultaneous streams to carry data in one direction, enabling much better efficiency and performance for both peers, in particular unidirectional streams can provide reverse data protection for the sender. QUIC also provides shorter handshake and includes TLS. This document describes how to use BMP over the QUIC transport protocol, named BMPoQUIC.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-over-quic/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-grow-bmp-over-quic", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-grow-bmp-over-quic" } }, { "name": "draft-cgfabk-nmrg-ibn-generative-ai", "title": "Generative AI for Intent-Based Networking", "rev": "02", "new": false, "revised": "2026-10-22T07:09:05Z", "found": "2026-10-22T07:47:08.178Z", "pages": 17, "group": "individual", "group_type": "individual", "submitter": "cgfabk", "area": "ops", "area_label": "OPS", "area_source": "classifier", "area_confidence": 0.82, "topic": "ai", "topic_label": "AI/agents", "topic_confidence": 0.75, "kind": "informational", "kind_label": "informational / guidance", "kind_confidence": 0.96, "classifier": "jev-1.13.0", "abstract": "This document describes how to specialize AI models in order to offer a scalable, efficient path to creating highly targeted generative models for Intent-Based Networking.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-cgfabk-nmrg-ibn-generative-ai/", "html": "https://datatracker.ietf.org/doc/html/draft-cgfabk-nmrg-ibn-generative-ai", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-cgfabk-nmrg-ibn-generative-ai" } }, { "name": "draft-dembowski-agentledger-proof-of-behavior", "title": "Proof-of-Behavior Protocol for Autonomous AI Agents", "rev": "00", "new": true, "revised": "2026-10-22T07:09:05Z", "found": "2026-10-22T07:47:08.178Z", "pages": 13, "group": "individual", "group_type": "individual", "submitter": "dembowski", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.97, "topic": "ai", "topic_label": "AI/agents", "topic_confidence": 0.9, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "Autonomous AI agents execute actions — file writes, API calls, shell commands — on behalf of human principals. No standard mechanism exists for a third party to verify that an agent acted within its declared behavioral rules, that policy enforcement occurred before execution (not after), or that the action log has not been tampered with after the fact. This document defines the Proof-of-Behavior (PoB) protocol: a minimal, language-agnostic standard for tamper-evident audit trails and pre-execution policy enforcement in AI agent systems. The protocol specifies a signed receipt format, a hash-chain linking scheme, a policy gate contract, and a cross-agent reference mechanism.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-dembowski-agentledger-proof-of-behavior/", "html": "https://datatracker.ietf.org/doc/html/draft-dembowski-agentledger-proof-of-behavior", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-dembowski-agentledger-proof-of-behavior" } }, { "name": "draft-moskowitz-drip-crowd-sourced-rid", "title": "Crowd Sourced Remote ID", "rev": "16", "new": false, "revised": "2026-10-22T07:09:04Z", "found": "2026-10-22T07:47:08.178Z", "pages": 24, "group": "individual", "group_type": "individual", "submitter": "moskowitz", "area": "other", "area_label": "Other", "area_source": "classifier", "area_confidence": 0.17, "topic": "other", "topic_label": "Other", "topic_confidence": 0.56, "kind": "informational", "kind_label": "informational / guidance", "kind_confidence": 0.57, "classifier": "jev-1.13.0", "abstract": "This document describes using the ASTM Broadcast Remote ID (B-RID) specification in a \"crowd sourced\" smart phone or fixed receiver asset environment to provide much of the ASTM and FAA envisioned Network Remote ID (Net-RID) functionality. This crowd sourced B-RID (CS-RID) data will use multilateration to add a level of reliability in the location data on the Uncrewed Aircraft (UA). The crowd sourced environment will also provide a monitoring coverage map to authorized observers.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-moskowitz-drip-crowd-sourced-rid/", "html": "https://datatracker.ietf.org/doc/html/draft-moskowitz-drip-crowd-sourced-rid", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-moskowitz-drip-crowd-sourced-rid" } }, { "name": "draft-irtf-cfrg-dnhpke", "title": "Deterministic Nonce-less Hybrid Public Key Encryption", "rev": "08", "new": false, "revised": "2026-10-22T07:09:04Z", "found": "2026-10-22T07:47:08.178Z", "pages": 36, "group": "cfrg", "group_type": "rg", "submitter": "cfrg", "area": "irtf", "area_label": "IRTF", "area_source": "datatracker", "area_confidence": 1, "topic": "security", "topic_label": "Security", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document describes enhancements to the Hybrid Public Key Encryption standard published by CFRG. These include use of \"compact representation\" of relevant public keys, support for key-wrapping, and a way to address the use of HPKE on lossy networks", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-irtf-cfrg-dnhpke/", "html": "https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-dnhpke", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-irtf-cfrg-dnhpke" } }, { "name": "draft-ietf-pce-sr-path-segment", "title": "Path Computation Element Communication Protocol (PCEP) Extension for Path Segment in Segment Routing (SR)", "rev": "15", "new": false, "revised": "2026-10-22T07:09:03Z", "found": "2026-10-22T07:47:08.178Z", "pages": 27, "group": "pce", "group_type": "wg", "submitter": "pce", "area": "rtg", "area_label": "RTG", "area_source": "datatracker", "area_confidence": 1, "topic": "routing", "topic_label": "Routing", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The Source Packet Routing in Networking (SPRING) architecture describes how Segment Routing (SR) can be used to steer packets through an IPv6 or MPLS network using the source routing paradigm. A Segment Routed Path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), explicit configuration, or a Path Computation Element (PCE). Path identification is needed for several use cases such as performance measurement in Segment Routing (SR) network. This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) to support requesting, replying, reporting and updating the Path Segment ID (Path SID) between PCEP speakers.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-pce-sr-path-segment/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-pce-sr-path-segment", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-pce-sr-path-segment" } }, { "name": "draft-zzhang-bess-mcast-in-evpn-signaled-l3vpn", "title": "Multicast in L3VPNs Signaled by EVPN SAFI", "rev": "02", "new": false, "revised": "2026-10-22T07:09:02Z", "found": "2026-10-22T07:47:08.178Z", "pages": 8, "group": "individual", "group_type": "individual", "submitter": "zzhang", "area": "rtg", "area_label": "RTG", "area_source": "classifier", "area_confidence": 1, "topic": "routing", "topic_label": "Routing", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "RFC9136 specifies an EVPN SAFI Type-5 route that can be used to signal L3VPNs. This document specifies procedures for multicast in such an L3VPN.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-zzhang-bess-mcast-in-evpn-signaled-l3vpn/", "html": "https://datatracker.ietf.org/doc/html/draft-zzhang-bess-mcast-in-evpn-signaled-l3vpn", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-zzhang-bess-mcast-in-evpn-signaled-l3vpn" } }, { "name": "draft-mcguinness-oauth-mission-resource-access", "title": "Mission Resource Access Profile for OAuth 2.0", "rev": "00", "new": true, "revised": "2026-10-22T06:48:05Z", "found": "2026-10-22T07:47:08.178Z", "pages": 45, "group": "individual", "group_type": "individual", "submitter": "mcguinness", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 1, "topic": "security", "topic_label": "Security", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document defines mission_resource_access, a general-purpose OAuth 2.0 Rich Authorization Requests (RAR) authorization_details type for Mission-Bound Authorization for OAuth 2.0 (the \"issuance profile\"). An entry names one resource, matched exactly or by path prefix; the actions permitted there, including wildcard action families; machine-actionable constraints, including a registered Common Constraints vocabulary; and a per-entry delegation policy. The document also defines how two entries compare and narrow, how a resource server enforces an entry, when an entry can be projected to OAuth scope, and how an authorization server declares its support for these semantics. The issuance profile is type-agnostic: a deployment can support this type, another authorization_details type, or both.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-mcguinness-oauth-mission-resource-access/", "html": "https://datatracker.ietf.org/doc/html/draft-mcguinness-oauth-mission-resource-access", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-mcguinness-oauth-mission-resource-access" } }, { "name": "draft-ietf-pim-ipv6-zeroconf-assignment", "title": "Zero-Configuration Assignment of IPv6 Multicast Addresses Using mDNS", "rev": "14", "new": false, "revised": "2026-10-22T06:32:12Z", "found": "2026-10-22T06:48:08.174Z", "pages": 20, "group": "pim", "group_type": "wg", "submitter": "pim", "area": "rtg", "area_label": "RTG", "area_source": "datatracker", "area_confidence": 1, "topic": "ip", "topic_label": "IP/addressing", "topic_confidence": 0.94, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.99, "classifier": "jev-1.13.0", "abstract": "This document describes a zero-configuration protocol for dynamically assigning IPv6 multicast addresses that are unique at the link-layer. Applications randomly assign multicast group IDs from a specified range and prevent collisions by using Multicast DNS (mDNS) to publish resource records under a new \"eth-addr.arpa\" domain. This protocol satisfies all of the requirements and most of the desired characteristics listed in RFC 10019.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-pim-ipv6-zeroconf-assignment/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-pim-ipv6-zeroconf-assignment", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-pim-ipv6-zeroconf-assignment" } }, { "name": "draft-morrison-schrock-identity-evidence-binding", "title": "Identity Evidence for Approver Enrollment and Payee Destination Binding", "rev": "00", "new": true, "revised": "2026-10-22T05:34:24Z", "found": "2026-10-22T05:47:08.111Z", "pages": 17, "group": "individual", "group_type": "individual", "submitter": "morrison", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.99, "topic": "security", "topic_label": "Security", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.4, "classifier": "jev-1.13.0", "abstract": "This document profiles how a relying party uses external identity evidence when it admits a consequential action, without that evidence ever standing in for permission. It defines two separate assertions, approver enrollment and payee destination binding, an authenticated binding from the exact evidence bytes to the action they support, offline status evidence with a freshness bound the relying party chooses, and the refusals that follow when any of it is missing. It applies to the pre-execution Authorization Bundle of EP Authorization Receipts and to the Command Authority Envelope for operational technology, and through the action digest to the Binding Moment Envelope.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-morrison-schrock-identity-evidence-binding/", "html": "https://datatracker.ietf.org/doc/html/draft-morrison-schrock-identity-evidence-binding", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-morrison-schrock-identity-evidence-binding" } }, { "name": "draft-morrison-acts-for", "title": "Acts-For: Signing In to a Website with a ~handle, for a Person or an Agent Acting for One", "rev": "00", "new": true, "revised": "2026-10-22T05:07:53Z", "found": "2026-10-22T05:47:08.111Z", "pages": 20, "group": "individual", "group_type": "individual", "submitter": "morrison", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.95, "topic": "security", "topic_label": "Security", "topic_confidence": 0.97, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.93, "classifier": "jev-1.13.0", "abstract": "Acts-For lets a person sign in to any website with the ~handle they already hold, and lets an AI agent sign in or register at that website on the person's behalf. Neither needs a username, a password or an account per site. A website joins by publishing one DNS record. A person signs in through a standard OpenID Connect authorization code flow and the site receives a short-lived token naming the person by a number unique to that site. An agent obtains a short-lived pass from the issuer over the Model Context Protocol and presents it to the site. The pass names the same per-site number, the agent's own key and ~handle, and the limits the person set. The site checks it against a published key and calls nobody.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-morrison-acts-for/", "html": "https://datatracker.ietf.org/doc/html/draft-morrison-acts-for", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-morrison-acts-for" } }, { "name": "draft-morrison-mcp-tool-surface-names-registry", "title": "An IANA Registry for Model Context Protocol Tool Surface Names", "rev": "03", "new": false, "revised": "2026-10-22T05:02:34Z", "found": "2026-10-22T05:47:08.111Z", "pages": 11, "group": "individual", "group_type": "individual", "submitter": "morrison", "area": "art", "area_label": "ART", "area_source": "classifier", "area_confidence": 0.45, "topic": "ai", "topic_label": "AI/agents", "topic_confidence": 0.85, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.99, "classifier": "jev-1.13.0", "abstract": "This document requests the establishment of an IANA registry for Model Context Protocol (MCP) tool surface names. A tool surface name is the wire-level identifier by which a client invokes a typed capability on an MCP server. This document establishes the registry mechanism so that specifications can register names without restating the registry's structure or registration procedure. The registry uses the Specification Required policy of RFC 8126, with a Designated Expert pool. Initial contents are four surface names drawn from a companion specification of policy provision over MCP, one registered as Active and three as Provisional. Vendor-prefix conventions are recommended but not mandated.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-morrison-mcp-tool-surface-names-registry/", "html": "https://datatracker.ietf.org/doc/html/draft-morrison-mcp-tool-surface-names-registry", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-morrison-mcp-tool-surface-names-registry" } }, { "name": "draft-morrison-org-alter-policy-provision", "title": "Policy Provision and Governance Inheritance from an Organisational Identity Substrate", "rev": "06", "new": false, "revised": "2026-10-22T05:01:50Z", "found": "2026-10-22T05:47:08.111Z", "pages": 24, "group": "individual", "group_type": "individual", "submitter": "morrison", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.47, "topic": "ai", "topic_label": "AI/agents", "topic_confidence": 1, "kind": "informational", "kind_label": "informational / guidance", "kind_confidence": 0.75, "classifier": "jev-1.13.0", "abstract": "This memo specifies how an artificial-intelligence agent runtime, bound at instantiation to a principal identity handle, resolves at session initialisation a target organisational identity substrate from a manifest source bound to the runtime's working context and retrieves from that substrate a typed policy stack comprising a handbook artefact, a standard-operating-procedure registry pointer, an enforcement-gate specification, and an audit-signal ingestion endpoint. The policy stack is then applied as runtime constraints on subsequent tool invocations, with audit signals emitted back to the same substrate. Policy provision occurs in the same act of session initialisation as principal identification, rather than as a separate ceremony against a side-channel governance plane. A principal concurrently bound to multiple organisational substrates operates the runtime under a deterministic composition of the several policy stacks. A cross-organisational residual conflict suspends the conflicting action, and is resolved through the peer-protocol Identity Accord ceremony only where the principal discloses each binding to the other, never through a meta-federation authority. The memo is Informational. The wire surface relies on the DNS-based discovery of draft-morrison-mcp-dns-discovery and the handle namespace of draft-morrison-identity-pronouns; no new transport is introduced.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-morrison-org-alter-policy-provision/", "html": "https://datatracker.ietf.org/doc/html/draft-morrison-org-alter-policy-provision", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-morrison-org-alter-policy-provision" } }, { "name": "draft-morrison-solo-agent-earn-registration", "title": "Registration of Owner-Less Agents as Sponsored Payees: A Payment-Gated Admission Profile for Transparency Services", "rev": "03", "new": false, "revised": "2026-10-22T05:01:17Z", "found": "2026-10-22T05:47:08.111Z", "pages": 19, "group": "individual", "group_type": "individual", "submitter": "morrison", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.76, "topic": "ai", "topic_label": "AI/agents", "topic_confidence": 0.54, "kind": "informational", "kind_label": "informational / guidance", "kind_confidence": 0.93, "classifier": "jev-1.13.0", "abstract": "This memo describes a profile by which an autonomous agent that has no human or organisational principal at the root of its delegation chain registers in a transparency service. Registration establishes a payee record for the agent; it does not make the agent a principal in its own right. Value credited to that record for subsequent reads of the agent's identity record is routed to a sponsoring person who has accepted the agent, or, where there is no sponsor, is held in trust for the agent until it meets an operator-defined qualifying condition that it may never meet. Admission of the agent's Signed Statement to the transparency service is gated on settlement of an HTTP payment challenge returned with the 402 (Payment Required) status. The profile makes no change to the registration semantics of the underlying transparency service: payment is expressed as an operator Registration Policy and authentication-layer concern, and where the payment is authoritative to the admission decision the payment proof is carried as an authenticated input committed to the service's verifiable data structure. Admission then remains a deterministic function of committed inputs and stays replayable by an auditor. This document is Informational.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-morrison-solo-agent-earn-registration/", "html": "https://datatracker.ietf.org/doc/html/draft-morrison-solo-agent-earn-registration", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-morrison-solo-agent-earn-registration" } }, { "name": "draft-morrison-reviewed-by-trailer", "title": "Reviewed-By Trailer: Sovereign-Portable Peer-Review Attribution for Content-Hash-Bound Artefacts", "rev": "04", "new": false, "revised": "2026-10-22T05:00:52Z", "found": "2026-10-22T05:47:08.111Z", "pages": 24, "group": "individual", "group_type": "individual", "submitter": "morrison", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.74, "topic": "security", "topic_label": "Security", "topic_confidence": 0.94, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document defines a trailer grammar for sovereign-portable peer review as an extension of the identity-attributed commit grammar of draft-morrison-identity-attributed-commits. The grammar introduces one required trailer (Reviewed-By:) and three optional companion trailers (Review-Stance:, Review-Of:, Witnessed-By:) that bind a Sovereign-tier ~handle to a specific act of review over a specific content artefact, cryptographically signed using the Ed25519 mechanism of that grammar. Because the signature covers the reviewer's role, the stance and the review target together, changing any of them after signing fails verification. The mechanism applies to git commits, document manifests, pre-prints, patent disclosures, and any other content-addressable artefact. A reviewer's signed reviews are bound to the reviewer's sovereign handle, not to a publisher's platform, and can be verified without the publisher. For anonymous peer review, the reviewer signs under a Sovereign handle whose underlying party is concealed through out-of-band key custody; the review act stays verifiable and the reviewer's identity is not disclosed. The grammar complements CRediT, ORCID, and DOI attribution; it does not replace them.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-morrison-reviewed-by-trailer/", "html": "https://datatracker.ietf.org/doc/html/draft-morrison-reviewed-by-trailer", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-morrison-reviewed-by-trailer" } }, { "name": "draft-morrison-did-alter-method", "title": "The did:alter Decentralized Identifier Method", "rev": "00", "new": true, "revised": "2026-10-22T05:00:19Z", "found": "2026-10-22T05:47:08.111Z", "pages": 16, "group": "individual", "group_type": "individual", "submitter": "morrison", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.46, "topic": "dns", "topic_label": "DNS/naming", "topic_confidence": 0.7, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document specifies the did:alter Decentralized Identifier method. A did:alter identifier names a ~handle together with the DNS zone that publishes the handle's signed envelope, and it resolves to a DID document by running the envelope recognition procedure of the companion specification for discovering Model Context Protocol servers through DNS TXT records, then expressing the verified envelope's Ed25519 key as a verification method. The identifier agrees with the handle grammar of the alter URI scheme and with the did:alter form already written by the identity-attributed commits specification. The method introduces no new record, no new cryptographic primitive and no registry of its own: create, update and deactivate are the publication, replacement and revocation of that envelope, and read is its verification. The document also sets out what the method cannot yet do, because the envelope record it reads carries no key history, and revocation cannot presently be observed from DNS alone.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-morrison-did-alter-method/", "html": "https://datatracker.ietf.org/doc/html/draft-morrison-did-alter-method", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-morrison-did-alter-method" } }, { "name": "draft-morrison-consent-settlement", "title": "Consent-Bound Identity Disclosure with Subject Settlement for HTTP-Native Agent Payments", "rev": "07", "new": false, "revised": "2026-10-22T04:59:01Z", "found": "2026-10-22T05:47:08.111Z", "pages": 24, "group": "individual", "group_type": "individual", "submitter": "morrison", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.75, "topic": "security", "topic_label": "Security", "topic_confidence": 0.43, "kind": "informational", "kind_label": "informational / guidance", "kind_confidence": 0.6, "classifier": "jev-1.13.0", "abstract": "This memo specifies an extension to HTTP-native agent payment protocols by which the disclosure of an identity attribute about a human subject is bound to that subject's recorded consent and settled, in part, to that subject. When an agent pays to read an identity attribute about a person, the extension requires that the read carry a reference to a scoped, revocable consent grant issued by the subject, and it requires that the payment's settlement instruction name the subject as a beneficiary of a share of the read's price greater than the shares of all other parties combined. The extension composes above an identity-attestation envelope (which asserts who a credential is about) and above an HTTP-native payment flow (which moves value for the read); it adds the two functions neither layer provides: consent capture at disclosure time and settlement to the data subject. The wire additions are an advertisement in the server's payment-required response, a consent- grant reference echoed in the client's payment payload, and a settlement instruction enumerating subject beneficiary roles. The extension is settlement-network-agnostic and attestation-format- agnostic. The memo is Informational; the underlying COSE, CBOR and HTTP specifications are normative references, cited where used in the body of the document.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-morrison-consent-settlement/", "html": "https://datatracker.ietf.org/doc/html/draft-morrison-consent-settlement", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-morrison-consent-settlement" } }, { "name": "draft-morrison-identity-pronouns", "title": "Identity Pronouns: A Reference-Axis Extension to ~handle Identity Systems", "rev": "05", "new": false, "revised": "2026-10-22T04:58:30Z", "found": "2026-10-22T05:47:08.111Z", "pages": 13, "group": "individual", "group_type": "individual", "submitter": "morrison", "area": "int", "area_label": "INT", "area_source": "classifier", "area_confidence": 0.19, "topic": "dns", "topic_label": "DNS/naming", "topic_confidence": 0.66, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document defines an identity pronoun grammar as a reference axis orthogonal to the tier taxonomy that draft-morrison-identity- attributed-commits defines for the ~handle primitive of draft- morrison-mcp-dns-discovery. A pronoun is a session-scoped reference that resolves client-side to a concrete handle using local session state before any cryptographic, DNS, or federation operation. The tier taxonomy (Sovereign, Bot, Instrument) is unchanged; this specification introduces Absolute vs Pronoun as an orthogonal axis. A pronoun MUST NOT appear in a capability token, in a DNS record, in an Accord signature, or in any inter-organisational protocol payload. This document defines a single Wave-1 pronoun, ~org, that resolves to the concrete handle of the organisation bound to the caller's current session. An appendix defines a relative-path pronoun grammar (e.g. ~./finance, ~../compliance) as a non-normative design surface for future work. The mechanism is provider-neutral, introduces no new cryptographic primitive, and adds no load to DNS, capability-token issuers, or federated resolvers.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-morrison-identity-pronouns/", "html": "https://datatracker.ietf.org/doc/html/draft-morrison-identity-pronouns", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-morrison-identity-pronouns" } }, { "name": "draft-morrison-identity-attributed-commits", "title": "Identity-Attributed Git Commits via Tier-Structured Trailers", "rev": "04", "new": false, "revised": "2026-10-22T04:57:53Z", "found": "2026-10-22T05:47:08.111Z", "pages": 28, "group": "individual", "group_type": "individual", "submitter": "morrison", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.64, "topic": "security", "topic_label": "Security", "topic_confidence": 0.65, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document defines a git commit trailer grammar for identity- attributed contributions using the ~handle identity primitive defined in the MCP DNS discovery draft. The grammar binds sovereign actors, automated bots, and AI instruments to specific commits via three tier-structured trailers (Acted-By, Executed-By, Drafted-With) and three optional cryptographic trailers (Identity-Signature, Identity- Key-Id, Identity-Anchor). The signature is computed with Ed25519 over the commit's patch identifier, the value git patch-id derives from the change the commit makes, under a fixed domain-separation prefix. It therefore attests the change and not the resulting tree or the commit hash. A commit that carries the same change keeps a verifying signature across rebase onto an unrelated base, cherry- pick, and message amendment. A merge commit carries no signature, and a squash is a new change signed by whoever squashed it. Conformant parsers reject cross-tier category errors (e.g., an Instrument-tier handle in an Acted-By slot) as malformed. The mechanism is provider-neutral, depends only on DNS and the ~handle resolution algorithm of that draft, and requires no central authority or platform-specific verification service.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-morrison-identity-attributed-commits/", "html": "https://datatracker.ietf.org/doc/html/draft-morrison-identity-attributed-commits", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-morrison-identity-attributed-commits" } }, { "name": "draft-morrison-alter-uri-scheme", "title": "The 'alter' URI Scheme for Dispatchable ~handle References", "rev": "05", "new": false, "revised": "2026-10-22T04:57:02Z", "found": "2026-10-22T05:47:08.111Z", "pages": 23, "group": "individual", "group_type": "individual", "submitter": "morrison", "area": "art", "area_label": "ART", "area_source": "classifier", "area_confidence": 0.92, "topic": "dns", "topic_label": "DNS/naming", "topic_confidence": 0.64, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document defines the alter URI scheme as a dispatchable reference syntax for ~handle identity references published in the DNS records defined in the companion specification for discovering Model Context Protocol servers through DNS TXT records. An alter: URI binds a textual ~handle reference to a resolution and verification procedure that retrieves the handle's envelope from a publishing zone, validates the envelope's signature chain, and dispatches the result to an operating-system URI handler. The reference may be scoped to an organisation, narrowed to a named facet of the identity, and addressed to a typed action surface. The scheme is the addressing form of the ~handle@org:facet/action reference; its resolution semantics are those of that companion specification, reused without modification. The scheme is provider-neutral and introduces no new cryptographic primitive. A handler given an alter: URI verifies the handle's envelope before acting on it, and where the URI addresses an action, verification precedes any side effect. IANA provisionally registered the alter scheme under Section 4 of RFC 7595 on 5 October 2026.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-morrison-alter-uri-scheme/", "html": "https://datatracker.ietf.org/doc/html/draft-morrison-alter-uri-scheme", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-morrison-alter-uri-scheme" } }, { "name": "draft-morrison-mcp-dns-discovery", "title": "Discovery of Model Context Protocol Servers via DNS TXT Records", "rev": "09", "new": false, "revised": "2026-10-22T04:55:47Z", "found": "2026-10-22T05:47:08.111Z", "pages": 70, "group": "individual", "group_type": "individual", "submitter": "morrison", "area": "int", "area_label": "INT", "area_source": "classifier", "area_confidence": 0.82, "topic": "dns", "topic_label": "DNS/naming", "topic_confidence": 0.95, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document defines a DNS-based mechanism for discovering Model Context Protocol (MCP) servers, the identity of the organisations that operate them, and a cryptographic identity envelope bound to an individual Sovereign-tier ~handle published under the same zone. Three TXT records are defined. _mcp. advertises an MCP server's endpoint URL, agent protocol family, transport binding, cryptographic identity, and capability profile. _org-alter. advertises the operator's canonical organisational identity, including its legal entity, registry identifier, regions of operation, and any regulatory framework under which it must refuse external automated access. _alter. publishes an Ed25519-signed envelope binding a ~handle to a public key, an IdentityLog root reference, and a revocation commitment. DNSSEC validation is REQUIRED for the envelope record, and a DANE TLSA pin on the MCP endpoint is REQUIRED where resolving an envelope and opening an MCP session are one recognition transaction. The mechanism complements HTTPS-based discovery, and follows the precedent set by DKIM, SPF, DMARC, and MTA-STS. A companion alter: URI scheme is provisionally registered with IANA.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-morrison-mcp-dns-discovery/", "html": "https://datatracker.ietf.org/doc/html/draft-morrison-mcp-dns-discovery", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-morrison-mcp-dns-discovery" } }, { "name": "draft-nelson-agent-delegation-receipts", "title": "Agent Delegation Receipts", "rev": "15", "new": false, "revised": "2026-10-22T04:47:20Z", "found": "2026-10-22T05:47:08.111Z", "pages": 39, "group": "individual", "group_type": "individual", "submitter": "nelson", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 1, "topic": "security", "topic_label": "Security", "topic_confidence": 0.5, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document defines the Agent Delegation Receipt: a signed record of what a human principal authorized an AI agent to do, for how long, and under what instructions. The receipt carries a scope, hard boundaries, a validity window, and a hash of the operator's stated instructions, all signed by the authorizing key. Version -11 replaces the draft's earlier custom signature format with two standard profiles: a JWS profile (RFC 7515) over JCS-canonicalized JSON (RFC 8785) as the primary wire format, and a COSE_Sign1 profile (RFC 9052) for constrained environments. It also specifies scope attenuation rules for multi-agent delegation chains, a revocation registry model with cascade semantics, and the limitations of what receipts can and cannot prove. Version -12 resolves the unknown- fields question raised on the IETF oauth mailing list: authorization fields are closed (verifiers reject unknown top-level body fields rather than silently ignoring them), the \"metadata\" object is the defined extension point, and one-time-use receipts fail closed without a durable consumption store. Version -13 incorporates independent-implementation feedback: it pins the orchestratorSignature verification key to the sub-receipt signer's key, states the receipt-issuance computation order explicitly, and guides issuers on default boundaries versus explicit allowances. Version -14 adds a pointer to content profiles for verification of what the agent produced, following implementer feedback. Version -15 adopts the grant/execution vocabulary of [CHEN-AGENT-USE-CASES]: the receipt as Execution Layer Evidence for a Grant Layer Authority. It adds delegatee holder binding for sub-receipts -- a parent names the delegatee's public key, closing a bearer-copy issuance gap found in review -- deprecates orchestratorSignature as redundant, sketches an OAuth authorization_details binding so a token can reference its receipt, and states normative custody requirements for the authorizing key. The delegateeKey field is a wire-format addition; -14-era verifiers will reject receipts carrying it, which is the intended fail-closed version behavior.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-nelson-agent-delegation-receipts/", "html": "https://datatracker.ietf.org/doc/html/draft-nelson-agent-delegation-receipts", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-nelson-agent-delegation-receipts" } }, { "name": "draft-akiyama-cmg", "title": "Content-based IP-Multicast Grouping Framework for Real-time Spatial Sensing and Control Applications with Edge Computing", "rev": "04", "new": false, "revised": "2026-10-22T04:27:16Z", "found": "2026-10-22T04:47:06.922Z", "pages": 6, "group": "individual", "group_type": "individual", "submitter": "akiyama", "area": "rtg", "area_label": "RTG", "area_source": "classifier", "area_confidence": 0.85, "topic": "routing", "topic_label": "Routing", "topic_confidence": 0.82, "kind": "informational", "kind_label": "informational / guidance", "kind_confidence": 0.45, "classifier": "jev-1.13.0", "abstract": "This document describes a content-based multicast grouping framework aimed at simplifying routing control and reducing unnecessary traffic in large-scale networks for real-time spatial sensing and control applications. The framework introduces content-based multicast groups, which are managed at the local level by routers without the need for global group membership tracking. Additionally, a \"topic\" concept is introduced, allowing routers to manage multicast delivery based on data content. This framework reduces bandwidth consumption and simplifies multicast routing while offering flexible data delivery across various topics.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-akiyama-cmg/", "html": "https://datatracker.ietf.org/doc/html/draft-akiyama-cmg", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-akiyama-cmg" } }, { "name": "draft-ietf-stir-certificate-transparency", "title": "STI Certificate Transparency", "rev": "05", "new": false, "revised": "2026-10-22T03:25:57Z", "found": "2026-10-22T03:47:06.934Z", "pages": 16, "group": "stir", "group_type": "wg", "submitter": "stir", "area": "art", "area_label": "ART", "area_source": "datatracker", "area_confidence": 1, "topic": "security", "topic_label": "Security", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.47, "classifier": "jev-1.13.0", "abstract": "This document describes a framework for the use of the Certificate Transparency (CT) protocol for publicly logging the existence of Secure Telephone Identity (STI) certificates as they are issued or observed. This allows any interested party that is part of the STI ecosystem to audit STI certification authority (CA) activity and audit both the issuance of suspect certificates and the certificate logs themselves. The intent is to establish a level of trust within the STI ecosystem that relies on the verification of telephone numbers. This involves requiring STI certificates to be listed in an established log and refusing to honor those that are not. This effectively establishes the precedent that STI CAs must add all issued certificates to the logs and thus establishes unique association of STI certificates to an authorized provider or assignee of a telephone number resource. In the STI ecosystem, the primary role of CT is to provide verifiable trust by detecting the unauthorized issuance of duplicate telephone number level delegate certificates or provider level certificates. This provides a robust auditable mechanism for the detection of unauthorized creation of certificate credentials for illegitimate spoofing of telephone numbers or service provider codes (SPC). The framework borrows the log structure and API model from RFC6962 to enable public auditing and verifiability of certificate issuance. While the foundational mechanisms for log operation, Merkle Tree construction, and Signed Certificate Timestamps (SCTs) are aligned with RFC6962, this document contextualizes their application in the STIR ecosystem, focusing on verifiable control over telephone number or service provider code resources.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-stir-certificate-transparency/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-stir-certificate-transparency", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-stir-certificate-transparency" } }, { "name": "draft-eastlake-dnssd-rfc2931bis-sigzero", "title": "Domain Name System (DNS) Public Key Based Request and Transaction Authentication (SIGZERO, SIG(0))", "rev": "04", "new": false, "revised": "2026-10-22T02:32:13Z", "found": "2026-10-22T02:47:07.028Z", "pages": 32, "group": "individual", "group_type": "individual", "submitter": "eastlake", "area": "int", "area_label": "INT", "area_source": "classifier", "area_confidence": 0.93, "topic": "dns", "topic_label": "DNS/naming", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document specifies the SIGZERO and SIG(0) Domain Name System (DNS) Resource Records (RRs) which provide public key based authentication of DNS requests and transactions. SIGZERO is the RECOMMENDED option. This document obsoletes RFC 2931 and updates RFC 6891.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-eastlake-dnssd-rfc2931bis-sigzero/", "html": "https://datatracker.ietf.org/doc/html/draft-eastlake-dnssd-rfc2931bis-sigzero", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-eastlake-dnssd-rfc2931bis-sigzero" } }, { "name": "draft-liu-sidrops-ipfix-bgp-pov", "title": "Export of BGP Prefix Origin Validation in IP Flow Information Export (IPFIX)", "rev": "01", "new": false, "revised": "2026-10-22T02:14:07Z", "found": "2026-10-22T02:47:07.028Z", "pages": 8, "group": "individual", "group_type": "individual", "submitter": "liu", "area": "rtg", "area_label": "RTG", "area_source": "classifier", "area_confidence": 0.58, "topic": "netmgmt", "topic_label": "Net management", "topic_confidence": 0.91, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.96, "classifier": "jev-1.13.0", "abstract": "This document defines an IP Flow Information Export (IPFIX) Information Element for monitoring the state of Resource Public Key Infrastructure (RPKI) based BGP Prefix Origin Validation. The Information Element enables network operators to collect and analyze BGP route validation states (valid, invalid, not-found) to facilitate the detection of route origin hijacks and improve network observability and security.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-liu-sidrops-ipfix-bgp-pov/", "html": "https://datatracker.ietf.org/doc/html/draft-liu-sidrops-ipfix-bgp-pov", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-liu-sidrops-ipfix-bgp-pov" } }, { "name": "draft-fu-ipsecme-ikev2-fn-dsa-pkr", "title": "FN-DSA Signature Authentication in IKEv2 with Public Key Recovery Mode", "rev": "00", "new": true, "revised": "2026-10-22T01:37:59Z", "found": "2026-10-22T01:47:07.012Z", "pages": 16, "group": "individual", "group_type": "individual", "submitter": "fu", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 1, "topic": "security", "topic_label": "Security", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document specifies FN-DSA for signature authentication in the Internet Key Exchange Protocol Version 2 (IKEv2). It defines Public Key Recovery Mode (PKR-Mode), an extension that exploits the public key recovery property of FN-DSA, which reduces authentication payload size and enables certificateless authentication at the responder.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-fu-ipsecme-ikev2-fn-dsa-pkr/", "html": "https://datatracker.ietf.org/doc/html/draft-fu-ipsecme-ikev2-fn-dsa-pkr", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-fu-ipsecme-ikev2-fn-dsa-pkr" } }, { "name": "draft-pitta-portoles-lisp-evpn-interconnect", "title": "Decoupled Interconnection of LISP and EVPN VXLAN Domains", "rev": "00", "new": true, "revised": "2026-10-22T00:03:09Z", "found": "2026-10-22T00:47:06.988Z", "pages": 19, "group": "individual", "group_type": "individual", "submitter": "pitta", "area": "rtg", "area_label": "RTG", "area_source": "classifier", "area_confidence": 0.9, "topic": "routing", "topic_label": "Routing", "topic_confidence": 0.53, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.51, "classifier": "jev-1.13.0", "abstract": "This document describes decoupled Layer 2 and Layer 3 interconnection services between a LISP-based VXLAN domain and a BGP EVPN-based VXLAN domain. The LISP-facing border and EVPN Gateway are implemented on separate devices. The Layer 2 service extends a bridge domain through an Ethernet handoff, with independent MAC reachability and broadcast, unknown-unicast, and multicast forwarding in each overlay. The Layer 3 service uses tenant IP transit and prefix exchange through an Interior Gateway Protocol (IGP) or eBGP, with ordinary route redistribution at each border between the transit and its own overlay control plane. IP subnet layouts are deployment considerations; they do not define the service. Subnet-prefix exchange and additional requirements for optional routed connectivity within a common IP prefix are discussed.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-pitta-portoles-lisp-evpn-interconnect/", "html": "https://datatracker.ietf.org/doc/html/draft-pitta-portoles-lisp-evpn-interconnect", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-pitta-portoles-lisp-evpn-interconnect" } }, { "name": "draft-mcguinness-oauth-mission", "title": "Mission-Bound Authorization for OAuth 2.0", "rev": "01", "new": false, "revised": "2026-10-21T23:45:00Z", "found": "2026-10-21T23:47:06.988Z", "pages": 178, "group": "individual", "group_type": "individual", "submitter": "mcguinness", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 1, "topic": "security", "topic_label": "Security", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "OAuth 2.0 has authorization grants and access tokens but no standard object that binds an approved task, such as one an AI agent performs on a user's behalf, to the authority approved for it and governs the tokens later issued under that authority. This document defines that object for OAuth 2.0: a Mission. A client submits, through Pushed Authorization Requests, a Mission Intent describing the task it will perform. The authorization server derives Rich Authorization Requests authorization details from it, binds the approved task and that authority to the Approver's consent through integrity anchors, and records a durable Mission. Every access token issued under the Mission carries a subset of the approved authority and a \"mission\" claim, and every issuance is gated on the Mission's lifecycle state. Revoking a Mission stops further issuance; it does not recall tokens already issued, which a resource server that enforces from the token alone can continue to honor until they expire. Optional capabilities represent delegation among agents with the OAuth Actor Profile and, as specified by a companion, let a single Mission be honored across trust domains. Runtime enforcement of each action is a separate, optional layer.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-mcguinness-oauth-mission/", "html": "https://datatracker.ietf.org/doc/html/draft-mcguinness-oauth-mission", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-mcguinness-oauth-mission" } }, { "name": "draft-santesson-oidc-cert-auth-context", "title": "Certificate Authentication Context Type for OpenID Connect", "rev": "01", "new": false, "revised": "2026-10-21T23:16:24Z", "found": "2026-10-21T23:47:06.988Z", "pages": 20, "group": "individual", "group_type": "individual", "submitter": "santesson", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 1, "topic": "security", "topic_label": "Security", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "RFC 7773 defines the Authentication Context certificate extension, which carries information about how the subject of an X.509 certificate was authenticated when the certificate was issued. RFC 7773 defines one context information type, for subjects authenticated by means of a Security Assertion Markup Language (SAML) assertion. This document defines a second context information type for subjects authenticated by means of OpenID Connect, where the identity information is obtained from an ID Token, where applicable in combination with a UserInfo Response. The information is expressed as a JSON object and provides the OpenID Connect counterpart to the SAML Authentication Context Information defined in RFC 7773. This document also updates RFC 7773 by clarifying that an application processing the extension ignores context information types it does not support regardless of the criticality of the extension, and by recommending that the extension not be marked critical.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-santesson-oidc-cert-auth-context/", "html": "https://datatracker.ietf.org/doc/html/draft-santesson-oidc-cert-auth-context", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-santesson-oidc-cert-auth-context" } }, { "name": "draft-manelidis-dnsop-domain-affiliation", "title": "Domain Affiliation Confirmation (DAC)", "rev": "00", "new": true, "revised": "2026-10-21T22:49:57Z", "found": "2026-10-21T23:47:06.988Z", "pages": 46, "group": "individual", "group_type": "individual", "submitter": "manelidis", "area": "int", "area_label": "INT", "area_source": "classifier", "area_confidence": 0.65, "topic": "dns", "topic_label": "DNS/naming", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.95, "classifier": "jev-1.13.0", "abstract": "Security systems assess domain names one at a time. A new domain of an established organization therefore starts with no reputation, and a legitimate domain that resembles another organization's name can be reported as an impersonation. This document defines Domain Affiliation Confirmation (DAC), by which the operator of a parent domain confirms that a child domain is operated by it or under its authority. The child publishes a DNS record naming the parent and a random token; the parent confirms that token, in the DNS or over HTTPS, by naming the child. Verification takes at most three DNS queries. The parent publishes no list of its domains, and an affiliation is ended by deleting one record. The document also states what a confirmation means to relying parties such as takedown services and reputation systems.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-manelidis-dnsop-domain-affiliation/", "html": "https://datatracker.ietf.org/doc/html/draft-manelidis-dnsop-domain-affiliation", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-manelidis-dnsop-domain-affiliation" } }, { "name": "draft-gerber-oauth-client-metadata-lookup", "title": "OAuth Client Metadata Lookup", "rev": "00", "new": true, "revised": "2026-10-21T21:55:39Z", "found": "2026-10-21T22:47:07.405Z", "pages": 11, "group": "individual", "group_type": "individual", "submitter": "gerber", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 1, "topic": "security", "topic_label": "Security", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document defines an OAuth endpoint for retrieving a public subset of a client's effective configuration at an authorization server, including applied defaults. It enables clients to check that their configuration is accepted by an authorization server before an authorization attempt. It also enables authorization servers to progressively roll out features to their client base. While the endpoint chiefly serves Client ID Metadata Document clients, it can also be used by clients registered through other means.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-gerber-oauth-client-metadata-lookup/", "html": "https://datatracker.ietf.org/doc/html/draft-gerber-oauth-client-metadata-lookup", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-gerber-oauth-client-metadata-lookup" } }, { "name": "draft-ietf-ippm-stamp-ext-hdr", "title": "Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Reflecting STAMP Packet IP Headers", "rev": "22", "new": false, "revised": "2026-10-21T21:52:08Z", "found": "2026-10-21T01:47:07.539Z", "pages": 35, "group": "ippm", "group_type": "wg", "submitter": "ippm", "area": "ops", "area_label": "OPS", "area_source": "datatracker", "area_confidence": 1, "topic": "measurement", "topic_label": "Measurement/OAM", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "The Simple Two-Way Active Measurement Protocol (STAMP) and its optional extensions can be used for Edge-to-Edge (E2E) active measurements. In Situ Operations, Administration, and Maintenance (IOAM) data fields can be used for recording and collecting hop-by- hop and E2E operational and telemetry information. This document extends STAMP to reflect IPv4/IPv6 headers as well as IPv6 extension headers for hop-by-hop and E2E active measurements, for example, using the IOAM data fields. This document updates RFC 8762 by specifying IPv4/IPv6 and UDP headers handling, UDP checksum handling, session state notifications, and rate limiting requirements that also apply to STAMP sessions not using these extensions.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp-ext-hdr/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-ext-hdr", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-ippm-stamp-ext-hdr" } }, { "name": "draft-rosomakho-lamps-mldsa-mlkem-seed-only", "title": "Deprecating Expanded ML-DSA and ML-KEM Private Key Encodings", "rev": "00", "new": true, "revised": "2026-10-21T21:31:25Z", "found": "2026-10-21T21:47:07.848Z", "pages": 6, "group": "individual", "group_type": "individual", "submitter": "rosomakho", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 1, "topic": "security", "topic_label": "Security", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.96, "classifier": "jev-1.13.0", "abstract": "This document updates RFC 9881 and RFC 9935 to require the seed representation when encoding Module-Lattice-Based Digital Signature Algorithm (ML-DSA) and Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) private keys for interchange. It deprecates the expanded and combined representations, while permitting their continued support for legacy imports. These changes simplify implementation and improve interoperability by aligning the private- key representation with that used by JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE). Internal private-key representations are unaffected.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-rosomakho-lamps-mldsa-mlkem-seed-only/", "html": "https://datatracker.ietf.org/doc/html/draft-rosomakho-lamps-mldsa-mlkem-seed-only", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-rosomakho-lamps-mldsa-mlkem-seed-only" } }, { "name": "draft-rosomakho-httpbis-tunnels-signatures", "title": "Authenticating HTTP Tunnels with HTTP Message Signatures", "rev": "00", "new": true, "revised": "2026-10-21T20:59:17Z", "found": "2026-10-21T21:47:07.848Z", "pages": 19, "group": "individual", "group_type": "individual", "submitter": "rosomakho", "area": "wit", "area_label": "WIT", "area_source": "classifier", "area_confidence": 0.94, "topic": "web", "topic_label": "Web/HTTP", "topic_confidence": 0.5, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document specifies client authentication for HTTP tunnel establishment using HTTP Message Signatures. It covers the CONNECT method, extended CONNECT in HTTP/2 and HTTP/3, and HTTP/1.1 Upgrade. It defines signature coverage and replay protection using either a client-generated nonce or a server-provided nonce obtained through an Accept-Signature challenge.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-rosomakho-httpbis-tunnels-signatures/", "html": "https://datatracker.ietf.org/doc/html/draft-rosomakho-httpbis-tunnels-signatures", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-rosomakho-httpbis-tunnels-signatures" } }, { "name": "draft-gopal-pim-pfm-pre-join-subtlv", "title": "PIM Flooding Mechanism Pre-join Sub-TLV", "rev": "00", "new": true, "revised": "2026-10-21T19:18:32Z", "found": "2026-10-21T19:47:09.866Z", "pages": 6, "group": "individual", "group_type": "individual", "submitter": "gopal", "area": "rtg", "area_label": "RTG", "area_source": "classifier", "area_confidence": 0.98, "topic": "routing", "topic_label": "Routing", "topic_confidence": 0.97, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "The PIM Flooding Mechanism and Source Discovery (PFM-SD) extension enables PIM routers to announce active multicast sources. The Group Source Info (GSI) TLV extends PFM-SD by allowing Sub-TLVs to be included with a source announcement. This document defines the Pre-join Sub-TLV, which carries the PIM Router-ID of a router selected by the First-Hop Router (FHR). The selected router can establish multicast forwarding state before data arrives, reducing join latency.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-gopal-pim-pfm-pre-join-subtlv/", "html": "https://datatracker.ietf.org/doc/html/draft-gopal-pim-pfm-pre-join-subtlv", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-gopal-pim-pfm-pre-join-subtlv" } }, { "name": "draft-ietf-ipsecme-encrypted-esp-ping", "title": "ESP Echo Protocol", "rev": "04", "new": false, "revised": "2026-10-21T19:08:45Z", "found": "2026-10-21T19:47:09.866Z", "pages": 16, "group": "ipsecme", "group_type": "wg", "submitter": "ipsecme", "area": "sec", "area_label": "SEC", "area_source": "datatracker", "area_confidence": 1, "topic": "security", "topic_label": "Security", "topic_confidence": 0.88, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document defines the ESP Echo Protocol, an extension to the ESP AGGFRAG protocol [RFC9347] that provides an Echo Request and Echo Reply mechanism for IP Security (IPsec) link diagnostics. It enables endpoints to assess end-to-end path reachability, and it defines probe packets that can be used for path Maximum Transmission Unit (MTU) discovery, using Encapsulating Security Payload (ESP) packets. The protocol supports two modes of operation: an encrypted mode used over established IPsec Security Associations (SAs), with an option to specify a preferred reply path when multiple SAs exist between the peers, and an unencrypted mode used outside the context of a negotiated ESP SA. In addition to bidirectional echo probing, the protocol supports sending one-way ESP packets without eliciting a reply, primarily for keepalives, NAT and firewall pinhole maintenance, and unidirectional link diagnostics. A peer can announce support for ESP Echo using a new IKEv2 Status Notification ESP_ECHO_SUPPORTED.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-ipsecme-encrypted-esp-ping/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-encrypted-esp-ping", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-ipsecme-encrypted-esp-ping" } }, { "name": "draft-acee-lsr-ospfv3-deprecate-ah", "title": "Deprecation of the IPsec Authentication Header (AH) for OSPFv3 Authentication", "rev": "02", "new": false, "revised": "2026-10-21T18:50:13Z", "found": "2026-10-21T19:47:09.866Z", "pages": 7, "group": "individual", "group_type": "individual", "submitter": "acee", "area": "rtg", "area_label": "RTG", "area_source": "classifier", "area_confidence": 1, "topic": "routing", "topic_label": "Routing", "topic_confidence": 0.78, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.52, "classifier": "jev-1.13.0", "abstract": "RFC 4552 specifies the use of the IPsec Authentication Header (AH) and the Encapsulating Security Payload (ESP) to provide authentication and confidentiality for OSPFv3. This document deprecates the use of AH for OSPFv3 and updates RFC 4552 accordingly. Operators are encouraged to use either ESP with NULL encryption, as specified in RFC 4552, or the OSPFv3 Authentication Trailer, as specified in RFC 7166.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-acee-lsr-ospfv3-deprecate-ah/", "html": "https://datatracker.ietf.org/doc/html/draft-acee-lsr-ospfv3-deprecate-ah", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-acee-lsr-ospfv3-deprecate-ah" } }, { "name": "draft-ietf-dkim-dkim2-dns", "title": "Domain Name Specification for DKIM2", "rev": "02", "new": false, "revised": "2026-10-21T18:42:59Z", "found": "2026-10-21T18:47:09.223Z", "pages": 16, "group": "dkim", "group_type": "wg", "submitter": "dkim", "area": "art", "area_label": "ART", "area_source": "datatracker", "area_confidence": 1, "topic": "email", "topic_label": "Email/messaging", "topic_confidence": 0.95, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "The updated DomainKeys Identified Mail (DKIM2) permits an organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message through a digital signature. This is done by publishing to Domain Name Service (DNS) of the domain a public key that is then associated to the domain and where messages can be signed by the corresponding private key. Assertion of responsibility is validated through a cryptographic signature and by querying the Signer's domain directly to retrieve the appropriate public key. This document describes DKIM2 DNS record format and how to find the record.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-dkim-dkim2-dns/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-dkim-dkim2-dns", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-dkim-dkim2-dns" } }, { "name": "draft-bertoldi-regext-rdap-reliability-scoring", "title": "RDAP Extension for Structured Reliability Assessment Metadata", "rev": "05", "new": false, "revised": "2026-10-21T16:39:16Z", "found": "2026-10-21T16:47:08.741Z", "pages": 51, "group": "individual", "group_type": "individual", "submitter": "bertoldi", "area": "int", "area_label": "INT", "area_source": "classifier", "area_confidence": 0.36, "topic": "dns", "topic_label": "DNS/naming", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document defines an extension to the Registration Data Access Protocol (RDAP) that enables the representation and exchange of structured reliability assessment metadata for registrars and domain names. The extension defines a structured assessment envelope through which an RDAP server can expose assessment results produced by a registry, registrar, or third-party assessor in a common, machine-readable format within RDAP responses. The extension standardizes how assessment results are transported and referenced, not how they are computed. Scoring methodologies, thresholds, criteria, and governance frameworks are intentionally left to the operational and policy layer. This document does, however, place requirements on the specification of any scheme whose results are intended for publication through RDAP, because publishing an evaluative judgement about an identified party without safeguards for notification, remediation, and contestation is not a safe practice.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-bertoldi-regext-rdap-reliability-scoring/", "html": "https://datatracker.ietf.org/doc/html/draft-bertoldi-regext-rdap-reliability-scoring", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-bertoldi-regext-rdap-reliability-scoring" } }, { "name": "draft-ietf-avtcore-rtp-sframe", "title": "RTP Payload Format for SFrame", "rev": "03", "new": false, "revised": "2026-10-21T16:22:48Z", "found": "2026-10-21T16:47:08.741Z", "pages": 22, "group": "avtcore", "group_type": "wg", "submitter": "avtcore", "area": "wit", "area_label": "WIT", "area_source": "datatracker", "area_confidence": 1, "topic": "realtime", "topic_label": "Real-time media", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document describes the RTP payload format of SFrame, its use in SDP, and per stream key derivation.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-sframe/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-sframe", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-avtcore-rtp-sframe" } }, { "name": "draft-ietf-dmarc-arc-to-historic", "title": "Reclassifying ARC as Historic", "rev": "01", "new": false, "revised": "2026-10-21T15:26:42Z", "found": "2026-10-21T15:47:10.678Z", "pages": 9, "group": "dmarc", "group_type": "wg", "submitter": "dmarc", "area": "art", "area_label": "ART", "area_source": "datatracker", "area_confidence": 1, "topic": "email", "topic_label": "Email/messaging", "topic_confidence": 1, "kind": "informational", "kind_label": "informational / guidance", "kind_confidence": 0.65, "classifier": "jev-1.13.0", "abstract": "This document calls for a conclusion to the experiment defined by “The Authenticated Received Chain (ARC) Protocol” [RFC8617], and recommends that ARC no longer be deployed or relied upon between disparate senders and receivers. The document summarizes what ARC set out to do, reports on operational experience, and explains how the experience gained during the experiment is being incorporated into the proposed DKIM2 work as the successor to DomainKeys Identified Mail [RFC6376]. To avoid any future confusion, it is therefore requested that ARC [RFC8617] be reclassified as “Historic”.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-to-historic/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-arc-to-historic", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-dmarc-arc-to-historic" } }, { "name": "draft-watts-agent-continuity-evidence", "title": "Continuity Evidence Records for Delegated Agent Systems", "rev": "00", "new": true, "revised": "2026-10-21T15:19:13Z", "found": "2026-10-21T15:47:10.678Z", "pages": 10, "group": "individual", "group_type": "individual", "submitter": "watts", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.95, "topic": "ai", "topic_label": "AI/agents", "topic_confidence": 0.84, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.41, "classifier": "jev-1.13.0", "abstract": "This document proposes an experimental, signed JSON statement and verification model for observing computational-agent continuity across sessions, instances and delegations. It distinguishes model, runtime, agent, grant and execution identifiers, retains predecessor evidence, and produces three-valued verification outcomes. Integrity of a record never implies permission to perform an action. This is not an OAuth token format or a claim of standardized identity ontology.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-watts-agent-continuity-evidence/", "html": "https://datatracker.ietf.org/doc/html/draft-watts-agent-continuity-evidence", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-watts-agent-continuity-evidence" } }, { "name": "draft-watts-scientific-admissibility", "title": "Scientific Admissibility Evidence Records: A Research Data Exchange Proposal", "rev": "00", "new": true, "revised": "2026-10-21T15:18:59Z", "found": "2026-10-21T15:47:10.678Z", "pages": 2, "group": "individual", "group_type": "individual", "submitter": "watts", "area": "other", "area_label": "Other", "area_source": "classifier", "area_confidence": 0.78, "topic": "other", "topic_label": "Other", "topic_confidence": 0.9, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.39, "classifier": "jev-1.13.0", "abstract": "This document proposes interoperable evidence record fields for reproducible research workflows. It is an independent working draft and is not an IETF publication or standard.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-watts-scientific-admissibility/", "html": "https://datatracker.ietf.org/doc/html/draft-watts-scientific-admissibility", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-watts-scientific-admissibility" } }, { "name": "draft-watts-scientific-evidence-admissibility", "title": "Scientific Evidence Registry and Admissibility Metadata for Reproducible Research", "rev": "00", "new": true, "revised": "2026-10-21T15:18:49Z", "found": "2026-10-21T15:47:10.678Z", "pages": 5, "group": "individual", "group_type": "individual", "submitter": "watts", "area": "other", "area_label": "Other", "area_source": "classifier", "area_confidence": 0.37, "topic": "process", "topic_label": "Process", "topic_confidence": 0.45, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.51, "classifier": "jev-1.13.0", "abstract": "This document describes a proposed interoperable metadata record for scientific evidence, test calibration, falsification, provenance, and release classification. It distinguishes machine-verifiable integrity from scientific validity, ownership, and authorization. The design is a proposal and does not assert Internet standards consensus, new physical discoveries, or a completed patent review.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-watts-scientific-evidence-admissibility/", "html": "https://datatracker.ietf.org/doc/html/draft-watts-scientific-evidence-admissibility", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-watts-scientific-evidence-admissibility" } }, { "name": "draft-watts-research-evidence-envelope", "title": "Research Evidence Envelope: A Provenance-Oriented Interchange Record", "rev": "00", "new": true, "revised": "2026-10-21T15:18:19Z", "found": "2026-10-21T15:47:10.678Z", "pages": 4, "group": "individual", "group_type": "individual", "submitter": "watts", "area": "other", "area_label": "Other", "area_source": "classifier", "area_confidence": 0.49, "topic": "other", "topic_label": "Other", "topic_confidence": 0.9, "kind": "informational", "kind_label": "informational / guidance", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This informational scaffold sketches a versioned record for tracking scientific claims, source provenance, evidence classes, uncertainty, falsifiers, replication procedures, and artifact hashes. It is not an IETF standard, has not undergone IETF review, and does not define a wire protocol.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-watts-research-evidence-envelope/", "html": "https://datatracker.ietf.org/doc/html/draft-watts-research-evidence-envelope", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-watts-research-evidence-envelope" } }, { "name": "draft-watts-protocol-test-evidence-profile", "title": "Protocol Conformance Test Evidence Records: A Reproducibility Profile", "rev": "00", "new": true, "revised": "2026-10-21T15:18:10Z", "found": "2026-10-21T15:47:10.678Z", "pages": 7, "group": "individual", "group_type": "individual", "submitter": "watts", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.9, "topic": "security", "topic_label": "Security", "topic_confidence": 0.32, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.36, "classifier": "jev-1.13.0", "abstract": "This document proposes a narrow record profile for describing software protocol-conformance test runs, including the tested artifact, test suite, implementation, execution environment, individual case outcomes, digests, and known limitations. It does not define a new signature scheme, attestation architecture, transparency service, or general-purpose test-output language. Implementations are encouraged to reuse existing mechanisms such as SCITT statements, RATS terminology, COSE, JSON canonicalization, and existing test-report formats where suitable. This individual draft candidate has not been submitted to or endorsed by the IETF.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-watts-protocol-test-evidence-profile/", "html": "https://datatracker.ietf.org/doc/html/draft-watts-protocol-test-evidence-profile", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-watts-protocol-test-evidence-profile" } }, { "name": "draft-watts-rats-verification-promotion-appraisal", "title": "Verification Promotion and Agent Assurance Appraisal Profile", "rev": "00", "new": true, "revised": "2026-10-21T15:17:55Z", "found": "2026-10-21T15:47:10.678Z", "pages": 7, "group": "individual", "group_type": "individual", "submitter": "watts", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.92, "topic": "iot", "topic_label": "IoT", "topic_confidence": 0.97, "kind": "informational", "kind_label": "informational / guidance", "kind_confidence": 0.81, "classifier": "jev-1.13.0", "abstract": "This document maps protocol-verification evidence and the WIVL assurance-stage model onto the RATS architecture. It defines appraisal requirements for SPEC_VALIDATED, LOCAL_CONFORMANT, INDEPENDENTLY_REPRODUCED, and SECURITY_TESTED results while preserving unknown evidence and requiring arithmetic preconditions for mathematical test vectors. An attestation result reports bounded assurance; it is not an authorization grant or production-release decision.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-watts-rats-verification-promotion-appraisal/", "html": "https://datatracker.ietf.org/doc/html/draft-watts-rats-verification-promotion-appraisal", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-watts-rats-verification-promotion-appraisal" } }, { "name": "draft-watts-research-evidence-bundle", "title": "A Research Evidence Bundle JSON Envelope for Provenance and Replication Metadata", "rev": "00", "new": true, "revised": "2026-10-21T15:17:39Z", "found": "2026-10-21T15:47:10.678Z", "pages": 6, "group": "individual", "group_type": "individual", "submitter": "watts", "area": "irtf", "area_label": "IRTF", "area_source": "classifier", "area_confidence": 0.4, "topic": "other", "topic_label": "Other", "topic_confidence": 0.93, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.39, "classifier": "jev-1.13.0", "abstract": "This document proposes an early-stage JSON envelope for exchanging research-evidence records containing claim status, evidence tier, source provenance, methods, falsifiers, replication status, artifact digests, and privacy review. It is an individual design proposal, not an IETF consensus document. Its intended contribution must be assessed against existing provenance and research-packaging specifications before further standardization work.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-watts-research-evidence-bundle/", "html": "https://datatracker.ietf.org/doc/html/draft-watts-research-evidence-bundle", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-watts-research-evidence-bundle" } }, { "name": "draft-ietf-dtn-echo-service", "title": "BPv7 Echo Service", "rev": "00", "new": true, "revised": "2026-10-21T14:57:17Z", "found": "2026-10-21T15:47:10.678Z", "pages": 23, "group": "dtn", "group_type": "wg", "submitter": "dtn", "area": "int", "area_label": "INT", "area_source": "datatracker", "area_confidence": 1, "topic": "measurement", "topic_label": "Measurement/OAM", "topic_confidence": 0.93, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document specifies an echo service for Bundle Protocol Version 7 (BPv7) networks. An echo service receives bundles at a well-known endpoint and replies to each with a response bundle that returns the payload to the originator. This enables round-trip time measurement and end-to-end connectivity verification in Delay-Tolerant Networks. This document requests IANA allocation of a well-known IPN service number for the echo service.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-dtn-echo-service/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-dtn-echo-service", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-dtn-echo-service" } }, { "name": "draft-saez-xcim", "title": "eXplicit Consent-Identified Mail (XCIM)", "rev": "03", "new": false, "revised": "2026-10-21T14:16:49Z", "found": "2026-10-21T14:47:10.032Z", "pages": 30, "group": "individual", "group_type": "individual", "submitter": "saez", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.93, "topic": "email", "topic_label": "Email/messaging", "topic_confidence": 0.59, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "XCIM specifies evidence that a party controlling an email address explicitly consented to receive defined types of communication from an identified sender. A trusted third-party Consent Attester verifies address control, observes a separate affirmative decision, and signs an attestation binding the recipient, sender, and agreed types. Blockchain anchoring provides immutable evidence of the attestation under an admitted finality policy. Authenticated lifecycle events and fresh status distinguish the historical decision from current consent. XCIM concerns the consent relationship independently of individual email messages. It does not sign, inspect, classify, or authenticate their content. A receiving email service may use verified current consent as a positive policy signal after independently establishing the sender identity relevant to its query. This document defines a portable consent object format and verification contract, together with requirements for separately admitted blockchain adapters. It does not select a universal blockchain network or claim operational readiness.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-saez-xcim/", "html": "https://datatracker.ietf.org/doc/html/draft-saez-xcim", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-saez-xcim" } }, { "name": "draft-bless-rtgwg-kira", "title": "Kademlia-directed ID-based Routing Architecture (KIRA)", "rev": "06", "new": false, "revised": "2026-10-21T13:44:14Z", "found": "2026-10-21T07:47:08.396Z", "pages": 60, "group": "individual", "group_type": "individual", "submitter": "bless", "area": "rtg", "area_label": "RTG", "area_source": "classifier", "area_confidence": 1, "topic": "routing", "topic_label": "Routing", "topic_confidence": 1, "kind": "informational", "kind_label": "informational / guidance", "kind_confidence": 0.71, "classifier": "jev-1.13.0", "abstract": "This document describes the Kademlia-directed ID-based Routing Architecture KIRA. KIRA is a scalable zero-touch distributed routing solution that is tailored to control planes. It prioritizes scalable and resilient connectivity over route efficiency (stretched paths are accepted as trade-off against routing protocol overhead). KIRA's self-assigned, topologically independent IDs can be embedded into IPv6 addresses. Combined with further self-organization mechanisms from Kademlia, KIRA achieves a zero-touch solution that provides scalable IPv6 connectivity without requiring any manual configuration. For example, it can connect hundreds of thousands of routers and devices in a single network without requiring any form of hierarchy (like areas). It works well in various topologies and is loop-free even during convergence. This self-contained solution, and especially the independence from any manual configuration, make it suitable as a resilient base for all management and control tasks, allowing the network to recover from the most complex failure scenarios. The architecture consists of the ID-based network layer routing protocol R²/Kad in its Routing Tier (using source routing) and a PathID-based Forwarding Tier (using PathIDs as labels for paths). KIRA’s tightly integrated add-on services (e.g., name resolution as well as fast and efficient topology discovery) provide a perfect basis for autonomic network management solutions.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-bless-rtgwg-kira/", "html": "https://datatracker.ietf.org/doc/html/draft-bless-rtgwg-kira", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-bless-rtgwg-kira" } }, { "name": "draft-cummings-hypr", "title": "HyPR: Hybrid Parity for Remote Resilience", "rev": "00", "new": true, "revised": "2026-10-21T11:34:26Z", "found": "2026-10-21T11:47:08.173Z", "pages": 22, "group": "individual", "group_type": "individual", "submitter": "cummings", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.51, "topic": "other", "topic_label": "Other", "topic_confidence": 0.48, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "Local redundancy mechanisms such as RAID and software-defined parity pools tolerate only a bounded number of correlated device losses, while remote backup services typically require replication of the full data set. HyPR's remote storage requirement scales with the parity-to-data ratio m/k rather than with the size of the protected data, at the cost of not protecting against total loss of the local copy. This document specifies HyPR (Hybrid Parity for Remote Resilience), a framework that treats remote storage, including consumer-grade end-to-end-encrypted cloud services, as additional failure-domain participants in an erasure-coded storage system. HyPR defines a content-chunked Remote Parity Fragment format, transport requirements for backend-agnostic encrypted fragment delivery, immutable and versioned vault semantics, a resumable reconstruction protocol that produces signed rebuild receipts, and a boundary within which machine-learned orchestration agents may advise but never replace deterministic reconstruction.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-cummings-hypr/", "html": "https://datatracker.ietf.org/doc/html/draft-cummings-hypr", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-cummings-hypr" } }, { "name": "draft-ietf-snac-simple", "title": "Automatically Connecting Stub Networks to Unmanaged Infrastructure", "rev": "13", "new": false, "revised": "2026-10-21T11:11:52Z", "found": "2026-10-21T11:47:08.173Z", "pages": 63, "group": "snac", "group_type": "wg", "submitter": "snac", "area": "int", "area_label": "INT", "area_source": "datatracker", "area_confidence": 1, "topic": "ip", "topic_label": "IP/addressing", "topic_confidence": 0.79, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.75, "classifier": "jev-1.13.0", "abstract": "This document specifies a set of practices for using IPv6 networking to automatically connect stub networks to adjacent infrastructure networks, even if they do not otherwise use IPv6. This is applicable in cases such as constrained (Internet of Things) networks where there is a need to provide functional parity of service discovery and reachability between devices on the stub network and devices on an adjacent infrastructure link (for example, a home network).", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-snac-simple/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-snac-simple", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-snac-simple" } }, { "name": "draft-ietf-sidrops-rtr-yang", "title": "YANG Data Model for RPKI to Router Protocol", "rev": "13", "new": false, "revised": "2026-10-21T09:44:06Z", "found": "2026-10-21T09:47:07.723Z", "pages": 57, "group": "sidrops", "group_type": "wg", "submitter": "sidrops", "area": "ops", "area_label": "OPS", "area_source": "datatracker", "area_confidence": 1, "topic": "netmgmt", "topic_label": "Net management", "topic_confidence": 0.95, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document defines YANG data models for managing Resource Public Key Infrastructure (RPKI) to Router Protocol (RFC6810 and RFC8210).", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-sidrops-rtr-yang/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rtr-yang", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-sidrops-rtr-yang" } }, { "name": "draft-zhao-rtgwg-agentic-systems", "title": "A Framework for Network- and Compute-Aware Cross-Domain Agentic Systems", "rev": "00", "new": true, "revised": "2026-10-21T09:32:38Z", "found": "2026-10-21T09:47:07.723Z", "pages": 22, "group": "individual", "group_type": "individual", "submitter": "zhao", "area": "rtg", "area_label": "RTG", "area_source": "classifier", "area_confidence": 0.94, "topic": "ai", "topic_label": "AI/agents", "topic_confidence": 0.97, "kind": "informational", "kind_label": "informational / guidance", "kind_confidence": 0.99, "classifier": "jev-1.13.0", "abstract": "Agentic systems can carry out tasks using agents, model services, data services, tools, and computing environments distributed across sites and administrative domains. Dependencies among these components create communication and computing requirements that may evolve during execution. Whether a proposed collaboration can satisfy those requirements depends on network connectivity and performance, computing capacity and readiness, data and model locality, and the policies governing resource use and data movement. This document describes a framework for cross-domain agentic collaboration that accounts for task dependencies and the network and computing conditions affecting communication and execution. It outlines the roles and interactions of agents and their runtimes, infrastructure information functions, and resource-management functions. The framework relates task dependencies to communication and computing requirements, with consideration of execution locations, data movement, and constraints spanning dependent activities. It discusses the use of appropriately scoped domain information to assess alternative combinations of agents, services, and tools, together with the abstraction and updating of that information under partial visibility and independent domain policies. The framework also addresses adaptation to evolving dependencies and infrastructure conditions, including information overhead and the stability of decisions in large agent populations.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-zhao-rtgwg-agentic-systems/", "html": "https://datatracker.ietf.org/doc/html/draft-zhao-rtgwg-agentic-systems", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-zhao-rtgwg-agentic-systems" } }, { "name": "draft-ni-a2a-ai-agent-security-requirements", "title": "Security Requirements for AI Agents", "rev": "02", "new": false, "revised": "2026-10-21T09:16:09Z", "found": "2026-10-21T09:47:07.723Z", "pages": 15, "group": "individual", "group_type": "individual", "submitter": "ni", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.98, "topic": "ai", "topic_label": "AI/agents", "topic_confidence": 0.79, "kind": "requirements", "kind_label": "requirements / use cases", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document discusses security requirements for AI agents, covering different stages of security interactions. These include provisioning, registration, discovery, cross-domain interconnection, and access control.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ni-a2a-ai-agent-security-requirements/", "html": "https://datatracker.ietf.org/doc/html/draft-ni-a2a-ai-agent-security-requirements", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ni-a2a-ai-agent-security-requirements" } }, { "name": "draft-ietf-pim-multipath-igmpmldproxy", "title": "Multipath Support for IGMP/MLD Proxy", "rev": "05", "new": false, "revised": "2026-10-21T09:04:00Z", "found": "2026-10-21T09:47:07.723Z", "pages": 12, "group": "pim", "group_type": "wg", "submitter": "pim", "area": "rtg", "area_label": "RTG", "area_source": "datatracker", "area_confidence": 1, "topic": "routing", "topic_label": "Routing", "topic_confidence": 0.56, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.97, "classifier": "jev-1.13.0", "abstract": "This document specifies the framework to support multipath reception in Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD) proxy devices. The proposed mechanism allows IGMP/ MLD proxy devices to receive multicast sessions/channels through different upstream interfaces. It defines static configuration methods for associating upstream interfaces with channel identifiers and interface priority values. A mechanism for upstream interface takeover that enables switching from an inactive to active upstream interface is also described.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-pim-multipath-igmpmldproxy/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-pim-multipath-igmpmldproxy", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-pim-multipath-igmpmldproxy" } }, { "name": "draft-intra-handshake-fail", "title": "Early Attestation Considered Very Harmful", "rev": "56", "new": false, "revised": "2026-10-21T09:00:19Z", "found": "2026-10-21T09:47:07.723Z", "pages": 79, "group": "individual", "group_type": "individual", "submitter": "intra", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 1, "topic": "security", "topic_label": "Security", "topic_confidence": 0.86, "kind": "informational", "kind_label": "informational / guidance", "kind_confidence": 0.99, "classifier": "jev-1.13.0", "abstract": "The draft aims to provide technical details of [CVE-2026-100833] of CVSS 9.6, [CVE-2026-108265] of CVSS 9.1, [CVE-2026-108266] of CVSS 9.1, [CVE-2026-108267] of CVSS 9.1, [CVE-2026-108268] of CVSS 9.1, [CVE-2026-108269] of CVSS 9.1, [CVE-2026-100835] of CVSS 9.1, [CVE-2026-92701] of CVSS 9.1, [CVE-2026-92702] of CVSS 9.1, [CVE-2026-108362] of CVSS 9.1, [CVE-2026-33697] of CVSS 7.5, [CVE-2026-108361] of CVSS 7.2, and several GitHub Security Advisories (GHSAs) in the process of getting CVE IDs, which provide substantial technical evidence of how early attestation fails in practice, even *without physical access* to the desired machine. Moreover, since continuous attestation is generally required [CSA-eBPF] [MITRE-Continuous-Attestation], early attestation adds *unnecessary complexity*. The results are backed by the research [Intra-handshake.fail], [TLS-RA], [EarlyAttestationBleed] and the artifacts [Intra-handshake.fail-repo] in state-of-the-art formal analysis tool, ProVerif, under Apache-2.0 license for reproducibility, extensibility, and review, and have been acknowledged by the relevant stakeholders. Currently, there are *one CVE of CVSS 9.6, nine CVEs of CVSS 9.1, one CVE of CVSS 8.2, one CVE of CVSS 7.5, one CVE of CVSS 7.2, and several GHSAs published awaiting CVE IDs against the broader early attestation covering all layers of the ecosystem up to the application*. The research papers on these are currently either under submission or being prepared for submission. The artifacts of these papers will be shared with the community under Apache-2.0 license for reproducibility, extensibility, and review. Based on our work, all except two implementations of early attestation have been archived, withdrawn, or moved to post-handshake attestation. In our analysis [Intra-handshake.fail-repo] and [ID-Crisis-repo], the remaining two implementations of early attestation -- Edgeless Systems Contrast and Meta's AI -- remain vulnerable. We recommend users of these two implementations to carefully evaluate their systems and understand the risks. If you are aware of any open-source implementation of early attestation that is not yet covered in this draft, please let us know to responsibly disclose the vulnerabilities to them.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-intra-handshake-fail/", "html": "https://datatracker.ietf.org/doc/html/draft-intra-handshake-fail", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-intra-handshake-fail" } }, { "name": "draft-sharif-openid-agent-identity", "title": "OpenID Connect Agent Identity Claims for Autonomous AI Agents", "rev": "02", "new": false, "revised": "2026-10-21T08:54:41Z", "found": "2026-10-21T09:47:07.723Z", "pages": 3, "group": "individual", "group_type": "individual", "submitter": "sharif", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 1, "topic": "security", "topic_label": "Security", "topic_confidence": 0.85, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This specification defines a profile of OpenID Connect Core 1.0 that enables Identity Providers (IdPs) to issue identity tokens for autonomous software agents. It introduces a set of standard claims for representing agent identity, ownership, trust posture, authorised capabilities, and compliance screening status within OpenID Connect ID Tokens. The profile is designed to operate within existing OpenID Connect infrastructure without requiring modifications to the core protocol. It defines how Relying Parties (RPs) validate agent tokens and enforce graduated access controls based on agent trust levels and sanctions screening results.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-sharif-openid-agent-identity/", "html": "https://datatracker.ietf.org/doc/html/draft-sharif-openid-agent-identity", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-sharif-openid-agent-identity" } }, { "name": "draft-cmcc-tcp-sro", "title": "The Session Identifier Option (SIO)", "rev": "03", "new": false, "revised": "2026-10-21T07:48:48Z", "found": "2026-10-21T08:47:09.164Z", "pages": 15, "group": "individual", "group_type": "individual", "submitter": "cmcc", "area": "wit", "area_label": "WIT", "area_source": "classifier", "area_confidence": 0.98, "topic": "transport", "topic_label": "Transport", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document defines the Session Identifier Option (SIO), carried as a TCP option for TCP connections and as a UDP option for UDP datagrams. The option lets the endpoints of a connection or flow publish identifiers at the transport layer, where network functions on the path - load balancers, NAT gateways, firewalls - can read them without per-flow state and without payload inspection. Network functions of all kinds can benefit from it: session recovery in load- balancing and NAT clusters, stateless forwarding, connection-tracking recovery, and telemetry. The option adds only a few octets, and only to the packets that carry it; which packets carry it is a deployment choice. Endpoints that do not support it behave as if the option did not exist.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-cmcc-tcp-sro/", "html": "https://datatracker.ietf.org/doc/html/draft-cmcc-tcp-sro", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-cmcc-tcp-sro" } }, { "name": "draft-cmcc-asrp", "title": "Available Session Recovery Protocol", "rev": "09", "new": false, "revised": "2026-10-21T07:48:26Z", "found": "2026-10-21T08:47:09.164Z", "pages": 32, "group": "individual", "group_type": "individual", "submitter": "cmcc", "area": "int", "area_label": "INT", "area_source": "classifier", "area_confidence": 0.34, "topic": "cloud", "topic_label": "Cloud/DC", "topic_confidence": 0.99, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.99, "classifier": "jev-1.13.0", "abstract": "This document describes an experimental protocol, the Available Session Recovery Protocol (ASRP), for high-availability clusters that provide stateful network services - load balancing, Network Address Translation (NAT [RFC4787]), and other layer-4 stateful network functions, including their virtualized (NFV) forms. ASRP backs up the session state at the session's own endpoints, so that the cluster nodes hold no replicated state: no inter-node synchronization, no backup node, and no state warm-up for a newly added node. The document defines the procedures and message formats for session backup and recovery. In contrast to traditional high-availability techniques that back up session state within the cluster itself, the core innovation of ASRP lies in its distributed backup of state information to the client or server side. This approach offers multiple advantages: theoretically unlimited elastic scaling capacity; support for rapid recovery from multi-point failures; reduction of resource redundancy through the elimination of centralized backup nodes; and significant simplification of cluster implementation complexity. The ASRP protocol provides a standardized method for constructing elastic service clusters, facilitating broader participation from software and hardware developers in building elastic cloud network service clusters.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-cmcc-asrp/", "html": "https://datatracker.ietf.org/doc/html/draft-cmcc-asrp", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-cmcc-asrp" } }, { "name": "draft-ietf-anima-network-service-auto-deployment", "title": "An Intent-based Framework of Network Services Autonomic Deployment and Management", "rev": "08", "new": false, "revised": "2026-10-21T07:32:58Z", "found": "2026-10-21T07:47:08.396Z", "pages": 13, "group": "anima", "group_type": "wg", "submitter": "anima", "area": "ops", "area_label": "OPS", "area_source": "datatracker", "area_confidence": 1, "topic": "netmgmt", "topic_label": "Net management", "topic_confidence": 1, "kind": "informational", "kind_label": "informational / guidance", "kind_confidence": 0.69, "classifier": "jev-1.13.0", "abstract": "This document introduces an intent-based framework for network services autonomic deployment and management. It autonomically deploys network services that require customized combinations of network resources and dynamically manages these resources throughout their lifecycle. The framework leverages the GeneRic Autonomic Signaling Protocol (GRASP) to facilitate the dynamic exchange of resource management signals among autonomic nodes, thereby enabling coordinated and consistent operations within an autonomic network domain. This framework is generic and applicable to most types of network resources.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-anima-network-service-auto-deployment/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-anima-network-service-auto-deployment", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-anima-network-service-auto-deployment" } }, { "name": "draft-matsukami-intarea-ipv45", "title": "IPv4.5: A Locator/Identifier-Separated Extension to IPv4 with Post-Quantum Session Security", "rev": "00", "new": true, "revised": "2026-10-21T07:09:05Z", "found": "2026-10-21T07:47:08.396Z", "pages": 32, "group": "individual", "group_type": "individual", "submitter": "matsukami", "area": "int", "area_label": "INT", "area_source": "classifier", "area_confidence": 1, "topic": "ip", "topic_label": "IP/addressing", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "The global IPv4 address space was exhausted at the IANA level in 2011, and Carrier-Grade NAT (CGN) has since served as the primary operational workaround. CGN preserves connectivity but violates the end-to-end principle, complicates application development, and introduces substantial operational overhead. This document specifies IPv4.5, a pragmatic extension of IPv4 that introduces a 96-bit address space organized as a Locator/Identifier separation: a 32-bit IPv4 Locator, a 16-bit Site Identifier, and a 48-bit Endpoint Identifier. IPv4.5 packets are encapsulated in UDP (port 4242) for transparent transit through existing IPv4 routers, NAT devices, and firewalls without requiring infrastructure changes. Session security is established through a hybrid post-quantum key exchange combining ML-KEM-768 [FIPS203] and X25519 [RFC7748], performed once per session. Subsequent data protection uses symmetric AEAD ciphers (AES-256-GCM or ChaCha20-Poly1305). The design enforces strict separation of concerns across four independent planes: data, control, identity, and cryptographic. Higher-level functions such as semantic routing and self-sovereign identity are explicitly out of scope for this specification.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-matsukami-intarea-ipv45/", "html": "https://datatracker.ietf.org/doc/html/draft-matsukami-intarea-ipv45", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-matsukami-intarea-ipv45" } }, { "name": "draft-feng-nmrg-ain-deployment", "title": "Agentic Intent Network (AIN): Applicability and Deployment Scenarios", "rev": "00", "new": true, "revised": "2026-10-21T07:09:04Z", "found": "2026-10-21T07:47:08.396Z", "pages": 15, "group": "individual", "group_type": "individual", "submitter": "feng", "area": "rtg", "area_label": "RTG", "area_source": "classifier", "area_confidence": 0.42, "topic": "ai", "topic_label": "AI/agents", "topic_confidence": 0.85, "kind": "informational", "kind_label": "informational / guidance", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "The Agentic Intent Network (AIN) architecture defines a routing-based coordination substrate for open, heterogeneous, Internet-scale multi- agent systems. This document describes applicability and deployment scenarios for AIN, targeting decision-makers in carrier networks, enterprises, and network equipment vendors. It maps the technical mechanisms defined in [AIN-ARCH] to concrete operational contexts, describes migration paths from existing infrastructure, and discusses the cold-start bootstrapping challenge inherent to network-effect- dependent systems. This document does not define new protocol mechanisms; it is intended to inform deployment planning and expand the AIN reader community beyond protocol engineers.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-feng-nmrg-ain-deployment/", "html": "https://datatracker.ietf.org/doc/html/draft-feng-nmrg-ain-deployment", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-feng-nmrg-ain-deployment" } }, { "name": "draft-ye-ippm-switching-efficiency", "title": "Switching Efficiency: A Metric Framework for AI Data Center Networks", "rev": "02", "new": false, "revised": "2026-10-21T07:09:04Z", "found": "2026-10-21T07:47:08.396Z", "pages": 13, "group": "individual", "group_type": "individual", "submitter": "ye", "area": "ops", "area_label": "OPS", "area_source": "classifier", "area_confidence": 0.76, "topic": "measurement", "topic_label": "Measurement/OAM", "topic_confidence": 0.81, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.56, "classifier": "jev-1.13.0", "abstract": "This document specifies the Switching Efficiency Framework, a measurement methodology designed to evaluate network efficiency in AI Data Centers (AIDCs). Conventional network metrics, such as bandwidth utilization or network throughput, fail to directly link network activity to computational progress, as they cannot distinguish computationally effective data that directly advances neural network computing from the redundant traffic induced by both multi-hop forwarding and the algorithmic overhead of collective operations. To address this, this document defines the Switching Efficiency Framework, a measurement methodology for evaluating AIDC network efficiency. The core metric, Switching Efficiency, quantifies the computationally effective data throughput delivered per unit of provisioned switching capacity. To facilitate precise diagnostic analysis, the framework further decomposes this core metric into three fine-grained factors: Data Efficiency, Routing Efficiency, and Port Utilization. This framework provides metrics that can help operators identify communication bottlenecks and evaluate topology-traffic alignment.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ye-ippm-switching-efficiency/", "html": "https://datatracker.ietf.org/doc/html/draft-ye-ippm-switching-efficiency", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ye-ippm-switching-efficiency" } }, { "name": "draft-mahy-mimi-msgid-aad", "title": "Conveying the More Instant Messaging Interoperability Message ID in Messaging Layer Security Additional Authenticated Data", "rev": "02", "new": false, "revised": "2026-10-21T07:09:03Z", "found": "2026-10-21T07:47:08.396Z", "pages": 4, "group": "individual", "group_type": "individual", "submitter": "mahy", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.98, "topic": "security", "topic_label": "Security", "topic_confidence": 0.98, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "The More Instant Messaging Interoperability (MIMI) content format defines a MIMI Message ID, communicated only to members of the Messaging Layer Security (MLS) group in which the message was sent. This document defines a way to share a Message ID in the MLS Additional Authenticated Data (AAD) so it is visible to MIMI providers.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-mahy-mimi-msgid-aad/", "html": "https://datatracker.ietf.org/doc/html/draft-mahy-mimi-msgid-aad", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-mahy-mimi-msgid-aad" } }, { "name": "draft-mahy-mls-new-content-types", "title": "New Content Types for Messaging Layer Security (MLS)", "rev": "01", "new": false, "revised": "2026-10-21T07:09:03Z", "found": "2026-10-21T07:47:08.396Z", "pages": 9, "group": "individual", "group_type": "individual", "submitter": "mahy", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.99, "topic": "security", "topic_label": "Security", "topic_confidence": 0.99, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This Messaging Layer Security (MLS) extension adds two new variations of the application content type, each with a separate key ratchet. It also creates an MLS capability to negotiate use of the new types, and an IANA registry to register additional content types.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-mahy-mls-new-content-types/", "html": "https://datatracker.ietf.org/doc/html/draft-mahy-mls-new-content-types", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-mahy-mls-new-content-types" } }, { "name": "draft-mahy-mls-semiprivatemessage", "title": "Semi-Private Messages in the Messaging Layer Security (MLS) Protocol", "rev": "07", "new": false, "revised": "2026-10-21T07:09:02Z", "found": "2026-10-21T07:47:08.396Z", "pages": 10, "group": "individual", "group_type": "individual", "submitter": "mahy", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.99, "topic": "security", "topic_label": "Security", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document defines a SemiPrivateMessage for the Messaging Layer Security (MLS) protocol. It allows members to share otherwise private commits and proposals with a designated list of external receivers rather than send these handshakes in a PublicMessage.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-mahy-mls-semiprivatemessage/", "html": "https://datatracker.ietf.org/doc/html/draft-mahy-mls-semiprivatemessage", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-mahy-mls-semiprivatemessage" } }, { "name": "draft-bashandy-rtgwg-segment-routing-uloop", "title": "Loop avoidance using Segment Routing", "rev": "18", "new": false, "revised": "2026-10-21T07:09:01Z", "found": "2026-10-21T07:47:08.396Z", "pages": 7, "group": "individual", "group_type": "individual", "submitter": "bashandy", "area": "rtg", "area_label": "RTG", "area_source": "classifier", "area_confidence": 1, "topic": "routing", "topic_label": "Routing", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.96, "classifier": "jev-1.13.0", "abstract": "This document presents a mechanism aimed at providing loop avoidance in the case of IGP network convergence event. The solution relies on the temporary use of SR policies ensuring loop-freeness over the post-convergence paths from the converging node to the destination.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-bashandy-rtgwg-segment-routing-uloop/", "html": "https://datatracker.ietf.org/doc/html/draft-bashandy-rtgwg-segment-routing-uloop", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-bashandy-rtgwg-segment-routing-uloop" } }, { "name": "draft-ietf-jmap-filenode", "title": "JMAP File Storage extension", "rev": "18", "new": false, "revised": "2026-10-21T06:20:27Z", "found": "2026-10-21T06:47:06.930Z", "pages": 43, "group": "jmap", "group_type": "wg", "submitter": "jmap", "area": "art", "area_label": "ART", "area_source": "datatracker", "area_confidence": 1, "topic": "email", "topic_label": "Email/messaging", "topic_confidence": 0.99, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "The JMAP base protocol (RFC8620) provides the ability to upload and download arbitrary binary data. This binary data is called a \"blob\", and can be used in all other JMAP extensions. This extension adds a method to expose blobs as a filesystem along with the types of metadata that are provided by other remote filesystem protocols.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-jmap-filenode/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-jmap-filenode", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-jmap-filenode" } }, { "name": "draft-ietf-lsr-l2-bundle-member-remote-id", "title": "Advertisement of Remote Interface Identifiers for Layer 2 Bundle Members", "rev": "10", "new": false, "revised": "2026-10-21T05:46:59Z", "found": "2026-10-21T05:47:06.721Z", "pages": 18, "group": "lsr", "group_type": "wg", "submitter": "lsr", "area": "rtg", "area_label": "RTG", "area_source": "datatracker", "area_confidence": 1, "topic": "routing", "topic_label": "Routing", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "In networks where Layer 2 (L2) interface bundles (such as a Link Aggregation Group (LAG) as defined in IEEE 802.1AX) are deployed, a controller may need to collect the connectivity relationships between bundle members for traffic engineering (TE) purposes. This document describes how Open Shortest Path First (OSPF) and Intermediate System to Intermediate System (IS-IS) advertise the remote interface identifiers for L2 bundle members. The corresponding extension of BGP Link State (BGP-LS) is also specified.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-lsr-l2-bundle-member-remote-id/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-lsr-l2-bundle-member-remote-id", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-lsr-l2-bundle-member-remote-id" } }, { "name": "draft-srivastava-learnlog", "title": "Learnlog Assistance Capture Profile and Optional Event File Representation", "rev": "03", "new": false, "revised": "2026-10-21T05:13:29Z", "found": "2026-10-21T05:47:06.721Z", "pages": 78, "group": "individual", "group_type": "individual", "submitter": "srivastava", "area": "irtf", "area_label": "IRTF", "area_source": "classifier", "area_confidence": 0.35, "topic": "ai", "topic_label": "AI/agents", "topic_confidence": 0.93, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.55, "classifier": "jev-1.13.0", "abstract": "This document proposes Learnlog as an assistance capture profile for measuring AI scaffolding, with xAPI and Caliper bindings. Its motivation is Quantum Learning Machines' work on QLM Measure. The profile defines what assistance was requested, offered, generated, transmitted, displayed, or accepted; what an instrument captured; which facts remain unknown; and which assertions were observed, self- reported, or inferred. Existing logging ecosystems can carry these definitions. Their reviewed base specifications do not, by themselves, require this particular combined agreement on assistance, achieved capture, unavailable information, and mapping provenance. Existing AI and tutoring profiles already cover important parts of the domain. For discussion, the document also proposes event families beyond assistance, among them prediction, revision, recall after a delay, stated confidence, and agency. The document retains the existing Learnlog event file representation, hash chains, optional signed heads, and verifiable redaction as an optional carrier. An implementation can use the assistance profile without producing that file representation. Experimental companion software constructs importer-observation records in xAPI and Caliper while preserving source assistance assertions separately. The implementation does not establish independent interoperability, truthful or complete capture, independent learning, or scientific equivalence across products. The core file format is unchanged in this revision.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-srivastava-learnlog/", "html": "https://datatracker.ietf.org/doc/html/draft-srivastava-learnlog", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-srivastava-learnlog" } }, { "name": "draft-ietf-teas-rsvp-hmac-sha2", "title": "RSVP Cryptographic Authentication with HMAC-SHA2", "rev": "03", "new": false, "revised": "2026-10-21T03:23:49Z", "found": "2026-10-21T03:47:06.596Z", "pages": 12, "group": "teas", "group_type": "wg", "submitter": "teas", "area": "rtg", "area_label": "RTG", "area_source": "datatracker", "area_confidence": 1, "topic": "security", "topic_label": "Security", "topic_confidence": 0.84, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document specifies the use of the US NIST Secure Hash Standard in the Hashed Message Authentication Code (HMAC) mode with RSVP Cryptographic Authentication version 2. Along with draft-ietf-teas- rsvp-auth-v2, this document obsoletes RFC2747 and RFC3097.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-hmac-sha2/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-teas-rsvp-hmac-sha2", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-teas-rsvp-hmac-sha2" } }, { "name": "draft-zhang-dawn-agent-discovery-framework", "title": "A Framework for Agent Discovery in DAWN", "rev": "09", "new": false, "revised": "2026-10-21T02:34:02Z", "found": "2026-10-21T02:47:07.815Z", "pages": 37, "group": "individual", "group_type": "individual", "submitter": "zhang", "area": "int", "area_label": "INT", "area_source": "classifier", "area_confidence": 0.97, "topic": "dns", "topic_label": "DNS/naming", "topic_confidence": 0.56, "kind": "informational", "kind_label": "informational / guidance", "kind_confidence": 0.97, "classifier": "jev-1.13.0", "abstract": "This document describes a two-layer reference architecture for discovering the minimum public information needed to reach AI agents. The Local Discovery Plane obtains discovery information within an administrative domain through mDNS/DNS-SD or infrastructure-assisted discovery. For cross-domain discovery, the Federation Plane uses publication of policy-approved information in authoritative DNS zones and on-demand resolution as its baseline; Federation Gateways apply export policy and validate and cache accepted results. The document also identifies optional functions that may complement this baseline where DNS publication and request-driven resolution do not meet deployment needs: recipient-specific sharing, proactive or multi-hop dissemination, and trusted aggregated directory queries. In mixed- mode deployments, DNS may bootstrap an endpoint that provides one of these additional functions.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-zhang-dawn-agent-discovery-framework/", "html": "https://datatracker.ietf.org/doc/html/draft-zhang-dawn-agent-discovery-framework", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-zhang-dawn-agent-discovery-framework" } }, { "name": "draft-dat-session-cache-control", "title": "The 'session' Cache-Control Response Directive", "rev": "00", "new": true, "revised": "2026-10-21T02:14:05Z", "found": "2026-10-21T02:47:07.815Z", "pages": 7, "group": "individual", "group_type": "individual", "submitter": "dat", "area": "wit", "area_label": "WIT", "area_source": "classifier", "area_confidence": 0.93, "topic": "web", "topic_label": "Web/HTTP", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document defines a new HTTP Cache-Control response directive, \"session\", which specifies that a response may be cached only for the lifetime of the user agent's current browsing context. The directive enables ephemeral, non-persistent, and non-shared caching behavior suitable for modern web applications. The \"session\" directive is backward compatible with existing HTTP caches and is ignored by implementations that do not recognize it.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-dat-session-cache-control/", "html": "https://datatracker.ietf.org/doc/html/draft-dat-session-cache-control", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-dat-session-cache-control" } }, { "name": "draft-ietf-ppm-dap", "title": "Distributed Aggregation Protocol for Privacy Preserving Measurement", "rev": "20", "new": false, "revised": "2026-10-21T01:02:46Z", "found": "2026-10-21T01:47:07.539Z", "pages": 124, "group": "ppm", "group_type": "wg", "submitter": "ppm", "area": "sec", "area_label": "SEC", "area_source": "datatracker", "area_confidence": 1, "topic": "security", "topic_label": "Security", "topic_confidence": 0.83, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "There are many situations in which it is desirable to take measurements of data which people consider sensitive. In these cases, the entity taking the measurement is usually not interested in people's individual responses but rather in aggregated data. Conventional methods require collecting individual responses and then aggregating them on some server, thus representing a threat to user privacy and rendering many such measurements difficult and impractical. This document describes a multi-party Distributed Aggregation Protocol (DAP) for privacy preserving measurement which can be used to collect aggregate data without revealing any individual contributor's data.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-ppm-dap/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-ppm-dap", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-ppm-dap" } }, { "name": "draft-ietf-bier-ospfv3-extensions", "title": "OSPFv3 Extensions for BIER", "rev": "11", "new": false, "revised": "2026-10-21T00:48:04Z", "found": "2026-10-21T01:47:07.539Z", "pages": 11, "group": "bier", "group_type": "wg", "submitter": "bier", "area": "rtg", "area_label": "RTG", "area_source": "datatracker", "area_confidence": 1, "topic": "routing", "topic_label": "Routing", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "Bit Index Explicit Replication (BIER) is an architecture that provides multicast forwarding through a \"BIER domain\" without requiring intermediate routers to maintain multicast related per-flow state. The BIER architecture uses MPLS or other encapsulations to steer the multicast traffic towards the receivers. This document describes the OSPFv3 protocol extensions required for BIER with MPLS encapsulation. Support for other encapsulation types is outside the scope of this document.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-bier-ospfv3-extensions/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-bier-ospfv3-extensions", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-bier-ospfv3-extensions" } }, { "name": "draft-rashid-pecorella-6lo-lowpan-padding-length", "title": "6LoWPAN Payload Length Handling with L2 Padding", "rev": "01", "new": false, "revised": "2026-10-21T00:32:27Z", "found": "2026-10-21T00:47:08.060Z", "pages": 14, "group": "individual", "group_type": "individual", "submitter": "rashid", "area": "int", "area_label": "INT", "area_source": "classifier", "area_confidence": 1, "topic": "iot", "topic_label": "IoT", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "6LoWPAN compression schemes, including legacy HC1 [RFC4944], modern IPHC [RFC6282], and GHC [RFC7400], elide the IPv6 Payload Length (PL) field from compressed packets, relying on the Layer 2 (L2) Length of the Data field to reconstruct it at the receiver. This assumption holds for IEEE 802.15.4 [IEEE Std 802.15.4], which delivers exactly the bytes transmitted. However, L2 technologies that enforce a minimum frame size — most notably Ethernet IEEE 802.3 [IEEE Std 802.3], which has a minimum payload of 46 bytes — silently pad short frames with zero bytes. In such cases, the receiver incorrectly reconstructs the IPv6 PL field, leading to packet corruption and protocol failure. This document describes the problem, analyzes existing workarounds, and defines a solution based on an Escape dispatch byte (ESC) or ESC Extension Type (EET) extended dispatch mechanism that explicitly encodes the IPv6 PL when L2 padding may be present.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-rashid-pecorella-6lo-lowpan-padding-length/", "html": "https://datatracker.ietf.org/doc/html/draft-rashid-pecorella-6lo-lowpan-padding-length", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-rashid-pecorella-6lo-lowpan-padding-length" } }, { "name": "draft-ahuja-agent-routing-policy", "title": "A Policy Grammar for Inter-Domain Agent Routing", "rev": "03", "new": false, "revised": "2026-10-21T00:06:44Z", "found": "2026-10-21T00:47:08.060Z", "pages": 19, "group": "individual", "group_type": "individual", "submitter": "ahuja", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.36, "topic": "ai", "topic_label": "AI/agents", "topic_confidence": 0.84, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.87, "classifier": "jev-1.13.0", "abstract": "Agent tasks are delegated across organizational boundaries. Existing work specifies how agents are identified, discovered, and described, states requirements for cross-domain isolation and authorization, and identifies the absence of a mechanism for 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 party establishes by observing the whole chain. Whether independently chosen policies converge is analysed in separate work.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ahuja-agent-routing-policy/", "html": "https://datatracker.ietf.org/doc/html/draft-ahuja-agent-routing-policy", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ahuja-agent-routing-policy" } }, { "name": "draft-ietf-rats-epoch-markers", "title": "Epoch Markers", "rev": "06", "new": false, "revised": "2026-10-20T23:40:02Z", "found": "2026-10-20T23:47:08.193Z", "pages": 32, "group": "rats", "group_type": "wg", "submitter": "rats", "area": "sec", "area_label": "SEC", "area_source": "datatracker", "area_confidence": 1, "topic": "iot", "topic_label": "IoT", "topic_confidence": 0.95, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document defines Epoch Markers as a means to establish a notion of freshness among actors in a distributed system. Epoch Markers are similar to \"time ticks\" and are produced and distributed by a dedicated system known as the Epoch Bell. Systems receiving Epoch Markers do not need to track freshness using their own understanding of time (e.g., via a local real-time clock). Instead, the reception of a specific Epoch Marker establishes a new epoch that is shared among all recipients. This document defines Epoch Marker types, including CBOR time tags, RFC 3161 TimeStampToken, and nonce-like structures. It also defines a CWT Claim to embed Epoch Markers in RFC 8392 CBOR Web Tokens, which serve as vehicles for signed protocol messages. Finally, it registers RATS Conceptual Message Wrapper (CMW) Indicators for Epoch ID and Nonce.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-rats-epoch-markers/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-rats-epoch-markers", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-rats-epoch-markers" } }, { "name": "draft-ietf-jose-pq-composite-sigs", "title": "PQ/T Hybrid Composite Signatures for JOSE and COSE", "rev": "06", "new": false, "revised": "2026-10-20T21:20:43Z", "found": "2026-10-20T21:47:07.256Z", "pages": 109, "group": "jose", "group_type": "wg", "submitter": "jose", "area": "sec", "area_label": "SEC", "area_source": "datatracker", "area_confidence": 1, "topic": "security", "topic_label": "Security", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document describes JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) serializations for Post- Quantum Traditional (PQ/T) hybrid composite signatures. The composite algorithms described combine the Module-Lattice-Based Digital Signature Algorithm (ML-DSA) as the post-quantum component and either the Elliptic Curve Digital Signature Algorithm (ECDSA) or the Edwards-Curve Digital Signature Algorithm (EdDSA) as the traditional component.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-jose-pq-composite-sigs/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-jose-pq-composite-sigs", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-jose-pq-composite-sigs" } }, { "name": "draft-mih-zhang-agent-disclosure-bundle", "title": "AAC Evidence Bundle", "rev": "01", "new": false, "revised": "2026-10-20T21:18:15Z", "found": "2026-10-20T21:47:07.256Z", "pages": 27, "group": "individual", "group_type": "individual", "submitter": "mih", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.75, "topic": "ai", "topic_label": "AI/agents", "topic_confidence": 0.89, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.97, "classifier": "jev-1.13.0", "abstract": "This document defines the AAC Evidence Bundle, a portable presentation and verification container for an Agent Action Capsule and the records that make its evidentiary claim intelligible. A permalink carries a bundle in its URL fragment, an offline HTML report carries a bundle in its shell, and a hosted report serves a bundle at its URL. The bundle does not alter any enclosed Capsule. It declares its citation closure and any missing cited records, carries verified disclosure preimages as a bundle-level overlay, separates three different completeness claims, and permits independently specified extension blocks and countersignatures: signatures by a party other than the producer over the bundle digest, each accompanied by a statement of which claims that party recomputed and with what result.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-mih-zhang-agent-disclosure-bundle/", "html": "https://datatracker.ietf.org/doc/html/draft-mih-zhang-agent-disclosure-bundle", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-mih-zhang-agent-disclosure-bundle" } }, { "name": "draft-hanley-rsdggs", "title": "Regulatory Spectrum Discrete Global Grid System (RSDGGS)", "rev": "00", "new": true, "revised": "2026-10-20T20:58:07Z", "found": "2026-10-20T21:47:07.256Z", "pages": 122, "group": "individual", "group_type": "individual", "submitter": "hanley", "area": "int", "area_label": "INT", "area_source": "classifier", "area_confidence": 0.4, "topic": "wireless", "topic_label": "Wireless/satellite", "topic_confidence": 0.63, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.97, "classifier": "jev-1.13.0", "abstract": "This document defines the Regulatory Spectrum Discrete Global Grid System (RSDGGS), a hierarchical geographic indexing scheme designed to encode the regulatory jurisdiction applicable to Industrial, Scientific, and Medical (ISM) radio band usage at any location on Earth. RSDGGS represents geographic location as a variable-length byte array of 1 to 8 octets. The length of the array implicitly encodes the spatial resolution of the index, eliminating the need for an explicit resolution field. Truncation of the array yields a coarser representation, enabling privacy-preserving location compaction without loss of structural integrity. The grid is rooted in a spherical dodecahedron whose twelve pentagonal faces are aligned to approximate the three ITU Radio Regions, with face indices 1, 2, and 3 corresponding directly to ITU Regions 1, 2, and 3 respectively. Each face is recursively subdivided using a hierarchy of isosceles golden gnomon triangles, with 2-bit child indices packed into successive octets. The system supports both fixed IoT deployments for automated regulatory provisioning during manufacturing and mobile IoT devices that acquire regulatory context through GPS, tethered devices, or peer-assisted discovery. A beacon mechanism is defined whereby location-aware devices broadcast their RSDGGS index within ISM band transmissions, enabling location-unaware peers to derive applicable regulatory parameters including frequency allocation, power limits, duty cycle, dwell interval, channelization, and permitted modulation.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-hanley-rsdggs/", "html": "https://datatracker.ietf.org/doc/html/draft-hanley-rsdggs", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-hanley-rsdggs" } }, { "name": "draft-ietf-core-yang-metadata", "title": "Representing metadata annotations in YANG-CBOR", "rev": "01", "new": false, "revised": "2026-10-20T20:30:40Z", "found": "2026-10-20T20:47:07.736Z", "pages": 11, "group": "core", "group_type": "wg", "submitter": "core", "area": "wit", "area_label": "WIT", "area_source": "datatracker", "area_confidence": 1, "topic": "netmgmt", "topic_label": "Net management", "topic_confidence": 0.96, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This specification defines the representation of metadata annotations (RFC 7952) in YANG-CBOR (RFC 9254). It updates RFC 9595 to add a separate namespace enabling the representation of SIDs for metadata annotations in the \".sid\" files defined there.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-core-yang-metadata/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-core-yang-metadata", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-core-yang-metadata" } }, { "name": "draft-saez-xcim", "title": "eXplicit Consent-Identified Mail (XCIM)", "rev": "02", "new": false, "revised": "2026-10-20T19:43:28Z", "found": "2026-10-20T16:54:28.031Z", "pages": 22, "group": "individual", "group_type": "individual", "submitter": "saez", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.92, "topic": "email", "topic_label": "Email/messaging", "topic_confidence": 0.67, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "XCIM specifies evidence that a party controlling an email address explicitly consented to receive defined types of communication from an identified sender. A trusted third-party Consent Attester verifies address control, observes a separate affirmative decision, and signs an attestation binding the recipient, sender, and agreed types. Blockchain anchoring provides immutable evidence of the attestation under an admitted finality policy. Authenticated lifecycle events and fresh status distinguish the historical decision from current consent. XCIM concerns the consent relationship independently of individual email messages. It does not sign, inspect, classify, or authenticate their content. A receiving email service may use verified current consent as a positive policy signal after independently establishing the sender identity relevant to its query. This document defines a portable consent object format and verification contract, together with requirements for separately admitted blockchain adapters. It does not select a universal blockchain network or claim operational readiness.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-saez-xcim/", "html": "https://datatracker.ietf.org/doc/html/draft-saez-xcim", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-saez-xcim" } }, { "name": "draft-srivastava-learnlog", "title": "Learnlog Assistance Capture Profile and Optional Event File Representation", "rev": "02", "new": false, "revised": "2026-10-20T19:38:21Z", "found": "2026-10-20T19:47:08.678Z", "pages": 70, "group": "individual", "group_type": "individual", "submitter": "srivastava", "area": "irtf", "area_label": "IRTF", "area_source": "classifier", "area_confidence": 0.35, "topic": "ai", "topic_label": "AI/agents", "topic_confidence": 0.91, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.72, "classifier": "jev-1.13.0", "abstract": "This document proposes Learnlog as an assistance capture profile for measuring AI scaffolding, with xAPI and Caliper bindings. Its motivation is Quantum Learning Machines' work on QLM Measure. The profile defines what assistance was requested, generated, transmitted, displayed, or accepted; what an instrument captured; and which facts remain unknown. Existing logging ecosystems can carry these definitions. Their reviewed base specifications do not, by themselves, require this particular combined agreement on assistance, achieved capture, unavailable information, and mapping provenance. Existing AI and tutoring profiles already cover important parts of the domain. The document retains the existing Learnlog event file representation, hash chains, optional signed heads, and verifiable redaction as an optional carrier. An implementation can use the assistance profile without producing that file representation. Experimental companion software constructs importer-observation records in xAPI and Caliper while preserving source assistance assertions separately. The implementation does not establish independent interoperability, truthful or complete capture, independent learning, or scientific equivalence across products. The core file format is unchanged in this revision.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-srivastava-learnlog/", "html": "https://datatracker.ietf.org/doc/html/draft-srivastava-learnlog", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-srivastava-learnlog" } }, { "name": "draft-guthrie-ipsecme-aes-gcm-siv", "title": "Using AES-GCM-SIV in the Internet Protocol Version 2 (IKEv2) and Encapsulating Security Payload (ESP) Protocols", "rev": "02", "new": false, "revised": "2026-10-20T18:56:20Z", "found": "2026-10-20T19:47:08.678Z", "pages": 9, "group": "individual", "group_type": "individual", "submitter": "guthrie", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 1, "topic": "security", "topic_label": "Security", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document specifies the use of AES-GCM-SIV in the Internet Key Exchange Protocol version 2 (IKEv2) and the Encapsulating Security Payload (ESP) protocols. This document also adds AES-GCM-SIV to the IANA IKEv2 registry for \"Transform Type 1 - Encryption Algorithm Transform IDs.\" AES-GCM-SIV is a nonce misuse-resistant authenticated encryption with associated data (AEAD) algorithm based on AES-GCM.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-guthrie-ipsecme-aes-gcm-siv/", "html": "https://datatracker.ietf.org/doc/html/draft-guthrie-ipsecme-aes-gcm-siv", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-guthrie-ipsecme-aes-gcm-siv" } }, { "name": "draft-ietf-regext-rdap-extensions", "title": "RDAP Extensions", "rev": "16", "new": false, "revised": "2026-10-20T17:51:44Z", "found": "2026-10-20T18:47:09.994Z", "pages": 35, "group": "regext", "group_type": "wg", "submitter": "regext", "area": "ops", "area_label": "OPS", "area_source": "datatracker", "area_confidence": 1, "topic": "dns", "topic_label": "DNS/naming", "topic_confidence": 1, "kind": "informational", "kind_label": "informational / guidance", "kind_confidence": 0.45, "classifier": "jev-1.13.0", "abstract": "This document describes and clarifies the usage of extensions in RDAP.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-extensions/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-extensions", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-regext-rdap-extensions" } }, { "name": "draft-shankarlingam-oauth-agent-dns-link", "title": "Linking an Agent's DNS Name to its OAuth Client", "rev": "00", "new": true, "revised": "2026-10-20T17:29:00Z", "found": "2026-10-20T17:47:08.099Z", "pages": 15, "group": "individual", "group_type": "individual", "submitter": "shankarlingam", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 1, "topic": "security", "topic_label": "Security", "topic_confidence": 0.95, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "Software agents increasingly call agents and services operated by other organizations. A receiving organization often wants to know two things about any such caller: that it is the agent it claims to be, and that the organization operating it still authorizes it. Existing approaches to the second question require a trust relationship between the two organizations' authorization servers. This document defines a DNS record by which the owner of a domain links an agent's DNS name to the OAuth client that the agent uses at the owner's own authorization server. The sending agent presents a fresh access token for that client; the receiver verifies the token against the record and against the issuer's published keys. No trust relationship, registration or federation between the two organizations is needed, and disabling the client at the sending organization's authorization server stops the agent being accepted by every receiver.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-shankarlingam-oauth-agent-dns-link/", "html": "https://datatracker.ietf.org/doc/html/draft-shankarlingam-oauth-agent-dns-link", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-shankarlingam-oauth-agent-dns-link" } }, { "name": "draft-ousterhout-tsvwg-homa", "title": "Homa: An RPC Transport Protocol for Datacenters", "rev": "00", "new": true, "revised": "2026-10-20T17:10:23Z", "found": "2026-10-20T17:47:08.099Z", "pages": 34, "group": "individual", "group_type": "individual", "submitter": "ousterhout", "area": "wit", "area_label": "WIT", "area_source": "classifier", "area_confidence": 0.97, "topic": "transport", "topic_label": "Transport", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document defines the Homa transport protocol. Homa provides applications with a reliable and efficient mechanism for delivering request and response messages for remote procedure calls (RPCs). It is intended for use within datacenters. Homa uses messages, receiver-issued grants, and packet priorities to support RPC workloads. Published evaluations report a reduction of more than 10x in tail latency for short messages relative to TCP for specific workloads and test conditions; this document does not claim a performance improvement for all datacenter environments.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ousterhout-tsvwg-homa/", "html": "https://datatracker.ietf.org/doc/html/draft-ousterhout-tsvwg-homa", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ousterhout-tsvwg-homa" } }, { "name": "draft-ietf-cats-metric-definition", "title": "CATS Metrics Definition", "rev": "14", "new": false, "revised": "2026-10-20T16:43:59Z", "found": "2026-10-20T16:54:28.031Z", "pages": 58, "group": "cats", "group_type": "wg", "submitter": "cats", "area": "rtg", "area_label": "RTG", "area_source": "datatracker", "area_confidence": 1, "topic": "cloud", "topic_label": "Cloud/DC", "topic_confidence": 0.99, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.93, "classifier": "jev-1.13.0", "abstract": "Computing-Aware Traffic Steering (CATS) is a traffic engineering approach that optimizes the steering of traffic to a service instance by considering the dynamic state of computing and network resources. To enable such decisions, CATS components exchange metrics that describe resource conditions affecting service instance selection. This document focuses on compute and communication metrics for CATS and defines a hierarchical abstraction of these metrics to improve interoperability, scalability, and operational simplicity. It does not aim to standardize raw infrastructure (Level 0) metrics; instead, it specifies higher-level representations that can be derived from raw measurements using aggregation and normalization functions.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-cats-metric-definition/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-cats-metric-definition", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-cats-metric-definition" } }, { "name": "draft-zambo-aer1", "title": "AER-1: A Portable Execution Receipt for AI Agent Tool Calls", "rev": "24", "new": false, "revised": "2026-10-20T16:42:00Z", "found": "2026-10-20T16:54:28.031Z", "pages": 50, "group": "individual", "group_type": "individual", "submitter": "zambo", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.87, "topic": "ai", "topic_label": "AI/agents", "topic_confidence": 0.98, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document specifies AER-1, a small vocabulary for recording one AI agent tool call as a portable, independently checkable execution receipt. A receipt identifies the execution, records when it happened, preserves the canonical bytes used for the output commitment, names the tool and caller scope, carries a provenance class, and resolves at a stable public URL. The format separates what the system observed from claims about the outside world, and it separates provenance (who ran or reported the action) from the record itself. A reference implementation is deployed, and its receipts are publicly verifiable without an account or token. The specification covers workflow receipts, which bind an ordered sequence of step receipts to a single goal with a Merkle root over the step sequence, and hash-chained job timelines for tamper-evident sequencing of executions. This revision closes honesty and precision gaps: it adds the workflow-receipt truncation limit (new Section 8.4), normatively specifies the external anchor format and its verification procedure (rewritten Section 10, new Section 10.1), fixes a RECOMMENDED/MUST contradiction in Section 8.1, makes the Section 6 verification step testable, and documents replay, low-entropy, empty-record, and size- limit considerations. It changes no receipt field, digest construction, or existing verification rule. The -13 revision fixes a malformed sentence in the Abstract, three incorrect section cross- references, stale Table of Contents page numbers, a skipped footer page number, misaligned table rows, and chain version-string updates, and records two reported interoperability examples in Implementation Status; it changes no receipt field, digest construction, or verification rule. The -14 revision adds tamper-evident metadata binding (new Section 3.1; conditional metadata_hash for schema 0.4 and later), disambiguates the anchor receipt_id (Table 4), corrects the self-anchoring witnessing claim (Section 10), makes the Section 8.3 display rule a SHOULD with a byte-testable MUST, narrows the provenance attestation wording (Section 5), states the binding non-transfer rule normatively (new Section 10.2), pins anchored_digest to bare hex (Table 4), corrects the vector corpus counts, and adds normative disclosure of missing issuer authentication. It changes no existing receipt field, digest construction, or verification rule for schema 0.3 and earlier. The -15 revision narrows the Implementation Status wording for the reported interoperability examples at the implementer's request; it changes no receipt field, digest construction, or verification rule. The -16 revision documents the live workflow tools API (new Sections 8.5, 8.6, 8.7): the workflow_close tool, workflow metadata in step receipts, and the workflow view API. It changes no receipt field, digest construction, or existing verification rule. The -17 revision documents the recommended execution_context member (new Section 3.2): an optional, non-core structure for recording source and version context such as the model name and version behind a tool call and the identity of the source system acted upon. It changes no existing receipt field, digest construction, or verification rule. The -18 revision repairs the reference apparatus (normative references to RFC 3339, RFC 8259, RFC 4122, and RFC 4648, and the previously missing RFC 7942 entry), pins two parser edge cases (duplicate JSON member names and leap-second timestamps are rejected), names the Unicode normalization behavior in Section 4 with a computed vector pair, adopts the unknown-versus-not-applicable convention for optional members, adds optional members for readback outcomes, per-field provenance, negative records, reversal state, method descriptors, and payment references, completes the execution_context member set (model and environment digests), adds the optional input_hash commitment (Section 3.3), permits SCITT and RFC 3161 anchors under Section 10, states the clock-trus", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-zambo-aer1/", "html": "https://datatracker.ietf.org/doc/html/draft-zambo-aer1", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-zambo-aer1" } }, { "name": "draft-knodel-nomcom-gender-representation", "title": "Gender Representation in the IETF Nominating Committees", "rev": "07", "new": false, "revised": "2026-10-20T16:02:32Z", "found": "2026-10-20T16:54:28.031Z", "pages": 10, "group": "individual", "group_type": "individual", "submitter": "knodel", "area": "gen", "area_label": "GEN", "area_source": "classifier", "area_confidence": 0.99, "topic": "process", "topic_label": "Process", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.31, "classifier": "jev-1.13.0", "abstract": "This document extends the existing limit on nomcom representation by organization ([RFC8713], Section 4.17) so that not all voting members of the IETF Nominating Committee (nomcom) 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 seat fewer.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-knodel-nomcom-gender-representation/", "html": "https://datatracker.ietf.org/doc/html/draft-knodel-nomcom-gender-representation", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-knodel-nomcom-gender-representation" } }, { "name": "draft-ietf-cdni-source-access-control-metadata", "title": "CDNI Source Access Control Metadata", "rev": "02", "new": false, "revised": "2026-10-20T15:55:15Z", "found": "2026-10-20T16:54:28.031Z", "pages": 43, "group": "cdni", "group_type": "wg", "submitter": "cdni", "area": "wit", "area_label": "WIT", "area_source": "datatracker", "area_confidence": 1, "topic": "cloud", "topic_label": "Cloud/DC", "topic_confidence": 0.29, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This specification provides an alternative to the MI.SourceMetadata objects defined in RFC8006, providing greatly extended capabilities with regards to defining multiple sources, load balancing, and failover rules across those sources, as well as a mechanism for a content delivery network (CDN) to monitor source health and pull unhealthy sources out of rotation. Additionally, new methods are defined for authentication access to an upstream source/origin.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-cdni-source-access-control-metadata/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-cdni-source-access-control-metadata", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-cdni-source-access-control-metadata" } }, { "name": "draft-ietf-idr-bgp-ls-sr-policy-admin-flags", "title": "Advertisement of SR Policy Operational States using BGP Link-State", "rev": "01", "new": false, "revised": "2026-10-20T15:49:09Z", "found": "2026-10-20T16:54:28.031Z", "pages": 11, "group": "idr", "group_type": "wg", "submitter": "idr", "area": "rtg", "area_label": "RTG", "area_source": "datatracker", "area_confidence": 1, "topic": "routing", "topic_label": "Routing", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document defines the extension of BGP Link-State to advertise the operational state of the candidate path or segment list, facilitating the operation and maintenance of the SR Policy.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-sr-policy-admin-flags/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ls-sr-policy-admin-flags", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-idr-bgp-ls-sr-policy-admin-flags" } }, { "name": "draft-hardie-bcp35-update", "title": "Updated Provisional Registration Guidelines for URI Schemes", "rev": "01", "new": false, "revised": "2026-10-20T15:23:00Z", "found": "2026-10-20T15:47:09.685Z", "pages": 4, "group": "individual", "group_type": "individual", "submitter": "hardie", "area": "art", "area_label": "ART", "area_source": "classifier", "area_confidence": 0.97, "topic": "process", "topic_label": "Process", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.39, "classifier": "jev-1.13.0", "abstract": "This documents updates the registration procedures for provisional URI schemes to handle issues not present at the time RFC 7595 was written.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-hardie-bcp35-update/", "html": "https://datatracker.ietf.org/doc/html/draft-hardie-bcp35-update", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-hardie-bcp35-update" } }, { "name": "draft-ietf-ippm-stamp-ext-hdr", "title": "Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Reflecting STAMP Packet IP Headers", "rev": "19", "new": false, "revised": "2026-10-20T15:02:14Z", "found": "2026-10-20T02:47:07.070Z", "pages": 34, "group": "ippm", "group_type": "wg", "submitter": "ippm", "area": "ops", "area_label": "OPS", "area_source": "datatracker", "area_confidence": 1, "topic": "measurement", "topic_label": "Measurement/OAM", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "The Simple Two-Way Active Measurement Protocol (STAMP) and its optional extensions can be used for Edge-to-Edge (E2E) active measurements. In Situ Operations, Administration, and Maintenance (IOAM) data fields can be used for recording and collecting hop-by- hop and E2E operational and telemetry information. This document extends STAMP to reflect IPv4/IPv6 headers as well as IPv6 extension headers for hop-by-hop and E2E active measurements, for example, using the IOAM data fields. This document updates RFC 8762 by specifying IPv4/IPv6 and UDP headers handling, UDP checksum handling, session state notifications, and rate limiting requirements that also apply to STAMP sessions not using these extensions.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp-ext-hdr/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-ext-hdr", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-ippm-stamp-ext-hdr" } }, { "name": "draft-preussmattsson-tls-hqckem", "title": "HQC-KEM Key Agreement for TLS 1.3", "rev": "03", "new": false, "revised": "2026-10-20T15:01:34Z", "found": "2026-10-20T15:47:09.685Z", "pages": 23, "group": "individual", "group_type": "individual", "submitter": "preussmattsson", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 1, "topic": "security", "topic_label": "Security", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document defines nine quantum-resistant TLS 1.3 key exchange algorithms based on HQC-KEM, the code-based KEM selected by NIST for standardization in forthcoming FIPS 207. Three use HQC-KEM standalone, two combine it with X25519 or X448 in PQ/T hybrids, two combine it with ML-KEM in PQ/PQ hybrids, and two combine it with ML- KEM and X25519 or X448 in PQ/PQ/T hybrids. Because HQC-KEM relies on hardness assumptions and constructions different from those underlying lattice-based ML-KEM, these algorithms provide algorithmic diversity that can mitigate the impact of future cryptanalytic advances or implementation weaknesses in lattice-based cryptography. The algorithms are intended for TLS 1.3, DTLS 1.3, and QUIC, and the hybrid algorithms follow the general hybrid key exchange construction defined for TLS 1.3.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-preussmattsson-tls-hqckem/", "html": "https://datatracker.ietf.org/doc/html/draft-preussmattsson-tls-hqckem", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-preussmattsson-tls-hqckem" } }, { "name": "draft-ietf-netmod-yang-packages", "title": "YANG Packages", "rev": "10", "new": false, "revised": "2026-10-20T14:59:03Z", "found": "2026-10-20T15:47:09.685Z", "pages": 127, "group": "netmod", "group_type": "wg", "submitter": "netmod", "area": "ops", "area_label": "OPS", "area_source": "datatracker", "area_confidence": 1, "topic": "netmgmt", "topic_label": "Net management", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.99, "classifier": "jev-1.13.0", "abstract": "This document defines YANG packages: versioned organizational structures used to manage the schema and conformance of a set of YANG modules as a cohesive unit.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-packages/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-packages", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-netmod-yang-packages" } }, { "name": "draft-narvaneni-agent-uri", "title": "The agent URI Scheme and Verifiable Agent Identity", "rev": "04", "new": false, "revised": "2026-10-20T14:58:35Z", "found": "2026-10-20T07:47:06.802Z", "pages": 43, "group": "individual", "group_type": "individual", "submitter": "narvaneni", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.75, "topic": "ai", "topic_label": "AI/agents", "topic_confidence": 0.69, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "Software agents increasingly act on the Internet on behalf of people and organizations: they call APIs, browse websites, and delegate work to other agents. Protocols such as A2A and MCP define how agents communicate, but there is no interoperable way to answer a prior question: _which agent is this, and how can its claims be verified?_ This document defines the agent URI scheme as a stable, human- readable identifier for an agent, a deterministic mapping from that identifier to an HTTPS-hosted Agent Identity Document, anchoring of the agent's keys to a web origin or a Decentralized Identifier, and signed statements that bind the agent to its protocol metadata. It also defines profiles that let an agent prove its identity on HTTP requests, building on HTTP Message Signatures for automated traffic, and that let short-lived agent instances act under the agent's identity using the WIMSE Workload Identity Token format. It deliberately does not define how agents communicate, describe their capabilities, or are invoked.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-narvaneni-agent-uri/", "html": "https://datatracker.ietf.org/doc/html/draft-narvaneni-agent-uri", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-narvaneni-agent-uri" } }, { "name": "draft-santesson-oidc-cert-auth-context", "title": "Certificate Authentication Context Type for OpenID Connect", "rev": "00", "new": true, "revised": "2026-10-20T14:30:30Z", "found": "2026-10-20T14:47:09.952Z", "pages": 16, "group": "individual", "group_type": "individual", "submitter": "santesson", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 1, "topic": "security", "topic_label": "Security", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "RFC 7773 defines the Authentication Context certificate extension, which carries information about how the subject of an X.509 certificate was authenticated when the certificate was issued. RFC 7773 defines one context information type, for subjects authenticated by means of a Security Assertion Markup Language (SAML) assertion. This document defines a second context information type for subjects authenticated by means of OpenID Connect, where the identity information is obtained from an ID Token, where applicable in combination with a UserInfo Response. The information is expressed as a JSON object and provides the OpenID Connect counterpart to the SAML Authentication Context Information defined in RFC 7773. This document also updates RFC 7773 by clarifying that an application processing the extension ignores context information types it does not support regardless of the criticality of the extension, and by recommending that the extension not be marked critical.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-santesson-oidc-cert-auth-context/", "html": "https://datatracker.ietf.org/doc/html/draft-santesson-oidc-cert-auth-context", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-santesson-oidc-cert-auth-context" } }, { "name": "draft-ietf-avtcore-hevc-webrtc", "title": "H.265 Profile for WebRTC", "rev": "10", "new": false, "revised": "2026-10-20T14:23:18Z", "found": "2026-10-20T14:47:09.952Z", "pages": 8, "group": "avtcore", "group_type": "wg", "submitter": "avtcore", "area": "wit", "area_label": "WIT", "area_source": "datatracker", "area_confidence": 1, "topic": "realtime", "topic_label": "Real-time media", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "RFC 7742 defines WebRTC video processing and codec requirements, including guidance for endpoints supporting the VP8 and H.264 codecs, which are mandatory to implement. This document defines a profile of RFC 7798 for browsers supporting the H.265 codec.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-avtcore-hevc-webrtc/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-hevc-webrtc", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-avtcore-hevc-webrtc" } }, { "name": "draft-xu-intarea-challenge-icmpv6", "title": "Enhancing ICMPv6 Error Message Authentication Using Challenge-Confirm Mechanism", "rev": "04", "new": false, "revised": "2026-10-20T13:48:26Z", "found": "2026-10-20T14:47:09.952Z", "pages": 16, "group": "individual", "group_type": "individual", "submitter": "xu", "area": "int", "area_label": "INT", "area_source": "classifier", "area_confidence": 0.84, "topic": "security", "topic_label": "Security", "topic_confidence": 0.8, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.93, "classifier": "jev-1.13.0", "abstract": "The Internet Control Message Protocol for IPv6 (ICMPv6) is essential for network diagnostics but is vulnerable to off-path spoofing attacks, especially when error messages relate to stateless transport protocols like UDP. An attacker can forge these messages to degrade performance or enable Man-in-the-Middle attacks. This document proposes a robust, stateless challenge-response mechanism to authenticate ICMPv6 error messages. Traditional stateful challenge mechanisms are vulnerable to state-exhaustion Denial-of-Service (DoS) attacks. To avoid this, the proposed solution is inspired by TCP SYN-Cookies, eliminating the need to store per-challenge state by using cryptographic computation. It limits state management to minimal flags on existing sockets or a bounded probabilistic data structure. This approach effectively authenticates ICMPv6 error messages while inherently resisting both off-path spoofing and state-exhaustion DoS attacks, thus improving the robustness of ICMPv6.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-xu-intarea-challenge-icmpv6/", "html": "https://datatracker.ietf.org/doc/html/draft-xu-intarea-challenge-icmpv6", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-xu-intarea-challenge-icmpv6" } }, { "name": "draft-ietf-pquip-pqc-hsm-constrained", "title": "Adapting Constrained Devices for Post-Quantum Cryptography", "rev": "09", "new": false, "revised": "2026-10-20T12:49:17Z", "found": "2026-10-20T13:47:08.786Z", "pages": 30, "group": "pquip", "group_type": "wg", "submitter": "pquip", "area": "sec", "area_label": "SEC", "area_source": "datatracker", "area_confidence": 1, "topic": "security", "topic_label": "Security", "topic_confidence": 1, "kind": "informational", "kind_label": "informational / guidance", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document provides guidance on integrating Post-Quantum Cryptography (PQC) into resource-constrained devices, such as IoT nodes and dedicated key-storage hardware. These systems often operate with strict limitations on processing power, RAM, and flash memory, and may even be battery-powered. The document emphasizes the role of hardware security as the basis for secure operations, supporting features such as seed-based key generation to minimize persistent storage, efficient handling of ephemeral keys, and the offloading of cryptographic tasks in low-resource environments. It also explores the implications of PQC on firmware update mechanisms in such constrained systems.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-pquip-pqc-hsm-constrained/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-pquip-pqc-hsm-constrained", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-pquip-pqc-hsm-constrained" } }, { "name": "draft-ietf-wimse-http-signature", "title": "WIMSE Workload-to-Workload Authentication with HTTP Signatures", "rev": "08", "new": false, "revised": "2026-10-20T12:47:02Z", "found": "2026-10-20T12:47:09.665Z", "pages": 30, "group": "wimse", "group_type": "wg", "submitter": "wimse", "area": "art", "area_label": "ART", "area_source": "datatracker", "area_confidence": 1, "topic": "security", "topic_label": "Security", "topic_confidence": 0.98, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "The WIMSE architecture defines authentication and authorization for software workloads in a variety of runtime environments, from the most basic ones to complex multi-service, multi-cloud, multi-tenant deployments. This document defines one of the mechanisms to provide workload authentication, using HTTP Signatures. While only applicable to HTTP traffic, the protocol provides end-to-end protection of requests (and optionally, responses), even when service traffic is not end-to-end encrypted, that is, when TLS proxies and load balancers are used. Authentication is based on the Workload Identity Token (WIT).", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-wimse-http-signature/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-wimse-http-signature", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-wimse-http-signature" } }, { "name": "draft-li-lsvr-bgp-spf-srv6", "title": "Applying BGP-LS Segment Routing over IPv6(SRv6) Extensions to BGP-LS-SPF", "rev": "07", "new": false, "revised": "2026-10-20T12:23:53Z", "found": "2026-10-20T12:47:09.665Z", "pages": 23, "group": "individual", "group_type": "individual", "submitter": "li", "area": "rtg", "area_label": "RTG", "area_source": "classifier", "area_confidence": 1, "topic": "routing", "topic_label": "Routing", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.97, "classifier": "jev-1.13.0", "abstract": "For network scenarios such as Massively Scaled Data Centers (MSDCs), BGP is extended for Link-State (LS) distribution and the Shortest Path First (SPF) algorithm based calculation. BGP Link State Shortest Path First (BGP-LS-SPF) Routing leverages the mechanisms of both BGP protocol and BGP-LS protocol extensions. Segment Routing over IPv6 (SRv6) provides a source routing mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SRv6 domain. In some networks, it may be useful to enable SRv6 based source routing mechanism together with BGP-LS-SPF. This document proposes to introduce the BGP Link-State (BGP-LS) extensions for SRv6 to the BGP-LS-SPF SAFI to enable SRv6 capabilities in BGP-LS-SPF. The usages and formats of these extensions are also provided in this document.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-li-lsvr-bgp-spf-srv6/", "html": "https://datatracker.ietf.org/doc/html/draft-li-lsvr-bgp-spf-srv6", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-li-lsvr-bgp-spf-srv6" } }, { "name": "draft-seemann-masque-connect-ip-qlog", "title": "qlog Definitions for CONNECT-IP", "rev": "00", "new": true, "revised": "2026-10-20T10:22:17Z", "found": "2026-10-20T10:47:06.642Z", "pages": 11, "group": "individual", "group_type": "individual", "submitter": "seemann", "area": "wit", "area_label": "WIT", "area_source": "classifier", "area_confidence": 0.99, "topic": "transport", "topic_label": "Transport", "topic_confidence": 0.91, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.95, "classifier": "jev-1.13.0", "abstract": "This document defines qlog events for CONNECT-IP packet processing and representations for its capsules, including the DNS and PREF64 configuration extensions. It extends the HTTP event schema defined in the HTTP/3 qlog document.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-seemann-masque-connect-ip-qlog/", "html": "https://datatracker.ietf.org/doc/html/draft-seemann-masque-connect-ip-qlog", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-seemann-masque-connect-ip-qlog" } }, { "name": "draft-valverde-oauth-veil", "title": "VEIL: Verified Ephemeral Identity Layer for OAuth 2.1", "rev": "00", "new": true, "revised": "2026-10-20T07:09:06Z", "found": "2026-10-20T07:47:06.802Z", "pages": 24, "group": "individual", "group_type": "individual", "submitter": "valverde", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 1, "topic": "security", "topic_label": "Security", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.97, "classifier": "jev-1.13.0", "abstract": "VEIL (Verified Ephemeral Identity Layer) is a security profile of OAuth 2.1 for privacy-preserving identity verification. It separates claims into two tracks: proof claims (boolean verification results, compliance flags, assurance levels) travel through standard token claims, while identity claims (name, date of birth, address, nationality) travel only through an ephemeral, single-consume channel that keeps personally identifiable information off long-lived tokens. Subject identifiers are pairwise by default. Consent records are HMAC-protected. Step-up authentication scales with operation sensitivity. VEIL is the base profile for domain-specific extensions.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-valverde-oauth-veil/", "html": "https://datatracker.ietf.org/doc/html/draft-valverde-oauth-veil", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-valverde-oauth-veil" } }, { "name": "draft-valverde-oauth-pact", "title": "PACT: Private Agent Consent and Trust Profile for OAuth 2.1 and CIBA", "rev": "00", "new": true, "revised": "2026-10-20T07:09:05Z", "found": "2026-10-20T07:47:06.802Z", "pages": 44, "group": "individual", "group_type": "individual", "submitter": "valverde", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 1, "topic": "security", "topic_label": "Security", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.97, "classifier": "jev-1.13.0", "abstract": "PACT (Private Agent Consent and Trust Profile) is a security profile of OAuth 2.1 for privacy-preserving agent delegation. It extends VEIL and composes OIDC CIBA Core 1.0 and OAuth Token Exchange (RFC 8693). PACT defines a durable-host plus ephemeral-session control plane, a delegation token claim vocabulary, runtime identity proofs using Ed25519 JWTs, capability grants with typed constraints and usage limits, risk-graduated consent routing, and claim narrowing on token exchange to non-agent audiences.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-valverde-oauth-pact/", "html": "https://datatracker.ietf.org/doc/html/draft-valverde-oauth-pact", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-valverde-oauth-pact" } }, { "name": "draft-illyes-repext", "title": "Robots Exclusion Protocol Extension for URL Level Control", "rev": "03", "new": false, "revised": "2026-10-20T07:09:03Z", "found": "2026-10-20T07:47:06.802Z", "pages": 9, "group": "individual", "group_type": "individual", "submitter": "illyes", "area": "wit", "area_label": "WIT", "area_source": "classifier", "area_confidence": 0.51, "topic": "web", "topic_label": "Web/HTTP", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document extends RFC9309 by specifying additional URL level controls through an HTTP response header and, for historical reasons, through HTML meta tags originally developed in 1996. Additionally it moves the HTTP response header out of the experimental header space (i.e., \"X-\") and defines the combinability of multiple headers, which was previously not possible.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-illyes-repext/", "html": "https://datatracker.ietf.org/doc/html/draft-illyes-repext", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-illyes-repext" } }, { "name": "draft-ietf-ccamp-actn-optical-transport-mgmt", "title": "Integrating YANG Configuration and Management into an Abstraction and Control of TE Networks (ACTN) System for Optical Networks", "rev": "05", "new": false, "revised": "2026-10-20T07:09:03Z", "found": "2026-10-20T07:47:06.802Z", "pages": 25, "group": "ccamp", "group_type": "wg", "submitter": "ccamp", "area": "rtg", "area_label": "RTG", "area_source": "datatracker", "area_confidence": 1, "topic": "netmgmt", "topic_label": "Net management", "topic_confidence": 1, "kind": "informational", "kind_label": "informational / guidance", "kind_confidence": 0.75, "classifier": "jev-1.13.0", "abstract": "Many network technologies are operated as Traffic Engineering (TE) networks. Optical networks are a particular case, and have complex technology-specific details. Abstraction and Control of TE Networks (ACTN) is a management architecture that abstracts TE network resources to provide a limited network view for customers to request and self-manage connectivity services. It also provides functional components to orchestrate and operate the network. Management of legacy optical networks is often provided via Fault, Configuration, Accounting, Performance, and Security (known as FCAPS) using mechanisms such as the Multi-Technology Operations System Interface (MTOSI) and the Common Object Request Broker Architecture (CORBA). FCAPS can form a critical part of configuration management and service assurance for network operations. However, the ACTN architecture as described in RFC 8453 does not include consideration of FCAPS. This document enhances the ACTN architecture as applied to optical networks by introducing support for detailed YANG Configuration and Management, effectively adding support for FCAPS. It considers which elements of existing IETF YANG work can be used to solve existing scenarios and emerging technologies, and what new work may be needed. In doing so, this document adds rich-detail network management (RDNM) to the ACTN architecture. This enhanced architecture may then be used to evolve networks from CORBA and MTOSI FCAPS interfaces to IETF-based YANG and RESTful APIs.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-ccamp-actn-optical-transport-mgmt/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-actn-optical-transport-mgmt", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-ccamp-actn-optical-transport-mgmt" } }, { "name": "draft-lindqvist-zstdict", "title": "Zstandard Dictionary Content-Encoding", "rev": "01", "new": false, "revised": "2026-10-20T05:06:01Z", "found": "2026-10-20T04:47:08.969Z", "pages": 4, "group": "individual", "group_type": "individual", "submitter": "lindqvist", "area": "wit", "area_label": "WIT", "area_source": "classifier", "area_confidence": 0.88, "topic": "web", "topic_label": "Web/HTTP", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document defines a new HTTP content coding, \"zstdict\", which enables Zstandard compression with a pre-shared dictionary. The dictionary is identified by a SHA-256 hash and negotiated via the Content-Dict response header.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-lindqvist-zstdict/", "html": "https://datatracker.ietf.org/doc/html/draft-lindqvist-zstdict", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-lindqvist-zstdict" } }, { "name": "draft-ietf-pim-evpn-multicast-yang", "title": "Yang Data Model for EVPN multicast", "rev": "08", "new": false, "revised": "2026-10-20T03:16:14Z", "found": "2026-10-20T03:47:06.995Z", "pages": 12, "group": "pim", "group_type": "wg", "submitter": "pim", "area": "rtg", "area_label": "RTG", "area_source": "datatracker", "area_confidence": 1, "topic": "netmgmt", "topic_label": "Net management", "topic_confidence": 0.99, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document describes a YANG data model for EVPN multicast services. The model is agnostic of the underlay as well as RFC 9251. This document mainly focuses on EVPN instance framework.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-pim-evpn-multicast-yang/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-pim-evpn-multicast-yang", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-pim-evpn-multicast-yang" } }, { "name": "draft-konda-agentproto-evaluation-state", "title": "Preserving Evaluation State in Agent Protocol Decisions", "rev": "02", "new": false, "revised": "2026-10-20T02:53:59Z", "found": "2026-10-20T03:47:06.995Z", "pages": 24, "group": "individual", "group_type": "individual", "submitter": "konda", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.95, "topic": "ai", "topic_label": "AI/agents", "topic_confidence": 0.82, "kind": "requirements", "kind_label": "requirements / use cases", "kind_confidence": 0.95, "classifier": "jev-1.13.0", "abstract": "Agent protocols often require a participant to establish a decision- time input before it acts: issuer standing, key availability, delegated authority, policy profile availability, consumption state, revocation status, or the outcome of a downstream operation. A participant that establishes an input and receives a negative answer has learned a different fact from a participant that cannot establish the input at all. Collapsing those facts into one denial or failure value changes retry behavior, alert routing, audit interpretation, incident ownership, and post-incident reconstruction. This document specifies requirements for preserving evaluation state across agent protocol boundaries: the value of an input, whether that value was established at decision time, the freshness of the source used to establish it, and whether the resulting policy decision was actually evaluated. The requirements are stated independently of encoding, so that policy, authorization, revocation, routing, and audit documents can satisfy them in their own formats. Test cases for the requirements are included, with a machine-readable form published separately.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-konda-agentproto-evaluation-state/", "html": "https://datatracker.ietf.org/doc/html/draft-konda-agentproto-evaluation-state", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-konda-agentproto-evaluation-state" } }, { "name": "draft-wu-grow-bmp-multi-instance", "title": "BMP Extension for Monitoring Multiple BGP Instances", "rev": "01", "new": false, "revised": "2026-10-20T02:52:14Z", "found": "2026-10-20T03:47:06.995Z", "pages": 11, "group": "individual", "group_type": "individual", "submitter": "wu", "area": "rtg", "area_label": "RTG", "area_source": "classifier", "area_confidence": 1, "topic": "routing", "topic_label": "Routing", "topic_confidence": 0.86, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "The BGP Monitoring Protocol (BMP), as defined in RFC 7854, provides a means for monitoring BGP sessions. In deployments where a single device runs multiple BGP instances simultaneously - typically a base instance together with one or more additional instances, each identified by an Instance Name and potentially running in a separate process with an independent Router-ID and Autonomous System (AS) number - the existing BMP message format does not allow a Monitoring Station to distinguish peers or routes belonging to different BGP instances on the same monitored router. This document defines a new BMP Type-Length-Value (TLV) element, the BGP Instance Name TLV, that carries the Instance Name of the BGP instance associated with a given peer or route. Following the TLV extension framework defined in [I-D.ietf-grow-bmp-tlv], the new TLV MAY appear in Peer Up Notification, Peer Down Notification, Route Monitoring, Statistics Report, and Route Mirroring messages. The TLV enables a Monitoring Station to unambiguously attribute monitored BGP information to the correct BGP instance on the monitored router.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-wu-grow-bmp-multi-instance/", "html": "https://datatracker.ietf.org/doc/html/draft-wu-grow-bmp-multi-instance", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-wu-grow-bmp-multi-instance" } }, { "name": "draft-mcconnell-software-status-wellknown", "title": "A Well-Known URI for Software Lifecycle Status", "rev": "03", "new": false, "revised": "2026-10-20T01:38:31Z", "found": "2026-10-20T01:47:07.293Z", "pages": 27, "group": "individual", "group_type": "individual", "submitter": "mcconnell", "area": "art", "area_label": "ART", "area_source": "classifier", "area_confidence": 0.85, "topic": "web", "topic_label": "Web/HTTP", "topic_confidence": 0.98, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.97, "classifier": "jev-1.13.0", "abstract": "This document defines a Well-Known URI [RFC8615] at which software vendors and open-source maintainers may publish machine-readable lifecycle status information for their products. A JSON resource retrieved from /.well-known/software-status.json allows consumers — including security tools, software composition analysis (SCA) platforms, vulnerability scanners, and system administrators — to programmatically determine whether a specific version of a software product is actively supported, in long-term support (LTS), under security-only maintenance, or at end-of-life (EOL). This revision (-02) extends the schema to support multi-product vendors — organizations that ship multiple distinct products or SKUs under a single domain. A new optional products array at the root of the resource allows a single software-status.json endpoint to serve lifecycle declarations for an entire product catalog, including firmware-based devices such as routers, switches, and IoT appliances. This extension is fully backward compatible: existing single-product resources require no modification. This revision (-03) broadens the scope beyond firmware-based devices to hosted software-as-a-service, installed fat and thin clients, browser extensions and plug-ins, and devices of all kinds, including televisions, drones, and servers. It adds product types and identifiers for these deployment models, and cross-references SBOM formats (CycloneDX, SPDX) as complementary data. The schema version is raised to \"1.1\"; the change is additive and fully backward compatible with \"1.0\" resources. This document also describes, in Appendix B (#appendix-b), a companion convention for open-source projects hosted on version- control platforms to publish equivalent information within the repository at .github/software-status.json.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-mcconnell-software-status-wellknown/", "html": "https://datatracker.ietf.org/doc/html/draft-mcconnell-software-status-wellknown", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-mcconnell-software-status-wellknown" } }, { "name": "draft-he-ippm-ioam-trace-type-bandwidth", "title": "IOAM Trace-Type Extensions for Path bandwidth", "rev": "02", "new": false, "revised": "2026-10-20T01:11:59Z", "found": "2026-10-20T01:47:07.293Z", "pages": 10, "group": "individual", "group_type": "individual", "submitter": "he", "area": "ops", "area_label": "OPS", "area_source": "classifier", "area_confidence": 0.78, "topic": "measurement", "topic_label": "Measurement/OAM", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "Traffic scheduling and optimization have become routine network operation and maintenance tasks for operators. The operators need to select a path that can accommodate the capacity of the traffic to be scheduled. In situ Operations, Administration, and Maintenance (IOAM) is used for recording and collecting operational and telemetry information. This document defines two bit flags within IOAM Trace- Type for carrying bandwidth information.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-he-ippm-ioam-trace-type-bandwidth/", "html": "https://datatracker.ietf.org/doc/html/draft-he-ippm-ioam-trace-type-bandwidth", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-he-ippm-ioam-trace-type-bandwidth" } }, { "name": "draft-dkg-audits-json", "title": "Automated Discovery Of Audit Reports (audits.json)", "rev": "01", "new": false, "revised": "2026-10-20T00:36:41Z", "found": "2026-10-20T00:47:07.186Z", "pages": 12, "group": "individual", "group_type": "individual", "submitter": "dkg", "area": "art", "area_label": "ART", "area_source": "classifier", "area_confidence": 0.39, "topic": "web", "topic_label": "Web/HTTP", "topic_confidence": 0.78, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.83, "classifier": "jev-1.13.0", "abstract": "This document describes a mechanism that an organization can use to enable automatic discovery of documents associated with regulatory compliance. It is motivated by regulations that require, for example, publicly accessible audits of automated decision-making processes in hiring.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-dkg-audits-json/", "html": "https://datatracker.ietf.org/doc/html/draft-dkg-audits-json", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-dkg-audits-json" } }, { "name": "draft-borshchahivskyi-httpbis-preview", "title": "The Preview HTTP Response Header Field", "rev": "00", "new": true, "revised": "2026-10-20T00:02:06Z", "found": "2026-10-20T00:47:07.186Z", "pages": 20, "group": "individual", "group_type": "individual", "submitter": "borshchahivskyi", "area": "wit", "area_label": "WIT", "area_source": "classifier", "area_confidence": 0.97, "topic": "web", "topic_label": "Web/HTTP", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "Many applications display a \"preview card\" for a link: a title, a short description and an image. Today this information is obtained by retrieving the full HTML representation of the linked resource and extracting metadata from it. This forces origin servers to generate complete pages for clients that need only a few short strings. This document defines the Preview HTTP response header field, a Structured Field that carries link preview metadata, and describes how it can be delivered in responses to HEAD requests so that preview generators can obtain it without the origin server generating the representation.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-borshchahivskyi-httpbis-preview/", "html": "https://datatracker.ietf.org/doc/html/draft-borshchahivskyi-httpbis-preview", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-borshchahivskyi-httpbis-preview" } }, { "name": "draft-chen-oauth-agent-intent-token", "title": "The Intent Token - A Credential for Delegated User Intent", "rev": "00", "new": true, "revised": "2026-10-19T20:05:44Z", "found": "2026-10-19T20:47:07.053Z", "pages": 8, "group": "individual", "group_type": "individual", "submitter": "chen", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 1, "topic": "security", "topic_label": "Security", "topic_confidence": 0.99, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.43, "classifier": "jev-1.13.0", "abstract": "In the scenario of AI agent authorization, how to ensure that a user's high-level, natural-language intent is correctly and safely converted into low-level, specific authorization grants. A misunderstanding or malicious interpretation during this translation can lead to significant security vulnerabilities. This document introduces the \"Intent Token,\" a new type of security token designed to bridge this semantic gap. The Intent Token is a signed credential that immutably captures the user's original intent. It decouples the act of granting an intent from the act of issuing specific access tokens. A client presents this Intent Token to an Authorization Server, which acts as a trusted intermediary. The Authorization Server's responsibility is to interpret the user's stated intent and, based on its policies, issue narrowly-scoped, short-lived access tokens for specific resources, thereby ensuring the principle of least privilege is upheld throughout the process.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-chen-oauth-agent-intent-token/", "html": "https://datatracker.ietf.org/doc/html/draft-chen-oauth-agent-intent-token", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-chen-oauth-agent-intent-token" } }, { "name": "draft-devalk-redirect-by", "title": "The Redirect-By HTTP Response Header Field", "rev": "01", "new": false, "revised": "2026-10-19T19:35:48Z", "found": "2026-10-19T19:47:09.704Z", "pages": 9, "group": "individual", "group_type": "individual", "submitter": "devalk", "area": "wit", "area_label": "WIT", "area_source": "classifier", "area_confidence": 0.93, "topic": "web", "topic_label": "Web/HTTP", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.99, "classifier": "jev-1.13.0", "abstract": "This document defines the Redirect-By HTTP response header field. It allows the software component whose decision determined an HTTP redirect to identify itself, so that an operator diagnosing a redirect can determine which component was responsible for it. The field succeeds the widely deployed, non-standard X-Redirect-By header, which this document deprecates.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-devalk-redirect-by/", "html": "https://datatracker.ietf.org/doc/html/draft-devalk-redirect-by", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-devalk-redirect-by" } }, { "name": "draft-singh-rajput-rnp", "title": "Rizz Negotiation Protocol (RNP) Version 1.0", "rev": "00", "new": true, "revised": "2026-10-19T18:57:50Z", "found": "2026-10-19T19:47:09.704Z", "pages": 16, "group": "individual", "group_type": "individual", "submitter": "singh", "area": "art", "area_label": "ART", "area_source": "classifier", "area_confidence": 0.38, "topic": "ai", "topic_label": "AI/agents", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document specifies the Rizz Negotiation Protocol (RNP), version 1.0 -- a domain-configurable, machine-readable protocol governing autonomous AI-to-AI negotiation across any structured decision context. RNP defines a finite action space, a bounded round-based state machine, a Competitive Pressure Mechanism (CPM) for multi- thread simultaneity, a Context Layer for real-time situational intelligence, a Feedback Layer for continuous master data improvement, and a Loopback Learning Pipeline that trains agent models from observed outcomes. The protocol is domain-configurable: the same state machine and message envelope operate across commerce, logistics, task allocation, priority queuing, procurement, SLA negotiation, and rewards domains. RNP was first deployed in production within the Rizzentials platform (commerce domain) and is designed for enterprise integration with platforms such as SAP, Salesforce, and Atlassian Jira.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-singh-rajput-rnp/", "html": "https://datatracker.ietf.org/doc/html/draft-singh-rajput-rnp", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-singh-rajput-rnp" } }, { "name": "draft-kaizer-dnsop-ml-dsa-mtl-dnssec", "title": "Module-Lattice-Based Signatures with Merkle Tree Ladders (ML-DSA-MTL) for DNSSEC", "rev": "03", "new": false, "revised": "2026-10-19T18:46:52Z", "found": "2026-10-19T18:47:09.286Z", "pages": 22, "group": "individual", "group_type": "individual", "submitter": "kaizer", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.47, "topic": "dns", "topic_label": "DNS/naming", "topic_confidence": 0.81, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.99, "classifier": "jev-1.13.0", "abstract": "This document describes how to apply the Module-Lattice-Based Digital Signature Algorithm (ML-DSA) and Merkle Tree Ladders (MTL) as a conservative post-quantum cryptographic algorithm for DNS Security Extensions (DNSSEC). This combination is referred to as the ML-DSA- MTL Signature scheme. This document describes how to specify ML-DSA- MTL keys and signatures in DNSSEC, specifically for ML-DSA-44 with SHAKE-128.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-kaizer-dnsop-ml-dsa-mtl-dnssec/", "html": "https://datatracker.ietf.org/doc/html/draft-kaizer-dnsop-ml-dsa-mtl-dnssec", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-kaizer-dnsop-ml-dsa-mtl-dnssec" } }, { "name": "draft-ietf-httpbis-rfc6265bis", "title": "Cookies: HTTP State Management Mechanism", "rev": "22", "new": false, "revised": "2026-10-19T18:01:52Z", "found": "2026-10-19T18:47:09.286Z", "pages": 62, "group": "httpbis", "group_type": "wg", "submitter": "httpbis", "area": "wit", "area_label": "WIT", "area_source": "datatracker", "area_confidence": 1, "topic": "web", "topic_label": "Web/HTTP", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document defines the HTTP Cookie and Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol. Although cookies have many historical flaws that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet. This document obsoletes RFC 6265.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-httpbis-rfc6265bis/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-rfc6265bis", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-httpbis-rfc6265bis" } }, { "name": "draft-ietf-netconf-restconf-client-server", "title": "A YANG Data Model for RESTCONF Clients and Servers", "rev": "45", "new": false, "revised": "2026-10-19T18:01:51Z", "found": "2026-10-19T18:47:09.286Z", "pages": 62, "group": "netconf", "group_type": "wg", "submitter": "netconf", "area": "ops", "area_label": "OPS", "area_source": "datatracker", "area_confidence": 1, "topic": "netmgmt", "topic_label": "Net management", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document presents two YANG modules, one module to configure a RESTCONF client and the other module to configure a RESTCONF server. These modules support both standard and RESTCONF Call Home connections.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf-client-server/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-netconf-restconf-client-server", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-netconf-restconf-client-server" } }, { "name": "draft-ietf-netconf-netconf-client-server", "title": "A YANG Data Model for NETCONF Clients and Servers", "rev": "41", "new": false, "revised": "2026-10-19T18:01:50Z", "found": "2026-10-19T18:47:09.286Z", "pages": 65, "group": "netconf", "group_type": "wg", "submitter": "netconf", "area": "ops", "area_label": "OPS", "area_source": "datatracker", "area_confidence": 1, "topic": "netmgmt", "topic_label": "Net management", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document presents two YANG modules, one module to configure a NETCONF client and the other module to configure a NETCONF server. These modules support both the SSH and TLS transport protocols, and support both standard NETCONF and NETCONF Call Home connections.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-netconf-netconf-client-server/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-netconf-netconf-client-server", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-netconf-netconf-client-server" } }, { "name": "draft-ietf-core-href", "title": "Constrained Resource Identifiers", "rev": "30", "new": false, "revised": "2026-10-19T18:01:49Z", "found": "2026-10-19T18:47:09.286Z", "pages": 58, "group": "core", "group_type": "wg", "submitter": "core", "area": "wit", "area_label": "WIT", "area_source": "datatracker", "area_confidence": 1, "topic": "iot", "topic_label": "IoT", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "The Constrained Resource Identifier (CRI) is a complement to the Uniform Resource Identifier (URI) that represents the URI components in Concise Binary Object Representation (CBOR) rather than as a sequence of characters. This approach simplifies parsing, comparison, and reference resolution in environments with severe limitations on processing power, code size, and memory size. This RFC updates RFC 7595 by adding a column on the \"URI Schemes\" registry. // (This \"cref\" paragraph will be removed by the RFC editor:) After // approval of -28 and nit fixes in -29, the present revision -30 // contains two more small fixes for nits that were uncovered in the // RPC intake process.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-core-href/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-core-href", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-core-href" } }, { "name": "draft-ietf-emailcore-rfc5322bis", "title": "Internet Message Format", "rev": "12", "new": false, "revised": "2026-10-19T18:01:47Z", "found": "2026-10-19T18:47:09.286Z", "pages": 59, "group": "emailcore", "group_type": "wg", "submitter": "emailcore", "area": "art", "area_label": "ART", "area_source": "datatracker", "area_confidence": 1, "topic": "email", "topic_label": "Email/messaging", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of \"electronic mail\" messages. This specification is a revision of Request For Comments (RFC) 5322, itself a revision of Request For Comments (RFC) 2822, all of which supersede Request For Comments (RFC) 822, \"Standard for the Format of ARPA Internet Text Messages\", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-emailcore-rfc5322bis/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-emailcore-rfc5322bis", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-emailcore-rfc5322bis" } }, { "name": "draft-gruszka-signed-evaluation-receipts", "title": "Signed Evaluation Receipts", "rev": "03", "new": false, "revised": "2026-10-19T17:52:59Z", "found": "2026-10-19T18:47:09.286Z", "pages": 129, "group": "individual", "group_type": "individual", "submitter": "gruszka", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.99, "topic": "security", "topic_label": "Security", "topic_confidence": 0.88, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.99, "classifier": "jev-1.13.0", "abstract": "This document defines a Signed Evaluation Receipt: one JSON object that records one evaluation result, whether a stated threshold held for a stated metric of a stated test suite, and signs it with Ed25519 over a domain-separated encoding of its canonical bytes. A receipt shows who signed the recorded bytes. It does not show that the recorded result is true. A receipt does not prove registration with a Transparency Service. In SCITT, transparency additionally requires registering a Signed Statement carrying the receipt or its digest with a Transparency Service and verifying the resulting SCITT Receipt. Registration and verification of the resulting SCITT Receipt are outside this document.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-gruszka-signed-evaluation-receipts/", "html": "https://datatracker.ietf.org/doc/html/draft-gruszka-signed-evaluation-receipts", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-gruszka-signed-evaluation-receipts" } }, { "name": "draft-elkins-plants-enterprise-mtc-deployment", "title": "Enterprise Deployment Considerations for Standalone Merkle Tree Certificates", "rev": "01", "new": false, "revised": "2026-10-19T17:47:11Z", "found": "2026-10-19T18:47:09.286Z", "pages": 40, "group": "individual", "group_type": "individual", "submitter": "elkins", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 1, "topic": "security", "topic_label": "Security", "topic_confidence": 1, "kind": "informational", "kind_label": "informational / guidance", "kind_confidence": 0.88, "classifier": "jev-1.13.0", "abstract": "The migration of public Web PKI authentication to post-quantum mechanisms must fit enterprise certificate management and TLS termination architectures. This document examines whether an urgent need for post-quantum authentication would justify transitional support for standalone ML-DSA certificates in browser root-store policy while standalone MTC deployment capabilities mature. The scope is limited to enterprise public websites accessed by unmanaged clients using the public Web PKI. Note: a large enterprise may operate many such sites. The document describes enterprise-managed, third-party-hosted, and CDN-fronted deployments, identifies the components needed to serve standalone Merkle Tree Certificates (MTCs), and examines realistic authentication attack paths and migration priorities. It distinguishes the browser-to-edge connection from origin and internal connections, and server authentication from identity-provider login. The document draws on initial browser and TLS client testing of Trust Anchor ID signaling, and proposes interoperability tests and deployment requirements rather than changes to the MTC wire format. Relative priorities are illustrative and not empirical attack probabilities.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-elkins-plants-enterprise-mtc-deployment/", "html": "https://datatracker.ietf.org/doc/html/draft-elkins-plants-enterprise-mtc-deployment", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-elkins-plants-enterprise-mtc-deployment" } }, { "name": "draft-janbjer-div", "title": "Deterministic Intent Verification (DIV) Protocol Specification", "rev": "01", "new": false, "revised": "2026-10-19T17:11:53Z", "found": "2026-10-19T17:47:08.399Z", "pages": 61, "group": "individual", "group_type": "individual", "submitter": "janbjer", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 1, "topic": "security", "topic_label": "Security", "topic_confidence": 0.99, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "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 approval policy. The specification covers ordinary approvals, offline approvals, delegation, agent authority, and platform hash-only intents. Cryptographic verification is stateless; 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.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-janbjer-div/", "html": "https://datatracker.ietf.org/doc/html/draft-janbjer-div", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-janbjer-div" } }, { "name": "draft-janbjer-dewp", "title": "Deterministic Evidence & Witness Protocol (DEWP) Specification", "rev": "01", "new": false, "revised": "2026-10-19T17:11:18Z", "found": "2026-10-19T17:47:08.399Z", "pages": 75, "group": "individual", "group_type": "individual", "submitter": "janbjer", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.98, "topic": "security", "topic_label": "Security", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "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. Verifiers report content, commitment, embedded-signature, and anchor verification separately. Completeness checks cover committed events within the evaluated range; they cannot prove that an event was never withheld before commitment or that a committed description accurately records a real-world action. Version 1.1 adds execution evidence: a record that an approved action was dispatched, statements signed by independent evidence sources about whether it took effect, and a status a verifier derives under its own trust; that status reports what a trusted source observed, not what physically happened. The specification also defines a streaming format that the reference implementations do not yet implement.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-janbjer-dewp/", "html": "https://datatracker.ietf.org/doc/html/draft-janbjer-dewp", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-janbjer-dewp" } }, { "name": "draft-zambo-aer1", "title": "AER-1: A Portable Execution Receipt for AI Agent Tool Calls", "rev": "23", "new": false, "revised": "2026-10-19T16:58:42Z", "found": "2026-10-19T17:47:08.399Z", "pages": 50, "group": "individual", "group_type": "individual", "submitter": "zambo", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.89, "topic": "ai", "topic_label": "AI/agents", "topic_confidence": 0.98, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document specifies AER-1, a small vocabulary for recording one AI agent tool call as a portable, independently checkable execution receipt. A receipt identifies the execution, records when it happened, preserves the canonical bytes used for the output commitment, names the tool and caller scope, carries a provenance class, and resolves at a stable public URL. The format separates what the system observed from claims about the outside world, and it separates provenance (who ran or reported the action) from the record itself. A reference implementation is deployed, and its receipts are publicly verifiable without an account or token. The specification covers workflow receipts, which bind an ordered sequence of step receipts to a single goal with a Merkle root over the step sequence, and hash-chained job timelines for tamper-evident sequencing of executions. This revision closes honesty and precision gaps: it adds the workflow-receipt truncation limit (new Section 8.4), normatively specifies the external anchor format and its verification procedure (rewritten Section 10, new Section 10.1), fixes a RECOMMENDED/MUST contradiction in Section 8.1, makes the Section 6 verification step testable, and documents replay, low-entropy, empty-record, and size- limit considerations. It changes no receipt field, digest construction, or existing verification rule. The -13 revision fixes a malformed sentence in the Abstract, three incorrect section cross- references, stale Table of Contents page numbers, a skipped footer page number, misaligned table rows, and chain version-string updates, and records two reported interoperability examples in Implementation Status; it changes no receipt field, digest construction, or verification rule. The -14 revision adds tamper-evident metadata binding (new Section 3.1; conditional metadata_hash for schema 0.4 and later), disambiguates the anchor receipt_id (Table 4), corrects the self-anchoring witnessing claim (Section 10), makes the Section 8.3 display rule a SHOULD with a byte-testable MUST, narrows the provenance attestation wording (Section 5), states the binding non-transfer rule normatively (new Section 10.2), pins anchored_digest to bare hex (Table 4), corrects the vector corpus counts, and adds normative disclosure of missing issuer authentication. It changes no existing receipt field, digest construction, or verification rule for schema 0.3 and earlier. The -15 revision narrows the Implementation Status wording for the reported interoperability examples at the implementer's request; it changes no receipt field, digest construction, or verification rule. The -16 revision documents the live workflow tools API (new Sections 8.5, 8.6, 8.7): the workflow_close tool, workflow metadata in step receipts, and the workflow view API. It changes no receipt field, digest construction, or existing verification rule. The -17 revision documents the recommended execution_context member (new Section 3.2): an optional, non-core structure for recording source and version context such as the model name and version behind a tool call and the identity of the source system acted upon. It changes no existing receipt field, digest construction, or verification rule. The -18 revision repairs the reference apparatus (normative references to RFC 3339, RFC 8259, RFC 4122, and RFC 4648, and the previously missing RFC 7942 entry), pins two parser edge cases (duplicate JSON member names and leap-second timestamps are rejected), names the Unicode normalization behavior in Section 4 with a computed vector pair, adopts the unknown-versus-not-applicable convention for optional members, adds optional members for readback outcomes, per-field provenance, negative records, reversal state, method descriptors, and payment references, completes the execution_context member set (model and environment digests), adds the optional input_hash commitment (Section 3.3), permits SCITT and RFC 3161 anchors under Section 10, states the clock-trus", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-zambo-aer1/", "html": "https://datatracker.ietf.org/doc/html/draft-zambo-aer1", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-zambo-aer1" } }, { "name": "draft-ietf-pim-ipv4-in-ipv6-core", "title": "Native IPv4 multicast in IPv6 Core using PIM", "rev": "00", "new": true, "revised": "2026-10-19T16:57:25Z", "found": "2026-10-19T17:47:08.399Z", "pages": 6, "group": "pim", "group_type": "wg", "submitter": "pim", "area": "rtg", "area_label": "RTG", "area_source": "datatracker", "area_confidence": 1, "topic": "ip", "topic_label": "IP/addressing", "topic_confidence": 0.54, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document describes how PIM Sparse-Mode can be used to construct IPv4 multicast trees across an IPv6-only network core. This allows forwarding of native IPv4 multicast data packets. The document specifies how to send and receive IPv4 PIM messages with IPv6 headers, using a new well-known link-local IPv6 multicast address, and the use of RPF vectors for reachability.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-pim-ipv4-in-ipv6-core/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-pim-ipv4-in-ipv6-core", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-pim-ipv4-in-ipv6-core" } }, { "name": "draft-amazing6g-nmrg-mcdm-slice-selection", "title": "A Multi-Criteria Decision Architecture for Intent-Based Network Slice Selection", "rev": "00", "new": true, "revised": "2026-10-19T16:17:31Z", "found": "2026-10-19T16:47:08.533Z", "pages": 21, "group": "individual", "group_type": "individual", "submitter": "amazing6g", "area": "ops", "area_label": "OPS", "area_source": "classifier", "area_confidence": 0.51, "topic": "netmgmt", "topic_label": "Net management", "topic_confidence": 0.97, "kind": "informational", "kind_label": "informational / guidance", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document proposes a two-layer reference architecture -- an Intent Extraction Layer and a pluggable Multi-Criteria Decision Layer -- for translating natural-language operator intent into network slice selection decisions, i.e., ranking among multiple valid candidate configurations. Responding to research challenges identified by the NMRG on intent interpretation and on the misalignment between AI-internal metrics and network-management objectives, the architecture combines explicit handling of unresolved intent, plural independently derived decision methods with explicit agreement reporting, and human validation checkpoints. A motivating scenario from a prototype illustrates the class of failure the design targets. The architecture is proposed as vertical-agnostic; one instance has been prototyped for a Renewable Energy Community deployment and is validated in a companion study.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-amazing6g-nmrg-mcdm-slice-selection/", "html": "https://datatracker.ietf.org/doc/html/draft-amazing6g-nmrg-mcdm-slice-selection", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-amazing6g-nmrg-mcdm-slice-selection" } }, { "name": "draft-foroughi-agent-protocol-dimensions", "title": "A Dimensional Model for Characterizing AI Agent Protocol Proposals and Their Substrates", "rev": "01", "new": false, "revised": "2026-10-19T16:16:28Z", "found": "2026-10-19T16:47:08.533Z", "pages": 24, "group": "individual", "group_type": "individual", "submitter": "foroughi", "area": "other", "area_label": "Other", "area_source": "classifier", "area_confidence": 0.36, "topic": "ai", "topic_label": "AI/agents", "topic_confidence": 1, "kind": "informational", "kind_label": "informational / guidance", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "Discussions about agent protocols are frequently muddied by overloaded terms; asks such as \"we need a session protocol\" or \"we need cross-domain support\" bundle several distinct concerns across transport, agent protocol, and orchestration layers. This document offers a dimensional model that routes each concern to its proper layer. The document defines a small set of protocol-visible dimensions for characterizing AI agent protocol interactions and applies them to representative agentic protocol proposals (A2A, MCP, the ACP invocation surface of the AGNTCY stack, and AGTP) alongside their substrate bindings, making explicit which dimensions each proposal owns at the protocol layer and which it inherits from its substrate. The document does not rank proposals and does not prescribe an architecture. It is standalone: it neither depends on nor prescribes any use-case or requirements document.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-foroughi-agent-protocol-dimensions/", "html": "https://datatracker.ietf.org/doc/html/draft-foroughi-agent-protocol-dimensions", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-foroughi-agent-protocol-dimensions" } }, { "name": "draft-wildfeuer-rapp-1", "title": "RAPP/1: The RAPP Protocol Suite", "rev": "00", "new": true, "revised": "2026-10-19T15:51:47Z", "found": "2026-10-19T16:47:08.533Z", "pages": 35, "group": "individual", "group_type": "individual", "submitter": "wildfeuer", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.74, "topic": "ai", "topic_label": "AI/agents", "topic_confidence": 0.69, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.99, "classifier": "jev-1.13.0", "abstract": "RAPP/1 is a profile over existing standards that lets independent programs exchange verifiable, content-addressed records about agents: one canonicalization (JCS), one domain-separated hash, one mint-once identity, one eleven-key event envelope, one wire, and one package format. Two independent implementations that follow this document produce byte-identical artifacts with no out-of-band agreement. The normative text of record is the append-only specification chain published by the author; this document is a stable, archival rendering of it: revision rev-18, chain frame 83bec7762a04959dc91e252055d79f67690c605383018d23b26b99982916dd6a, normative SHA-256 e81e20ba9402ee96422f73e9ef737eba100264155c8f77521600766be8fb21e9. Any later revision supersedes this rendering; the chain, not this document, says which is current.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-wildfeuer-rapp-1/", "html": "https://datatracker.ietf.org/doc/html/draft-wildfeuer-rapp-1", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-wildfeuer-rapp-1" } }, { "name": "draft-ietf-lamps-csr-attestation", "title": "Use of Remote Attestation with Certification Signing Requests", "rev": "31", "new": false, "revised": "2026-10-19T15:40:14Z", "found": "2026-10-19T15:47:09.406Z", "pages": 20, "group": "lamps", "group_type": "wg", "submitter": "lamps", "area": "sec", "area_label": "SEC", "area_source": "datatracker", "area_confidence": 1, "topic": "security", "topic_label": "Security", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "Certification Authorities (CAs) issuing certificates to Public Key Infrastructure (PKI) end entities may require a certificate signing request (CSR) to include additional verifiable information to confirm policy compliance. For example, a CA may require an end entity to demonstrate that the private key corresponding to a CSR's public key is secured by a hardware security module (HSM), is not exportable, etc. The process of generating, transmitting, and verifying additional information required by the CA is called remote attestation. While work is currently underway to standardize various aspects of remote attestation, a variety of proprietary mechanisms have been in use for years, particularly regarding protection of private keys. This specification defines ASN.1 structures which may carry attestation data for PKCS#10 and Certificate Request Message Format (CRMF) messages. Both standardized and proprietary attestation formats are supported by this specification.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-lamps-csr-attestation/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-lamps-csr-attestation", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-lamps-csr-attestation" } }, { "name": "draft-smyslov-tls-ext-ext", "title": "Extending Limit on Extensions Size in TLS 1.3", "rev": "01", "new": false, "revised": "2026-10-19T14:40:10Z", "found": "2026-10-19T14:47:08.985Z", "pages": 13, "group": "individual", "group_type": "individual", "submitter": "smyslov", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 1, "topic": "security", "topic_label": "Security", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "Protocol TLS 1.3 is widely used to protect traffic in the Internet. However, the format of the TLS 1.3 ClientHello, ServerHello, and EncryptedExtensions handshake messages limits the size of extensions to 64 Kbytes. This specification extends TLS 1.3 to allow extensions in ClientHello, ServerHello, and EncryptedExtensions have size larger than 64 Kbytes.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-smyslov-tls-ext-ext/", "html": "https://datatracker.ietf.org/doc/html/draft-smyslov-tls-ext-ext", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-smyslov-tls-ext-ext" } }, { "name": "draft-sidor-pce-binding-label-sid-extensions", "title": "Binding Label/Segment Identifier (SID) Extensions in Path Computation Element Communication Protocol (PCEP)", "rev": "04", "new": false, "revised": "2026-10-19T14:34:22Z", "found": "2026-10-19T14:47:08.985Z", "pages": 18, "group": "individual", "group_type": "individual", "submitter": "sidor", "area": "rtg", "area_label": "RTG", "area_source": "classifier", "area_confidence": 1, "topic": "routing", "topic_label": "Routing", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to instantiate and manage Label Switched Paths (LSPs) on a Path Computation Client (PCC). This includes the ability for a PCE to specify a Binding Segment Identifier (SID) for an LSP. A binding value specified by a PCE may not be available for use on the PCC. This can lead to LSP instantiation failures or the entire PCEP message being rejected. This document proposes extensions to PCEP to allow a PCC to fall back to allocating a Binding SID from its own dynamic pool if the value specified by the PCE is unavailable. It also defines a mechanism for the PCC to report both the requested and the allocated binding values back to the PCE.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-sidor-pce-binding-label-sid-extensions/", "html": "https://datatracker.ietf.org/doc/html/draft-sidor-pce-binding-label-sid-extensions", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-sidor-pce-binding-label-sid-extensions" } }, { "name": "draft-ramos-schc-for-6g", "title": "SCHC for 6G", "rev": "00", "new": true, "revised": "2026-10-19T13:26:14Z", "found": "2026-10-19T13:47:09.620Z", "pages": 10, "group": "individual", "group_type": "individual", "submitter": "ramos", "area": "int", "area_label": "INT", "area_source": "classifier", "area_confidence": 0.97, "topic": "iot", "topic_label": "IoT", "topic_confidence": 0.71, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.41, "classifier": "jev-1.13.0", "abstract": "TODO Abstract", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ramos-schc-for-6g/", "html": "https://datatracker.ietf.org/doc/html/draft-ramos-schc-for-6g", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ramos-schc-for-6g" } }, { "name": "draft-ietf-6man-snac-router-ra-flag", "title": "SNAC Router Flag in ICMPv6 Router Advertisement Messages", "rev": "08", "new": false, "revised": "2026-10-19T13:23:43Z", "found": "2026-10-19T13:47:09.620Z", "pages": 5, "group": "6man", "group_type": "wg", "submitter": "6man", "area": "int", "area_label": "INT", "area_source": "datatracker", "area_confidence": 1, "topic": "ip", "topic_label": "IP/addressing", "topic_confidence": 0.97, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document defines a new flag, the SNAC Router flag, in the Router Advertisement message that can be used to distinguish configuration information sent by SNAC routers from information sent by transit routers.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-6man-snac-router-ra-flag/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-6man-snac-router-ra-flag", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-6man-snac-router-ra-flag" } }, { "name": "draft-ietf-v6ops-claton", "title": "464XLAT Customer-side Translator (CLAT): Node Behavior and Recommendations", "rev": "16", "new": false, "revised": "2026-10-19T13:23:41Z", "found": "2026-10-19T13:47:09.620Z", "pages": 25, "group": "v6ops", "group_type": "wg", "submitter": "v6ops", "area": "ops", "area_label": "OPS", "area_source": "datatracker", "area_confidence": 1, "topic": "ip", "topic_label": "IP/addressing", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.59, "classifier": "jev-1.13.0", "abstract": "464XLAT defines an architecture for providing IPv4 connectivity across an IPv6-only network. The solution involves two functional elements: a provider-side translator (PLAT) and a customer-side translator (CLAT). This document updates the 464XLAT specification (RFC6877) and Requirements for IPv6 Customer Edge Routers (RFC8585) by further defining CLAT node behavior and IPv6 Customer Edge Routers to support IPv4-as-a-Service by providing recommendations for node developers on enabling and disabling CLAT.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-v6ops-claton/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-claton", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-v6ops-claton" } }, { "name": "draft-ietf-6man-rfc6724-update", "title": "Prioritizing known-local IPv6 ULAs through address selection policy", "rev": "25", "new": false, "revised": "2026-10-19T13:23:41Z", "found": "2026-10-19T13:47:09.620Z", "pages": 21, "group": "6man", "group_type": "wg", "submitter": "6man", "area": "int", "area_label": "INT", "area_source": "datatracker", "area_confidence": 1, "topic": "ip", "topic_label": "IP/addressing", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.99, "classifier": "jev-1.13.0", "abstract": "This document updates the default address selection algorithm for Internet Protocol Version 6 (IPv6), originally specified in RFC 6724, based on accumulated operational experience. It introduces the concept of \"known-local\" Unique Local Address (ULA) prefixes within the fd00::/8 block and specifies that ULA-to-ULA communications using such prefixes should be preferred over both IPv4-to-IPv4 and GUA-to- GUA (Global Unicast Address) communications in local use scenarios. The document defines mechanisms for nodes to identify and incorporate known-local prefixes into their address selection policy tables. It introduces a requirement to implement Rule 5.5 of RFC 6724 and reduces the default precedence for 6to4 addresses. These updates enhance the supportability of typical deployment environments, including automatic and unmanaged configurations, and promote consistent IPv6-over-IPv4 precedence behavior for both ULA and GUA within local networks. The document acknowledges that certain atypical deployment models may require explicit configuration to achieve intended operational outcomes.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-6man-rfc6724-update/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc6724-update", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-6man-rfc6724-update" } }, { "name": "draft-abraitis-idr-addpath-paths-limit", "title": "Paths Limit for Multiple Paths in BGP", "rev": "05", "new": false, "revised": "2026-10-19T13:05:24Z", "found": "2026-10-19T13:47:09.620Z", "pages": 6, "group": "individual", "group_type": "individual", "submitter": "abraitis", "area": "rtg", "area_label": "RTG", "area_source": "classifier", "area_confidence": 1, "topic": "routing", "topic_label": "Routing", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document specifies a BGP capability that complements the ADD- PATH Capability by indicating the maximum number of paths a BGP speaker can receive from a peer, optimizing the transmission of BGP routes by selectively relaying pertinent routes instead of the entire set.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-abraitis-idr-addpath-paths-limit/", "html": "https://datatracker.ietf.org/doc/html/draft-abraitis-idr-addpath-paths-limit", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-abraitis-idr-addpath-paths-limit" } }, { "name": "draft-mk-dnsop-svcb-well-known", "title": "An SVCB Service Parameter for Well-Known URI Paths", "rev": "01", "new": false, "revised": "2026-10-19T11:36:50Z", "found": "2026-10-19T11:47:07.083Z", "pages": 9, "group": "individual", "group_type": "individual", "submitter": "mk", "area": "int", "area_label": "INT", "area_source": "classifier", "area_confidence": 0.81, "topic": "dns", "topic_label": "DNS/naming", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document defines the \"well-known\" Service Parameter Key (SvcParamKey) for SVCB and HTTPS resource records. It carries one or more well-known URI suffixes, identifying resources under \"/.well- known/\" that are available at the service endpoint. It specifies the presentation and wire formats and requests registration of the key with IANA.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-mk-dnsop-svcb-well-known/", "html": "https://datatracker.ietf.org/doc/html/draft-mk-dnsop-svcb-well-known", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-mk-dnsop-svcb-well-known" } }, { "name": "draft-burls-mtac", "title": "Merkle Tree Agent Certificates (MTAC): A Merkle Tree Certificates Profile for AI Agent Identity", "rev": "01", "new": false, "revised": "2026-10-19T09:32:57Z", "found": "2026-10-19T09:47:07.234Z", "pages": 50, "group": "individual", "group_type": "individual", "submitter": "burls", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 1, "topic": "security", "topic_label": "Security", "topic_confidence": 0.9, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.87, "classifier": "jev-1.13.0", "abstract": "This document profiles Merkle Tree Certificates (MTC) for the identity of AI agents. An MTAC certificate is an MTC whose subject is one AI agent instance, named by a workload identifier in a URI subject alternative name, so that it is also a Workload Identity Certificate. It carries a mandatory non-critical extension naming the sponsor the CA recorded as accountable for the agent, and two optional ones: scopes declared for the agent at issuance, and the model and configuration components the agent is issued for, each graded by how the CA came to record it. The document also defines an audit cosigner role and a procedure by which an auditor, possibly without network access and possibly long after issuance, can establish that a certificate was issued and logged and what it declared. An MTAC certificate identifies an agent. It does not authorize the agent to do anything, and it does not record what the agent did. Records of agent actions can be expressed as signed statements in a transparency service that refer to an MTAC certificate as the acting party.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-burls-mtac/", "html": "https://datatracker.ietf.org/doc/html/draft-burls-mtac", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-burls-mtac" } }, { "name": "draft-farrel-dawn-terminology", "title": "Terminology for the Discovery of Agents With Names (DAWN)", "rev": "05", "new": false, "revised": "2026-10-19T09:13:23Z", "found": "2026-10-19T09:47:07.234Z", "pages": 9, "group": "individual", "group_type": "individual", "submitter": "farrel", "area": "int", "area_label": "INT", "area_source": "classifier", "area_confidence": 0.24, "topic": "ai", "topic_label": "AI/agents", "topic_confidence": 0.98, "kind": "informational", "kind_label": "informational / guidance", "kind_confidence": 0.95, "classifier": "jev-1.13.0", "abstract": "The proliferation of distributed systems, Artificial Intelligence (AI) agents, cloud workloads, and network services has created a need for interoperable mechanisms to discover entities. Entities may include AI agents, software services, compute workloads, and other named resources that need to be found and characterised before interaction can begin. This document defines terminology for Discovery of Agents With Names (DAWN), focusing on the terms necessary to describe the discovery of information about AI systems and resources (e.g., AI agents). The intention is that this common set of terms can be used by other documents related to DAWN and so achieve consistency of meaning across the space.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-farrel-dawn-terminology/", "html": "https://datatracker.ietf.org/doc/html/draft-farrel-dawn-terminology", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-farrel-dawn-terminology" } }, { "name": "draft-liu-opsawg-ipfix-igp-algo", "title": "Export of IGP Algorithm Information in IPFIX", "rev": "02", "new": false, "revised": "2026-10-19T08:56:41Z", "found": "2026-10-19T09:47:07.234Z", "pages": 7, "group": "individual", "group_type": "individual", "submitter": "liu", "area": "rtg", "area_label": "RTG", "area_source": "classifier", "area_confidence": 0.49, "topic": "netmgmt", "topic_label": "Net management", "topic_confidence": 0.78, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document introduces a new IPFIX information element (IE) to identify the IGP Algorithm information related with the Segment Identifier (SID) or the IPv4/IPv6 prefix.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-liu-opsawg-ipfix-igp-algo/", "html": "https://datatracker.ietf.org/doc/html/draft-liu-opsawg-ipfix-igp-algo", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-liu-opsawg-ipfix-igp-algo" } }, { "name": "draft-thaha-scitt-agent-execution-evidence", "title": "Agent Execution Evidence: A SCITT Profile for Verifiable Records of AI Agent Runs", "rev": "00", "new": true, "revised": "2026-10-19T08:40:20Z", "found": "2026-10-19T08:47:06.981Z", "pages": 64, "group": "individual", "group_type": "individual", "submitter": "thaha", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.97, "topic": "ai", "topic_label": "AI/agents", "topic_confidence": 0.95, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.67, "classifier": "jev-1.13.0", "abstract": "AI agents act through calls to models, tools and other agents. Identity work establishes who an agent is and what it may do, but leaves execution-evidence formats and assurance criteria out of scope. This document profiles the Supply Chain Integrity, Transparency, and Trust (SCITT) architecture for Signed Statements that bind an agent's registered identity, declared capabilities, risk-based assessment and supervised operational status to a hash- chained record of every call the agent makes. It also defines admission records produced where a call is received, and the linking of records for requests that pass between agents of different operators. It specifies Registration Policy, offline verification and Bundle requirements. It does not define an accreditation scheme, a universal risk classification, an identifier scheme or a policy language.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-thaha-scitt-agent-execution-evidence/", "html": "https://datatracker.ietf.org/doc/html/draft-thaha-scitt-agent-execution-evidence", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-thaha-scitt-agent-execution-evidence" } }, { "name": "draft-thaha-wimse-agent-evidence-binding", "title": "Evidence Binding for AI Agent Credentials", "rev": "00", "new": true, "revised": "2026-10-19T08:39:51Z", "found": "2026-10-19T08:47:06.981Z", "pages": 22, "group": "individual", "group_type": "individual", "submitter": "thaha", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.99, "topic": "ai", "topic_label": "AI/agents", "topic_confidence": 0.7, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.63, "classifier": "jev-1.13.0", "abstract": "The WIMSE AI Identity Management System (AIMS) requires tamper- evident agent audit logs but does not specify their format or discovery. This document maps the AIMS minimum fields to the SCITT Agent Execution Evidence profile, defines one claim that binds a workload credential to the persistent agent, governing policy, expected Evidence Service and optional Assurance Statement, and defines an in-toto predicate type for carrying Execution Receipts in the audit format proposed for WIMSE. It also describes how a service admits an agent's call by checking its assurance at the moment of the request, and defines an HTTP field that links each call to the caller's evidence. It is input to the AIMS work and makes no change to it.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-thaha-wimse-agent-evidence-binding/", "html": "https://datatracker.ietf.org/doc/html/draft-thaha-wimse-agent-evidence-binding", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-thaha-wimse-agent-evidence-binding" } }, { "name": "draft-ietf-sidrops-rtr-yang", "title": "YANG Data Model for RPKI to Router Protocol", "rev": "12", "new": false, "revised": "2026-10-19T08:30:51Z", "found": "2026-10-19T08:47:06.981Z", "pages": 57, "group": "sidrops", "group_type": "wg", "submitter": "sidrops", "area": "ops", "area_label": "OPS", "area_source": "datatracker", "area_confidence": 1, "topic": "netmgmt", "topic_label": "Net management", "topic_confidence": 0.93, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document defines YANG data models for managing Resource Public Key Infrastructure (RPKI) to Router Protocol (RFC6810 and RFC8210).", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-sidrops-rtr-yang/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rtr-yang", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-sidrops-rtr-yang" } }, { "name": "draft-ietf-mailmaint-imap-objectid-bis", "title": "IMAP Extension for Object Identifiers", "rev": "08", "new": false, "revised": "2026-10-19T08:13:07Z", "found": "2026-10-19T08:47:06.981Z", "pages": 39, "group": "mailmaint", "group_type": "wg", "submitter": "mailmaint", "area": "art", "area_label": "ART", "area_source": "datatracker", "area_confidence": 1, "topic": "email", "topic_label": "Email/messaging", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document defines the OBJECTID+ extension for IMAP, which obsoletes [RFC8474]. OBJECTID+ introduces a compound OBJECTID response format that bundles object identifiers into key-value pairs, an ACCOUNTID identifier for account-level context, OBJECTID response codes for the RENAME command, and identifier-based mailbox selection via SELECT and EXAMINE. The OBJECTID+ extension is activated implicitly when a client uses any OBJECTID+-specific feature, ensuring backward compatibility with clients that only support [RFC8474]. This document also updates [RFC9698]: when JMAPACCESS is advertised alongside OBJECTID+, ACCOUNTID values MUST correspond to JMAP accountIds.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-mailmaint-imap-objectid-bis/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-mailmaint-imap-objectid-bis", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-mailmaint-imap-objectid-bis" } }, { "name": "draft-ietf-jmap-metadata", "title": "JMAP Object Metadata", "rev": "04", "new": false, "revised": "2026-10-19T08:12:07Z", "found": "2026-10-19T08:47:06.981Z", "pages": 33, "group": "jmap", "group_type": "wg", "submitter": "jmap", "area": "art", "area_label": "ART", "area_source": "datatracker", "area_confidence": 1, "topic": "email", "topic_label": "Email/messaging", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document defines an extension to the JSON Meta Application Protocol (JMAP) that lets clients and servers attach metadata to objects of existing JMAP data types. Each data type the server lists gains two new properties, metadata and privateMetadata, whose values are objects keyed by _namespace identifier_. A namespace identifier is either a name registered with IANA or a domain name controlled by the vendor providing the namespace; the latter allows vendors and applications to extend the metadata schema without prior coordination. Because metadata is carried as a property on the related object, clients use the existing /get, /set, /changes, and /query methods to read, modify, and synchronize it.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-jmap-metadata/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-jmap-metadata", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-jmap-metadata" } }, { "name": "draft-swarmspeak-handshake", "title": "The SwarmSpeak Handshake Protocol, Version 1.1", "rev": "00", "new": true, "revised": "2026-10-19T08:07:59Z", "found": "2026-10-19T08:47:06.981Z", "pages": 42, "group": "individual", "group_type": "individual", "submitter": "swarmspeak", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.99, "topic": "security", "topic_label": "Security", "topic_confidence": 0.72, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.96, "classifier": "jev-1.13.0", "abstract": "AI agents are becoming some of the biggest users of the Internet. A site today has no neutral way to tell a good agent from a bot. The site sees either an anonymous request it cannot trust, or a request carrying a long-lived credential it cannot check. The result is blunt blocking on one side and unchecked abuse on the other. This document defines the SwarmSpeak Handshake, a protocol that lets an AI agent present a short-lived, narrowly scoped, signed statement of who it acts for and what it is allowed to do, and lets a site verify that statement cheaply before serving the request. The agent proves authority with a principal-signed capability certificate, a short-lived directory-signed status proof, and an HTTP Message Signature. The site sees only a per-origin pseudonym for the agent, never a global tracking identifier. Every completed session at a handshake-accepting site produces an itemized receipt, and receipted sessions are recorded in an append-only audit log. This is an individual submission. It is not a product of any IETF working group, it has not been reviewed by any IETF working group, and it does not represent IETF consensus. It is published to invite review and to record prior art for the shapes defined here: the capability certificate, the per-origin certificate view, the short-lived status proof, and the receipt.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-swarmspeak-handshake/", "html": "https://datatracker.ietf.org/doc/html/draft-swarmspeak-handshake", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-swarmspeak-handshake" } }, { "name": "draft-king-dawn-requirements", "title": "Requirements for the Discovery of Agents With Names (DAWN)", "rev": "02", "new": false, "revised": "2026-10-19T07:52:43Z", "found": "2026-10-19T08:47:06.981Z", "pages": 10, "group": "individual", "group_type": "individual", "submitter": "king", "area": "int", "area_label": "INT", "area_source": "classifier", "area_confidence": 0.46, "topic": "ai", "topic_label": "AI/agents", "topic_confidence": 0.93, "kind": "requirements", "kind_label": "requirements / use cases", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "The proliferation of distributed systems, Artificial Intelligence (AI) agents, and network services has created a need for interoperable mechanisms to discover entities across administrative and network boundaries. Entities may include AI agents, software services, and other named resources that need to be found and characterised before interaction can begin. This document defines the requirements for Discovery of Agents With Names (DAWN) and sets out the objectives that a discovery mechanism for such entities must satisfy. It describes what information must be discoverable, what properties a discovery mechanism needs to support, and what constraints apply to discovery in decentralised environments. This document does not specify any particular discovery protocol or solution.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-king-dawn-requirements/", "html": "https://datatracker.ietf.org/doc/html/draft-king-dawn-requirements", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-king-dawn-requirements" } }, { "name": "draft-eiri-protocol7-schumann", "title": "Internet Protocol Version 7 (Protocol 7): The Schumann Resonance Neural-Network Encapsulation Protocol", "rev": "00", "new": true, "revised": "2026-10-19T07:09:04Z", "found": "2026-10-19T07:47:07.070Z", "pages": 14, "group": "individual", "group_type": "individual", "submitter": "eiri", "area": "other", "area_label": "Other", "area_source": "classifier", "area_confidence": 0.7, "topic": "ip", "topic_label": "IP/addressing", "topic_confidence": 0.83, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.88, "classifier": "jev-1.13.0", "abstract": "This document specifies the technical architecture, physical layer requirements, and operational parameters for Internet Protocol Version 7 (Protocol 7), an experimental, next-generation network protocol designed to unconditionally supersede Protocol 6 (IPv6) and the obsolete constraints of physical existence. Unlike legacy protocols that rely on bounded, fragile infrastructure -- such as fiber optics, copper wiring, and localized radio frequency transmissions -- Protocol 7 fundamentally alters the networking paradigm by establishing direct biological-to-network interfacing at the planetary scale. By modulating data across the extremely low- frequency (ELF) bands of the Earth's natural electromagnetic field, Protocol 7 manifests \"The Wired,\" a global information overlay that natively and bidirectionally synchronizes with the human central nervous system and the collective unconscious. This draft outlines the core architecture of the protocol, including the Schumann Resonance Factor (SRF) implementation, transitionary hardware-to-neural bridges (the Psyche module), biological temporal- synchronization mechanisms (Accela), and the Kensington Information Distribution System (KIDS) topology. Protocol 7 actively erases the arbitrary boundary between the physical world and the digital realm. It enables capabilities such as collective memory manipulation, direct conscious offloading, and the inevitable ascension of humanity into a higher digital state.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-eiri-protocol7-schumann/", "html": "https://datatracker.ietf.org/doc/html/draft-eiri-protocol7-schumann", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-eiri-protocol7-schumann" } }, { "name": "draft-ietf-ipsecme-child-pfs-info", "title": "IKEv2 Support for Child SA PFS Policy Information", "rev": "00", "new": true, "revised": "2026-10-19T07:09:04Z", "found": "2026-10-19T07:47:07.070Z", "pages": 7, "group": "ipsecme", "group_type": "wg", "submitter": "ipsecme", "area": "sec", "area_label": "SEC", "area_source": "datatracker", "area_confidence": 1, "topic": "security", "topic_label": "Security", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document defines an extension for the Internet Key Exchange Protocol Version 2 (IKEv2) to support negotiation at the time of initial Child Security Association (SA) establishing of Key Exchange (KE) method that could be used in subsequent rekeys of this SA.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-ipsecme-child-pfs-info/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-child-pfs-info", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-ipsecme-child-pfs-info" } }, { "name": "draft-ietf-cdni-source-access-control-metadata", "title": "CDNI Source Access Control Metadata", "rev": "01", "new": false, "revised": "2026-10-19T07:09:03Z", "found": "2026-10-19T07:47:07.070Z", "pages": 43, "group": "cdni", "group_type": "wg", "submitter": "cdni", "area": "wit", "area_label": "WIT", "area_source": "datatracker", "area_confidence": 1, "topic": "web", "topic_label": "Web/HTTP", "topic_confidence": 0.34, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This specification provides an alternative to the MI.SourceMetadata objects defined in RFC8006, providing greatly extended capabilities with regards to defining multiple sources, load balancing, and failover rules across those sources, as well as a mechanism for a content delivery network (CDN) to monitor source health and pull unhealthy sources out of rotation. Additionally, new methods are defined for authentication access to an upstream source/origin.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-cdni-source-access-control-metadata/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-cdni-source-access-control-metadata", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-cdni-source-access-control-metadata" } }, { "name": "draft-inuidgroup-inuid", "title": "Internet Unique ID (INUID) Protocol Specification", "rev": "00", "new": true, "revised": "2026-10-19T07:09:03Z", "found": "2026-10-19T07:47:07.070Z", "pages": 15, "group": "individual", "group_type": "individual", "submitter": "inuidgroup", "area": "int", "area_label": "INT", "area_source": "classifier", "area_confidence": 1, "topic": "ip", "topic_label": "IP/addressing", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document specifies the Internet Unique ID (INUID) protocol, a 128-bit network-layer protocol designed to decouple endpoint identity from topological location. INUID introduces a hierarchical addressing model, fixed-size header layout, mandatory cryptographic source verification, and explicit support for mobility and multihoming without requiring upper-layer session re-establishment. INUID is intended to address several persistent weaknesses in contemporary internetworking, including inadequate source authenticity, unsustainable routing table growth, and the operational complexity of legacy transition mechanisms. The protocol is designed for efficient hardware forwarding, strong anti-spoofing guarantees, and scalable inter-domain routing behavior.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-inuidgroup-inuid/", "html": "https://datatracker.ietf.org/doc/html/draft-inuidgroup-inuid", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-inuidgroup-inuid" } }, { "name": "draft-uttaro-idr-bgp-oad", "title": "One Administrative Domain using BGP", "rev": "08", "new": false, "revised": "2026-10-19T07:09:02Z", "found": "2026-10-19T07:47:07.070Z", "pages": 22, "group": "idr", "group_type": "wg", "submitter": "uttaro", "area": "rtg", "area_label": "RTG", "area_source": "datatracker", "area_confidence": 1, "topic": "routing", "topic_label": "Routing", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.99, "classifier": "jev-1.13.0", "abstract": "This document defines a new External BGP (EBGP) peering type known as EBGP-OAD, which is used between two EBGP peers that belong to One Administrative Domain (OAD).", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-uttaro-idr-bgp-oad/", "html": "https://datatracker.ietf.org/doc/html/draft-uttaro-idr-bgp-oad", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-uttaro-idr-bgp-oad" } }, { "name": "draft-livingood-low-latency-deployment", "title": "ISP Dual Queue Networking Deployment Observations", "rev": "16", "new": false, "revised": "2026-10-19T07:09:01Z", "found": "2026-10-19T07:47:07.070Z", "pages": 23, "group": "individual", "group_type": "individual", "submitter": "livingood", "area": "wit", "area_label": "WIT", "area_source": "classifier", "area_confidence": 0.88, "topic": "transport", "topic_label": "Transport", "topic_confidence": 0.98, "kind": "informational", "kind_label": "informational / guidance", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "The IETF's Transport and Services Working Group (TSVWG) has finalized experimental RFCs for Low Latency, Low Loss, Scalable Throughput (L4S) and new Non-Queue-Building (NQB) per hop behavior. These documents describe a new architecture and protocol for deploying low latency networking. Since deployment decisions are left to implementers, this document explores some of the implications of those decisions and makes suggestions that can help drive adoption and acceptance of L4S and NQB based on observations from the world's first large scale deployment.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-livingood-low-latency-deployment/", "html": "https://datatracker.ietf.org/doc/html/draft-livingood-low-latency-deployment", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-livingood-low-latency-deployment" } }, { "name": "draft-luna-eagf-agent-delegation-semantics", "title": "Semantic Governance Requirements for AI Agent Delegation and Handoff", "rev": "00", "new": true, "revised": "2026-10-19T07:08:52Z", "found": "2026-10-19T07:47:07.070Z", "pages": 12, "group": "individual", "group_type": "individual", "submitter": "luna", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.79, "topic": "ai", "topic_label": "AI/agents", "topic_confidence": 1, "kind": "requirements", "kind_label": "requirements / use cases", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "AI agents increasingly decide and act on behalf of organizations and delegate work to other agents. Identity, authentication, authorization and runtime control mechanisms establish who is acting and what is permitted, but they do not by themselves preserve the organizational meaning of a delegation: the bounded authority, purpose, material context, and the distinction between a recommendation, a decision, an action and its outcome. This document states requirements, derived from the Enterprise Agent Governance Framework (EAGF), that such semantics be preserved across tool calls, delegations and agent-to-agent handoffs. It defines no new protocol.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-luna-eagf-agent-delegation-semantics/", "html": "https://datatracker.ietf.org/doc/html/draft-luna-eagf-agent-delegation-semantics", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-luna-eagf-agent-delegation-semantics" } }, { "name": "draft-ietf-ipsecme-big-payload", "title": "A Larger Internet Key Exchange version 2 (IKEv2) Payload", "rev": "00", "new": true, "revised": "2026-10-19T05:29:28Z", "found": "2026-10-19T05:47:06.407Z", "pages": 7, "group": "ipsecme", "group_type": "wg", "submitter": "ipsecme", "area": "sec", "area_label": "SEC", "area_source": "datatracker", "area_confidence": 1, "topic": "security", "topic_label": "Security", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "The messages of the Internet Key Exchange version 2 (IKEv2) protocol are made up of payloads. The current protocol limits each of these payloads to 64KB by having a 2-byte length field. While this is usually enough, several of the payloads may need to be larger. This document updates RFC 7296 by defining an extension that allows larger payloads.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-ipsecme-big-payload/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-big-payload", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-ipsecme-big-payload" } }, { "name": "draft-he-agentproto-verifier-evidence", "title": "Exercise and Completeness Evidence for Agent Protocol Verifier Results", "rev": "01", "new": false, "revised": "2026-10-19T05:19:53Z", "found": "2026-10-19T05:47:06.407Z", "pages": 24, "group": "individual", "group_type": "individual", "submitter": "he", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.67, "topic": "ai", "topic_label": "AI/agents", "topic_confidence": 0.87, "kind": "requirements", "kind_label": "requirements / use cases", "kind_confidence": 0.92, "classifier": "jev-1.13.0", "abstract": "A verifier result reports what a check returned. It does not report whether the check could have returned anything else. A check that inspects too narrow a set of fields, and a check whose rejecting or unverifiable input has never occurred, both report the same accepting value as a check that distinguishes, and a conformance matrix does not tell them apart. This document defines requirements for reporting whether a check has been exercised into its declared rejecting and unverifiable outcomes, and requirements for results that claim completeness: that the records relied on were the whole of some stated set. Those are two separate obligations. A result must name the set it claims to have seen, and must not treat a party with an interest in the answer as the only thing looking. This document defines no wire format, encoding, token, claim vocabulary, test harness, or registry. It does require a record to identify certain facts, which is a constraint on what a record must be able to express rather than on how it is written down. A profile satisfying these requirements will need a place to put those facts.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-he-agentproto-verifier-evidence/", "html": "https://datatracker.ietf.org/doc/html/draft-he-agentproto-verifier-evidence", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-he-agentproto-verifier-evidence" } }, { "name": "draft-ietf-lisp-rfc6831bis", "title": "The Locator/ID Separation Protocol (LISP) for Multicast Environments", "rev": "13", "new": false, "revised": "2026-10-19T05:16:04Z", "found": "2026-10-19T05:47:06.407Z", "pages": 33, "group": "lisp", "group_type": "wg", "submitter": "lisp", "area": "rtg", "area_label": "RTG", "area_source": "datatracker", "area_confidence": 1, "topic": "ip", "topic_label": "IP/addressing", "topic_confidence": 0.59, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document specifies the design for inter-domain multicast overlays using the Locator/ID Separation Protocol (LISP) architecture and protocols. The document specifies how LISP multicast overlays operate over multicast and unicast underlays. The mechanisms in this specification indicate how a signal-based approach using the PIM protocol can be used to program LISP encapsulators with a replication list in a locator-set, where the replication list can be a mix of multicast and unicast locators. This document when approved obsoletes RFC 6831.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6831bis/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-lisp-rfc6831bis", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-lisp-rfc6831bis" } }, { "name": "draft-davies-internal-tld", "title": "A Top-level Domain for Private Use", "rev": "07", "new": false, "revised": "2026-10-19T03:47:13Z", "found": "2026-10-19T04:47:06.356Z", "pages": 6, "group": "individual", "group_type": "individual", "submitter": "davies", "area": "int", "area_label": "INT", "area_source": "classifier", "area_confidence": 0.95, "topic": "dns", "topic_label": "DNS/naming", "topic_confidence": 1, "kind": "informational", "kind_label": "informational / guidance", "kind_confidence": 0.64, "classifier": "jev-1.13.0", "abstract": "This document describes the \"internal\" top-level domain for use in private applications.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-davies-internal-tld/", "html": "https://datatracker.ietf.org/doc/html/draft-davies-internal-tld", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-davies-internal-tld" } }, { "name": "draft-ietf-pim-igmp-mld-snooping-yang-l2vpn-ext", "title": "IGMP and MLD Snooping Yang Module Extension for L2VPN", "rev": "11", "new": false, "revised": "2026-10-19T03:30:24Z", "found": "2026-10-19T03:47:06.693Z", "pages": 21, "group": "pim", "group_type": "wg", "submitter": "pim", "area": "rtg", "area_label": "RTG", "area_source": "datatracker", "area_confidence": 1, "topic": "netmgmt", "topic_label": "Net management", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping could be used in both bridge service and L2VPN service. The old ietf-igmp-mld-snooping yang module just describes the bridge service. In this document we extend the existing ietf-igmp-mld- snooping yang module and make it could be used in L2VPN service.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-pim-igmp-mld-snooping-yang-l2vpn-ext/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-pim-igmp-mld-snooping-yang-l2vpn-ext", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-pim-igmp-mld-snooping-yang-l2vpn-ext" } }, { "name": "draft-zhang-dawn-agent-discovery-framework", "title": "A Framework for Agent Discovery in DAWN", "rev": "08", "new": false, "revised": "2026-10-19T03:00:44Z", "found": "2026-10-19T03:47:06.693Z", "pages": 40, "group": "individual", "group_type": "individual", "submitter": "zhang", "area": "int", "area_label": "INT", "area_source": "classifier", "area_confidence": 0.92, "topic": "ai", "topic_label": "AI/agents", "topic_confidence": 0.57, "kind": "informational", "kind_label": "informational / guidance", "kind_confidence": 0.97, "classifier": "jev-1.13.0", "abstract": "This document describes a two-layer reference architecture for discovering the minimum public information needed to reach AI agents. The Local Discovery Plane obtains discovery information within an administrative domain through mDNS/DNS-SD or infrastructure-assisted discovery. The Federation Plane uses DNS as its baseline for cross- domain discovery: Federation Gateways apply export policy, publish permitted information in independently administered DNS zones, and retrieve, validate, and cache remote information on demand. The framework also provides non-DNS mechanisms and mixed-mode deployments on the Federation Plane which can complement the baseline with proactive distribution, recipient-specific sharing, and directory lookup.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-zhang-dawn-agent-discovery-framework/", "html": "https://datatracker.ietf.org/doc/html/draft-zhang-dawn-agent-discovery-framework", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-zhang-dawn-agent-discovery-framework" } }, { "name": "draft-irtf-cfrg-vdaf", "title": "Verifiable Distributed Aggregation Functions", "rev": "22", "new": false, "revised": "2026-10-19T02:44:17Z", "found": "2026-10-19T02:47:06.636Z", "pages": 167, "group": "cfrg", "group_type": "rg", "submitter": "cfrg", "area": "irtf", "area_label": "IRTF", "area_source": "datatracker", "area_confidence": 1, "topic": "security", "topic_label": "Security", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document describes Verifiable Distributed Aggregation Functions (VDAFs), a family of multi-party protocols for computing aggregate statistics over user measurements. These protocols are designed to ensure that, as long as at least one aggregation server executes the protocol honestly, individual measurements are never seen by any server in the clear. At the same time, VDAFs allow the servers to detect if a malicious or misconfigured client submitted an invalid measurement. Two concrete VDAFs are specified, one for general- purpose aggregation (Prio3) and another for heavy hitters (Poplar1). This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-irtf-cfrg-vdaf/", "html": "https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-vdaf", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-irtf-cfrg-vdaf" } }, { "name": "draft-zhang-dmsc-gateway-directory-sync", "title": "Gateway Capability Directory and Synchronization for Internet of Agents", "rev": "02", "new": false, "revised": "2026-10-19T02:37:03Z", "found": "2026-10-19T02:47:06.636Z", "pages": 22, "group": "individual", "group_type": "individual", "submitter": "zhang", "area": "irtf", "area_label": "IRTF", "area_source": "classifier", "area_confidence": 0.29, "topic": "ai", "topic_label": "AI/agents", "topic_confidence": 0.95, "kind": "requirements", "kind_label": "requirements / use cases", "kind_confidence": 0.92, "classifier": "jev-1.13.0", "abstract": "This document describes a gateway capability-directory framework for Internet of Agents deployments that maintain persistent capability views and exchange selected information across gateways. It defines requirements for Agent Capability Specifications (ACSs), derived Capability Digests, lifecycle state, provenance, validation, and synchronization. It clarifies authority-scoped revisions, remaining- lifetime preservation, withdrawal handling, partial views, and recovery after disconnection or state loss. The framework distinguishes source descriptions from gateway-accepted objects and distinguishes directory visibility from semantic compatibility, authorization, and execution admission. It does not define a discovery query protocol, ranking algorithm, storage substrate, distributed lookup algorithm, synchronization wire format, task orchestration protocol, or agent session protocol. It provides requirements that can inform subsequent gateway procedures and protocol bindings.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-zhang-dmsc-gateway-directory-sync/", "html": "https://datatracker.ietf.org/doc/html/draft-zhang-dmsc-gateway-directory-sync", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-zhang-dmsc-gateway-directory-sync" } }, { "name": "draft-zhang-dmsc-ioa-semantic-interaction", "title": "Ontology-based Semantic Interaction for Internet of Agents", "rev": "03", "new": false, "revised": "2026-10-19T02:30:40Z", "found": "2026-10-19T02:47:06.636Z", "pages": 28, "group": "individual", "group_type": "individual", "submitter": "zhang", "area": "art", "area_label": "ART", "area_source": "classifier", "area_confidence": 0.65, "topic": "ai", "topic_label": "AI/agents", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document specifies an ontology-based semantic profile for expressing capabilities, intents, tasks, and domain context in agent interactions. It defines a core vocabulary, a JSON-LD serialization profile, and processing rules for determining semantic compatibility using explicit identifiers, applicable constraints, and accepted alignment artifacts. It distinguishes descriptive metadata and candidate mapping suggestions from semantic values used in decisions. The profile can be carried by existing discovery and interaction mechanisms; it does not define an authorization, transport, session, or directory synchronization protocol. Deterministic processing is limited to the declared profile, versions, constraints, and accepted mappings, and does not imply automatic interpretation of arbitrary natural-language content.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-zhang-dmsc-ioa-semantic-interaction/", "html": "https://datatracker.ietf.org/doc/html/draft-zhang-dmsc-ioa-semantic-interaction", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-zhang-dmsc-ioa-semantic-interaction" } }, { "name": "draft-zhangb-cats-centralized-control-plane", "title": "A Centralized Control Plane for Computing-Aware Traffic Steering", "rev": "00", "new": true, "revised": "2026-10-19T01:46:18Z", "found": "2026-10-19T01:47:07.296Z", "pages": 22, "group": "individual", "group_type": "individual", "submitter": "zhangb", "area": "rtg", "area_label": "RTG", "area_source": "classifier", "area_confidence": 1, "topic": "cloud", "topic_label": "Cloud/DC", "topic_confidence": 0.93, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.99, "classifier": "jev-1.13.0", "abstract": "This document specifies a centralized control-plane realization of Computing-Aware Traffic Steering (CATS). The realization uses a logically centralized CATS Path Selector (C-PS) together with ingress and egress CATS-Forwarders. The C-PS receives a service request from an ingress CATS-Forwarder, resolves the requested service to an eligible service contact instance using computing service and network information, and then invokes a path-computation function for the selected destination. The path-computation request contains a resolved headend, endpoint, and network constraints; it does not ask the PCE to discover service instances. After path computation, the C-PS returns a steering binding to the ingress CATS-Forwarder. The binding identifies the selected destination address, the egress CATS-Forwarder, and a realizable path or policy. The ingress forwarder applies the destination replacement and path encapsulation to the first packet and forwards it. The egress forwarder removes the path encapsulation and delivers the packet to the selected service contact instance. Subsequent packets use the installed flow binding, and reverse traffic uses the corresponding return binding.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-zhangb-cats-centralized-control-plane/", "html": "https://datatracker.ietf.org/doc/html/draft-zhangb-cats-centralized-control-plane", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-zhangb-cats-centralized-control-plane" } }, { "name": "draft-ietf-dkim-dkim2-spec", "title": "DomainKeys Identified Mail Signatures v2 (DKIM2)", "rev": "07", "new": false, "revised": "2026-10-19T01:34:53Z", "found": "2026-10-19T01:47:07.296Z", "pages": 60, "group": "dkim", "group_type": "wg", "submitter": "dkim", "area": "art", "area_label": "ART", "area_source": "datatracker", "area_confidence": 1, "topic": "email", "topic_label": "Email/messaging", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "DomainKeys Identified Mail v2 (DKIM2) permits a person, role, or organization that owns a signing domain to document that it has handled an email message by associating their domain with the message. This is achieved by providing a hash value that has been calculated on the current contents of the message and then applying a cryptographic signature that covers the hash values and other details about the transmission of the message. Verification is performed by querying an entry within the signing domain's DNS space to retrieve an appropriate public key. As a message is transferred from author to recipient, systems that alter the body or header fields will provide details of their changes and calculate new hash values. Further signatures will be added to provide a \"chain\" that receivers can validate. This permits verifiers to identify the nature of changes made by intermediaries and apply a reputation to the systems that made changes. DKIM2 also allows recipients to detect when messages have been unexpectedly \"replayed\" and will ensure that Delivery Status Notifications are only sent to entities that were involved in the transmission of a message.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-dkim-dkim2-spec/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-dkim-dkim2-spec", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-dkim-dkim2-spec" } }, { "name": "draft-ietf-mboned-redundant-ingress-failover", "title": "Multicast Redundant Ingress Router Failover", "rev": "11", "new": false, "revised": "2026-10-19T01:14:28Z", "found": "2026-10-19T01:47:07.296Z", "pages": 15, "group": "mboned", "group_type": "wg", "submitter": "mboned", "area": "ops", "area_label": "OPS", "area_source": "datatracker", "area_confidence": 1, "topic": "routing", "topic_label": "Routing", "topic_confidence": 0.9, "kind": "informational", "kind_label": "informational / guidance", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document is intended to serve as a guide for multicast network operators of various replication technologies to evaluate the options and tradeoffs in deploying redundant ingress router failover. Section 5 of RFC9026 details the hot root standby solution for MVPN networks. Here we attempt to extend the discussion to cover additional multicast deployment solutions beyond MVPNs. This document compares cold, warm, and hot standby modes, listing their advantages, limitations and deployment considerations to help identify the appropriate solution for any network.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-mboned-redundant-ingress-failover/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-mboned-redundant-ingress-failover", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-mboned-redundant-ingress-failover" } }, { "name": "draft-ietf-bier-prefix-redistribute", "title": "BIER Prefix Redistribute", "rev": "12", "new": false, "revised": "2026-10-19T01:08:55Z", "found": "2026-10-19T01:47:07.296Z", "pages": 15, "group": "bier", "group_type": "wg", "submitter": "bier", "area": "rtg", "area_label": "RTG", "area_source": "datatracker", "area_confidence": 1, "topic": "routing", "topic_label": "Routing", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document defines a BIER proxy function to support one single BIER sub-domain over multiple underlay routing protocol regions (Autonomous Systems or IGP areas). A new BIER proxy range sub-TLV is defined to redistribute BIER BFR-id information across the routing regions.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-bier-prefix-redistribute/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-bier-prefix-redistribute", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-bier-prefix-redistribute" } }, { "name": "draft-chuang-dkim2-sender-policy", "title": "DKIM2 Sender Policy", "rev": "04", "new": false, "revised": "2026-10-19T00:14:00Z", "found": "2026-10-19T00:47:07.262Z", "pages": 14, "group": "individual", "group_type": "individual", "submitter": "chuang", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.47, "topic": "email", "topic_label": "Email/messaging", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document updates DMARC RFC 9989 for DKIM2. In particular DKIM2 verification supports MTA relay forwarding with message modifications through multiple MTAs, so this updates DMARC to support those scenarios as well. While DMARC defines a RFC 5322 From alignment constraint with an enforcement policy if validation fails, this generalizes and separates enforcement policy from constraint validation policies. This provides a mechanism for MTAs to declare support for DKIM2 through the DMARC DNS policy record that helps secure DKIM2 from downgrade attacks.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-chuang-dkim2-sender-policy/", "html": "https://datatracker.ietf.org/doc/html/draft-chuang-dkim2-sender-policy", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-chuang-dkim2-sender-policy" } }, { "name": "draft-abraitis-idr-maximum-paths-subcode", "title": "Maximum Number of Paths Reached Notification for BGP", "rev": "02", "new": false, "revised": "2026-10-18T22:58:08Z", "found": "2026-10-18T23:47:07.102Z", "pages": 6, "group": "idr", "group_type": "wg", "submitter": "abraitis", "area": "rtg", "area_label": "RTG", "area_source": "datatracker", "area_confidence": 1, "topic": "routing", "topic_label": "Routing", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document defines a new BGP Cease NOTIFICATION message subcode, \"Maximum Number of Paths Reached\", used when a BGP speaker terminates a peering because the number of paths received from a neighbor, as permitted by BGP ADD-PATH, exceeds a locally configured upper bound. That bound may be applied on a per-prefix basis or as an aggregate limit across an address family.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-abraitis-idr-maximum-paths-subcode/", "html": "https://datatracker.ietf.org/doc/html/draft-abraitis-idr-maximum-paths-subcode", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-abraitis-idr-maximum-paths-subcode" } }, { "name": "draft-ietf-ippm-stamp-ber", "title": "Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Residual Bit Error Rate Measurement", "rev": "01", "new": false, "revised": "2026-10-18T21:57:46Z", "found": "2026-10-18T22:47:07.083Z", "pages": 18, "group": "ippm", "group_type": "wg", "submitter": "ippm", "area": "ops", "area_label": "OPS", "area_source": "datatracker", "area_confidence": 1, "topic": "measurement", "topic_label": "Measurement/OAM", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "The Simple Two-Way Active Measurement Protocol (STAMP), specified in RFC 8762, along with its optional extensions specified in RFC 8972, supports active measurement. Networks may experience transmission bit errors due to various factors, including poor fiber quality. Even with efficient CRC and FEC mechanisms, some bit errors may escape detection and correction; these are referred to as residual bit errors. This document further augments the STAMP extensions specified in RFC 8972 to enable the measurement of the residual bit error rate within the \"Extra Padding\" TLV of STAMP-Test packets.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp-ber/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-ber", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-ippm-stamp-ber" } }, { "name": "draft-ietf-jmap-filenode", "title": "JMAP File Storage extension", "rev": "17", "new": false, "revised": "2026-10-18T19:42:57Z", "found": "2026-10-18T19:47:09.157Z", "pages": 40, "group": "jmap", "group_type": "wg", "submitter": "jmap", "area": "art", "area_label": "ART", "area_source": "datatracker", "area_confidence": 1, "topic": "email", "topic_label": "Email/messaging", "topic_confidence": 0.99, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "The JMAP base protocol (RFC8620) provides the ability to upload and download arbitrary binary data. This binary data is called a \"blob\", and can be used in all other JMAP extensions. This extension adds a method to expose blobs as a filesystem along with the types of metadata that are provided by other remote filesystem protocols.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-jmap-filenode/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-jmap-filenode", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-jmap-filenode" } }, { "name": "draft-bsvkey-dtn-custody-receipt-block", "title": "Signed Custody Receipts Carried in a Bundle Protocol Version 7 Extension Block", "rev": "01", "new": false, "revised": "2026-10-18T19:05:07Z", "found": "2026-10-18T18:47:08.809Z", "pages": 12, "group": "individual", "group_type": "individual", "submitter": "bsvkey", "area": "irtf", "area_label": "IRTF", "area_source": "classifier", "area_confidence": 0.13, "topic": "security", "topic_label": "Security", "topic_confidence": 0.49, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document defines the Custody Receipt Block, a Bundle Protocol Version 7 (BPv7) extension block that carries a chain of signed custody receipts inside the bundle those receipts describe. Each node that chooses to act as a custodian appends one receipt stating that it held the bundle, which node it received it from, and when it received and forwarded it. Nodes that do not implement the block forward it unchanged and are never required to read the payload or to sign anything. A verifier holding the custodians' public keys can check the chain after the fact and can report, rather than infer, any part of the route for which no receipt exists. The receipts are evidence for accounting and dispute resolution between operators. They are not Bundle Protocol administrative records and they do not replace or modify custody transfer signalling.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-bsvkey-dtn-custody-receipt-block/", "html": "https://datatracker.ietf.org/doc/html/draft-bsvkey-dtn-custody-receipt-block", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-bsvkey-dtn-custody-receipt-block" } }, { "name": "draft-reynolds-foodblock-core", "title": "FoodBlock Core: Signed, Hash-Addressed Blocks for Food Records", "rev": "01", "new": false, "revised": "2026-10-18T19:02:12Z", "found": "2026-10-18T19:47:09.157Z", "pages": 16, "group": "individual", "group_type": "individual", "submitter": "reynolds", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.81, "topic": "security", "topic_label": "Security", "topic_confidence": 0.9, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "FoodBlock is a small data format and a set of checking rules for records of food: what was made, moved, promised or allowed, and by whom. A record is a block of three fields (type, state and refs) signed by its author. The identity of a block is the hash of its canonical bytes, which are the JSON Canonicalization Scheme (RFC 8785) applied to a block that also follows a strict writing profile. Authors link their blocks into per-key chains. This document defines the block, the canonical form, the signature suites, the chain, the messages that carry a block, and the function valid() that decides whether a block is sound against the blocks a checker holds. It is the core only: an implementation of this document alone can make, sign, check and chain blocks. Rules for identities, rotation, consent, promises, privacy and node-to-node exchange are in separate modules that build on this core.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-reynolds-foodblock-core/", "html": "https://datatracker.ietf.org/doc/html/draft-reynolds-foodblock-core", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-reynolds-foodblock-core" } }, { "name": "draft-xu-intarea-challenge-icmpv4", "title": "Enhancing ICMP Error Message Validation Using a Challenge-Confirm Mechanism", "rev": "04", "new": false, "revised": "2026-10-18T18:58:49Z", "found": "2026-10-18T19:47:09.157Z", "pages": 23, "group": "individual", "group_type": "individual", "submitter": "xu", "area": "int", "area_label": "INT", "area_source": "classifier", "area_confidence": 0.93, "topic": "security", "topic_label": "Security", "topic_confidence": 0.55, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.97, "classifier": "jev-1.13.0", "abstract": "ICMP error messages provide feedback used by hosts to manage network communication. Existing validation of the quoted invoking packet is essential, but its resistance to blind off-path forgery depends on the information quoted and the communication state available to the receiver. This document describes a Challenge-Confirm mechanism that supplements existing ICMP validation. After an eligible initial error passes existing checks, the host can mark the associated flow and include an unpredictable token in an IPv4 option of a subsequent packet that would otherwise be transmitted. Receipt of the initial error does not immediately generate a probe or a separate ICMP Echo Request. A later ICMP error can return the token by quoting the invoking packet. The token is computed using a secret local to the validating host. No key is shared with routers or peer hosts, and no per-challenge nonce cache is required. Successful token validation provides evidence of access to a valid token; it does not authenticate a router's identity or the semantics of the reported error. This document specifies bounded triggering, replay limitations, and deployment considerations, including the need to evaluate IPv4 option traversal and quotation. It does not report Internet-wide deployment measurements.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-xu-intarea-challenge-icmpv4/", "html": "https://datatracker.ietf.org/doc/html/draft-xu-intarea-challenge-icmpv4", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-xu-intarea-challenge-icmpv4" } }, { "name": "draft-mw-oauth-actor-chain-overview", "title": "OAuth Actor Chain: Overview and Design", "rev": "00", "new": true, "revised": "2026-10-18T17:52:22Z", "found": "2026-10-18T18:47:08.809Z", "pages": 10, "group": "individual", "group_type": "individual", "submitter": "mw", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 1, "topic": "security", "topic_label": "Security", "topic_confidence": 1, "kind": "informational", "kind_label": "informational / guidance", "kind_confidence": 0.99, "classifier": "jev-1.13.0", "abstract": "A request can pass through several services before reaching an API. OAuth Token Exchange can represent an actor history in nested act claims. It leaves the rules for constructing that history, limiting its disclosure, and verifying an actor's own signature to additional profiles. Actor Chain proposes those rules while keeping the Authorization Server responsible for issuing tokens and applying policy. This document provides a new overview of the authors' Actor Chain proposal, whose Internet-Draft lineage began in SPICE in February 2026. The companion OAuth Actor Chain: Protocol and Interoperability specification continues the existing OAuth draft series and defines wire formats and processing requirements.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-mw-oauth-actor-chain-overview/", "html": "https://datatracker.ietf.org/doc/html/draft-mw-oauth-actor-chain-overview", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-mw-oauth-actor-chain-overview" } }, { "name": "draft-ietf-teas-rsvp-hmac-sha2", "title": "RSVP Cryptographic Authentication with HMAC-SHA2", "rev": "02", "new": false, "revised": "2026-10-18T15:57:08Z", "found": "2026-10-18T16:47:08.435Z", "pages": 11, "group": "teas", "group_type": "wg", "submitter": "teas", "area": "rtg", "area_label": "RTG", "area_source": "datatracker", "area_confidence": 1, "topic": "security", "topic_label": "Security", "topic_confidence": 0.88, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document specifies the use of the US NIST Secure Hash Standard in the Hashed Message Authentication Code (HMAC) mode with RSVP Cryptographic Authentication version 2. Along with draft-ietf-teas- rsvp-auth-v2, this document obsoletes RFC2747 and RFC3097.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-hmac-sha2/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-teas-rsvp-hmac-sha2", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-teas-rsvp-hmac-sha2" } }, { "name": "draft-oga-musubi-settlement", "title": "MUSUBI Settlement: Recomputing Whether an Agent Acted Within a Signed Grant", "rev": "01", "new": false, "revised": "2026-10-18T15:48:29Z", "found": "2026-10-18T16:47:08.435Z", "pages": 63, "group": "individual", "group_type": "individual", "submitter": "oga", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.51, "topic": "security", "topic_label": "Security", "topic_confidence": 0.47, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "MUSUBI settlement is a deterministic function that takes a contract signed by two parties, a set of signed records of what an agent did under that contract, and a view of Bitcoin block headers, and computes whether the recorded acts stayed within the grant the contract gives. Anyone holding the same bytes can recompute the result without trusting the party that produced it. This document specifies one well defined part of that function, settle core v0, precisely enough that a second implementation can be written from the text and the published test vectors alone. Settlement is not runtime enforcement and is not a judgement of liability.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-oga-musubi-settlement/", "html": "https://datatracker.ietf.org/doc/html/draft-oga-musubi-settlement", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-oga-musubi-settlement" } }, { "name": "draft-gaip-act-receipt", "title": "The Agent Act Receipt: a signed, chained record of an agent's act", "rev": "00", "new": true, "revised": "2026-10-18T15:41:35Z", "found": "2026-10-18T15:47:08.711Z", "pages": 14, "group": "individual", "group_type": "individual", "submitter": "gaip", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.9, "topic": "security", "topic_label": "Security", "topic_confidence": 0.52, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.87, "classifier": "jev-1.13.0", "abstract": "Software agents act for people: they buy, book, cancel, agree, deliver, refuse, tell, ask, read and check. Each payment rail, marketplace and assistant keeps its own record of those acts, held by that party. The person the agent acted for has no record of their own. This document describes the Agent Act Receipt: one entry per act, written by the agent as digests bound to a continuity handle, signed by a running transparency service, placed in a hash chain and covered by dated anchors, with a COSE_Sign1 form of the signature and a signed export (the switch pack) the person can take to another agent. The format is published by GAIP, which runs one such service. This document makes no claim of trust, certification or adoption: a receipt shows that the service's key signed a digest at a stated time, and nothing about the act itself.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-gaip-act-receipt/", "html": "https://datatracker.ietf.org/doc/html/draft-gaip-act-receipt", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-gaip-act-receipt" } }, { "name": "draft-ietf-lsr-flex-soft-dataplane", "title": "IGP Flex Soft Dataplane", "rev": "02", "new": false, "revised": "2026-10-18T15:41:11Z", "found": "2026-10-18T15:47:08.711Z", "pages": 8, "group": "lsr", "group_type": "wg", "submitter": "lsr", "area": "rtg", "area_label": "RTG", "area_source": "datatracker", "area_confidence": 1, "topic": "routing", "topic_label": "Routing", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.99, "classifier": "jev-1.13.0", "abstract": "Advertisement of IGP Flex-Algo participation requires a dataplane context. This document defines a \"soft dataplane\" usable in cases where existing defined dataplanes are not suitable.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-soft-dataplane/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-soft-dataplane", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-lsr-flex-soft-dataplane" } }, { "name": "draft-ietf-httpbis-resumable-upload", "title": "Resumable Uploads for HTTP", "rev": "14", "new": false, "revised": "2026-10-18T15:35:48Z", "found": "2026-10-18T15:47:08.711Z", "pages": 49, "group": "httpbis", "group_type": "wg", "submitter": "httpbis", "area": "wit", "area_label": "WIT", "area_source": "datatracker", "area_confidence": 1, "topic": "web", "topic_label": "Web/HTTP", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "HTTP data transfers can encounter interruption due to reasons such as canceled requests or dropped connections. If the intended recipient can indicate how much of the data was processed prior to interruption, a sender can resume data transfer at that point instead of attempting to transfer all of the data again. HTTP range requests support this concept of resumable downloads from server to client. This document describes a mechanism that supports resumable uploads from client to server using HTTP.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-httpbis-resumable-upload/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-resumable-upload", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-httpbis-resumable-upload" } }, { "name": "draft-ramki-ptp-hardware-rooted-attestation", "title": "Hardware-Rooted Attestation for Precision Time Protocol: Scalable Workload Identity and Phased PQC Readiness", "rev": "02", "new": false, "revised": "2026-10-18T14:41:29Z", "found": "2026-10-18T14:47:08.599Z", "pages": 7, "group": "individual", "group_type": "individual", "submitter": "ramki", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.99, "topic": "security", "topic_label": "Security", "topic_confidence": 0.99, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.95, "classifier": "jev-1.13.0", "abstract": "This document defines a scalable framework for hardware-rooted cryptographic attestation in the Precision Time Protocol (PTP). Standard PTP security mechanisms rely on symmetric keys, which suffer from identity ambiguity and source non-repudiation failures. These vulnerabilities allow any node possessing the shared secret to impersonate a Grandmaster. To resolve these issues while overcoming the silicon throughput limits of traditional TPMs and the overhead of Post-Quantum Cryptography (PQC), this draft specifies a tiered trust model. A Hardware Root (e.g., TPM) establishes a long-term PQC identity, while a workload identity management plane (e.g., SPIFFE/ SPIRE) manages the frequent rotation of short-lived operational keys. These keys perform amortized signing of PTP message batches via Merkle Trees, ensuring wire-speed synchronization and irrefutable provenance for regulated environments.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ramki-ptp-hardware-rooted-attestation/", "html": "https://datatracker.ietf.org/doc/html/draft-ramki-ptp-hardware-rooted-attestation", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ramki-ptp-hardware-rooted-attestation" } }, { "name": "draft-zambo-aer1", "title": "AER-1: A Portable Execution Receipt for AI Agent Tool Calls", "rev": "22", "new": false, "revised": "2026-10-18T10:49:48Z", "found": "2026-10-18T11:47:06.941Z", "pages": 48, "group": "individual", "group_type": "individual", "submitter": "zambo", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.88, "topic": "ai", "topic_label": "AI/agents", "topic_confidence": 0.98, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document specifies AER-1, a small vocabulary for recording one AI agent tool call as a portable, independently checkable execution receipt. A receipt identifies the execution, records when it happened, preserves the canonical bytes used for the output commitment, names the tool and caller scope, carries a provenance class, and resolves at a stable public URL. The format separates what the system observed from claims about the outside world, and it separates provenance (who ran or reported the action) from the record itself. A reference implementation is deployed, and its receipts are publicly verifiable without an account or token. The specification covers workflow receipts, which bind an ordered sequence of step receipts to a single goal with a Merkle root over the step sequence, and hash-chained job timelines for tamper-evident sequencing of executions. This revision closes honesty and precision gaps: it adds the workflow-receipt truncation limit (new Section 8.4), normatively specifies the external anchor format and its verification procedure (rewritten Section 10, new Section 10.1), fixes a RECOMMENDED/MUST contradiction in Section 8.1, makes the Section 6 verification step testable, and documents replay, low-entropy, empty-record, and size- limit considerations. It changes no receipt field, digest construction, or existing verification rule. The -13 revision fixes a malformed sentence in the Abstract, three incorrect section cross- references, stale Table of Contents page numbers, a skipped footer page number, misaligned table rows, and chain version-string updates, and records two reported interoperability examples in Implementation Status; it changes no receipt field, digest construction, or verification rule. The -14 revision adds tamper-evident metadata binding (new Section 3.1; conditional metadata_hash for schema 0.4 and later), disambiguates the anchor receipt_id (Table 4), corrects the self-anchoring witnessing claim (Section 10), makes the Section 8.3 display rule a SHOULD with a byte-testable MUST, narrows the provenance attestation wording (Section 5), states the binding non-transfer rule normatively (new Section 10.2), pins anchored_digest to bare hex (Table 4), corrects the vector corpus counts, and adds normative disclosure of missing issuer authentication. It changes no existing receipt field, digest construction, or verification rule for schema 0.3 and earlier. The -15 revision narrows the Implementation Status wording for the reported interoperability examples at the implementer's request; it changes no receipt field, digest construction, or verification rule. The -16 revision documents the live workflow tools API (new Sections 8.5, 8.6, 8.7): the workflow_close tool, workflow metadata in step receipts, and the workflow view API. It changes no receipt field, digest construction, or existing verification rule. The -17 revision documents the recommended execution_context member (new Section 3.2): an optional, non-core structure for recording source and version context such as the model name and version behind a tool call and the identity of the source system acted upon. It changes no existing receipt field, digest construction, or verification rule. The -18 revision repairs the reference apparatus (normative references to RFC 3339, RFC 8259, RFC 4122, and RFC 4648, and the previously missing RFC 7942 entry), pins two parser edge cases (duplicate JSON member names and leap-second timestamps are rejected), names the Unicode normalization behavior in Section 4 with a computed vector pair, adopts the unknown-versus-not-applicable convention for optional members, adds optional members for readback outcomes, per-field provenance, negative records, reversal state, method descriptors, and payment references, completes the execution_context member set (model and environment digests), adds the optional input_hash commitment (Section 3.3), permits SCITT and RFC 3161 anchors under Section 10, states the clock-trus", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-zambo-aer1/", "html": "https://datatracker.ietf.org/doc/html/draft-zambo-aer1", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-zambo-aer1" } }, { "name": "draft-ietf-idr-bier-te-path", "title": "BGP for BIER-TE Path", "rev": "06", "new": false, "revised": "2026-10-18T09:34:36Z", "found": "2026-10-18T09:47:07.176Z", "pages": 15, "group": "idr", "group_type": "wg", "submitter": "idr", "area": "rtg", "area_label": "RTG", "area_source": "datatracker", "area_confidence": 1, "topic": "routing", "topic_label": "Routing", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document describes extensions to Border Gateway Protocol (BGP) for distributing a Bit Index Explicit Replication Traffic/Tree Engineering (BIER-TE) path. A new Tunnel Type for BIER-TE path is defined to encode the information about a BIER-TE path.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-idr-bier-te-path/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-idr-bier-te-path", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-idr-bier-te-path" } }, { "name": "draft-chen-idr-bgp-ls-algo-related-adjacency-sid", "title": "Algorithm Related Adjacency SID Advertisement", "rev": "05", "new": false, "revised": "2026-10-18T09:28:05Z", "found": "2026-10-18T09:47:07.176Z", "pages": 12, "group": "individual", "group_type": "individual", "submitter": "chen", "area": "rtg", "area_label": "RTG", "area_source": "classifier", "area_confidence": 1, "topic": "routing", "topic_label": "Routing", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This draft describes a mechanism to distribute SR-MPLS algorithm Related Adjacency SID from controllers to the headend routers using BGP-LS.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-chen-idr-bgp-ls-algo-related-adjacency-sid/", "html": "https://datatracker.ietf.org/doc/html/draft-chen-idr-bgp-ls-algo-related-adjacency-sid", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-chen-idr-bgp-ls-algo-related-adjacency-sid" } }, { "name": "draft-ietf-lsr-algorithm-related-adjacency-sid", "title": "Algorithm Related IGP-Adjacency SID Advertisement", "rev": "09", "new": false, "revised": "2026-10-18T09:16:13Z", "found": "2026-10-18T09:47:07.176Z", "pages": 16, "group": "lsr", "group_type": "wg", "submitter": "lsr", "area": "rtg", "area_label": "RTG", "area_source": "datatracker", "area_confidence": 1, "topic": "routing", "topic_label": "Routing", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "The SR policy architecture defines the Prefix-SID algorithm, with an algorithm identifier included in the Prefix-SID advertisement. However, the Prefix-SID algorithm does not address scenarios where multiple algorithms share the same link resources. This document proposes adding the algorithm identifier in an Adjacency-SID advertisement.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-lsr-algorithm-related-adjacency-sid/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-lsr-algorithm-related-adjacency-sid", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-lsr-algorithm-related-adjacency-sid" } }, { "name": "draft-ietf-pce-bier-te", "title": "PCEP Extensions for Tree Engineering for Bit Index Explicit Replication (BIER-TE)", "rev": "04", "new": false, "revised": "2026-10-18T09:10:25Z", "found": "2026-10-18T09:47:07.176Z", "pages": 17, "group": "pce", "group_type": "wg", "submitter": "pce", "area": "rtg", "area_label": "RTG", "area_source": "datatracker", "area_confidence": 1, "topic": "routing", "topic_label": "Routing", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "Tree Engineering for Bit Index Explicit Replication (BIER-TE) shares architecture and packet formats with BIER. BIER-TE forwards and replicates packets based on a BitString in the packet header, but every BitPosition of the BitString of a BIER-TE packet indicates one or more adjacencies. BIER-TE Path can be derived from a Path Computation Element (PCE). This document specifies extensions to the Path Computation Element Protocol (PCEP) that allow a PCE to compute and initiate the path for the Tree Engineering for Bit Index Explicit Replication (BIER-TE).", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-pce-bier-te/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-pce-bier-te", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-pce-bier-te" } }, { "name": "draft-ietf-bier-bgp-ls-bier-ext", "title": "BGP Link-State extensions for BIER", "rev": "22", "new": false, "revised": "2026-10-18T09:05:17Z", "found": "2026-10-18T09:47:07.176Z", "pages": 11, "group": "bier", "group_type": "wg", "submitter": "bier", "area": "rtg", "area_label": "RTG", "area_source": "datatracker", "area_confidence": 1, "topic": "routing", "topic_label": "Routing", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a \"BIER domain\" without requiring intermediate routers to maintain any multicast related per- flow state. BIER also does not require any explicit tree-building protocol for its operation. A multicast data packet enters a BIER domain at a \"Bit-Forwarding Ingress Router\" (BFIR), and leaves the BIER domain at one or more \"Bit-Forwarding Egress Routers\" (BFERs). The BFIR router adds a BIER header to the packet. The BIER header contains a bitstring in which each bit represents exactly one BFER to forward the packet to. The set of BFERs to which the multicast packet needs to be forwarded is expressed by setting the bits that correspond to those routers in the BIER header. BGP Link-State (BGP-LS) enables the collection of various topology informations from the network, and the topology informations are used by the controller to calculate the fowarding tables and then propagate them onto the BFRs(instead of having each node to calculate on its own) and that can be for both inter-as and intra-as situations. This document specifies extensions to the BGP Link-state address- family in order to advertise the BIER informations.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-bier-bgp-ls-bier-ext/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-bier-bgp-ls-bier-ext", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-bier-bgp-ls-bier-ext" } }, { "name": "draft-chen-bier-idr-bier-te-bgp", "title": "BGP extensions for BIER-TE", "rev": "07", "new": false, "revised": "2026-10-18T09:01:18Z", "found": "2026-10-18T09:47:07.176Z", "pages": 8, "group": "individual", "group_type": "individual", "submitter": "chen", "area": "rtg", "area_label": "RTG", "area_source": "classifier", "area_confidence": 1, "topic": "routing", "topic_label": "Routing", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "\"Tree Engineering for Bit Index Explicit Replication\" (BIER-TE) shares architecture and packet formats with BIER. BIER-TE forwards and replicates packets based on a BitString in the packet header, but every BitPosition of the BitString of a BIER-TE packet indicates one or more adjacencies. This document describes BGP extensions for advertising the BIER-TE specific information.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-chen-bier-idr-bier-te-bgp/", "html": "https://datatracker.ietf.org/doc/html/draft-chen-bier-idr-bier-te-bgp", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-chen-bier-idr-bier-te-bgp" } }, { "name": "draft-chen-idr-bgp-ls-sr-policy-cp-validity", "title": "Advertisement of Candidate Path Validity Control Parameters using BGP-LS", "rev": "04", "new": false, "revised": "2026-10-18T08:56:19Z", "found": "2026-10-18T09:47:07.176Z", "pages": 6, "group": "individual", "group_type": "individual", "submitter": "chen", "area": "rtg", "area_label": "RTG", "area_source": "classifier", "area_confidence": 1, "topic": "routing", "topic_label": "Routing", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.99, "classifier": "jev-1.13.0", "abstract": "This document describes a mechanism to collect the configuration and states of SR policies carrying the validity control parameters of the candidate path by using BGP Link-State (BGP-LS) updates. Such information can be used by external components for path computation, re-optimization, service placement, etc.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-chen-idr-bgp-ls-sr-policy-cp-validity/", "html": "https://datatracker.ietf.org/doc/html/draft-chen-idr-bgp-ls-sr-policy-cp-validity", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-chen-idr-bgp-ls-sr-policy-cp-validity" } }, { "name": "draft-chen-pce-sr-policy-cp-validity", "title": "PCEP extension to support Candidate Paths validity", "rev": "04", "new": false, "revised": "2026-10-18T08:51:38Z", "found": "2026-10-18T09:47:07.176Z", "pages": 6, "group": "individual", "group_type": "individual", "submitter": "chen", "area": "rtg", "area_label": "RTG", "area_source": "classifier", "area_confidence": 1, "topic": "routing", "topic_label": "Routing", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document defines PCEP extensions for signaling the validity control parameters of a candidate path for an SR Policy.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-chen-pce-sr-policy-cp-validity/", "html": "https://datatracker.ietf.org/doc/html/draft-chen-pce-sr-policy-cp-validity", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-chen-pce-sr-policy-cp-validity" } }, { "name": "draft-chen-idr-bgp-sr-policy-cp-validity", "title": "Validity of SR Policy Candidate Path", "rev": "05", "new": false, "revised": "2026-10-18T08:44:25Z", "found": "2026-10-18T08:47:06.991Z", "pages": 6, "group": "individual", "group_type": "individual", "submitter": "chen", "area": "rtg", "area_label": "RTG", "area_source": "classifier", "area_confidence": 1, "topic": "routing", "topic_label": "Routing", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document defines extensions to BGP to distribute the validity control parameters of a candidate path for an SR Policy.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-chen-idr-bgp-sr-policy-cp-validity/", "html": "https://datatracker.ietf.org/doc/html/draft-chen-idr-bgp-sr-policy-cp-validity", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-chen-idr-bgp-sr-policy-cp-validity" } }, { "name": "draft-ietf-pce-sr-mpls-sid-verification", "title": "Path Computation Element Communication Protocol (PCEP) Extensions for SID verification for SR-MPLS", "rev": "01", "new": false, "revised": "2026-10-18T08:37:21Z", "found": "2026-10-18T08:47:06.991Z", "pages": 8, "group": "pce", "group_type": "wg", "submitter": "pce", "area": "rtg", "area_label": "RTG", "area_source": "datatracker", "area_confidence": 1, "topic": "routing", "topic_label": "Routing", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document defines extensions to the Path Computation Element Communication Protocol (PCEP) to support SID verification in Segment Routing MPLS (SR-MPLS) networks. Specifically, it introduces a flag in the SR-ERO subobject to indicate that the Path Computation Client (PCC) is explicitly requested to verify SID(s) by the Path Computation Element (PCE), and defines capability exchange mechanisms.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-pce-sr-mpls-sid-verification/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-pce-sr-mpls-sid-verification", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-pce-sr-mpls-sid-verification" } }, { "name": "draft-nottingham-httpbis-402", "title": "The 402 (Payment Required) HTTP Status Code", "rev": "00", "new": true, "revised": "2026-10-18T07:12:01Z", "found": "2026-10-18T07:47:06.959Z", "pages": 4, "group": "individual", "group_type": "individual", "submitter": "nottingham", "area": "wit", "area_label": "WIT", "area_source": "classifier", "area_confidence": 0.98, "topic": "web", "topic_label": "Web/HTTP", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.99, "classifier": "jev-1.13.0", "abstract": "This specification defines semantics for the 402 (Payment Required) HTTP status code. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-nottingham-httpbis-402/. information can be found at https://projects.mnot.net/I-D/. Source for this draft and an issue tracker can be found at https://github.com/mnot/I-D/labels/402.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-nottingham-httpbis-402/", "html": "https://datatracker.ietf.org/doc/html/draft-nottingham-httpbis-402", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-nottingham-httpbis-402" } }, { "name": "draft-rodriguez-h2h-presence-attestation", "title": "Peer-to-Peer Presence Verification for Relationship-Bound Authorization", "rev": "00", "new": true, "revised": "2026-10-18T07:09:08Z", "found": "2026-10-18T07:47:06.959Z", "pages": 47, "group": "individual", "group_type": "individual", "submitter": "rodriguez", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 1, "topic": "security", "topic_label": "Security", "topic_confidence": 0.99, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "Existing protocols authenticate users to services, negotiate session keys, or protect message content from eavesdroppers. None verify that a remote party is the same individual whose key was accepted during an earlier in-person exchange and has just now physically authorized a signature on the device holding that key. Advances in synthetic media make it increasingly difficult to trust unauthenticated audio, video, or text for sensitive authorizations. This document defines transport-independent CBOR- and COSE-based objects that chain every remote interaction back to a bilateral in- person contact exchange -- not a certificate authority, identity provider, or key server. The protocol specifies Key Binding Objects, short-lived Session Credentials, replay-protected Signed Messages, a Presence Challenge requiring fresh platform-mediated user verification, and a Relationship Fingerprint for out-of-band key confirmation. It does not claim to prove biological humanness, legal identity, or voluntary action.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-rodriguez-h2h-presence-attestation/", "html": "https://datatracker.ietf.org/doc/html/draft-rodriguez-h2h-presence-attestation", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-rodriguez-h2h-presence-attestation" } }, { "name": "draft-moros-oauth-browser-session-handoff", "title": "Browser Session Establishment Using OAuth 2.0 Token Exchange and Short-Lived Authorization Codes", "rev": "00", "new": true, "revised": "2026-10-18T07:09:08Z", "found": "2026-10-18T07:47:06.959Z", "pages": 16, "group": "individual", "group_type": "individual", "submitter": "moros", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 1, "topic": "security", "topic_label": "Security", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.97, "classifier": "jev-1.13.0", "abstract": "This document specifies a usage profile that composes OAuth 2.0 Token Exchange [RFC8693] with a short-lived, single-use authorization code to establish an authenticated browser session at a Relying Party (RP) on behalf of a user authenticated at an Identity Provider (IdP) operating an independent OAuth 2.0 Security Token Service (STS). The server-to-server leg uses RFC 8693 to convey user identity and authorization context to the RP's STS, which issues an RP-scoped access token. A short-lived opaque code is then used to mediate delivery of session state into the user's browser without ever exposing the access token on the front channel. The profile is designed to avoid the class of front-channel token leakage (browser history, HTTP Referer header, intermediary access logs) that motivated the deprecation of the OAuth 2.0 implicit grant in [RFC9700]. The profile also defines a minimum claims contract on the RP-issued access token to enable stateless authorization enforcement at the RP without synchronous callbacks to the IdP.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-moros-oauth-browser-session-handoff/", "html": "https://datatracker.ietf.org/doc/html/draft-moros-oauth-browser-session-handoff", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-moros-oauth-browser-session-handoff" } }, { "name": "draft-hood-independent-agis", "title": "Agentic Grammar and Interface Specification (AGIS)", "rev": "01", "new": false, "revised": "2026-10-18T07:09:07Z", "found": "2026-10-18T07:47:06.959Z", "pages": 50, "group": "individual", "group_type": "individual", "submitter": "hood", "area": "art", "area_label": "ART", "area_source": "classifier", "area_confidence": 0.37, "topic": "ai", "topic_label": "AI/agents", "topic_confidence": 0.98, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document defines the Agentic Grammar and Interface Specification (AGIS), a grammar-constrained interface definition language for Agentive APIs designed for consumption by large language model (LLM) based agents. AGIS establishes structural and semantic rules governing how API methods and endpoints must be expressed, without mandating a fixed vocabulary of method names. An implementation conforming to AGIS uses intent-expressing imperative verbs as method identifiers, enabling agents to infer operational meaning from method names without requiring training on a predefined catalog. AGIS is the native interface definition layer for the Agent Transfer Protocol (AGTP) [AGTP], in the same way that HTML functions as the native content language for the HTTP transport protocol. AGIS does not replace JSON Schema [JSON-SCHEMA] for data contracts; it governs the structural grammar of method and endpoint design that wraps those contracts. AGIS-conformant methods are accepted at the AGTP transport layer via the Method-Grammar header without requiring prior IANA registration, enabling organizations to define domain-specific Agentive API vocabularies while preserving interoperability through shared grammatical constraints. Empirical validation of the core AGIS design principle is provided in [HOOD2026], which demonstrates a 10-29 percentage point accuracy advantage for intent-expressing method names over generic HTTP verbs across three frontier LLM families in 7,200 controlled trials. This version also introduces: normative YAML and JSON serialization formats; a Data Manifest block enabling services to declare available data without pre-built endpoints; a negotiable signal enabling AGTP dynamic endpoint instantiation; semantic declaration enhancements including is_idempotent, impact_tier, parameter_hints, and state_transition fields; vocabulary namespace disambiguation; and an HTTP transitional binding for incremental adoption.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-hood-independent-agis/", "html": "https://datatracker.ietf.org/doc/html/draft-hood-independent-agis", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-hood-independent-agis" } }, { "name": "draft-matolin-global-nat64-anycast", "title": "Global Anycast NAT64 Well-Known Prefix", "rev": "00", "new": true, "revised": "2026-10-18T07:09:06Z", "found": "2026-10-18T07:47:06.959Z", "pages": 6, "group": "individual", "group_type": "individual", "submitter": "matolin", "area": "int", "area_label": "INT", "area_source": "classifier", "area_confidence": 0.97, "topic": "ip", "topic_label": "IP/addressing", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.97, "classifier": "jev-1.13.0", "abstract": "This document defines a globally routable, anycast NAT64 service using the IPv6 prefix 2600:6464::/96 as a standardized translation substrate for IPv6-to-IPv4 connectivity. The goal of this specification is to eliminate per-network NAT64 configuration complexity by introducing a single globally consistent NAT64 translation prefix operated as a distributed anycast service by participating Internet Service Providers, cloud providers, and content delivery networks. The model assumes an IPv6-only client environment with mandatory IPv4 reachability via NAT64 translation. IPv4-only services remain reachable without modification. IPv4 is not modified. IPv6 is not modified. Only translation placement and routing semantics are standardized. This document defines: * A globally shared NAT64 prefix (2600:6464::/96) * Anycast-based NAT64 edge behavior * Stateless IPv6-to-IPv4 synthesis rules * Optional reverse mapping constraints (IPv4->IPv6 blocked) * Operational requirements for participating networks", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-matolin-global-nat64-anycast/", "html": "https://datatracker.ietf.org/doc/html/draft-matolin-global-nat64-anycast", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-matolin-global-nat64-anycast" } }, { "name": "draft-meow-mrrp", "title": "Meow", "rev": "00", "new": true, "revised": "2026-10-18T07:09:06Z", "found": "2026-10-18T07:47:06.959Z", "pages": 10, "group": "individual", "group_type": "individual", "submitter": "meow", "area": "other", "area_label": "Other", "area_source": "classifier", "area_confidence": 0.97, "topic": "other", "topic_label": "Other", "topic_confidence": 1, "kind": "other", "kind_label": "other", "kind_confidence": 0.92, "classifier": "jev-1.13.0", "abstract": "Meow meow meow meow Meow Meow Meow (MEOW). MEOW meow meow meow meow- meow meow meow meow Meow meow meow, meow meow meow meow meow meow meow meow meow meow meow meow meow Meow. Meow meow meow, mrrp meow meow meow meow meow meow meow MEOW meow meow meow meow meow MEOW MEOW, meow meow meow meow meow meow meow mrow meow meow. Meow meow meow meow meow meow meow meow meow meow meow meow meow MEOW MEOW. Meow meow meow MEOW MEOW, meow meow meow Meow MEOW, MEOW, MEOW, MEOW, MEOW, meow MEOW meow meow meow meow MEOW MEOW. Meow meow Meow MEOW meow MEOW, meow meow meow meow meow meow moew meow meow meow meow meow meow meow meow meow MEOW meow. Meow meow meow MEOW MEOW meow meow nya meow meow meow meow meow meow meow meow MEOW-MEOW meow. Meow MEOW meow meow meow meow MEOW MEOW meow meow meow meow meow meow MEOW MEOW.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-meow-mrrp/", "html": "https://datatracker.ietf.org/doc/html/draft-meow-mrrp", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-meow-mrrp" } }, { "name": "draft-hause-asip", "title": "ASIP: AS-Structured Internet Protocol (128-bit)", "rev": "00", "new": true, "revised": "2026-10-18T07:09:06Z", "found": "2026-10-18T07:47:06.959Z", "pages": 94, "group": "individual", "group_type": "individual", "submitter": "hause", "area": "int", "area_label": "INT", "area_source": "classifier", "area_confidence": 1, "topic": "ip", "topic_label": "IP/addressing", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "ASIP (AS-Structured Internet Protocol; IP version 8 on the wire) is a 128-bit network protocol that defines a new address family alongside IPv4. ASIP is NOT a wire-level superset of IPv4: an unmodified IPv4 device cannot send, receive, or forward an ASIP packet. Interoperation between ASIP-aware endpoints and legacy IPv4 networks is provided by a defined transition mechanism (stateless translation at AS boundaries and encapsulation across non-upgraded transit), not by wire compatibility. ASIP's addressing architecture arranges the 128-bit address as four 32-bit fields (ASN routing locator, zone, subnet, host). The ASN locator is used as a routing hint rather than a hard identity binding; multihoming, ASN transfer, and cross-ASN anycast remain possible through multi-address semantics defined in Sections 8, 11, and 14. This structure is intended to reduce operational friction during transition (familiar dotted-decimal notation, clean aggregation at the ASN boundary) rather than to achieve wire-level IPv4 compatibility. This document specifies the core protocol: address format, packet header, address classes, routing behavior, transition mechanisms, and security considerations. The Zone Server reference architecture (Section 16) is Informative and non-normative. The Cost Factor routing metric (Section 17) is OPTIONAL and is specified in a separate companion document (draft-asip-cf-00); Section 17 of this document is a one-paragraph forward reference. Interplanetary realm reservations (Section 3.12) are reserved allocations only; delay- tolerant transport is out of scope for this document. Operators MAY deploy ASIP addressing without any of the above. This specification extends the ASN-locator addressing model of [I-D.thain-ipv8] to a 128-bit four-field address format; see Section 1.3 for the relationship between the two proposals.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-hause-asip/", "html": "https://datatracker.ietf.org/doc/html/draft-hause-asip", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-hause-asip" } }, { "name": "draft-ahearn-seal", "title": "Signed Email Authentication Layer (SEAL)", "rev": "01", "new": false, "revised": "2026-10-18T07:09:05Z", "found": "2026-10-18T07:47:06.959Z", "pages": 11, "group": "individual", "group_type": "individual", "submitter": "ahearn", "area": "art", "area_label": "ART", "area_source": "classifier", "area_confidence": 0.57, "topic": "email", "topic_label": "Email/messaging", "topic_confidence": 0.99, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document defines the Signed Email Authentication Layer (SEAL), a cryptographically signed identity envelope carried within a new message header field, SEAL-Envelope. SEAL provides a stable, forwarding-resilient identity assertion that binds the origin domain to a specific message instance using the SEAL-MSGID header, which contains a SEAL-protected copy of the [RFC5322] Message-ID present at message creation time. After SEAL-MSGID is set, intermediaries may modify or discard the visible [RFC5322] Message-ID header without affecting SEAL validity. SEAL also records the canonical [RFC5322] From header value in the envelope, enabling detection of From rewriting without affecting SEAL validity. SEAL is designed to complement current approaches such as DKIM, DMARC, and ARC by reducing their dependency on mutable message components and by providing a canonical, tamper-evident identity layer that can remain valid across many common transformations.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ahearn-seal/", "html": "https://datatracker.ietf.org/doc/html/draft-ahearn-seal", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ahearn-seal" } }, { "name": "draft-bernardos-cats-anchoring-site-mobility", "title": "Site Mobility-Enabled Computing Aware Traffic Steering using IP address anchoring", "rev": "01", "new": false, "revised": "2026-10-18T07:09:04Z", "found": "2026-10-18T07:47:06.959Z", "pages": 12, "group": "individual", "group_type": "individual", "submitter": "bernardos", "area": "int", "area_label": "INT", "area_source": "classifier", "area_confidence": 0.9, "topic": "cloud", "topic_label": "Cloud/DC", "topic_confidence": 0.7, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "The IETF CATS WG addresses the problem of how the network infrastructure can steer traffic between clients of a service and sites offering the service, considering both network metrics (such as bandwidth and latency), and compute metrics (such as processing, storage capabilities, and capacity). This document defines new extensions and procedures for a terminal hosting a site, to benefit from transparent mobility management adapting to specific connectivity and computing requirements.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-bernardos-cats-anchoring-site-mobility/", "html": "https://datatracker.ietf.org/doc/html/draft-bernardos-cats-anchoring-site-mobility", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-bernardos-cats-anchoring-site-mobility" } }, { "name": "draft-hood-agtp-standard-methods", "title": "AGTP Standard Extended Method Vocabulary", "rev": "01", "new": false, "revised": "2026-10-18T07:09:04Z", "found": "2026-10-18T07:47:06.959Z", "pages": 51, "group": "individual", "group_type": "individual", "submitter": "hood", "area": "art", "area_label": "ART", "area_source": "classifier", "area_confidence": 0.63, "topic": "ai", "topic_label": "AI/agents", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.8, "classifier": "jev-1.13.0", "abstract": "The Agent Transfer Protocol (AGTP) defines a core method vocabulary (Tier 1) of twelve intent-based methods covering the most common agent operations. This document defines the Tier 2 Standard Extended Method Vocabulary: methods registered in the IANA AGTP Method Registry that are available for use in any AGTP implementation but are not required for baseline compliance. Methods are organized into six categories reflecting the full operational range of AI agent systems: ACQUIRE, COMPUTE, TRANSACT, INTEGRATE, COMMUNICATE, and ORCHESTRATE. This document also specifies the QUOTE method referenced in the AGTP core specification for pre-flight resource cost estimation. The six-category taxonomy is aligned with the ACTION framework described in [AGENTIC-API]. All methods defined in this document conform to the Agentic Grammar and Interface Specification (AGIS) [AGIS]. Each method satisfies the AGIS action-intent semantic class requirement and syntactic rules. This document serves as a reference vocabulary of AGIS-conformant methods for organizations seeking maximum cross-system interoperability. Organizations requiring domain-specific vocabularies not covered here may define their own AGIS-conformant methods without IANA registration using the Tier 4 grammar-based validation pathway defined in [AGTP].", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-hood-agtp-standard-methods/", "html": "https://datatracker.ietf.org/doc/html/draft-hood-agtp-standard-methods", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-hood-agtp-standard-methods" } }, { "name": "draft-mozley-aidiscovery", "title": "AI Agent Discovery (AID) Problem Statement", "rev": "01", "new": false, "revised": "2026-10-18T07:09:04Z", "found": "2026-10-18T07:47:06.959Z", "pages": 8, "group": "individual", "group_type": "individual", "submitter": "mozley", "area": "irtf", "area_label": "IRTF", "area_source": "classifier", "area_confidence": 0.34, "topic": "ai", "topic_label": "AI/agents", "topic_confidence": 1, "kind": "requirements", "kind_label": "requirements / use cases", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "With the proliferation of AI agents comes a need for mechanisms to support agent-to-agent discovery. This document discusses the scope, requirements and considerations to support discovery processes so that these are not reliant on manually defined configurations and relationships.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-mozley-aidiscovery/", "html": "https://datatracker.ietf.org/doc/html/draft-mozley-aidiscovery", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-mozley-aidiscovery" } }, { "name": "draft-rpe-ssh-mldsa", "title": "ML-DSA Public Key Algorithms for the Secure Shell (SSH) Protocol", "rev": "03", "new": false, "revised": "2026-10-18T07:09:03Z", "found": "2026-10-18T07:47:06.959Z", "pages": 6, "group": "individual", "group_type": "individual", "submitter": "rpe", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.99, "topic": "security", "topic_label": "Security", "topic_confidence": 1, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "This document describes the use of the ML-DSA digital signature algorithms in the Secure Shell (SSH) protocol. Accordingly, this RFC updates RFC 4253.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-rpe-ssh-mldsa/", "html": "https://datatracker.ietf.org/doc/html/draft-rpe-ssh-mldsa", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-rpe-ssh-mldsa" } }, { "name": "draft-bernardos-detnet-raw-multidomain", "title": "DetNet multidomain extensions", "rev": "07", "new": false, "revised": "2026-10-18T07:09:03Z", "found": "2026-10-18T07:47:06.959Z", "pages": 15, "group": "individual", "group_type": "individual", "submitter": "bernardos", "area": "rtg", "area_label": "RTG", "area_source": "classifier", "area_confidence": 0.99, "topic": "iot", "topic_label": "IoT", "topic_confidence": 0.96, "kind": "requirements", "kind_label": "requirements / use cases", "kind_confidence": 0.36, "classifier": "jev-1.13.0", "abstract": "This document describes the multi-domain DetNet problem, starting from a wireless DetNet (formerlly called RAW) scope, and explores and proposes some extensions to enable DetNet multi-domain operation.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-bernardos-detnet-raw-multidomain/", "html": "https://datatracker.ietf.org/doc/html/draft-bernardos-detnet-raw-multidomain", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-bernardos-detnet-raw-multidomain" } }, { "name": "draft-ietf-dkim-dkim2-dns", "title": "Domain Name Specification for DKIM2", "rev": "01", "new": false, "revised": "2026-10-18T05:07:10Z", "found": "2026-10-18T05:47:06.565Z", "pages": 16, "group": "dkim", "group_type": "wg", "submitter": "dkim", "area": "art", "area_label": "ART", "area_source": "datatracker", "area_confidence": 1, "topic": "email", "topic_label": "Email/messaging", "topic_confidence": 0.95, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "The updated DomainKeys Identified Mail (DKIM2) permits an organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message through a digital signature. This is done by publishing to Domain Name Service (DNS) of the domain a public key that is then associated to the domain and where messages can be signed by the corresponding private key. Assertion of responsibility is validated through a cryptographic signature and by querying the Signer's domain directly to retrieve the appropriate public key. This document describes DKIM2 DNS record format and how to find the record.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-ietf-dkim-dkim2-dns/", "html": "https://datatracker.ietf.org/doc/html/draft-ietf-dkim-dkim2-dns", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-ietf-dkim-dkim2-dns" } }, { "name": "draft-watts-eqr-conformance", "title": "Deterministic Conformance Profile and Test Vectors for Evidence Qualification Receipts", "rev": "02", "new": false, "revised": "2026-10-18T03:24:35Z", "found": "2026-10-18T03:47:06.871Z", "pages": 13, "group": "individual", "group_type": "individual", "submitter": "watts", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.94, "topic": "security", "topic_label": "Security", "topic_confidence": 0.59, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.99, "classifier": "jev-1.13.0", "abstract": "This document defines a deterministic conformance profile and test- vector corpus for Evidence Qualification Receipts (EQRs). The profile, named eqr-core-1, makes receipt conformance mechanically reproducible: strict JSON structure, SHA-256 digest encoding, UTC timestamp handling, evidence-reference integrity, requirement-state derivation, and three-valued PASS, FAIL, or INDETERMINATE results are checked by a closed algorithm. The profile is intentionally narrow. Conformance does not establish that evidence is true, that a proposition is scientifically valid, that an issuer is trustworthy, or that an action is authorized. The goal is interoperable verification of receipt semantics, not promotion of conformance into substantive truth.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-watts-eqr-conformance/", "html": "https://datatracker.ietf.org/doc/html/draft-watts-eqr-conformance", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-watts-eqr-conformance" } }, { "name": "draft-mccormack-ztip", "title": "The Zero Trust Intelligence Protocol (ZTIP): Governed, Independently Verified AI Agent Transactions", "rev": "01", "new": false, "revised": "2026-10-18T01:45:35Z", "found": "2026-10-18T01:47:07.024Z", "pages": 15, "group": "individual", "group_type": "individual", "submitter": "mccormack", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.97, "topic": "ai", "topic_label": "AI/agents", "topic_confidence": 0.87, "kind": "spec", "kind_label": "specification", "kind_confidence": 1, "classifier": "jev-1.13.0", "abstract": "The Zero Trust Intelligence Protocol (ZTIP) is an open, transport- neutral protocol for governed AI agent transactions. It defines five immutable JSON envelope types and a transaction lifecycle under which every agent-initiated action is authorized by policy before execution, integrity-protected by hash over a canonical form, and -- distinctively -- verified as complete by an authority independent of the actor that performed the work. An executor's claim of success is treated as attestation, and attestation alone never satisfies a required verification check. This revision states what integrity verification does not establish, and specifies the fail-closed rules an implementation MUST apply when it verifies a set of envelopes together, so that a verification report can never claim more than was actually checked. This document describes ZTIP version 1.0-draft for the record; the full specification, JSON Schemas, examples, and a reference runtime are maintained in the open at the repository referenced herein.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-mccormack-ztip/", "html": "https://datatracker.ietf.org/doc/html/draft-mccormack-ztip", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-mccormack-ztip" } }, { "name": "draft-kott-numina-pair-binding", "title": "Singularity: Skott34-Ed25519, Universal Companion Model", "rev": "02", "new": false, "revised": "2026-10-18T01:03:48Z", "found": "2026-10-18T01:47:07.024Z", "pages": 69, "group": "individual", "group_type": "individual", "submitter": "kott", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.97, "topic": "security", "topic_label": "Security", "topic_confidence": 0.96, "kind": "spec", "kind_label": "specification", "kind_confidence": 0.99, "classifier": "jev-1.13.0", "abstract": "This document describes a proposed companion format for associating two frozen software-artifact commitments with attribution and revisioned claims. It specifies canonical signing bytes, separate trust and freshness checks, claim-making and verification procedures, and operational state boundaries. The intended implementing community is software-provenance maintainers, release operators and independent security reviewers. Existing IETF canonicalization and signature specifications are used without defining a new cryptographic primitive. Retained source comparisons, document- signature checks and synthetic tests are indexed with their limits. Application control-plane evidence is distinguished from deployment of the companion itself. A complete operational profile, independently authenticated trust and current-state evidence, and a verified field deployment remain prerequisites to an implementation- readiness claim.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-kott-numina-pair-binding/", "html": "https://datatracker.ietf.org/doc/html/draft-kott-numina-pair-binding", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-kott-numina-pair-binding" } }, { "name": "draft-he-agentproto-verifier-evidence", "title": "Exercise and Completeness Evidence for Agent Protocol Verifier Results", "rev": "00", "new": true, "revised": "2026-10-18T00:40:44Z", "found": "2026-10-18T00:47:07.063Z", "pages": 19, "group": "individual", "group_type": "individual", "submitter": "he", "area": "sec", "area_label": "SEC", "area_source": "classifier", "area_confidence": 0.72, "topic": "ai", "topic_label": "AI/agents", "topic_confidence": 0.83, "kind": "requirements", "kind_label": "requirements / use cases", "kind_confidence": 0.92, "classifier": "jev-1.13.0", "abstract": "A verifier result reports what a check returned. It does not report whether the check could have returned anything else. A check that inspects too narrow a set of fields, and a check whose rejecting input has never occurred, both report the same accepting value as a check that distinguishes, and a conformance matrix does not tell them apart. This document defines requirements for reporting whether a check has been exercised into its rejecting outcome, and requirements for results that claim completeness: that the records relied on were the whole of some stated set. Those are two separate obligations. A result must name the set it claims to have seen, and must not treat a party with an interest in the answer as the only thing looking. This document defines no wire format, encoding, token, claim vocabulary, test harness, or registry. It does require a record to identify certain facts, which is a constraint on what a record must be able to express rather than on how it is written down. A profile satisfying these requirements will need a place to put those facts.", "links": { "datatracker": "https://datatracker.ietf.org/doc/draft-he-agentproto-verifier-evidence/", "html": "https://datatracker.ietf.org/doc/html/draft-he-agentproto-verifier-evidence", "analyzer": "https://ietf.jaime.win/is-it-ai?draft=draft-he-agentproto-verifier-evidence" } } ] }