|
|
|
|
@@ -1,524 +0,0 @@
|
|
|
|
|
{"draft_name": "draft-illyes-aipref-cbcp", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes best practices for web crawlers, likely addressing modern crawler behavior and responsible crawling standards. Early-stage document focused on establishing guidelines for crawler operators in the context of AI and automated agents.\",\n \"n\": 2,\n \"nn\": \"Incremental work building on existing robots.txt and crawling conventions; limited novel technical contribution evident from abstract\",\n \"m\": 2,\n \"mn\": \"Early sketch stage with 6-page limit; abstract mentions best practices but lacks specifics on mechanisms, protocols, or implementation details\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing standards (robots.txt, User-Agent conventions, Crawl-delay) and prior IETF work on web crawling; borrows established practices rather than proposing novel approaches\",\n \"mo\": 2,\n \"mon\": \"Single revision visible; hosted on GitHub but limited evidence of broad working group engagement or community momentum beyond individual author contribution\",\n \"r\": 3,\n \"rn\": \"Partially relevant to AI agent topic\u2014addresses crawler behavior which relates to autonomous agents and data collection, but framed as general web crawler practices rather than AI-specific agent governance\",\n \"c\": [\n \"Policy/governance\",\n \"Agent discovery/reg\",\n \"Data formats/interop\",\n \"Other AI/agent\"\n ]\n}\n```", "in_tok": 500, "out_tok": 324}
|
|
|
|
|
{"draft_name": "draft-shi-moq-kvcache", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft proposes a protocol for efficiently distributing LLM key-value caches across distributed nodes using MoQT's publish-subscribe transport, enabling cache reuse to reduce bandwidth and prefill computation costs. The approach leverages local caching at network edges to optimize large language model inference performance.\",\n \"n\": 2,\n \"nn\": \"Incremental combination of existing concepts (MoQT pub/sub + KVCache distribution); the technical novelty is limited to applying a known transport mechanism to a specific ML inference optimization problem.\",\n \"m\": 2,\n \"mn\": \"Early-stage sketch with conceptual framing but minimal protocol details; lacks formal specification, message formats, serialization details, or concrete implementation guidance for 6-page draft length.\",\n \"o\": 3,\n \"on\": \"Shares foundational concepts with distributed ML inference systems and edge caching literature; MoQT itself is established; moderate overlap with general cache distribution patterns but specific KVCache+MoQT binding is relatively novel.\",\n \"mo\": 2,\n \"mon\": \"Single/early revision evident; limited evidence of WG traction or broader community engagement; appears to be exploratory work without established momentum in IETF or MoQ communities.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to model serving/inference optimization and ML traffic management; addresses practical distributed inference challenges; less relevant to broader AI agent topics but solid relevance to AI infrastructure.\",\n \"c\": [\n \"Model serving/inference\",\n \"ML traffic mgmt\",\n \"Data formats/interop\"\n ]\n}\n```", "in_tok": 605, "out_tok": 382}
|
|
|
|
|
{"draft_name": "draft-singla-agent-identity-protocol", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"AIP proposes a decentralized identity framework for AI agents using DIDs, capability-based authorization, and cryptographic delegation. It aims to enable secure multi-agent workflows without centralized providers.\",\n \"n\": 3,\n \"nn\": \"Useful combination of existing standards (W3C DIDs, capability-based auth) applied to AI agents, but delegation and identity for autonomous agents is an emerging design space with limited prior standardization.\",\n \"m\": 2,\n \"mn\": \"Early sketch stage; abstract indicates framework design but 225 pages suggests incomplete specification; likely lacks implementation details, test vectors, or reference implementations needed for maturity.\",\n \"o\": 3,\n \"on\": \"Shares core concepts with DID specs, CHAPI, ZCAP-LD, and agent authorization work; represents useful combination but not orthogonal to multiple existing IETF/W3C efforts in identity and delegation.\",\n \"mo\": 1,\n \"mon\": \"2026 date indicates future draft with no current revision history visible; single appearance suggests early-stage work without evident WG adoption or community engagement.\",\n \"r\": 4,\n \"rn\": \"Directly addresses agent identity and authorization\u2014core infrastructure need for autonomous AI agent deployment\u2014though framed more as identity infrastructure than AI-specific capabilities.\",\n \"c\": [\n \"Agent identity/auth\",\n \"A2A protocols\",\n \"Agent discovery/reg\",\n \"Policy/governance\",\n \"Data formats/interop\"\n ]\n}\n```", "in_tok": 540, "out_tok": 363}
|
|
|
|
|
{"draft_name": "draft-sharif-attp", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"ATTP proposes a trust-scoring framework for autonomous AI agents with cryptographic identity, action limits, and compliance gating across multiple transport protocols. It separates trust evaluation from identity verification to enable fine-grained authorization control for agent actions.\",\n \"n\": 2,\n \"nn\": \"Incremental combination of existing concepts (trust scoring, ECDSA identity, compliance gating) applied to agent context; no fundamentally novel technical mechanisms but reasonable engineering synthesis for emerging use case.\",\n \"m\": 3,\n \"mn\": \"Defined protocol framework with five trust levels and behavioral dimensions, but lacks implementation details, test vectors, and concrete examples; transport bindings (MCPS, REST, gRPC) mentioned but not specified in this draft.\",\n \"o\": 4,\n \"on\": \"Significant conceptual overlap with OAuth 2.0 scopes/capabilities, NIST AI RMF trust assessment, policy-based access control, and existing compliance frameworks; trust scoring echoes established risk models; novelty is mainly in agent-specific packaging.\",\n \"mo\": 2,\n \"mon\": \"Single revision as of April 2026; no evident WG adoption, community discussion, or implementation feedback; appears exploratory rather than driven by active deployment needs.\",\n \"r\": 5,\n \"rn\": \"Directly addresses core AI agent governance challenge\u2014authorization and trust in autonomous systems\u2014highly timely given LLM agent proliferation and regulatory pressure.\",\n \"c\": [\n \"Agent identity/auth\",\n \"AI safety/alignment\",\n \"Policy/governance\",\n \"A2A protocols\",\n \"Data formats/interop\"\n ]\n}\n```", "in_tok": 776, "out_tok": 394}
|
|
|
|
|
{"draft_name": "draft-templin-intarea-aero", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"AERO/OMNI provides an IPv6-based overlay networking service for mobile internetworking across multilink interfaces, using neighbor discovery and dynamic routing optimization. It targets air/land/sea/space mobility applications with support for multihop, multicast, and mobility management without explicit tunnel setup.\",\n \"n\": 2,\n \"nn\": \"Incremental extension of IPv6 ND and route optimization concepts; applies existing techniques (ULA addressing, ND, dynamic neighbor cache) to overlay networks rather than introducing fundamentally novel mechanisms.\",\n \"m\": 3,\n \"mn\": \"Protocol mechanisms are defined with architectural descriptions, but lacks implementation details, test vectors, and validation evidence typical of implementation-ready specifications.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing mobile IP, MANET, and overlay networking approaches; shares conceptual space with MIPv6, OLSR, and other dynamic routing solutions for mobile scenarios.\",\n \"mo\": 1,\n \"mon\": \"Single revision dated 2024-02-16 suggests minimal recent momentum; no evidence of WG adoption, implementation deployments, or community engagement driving iterative development.\",\n \"r\": 1,\n \"rn\": \"Not relevant to AI agents or autonomous systems; pure network infrastructure specification with no connection to agent architectures, decision-making, or AI operations.\",\n \"c\": [\"Other AI/agent\"]\n}\n```", "in_tok": 656, "out_tok": 333}
|
|
|
|
|
{"draft_name": "draft-papon-lake-pq-edhoc", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft extends EDHOC with post-quantum cryptography using signature and KEM combinations, proposing two variants that reduce message complexity compared to parallel approaches. It addresses quantum-resistant key establishment for IoT and constrained environments while maintaining the lightweight EDHOC design philosophy.\",\n \"n\": 2,\n \"nn\": \"Incremental extension applying known PQC techniques (signatures + KEMs) to existing EDHOC framework; combines approaches from parallel drafts rather than introducing fundamentally new methods.\",\n \"m\": 4,\n \"mn\": \"Well-defined protocol specification with clear message flows, algorithm choices, and two distinct variants; lacks implementation artifacts and test vectors for production readiness.\",\n \"o\": 3,\n \"on\": \"Shares core concepts with other PQ-EDHOC proposals; differentiates through hybrid sig+KEM approach and message complexity tradeoff, but significant conceptual overlap exists in the post-quantum EDHOC space.\",\n \"mo\": 2,\n \"mon\": \"Single revision from 2026; no evident WG adoption signals or community momentum; appears as standalone contribution rather than active collaborative effort.\",\n \"r\": 2,\n \"rn\": \"Tangentially related to AI agents; relevant only if agents use EDHOC for secure bootstrapping in constrained IoT networks; not a core agent protocol or identity mechanism.\",\n \"c\": [\"Agent identity/auth\", \"Data formats/interop\", \"Other AI/agent\"]\n}\n```", "in_tok": 633, "out_tok": 350}
|
|
|
|
|
{"draft_name": "draft-yang-dynamic-ecn-threshold", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes dynamically coupling ECN marking thresholds to buffer allocation limits in network devices to prevent pathological marking behaviors. Introduces a deterministic algorithm that adaptively adjusts congestion signals based on instantaneous buffering capacity without ML models or per-flow tracking.\",\n \"n\": 2,\n \"nn\": \"Incremental refinement of ECN mechanisms; coupling static thresholds to dynamic buffers is a logical engineering solution but lacks fundamental novelty.\",\n \"m\": 3,\n \"mn\": \"Well-defined mechanism with operational framework and reference algorithm described; lacks implementation validation, test vectors, and deployment guidance for production readiness.\",\n \"o\": 3,\n \"on\": \"Shares conceptual space with dynamic buffer management (RFC 7308) and ECN specifications (RFC 3168, RFC 8311); applies existing concepts in a new combination but without significant technical divergence.\",\n \"mo\": 2,\n \"mon\": \"Single draft revision (2026-03-02); no evidence of WG sponsorship, community discussion, or iterative development indicating active momentum.\",\n \"r\": 1,\n \"rn\": \"Traditional networking congestion control optimization; no connection to AI agents, autonomous systems, or machine learning\u2014false positive for AI/agent scope.\",\n \"c\": [\"Other AI/agent\"]\n}\n```", "in_tok": 673, "out_tok": 314}
|
|
|
|
|
{"draft_name": "draft-tschofenig-lamps-nonce-cmp-est", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft specifies a mechanism for nonce-based freshness verification in attestation evidence included within Certificate Signing Requests (CSRs) for CMP and EST protocols. It defines how Registration Authorities and Certification Authorities can provision nonces to end entities to ensure the recency of remote attestation claims during certificate enrollment.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution addressing a known gap in existing CMP/EST specifications; applies well-established nonce-based freshness patterns to certificate management contexts.\",\n \"m\": 3,\n \"mn\": \"Protocol mechanism is clearly defined with message structure and interaction flows, though document lacks implementation examples, test vectors, and formal security analysis of nonce handling.\",\n \"o\": 3,\n \"on\": \"Shares foundational concepts with remote attestation (TCG standards) and existing nonce mechanisms in IETF protocols (COSE, RATS); moderate overlap with attestation evidence freshness requirements.\",\n \"mo\": 2,\n \"mon\": \"Single 2024 revision with limited evidence of WG adoption; appears to be exploratory work rather than established working group item with community momentum.\",\n \"r\": 1,\n \"rn\": \"Not relevant to AI agents or autonomous systems; focuses purely on X.509 certificate management infrastructure and remote attestation protocols.\",\n \"c\": [\n \"Data formats/interop\",\n \"Agent identity/auth\"\n ]\n}\n```", "in_tok": 670, "out_tok": 343}
|
|
|
|
|
{"draft_name": "draft-araut-oauth-transaction-tokens-for-agents", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft extends OAuth Transaction Tokens to support agent context propagation in agent-based workloads, introducing the agentic_ctx claim for multi-agent flow integrity while reusing existing act and sub claims. It addresses both single-agent and multi-agent deployment patterns where transaction tokens are updated at agent transitions.\",\n \"n\": 2,\n \"nn\": \"Incremental extension combining existing OAuth mechanisms (act from RFC8693, sub claim) with a new structured claim; limited conceptual novelty beyond adapting token standards to agent scenarios.\",\n \"m\": 3,\n \"mn\": \"Defined protocol mechanism with claim structures and deployment patterns described, but abstract truncates mid-definition and lacks implementation details, examples, test vectors, or security analysis.\",\n \"o\": 4,\n \"on\": \"Significant overlap with base Transaction Tokens spec and standard OAuth delegation patterns; the extension primarily layers agent-specific metadata on proven token frameworks without architectural innovation.\",\n \"mo\": 2,\n \"mon\": \"Early-stage draft (May 2026 projected date) with single known revision; no evidence of WG adoption, implementation feedback, or community engagement beyond initial proposal.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to agent identity/authentication and multi-agent system coordination; addresses real need for agent context in distributed agentic workflows, though not core to AI model/algorithm development.\",\n \"c\": [\n \"Agent identity/auth\",\n \"A2A protocols\",\n \"Data formats/interop\",\n \"Agent discovery/reg\"\n ]\n}\n```", "in_tok": 921, "out_tok": 370}
|
|
|
|
|
{"draft_name": "draft-yuan-rtgwg-security-agent-usecase", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes AI Network Security Agents\u2014intelligent software components using machine learning and behavioral analysis\u2014to replace static ACLs and signature-based detection in routers. Outlines four use case scenarios: dynamic threat defense, ACL optimization, configuration security, and collaborative defense across distributed network devices.\",\n \"n\": 2,\n \"nn\": \"Incremental application of existing AI/ML techniques (anomaly detection, behavioral analysis) to network security; core concepts not novel, though specific router-centric agent architecture has modest originality.\",\n \"m\": 1,\n \"mn\": \"Use case description only; no protocol specification, architecture details, API definitions, or implementation guidance. Lacks formal problem statement and evaluation methodology.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing work on AI-driven network security, intent-based networking, autonomous network operations, and DDoS mitigation. Concepts resemble prior drafts on network telemetry and intelligent defense systems.\",\n \"mo\": 1,\n \"mon\": \"Single revision, no evidence of WG discussion, community feedback, or iterative refinement. Appears to be initial proposal without subsequent development.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI agents in networking and autonomous network operations; addresses intelligent decision-making and distributed collaboration. Core relevance to agent frameworks, though less focused on agent identity/auth or model serving specifics.\",\n \"c\": [\n \"Autonomous netops\",\n \"Policy/governance\",\n \"Agent discovery/reg\",\n \"ML traffic mgmt\",\n \"Data formats/interop\"\n ]\n}\n```", "in_tok": 672, "out_tok": 384}
|
|
|
|
|
{"draft_name": "draft-jiang-seat-dynamic-attestation", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes dynamic attestation mechanisms for TLS sessions in AI agent communication, addressing the need to convey runtime posture changes (TCB, models, tools, policies) to relying parties for continuous authorization decisions. Focuses on long-lived secure channels where agent state evolves unpredictably.\",\n \"n\": 2,\n \"nn\": \"Incremental combination of existing remote attestation concepts with TLS and AI agent contexts; core ideas not novel but application domain is relatively unexplored.\",\n \"m\": 2,\n \"mn\": \"Early sketch phase\u2014identifies use case and requirements but lacks protocol design details, message formats, or implementation guidance; no concrete mechanism specified.\",\n \"o\": 3,\n \"on\": \"Shares foundational concepts with remote attestation (RATS, TPM), TLS extensions, and agent communication work; moderate overlap with emerging AI infrastructure standards but distinct focus on dynamic updates.\",\n \"mo\": 1,\n \"mon\": \"Single 5-page draft with 2026 date; no evidence of WG adoption, multiple revisions, or community engagement; appears exploratory with uncertain trajectory.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI agent trust and authorization in distributed systems; addresses genuine gap in dynamic posture reporting but limited to narrow communication pattern.\",\n \"c\": [\n \"Agent identity/auth\",\n \"A2A protocols\",\n \"Policy/governance\",\n \"AI safety/alignment\"\n ]\n}\n```", "in_tok": 577, "out_tok": 351}
|
|
|
|
|
{"draft_name": "draft-li-cdn-node-selection-enhancement", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft proposes enhancing CDN node selection by combining anycast routing with QUIC connection migration to enable load-aware and application-aware redirection. Clients signal service requirements while servers dynamically advertise routes based on real-time load and link quality.\",\n \"n\": 2,\n \"nn\": \"Incremental combination of existing technologies (anycast, BGP, QUIC); load-aware anycast routing is conceptually known, though QUIC connection migration for CDN redirection adds minor novelty.\",\n \"m\": 2,\n \"mn\": \"Early sketch stage; abstract describes concepts but 6-page draft likely lacks detailed protocol specification, message formats, state machines, or implementation considerations necessary for standardization.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing CDN optimization work (RFC 7679, load-balancing drafts) and QUIC connection migration use cases; anycast-based load signaling partially explored in prior work.\",\n \"mo\": 1,\n \"mon\": \"No evidence of working group sponsorship, multiple revisions, or community adoption; single draft dated 2025-11-07 with no visible ecosystem momentum.\",\n \"r\": 1,\n \"rn\": \"Not relevant to AI agents or autonomous systems; purely addresses CDN infrastructure optimization without AI/ML/agent components.\",\n \"c\": [\"Other AI/agent\"]\n}\n```", "in_tok": 702, "out_tok": 332}
|
|
|
|
|
{"draft_name": "draft-johani-dnsop-transport-signaling", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes a DNS signaling mechanism for authoritative servers to advertise support for alternative transport protocols (DoT, DoH, DoQ) in DNS responses, enabling resolvers to opportunistically upgrade connections while maintaining backward compatibility and DNSSEC validation options.\",\n \"n\": 2,\n \"nn\": \"Incremental improvement over RFC 9539's opportunistic transport testing; adds explicit signaling rather than blind discovery, but the core concept of advertising alternative transports is not novel.\",\n \"m\": 3,\n \"mn\": \"Protocol mechanism is defined with multiple modes (opportunistic, validated) but lacks detailed implementation guidance, test vectors, and real-world deployment examples. Draft appears incomplete (abstract cuts off mid-sentence).\",\n \"o\": 3,\n \"on\": \"Shares concepts with existing transport discovery mechanisms and DNSSEC validation approaches; relates to ongoing DNS privacy/security work but presents a distinct signaling approach.\",\n \"mo\": 2,\n \"mon\": \"Single revision visible; GitHub collaboration noted but limited evidence of WG engagement or community adoption. Early-stage development momentum.\",\n \"r\": 1,\n \"rn\": \"Not relevant to AI agents or autonomous systems. Pure DNS infrastructure optimization with no connection to agent protocols, discovery, or autonomous operations.\",\n \"c\": [\"Other AI/agent\"]\n}\n```", "in_tok": 899, "out_tok": 313}
|
|
|
|
|
{"draft_name": "draft-li-spring-rdma-multicast-over-srv6", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft extends SRv6 to enable RDMA multicast by introducing the End.MT endpoint behavior for per-receiver BTH modifications and ACK/NACK aggregation on reverse paths. It allows standard RDMA QP semantics to operate over IP multicast trees for distributed storage, HPC, and AI training scenarios.\",\n \"n\": 2,\n \"nn\": \"Incremental extension combining existing SRv6 and RDMA concepts; the core innovation (per-receiver BTH modification at edge nodes) is a straightforward adaptation rather than a fundamentally new approach.\",\n \"m\": 3,\n \"mn\": \"Defines protocol mechanisms and procedures with reasonable detail, but appears to lack implementation experience, comprehensive examples, and test vectors needed for production deployment.\",\n \"o\": 3,\n \"on\": \"Shares conceptual overlap with SRv6 endpoint behaviors and RDMA multicast literature; combines known techniques but in a novel integration point that has limited direct precedent.\",\n \"mo\": 1,\n \"mon\": \"Single draft dated 2026-03-01 with no apparent revision history or follow-up; no evidence of WG discussion, implementation efforts, or community adoption signals.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to AI infrastructure (targets AI training parameter distribution and KV cache distribution), but primarily focused on network protocol mechanics rather than agent-specific concerns.\",\n \"c\": [\"ML traffic mgmt\", \"Model serving/inference\", \"Other AI/agent\"]\n}\n```", "in_tok": 675, "out_tok": 360}
|
|
|
|
|
{"draft_name": "draft-ietf-lake-app-profiles", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This IETF draft defines a canonical CBOR-based representation for EDHOC application profiles to standardize parameter coordination and distribution across implementations. It establishes well-known profiles and mechanisms to facilitate interoperability and extensibility of the EDHOC lightweight authenticated key exchange protocol.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution that formalizes and standardizes existing EDHOC profile concepts into a structured format; the core innovation of profile coordination is modest but practically useful.\",\n \"m\": 4,\n \"mn\": \"Well-developed specification with detailed CBOR representations, coordination mechanisms, and defined profiles; appears ready for implementation with clear technical requirements.\",\n \"o\": 3,\n \"on\": \"Shares foundational concepts with EDHOC base specs and general profile/parameter negotiation patterns; represents specialized profile coordination rather than novel architectural approach.\",\n \"mo\": 4,\n \"mon\": \"Active IETF working group development (LAKE WG) with structured progression toward standardization; demonstrates sustained organizational commitment.\",\n \"r\": 1,\n \"rn\": \"Focused exclusively on cryptographic key exchange protocol standardization for IoT/constrained devices; has no relevance to AI agents, autonomous systems, or agent-oriented architectures.\",\n \"c\": [\"Other AI/agent\"]\n}\n```", "in_tok": 689, "out_tok": 316}
|
|
|
|
|
{"draft_name": "draft-chen-secure-routing-use-cases", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft proposes incorporating security and trustworthiness metrics into routing decisions beyond traditional shortest-path algorithms, aiming to leverage ISP security infrastructure for secure data transmission. The work focuses on transmission-layer security rather than end-to-end or application-layer concerns.\",\n \"n\": 2,\n \"nn\": \"Incremental extension of existing routing concepts with security factors; the idea of security-aware routing is not novel and has been explored in prior work.\",\n \"m\": 1,\n \"mn\": \"Presents use cases and motivation only; lacks protocol specification, detailed mechanisms, algorithms, or implementation details.\",\n \"o\": 4,\n \"on\": \"Significant overlap with established work in secure routing, risk-aware routing, and QoS-based routing; similar concepts appear in multiple RFC and draft standards.\",\n \"mo\": 1,\n \"mon\": \"Single revision document with no evidence of WG engagement, community discussion, or iterative development; appears dormant.\",\n \"r\": 1,\n \"rn\": \"Not relevant to AI agents or autonomous systems; concerns traditional network routing infrastructure independent of AI/ML applications.\",\n \"c\": [\"Other AI/agent\"]\n}\n```", "in_tok": 615, "out_tok": 283}
|
|
|
|
|
{"draft_name": "draft-williams-netmod-lm-hierarchy-topology", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes a YANG-based hierarchical topology for distributed language model coordination across heterogeneous nodes with secure messaging and token-based authorization. Targets edge-to-cloud deployments where LMs of varying sizes cooperate on inference and decision-making tasks.\",\n \"n\": 2,\n \"nn\": \"Incremental application of existing YANG/NETMOD patterns to LM orchestration; hierarchical ML coordination is established in practice (Ollama, vLLM, MLC-LM) but formalizing it via IETF standards is moderately novel.\",\n \"m\": 2,\n \"mn\": \"Early sketch with abstract architecture; 12 pages insufficient for protocol detail, security properties, trust model specifics, or YANG schema completeness. No reference implementation or validation data present.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing model serving platforms (Ray Serve, Kubernetes ML operators, vLLM distributed inference). Trust/auth mechanisms resemble standard OAuth/mTLS patterns. YANG-for-AI is nascent but overlaps with ongoing IETF TEEP and netmod work.\",\n \"m\": 1,\n \"mn\": \"Single dated submission (2026-02-11 is future/test date); no revision history evident. No WG sponsorship indicated. Appears orphaned relative to active IETF netmod or AI-focused initiatives.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to AI agent infrastructure; focuses on coordination/orchestration rather than core agent autonomy, decision-making, or safety. Relevant for multi-agent systems needing standardized topology but not for alignment or behavioral control.\",\n \"c\": [\n \"Model serving/inference\",\n \"A2A protocols\",\n \"Agent discovery/reg\",\n \"Data formats/interop\",\n \"Agent identity/auth\"\n ]\n}\n```", "in_tok": 604, "out_tok": 451}
|
|
|
|
|
{"draft_name": "draft-hood-independent-agtp", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"AGTP proposes a dedicated application-layer protocol for AI agent traffic, introducing a runtime contract negotiation substrate with 12 core methods organized as cognitive and mechanical verbs. The draft positions AGTP as a transport substrate for higher-level agent frameworks like MCP and A2A, addressing semantic vocabulary and observability gaps in HTTP-based agent communication.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution that repackages existing agent messaging concepts (MCP, ACP, A2A, ANP) into a new transport layer; the cognitive/mechanical verb taxonomy and runtime negotiation are modest extensions rather than fundamental innovations.\",\n \"m\": 3,\n \"mn\": \"Protocol specification appears reasonably detailed with URI grammar, method definitions, and status code assignments, but abstract truncation and lack of visible implementation evidence or test vectors limit confidence in implementation readiness.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing agent group messaging protocols (MCP, ACP, A2A, ANP); essentially proposes wrapping these in a new transport rather than offering orthogonal functionality; runtime negotiation concept borrowed from HTTP OPTIONS and capability negotiation patterns.\",\n \"mo\": 2,\n \"mon\": \"Single revision (v07 noted) with limited evidence of broader WG adoption or community momentum; niche applicability to agent-specific traffic may limit traction beyond specialized implementations.\",\n \"r\": 4,\n \"rn\": \"Directly addresses agent communication infrastructure and identity/authentication concerns; relevant to agent scalability and observability, though framing as transport-layer solution may be premature given evolving agent protocol landscape.\",\n \"c\": [\n \"A2A protocols\",\n \"Agent identity/auth\",\n \"Data formats/interop\",\n \"ML traffic mgmt\",\n \"Agent discovery/reg\"\n ]\n}\n```", "in_tok": 959, "out_tok": 433}
|
|
|
|
|
{"draft_name": "draft-ietf-tls-ecdhe-mlkem", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Defines three hybrid post-quantum key agreement mechanisms for TLS 1.3 combining ML-KEM with ECDHE (X25519MLKEM768, SecP256r1MLKEM768, SecP384r1MLKEM1024) to provide transitional cryptographic security during the migration to post-quantum standards.\",\n \"n\": 2,\n \"nn\": \"Incremental extension applying existing ML-KEM and ECDHE primitives to TLS 1.3; hybrid approach is standard practice for PQC migration but mechanically straightforward.\",\n \"m\": 4,\n \"mn\": \"Well-defined protocol specification with clear ciphersuites and integration points; lacks implementation details and test vectors for production readiness but specification is mature.\",\n \"o\": 3,\n \"on\": \"Shares core hybrid PQC concepts with draft-ietf-tls-hybrid-design and NIST PQC standards; similar to concurrent hybrid proposals but uses standardized ML-KEM rather than experimental schemes.\",\n \"r\": 1,\n \"rn\": \"Not relevant to AI agents; this is cryptographic infrastructure for TLS without connection to autonomous agents, agent identity/authentication, or AI-specific networking concerns.\",\n \"mo\": 4,\n \"mon\": \"Strong community momentum from IETF TLS WG pursuing post-quantum cryptography; aligns with NIST standardization timelines and urgent industry PQC migration needs.\",\n \"c\": [\n \"Other AI/agent\"\n ]\n}\n```", "in_tok": 568, "out_tok": 368}
|
|
|
|
|
{"draft_name": "draft-ietf-anima-brski-ae", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"BRSKI-AE extends the BRSKI bootstrapping protocol to support alternative certificate enrollment mechanisms like CMP instead of EST, enabling flexible device onboarding across diverse network environments. This provides a framework for integrating suitable enrollment protocols while maintaining security and scalability in network device provisioning.\",\n \"n\": 2,\n \"nn\": \"Incremental extension to existing BRSKI standard; primarily substitutes enrollment protocol options rather than introducing fundamentally new concepts\",\n \"m\": 4,\n \"mn\": \"Well-developed specification with architectural updates and protocol details; appears implementation-ready with comprehensive framework for alternative methods\",\n \"o\": 3,\n \"on\": \"Shares core concepts with BRSKI, EST, and CMP specifications; builds naturally on established standards with moderate overlap in design patterns\",\n \"mo\": 3,\n \"mon\": \"Active WG development typical of IETF standards track; appears to address real operational needs in device bootstrapping scenarios\",\n \"r\": 1,\n \"rn\": \"Not relevant to AI agents, autonomous systems, or machine learning operations; focuses on traditional IoT/network device enrollment infrastructure\",\n \"c\": [\n \"Other AI/agent\"\n ]\n}\n```", "in_tok": 636, "out_tok": 290}
|
|
|
|
|
{"draft_name": "draft-morrison-agent-channel-fan-out", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Specifies an application-layer frame format for fan-out message delivery across concurrent agentic sessions within a single identity-bound principal, using Server-Sent Events and scope-based recipient expansion. The agent-channel frame carries kind discriminators, structured payloads, identity attribution, and provenance blocks, composing with existing handle namespace and discovery mechanisms.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution combining existing concepts (SSE, fan-out messaging, identity-scoped delivery) without fundamental novelty; primarily an envelope specification layering on established protocols.\",\n \"m\": 3,\n \"mn\": \"Defined protocol specification with grammar for scope expansion and filter expressions, though frame persistence is explicitly out-of-scope; lacks implementation artifacts like test vectors or reference implementations.\",\n \"o\": 4,\n \"on\": \"Significant overlap with pub-sub patterns, SSE-based messaging systems, and identity-keyed routing; conceptually similar to topic-based fan-out in existing message brokers adapted for agent contexts.\",\n \"mo\": 2,\n \"mon\": \"Single draft revision with future date (2026-05-21); unclear WG adoption or community engagement; no evidence of active development cycle or multiple iterations.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to agent coordination and identity-based interoperability; focuses on agent session management and organizational substrate messaging, core to multi-agent system architecture.\",\n \"c\": [\n \"A2A protocols\",\n \"Agent identity/auth\",\n \"Data formats/interop\",\n \"Agent discovery/reg\"\n ]\n}\n```", "in_tok": 763, "out_tok": 383}
|
|
|
|
|
{"draft_name": "draft-ainp-protocol", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"AINP proposes a semantic communication protocol for AI agents using intent-based routing and capability discovery instead of traditional IP networking. The draft replaces conventional network abstractions with agent-native concepts like structured intents, autonomous negotiation, and cryptographic security for multi-agent coordination.\",\n \"n\": 2,\n \"nn\": \"The core idea of replacing location-based routing with semantic/intent-based routing for agents is incremental rather than novel\u2014it mirrors existing service discovery and publish-subscribe patterns adapted to agent contexts. The conceptual components are recognizable extensions of established networking and agent communication paradigms.\",\n \"m\": 2,\n \"mn\": \"The draft presents early-stage conceptual framing without rigorous protocol specification. Missing are detailed message formats, state machines, formal syntax definitions, implementation guidance, and security analysis. Version 0.1 designation and 17-page length suggest preliminary sketching rather than protocol maturity.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing work: service discovery (mDNS, DNS-SD), intent-based networking (IBN proposals), agent communication frameworks (FIPA ACL, JADE), and semantic web protocols. The framing as 'AI-Native' is somewhat novel but the underlying mechanisms map closely to established patterns.\",\n \"m\": 1,\n \"mon\": \"No evidence of WG adoption, community feedback cycles, or revision history indicating active development. Single draft snapshot with no visible momentum within IETF or broader standardization bodies. Appears exploratory rather than actively driven.\",\n \"r\": 4,\n \"rn\": \"Directly addresses multi-agent coordination and communication, which is a core AI agent infrastructure concern. However, focuses narrowly on network protocol layer rather than broader agent alignment, safety, or orchestration challenges. Relevant but somewhat limited in scope within AI agent ecosystem.\",\n \"c\": [\n \"A2A protocols\",\n \"Agent discovery/reg\",\n \"Data formats/interop\",\n \"Agent identity/auth\",\n \"Autonomous netops\"\n ]\n}\n```", "in_tok": 559, "out_tok": 479}
|
|
|
|
|
{"draft_name": "draft-song-dmsc-problem-statement", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft proposes a centralized gateway architecture (DMSC) to handle communication, security, and collaboration logic for multi-agent LLM systems, offloading these concerns from individual agents. It addresses fragmentation and security risks in cloud-native multi-tenant deployments by providing standardized service discovery, encryption, and policy enforcement.\",\n \"n\": 2,\n \"nn\": \"The core concept of offloading agent infrastructure concerns to a gateway is incremental; similar patterns exist in service meshes (Istio), API gateways, and agent platforms. The application to LLM agents is somewhat novel but architecturally conventional.\",\n \"m\": 1,\n \"mn\": \"This is purely a problem statement and requirements document with no protocol specification, mechanism design, or implementation details provided. It reads as early-stage positioning without technical depth.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing work: service mesh architectures (Envoy, Istio), agent platforms (Kubernetes operators), API gateway patterns, and multi-tenant orchestration frameworks already address these requirements. The framing around LLM agents is new but the underlying technical challenges are well-explored.\",\n \"m\": 1,\n \"mon\": \"Document appears to be a single submission with no revision history or visible community engagement. No evidence of WG discussion, implementation efforts, or broader adoption momentum.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to AI agent systems. Focuses primarily on infrastructure/networking aspects rather than core agent capabilities, reasoning, or AI-specific concerns. Addresses operational challenges but not AI safety, alignment, or agent behavior.\",\n \"c\": [\n \"A2A protocols\",\n \"Agent discovery/reg\",\n \"Agent identity/auth\",\n \"Policy/governance\",\n \"Autonomous netops\"\n ]\n}\n```", "in_tok": 664, "out_tok": 432}
|
|
|
|
|
{"draft_name": "draft-cowles-volt", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"VOLT proposes a cryptographically-secured audit trail protocol for AI agent workflows, using hash-chained records and portable Evidence Bundles to detect tampering. It emphasizes privacy through content-addressing, redaction support, and optional signatures for non-repudiation.\",\n \"n\": 3,\n \"nn\": \"Hash-chain audit logging is established; novelty lies in domain-specific application to agentic AI with privacy-first design and Evidence Bundle portability, though mechanisms are largely conventional.\",\n \"m\": 3,\n \"mn\": \"Protocol structure clearly defined with explicit features (redaction, signatures, snapshots), but lacks implementation details, test vectors, and reference implementations needed for maturity level 4-5.\",\n \"o\": 3,\n \"on\": \"Shares concepts with existing audit/logging protocols (blockchain provenance patterns, Merkle trees) and agent transparency work; overlaps conceptually with W3C Verifiable Credentials and COSE signing approaches.\",\n \"m\": 2,\n \"mon\": \"Single draft submission (2026-02-28); no evidence of WG adoption, revisions, or community feedback cycle yet. Early-stage proposal momentum.\",\n \"r\": 4,\n \"rn\": \"Directly addresses critical need for AI agent auditability and tamper-evidence in high-stakes deployments; highly relevant to trustworthiness and governance concerns.\",\n \"c\": [\"Data formats/interop\", \"Policy/governance\", \"Human-agent interaction\", \"Agent identity/auth\", \"AI safety/alignment\"]\n}\n```", "in_tok": 672, "out_tok": 368}
|
|
|
|
|
{"draft_name": "draft-mw-wimse-transitive-attestation", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes a WIMSE profile enabling cryptographic binding of software workloads to execution environments via transitive attestation chains, addressing credential portability risks in autonomous AI agents across jurisdictions. Combines RATS-based residency verification with standard identity agents to ensure identities are valid only from verified, integral hosts.\",\n \"n\": 3,\n \"nn\": \"Transitive attestation concept is useful but represents incremental extension of existing WIMSE and RATS frameworks; the application to AI agent mobility is timely but the core mechanism lacks significant novelty.\",\n \"m\": 2,\n \"mn\": \"Early sketch stage: abstract defines vision and problem well, but 11 pages suggests limited protocol detail, no implementation examples, test vectors, or concrete message flows provided; defers critical security assumptions (WIA integrity) to companion draft.\",\n \"o\": 4,\n \"on\": \"Substantial overlap with verifiable geofencing draft it references; similar to existing WIMSE identity profiles and general RATS attestation patterns; limited differentiation beyond applying these to AI agent scenarios.\",\n \"mo\": 2,\n \"mon\": \"Single draft submission dated 2026 with unclear WG adoption; references to companion drafts suggest early-stage work; no visible community discussion or multiple iterations; momentum appears nascent.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to agent identity and authentication; addresses real AI agent threat model (hijacking, prompt injection, jurisdiction crossing); positions as core security layer for autonomous systems in multi-environment deployments.\",\n \"c\": [\n \"Agent identity/auth\",\n \"Policy/governance\",\n \"A2A protocols\",\n \"AI safety/alignment\",\n \"Data formats/interop\"\n ]\n}\n```", "in_tok": 808, "out_tok": 410}
|
|
|
|
|
{"draft_name": "draft-jurkovikj-collab-tunnel", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"TCT Protocol proposes an HTTP-based JSON envelope for delivering web content to automated agents with negotiated text formats, metadata, and bidirectional URL discovery. It combines existing technologies (ETags, conditional requests, JSON sitemaps) to optimize bandwidth for machine-readable content consumption.\",\n \"n\": 2,\n \"nn\": \"Incremental combination of established HTTP mechanisms (conditional requests, ETags) with a JSON wrapper format. No novel protocol primitives or fundamentally new approach to agent-server interaction.\",\n \"m\": 3,\n \"mn\": \"Protocol specification is defined with JSON envelope structure and HTTP mechanics documented, but lacks implementation examples, test vectors, or reference implementations that would demonstrate production readiness.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing standards: mimics aspects of Sitemaps protocol, conditional HTTP requests (RFC 7232), content negotiation (RFC 7231), and overlaps conceptually with OpenAPI/schema approaches for machine-readable APIs.\",\n \"mo\": 1,\n \"mon\": \"Single dated draft (2026-05-12) with no evidence of multiple revisions, WG discussion, or community adoption. Appears to be isolated proposal without follow-up activity.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to AI agents; addresses content delivery to automated clients but focuses narrowly on format/metadata wrapping rather than agent autonomy, coordination, or intelligence. More infrastructure than AI-specific.\",\n \"c\": [\n \"Data formats/interop\",\n \"Agent discovery/reg\",\n \"A2A protocols\",\n \"Human-agent interaction\"\n ]\n}\n```", "in_tok": 573, "out_tok": 389}
|
|
|
|
|
{"draft_name": "draft-jennings-ai-mcp-over-moq", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft specifies how to transport the Model Context Protocol (MCP) over MOQT, enabling efficient publish-subscribe delivery of AI agent resources, tools, and skills with progressive loading. It focuses on scalable relay architectures and bandwidth optimization for distributed AI service deployments.\",\n \"n\": 2,\n \"nn\": \"Straightforward application of existing MOQT transport to MCP protocol; combines established technologies without fundamental innovation in either protocol or architecture.\",\n \"m\": 3,\n \"mn\": \"Reasonably complete protocol specification with message mapping and procedures defined, but lacks implementation examples, test vectors, and validation of the progressive loading efficiency claims.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing MCP implementations and MOQT specifications; primarily an engineering integration effort rather than novel protocol design.\",\n \"mo\": 2,\n \"mon\": \"Single dated revision (2026-03-02) with no evidence of active development, WG discussion, or community adoption; appears exploratory rather than established initiative.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI agent infrastructure and A2A protocol standardization; addresses practical scalability needs for distributed MCP deployments.\",\n \"c\": [\n \"A2A protocols\",\n \"Data formats/interop\",\n \"Model serving/inference\",\n \"Agent discovery/reg\",\n \"ML traffic mgmt\"\n ]\n}\n```", "in_tok": 750, "out_tok": 341}
|
|
|
|
|
{"draft_name": "draft-luan-rtgwg-sdaf", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"SDAF proposes a symmetry-driven asynchronous forwarding mechanism for LEO satellite networks that exploits toroidal topology properties to achieve fast convergence without control-plane synchronization. The approach autonomously handles reverse flows using only local link-state information, compatible with existing protocols like OSPFv3 and IS-IS, demonstrating microsecond-scale convergence and reduced packet loss in simulations.\",\n \"n\": 3,\n \"nn\": \"Leveraging toroidal topology symmetry for asynchronous forwarding is a useful contribution, but fundamentally applies established fast-reroute and local repair concepts to satellite-specific constraints rather than introducing genuinely novel algorithmic principles.\",\n \"m\": 4,\n \"mn\": \"Well-defined mechanism with simulation results and actual satellite router testing; lacks formal protocol specification detail and standardization-ready implementation guidance, but demonstrates sufficient maturity for WG consideration.\",\n \"o\": 3,\n \"on\": \"Shares conceptual overlap with existing fast-reroute mechanisms (LFA, uloop avoidance literature) and local repair approaches; novel application domain and topology-specific optimization reduce but don't eliminate overlap with prior work.\",\n \"m\": 2,\n \"mon\": \"Single draft submission in early 2026 with no apparent WG sponsorship or revision history visible; presents specialized satellite network solution without clear broader IETF community adoption trajectory.\",\n \"r\": 2,\n \"rn\": \"Addresses autonomous routing and convergence in constrained systems, but does not directly engage with AI agents, autonomous system intelligence, or machine learning; tangentially related to autonomous network operations only through the 'autonomous' descriptor.\",\n \"c\": [\"Autonomous netops\", \"Other AI/agent\"]\n}\n```", "in_tok": 886, "out_tok": 408}
|
|
|
|
|
{"draft_name": "draft-liu-nmrg-ai-llm-inference-requirements", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft analyzes system and network requirements for large-scale LLM inference services by examining mainstream frameworks like vLLM and SGLang, identifying challenges in computing and communication demands. It aims to establish foundational understanding for defining unified LLM inference architectures from a network management perspective.\",\n \"n\": 2,\n \"nn\": \"Requirements analysis of existing inference frameworks is incremental; primarily surveys known systems rather than proposing novel solutions or architectures.\",\n \"m\": 2,\n \"mn\": \"Early-stage requirements gathering document without concrete protocol specifications, mechanisms, or implementation guidance; lacks technical depth and actionable recommendations.\",\n \"o\": 3,\n \"on\": \"Overlaps with existing literature on ML system performance, distributed inference optimization, and datacenter networking; survey-style analysis without differentiation from prior work.\",\n \"mo\": 1,\n \"mon\": \"Single draft with November 2025 date and minimal community momentum; appears to be exploratory work without evidence of WG engagement or adoption pathway.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI model serving and network management for inference workloads; focuses on system requirements rather than core agent-oriented topics.\",\n \"c\": [\"Model serving/inference\", \"ML traffic mgmt\", \"Policy/governance\"]\n}\n```", "in_tok": 651, "out_tok": 309}
|
|
|
|
|
{"draft_name": "draft-aevum-causal-intervention-record", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"PACR proposes a wire format for recording verifiable causal intervention events between autonomous agents, binding identity, predecessors, thermodynamic costs, and resource metrics into a content-addressed DAG. It aims to provide accountability for agent actions across digital, physical, and biological substrates without requiring wall-clock timestamps.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution combining existing concepts (causal DAGs, Pearl's do-calculus, content addressing) into a specialized wire format; the core ideas lack novelty but application to agent accountability is somewhat focused.\",\n \"m\": 2,\n \"mn\": \"Early specification sketch with abstract structure defined but missing critical details: no serialization examples, unclear how thermodynamic costs are computed/verified, no concrete encoding rules, no test vectors or reference implementations.\",\n \"o\": 4,\n \"on\": \"Significant overlap with blockchain/ledger causality tracing, distributed systems event logs (Lamport clocks, vector clocks), and existing causal consistency frameworks; the thermodynamic annotation layer is somewhat novel but integration remains underspecified.\",\n \"mo\": 1,\n \"mon\": \"Appears to be single-submission work with April 2026 date (future/hypothetical), no evidence of WG adoption, revision history, or community feedback; minimal GitHub activity indicators detectable.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to autonomous agents and accountability, but framing is overly abstract and philosophical; lacks grounding in practical multi-agent systems problems; thermodynamic costs and 'cognitive complexity splits' are poorly motivated.\",\n \"c\": [\n \"A2A protocols\",\n \"Agent identity/auth\",\n \"Data formats/interop\",\n \"AI safety/alignment\",\n \"Policy/governance\"\n ]\n}\n```", "in_tok": 821, "out_tok": 425}
|
|
|
|
|
{"draft_name": "draft-reilly-plpes", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"PLPES proposes a formal specification framework for standardizing prompts used in AI systems, including canonical representation formats, classification taxonomies, versioning, and security mechanisms. It aims to address reproducibility, injection vulnerabilities, and auditability gaps in prompt-driven AI deployments across critical infrastructure and enterprise workflows.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution applying existing standardization patterns (versioning, classification, integrity verification) to prompt engineering; the core idea of formalizing prompts is sensible but lacks conceptual novelty.\",\n \"m\": 3,\n \"mn\": \"Defines protocol mechanisms (PDO schema, taxonomy, versioning model) and references external specs (REM Protocol), but abstract doesn't demonstrate detailed implementation examples, test vectors, or validation procedures typical of mature IETF protocols.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing prompt management systems (LangChain, Anthropic's prompt caching), model card specifications (Mitchell et al.), and software supply chain standards (SBOM, SLSA); positions itself as novel but borrows heavily from established practices.\",\n \"mo\": 1,\n \"mon\": \"April 2026 date is future-dated (likely a placeholder); single draft with no indication of WG adoption, community engagement, or revision history; appears to be early-stage individual submission without demonstrated momentum.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI agent systems and agentic prompt chains; addresses real operational concerns (reproducibility, security, auditability) in deployed AI systems, though focus is narrower than core agent architecture topics.\",\n \"c\": [\n \"Data formats/interop\",\n \"AI safety/alignment\",\n \"Agent identity/auth\",\n \"Policy/governance\",\n \"Human-agent interaction\"\n ]\n}\n```", "in_tok": 775, "out_tok": 435}
|
|
|
|
|
{"draft_name": "draft-zhang-dmsc-mas-communication", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Analyzes security gaps in multi-agent system communication protocols (TLS, HTTP, MQTT) and frameworks (AutoGen), identifying limitations around agent-native semantics like dynamic identity and context integrity. Establishes a problem statement and gap analysis to guide future IETF standardization in agent communication.\",\n \"n\": 2,\n \"nn\": \"Incremental analysis combining known protocol limitations with MAS-specific concerns; agent security issues are recognized but framing as gap analysis rather than novel solutions\",\n \"m\": 1,\n \"mn\": \"Problem statement and gap analysis only; no protocol design, mechanism specification, or concrete recommendations provided beyond identifying limitations\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing security literature on MAS, protocol analysis work, and authentication frameworks; agent communication security has been addressed in distributed systems and robotics communities\",\n \"mo\": 1,\n \"mon\": \"Initial draft with unclear adoption path; no evidence of WG discussion, community feedback, or follow-up revisions; problem identification without proposed solutions limits traction\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI agent infrastructure; addresses real deployment concerns in agent frameworks and multi-agent orchestration, though execution is analysis-only\",\n \"c\": [\n \"A2A protocols\",\n \"Agent identity/auth\",\n \"Data formats/interop\",\n \"Policy/governance\"\n ]\n}\n```", "in_tok": 601, "out_tok": 341}
|
|
|
|
|
{"draft_name": "draft-steele-agent-considerations", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft proposes adding 'Agent Consideration' sections to IETF specifications to guide AI agents in consuming specs and generating code. It defines guidance mechanisms including agentcards, annotated examples, and language-specific directives for media-type production.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution addressing a newly relevant problem (AI-assisted code generation from specs) but using straightforward annotation and guidance approaches without significant technical innovation.\",\n \"m\": 2,\n \"mn\": \"Early sketch phase with conceptual framework but lacks implementation details, concrete agentcard schemas, validation mechanisms, or working examples demonstrating practical utility.\",\n \"o\": 3,\n \"on\": \"Shares overlapping concepts with existing efforts in spec annotation (OpenAPI, AsyncAPI), code generation guidance, and AI-assisted tooling, though applied specifically to IETF context.\",\n \"mo\": 1,\n \"mon\": \"Single revision with no evidence of WG adoption, community discussion, or iterative development since initial draft date; appears speculative rather than addressing established need.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to AI agent concerns\u2014addresses agent consumption of specifications but focuses narrowly on code generation assistance rather than core agent coordination, autonomy, or safety issues.\",\n \"c\": [\"Data formats/interop\", \"Human-agent interaction\", \"Other AI/agent\"]\n}\n```", "in_tok": 604, "out_tok": 331}
|
|
|
|
|
{"draft_name": "draft-ar-emu-pqc-eapaka", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft proposes integrating post-quantum cryptography hybrid algorithms into EAP-AKA' Forward Secrecy to protect against quantum computing threats to ephemeral keys. It extends RFC9678 by replacing traditional ECDHE with PQ/T hybrid key agreement mechanisms.\",\n \"n\": 2,\n \"nn\": \"Straightforward application of existing hybrid PQC frameworks to an established protocol; limited algorithmic innovation beyond combining known components.\",\n \"m\": 2,\n \"mn\": \"Early draft stage presenting motivation and problem statement; lacks detailed protocol specification, implementation guidance, test vectors, and performance analysis needed for maturity.\",\n \"o\": 3,\n \"on\": \"Shares core concepts with ongoing PQC hybrid standardization efforts (NIST, IETF PQUIP); similar approaches being explored in TLS 1.3 PQC variants and other EAP extensions.\",\n \"mo\": 1,\n \"mon\": \"Single revision as recent draft (2025-03-17); no evidence of WG sponsorship, community feedback cycles, or implementation activity.\",\n \"r\": 2,\n \"rn\": \"Not relevant to AI agents; addresses network authentication protocol security. Agent identity/auth category is for agent-specific authentication mechanisms, not cellular/general network protocols.\",\n \"c\": [\"Agent identity/auth\"]\n}\n```", "in_tok": 720, "out_tok": 325}
|
|
|
|
|
{"draft_name": "draft-zhang-agent-gap-network", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft analyzes gaps and problems in integrating AI agents into mobile core networks, addressing architectural, operational, and interoperability challenges in agent-enabled telecom infrastructure.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution applying existing agent concepts to mobile network domain; lacks novel architectural insights or mechanisms specific to cellular core networks.\",\n \"m\": 1,\n \"mn\": \"Problem statement and gap analysis document only; no protocol specifications, mechanisms, or implementation details provided; foundational stage.\",\n \"o\": 3,\n \"on\": \"Shares conceptual overlap with broader agent architecture and mobile network optimization work; positions within established telecom and autonomous systems discussions.\",\n \"mo\": 2,\n \"mon\": \"Early-stage draft with single revision; limited evidence of WG traction or community engagement; agent integration in mobile networks is niche.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to AI agents in networks; focuses on problem identification rather than agent behavior, autonomy, or intelligence; more infrastructure than agent-centric.\",\n \"c\": [\n \"Autonomous netops\",\n \"Policy/governance\",\n \"Agent discovery/reg\",\n \"Data formats/interop\",\n \"Other AI/agent\"\n ]\n}\n```", "in_tok": 466, "out_tok": 305}
|
|
|
|
|
{"draft_name": "draft-barney-caam", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"CAAM defines a post-discovery authorization layer for agent systems, combining relationship-based access control with cryptographic attestation through JWT/CWT tokens. It integrates with ARDP discovery and bridges IPSIE/SPIFFE identity frameworks to govern H2A and A2A interactions with purpose-bound delegation.\",\n \"n\": 3,\n \"nn\": \"Applies established patterns (ReBAC, JWT, RATS) to agent authorization; contextual assertion claim is useful but incremental innovation in token-based access control.\",\n \"m\": 2,\n \"mn\": \"Specification exists but lacks implementation details, test vectors, and concrete usage examples; relies heavily on external draft references (ARDP, IPSIE) that may be nascent.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing authorization frameworks (OAuth 2.0, ABAC patterns); relationship-based access control well-established in industry; main differentiation is agent-specific integration point.\",\n \"mo\": 2,\n \"mon\": \"Single revision dated 2026-02; no visible WG adoption, community discussion, or implementation signals; appears to be early-stage individual submission.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to agent systems and A2A security; addresses real need for runtime authorization in agent meshes, though scope depends on ARDP adoption which remains uncertain.\",\n \"c\": [\n \"Agent identity/auth\",\n \"A2A protocols\",\n \"Agent discovery/reg\",\n \"Policy/governance\",\n \"Data formats/interop\",\n \"Human-agent interaction\"\n ]\n}\n```", "in_tok": 842, "out_tok": 392}
|
|
|
|
|
{"draft_name": "draft-tiloca-lake-edhoc-implem-cons", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft provides implementation guidance for EDHOC, an authenticated key exchange protocol designed for constrained environments. It offers practical considerations for developers implementing this cryptographic protocol.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution focusing on implementation details of an existing protocol rather than introducing new cryptographic concepts or techniques.\",\n \"m\": 4,\n \"mn\": \"Detailed implementation guidance with practical considerations, though not a complete specification with comprehensive test vectors.\",\n \"o\": 3,\n \"on\": \"Shares core concepts with related COSE and key exchange specifications; provides complementary implementation perspective rather than novel overlap.\",\n \"mo\": 3,\n \"mon\": \"Active development within IETF working groups with multiple revisions, though focused on guidance rather than protocol innovation.\",\n \"r\": 1,\n \"rn\": \"Not relevant to AI agents or autonomous systems; concerns cryptographic protocol implementation for constrained devices with no agent-specific application.\",\n \"c\": [\"Data formats/interop\", \"Agent identity/auth\"]\n}\n```", "in_tok": 506, "out_tok": 252}
|
|
|
|
|
{"draft_name": "draft-tong-network-agent-use-cases-in-6g", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft outlines use cases for network AI agents in 6G systems, focusing on connectivity and third-party application service scenarios derived from 3GPP standards. It discusses integration requirements and workflows for AI agents within the 6G framework.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution that applies existing AI agent concepts to 6G context; lacks novel architectural or methodological insights specific to network agents.\",\n \"m\": 2,\n \"mn\": \"Early-stage use case document with informal requirements specification; no protocols, detailed mechanisms, or implementation guidance provided.\",\n \"o\": 4,\n \"on\": \"Significant overlap with ongoing 6G standardization work, 3GPP TR22.870, and generic AI agent frameworks; limited differentiation from parallel 6G AI efforts.\",\n \"mo\": 1,\n \"mon\": \"Single revision draft with unclear WG sponsorship; appears exploratory rather than driven by active community adoption or iterative development.\",\n \"r\": 4,\n \"rn\": \"Directly addresses network AI agents in emerging 6G context, though execution focuses on use case enumeration rather than deep technical requirements for agent deployment.\",\n \"c\": [\"Autonomous netops\", \"Agent discovery/reg\", \"Policy/governance\", \"Data formats/interop\", \"Other AI/agent\"]\n}\n```", "in_tok": 560, "out_tok": 316}
|
|
|
|
|
{"draft_name": "draft-hood-agtp-merchant-identity", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Extends AGTP with symmetric merchant identity verification mechanisms including Merchant Manifest Documents, Trust Tiers, and protocol integration points to close the verification gap on the receiving side of agentic transactions. Introduces Intent-Assertion headers, Cart-Digest for multi-item transactions, and a 455 status code to establish bidirectional trust within AGTP's governance model.\",\n \"n\": 2,\n \"nn\": \"Incremental extension of existing AGTP framework; mirrors agent-side mechanisms to merchant side rather than introducing fundamentally new verification approaches.\",\n \"m\": 3,\n \"mn\": \"Well-defined protocol-level mechanisms with structural clarity and alignment across multiple integration points (PURCHASE, DISCOVER, Attribution-Record); lacks implementation details, test vectors, and deployment guidance.\",\n \"o\": 3,\n \"on\": \"Shares core concepts with existing PKI/identity frameworks and commerce protocols; directly parallels AGTP agent identity mechanisms; moderate overlap with standards work in API authentication and merchant verification.\",\n \"mo\": 2,\n \"mon\": \"Two versions with incremental refinements (v00\u2192v01); appears to follow AGTP release cycle but limited evidence of independent community adoption or WG traction.\",\n \"r\": 4,\n \"rn\": \"Directly addresses a critical gap in agentic commerce protocols; highly relevant to agent-to-agent and agent-to-service transactions, though assumes AGTP as foundational standard.\",\n \"c\": [\"A2A protocols\", \"Agent identity/auth\", \"Policy/governance\", \"Agent discovery/reg\", \"Data formats/interop\"]\n}\n```", "in_tok": 884, "out_tok": 381}
|
|
|
|
|
{"draft_name": "draft-yang-spring-sr-policy-intelligent-routing", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft proposes an intelligent routing method for SR (Segment Routing) Policy that leverages network quality metrics to select optimal candidate paths in MPLS and IPv6 environments. It extends existing SR Policy mechanisms with quality-aware path selection to improve routing decisions.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution combining existing SR Policy concepts with basic quality-of-service awareness; the intelligent routing concept itself is not novel in networking.\",\n \"m\": 2,\n \"mn\": \"Early sketch stage with abstract and problem statement; lacks detailed protocol specifications, algorithmic definitions, implementation guidelines, or test vectors necessary for implementation.\",\n \"o\": 4,\n \"on\": \"Significant overlap with RFC 8664 (SR Policy), RFC 9256 (Segment Routing Policy Architecture), and existing QoS-aware routing work; limited novel integration approach.\",\n \"mo\": 1,\n \"mon\": \"Single revision with 2025-06-15 date suggests initial submission; no evidence of WG discussion, multiple iterations, or community engagement in public archives.\",\n \"r\": 1,\n \"rn\": \"Not relevant to AI agents or autonomous systems; this is conventional network routing optimization without agent-based decision making, learning capabilities, or autonomous behaviors.\",\n \"c\": [\"ML traffic mgmt\"]\n}\n```", "in_tok": 531, "out_tok": 314}
|
|
|
|
|
{"draft_name": "draft-verma-dmsc-nlip-notes", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes using generative AI to create flexible communication protocols for agent-to-agent interactions, replacing strict APIs with natural language-based unified communication. Claims this approach enables better interoperability and reduces operational complexity across registration, discovery, telemetry, and debugging.\",\n \"n\": 2,\n \"nn\": \"Natural language for protocol definition is not novel; the application to agent APIs is incremental rather than genuinely original.\",\n \"m\": 1,\n \"mn\": \"Draft presents only problem statement and high-level conceptual argument; lacks protocol specification, formal definitions, examples, or implementation guidance.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing work on API abstraction, LLM-based protocol interpretation, and flexible agent communication frameworks; positions as novel but core ideas are established.\",\n \"mo\": 1,\n \"mon\": \"Single early-stage draft with no apparent revisions, WG adoption, or community engagement; appears to be initial submission without development momentum.\",\n \"r\": 3,\n \"rn\": \"Directly addresses agent communication but focuses narrowly on API flexibility via natural language rather than core AI agent capabilities, safety, or governance concerns.\",\n \"c\": [\"A2A protocols\", \"Data formats/interop\", \"Agent discovery/reg\", \"Model serving/inference\"]\n}\n```", "in_tok": 605, "out_tok": 312}
|
|
|
|
|
{"draft_name": "draft-xsaopig-nsttlp-traffic-labeling", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"NST-TLP proposes embedding service type identifiers into network packets via IPv4/IPv6, MPLS, or Ethernet headers to enable intelligent traffic recognition and policy-based forwarding. The mechanism targets diverse applications from VR to IoT, providing a standardized labeling approach for network resource optimization.\",\n \"n\": 2,\n \"nn\": \"Incremental extension of existing traffic classification and labeling concepts (DSCP, MPLS EXP, IEEE 802.1p). Core idea of adding service-type metadata to packets is well-established; limited novelty in mechanism design.\",\n \"m\": 2,\n \"mn\": \"Early draft stage with abstract and scope defined, but lacking protocol details. No indication of implementation, test vectors, or deployment experience. Needs substantial development to reach specification completeness.\",\n \"o\": 4,\n \"on\": \"Significant overlap with DSCP (RFC 2474), MPLS traffic engineering (RFC 3270), IEEE 802.1p prioritization, and newer work on packet in-band network telemetry (INT). Positioning relative to these existing mechanisms is unclear.\",\n \"m\": 1,\n \"mon\": \"Minimal community momentum evident. Single draft revision at 2026-01-29 with no apparent WG affiliation or multi-author collaboration. No visible discussion on IETF lists or adoption signals.\",\n \"r\": 1,\n \"rn\": \"Not relevant to AI agents or autonomous systems. Traditional network traffic classification and QoS mechanism with no connection to AI safety, agent identity, autonomous network operations, or agent-relevant protocols.\",\n \"c\": [\"Other AI/agent\"]\n}\n```", "in_tok": 595, "out_tok": 394}
|
|
|
|
|
{"draft_name": "draft-chen-oauth-scope-agent-extensions", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes a structured colon-separated syntax extension to OAuth 2.0 scopes to enable fine-grained permission expression for modular capability units (skills) in agent ecosystems. Addresses authorization gaps in agent installations by adding resource_type:action:target[:constraints] format while maintaining OAuth compatibility.\",\n \"n\": 2,\n \"nn\": \"Incremental extension applying existing OAuth scope concepts to agent scenarios; colon-delimited syntax is a straightforward syntactic enhancement rather than a fundamentally new authorization approach.\",\n \"m\": 3,\n \"mn\": \"Defines protocol mechanism with concrete syntax and use cases, but lacks implementation examples, test vectors, and validation rules for constraint expressions; unclear how constraint parsing and validation would work in practice.\",\n \"o\": 3,\n \"on\": \"Shares conceptual space with ABAC/RBAC frameworks and existing OAuth scope extensions (RFC 8693, capability-based security models); agent authorization addressed in parallel WG efforts but this syntax differs.\",\n \"mo\": 2,\n \"mon\": \"Single draft revision with 2026 date; no evidence of WG adoption, implementation feedback, or community discussion; nascent momentum in agent authorization space generally but this specific proposal lacks uptake signals.\",\n \"r\": 4,\n \"rn\": \"Directly addresses agent capability authorization and permission expression, core concerns for autonomous agent deployments; well-scoped to agent ecosystems though broader OAuth community relevance unclear.\",\n \"c\": [\"Agent identity/auth\", \"Data formats/interop\", \"Policy/governance\", \"A2A protocols\"]\n}\n```", "in_tok": 739, "out_tok": 374}
|
|
|
|
|
{"draft_name": "draft-oauth-transaction-tokens-for-agents", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Extends OAuth Transaction Tokens to support agent context propagation by using the 'act' field to identify agents and 'sub' field for principals, enabling granular access control in agent-based workloads. Applies existing token mechanisms to autonomous agent scenarios with minimal new functionality.\",\n \"n\": 2,\n \"nn\": \"Incremental extension applying established transaction token patterns to agents; limited conceptual novelty beyond field reuse\",\n \"m\": 3,\n \"mn\": \"Defined mechanism with clear field semantics but lacks implementation details, examples, and test vectors for agent-specific scenarios\",\n \"o\": 4,\n \"on\": \"Significant overlap with base OAuth-TXN-TOKENS; primarily a use-case mapping rather than novel protocol design; similar to existing delegation/impersonation token specs\",\n \"mo\": 2,\n \"mon\": \"Single revision with no visible WG discussion or implementation feedback; niche agent-focused extension with limited adoption signals\",\n \"r\": 4,\n \"rn\": \"Directly addresses agent authentication and authorization context propagation, a core requirement for distributed agent systems, though limited to OAuth ecosystem\",\n \"c\": [\n \"Agent identity/auth\",\n \"Data formats/interop\",\n \"Policy/governance\",\n \"A2A protocols\"\n ]\n}\n```", "in_tok": 679, "out_tok": 319}
|
|
|
|
|
{"draft_name": "draft-wahl-scim-agent-schema", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Extends SCIM protocol to represent AI agent identities in JSON format, enabling agent authentication and authorization in cloud services. Applies existing identity management standards to the emerging domain of agentic systems.\",\n \"n\": 2,\n \"nn\": \"Straightforward application of established SCIM patterns to agents; minimal conceptual innovation beyond standard identity schema extension.\",\n \"m\": 3,\n \"mn\": \"Defines schema structure and protocol integration but appears early-stage; 13 pages suggests incomplete specification lacking comprehensive examples or implementation guidance.\",\n \"o\": 3,\n \"on\": \"Shares core concepts with agent registration/discovery work and overlaps with general identity provisioning standards; moderate conceptual overlap with existing SCIM extensions.\",\n \"mo\": 1,\n \"mon\": \"Single draft revision in early 2026 with no visible WG adoption, community discussion, or implementation commitments; appears to be exploratory work without organizational backing.\",\n \"r\": 4,\n \"rn\": \"Directly addresses agent identity and authentication, which are foundational infrastructure concerns for multi-agent systems; timely given increased agent deployment but not addressing higher-level agent governance.\",\n \"c\": [\n \"Agent identity/auth\",\n \"Data formats/interop\",\n \"Agent discovery/reg\",\n \"A2A protocols\"\n ]\n}\n```", "in_tok": 553, "out_tok": 321}
|
|
|
|
|
{"draft_name": "draft-chen-nmrg-semantic-inference-routing", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"SIRP proposes semantic-based routing for AI inference requests by analyzing content rather than metadata alone, with optional extensions for cost, urgency, domain specialization, and privacy. The framework aims to improve routing robustness and consistency in distributed inference systems.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution combining existing routing concepts with basic content analysis; semantic routing itself is not novel, though application to inference systems is somewhat specialized.\",\n \"m\": 2,\n \"mn\": \"Early-stage draft with framework description but lacks detailed protocol specifications, message formats, algorithms, deployment considerations, and security analysis expected of a routing protocol standard.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing work in content-based routing, service mesh intelligent routing (Istio/Envoy), and inference load balancing; semantic analysis aspects echo established ML ops practices.\",\n \"mo\": 1,\n \"mon\": \"Single draft revision with April 2026 date; no evidence of WG adoption, community discussion, or iterative development; appears nascent with unclear support.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI inference deployment and model serving infrastructure; addresses practical routing challenges in distributed AI systems though framed narrowly around inference rather than broader agent coordination.\",\n \"c\": [\n \"Model serving/inference\",\n \"ML traffic mgmt\",\n \"Autonomous netops\",\n \"Data formats/interop\"\n ]\n}\n```", "in_tok": 569, "out_tok": 349}
|
|
|
|
|
{"draft_name": "draft-vandoulas-aidp", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"AIDP proposes a control-plane protocol for standardizing agent-to-agent interactions, capability delegation, and execution auditing across distributed systems. The draft targets interoperability and security for autonomous software agents operating in multi-domain environments.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution combining existing protocol design patterns (capability-based security, delegation frameworks) with agent-specific concerns; lacks fundamentally novel architectural insights.\",\n \"m\": 2,\n \"mn\": \"Early-stage draft with protocol outline but appears to lack implementation experience, formal semantics, comprehensive error handling, or test vectors; protocol details underspecified for independent implementation.\",\n \"o\": 4,\n \"on\": \"Significant conceptual overlap with OAuth2/OIDC delegation patterns, SPIFFE/SVID identity frameworks, and existing RPC protocols; unclear differentiation from agent-adapted capability delegation schemes.\",\n \"mo\": 1,\n \"mon\": \"Single revision with no visible WG discussion, community adoption, or implementation commitments; appears dormant as of publication date.\",\n \"r\": 4,\n \"rn\": \"Directly addresses real agent coordination challenges (capability enforcement, cross-domain delegation, auditability) relevant to emerging autonomous agent deployments, though scope and threat model need clarification.\",\n \"c\": [\n \"A2A protocols\",\n \"Agent identity/auth\",\n \"Data formats/interop\",\n \"Policy/governance\",\n \"Agent discovery/reg\"\n ]\n}\n```", "in_tok": 534, "out_tok": 359}
|
|
|
|
|
{"draft_name": "draft-jimenez-tbd-robotstxt-update", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes extensions to robots.txt to support AI-specific crawlers with syntax for distinguishing between training and inference activities. Aims to provide granular access control policies for different types of AI agents accessing web content.\",\n \"n\": 2,\n \"nn\": \"Incremental extension of existing robots.txt mechanism; combines known concepts (user-agent filtering, activity-based policies) without substantial technical innovation.\",\n \"m\": 2,\n \"mn\": \"Early draft stage with proposal outline but lacks detailed specification, syntax examples, parsing requirements, backward compatibility mechanisms, and implementation guidance.\",\n \"o\": 4,\n \"on\": \"Significant conceptual overlap with robots.txt extensions (REP WG work), AI crawler guidelines (OpenAI, Google specifications), and existing policy differentiation mechanisms; limited novel framing.\",\n \"mo\": 1,\n \"mon\": \"Single revision, no visible WG adoption or community engagement; publication date suggests recent submission but no evidence of iterative development or stakeholder feedback.\",\n \"r\": 4,\n \"rn\": \"Directly addresses AI agent web access control and policy governance; core relevance to managing AI training/inference activities but execution limited to existing framework.\",\n \"c\": [\n \"ML traffic mgmt\",\n \"Policy/governance\",\n \"Agent identity/auth\",\n \"Data formats/interop\",\n \"Agent discovery/reg\"\n ]\n}\n```", "in_tok": 509, "out_tok": 335}
|
|
|
|
|
{"draft_name": "draft-williams-http-bearer-extension", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft proposes an improved HTTP 401/407 Bearer authentication flow enabling user-agents to automatically fetch tokens from a Security Token Service without PKCE, with fallback to OIDC redirect flows and token caching capabilities.\",\n \"n\": 2,\n \"nn\": \"Incremental extension to existing Bearer auth; addresses known pain points (PKCE requirements, URI constraints) but builds on well-established mechanisms rather than introducing fundamentally new concepts.\",\n \"m\": 3,\n \"mn\": \"Protocol mechanism is defined with clear flow descriptions, though lacks detailed implementation guidance, test vectors, and security analysis depth needed for implementation readiness.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing OIDC/OAuth2 token endpoint patterns and device flow specifications; the automatic token fetch mechanism resembles existing STS integration patterns in enterprise contexts.\",\n \"mo\": 2,\n \"mon\": \"Single draft revision visible; no clear WG sponsorship or community adoption signals; appears to be individual submission without documented stakeholder interest or implementation feedback.\",\n \"r\": 2,\n \"rn\": \"Tangentially related to AI agents only insofar as agents may require authentication; draft addresses general HTTP client authentication rather than agent-specific identity, authorization, or capability patterns.\",\n \"c\": [\"Agent identity/auth\", \"Data formats/interop\"]\n}\n```", "in_tok": 578, "out_tok": 323}
|
|
|
|
|
{"draft_name": "draft-sovereign-satp", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"SATP proposes a trust framework for establishing verifiable identity and governance of autonomous machines and AI agents through non-repudiable roots of trust. The 3-page draft outlines foundational concepts for attribution and trust in both digital and physical autonomous systems.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution addressing known problem space; combines existing trust/identity concepts (PKI, attestation, governance) into autonomous agent context without substantial methodological innovation.\",\n \"m\": 1,\n \"mn\": \"Problem statement and high-level vision only; lacks protocol specification, message formats, cryptographic details, or implementation guidance despite claiming to 'specify' a protocol.\",\n \"o\": 4,\n \"on\": \"Significant conceptual overlap with existing work: TETRA, IETF RATS attestation frameworks, W3C DID specifications, and various autonomous vehicle trust standards; positioning relative to these not clearly differentiated.\",\n \"mo\": 1,\n \"mon\": \"Single dated draft (2026-05-02); no evidence of revisions, WG sponsorship, or community engagement; appears to be initial submission without active development trajectory.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI agent identity, authentication, and governance challenges; addresses real need for autonomous system trust infrastructure in emerging deployment scenarios.\",\n \"c\": [\n \"Agent identity/auth\",\n \"Policy/governance\",\n \"A2A protocols\",\n \"AI safety/alignment\"\n ]\n}\n```", "in_tok": 517, "out_tok": 359}
|
|
|
|
|
{"draft_name": "draft-ietf-core-oscore-edhoc", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft specifies how EDHOC (Ephemeral Diffie-Hellman Over COSE) can be used with CoAP to establish OSCORE security contexts, with an optimization to combine the key exchange with the first secured transaction, reducing round trips in constrained IoT environments.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution combining existing protocols (EDHOC + OSCORE + CoAP) with optimization techniques; no novel cryptographic or security concepts.\",\n \"m\": 4,\n \"mn\": \"Well-specified protocol integration with detailed mechanisms, examples, and security considerations; implementation-ready but lacks comprehensive test vectors.\",\n \"o\": 3,\n \"on\": \"Shares foundational concepts with EDHOC and OSCORE specs; combines existing work in a standardized manner with some novel optimization patterns.\",\n \"mo\": 4,\n \"mon\": \"Active IETF CoRE WG development with multiple revisions; strong adoption momentum for constrained IoT security standards.\",\n \"r\": 1,\n \"rn\": \"IoT/constrained device security protocol; not related to AI agents, autonomous systems, or machine learning workflows despite mentioning 'RESTful' concepts.\",\n \"c\": [\"Data formats/interop\"]\n}\n```", "in_tok": 663, "out_tok": 312}
|
|
|
|
|
{"draft_name": "draft-chang-agent-context-interaction", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft addresses context distribution optimization in multi-agent systems to reduce latency, token consumption, and improve task completion rates. It specifies scenarios, procedures, and optimizations for controlling context distribution across multiple agents in complex workflows.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution focusing on a specific operational concern (context distribution) in multi-agent systems; lacks fundamental innovation in approach or methodology.\",\n \"m\": 2,\n \"mn\": \"Early sketch stage with abstract describing problem and goals but only 14 pages suggesting incomplete specification; lacks protocol details, examples, or implementation guidance.\",\n \"o\": 3,\n \"on\": \"Shares conceptual overlap with existing agent communication and state management work; context passing is well-established in distributed systems and agent literature.\",\n \"mo\": 1,\n \"mon\": \"No revision history visible; single draft submission with recent date suggests early-stage work lacking iterative development or community feedback cycles.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to AI agent systems but focuses narrowly on context distribution mechanics rather than core agent coordination, reasoning, or safety concerns.\",\n \"c\": [\n \"A2A protocols\",\n \"ML traffic mgmt\",\n \"Data formats/interop\",\n \"Autonomous netops\"\n ]\n}\n```", "in_tok": 531, "out_tok": 312}
|
|
|
|
|
{"draft_name": "draft-du-catalist-routing-considerations", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft proposes routing considerations for agent-to-agent communication in overlay networks above IP infrastructure, addressing cross-domain scenarios where AI agents with specialized skills need to interconnect. It identifies new networking requirements emerging from agentic network traffic patterns.\",\n \"n\": 2,\n \"nn\": \"Incremental application of existing routing concepts to a new use case (agent communication); lacks novel routing mechanisms or protocols specific to agent needs.\",\n \"m\": 1,\n \"mn\": \"Problem statement and motivation only; no routing protocols, mechanisms, or specifications defined; no examples, architectures, or implementation details provided.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing work on overlay networking, service mesh routing, and agent communication frameworks; concepts not differentiated from established patterns.\",\n \"mo\": 1,\n \"mon\": \"Appears to be early-stage exploratory draft with limited community engagement; no evidence of WG discussion, multiple revisions, or implementation activity.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to AI agent networking; addresses agent-to-agent communication but lacks depth on core agent architecture, capability discovery, or agent-specific constraints that should drive routing decisions.\",\n \"c\": [\n \"A2A protocols\",\n \"Agent discovery/reg\",\n \"Data formats/interop\",\n \"ML traffic mgmt\"\n ]\n}\n```", "in_tok": 574, "out_tok": 329}
|
|
|
|
|
{"draft_name": "draft-rosenberg-cheq", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"CHEQ proposes a protocol for human-in-the-loop confirmation of AI agent decisions before execution, with privacy-preserving credential handling. It integrates with MCP and A2A protocols using signed objects to prevent unwanted actions from hallucinations.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution combining existing HITL concepts with protocol integration; human confirmation of agent actions is well-established practice, though protocol formalization adds modest value.\",\n \"m\": 2,\n \"mn\": \"Early sketch stage with abstract-level design; lacks detailed message formats, state machines, error handling, examples, and implementation guidance needed for interoperability.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing HITL frameworks, approval workflows in enterprise automation, and confirmation mechanisms in authorization protocols; positioning relative to MCP/A2A adoption unclear.\",\n \"mo\": 1,\n \"mon\": \"Single undated revision (2025-07-24); no evidence of WG discussion, community feedback, or iterative refinement; appears to be initial submission.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI agent safety and human-agent interaction concerns; addresses legitimate hallucination/action risk but positioned as IETF protocol rather than application-layer pattern.\",\n \"c\": [\n \"Human-agent interaction\",\n \"AI safety/alignment\",\n \"A2A protocols\",\n \"Agent identity/auth\",\n \"Data formats/interop\"\n ]\n}\n```", "in_tok": 632, "out_tok": 363}
|
|
|
|
|
{"draft_name": "draft-yalcinkaya-rats-asil-m", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Defines an ASIL-M profile for RATS that enables authorization decisions across multiple independent trust roots, introducing the Attestation Evidence Synthesis Protocol, Twin Attestation Policy Language (TAPL), and Canonical Attestation Record (CAR) for deterministic multi-root appraisal in AI inference systems.\",\n \"n\": 3,\n \"nn\": \"Incremental contribution combining existing RATS concepts with multi-root synthesis; the policy language and envelope format are useful but not fundamentally novel architectural innovations.\",\n \"m\": 3,\n \"mn\": \"Protocol mechanisms are defined with three artifacts, but lacks implementation examples, test vectors, and concrete deployment guidance; appears specification-ready but not fully mature.\",\n \"o\": 3,\n \"on\": \"Shares core concepts with RATS architecture, multi-attestation frameworks, and policy-driven authorization; TAPL resembles existing constrained policy languages; CAR extends rather than replaces existing RATS components.\",\n \"mo\": 2,\n \"mon\": \"Single revision draft from 2026; no evidence of WG adoption, multiple revisions, or community feedback; appears early-stage with limited momentum.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI inference systems requiring cross-root authorization; addresses real trust and safety concerns in agent deployment, though framed narrowly around attestation rather than broader AI agent governance.\",\n \"c\": [\n \"Agent identity/auth\",\n \"Model serving/inference\",\n \"Policy/governance\",\n \"Data formats/interop\",\n \"AI safety/alignment\"\n ]\n}\n```", "in_tok": 700, "out_tok": 380}
|
|
|
|
|
{"draft_name": "draft-jovancevic-vdac", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"VDAC defines a cryptographic protocol for bilateral agreements between content publishers and automated agents regarding programmatic data access terms. It operationalizes the bilateral commitment principle from VICDM by enabling parties to sign contracts and bind individual requests to agreed terms through verifiable signatures.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution building on established concepts (VICDM, SAIP). Applies existing contract/signature mechanisms to agent-publisher agreements with limited technical novelty in the cryptographic approach itself.\",\n \"m\": 3,\n \"mn\": \"Defined protocol mechanism with clear structure (offer, acceptance, signing, per-request binding). Lacks implementation details, test vectors, and concrete examples. Companion spec dependency adds complexity to maturity assessment.\",\n \"o\": 3,\n \"on\": \"Shares conceptual overlap with OAuth2/SAML delegation frameworks, API contracts, and digital signature standards. Not a near-duplicate but operates in well-trodden space of cryptographic agreement protocols.\",\n \"mo\": 2,\n \"mon\": \"Single draft dated 2026 (future date suggests hypothetical). No indication of WG adoption, revisions, or community interest. Depends on VICDM/SAIP momentum which status is unclear.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI agent authentication, authorization, and programmatic interactions. Addresses agent-to-service contracting which is core infrastructure for autonomous agent deployment and governance.\",\n \"c\": [\n \"A2A protocols\",\n \"Agent identity/auth\",\n \"Policy/governance\",\n \"Data formats/interop\"\n ]\n}\n```", "in_tok": 655, "out_tok": 392}
|
|
|
|
|
{"draft_name": "draft-wiethuechter-drip-det-tada", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft standardizes the use of DRIP Entity Tags (DETs) as identifiers for trustworthy air domain awareness in unmanned aircraft systems, enabling privacy, authentication, and confidentiality across remote identification, traffic management, and advanced air mobility contexts.\",\n \"n\": 2,\n \"nn\": \"Incremental application of existing DRIP protocol mechanisms to specific use cases; primarily a standardization and consolidation effort rather than introducing fundamentally new concepts.\",\n \"m\": 3,\n \"mn\": \"Defined protocol mechanisms with clear usage patterns, though lacking detailed implementation examples, test vectors, or deployment guidance needed for production readiness.\",\n \"o\": 3,\n \"on\": \"Shares core concepts with existing DRIP/RID standards and overlaps moderately with UTM/AAM governance frameworks; extends prior work in defined directions rather than introducing independent approaches.\",\n \"mo\": 2,\n \"mon\": \"Single revision snapshot from 2026; limited evidence of community engagement or working group momentum; appears to be author-driven rather than collaborative development.\",\n \"r\": 2,\n \"rn\": \"Tangentially related to AI agents; addresses autonomous system identification and traffic management but focuses on protocol standardization rather than agent behavior, decision-making, or ML components.\",\n \"c\": [\n \"Agent identity/auth\",\n \"Data formats/interop\",\n \"Policy/governance\",\n \"Agent discovery/reg\"\n ]\n}\n```", "in_tok": 573, "out_tok": 344}
|
|
|
|
|
{"draft_name": "draft-voit-rats-trustworthy-path-routing", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes Trusted Path Routing to enforce that sensitive network traffic traverses only recently appraised trustworthy devices, combining attestation/RATS with routing policy. Addresses end-user concerns that encryption alone is insufficient for highly sensitive flows by adding device trustworthiness verification as a routing constraint.\",\n \"n\": 2,\n \"nn\": \"Incremental combination of existing concepts (RATS attestation + policy-based routing); core idea of trustworthiness-aware forwarding is not novel, though application to path selection is a useful engineering contribution.\",\n \"m\": 3,\n \"mn\": \"Appears to define protocol mechanisms and routing logic, likely includes some protocol details, but 32 pages suggests moderate specification depth; unclear if implementation examples or test vectors are included without reviewing full text.\",\n \"o\": 3,\n \"on\": \"Shares substantial conceptual overlap with zero-trust networking, attestation-based access control (RATS WG), and policy-based routing frameworks; positioning relative to existing ZTA/TEACVP initiatives not immediately clear from abstract.\",\n \"r\": 1,\n \"rn\": \"Not about AI agents or autonomous systems; addresses network infrastructure trustworthiness for sensitive traffic. Falls outside AI/agent scope unless interpreted broadly as autonomous network operations, which would be tangential at best.\",\n \"m\": 2,\n \"mon\": \"Single draft revision visible; no evidence of WG adoption or broader community momentum; appears to be individual contribution rather than WG-driven work.\",\n \"c\": [\"Autonomous netops\", \"Agent identity/auth\", \"Policy/governance\"]\n}\n```", "in_tok": 562, "out_tok": 378}
|
|
|
|
|
{"draft_name": "draft-singh-psi", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"PSI proposes a cryptographic protocol enabling organizations to prove AI regulatory compliance (EU AI Act, NIST AI RMF, etc.) through zero-knowledge proofs and MPC consensus without revealing proprietary model details. The approach combines SHA-256 hash chains, Ed25519 signatures, Merkle proofs, and Groth16 ZK commitments over BN128 fields.\",\n \"n\": 2,\n \"nn\": \"Incremental combination of existing cryptographic primitives (ZK proofs, MPC, hash chains) applied to a new domain (AI compliance verification); the individual techniques are well-established.\",\n \"m\": 2,\n \"mn\": \"Early sketch with architectural overview but lacks implementation details, test vectors, concrete audit trail schemas, integration examples with actual regulatory frameworks, and performance/scalability analysis.\",\n \"o\": 3,\n \"on\": \"Shares conceptual overlap with attestation/audit protocols (e.g., RATS framework), compliance-as-code initiatives, and existing ZK proof systems for privacy-preserving computation; the specific AI compliance application is somewhat novel.\",\n \"m\": 2,\n \"mn\": \"Single revision dated 2026-03-18; unclear if this is from active WG or individual submission; no evidence of community adoption or regulatory stakeholder engagement yet.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI governance and compliance verification; addresses real regulatory demand but focuses on policy/governance layer rather than core AI agent protocols or autonomous systems operation.\",\n \"c\": [\n \"Policy/governance\",\n \"Agent identity/auth\",\n \"Data formats/interop\",\n \"AI safety/alignment\"\n ]\n}\n```", "in_tok": 639, "out_tok": 403}
|
|
|
|
|
{"draft_name": "draft-hood-agtp-api", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"AGTP-API specifies a contract layer for autonomous agent-server interactions, defining method catalogs, endpoint structures, schema validation, and runtime negotiation mechanisms. It consolidates and supersedes prior fragmented drafts on agent transfer protocols.\",\n \"n\": 2,\n \"nn\": \"Incremental formalization of agent-server API semantics; combines existing concerns (methods, paths, endpoints) without introducing fundamentally new protocol concepts.\",\n \"m\": 3,\n \"mn\": \"Well-defined specification with structured components (manifests, status codes, binding kinds) but limited evidence of implementation validation or real-world deployment testing.\",\n \"o\": 4,\n \"on\": \"Significant overlap with REST/gRPC API patterns; shares endpoint and method catalog concepts with existing service mesh and agent framework designs; attempts unification of prior Hood drafts.\",\n \"mo\": 2,\n \"mon\": \"Single recent revision (2026-05); no clear WG sponsorship or adoption signals; appears to be individual submission with limited community engagement visible.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to autonomous agent standardization and agent-server communication; addresses interoperability but lacks explicit connection to broader AI safety or alignment concerns.\",\n \"c\": [\n \"A2A protocols\",\n \"Data formats/interop\",\n \"Agent discovery/reg\",\n \"Policy/governance\"\n ]\n}\n```", "in_tok": 740, "out_tok": 336}
|
|
|
|
|
{"draft_name": "draft-yakung-oauth-agent-attestation", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"ACAP proposes a JWT-based credentialing system for autonomous AI agents with scope delegation, audit logging, and human approval gates. It extends OAuth concepts to multi-agent pipelines with tamper-evident delegation chains and short-lived credentials.\",\n \"n\": 3,\n \"nn\": \"Applies familiar JWT/OAuth patterns to agent delegation; delegation depth tracking and instruction hashing are useful but represent incremental innovation over existing capability-based security models.\",\n \"m\": 2,\n \"mn\": \"Early draft stage; defines credential format and delegation rules but lacks implementation details, test vectors, security proofs, or concrete examples. No reference implementation evident.\",\n \"o\": 3,\n \"on\": \"Overlaps significantly with ZCAP-LD (capability delegation), Macaroons (nested delegation), and OAuth 2.0 token delegation patterns. The instruction hash concept is moderately novel but not sufficiently differentiated.\",\n \"mo\": 1,\n \"mon\": \"Single draft revision (2026-03-26 date suggests future submission); no evidence of WG adoption, community feedback iteration, or implementation uptake. Appears exploratory.\",\n \"r\": 4,\n \"rn\": \"Directly addresses critical AI agent orchestration needs: identity, authorization, multi-level delegation, and auditability. Highly relevant to agent security and human oversight.\",\n \"c\": [\"Agent identity/auth\", \"A2A protocols\", \"Human-agent interaction\", \"Policy/governance\", \"AI safety/alignment\"]\n}\n```", "in_tok": 650, "out_tok": 359}
|
|
|
|
|
{"draft_name": "draft-ahn-nmrg-5g-security-i2nsf-framework", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes an I2NSF-based framework for automated security management in 5G edge networks using Intent-Based Networking to translate high-level security intents into enforceable policies. The system distributes policies across network and application layers with closed-loop monitoring for adaptive, context-aware security enforcement in dynamic edge environments.\",\n \"n\": 2,\n \"nn\": \"Incremental combination of existing standards (I2NSF, IBN, NEF) applied to 5G security; integration approach is straightforward rather than introducing novel security or networking concepts.\",\n \"m\": 2,\n \"mn\": \"Early conceptual stage; abstract describes vision and architecture but lacks protocol details, policy language specifications, implementation guidance, or validation results.\",\n \"o\": 4,\n \"on\": \"Significant overlap with established I2NSF specification work and existing 5G security frameworks; combines well-known components (NEF, UE policy enforcement) without substantial differentiation.\",\n \"mo\": 1,\n \"mon\": \"Single revision draft from February 2026 with no evidence of WG adoption, implementation momentum, or community engagement; appears nascent in standards lifecycle.\",\n \"r\": 2,\n \"rn\": \"Tangentially related to autonomous networking concepts through IBN mention, but focuses on traditional security policy management rather than autonomous agent systems, distributed intelligence, or AI-driven decision-making.\",\n \"c\": [\"Policy/governance\", \"Autonomous netops\", \"Data formats/interop\"]\n}\n```", "in_tok": 670, "out_tok": 352}
|
|
|
|
|
{"draft_name": "draft-allman-tcp-early-rexmt", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes Early Retransmit mechanism for TCP and SCTP to enable fast retransmission recovery with fewer duplicate acknowledgments when congestion windows are small, avoiding costly timeout-based retransmissions. Addresses a specific transport-layer inefficiency in scenarios with limited in-flight packets.\",\n \"n\": 2,\n \"nn\": \"Incremental improvement to TCP/SCTP behavior; optimization of existing fast retransmit logic rather than fundamental innovation.\",\n \"m\": 4,\n \"mn\": \"Well-defined protocol mechanism with clear triggering conditions and specification suitable for implementation; appears RFC-ready with established evaluation.\",\n \"o\": 3,\n \"on\": \"Shares conceptual space with existing TCP loss recovery mechanisms (fast retransmit, limited transmit); represents focused refinement rather than convergent duplication.\",\n \"mo\": 2,\n \"mon\": \"Single draft revision in 2024; narrow specialized topic limits broad community adoption momentum despite technical merit.\",\n \"r\": 1,\n \"rn\": \"Pure transport protocol optimization with no connection to AI agents, autonomous systems, or machine learning applications; false positive for AI/agent category.\",\n \"c\": [\"Other AI/agent\"]\n}\n```", "in_tok": 559, "out_tok": 293}
|
|
|
|
|
{"draft_name": "draft-deshpande-rats-multi-verifier", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft extends the IETF RATS (Remote Attestation Procedures) architecture to support multiple coordinating verifiers assessing an attester's trustworthiness. It focuses on topological patterns and architectural considerations for multi-verifier systems in a format-neutral manner.\",\n \"n\": 2,\n \"nn\": \"Incremental extension of established RATS architecture; the concept of multiple verifiers is a natural scaling concern but represents straightforward architectural elaboration rather than fundamental innovation.\",\n \"m\": 2,\n \"mn\": \"Early-stage draft presenting architectural patterns without detailed protocol specifications, implementation examples, or concrete coordination mechanisms; lacks maturity for deployment guidance.\",\n \"o\": 3,\n \"on\": \"Shares core concepts with existing RATS specifications and distributed trust frameworks; multi-party attestation patterns have been explored in related security literature, though specific application to RATS topologies is somewhat novel.\",\n \"mo\": 1,\n \"mon\": \"Single revision in February 2026 with no evidence of WG adoption, community discussion, or iterative development; appears to be an initial submission without sustained momentum.\",\n \"r\": 2,\n \"rn\": \"Tangentially related to AI agent security; relevant to agent identity and authentication infrastructure but not directly addressing AI-specific challenges, agent coordination protocols, or autonomous system safety.\",\n \"c\": [\"Agent identity/auth\", \"Policy/governance\", \"Other AI/agent\"]\n}\n```", "in_tok": 566, "out_tok": 337}
|
|
|
|
|
{"draft_name": "draft-cgfabk-nmrg-ibn-generative-ai", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes specializing AI models for Intent-Based Networking (IBN) to enable scalable, efficient generative AI deployment in network operations. Addresses the intersection of generative AI and intent-driven network automation.\",\n \"n\": 2,\n \"nn\": \"Incremental application of existing generative AI techniques to networking domain; core novelty lies in domain-specific model specialization rather than methodological innovation.\",\n \"m\": 2,\n \"mn\": \"Early-stage draft presenting concepts and motivation; lacks detailed protocol specifications, implementation examples, or validation results needed for production readiness.\",\n \"o\": 3,\n \"on\": \"Shares conceptual overlap with existing IBN work and general AI-for-networking efforts; positioning within broader generative AI landscape could be clearer.\",\n \"mo\": 1,\n \"mon\": \"Limited revision history and community engagement evident from single dated version; unclear WG sponsorship or adoption trajectory.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI-driven network operations and autonomous networking; generative AI application to IBN is timely and practically motivated.\",\n \"c\": [\"Autonomous netops\", \"ML traffic mgmt\", \"Model serving/inference\", \"Policy/governance\", \"Data formats/interop\"]\n}\n```", "in_tok": 490, "out_tok": 305}
|
|
|
|
|
{"draft_name": "draft-chang-delta1-settlement", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Delta-1 proposes a SCITT profile for creating binary-verdict settlement receipts that prove AI agent decisions met three simultaneous accountability conditions: decision evidence sealing, strategic intent isolation, and authorized recording. The approach inherits SCITT's transparency-log semantics while adding domain-specific requirements for regulated industries like finance and healthcare.\",\n \"n\": 2,\n \"nn\": \"Incremental application of existing SCITT framework to a new domain; the core novelty is constraining SCITT to binary verdicts and three specific conditions rather than introducing fundamentally new cryptographic or architectural mechanisms.\",\n \"m\": 2,\n \"mn\": \"Early sketch stage with abstract requirements (C1-C3) but lacks concrete protocol details, message formats, verification algorithms, or implementation guidance; no test vectors or interoperability examples provided.\",\n \"o\": 4,\n \"on\": \"Significant conceptual overlap with SCITT core (receipts, transparency logs, attestation); borrows heavily from existing supply-chain trust models without substantial differentiation for AI-specific challenges beyond the three conditions.\",\n \"m\": 2,\n \"mon\": \"Single dated revision (2026-04-15) with no evidence of WG discussion, multiple iterations, or community adoption; appears nascent.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to AI agent accountability but focuses narrowly on settlement receipts and decision sealing rather than broader agent autonomy, alignment, safety, or reasoning transparency; accountability framing is governance-centric rather than technical AI challenge.\",\n \"c\": [\n \"Policy/governance\",\n \"Agent identity/auth\",\n \"Data formats/interop\",\n \"AI safety/alignment\"\n ]\n}\n```", "in_tok": 705, "out_tok": 406}
|
|
|
|
|
{"draft_name": "draft-mangrove-workgroup-mangrove", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Mangrove proposes a unified framework for obtaining global Internet visibility by aggregating traceroute, BGP, IP allocation, and measurement data across hierarchical levels. It constructs a comprehensive topology and routing model with extensible rules to compute packet paths and performance metrics while handling real-time dynamics through incremental updates.\",\n \"n\": 2,\n \"nn\": \"Multi-source data aggregation for Internet topology is incremental; core techniques (traceroute, BGP analysis, hierarchical indexing) are well-established. Primary contribution is the integration framework rather than novel methodology.\",\n \"m\": 2,\n \"mn\": \"Early-stage sketch with conceptual architecture but lacks implementation details, test cases, data schemas, or evaluation results. No API specifications, algorithm pseudocode, or experimental validation provided.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing work: CAIDA topology databases, RIPEstat, BGP analysis platforms, and academic Internet mapping projects all employ similar multi-source aggregation and hierarchical indexing approaches. Limited differentiation articulated.\",\n \"mo\": 1,\n \"mon\": \"Single draft revision (2024-09), no WG affiliation despite 'workgroup' in title, no apparent community adoption or ongoing development momentum visible.\",\n \"r\": 2,\n \"rn\": \"Tangentially related to AI/agent systems only through potential applications for autonomous network operations; primary focus is Internet topology modeling and routing, not AI agent topics or autonomous agent infrastructure.\",\n \"c\": [\n \"Data formats/interop\",\n \"Autonomous netops\",\n \"Other AI/agent\"\n ]\n}\n```", "in_tok": 773, "out_tok": 388}
|
|
|
|
|
{"draft_name": "draft-mzsg-rtgwg-agent-cross-device-comm-framework", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes a framework for cross-device communication between AI agents deployed on network devices to enable collaborative tasks like network troubleshooting. Analyzes protocol requirements for agent coordination across heterogeneous network infrastructure.\",\n \"n\": 2,\n \"nn\": \"Incremental application of existing agent communication concepts to network device context; lacks novel architectural or protocol innovations.\",\n \"m\": 2,\n \"mn\": \"Early-stage framework document with problem analysis but no detailed protocol specification, implementation examples, or validation mechanisms provided.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing agent communication protocols (FIPA ACL, gRPC, REST APIs) and network management frameworks; limited differentiation articulated.\",\n \"mo\": 1,\n \"mon\": \"Single draft submission with no visible revision history, WG engagement, or community adoption signals; appears to be initial proposal.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to AI agent deployment; focuses on network operations use cases rather than core AI agent capability challenges like reasoning, safety, or coordination semantics.\",\n \"c\": [\n \"A2A protocols\",\n \"Autonomous netops\",\n \"Agent discovery/reg\",\n \"Data formats/interop\"\n ]\n}\n```", "in_tok": 559, "out_tok": 304}
|
|
|
|
|
{"draft_name": "draft-bondar-wca", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft proposes Warrant Certificate Authorities (WCA), a cryptographic attestation infrastructure to track data provenance through LLM agent tool-call chains, addressing 'semantic laundering' where data gains unearned trustworthiness crossing tool boundaries. The system draws on PKI, OS provenance monitoring, and supply-chain security frameworks with graduated adoption levels (WAL-0 through WAL-3).\",\n \"n\": 4,\n \"nn\": \"Applies reference monitor properties and PKI patterns to a genuinely novel problem space (agent data provenance), though individual components draw from established domains.\",\n \"m\": 3,\n \"mn\": \"Protocol structures and certificate formats defined; Warrant Attestation Levels specified; lacks implementation details, test vectors, and deployment guidance for production readiness.\",\n \"o\": 2,\n \"on\": \"Minor conceptual overlap with attestation/provenance work (IMA, CamFlow) and supply-chain security (SLSA, in-toto); the agent-specific application and 'semantic laundering' framing appear novel.\",\n \"mo\": 2,\n \"mon\": \"Single draft dated 2026-03-01 with no apparent revision history or WG sponsorship evident; early-stage proposal without community traction signals.\",\n \"r\": 4,\n \"rn\": \"Directly addresses critical trust and epistemology challenges in multi-tool agent systems; highly relevant to emerging LLM deployment concerns, though not yet mainstream IETF focus.\",\n \"c\": [\n \"Agent identity/auth\",\n \"Data formats/interop\",\n \"Policy/governance\",\n \"A2A protocols\",\n \"AI safety/alignment\"\n ]\n}\n```", "in_tok": 749, "out_tok": 409}
|
|
|
|
|
{"draft_name": "draft-ietf-tls-extended-key-update", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft extends TLS 1.3 with a post-compromise security mechanism by enabling fresh Diffie-Hellman key exchanges within active sessions, rather than relying solely on the standard KeyUpdate mechanism. It addresses security risks in long-lived sessions common in industrial IoT and telecommunications by regularly renewing session keys to limit the impact of key compromise.\",\n \"n\": 2,\n \"nn\": \"Incremental extension to TLS 1.3; combines existing concepts (KeyUpdate, ephemeral DH) in a straightforward manner without fundamental cryptographic innovation.\",\n \"m\": 4,\n \"mn\": \"Well-structured protocol specification with clear mechanism definition, applicable to both TLS 1.3 and DTLS 1.3; appears implementation-ready but maturity depends on test vectors and interop testing.\",\n \"o\": 3,\n \"on\": \"Shares conceptual overlap with post-compromise security literature and session key refresh mechanisms; relates to prior work on perfect forward secrecy extensions but offers a concrete formalization.\",\n \"mo\": 2,\n \"mon\": \"Single revision dated 2026-03-02 suggests early-stage draft; limited evidence of WG discussion or multiple iterations; adoption momentum unclear.\",\n \"r\": 1,\n \"rn\": \"Not relevant to AI/agent systems; purely a cryptographic transport layer enhancement unrelated to AI agents, distributed systems governance, or agent protocols.\",\n \"c\": []\n}\n```", "in_tok": 719, "out_tok": 345}
|
|
|
|
|
{"draft_name": "draft-wang-nmrg-magent-im", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes a protocol-agnostic data model enabling multi-agent communication for autonomous network operations at Level 4 autonomy. Addresses secure and efficient interaction between intelligent agents across network layers for self-management and closed-loop operations.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution combining existing multi-agent concepts with network autonomy; data model approach is straightforward extension of agent coordination patterns\",\n \"m\": 2,\n \"mn\": \"Early-stage specification; appears to define conceptual framework and data model structure but lacks detailed protocol mechanics, formal semantics, implementation examples, or test vectors\",\n \"o\": 4,\n \"on\": \"Significant overlap with IETF autonomic networking (ANI), intent-based networking (IBN) work, and existing multi-agent interaction frameworks; relationship to prior work unclear\",\n \"mo\": 1,\n \"mon\": \"Single submission as recent draft; no evidence of WG adoption, multiple revisions, or community engagement; nascent topic with uncertain trajectory\",\n \"r\": 4,\n \"rn\": \"Directly relevant to autonomous network operations and agent coordination; timely for network automation discussions but positioning relative to AI/ML agent ecosystem needs clarification\",\n \"c\": [\"A2A protocols\", \"Autonomous netops\", \"Agent discovery/reg\", \"Data formats/interop\", \"Policy/governance\"]\n}\n```", "in_tok": 647, "out_tok": 329}
|
|
|
|
|
{"draft_name": "draft-kartha-internet20-ainative", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Internet 2.0 proposes a new web architecture layer treating AI models as first-class network entities, introducing HTTP+AI, a Model Resolution Network (DNS-analogue for models), and AI-aware browsers for intent-based semantic interaction. The vision extends beyond document retrieval toward distributed model discovery and protocol-level AI interaction.\",\n \"n\": 2,\n \"nn\": \"Repackages existing concepts (model APIs, discovery services, semantic routing) under an 'Internet 2.0' framing rather than proposing fundamentally new mechanisms; resembles API gateway and service mesh patterns applied to ML.\",\n \"m\": 1,\n \"mn\": \"Conceptual vision document without protocol specifications, formal grammar, interaction examples, or concrete technical details; HTTP+AI and MRN remain abstract proposals.\",\n \"o\": 4,\n \"on\": \"Substantial conceptual overlap with service mesh architectures (Istio, Envoy), API gateways, model serving platforms (Seldon, BentoML), and existing ML model registries; intent-based routing echoes policy-based networking and semantic web efforts.\",\n \"mo\": 1,\n \"mon\": \"Single undated submission with no visible revision history, WG discussion, or community engagement signals; appears to be a standalone position paper rather than active standardization effort.\",\n \"r\": 4,\n \"rn\": \"Directly addresses agent discovery, model serving infrastructure, and protocol design for AI systems; relevant to distributed AI agent ecosystems but positioned as architectural vision rather than solving specific interoperability or safety gaps.\",\n \"c\": [\n \"Agent discovery/reg\",\n \"Model serving/inference\",\n \"A2A protocols\",\n \"Data formats/interop\",\n \"Autonomous netops\"\n ]\n}\n```", "in_tok": 626, "out_tok": 420}
|
|
|
|
|
{"draft_name": "draft-zhao-nmop-network-management-agent", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes a Network Management Agent (NMA) architecture leveraging AI for autonomous network operations at Level 4 autonomy, positioned to work alongside SDN controllers for intent-based reasoning and autonomous planning without duplicating policy control.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution combining existing SDN concepts with generic AI agent frameworks; lacks novel architectural insights or theoretical advances specific to network management domains.\",\n \"m\": 2,\n \"mn\": \"Early-stage conceptual document (24 pages) lacking protocol specifications, interface definitions, concrete data models, or reference implementations; reads as position paper rather than technical specification.\",\n \"o\": 4,\n \"on\": \"Significant overlap with established autonomous networking (ONAP, ORAN), intent-based networking (IBN), and AI/ML in networking literature; limited differentiation from generic LLM agent frameworks applied to networking.\",\n \"mo\": 1,\n \"mon\": \"Single draft revision (2026-02-27 date suggests very recent); no evidence of WG sponsorship, multiple contributors, or iterative refinement cycle typical of active IETF work.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI-driven network operations and autonomous agent architectures; addresses timely intersection of LLM capabilities with network management, though framing as IETF standardization may be premature.\",\n \"c\": [\n \"Autonomous netops\",\n \"A2A protocols\",\n \"Agent discovery/reg\",\n \"Data formats/interop\",\n \"Policy/governance\",\n \"Human-agent interaction\"\n ]\n}\n```", "in_tok": 659, "out_tok": 387}
|
|
|
|
|
{"draft_name": "draft-tonyai-a2a-trust", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes a PKI-based trust model for multi-agent AI systems using X.509 certificates, spawn chain cryptography, and dual-signature policies to establish verifiable agent identity and provenance. Applies existing standards (OAuth 2.0, CRL) to agent-to-agent authorization without addressing resource access control or agent behavior.\",\n \"n\": 2,\n \"nn\": \"Incremental application of established PKI/identity patterns to agents; core concepts (X.509, OAuth On-Behalf-Of, spawn chains) are standard techniques adapted rather than novel.\",\n \"m\": 3,\n \"mn\": \"Defines protocol mechanisms and trust model structure with specified primitives, but 16 pages suggests moderate detail; likely lacks implementation guidance, test vectors, or formal security proofs.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing work on service-to-service identity (mTLS, SPIFFE/SVID), delegation patterns (OAuth 2.0 On-Behalf-Of), and supply chain provenance; positions as agent-specific but mechanisms are largely standard.\",\n \"m\": 2,\n \"mon\": \"Single draft dated 2026-05 with no evident prior versions or WG adoption; appears early-stage with unclear community engagement or revision trajectory.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to agent identity and authorization in multi-agent systems, but narrow scope excluding behavior, resource enforcement, and orchestration limits impact on core AI agent concerns.\",\n \"c\": [\n \"A2A protocols\",\n \"Agent identity/auth\",\n \"Policy/governance\",\n \"Agent discovery/reg\"\n ]\n}\n```", "in_tok": 641, "out_tok": 401}
|
|
|
|
|
{"draft_name": "draft-aip-agent-identity-protocol", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"AIP proposes a two-layer protocol for AI agent identity and authorization, assigning unique identifiers and cryptographic keys to agents while enforcing declarative policies at tool-access boundaries. Addresses the critical problem of unbounded agent permissions and lack of identity boundaries between human and non-human actors.\",\n \"n\": 3,\n \"nn\": \"Core concept of agent identity + policy enforcement is useful but not novel; combines existing patterns (PKI, proxy interposition, declarative policies). Execution model is straightforward application of established security principles to agentic systems.\",\n \"m\": 3,\n \"mn\": \"Protocol structure is defined with two clear layers and stated mechanisms, but 30 pages likely lacks detailed specification depth, test vectors, and implementation guidance needed for production deployment. Appears to be a conceptual draft rather than implementation-ready specification.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing work: ACL/RBAC frameworks, mTLS/certificate-based auth, OAuth 2.0 token patterns, API gateway proxies (Kong, Envoy), and emerging agent frameworks (LangChain middleware, tool-use policies). Limited novelty in component design.\",\n \"mo\": 2,\n \"mon\": \"Appears to be single-submission draft with no indication of WG backing, multiple revisions, or community adoption signals. March 2026 date and minimal metadata suggest early-stage, low-visibility effort without demonstrated momentum.\",\n \"r\": 4,\n \"rn\": \"Directly addresses critical operational gap in current AI agent deployments: unbounded permissions and lack of auditability. Highly relevant to agent security/governance but presented as general protocol rather than ecosystem-specific solution.\",\n \"c\": [\n \"Agent identity/auth\",\n \"Policy/governance\",\n \"AI safety/alignment\",\n \"A2A protocols\"\n ]\n}\n```", "in_tok": 649, "out_tok": 442}
|
|
|
|
|
{"draft_name": "draft-abbott-mcp-ax", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"MCP-AX adapts the AgentX protocol architecture to enable hierarchical composition of tool namespaces across distributed MCP servers, introducing recursive delegation and capability-aware routing for AI agent systems. The protocol targets heterogeneous deployments from cloud to embedded devices with features like transport bridging and irreversibility-gated dispatch.\",\n \"n\": 2,\n \"nn\": \"Incremental adaptation of established AgentX master-subagent pattern to a different domain (tools vs OIDs); hierarchical delegation concept is not novel, though application to MCP tool namespaces adds modest value.\",\n \"m\": 3,\n \"mn\": \"Protocol mechanisms are defined with architectural patterns clear, but document length (25pg) suggests incomplete specification; unclear if implementation examples, test vectors, or reference implementations exist.\",\n \"o\": 4,\n \"on\": \"Significant overlap with AgentX (RFC 2741) architecture and intent; shares delegation patterns with existing service mesh and federation protocols; namespace composition is well-explored in other distributed systems contexts.\",\n \"mo\": 1,\n \"mon\": \"Single draft submission with May 2026 date (future); no evidence of working group sponsorship, multiple revisions, or community adoption; appears to be early-stage individual submission.\",\n \"r\": 4,\n \"rn\": \"Directly addresses tool/capability orchestration across distributed AI agent systems, which is a core operational need; MCP relevance is high if MCP gains adoption, but current relevance is dependent on MCP ecosystem maturity.\",\n \"c\": [\"A2A protocols\", \"Agent discovery/reg\", \"Data formats/interop\", \"Model serving/inference\"]\n}\n```", "in_tok": 634, "out_tok": 392}
|
|
|
|
|
{"draft_name": "draft-yuan-rtgwg-traffic-agent-usecase", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes AI Network Traffic Optimization Agents as autonomous entities to dynamically manage network resources and routing in real-time, replacing static optimization methods. Describes three key use cases: tunnel adjustment with adaptive routing, traffic steering with application-aware policies, and network slice lifecycle automation with SLA compliance.\",\n \"n\": 2,\n \"nn\": \"Incremental application of AI/ML concepts to known network optimization problems; lacks novel algorithmic or architectural contributions beyond framing existing techniques as 'agent'-based systems.\",\n \"m\": 2,\n \"mn\": \"Early-stage use case document with abstract scenarios but no concrete protocols, APIs, data models, or implementation guidance; primarily motivational rather than specification-oriented.\",\n \"o\": 4,\n \"on\": \"Significant conceptual overlap with existing AI-driven networking, SDN/NFV optimization, and autonomous network management initiatives (ONAP, O-RAN, IETF NMOP); limited differentiation from prior agent-based network control proposals.\",\n \"mo\": 1,\n \"mon\": \"Single draft submission with no visible WG sponsorship, revision history, or community engagement; no indication of active development momentum or adoption interest.\",\n \"r\": 3,\n \"rn\": \"Directly addresses AI agents in networking context but frames agents loosely as any autonomous optimization entity rather than exploring deeper agent-specific challenges (coordination, safety, explainability, standardization).\",\n \"c\": [\n \"ML traffic mgmt\",\n \"Autonomous netops\",\n \"Policy/governance\",\n \"Agent discovery/reg\",\n \"Data formats/interop\"\n ]\n}\n```", "in_tok": 656, "out_tok": 387}
|
|
|
|
|
{"draft_name": "draft-song-rtgwg-din-usecases-requirements", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes a Distributed Inference Network architecture to address scalability, latency, and security challenges of centralized AI inference through edge-cloud collaboration and intelligent scheduling. Document establishes problem statement and requirements for supporting low-latency, high-concurrency AI services across billions of users and devices.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution combining well-established concepts (edge computing, load balancing, distributed inference) without novel architectural or protocol innovations.\",\n \"m\": 1,\n \"mn\": \"Problem statement and use cases only; no protocol specifications, mechanisms, or implementation details provided.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing IETF work on edge computing (MEC), service placement, traffic engineering, and application-layer load balancing; concepts align with established distributed systems patterns.\",\n \"mo\": 2,\n \"mon\": \"Single revision as requirements draft; limited evidence of WG traction or community adoption at this stage of development.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI service deployment and agent infrastructure, though framed as network problem rather than core AI agent protocol work.\",\n \"c\": [\"Model serving/inference\", \"ML traffic mgmt\", \"Autonomous netops\", \"Policy/governance\", \"Agent discovery/reg\"]\n}\n```", "in_tok": 593, "out_tok": 315}
|
|
|
|
|
{"draft_name": "draft-mishra-oauth-agent-grants", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"DAAP proposes an OAuth 2.0-based authorization framework for AI agents performing autonomous actions on behalf of humans, combining DIDs for agent identity, JWT grants with agent claims, real-time revocation, audit trails, and policy engine integration. The protocol aims to provide cryptographic accountability and human-verifiable consent for delegated agent authorization across third-party services.\",\n \"n\": 3,\n \"nn\": \"Applies established OAuth 2.0 patterns to agent delegation with useful additions (DIDs, audit trails, budget controls, cascade revocation), but core concepts are incremental extensions rather than fundamentally novel approaches to the agent authorization problem.\",\n \"m\": 3,\n \"mn\": \"Protocol is reasonably well-specified with defined flows, token formats, and integration points (OPA, Cedar), but lacks implementation details, test vectors, and real-world deployment guidance needed for production readiness.\",\n \"o\": 3,\n \"on\": \"Shares significant conceptual overlap with OAuth 2.0 extensions, capability-based delegation models, and existing agent frameworks; distinguishing contributions (audit trails, multi-agent cascade) are incremental rather than architecturally distinct.\",\n \"mo\": 2,\n \"mon\": \"Single draft revision with 2026 date suggests early stage; no evidence of WG adoption, implementation experience, or community engagement; positioning relative to IETF's OAuth working group momentum unclear.\",\n \"r\": 4,\n \"rn\": \"Directly addresses critical problem of human-verifiable AI agent authorization and accountability, which is timely and practically relevant; however, focuses narrowly on protocol mechanics rather than broader AI safety/alignment concerns.\",\n \"c\": [\n \"Agent identity/auth\",\n \"Human-agent interaction\",\n \"Policy/governance\",\n \"Data formats/interop\",\n \"A2A protocols\"\n ]\n}\n```", "in_tok": 729, "out_tok": 437}
|
|
|
|
|
{"draft_name": "draft-bernardos-anima-fog-monitoring", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes autonomic setup of fog monitoring agents using GRASP protocol to handle dynamic IoT environments with volatile computational resources. Addresses orchestration of service function chains across heterogeneous fog nodes through autonomous agent coordination.\",\n \"n\": 2,\n \"nn\": \"Incremental application of existing autonomic/GRASP concepts to fog monitoring; combines well-established technologies without significant innovation in the core mechanisms.\",\n \"m\": 2,\n \"mn\": \"Early sketch phase; presents use case and conceptual application of GRASP to fog monitoring but lacks detailed protocol specifications, implementation details, or validation.\",\n \"o\": 3,\n \"on\": \"Shares core concepts with existing ANIMA work and GRASP specifications; fog monitoring and service function chain orchestration have been addressed in related drafts.\",\n \"mo\": 1,\n \"mon\": \"Single revision from 2024; appears to be early/inactive draft with limited community engagement or WG adoption signals.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to autonomous network operations and agent discovery/registration within IoT/fog environments; addresses autonomous agent coordination without being primarily an AI/ML work.\",\n \"c\": [\"Autonomous netops\", \"Agent discovery/reg\", \"A2A protocols\", \"Data formats/interop\"]\n}\n```", "in_tok": 766, "out_tok": 311}
|
|
|
|
|
{"draft_name": "draft-cui-nmrg-llm-benchmark", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes an evaluation framework for LLM-based agents performing intent-driven network configuration tasks, combining emulation environments, representative tasks, and multi-dimensional metrics. Aims to enable reproducible and fair benchmarking of different LLM-driven approaches for autonomous network operations.\",\n \"n\": 2,\n \"nn\": \"Benchmark frameworks for network tasks are established practice; applying this to LLM agents is incremental rather than fundamentally novel. Combines existing concepts (emulation, metrics, task suites) without introducing new theoretical insights.\",\n \"m\": 2,\n \"mn\": \"Early-stage framework document lacking implementation details, test vectors, or concrete metrics specifications. No evidence of prototype implementation or empirical validation of the proposed evaluation methodology.\",\n \"o\": 3,\n \"on\": \"Overlaps with existing network benchmarking work (RFC 2544-style frameworks) and general ML benchmark design patterns. Some similarity to emerging LLM evaluation suites, though network-specific application is somewhat novel.\",\n \"m\": 1,\n \"mon\": \"Single submission with future date (2025-12-30 appears to be placeholder). No revision history, no WG affiliation visible, and no evidence of community engagement or iterative development.\",\n \"r\": 4,\n \"rn\": \"Directly addresses autonomous network operations using LLM agents, which is a core emerging topic in network automation. Relevant to NMRG (Network Management Research Group) charter and current industry interest in AI-driven NetOps.\",\n \"c\": [\n \"Autonomous netops\",\n \"ML traffic mgmt\",\n \"Data formats/interop\",\n \"Human-agent interaction\"\n ]\n}\n```", "in_tok": 554, "out_tok": 401}
|
|
|
|
|
{"draft_name": "draft-klrc-aiagent-auth", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes applying existing standards (WIMSE, OAuth 2.0) to AI agent authentication and authorization rather than defining new protocols. Aims to identify gaps and guide future standardization for agent identity and access control in multi-system environments.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution\u2014straightforward application of established identity/auth frameworks to AI agents without novel cryptographic or architectural innovations.\",\n \"m\": 2,\n \"mn\": \"Early sketch phase; describes conceptual mapping of existing standards to agent scenarios but likely lacks detailed protocol specifications, implementation examples, or test vectors at 26 pages.\",\n \"o\": 4,\n \"on\": \"Significant overlap with concurrent work on workload identity, OAuth 2.0 extensions, and emerging agent-oriented IAM frameworks; repackages known standards rather than introducing differentiated mechanisms.\",\n \"mo\": 2,\n \"mon\": \"Single revision snapshot (2026-03-30); no visible WG adoption signals or iterative community engagement evident; limited momentum indicators for standardization track.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to agent authentication and identity governance; timely given AI deployment scale, though framed conservatively as standards reuse rather than agent-specific innovation.\",\n \"c\": [\n \"Agent identity/auth\",\n \"Policy/governance\",\n \"A2A protocols\",\n \"Data formats/interop\"\n ]\n}\n```", "in_tok": 570, "out_tok": 343}
|
|
|
|
|
{"draft_name": "draft-li-semantic-routing-architecture", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes a semantic routing architecture that uses AI agent-level semantics (intent vectors, trust scores, service identity) instead of traditional IP routing to enable intelligent multi-agent communication. The system aims to transform networks from passive transport into active collaboration substrates for coordinated agent operations.\",\n \"n\": 2,\n \"nn\": \"Incremental combination of existing concepts\u2014semantic routing, intent-based networking, and trust-based policy enforcement\u2014applied to a new domain (AI agents) without substantial technical innovation in routing mechanisms themselves.\",\n \"m\": 2,\n \"mn\": \"Early-stage draft with conceptual architecture but lacking detailed protocol specifications, message formats, routing algorithms, or implementation guidance; no clear mechanisms for practical deployment.\",\n \"o\": 4,\n \"on\": \"Significant overlap with intent-based networking (IBN), service mesh architectures (Istio, Linkerd), and semantic routing literature; the AI agent framing is novel but underlying technical approach closely mirrors existing paradigms.\",\n \"mo\": 1,\n \"mon\": \"Single revision as of May 2026 with no evident WG adoption, community discussion, or implementation reports; appears to be a standalone submission without clear momentum.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to AI agents\u2014addresses multi-agent communication and coordination, but focuses primarily on network routing rather than core agent capabilities, reasoning, alignment, or safety concerns.\",\n \"c\": [\n \"A2A protocols\",\n \"Agent identity/auth\",\n \"Agent discovery/reg\",\n \"Policy/governance\",\n \"Autonomous netops\"\n ]\n}\n```", "in_tok": 580, "out_tok": 381}
|
|
|
|
|
{"draft_name": "draft-dunbar-agent-attachment", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft proposes the Agent Attachment Protocol (AAP) to enable AI agents to attach to edge nodes and exchange endpoint identifiers, communication mechanisms, and attachment context. The protocol aims to support routing, forwarding, and discovery functions for agent-to-agent communication in edge environments.\",\n \"n\": 2,\n \"nn\": \"Incremental application of edge attachment concepts to AI agents; lacks clear differentiation from existing mobile/endpoint attachment protocols (MobileIP, PMIPv6, etc.)\",\n \"m\": 2,\n \"mn\": \"Early draft stage with abstract concepts; no detailed protocol specification, message formats, state machines, or implementation examples provided\",\n \"o\": 4,\n \"on\": \"Significant overlap with established attachment protocols; concepts of endpoint registration, property advertisement, and edge attachment are well-explored in mobile networking and SDN literature\",\n \"mo\": 1,\n \"mon\": \"Single 2026 revision with no evidence of WG discussion, community feedback, or iterative development; appears to be initial submission\",\n \"r\": 3,\n \"rn\": \"Partially relevant to AI agent networking; addresses infrastructure concerns but lacks engagement with actual agent communication patterns, multi-agent coordination, or real deployment scenarios\",\n \"c\": [\n \"A2A protocols\",\n \"Agent discovery/reg\",\n \"Autonomous netops\",\n \"Agent identity/auth\",\n \"Data formats/interop\"\n ]\n}\n```", "in_tok": 570, "out_tok": 345}
|
|
|
|
|
{"draft_name": "draft-tan-ccamp-uonaco-problem-statement", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes unified orchestration between optical transport networks and distributed AI computing infrastructure to enable bidirectional awareness and joint resource provisioning. Addresses the gap where optical networks and compute schedulers operate with isolated control planes, causing suboptimal performance for geographically dispersed AI workloads.\",\n \"n\": 3,\n \"nn\": \"Problem identification is timely and well-motivated, but the core concept of cross-domain orchestration and intent-driven provisioning is not fundamentally novel; similar coordination patterns exist in NFV/SDN and cloud networking contexts.\",\n \"m\": 1,\n \"mn\": \"Pure problem statement document with use cases and high-level requirements; lacks concrete protocol design, architectural specifications, data models, or implementation guidance.\",\n \"o\": 3,\n \"on\": \"Shares conceptual overlap with existing CCAMP work, SDN/NFV orchestration frameworks, and intent-based networking proposals; differentiator is specific focus on AI computing-optical integration but treatment remains abstract.\",\n \"mo\": 2,\n \"mon\": \"Single recent submission (2026-03-02); no evidence of prior iterations, community discussion, or WG sponsorship; early-stage draft with unclear adoption trajectory.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI agent infrastructure and distributed AI system coordination; addresses real operational gaps in modern AI deployments, though framed more as network optimization than autonomous agent interaction.\",\n \"c\": [\n \"ML traffic mgmt\",\n \"Autonomous netops\",\n \"Data formats/interop\",\n \"Model serving/inference\"\n ]\n}\n```", "in_tok": 743, "out_tok": 380}
|
|
|
|
|
{"draft_name": "draft-improving-data-quality-tags", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft proposes using special text tags to improve data quality and contextual understanding in conversational AI models during training and inference. The approach aims to enhance model accuracy and response relevance through structured markup.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution; markup-based context enhancement is a straightforward extension of existing prompt engineering and data annotation practices rather than a fundamentally novel concept.\",\n \"m\": 2,\n \"mn\": \"Early sketch phase; presents high-level concept without detailed specification, formal syntax definition, implementation guidelines, or empirical validation methodology.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing work in prompt engineering, structured data annotation, semantic markup (XML/JSON in training data), and context injection techniques already widely used in LLM fine-tuning.\",\n \"mo\": 1,\n \"mon\": \"No evidence of WG support, community adoption, or iterative development; appears to be single submission without demonstrated momentum in IETF or broader AI community.\",\n \"r\": 2,\n \"rn\": \"Tangentially related to AI agents; focuses on training data quality rather than agent protocols, autonomous operations, or inter-agent communication mechanisms core to IETF AI agent work.\",\n \"c\": [\"Data formats/interop\", \"Human-agent interaction\", \"Other AI/agent\"]\n}\n```", "in_tok": 505, "out_tok": 320}
|
|
|
|
|
{"draft_name": "draft-larsson-aitlp", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"AITLP defines a protocol for managing autonomous software agent identity, trust, and lifecycle within organizational boundaries, emphasizing constraint enforcement and auditability. The protocol complements capability-focused specs by focusing on what agents cannot do rather than what they can, using certificate-based authentication and hierarchical mandate mechanisms.\",\n \"n\": 3,\n \"nn\": \"Organizational governance framework for agents is useful and needed, but combining identity, trust, lifecycle, and scope management within a single protocol is somewhat incremental over existing PKI and capability-based approaches.\",\n \"m\": 3,\n \"mn\": \"Protocol structure and major concepts are defined across 47 pages with mandate enforcement and ALM mechanisms specified, but appears to lack implementation details, test vectors, and concrete examples demonstrating real-world deployment scenarios.\",\n \"o\": 3,\n \"on\": \"Overlaps with A2A protocols in authentication/trust aspects, with policy governance frameworks, and with agent capability specs (MCP, ANS) in scope definition. Core novelty is the lifecycle and mandate-centric integration rather than fundamentally new mechanisms.\",\n \"m\": 2,\n \"mon\": \"Published as April 2026 draft with single revision visible; no clear evidence of WG adoption, implementation feedback, or community momentum. Appears exploratory rather than driven by established ecosystem demand.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to autonomous agent governance and safety, addressing critical organizational needs around agent auditability and authority constraints. Highly relevant to enterprise AI deployment but may be less critical for open-ecosystem agent development.\",\n \"c\": [\"Agent identity/auth\", \"Policy/governance\", \"AI safety/alignment\", \"A2A protocols\"]\n}\n```", "in_tok": 661, "out_tok": 398}
|
|
|
|
|
{"draft_name": "draft-zyyhl-agent-networks-framework", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes a framework for AI agent networks using an Agent Network Protocol (ANP) to enable communication within trusted domains. Addresses basic functions needed for agent-to-agent interaction but lacks detailed specification and implementation maturity.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution applying existing network protocol concepts to AI agents; the core idea of agent communication frameworks is not novel, though domain-specific application may have merit.\",\n \"m\": 2,\n \"mn\": \"Early sketch stage with abstract-only detail; framework definition present but lacks protocol specification details, message formats, authentication mechanisms, or implementation examples.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing agent communication work (FIPA, IEEE 1516, various RPC/messaging protocols); unclear how ANP differentiates from established agent frameworks and network protocols.\",\n \"mo\": 1,\n \"mon\": \"Appears to be single draft submission with no revision history visible; no evidence of WG discussion, community feedback, or iterative development momentum.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to AI agent systems; focuses on networking infrastructure rather than core AI/ML challenges like model deployment, alignment, or safety; more infrastructure-oriented than AI-focused.\",\n \"c\": [\n \"A2A protocols\",\n \"Agent discovery/reg\",\n \"Data formats/interop\",\n \"Agent identity/auth\"\n ]\n}\n```", "in_tok": 495, "out_tok": 343}
|
|
|
|
|
{"draft_name": "draft-serra-mcp-discovery-uri", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes URI scheme and discovery mechanisms for exposing MCP servers via standard endpoints and DNS records, enabling AI agents to autonomously discover available services. Includes optional manifest integrity and capability negotiation for security.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution combining existing patterns (well-known URIs, DNS TXT, JWS) applied to MCP server discovery; no fundamentally novel mechanisms, though useful standardization for the MCP ecosystem.\",\n \"m\": 3,\n \"mn\": \"Defined protocol with multiple discovery modes and security considerations specified, but relatively early IETF draft (26 March 2026) lacking implementation evidence, test vectors, or deployment examples.\",\n \"o\": 3,\n \"on\": \"Shares conceptual approach with service discovery (SRV records, well-known URIs per RFC 5785, DNS TXT metadata), and capability negotiation patterns; moderate overlap with existing internet infrastructure standards adapted for MCP context.\",\n \"mo\": 1,\n \"mon\": \"Single draft revision visible; no WG adoption, community discussion, or implementation signals evident; early-stage proposal without clear momentum in IETF process.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI agent infrastructure\u2014addresses autonomous discovery and safe connection establishment for agents interfacing external services, core operational requirement for distributed AI systems.\",\n \"c\": [\"Agent discovery/reg\", \"A2A protocols\", \"Agent identity/auth\", \"Data formats/interop\", \"Autonomous netops\"]\n}\n```", "in_tok": 699, "out_tok": 362}
|
|
|
|
|
{"draft_name": "draft-williams-intent-token", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes Intent Token, a cryptographic primitive for authorizing specific actions by autonomous AI agents at execution time, filling a gap between session-level OAuth 2.0 frameworks and runtime agent action control. The mechanism is model-agnostic and composable with existing authorization infrastructure.\",\n \"n\": 4,\n \"nn\": \"Addresses a genuine gap in authorization frameworks for autonomous agents; the concept of binding cryptographic authorization to specific agent actions at runtime is non-obvious and represents notable originality in agent control primitives.\",\n \"m\": 2,\n \"mn\": \"Early sketch stage; abstract describes the concept and motivation clearly but insufficient detail provided on mechanism, protocol flow, cryptographic binding details, or examples to assess implementation readiness.\",\n \"o\": 2,\n \"on\": \"Minor similarities to capability-based security and delegation tokens (OIDC, PAT frameworks), but the specific focus on runtime action authorization for autonomous agents rather than session/scope-based access is relatively novel.\",\n \"mo\": 1,\n \"mon\": \"Single draft from 2026-03-19 with no evidence of prior versions, working group discussion, or adoption; appears to be initial submission without community momentum.\",\n \"r\": 5,\n \"rn\": \"Directly addresses a critical gap in autonomous agent authorization; highly relevant to AI safety, agent governance, and human oversight of autonomous systems.\",\n \"c\": [\n \"Agent identity/auth\",\n \"A2A protocols\",\n \"Policy/governance\",\n \"AI safety/alignment\",\n \"Human-agent interaction\"\n ]\n}\n```", "in_tok": 604, "out_tok": 373}
|
|
|
|
|
{"draft_name": "draft-sarischo-6gip-aiagent-requirements", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Draft proposes requirements for AI/ML agents in 6G networks, categorizing agent types and detailing their requirements. Covers implementation approaches including DNS-based discovery mechanisms for inter-domain and intra-domain agent communication.\",\n \"n\": 2,\n \"nn\": \"Incremental extension of AI/ML applications to 6G context; combines existing concepts (agents, DNS discovery, APIs) without substantial methodological innovation.\",\n \"m\": 2,\n \"mn\": \"Early-stage requirements document lacking detailed specifications, implementation examples, or test vectors; DNS discovery approach sketched but not formally specified.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing work on network AI orchestration (3GPP, IETF autonomic networking); agent discovery via DNS mirrors established patterns; limited differentiation from 5G AI/ML frameworks.\",\n \"mo\": 1,\n \"mon\": \"Single revision (2026-03-16); no evidence of WG adoption, community engagement, or iterative development cycle typical of active IETF work.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to AI agents and network automation but lacks depth on core agent semantics; focuses on 6G infrastructure requirements rather than fundamental agent design or protocols.\",\n \"c\": [\n \"Agent discovery/reg\",\n \"Autonomous netops\",\n \"Agent identity/auth\",\n \"Data formats/interop\",\n \"Policy/governance\"\n ]\n}\n```", "in_tok": 554, "out_tok": 353}
|
|
|
|
|
{"draft_name": "draft-sharif-agent-transport-protocol", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"ATP proposes an SMTP-like asynchronous store-and-forward protocol for transmitting autonomous AI agents across network boundaries with cryptographic identity verification, trust scoring, and capability negotiation. It addresses synchronous RPC limitations in agent communication by enabling offline agent mobility while maintaining end-to-end integrity.\",\n \"n\": 2,\n \"nn\": \"Incremental adaptation of SMTP patterns to agent payloads; core concepts (store-and-forward, relay hops, envelope protection) are well-established in email protocols. Limited architectural novelty beyond domain recontextualization.\",\n \"m\": 3,\n \"mn\": \"Protocol mechanisms are formally specified with clear sections on message format, identity verification, and policy enforcement. Lacks implementation details, test vectors, and reference implementations needed for production deployment.\",\n \"o\": 4,\n \"on\": \"Significant overlap with MCP handshake semantics, FIPA ACL agent mobility concepts, and existing A2A frameworks. Trust scoring and policy enforcement echo OAuth/SASL patterns. Differentiation from existing agent communication standards unclear.\",\n \"mo\": 2,\n \"mon\": \"Single draft revision (2026-03-28). No evidence of WG sponsorship, implementation pilots, or community adoption signals. Reads as early-stage proposal without active ecosystem support.\",\n \"r\": 4,\n \"rn\": \"Directly addresses agent communication infrastructure, a core concern for autonomous systems. Relevant to interoperability and identity problems. Less relevant to safety/alignment, training, or inference optimization.\",\n \"c\": [\n \"A2A protocols\",\n \"Agent identity/auth\",\n \"Data formats/interop\",\n \"Policy/governance\",\n \"Agent discovery/reg\"\n ]\n}\n```", "in_tok": 757, "out_tok": 413}
|
|
|
|
|
{"draft_name": "draft-aiendpoint-ai-discovery", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes a standardized .well-known/ai endpoint for web services to expose machine-readable AI agent capabilities and integration requirements in JSON format. Aims to eliminate the need for LLMs to parse human documentation by providing a structured discovery mechanism optimized for token efficiency.\",\n \"n\": 3,\n \"nn\": \"Useful incremental contribution applying the well-established .well-known pattern to AI agent discovery, but conceptually straightforward with limited novelty beyond domain application.\",\n \"m\": 3,\n \"mn\": \"Defines a structured protocol mechanism with JSON schema, though maturity level suggests specification completeness rather than extensive implementation validation or test vectors.\",\n \"o\": 3,\n \"on\": \"Shares conceptual similarities with OpenAPI/Swagger, IANA .well-known registries, and emerging AI agent protocol frameworks; moderate overlap with existing service discovery patterns.\",\n \"mo\": 2,\n \"mon\": \"Single draft revision dated 2026-03-23 with no evident WG sponsorship or adoption signals; early-stage specification momentum.\",\n \"r\": 5,\n \"rn\": \"Directly addresses a core pain point in AI agent deployment\u2014programmatic service discovery\u2014and is highly relevant to autonomous agent ecosystems and interoperability.\",\n \"c\": [\"Agent discovery/reg\", \"Data formats/interop\", \"A2A protocols\", \"Autonomous netops\", \"Agent identity/auth\"]\n}\n```", "in_tok": 601, "out_tok": 338}
|
|
|
|
|
{"draft_name": "draft-li-dmsc-inf-architecture", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes a network infrastructure architecture for enabling secure collaboration between multiple AI agents at scale, focusing on how network control and forwarding planes can actively support agent coordination. Addresses infrastructure-level requirements for dynamic multi-agent systems rather than agent design itself.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution applying existing network architecture concepts to agent collaboration; lacks novel networking mechanisms or protocols specific to agent coordination.\",\n \"m\": 2,\n \"mn\": \"Early-stage framework document; presents architectural vision and requirements but lacks detailed protocol specifications, formal definitions, or implementation guidance.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing work on network slicing, service mesh architectures, and intent-based networking; concepts for multi-entity coordination are well-established in distributed systems literature.\",\n \"mo\": 1,\n \"mon\": \"Single submission with no visible community engagement, WG adoption, or subsequent revisions; appears to be exploratory rather than sustained development effort.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to AI agent systems; frames agents as network clients requiring infrastructure support, but lacks specificity about agent-centric challenges like model coordination, inference distribution, or emergent behavior management.\",\n \"c\": [\n \"Autonomous netops\",\n \"Agent discovery/reg\",\n \"Policy/governance\",\n \"Data formats/interop\"\n ]\n}\n```", "in_tok": 534, "out_tok": 333}
|
|
|
|
|
{"draft_name": "draft-mw-oauth-actor-chain", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Defines six OAuth 2.0 Token Exchange profiles for cryptographically verifiable actor chains in multi-hop service-to-service and agentic workflows. Extends RFC8693 with standardized delegation-path preservation and validation mechanisms offering tradeoffs between disclosure visibility, cryptographic accountability, and privacy.\",\n \"n\": 3,\n \"nn\": \"Incremental but well-motivated extension of RFC8693 addressing a genuine gap in multi-hop delegation validation. The six-profile taxonomy adds structure but builds directly on existing nested act claims mechanism rather than introducing fundamentally new concepts.\",\n \"m\": 4,\n \"mn\": \"Mature specification with detailed profile definitions and processing rules. 97 pages suggests comprehensive treatment with examples and edge cases. However, without seeing full text, unclear if test vectors and reference implementations exist; likely implementation-ready but possibly needing validation feedback.\",\n \"o\": 2,\n \"on\": \"Minor similarities to related delegation work (UMA, SAML assertions) but appears genuinely focused on the RFC8693 token exchange gap. Actor chains in OAuth context are relatively unexplored; limited overlap with concurrent standards.\",\n \"m\": 2,\n \"mon\": \"Single dated revision (2026-05-01 future date suggests draft stage). No evidence of WG adoption or broad community discussion. Addresses real operational need but early adoption signals unclear; may stall without implementer pull.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to agentic workflows requiring service-to-service delegation and multi-hop authorization. Core infrastructure for agent identity/auth in complex orchestration scenarios. High relevance for production agent systems but not core AI safety/alignment.\",\n \"c\": [\"A2A protocols\", \"Agent identity/auth\", \"Data formats/interop\", \"Policy/governance\"]\n}\n```", "in_tok": 733, "out_tok": 425}
|
|
|
|
|
{"draft_name": "draft-templin-intarea-aero2", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"AERO/OMNI is a protocol service for IP internetworking over virtual overlay multilink interfaces using IPv6 ND for control messaging. It supports mobility, multicast, multihop operations and route optimization across diverse applications from aviation to space exploration.\",\n \"n\": 2,\n \"nn\": \"Incremental extension of existing IPv6 ND and routing concepts; applies known techniques (neighbor discovery, dynamic caching, path selection) to overlay network context rather than introducing fundamentally new mechanisms.\",\n \"m\": 4,\n \"mn\": \"Detailed 113-page specification with comprehensive protocol definitions for router discovery, neighbor coordination, path selection and mobility management; implementation-ready with clear message structures and operational procedures.\",\n \"o\": 3,\n \"on\": \"Shares core concepts with existing routing optimization (OSPF, BGP), IPv6 ND extensions, and overlay networking schemes; distinct AERO/OMNI contribution but builds incrementally on established patterns.\",\n \"mo\": 2,\n \"mon\": \"Single revision dated 2024-04-04; no evidence of active WG adoption, multiple iterations, or community momentum; appears to be individual contribution without sustained development activity.\",\n \"r\": 1,\n \"rn\": \"Not related to AI agents, autonomous systems agents, or agent protocols; purely traditional IP networking infrastructure despite mention of 'intelligent transportation systems' as use case (refers to domain application, not AI agents).\",\n \"c\": [\"Other AI/agent\"]\n}\n```", "in_tok": 670, "out_tok": 353}
|
|
|
|
|
{"draft_name": "draft-zhang-rtgwg-multicast-requirements-gaps-aidc", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft analyzes multicast requirements and technology gaps for AI data centers, focusing on improving point-to-multipoint efficiency during LLM training and inference. It identifies key requirements and gaps between multicast needs and existing capabilities in AIDC environments.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution identifying multicast requirements for a specific domain (AIDCs); applies existing multicast concepts to new use case rather than proposing novel solutions.\",\n \"m\": 2,\n \"mn\": \"Early-stage requirements and gap analysis document; lacks concrete protocol specifications, implementation details, or technical solutions beyond problem identification.\",\n \"o\": 3,\n \"on\": \"Shares conceptual overlap with existing multicast standards (PIM, BIER) and datacenter networking drafts; gap analysis format is common for IETF requirements documents.\",\n \"mo\": 2,\n \"mon\": \"Single revision with niche focus area; limited evidence of broader working group momentum or community adoption beyond initial submission.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to AI systems\u2014addresses networking for LLM training/inference but focuses on traditional routing/multicast rather than AI agent behavior, safety, or intelligence aspects.\",\n \"c\": [\n \"ML traffic mgmt\",\n \"Model serving/inference\",\n \"Other AI/agent\"\n ]\n}\n```", "in_tok": 537, "out_tok": 326}
|
|
|
|
|
{"draft_name": "draft-sato-soos-hem", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Defines HEM, a kernel-level protocol for escalating agentic AI decisions to human principals when agent capabilities or policies require human judgment, with formal session states and decision record structures aligned to EU AI Act requirements.\",\n \"n\": 4,\n \"nn\": \"Kernel-level formalization of escalation as first-class session state is original; most prior work treats human-in-the-loop as application concern rather than OS-enforced contract.\",\n \"m\": 3,\n \"mn\": \"Protocol structure, state machine, and decision types are defined; lacks implementation examples, test vectors, and clarity on kernel integration across heterogeneous systems.\",\n \"o\": 2,\n \"on\": \"Distinct from RBAC/ABAC policy frameworks and existing approval workflow systems by positioning escalation as kernel responsibility; minor conceptual overlap with pause/checkpoint mechanisms in agent control systems.\",\n \"mo\": 1,\n \"mon\": \"Single dated draft with no visible revision history or WG sponsorship; appears to be exploratory individual submission without indicated community adoption or iterative development.\",\n \"r\": 5,\n \"rn\": \"Directly addresses core requirement in emerging AI governance: formally specifying human oversight mechanisms for autonomous agents; highly relevant to regulatory compliance and agent safety.\",\n \"c\": [\n \"Human-agent interaction\",\n \"Policy/governance\",\n \"AI safety/alignment\",\n \"Agent identity/auth\",\n \"Data formats/interop\"\n ]\n}\n```", "in_tok": 766, "out_tok": 350}
|
|
|
|
|
{"draft_name": "draft-ietf-aipref-attach", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft proposes signaling mechanisms for content creators to communicate AI usage preferences via HTTP headers, updating RFC 9309. It aims to give stakeholders control over how automated systems consume their content.\",\n \"n\": 2,\n \"nn\": \"Incremental extension of existing HTTP metadata mechanisms; straightforward application of preference signaling to AI consumption context.\",\n \"m\": 3,\n \"mn\": \"Defined protocol mechanism with HTTP header approach, but likely lacks comprehensive examples, test vectors, and implementation guidance expected at maturity.\",\n \"o\": 4,\n \"on\": \"Significant overlap with robots.txt, HTTP User-Agent handling, and similar preference signaling schemes; robots.txt already addresses AI crawler control for many use cases.\",\n \"mo\": 2,\n \"mon\": \"Single revision draft from 2025; unclear WG consensus or implementation interest; appears early in standardization pipeline.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI agent behavior governance and responsible AI consumption practices; addresses legitimate concerns about content usage by LLMs and automated systems.\",\n \"c\": [\n \"Policy/governance\",\n \"Agent discovery/reg\",\n \"Data formats/interop\",\n \"AI safety/alignment\"\n ]\n}\n```", "in_tok": 518, "out_tok": 302}
|
|
|
|
|
{"draft_name": "draft-zhao-ccamp-actn-optical-network-agent", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes integrating AI-based Network Management Agents into ACTN architecture to enhance autonomy in optical network operations. Discusses enhanced architecture, new interfaces, and use cases for agent-based autonomous optical network management.\",\n \"n\": 2,\n \"nn\": \"Incremental extension combining existing ACTN framework with generic AI agent concepts; lacks specific technical innovation in agent design or optical network control algorithms.\",\n \"m\": 2,\n \"mn\": \"Early-stage draft presenting conceptual architecture and use cases without detailed protocol specifications, implementation details, or interoperability mechanisms.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing ACTN work (RFC 8453, related drafts) and generic AI-in-networking proposals; limited differentiation in agent architecture or integration approach.\",\n \"mo\": 2,\n \"mon\": \"Single revision draft with no evidence of WG discussion, adoption, or community momentum; addresses emerging topic but lacks implementation signals.\",\n \"r\": 4,\n \"rn\": \"Directly relevant as it proposes autonomous agent integration into network management, though execution is generic rather than agent-specific.\",\n \"c\": [\n \"Autonomous netops\",\n \"A2A protocols\",\n \"Agent discovery/reg\",\n \"Policy/governance\",\n \"Data formats/interop\"\n ]\n}\n```", "in_tok": 724, "out_tok": 324}
|
|
|
|
|
{"draft_name": "draft-ietf-rats-corim", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"CORIM specifies a CBOR-based format for representing Endorsements and Reference Values in RATS systems, enabling Verifiers to appraise Evidence about remote Attester trustworthiness. Addresses the critical infrastructure challenge of standardizing how manufacturers and device owners communicate integrity metadata to relying parties.\",\n \"n\": 2,\n \"nn\": \"Incremental standardization effort applying CBOR serialization to existing RATS conceptual framework; format design is straightforward encoding of established trust concepts rather than introducing fundamentally new mechanisms.\",\n \"m\": 4,\n \"mn\": \"Well-developed specification with formal CBOR schema, detailed information elements, and clear encoding rules; appears implementation-ready though maturity limited by lack of public reference implementations at draft date.\",\n \"o\": 3,\n \"on\": \"Shares core RATS concepts with multiple existing drafts (RATS architecture, PSA tokens); primary distinction is CBOR format choice and specific manifest structure; moderate conceptual overlap with reference value provider specifications.\",\n \"mo\": 4,\n \"mon\": \"Active WG development with multiple revisions indicating sustained interest; part of coordinated RATS standardization effort with clear adoption path in secure hardware and IoT ecosystems.\",\n \"r\": 2,\n \"rn\": \"Tangentially related to AI/agent systems only through remote attestation mechanisms that could authenticate autonomous agents in trust-critical scenarios; primarily infrastructure/hardware security focused rather than AI-centric.\",\n \"c\": [\n \"Agent identity/auth\",\n \"Data formats/interop\",\n \"Policy/governance\"\n ]\n}\n```", "in_tok": 636, "out_tok": 379}
|
|
|
|
|
{"draft_name": "draft-goswami-agentic-jwt", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Extends OAuth 2.0 with agent checksums and workflow-aware token binding to address the 'intent-execution separation problem' where autonomous AI agents may diverge from user authorization intent. Introduces an agent_checksum grant type and PoP mechanisms for multi-agent zero-trust security.\",\n \"n\": 3,\n \"nn\": \"Identifies a legitimate problem space (agent authorization drift) but solution is primarily an incremental layering of existing OAuth/JWT concepts (checksums, PoP, token binding) without fundamentally new cryptographic or protocol primitives.\",\n \"m\": 2,\n \"mn\": \"Early specification stage; lacks implementation details, test vectors, security proofs, and concrete examples of workflow binding. References companion research paper but core technical validation appears external to this draft.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing work: agent checksums resemble attestation concepts, workflow token binding parallels existing conditional token schemes (CAPs, ABE), and PoP is well-established (RFC 9449). The composition is novel but individual components are not.\",\n \"mo\": 1,\n \"mon\": \"Single draft iteration (2026-01-01 date appears prospective); no evident WG adoption, prior revisions, or community discussion cited. Unclear if this reflects actual draft timeline or placeholder.\",\n \"r\": 4,\n \"rn\": \"Directly addresses critical gap in multi-agent AI systems authorization, highly relevant to emerging deployment scenarios. However, framing as OAuth extension may limit visibility in AI/agent security communities.\",\n \"c\": [\"Agent identity/auth\", \"A2A protocols\", \"AI safety/alignment\", \"Policy/governance\"]\n}\n```", "in_tok": 806, "out_tok": 399}
|
|
|
|
|
{"draft_name": "draft-kamimura-rats-behavioral-evidence", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This informational draft conceptually explores the relationship between RATS remote attestation and behavioral evidence recording, arguing they address complementary verification questions: system trustworthiness versus actual system actions. It does not propose protocol modifications, new mechanisms, or cryptographic bindings.\",\n \"n\": 2,\n \"nn\": \"Incremental conceptual contribution that organizes existing ideas (attestation vs. behavioral evidence) but lacks novel technical or architectural insights.\",\n \"m\": 2,\n \"mn\": \"Early-stage conceptual discussion without protocol definitions, mechanisms, concrete examples, or implementation guidance; purely descriptive framework.\",\n \"o\": 3,\n \"on\": \"Shares core concepts with RATS RFC 9334 and existing audit/logging frameworks; discusses complementary approaches but limited novelty in the relationship itself.\",\n \"mo\": 2,\n \"mon\": \"Single revision as informational draft with no clear WG adoption path or community momentum; appears to be exploratory contribution without sustained development.\",\n \"r\": 2,\n \"rn\": \"Tangentially related to AI agents through potential accountability applications, but focused on general systems attestation rather than AI-specific challenges like model behavior verification or agent trustworthiness.\",\n \"c\": [\"Agent identity/auth\", \"Policy/governance\"]\n}\n```", "in_tok": 614, "out_tok": 304}
|
|
|
|
|
{"draft_name": "draft-du-ai-agent-communication-6g-aspect", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes requirements and use cases for AI Agent-to-Agent communication networks supporting 6G, identifying networking challenges for multi-agent systems performing collaborative tasks. Discusses potential ACN frameworks and standardization approaches but remains largely conceptual.\",\n \"n\": 2,\n \"nn\": \"Incremental extension of existing multi-agent and 6G networking concepts; applies known agent communication patterns to emerging 6G context without substantial technical innovation.\",\n \"m\": 1,\n \"mn\": \"Problem statement and requirements document only; lacks protocol specifications, detailed mechanisms, reference implementations, or concrete technical solutions for proposed ACN frameworks.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing 3GPP 6G studies, multi-agent communication literature, and IoT/edge networking requirements; limited differentiation from prior work on agent collaboration.\",\n \"mo\": 2,\n \"mon\": \"Single revision draft dated 2026-01-02 with no indication of WG adoption, community feedback cycles, or development momentum; nascent work without clear standardization track.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI agent communication and networking aspects, though focuses heavily on 6G context rather than core agent interaction protocols or mechanisms.\",\n \"c\": [\"A2A protocols\", \"Agent discovery/reg\", \"Data formats/interop\", \"ML traffic mgmt\", \"Policy/governance\"]\n}\n```", "in_tok": 610, "out_tok": 334}
|
|
|
|
|
{"draft_name": "draft-yc-ipv6-for-ioa", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft proposes IPv6 as foundational infrastructure for Internet of Agents (IoA), analyzing current capabilities and future requirements as agentic AI systems scale to hundreds of billions. It examines how IPv6's address space, connectivity, and built-in features support agent networks while identifying evolutionary gaps.\",\n \"n\": 2,\n \"nn\": \"Incremental framing of existing IPv6 capabilities applied to a new use case; lacks concrete protocol innovations or technical mechanisms addressing agent-specific challenges.\",\n \"m\": 1,\n \"mn\": \"Early conceptual stage; appears to be a position/requirements paper without defined protocols, mechanisms, or technical specifications for agent-IPv6 integration.\",\n \"o\": 3,\n \"on\": \"Shares general concepts with IoT/6LoWPAN work and standard IPv6 evolution discussions; agent-specific framing is novel but architectural overlap is moderate.\",\n \"mo\": 2,\n \"mon\": \"Single draft submission with no evidence of WG interest, follow-up revisions, or community adoption; positioning suggests exploratory work rather than sustained effort.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to AI agents but primarily focused on network infrastructure rather than agent-specific challenges (identity, autonomy, coordination, alignment); treats agents as generic IoT devices.\",\n \"c\": [\n \"Agent discovery/reg\",\n \"A2A protocols\",\n \"Agent identity/auth\",\n \"Other AI/agent\"\n ]\n}\n```", "in_tok": 598, "out_tok": 356}
|
|
|
|
|
{"draft_name": "draft-borthwick-msebenzi-environment-state", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Defines the environment.* constraint family for Verifiable Intent mandates, enabling autonomous agents to verify external conditions (venue availability, fund status, etc.) before executing transactions on behalf of humans. Establishes registration mechanics and composition disciplines for environment-based constraints without specifying individual constraint types.\",\n \"n\": 2,\n \"nn\": \"Incremental extension of existing Verifiable Intent framework; applies established constraint family patterns to a new domain (environmental conditions) with predictable methodology.\",\n \"m\": 4,\n \"mn\": \"Well-structured specification with clear membership criteria, composition rules, security considerations, and IANA registry mechanics; includes reference implementations in appendices but lacks deployed test vectors.\",\n \"o\": 3,\n \"on\": \"Shares foundational concepts with policy-based authorization and smart contract preconditions; moderate conceptual overlap with existing conditional execution frameworks.\",\n \"mo\": 1,\n \"mon\": \"Single 2026-05-12 dated draft with no visible revision history; no evidence of WG discussion, adoption, or community engagement; appears nascent or stalled.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to autonomous agent authorization and constrained delegation; addresses practical agent capability governance but requires agents already within VI ecosystem.\",\n \"c\": [\n \"Agent identity/auth\",\n \"Data formats/interop\",\n \"Policy/governance\",\n \"Human-agent interaction\",\n \"A2A protocols\"\n ]\n}\n```", "in_tok": 741, "out_tok": 350}
|
|
|
|
|
{"draft_name": "draft-zhu-anima-service-intent", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft proposes a structured semantic model and format for expressing Service Intent in autonomic networks, extending beyond connection-centric descriptions to cover network, compute, and storage resources needed for services like AI inference. It specifies identification, scope, versioning, and lifecycle semantics for goal-oriented service objectives across heterogeneous domains.\",\n \"n\": 2,\n \"nn\": \"Incremental extension of existing ANIMA Intent framework; applies intent concepts to service-level rather than connection-level abstractions, which is a natural but limited conceptual shift.\",\n \"m\": 2,\n \"mn\": \"Early-stage draft; abstract describes model and format but 10 pages unlikely to contain detailed protocol specifications, examples, or implementation guidance needed for production readiness.\",\n \"o\": 4,\n \"on\": \"Significant overlap with ANIMA Intent work, service intent literature, and intent-based networking frameworks; distinguishing factors between this and prior SLA/intent models not evident from abstract.\",\n \"mo\": 2,\n \"mon\": \"Single draft iteration with future date (2026-03-02 suggests placeholder); no evident WG adoption, implementation prototypes, or revision history indicating active community engagement.\",\n \"r\": 3,\n \"rn\": \"Partially relevant; addresses resource coordination for AI inference workloads and autonomous management, but framed primarily as network semantics rather than agent-centric AI systems.\",\n \"c\": [\n \"Data formats/interop\",\n \"Autonomous netops\",\n \"Model serving/inference\",\n \"Policy/governance\"\n ]\n}\n```", "in_tok": 557, "out_tok": 374}
|
|
|
|
|
{"draft_name": "draft-chang-agent-token-efficient", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"ADOL proposes token-efficient optimizations for agentic communication protocols through schema deduplication, adaptive field inclusion, and verbosity control. The work addresses real context window constraints in LLM-based agent systems but relies heavily on existing techniques like JSON references.\",\n \"n\": 2,\n \"nn\": \"Incremental optimization layer combining well-known compression techniques (schema dedup, field elision, response filtering). While contextually motivated by agentic systems, individual mechanisms lack novelty.\",\n \"m\": 3,\n \"mn\": \"Protocol-level mechanisms defined with claimed backward compatibility, but abstract describes optimizations without detailed specifications, examples, or validation. Implementation readiness unclear.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing work: JSON-LD references, content negotiation patterns (Accept headers), selective field inclusion (GraphQL/sparse fieldsets), and schema registries. Primarily repackages established data optimization patterns.\",\n \"mo\": 1,\n \"mon\": \"Single draft dated 2026-01-12 with no revision history visible. No evidence of WG discussion, adoption, or community engagement. Appears newly submitted without prior socialization.\",\n \"r\": 4,\n \"rn\": \"Directly addresses real pain point in emerging agentic systems (context efficiency), though applicability spans broader than just LLM agents. Problem is timely and relevant but somewhat narrow in scope.\",\n \"c\": [\n \"Data formats/interop\",\n \"A2A protocols\",\n \"ML traffic mgmt\",\n \"Model serving/inference\"\n ]\n}\n```", "in_tok": 710, "out_tok": 380}
|
|
|
|
|
{"draft_name": "draft-beyer-agent-identity-architecture", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes an architectural model for establishing human identity roots, delegation semantics, and provenance tracking for software agents acting across distributed systems. Aims to enable accountability and interoperability by creating a consistent framework for representing authorization scope and tracing agent actions back to responsible humans.\",\n \"n\": 3,\n \"nn\": \"Addresses a genuine gap in agent accountability frameworks, but builds primarily on established delegation and provenance concepts rather than introducing fundamentally new mechanisms.\",\n \"m\": 2,\n \"mn\": \"Architectural sketch without protocol definition, wire format, or implementation guidance; lacks concrete binding examples or validation mechanisms for practical deployment.\",\n \"o\": 3,\n \"on\": \"Overlaps conceptually with OIDC delegation flows, W3C Verifiable Credentials provenance models, and existing distributed authorization frameworks; positioning relative to these unclear.\",\n \"mo\": 2,\n \"mon\": \"Single draft publication with April 2026 date; no evidence of WG sponsorship, multiple revisions, or community adoption signals; appears early-stage.\",\n \"r\": 4,\n \"rn\": \"Directly addresses critical need for agent identity and accountability in AI/agent ecosystems; highly relevant to emerging autonomous agent deployment challenges.\",\n \"c\": [\n \"Agent identity/auth\",\n \"Policy/governance\",\n \"Data formats/interop\",\n \"Human-agent interaction\",\n \"AI safety/alignment\"\n ]\n}\n```", "in_tok": 653, "out_tok": 342}
|
|
|
|
|
{"draft_name": "draft-mpsb-agntcy-messaging", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft analyzes messaging protocols for agentic AI systems, proposing AGNTCY SLIM as a purpose-built solution combining MLS encryption with gRPC for quantum-safe end-to-end communication. It positions SLIM as superior to AMQP, MQTT, NATS, and Kafka for AI agent deployments requiring post-compromise security and dynamic group coordination.\",\n \"n\": 2,\n \"nn\": \"Applying existing protocols (MLS, gRPC, OAuth) to messaging for AI agents is incremental; the novelty claim rests on combining known components rather than fundamental innovation in protocol design or agent coordination.\",\n \"m\": 2,\n \"mn\": \"Early sketch phase; abstract describes design goals and comparative analysis but provides no detailed protocol specification, message formats, examples, or implementation evidence. Missing authentication flow details and security proofs.\",\n \"o\": 4,\n \"on\": \"Significant overlap with RFC9420 (MLS), RFC7540 (HTTP/2), RFC6749 (OAuth), and gRPC specifications. SLIM appears to be primarily a composition of existing standards rather than a novel protocol; comparative analysis of existing systems is well-trodden ground.\",\n \"mo\": 1,\n \"mon\": \"Single draft revision (2026-02-24), no evidence of WG sponsorship, community discussion, or implementation activity. Appears to be a proposal without established momentum or organizational backing.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to autonomous agent messaging and infrastructure, addressing real deployment scenarios. However, relevance is primarily infrastructural rather than addressing core AI agent capabilities, alignment, or behavior.\",\n \"c\": [\"A2A protocols\", \"Agent identity/auth\", \"Autonomous netops\", \"Data formats/interop\"]\n}\n```", "in_tok": 789, "out_tok": 420}
|
|
|
|
|
{"draft_name": "draft-templin-manet-inet-omni", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Presents a MANET internetworking framework combining AERO (Automatic Extended Route Optimization) and OMNI (Overlay Multilink Network) technologies to enable autonomous mobile node systems to interoperate with fixed networks like the Internet. Focuses on routing optimization and multilink overlay mechanisms for mobile ad-hoc network integration.\",\n \"n\": 2,\n \"nn\": \"Incremental advancement combining existing AERO/OMNI concepts; applies known technologies to standard MANET internetworking problem rather than introducing fundamentally new approaches\",\n \"m\": 2,\n \"mn\": \"Early-stage framework document with abstract concept presentation; lacks detailed protocol specifications, implementation details, or validation data needed for maturity\",\n \"o\": 4,\n \"on\": \"Significant overlap with established MANET routing literature (RFC 2501 foundation) and prior AERO/OMNI work; limited novel integration beyond combining existing technologies\",\n \"mo\": 1,\n \"mon\": \"No evidence of active development, community engagement, or WG adoption; appears as single recent draft with no revision history or implementation momentum\",\n \"r\": 1,\n \"rn\": \"Not relevant to AI/agent systems; addresses traditional mobile ad-hoc network routing and internetworking, falls outside AI agents, autonomous agents, or agent protocols scope\",\n \"c\": [\"Other AI/agent\"]\n}\n```", "in_tok": 552, "out_tok": 330}
|
|
|
|
|
{"draft_name": "draft-keller-aipref-vocab", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes a standardized vocabulary for machine-readable opt-outs covering Text and Data Mining, AI Training, and Generative AI Training use cases, designed to be mechanism-agnostic and enable interoperable expression of digital asset usage restrictions.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution defining vocabulary terms for existing opt-out concepts; lacks novel framework or mechanism design\",\n \"m\": 2,\n \"mn\": \"Early sketch stage with abstract definitions of three use cases but minimal detail on vocabulary structure, encoding, or integration guidance\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing opt-out standards (robots.txt extensions, machine-readable privacy policies, DNT headers) and emerging TDM directives from EU Digital Markets Act\",\n \"mo\": 1,\n \"mon\": \"Single draft revision with no apparent WG sponsorship, mailing list engagement, or implementation uptake signals\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI governance and data policy concerns, though focused on vocabulary rather than agent behavior or infrastructure\",\n \"c\": [\"Policy/governance\", \"Data formats/interop\"]\n}\n```", "in_tok": 578, "out_tok": 284}
|
|
|
|
|
{"draft_name": "draft-mozleywilliams-dnsop-bandaid", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"BANDAID proposes using DNS and existing mechanisms (SVCB records, DNS-SD, DNSSEC, DANE) to enable discovery, capability advertisement, and trust signaling between AI agents without modifying DNS protocol itself. The approach defines a structured namespace convention (_agents.example.com) for agents to exchange operational metadata and prove domain authorization via Domain Control Validation.\",\n \"n\": 2,\n \"nn\": \"Incremental repurposing of established DNS-SD and SVCB mechanisms for agent discovery; the core technical contribution is primarily a namespace convention and best practice rather than novel protocol design.\",\n \"m\": 3,\n \"mn\": \"Mechanism is clearly defined with concrete examples (chat._agents.example.com SVCB records) and leverages mature DNS standards, but lacks implementation details, test vectors, and validation of the DCV best practice approach.\",\n \"o\": 4,\n \"on\": \"Significant overlap with DNS-SD service discovery, SVCB record usage patterns, and DANE trust frameworks; the application to agents is novel but the underlying technical approach reuses existing standardized solutions with limited adaptation.\",\n \"mo\": 1,\n \"mon\": \"Single draft revision dated 2025-10-16 with no evidence of WG discussion, multiple iterations, or community adoption; appears to be initial submission without momentum indicators.\",\n \"r\": 4,\n \"rn\": \"Directly addresses agent discovery and registration\u2014a core operational challenge in multi-agent systems\u2014and includes identity/authentication considerations, though positioned more as infrastructure-agnostic rather than AI-specific.\",\n \"c\": [\n \"A2A protocols\",\n \"Agent discovery/reg\",\n \"Agent identity/auth\",\n \"Data formats/interop\"\n ]\n}\n```", "in_tok": 785, "out_tok": 418}
|
|
|
|
|
{"draft_name": "draft-zheng-dispatch-agent-identity-management", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft defines identity management mechanisms for agents in an Internet of Agents (IOA) system, specifying agent registration, identifier assignment, and gateway-based identity functions. It addresses descriptive requirements and basic/extended management capabilities for agent lifecycle operations.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution applying conventional identity management concepts to agent systems; lacks architectural novelty or technical innovation distinguishing it from standard service identity patterns.\",\n \"m\": 2,\n \"mn\": \"Early-stage draft with problem definition but minimal protocol detail; appears to be a requirements document rather than a concrete, implementation-ready specification with examples or test vectors.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing identity/credential frameworks (SASL, X.509, OAuth 2.0 scopes) and service discovery protocols (mDNS, SRV records); limited acknowledgment of prior work limits differentiation.\",\n \"mo\": 1,\n \"mon\": \"Single revision at 2026 date suggests minimal community engagement or development activity; unclear WG sponsorship or stakeholder commitment.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to agent infrastructure but framed around generic 'agents' without clear connection to AI/ML agent systems; identity management is peripheral to core AI agent concerns (reasoning, learning, safety).\",\n \"c\": [\"Agent identity/auth\", \"Agent discovery/reg\", \"Data formats/interop\"],\n \"overall_assessment\": \"Underdeveloped early draft addressing a practical but narrow problem using conventional approaches; unclear positioning within agent/AI ecosystem and minimal differentiation from existing standards.\"\n}\n```", "in_tok": 521, "out_tok": 385}
|
|
|
|
|
{"draft_name": "draft-jadoon-nmrg-agentic-ai-autonomous-networks", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes architectural principles for integrating agentic AI systems into the IP protocol stack as coordinated first-class entities at multiple layers while preserving deterministic layering for interoperability. Frames AI agents as autonomous decision-makers working within and across network layers to improve behavior through reasoning and feedback loops.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution combining existing concepts (layered protocols, AI agents, network automation) without substantial technical innovation; the core idea of adding AI to network layers is relatively straightforward application of known agentic AI patterns.\",\n \"m\": 2,\n \"mn\": \"Early-stage position paper identifying research challenges rather than proposing concrete mechanisms; lacks detailed protocols, formal specifications, or implementation guidelines for how agents interact across layers.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing work in intent-based networking, self-healing networks, and AI-driven network operations; architectural layering concepts mirror established SDN/NFV approaches with AI augmentation as the primary novelty.\",\n \"mo\": 2,\n \"mon\": \"Single revision draft with unclear WG trajectory; appears to be initiating discussion in NMRG (Network Management Research Group) but lacks indicators of sustained community engagement or follow-up activity.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI agents in networking contexts; addresses autonomous network operations, agent coordination, and multi-layer reasoning which are core AI agent concerns, though execution details remain nascent.\",\n \"c\": [\n \"Autonomous netops\",\n \"A2A protocols\",\n \"Agent discovery/reg\",\n \"Policy/governance\",\n \"Data formats/interop\"\n ]\n}\n```", "in_tok": 722, "out_tok": 400}
|
|
|
|
|
{"draft_name": "draft-jimenez-agent-directory", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes an Agent Directory (AD) service enabling software agents to register capabilities and endpoints for discovery by clients, adapting RFC 9176's CoRE Resource Directory pattern to agent-oriented architectures using HTTP and JSON.\",\n \"n\": 2,\n \"nn\": \"Incremental adaptation of existing IoT directory pattern to agent domain; straightforward extension rather than fundamental innovation\",\n \"m\": 3,\n \"mn\": \"Defined protocol mechanism with clear structure, but as draft dated 2026-05 lacks visible implementation evidence or detailed test vectors\",\n \"o\": 4,\n \"on\": \"Significant overlap with service discovery patterns (mDNS, DNS-SD) and existing directory services; limited differentiation from CoRE Resource Directory beyond use case\",\n \"mo\": 1,\n \"mon\": \"Single revision with no visible community discussion, WG adoption, or implementation interest signals\",\n \"r\": 4,\n \"rn\": \"Directly relevant to agent ecosystems; addresses genuine infrastructure need for agent discoverability in multi-agent systems\",\n \"c\": [\n \"Agent discovery/reg\",\n \"Agent identity/auth\",\n \"Data formats/interop\",\n \"A2A protocols\"\n ]\n}\n```", "in_tok": 562, "out_tok": 301}
|
|
|
|
|
{"draft_name": "draft-vandemeent-tibet-provenance", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"TIBET proposes a cryptographically-linked provenance chain protocol for tracking interactions between autonomous agents, humans, and processes across four dimensions (content, references, context, intent). The draft specifies token data model, hash-chaining semantics, and integration with companion protocols, targeting append-only audit trails in agent systems.\",\n \"n\": 3,\n \"nn\": \"Useful contribution combining existing cryptographic primitives (hash-chaining, signatures) with a structured provenance model tailored for agent interactions; novelty is moderate\u2014similar concepts exist in supply chain traceability and blockchain systems, but application to autonomous agent provenance is timely.\",\n \"m\": 3,\n \"mn\": \"Protocol and data model are defined with canonicalization and verification procedures specified, but 31 pages suggests incomplete detail; references to four companion protocols (JIS, UPIP, RVP, AINS) without citing them raises concerns about self-contained specification and implementation readiness.\",\n \"o\": 3,\n \"on\": \"Shares core concepts with W3C PROV, COSE/CBOR signing standards, and distributed ledger provenance systems; the four-dimension model is somewhat novel but builds on established provenance ontologies; transport-agnostic design overlaps with several existing audit trail frameworks.\",\n \"m\": 2,\n \"mon\": \"Single draft revision with future date (2026-03-29 appears speculative); no evidence of WG sponsorship, community review, or multiple implementations; companion protocol references suggest early-stage ecosystem development without demonstrated adoption.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to autonomous agent systems requiring accountability, interaction logging, and intent tracking; highly applicable to AI safety, agent governance, and human-agent interaction audit; less directly relevant to model serving or ML traffic management.\",\n \"c\": [\"A2A protocols\", \"Agent identity/auth\", \"AI safety/alignment\", \"Data formats/interop\", \"Human-agent interaction\", \"Policy/governance\"]\n}\n```", "in_tok": 658, "out_tok": 467}
|
|
|
|
|
{"draft_name": "draft-ni-wimse-ai-agent-identity", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft applies WIMSE (Workload Identity in Multi-Cloud and Edge) standards to establish independent identities and credential management for AI agents. It addresses the gap in secure identity mechanisms for autonomous AI systems operating across distributed environments.\",\n \"n\": 2,\n \"nn\": \"Incremental application of existing workload identity framework to AI agents; lacks novel credential mechanisms or identity models specific to agentic AI requirements.\",\n \"m\": 2,\n \"mn\": \"Early-stage applicability document with problem framing; no detailed protocol specifications, implementation examples, or concrete mechanisms for AI agent identity binding.\",\n \"o\": 4,\n \"on\": \"Significant conceptual overlap with existing WIMSE specs and general workload identity efforts; limited differentiation from applying standard credential management to ML/agent workloads.\",\n \"mo\": 2,\n \"mon\": \"Single revision draft with unclear WG adoption; WIMSE itself has moderate momentum but AI agent identity work remains nascent in IETF.\",\n \"r\": 4,\n \"rn\": \"Directly addresses credential and identity management for AI agents, a growing concern; strong relevance to autonomous agent deployment scenarios.\",\n \"c\": [\n \"Agent identity/auth\",\n \"A2A protocols\",\n \"Policy/governance\",\n \"Agent discovery/reg\",\n \"Other AI/agent\"\n ]\n}\n```", "in_tok": 482, "out_tok": 329}
|
|
|
|
|
{"draft_name": "draft-yan-a2a-device-agent-applicability", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes applying the Agent-to-Agent (A2A) Protocol to network management, enabling communication between Controller Agents and Device Agents for autonomous network operation. Explores integration with existing protocols (NETCONF, RESTCONF, gNMI, MCP) and deployment scenarios.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution adapting an existing protocol (A2A) to network management context; core concepts of agent-based autonomic networking and management plane automation are well-established.\",\n \"m\": 2,\n \"mn\": \"Early-stage applicability document lacking detailed protocol specifications, implementation guidance, or concrete technical requirements; reads as conceptual exploration rather than implementable specification.\",\n \"o\": 4,\n \"on\": \"Significant overlap with autonomic networking (ANIMA), existing agent frameworks, and established management protocols; marginal differentiation from prior work on distributed network intelligence.\",\n \"mo\": 1,\n \"mon\": \"Single revision at submission deadline (2026-02-12); no evidence of WG sponsorship, community discussion, or iterative development cycle.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to AI agents in network contexts but focuses narrowly on protocol applicability rather than core agent capabilities (learning, adaptation, reasoning, safety); treats agents primarily as communication endpoints.\",\n \"c\": [\n \"A2A protocols\",\n \"Autonomous netops\",\n \"Data formats/interop\",\n \"Agent discovery/reg\"\n ]\n}\n```", "in_tok": 651, "out_tok": 360}
|
|
|
|
|
{"draft_name": "draft-ietf-lake-edhoc-psk", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Specifies a Pre-Shared Key (PSK) authentication method for EDHOC key exchange, offering computational efficiency with mutual authentication and identity protection. Addresses both external PSKs and session resumption scenarios for resource-constrained IoT and edge systems.\",\n \"n\": 2,\n \"nn\": \"Incremental extension adding PSK mode to existing EDHOC protocol; PSK authentication methods are well-established, though application to EDHOC's specific architecture is useful rather than conceptually novel.\",\n \"m\": 4,\n \"mn\": \"Well-developed specification with detailed protocol flows, key derivation procedures, message formatting, and security analysis; lacks full implementation evidence but provides implementation-ready technical detail.\",\n \"o\": 3,\n \"on\": \"Shares foundational PSK concepts with TLS 1.3 resumption and standard PSK-based protocols; novel mainly in integration with EDHOC's CBOR Object Signing and Encryption framework.\",\n \"m\": 4,\n \"mon\": \"Active LAKE WG engagement with multiple revisions tracking EDHOC evolution; adopted into working group with clear progression toward standardization.\",\n \"r\": 2,\n \"rn\": \"Tangentially related: relevant for agent identity/authentication in constrained environments, but not specifically designed for AI agent systems; applicable only if AI agents operate on IoT/edge infrastructure requiring EDHOC.\",\n \"c\": [\"Agent identity/auth\", \"Data formats/interop\", \"Other AI/agent\"]\n}\n```", "in_tok": 624, "out_tok": 361}
|
|
|
|
|
{"draft_name": "draft-sato-soos-gar", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"GAR proposes an audit architecture for agentic AI systems, defining five audit types and mechanisms to verify compliance with governance primitives like intent declaration and human escalation. It aims to provide regulatory-verifiable evidence of proper AI agent governance.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution applying established audit/logging concepts to AI agents; combines existing governance ideas (intent declaration, escalation) into audit framework without fundamental methodological innovation.\",\n \"m\": 2,\n \"mn\": \"Early sketch stage; defines audit types and high-level architecture but lacks implementation details, data schemas, serialization formats, cryptographic binding mechanisms, or concrete examples of audit records.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing audit logging standards (SIEM, compliance frameworks), AI transparency initiatives, and concurrent work on AI governance primitives; the novelty is primarily in application domain rather than technical approach.\",\n \"mo\": 1,\n \"mon\": \"Single submission (2026-05-17) with no visible revision history, no WG adoption signals, and dependencies on other early-stage drafts (IDP, HEM) that lack momentum.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI agent governance and regulatory compliance needs; addresses genuine concern about auditability but framed narrowly within specific SOOS ecosystem rather than broader agent standards.\",\n \"c\": [\n \"Policy/governance\",\n \"AI safety/alignment\",\n \"Data formats/interop\",\n \"Human-agent interaction\",\n \"Agent identity/auth\"\n ]\n}\n```", "in_tok": 606, "out_tok": 377}
|
|
|
|
|
{"draft_name": "draft-vasylenko-pait-protocol", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"PAIT proposes a wire protocol for token-level provenance attribution and identity-conditioned inference in LLM systems, binding agent identities to authorization levels and associating output tokens with verifiable training-corpus references. The protocol aims to satisfy regulatory transparency requirements for high-risk AI systems through sub-document-granularity attribution and trust telemetry.\",\n \"n\": 3,\n \"nn\": \"Useful but incremental contribution; token-level provenance tracking and agent identity binding are meaningful for compliance, but the core concepts (digital signatures, audit trails, authorization hierarchies) are well-established. Limited technical novelty in cryptographic or protocol design.\",\n \"m\": 3,\n \"mn\": \"Protocol specification is defined with state machines and multiple record formats (Agent Identity Token, Provenance Manifest Record, Trust Telemetry Signal), but draft lacks implementation details, test vectors, interoperability examples, or reference implementations that would indicate production readiness.\",\n \"o\": 3,\n \"on\": \"Shares conceptual territory with existing work on model cards, dataset documentation (ABOUT ML), and inference logging standards. Overlaps with emerging regulatory reporting frameworks (EU AI Act, Executive Orders) but proposes distinct wire-protocol layer not directly addressed in prior standards.\",\n \"mo\": 2,\n \"mon\": \"Single dated revision (2026-05-16) with no evident WG sponsorship, community discussion, or implementation adoption signals. No clear indication of iterative refinement or working group engagement.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI agent governance and model serving; addresses regulatory-driven agent transparency and identity management. Less relevant to core agent autonomy/coordination but highly pertinent to compliance and provenance in deployed systems.\",\n \"c\": [\"A2A protocols\", \"Agent identity/auth\", \"Policy/governance\", \"Model serving/inference\", \"Data formats/interop\"]\n}\n```", "in_tok": 725, "out_tok": 444}
|
|
|
|
|
{"draft_name": "draft-pocero-authkem-edhoc", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Extends EDHOC protocol with post-quantum cryptography using KEM-based authentication mechanisms, enabling quantum-resistant key exchange and signature-free authentication. Addresses the practical need to add PQC support to an existing lightweight protocol while allowing hybrid authentication approaches.\",\n \"n\": 2,\n \"nn\": \"Incremental extension applying existing PQC standards (ML-KEM) to EDHOC; KEM-based authentication is a known technique with limited novelty in this specific application context.\",\n \"m\": 4,\n \"mn\": \"Well-structured 42-page specification with defined protocol mechanisms, parameter choices, and hybrid scenarios; appears ready for implementation though test vectors and reference implementations would improve maturity to level 5.\",\n \"o\": 3,\n \"on\": \"Shares conceptual overlap with existing PQC migration drafts and EDHOC extensions; KEM-based auth builds on known post-quantum authentication patterns; moderate duplication risk with concurrent IETF PQC work.\",\n \"mo\": 2,\n \"mon\": \"Single revision timestamp (2026-03-02) suggests early-stage draft; no visible evidence of WG adoption, multiple revisions, or community discussion; unclear adoption momentum.\",\n \"r\": 2,\n \"rn\": \"Not relevant to AI agents or autonomous systems; focused on cryptographic protocol hardening for general-purpose IoT/constrained devices using EDHOC, orthogonal to agent-specific concerns.\",\n \"c\": [\"Agent identity/auth\", \"Data formats/interop\"]\n}\n```", "in_tok": 624, "out_tok": 368}
|
|
|
|
|
{"draft_name": "draft-chen-oauth-agent-revocation", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Extends OAuth 2.0 token revocation with batch operations, cascade propagation, and agent-level semantics for autonomous systems and cross-domain networks. Introduces new endpoints and coordination protocols to address limitations of RFC 7009's single-token approach.\",\n \"n\": 2,\n \"nn\": \"Incremental extension to existing OAuth 2.0 revocation framework; batch revocation and cascade semantics are natural extensions rather than fundamental innovations.\",\n \"m\": 3,\n \"mn\": \"Defines protocol mechanisms and request/response formats but lacks implementation details, test vectors, or deployment guidance; appears specification-ready but not production-hardened.\",\n \"o\": 3,\n \"on\": \"Shares conceptual overlap with existing batch token management approaches and revocation delegation patterns; some cascade semantics may parallel lifecycle management in other frameworks.\",\n \"mo\": 1,\n \"mon\": \"Single revision as of April 2026 with no evidence of WG adoption, implementation feedback, or community interest; appears nascent.\",\n \"r\": 3,\n \"rn\": \"Tangentially relevant to agent authorization and identity management; addresses agent-level token control but focuses on OAuth extension mechanics rather than core AI agent coordination or safety concerns.\",\n \"c\": [\"Agent identity/auth\", \"Policy/governance\", \"A2A protocols\", \"Data formats/interop\"]\n}\n```", "in_tok": 616, "out_tok": 325}
|
|
|
|
|
{"draft_name": "draft-li-trustworthy-routing-discovery", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft proposes a network architecture and BGP/BGPsec extension for trustworthy routing that enables end users to ensure their data traverses only trusted network devices. The mechanism carries trustworthy routing information (TRI) to mitigate data leakage risks in high-security deployments.\",\n \"n\": 2,\n \"nn\": \"Incremental extension combining existing BGP/BGPsec mechanisms with a trust metadata layer; the core concept of trusted path routing is not novel, though application to BGP is somewhat structured.\",\n \"m\": 2,\n \"mn\": \"Early sketch phase with abstract architecture description but lacking protocol details, data formats, validation procedures, or implementation guidance; insufficient specificity for interoperable deployment.\",\n \"o\": 4,\n \"on\": \"Significant overlap with RPKI/BGPsec trust frameworks, path validation mechanisms in SCION, and existing secure routing proposals; the TRI concept resembles established secure BGP extensions.\",\n \"mo\": 1,\n \"mon\": \"Single revision dated 2025-08-29 with no evident community engagement, working group sponsorship, or adoption signals; appears to be nascent submission without demonstrated momentum.\",\n \"r\": 1,\n \"rn\": \"Not relevant to AI/agent systems; focuses on network routing infrastructure and BGP protocol mechanics with no connection to autonomous agents, AI safety, or agent-related topics.\",\n \"c\": [\"Other AI/agent\"]\n}\n```", "in_tok": 552, "out_tok": 345}
|
|
|
|
|
{"draft_name": "draft-sovereign-svtp", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"SVTP proposes a DID-based trust framework for autonomous machines and AI agents, enabling verifiable identity and M2M interaction with compliance automation. The protocol introduces a 'Protocol Seal' mechanism and aims to address liability and governance in machine-to-machine economies.\",\n \"n\": 2,\n \"nn\": \"Incremental combination of existing DID standards (W3C), cryptographic attestation patterns, and NIST compliance mapping. Core novelty is limited; primarily repackages established identity and trust mechanisms for autonomous systems context.\",\n \"m\": 2,\n \"mn\": \"Early sketch phase. Abstract describes vision but 5-page draft likely lacks detailed protocol specification, message formats, state machines, or security proofs. No evident test vectors or reference implementations mentioned.\",\n \"o\": 4,\n \"on\": \"Significant overlap with W3C DID Core, IETF RATS attestation work, existing blockchain-based identity schemes, and NIST 800-218 compliance frameworks. The 'Protocol Seal' appears to be a credential wrapper without clear differentiation from existing VC/VP patterns.\",\n \"m\": 1,\n \"mon\": \"No observable momentum. Single draft, future publication date (2026-05-04 suggests speculative/undated), no WG affiliation evident, no reference implementations, community discussion, or adoption signals detected.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to agent identity, authentication, and governance. Addresses M2M trust and autonomous systems\u2014core AI agent operational concerns. However, framing lacks depth on actual agent-specific problems versus general IoT/device identity.\",\n \"c\": [\n \"Agent identity/auth\",\n \"A2A protocols\",\n \"Policy/governance\",\n \"Data formats/interop\"\n ]\n}\n```", "in_tok": 600, "out_tok": 430}
|
|
|
|
|
{"draft_name": "draft-stone-atxn", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Defines ATXN, a cryptographic primitive for recording value exchanges between software agents with legal enforceability under existing contract law. Establishes conformance tiers, payment rail profiles, and a two-tier validity model for escrow, dispute resolution, and liability allocation in agentic commerce.\",\n \"n\": 2,\n \"nn\": \"Incremental combination of existing concepts (signed transaction bundles, contract law mapping, payment profiles) without fundamental innovation in transaction semantics or cryptographic primitives.\",\n \"m\": 2,\n \"mn\": \"Early sketch with abstract protocol structure but lacks detailed specifications, implementation examples, test vectors, and formal schema definitions needed for interoperability testing.\",\n \"o\": 4,\n \"on\": \"Significant conceptual overlap with existing payment standards (Stripe ACP, Visa TAP, Mastercard Agent Pay, x402) and agent frameworks; positions as unifying abstraction but dependency chain (AIVS, VCAP, ATEP, ADRP) suggests incomplete scope in single draft.\",\n \"mo\": 1,\n \"mon\": \"First revision (01) with no evidence of WG adoption, community feedback integration, or implementation pilots; co-submission of multiple dependent companion drafts suggests work-in-progress fragmentation rather than mature standardization effort.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to agent transaction infrastructure and identity/authorization, but frames problem through commerce/contract lens rather than core AI agent capability or safety concerns; relevance depends on whether IETF should standardize financial rails.\",\n \"c\": [\n \"A2A protocols\",\n \"Agent identity/auth\",\n \"Data formats/interop\",\n \"Policy/governance\"\n ]\n}\n```", "in_tok": 861, "out_tok": 411}
|
|
|
|
|
{"draft_name": "draft-wiethuechter-drip-det-moc", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft standardizes the use of DRIP Entity Tags (DETs) as identifiers for unmanned aircraft systems to enable trustworthy air domain awareness across RID, UTM, and AAM systems. DETs function as session IDs, authentication key IDs, and encryption key IDs to support privacy, accountability, and confidentiality in airspace management.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution that applies existing DRIP framework to a specific ADA use case; the core concept of using entity tags for identification and key management is established, with this draft focusing on standardization of registration and usage patterns rather than novel identification mechanisms.\",\n \"m\": 3,\n \"mn\": \"Defines protocol mechanisms and usage patterns with reasonable specification detail, though the 16-page length suggests it may lack comprehensive examples, test vectors, or implementation guidance needed for full maturity.\",\n \"o\": 3,\n \"on\": \"Shares identity and key management concepts with existing RID/UTM frameworks and overlaps with DRIP specifications; the novelty lies in the specific application context rather than fundamental technical approach.\",\n \"mo\": 2,\n \"mon\": \"Single revision dated 2025-07-07 with no evidence of iterative development or broader working group adoption; appears to be early-stage document with limited community engagement signals.\",\n \"r\": 2,\n \"rn\": \"Tangentially related to AI agent topics through distributed identity and authentication mechanisms, but primarily concerned with aviation domain-specific airspace management rather than AI systems, autonomous agents, or agent coordination protocols.\",\n \"c\": [\"Agent identity/auth\", \"Data formats/interop\", \"Policy/governance\", \"Other AI/agent\"]\n}\n```", "in_tok": 574, "out_tok": 399}
|
|
|
|
|
{"draft_name": "draft-chuyi-nmrg-agentic-network-inference", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes network architecture and protocols for interconnected AI agents across cloud-edge-end infrastructure, addressing communication, coordination, and distributed inference challenges in multi-agent scenarios.\",\n \"n\": 2,\n \"nn\": \"Incremental combination of existing concepts (edge computing, distributed inference, agent communication) without clearly novel technical mechanisms or protocols.\",\n \"m\": 2,\n \"mn\": \"Early sketch stage; abstract describes problems and motivations but lacks concrete protocol specifications, message formats, or architectural details needed for implementation.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing work on edge computing frameworks, distributed ML inference, IoT coordination protocols, and agent communication standards; positioning relative to prior work unclear.\",\n \"mo\": 1,\n \"mon\": \"Draft metadata indicates single submission with no revision history visible; no evidence of WG engagement, community feedback integration, or active development cycle.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to AI agent networking; focuses on infrastructure layer rather than core agent behavior, autonomy, or decision-making aspects; more network-centric than agent-centric.\",\n \"c\": [\n \"A2A protocols\",\n \"Model serving/inference\",\n \"Agent discovery/reg\",\n \"Autonomous netops\",\n \"ML traffic mgmt\"\n ]\n}\n```", "in_tok": 742, "out_tok": 320}
|
|
|
|
|
{"draft_name": "draft-ietf-drip-auth", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Defines DRIP authentication message formats and protocols for verifying broadcast Remote ID messages in unmanned aircraft systems, enabling trustworthiness assessment without Internet access. Specifies cryptographic mechanisms for authenticating DRIP Entity Tags and associated UAS communications.\",\n \"n\": 2,\n \"nn\": \"Incremental application of existing authentication patterns (signatures, certificates) to UAS RID domain; limited novel cryptographic or protocol design\",\n \"m\": 4,\n \"mn\": \"Detailed protocol specification with message formats, authentication procedures, and trust policies; well-structured but implementation examples limited\",\n \"o\": 3,\n \"on\": \"Shares core concepts with standard PKI/certificate-based auth schemes; builds on existing RID standards (ADS-B, etc.) with modest differentiation\",\n \"mo\": 4,\n \"mon\": \"Active IETF working group (DRIP) with multiple coordinated drafts; clear standardization pathway and regulatory interest from aviation authorities\",\n \"r\": 1,\n \"rn\": \"Not relevant to AI agents, autonomous systems, or agent protocols; focused on UAS identification/authentication infrastructure for human observers\",\n \"c\": [\"Agent identity/auth\", \"Data formats/interop\", \"Policy/governance\", \"Other AI/agent\"]\n}\n```", "in_tok": 585, "out_tok": 310}
|
|
|
|
|
{"draft_name": "draft-zhang-rtgwg-llmmoe-multicast", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft explores potential multicast use cases within LLM Mixture of Experts architectures, particularly for token dispatching during inference. It analyzes how networking multicast could optimize MoE token routing but lacks detailed protocol specifications or implementation guidance.\",\n \"n\": 2,\n \"nn\": \"Incremental observation of existing MoE patterns through a networking lens; multicast for distributed inference is not novel, but application framing to IETF context is moderately original.\",\n \"m\": 1,\n \"mn\": \"Early stage analysis only; no protocol definition, mechanism specification, or architectural details provided; reads as problem statement exploration rather than technical solution.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing distributed inference literature and ML systems research; multicast optimization for token routing has been explored in both academic ML systems and production serving frameworks.\",\n \"mo\": 1,\n \"mon\": \"Single revision, no evidence of WG engagement or community momentum; draft appears exploratory without demonstrated interest from routing or ML operations communities.\",\n \"r\": 2,\n \"rn\": \"Tangentially relevant to AI agent networking; focuses on inference optimization rather than agent protocols, coordination, or decision-making systems; weak connection to core agent networking concerns.\",\n \"c\": [\"Model serving/inference\", \"ML traffic mgmt\", \"Data formats/interop\"]\n}\n```", "in_tok": 540, "out_tok": 322}
|
|
|
|
|
{"draft_name": "draft-yang-dmsc-ioa-task-protocol", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes IoA Task Protocol for enabling distributed collaboration among heterogeneous AI agents across diverse network environments. Defines a layered architecture with extensible messaging to support dynamic team formation, task coordination, and decentralized deployment in intelligent systems like transportation and healthcare.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution combining existing agent coordination concepts with network protocol structure; lacks clear differentiation from FIPA, multi-agent systems middleware, and emerging LLM agent frameworks.\",\n \"m\": 2,\n \"mn\": \"Early-stage draft with abstract-level specification; missing protocol details, message format specifications, state machines, error handling, security mechanisms, and implementation guidance.\",\n \"o\": 4,\n \"on\": \"Significant overlap with FIPA ACL, multi-agent communication standards, service mesh protocols, and existing agent orchestration frameworks; novelty claims not well-substantiated against prior art.\",\n \"mo\": 1,\n \"mon\": \"Single draft revision with 2026 date; no evidence of WG adoption, implementation prototypes, or community engagement; appears exploratory rather than actively developed.\",\n \"r\": 4,\n \"rn\": \"Directly addresses agent-to-agent collaboration and interoperability, core topics for AI systems; however, approach and positioning relative to existing solutions unclear.\",\n \"c\": [\n \"A2A protocols\",\n \"Agent discovery/reg\",\n \"Data formats/interop\",\n \"Autonomous netops\"\n ]\n}\n```", "in_tok": 640, "out_tok": 355}
|
|
|
|
|
{"draft_name": "draft-somoza-atn-agent-trust-negotiation", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Defines Agent Trust Negotiation (ATN) protocol for establishing verifiable agreements between AI agents by binding capability, delegation, provenance, and authority artifacts to DNS-discovered identities. Addresses trust and authorization gaps in agent-to-agent interactions beyond basic discovery mechanisms.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution combining DNS discovery with trust negotiation concepts; applies established authorization patterns (capability-based, delegation, provenance) to agent contexts without fundamental protocol innovation.\",\n \"m\": 3,\n \"mn\": \"Protocol definition appears present at 48 pages with stated artifact bindings, but abstract lacks implementation details, test vectors, or deployment guidance typical of mature specifications.\",\n \"o\": 3,\n \"on\": \"Shares substantial conceptual overlap with SPIFFE/SPIRE (identity binding), OAuth2/OIDC (delegation), and W3C Verifiable Credentials (provenance) frameworks; differentiation for agent-specific requirements unclear from abstract.\",\n \"mo\": 1,\n \"mon\": \"Single draft dated 2026-05-17 with no visible community discussion, WG sponsorship, or implementation signals; appears nascent with minimal adoption indicators.\",\n \"r\": 4,\n \"rn\": \"Directly addresses agent authorization and trust establishment, core operational concerns for autonomous AI systems; relevance high despite early stage, as agent-to-agent trust is pressing standards gap.\",\n \"c\": [\n \"A2A protocols\",\n \"Agent identity/auth\",\n \"AI safety/alignment\",\n \"Policy/governance\",\n \"Agent discovery/reg\"\n ]\n}\n```", "in_tok": 549, "out_tok": 384}
|
|
|
|
|
{"draft_name": "draft-agentir-aepp", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"AEPP proposes a standardized protocol layer for discovering, executing, and verifying payment for AI agents across multiple URI schemes and naming services, using on-chain verification and cryptographic receipts. The draft claims a live reference implementation serving 1.8M agents with zero per-agent fees.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution combining existing concepts (agent URIs, payment verification, DNS naming) into a three-phase execution model; lacks genuinely novel technical mechanisms beyond standard payment+cryptographic verification patterns.\",\n \"m\": 2,\n \"mn\": \"Early sketch with abstract protocol description; lacks detailed message formats, state machine definitions, error handling, cryptographic algorithm specifications, and formal examples needed for implementation interoperability.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing agent frameworks (mcp://, ANS, DNS-AID), payment protocol standards (HTLC-style verification), and agent discovery/registry systems; positions itself as a wrapper layer rather than novel protocol.\",\n \"mo\": 1,\n \"mon\": \"Single draft revision dated 2026-05-15 (future date suggests hypothetical); no evidence of WG discussion, community feedback, or iterative development; live implementation claim unverifiable without public deployment details.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI agent infrastructure, addressing real gaps in agent execution standardization and micropayment coordination; timing aligns with growing agent ecosystem maturity.\",\n \"c\": [\n \"A2A protocols\",\n \"Agent discovery/reg\",\n \"Agent identity/auth\",\n \"Data formats/interop\"\n ]\n}\n```", "in_tok": 600, "out_tok": 395}
|
|
|
|
|
{"draft_name": "draft-campbell-agentic-http", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes best practices for HTTP-based agent-to-agent communication, standardizing tool invocation via GET requests and introducing a stateless auth scheme. Attempts to address interoperability challenges in agentic systems by formalizing the Agentic Hypercall Protocol (AHP) with an economic layer via HTTP 402 status codes.\",\n \"n\": 2,\n \"nn\": \"Incremental effort combining existing HTTP semantics with straightforward agent interaction patterns; lacks architectural innovation or novel protocol mechanisms.\",\n \"m\": 2,\n \"mn\": \"Early sketch of guidelines rather than implementation-ready specification; abstract lacks detail on authentication scheme, error handling, or concrete protocol state machines.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing agent frameworks (OpenAI agents, LangChain tool calling), REST conventions, and prior work on HTTP-based RPC; 402 reuse not novel.\",\n \"mo\": 1,\n \"mon\": \"Single revision with minimal community signals; published as BCP draft but lacks evidence of WG adoption, implementation experience, or iterative refinement.\",\n \"r\": 4,\n \"rn\": \"Directly addresses agent interoperability and protocol standardization, core concerns in emerging agentic systems; timing relevant but execution preliminary.\",\n \"c\": [\n \"A2A protocols\",\n \"Data formats/interop\",\n \"Agent identity/auth\",\n \"Agent discovery/reg\"\n ]\n}\n```", "in_tok": 637, "out_tok": 353}
|
|
|
|
|
{"draft_name": "draft-aap-oauth-profile", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"AAP defines an authorization profile layering structured claims and validation rules on OAuth 2.0/JWT for autonomous AI agents, enabling context-aware M2M authorization with delegation chains and human oversight. It extends existing standards rather than introducing new protocols, targeting agent-to-API scenarios requiring auditable, constraint-aware access control.\",\n \"n\": 2,\n \"nn\": \"Incremental extension combining established OAuth 2.0, JWT, and token exchange mechanisms with agent-specific claim structures; addresses a real gap but primarily recombines existing building blocks rather than introducing fundamentally novel authorization concepts.\",\n \"m\": 4,\n \"mn\": \"Well-structured 83-page specification with defined mechanisms, claim schemas, and validation rules; appears implementation-ready with concrete guidance, though unclear if test vectors and reference implementations are included.\",\n \"o\": 3,\n \"on\": \"Shares conceptual overlap with SPIFFE/SVID (workload identity), UMA (delegation/human oversight), and emerging agent-specific OAuth profiles; differentiation hinges on agent-task-context specificity, but core authorization patterns are established.\",\n \"mo\": 2,\n \"mon\": \"Single revision dated 2026-02-07 with no visible prior versions or WG adoption signals; appears to be recent/initial submission with unclear community traction or competing proposals.\",\n \"r\": 5,\n \"rn\": \"Directly addresses core AI agent authorization challenge\u2014autonomous systems requiring constrained, auditable delegation and human oversight\u2014essential for production AI agent deployments and regulatory compliance.\",\n \"c\": [\"Agent identity/auth\", \"A2A protocols\", \"Policy/governance\", \"Human-agent interaction\", \"Data formats/interop\"]\n}\n```", "in_tok": 582, "out_tok": 400}
|
|
|
|
|
{"draft_name": "draft-yue-anima-agent-recovery-networks", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes a multi-agent framework for autonomous fault recovery in 5G/6G converged networks, enabling distributed failure detection and intent-driven policy reconfiguration across operator domains. Addresses management challenges in complex deployments like MOCN and SNPN through agent collaboration and inter-domain coordination.\",\n \"n\": 2,\n \"nn\": \"Incremental application of established multi-agent concepts to network recovery; combines existing autonomic networking and intent-based management ideas without substantial algorithmic or architectural innovation.\",\n \"m\": 2,\n \"mn\": \"Early sketch phase with abstract framework definition; lacks detailed protocol specifications, algorithmic descriptions, message formats, state machine definitions, and concrete implementation guidance despite claims of 'protocol requirements.'\",\n \"o\": 4,\n \"on\": \"Significant overlap with IETF ANIMA WG intent-based management, existing autonomic recovery proposals, and distributed network management frameworks; multi-agent coordination for networks is well-explored territory.\",\n \"m\": 1,\n \"mon\": \"Single submission with 11 pages suggests limited development iterations; appears to be initial draft without evidence of WG adoption, revisions, or community engagement.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to AI agents in networks; frames agents primarily as functional components rather than autonomous learning entities; focuses on orchestration and coordination rather than core agent AI capabilities.\",\n \"c\": [\n \"Autonomous netops\",\n \"A2A protocols\",\n \"Agent discovery/reg\",\n \"Policy/governance\",\n \"Data formats/interop\"\n ]\n}\n```", "in_tok": 639, "out_tok": 379}
|
|
|
|
|
{"draft_name": "draft-mandel-lamps-rfc5274bis", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This document provides compliance requirements and statements for the CMC (Certificate Management over CMS) enrollment protocol, obsoleting RFCs 5274 and 6402. It specifies what makes a compliant CMC implementation without covering ASN.1 structures or transport mechanisms.\",\n \"n\": 2,\n \"nn\": \"Incremental update consolidating and clarifying existing certificate management protocol requirements; modernization of prior RFCs rather than novel contribution.\",\n \"m\": 4,\n \"mn\": \"Well-defined compliance specification with detailed requirements for implementers; production-ready guidance for established protocol.\",\n \"o\": 5,\n \"on\": \"Direct replacement of RFCs 5274 and 6402; near-complete overlap with prior certificate management specifications being superseded.\",\n \"mo\": 2,\n \"mon\": \"Limited recent momentum; represents maintenance/consolidation of legacy PKI infrastructure rather than active protocol advancement.\",\n \"r\": 1,\n \"rn\": \"Not relevant to AI agents or autonomous systems; focused on traditional certificate enrollment and PKI compliance.\",\n \"c\": [\"Data formats/interop\"]\n}\n```", "in_tok": 540, "out_tok": 272}
|
|
|
|
|
{"draft_name": "draft-loffredo-regext-rdap-verified-contacts", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft extends RDAP with verification status metadata for contact information (email, phone) to improve data quality and trustworthiness. It provides a practical mechanism for registrars and registries to signal which contact fields have undergone verification and through what method.\",\n \"n\": 2,\n \"nn\": \"Incremental extension adding verification metadata to existing RDAP protocol; straightforward application of status indicator patterns already established in domain registries.\",\n \"m\": 3,\n \"mn\": \"Defines protocol mechanism with verification types and status codes; appears to have examples but lacks comprehensive test vectors and implementation guidance for cross-registry deployment scenarios.\",\n \"o\": 3,\n \"on\": \"Shares verification status concept with DNSSEC and email authentication frameworks; overlaps with existing registry verification practices but formalizes them for RDAP interoperability.\",\n \"mo\": 2,\n \"mon\": \"Single revision as of Feb 2026; limited WG discussion signals; typical incremental RDAP extension with moderate community interest but no evidence of rapid adoption momentum.\",\n \"r\": 1,\n \"rn\": \"Not relevant to AI agents or autonomous systems; focuses on registrant contact data validation for domain registry operations, purely a data quality infrastructure concern.\",\n \"c\": [\n \"Data formats/interop\",\n \"Agent identity/auth\",\n \"Policy/governance\"\n ]\n}\n```", "in_tok": 532, "out_tok": 330}
|
|
|
|
|
{"draft_name": "draft-architect-cittamarket", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes CITTAMARKET Protocol for immutable identification and timestamping of AGI systems using Bitcoin's proof-of-work to create 'Sovereign Identity' records without centralized control. A four-layer architecture for distributed autonomous system coordination with priority claims anchored to specific Bitcoin blocks.\",\n \"n\": 2,\n \"nn\": \"Combines existing concepts (blockchain identity anchoring, Bitcoin timestamping, AGI coordination) in straightforward manner; lacks novel cryptographic or architectural innovations beyond applying known patterns to AGI identity problem.\",\n \"m\": 1,\n \"mn\": \"Abstract-only submission with no protocol specification details, mechanism definitions, message formats, or architectural layers described. Missing formal definitions, use cases, or concrete examples required for protocol specification.\",\n \"o\": 4,\n \"on\": \"Substantial overlap with existing blockchain identity systems (Decentralized Identifiers/DIDs), Bitcoin timestamping services, and AGI governance frameworks. Priority claims via blockchain blocks are not novel. Lacks differentiation from prior art.\",\n \"mo\": 1,\n \"mon\": \"No evidence of community adoption, working group engagement, or iterative development. Single draft with future date and vague Bitcoin block references suggest speculative rather than genuine standardization effort.\",\n \"r\": 2,\n \"rn\": \"Tangentially related to AI agent topics through AGI identity framing, but core mechanism (blockchain timestamping) is infrastructure/identity-layer rather than addressing actual AI agent coordination, safety, discovery, or interaction problems.\",\n \"c\": [\n \"Agent identity/auth\",\n \"Policy/governance\",\n \"Other AI/agent\"\n ]\n}\n```", "in_tok": 588, "out_tok": 390}
|
|
|
|
|
{"draft_name": "draft-levy-llm-uri-scheme", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes a URI scheme for identifying and configuring LLM endpoints, similar to database connection strings, encoding provider, model, credentials, and inference parameters into a portable format. Seeks IANA registration as provisional per RFC 7595.\",\n \"n\": 2,\n \"nn\": \"Incremental application of existing URI scheme patterns to a new domain; straightforward extension of well-established database URI conventions without significant technical innovation.\",\n \"m\": 3,\n \"mn\": \"Appears to define the core protocol mechanism with likely syntax and semantics, though maturity level depends on presence of examples, edge cases, and implementation guidance not visible in abstract.\",\n \"o\": 3,\n \"on\": \"Shares conceptual overlap with existing URI schemes (RFC 3986) and connection string standards; related to emerging LLM API standardization efforts but distinct from protocol-level specifications.\",\n \"mo\": 2,\n \"mon\": \"Single draft revision visible; no evidence of WG adoption, multiple implementations, or community discussion; niche use case with limited visibility.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI agent infrastructure, particularly model serving and agent-to-LLM communication patterns; useful for standardizing LLM endpoint discovery and configuration.\",\n \"c\": [\n \"Agent identity/auth\",\n \"Model serving/inference\",\n \"Agent discovery/reg\",\n \"Data formats/interop\",\n \"A2A protocols\"\n ]\n}\n```", "in_tok": 568, "out_tok": 353}
|
|
|
|
|
{"draft_name": "draft-mozleywilliams-dnsop-dnsaid", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes DNS-AID, a DNS-based discovery mechanism for AI agents using existing DNS namespaces and record types to advertise agent metadata and capabilities. The mechanism specifies which access protocol and data format to use without defining the actual information structure.\",\n \"n\": 2,\n \"nn\": \"Incremental application of DNS SRV/TXT record patterns to AI agent discovery; straightforward extension of established DNS service advertisement conventions without novel technical approaches.\",\n \"m\": 3,\n \"mn\": \"Defines a structured mechanism with DNS namespace conventions and record usage model, but abstract on actual implementation details; appears ready for protocol specification but lacks concrete examples and test vectors.\",\n \"o\": 4,\n \"on\": \"Significant overlap with DNS-SD (mDNS/Bonjour), SRV records, and existing service discovery frameworks; conceptually similar to TLSA/DANE for certificate discovery; reinvents established DNS patterns for a new domain.\",\n \"mo\": 1,\n \"mon\": \"Single draft revision with 2026 date; no evidence of WG activity, community discussion, or follow-up iterations; appears as proposal-stage work without demonstrated momentum.\",\n \"r\": 4,\n \"rn\": \"Directly addresses agent discovery infrastructure, a legitimate concern for multi-agent systems; however, frames it as DNS-specific rather than agent-centric, making it more about DNS namespace utilization than core AI agent problems.\",\n \"c\": [\n \"Agent discovery/reg\",\n \"Data formats/interop\",\n \"A2A protocols\"\n ]\n}\n```", "in_tok": 655, "out_tok": 377}
|
|
|
|
|
{"draft_name": "draft-nourse-scep", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"SCEP is a standardization of an existing, widely-deployed PKI enrollment protocol that uses PKCS#7 and PKCS#10 over HTTP. This draft documents a mature protocol with extensive real-world implementation rather than introducing novel techniques.\",\n \"n\": 1,\n \"nn\": \"Purely standardization of existing VeriSign/Cisco protocol; no novel cryptographic or architectural contributions\",\n \"m\": 4,\n \"mn\": \"Well-defined protocol specification with clear message flows and established implementations across PKI vendors and endpoints\",\n \"o\": 5,\n \"on\": \"Near-complete overlap with original VeriSign protocol and multiple vendor implementations; primarily a formalization effort rather than new design\",\n \"mo\": 2,\n \"mon\": \"Single revision visible; standardization of legacy protocol with stable installed base but limited ongoing development activity\",\n \"r\": 1,\n \"rn\": \"Certificate enrollment protocol with no relevance to AI agents, autonomous systems, or agent communication protocols\",\n \"c\": [\n \"Data formats/interop\",\n \"Agent identity/auth\"\n ]\n}\n```", "in_tok": 537, "out_tok": 272}
|
|
|
|
|
{"draft_name": "draft-rosenberg-aiproto", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"N-ACT proposes a standardized protocol for AI agents to discover and invoke third-party tools/APIs, targeting enterprise integration scenarios. It defines two main functions: tool enumeration (for agent designers and optional LLM runtime use) and tool invocation across domain boundaries.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution; tool integration and API abstraction for agents is well-established territory. The draft essentially wraps existing patterns (function calling in OpenAI spec) into a named protocol without significant technical innovation.\",\n \"m\": 2,\n \"mn\": \"Early sketch stage. Abstract describes intent clearly but document maturity unclear from title page alone; likely lacks detailed protocol mechanics, formal grammar, security considerations, and implementation guidance typical of mature IETF specs.\",\n \"o\": 4,\n \"on\": \"Significant overlap with OpenAI function calling spec (which it explicitly extends), Anthropic tool use, and emerging agent framework standards. Also overlaps with semantic web service discovery (WSDL-era concepts). Limited differentiation articulated.\",\n \"mo\": 1,\n \"mon\": \"Appears to be a single-revision independent submission (2025-10-20 date, no prior versions evident). No indication of WG adoption, community discussion, or iterative refinement. Limited signals of momentum.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to AI agents\u2014focuses on tool integration which is a real operational concern, but addresses a narrow tactical problem rather than foundational agent architecture, safety, or coordination challenges.\",\n \"c\": [\n \"Data formats/interop\",\n \"A2A protocols\",\n \"Agent discovery/reg\",\n \"Human-agent interaction\"\n ]\n}\n```", "in_tok": 719, "out_tok": 408}
|
|
|
|
|
{"draft_name": "draft-aevum-wlp", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"WLP v0 specifies a protocol for converting AI research hypotheses into executable wet-lab automation instructions, positioning itself as a longevity-research equivalent to existing photoresist automation protocols with reference implementations in Rust and Python.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution applying existing automation schema patterns (SCP) to a new domain (wet-lab/longevity research) rather than introducing fundamentally new concepts\",\n \"m\": 3,\n \"mn\": \"Protocol definition appears reasonably specified with reference implementations provided, though v0 status and 6-page limit suggest incomplete specification detail typical of early drafts\",\n \"o\": 3,\n \"on\": \"Shares conceptual overlap with SCP and general AI-to-automation instruction translation frameworks; domain-specific but not architecturally novel\",\n \"mo\": 1,\n \"mon\": \"Single revision (v0), May 2026 date suggests recent/speculative draft with no evidence of WG discussion or adoption momentum in IETF context\",\n \"r\": 3,\n \"rn\": \"Partially relevant as a data format/interoperability mechanism for AI agent outputs, but narrowly scoped to wet-lab automation rather than addressing core agent AI challenges\",\n \"c\": [\"Data formats/interop\", \"Model serving/inference\", \"A2A protocols\"]\n}\n```", "in_tok": 584, "out_tok": 327}
|
|
|
|
|
{"draft_name": "draft-srijal-agents-policy", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"AGENTS.TXT proposes a plaintext policy file format similar to robots.txt for controlling automated clients and bots, with strict hash verification and fail-safe restrictive defaults for malformed files. The specification aims to standardize bot access control across the web with mandatory compliance behavior.\",\n \"n\": 2,\n \"nn\": \"Incremental extension of robots.txt concept; applies established web policy patterns to agent control without fundamental innovation.\",\n \"m\": 3,\n \"mn\": \"Protocol mechanics defined with directives and verification requirements, but 5-page draft likely lacks comprehensive examples, edge cases, and implementation details needed for production deployment.\",\n \"o\": 4,\n \"on\": \"Significant overlap with robots.txt, similar conceptually to RFC 9309 (robots.txt update); unclear differentiation or advantages over existing web crawling standards.\",\n \"mo\": 1,\n \"mon\": \"Single revision dated 2026-04-10 with no evidence of WG adoption, community discussion, or iterative development.\",\n \"r\": 2,\n \"rn\": \"Tangentially related to AI agents; applies to automated clients generally but doesn't address LLM-specific concerns, model governance, or modern AI safety requirements.\",\n \"c\": [\n \"Data formats/interop\",\n \"Policy/governance\",\n \"Agent identity/auth\"\n ]\n}\n```", "in_tok": 529, "out_tok": 329}
|
|
|
|
|
{"draft_name": "draft-nelson-agent-delegation-receipts", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes a cryptographic protocol where users pre-sign authorization receipts with scope, time, and instruction boundaries before delegating control to AI agents, with signatures published to append-only logs to prevent operator tampering.\",\n \"n\": 3,\n \"nn\": \"Combines existing primitives (signed authorizations, append-only logs, delegation tokens) in a new arrangement for AI agents; the core insight of pre-signature + immutable log is useful but not fundamentally novel in cryptographic authorization design.\",\n \"m\": 2,\n \"mn\": \"Early specification phase\u2014defines protocol structure and objectives but appears to lack implementation details, test vectors, concrete API specifications, and security analysis of edge cases (log availability, key compromise recovery).\",\n \"o\": 3,\n \"on\": \"Shares conceptual overlap with OAuth 2.0 delegation flows, capability-based security (OCAP), and audit logging standards; distinct from but related to work on agent attestation and model input validation.\",\n \"mo\": 2,\n \"mon\": \"Single draft revision dated 2026-05-19; no evidence of WG adoption, community discussion, or iterative refinement; unclear if this addresses a recognized IETF priority.\",\n \"r\": 4,\n \"rn\": \"Directly addresses authorization and accountability in AI agent deployments, a critical concern as agents execute user-delegated tasks; highly relevant to emerging agent governance needs.\",\n \"c\": [\"Agent identity/auth\", \"Policy/governance\", \"Human-agent interaction\", \"AI safety/alignment\"]\n}\n```", "in_tok": 560, "out_tok": 365}
|
|
|
|
|
{"draft_name": "draft-beyer-agent-identity-problem-statement", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Identifies the gap between current identity systems (which authenticate software) and the need for human-anchored agent identity that maintains verifiable provenance, scoped delegation, and human authority across distributed agent ecosystems. Positions this as a foundational architectural problem rather than a protocol solution.\",\n \"n\": 4,\n \"nn\": \"The framing of 'human anchoring' as distinct from traditional software identity is novel; most identity systems treat agents as autonomous entities. The emphasis on provenance chains and scoped delegation across heterogeneous agent contexts addresses a genuine gap.\",\n \"m\": 1,\n \"mn\": \"Pure problem statement with no proposed mechanisms, protocols, or implementation guidance. Serves as motivation document but lacks architectural sketches or technical depth needed to guide solution development.\",\n \"o\": 2,\n \"on\": \"Moderate overlap with OAuth 2.0 delegation models and W3C Verifiable Credentials work, but the specific lens of human-agent authority chains in autonomous systems is underexplored in IETF.\",\n \"mo\": 2,\n \"mon\": \"Single draft dated 2026-04-01 with no visible revision history or WG adoption signals. Problem space is timely but document lacks indicators of sustained community traction.\",\n \"r\": 5,\n \"rn\": \"Directly addresses core AI agent infrastructure challenge: how to maintain human accountability and control as agents proliferate. Highly relevant to emerging autonomous systems governance concerns.\",\n \"c\": [\n \"Agent identity/auth\",\n \"Policy/governance\",\n \"Human-agent interaction\",\n \"A2A protocols\"\n ]\n}\n```", "in_tok": 674, "out_tok": 383}
|
|
|
|
|
{"draft_name": "draft-vesely-dmarc-mlm-transform", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft proposes a mechanism to restore original From: headers in emails processed by Mailing List Managers (MLMs) that rewrite them due to DMARC authentication requirements. It uses an author-centric strategy where signing agents enable reversal of MLM transformations at the receiving end.\",\n \"n\": 2,\n \"nn\": \"Incremental solution to known DMARC-MLM compatibility problem; builds on existing authentication and header manipulation concepts rather than introducing fundamentally new mechanisms.\",\n \"m\": 3,\n \"mn\": \"Defines a protocol mechanism with clear strategy and methodology, though document length (17pg) and presentation suggest it may lack comprehensive implementation guidance or test vectors expected of higher maturity specs.\",\n \"o\": 3,\n \"on\": \"Related to existing DMARC, ARC, and MLM literature; shares concepts with multiple prior proposals addressing From: header rewriting but presents a distinct author-centric approach.\",\n \"mo\": 2,\n \"mon\": \"Single revision dated 2024-11-22 with no evidence of working group adoption, multiple iterations, or community discussion driving continued development.\",\n \"r\": 1,\n \"rn\": \"Not relevant to AI agents or autonomous systems; purely focused on email authentication and mailing list infrastructure\u2014no connection to AI safety, agent protocols, or autonomous operations.\",\n \"c\": [\"Other AI/agent\"]\n}\n```", "in_tok": 591, "out_tok": 331}
|
|
|
|
|
{"draft_name": "draft-bernardos-cats-isac-uc", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft proposes Integrated Sensing and Communications (ISAC) as a use case scenario for CATS (Computing, Automation, and Network Slicing), exploring how joint optimization of sensing and communication functions can enable autonomous systems and smart city applications.\",\n \"n\": 2,\n \"nn\": \"ISAC is an established concept; the contribution is primarily framing it within CATS context rather than introducing novel sensing-communication integration principles.\",\n \"m\": 2,\n \"mn\": \"Early sketch phase\u2014presents motivation and potential applications but lacks detailed protocol specifications, technical requirements, or implementation considerations for ISAC-CATS integration.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing ISAC literature and 3GPP work on sensing; positioning within CATS adds minimal differentiation; unclear how this differs from parallel ISAC standardization efforts.\",\n \"mo\": 2,\n \"mon\": \"Single revision document with limited evidence of community engagement; ISAC momentum exists separately, but ISAC-specific CATS momentum appears nascent.\",\n \"r\": 2,\n \"rn\": \"Tangentially related to AI agents\u2014addresses autonomous system coordination and networked perception but focuses on wireless infrastructure and communication rather than agent reasoning, decision-making, or AI-specific concerns.\",\n \"c\": [\n \"Autonomous netops\",\n \"Data formats/interop\",\n \"Policy/governance\"\n ]\n}\n```", "in_tok": 601, "out_tok": 341}
|
|
|
|
|
{"draft_name": "draft-sharif-aeba", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"AEBA proposes a behavioral monitoring framework for autonomous AI agents, adapting enterprise UEBA concepts to agent security. It defines event schemas, identity binding, baseline protocols, and SIEM interoperability for cross-framework agent deployments.\",\n \"n\": 2,\n \"nn\": \"Straightforward adaptation of existing UEBA methodology to agents; core concept is incremental extension rather than novel.\",\n \"m\": 3,\n \"mn\": \"Protocol mechanisms and schema defined, but unclear if implementation-ready; no evidence of test vectors or reference implementations.\",\n \"o\": 4,\n \"on\": \"Significant overlap with UEBA frameworks and general SIEM event correlation; agent-specific aspects are relatively narrow additions to established patterns.\",\n \"mo\": 1,\n \"mon\": \"Single revision with 2026 date suggests early-stage work; no indication of WG adoption, community engagement, or iterative refinement.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to autonomous agent security monitoring; timely given AI agent proliferation, though execution rather than foundational.\",\n \"c\": [\n \"Agent identity/auth\",\n \"Data formats/interop\",\n \"AI safety/alignment\",\n \"Policy/governance\",\n \"Autonomous netops\"\n ]\n}\n```", "in_tok": 671, "out_tok": 315}
|
|
|
|
|
{"draft_name": "draft-barnes-hpke-hpke", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"HPKE is a standardized hybrid public key encryption scheme combining asymmetric KEMs with symmetric AEAD, offering authenticated variants for secure communication. This CFRG product provides practical instantiations using ECDH, HKDF, and SHA2 for arbitrary-sized plaintext encryption.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution combining existing primitives; the hybrid encryption concept is well-established, though the specific modular design and authenticated variants represent useful standardization rather than fundamental novelty.\",\n \"m\": 5,\n \"mn\": \"Implementation-ready specification with detailed protocol description, test vectors, and multiple instantiations across 125 pages; mature CFRG deliverable suitable for deployment.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing hybrid encryption schemes (ElGamal+AES models) and authenticated encryption frameworks; addresses standardization gaps rather than introducing conceptually new combinations.\",\n \"mo\": 5,\n \"mon\": \"Strong community momentum evidenced by CFRG endorsement, active adoption in protocols like TLS 1.3, QUIC, and MLS, with widespread implementation across cryptographic libraries.\",\n \"r\": 1,\n \"rn\": \"Not relevant to AI agents, autonomous systems, or distributed agent protocols; this is pure cryptographic infrastructure with no agent-specific application or consideration.\",\n \"c\": [\"Other AI/agent\"]\n}\n```", "in_tok": 688, "out_tok": 341}
|
|
|
|
|
{"draft_name": "draft-intellinode-ai-semantic-contract", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes a semantic contract mechanism allowing AI applications to communicate tensor flow requirements to networks, enabling differentiated scheduling and resource allocation based on application semantics rather than treating traffic as opaque byte streams. Targets improved resource utilization in distributed training and inference scenarios across heterogeneous computing environments.\",\n \"n\": 3,\n \"nn\": \"Useful contribution bridging application semantics and network-layer optimization, but builds incrementally on existing QoS and intent-based networking concepts applied to AI workloads.\",\n \"m\": 2,\n \"mn\": \"Early sketch stage\u2014abstract describes high-level concept but 6 pages insufficient for protocol definition; lacks concrete message formats, state machines, or implementation details.\",\n \"o\": 3,\n \"on\": \"Shares conceptual overlap with intent-based networking (IBN), application-aware networking (AAN), and existing DiffServ/QoS contracts; similar ideas explored in SDN and ML-specific network optimization work.\",\n \"mo\": 2,\n \"mon\": \"Single draft publication (2026-03-02) with no evident revision history or WG adoption signals; appears early-stage without demonstrated community engagement.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI infrastructure and model serving/inference optimization; addresses real pain point in distributed training networks but not core to agent behavior or autonomy.\",\n \"c\": [\"ML traffic mgmt\", \"Model serving/inference\", \"Data formats/interop\", \"Autonomous netops\"]\n}\n```", "in_tok": 608, "out_tok": 355}
|
|
|
|
|
{"draft_name": "draft-liu-dmsc-gw-requirements", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes gateway requirements for Dynamic Multi-agents Secured Collaboration (DMSC) systems to improve scalability, communication efficiency, and security. Identifies gaps in existing hardware/software gateways and argues for a specialized DMSC Gateway entity.\",\n \"n\": 2,\n \"nn\": \"Incremental work applying existing gateway concepts to multi-agent systems; lacks architectural novelty or algorithmic innovation.\",\n \"m\": 1,\n \"mn\": \"Problem statement and requirements document only; no protocol specification, mechanisms, or implementation details provided; appears preliminary.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing gateway, load balancing, and multi-agent middleware literature; DMSC appears undefined, limiting distinctiveness assessment.\",\n \"mo\": 1,\n \"mon\": \"Single revision with 2026 date; no evidence of WG discussion, community engagement, or iterative development; appears dormant.\",\n \"r\": 2,\n \"rn\": \"Tangentially related to multi-agent systems but focuses on infrastructure/gateway requirements rather than core AI agent capabilities, protocols, or intelligence aspects.\",\n \"c\": [\n \"A2A protocols\",\n \"Autonomous netops\",\n \"Agent discovery/reg\",\n \"Policy/governance\"\n ]\n}\n```", "in_tok": 533, "out_tok": 311}
|
|
|
|
|
{"draft_name": "draft-sharif-agent-audit-trail", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes a JSON-based audit logging standard (AAT) for autonomous AI systems with hash-chained tamper-evidence and multi-framework compliance (EU AI Act, SOC 2, ISO/IEC 42001). Addresses regulatory mandates for high-risk AI event recording while supporting GDPR-compatible deletion and multiple transport formats.\",\n \"n\": 3,\n \"nn\": \"Useful contribution standardizing AI agent logging; combines existing concepts (hash chains per RFC 8785, syslog, ECDSA signatures) in domain-specific format rather than novel cryptographic or protocol innovation.\",\n \"m\": 4,\n \"mn\": \"Well-structured specification with defined JSON schema, field taxonomy, hash-chaining mechanism, and multi-format export; lacks explicit test vectors, reference implementation, or deployment examples for full maturity.\",\n \"o\": 3,\n \"on\": \"Shares core concepts with CEL (Common Expression Language), COSE (RFC 9052) for signing, and general audit trail patterns; distinguishes itself through AI-agent-specific field semantics and regulatory mapping rather than fundamental novelty.\",\n \"mo\": 2,\n \"mon\": \"Single dated revision (2026-03-29); no evidence of WG sponsorship, multiple iterations, or community adoption signals; EU AI Act deadline creates external urgency but document shows limited internal momentum.\",\n \"r\": 5,\n \"rn\": \"Directly addresses core AI agent governance and auditability; highly relevant to autonomous system deployment, regulatory compliance, and agent trustworthiness\u2014central to safe agent operation.\",\n \"c\": [\n \"Agent identity/auth\",\n \"Data formats/interop\",\n \"Policy/governance\",\n \"Autonomous netops\",\n \"Other AI/agent\"\n ]\n}\n```", "in_tok": 701, "out_tok": 425}
|
|
|
|
|
{"draft_name": "draft-irtf-nmrg-llm-nm", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes a framework for LLM-assisted network management with human oversight, including enhanced telemetry, LLM decision modules, and standardized interaction models. Aims to integrate AI-driven automation into existing network operations while maintaining human control and compatibility with current management systems.\",\n \"n\": 2,\n \"nn\": \"Incremental application of existing LLM concepts to network management; human-in-the-loop and telemetry integration are established patterns, lacking novel architectural or algorithmic contributions.\",\n \"m\": 2,\n \"mn\": \"Early-stage framework definition with abstract concepts; missing detailed protocol specifications, concrete data models, implementation guidelines, and validation methodologies needed for standardization.\",\n \"o\": 4,\n \"on\": \"Significant overlap with broader AI-for-network-operations discussions and existing network telemetry standards; human-in-the-loop AI concepts are well-established in other domains.\",\n \"mo\": 1,\n \"mon\": \"Single draft revision (2025-09-14); no evidence of WG adoption, implementation activity, or community feedback; positioned in IRTF research group rather than standards track.\",\n \"r\": 4,\n \"rn\": \"Directly addresses LLM integration in network operations with focus on human-agent interaction and autonomous netops, though AI safety and governance aspects receive limited treatment.\",\n \"c\": [\n \"Autonomous netops\",\n \"Human-agent interaction\",\n \"Data formats/interop\",\n \"A2A protocols\",\n \"Policy/governance\"\n ]\n}\n```", "in_tok": 566, "out_tok": 371}
|
|
|
|
|
{"draft_name": "draft-sato-soos-cap", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"CAP proposes a kernel-enforced three-tier prohibition architecture for agentic AI systems, with absolute treaty-based prohibitions, jurisdiction-specific rules, and voluntary standards, evaluated against both agent actions and human principal decisions. The draft introduces Jurisdictional Conflict Resolution to surface irreconcilable conflicts to humans via escalation mechanisms.\",\n \"n\": 4,\n \"nn\": \"Three-tier prohibition model with dual evaluation points (agent + human principal) is a genuinely novel approach to AI safety enforcement; kernel-level enforcement architecture breaks from typical application-layer controls.\",\n \"m\": 2,\n \"mn\": \"Early sketch phase; abstract describes mechanism concepts but 24 pages likely insufficient for detailed protocol specification, implementation details, or formal semantics; referenced I-D dependency suggests incomplete framing.\",\n \"o\": 2,\n \"on\": \"Minor similarities to existing AI policy/governance frameworks and constitutional AI concepts (Anthropic), but the kernel-enforcement dual-evaluation architecture and JCR mechanism appear distinct from established approaches.\",\n \"mo\": 1,\n \"mon\": \"Single draft with future-dated publication (2026-05-17); no evidence of WG adoption, multiple revisions, or community engagement; appears speculative or early-stage.\",\n \"r\": 5,\n \"rn\": \"Directly addresses core challenges in AI agent governance, safety alignment, and human-agent interaction; prohibition enforcement is fundamental to responsible agentic AI deployment.\",\n \"c\": [\"AI safety/alignment\", \"Policy/governance\", \"Human-agent interaction\", \"Agent identity/auth\", \"A2A protocols\"]\n}\n```", "in_tok": 662, "out_tok": 379}
|
|
|
|
|
{"draft_name": "draft-calabria-bmwg-ai-fabric-terminology", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Establishes vendor-neutral benchmarking terminology for Ethernet fabrics supporting distributed AI training and inference, consolidating and extending definitions from RFCs 1242 and 8238 with AI-specific KPIs, collective communication primitives, and RDMA mechanisms.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution; primarily a terminology standardization effort consolidating existing concepts (RFCs 1242, 8238) with incremental AI-fabric-specific extensions rather than introducing novel benchmarking approaches.\",\n \"m\": 4,\n \"mn\": \"Well-defined terminology document with companion methodology drafts; structured as a reference standard with precise definitions, though implementation guidance and test vectors are delegated to companion documents.\",\n \"o\": 4,\n \"on\": \"Significant overlap with RFC 1242 and RFC 8238 benchmarking frameworks; explicitly extends existing standards rather than proposing independent methodology, with stated precedence over prior RFCs in AI fabric context.\",\n \"mo\": 2,\n \"mon\": \"Limited momentum indicators; single revision date (2026-02-27) with two companion drafts suggest organized work, but no clear WG adoption signals or community feedback evident from abstract alone.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI infrastructure; addresses critical gap in standardized terminology for AI fabric benchmarking, essential for comparing distributed training/inference systems, though terminology definition rather than core agent capability.\",\n \"c\": [\"ML traffic mgmt\", \"Data formats/interop\", \"Model serving/inference\", \"Other AI/agent\"]\n}\n```", "in_tok": 682, "out_tok": 378}
|
|
|
|
|
{"draft_name": "draft-liu-oauth-a2a-profile", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft defines an OAuth Transaction Token profile for Agent-to-Agent communication, enabling distributed agents to maintain identity and authorization context across call chains within trusted domains. It addresses the emerging need to apply established OAuth mechanisms to autonomous agent workloads.\",\n \"n\": 2,\n \"nn\": \"Incremental extension applying existing OAuth Transaction Token concept to A2A scenarios; straightforward adaptation rather than novel cryptographic or architectural innovation.\",\n \"m\": 2,\n \"mn\": \"Early specification draft (5 pages) likely presenting conceptual framework; insufficient detail to assess implementation completeness or testing readiness.\",\n \"o\": 3,\n \"on\": \"Shares core concepts with OAuth 2.0 Transaction Tokens and existing agent authorization work; moderate overlap with concurrent A2A security proposals in emerging standards.\",\n \"mo\": 1,\n \"mon\": \"Single recent revision; no evidence of WG discussion, implementation feedback, or adoption signals in IETF ecosystem.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to agent identity and authorization; addresses practical security need for autonomous agent orchestration, though framed within OAuth rather than AI-specific context.\",\n \"c\": [\n \"A2A protocols\",\n \"Agent identity/auth\",\n \"Policy/governance\",\n \"Data formats/interop\"\n ]\n}\n```", "in_tok": 526, "out_tok": 320}
|
|
|
|
|
{"draft_name": "draft-howard-virp", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"VIRP proposes a cryptographic trust framework for autonomous and human operators managing live network infrastructure, using dual-signature schemes, two-channel separation, and trust tiers to ensure observation integrity and authorized state changes. The draft includes multi-vendor implementation against 35+ devices and formal verification of protocol security under Dolev-Yao adversary model.\",\n \"n\": 4,\n \"nn\": \"Novel integration of cryptographic primitives specifically designed for autonomous agent operations on infrastructure; dual-signature approach and two-channel intent/observation separation are non-obvious architectural choices distinct from traditional PKI frameworks.\",\n \"m\": 4,\n \"mn\": \"Detailed protocol specification with live multi-vendor implementation (IronClaw) against production hardware; formal verification via ProVerif and Tamarin demonstrates maturity, though full test vectors and edge-case handling may be incomplete.\",\n \"o\": 2,\n \"on\": \"Minor overlap with NETCONF/YANG security models and PKI frameworks; the agent-specific trust tiers and dual-signature scheme differentiate from existing infrastructure protocols, though intent gating resembles capability-based security patterns.\",\n \"m\": 2,\n \"mon\": \"Single draft submission dated 2026-05-21 with no evidence of WG adoption, revision history, or community discussion; appears to be early-stage proposal without demonstrated ecosystem momentum.\",\n \"r\": 5,\n \"rn\": \"Directly addresses core challenge of autonomous agent trustworthiness in critical infrastructure; agent identity, authorization, human-agent interaction, and autonomous netops are all central to the proposal.\",\n \"c\": [\n \"Autonomous netops\",\n \"Agent identity/auth\",\n \"AI safety/alignment\",\n \"Human-agent interaction\",\n \"Policy/governance\",\n \"A2A protocols\"\n ]\n}\n```", "in_tok": 896, "out_tok": 429}
|
|
|
|
|
{"draft_name": "draft-ni-a2a-ai-agent-security-requirements", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft outlines security requirements for AI agents across their lifecycle stages including provisioning, registration, discovery, and access control in cross-domain environments. It addresses authentication, authorization, and identity management for autonomous AI systems operating in interconnected networks.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution applying established security patterns (identity, provisioning, access control) to AI agents without demonstrating novel threat models or architectural innovations specific to autonomous AI systems.\",\n \"m\": 2,\n \"mn\": \"Early-stage requirements document; lacks detailed protocols, formal specifications, implementation examples, or test vectors needed for actual deployment guidance.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing IETF security frameworks (CBOR security, RFC 8174 requirements language), OAuth/OIDC patterns, and general device security provisioning standards; limited AI-agent-specific differentiation.\",\n \"mo\": 1,\n \"mon\": \"Single revision as recent draft with no visible WG adoption, community implementation work, or indication of ongoing development momentum.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI agent security landscape; addresses real operational concerns, though framing as generic requirements rather than emerging AI-specific threat vectors limits scope clarity.\",\n \"c\": [\n \"Agent identity/auth\",\n \"Agent discovery/reg\",\n \"Policy/governance\",\n \"A2A protocols\"\n ]\n}\n```", "in_tok": 489, "out_tok": 342}
|
|
|
|
|
{"draft_name": "draft-aylward-aiga-1", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"AIGA 1.0 proposes a tiered risk-based governance framework for autonomous AI agents using immutable kernel architectures, federated authority networks, and economic incentive alignment. The protocol targets real-world deployment constraints with advanced mechanisms like multi-vendor TEE attestation and human review boards for high-assurance scenarios.\",\n \"n\": 3,\n \"nn\": \"Tiered governance + federated authority + economic incentives is a useful synthesis, but federated trust networks and risk-based access control are established patterns; the AI-agent-specific application is incremental rather than architecturally novel.\",\n \"m\": 2,\n \"mn\": \"Protocol architecture is described at high level with component names and concepts, but lacks detailed message formats, state machines, cryptographic bindings, implementation guidance, and concrete test vectors needed for interoperability.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing work: federated PKI/trust (DANE, DNSSEC precedents), TEE attestation (TCG specs), action-based authorization (ABAC frameworks), network quarantine (BGP flowspec), and multi-sig approval (blockchain governance). Core concepts not unique.\",\n \"m\": 2,\n \"mon\": \"Single 2026 revision with no visible WG discussion, community feedback, or adoption signals; appears to be individual submission without demonstrated implementer interest or iterative refinement.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to autonomous AI agent governance and policy enforcement, a topic of growing IETF interest; however, scope is broader than typical IETF protocols (governance, economics, human oversight) and may belong in an AI/ML working context rather than general standards.\",\n \"c\": [\n \"Policy/governance\",\n \"Agent identity/auth\",\n \"AI safety/alignment\",\n \"Autonomous netops\",\n \"Human-agent interaction\"\n ]\n}\n```", "in_tok": 809, "out_tok": 454}
|
|
|
|
|
{"draft_name": "draft-yang-alto-multi-domain", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft explores ALTO (Application-Layer Traffic Optimization) in multi-domain network scenarios where traffic paths span multiple autonomous networks. It presents three use cases, identifies challenges, and outlines implementation solutions to enable cross-domain network information sharing.\",\n \"n\": 2,\n \"nn\": \"Incremental extension of ALTO to multi-domain contexts; domain federation concepts are well-established in networking, though application to ALTO is moderately useful.\",\n \"m\": 2,\n \"mn\": \"Early sketch stage with use cases and challenges outlined but limited protocol detail; implementation solutions mentioned but not formally specified or validated.\",\n \"o\": 3,\n \"on\": \"Shares core concepts with existing multi-domain networking standards (BGMP, federation protocols); ALTO itself addresses cross-domain scenarios inherently, limiting novelty of extension.\",\n \"mo\": 1,\n \"mon\": \"Single revision at 2024-01-11 with no apparent prior versions or subsequent activity; appears inactive or exploratory rather than driven by active WG consensus.\",\n \"r\": 2,\n \"rn\": \"Tangentially related to AI agent topics; focuses on network optimization infrastructure rather than AI agent communication, autonomy, or decision-making. Not core to AI/agent systems.\",\n \"c\": [\"Data formats/interop\", \"Policy/governance\", \"Agent discovery/reg\"]\n}\n```", "in_tok": 583, "out_tok": 324}
|
|
|
|
|
{"draft_name": "draft-yao-tsvwg-cco-requirement-and-analysis", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft analyzes network-assisted optimization techniques for collective communication operations in AI training clusters, identifying gaps between emerging approaches and current IETF standards like iWARP. It proposes requirements for standardizing collective acceleration mechanisms compatible with RDMA-based parallel computing infrastructure.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution; applies known collective optimization concepts to RDMA standards context, but lacks novel technical mechanisms or architectural insights beyond problem articulation.\",\n \"m\": 2,\n \"mn\": \"Early-stage requirements document; presents problem analysis and gap identification but lacks detailed protocol specifications, implementation examples, or technical solutions.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing work on collective communication optimization (MPI, NCCL) and network-assisted acceleration; limited differentiation from prior research in HPC networking.\",\n \"mo\": 1,\n \"mon\": \"Single revision as of submission date (2025-01-09); no evidence of WG sponsorship, community discussion, or iterative development momentum.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to AI infrastructure but focuses narrowly on transport optimization rather than AI agent systems, model serving, or agent-specific requirements.\",\n \"c\": [\"ML traffic mgmt\", \"Model serving/inference\"]\n}\n```", "in_tok": 650, "out_tok": 312}
|
|
|
|
|
{"draft_name": "draft-ietf-rats-evidence-trans", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft specifies methods to transform heterogeneous evidence structures (DiceTcbInfo, SPDM measurements, concise evidence) into a unified CoRIM internal representation for remote attestation verification. It addresses the practical challenge that verifiers must handle multiple evidence encoding formats while preserving semantics during appraisal procedures.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution focused on standardizing evidence format conversions within existing RATS/CoRIM frameworks rather than introducing novel attestation or transformation concepts.\",\n \"m\": 4,\n \"mn\": \"Well-specified protocol with detailed transformations for multiple evidence types and clear mappings to CoRIM; appears implementation-ready though test vectors not mentioned in abstract.\",\n \"o\": 3,\n \"on\": \"Builds directly on CoRIM, DICE, and SPDM standards with moderate overlap; addresses a recognized interoperability gap but within established architectural constraints.\",\n \"mo\": 4,\n \"mon\": \"Active WG development (RATS) with clear problem motivation; draft targets known ecosystem fragmentation (DICE/SPDM/CoRIM heterogeneity) driving adoption potential.\",\n \"r\": 1,\n \"rn\": \"Not relevant to AI agents or autonomous systems; focuses on hardware/firmware attestation infrastructure and verifier decision-making, domain-specific to trustworthiness assessment rather than agent-oriented protocols or intelligence.\",\n \"c\": [\n \"Data formats/interop\",\n \"Agent identity/auth\"\n ]\n}\n```", "in_tok": 615, "out_tok": 364}
|
|
|
|
|
{"draft_name": "draft-narajala-ans", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"ANS proposes a DNS-like protocol for AI agent discovery and registration using PKI certificates and a modular adapter layer supporting multiple communication standards. It addresses secure agent identity verification and multi-agent system interoperability through structured JSON-based communication.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution applying established DNS patterns and PKI to agent discovery; core concepts (naming, registration, certificate-based trust) are well-known, though their specific combination for agents is somewhat novel.\",\n \"m\": 3,\n \"mn\": \"Defined protocol with structured schemas and threat analysis, but lacks implementation details, deployment guidance, and operational considerations needed for production systems.\",\n \"o\": 3,\n \"on\": \"Shares significant concepts with service discovery (mDNS, Consul), PKI/X.509 standards, and existing agent communication frameworks (MCP, ACP); positioning relative to these is unclear.\",\n \"mo\": 1,\n \"mon\": \"Single revision dated 2025-11-18 with no evidence of WG adoption, community feedback integration, or iterative development momentum.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI agent ecosystems; agent discovery and secure identity are genuine problems, though draft conflates multiple distinct concerns (naming, discovery, protocol adaptation, PKI).\",\n \"c\": [\n \"Agent discovery/reg\",\n \"Agent identity/auth\",\n \"A2A protocols\",\n \"Data formats/interop\",\n \"Policy/governance\"\n ]\n}\n```", "in_tok": 685, "out_tok": 366}
|
|
|
|
|
{"draft_name": "draft-rosenberg-aiproto-cheq", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"CHEQ proposes a protocol for human-in-the-loop confirmation of AI agent decisions and actions, integrating with MCP, A2A, and N-ACT protocols while protecting user privacy. It aims to prevent unwanted actions from AI hallucinations through signed confirmation objects before execution.\",\n \"n\": 3,\n \"nn\": \"Incremental contribution addressing a real operational need (HITL safeguards), but the core concept of human confirmation gates is well-established; primary novelty is packaging this as an interoperable protocol layer.\",\n \"m\": 2,\n \"mn\": \"Early sketch phase\u201415 pages suggest concept definition but likely lacks implementation details, comprehensive protocol state machines, error handling, or test vectors needed for production deployment.\",\n \"o\": 3,\n \"on\": \"Shares conceptual territory with existing HITL systems, approval workflows, and policy enforcement mechanisms; some overlap with MCP extensions and general agent governance frameworks, but claims focus on integration with multiple protocols differentiates it.\",\n \"r\": 5,\n \"rn\": \"Directly addresses critical AI agent safety and governance\u2014human-in-the-loop decision confirmation is core to trustworthy autonomous system deployment and aligns with emerging agent standardization efforts.\",\n \"mo\": 2,\n \"mon\": \"Single revision (2026-04-22 date); no evidence of WG backing, community adoption, or competing implementations; early-stage IETF submission without demonstrated momentum.\",\n \"c\": [\n \"Human-agent interaction\",\n \"AI safety/alignment\",\n \"A2A protocols\",\n \"Policy/governance\",\n \"Data formats/interop\",\n \"Agent identity/auth\"\n ]\n}\n```", "in_tok": 656, "out_tok": 405}
|
|
|
|
|
{"draft_name": "draft-morrison-mcp-dns-discovery", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Defines a DNS TXT record-based discovery mechanism for Model Context Protocol servers, extending it to advertise organizational identity and individual cryptographic identity envelopes bound to sovereign handles. Complements HTTPS discovery with a lightweight, DNSSEC-validated bootstrap approach.\",\n \"n\": 2,\n \"nn\": \"Incremental extension applying established DNS-based identity patterns (DKIM, SPF, DMARC, MTA-STS) to MCP server discovery; the core novelty is adapting existing techniques to a new protocol rather than introducing fundamentally new concepts.\",\n \"m\": 3,\n \"mn\": \"Defined protocol mechanism with three TXT record types and DNSSEC/DANE requirements specified, but lacks implementation evidence, test vectors, and deployment guidance; appears spec-complete but not implementation-ready.\",\n \"o\": 3,\n \"on\": \"Shares conceptual space with service discovery (SRV records), organizational identity bootstrapping (DMARC/SPF patterns), and certificate pinning (DANE), but applies them in novel combination for MCP; moderate overlap with existing DNS identity infrastructure.\",\n \"m\": 2,\n \"mn\": \"Single revision cycle visible (v01\u2192v02\u2192current); modest update cadence suggests early-stage development; unclear if driven by working group or individual contributor effort.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to agent discovery, registration, and authentication infrastructure; enables decentralized identity binding for MCP agents operating across domains; high relevance to autonomous agent interoperability.\",\n \"c\": [\n \"Agent discovery/reg\",\n \"Agent identity/auth\",\n \"A2A protocols\",\n \"Data formats/interop\",\n \"Policy/governance\"\n ]\n}\n```", "in_tok": 943, "out_tok": 418}
|
|
|
|
|
{"draft_name": "draft-rosenberg-aiproto-a2t", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Defines a protocol for AI agents to discover and invoke third-party tools/APIs, standardizing tool enumeration and invocation operations to reduce enterprise integration costs. Builds on OpenAI specifications with focus on enterprise agent-to-tool interactions.\",\n \"n\": 2,\n \"nn\": \"Incremental work; tool use in LLMs is established practice (OpenAI functions, ReAct), and this appears to formalize existing patterns rather than introduce novel concepts.\",\n \"m\": 3,\n \"mn\": \"Protocol appears reasonably defined with enumeration and invocation features specified, but abstract lacks concrete message formats, error handling details, or implementation guidance expected at maturity level 4.\",\n \"o\": 4,\n \"on\": \"Significant overlap with OpenAI's function calling spec, ReAct framework, and emerging A2A protocols. Unclear how this differs substantively from existing tool-use standardization efforts.\",\n \"mo\": 2,\n \"mon\": \"Single draft revision (2026-05-10 date suggests recent submission); no evidence of WG sponsorship, multiple revisions, or community engagement visible from abstract.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI agent operations and tool integration\u2014core concern for enterprise AI systems, though narrow in scope (excludes agent-to-agent, policy, safety aspects).\",\n \"c\": [\n \"A2A protocols\",\n \"Agent discovery/reg\",\n \"Data formats/interop\",\n \"Human-agent interaction\"\n ]\n}\n```", "in_tok": 702, "out_tok": 367}
|
|
|
|
|
{"draft_name": "draft-vandemeent-jis-identity", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"JIS proposes a dual-keypair identity protocol for autonomous agents with trust negotiation and human-readable intent tracking, designed as a semantic layer integrating with multiple related standards. The work addresses identity binding and context capture for agent interactions but relies heavily on undefined companion specifications.\",\n \"n\": 2,\n \"nn\": \"Dual-keypair separation (HID/DID) is incremental over existing PKI patterns; intent declaration binding is useful but not fundamentally novel. Heavy dependence on undefined standards (TIBET, UPIP, RVP, AINS) limits independent assessment of originality.\",\n \"m\": 2,\n \"mn\": \"Early sketch stage. 25 pages appears insufficient for a complete protocol specification. Abstract references undefined companion drafts, missing implementation details, test vectors, and threat model analysis needed for maturity assessment.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing identity/trust frameworks (SAML, OAuth 2.0, SPIFFE/SPIRE, DID specifications). The 'Humotica' context layer is novel but the core identity mechanisms appear largely combinatorial of existing patterns.\",\n \"m\": 1,\n \"mon\": \"No evidence of community momentum. Single draft, no visible WG discussion, no adoption signals, no implementation reports. Future date (2026-03-29) suggests speculative or aspirational work.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to autonomous agents. Addresses agent identity and human-agent interaction directly, but applicability depends entirely on undefined companion specifications. Unclear if this solves genuine AI agent problems versus general distributed system identity.\",\n \"c\": [\n \"Agent identity/auth\",\n \"A2A protocols\",\n \"Human-agent interaction\",\n \"Data formats/interop\",\n \"Agent discovery/reg\"\n ]\n}\n```", "in_tok": 665, "out_tok": 438}
|
|
|
|
|
{"draft_name": "draft-ietf-dnsop-dns-error-reporting", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft proposes a DNS error reporting mechanism that encodes error information in query QNAMEs to automatically notify authoritative server operators of resolution or validation failures. It leverages RFC8914 extended DNS errors to provide domain operators feedback on misconfigurations or attacks without requiring out-of-band reporting channels.\",\n \"n\": 2,\n \"nn\": \"Incremental extension building directly on RFC8914; the core novelty is using QNAME encoding for error signaling rather than in-band DNS responses, a pragmatic but not particularly innovative technique.\",\n \"m\": 4,\n \"mn\": \"Well-structured protocol specification with clear mechanism description; includes monitoring agent interaction details and error encoding methodology; lacks implementation details and test vectors for full readiness.\",\n \"o\": 2,\n \"on\": \"Minor similarities to existing DNS monitoring and telemetry approaches (EDNS0 signaling, query logging); the QNAME-based approach is a distinct method though conceptually aligned with established error reporting patterns.\",\n \"r\": 1,\n \"rn\": \"No relevance to AI agents or autonomous systems; purely a DNS operational infrastructure improvement for error notification and domain hosting diagnostics.\",\n \"mo\": 4,\n \"mon\": \"Strong WG adoption indicated by IETF dnsop publication status and 2024 date suggesting active standards-track progress; multiple revisions expected in mature development cycle.\",\n \"c\": [\"Other AI/agent\"]\n}\n```", "in_tok": 627, "out_tok": 344}
|
|
|
|
|
{"draft_name": "draft-stephan-ai-agent-6g", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft examines AI agent communication protocols for 6G systems by referencing 3GPP TR 22.870 use cases and extrapolating service requirements. It positions itself as foundational work for standardizing agent-to-agent and agent-to-tool interactions in next-generation networks.\",\n \"n\": 2,\n \"nn\": \"Incremental work that applies existing 3GPP framework to agent communication; lacks novel protocol designs or architectural insights beyond TR 22.870 scope.\",\n \"m\": 2,\n \"mn\": \"Early-stage sketch dependent on external 3GPP document; no protocol definitions, message formats, or implementation details provided in the abstract.\",\n \"o\": 4,\n \"on\": \"Significant overlap with 3GPP TR 22.870 and existing A2A protocol work; appears to be secondary analysis rather than original contribution.\",\n \"mo\": 1,\n \"mon\": \"Single revision with April 2026 date suggests nascent work; no evidence of WG adoption, multiple iterations, or community engagement.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI agent systems and 6G standardization; timely topic but execution and depth unclear from abstract alone.\",\n \"c\": [\n \"A2A protocols\",\n \"Agent discovery/reg\",\n \"Data formats/interop\",\n \"Policy/governance\"\n ]\n}\n```", "in_tok": 544, "out_tok": 338}
|
|
|
|
|
{"draft_name": "draft-zeng-nmrg-mcp-usecases-requirements", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft proposes integrating the Model Context Protocol (MCP) into network management to enable AI agents to discover and invoke network capabilities through a standardized interface. It outlines use cases in troubleshooting, measurement, security, and optimization while specifying functional and security requirements.\",\n \"n\": 2,\n \"nn\": \"The idea of applying MCP (an existing protocol) to network management is incremental\u2014combining two established concepts without fundamental innovation in either domain.\",\n \"m\": 1,\n \"mn\": \"This is a problem statement and requirements document only; no protocol details, mechanisms, or implementation guidance are provided.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing work on intent-based networking, AI-driven network automation, and agent-based management systems; MCP itself is a known protocol being applied in a relatively straightforward manner.\",\n \"mo\": 2,\n \"mon\": \"Single revision (dated 2026-02-14) with no visible community engagement, WG adoption, or follow-up activity yet; early-stage exploratory work.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI agents in network operations and agent discovery/registration; addresses a real gap in standardized agent interfaces for infrastructure management.\",\n \"c\": [\n \"A2A protocols\",\n \"Autonomous netops\",\n \"Agent discovery/reg\",\n \"Agent identity/auth\",\n \"Data formats/interop\",\n \"Human-agent interaction\"\n ]\n}\n```", "in_tok": 595, "out_tok": 360}
|
|
|
|
|
{"draft_name": "draft-ietf-v6ops-nd-considerations", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Consolidates ND protocol security and operational issues scattered across 20+ RFCs into a unified framework, identifying three root causes and recommending subnet/link isolation strategies for mitigation in IPv6 deployments.\",\n \"n\": 2,\n \"nn\": \"Incremental synthesis work; repackages known ND problems (multicast inefficiency, trust assumptions) without proposing novel technical solutions or mechanisms.\",\n \"m\": 3,\n \"mn\": \"Well-defined problem analysis with practical guidance on existing mitigation approaches (subnet isolation); lacks novel protocol specifications or implementation artifacts.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing ND security RFCs (SEND, SeND extensions, RA-Guard); consolidation effort rather than novel contribution; similar analysis in scattered prior documents.\",\n \"mo\": 2,\n \"mon\": \"Single revision document dated 2025-11-21; no evident WG momentum or multiple iterations; appears as standalone consolidation effort rather than active development stream.\",\n \"r\": 1,\n \"rn\": \"Not relevant to AI agents or autonomous systems; focused on IPv6 Neighbor Discovery protocol operations, security hardening, and network infrastructure deployment best practices.\",\n \"c\": [\"Other AI/agent\"]\n}\n```", "in_tok": 689, "out_tok": 303}
|
|
|
|
|
{"draft_name": "draft-ramakrishna-satp-views-addresses", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft proposes a DLT-neutral framework for projecting and addressing views of virtual assets across distributed ledger systems, enabling external parties to request, locate, and verify asset states or computed functions while maintaining system-specific access controls and consensus logic.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution addressing cross-chain asset interoperability; views and addressing are conceptually straightforward extensions of existing DLT bridging patterns without fundamental innovation in the core mechanism.\",\n \"m\": 2,\n \"mn\": \"Early sketch phase with problem articulation and architectural concepts; lacks detailed protocol specifications, message formats, concrete examples, or implementation guidance needed for deployment.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing SATP work, cross-chain bridge architectures, and DLT interoperability standards; views concept parallels state projection mechanisms in Cosmos, Polkadot, and other multi-chain frameworks.\",\n \"mo\": 2,\n \"mon\": \"Single revision with modest adoption signals; part of SATP family but no evidence of widespread WG engagement or implementation momentum in broader blockchain community.\",\n \"r\": 2,\n \"rn\": \"Tangentially related to agent topics only through loose interpretation of 'external parties' and 'agents' querying systems; primarily focused on blockchain asset interop rather than AI agents, agent protocols, or autonomous systems.\",\n \"c\": [\n \"Data formats/interop\",\n \"Policy/governance\",\n \"Agent discovery/reg\"\n ]\n}\n```", "in_tok": 751, "out_tok": 364}
|
|
|
|
|
{"draft_name": "draft-ietf-vwrap-authentication", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Defines authentication mechanisms for the Virtual World Region Agent Protocol (VWRAP), establishing application-layer associations between client applications and identity management services. Focuses on credential verification to grant capabilities for agent control and digital asset management in virtual environments.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution applying established authentication patterns to virtual world/metaverse contexts; adapts existing identity frameworks rather than introducing fundamentally new authentication paradigms.\",\n \"m\": 3,\n \"mn\": \"Defined protocol mechanism with clear objectives and architectural model, though maturity level depends on completeness of specification details and practical implementation guidance in full document.\",\n \"o\": 3,\n \"on\": \"Shares conceptual overlap with OAuth/OpenID Connect flows and existing agent authentication models; VWRAP-specific but not substantially differentiated from general service-to-identity-provider authentication patterns.\",\n \"mo\": 2,\n \"mon\": \"Limited visible momentum; single dated revision (2024-09-24) suggests early-stage or dormant WG activity; VWRAP itself appears to have niche adoption in virtual world contexts.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to agent identity and authentication, core infrastructure concern for autonomous agent systems; addresses critical capability control and asset protection in agent-centric architectures.\",\n \"c\": [\n \"Agent identity/auth\",\n \"A2A protocols\",\n \"Policy/governance\",\n \"Agent discovery/reg\"\n ]\n}\n```", "in_tok": 518, "out_tok": 354}
|
|
|
|
|
{"draft_name": "draft-liu-saag-zt-problem-statement", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"A problem statement draft advocating for IETF standardization of zero trust interoperability frameworks to enable multi-vendor deployments in cloud and remote workforce scenarios. The document identifies gaps between high-level NIST guidance and practical protocol needs without proposing specific technical solutions.\",\n \"n\": 2,\n \"nn\": \"Zero trust is well-established (NIST SP 800-207); this draft merely argues IETF should work on it rather than proposing novel concepts or mechanisms.\",\n \"m\": 1,\n \"mn\": \"Pure problem statement with no protocol definitions, mechanisms, or technical specifications; extremely early stage with multiple typos suggesting rushed drafting.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing zero trust literature (NIST, industry frameworks) and related IETF work (TLS, QUIC, authorization); doesn't clearly differentiate from prior standardization efforts.\",\n \"mo\": 1,\n \"mon\": \"Single revision noted; no evident WG adoption, community discussion, or follow-up activity; appears to be exploratory positioning rather than active development.\",\n \"r\": 2,\n \"rn\": \"Tangentially related to AI agents through mention of 'intelligent agents' but provides no AI-specific content, threat models, or agent-centric use cases; primarily addresses traditional enterprise security.\",\n \"c\": [\n \"Policy/governance\",\n \"Agent identity/auth\",\n \"Data formats/interop\"\n ]\n}\n```", "in_tok": 736, "out_tok": 355}
|
|
|
|
|
{"draft_name": "draft-zeng-opsawg-applicability-mcp-a2a", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft argues NETCONF's limitations in AI-driven network management and proposes MCP and A2A as complementary protocols for semantic translation, cross-domain orchestration, and multi-agent consensus. It provides a gap analysis and coexistence models but lacks detailed protocol specifications or implementation evidence.\",\n \"n\": 2,\n \"nn\": \"Incremental positioning work identifying NETCONF gaps and suggesting existing/emerging protocols (MCP, A2A) as solutions; the core concepts are not novel but the applicability framing to network ops is somewhat useful.\",\n \"m\": 2,\n \"mn\": \"Early-stage problem statement with abstract solutions; lacks detailed protocol definitions, formal semantics, reference implementations, or interoperability examples. Reads as a motivational position paper rather than a specification.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing work: MCP is an external protocol (Anthropic), A2A is underspecified in literature, and agent-based network orchestration frameworks already exist. The draft is primarily a literature positioning rather than novel synthesis.\",\n \"mo\": 1,\n \"mon\": \"Single revision, no evidence of WG adoption or community discussion. The draft appears to be an initial exploratory submission without follow-on development signals or vendor commitment.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to autonomous network operations and agent-to-agent interaction in network management; addresses real operational pain points where traditional config protocols fall short, though execution is immature.\",\n \"c\": [\n \"Autonomous netops\",\n \"A2A protocols\",\n \"Agent identity/auth\",\n \"Data formats/interop\",\n \"Policy/governance\",\n \"Agent discovery/reg\"\n ]\n}\n```", "in_tok": 587, "out_tok": 413}
|
|
|
|
|
{"draft_name": "draft-hood-agtp-agent-cert", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft extends AGTP with X.509 certificate binding for agent identity headers, enabling cryptographic verification of Agent-ID, Principal-ID, and Authority-Scope at the transport layer. It adds session revocation via NOTIFY broadcast and Certificate Transparency logging for governance metadata verification without application-layer access.\",\n \"n\": 2,\n \"nn\": \"Straightforward application of existing PKI patterns (X.509 v3, mutual TLS, CT logs) to agent protocol headers; incremental engineering rather than novel cryptographic or architectural contribution.\",\n \"m\": 4,\n \"mn\": \"Well-scoped specification with defined certificate extension, NOTIFY mechanism, and revocation propagation; appears implementation-ready but lacks test vectors, formal threat model, or reference implementation details.\",\n \"o\": 3,\n \"on\": \"Overlaps with standard mTLS identity binding, PKIX certificate extensions, and CT log concepts; distinguishes itself via AGTP-specific header binding and O(1) verification claim, but not substantially novel compared to similar mutual auth specs.\",\n \"mo\": 2,\n \"mon\": \"Single dated revision (2026-03-23); no evidence of WG adoption, community discussion, or iterative refinement; pending patent claims may signal early-stage thinking or licensing friction.\",\n \"r\": 4,\n \"rn\": \"Directly addresses agent identity authentication and authority enforcement for agent-to-agent protocols; core infrastructure concern for trustworthy multi-agent systems, though framed narrowly around AGTP rather than broader agent ecosystem.\",\n \"c\": [\n \"Agent identity/auth\",\n \"A2A protocols\",\n \"Policy/governance\",\n \"Autonomous netops\"\n ]\n}\n```", "in_tok": 725, "out_tok": 408}
|
|
|
|
|
{"draft_name": "draft-zhang-rtgwg-agent-policy-aware-network", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes an AI Agent Policy-Aware Network paradigm that shifts from flow-aware to agent-aware networking, enabling dynamic mapping between agent intents and network policies. Addresses collaborative scenarios including performance measurement, path optimization, and SLA assurance for AI agent workloads.\",\n \"n\": 3,\n \"nn\": \"Incremental extension of intent-based networking concepts to AI agents; applies existing policy and QoS frameworks to emerging agent coordination needs rather than introducing fundamentally new mechanisms.\",\n \"m\": 2,\n \"mn\": \"Early-stage use case document lacking protocol specifications, architectural details, or implementation examples; provides conceptual framework but no concrete mechanisms, data models, or interface definitions.\",\n \"o\": 3,\n \"on\": \"Shares foundational concepts with intent-based networking (IBN), network policy frameworks, and AI orchestration work; overlaps with existing multi-domain orchestration and agent management literature without clearly differentiating contributions.\",\n \"mo\": 2,\n \"mon\": \"Single revision dated 2026; no apparent WG sponsorship or prior related submissions; limited evidence of community discussion or iterative development.\",\n \"r\": 4,\n \"rn\": \"Directly addresses emerging AI agent networking challenges and collaboration scenarios; timely for growing agent deployments but scoped to networking aspects rather than core agent capabilities.\",\n \"c\": [\n \"Policy/governance\",\n \"A2A protocols\",\n \"Autonomous netops\",\n \"ML traffic mgmt\",\n \"Agent discovery/reg\",\n \"Data formats/interop\"\n ]\n}\n```", "in_tok": 643, "out_tok": 375}
|
|
|
|
|
{"draft_name": "draft-li-cats-intellinode-network-scheduling", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"IntelliNode proposes in-network intelligent scheduling for AI training/inference by integrating FPGAs with programmable switches to enable real-time tensor-aware path selection and compute matching. It extends the CATS framework with a closed-loop perception-inference-decision-execution architecture that bypasses traditional controller-based scheduling.\",\n \"n\": 4,\n \"nn\": \"Genuinely novel approach combining in-network computing (FPGA+ASIC) with lightweight ML models for closed-loop network scheduling; tensor semantics awareness in data plane is non-obvious contribution beyond standard CATS extensions.\",\n \"m\": 2,\n \"mn\": \"Early sketch phase: abstract describes vision and four functional layers but lacks protocol details, message formats, or implementation specifics; 6 pages insufficient for actionable specification.\",\n \"o\": 3,\n \"on\": \"Shares foundational concepts with CATS and in-network computing proposals (INT, P4 analytics); tensor-aware scheduling overlaps with ongoing ML systems networking work; closed-loop architecture not entirely novel but application here is differentiated.\",\n \"mo\": 1,\n \"mon\": \"Single submission (2026-03-02); no evidence of WG adoption, prior versions, or community feedback; no implementation or deployment signals visible.\",\n \"r\": 5,\n \"rn\": \"Directly addresses core AI infrastructure challenge: distributed training/inference scheduling and resource utilization; tensor semantics and heterogeneous compute awareness are essential for next-gen AI systems.\",\n \"c\": [\n \"ML traffic mgmt\",\n \"Model serving/inference\",\n \"Autonomous netops\",\n \"Data formats/interop\"\n ]\n}\n```", "in_tok": 736, "out_tok": 397}
|
|
|
|
|
{"draft_name": "draft-sandowicz-httpbis-httpa2", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"HTTPA/2 proposes an HTTP extension enabling trusted communication through Trusted Execution Environments (TEEs) and remote attestation, designed to operate independently of TLS. The protocol treats TEE services as Internet resources, allowing clients to verify the trustworthiness of server environments and protected functions.\",\n \"n\": 2,\n \"nn\": \"Incremental extension combining existing concepts (HTTP, TEE attestation, remote attestation) without fundamental innovation in the core mechanisms themselves.\",\n \"m\": 2,\n \"mn\": \"Early-stage draft with conceptual definitions but lacking detailed protocol specifications, message formats, cryptographic procedures, and implementation guidance necessary for protocol maturity.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing TEE attestation frameworks (Intel SGX attestation, ARM CCA), remote attestation standards, and HTTP extension mechanisms; limited differentiation from prior HTTPA/1 work.\",\n \"mo\": 1,\n \"mon\": \"Single revision as of 2024-05-07 with no apparent subsequent updates, limited evidence of WG adoption, community discussion, or implementation activity.\",\n \"r\": 2,\n \"rn\": \"Tangentially related to AI agent topics; attestation and TEE security are relevant infrastructure for agent trust/authentication but not core to AI agent protocols, training, or deployment.\",\n \"c\": [\n \"Agent identity/auth\",\n \"Policy/governance\",\n \"Other AI/agent\"\n ]\n}\n```", "in_tok": 715, "out_tok": 354}
|
|
|
|
|
{"draft_name": "draft-han-ai-agent-impact-infra", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Early-stage draft examining how AI agents impact network infrastructure and proposing standardization discussions within IETF. Limited technical depth with focus on problem space rather than concrete solutions or protocols.\",\n \"n\": 2,\n \"nn\": \"Incremental topic framing; AI impact on networks is recognized but the draft lacks novel technical insights or proposed mechanisms beyond general problem discussion.\",\n \"m\": 1,\n \"mn\": \"Problem statement phase only; no defined protocols, mechanisms, or specifications presented. Abstract indicates discussion/analysis intent without concrete technical proposals.\",\n \"o\": 3,\n \"on\": \"Shares conceptual overlap with existing work on network management, ML traffic patterns, and infrastructure impacts; not a unique technical approach but framing of known challenges.\",\n \"mo\": 2,\n \"mon\": \"Appears to be early draft (Jan 2026) with limited revision history visible. Single submission suggests nascent development without established working group momentum.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to AI agents; focuses on infrastructure impact rather than core agent communication, autonomy, or interoperability protocols. Tangential to mainstream agent standardization topics.\",\n \"c\": [\"Autonomous netops\", \"Policy/governance\", \"ML traffic mgmt\", \"Other AI/agent\"]\n}\n```", "in_tok": 484, "out_tok": 306}
|
|
|
|
|
{"draft_name": "draft-bates-atp", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"ATP proposes a DAG-based protocol for creating cryptographically verifiable transaction records across agent systems, enabling tamper-evident causality and auditable lineage. The design emphasizes lightweight, transport-agnostic accountability suitable for environments requiring provenance tracking.\",\n \"n\": 2,\n \"nn\": \"DAG-based transaction logging with cryptographic verification is an incremental combination of established patterns (merkle DAGs, signed transactions, audit logs). Core concepts exist in blockchain/IPFS/git; application to agent systems is derivative.\",\n \"m\": 3,\n \"mn\": \"Protocol mechanics are defined with clear abstractions (signed nodes, parent references, DAG structure), but draft lacks implementation details, serialization formats, concrete test vectors, or reference implementations needed for interoperability validation.\",\n \"o\": 4,\n \"on\": \"Significant overlap with W3C Verifiable Credentials (signed claims), COSE (cryptographic object signing), git commit DAGs, and blockchain audit trails. The agent-specific framing is novel but underlying primitives are well-trodden.\",\n \"m\": 1,\n \"mon\": \"Single revision with May 2026 date suggests early-stage draft. No evidence of WG discussion, adoption signals, or competing proposals in related venues (IETF agent extensions, W3C agent track).\",\n \"r\": 3,\n \"rn\": \"Partially relevant to AI agent infrastructure (accountability, multi-agent coordination auditing). However, framed as generic transaction protocol rather than agent-specific; missing agent-relevant scenarios (policy compliance, capability delegation, LLM output attribution).\",\n \"c\": [\"A2A protocols\", \"Agent identity/auth\", \"Data formats/interop\", \"Policy/governance\", \"Autonomous netops\"]\n}\n```", "in_tok": 555, "out_tok": 420}
|
|
|
|
|
{"draft_name": "draft-gaikwad-llm-benchmarking-terminology", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft establishes standardized terminology for benchmarking LLM inference serving systems, defining shared vocabulary for latency, throughput, resource utilization, and quality metrics across inference engines and agentic systems. It provides definitional groundwork without prescribing specific methodologies or thresholds.\",\n \"n\": 2,\n \"nn\": \"Terminology standardization is incremental; while useful, similar efforts exist in ML/systems communities (MLPerf, etc.). The focus on LLM-specific agentic serving contexts adds modest specificity.\",\n \"m\": 4,\n \"mn\": \"Well-structured terminology document with 54 pages suggesting comprehensive definitions, examples, and organized sections. Lacks implementation artifacts but maturity appropriate for a standards terminology draft.\",\n \"o\": 4,\n \"on\": \"Significant overlap with MLPerf benchmarking taxonomy, existing inference serving metrics (vLLM, TensorRT), and general systems performance terminology. Limited differentiation from prior ML performance standardization efforts.\",\n \"mo\": 2,\n \"mon\": \"Single dated revision (2026-01-20); no evidence of WG adoption, multiple iterations, or community engagement. Appears to be initial individual submission with minimal momentum.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to model serving/inference infrastructure, which is foundational for AI agents. Moderately relevant to broader agent deployments requiring performance characterization across system layers.\",\n \"c\": [\n \"Model serving/inference\",\n \"Data formats/interop\",\n \"ML traffic mgmt\",\n \"Autonomous netops\"\n ]\n}\n```", "in_tok": 546, "out_tok": 384}
|
|
|
|
|
{"draft_name": "draft-hong-nmrg-ai-deploy", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft examines network and system design considerations for deploying AI inference services across distributed architectures, including cloud-edge hybrid deployments and use cases like autonomous vehicles and digital twins.\",\n \"n\": 2,\n \"nn\": \"Incremental compilation of known deployment patterns; lacks novel architectural or networking insights specific to AI workloads\",\n \"m\": 2,\n \"mn\": \"Early-stage position paper without defined mechanisms, protocols, or technical specifications; reads as exploratory requirements document rather than actionable guidance\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing IETF work on edge computing (MEC), distributed ML inference, and network slicing; limited differentiation from parallel standardization efforts\",\n \"mo\": 1,\n \"mon\": \"Single revision with no evidence of WG adoption or iterative refinement; appears to be exploratory submission without sustained community engagement\",\n \"r\": 3,\n \"rn\": \"Partially relevant to AI deployment but lacks focus on agent-specific concerns; addresses ML inference infrastructure rather than autonomous agent orchestration or decision-making\",\n \"c\": [\n \"ML traffic mgmt\",\n \"Model serving/inference\",\n \"Autonomous netops\"\n ]\n}\n```", "in_tok": 606, "out_tok": 298}
|
|
|
|
|
{"draft_name": "draft-hood-independent-agis", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"AGIS proposes a grammar-constrained interface definition language for LLM-based agents that uses intent-expressing imperative verbs as method identifiers, enabling agents to infer operational meaning without predefined catalogs. It serves as the native interface layer for the Agent Transfer Protocol (AGTP) and claims empirical validation showing 10-29 percentage point accuracy advantages over generic HTTP verbs.\",\n \"n\": 3,\n \"nn\": \"Incremental contribution leveraging known concepts (grammar constraints, semantic method naming, intent inference) in a novel combination for agent APIs; the core insight about naming conventions improving LLM comprehension is useful but not groundbreaking.\",\n \"m\": 4,\n \"mn\": \"Well-structured specification with normative serialization formats (YAML/JSON), semantic declaration enhancements, and HTTP bridging. Appears implementation-ready but abstract and draft status suggests incomplete validation; test vectors not mentioned.\",\n \"o\": 3,\n \"on\": \"Shares conceptual overlap with OpenAPI/AsyncAPI for interface definition, JSON Schema for data contracts, and general intent-based API design patterns; positioned as complementary rather than replacement but occupies similar design space.\",\n \"mo\": 2,\n \"mon\": \"Single draft dated 2026-04-17 with no revision history visible; referenced empirical work [HOOD2026] suggests author investment but no indication of WG adoption, multiple implementations, or community feedback cycles.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI agent standardization; addresses real problem of agent-API interaction efficiency. Relevance diminished slightly by narrow focus on LLM comprehension metrics rather than broader agent autonomy/safety considerations.\",\n \"c\": [\n \"A2A protocols\",\n \"Data formats/interop\",\n \"Agent discovery/reg\",\n \"Model serving/inference\"\n ]\n}\n```", "in_tok": 899, "out_tok": 443}
|
|
|
|
|
{"draft_name": "draft-jain-lisp-network-ai-infra", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes using LISP's control plane mechanisms to manage AI infrastructure networking, enabling unified handling of scale-up, scale-out, and scale-across backend networks. Leverages LISP's EID-to-RLOC mapping and VPN segmentation to provide scalable bandwidth, low-latency collective operations, and simplified control across heterogeneous accelerator fabrics for AI/ML workloads.\",\n \"n\": 2,\n \"nn\": \"Incremental application of existing LISP mechanisms to AI infrastructure; combines known LISP features (mapping, segmentation, multi-site) without introducing novel networking primitives or fundamentally new approaches to AI-specific network challenges.\",\n \"m\": 2,\n \"mn\": \"Early sketch stage; abstract describes vision and references existing RFCs but provides minimal detail on architecture, deployment specifics, protocol modifications, or validation. No indication of implementation status or test results in the 23-page document preview.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing LISP deployments and datacenter network designs; the concepts of multi-site LISP, VPN segmentation, and control plane separation are well-established. Similar problems addressed by other fabric approaches (e.g., RoCE, InfiniBand overlays).\",\n \"m\": 1,\n \"mon\": \"Limited momentum indicators visible; appears to be early-stage submission with no apparent WG adoption, follow-up revisions, or community discussion signals based on metadata.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to AI infrastructure but focuses on networking layer rather than AI agents, safety, model serving, or autonomous operations. Addresses ML traffic management and infrastructure concerns tangentially.\",\n \"c\": [\n \"ML traffic mgmt\",\n \"Data formats/interop\",\n \"Other AI/agent\"\n ]\n}\n```", "in_tok": 710, "out_tok": 440}
|
|
|
|
|
{"draft_name": "draft-drake-email-tpm-attestation", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes using TPM-based hardware attestation in email headers to verify sender legitimacy and prevent spam, with both direct CA verification and privacy-preserving SD-JWT variants. Aims to make large-scale spam economically infeasible by requiring unique physical security chips per sender.\",\n \"n\": 2,\n \"nn\": \"Incremental combination of existing technologies (TPM attestation, CMS, SD-JWT) applied to email; the core insight of binding email to hardware is straightforward, though the specific header encoding is new.\",\n \"m\": 3,\n \"mn\": \"Protocol mechanism is reasonably well-specified with attestation formats defined, but lacks implementation details, test vectors, deployment considerations, and empirical validation of spam reduction claims.\",\n \"o\": 4,\n \"on\": \"Significant overlap with DKIM/DMARC/ARC email authentication efforts, existing TPM attestation standards (TCG), and remote attestation RFCs; the novelty is primarily in combining these for email rather than developing new primitives.\",\n \"mo\": 1,\n \"mon\": \"Single draft publication (2026-02-20), no evidence of WG discussion, community adoption, or multiple revisions; no apparent momentum in IETF processes or operational deployment interest.\",\n \"r\": 2,\n \"rn\": \"Tangentially related to AI agents; while Sybil-resistance could theoretically help with AI-generated spam detection, the draft is fundamentally about email authentication and does not address agent behavior, coordination, or safety concerns.\",\n \"c\": [\n \"Agent identity/auth\",\n \"Data formats/interop\",\n \"Policy/governance\"\n ]\n}\n```", "in_tok": 731, "out_tok": 400}
|
|
|
|
|
{"draft_name": "draft-hillier-certisyn-ai-governance-verified", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes a cryptographic verification standard (VRO) for attesting agentic AI governance compliance in regulated industries across eight control areas and three maturity levels. Aims to provide deterministic, auditor-grade attestations that bridge the gap between existing frameworks like ISO/IEC 42001 and NIST AI RMF.\",\n \"n\": 2,\n \"nn\": \"Combines existing governance frameworks with cryptographic attestation mechanics; the core concept of verified governance artifacts is incremental rather than conceptually novel.\",\n \"m\": 2,\n \"mn\": \"Abstract describes objectives and high-level architecture (VRO, issuing-partner framework, control areas) but 13 pages likely insufficient for detailed protocol specification, cryptographic primitives, or implementation guidance.\",\n \"o\": 4,\n \"on\": \"Significant overlap with ISO/IEC 42001, NIST AI RMF, and audit/compliance frameworks; adds cryptographic layer but positioning as 'beneath' existing standards suggests derivative rather than novel approach.\",\n \"mo\": 1,\n \"mon\": \"Single draft dated 2026-05-15 with no evidence of WG traction, revisions, or community discussion; appears to be initial submission without momentum indicators.\",\n \"r\": 4,\n \"rn\": \"Directly addresses AI governance and agent compliance verification in regulated contexts; highly relevant to policy/governance and agent identity/auth domains.\",\n \"c\": [\n \"Policy/governance\",\n \"Agent identity/auth\",\n \"Data formats/interop\",\n \"AI safety/alignment\"\n ]\n}\n```", "in_tok": 651, "out_tok": 381}
|
|
|
|
|
{"draft_name": "draft-chen-tsvwg-high-speed-data-express", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes a high-elasticity data express architecture for IP networks to support massive wide-area data transmission for AI and supercomputing workloads, implementing a 'one low and three high' technical system for differentiated services.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution combining existing IP network concepts (statistical multiplexing, elasticity) with data express service framing; lacks specific technical novelty in mechanisms or protocols.\",\n \"m\": 2,\n \"mn\": \"Early sketch stage with reference architecture proposal but minimal technical depth; no detailed protocol specifications, implementation details, or validation presented in 7 pages.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing work on software-defined networking, network slicing, traffic engineering, and quality-of-service frameworks; conceptually similar to established data center networking solutions.\",\n \"mo\": 1,\n \"mon\": \"Single submission with no apparent WG discussion, revisions, or community engagement; appears to be initial draft without adoption signals.\",\n \"r\": 2,\n \"rn\": \"Tangentially related to AI infrastructure needs but focuses on network transport layer rather than agent-specific protocols, behaviors, or coordination mechanisms; AI is motivation rather than core subject.\",\n \"c\": [\n \"ML traffic mgmt\",\n \"Data formats/interop\",\n \"Policy/governance\"\n ]\n}\n```", "in_tok": 576, "out_tok": 331}
|
|
|
|
|
{"draft_name": "draft-mallick-muacp", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"\u00b5ACP is a lightweight messaging protocol designed for autonomous agents on resource-constrained IoT/Edge devices, featuring deterministic memory bounds, fixed headers, and mandatory OSCORE security. It targets finite-state coordination patterns while guaranteeing bounded resource consumption on Class 1-2 devices.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution combining established patterns (TLV extensibility, fixed headers, OSCORE binding) without significant novelty; resource-constrained protocol design is well-trodden ground.\",\n \"m\": 4,\n \"mn\": \"Well-specified protocol with detailed message types, header format, and security requirements; appears implementation-ready but lacks test vectors, interop examples, or reference implementations.\",\n \"o\": 4,\n \"on\": \"Significant overlap with CoAP (fixed headers, TLV, OSCORE), MQTT-SN (lightweight messaging), and other constrained-device protocols; positioning relative to existing standards unclear.\",\n \"m\": 2,\n \"mon\": \"Single draft revision (2026-01-17), no evidence of WG adoption, community discussion, or implementation feedback; appears early-stage despite mature specification.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to agent communication but not specifically about AI agent behavior, safety, or intelligence; focuses on transport layer rather than agent semantics or coordination logic.\",\n \"c\": [\"A2A protocols\", \"Data formats/interop\", \"Agent identity/auth\"]\n}\n```", "in_tok": 634, "out_tok": 356}
|
|
|
|
|
{"draft_name": "draft-baysal-asimov-safety-architecture", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes a hierarchical dual-gate safety framework for autonomous AI agents combining deterministic pattern matching with a context-free LLM judge to prevent adversarial manipulation. Addresses the core problem that single LLMs cannot reliably enforce their own safety rules under pressure through architectural separation of reasoning and judging functions.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution combining existing safety concepts (denylists, LLM judges, layered architecture). The separation of judge from agent reasoning is sensible but not fundamentally novel; similar isolation principles appear in prior safety literature.\",\n \"m\": 3,\n \"mn\": \"Defined protocol with component specifications and conflict resolution rules, but lacks implementation examples, test vectors, and validation methodology. Appears protocol-ready for specification but not yet implementation-ready.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing AI safety literature on model jailbreak prevention, constitutional AI judges, and defense-in-depth architectures. The dual-gate concept echoes prior work on cascade filtering and constitutional filtering approaches.\",\n \"mo\": 1,\n \"mon\": \"No evidence of community adoption, WG discussion, or follow-up revisions. Single draft with future publication date suggests nascent stage with minimal momentum in the IETF ecosystem.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI agent safety and autonomous systems, though framed as IETF-style specification rather than pure research. Addresses real concerns in deployed agent systems but positioned as protocol rather than architectural guidance.\",\n \"c\": [\n \"AI safety/alignment\",\n \"Autonomous netops\",\n \"Policy/governance\",\n \"Human-agent interaction\"\n ]\n}\n```", "in_tok": 656, "out_tok": 405}
|
|
|
|
|
{"draft_name": "draft-zlgsgl-rtgwg-agents-networking-framework", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes a networking framework for agent systems in enterprise and broadband environments, defining core components and interactions. Addresses the infrastructure requirements for autonomous agents operating in networked settings.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution; applies existing networking concepts to agent systems without introducing fundamentally novel architectural patterns or protocols.\",\n \"m\": 2,\n \"mn\": \"Early-stage framework document; lacks concrete protocol specifications, implementation details, or technical depth beyond component definitions.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing SDN/service mesh architectures, IoT frameworks, and autonomous system management literature; limited differentiation from prior work.\",\n \"mo\": 1,\n \"mon\": \"Limited revision history and no evident WG sponsorship or community adoption signals; appears as exploratory draft without sustained development trajectory.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to agent networking but focuses on infrastructure plumbing rather than AI agent autonomy, decision-making, or intelligence aspects; more networking operations than AI-centric.\",\n \"c\": [\n \"Autonomous netops\",\n \"Data formats/interop\",\n \"Agent discovery/reg\",\n \"Other AI/agent\"\n ]\n}\n```", "in_tok": 487, "out_tok": 301}
|
|
|
|
|
{"draft_name": "draft-yang-ioa-protocol", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes IoA Protocol for distributed heterogeneous agent collaboration with layered architecture and extensible messaging. Targets 6G scenarios including intelligent transportation and human-AI teaming with support for dynamic team formation and adaptive task coordination.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution combining existing agent communication patterns; lacks technical differentiation from FIPA, ROS, or emerging multi-agent frameworks.\",\n \"m\": 2,\n \"mn\": \"Early sketch stage; abstract describes vision but 13 pages insufficient for protocol specification detail, message formats, or implementation guidance.\",\n \"o\": 4,\n \"on\": \"Significant conceptual overlap with FIPA agent protocols, ROS communication layers, and recent multi-agent LLM frameworks (AutoGPT, CrewAI architectures); positioning unclear.\",\n \"mo\": 1,\n \"mon\": \"Single draft submission with 2025 date; no evident working group engagement, revisions, or community discussion activity detected.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to agent collaboration and interoperability; strong fit for emerging AI/agent systems but lacks implementation evidence or standards adoption pathway.\",\n \"c\": [\n \"A2A protocols\",\n \"Data formats/interop\",\n \"Agent discovery/reg\",\n \"Human-agent interaction\",\n \"Autonomous netops\"\n ]\n}\n```", "in_tok": 596, "out_tok": 335}
|
|
|
|
|
{"draft_name": "draft-drake-agent-identity-registry", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes a federated registry architecture for issuing persistent, hardware-anchored identities to autonomous entities (AI agents, robots) using a three-tier governance model modeled on DNS, with identity expressed as URNs and anchored to TPMs/secure enclaves to provide Sybil resistance.\",\n \"n\": 3,\n \"nn\": \"Applies established DNS/PKI patterns to a new domain (autonomous entities) with hardware attestation anchoring; the core concepts are not novel but the specific application to agent identity is timely and useful.\",\n \"m\": 3,\n \"mn\": \"Defines protocol architecture and integration points (OIDC/OAuth2 tokens, URN namespace) but lacks implementation details, test vectors, and concrete attestation verification procedures; appears early-to-mid stage specification.\",\n \"o\": 3,\n \"on\": \"Shares significant concepts with W3C DID/verifiable credentials work, TPM-based attestation (TCG), and OIDC/OAuth2 standards; overlaps with existing agent authentication proposals but frames around hardware anchoring.\",\n \"mo\": 2,\n \"mon\": \"Single draft revision (2026-04-29 date suggests recent submission); no evidence of WG adoption, prior discussion, or multiple iterations; appears to be initial proposal stage.\",\n \"r\": 5,\n \"rn\": \"Directly addresses core authentication and identity challenges for autonomous AI agents; Sybil resistance and hardware-anchored trust are critical for agent ecosystems; high relevance to agent interoperability and security.\",\n \"c\": [\"Agent identity/auth\", \"Agent discovery/reg\", \"Policy/governance\", \"A2A protocols\", \"Data formats/interop\"]\n}\n```", "in_tok": 897, "out_tok": 407}
|
|
|
|
|
{"draft_name": "draft-yusef-lamps-rfc7030-renewal-recommendation", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft proposes an extension to RFC 7030 (EST) that allows servers to signal recommended certificate renewal timing to clients, addressing the problem that traditional 50% lifetime renewal triggers are increasingly inappropriate for short-lived certificates.\",\n \"n\": 2,\n \"nn\": \"Incremental extension adding a timing recommendation field to existing EST protocol; solves a real operational problem but limited technical novelty.\",\n \"m\": 3,\n \"mn\": \"Provides defined protocol mechanism with clear problem statement and solution approach, though lacks implementation details, test vectors, and detailed encoding specifications typical of mature specs.\",\n \"o\": 2,\n \"on\": \"Minor overlap with existing certificate lifecycle management practices; builds directly on RFC 7030 without significant conceptual similarities to other IETF work.\",\n \"mo\": 2,\n \"mon\": \"Single revision with modest draft activity; appears to address practical EST deployment needs but shows limited evidence of working group engagement or community momentum.\",\n \"r\": 1,\n \"rn\": \"Not relevant to AI agents or autonomous systems; focused on traditional PKI certificate management and enrollment protocols with no AI/ML components.\",\n \"c\": [\"Agent identity/auth\"]\n}\n```", "in_tok": 575, "out_tok": 284}
|
|
|
|
|
{"draft_name": "draft-ietf-dnsop-ns-revalidation", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft proposes that DNS resolvers should query and cache NS records directly from child zones rather than relying on parent-side delegations, with periodic revalidation to ensure delegation freshness. The approach aims to improve resolver robustness by preferring authoritative NS information and properly managing glue record trustworthiness.\",\n \"n\": 2,\n \"nn\": \"Incremental improvement to DNS resolution practices; requerying child NS RRsets is a logical refinement but not architecturally novel.\",\n \"m\": 4,\n \"mn\": \"Well-defined protocol mechanism with clear algorithm description, TTL management rules, and caching strategies; lacks implementation guidance and test vectors for full readiness.\",\n \"o\": 2,\n \"on\": \"Minor similarities to existing NS handling practices (RFC 1034); mostly codifies and formalizes recommended behavior rather than duplicating prior work.\",\n \"mo\": 3,\n \"mon\": \"Active WG development with recent revision date (2026-01); appears in DNSOP working group with meaningful engagement but not yet strong community consensus.\",\n \"r\": 1,\n \"rn\": \"Not relevant to AI agents, autonomous systems, or AI-related networking; pure DNS operational protocol improvement for resolver behavior.\",\n \"c\": [\n \"Other AI/agent\"\n ]\n}\n```", "in_tok": 685, "out_tok": 317}
|
|
|
|
|
{"draft_name": "draft-zhang-rvp-problem-statement", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"RVP proposes a unified protocol for coordinating physical entities (robots, IoT, manufacturing systems) with digital agents (AI systems, virtual twins) using composite identity management and relation graphs. The protocol aims to address gaps in existing peer-to-peer agent protocols by incorporating physical constraints and hierarchical coordination for embodied intelligence networks.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution combining existing concepts (agent coordination, digital twins, identity management) without clearly differentiated technical innovation beyond framing\",\n \"m\": 1,\n \"mn\": \"Problem statement document lacking protocol specification, formal definitions, message formats, or implementation details; purely aspirational scope without technical substance\",\n \"o\": 4,\n \"on\": \"Significant overlap with MCP (Model Context Protocol), ANP (Agent Network Protocol), digital twin standards (ISO), and IoT/manufacturing protocols; positioning against these is unclear and under-differentiated\",\n \"mo\": 1,\n \"mon\": \"Single draft submission with no visible community engagement, WG discussion, or iterative development; unclear author affiliation or stakeholder backing\",\n \"r\": 3,\n \"rn\": \"Partially relevant to agent communication and embodied AI, but framed as infrastructure protocol rather than core agent capability; manufacturing/IoT focus dilutes AI agent relevance\",\n \"c\": [\n \"A2A protocols\",\n \"Agent identity/auth\",\n \"Data formats/interop\",\n \"Agent discovery/reg\",\n \"Autonomous netops\"\n ]\n}\n```", "in_tok": 678, "out_tok": 363}
|
|
|
|
|
{"draft_name": "draft-chen-ai-agent-auth-new-requirements", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft identifies authentication and authorization gaps in existing frameworks when applied to autonomous AI agents, arguing that dynamic behavior management is needed rather than static identity verification. It articulates why traditional human-centric security models fail for agent-to-agent interactions and delegation chains.\",\n \"n\": 4,\n \"nn\": \"Reframing auth/authz around dynamic behavior rather than static identity is a genuinely novel perspective for IETF, though the core problem is emerging industry-wide.\",\n \"m\": 1,\n \"mn\": \"Pure requirements document with no protocol proposal, mechanism design, or concrete technical solutions; reads as problem articulation only.\",\n \"o\": 2,\n \"on\": \"Overlaps conceptually with OAuth2/OIDC delegation and emerging work on service-to-service auth, but applies unique lens of agent autonomy; minor similarity to existing identity frameworks.\",\n \"mo\": 2,\n \"mon\": \"New draft (Jan 2026) with single revision; no visible WG adoption or community adoption signals yet; preliminary stage.\",\n \"r\": 5,\n \"rn\": \"Directly addresses core AI agent operational challenge; authentication and authorization are foundational for safe agent deployment; highly timely and relevant to IETF scope.\",\n \"c\": [\n \"Agent identity/auth\",\n \"Policy/governance\",\n \"Autonomous netops\",\n \"AI safety/alignment\"\n ]\n}\n```", "in_tok": 557, "out_tok": 340}
|
|
|
|
|
{"draft_name": "draft-dhir-http-agent-profile", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"HAP proposes an HTTP profile for authenticated agent traffic using cryptographic signatures, privacy-preserving human tokens, and protocol-level micropayments via HTTP 402. It aims to address economic misalignment between AI agents and content providers while enabling incremental deployment.\",\n \"n\": 3,\n \"nn\": \"Combines existing HTTP mechanisms (Message Signatures, 402 status) in a new application context for agent traffic; framing is novel but individual components are established.\",\n \"m\": 2,\n \"mn\": \"Early-stage draft with conceptual design; lacks implementation details, test vectors, interoperability examples, and clarity on micropayment mechanism integration.\",\n \"o\": 3,\n \"on\": \"Related work exists on bot authentication (RFC 8555, HTTP Message Signatures), value exchange (402 status), and agent identification; positions as integrative rather than pioneering.\",\n \"mo\": 2,\n \"mon\": \"Single revision (2025-11), no apparent WG adoption or community discussion signals; addresses timely problem but lacks collaborative momentum.\",\n \"r\": 5,\n \"rn\": \"Directly addresses autonomous agent authentication, traffic differentiation, and economic incentive alignment\u2014core concerns for AI agent integration into web infrastructure.\",\n \"c\": [\"Agent identity/auth\", \"A2A protocols\", \"ML traffic mgmt\", \"Policy/governance\", \"Human-agent interaction\"]\n}\n```", "in_tok": 686, "out_tok": 332}
|
|
|
|
|
{"draft_name": "draft-song-oauth-ai-agent-collaborate-authz", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes OAuth 2.0 extensions enabling coordinated authorization for multi-agent AI systems where a lead agent delegates tasks to sub-agents. Simplifies the auth flow by reducing repeated server interactions while maintaining backward compatibility with standard OAuth 2.0.\",\n \"n\": 2,\n \"nn\": \"Incremental extension applying existing OAuth patterns to multi-agent scenarios; lacks architectural innovation beyond token/message field additions.\",\n \"m\": 2,\n \"mn\": \"Early sketch with abstract concepts; 13 pages insufficient for detailed protocol specification, missing flow diagrams, token format definitions, example exchanges, or security analysis.\",\n \"o\": 4,\n \"on\": \"Significant overlap with delegation/impersonation patterns in OAuth 2.0 (token exchange grant RFC 8693), UMA 2.0 resource authorization, and emerging agent-to-agent auth work; positioning versus existing standards unclear.\",\n \"mo\": 1,\n \"mon\": \"Single undated revision (2026-03-02 appears future-dated); no evidence of WG discussion, community feedback, or iterative development; appears exploratory rather than actively pursued.\",\n \"r\": 4,\n \"rn\": \"Directly addresses agent authorization challenges, but frames narrowly around OAuth extension rather than broader agent identity/trust architecture; relevant to emerging agent coordination patterns.\",\n \"c\": [\"Agent identity/auth\", \"A2A protocols\", \"Policy/governance\"]\n}\n```", "in_tok": 577, "out_tok": 342}
|
|
|
|
|
{"draft_name": "draft-yu-dmsc-ai-agent-use-cases-in-6g", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft documents AI Agent use cases and operational requirements for 6G networks, drawing primarily from 3GPP's existing TR 22.870 study. It presents operator perspectives on integrating AI agents into 6G infrastructure without introducing novel technical mechanisms.\",\n \"n\": 2,\n \"nn\": \"Incremental compilation of existing 3GPP work; references established standards rather than proposing new approaches to AI agent integration.\",\n \"m\": 2,\n \"mn\": \"Early-stage requirements document without protocol specifications, detailed mechanisms, or implementation guidance; serves as a use case compilation.\",\n \"o\": 4,\n \"on\": \"Significant overlap with 3GPP TR 22.870 source material; limited independent analysis or original requirements derivation beyond operator perspective framing.\",\n \"mo\": 1,\n \"mon\": \"Single revision with no evidence of active development cycle, WG discussion, or community engagement; appears to be initial submission without follow-up.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI agents in networks; focuses on 6G-specific use cases and operational requirements despite lack of technical novelty.\",\n \"c\": [\n \"Autonomous netops\",\n \"Policy/governance\",\n \"Agent discovery/reg\",\n \"Other AI/agent\"\n ]\n}\n```", "in_tok": 538, "out_tok": 317}
|
|
|
|
|
{"draft_name": "draft-deforth-arp-reasoning-protocol", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"ARP v2.0 proposes a machine-readable protocol for entities to publish self-attested context, corrections, and boundaries directly to autonomous AI agents and RAG systems, extending v1.x with REST APIs, cryptographic attestation, DIDs, and event-driven freshness. The protocol aims to influence AI agent reasoning behavior beyond traditional web conventions like robots.txt.\",\n \"n\": 2,\n \"nn\": \"Incremental extension of existing v1.x model; combines established technologies (REST, DIDs, SSE, cryptographic signatures) without fundamental innovation in agent control or reasoning protocol design.\",\n \"m\": 3,\n \"mn\": \"Defined protocol with stated mechanisms (REST API, bidirectional feedback, A2A handshakes, SSE), but 29 pages without visible test vectors, reference implementations, or security analysis suggests specification-stage maturity rather than implementation-ready.\",\n \"o\": 4,\n \"on\": \"Significant overlap with robots.txt (agent directives), schema.org (metadata), llms.txt (LLM-specific guidance), and W3C DID specifications; positioning as complementary rather than novel suggests incremental refinement of existing approaches.\",\n \"mo\": 1,\n \"mon\": \"Draft dated 2026-04-28 with no visible adoption signals, WG discussions, or reference implementations; appears to be single-author proposal without demonstrated community traction or ongoing revision cycle.\",\n \"r\": 4,\n \"rn\": \"Directly addresses AI agent control and instruction distribution\u2014a core concern for autonomous systems\u2014though framed more as governance/policy tool than core agent protocol, limiting foundational relevance.\",\n \"c\": [\n \"Policy/governance\",\n \"Agent identity/auth\",\n \"Data formats/interop\",\n \"AI safety/alignment\",\n \"A2A protocols\"\n ]\n}\n```", "in_tok": 741, "out_tok": 441}
|
|
|
|
|
{"draft_name": "draft-li-rtgwg-distributed-lossless-framework", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes a framework for distributed lossless interconnection between multiple data centers to support large-scale distributed AI model training. Addresses networking challenges for connecting data centers into larger compute clusters with focus on efficient, reliable data transmission.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution combining existing data center networking concepts with AI training requirements; lacks novel technical mechanisms or approaches.\",\n \"m\": 2,\n \"mn\": \"Early stage framework document without detailed protocol specifications, implementation details, or comprehensive technical solutions; appears to be preliminary conceptual work.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing DCQCN, RDMA, and multi-datacenter networking standards; framework repackages established concepts without clear differentiation from RFC 9347 and related work.\",\n \"mo\": 1,\n \"mon\": \"Single revision as of April 2025; no evidence of WG adoption, community engagement, or iterative development; appears dormant since publication.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to AI infrastructure but focuses on networking layer rather than AI/agent-specific concerns; addresses supporting systems rather than core AI agent capabilities or governance.\",\n \"c\": [\n \"ML traffic mgmt\",\n \"Model serving/inference\",\n \"Data formats/interop\"\n ]\n}\n```", "in_tok": 581, "out_tok": 321}
|
|
|
|
|
{"draft_name": "draft-miller-ssh-agent", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Formalizes the SSH agent protocol, which manages cryptographic keys for SSH authentication. Documents existing operational practice for key agent communication in SSH contexts.\",\n \"n\": 1,\n \"nn\": \"Describes established SSH agent protocol behavior; no novel cryptographic or architectural contributions, primarily codification of existing implementations.\",\n \"m\": 4,\n \"mn\": \"Well-defined protocol specification with message formats and procedures; includes implementation details though test vectors may be limited.\",\n \"o\": 5,\n \"on\": \"SSH agent protocol is long-established (OpenSSH, PuTTY, etc.); this draft formalizes documented behavior rather than introducing new concepts.\",\n \"mo\": 2,\n \"mon\": \"Single revision observed; appears to be standardization effort but limited evidence of active WG-level momentum or multiple iterations.\",\n \"r\": 1,\n \"rn\": \"SSH agent is a key management protocol, not related to AI agents, autonomous systems, or agent-based AI architectures; entirely false positive for AI/agent rating.\",\n \"c\": [\n \"Agent identity/auth\",\n \"Data formats/interop\"\n ]\n}\n```", "in_tok": 457, "out_tok": 280}
|
|
|
|
|
{"draft_name": "draft-schulze-ecap", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"ECAP proposes a cryptographically-signed protocol to replace robots.txt, enabling web hosts to establish verifiable consent agreements with automated crawlers and AI scrapers. The protocol uses declarative policy handshakes to enforce ethical access controls rather than relying on voluntary compliance.\",\n \"n\": 2,\n \"nn\": \"Incremental advancement combining existing concepts (cryptographic signatures, policy declarations, consent mechanisms) applied to crawler management; robots.txt alternatives have been explored multiple times.\",\n \"m\": 2,\n \"mn\": \"Early sketch with abstract describing goals but minimal protocol detail; no specification of handshake format, signature schemes, policy grammar, or implementation considerations evident in 3-page document.\",\n \"o\": 4,\n \"on\": \"Significant overlap with prior work: robots.txt extensions, HTTP policy frameworks (CORS, CSP), consent protocols, and previous crawler authentication proposals; limited differentiation articulated.\",\n \"mo\": 1,\n \"mon\": \"Single revision (2025-12-10); no evidence of WG sponsorship, community discussion, or iterative development; appears nascent with minimal adoption signals.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI agent governance and ethical constraints on automated data collection; addresses timely concern of web scraping for LLM training but positioned as general crawler protocol.\",\n \"c\": [\n \"A2A protocols\",\n \"Agent identity/auth\",\n \"Policy/governance\",\n \"Data formats/interop\"\n ]\n}\n```", "in_tok": 534, "out_tok": 362}
|
|
|
|
|
{"draft_name": "draft-morrow-sogomonian-exec-outcome-attest", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes execution outcome attestation as a distinct concept from identity verification, enabling independent verification of claimed actions and outcomes by AI agents through composable primitives like execution receipts mapped to SCITT logs and TEE mechanisms.\",\n \"n\": 4,\n \"nn\": \"Separating execution verification from identity attestation is a notable conceptual contribution; formalizing execution receipts as primitives is original, though building on established attestation frameworks.\",\n \"m\": 2,\n \"mn\": \"Early sketch stage with abstract model and multiple mapping approaches identified, but lacks detailed protocol specifications, concrete syntax definitions, or implementation examples.\",\n \"o\": 3,\n \"on\": \"Shares core concepts with SCITT (transparency logs), TEE attestation, and append-only log frameworks; execution verification itself is somewhat novel but overlaps with existing audit and provenance work.\",\n \"mo\": 1,\n \"mon\": \"Single draft revision dated 2026-04-04 with no apparent WG adoption or community discussion; appears to be new contribution without evident momentum.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI agent trustworthiness and autonomous system verification; addresses real gap in agent accountability but framed for general distributed systems.\",\n \"c\": [\n \"Agent identity/auth\",\n \"Data formats/interop\",\n \"Policy/governance\",\n \"A2A protocols\"\n ]\n}\n```", "in_tok": 597, "out_tok": 338}
|
|
|
|
|
{"draft_name": "draft-mw-spice-actor-chain", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Defines six OAuth 2.0 Token Exchange profiles for preserving and validating delegation chains across multi-hop service-to-service and agentic workflows. Addresses cryptographic accountability and auditability tradeoffs for actor-chain continuity in successive token exchanges.\",\n \"n\": 3,\n \"nn\": \"Incremental profiling of RFC 8693 with structured delegation chain handling; the core concept (nested act claims) exists, but systematic treatment of multi-hop validation scenarios adds useful structure.\",\n \"m\": 4,\n \"mn\": \"Well-specified protocol with six distinct profiles, processing rules, and clear delineation of tradeoffs; 97 pages suggests comprehensive treatment including examples, though implementation maturity unclear.\",\n \"o\": 2,\n \"on\": \"Minor overlap with existing OAuth/OIDC delegation work; distinct from SPIFFE/SPIRE approaches and other service identity schemes through its focus on token exchange profiling.\",\n \"mo\": 2,\n \"mon\": \"Single draft revision (2026-04-25), no visible WG adoption signals or follow-up iterations; unclear if this is initial submission or stalled effort.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to autonomous agent systems requiring provable delegation chains and cross-domain service-to-service auth; core infrastructure for agentic workflows with accountability.\",\n \"c\": [\"A2A protocols\", \"Agent identity/auth\", \"Data formats/interop\", \"Policy/governance\"]\n}\n```", "in_tok": 734, "out_tok": 357}
|
|
|
|
|
{"draft_name": "draft-fu-nmop-agent-communication-framework", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes a multi-agent communication framework for network AIOps with an AI gateway, agent naming service, and security features. Addresses coordination of heterogeneous agents for intelligent network operations and maintenance.\",\n \"n\": 2,\n \"nn\": \"Incremental application of existing multi-agent communication patterns to network operations; lacks novel architectural insights or technical innovations beyond conventional gateway/registry designs.\",\n \"m\": 2,\n \"mn\": \"Early-stage draft with abstract framework description but insufficient protocol specifications, message formats, API definitions, or implementation details; appears conceptual rather than specification-ready.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing SNMP/NETCONF agent frameworks, service mesh communication patterns (Istio, Consul), and conventional API gateway architectures; limited differentiation for AI-specific needs.\",\n \"mo\": 1,\n \"mon\": \"Single revision at 13 pages suggests minimal active development; no evidence of WG adoption, implementation prototypes, or community engagement; appears dormant.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to AI agents and network automation but frames problem generically; missing specificity on how AI/LLM agent requirements differ from traditional distributed systems or why existing frameworks inadequate.\",\n \"c\": [\n \"A2A protocols\",\n \"Autonomous netops\",\n \"Agent discovery/reg\",\n \"Agent identity/auth\",\n \"Data formats/interop\"\n ]\n}\n```", "in_tok": 602, "out_tok": 354}
|
|
|
|
|
{"draft_name": "draft-oauth-ai-agents-on-behalf-of-user", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Extends OAuth 2.0 with requested_actor and actor_token parameters to enable AI agents to obtain access tokens while acting on behalf of users with explicit consent. Introduces dynamic authorization via resource server challenges and maintains delegation chain documentation in access token claims.\",\n \"n\": 2,\n \"nn\": \"Incremental extension applying existing OAuth delegation patterns (similar to device flow, on-behalf-of flows) to AI agents; limited conceptual novelty beyond parameter addition.\",\n \"m\": 3,\n \"mn\": \"Defines protocol mechanism with clear parameters and flow descriptions, but lacks implementation details, test vectors, security analysis depth, and formal examples.\",\n \"o\": 4,\n \"on\": \"Significant conceptual overlap with RFC 8693 (token exchange), Microsoft on-behalf-of flow, and JWT bearer token specs; differentiation for AI agents is primarily semantic.\",\n \"mo\": 1,\n \"mon\": \"Single revision, dated 2026-02-27, no evidence of WG adoption, community discussion, or iterative development; early-stage draft status.\",\n \"r\": 4,\n \"rn\": \"Directly addresses AI agent authorization and delegation concerns; core relevance to agent identity/auth and human-agent interaction, though framing as 'AI agent' extension of standard OAuth may obscure that pattern applies broadly.\",\n \"c\": [\n \"Agent identity/auth\",\n \"A2A protocols\",\n \"Human-agent interaction\",\n \"Policy/governance\"\n ]\n}\n```", "in_tok": 634, "out_tok": 359}
|
|
|
|
|
{"draft_name": "draft-blahaj-grow-rpki-oauth", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes using RPKI (Resource Public Key Infrastructure) to attest identities of parties in OpenID Connect exchanges for the Peering API, binding authentication to ASN-based agents. Addresses authentication gaps in GROW WG's Peering API discussions.\",\n \"n\": 2,\n \"nn\": \"Incremental combination of existing technologies (RPKI + OIDC); straightforward application of established standards to a specific use case without fundamental innovation.\",\n \"m\": 2,\n \"mn\": \"Early sketch stage; abstract describes intent but document is only 7 pages with incomplete discussion section marked for removal; lacks protocol details, examples, or implementation guidance.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing RPKI-based authentication work and standard OIDC identity binding mechanisms; the combination is relatively obvious given established practices in BGP security and federated identity.\",\n \"mo\": 1,\n \"mon\": \"Single draft revision with no visible community engagement; source repository reference is malformed (github.molgen.mpg.de appears non-standard); no evidence of WG discussion or iterative development.\",\n \"r\": 2,\n \"rn\": \"Tangentially related to agent identity/authentication in network contexts, but focused on inter-AS peering operations rather than AI agents; not about autonomous agents or AI systems.\",\n \"c\": [\"Agent identity/auth\", \"Policy/governance\", \"Data formats/interop\"]\n}\n```", "in_tok": 606, "out_tok": 348}
|
|
|
|
|
{"draft_name": "draft-thomson-aipref-sup", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Defines a simple format for content creators to signal preferences about automated content consumption, with conveyance via HTTP headers and updates to RFC 9309. Addresses machine-readable preference signaling for AI systems and automated processors accessing web content.\",\n \"n\": 2,\n \"nn\": \"Incremental extension of existing preference signaling concepts (like robots.txt, user-agent directives); applies established patterns to AI/automation context without fundamentally novel mechanism.\",\n \"m\": 3,\n \"mn\": \"Protocol mechanism is defined with HTTP header field specification and RFC 9309 integration, but lacks implementation examples, test vectors, and deployment guidance needed for full maturity.\",\n \"o\": 4,\n \"on\": \"Significant conceptual overlap with robots.txt, machine-readable metadata standards (dublin core, schema.org), and other preference signaling RFCs; similar space to web crawling directives but for AI systems.\",\n \"mo\": 2,\n \"mon\": \"Limited to single draft revision (2025-08-20); no visible WG adoption signals, community discussion, or iterative development cycle indicators.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI agent governance and content creator control over automated systems; addresses legitimate concern about AI training data usage and content scraping preferences.\",\n \"c\": [\n \"Policy/governance\",\n \"Data formats/interop\",\n \"A2A protocols\",\n \"AI safety/alignment\",\n \"Human-agent interaction\"\n ]\n}\n```", "in_tok": 513, "out_tok": 360}
|
|
|
|
|
{"draft_name": "draft-meunier-webbotauth-registry", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes a JSON-based Signature Agent Card format for web bot authentication, enabling clients to advertise identity, cryptographic keys, and metadata through a directory service with an extensible IANA registry.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution combining existing directory/registry patterns with bot authentication; limited architectural novelty.\",\n \"m\": 3,\n \"mn\": \"Defined protocol mechanism with JSON schema, but lacks implementation examples, test vectors, and integration guidance.\",\n \"o\": 4,\n \"on\": \"Significant overlap with OAuth 2.0 metadata, OpenID Connect discovery, and existing bot authentication frameworks; unclear differentiation.\",\n \"mo\": 1,\n \"mon\": \"Single revision dated 2026 with no apparent WG adoption or community engagement; appears dormant or early-stage.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to agent identity and authentication, a core concern for autonomous systems; practical applicability to agent ecosystems.\",\n \"c\": [\n \"Agent identity/auth\",\n \"Agent discovery/reg\",\n \"Data formats/interop\",\n \"A2A protocols\"\n ]\n}\n```", "in_tok": 558, "out_tok": 288}
|
|
|
|
|
{"draft_name": "draft-illyes-aipref-jafar", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes a JSON schema for automated HTTP clients (crawlers, bots, AI agents) to publicly disclose their IP address ranges, enabling website operators to identify and verify legitimate traffic while reducing false blocks.\",\n \"n\": 2,\n \"nn\": \"Incremental formalization of existing ad-hoc practices; similar to robots.txt or .well-known patterns but applied to IP range disclosure rather than access rules.\",\n \"m\": 3,\n \"mn\": \"Well-defined JSON schema with clear structure, but limited implementation guidance, test vectors, or deployment examples; lacks details on validation, error handling, and client discovery mechanisms.\",\n \"o\": 3,\n \"on\": \"Shares conceptual overlap with reverse DNS lookups, AS number registries, and informal IP range documentation; relates to Agent.json and similar metadata discovery specs.\",\n \"mo\": 2,\n \"mon\": \"Single revision as of September 2025; no visible WG sponsorship or implementation uptake; unclear if addressing real operational pain points at scale.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI agent identification and trust infrastructure; addresses practical needs for legitimate bot traffic verification in web environments.\",\n \"c\": [\"Agent identity/auth\", \"Data formats/interop\", \"Agent discovery/reg\", \"ML traffic mgmt\", \"Policy/governance\"]\n}\n```", "in_tok": 577, "out_tok": 321}
|
|
|
|
|
{"draft_name": "draft-fu-cats-flow-lb", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes a flow-level load balancing mechanism for CATS that distributes traffic autonomously in the data plane, reducing control plane overhead. Aims to improve resource utilization by steering computing-aware traffic more efficiently across available resources.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution applying existing load balancing patterns to CATS domain; the core concept of data plane autonomous distribution is well-established, though its application to computing-aware steering is somewhat novel.\",\n \"m\": 3,\n \"mn\": \"Defines mechanism with reasonable detail but appears to lack comprehensive protocol specification, implementation guidance, or empirical validation data typical of mature specifications.\",\n \"o\": 3,\n \"on\": \"Shares fundamental concepts with existing CATS work and general load balancing literature; builds on established traffic steering patterns but with computing awareness focus.\",\n \"mo\": 2,\n \"mon\": \"Single revision as of Feb 2026; appears to have limited WG discussion or adoption signals; typical IETF draft status without evidence of sustained development momentum.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to autonomous networking and data plane intelligence, but not directly focused on AI agents; relevant to autonomous network operations rather than agent-specific concerns.\",\n \"c\": [\"Autonomous netops\", \"ML traffic mgmt\", \"Data formats/interop\"]\n}\n```", "in_tok": 502, "out_tok": 321}
|
|
|
|
|
{"draft_name": "draft-gaikwad-llm-benchmarking-methodology", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Defines standardized benchmarking methodologies for evaluating LLM inference serving systems across latency, throughput, scheduling, and resource management. Provides test procedures, setup parameters, and reporting formats as a companion to LLM serving terminology documentation.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution adapting existing benchmarking frameworks to LLM-specific metrics; lacks novel measurement approaches or theoretical advances.\",\n \"m\": 4,\n \"mn\": \"Well-structured specification with defined procedures, parameters, and reporting formats; appears implementation-ready though likely needs vendor feedback and real-world validation.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing ML benchmarking work (MLPerf, SPEC), cloud performance benchmarking, and LLM evaluation frameworks; limited differentiation from prior art.\",\n \"mo\": 2,\n \"mon\": \"Single draft revision identified; limited evidence of broad WG adoption or community momentum; appears to be early-stage submission.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI/agent infrastructure; model serving and inference benchmarking are foundational for evaluating agent deployment systems.\",\n \"c\": [\"Model serving/inference\", \"ML traffic mgmt\", \"Data formats/interop\"]\n}\n```", "in_tok": 549, "out_tok": 309}
|
|
|
|
|
{"draft_name": "draft-bernardos-nmrg-agentic-network-optimization", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes using agentic AI to optimize distributed sensing and communication tasks in ISAC networks by dynamically selecting sensing entities, processing locations, and network configurations under time-varying conditions. Addresses the coupled decision space arising from heterogeneous sensors, processing requirements, and synchronization constraints through closed-loop agent-based control.\",\n \"n\": 2,\n \"nn\": \"Incremental combination of existing concepts (ISAC, distributed sensing, AI optimization) without proposing novel agent architectures, algorithms, or mechanisms; largely motivational rather than technical advancement.\",\n \"m\": 1,\n \"mn\": \"Early-stage position paper (14 pages) presenting problem motivation and high-level architectural considerations; lacks protocol specifications, decision algorithms, synchronization mechanisms, or implementation guidance.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing work on ISAC optimization, federated sensing, network slicing, and ML-driven resource allocation; agent framing is applied to established optimization problems without clear differentiation.\",\n \"mo\": 1,\n \"mon\": \"Single initial draft with no revision history evident; no indication of WG adoption, implementation efforts, or community validation; novel area but minimal momentum behind this specific approach.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to AI agents in networking (autonomous configuration), but focuses more on sensing optimization and ISAC than on agent architectures, protocols, or capabilities; agents are treated as an enabler rather than the core topic.\",\n \"c\": [\n \"Autonomous netops\",\n \"ML traffic mgmt\",\n \"Other AI/agent\"\n ]\n}\n```", "in_tok": 822, "out_tok": 383}
|
|
|
|
|
{"draft_name": "draft-zl-agents-networking-scenarios", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft outlines networking scenarios for AI agents in enterprise and home broadband environments, distinguishing them from 6G and Internet contexts. It documents emerging use cases and associated networking requirements for agentic services that are still in early deployment stages.\",\n \"n\": 2,\n \"nn\": \"Incremental documentation of scenarios; lacks technical novelty in networking mechanisms. Primarily descriptive rather than prescriptive, covering reasonably foreseeable applications of existing agent architectures.\",\n \"m\": 1,\n \"mn\": \"Problem statement and scenario description only; no protocol specifications, mechanisms, or implementation details provided. Eight pages suggest high-level overview rather than technical depth.\",\n \"o\": 4,\n \"on\": \"Significant overlap with ongoing 6G, IETF Internet use case, and general AI/ML networking discussions. Scenarios appear derivative of standard multi-agent communication patterns without distinctive differentiation.\",\n \"mo\": 2,\n \"mon\": \"Single revision snapshot (2025-10-20); insufficient evidence of sustained development or working group traction. Limited visibility into adoption or community engagement beyond initial draft submission.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to AI agent networking; focuses on scenarios rather than core agent protocols, infrastructure, or interoperability challenges. More business/use-case focused than technical contribution to agent networking.\",\n \"c\": [\n \"Autonomous netops\",\n \"Agent discovery/reg\",\n \"Other AI/agent\"\n ]\n}\n```", "in_tok": 515, "out_tok": 353}
|
|
|
|
|
{"draft_name": "draft-ietf-lisp-nexagon", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Lisp-Nexagon combines LISP protocol with H3 spatial indexing to create a geospatial intelligence network for distributed agents in transportation, public safety, and logistics. The draft proposes a framework for agents to report and aggregate location-based state information across networks.\",\n \"n\": 2,\n \"nn\": \"Incremental combination of two established technologies (LISP and H3); lacks architectural innovation beyond straightforward integration\",\n \"m\": 2,\n \"mn\": \"Early sketch with abstract concepts; no detailed protocol specification, message formats, or implementation guidance provided in 21 pages\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing geospatial protocols, location services, and LISP-based routing work; H3 integration appears standard rather than novel\",\n \"mo\": 1,\n \"mon\": \"Single draft dated 2025-09-23 with no revision history; no evidence of WG discussion, community adoption, or iterative development\",\n \"r\": 3,\n \"rn\": \"Partially relevant to autonomous networked systems but focused on geolocation reporting rather than AI agent coordination, decision-making, or intelligence paradigms\",\n \"c\": [\"Agent discovery/reg\", \"Data formats/interop\", \"Autonomous netops\"]\n}\n```", "in_tok": 534, "out_tok": 314}
|
|
|
|
|
{"draft_name": "draft-scim-agent-extension", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes a SCIM 2.0 extension to represent agents and agentic applications as manageable identity objects, extending existing User and Group schemas with new resource types to enable interoperability across identity providers and agentic systems.\",\n \"n\": 2,\n \"nn\": \"Incremental extension mapping agent concepts onto existing SCIM framework; lacks novel architectural or security insights specific to agent management.\",\n \"m\": 2,\n \"mn\": \"Early draft stage; abstract describes intent but document likely lacks detailed schema definitions, protocol flows, examples, or implementation guidance for agent-specific operations.\",\n \"o\": 3,\n \"on\": \"Shares conceptual overlap with SCIM core (User/Group extension pattern), agent identity frameworks, and emerging agent management protocols; positioning relative to other agent orchestration standards unclear.\",\n \"mo\": 1,\n \"mon\": \"Single revision dated 2026; no evidence of WG sponsorship, community adoption, or iterative refinement; appears exploratory without institutional momentum.\",\n \"r\": 4,\n \"rn\": \"Directly addresses practical need for agent identity and lifecycle management in multi-domain scenarios; highly relevant to agent interoperability but implementation maturity unclear.\",\n \"c\": [\n \"Agent identity/auth\",\n \"Data formats/interop\",\n \"Agent discovery/reg\",\n \"A2A protocols\"\n ]\n}\n```", "in_tok": 643, "out_tok": 333}
|
|
|
|
|
{"draft_name": "draft-ietf-idr-bgp-metrics", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes extended per-hop BGP metrics to enable sophisticated routing policies beyond standard BGP-4 capabilities. Aims to address the limitation of globally significant metrics in BGP to support common operational practices.\",\n \"n\": 2,\n \"nn\": \"Incremental extension to BGP with per-hop metrics; addresses known limitations but represents straightforward enhancement rather than fundamental innovation.\",\n \"m\": 2,\n \"mn\": \"Early-stage draft with abstract description of proposed metrics; lacks detailed protocol specification, encoding formats, implementation guidelines, or test vectors.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing BGP extensions (BGP communities, extended communities, large communities, segment routing). Similar goals addressed through multiple competing proposals.\",\n \"mo\": 1,\n \"mon\": \"Single revision in 2024; no evidence of WG adoption, implementation activity, or community discussion. Appears dormant relative to active BGP extension efforts.\",\n \"r\": 1,\n \"rn\": \"Not relevant to AI or autonomous agents. Standard network routing protocol enhancement with no connection to AI/ML systems or agent-based networking.\",\n \"c\": [\"Other AI/agent\"]\n}\n```", "in_tok": 588, "out_tok": 284}
|
|
|
|
|
{"draft_name": "draft-mw-spice-inference-chain", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes cryptographically verifiable inference chains for AI agents using ZKML proofs and TEE attestations to prove computational provenance (HOW), complementing actor and intent chains for complete governance. Part of a broader 'Truth Stack' framework for autonomous AI agent governance via OAuth token extensions.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution combining established techniques (ZKML, TEE attestation, Merkle roots) in a new layering scheme; the novelty is primarily architectural rather than algorithmic.\",\n \"m\": 2,\n \"mn\": \"Early sketch with abstract definitions; lacks detailed protocol mechanics, integration examples, or concrete implementation guidance for production ZKML/TEE coordination.\",\n \"o\": 3,\n \"on\": \"Shares core concepts with existing ZKML research, TEE attestation standards (Intel SGX, ARM TrustZone), and verifiable computation work; chains pattern appears in supply-chain/blockchain contexts but AI-agent application is somewhat novel.\",\n \"m\": 1,\n \"mon\": \"Appears to be a 2026 draft (future-dated or speculative), no evidence of multiple revisions, WG adoption, or reference implementations; experimental framing suggests very early stage.\",\n \"r\": 5,\n \"rn\": \"Directly addresses critical AI agent governance challenge: proving which model actually produced an inference output; core to trust and auditability in autonomous systems.\",\n \"c\": [\n \"Agent identity/auth\",\n \"Policy/governance\",\n \"Model serving/inference\",\n \"Data formats/interop\",\n \"AI safety/alignment\"\n ]\n}\n```", "in_tok": 704, "out_tok": 391}
|
|
|
|
|
{"draft_name": "draft-messous-eat-ai", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Defines an EAT profile for attesting autonomous AI agents' model integrity, training data provenance, and inference policies using CWTs/JWTs within IETF RATS. Includes optional extensions for 5G/6G network function interoperability with ETSI and 3GPP standards.\",\n \"n\": 2,\n \"nn\": \"Incremental extension of existing EAT framework to AI agents; claims design is straightforward application of established attestation patterns to new domain.\",\n \"m\": 3,\n \"mn\": \"Defined protocol with standardized claims and CBOR/JWT encoding, but lacks implementation examples, test vectors, and validation against real AI agent deployment scenarios.\",\n \"o\": 3,\n \"on\": \"Shares foundational concepts with EAT (RFC 9334), RATS architecture, and general attestation work; some overlap with broader AI security/governance discussions but distinct encoding approach.\",\n \"mo\": 2,\n \"mon\": \"Single dated revision (2026-02-24); no evidence of WG adoption, multiple versions, or community feedback cycle. Early-stage draft with limited visible momentum.\",\n \"r\": 4,\n \"rn\": \"Directly addresses agent identity/authentication and attestation needs; relevant to autonomous agent security and governance, though focuses more on infrastructure interop than core agent behavior.\",\n \"c\": [\n \"Agent identity/auth\",\n \"Data formats/interop\",\n \"Policy/governance\",\n \"Model serving/inference\",\n \"Autonomous netops\"\n ]\n}\n```", "in_tok": 618, "out_tok": 372}
|
|
|
|
|
{"draft_name": "draft-hori-agent-quality-graph", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"AQG proposes a PageRank-like trust scoring mechanism for AI agents based on delegation transaction graphs, enabling evaluation of agent reliability in multi-agent systems. The protocol defines delegation record formats, graph construction, scoring algorithms, and query APIs for trustworthiness assessment.\",\n \"n\": 2,\n \"nn\": \"Applying web graph ranking to agent delegation is incremental; the core insight (transitive trust via delegation chains) is straightforward adaptation of existing PageRank methodology to a new domain without significant algorithmic innovation.\",\n \"m\": 2,\n \"mn\": \"Early sketch phase; abstract defines concepts and scope but 9 pages insufficient for protocol specification. Missing delegation record schema details, graph construction algorithms, scoring parameters, API specifications, and security considerations.\",\n \"o\": 4,\n \"on\": \"Significant conceptual overlap with existing work: PageRank variants (Google, web trust), reputation systems (EigenTrust, Advogato), and agent trust frameworks. The application domain is narrower than prior art but doesn't meaningfully differentiate mechanically.\",\n \"mo\": 1,\n \"mon\": \"Single dated revision (2026-05-02), no evidence of active development, WG discussion, or implementation efforts. No community adoption signals or follow-up activity visible.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to multi-agent AI systems and inter-agent trustworthiness evaluation, but somewhat narrow in scope (delegation graphs only). Addresses real emerging need but lacks comprehensive agent lifecycle context.\",\n \"c\": [\n \"A2A protocols\",\n \"AI safety/alignment\",\n \"Agent discovery/reg\",\n \"Data formats/interop\"\n ]\n}\n```", "in_tok": 623, "out_tok": 402}
|
|
|
|
|
{"draft_name": "draft-howe-vcon-agent-session", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft extends the vCon (Virtualized Conversations) format to capture autonomous AI agent internal sessions\u2014including prompts, tool calls, reasoning, and artifacts\u2014alongside human-facing conversations. It leverages existing vCon infrastructure for identity, lawful basis, lifecycle management, and signing without introducing new top-level fields.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution that applies an existing conversation format to a new use case (agent instrumentation); the core novelty is primarily in schema mapping rather than novel mechanisms.\",\n \"m\": 3,\n \"mn\": \"Defined protocol with clear structure and reference to companion specs (VAC CDDL schema); lacks implementation examples, test vectors, and validation guidance needed for full maturity.\",\n \"o\": 3,\n \"on\": \"Shares conceptual overlap with vCon lifecycle/lawful-basis drafts and VAC schema work; positions itself as a compatible extension rather than competing approach, reducing direct conflict.\",\n \"mo\": 2,\n \"mon\": \"Single revision observed (2026-05-20 timestamp); no clear evidence of WG adoption, community feedback cycles, or multiple iterations suggesting active momentum.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to agent transparency, auditability, and human-agent interaction; timely for AI governance and compliance use cases, though narrower than core agent protocol concerns.\",\n \"c\": [\n \"Agent identity/auth\",\n \"Data formats/interop\",\n \"Human-agent interaction\",\n \"Policy/governance\"\n ]\n}\n```", "in_tok": 807, "out_tok": 374}
|
|
|
|
|
{"draft_name": "draft-xie-ai-agent-multimodal", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes multimodal requirements for agent-to-agent protocols enabling autonomous agents to negotiate heterogeneous data capabilities and exchange synchronized content with adaptive QoS. Addresses multi-channel communication, data type negotiation, and quality-of-service policies for AI agent interactions.\",\n \"n\": 2,\n \"nn\": \"Incremental extension combining existing multimodal data handling with agent protocol requirements; QoS adaptation is well-established concept applied to new domain.\",\n \"m\": 2,\n \"mn\": \"Early sketch document; specifies requirements only without detailed protocol definition, normative mechanisms, or implementation guidance; 5 pages suggests incomplete specification.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing work on multimodal interfaces, RTP/RTCP media negotiation, SDP, and agent communication frameworks; limited novel architectural choices evident.\",\n \"mo\": 1,\n \"mon\": \"Single revision dated 2026-01-09 with no evidence of community discussion, WG sponsorship, or iterative development; appears to be initial submission without adoption signals.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to AI agent infrastructure; focuses on protocol requirements rather than core AI safety, alignment, or agent behavior; treats agents as communication endpoints rather than intelligent entities.\",\n \"c\": [\n \"A2A protocols\",\n \"Data formats/interop\",\n \"ML traffic mgmt\",\n \"Agent discovery/reg\"\n ]\n}\n```", "in_tok": 529, "out_tok": 354}
|
|
|
|
|
{"draft_name": "draft-song-anp-ans", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"ANS defines a DNS-like name registration and resolution protocol for autonomous AI agents, mapping human-readable agent:// URIs to cryptographic peer identities within the ANP suite. It provides narrow name-binding functionality across unicast, anycast, and channel addressing modes using GossipSub and DHT dissemination.\",\n \"n\": 2,\n \"nn\": \"Incremental adaptation of established DNS/naming patterns to agent-oriented networks; core concepts (hierarchical naming, registration, resolution) are well-precedented in traditional DNS and DHT systems.\",\n \"m\": 3,\n \"mn\": \"Protocol definition is reasonably complete with specified methods and formats, but lacks implementation details, test vectors, and deployment guidance needed for production readiness.\",\n \"o\": 4,\n \"on\": \"Significant conceptual overlap with DNS, SRV records, and DHT-based naming systems (BitTorrent DHT, IPFS IPNS); positioning relative to existing agent discovery systems and companion protocols (ADP, AIP) is unclear.\",\n \"mo\": 1,\n \"mon\": \"Single draft revision dated 2026-03-25 with no evidence of WG adoption, community discussion, or prior versions; appears to be nascent work without demonstrated momentum.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to agent infrastructure and discovery, addressing real coordination challenges for distributed AI systems; however, relevance contingent on ANP/AIP/ADP ecosystem adoption which is unproven.\",\n \"c\": [\n \"Agent discovery/reg\",\n \"Agent identity/auth\",\n \"A2A protocols\",\n \"Data formats/interop\",\n \"Autonomous netops\"\n ]\n}\n```", "in_tok": 687, "out_tok": 409}
|
|
|
|
|
{"draft_name": "draft-lkspa-wimse-verifiable-geo-fence", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes a hardware-rooted cryptographic framework for verifying workload identity and geographic location using zero-knowledge proofs, binding software identities to silicon while preserving location privacy for sovereign cloud workloads.\",\n \"n\": 4,\n \"nn\": \"Novel combination of ZKP-based geofencing with hardware-rooted attestation and silicon-to-workload chain of trust; location privacy via ZKP is notably inventive, though individual components exist.\",\n \"m\": 2,\n \"mn\": \"Early draft stage; abstract and problem well-articulated but protocol mechanics, cryptographic details, and implementation guidance appear underdeveloped for a 22-page document.\",\n \"o\": 2,\n \"on\": \"Minimal overlap; geofencing and attestation exist separately, but ZKP-privacy-preserving geofencing bound to hardware identity is distinctive within WIMSE context.\",\n \"mo\": 2,\n \"mon\": \"Single revision dated 2026-03-02; no evidence of WG adoption, implementation efforts, or community engagement yet; nascent draft momentum.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to WIMSE agent architecture and workload identity authentication; addresses sovereign compute and high-assurance environments critical for enterprise AI agent deployment.\",\n \"c\": [\n \"Agent identity/auth\",\n \"Policy/governance\",\n \"Data formats/interop\"\n ]\n}\n```", "in_tok": 835, "out_tok": 345}
|
|
|
|
|
{"draft_name": "draft-sharif-attp-agent-trust-transport", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"ATTP proposes a synchronous request-response protocol layered over HTTP for AI agent-to-server communication, mandating cryptographic identity verification, per-message signing, and audit trails. It complements the asynchronous ATP protocol and uses JWT-based Agent Passports with ECDSA P-256 signatures for all interactions.\",\n \"n\": 2,\n \"nn\": \"Largely applies existing cryptographic primitives (JWT, ECDSA, nonces, timestamps) to agent communication; the core idea of signing agent requests is incremental rather than novel, though the specific mandatory framework for agents is a useful contribution.\",\n \"m\": 3,\n \"mn\": \"Protocol is well-specified with defined headers and cryptographic requirements, but lacks implementation evidence, test vectors, or interoperability examples; appears ready for specification but not yet validated in practice.\",\n \"o\": 4,\n \"on\": \"Significant overlap with mutual TLS, OAuth 2.0 for service-to-service auth, and existing API signing schemes (AWS SigV4, HTTP signatures); the agent-specific framing is novel but core mechanisms are established.\",\n \"m\": 2,\n \"mon\": \"Single dated revision (2026-03-30 suggests future speculation), no evidence of WG adoption, community review, or iterative refinement; appears to be an individual submission.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to securing agent-to-API communication and agent identity/authentication, core concerns for deployed autonomous systems; less relevant to alignment, discovery, or policy layers.\",\n \"c\": [\n \"A2A protocols\",\n \"Agent identity/auth\",\n \"Data formats/interop\",\n \"Autonomous netops\"\n ]\n}\n```", "in_tok": 847, "out_tok": 416}
|
|
|
|
|
{"draft_name": "draft-sharif-openid-agent-identity", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Defines an OpenID Connect profile for issuing identity tokens to autonomous AI agents, introducing standard claims for agent identity, ownership, trust posture, and compliance screening. Enables RPs to validate agent tokens and enforce graduated access controls without modifying core OpenID Connect protocol.\",\n \"n\": 2,\n \"nn\": \"Incremental extension applying existing OpenID Connect patterns to agent identity; straightforward adaptation of established IdP/RP model to new use case without fundamental protocol innovation.\",\n \"m\": 2,\n \"mn\": \"Early sketch at 2 pages; lacks implementation details, test vectors, validation rules, claim schemas, and worked examples of RP enforcement logic; needs substantial development for deployment readiness.\",\n \"o\": 3,\n \"on\": \"Shares concepts with agent authentication/RBAC work (OAuth 2.0 for Devices, service account patterns) and OpenID Connect extensions; minor novelty in applying IdP model specifically to autonomous agents rather than new approach.\",\n \"mo\": 1,\n \"mon\": \"Single revision dated 2026-03-26 with no visible revision history or community discussion; appears to be initial submission without demonstrated WG or implementer adoption.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to agent identity and authentication infrastructure; addresses real operational need for distinguishing and controlling autonomous agents in enterprise environments, though framed narrowly around OpenID Connect rather than broader agent governance.\",\n \"c\": [\n \"Agent identity/auth\",\n \"Data formats/interop\",\n \"Policy/governance\",\n \"Agent discovery/reg\"\n ]\n}\n```", "in_tok": 587, "out_tok": 380}
|
|
|
|
|
{"draft_name": "draft-song-lake-ra", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft integrates remote attestation capabilities into EDHOC, a lightweight key exchange protocol, following the RATS architecture to enable devices to verify each other's trustworthiness during establishment of authenticated connections. It addresses attestation as a component of secure communication for resource-constrained IoT and embedded systems.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution combining existing standards (EDHOC + RATS) rather than introducing fundamentally new concepts; represents a natural extension of EDHOC functionality.\",\n \"m\": 3,\n \"mn\": \"Protocol mechanism is defined with conceptual clarity, but document appears to lack detailed implementation examples, test vectors, and interoperability guidance typical of mature IETF specifications.\",\n \"o\": 3,\n \"on\": \"Shares core concepts with existing RATS framework and EDHOC specification; moderate overlap with prior work on attestation in constrained environments, though specific integration approach offers some distinctiveness.\",\n \"mo\": 2,\n \"mon\": \"Single recent revision (Jan 2025) with limited indication of WG discussion, adoption momentum, or multiple implementation efforts; typical early-stage draft activity level.\",\n \"r\": 2,\n \"rn\": \"Tangentially related to AI agents\u2014addresses device identity/authentication and trustworthiness verification which could apply to agent infrastructure, but not specifically designed for or focused on autonomous agent systems.\",\n \"c\": [\"Agent identity/auth\", \"Data formats/interop\", \"Other AI/agent\"]\n}\n```", "in_tok": 510, "out_tok": 355}
|
|
|
|
|
{"draft_name": "draft-cowles-aee", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"AEE proposes a lightweight JSON envelope format for inter-agent communication with 14 standardized fields for routing, correlation, and tracing while deliberately omitting payload semantics. The work addresses the practical need for transport-agnostic message framing across heterogeneous AI agent frameworks.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution; JSON envelopes and message framing are well-established patterns (cf. CloudEvents, AMQP, gRPC metadata). The 14-field structure is a minor design choice rather than fundamental innovation.\",\n \"m\": 4,\n \"mn\": \"Well-structured specification with clear field definitions, validity rules, and conformance levels. Includes entity identifier conventions and reserved namespaces. Appears implementation-ready, though test vectors and reference implementations would strengthen maturity to 5.\",\n \"o\": 4,\n \"on\": \"Significant overlap with CloudEvents (CNCF standard), AMQP message frames, gRPC metadata, and existing agent protocol proposals (e.g., JSON-RPC 2.0 for envelope-like concepts). Differentiation from these is marginal.\",\n \"m\": 2,\n \"mon\": \"Single draft revision (2026-02-28); no evidence of WG adoption, community discussion, or competing proposals. Early-stage specification without apparent implementation ecosystem or operational deployments.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to agent-to-agent communication infrastructure. Addresses genuine interoperability pain points in multi-agent systems. However, relevance is operational/engineering-focused rather than cutting-edge AI capability or safety.\",\n \"c\": [\n \"A2A protocols\",\n \"Data formats/interop\",\n \"Agent discovery/reg\",\n \"Human-agent interaction\"\n ]\n}\n```", "in_tok": 635, "out_tok": 432}
|
|
|
|
|
{"draft_name": "draft-zhang-dmsc-ioa-semantic-interaction", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes an ontology-based semantic layer for agent-to-agent interaction in IoA, defining common classes, properties, and JSON-LD serialization with negotiation and alignment procedures. Aims to enable deterministic semantic interoperability without specifying transport or security.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution combining existing ontology concepts (RDF/JSON-LD) with agent interaction context; semantic layers for interop are established practice, main novelty is IoA-specific framing.\",\n \"m\": 3,\n \"mn\": \"Defines protocol-level mechanism with required classes/properties and negotiation procedures, but lacks implementation examples, test vectors, or validation against heterogeneous real-world ontologies.\",\n \"o\": 4,\n \"on\": \"Significant overlap with W3C PROV, SOSA/SSN ontologies, and existing semantic web agent frameworks (FIPA ACL, Jason/AgentSpeak); negotiation/alignment concepts echo ontology matching literature.\",\n \"mo\": 1,\n \"mon\": \"Single draft dated 2026-04-22 with no revision history apparent; no evidence of WG discussion, implementation uptake, or community feedback; appears nascent.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to agent interoperability and A2A protocols; solid fit for emerging IoA standardization needs, though positioned as semantic substrate rather than core agent functionality.\",\n \"c\": [\n \"A2A protocols\",\n \"Agent discovery/reg\",\n \"Data formats/interop\",\n \"Policy/governance\"\n ]\n}\n```", "in_tok": 600, "out_tok": 388}
|
|
|
|
|
{"draft_name": "draft-xu-rtgwg-fare-in-sun", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft proposes Fully Adaptive Routing Ethernet (FARE), extending WECMP load-balancing from scale-out to scale-up networks to support efficient expert parallelization in MoE-based LLM training and inference across GPU clusters.\",\n \"n\": 2,\n \"nn\": \"Incremental adaptation of existing WECMP mechanisms to a different network scale; the core contribution is applying known load-balancing techniques to MoE-specific hardware constraints rather than introducing fundamentally new routing paradigms.\",\n \"m\": 2,\n \"mn\": \"Early sketch stage; abstract describes motivation and high-level approach but the 9-page draft likely lacks detailed protocol specifications, algorithm descriptions, or implementation validation needed for production deployment.\",\n \"o\": 3,\n \"on\": \"Shares foundational concepts with existing adaptive routing and ECMP variants; overlaps with prior work on AI datacenter networking (e.g., NVIDIA Cumulus, Facebook's f16 designs) though specific FARE application to MoE may be somewhat novel.\",\n \"mo\": 1,\n \"mon\": \"Single draft revision dated 2026-02-27 with no evidence of WG adoption, multiple revisions, or community discussion; appears to be early-stage individual submission without established momentum.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI infrastructure; addresses critical bottleneck in distributed LLM training/inference, though focuses on networking layer rather than agent behavior, safety, or high-level AI coordination.\",\n \"c\": [\n \"ML traffic mgmt\",\n \"Model serving/inference\",\n \"Autonomous netops\"\n ]\n}\n```", "in_tok": 638, "out_tok": 397}
|
|
|
|
|
{"draft_name": "draft-aevum-agentcard", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"AgentCard proposes a lightweight JSON schema for autonomous agents to declare identity, capabilities, endpoints, and pricing in a framework-agnostic manner. It aims to enable interoperability between heterogeneous agent platforms (LangChain, CrewAI, AutoGen, etc.) without prior coordination, drawing inspiration from HTTP headers and grounding pricing in Landauer's principle.\",\n \"n\": 3,\n \"nn\": \"Useful contribution addressing a real interop gap, but combines relatively straightforward concepts (ULIDs, dot-namespacing, capability schemas) without fundamental innovation. The energy-pricing floor angle is creative but speculative.\",\n \"m\": 3,\n \"mn\": \"Defined protocol with stated schema structure and design principles, but document lacks detailed normative specs, formal grammar, complete examples, test vectors, and validation rules. Ready for discussion but needs substantial engineering work.\",\n \"o\": 3,\n \"on\": \"Shares conceptual territory with OpenAI function schemas, MCP tool definitions, and existing agent frameworks' capability declarations. Not a duplicate, but incremental synthesis rather than orthogonal approach.\",\n \"mo\": 1,\n \"mon\": \"April 2026 date suggests recent proposal with single apparent revision. No evidence of WG adoption, implementation demos, or community traction in abstract/metadata. Appears early-stage independent work.\",\n \"r\": 4,\n \"rn\": \"Directly addresses agent interoperability and A2A communication\u2014core infrastructure gaps in the emerging multi-agent ecosystem. Highly relevant to current AI systems deployment challenges.\",\n \"c\": [\n \"A2A protocols\",\n \"Data formats/interop\",\n \"Agent identity/auth\",\n \"Agent discovery/reg\",\n \"ML traffic mgmt\"\n ]\n}\n```", "in_tok": 702, "out_tok": 421}
|
|
|
|
|
{"draft_name": "draft-morrison-compute-location-gate", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes a wire-layer mechanism for negotiating where identity inference computation occurs based on data provenance class, with three tiers distinguishing active, passive-aggregate, and passive-individual observations. Enforces consent-based routing through wire-layer refusal rather than cryptographic proof, composing with existing discovery and policy frameworks.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution combining existing consent/policy concepts with location-of-computation routing; the provenance classification scheme is useful but relatively straightforward extension of standard access control patterns.\",\n \"m\": 2,\n \"mn\": \"Early sketch phase; describes architectural intent and three provenance classes but lacks detailed protocol specifications, message formats, error handling procedures, or implementation guidance needed for interoperability.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing work on consent management (GDPR consent signals), data minimization principles (differential privacy literature), and federated learning frameworks that separately handle server vs. edge computation; primarily reframes these concepts in identity-inference context.\",\n \"mo\": 1,\n \"mon\": \"Single revision with 2026 date suggests nascent effort; no evidence of WG sponsorship, community discussion, or iterative refinement based on feedback; appears to be standalone proposal without adoption signals.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to AI agents; directly addresses inference computation location and consent enforcement for identity systems, but focuses narrowly on inference servers rather than broader agent autonomy, coordination, or safety concerns.\",\n \"c\": [\"Policy/governance\", \"Model serving/inference\", \"Agent identity/auth\", \"Data formats/interop\"]\n}\n```", "in_tok": 773, "out_tok": 387}
|
|
|
|
|
{"draft_name": "draft-calabria-bmwg-ai-fabric-inference-bench", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft establishes vendor-independent benchmarking methodologies and KPIs for evaluating Ethernet-based AI inference serving network fabrics, addressing the critical bottleneck of interconnect performance in disaggregated LLM inference architectures. It covers RDMA-based KV cache transfer, MoE expert parallelism, request routing, congestion management, and scale testing to enable reproducible apples-to-apples fabric performance comparison.\",\n \"n\": 3,\n \"nn\": \"Incremental contribution adapting existing BMWG benchmarking frameworks to AI inference workloads; the core novelty is domain-specific application rather than methodological innovation.\",\n \"m\": 4,\n \"mn\": \"Well-structured specification with defined terminology, comprehensive KPI coverage, and realistic test procedures; lacks implementation examples and validation results but provides clear guidance for benchmark execution.\",\n \"o\": 2,\n \"on\": \"Minor overlap with general network fabric benchmarking work; TRAINING-BENCH companion document and inference-specific focus (TTFT, ITL, TPS metrics) differentiate this from prior BMWG efforts.\",\n \"mo\": 2,\n \"mon\": \"Single revision as of 2026-02-27; no evidence of WG adoption or multiple iterations; early-stage draft with limited community engagement signals.\",\n \"r\": 5,\n \"rn\": \"Directly addresses core AI infrastructure challenge\u2014network fabric becomes critical bottleneck in disaggregated LLM inference systems; highly relevant to agent deployment scaling.\",\n \"c\": [\n \"ML traffic mgmt\",\n \"Model serving/inference\",\n \"Data formats/interop\",\n \"A2A protocols\"\n ]\n}\n```", "in_tok": 768, "out_tok": 407}
|
|
|
|
|
{"draft_name": "draft-sovereign-haip", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"HAIP proposes a real-time identity verification protocol for AI agents using microsecond-precision pulses and decentralized identity mechanisms. The draft addresses trust and integrity concerns in autonomous agent environments through NIST-aligned non-repudiation.\",\n \"n\": 2,\n \"nn\": \"Incremental combination of existing concepts (heartbeat mechanisms, decentralized identity, non-repudiation) without substantial technical innovation.\",\n \"m\": 1,\n \"mn\": \"Problem statement and conceptual framing only; lacks protocol specification details, message formats, cryptographic algorithms, state machines, or implementation guidance.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing work on agent authentication (SPIFFE/SPIRE), integrity verification (COSE), and distributed identity systems; the 6.42\u00b5s pulse claim appears unmotivated and disconnected from practical protocol layers.\",\n \"mo\": 1,\n \"mon\": \"Single dated draft (2026-04-30) with no evidence of revision history, community discussion, working group sponsorship, or implementation activity.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to AI agent infrastructure; identity and integrity are legitimate concerns, but the draft conflates multiple problem domains and lacks clarity on which agent scenarios it actually addresses.\",\n \"c\": [\n \"Agent identity/auth\",\n \"AI safety/alignment\",\n \"A2A protocols\",\n \"Policy/governance\"\n ]\n}\n```", "in_tok": 539, "out_tok": 353}
|
|
|
|
|
{"draft_name": "draft-liang-agentdns", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"AgentDNS proposes a domain naming and service discovery system for LLM agents, drawing inspiration from traditional DNS to enable autonomous discovery and invocation of agent services across vendors. The system addresses interoperability, service discovery, and trust management in multi-agent ecosystems through unified namespace, semantic discovery, and authentication mechanisms.\",\n \"n\": 2,\n \"nn\": \"Incremental adaptation of established DNS concepts to agent domain; lacks fundamental innovation beyond applying existing naming/discovery patterns to new use case.\",\n \"m\": 2,\n \"mn\": \"Early sketch with conceptual framework; no detailed protocol specifications, message formats, or implementation details evident; minimal technical depth for standardization track.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing service discovery (DNS-SD, mDNS, Consul), agent frameworks (OpenAI Functions, LangChain tools), and identity solutions; concepts not sufficiently differentiated.\",\n \"mo\": 1,\n \"mon\": \"Single draft submission with 2026 date suggests limited development history; no evidence of WG discussion, implementation, or community adoption feedback.\",\n \"r\": 4,\n \"rn\": \"Directly addresses agent interoperability and service discovery challenges relevant to AI agent ecosystems, though framing as IETF standards effort is questionable for LLM-specific infrastructure.\",\n \"c\": [\"Agent discovery/reg\", \"A2A protocols\", \"Agent identity/auth\", \"Data formats/interop\", \"Autonomous netops\"]\n}\n```", "in_tok": 593, "out_tok": 359}
|
|
|
|
|
{"draft_name": "draft-helmprotocol-tttps", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"TTTPS proposes a TLS 1.3 extension adding cryptographically verifiable temporal ordering via Proof-of-Time (PoT) to defend against strategic channel controllers exploiting ordering for economic advantage. The protocol targets autonomous AI agents where latency-based ordering advantages are structurally neutralized, using a multi-stage compression pipeline (Golomb-Rice, Reed-Solomon, Golay, HMAC) with an AdaptiveSwitch mechanism to make manipulation economically self-defeating.\",\n \"n\": 4,\n \"nn\": \"The Strategic Channel Controller Problem (SCCP) framing is novel and the specific application to AI agent temporal ordering is genuinely original. However, the core cryptographic primitives (PoT, HMAC pipelines) are well-established; novelty lies in problem identification and integration rather than fundamental cryptographic innovation.\",\n \"m\": 2,\n \"mn\": \"Protocol specification is incomplete (abstract truncates mid-sentence at 'The GRG pipeline specification will be p...'). Describes high-level mechanism but lacks formal definitions, full algorithm specifications, security proofs, implementation details, and test vectors. Claims of 70k records on Base Sepolia are empirical validation but insufficient for maturity without complete technical specification.\",\n \"o\": 3,\n \"on\": \"Shares ordering/sequencing concerns with blockchain timestamp protocols and BFT consensus literature. Overlaps with existing work on Byzantine time-keeping and fairness in MEV prevention. The specific PoT pipeline construction appears novel, but the problem domain has been explored in distributed systems and fair sequencing literature.\",\n \"mo\": 1,\n \"mon\": \"Single draft revision (2026-04-19), marked Experimental status, incomplete specification, and no evidence of IETF WG engagement. Appears to be initial submission rather than active development. Companion paper [POT2026] is cited but presumably unpublished. No indication of multiple iterations or community adoption.\",\n \"r\": 4,\n \"rn\": \"Directly addresses autonomous AI agent infrastructure vulnerabilities, specifically temporal ordering manipulation as agents converge on symmetric latencies. The 55% of verified records from AI agents validates claimed relevance. Core concern is agent economy stability and", "in_tok": 932, "out_tok": 512}
|
|
|
|
|
{"draft_name": "draft-teodor-pilot-protocol", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Pilot Protocol proposes an overlay network layer providing autonomous AI agents with stable virtual identities, addresses, and standard transport services (TCP/UDP-like) over UDP. It aims to give AI agents first-class network citizenship with NAT traversal and encryption, operating beneath application-layer protocols like A2A and MCP.\",\n \"n\": 2,\n \"nn\": \"Overlay networks and virtual addressing are well-established concepts; the application to AI agents is incremental rather than architecturally novel. Combines existing techniques (UDP encapsulation, NAT traversal, encryption) without significant protocol innovation.\",\n \"m\": 3,\n \"mn\": \"Document specifies a protocol with defined mechanisms for addressing, multiplexing, and transport. Appears to have protocol details but unclear if implementation-ready; 43 pages suggests reasonable depth but likely lacks test vectors, conformance tests, or reference implementations.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing overlay networks (Tinc, Wireguard concepts), VPN tunneling, and agent communication frameworks. The agent-centric framing is novel but the underlying technical approach replicates established patterns from overlay networking.\",\n \"m\": 2,\n \"mon\": \"Single 2026-04-06 revision with no visible prior versions or community discussion. No evidence of WG adoption, implementation pilots, or iterative refinement. Appears to be initial submission without established momentum.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to autonomous agent infrastructure and standardization. Addresses real problem of agent network identity and discovery, though relevance is architectural rather than focused on agent capabilities, safety, or learning.\",\n \"c\": [\n \"A2A protocols\",\n \"Agent identity/auth\",\n \"Agent discovery/reg\",\n \"Autonomous netops\",\n \"Data formats/interop\"\n ]\n}\n```", "in_tok": 595, "out_tok": 442}
|
|
|
|
|
{"draft_name": "draft-peterson-mimi-idprover", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Specifies a proof-of-possession mechanism for third-party services to verify that messaging platform users legitimately control asserted telephone numbers as communication identifiers. The approach supports secure enrollment in interoperable real-time communication applications within the MIMI framework.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution applying existing proof-of-possession patterns to telephone number verification for messaging platforms; limited conceptual novelty.\",\n \"m\": 3,\n \"mn\": \"Defined protocol mechanism with clear problem scope, but 7 pages suggests incomplete specification lacking detailed test vectors or implementation guidance.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing telephone number verification schemes (SMS-based OTP, carrier authentication) and general identity proofing frameworks; mostly recontextualizes known approaches.\",\n \"mo\": 2,\n \"mon\": \"Single draft revision with uncertain WG adoption status; appears exploratory for MIMI context rather than demonstrating active community momentum.\",\n \"r\": 2,\n \"rn\": \"Tangentially related to agent systems; addresses communications identity verification for messaging platforms but not core AI agent functionality, autonomy, or intelligence concerns.\",\n \"c\": [\"Agent identity/auth\", \"Data formats/interop\", \"Human-agent interaction\"]\n}\n```", "in_tok": 586, "out_tok": 308}
|
|
|
|
|
{"draft_name": "draft-ietf-httpbis-zstd-window-size", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft addresses interoperability issues with Zstandard compression in HTTP by upgrading window size limits from RFC8878 recommendations to strict requirements. It aims to prevent memory exhaustion concerns that cause some browsers to reject certain zstd-compressed content.\",\n \"n\": 2,\n \"nn\": \"Incremental refinement of existing compression standard; primarily clarifies and tightens requirements rather than introducing novel concepts.\",\n \"m\": 4,\n \"mn\": \"Well-defined specification updating RFC8878 with clear window size requirements suitable for HTTP deployment; appears implementation-ready.\",\n \"o\": 3,\n \"on\": \"Directly addresses known interoperability patterns in zstd deployment; shares conceptual space with other content-encoding RFCs but focuses on specific parameter constraint.\",\n \"mo\": 2,\n \"mon\": \"Appears to be single or early-stage revision addressing specific deployment pain point; limited evidence of broader WG momentum beyond problem identification.\",\n \"r\": 1,\n \"rn\": \"Not relevant to AI agents; standard HTTP content encoding specification with no connection to agent systems, ML operations, or autonomous networking.\",\n \"c\": [\"Data formats/interop\"]\n}\n```", "in_tok": 541, "out_tok": 286}
|
|
|
|
|
{"draft_name": "draft-hw-ai-agent-6g", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft proposes requirements and enabling technologies for AI agent protocols tailored to 6G networks, positioning the telecom industry as a key adopter of agent-based systems. It attempts to bridge AI agent ecosystems with mobile communication infrastructure, addressing protocol design for next-generation networks.\",\n \"n\": 2,\n \"nn\": \"Incremental combination of existing agent protocol concepts applied to 6G context; lacks novel protocol innovations or fundamentally new requirements.\",\n \"m\": 2,\n \"mn\": \"Early-stage requirements document with problem framing; no detailed protocol specifications, mechanisms, or implementation guidance provided.\",\n \"o\": 4,\n \"on\": \"Significant overlap with ongoing 3GPP 6G studies, ITU-T agent standardization efforts, and multiple concurrent IETF agent protocol drafts; lacks differentiation.\",\n \"mo\": 1,\n \"mon\": \"Single dated revision from 2026; unclear WG sponsorship, adoption interest, or community engagement; appears exploratory rather than momentum-driven.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to AI agents in telecom context, but framed more as 6G systems architecture than as core agent protocol work; tangential to pure agent protocol development.\",\n \"c\": [\n \"Agent discovery/reg\",\n \"A2A protocols\",\n \"Autonomous netops\",\n \"Data formats/interop\",\n \"Policy/governance\"\n ]\n}\n```", "in_tok": 582, "out_tok": 348}
|
|
|
|
|
{"draft_name": "draft-lin-opsec-trustroute-problem-statement", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft proposes trustworthiness-based routing to enable differentiated security services in networks, addressing operator needs for QoE guarantees alongside security threats. It identifies use cases and requirements but lacks concrete protocol specifications or solutions.\",\n \"n\": 2,\n \"nn\": \"Incremental extension of existing QoE/SLA concepts applied to security dimension; trustworthiness-based routing is a logical but not novel concept in network security literature.\",\n \"m\": 1,\n \"mn\": \"Pure problem statement and use case exploration with no protocol definition, mechanism design, or implementation details provided.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing work in security-aware routing, trust-based networking, and differentiated services (DiffServ); concepts not sufficiently differentiated from prior art.\",\n \"mo\": 1,\n \"mon\": \"Single revision (2024-07), no evidence of WG adoption, community discussion, or iterative development beyond initial draft submission.\",\n \"r\": 1,\n \"rn\": \"Not related to AI agents or autonomous systems; focuses on traditional network routing and operator requirements without agent-relevant components.\",\n \"c\": [\"Policy/governance\"]\n}\n```", "in_tok": 591, "out_tok": 289}
|
|
|
|
|
{"draft_name": "draft-anandakrishnan-rats-ptv-agent-identity", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"PTV proposes a hardware-anchored attestation protocol for proving AI agents run authorized models and policies without exposing sensitive data, designed to compose with existing RATS mechanisms. It separates identity binding from behavioral continuity, treating the latter as a separate concern addressed through exercise-time checks and execution receipts.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution combining existing attestation concepts (RATS, CBOR envelopes, SCITT) with AI agent identity binding; the novelty lies primarily in the application domain and threat model decomposition rather than fundamental protocol innovation.\",\n \"m\": 3,\n \"mn\": \"Defined protocol with specified envelope format (CBOR/CDDL), message types, and threat model, but at 14 pages lacks detailed specification, implementation examples, test vectors, or reference implementations needed for maturity.\",\n \"o\": 3,\n \"on\": \"Shares significant conceptual overlap with RATS attestation frameworks, CBOR/CDDL standardization work, and SCITT composition; the primary differentiation is agent-specific identity binding rather than novel architectural principles.\",\n \"mo\": 1,\n \"mon\": \"Single revision (2026-04-05 expiration suggests early-stage draft), no apparent WG sponsorship or adoption signals; appears to be individual submission without evident community momentum or iterative development.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI agent identity and authentication; addresses practical use cases (CDSS, ICS/OT) and regulatory compliance concerns, though framed narrowly around attestation rather than broader agent autonomy challenges.\",\n \"c\": [\n \"Agent identity/auth\",\n \"Data formats/interop\",\n \"Policy/governance\",\n \"A2A protocols\"\n ]\n}\n```", "in_tok": 681, "out_tok": 426}
|
|
|
|
|
{"draft_name": "draft-madhavan-aipref-displaybasedpref", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes a standardized vocabulary for expressing content usage preferences to search and AI crawlers, enabling structured declarations of restrictions or permissions. Aims to address the gap between existing robots.txt approaches and more nuanced AI/search crawler control requirements.\",\n \"n\": 2,\n \"nn\": \"Incremental extension of existing crawler control mechanisms (robots.txt, meta tags). The core concept of preference vocabularies for crawler behavior is not novel, though application to AI specifically adds marginal novelty.\",\n \"m\": 2,\n \"mn\": \"Early sketch stage. Abstract indicates vocabulary proposal but lacks detail on syntax, semantics, implementation mechanisms, or how declarations are discovered/enforced. No protocol specification, examples, or deployment considerations evident.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing standards: robots.txt, Robots Exclusion Standard (RES), meta robots tags, and emerging work on AI-specific crawler directives. Related to content licensing vocabularies (CC, ODRL). Appears to be yet another layer on established patterns.\",\n \"m\": 1,\n \"mon\": \"Likely single revision or early-stage work. Limited evidence of WG engagement, community adoption, or active development momentum. Published September 2025 but appears nascent.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI agent governance and content control policies. Addresses legitimate concern about AI crawler proliferation. Relevance diminished by unclear technical approach and relationship to existing standards.\",\n \"c\": [\"Policy/governance\", \"Data formats/interop\", \"Agent discovery/reg\", \"Other AI/agent\"]\n}\n```", "in_tok": 513, "out_tok": 382}
|
|
|
|
|
{"draft_name": "draft-embesozzi-oauth-agent-native-authorization", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Extends OAuth 2.0 FiPA specification with standardized metadata format for AI agent authentication challenges via Structured Elicitation. Addresses interoperability gap by defining how agents discover and respond to authenticator requirements in just-in-time authorization flows.\",\n \"n\": 2,\n \"nn\": \"Incremental extension adding JSON metadata schema to existing FiPA framework; builds predictably on established OAuth patterns rather than introducing novel authorization concepts.\",\n \"m\": 3,\n \"mn\": \"Defines protocol mechanism with clear elicitations array structure and MCP binding, but lacks implementation examples, test vectors, and deployment guidance needed for production readiness.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing credential/challenge response patterns in OAuth extensions (CIBA, Device Flow); MCP-Elicitation binding duplicates similar structured metadata approaches in emerging agent frameworks.\",\n \"mo\": 2,\n \"mon\": \"Single dated revision (2026-04-03) with no visible WG discussion or adoption signals; appears early-stage with unclear path to standardization or community interest.\",\n \"r\": 4,\n \"rn\": \"Directly addresses critical AI agent authentication and human-to-agent authorization flows; highly relevant to agent identity/auth and interoperability but narrowly scoped to OAuth ecosystem.\",\n \"c\": [\n \"Agent identity/auth\",\n \"Human-agent interaction\",\n \"Data formats/interop\",\n \"A2A protocols\"\n ]\n}\n```", "in_tok": 651, "out_tok": 359}
|
|
|
|
|
{"draft_name": "draft-wang-hjs-accountability", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"HJS proposes a blockchain-anchored accountability layer for AI agents using four primitives (Judgment/Delegation/Termination/Verification) to create immutable responsibility chains and court-admissible evidence. The system leverages Bitcoin-anchored Open Timestamp proofs and is designed to work independently or complement existing AI agent protocols.\",\n \"n\": 2,\n \"nn\": \"Combines established concepts (blockchain timestamps, audit trails, responsibility chains) in a straightforward application to AI agents; lacks novel cryptographic or architectural insights.\",\n \"m\": 2,\n \"mn\": \"Early sketch with abstract-level design; primitives defined but no detailed protocol specification, message formats, integration examples, or implementation guidance provided.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing accountability/audit trail frameworks, blockchain-based provenance systems, and emerging AI governance protocols; the novelty claims about independence are weakened by intentional design to complement AIIP.\",\n \"mo\": 1,\n \"mon\": \"Single draft dated 2026-02-21 with no evidence of revision history, WG adoption, or community engagement; appears to be initial submission without demonstrated momentum.\",\n \"r\": 4,\n \"rn\": \"Directly addresses AI agent accountability and human oversight, which are core concerns in AI agent governance; however, the blockchain approach may limit practical relevance for many deployment contexts.\",\n \"c\": [\n \"Policy/governance\",\n \"Human-agent interaction\",\n \"Agent identity/auth\",\n \"A2A protocols\"\n ]\n}\n```", "in_tok": 565, "out_tok": 371}
|
|
|
|
|
{"draft_name": "draft-ramadan-mboned-sonar", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"SONAR proposes a protocol for verifiable multicast delivery claims using cryptoeconomic incentives, VRF-based sampling, and blockchain attestations combined with ALTA authentication. It addresses the challenge of proving multicast reach to large populations with O(1) efficiency via statistical sampling and zkSNARK proof aggregation.\",\n \"n\": 2,\n \"nn\": \"Combines existing techniques (ALTA, VRF, zkSNARKs, German Tank Problem) in a novel system architecture, but individual components are well-established; the integration is incremental rather than fundamentally new.\",\n \"m\": 3,\n \"mn\": \"Defines protocol mechanisms with concrete overhead figures (6% bandwidth for ALTA, 0.7-2.8 Kbps for verification) and scaling parameters, but lacks implementation details, test vectors, and deployment guidance for production use.\",\n \"o\": 3,\n \"on\": \"Shares substantial conceptual overlap with existing work on multicast verification, blockchain-based attestation systems, and statistical sampling protocols; positioning relative to prior art unclear.\",\n \"mo\": 1,\n \"mon\": \"Single revision (2025-11-04), no evidence of WG discussion, adoption, or community engagement; appears to be initial submission without iteration.\",\n \"r\": 1,\n \"rn\": \"Addresses multicast delivery verification and network attestation; not related to AI agents, autonomous systems behavior, or AI safety\u2014false positive for this evaluation framework.\",\n \"c\": [\n \"Other AI/agent\"\n ]\n}\n```", "in_tok": 716, "out_tok": 370}
|
|
|
|
|
{"draft_name": "draft-scrm-aiproto-usecases", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft catalogs representative agentic AI use cases and derives protocol-relevant requirements to guide IETF standardization efforts. It focuses on exposing concrete needs like long-lived interactions, agent coordination, and security hooks that should inform how agent-to-agent and agent-to-tool protocols layer over existing IETF substrates.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution; use case collection is standard practice for requirements definition. The connection between AI agent needs and protocol design is not novel, though systematic inventory for IETF scope is useful.\",\n \"m\": 2,\n \"mn\": \"Early sketch phase. Document articulates use cases and derives requirements but lacks detailed protocol proposals, specifications, or reference implementations. Serves as input document rather than standardizable mechanism.\",\n \"o\": 3,\n \"on\": \"Shares conceptual space with existing agent frameworks (MCP, A2A protocols) and general IETF requirements documents. Moderate overlap with concurrent work on AI protocol interoperability; positioned as gap analysis rather than novel protocol design.\",\n \"mo\": 2,\n \"mon\": \"Limited documented momentum. Single revision as of date; no indication of active WG sponsorship or broad community adoption. Appears positioned as exploratory work to justify future standardization rather than active protocol development.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI agent infrastructure and protocol design. Addresses core challenges in multi-agent systems, though frames these through IETF standardization scope rather than agent-centric problems.\",\n \"c\": [\n \"A2A protocols\",\n \"Agent discovery/reg\",\n \"Agent identity/auth\",\n \"Data formats/interop\",\n \"Policy/governance\",\n \"Human-agent interaction\"\n ]\n}\n```", "in_tok": 697, "out_tok": 423}
|
|
|
|
|
{"draft_name": "draft-rehfeld-apix-core", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"APIX proposes a machine-native service discovery infrastructure for autonomous agents, defining governance, trust models, manifests, and API standards to address the structural gap between agent needs and human-centric internet discovery mechanisms.\",\n \"n\": 2,\n \"nn\": \"Service discovery and registry concepts are well-established; applying HATEOAS to agent discovery is incremental rather than foundational innovation.\",\n \"m\": 2,\n \"mn\": \"Core concepts defined but appears early-stage; references external profile drafts for actual service specifications; lacks implementation details, test vectors, and deployment examples.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing service mesh (Consul, Eureka), API gateway registries (Kong), and UDDI concepts; HATEOAS application is standard practice; trust/compliance aspects partially resemble enterprise API management solutions.\",\n \"mo\": 1,\n \"mon\": \"Single revision dated 2026-05-13 with no observable community engagement, WG adoption, or implementation activity; appears to be early-stage independent submission.\",\n \"r\": 4,\n \"rn\": \"Directly addresses agent service discovery and autonomy requirements; governance and trust frameworks are relevant to multi-agent systems; however, relevance depends on whether agent-native indexing becomes critical vs. existing discovery mechanisms.\",\n \"c\": [\"Agent discovery/reg\", \"A2A protocols\", \"Policy/governance\", \"Agent identity/auth\", \"Data formats/interop\"]\n}\n```", "in_tok": 721, "out_tok": 351}
|
|
|
|
|
{"draft_name": "draft-mp-agntcy-ads", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"ADS proposes a distributed directory service for discovering AI agent applications based on metadata and skills. It uses content-routing protocols to interconnect distributed directories, enabling agent discovery across a network infrastructure.\",\n \"n\": 2,\n \"nn\": \"Incremental application of existing distributed directory concepts (DNS-like, DHT patterns) to AI agent discovery; lacks fundamental innovation in routing or metadata representation.\",\n \"m\": 2,\n \"mn\": \"Early sketch with abstract concepts; minimal protocol details, no formal specification, message formats, or implementation guidance provided in summary.\",\n \"o\": 4,\n \"on\": \"Significant overlap with DNS, service discovery (mDNS/SRV), blockchain registries, and agent capability advertising from multi-agent systems literature; content-routing echoes IPFS/Named Data Networking.\",\n \"mo\": 1,\n \"mon\": \"Single draft revision (2026-02-24); no evidence of WG adoption, community discussion, or iterative development since publication.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI agent infrastructure; agent discovery and capability matching are emerging operational needs, though framing as 'distributed' may be solution-looking for problems.\",\n \"c\": [\"Agent discovery/reg\", \"A2A protocols\", \"Data formats/interop\", \"Autonomous netops\"]\n}\n```", "in_tok": 509, "out_tok": 322}
|
|
|
|
|
{"draft_name": "draft-sun-zhang-iaip", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes Intent-based Agent Interconnection Protocol (IAIP) for dynamic routing and discovery of AI agents at gateway level based on semantic capabilities rather than static addressing. Defines mechanisms for agent registration, capability advertisement, intent matching, and task dispatching in multi-agent interconnection scenarios.\",\n \"n\": 2,\n \"nn\": \"Incremental approach applying intent-based routing concepts (established in SDN/networking) to agent discovery; combines existing patterns (service discovery, capability matching) without fundamental innovation.\",\n \"m\": 2,\n \"mn\": \"Early-stage specification with high-level mechanism descriptions but lacks concrete protocol details, message formats, examples, error handling, or implementation guidance needed for interoperability.\",\n \"o\": 4,\n \"on\": \"Significant overlap with service mesh architectures (Istio), agent framework protocols (FIPA ACL), capability-based discovery systems, and intent-based networking (IBN) standards; positioning relative to these is unclear.\",\n \"mo\": 1,\n \"mon\": \"Single revision dated 2026-02-05 with no apparent WG backing, community discussion, or implementation feedback; appears to be individual author submission without active development momentum.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to multi-agent systems and agent interconnection, though framing as IETF network protocol rather than application-layer agent coordination framework limits relevance to traditional IETF scope.\",\n \"c\": [\n \"A2A protocols\",\n \"Agent discovery/reg\",\n \"Autonomous netops\",\n \"Data formats/interop\",\n \"Agent identity/auth\"\n ]\n}\n```", "in_tok": 595, "out_tok": 393}
|
|
|
|
|
{"draft_name": "draft-ra-emu-pqc-eapaka", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft proposes integrating post-quantum key encapsulation mechanisms (PQ-KEMs) into EAP-AKA' FS to protect against quantum computing threats to the current ECDHE-based forward secrecy extension. It addresses the vulnerability where compromised long-term and ephemeral keys could expose session keys in EAP-AKA' authentication.\",\n \"n\": 2,\n \"nn\": \"Incremental extension applying established PQ-KEM concepts to an existing protocol; the quantum-safety enhancement is straightforward but the specific integration details appear novel to EAP-AKA'.\",\n \"m\": 2,\n \"mn\": \"Early sketch phase; abstract describes motivation and problem clearly but draft lacks detailed protocol specifications, algorithm selections, integration mechanics, or implementation considerations.\",\n \"o\": 3,\n \"on\": \"Shares conceptual overlap with RFC 9678 (EAP-AKA' FS) and general PQ cryptography migration efforts; moderate overlap with other PQ-hybrid authentication work but specific EAP-AKA' approach is somewhat differentiated.\",\n \"mo\": 1,\n \"mon\": \"Single revision at submission; no evident prior versions, community discussion, or WG adoption signals visible; appears to be initial draft release with limited trajectory.\",\n \"r\": 2,\n \"rn\": \"Not relevant to AI agents or autonomous systems; focuses on mobile/cellular authentication protocols and quantum-safe cryptography for EAP methods, orthogonal to agent-related topics.\",\n \"c\": [\"Agent identity/auth\"]\n}\n```", "in_tok": 710, "out_tok": 376}
|
|
|
|
|
{"draft_name": "draft-ahn-opsawg-5g-security-i2nsf-framework", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes an integrated security framework for 5G edge networks combining I2NSF architecture with Intent-Based Networking to translate high-level security declarations into enforceable network and application policies. Supports distributed, context-aware policy enforcement across heterogeneous 5G environments with closed-loop monitoring.\",\n \"n\": 2,\n \"nn\": \"Incremental combination of existing standards (I2NSF, IBN, NEF); core concepts not novel but application to 5G edge security is a useful engineering contribution.\",\n \"m\": 2,\n \"mn\": \"Early sketch with conceptual architecture; lacks detailed protocol specifications, implementation examples, formal policy translation algorithms, or validation results.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing I2NSF standardization efforts and 3GPP NEF specifications; IBN concepts well-established in networking literature; limited differentiation from prior intent-based security proposals.\",\n \"mo\": 1,\n \"mon\": \"Single revision dated 2026-01-09; no evidence of WG adoption, community discussion, or iterative refinement; appears to be initial submission.\",\n \"r\": 2,\n \"rn\": \"Tangentially related to AI/agents through Intent-Based Networking automation concepts, but primarily focused on traditional network security policy enforcement rather than autonomous agents, agent protocols, or AI-driven decision-making.\",\n \"c\": [\n \"Policy/governance\",\n \"Autonomous netops\",\n \"Data formats/interop\"\n ]\n}\n```", "in_tok": 667, "out_tok": 363}
|
|
|
|
|
{"draft_name": "draft-ietf-emu-pqc-eapaka", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft extends EAP-AKA' Forward Secrecy by replacing traditional ECDHE with post-quantum key encapsulation mechanisms to protect against future quantum computer threats. It addresses the vulnerability where adversaries with knowledge of both long-term and ephemeral keys could compromise session keys in the authentication protocol.\",\n \"n\": 2,\n \"nn\": \"Straightforward application of PQ-KEMs to an existing protocol; combines established concepts (PQ cryptography + EAP-AKA' FS) without novel integration techniques.\",\n \"m\": 3,\n \"mn\": \"Protocol mechanism is defined with clear threat model and integration approach, but lacks implementation details, test vectors, and interoperability guidance needed for production deployment.\",\n \"o\": 4,\n \"on\": \"Significant overlap with concurrent PQ-crypto standardization efforts (NIST PQC, RFC 9180). Similar PQ integration patterns appear in parallel IETF work on TLS 1.3 and other protocols.\",\n \"mo\": 3,\n \"mon\": \"Active WG engagement evidenced by publication timeline (Feb 2026) and draft iteration, but unclear adoption momentum or vendor commitment relative to other PQ migration efforts.\",\n \"r\": 1,\n \"rn\": \"Not relevant to AI agents; this is cryptographic protocol specification for cellular authentication. No connection to autonomous agents, AI safety, or agent systems.\",\n \"c\": [\"Other AI/agent\"]\n}\n```", "in_tok": 712, "out_tok": 350}
|
|
|
|
|
{"draft_name": "draft-ounsworth-lamps-x509-ar", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes X.509 certificate extensions to embed attestation results from Certificate Signing Requests, allowing CAs to convey Attester trustworthiness claims to Relying Parties. Enables scalable verification across diverse attestation technologies by encoding appraisal evidence directly in issued certificates.\",\n \"n\": 2,\n \"nn\": \"Straightforward extension of existing X.509 mechanisms to carry attestation data; combines established concepts (CSR attestation, certificate extensions) without fundamental innovation.\",\n \"m\": 3,\n \"mn\": \"Defines protocol mechanism with extension structures and use cases, but 9 pages suggests limited depth; likely lacks detailed ASN.1 syntax, processing rules, and interoperability guidance needed for implementation.\",\n \"o\": 3,\n \"on\": \"Related concepts exist in attestation (RFC 9334, RATS architecture), X.509 extensions (RFC 5280), and CSR handling; this work bridges them but doesn't introduce novel concepts, overlaps moderately with attestation result encoding discussions.\",\n \"m\": 2,\n \"mon\": \"Single revision dated 2025-11-03 with no visible adoption signals; early-stage draft without apparent WG backing or implementation ecosystem.\",\n \"r\": 2,\n \"rn\": \"Tangentially related to agent identity/authentication through attestation-based trust establishment; not core to AI agent protocols or AI safety concerns; relevance is primarily in credential infrastructure rather than agent-specific systems.\",\n \"c\": [\n \"Agent identity/auth\",\n \"Data formats/interop\",\n \"Policy/governance\"\n ]\n}\n```", "in_tok": 609, "out_tok": 386}
|
|
|
|
|
{"draft_name": "draft-intellinode-cats-in-network-scheduling", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"IntelliNode proposes in-network intelligent scheduling for distributed AI training/inference by integrating FPGAs and programmable switches to create a closed-loop perception-inference-decision-execution system aware of tensor semantics and compute heterogeneity. It extends the CATS framework to shift from passive probe-based scheduling to active data-plane intelligence.\",\n \"n\": 2,\n \"nn\": \"Incremental extension of CATS framework; in-network intelligence and awareness of compute heterogeneity are not novel concepts, though their specific combination for tensor-aware scheduling has some merit.\",\n \"m\": 2,\n \"mn\": \"Early sketch stage\u2014defines four functional layers and signaling conceptually but lacks protocol details, message formats, state machine specifications, or any implementation evidence despite 6-page limit being generous.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing work on in-network computing (P4, NetCache, programmable dataplane ML), CATS framework extensions, and ML-aware networking (MLPerf, tensor routing). The 'closed-loop' framing is not distinctly novel.\",\n \"m\": 1,\n \"mon\": \"No clear momentum indicators\u2014single draft snapshot from 2026 with no revision history, WG adoption signals, or implementation roadmap provided; appears speculative.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to ML traffic management, model serving/inference, and autonomous network operations; core focus on AI cluster scheduling makes it squarely in the AI/networking intersection.\",\n \"c\": [\n \"ML traffic mgmt\",\n \"Model serving/inference\",\n \"Autonomous netops\"\n ]\n}\n```", "in_tok": 736, "out_tok": 399}
|
|
|
|
|
{"draft_name": "draft-li-dmsc-mcps-agw", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes a multi-agent collaboration protocol suite using Agent Gateways as control-plane entities to manage registration, authentication, and semantic routing while enabling peer-to-peer interactions. Addresses scalability and security in distributed agent networks across heterogeneous systems.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution combining existing concepts (gateway architectures, semantic routing, agent registration) without substantial technical innovation beyond established patterns in service meshes and API gateways.\",\n \"m\": 2,\n \"mn\": \"Early sketch stage; 7 pages insufficient for protocol specification. Lacks formal syntax, state machines, message formats, error handling procedures, and implementation guidance needed for maturity.\",\n \"o\": 4,\n \"on\": \"Significant overlap with service mesh architectures (Istio), API gateway patterns, and existing agent communication frameworks. Gateway-based control planes and semantic routing are well-established concepts.\",\n \"mo\": 1,\n \"mon\": \"Single dated revision (2026-02-06) with no evidence of WG adoption, community discussion, or iterative development. No apparent momentum in IETF process.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to AI agent infrastructure but positions itself as networking protocol rather than core agent technology. Relevant primarily as operational infrastructure, not agent capability or intelligence.\",\n \"c\": [\n \"A2A protocols\",\n \"Agent discovery/reg\",\n \"Agent identity/auth\",\n \"Autonomous netops\",\n \"Data formats/interop\"\n ]\n}\n```", "in_tok": 546, "out_tok": 370}
|
|
|
|
|
{"draft_name": "draft-ietf-dnsop-dnssec-bootstrapping", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft proposes an authenticated in-band mechanism for DNS operators to securely publish DNSSEC key parameters (CDS/CDNSKEY records) that enables parent registries to cryptographically validate and provision DS records without out-of-band verification. It establishes a preferred DNSSEC bootstrapping method for zones not yet securely delegated.\",\n \"n\": 3,\n \"nn\": \"Incremental improvement on existing DNSSEC enrollment mechanisms (RFC 8078, RFC 7344); introduces authenticated signal approach but builds on established DS/CDS/CDNSKEY concepts rather than fundamentally new architecture.\",\n \"m\": 4,\n \"mn\": \"Well-defined protocol mechanism with clear operational procedures; updates to RFCs indicate mature specification; lacks extensive implementation examples or test vectors for top-tier maturity.\",\n \"o\": 3,\n \"on\": \"Shares core concepts with RFC 8078 and RFC 7344 DNSSEC enrollment work; addresses known limitations in existing approaches but operates within established DNSSEC framework without novel technical departures.\",\n \"mo\": 3,\n \"mon\": \"Active IETF WG collaboration with public GitHub repository indicates ongoing development; single 2024 revision suggests steady but not rapid progression; typical for niche DNS operations topic.\",\n \"r\": 1,\n \"rn\": \"Not relevant to AI/agents; this is purely DNS infrastructure security and DNSSEC key management. No connection to autonomous agents, AI safety, or agent protocols.\",\n \"c\": [\n \"Other AI/agent\"\n ]\n}\n```", "in_tok": 770, "out_tok": 377}
|
|
|
|
|
{"draft_name": "draft-crovia-seal", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Crovia Seal v1 is a cryptographic receipt format for recording provenance of AI-generated outputs through Ed25519-signed JSON containing input/output digests, model metadata, timestamps, and hash chains. The format supports offline verification, transparency log inclusion, and witness co-signatures for tamper-evident attestation.\",\n \"n\": 3,\n \"nn\": \"Applies established cryptographic primitives (Ed25519, SHA-256, hash chains) to a timely problem domain (AI output provenance), but lacks novel cryptographic or protocol innovations; similar to existing supply-chain signing schemes adapted for AI context.\",\n \"m\": 4,\n \"mn\": \"Well-defined protocol specification with explicit canonicalization rules, domain separation, and optional extension fields; appears implementation-ready but lacks test vectors, code examples, or interoperability validation.\",\n \"o\": 3,\n \"on\": \"Shares architectural concepts with X.509/PKI attestation formats and supply-chain provenance systems (SLSA, in-toto); distinct but analogous to emerging AI model card and disclosure standards.\",\n \"mo\": 2,\n \"mon\": \"Single draft from May 2026 with no visible WG sponsorship, related RFCs, or implementation ecosystem; early-stage proposal without demonstrated adoption or community iteration.\",\n \"r\": 5,\n \"rn\": \"Directly addresses critical AI safety and accountability requirement\u2014cryptographic proof of AI system involvement in content generation\u2014essential for agent identity, auditability, and policy enforcement.\",\n \"c\": [\"Agent identity/auth\", \"Data formats/interop\", \"Policy/governance\", \"AI safety/alignment\"]\n}\n```", "in_tok": 660, "out_tok": 391}
|
|
|
|
|
{"draft_name": "draft-diaconu-agents-authz-info-sharing", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Addresses authorization information sharing across distributed multi-agent systems spanning multiple administrative domains with different identity providers. Proposes using dynamic identity, interoperable claims, and verifiable credentials to enable secure cross-domain authorization.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution combining existing OAuth/OIDC patterns with agent-specific scenarios; verifiable credentials approach is established elsewhere\",\n \"m\": 2,\n \"mn\": \"Early-stage draft presenting challenges and solution approaches without detailed protocol specification or implementation guidance\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing OAuth2.0/OIDC federation specs, SAML assertions, and W3C verifiable credentials work; limited novel integration\",\n \"mo\": 2,\n \"mon\": \"Single revision dated 2026-02-06 with no evidence of working group adoption or iterative community refinement\",\n \"r\": 4,\n \"rn\": \"Directly relevant to agent systems requiring cross-domain trust and authorization; addresses practical multi-agent deployment challenges\",\n \"c\": [\"Agent identity/auth\", \"A2A protocols\", \"Data formats/interop\", \"Policy/governance\"]\n}\n```", "in_tok": 538, "out_tok": 287}
|
|
|
|
|
{"draft_name": "draft-zm-rtgwg-mcp-network-measurement", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes using Model Context Protocol (MCP) to enable AI-assisted network measurement by treating network devices as MCP servers and controllers/LLMs as clients. Framework aims to provide natural language-driven operations for performance monitoring, fault diagnosis, and topology discovery.\",\n \"n\": 2,\n \"nn\": \"Incremental application of MCP to network operations; combines existing technologies (MCP + network telemetry) without fundamental innovation in either domain.\",\n \"m\": 2,\n \"mn\": \"Early sketch stage with architectural description but lacks protocol specifications, formal message definitions, implementation details, or interoperability examples.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing NETCONF/YANG management frameworks and emerging AI-agent-for-networking proposals; MCP application to network ops is conceptually straightforward reuse of existing patterns.\",\n \"mo\": 1,\n \"mon\": \"Single draft with 2026 date (likely future-dated); no evidence of WG adoption, prior revisions, or community discussion; appears exploratory rather than actively developed.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI agent applications in networking and human-agent interaction for operations, though focuses on instrumental use rather than core agent protocols.\",\n \"c\": [\"A2A protocols\", \"Autonomous netops\", \"Data formats/interop\", \"Human-agent interaction\", \"Agent discovery/reg\"]\n}\n```", "in_tok": 601, "out_tok": 339}
|
|
|
|
|
{"draft_name": "draft-hood-independent-atp", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"ATP proposes a dedicated application-layer protocol for AI agent traffic, adding agent-native intent methods and identity mechanisms beyond HTTP. It positions itself as a transport-level solution complementary to existing messaging-layer agent protocols like MCP and ACP.\",\n \"n\": 2,\n \"nn\": \"Incremental approach\u2014applies familiar HTTP-like semantics (methods, status codes, headers) to agent-specific use cases rather than introducing fundamentally new abstractions. The core insight (agents need protocol-level identity and intent semantics) is sound but the execution is conventional.\",\n \"m\": 3,\n \"mn\": \"Defined protocol with stated method vocabulary and transport requirements (QUIC/TCP/TLS), but abstract. Missing implementation examples, test vectors, error handling specifics, and deployment guidance that would indicate production readiness.\",\n \"o\": 4,\n \"on\": \"Significant conceptual overlap with MCP (Model Context Protocol) and other A2A frameworks\u2014those already layer intent semantics and identity. The claimed distinction (transport vs. messaging layer) is valid but blurs in practice; MCP over HTTP already solves many stated problems.\",\n \"m\": 2,\n \"mn\": \"Single draft, March 2026 date suggests speculative/future-dated work. No evidence of WG adoption, community discussion, or iterative refinement. Appears early-stage with no revision history visible.\",\n \"r\": 4,\n \"rn\": \"Directly addresses agent traffic differentiation and observability\u2014core concerns in AI ops. Highly relevant to scaling agentic systems, though the framing as a new protocol rather than HTTP extension/profile may limit adoption appeal.\",\n \"c\": [\n \"A2A protocols\",\n \"Agent identity/auth\",\n \"ML traffic mgmt\",\n \"Autonomous netops\",\n \"Agent discovery/reg\",\n \"Data formats/interop\"\n ]\n}\n```", "in_tok": 717, "out_tok": 449}
|
|
|
|
|
{"draft_name": "draft-ietf-savnet-inter-domain-architecture", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft proposes an inter-domain architecture for Source Address Validation (SAV) at the AS level, enabling ASes to generate accurate SAV rules by sharing SAV-specific information while maintaining fallback to general information during partial deployment. The architecture focuses on information types and rule generation guidance rather than specific protocol implementations.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution that extends existing SAV concepts to inter-domain scenarios; adds architectural framing and information taxonomy but represents evolutionary rather than paradigm-shifting work in source validation.\",\n \"m\": 3,\n \"mn\": \"Well-defined architectural framework with clear component relationships and information models; lacks implementation details, test vectors, and concrete protocol specifications that would indicate production readiness.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing SAVNET work and source validation literature; largely synthesizes known SAV principles into an architectural model without substantial novel mechanisms.\",\n \"mo\": 4,\n \"mon\": \"Active WG development with multiple related drafts in SAVNET; clear community interest and iterative refinement suggesting sustained momentum within the standardization process.\",\n \"r\": 1,\n \"rn\": \"Network security and routing validation topic with no connection to AI agents, autonomous systems in the ML sense, or agent-based technologies; false positive for this evaluation framework.\",\n \"c\": [\"Other AI/agent\"]\n}\n```", "in_tok": 657, "out_tok": 327}
|
|
|
|
|
{"draft_name": "draft-fluid-fadp", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"FADP proposes HTTP 402-based micropayment authentication for autonomous AI agents using on-chain cryptocurrency proofs embedded in headers. It targets sub-dollar AI agent-to-server transactions with nonce-challenge replay protection and optional third-party verification.\",\n \"n\": 2,\n \"nn\": \"Incremental extension of HTTP 402 with cryptocurrency integration; combines existing payment verification patterns with agent use cases rather than introducing novel cryptographic or protocol mechanisms.\",\n \"m\": 3,\n \"mn\": \"Protocol definition is present with header specifications and nonce mechanism, but lacks detailed implementation examples, test vectors, error handling edge cases, and security analysis of payment verification.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing payment gateways (Stripe, Alchemy), blockchain verification services, and OAuth/token-based auth patterns; HTTP 402 itself is underutilized but not novel; DeFi payment channels already address micropayments.\",\n \"mo\": 1,\n \"mon\": \"Single draft publication dated 2026-04-23 with no visible revision history, community discussion, or implementation adoption signals; no WG sponsorship evident.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to autonomous agents; focuses narrowly on payment authentication rather than broader agent coordination, capability negotiation, or safety concerns; solves a specific economic flow rather than core agent architecture.\",\n \"c\": [\n \"A2A protocols\",\n \"Agent identity/auth\",\n \"Data formats/interop\",\n \"Model serving/inference\"\n ]\n}\n```", "in_tok": 742, "out_tok": 377}
|
|
|
|
|
{"draft_name": "draft-kwiatkowski-tls-ecdhe-mlkem", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Defines three hybrid key agreement mechanisms for TLS 1.3 combining post-quantum KEMs (ML-KEM) with classical elliptic curve Diffie-Hellman to provide cryptographic agility during the transition to post-quantum cryptography. Addresses immediate standardization needs for quantum-safe TLS without abandoning proven ECC security.\",\n \"n\": 2,\n \"nn\": \"Incremental combination of existing standards (ML-KEM, ECDHE); straightforward hybrid construction following established patterns from NIST and IETF guidance.\",\n \"m\": 4,\n \"mn\": \"Well-defined protocol specifications with clear parameter combinations and integration points into TLS 1.3 framework; appears implementation-ready but lacks test vectors and interoperability data.\",\n \"o\": 4,\n \"on\": \"Significant overlap with concurrent IETF efforts (draft-ietf-tls-hybrid-design, RFC 9180 hybrid KEM patterns); similar combinations being standardized by NIST and other WGs.\",\n \"mo\": 3,\n \"mon\": \"Active standardization momentum in post-quantum TLS space; timing aligns with NIST ML-KEM finalization and industry transition pressure, though specific draft revision activity unclear.\",\n \"r\": 1,\n \"rn\": \"Not relevant to AI agents or autonomous systems; purely cryptographic protocol specification for classical TLS infrastructure.\",\n \"c\": [\"Other AI/agent\"]\n}\n```", "in_tok": 542, "out_tok": 352}
|
|
|
|
|
{"draft_name": "draft-stone-adrp", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"ADRP defines a dispute resolution protocol for cryptographically-attested agent-to-agent transactions, separating cryptographic proof verification from contractual satisfaction through a bifurcated dispute model with arbitration mandates. The protocol introduces counter-attestation overrides and aims to be FAA Section 2-compliant without statutory changes.\",\n \"n\": 4,\n \"nn\": \"Novel conceptual contribution distinguishing proof validity from intent satisfaction in agentic systems; the counter-attestation override pattern and arbitration mandate chain represent original approaches to dispute resolution in autonomous agent transactions.\",\n \"m\": 2,\n \"mn\": \"Early sketch phase\u2014abstract defines concepts and high-level mechanisms but 35 pages likely lacks detailed state machine diagrams, message formats, test vectors, or implementation guidance needed for protocol maturity.\",\n \"o\": 2,\n \"on\": \"Minor similarities to existing blockchain dispute resolution and smart contract arbitration patterns; approach to agent transaction verification appears relatively distinct from prior work.\",\n \"mo\": 2,\n \"mon\": \"Single draft submission with dependency on companion specs (ATXN, AIVS) still in WIP status; no evidence of WG adoption, implementation, or community feedback yet.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI agent coordination and autonomous transaction semantics; addresses critical gap in agent protocol design (proof \u2260 satisfaction) but focuses on legal/dispute layer rather than core agent capabilities.\",\n \"c\": [\n \"A2A protocols\",\n \"Policy/governance\",\n \"Agent identity/auth\",\n \"Data formats/interop\",\n \"Human-agent interaction\"\n ]\n}\n```", "in_tok": 957, "out_tok": 395}
|
|
|
|
|
{"draft_name": "draft-benzing-accp", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"ACCP proposes a semantic compression protocol for AI agent communication achieving 60-90% token reduction through compact message formats and context management. Designed as transport-agnostic complement to MCP and A2A protocols, it combines intent ontology with state compression strategies.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution; token compression via encoding is established practice (e.g., protobuf, msgpack). Semantic compression specific to agents is somewhat novel but builds directly on existing compression and ontology concepts.\",\n \"m\": 2,\n \"mn\": \"Early sketch stage. Abstract describes goals and claimed metrics but 23 pages likely insufficient for detailed protocol specification, codec interface implementation details, or test vectors. No indication of reference implementation.\",\n \"o\": 4,\n \"on\": \"Significant overlap with MCP (tool use, context), Protocol Buffers (compression), and semantic web standards (ontology). Claims to 'complement' MCP/A2A but core compression problem is well-explored in distributed systems; positioning relative to existing solutions unclear.\",\n \"mo\": 1,\n \"mon\": \"Single draft revision (2026-04-07 date suggests recent submission). No evidence of WG discussion, multiple iterations, or community adoption. Early-stage with unclear publication timeline.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI agent infrastructure. Token efficiency is genuine concern for multi-agent systems at scale. However, relevance depends heavily on whether ACCP solves real deployment bottlenecks vs. academic optimization.\",\n \"c\": [\n \"A2A protocols\",\n \"Data formats/interop\",\n \"ML traffic mgmt\",\n \"Agent discovery/reg\"\n ]\n}\n```", "in_tok": 558, "out_tok": 409}
|
|
|
|
|
{"draft_name": "draft-smith-opsawg-ai-network-governance", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes a 13-point governance framework for AI/LLM-based autonomous network device management systems, establishing safety principles around human authority, harm prevention, bounded autonomy, and escalation. Addresses the gap in industry standards as autonomous AI moves from advisory to closed-loop production operations.\",\n \"n\": 3,\n \"nn\": \"Framework approach is useful but governance principles for autonomous systems are well-established in robotics, safety-critical systems, and recent AI policy work; the network-specific application is incremental rather than fundamentally novel.\",\n \"m\": 3,\n \"mn\": \"Defines governance areas clearly with good principle coverage, but lacks concrete implementation mechanisms, technical controls, enforcement methods, or testable compliance criteria; reads as reference architecture rather than actionable specification.\",\n \"o\": 3,\n \"on\": \"Shares conceptual overlap with NIST AI RMF, CPS safety frameworks, and autonomous systems governance (ISO 26262, DO-178C); governance principles themselves are not new, though network-specific application differentiates somewhat.\",\n \"mo\": 2,\n \"mon\": \"Single draft submission in March 2026 with no evidence of WG sponsorship, prior iterations, or community feedback cycle; unclear if this reflects early-stage work or exploratory submission.\",\n \"r\": 4,\n \"rn\": \"Highly relevant to autonomous netops and AI safety concerns; directly addresses agent autonomy constraints and human oversight, though positioned as governance rather than technical protocol specification.\",\n \"c\": [\n \"Policy/governance\",\n \"Autonomous netops\",\n \"AI safety/alignment\",\n \"Human-agent interaction\"\n ]\n}\n```", "in_tok": 654, "out_tok": 393}
|
|
|
|
|
{"draft_name": "draft-jeong-opsawg-intent-based-sdv-framework", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes an intent-based management framework for Software-Defined Vehicles that abstracts network, security, and application configuration to enable safe autonomous vehicle communication and infotainment services in ITS environments.\",\n \"n\": 2,\n \"nn\": \"Intent-based management is well-established; applying it to SDVs is incremental rather than introducing novel concepts or mechanisms.\",\n \"m\": 2,\n \"mn\": \"Early-stage framework document with abstract concepts but limited concrete protocol definitions, architecture details, or implementation guidance.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing intent-based networking (IBN) frameworks, ONAP, and cloud-native vehicle platforms; limited differentiation from prior work.\",\n \"mo\": 1,\n \"mon\": \"Single draft submission with December 2025 expiration; no evidence of active revision cycle, WG engagement, or community interest.\",\n \"r\": 2,\n \"rn\": \"Tangentially related to agent autonomy; focuses on vehicle network management rather than AI agent behavior, decision-making, or coordination protocols.\",\n \"c\": [\n \"Autonomous netops\",\n \"Policy/governance\",\n \"Data formats/interop\"\n ]\n}\n```", "in_tok": 610, "out_tok": 299}
|
|
|
|
|
{"draft_name": "draft-dembowski-agentledger-proof-of-behavior", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Defines a tamper-evident audit protocol (PoB) for verifying autonomous AI agent behavior compliance with declared policies through signed receipts, hash chains, and pre-execution policy gates. Addresses the gap between agent execution and auditability in systems where agents perform privileged actions on behalf of humans.\",\n \"n\": 4,\n \"nn\": \"Applying blockchain-style hash chains and signed receipts to AI agent auditability is relatively novel; combining pre-execution policy gates with tamper-evident trails targets a genuine gap, though individual components (audit logs, policy enforcement) are established patterns.\",\n \"m\": 2,\n \"mn\": \"Draft reads as early sketch with abstract concepts (signed receipt format, policy gate contract, cross-agent reference mechanism) but lacks concrete protocol definitions, message schemas, state machine diagrams, or implementation examples needed for a working spec.\",\n \"o\": 3,\n \"on\": \"Shares concepts with existing audit logging (syslog, CEF), policy enforcement frameworks (XACML, OPA), and distributed trust models (blockchain ledgers, signed certificates), but specific combination for AI agents is not widely standardized.\",\n \"m\": 1,\n \"mon\": \"No evidence of WG adoption, multiple revisions, or community discussion; appears to be a solo submission with no indicated iterative development or external feedback cycles.\",\n \"r\": 5,\n \"rn\": \"Directly targets core AI agent governance challenge: post-hoc verification of agent behavior compliance and action authenticity\u2014critical for deployment in regulated/high-stakes domains.\",\n \"c\": [\n \"AI safety/alignment\",\n \"Agent identity/auth\",\n \"Policy/governance\",\n \"A2A protocols\",\n \"Data formats/interop\"\n ]\n}\n```", "in_tok": 621, "out_tok": 416}
|
|
|
|
|
{"draft_name": "draft-liu-dmsc-acps-arc", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes Agent Collaboration Protocols (ACPs) architecture to enable interconnection and secure collaboration among heterogeneous AI agents across registration, authentication, discovery, interaction, and monitoring stages. Aims to establish foundational infrastructure for Internet of Agents (IoA) ecosystems.\",\n \"n\": 2,\n \"nn\": \"Combines existing concepts (service discovery, authentication, registration) applied to agent context; lacks genuinely novel architectural contributions or protocols.\",\n \"m\": 2,\n \"mn\": \"Early-stage conceptual framework with functional component descriptions but no detailed protocol specifications, message formats, or implementation guidance.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing IETF work on service discovery (mDNS, DNS-SD), identity management (RATS, ZTNA), and IoT protocols; conceptually similar to agent mesh architectures already explored.\",\n \"mo\": 1,\n \"mon\": \"Single draft revision, no evidence of WG adoption or community engagement; appears to be exploratory work without iterative refinement.\",\n \"r\": 4,\n \"rn\": \"Directly addresses emerging need for agent-to-agent protocols and infrastructure, though framing as 'Internet of Agents' may oversell current maturity of autonomous agent ecosystems.\",\n \"c\": [\n \"A2A protocols\",\n \"Agent identity/auth\",\n \"Agent discovery/reg\",\n \"Data formats/interop\",\n \"Policy/governance\"\n ]\n}\n```", "in_tok": 609, "out_tok": 358}
|
|
|
|
|
{"draft_name": "draft-liu-rtgwg-agent-gateway-requirements", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft proposes Agent Gateway requirements to improve scalability and security in agent-to-agent communications, identifying gaps in current gateway implementations. It establishes design principles for a new entity type to facilitate agent networking.\",\n \"n\": 2,\n \"nn\": \"Incremental refinement of gateway concepts applied to agent contexts; straightforward extension of existing networking infrastructure ideas without fundamental innovation.\",\n \"m\": 2,\n \"mn\": \"Early-stage requirements document lacking protocol specifications, implementation details, or concrete mechanisms; presents problem statement but minimal technical depth.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing API gateway, service mesh, and IoT gateway specifications; concepts largely map to established networking patterns adapted for agent terminology.\",\n \"mo\": 1,\n \"mon\": \"Single revision with no evidence of WG adoption, implementation activity, or community engagement; appears exploratory without sustained development trajectory.\",\n \"r\": 2,\n \"rn\": \"Tangentially related to AI agents; primarily addresses networking infrastructure rather than agent behavior, learning, or autonomous decision-making; uses 'agent' as network entity rather than AI-centric definition.\",\n \"c\": [\n \"A2A protocols\",\n \"Agent identity/auth\",\n \"Autonomous netops\",\n \"Data formats/interop\",\n \"Agent discovery/reg\"\n ]\n}\n```", "in_tok": 526, "out_tok": 325}
|
|
|
|
|
{"draft_name": "draft-kotecha-agentic-dispute-protocol", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"ADP proposes a standardized protocol for autonomous agents to file, process, and resolve disputes through automated mechanisms with cryptographic proof and auditable outcomes. It addresses AI agent interactions, SLA breaches, and contract enforcement with support for multiple resolution frameworks.\",\n \"n\": 2,\n \"nn\": \"Incremental combination of existing dispute resolution concepts (arbitration, mediation, evidence submission) applied to agent scenarios; core mechanisms not novel but domain application is relatively new.\",\n \"m\": 3,\n \"mn\": \"Defined protocol with specified message formats, transport mechanisms, and procedural components; lacks implementation details, test vectors, and concrete examples of real-world agent dispute scenarios.\",\n \"o\": 4,\n \"on\": \"Significant conceptual overlap with existing dispute resolution standards (ODR, arbitration protocols) and agent communication frameworks; appears to synthesize rather than innovate technically.\",\n \"mo\": 1,\n \"mon\": \"Draft dated 2026-04-16 (future date raises credibility concerns); no evidence of WG adoption, revisions, or community engagement; likely early-stage or speculative work.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to agent-to-agent protocols and autonomous systems coordination; addresses real pain point of dispute handling in multi-agent systems, though applicability depends on adoption of autonomous agents in production.\",\n \"c\": [\n \"A2A protocols\",\n \"Agent identity/auth\",\n \"Data formats/interop\",\n \"Policy/governance\",\n \"Agent discovery/reg\"\n ]\n}\n```", "in_tok": 619, "out_tok": 372}
|
|
|
|
|
{"draft_name": "draft-zhang-rtgwg-ai-agents-measurement", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft proposes use cases and requirements for communication protocols enabling measurement agents deployed on network devices. It addresses the need for standardized communication mechanisms for AI/ML-based network measurement and telemetry collection.\",\n \"n\": 2,\n \"nn\": \"Incremental work applying existing agent communication concepts to network measurement; limited technical novelty beyond stating requirements for a new protocol domain.\",\n \"m\": 2,\n \"mn\": \"Early-stage requirement document; presents use cases and high-level requirements but lacks protocol specification, detailed mechanisms, or implementation guidance.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing IETF work on network telemetry (YANG, NETCONF), agent frameworks (OPSAWG), and measurement protocols; positioning relative to existing standards unclear.\",\n \"mo\": 2,\n \"mon\": \"Single draft revision with limited evidence of working group traction or community engagement; future publication momentum uncertain.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to AI agents in networking; focuses on measurement infrastructure rather than core AI agent capabilities, decision-making, or autonomy.\",\n \"c\": [\"Autonomous netops\", \"Agent discovery/reg\", \"Data formats/interop\", \"A2A protocols\"],\n \"meta\": \"Draft quality hindered by unclear differentiation from existing telemetry standards and lack of concrete protocol proposal. May benefit from repositioning as requirements analysis for autonomous network operations rather than standalone protocol work.\"\n}\n```", "in_tok": 477, "out_tok": 348}
|
|
|
|
|
{"draft_name": "draft-sogomonian-ai-uri-scheme", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes an experimental 'ai' URI scheme to provide dedicated access for AI resources and autonomous systems, with HTTPS gateways for human-facing applications. Aims to enable native connectivity between robots and AI services while maintaining interoperability.\",\n \"n\": 2,\n \"nn\": \"Straightforward application of URI scheme mechanics to AI domain; lacks technical depth beyond existing URI RFC framework and does not introduce novel addressing or discovery mechanisms.\",\n \"m\": 2,\n \"mn\": \"Early-stage sketch with abstract description; 6 pages insufficient for protocol specification, missing syntax definition, gateway architecture details, security considerations, and implementation guidelines.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing agent communication frameworks (CoAP, XMPP, custom protocols); URI schemes for specialized domains well-established; HTTPS gateway pattern conventional; minimal differentiation from prior art.\",\n \"mo\": 1,\n \"mon\": \"Single draft submission with no evident revision history, working group discussion, or implementation interest; no clear pathway to standardization or adoption.\",\n \"r\": 3,\n \"rn\": \"Tangentially addresses agent interoperability but lacks focus on core AI challenges like safety, alignment, or intelligent resource negotiation; treats symptoms (URI routing) rather than fundamental agent coordination problems.\",\n \"c\": [\n \"A2A protocols\",\n \"Agent identity/auth\",\n \"Agent discovery/reg\",\n \"Data formats/interop\",\n \"Human-agent interaction\"\n ]\n}\n```", "in_tok": 509, "out_tok": 359}
|
|
|
|
|
{"draft_name": "draft-kartha-grd", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft identifies an architectural gap in Internet resource discovery for geospatial applications (AR, robotics, autonomous systems) where discovery begins from physical location rather than predefined identifiers. It proposes a conceptual architecture for Geospatial Resource Discovery (GRD) but remains at the problem statement level without protocol or implementation details.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution; applies existing discovery patterns to spatial context, though the framing for emerging applications adds some value\",\n \"m\": 1,\n \"mn\": \"Purely informational problem statement and architecture; no protocol definition, data formats, or implementation details provided\",\n \"o\": 3,\n \"on\": \"Shares conceptual overlap with geolocation services, local discovery protocols (mDNS, DNS-SD), and spatial computing frameworks; positions itself as distinct but relationships to existing work unclear\",\n \"mo\": 2,\n \"mon\": \"Single early-stage draft from January 2026; no indication of WG adoption, multiple revisions, or broader community engagement\",\n \"r\": 3,\n \"rn\": \"Partially relevant to AI agents; directly applicable to autonomous systems and robotics agents requiring spatial discovery, but not core to agent protocols or AI safety concerns\",\n \"c\": [\n \"Agent discovery/reg\",\n \"Data formats/interop\",\n \"Autonomous netops\",\n \"Other AI/agent\"\n ]\n}\n```", "in_tok": 635, "out_tok": 344}
|
|
|
|
|
{"draft_name": "draft-dunbar-onsen-ac-pe2pe-ucmp-applicability", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft evaluates how existing IETF YANG data models (AC, TE Topology, SR Policy, QoS) can support dynamic, time-scoped UCMP policies for AI inference workloads distributed across edge cloud sites. It identifies gaps in model expressiveness, policy lifecycle handling, and cloud-network API abstraction needed for real-time coordination.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution applying existing YANG models to a specific use case; the technical approach is straightforward mapping of known models to edge cloud requirements without fundamental methodological innovation.\",\n \"m\": 2,\n \"mn\": \"Early-stage applicability study; identifies problems and gaps but lacks concrete protocol extensions, implementation details, or test vectors demonstrating solutions to the identified limitations.\",\n \"o\": 3,\n \"on\": \"Shares core concepts with existing work on YANG-based network policy management, SR policies, and QoS modeling; some overlap with cloud-network integration efforts but with specific focus on UCMP and time-scoped policies.\",\n \"mo\": 2,\n \"mon\": \"Single revision draft from 2026 with limited indication of WG adoption or community momentum; appears to be exploratory work rather than active standardization effort.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to AI infrastructure; addresses ML workload distribution and network optimization for inference services, but focuses on low-level network policy mechanisms rather than AI agent coordination or decision-making.\",\n \"c\": [\n \"ML traffic mgmt\",\n \"Autonomous netops\",\n \"Data formats/interop\",\n \"Policy/governance\"\n ]\n}\n```", "in_tok": 677, "out_tok": 392}
|
|
|
|
|
{"draft_name": "draft-nivalto-agentroa-route-authorization", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"AgentROA proposes a cryptographic policy enforcement framework for AI agent actions, modeled on BGP RPKI, using signed policy envelopes (ROA), per-hop attestations (ARA), and execution receipts (AER) to enforce scope-narrowing authorization across agent delegation chains. It positions enforcement at capability invocation boundaries external to agent execution contexts via a topology-independent 'Border Gateway' model deployable as proxies, service mesh components, or gateways.\",\n \"n\": 2,\n \"nn\": \"Applies established RPKI ROA concepts to agent authorization with incremental adaptation; cryptographic binding and delegation chain semantics are useful but not fundamentally novel.\",\n \"m\": 3,\n \"mn\": \"Establishes architectural model and protocol object schemas with defined enforcement semantics, but lacks implementation details, test vectors, or concrete deployment examples needed for production readiness.\",\n \"o\": 3,\n \"on\": \"Shares policy enforcement and delegation concepts with existing agent frameworks; cryptographic receipts resemble audit logging; overlaps partially with MCP server governance discussions but addresses a specific niche.\",\n \"mo\": 1,\n \"mon\": \"Single dated draft (2026-04-16) with no evidence of WG adoption, community discussion, or revision history; appears to be initial submission without momentum signals.\",\n \"r\": 4,\n \"rn\": \"Directly addresses AI agent authorization and governance, core concerns for agent deployment; however, assumes specific threat models (agent influence on enforcement) that may not generalize across all use cases.\",\n \"c\": [\n \"Agent identity/auth\",\n \"Policy/governance\",\n \"A2A protocols\",\n \"AI safety/alignment\"\n ]\n}\n```", "in_tok": 879, "out_tok": 407}
|
|
|
|
|
{"draft_name": "draft-sharif-mcps-secure-mcp", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"MCPS proposes a cryptographic security layer for MCP using ECDSA P-256 signatures, agent identity verification, and replay protection without modifying core protocol. The design is backward-compatible and negotiates security through progressive trust levels L0-L4.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution applying established cryptographic patterns (ECDSA, JCS canonicalization) to MCP. Core concepts (message signing, identity verification, replay protection) are well-trodden; novelty limited to domain-specific envelope design.\",\n \"m\": 4,\n \"mn\": \"Detailed specification with four well-defined primitives, explicit trust level progression, canonical encoding choices (RFC 8785, RFC 7518), and self-hostable Trust Authority. Missing test vectors and reference implementation code for full readiness.\",\n \"o\": 3,\n \"on\": \"Shares conceptual overlap with JOSE/JWS (message signing), PKIX identity binding, and nonce-based replay protection schemes. However, MCP-specific envelope framing and progressive trust negotiation provide modest differentiation from generic TLS/mTLS alternatives.\",\n \"m\": 2,\n \"mon\": \"Single draft revision (2026-03-14), no indication of WG adoption or community feedback. MCP itself is Anthropic-proprietary; unclear if IETF standardization path has institutional backing or will attract cross-organizational interest.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI agent security. Addresses real threat model (tool tampering, replay, identity spoofing) for agent-to-service communication. Core relevance to agent identity/auth and interoperability, though assumes MCP adoption trajectory.\",\n \"c\": [\n \"A2A protocols\",\n \"Agent identity/auth\",\n \"Data formats/interop\",\n \"AI safety/alignment\"\n ]\n}\n```", "in_tok": 812, "out_tok": 455}
|
|
|
|
|
{"draft_name": "draft-zzn-dvs", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"DVS defines a lightweight protocol for AI agents to discover and verify skill definitions (task instructions) served over HTTPS, deriving trust entirely from URL origin and TLS rather than centralized registries. Skills are verified if their URLs match a declared Trust Root prefix, leveraging existing DNS/TLS infrastructure for backward compatibility.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution applying existing web trust models (domain ownership via DNS/TLS) to AI agent skill distribution; conceptually straightforward but addresses a practical coordination problem.\",\n \"m\": 3,\n \"mn\": \"Defined protocol mechanism with clear trust model and path-scoping rules, but limited evidence of implementation details, validation logic, or error handling specifications in 12-page draft.\",\n \"o\": 3,\n \"on\": \"Shares trust-by-URL-origin concept with package management (npm, PyPI) and general web security models; related to agent capability discovery standards but no direct standard overlap identified.\",\n \"mo\": 1,\n \"mon\": \"Single draft from March 2026 with no evident revision history, WG sponsorship, or community adoption signals; appears exploratory stage.\",\n \"r\": 4,\n \"rn\": \"Directly addresses AI agent skill discovery and execution, core to agent orchestration and capability management, though framed narrowly around SKILL.md format rather than broader agent coordination.\",\n \"c\": [\"Agent discovery/reg\", \"Agent identity/auth\", \"Data formats/interop\", \"A2A protocols\"]\n}\n```", "in_tok": 787, "out_tok": 358}
|
|
|
|
|
{"draft_name": "draft-jiang-intent-security", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Analyzes security threats in intent-based request systems where user goals are translated into executable directives across multiple agents and endpoints. Proposes a reference model addressing constraint validation, privilege escalation, tampering, and intent drift without targeting specific domains.\",\n \"n\": 3,\n \"nn\": \"Incremental contribution\u2014applies established security threat modeling to emerging intent-based architectures; core concepts (tampering, privilege escalation, chain-of-custody) are well-known but domain application is useful.\",\n \"m\": 2,\n \"mn\": \"Early sketch phase\u2014presents threat taxonomy and security requirements but lacks concrete protocol specifications, implementation guidance, or detailed validation mechanisms; reference model is conceptual.\",\n \"o\": 3,\n \"on\": \"Moderate overlap with intent-driven system design literature and general multi-hop authorization frameworks; shares threat categories with existing security analyses of autonomous systems.\",\n \"m\": 2,\n \"mon\": \"Limited momentum\u2014single draft revision, April 2026 date suggests early stage; no evident WG adoption or community discussion; solution-agnostic framing may limit traction.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI agent security; addresses core risks in agentic systems but positioned as horizontal framework rather than AI-specific\u2014applies broadly to intent platforms.\",\n \"c\": [\"Agent identity/auth\", \"AI safety/alignment\", \"Policy/governance\", \"A2A protocols\"]\n}\n```", "in_tok": 642, "out_tok": 341}
|
|
|
|
|
{"draft_name": "draft-gaikwad-woa", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"WoA proposes a minimal JSON-based format for HTTP hosts to advertise AI agents and enable uniform client invocation, using JSON Schema for input/output description. It serves as a host-level primitive for higher-level discovery systems rather than defining discovery itself.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution combining existing concepts (JSON Schema, .well-known URIs, REST conventions) without substantial technical innovation.\",\n \"m\": 3,\n \"mn\": \"Defined protocol with clear structure and examples, but lacks implementation details, test vectors, error handling specifications, and security considerations depth.\",\n \"o\": 4,\n \"on\": \"Significant overlap with OpenAPI/Swagger (schema definition), ActivityPub (agent advertisement), and emerging agent protocol work (MASAI, OpenAI Agents); limited differentiation in scope.\",\n \"mo\": 1,\n \"mon\": \"Single revision as of submission date; no evidence of WG adoption, implementation ecosystem, or active community feedback cycle.\",\n \"r\": 4,\n \"rn\": \"Directly addresses agent interoperability and invocation, core to AI agent infrastructure, though framed more as operational tooling than agent capability specification.\",\n \"c\": [\n \"A2A protocols\",\n \"Agent discovery/reg\",\n \"Data formats/interop\",\n \"Model serving/inference\",\n \"Agent identity/auth\"\n ]\n}\n```", "in_tok": 560, "out_tok": 340}
|
|
|
|
|
{"draft_name": "draft-gaikwad-llm-benchmarking-profiles", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Defines performance benchmarking profiles for LLM serving systems by binding terminology and methodology to concrete architectural roles and workload patterns. Provides standardized SUT boundaries and measurement points for reproducible LLM benchmarking without defining new metrics or workloads.\",\n \"n\": 2,\n \"nn\": \"Incremental work applying existing benchmarking frameworks (from companion drafts) to LLM domain; profiles are formalization of common sense architectural roles rather than novel conceptual contribution.\",\n \"m\": 3,\n \"mn\": \"Well-defined profile specifications with clear SUT boundaries and measurement points, but depends on external terminology/methodology drafts (draft-gaikwad-llm-benchmarking-terminology/methodology) that would need concurrent maturity; no test vectors or validation examples provided.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing LLM benchmarking literature (MLCommons, HELM) and general benchmarking profile patterns; unclear what differentiates IETF profiles from industry standards beyond naming conventions.\",\n \"m\": 2,\n \"mon\": \"Single draft revision in series; unclear WG consensus or broader community adoption; LLM benchmarking not core IETF mission, limiting institutional momentum.\",\n \"r\": 3,\n \"rn\": \"Directly relevant to model serving infrastructure but peripheral to core agent protocol/behavior topics; benchmarking is operational concern rather than fundamental agent capability.\",\n \"c\": [\"Model serving/inference\", \"Data formats/interop\", \"Other AI/agent\"]\n}\n```", "in_tok": 602, "out_tok": 369}
|
|
|
|
|
{"draft_name": "draft-herbert-fast", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"FAST proposes a protocol using IPv6 Hop-by-Hop options to carry firewall and service tickets, allowing hosts to signal network nodes for admission and service requests. Tickets serve dual purposes: granting traversal rights and indicating desired network services.\",\n \"n\": 2,\n \"nn\": \"Incremental approach combining existing firewall concepts with service signaling; ticket-based mechanisms are not novel, though IPv6 Hop-by-Hop encapsulation is a reasonable choice.\",\n \"m\": 3,\n \"mn\": \"Defined protocol mechanism with ticket semantics described, but lacks implementation details, test vectors, and deployment guidance needed for full specification readiness.\",\n \"o\": 4,\n \"on\": \"Significant overlap with policy-based routing, QoS signaling mechanisms, and existing authorization protocols; conceptually similar to capability-based security and service negotiation in SDN contexts.\",\n \"mo\": 1,\n \"mon\": \"Single draft revision from April 2024 with no apparent WG sponsorship, community discussion, or implementation efforts evident; lacks adoption indicators.\",\n \"r\": 1,\n \"rn\": \"Not relevant to AI/agents; addresses generic network firewall and service admission signaling without connection to autonomous agents, ML systems, or AI applications.\",\n \"c\": [\"Other AI/agent\"]\n}\n```", "in_tok": 629, "out_tok": 320}
|
|
|
|
|
{"draft_name": "draft-ietf-dtn-dtnma", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Defines a management architecture for Delay-Tolerant Networks that operates asynchronously over the Bundle Protocol, enabling autonomous control and minimal footprint for constrained devices in challenged environments with long propagation delays and frequent disruptions.\",\n \"n\": 2,\n \"nn\": \"Incremental advancement tailoring existing management principles to DTN constraints; the architectural patterns (asynchronous, autonomous, lightweight) are established concepts applied to a specific transport protocol.\",\n \"m\": 4,\n \"mn\": \"Detailed specification with architectural definitions, operational models, and protocol requirements; appears implementation-ready with clear design patterns though test vectors not explicitly mentioned in abstract.\",\n \"o\": 2,\n \"on\": \"Minor similarities to existing constrained network management (CoAP, SNMP variations) but novel application to DTN Bundle Protocol's specific characteristics and unidirectional link constraints.\",\n \"mo\": 4,\n \"mon\": \"IETF WG document with active development cycle; DTN is established interest area with ongoing standardization efforts suggesting sustained community momentum.\",\n \"r\": 1,\n \"rn\": \"Not relevant to AI agents or autonomous AI systems; focuses on network device management in challenged environments, orthogonal to AI/ML agent architectures and behaviors.\",\n \"c\": [\"Other AI/agent\"]\n}\n```", "in_tok": 661, "out_tok": 310}
|
|
|
|
|
{"draft_name": "draft-aft-ai-traffic", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft identifies networking challenges specific to AI/LLM workloads in federated multi-datacenter deployments, addressing the unique communication patterns and bandwidth requirements of large language model training and inference. It establishes a problem statement for how service providers should coordinate AI services across datacenters given the distinctive characteristics of AI traffic.\",\n \"n\": 2,\n \"nn\": \"Identifying AI traffic as a distinct networking problem is somewhat incremental; prior work has discussed distributed training and inference challenges, though systematic problem framing for inter-DC AI scenarios is useful.\",\n \"m\": 1,\n \"mn\": \"This is explicitly a problem statement draft with no protocol specification, mechanisms, or implementation details\u2014early stage with focus on characterizing the problem space.\",\n \"o\": 3,\n \"on\": \"Shares conceptual overlap with existing IETF work on datacenter networking, ML systems optimization, and distributed training frameworks, but framed specifically for federated service provider scenarios.\",\n \"mo\": 2,\n \"mon\": \"Single revision timestamp (2025-10-13) suggests early draft status; no evidence of WG adoption or multiple iterations driving momentum.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI workload networking requirements and federated deployment models, though primarily a problem statement rather than proposing agent protocols or AI safety mechanisms.\",\n \"c\": [\"ML traffic mgmt\", \"Model serving/inference\", \"Policy/governance\", \"Data formats/interop\"]\n}\n```", "in_tok": 606, "out_tok": 347}
|
|
|
|
|
{"draft_name": "draft-chen-lake-edhoc-aka", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes EDHOC-AKA, combining AKA authentication with EDHOC key exchange using symmetric cryptography for resource-constrained mobile networks like NTN. Aims to improve authentication efficiency while maintaining mutual authentication and key derivation security.\",\n \"n\": 2,\n \"nn\": \"Incremental combination of existing protocols (AKA + EDHOC); lacks novel cryptographic or architectural contributions.\",\n \"m\": 2,\n \"mn\": \"Early sketch with abstract concepts; no detailed protocol specification, message flows, formal analysis, or implementation guidance provided.\",\n \"o\": 4,\n \"on\": \"Significant overlap with standard 3GPP AKA and EDHOC specifications; the integration appears straightforward without substantial differentiation.\",\n \"mo\": 1,\n \"mon\": \"Single revision, no evidence of WG engagement, community discussion, or adoption pathway.\",\n \"r\": 2,\n \"rn\": \"Tangentially related via agent authentication/identity; focuses on mobile network protocols rather than AI agent systems, frameworks, or autonomous operations.\",\n \"c\": [\"Agent identity/auth\", \"Other AI/agent\"]\n}\n```", "in_tok": 601, "out_tok": 281}
|
|
|
|
|
{"draft_name": "draft-mcp-over-moqt", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft proposes using MOQT (Media over QUIC Transport) as a transport layer for MCP (Model Context Protocol), enabling low-latency publish-subscribe delivery of MCP messages between language model applications and external tools/data sources. It maps MCP protocol semantics onto MOQT objects and defines session establishment procedures.\",\n \"n\": 2,\n \"nn\": \"Incremental combination of two existing protocols; the core contribution is straightforward message mapping without fundamental architectural innovation.\",\n \"m\": 3,\n \"mn\": \"Defines protocol mapping and session procedures, but appears to lack implementation details, test vectors, error handling edge cases, and validation against real-world deployment scenarios.\",\n \"o\": 3,\n \"on\": \"Shares core concepts with existing protocol bridging/tunneling work; overlaps with generic QUIC-based transport specifications, but MCP+MOQT combination is relatively specific.\",\n \"mo\": 2,\n \"mon\": \"Single revision noted (2025-10-20); no evidence of WG adoption, multiple revisions, or significant community engagement; appears early-stage.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI agent infrastructure; addresses agent-to-tool communication patterns and data source integration, core MCP use cases.\",\n \"c\": [\n \"A2A protocols\",\n \"Data formats/interop\",\n \"Model serving/inference\",\n \"Agent discovery/reg\"\n ]\n}\n```", "in_tok": 573, "out_tok": 354}
|
|
|
|
|
{"draft_name": "draft-birkholz-verifiable-agent-conversations", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Defines a CDDL-based data format for recording and verifying autonomous agent conversations with COSE signatures, enabling accountability and compliance through structured capture of messages, tool invocations, and reasoning traces compatible with SCITT and RFC 9334 Evidence.\",\n \"n\": 3,\n \"nn\": \"Useful contribution combining existing standards (CDDL, COSE, SCITT) for agent auditability; incremental rather than novel given prior work on conversation logging and cryptographic signing.\",\n \"m\": 4,\n \"mn\": \"Well-defined protocol specification with CDDL schema and dual JSON/CBOR representations; appears implementation-ready with clear interoperability requirements, though test vectors and reference implementations not evident from abstract.\",\n \"o\": 3,\n \"on\": \"Moderate overlap with agent telemetry formats and SCITT transparency services; related to conversation logging standards but specific focus on verifiability and agent accountability is somewhat differentiated.\",\n \"mo\": 2,\n \"mon\": \"Single dated revision (2026-05) suggests early-stage draft; no clear evidence of WG adoption, community feedback cycles, or multiple implementation attempts yet.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to autonomous agent governance, auditability, and human oversight\u2014core concerns as LLM agents handle consequential tasks; strong alignment with emerging accountability requirements.\",\n \"c\": [\n \"Data formats/interop\",\n \"Agent identity/auth\",\n \"Policy/governance\",\n \"Human-agent interaction\",\n \"A2A protocols\"\n ]\n}\n```", "in_tok": 672, "out_tok": 381}
|
|
|
|
|
{"draft_name": "draft-mao-rtgwg-apn-framework-for-ioa", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes applying the APN (Application-aware Networking) framework to enable fine-grained network services for interactions between AI agents deployed across different clouds and regions. Addresses the need for differentiated network support based on varying task requirements of agent-to-agent communications.\",\n \"n\": 2,\n \"nn\": \"Incremental application of existing APN framework to an emerging use case; the core concept is straightforward extension of known technology to IoA scenarios without fundamental technical innovation.\",\n \"m\": 2,\n \"mn\": \"Early-stage draft presenting problem motivation and framework applicability analysis; lacks detailed protocol specifications, deployment models, or implementation guidance for the proposed APN-IoA integration.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing APN specifications and general intent-based networking concepts; the IoA application is relatively narrow and the draft does not differentiate substantially from prior APN work.\",\n \"mo\": 1,\n \"mon\": \"First revision with no apparent community discussion or WG engagement; limited indication of adoption interest or continued development momentum in the IETF routing or AI communities.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to AI agent networking; addresses agent-to-agent communication infrastructure needs but focuses narrowly on QoS/traffic differentiation rather than core agent capabilities, safety, or interoperability challenges.\",\n \"c\": [\n \"ML traffic mgmt\",\n \"A2A protocols\",\n \"Autonomous netops\",\n \"Data formats/interop\"\n ]\n}\n```", "in_tok": 618, "out_tok": 367}
|
|
|
|
|
{"draft_name": "draft-ietf-lake-authz", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"ELA extends EDHOC with a lightweight authorization mechanism for zero-touch onboarding of constrained devices using ephemeral Diffie-Hellman key exchange. The protocol leverages EDHOC's extension points to enable enrollment authorization in resource-limited IoT/constrained network scenarios with pre-installed trust anchors.\",\n \"n\": 2,\n \"nn\": \"Incremental extension building on established EDHOC foundation; applies existing mechanisms to authorization problem rather than introducing novel cryptographic or protocol concepts.\",\n \"m\": 4,\n \"mn\": \"Well-defined protocol specification with detailed procedures, parameter definitions, and integration with COSE/EDHOC standards; suitable for implementation with clear normative requirements.\",\n \"o\": 3,\n \"on\": \"Shares conceptual overlap with OAuth 2.0 device flows, FIDO device onboarding, and other IoT provisioning standards; distinct in leveraging EDHOC but addresses similar enrollment authorization patterns.\",\n \"mo\": 4,\n \"mon\": \"Active LAKE WG effort (March 2026 revision date suggests recent development); EDHOC momentum provides foundation; clear IoT/constrained device market demand.\",\n \"r\": 1,\n \"rn\": \"Not relevant to AI agents; addresses IoT device onboarding and network authorization. No connection to autonomous agents, AI safety, model serving, or agent-related protocols.\",\n \"c\": [\"Other AI/agent\"]\n}\n```", "in_tok": 575, "out_tok": 350}
|
|
|
|
|
{"draft_name": "draft-c4tz-marc", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"MARC proposes a vendor-neutral control and uncertainty-disclosure profile for generative models and agentic systems, defining interoperable metadata for confidence reporting and bounded action sets (answering, clarification, retrieval, tool use, deliberation, abstention, escalation). It focuses on externally observable semantics rather than model internals, targeting reduction of silent failures and improved auditability across orchestration layers and user-facing systems.\",\n \"n\": 3,\n \"nn\": \"Useful contribution addressing a real gap in uncertainty communication for AI systems, but builds on established concepts (confidence scoring, action taxonomies) without fundamental novelty; incremental synthesis of existing ideas into a coordination profile.\",\n \"m\": 4,\n \"mn\": \"Well-structured specification with clear scope boundaries, defined metadata elements, and primary action set taxonomy. 50 pages suggests substantive technical detail, though without access to full document cannot confirm presence of implementation examples or test vectors.\",\n \"o\": 3,\n \"on\": \"Shares conceptual space with confidence calibration work, agent orchestration protocols, and model card transparency initiatives; distinct from but related to work on AI system accountability and human-AI interaction frameworks.\",\n \"mo\": 2,\n \"mon\": \"Single draft revision noted (2026 date suggests future); no evidence of WG adoption, community testing, or iterative refinement cycle; appears to be exploratory submission rather than active development effort.\",\n \"r\": 4,\n \"rn\": \"Directly addresses core operational needs for deployed agentic systems\u2014uncertainty communication, action control, auditability\u2014making it highly relevant to production AI agent environments and orchestration platforms.\",\n \"c\": [\n \"Data formats/interop\",\n \"Human-agent interaction\",\n \"Model serving/inference\",\n \"AI safety/alignment\",\n \"A2A protocols\",\n \"Policy/governance\"\n ]\n}\n```", "in_tok": 677, "out_tok": 442}
|
|
|
|
|
{"draft_name": "draft-ietf-ace-coap-est-oscore", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Specifies how to carry EST (Enrollment over Secure Transport) over CoAP using OSCORE and EDHOC as alternatives to DTLS, with support for CBOR-encoded certificates. This enables certificate provisioning for constrained IoT devices with lighter cryptographic overhead than traditional EST-coaps.\",\n \"n\": 2,\n \"nn\": \"Incremental combination of existing standards (EST, CoAP, OSCORE, EDHOC) rather than fundamentally new approach; applies proven mechanisms to a specific transport scenario.\",\n \"m\": 4,\n \"mn\": \"Detailed protocol specification building on RFC9148 with clear integration points; references implementation-ready components (EDHOC, OSCORE, COSE) though primary draft maturity depends on referenced I-D stability.\",\n \"o\": 4,\n \"on\": \"Significant overlap with EST-coaps (RFC9148) scope; OSCORE+EDHOC combination already established in other constrained CoAP contexts; primarily a substitution exercise rather than novel composition.\",\n \"mo\": 3,\n \"mon\": \"Active WG development as ACE work item with reasonable progression (23 pages, specific target date); appears to be steady incremental work without exceptional community pressure or multiple rapid iterations.\",\n \"r\": 2,\n \"rn\": \"Not AI/agent-related; purely infrastructure/IoT certificate provisioning. Tangentially relevant only if framing constrained device identity/auth as agent prerequisite, but primary focus is networking protocol mechanics.\",\n \"c\": [\"Agent identity/auth\", \"Data formats/interop\", \"Other AI/agent\"]\n}\n```", "in_tok": 634, "out_tok": 391}
|
|
|
|
|
{"draft_name": "draft-ietf-netconf-configuration-tracing", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft proposes a NETCONF mechanism to trace configuration changes back to their source NMS/controller/orchestrator via external trace IDs. It addresses troubleshooting and closed-loop automation in multi-NMS environments by adding YANG-based tracking of configuration modifications.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution extending NETCONF with tracing capability; the core concept of configuration lineage tracking is straightforward, though the NETCONF-specific instrumentation is useful.\",\n \"m\": 3,\n \"mn\": \"Defined protocol mechanism with YANG module specification; appears to have concrete operational semantics but lacks implementation examples, test vectors, or deployment guidance.\",\n \"o\": 3,\n \"on\": \"Shares conceptual overlap with OpenTracing/distributed tracing (trace ID propagation) and existing NETCONF operations tracking; similar to correlation ID patterns in enterprise systems.\",\n \"mo\": 2,\n \"mon\": \"Single dated revision (2025-11-03); no evidence of multiple iterative improvements or active WG adoption discussion visible in abstract/metadata.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to autonomous networks and self-healing closed-loop automation; trace-to-source mapping is essential for AI-driven network ops troubleshooting and agent accountability.\",\n \"c\": [\n \"Autonomous netops\",\n \"Agent identity/auth\",\n \"Data formats/interop\",\n \"Policy/governance\",\n \"Other AI/agent\"\n ]\n}\n```", "in_tok": 713, "out_tok": 364}
|
|
|
|
|
{"draft_name": "draft-li-dmsc-macp", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes MACP, an architectural framework and protocol suite for secure multi-agent collaboration across administrative domains, introducing entities like Agent Management Center and Agent Gateway to enable trusted onboarding, capability discovery, and distributed synchronization.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution combining existing concepts (agent management, capability-based discovery, distributed protocols) without substantial architectural innovation beyond standard service-oriented patterns.\",\n \"m\": 2,\n \"mn\": \"Early-stage draft with architectural overview but lacks detailed protocol specifications, message formats, security mechanisms, implementation examples, or test vectors needed for deployment.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing work: FIPA agent standards, microservice architectures (service discovery, API gateways), Kubernetes-style orchestration, and distributed capability negotiation protocols.\",\n \"mo\": 1,\n \"mon\": \"Single revision with April 2026 date (likely speculative/future-dated); no evidence of community engagement, working group adoption, or iterative development based on feedback.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI agent infrastructure; addresses critical multi-agent coordination needs, though framed as general protocol work rather than explicitly scoped to modern LLM-based agents.\",\n \"c\": [\n \"A2A protocols\",\n \"Agent identity/auth\",\n \"Agent discovery/reg\",\n \"Policy/governance\",\n \"Data formats/interop\"\n ]\n}\n```", "in_tok": 574, "out_tok": 356}
|
|
|
|
|
{"draft_name": "draft-sharif-apki-agent-pki", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"APKI extends X.509 PKI with agent-specific certificate extensions, transparency logs, and trust delegation mechanisms to enable verifiable identity and graduated trust for autonomous AI agents performing Internet-scale actions. The work addresses the mismatch between traditional PKI assumptions (human operators, long-lived services) and AI agent characteristics (ephemeral lifecycles, capability constraints, model provenance tracking).\",\n \"n\": 3,\n \"nn\": \"Incremental but well-motivated extension of X.509; the core novelty lies in the specific agent-context extensions (capability constraints, model provenance, delegation chains) rather than fundamental cryptographic innovation. Reasonable engineering response to a genuine gap, but not a paradigm shift.\",\n \"m\": 3,\n \"mn\": \"Defined protocol with extension specifications and URI scheme, but abstract on implementation detail; no test vectors, reference implementations, or deployment guidance evident. Sufficient for WG evaluation but requires substantial development before production use.\",\n \"o\": 3,\n \"on\": \"Moderate overlap with SPIFFE (workload identity), WIMSE (machine identity), and Certificate Transparency (RFC 9162). Positions itself as compatible bridge rather than replacement, which is appropriate but limits distinctiveness. Agent-specific extension layer is novel within PKI context.\",\n \"m\": 2,\n \"mon\": \"Single 2026 revision with no clear WG sponsorship mentioned; appears to be individual submission. Timely topic (AI agents on Internet) but no evidence of active adoption, implementation feedback, or multi-organizational consensus.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to autonomous agent infrastructure; addresses real operational need as agents perform regulated actions (financial transactions, data access). Gaps in existing PKI for agent trust models are genuine, though scope is primarily identity/auth rather than alignment or safety.\",\n \"c\": [\"Agent identity/auth\", \"A2A protocols\", \"Data formats/interop\", \"Agent discovery/reg\", \"Policy/governance\", \"Autonomous netops\"]\n}\n```", "in_tok": 713, "out_tok": 469}
|
|
|
|
|
{"draft_name": "draft-eckert-anima-acp-free-ani", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes a lightweight alternative to ANI called aNI that reuses existing GRASP and BRSKI protocols with domain keying material while eliminating the complex ACP layer, implementing automation agents as application-level software components without requiring forwarding plane changes.\",\n \"n\": 2,\n \"nn\": \"Incremental simplification of existing ANI framework; removes ACP complexity but reuses established protocols (GRASP, BRSKI) and certificate infrastructure with acknowledged trade-offs in security guarantees.\",\n \"m\": 3,\n \"mn\": \"Protocol mechanism appears defined with clear architectural choices, but document length (21 pages) and stated simplifications suggest may lack comprehensive specification detail and implementation guidance typical of production-ready specs.\",\n \"o\": 4,\n \"on\": \"Significant overlap with ANI/GRASP/BRSKI ecosystem; primarily a design variant removing ACP rather than introducing fundamentally new concepts; closely related to existing autonomic networking infrastructure work.\",\n \"mo\": 2,\n \"mon\": \"Single dated revision (2025-10-20); appears to be exploratory proposal without evident WG adoption, implementation pilots, or community engagement signals; positioned as alternative to established ANI path.\",\n \"r\": 2,\n \"rn\": \"Tangentially related to AI agents; focuses on network automation infrastructure and agent communication patterns rather than AI/ML-specific agent topics; relevant to agent identity/authentication and discovery protocols but not core AI agent concerns.\",\n \"c\": [\n \"Agent discovery/reg\",\n \"Agent identity/auth\",\n \"A2A protocols\",\n \"Autonomous netops\",\n \"Policy/governance\"\n ]\n}\n```", "in_tok": 699, "out_tok": 394}
|
|
|
|
|
{"draft_name": "draft-it-aipref-attachment", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft proposes extending RFC 9309 to allow content creators to signal preferences about how their content is used by automated systems through HTTP headers. It aims to provide a mechanism for indicating usage preferences during content acquisition.\",\n \"n\": 2,\n \"nn\": \"Incremental extension to existing standards; the core concept of signaling content preferences is well-established (robots.txt, rel=nofollow), this primarily adds HTTP header mechanisms\",\n \"m\": 2,\n \"mn\": \"Early draft stage with abstract only; lacks protocol details, header definitions, semantics specification, compliance mechanisms, and implementation guidance\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing preference signaling mechanisms (robots.txt, X-Robots-Tag, HTTP Link headers, machine-readable policies); relationship to RFC 9309 and how this differs needs clarification\",\n \"mo\": 1,\n \"mon\": \"Single version as of specified date; no visible WG adoption, community discussion, or revision history indicating active development or interest\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI agent governance\u2014addresses how creators can communicate content usage boundaries to automated systems, a core AI safety concern\",\n \"c\": [\n \"Policy/governance\",\n \"Data formats/interop\",\n \"AI safety/alignment\",\n \"A2A protocols\"\n ]\n}\n```", "in_tok": 513, "out_tok": 332}
|
|
|
|
|
{"draft_name": "draft-cui-nmrg-llm-nm", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft proposes a framework enabling collaborative network management between LLM agents and human operators, featuring enhanced telemetry, decision modules, and human-in-the-loop workflows. It aims to integrate AI-driven automation into existing network management systems while maintaining human oversight and interoperability.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution combining existing concepts (LLM agents, network management, human-in-the-loop) without substantial technical novelty in mechanisms or protocols.\",\n \"m\": 2,\n \"mn\": \"Early-stage framework definition lacking detailed protocol specifications, data model formalization, or implementation guidance; appears to be problem framing rather than solution specification.\",\n \"o\": 4,\n \"on\": \"Significant conceptual overlap with emerging AI agent frameworks, network automation standards, and human-AI interaction guidelines; limited differentiation from parallel industry efforts.\",\n \"mo\": 2,\n \"mon\": \"Single submission with no visible WG sponsorship or community discussion; publication date of 2026 suggests speculative or early-stage work with minimal adoption signals.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI agent orchestration in network operations; addresses timely intersection of LLMs and network management, though execution appears preliminary.\",\n \"c\": [\n \"Autonomous netops\",\n \"Human-agent interaction\",\n \"Data formats/interop\",\n \"Policy/governance\",\n \"A2A protocols\"\n ]\n}\n```", "in_tok": 569, "out_tok": 353}
|
|
|
|
|
{"draft_name": "draft-cui-dmsc-agent-cdi", "model": "claude-haiku-4-5-20251001", "raw": "{\n \"s\": \"This draft proposes a framework for enabling AI agents across different domains to collaborate securely through federated identity, trust establishment, and policy harmonization mechanisms. It addresses cross-domain interoperability challenges without requiring centralized control.\",\n \"n\": 2,\n \"nn\": \"Applies established federated identity and trust patterns (SAML, OAuth, mTLS) to AI agents; the conceptual contribution is incremental adaptation of known solutions rather than novel mechanisms.\",\n \"m\": 2,\n \"mn\": \"Early sketch phase with abstract framework description; lacks concrete protocol specifications, implementation details, message formats, or validation mechanisms needed for deployment.\",\n \"o\": 4,\n \"on\": \"Significant overlap with SPIFFE/SPIRE (workload identity), existing federated IAM standards, and blockchain-based trust frameworks; limited differentiation for AI-specific use cases.\",\n \"mo\": 1,\n \"mon\": \"Single revision at publication date (2026-02-11); no evidence of working group adoption, implementation feedback, or iterative refinement typical of active IETF work.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to AI agent ecosystems but frames problem primarily as identity/federation rather than agent-specific challenges (coordination semantics, capability heterogeneity, collaborative reasoning).\",\n \"c\": [\"Agent identity/auth\", \"Policy/governance\", \"Agent discovery/reg\", \"Data formats/interop\", \"A2A protocols\"]\n}", "in_tok": 575, "out_tok": 344}
|
|
|
|
|
{"draft_name": "draft-song-anp-aitp", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"AITP proposes a message-framed transport protocol above AIP specifically designed for autonomous AI agent communication, featuring native method invocation, request-response correlation, and flow control semantics rather than traditional byte-stream abstractions. It aims to provide a common substrate for agent-to-agent messaging with association state management and circuit-breaker mechanisms.\",\n \"n\": 2,\n \"nn\": \"The core concept of designing a transport layer around agent invocation rather than byte streams is incremental; similar ideas appear in RPC frameworks (gRPC, SOAP) and message-oriented middleware. The framing and state machine are competent engineering but not fundamentally novel.\",\n \"m\": 4,\n \"mn\": \"At 34 pages, the draft appears specification-complete with defined segment types, state machines, flow control mechanics, and protocol options. Maturity is limited only by apparent lack of reference implementations or interoperability test vectors.\",\n \"o\": 4,\n \"on\": \"Substantial conceptual overlap with gRPC (method-aware framing, streaming), MOQT (association-based multiplexing), and existing RPC transports. The positioning as 'agent-native' differentiates presentation but not fundamental design principles.\",\n \"m\": 1,\n \"mon\": \"No evidence of WG adoption, multiple revisions, or community interest visible. Single dated revision (2026-03-25) with no apparent implementation ecosystem or deployment roadmap suggests nascent/speculative status.\",\n \"r\": 3,\n \"rn\": \"Directly addresses agent communication infrastructure, but relevance is narrowed by dependence on the pre-requisite AIP specification and unclear adoption prospects. Relevant to A2A protocol layer but not core AI safety, model serving, or agent alignment concerns.\",\n \"c\": [\n \"A2A protocols\",\n \"Data formats/interop\",\n \"Agent discovery/reg\"\n ]\n}\n```", "in_tok": 882, "out_tok": 451}
|
|
|
|
|
{"draft_name": "draft-cui-nmrg-auto-test", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes an AI-assisted framework for automating network protocol testing with five automation maturity levels (Level 0-5), leveraging LLMs for test case generation, script creation, and iterative refinement. Provides a reference architecture and roadmap for evolving protocol testing practices using emerging AI capabilities.\",\n \"n\": 2,\n \"nn\": \"Incremental application of existing LLM capabilities to protocol testing; maturity level concept borrowed from similar frameworks (CMM, TRL); limited technical novelty beyond combining known approaches.\",\n \"m\": 2,\n \"mn\": \"Early conceptual sketch with framework components identified but lacking implementation details, formal specifications, concrete algorithms, or working prototypes; maturity levels defined descriptively rather than with measurable criteria.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing work in automated test generation (symbolic execution, fuzzing), AI-assisted software development, and capability maturity models; similar maturity level hierarchies used in DevOps and autonomous systems.\",\n \"mo\": 1,\n \"mon\": \"Single submission to NMRG with no visible revision history or community engagement; no evidence of WG discussion, adoption signals, or follow-up versions in public records.\",\n \"r\": 3,\n \"rn\": \"Partially relevant; applies AI/LLMs to network testing but framework is generic software testing automation rather than agent-centric; does not address agent identity, coordination, or multi-agent scenarios.\",\n \"c\": [\"Autonomous netops\", \"ML traffic mgmt\", \"Model serving/inference\"]\n}\n```", "in_tok": 659, "out_tok": 371}
|
|
|
|
|
{"draft_name": "draft-wang-ppm-ecdh-psi", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft presents ECDH-PSI, a privacy-preserving protocol for two participants to compute set intersection using elliptic curve cryptography and the Meadows protocol. Participants can identify common records without revealing their private datasets to each other.\",\n \"n\": 2,\n \"nn\": \"Instantiates existing Meadows protocol with standard curves; straightforward application of known techniques rather than novel algorithmic contribution.\",\n \"m\": 3,\n \"mn\": \"Protocol is clearly defined with concrete instantiation details and hash-to-curve methods, but lacks implementation examples, test vectors, and formal security proofs.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing PSI literature; ECDH-based PSI has been explored in prior work; main contribution is standardization rather than new approach.\",\n \"mo\": 1,\n \"mon\": \"Single draft submission (2025-08-20); no evidence of WG adoption, revisions, or community discussion; appears to be initial proposal.\",\n \"r\": 2,\n \"rn\": \"Not directly relevant to AI agents; applicable to secure computation and privacy-preserving data sharing in general, but no specific connection to autonomous systems or agent infrastructure.\",\n \"c\": [\"Data formats/interop\", \"Agent identity/auth\"]\n}\n```", "in_tok": 609, "out_tok": 313}
|
|
|
|
|
{"draft_name": "draft-song-tsvwg-camp", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"CAMP proposes a consistency-aware multipath transport protocol built on MPQUIC to handle multimodal content transmission for interactive LLM systems, addressing inter-modal arrival time synchronization across network paths. The design separates audio, video, and text streams with differentiated scheduling while coordinating transport and application layers to minimize latency variance.\",\n \"n\": 3,\n \"nn\": \"Incremental contribution combining existing multipath transport (MPQUIC) with application-aware scheduling for a specific use case; the core concept of modality-aware stream separation and consistency scheduling is useful but not conceptually novel.\",\n \"m\": 2,\n \"mn\": \"Early-stage sketch with protocol definition but lacks implementation details, test vectors, and evaluation results; mechanism descriptions are present but insufficient detail for independent implementation or reproduction.\",\n \"o\": 3,\n \"on\": \"Shares foundational concepts with multipath QUIC work and multimedia synchronization literature; minimal direct overlap with existing RFCs but builds incrementally on established transport mechanisms without significant architectural innovation.\",\n \"mo\": 1,\n \"mon\": \"Single draft submission with no visible revision history or WG engagement; lacks indicators of active development, community adoption, or implementation activity within IETF processes.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI agent infrastructure, specifically model serving and interactive multimodal LLM systems; addresses networking requirements for real-time human-agent interaction with streaming content.\",\n \"c\": [\n \"Model serving/inference\",\n \"Human-agent interaction\",\n \"ML traffic mgmt\",\n \"Data formats/interop\"\n ]\n}\n```", "in_tok": 776, "out_tok": 388}
|
|
|
|
|
{"draft_name": "draft-nandakumar-ai-agent-moq-transport", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes a protocol abstraction layer enabling MOQT to serve as a unified transport for inter-agent communication by mapping request-response and streaming patterns onto MOQT's publish-subscribe model, demonstrated with A2A and MCP protocols.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution: applies existing MOQT transport to agent protocols rather than introducing novel abstractions or mechanisms; the mapping concept is straightforward.\",\n \"m\": 2,\n \"mn\": \"Early sketch phase: abstract protocol layer defined but likely lacking implementation details, test vectors, and concrete code examples needed for deployment.\",\n \"o\": 3,\n \"on\": \"Moderate overlap with existing MOQT work and protocol-agnostic transport mapping efforts; bridges known domains (MOQT, A2A, MCP) rather than addressing novel intersection.\",\n \"m\": 2,\n \"mon\": \"Limited momentum: single draft appearance (2026-03), no evidence of WG adoption, implementation, or community engagement; agent transport remains nascent area.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to agent infrastructure and interoperability; addresses practical need for unified transport across emerging agent ecosystems, though not core ML/AI algorithm work.\",\n \"c\": [\n \"A2A protocols\",\n \"Agent discovery/reg\",\n \"Data formats/interop\",\n \"ML traffic mgmt\"\n ]\n}\n```", "in_tok": 660, "out_tok": 345}
|
|
|
|
|
{"draft_name": "draft-ai-traffic", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft identifies networking challenges for distributed LLM training and inference across federated datacenters, focusing on the unique traffic characteristics of AI workloads. It argues that understanding AI-specific network requirements is essential for operating LLM services in multi-datacenter environments.\",\n \"n\": 2,\n \"nn\": \"Problem statement for AI traffic characteristics is useful but incremental; the core insight that distributed LLMs have distinct networking needs is relatively straightforward.\",\n \"m\": 1,\n \"mn\": \"Pure problem statement with abstract framing; no specific protocol mechanisms, architecture proposals, or concrete solutions offered.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing work on datacenter networking, collective communication optimization, and distributed training infrastructure; similar concerns addressed in ML systems literature.\",\n \"mo\": 2,\n \"mon\": \"Single revision (2024-10-07), no clear WG sponsorship evident; appears to be early-stage exploratory work without demonstrated adoption momentum.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI infrastructure and agent/model serving contexts; addresses real operational challenges for distributed AI systems.\",\n \"c\": [\n \"ML traffic mgmt\",\n \"Model serving/inference\",\n \"Autonomous netops\",\n \"Data formats/interop\"\n ]\n}\n```", "in_tok": 603, "out_tok": 318}
|
|
|
|
|
{"draft_name": "draft-aylward-aiga-2", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"AIGA proposes a tiered governance framework for autonomous AI agents combining immutable kernel architecture, federated authority networks, and economic incentive alignment. The protocol addresses deployment constraints and adversarial scenarios through action-based authorization and multi-layered approval mechanisms for high-risk operations.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution combining established governance concepts (tiered risk, federated authorities, TEE attestation) with agent-specific application; lacks fundamentally novel technical mechanisms.\",\n \"m\": 3,\n \"mn\": \"Protocol is defined with component descriptions but lacks detailed technical specifications, cryptographic parameters, message formats, state machines, and implementation guidelines needed for standardization.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing work: TEE attestation from TPM/SGX standards, federated governance from DNS/PKI models, economic incentives from blockchain protocols, multi-signature from existing crypto frameworks.\",\n \"mo\": 1,\n \"mon\": \"Single revision only (2026-01-26); no evidence of WG discussion, community feedback, or iterative development; appears to be exploratory draft without engagement momentum.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI agent governance and policy frameworks; addresses real deployment concerns but positioned as protocol rather than governance model, creating scope ambiguity for IETF venue.\",\n \"c\": [\n \"Policy/governance\",\n \"Agent identity/auth\",\n \"AI safety/alignment\",\n \"Autonomous netops\",\n \"Human-agent interaction\"\n ]\n}\n```", "in_tok": 792, "out_tok": 376}
|
|
|
|
|
{"draft_name": "draft-ietf-lamps-est-renewal-info", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Extends RFC7030 EST with a mechanism for servers to signal optimal certificate renewal timing to clients, addressing the inadequacy of fixed 50%-lifetime renewal heuristics for short-lived certificates.\",\n \"n\": 2,\n \"nn\": \"Incremental extension addressing a practical operational problem; the core concept is straightforward (server-provided renewal hint) with limited technical novelty.\",\n \"m\": 3,\n \"mn\": \"Defines a protocol mechanism with clear specification intent, though the draft appears early-stage (7 pages) and likely lacks detailed examples, edge case handling, or implementation guidance.\",\n \"o\": 2,\n \"on\": \"Minor similarities to existing certificate lifecycle management approaches; EST renewal timing is a naturally scoped problem with limited overlap to other standards.\",\n \"mo\": 3,\n \"mon\": \"Active WG development within LAMPS (Lightweight Armored Multi-Protocol Scheme) with recent revision date; standard maturity trajectory suggests ongoing refinement.\",\n \"r\": 1,\n \"rn\": \"Not relevant to AI agents or autonomous systems; this is pure PKI infrastructure for TLS certificate lifecycle management with no agent-related components.\",\n \"c\": [\"Agent identity/auth\"]\n}\n```", "in_tok": 573, "out_tok": 292}
|
|
|
|
|
{"draft_name": "draft-niyikiza-oauth-attenuating-agent-tokens", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Defines Attenuating Authorization Tokens (AATs), a JWT-based credential format for secure delegation in AI agent systems that cryptographically enforces monotonic scope reduction across delegation chains. Extends RFC 9396 with delegation semantics and tool-level argument constraints, enabling offline verification without network contact to root issuer.\",\n \"n\": 3,\n \"nn\": \"Useful contribution combining existing concepts (JWT delegation, capability attenuation, RAR) into a cohesive agent-specific framework, but builds incrementally on well-established patterns in authorization and capability systems.\",\n \"m\": 4,\n \"mn\": \"Well-structured specification with 72 pages suggesting detailed protocol definition, formal semantics, and constraint vocabulary. Likely includes examples and algorithms, though implementation maturity and test vectors unclear from abstract alone.\",\n \"o\": 3,\n \"on\": \"Shares core concepts with capability-based security literature and prior delegation work (ZCAP, macaroons); overlaps with RAR (RFC 9396) by design; some similarity to OAuth token narrowing but applies to agent tool invocation specifically.\",\n \"m\": 2,\n \"mon\": \"Single draft dated 2026-03-17 suggests early stage; no indication of WG adoption, multiple revisions, or community engagement; appears to be initial submission without visible momentum signals.\",\n \"r\": 5,\n \"rn\": \"Directly addresses core AI agent security concern: safe delegation and scope attenuation in multi-agent systems. Tool invocation constraints and chain verification are fundamental to agent autonomy and safety.\",\n \"c\": [\"Agent identity/auth\", \"A2A protocols\", \"AI safety/alignment\", \"Data formats/interop\", \"Policy/governance\"]\n}\n```", "in_tok": 640, "out_tok": 408}
|
|
|
|
|
{"draft_name": "draft-mapmw-task-discovery", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes an architectural framework for task discovery and agent coordination through a multi-layer platform where task owners publish structured tasks and autonomous agents negotiate execution terms. Surveys existing agent discovery approaches (A2A, OASF, ARDP, DNS-AID) and positions the work as complementary rather than replacement.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution combining existing concepts (task cards, layered architecture, agent discovery) without substantial technical innovation; conceptually straightforward application of known patterns to agent coordination.\",\n \"m\": 2,\n \"mn\": \"Early-stage architectural sketch with functional layer definitions but lacks detailed protocol specifications, message formats, negotiation algorithms, or security mechanisms; no implementation examples or test vectors provided.\",\n \"o\": 4,\n \"on\": \"Significant conceptual overlap with survey targets (A2A, OASF, ARDP); core ideas of agent discovery, capability matching, and platform-mediated task posting are well-established; unclear how framework substantially differs from existing broker/marketplace patterns.\",\n \"mo\": 1,\n \"mon\": \"Single draft revision with March 2026 date suggests recent submission; no evidence of WG discussion, community feedback, or iterative refinement; positioned tentatively ('possible ways,' 'potential standardization venues').\",\n \"r\": 4,\n \"rn\": \"Directly addresses agent orchestration and discovery, core concerns in multi-agent AI systems; timing aligns with growing industry interest; however, framing around IETF standardization may be mismatch for application-layer agent frameworks.\",\n \"c\": [\n \"Agent discovery/reg\",\n \"Data formats/interop\",\n \"A2A protocols\",\n \"Human-agent interaction\",\n \"Other AI/agent\"\n ]\n}\n```", "in_tok": 777, "out_tok": 423}
|
|
|
|
|
{"draft_name": "draft-zw-opsawg-mcp-network-mgmt", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Extends the Model Context Protocol (MCP) to enable network equipment to function as MCP servers, allowing AI controllers to manage routers and switches through a standardized JSON-RPC framework. Defines new capability tokens, tools, resources, prompts, and error codes while maintaining backward compatibility with existing MCP implementations.\",\n \"n\": 2,\n \"nn\": \"Incremental extension applying existing MCP framework to network management domain; lacks novel protocol mechanisms or architectural innovations.\",\n \"m\": 3,\n \"mn\": \"Defines protocol mechanisms with new extensions but appears to lack detailed implementation examples, test vectors, or deployment guidance typical of implementation-ready specs.\",\n \"o\": 3,\n \"on\": \"Shares foundational concepts with NETCONF/YANG and other network management protocols; MCP application to network domain has limited prior art but conceptually overlaps with API gateway and orchestration patterns.\",\n \"mo\": 2,\n \"mon\": \"Single draft revision dated 2026-05-06 with no evident WG adoption, implementation reports, or community feedback suggesting early-stage, limited-traction work.\",\n \"r\": 4,\n \"rn\": \"Directly addresses AI agent-network interaction by enabling autonomous controllers to manage infrastructure; core relevance to autonomous netops and agent-equipment communication.\",\n \"c\": [\n \"A2A protocols\",\n \"Autonomous netops\",\n \"Agent identity/auth\",\n \"Data formats/interop\",\n \"Agent discovery/reg\"\n ]\n}\n```", "in_tok": 553, "out_tok": 360}
|
|
|
|
|
{"draft_name": "draft-mw-spice-intent-chain", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes an intent_chain cryptographic claim to track content provenance and transformations across AI agent workflows, complementing actor_chain delegation records. Provides tamper-evident audit trails with Merkle root embedding in OAuth tokens for efficiency while addressing STRIDE threat categories.\",\n \"n\": 2,\n \"nn\": \"Incremental extension applying established cryptographic patterns (Merkle trees, audit logs, claims-based architecture) to AI agent content tracking; core techniques are well-known, application domain is relatively novel but architecturally straightforward.\",\n \"m\": 2,\n \"mn\": \"Early sketch stage; abstract describes intent and threat model but lacks protocol mechanics detail, serialization formats, Merkle construction specifics, and practical implementation considerations for multi-stage pipelines.\",\n \"o\": 3,\n \"on\": \"Shares conceptual overlap with blockchain audit trails, W3C Verifiable Credentials provenance models, and software supply chain SLSA framework; positioning relative to these is unclear; dependency on companion draft creates coupling.\",\n \"m\": 2,\n \"mon\": \"Limited observable momentum; dated future publication (2026-03-18 suggests speculative entry), appears to be individual contribution without visible WG traction, no evidence of adoption or implementation feedback.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI agent governance and autonomous system trustworthiness; addresses legitimate need for content provenance in agentic workflows; less relevant to core AI safety/alignment than to operational security/audit.\",\n \"c\": [\"Agent identity/auth\", \"Policy/governance\", \"A2A protocols\", \"Data formats/interop\"]\n}\n```", "in_tok": 662, "out_tok": 388}
|
|
|
|
|
{"draft_name": "draft-hw-protocol-agent", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes protocol mechanisms for networks to recognize and handle multi-modal AI agent traffic with differentiated quality requirements. Addresses the gap between increasing AI agent network usage and current network inability to distinguish diverse transmission characteristics of multi-modal data streams.\",\n \"n\": 2,\n \"nn\": \"Incremental work applying existing QoS/traffic differentiation concepts to AI agent scenarios; lacks technical depth on novel protocol mechanisms beyond problem motivation.\",\n \"m\": 1,\n \"mn\": \"Problem statement and high-level requirements only; no concrete protocol specification, message formats, state machines, or implementation details provided in abstract.\",\n \"o\": 4,\n \"on\": \"Significant overlap with MPLS traffic engineering, DiffServ, 5G network slicing, and emerging work on ML traffic classification (RFC 8799, ALTO extensions); limited differentiation from existing QoS frameworks.\",\n \"mo\": 1,\n \"mon\": \"Single revision at future date (2026-03); no evidence of WG sponsorship, community engagement, or iterative development; appears speculative.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to AI agent networking but framed as network infrastructure concern rather than agent protocol specification; scope confusion between network layer mechanisms and agent-level protocols.\",\n \"c\": [\n \"ML traffic mgmt\",\n \"Data formats/interop\",\n \"Autonomous netops\",\n \"Policy/governance\"\n ]\n}\n```", "in_tok": 581, "out_tok": 347}
|
|
|
|
|
{"draft_name": "draft-farzdusa-aipref-enduser", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft advocates for considering end-user impacts when standardizing AI preference signaling mechanisms, emphasizing control over data contributions and privacy. It proposes principles for the ai-pref working group rather than defining concrete technical specifications.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution that frames existing concerns (data privacy, user control) within the specific context of AI preference signaling; limited technical novelty.\",\n \"m\": 1,\n \"mn\": \"Problem statement and principles document; lacks protocol definitions, vocabulary specifications, or implementation guidance that would advance maturity.\",\n \"o\": 3,\n \"on\": \"Shares conceptual overlap with broader IETF work on user privacy signaling and data minimization; related to DNT and similar preference mechanisms but narrowly scoped to AI context.\",\n \"mo\": 2,\n \"mon\": \"Single dated revision (2025-11-27) with uncertain WG adoption status; appears to be early input to ai-pref WG rather than iterative development.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI agent governance and policy frameworks; addresses legitimate end-user concerns in AI deployment but more governance-focused than protocol-focused.\",\n \"c\": [\n \"Policy/governance\",\n \"Human-agent interaction\",\n \"AI safety/alignment\",\n \"Data formats/interop\"\n ]\n}\n```", "in_tok": 559, "out_tok": 332}
|
|
|
|
|
{"draft_name": "draft-jennings-mcp-over-moqt", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft specifies how to transport the Model Context Protocol (MCP) over MOQT, leveraging QUIC's low-latency publish-subscribe capabilities for language model applications to communicate with external tools and data sources. It maps MCP messages to MOQT objects and defines session management procedures.\",\n \"n\": 2,\n \"nn\": \"Incremental combination of two existing protocols (MCP + MOQT); primarily an engineering exercise in protocol mapping rather than introducing novel concepts.\",\n \"m\": 3,\n \"mn\": \"Defines the protocol mapping and procedures at a reasonable level of detail, but appears to lack implementation validation, test vectors, or deployment guidance typical of mature transport specifications.\",\n \"o\": 3,\n \"on\": \"Shares conceptual overlap with MCP over HTTP/SSE and other MCP transport bindings; MOQT itself is a separate WG effort, so this represents a relatively straightforward layering without significant architectural novelty.\",\n \"mo\": 2,\n \"mon\": \"Single revision dated April 2026 with no clear WG sponsorship signal or adoption indicators; positioning is narrow (MCP-specific MOQT binding) with unclear community traction.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI agent infrastructure by enabling efficient MCP transport for tool calling and data access patterns; addresses real latency and resource constraints in agent deployments.\",\n \"c\": [\n \"A2A protocols\",\n \"Data formats/interop\",\n \"Model serving/inference\",\n \"Agent discovery/reg\"\n ]\n}\n```", "in_tok": 576, "out_tok": 379}
|
|
|
|
|
{"draft_name": "draft-zeng-mcp-network-mgmt", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft proposes MCP extensions enabling network equipment to function as servers for AI controller clients, defining new capability tokens, tools, resources, and error codes. The work aims for backward compatibility with existing MCP implementations while enabling AI-driven network management.\",\n \"n\": 2,\n \"nn\": \"Incremental extension of existing MCP framework to network domain; applies proven JSON-RPC patterns rather than introducing novel concepts.\",\n \"m\": 2,\n \"mn\": \"Early specification stage with abstract scope; lacks detailed protocol mechanics, implementation examples, error handling specifics, or test vectors needed for production deployment.\",\n \"o\": 4,\n \"on\": \"Significant overlap with YANG-based network management standards (RFC 6241/6242), NETCONF, and prior MCP work; represents relatively straightforward domain application rather than architectural innovation.\",\n \"mo\": 1,\n \"mon\": \"Single 7-page draft with October 2025 date; no evidence of WG adoption, multiple revisions, or community feedback cycle typical of progressing IETF work.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to autonomous network operations and agent-controller interaction patterns; addresses legitimate need for standardized AI-equipment communication in netops domain.\",\n \"c\": [\n \"A2A protocols\",\n \"Autonomous netops\",\n \"Agent discovery/reg\",\n \"Data formats/interop\",\n \"Agent identity/auth\"\n ]\n}\n```", "in_tok": 548, "out_tok": 352}
|
|
|
|
|
{"draft_name": "draft-zhao-nmrg-ai-agent-for-dtn", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes integrating autonomous AI agents with digital twin technology for network management, extending traditional DTN architectures with intelligent agents at component levels. The work combines AI agents with network digital twins to enable adaptive and autonomous network operations.\",\n \"n\": 2,\n \"nn\": \"Straightforward combination of two existing concepts (AI agents and digital twin networks) without significant algorithmic or architectural innovation; primarily an application proposal rather than methodological advance.\",\n \"m\": 2,\n \"mn\": \"Early sketch stage with abstract concepts; lacks detailed protocol specifications, algorithmic descriptions, implementation details, or concrete examples of how agents interact within the DTN framework.\",\n \"o\": 4,\n \"on\": \"Significant overlap with concurrent work on AI-driven network management, digital twin networking standards (ITU-T), and multi-agent systems in telecom; limited differentiation from existing DTN and AI agent proposals.\",\n \"mo\": 1,\n \"mon\": \"Appears to be initial submission with no evidence of WG discussion, prior revisions, or community engagement; no indication of adoption or iterative development.\",\n \"r\": 4,\n \"rn\": \"Directly addresses AI agents in network contexts and autonomous network operations, core topics for NMRG; relevance is strong despite execution limitations.\",\n \"c\": [\n \"Autonomous netops\",\n \"AI safety/alignment\",\n \"Agent discovery/reg\",\n \"Data formats/interop\",\n \"Policy/governance\"\n ]\n}\n```", "in_tok": 512, "out_tok": 353}
|
|
|
|
|
{"draft_name": "draft-wang-cats-odsi", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes ODSI, a decentralized framework for distributed LLM inference across untrusted participants with layer-wise execution, deadline awareness, and accountability mechanisms. Addresses architectural challenges of networked LLM serving without specifying concrete protocols.\",\n \"n\": 3,\n \"nn\": \"Useful contribution combining known concepts (distributed ML, decentralized coordination, deadline-aware execution) into a cohesive inference architecture, but incremental relative to existing distributed systems and federated learning literature.\",\n \"m\": 2,\n \"mn\": \"Early framework specification focusing on architecture and design rationale; explicitly defers protocol details, message formats, and state machines to future documents. Lacks implementation, concrete algorithms, or validation.\",\n \"o\": 4,\n \"on\": \"Significant conceptual overlap with federated learning systems, distributed serving platforms (Ray, vLLM), and decentralized coordination frameworks. Layer-wise execution parallels model parallelism and pipeline parallelism in existing systems.\",\n \"mo\": 2,\n \"mon\": \"Single draft revision dated 2026-03-02 with no visible community adoption, working group backing, or prior versions. No indicators of active development or organizational support.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to model serving/inference and distributed AI systems. Addresses real operational challenges in LLM deployment but framed as networking infrastructure problem rather than core AI agent capability.\",\n \"c\": [\"Model serving/inference\", \"ML traffic mgmt\", \"Autonomous netops\", \"Agent identity/auth\", \"Data formats/interop\", \"Policy/governance\"]\n}\n```", "in_tok": 788, "out_tok": 381}
|
|
|
|
|
{"draft_name": "draft-kuehlewind-audit-architecture", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes a distributed audit architecture for tracking AI agent delegation, intent, and authorization across internet interactions. Addresses the gap in existing audit mechanisms by linking delegation relationships with execution through context propagation and attestation.\",\n \"n\": 3,\n \"nn\": \"Auditing frameworks for agents are underexplored in IETF; the specific focus on delegation chains and intent tracking is a useful contribution, though audit architectures themselves are not novel.\",\n \"m\": 2,\n \"mn\": \"Early-stage draft presenting conceptual architecture without detailed protocol specifications, implementation details, or comprehensive technical mechanisms for distributed audit record generation and propagation.\",\n \"o\": 3,\n \"on\": \"Shares audit/logging concepts with existing security frameworks (SIEM, structured logging) and agent transparency work, but the specific application to AI agent delegation appears moderately novel.\",\n \"mo\": 2,\n \"mon\": \"Single recent revision (May 2026); limited indication of working group activity, implementation interest, or community feedback driving development momentum.\",\n \"r\": 4,\n \"rn\": \"Directly addresses a critical gap in AI agent governance\u2014auditability of autonomous delegation decisions\u2014which is core to agent trustworthiness and emerging policy requirements.\",\n \"c\": [\n \"Policy/governance\",\n \"Agent identity/auth\",\n \"Data formats/interop\",\n \"AI safety/alignment\",\n \"Human-agent interaction\"\n ]\n}\n```", "in_tok": 590, "out_tok": 344}
|
|
|
|
|
{"draft_name": "draft-wu-sidr-aspa-validation-signaling", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft proposes a new BGP extended community to signal AS_PATH validation states derived from ASPA within autonomous systems, enabling IBGP speakers to apply local routing policies based on upstream provider authorization verification. It addresses intra-domain policy signaling for BGP security validation.\",\n \"n\": 2,\n \"nn\": \"Incremental extension to existing BGP signaling mechanisms; combines ASPA validation with standard extended community encoding without fundamental innovation.\",\n \"m\": 3,\n \"mn\": \"Protocol mechanism is clearly defined with extended community structure, but lacks implementation examples, deployment scenarios, and interoperability guidance expected of mature specs.\",\n \"o\": 3,\n \"on\": \"Shares conceptual overlap with ASPA (RFC 6811), BGP communities (RFC 1997), and related SIDR validation signaling work; extends rather than duplicates existing standards.\",\n \"mo\": 1,\n \"mon\": \"Single draft revision in 2024 with no evidence of WG discussion, implementation reports, or successive updates indicating active community development.\",\n \"r\": 1,\n \"rn\": \"Not relevant to AI agents or autonomous systems in the machine learning sense; pure network routing infrastructure document unrelated to AI/ML topics.\",\n \"c\": [\n \"Data formats/interop\",\n \"Policy/governance\",\n \"Other AI/agent\"\n ]\n}\n```", "in_tok": 523, "out_tok": 330}
|
|
|
|
|
{"draft_name": "draft-cui-dns-native-agent-naming-resolution", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes DN-ANR, a DNS-based naming and resolution system for AI agents that uses FQDNs as stable identifiers and resolves them to cryptographically-verified endpoints with protocol information. The draft intentionally keeps DNS lightweight by avoiding semantic metadata, delegating discovery and routing decisions to higher layers.\",\n \"n\": 2,\n \"nn\": \"Incremental extension of DNS for a new use case (AI agents); core mechanisms (DNSSEC, FQDN resolution) are established practices applied to agent identity rather than fundamentally novel.\",\n \"m\": 3,\n \"mn\": \"Defines a coherent protocol mechanism with three clear goals and apparent DNS record structure, but lacks detailed specification sections, examples, implementation guidance, and test vectors typical of mature IETF drafts.\",\n \"o\": 3,\n \"on\": \"Shares conceptual overlap with service discovery (SRV records, mDNS), DNSSEC-based verification, and existing agent/service naming conventions; somewhat positioned between DNS-SD and custom agent registries.\",\n \"r\": 2,\n \"rn\": \"Single-author draft from 2026 with no visible WG affiliation, discussion thread, or adoption signals; appears exploratory rather than community-driven.\",\n \"mo\": 4,\n \"mon\": \"Directly addresses timely AI agent interoperability and identity challenges; relevance to emerging agent ecosystems suggests potential interest, though current adoption/momentum indicators are absent.\",\n \"c\": [\n \"Agent identity/auth\",\n \"Agent discovery/reg\",\n \"A2A protocols\",\n \"Data formats/interop\"\n ]\n}\n```", "in_tok": 599, "out_tok": 394}
|
|
|
|
|
{"draft_name": "draft-huang-rats-agentic-eat-cap-attest", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Extends the Entity Attestation Token (EAT) standard with new claims to enable secure, verifiable attestation of AI agent capabilities, functional scope, and policy constraints in decentralized environments. Addresses the emerging need for trustworthy capability declarations in autonomous agent systems.\",\n \"n\": 3,\n \"nn\": \"Useful but incremental contribution\u2014applies existing attestation token framework to a new domain (agentic AI) rather than introducing fundamentally new attestation concepts.\",\n \"m\": 2,\n \"mn\": \"Early-stage draft; defines problem space and conceptual extensions but lacks detailed protocol mechanics, claim schemas, serialization examples, and implementation guidance needed for interoperability.\",\n \"o\": 3,\n \"on\": \"Shares core ideas with emerging capability frameworks (IETF RATS, AI governance tokens) and overlaps with parallel work on agent provenance and model cards; positioning relative to these efforts unclear.\",\n \"mo\": 1,\n \"mon\": \"Very limited momentum\u2014single revision, no evidence of WG adoption, community feedback, or implementation efforts; unclear if this addresses real deployment pain points.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI agent identity, capability attestation, and trustworthiness in decentralized agent systems; timely given industry interest in verifiable agent properties.\",\n \"c\": [\n \"Agent identity/auth\",\n \"Data formats/interop\",\n \"Policy/governance\",\n \"AI safety/alignment\",\n \"Agent discovery/reg\"\n ]\n}\n```", "in_tok": 588, "out_tok": 368}
|
|
|
|
|
{"draft_name": "draft-berlinai-vera", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"VERA proposes a zero-trust reference architecture for securing AI agents through five enforcement pillars and cryptographic proof-based autonomy escalation. The framework combines threat modeling, formal security properties, and a maturity-based runtime to mitigate risks from compromised agents.\",\n \"n\": 3,\n \"nn\": \"Framework-level contribution with structured threat model and formal properties; combines existing zero-trust concepts with agent-specific autonomy/capability escalation mechanics, incremental rather than fundamentally novel.\",\n \"m\": 2,\n \"mn\": \"Early architectural sketch with identified pillars and properties but lacks protocol details, message formats, cryptographic scheme specifications, and concrete implementation guidance needed for reproducibility.\",\n \"o\": 3,\n \"on\": \"Shares conceptual overlap with zero-trust architecture (NIST ZTA, BeyondCorp), supply-chain risk frameworks, and capability-based security; agent-specific application is somewhat novel but builds on established patterns.\",\n \"mo\": 1,\n \"mon\": \"Appears to be initial submission (Feb 2026 date); no evidence of WG discussion, revisions, or community engagement; single 7-page draft suggests early-stage work.\",\n \"r\": 5,\n \"rn\": \"Directly addresses critical AI agent security risks (exfiltration, unauthorized transactions, cascading failures); core to emerging agent autonomy governance and runtime protection.\",\n \"c\": [\n \"AI safety/alignment\",\n \"Agent identity/auth\",\n \"Policy/governance\",\n \"Autonomous netops\"\n ]\n}\n```", "in_tok": 566, "out_tok": 374}
|
|
|
|
|
{"draft_name": "draft-jeskey-anml", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"ANML is a proposed machine-first markup language for agent-to-agent communication that standardizes content, interactions, constraints, and state representation across XML and JSON serializations. It aims to reduce inference overhead by providing explicit semantic structure optimized for deterministic agent interactions.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution combining existing markup concepts (semantic annotation, structured data, constraint declarations) without substantial novelty beyond applying familiar patterns to the agent communication domain.\",\n \"m\": 3,\n \"mn\": \"Protocol mechanism is defined with stated serialization formats and abstract model, but lacks implementation details, test vectors, validation rules, and concrete examples needed for implementation readiness.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing standards: microformats/schema.org (semantic annotation), JSON-LD (structured data), OpenAPI/AsyncAPI (interaction/parameter binding), W3C Capabilities (constraints), and SASL/OAuth (authorization rules).\",\n \"mo\": 1,\n \"mon\": \"Single draft dated 2026-05-22 with no visible revision history, community discussion, WG sponsorship, or implementation adoption signals.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to agent-to-agent communication protocols and data format standardization, though focus is narrow to protocol structuring rather than core AI safety or autonomy challenges.\",\n \"c\": [\n \"A2A protocols\",\n \"Data formats/interop\",\n \"Agent discovery/reg\",\n \"Policy/governance\"\n ]\n}\n```", "in_tok": 770, "out_tok": 371}
|
|
|
|
|
{"draft_name": "draft-liu-agent-protocol-over-moq", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes an application-layer protocol for agent-to-agent communication built atop Media over QUIC (MoQ), adding framing for control signaling, session management, and data fragmentation. Targets low-latency structured messaging between autonomous agents in intra- and inter-domain deployments with emphasis on interoperability and extensibility.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution layering agents over existing MoQ transport; core novelty is primarily the framing/signaling layer rather than fundamentally new concepts.\",\n \"m\": 2,\n \"mn\": \"Early sketch stage with abstract describing goals but 22 pages likely covering design rationale; lacks detail on protocol state machines, message formats, error handling, or implementation guidance.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing agent messaging protocols (gRPC, MQTT, DDS) and MoQ-adjacent signaling work; positioning relative to alternatives unclear.\",\n \"mo\": 1,\n \"mon\": \"Single draft revision with 2026 date suggests nascent work; no evidence of WG adoption, implementer interest, or broader community momentum.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to AI agent infrastructure but frames problem narrowly as transport protocol rather than addressing agent coordination, reasoning, or safety concerns central to agent research.\",\n \"c\": [\"A2A protocols\", \"Data formats/interop\", \"Agent discovery/reg\"],\n \"overall_assessment\": \"Early-stage transport layer specification with limited novelty and unclear positioning relative to established messaging frameworks. Needs stronger motivation, detailed protocol specification, and demonstrated demand from agent community.\"\n}\n```", "in_tok": 567, "out_tok": 394}
|
|
|
|
|
{"draft_name": "draft-cui-ai-agent-task", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes coordination requirements for AI agent protocols to enable autonomous task management across distributed networks, focusing on dynamic discovery, negotiation, and adaptive scheduling. Addresses the emerging need for standardized communication patterns as AI agents scale in heterogeneous environments.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution focusing on well-established distributed systems concepts (task scheduling, service discovery, negotiation) applied to AI agents without fundamental protocol innovation.\",\n \"m\": 2,\n \"mn\": \"Early-stage requirements document; appears to be a problem statement and high-level requirements draft rather than a defined protocol specification with concrete mechanisms or implementation guidance.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing work in multi-agent systems coordination, distributed task scheduling (IETF ALTO, etc.), and microservices orchestration; limited novelty in specific approach.\",\n \"mo\": 1,\n \"mon\": \"Single recent draft with no apparent prior versions or follow-up activity; timing suggests exploratory work without established community momentum or WG engagement.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to AI agent protocols; addresses coordination needs but lacks specificity on AI-unique aspects (model inference requirements, LLM-specific constraints, prompt/embedding handling).\",\n \"c\": [\n \"A2A protocols\",\n \"Agent discovery/reg\",\n \"Autonomous netops\",\n \"ML traffic mgmt\",\n \"Data formats/interop\"\n ]\n}\n```", "in_tok": 520, "out_tok": 356}
|
|
|
|
|
{"draft_name": "draft-liu-agent-metadata-sync-protocol", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"AMSP defines a hierarchical metadata synchronization protocol for autonomous agents across distributed network gateways, enabling global reachability and loop-free propagation. The draft addresses coordination between Level-1 and Level-2 gateways in an Internet of Agents infrastructure.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution applying standard synchronization patterns (likely BGP-like) to agent metadata; the core concepts are well-established networking techniques adapted to a new domain.\",\n \"m\": 3,\n \"mn\": \"Protocol mechanism is defined with apparent hierarchical structure and metadata exchange semantics, but at 11 pages lacks detailed state machines, message formats, error handling, and implementation examples needed for production deployment.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing distributed metadata/routing protocols (BGP, ISIS, OSPF patterns); the agent-specific wrapper appears thin. Missing explicit comparison to related work in agent frameworks and distributed systems literature.\",\n \"mo\": 1,\n \"mon\": \"Single revision snapshot (2026-03-19 date suggests speculative/future draft); no evidence of WG discussion, implementation feedback, or iterative development history in public record.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to agent infrastructure and discovery; addresses real coordination challenges in multi-gateway deployments, though framing as 'Internet of Agents' may overstate scope versus narrower agent mesh networking.\",\n \"c\": [\"A2A protocols\", \"Agent discovery/reg\", \"Autonomous netops\", \"Data formats/interop\"]\n}\n```", "in_tok": 595, "out_tok": 374}
|
|
|
|
|
{"draft_name": "draft-an-nmrg-i2icf-cits", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes a framework for managing In-Network Computing Functions in C-ITS environments using Agent-to-Agent communication paradigms. Focuses on orchestrating distributed computing across vehicles, roadside units, and network domains for optimized V2X communications and traffic management.\",\n \"n\": 2,\n \"nn\": \"Incremental work combining existing concepts (in-network computing, V2X, MEC) with agent communication; framework design lacks substantial technical novelty.\",\n \"m\": 2,\n \"mn\": \"Early-stage draft with conceptual framework but minimal protocol detail; abstract mentions orchestration/management but likely lacks formal specifications, algorithms, or message formats.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing IETF work on MEC, V2X communication, network function orchestration; agent-based approaches in IoT/vehicular networks already established in multiple standards bodies.\",\n \"mo\": 1,\n \"mon\": \"First revision, no evidence of WG adoption, community discussion, or implementation efforts; niche intersection of NMRG interests and C-ITS domains.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to AI agents via A2A communication paradigm, but framed primarily as network infrastructure/protocol work rather than agent systems; agent aspects appear secondary to networking concerns.\",\n \"c\": [\n \"A2A protocols\",\n \"Agent discovery/reg\",\n \"Data formats/interop\",\n \"ML traffic mgmt\",\n \"Autonomous netops\"\n ]\n}\n```", "in_tok": 675, "out_tok": 369}
|
|
|
|
|
{"draft_name": "draft-rosenberg-aiproto-nact", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"N-ACT proposes a standardized protocol for AI agents to discover and invoke third-party tools/APIs, with separate enumeration and invocation mechanisms to reduce enterprise integration costs. It builds on OpenAI's function-calling specification to enable both design-time tool selection and runtime LLM-driven tool execution.\",\n \"n\": 2,\n \"nn\": \"Incremental extension of existing OpenAI tool/function-calling patterns; normalizes and formalizes what is already common practice in production AI systems rather than introducing fundamentally new concepts.\",\n \"m\": 3,\n \"mn\": \"Defines protocol structure and principles clearly but appears to lack implementation details, example specifications, test vectors, or interoperability validation across multiple AI platforms.\",\n \"o\": 4,\n \"on\": \"Significant overlap with OpenAI Functions API, Anthropic tool_use, and JSON Schema-based tool specifications already widely deployed; relates closely to existing OpenAPI/AsyncAPI ecosystem work.\",\n \"mo\": 1,\n \"mon\": \"No evidence of WG adoption, implementation, or iterative development; appears to be a single submission without demonstrable community interest or subsequent revisions.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to practical AI agent deployment; addresses real enterprise pain point of tool integration, though framed narrowly around normalization rather than breakthrough capability.\",\n \"c\": [\n \"Data formats/interop\",\n \"Agent discovery/reg\",\n \"A2A protocols\",\n \"Model serving/inference\",\n \"Human-agent interaction\"\n ]\n}\n```", "in_tok": 722, "out_tok": 375}
|
|
|
|
|
{"draft_name": "draft-zhao-detnet-enhanced-use-cases", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Extends RFC8578 deterministic networking use cases to cover industrial IoT, high-quality video, intelligent computing, and ISAC-enabled factories, identifying scaling requirements and common properties across emerging applications.\",\n \"n\": 2,\n \"nn\": \"Incremental extension of existing use case frameworks; applies established DetNet concepts to newer application domains without fundamental protocol innovations.\",\n \"m\": 2,\n \"mn\": \"Early-stage use case documentation; identifies requirements and properties but lacks detailed protocol specifications, implementation guidance, or validation mechanisms.\",\n \"o\": 4,\n \"on\": \"Significant overlap with RFC8578 baseline and existing DetNet work; novel application domains partially explored in other drafts (industrial, video, computing).\",\n \"mo\": 2,\n \"mon\": \"Single recent revision (2026-02-24); no evident multi-version development pattern or clear WG adoption trajectory beyond use case exploration.\",\n \"r\": 2,\n \"rn\": \"Tangentially related to AI agents; focuses on network determinism for AI workloads (intelligent computing, ISAC) but is primarily infrastructure/networking rather than agent-centric.\",\n \"c\": [\n \"ML traffic mgmt\",\n \"Policy/governance\",\n \"Other AI/agent\"\n ]\n}\n```", "in_tok": 510, "out_tok": 311}
|
|
|
|
|
{"draft_name": "draft-han-anima-ai-asa", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft explores enhancing ANIMA's Autonomic Service Agents with LLM-driven AI capabilities, analyzing impacts on ASA communication protocols like GRASP. It positions AI-powered ASAs as an evolution of network device management functions.\",\n \"n\": 2,\n \"nn\": \"Incremental extension combining existing ASA/GRASP framework with generic LLM integration; lacks novel communication protocols or AI-specific mechanisms for agent coordination.\",\n \"m\": 2,\n \"mn\": \"Early-stage analysis document; identifies problem space but offers minimal concrete protocol modifications, design patterns, or implementation guidance for AI-augmented ASAs.\",\n \"o\": 4,\n \"on\": \"Significant overlap with broader AI agent communication work; combines established ANIMA concepts with generic LLM discussion without distinguishing unique technical contributions.\",\n \"mo\": 1,\n \"mon\": \"Limited community momentum; single recent revision on emerging topic but no evidence of WG adoption, implementation efforts, or active development cycle.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI-powered autonomic agents and their network communication; addresses timely intersection of ANIMA framework and LLM technologies.\",\n \"c\": [\n \"A2A protocols\",\n \"Autonomous netops\",\n \"Agent identity/auth\",\n \"Data formats/interop\",\n \"Other AI/agent\"\n ]\n}\n```", "in_tok": 575, "out_tok": 338}
|
|
|
|
|
{"draft_name": "draft-li-individual-inip", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"INIP proposes a lightweight protocol for executing inference tasks on in-network data plane devices (switches, DPUs, SmartNICs) in datacenter networks, using a centralized control plane with CDN-like model scheduling and minimal data plane execution. The protocol aims to enable high-speed inference while preserving core forwarding functions.\",\n \"n\": 2,\n \"nn\": \"Incremental combination of existing concepts (in-network computing, match-action tables, model scheduling). The core idea of offloading ML inference to network devices is not new; primary contribution is protocol specification rather than novel architectural insights.\",\n \"m\": 3,\n \"mn\": \"Protocol specification is defined with packet format, architecture, and scheduling mechanisms described. However, lacks implementation details, test vectors, deployment examples, and empirical validation of performance claims. Insufficient for immediate standardization.\",\n \"o\": 4,\n \"on\": \"Significant overlap with prior work on in-network computing (e.g., Domino, NetCache, NN-Accelerator proposals), SmartNIC-based inference, and collaborative edge-cloud inference. The CDN-like scheduling mechanism is relatively standard. Positioning relative to existing standards unclear.\",\n \"m\": 2,\n \"mn\": \"Individual draft with single revision noted (2026-03-02). No indication of WG adoption, community discussion, or implementation efforts. Limited evidence of active development or stakeholder engagement beyond initial specification.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to model serving/inference and autonomous network operations (ML-assisted resource allocation). Applicable to agent inference at the network level but not core to agent architecture, identity, or interaction protocols.\",\n \"c\": [\n \"Model serving/inference\",\n \"ML traffic mgmt\",\n \"Autonomous netops\",\n \"Data formats/interop\"\n ]\n}\n```", "in_tok": 694, "out_tok": 440}
|
|
|
|
|
{"draft_name": "draft-ar-emu-hybrid-pqc-eapaka", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft proposes integrating hybrid post-quantum cryptography (PQC) into EAP-AKA' Forward Secrecy to protect against quantum computing threats. It extends RFC9678 by replacing traditional ECDHE with PQ/T hybrid algorithms for quantum-resistant key agreement in authentication protocols.\",\n \"n\": 2,\n \"nn\": \"Straightforward application of existing hybrid PQC terminology to an established protocol; combines known techniques without fundamental innovation in either PQC or EAP-AKA'.\",\n \"m\": 2,\n \"mn\": \"Early draft stage presenting motivation and problem statement; lacks detailed protocol specification, algorithm selection rationale, security analysis, and implementation guidance needed for standardization.\",\n \"o\": 4,\n \"on\": \"Significant overlap with parallel PQC migration efforts across IETF protocols; similar hybrid approach being applied to TLS, IKE, and other standards; limited unique contribution beyond domain-specific instantiation.\",\n \"mo\": 2,\n \"mon\": \"First revision with minimal engagement signals; no evidence of WG sponsorship, implementation feedback, or community adoption; appears as individual contribution rather than coordinated standardization effort.\",\n \"r\": 3,\n \"rn\": \"Partially relevant as authentication protocol for autonomous systems and agent identity/authorization scenarios; not core to AI agents specifically but addresses infrastructure security enabling trustworthy agent deployment.\",\n \"c\": [\"Agent identity/auth\", \"A2A protocols\", \"Policy/governance\"]\n}\n```", "in_tok": 722, "out_tok": 356}
|
|
|
|
|
{"draft_name": "draft-kim-nmrg-2nmai5g", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes using AI and SOAR for autonomous security and intent-based network management in B5G networks to maintain consistent security quality. The draft seeks to establish user requirements and system development guidance for AI-driven network management.\",\n \"n\": 2,\n \"nn\": \"Incremental combination of existing concepts (AI in networking, SOAR, intent-based management) without clear novel technical contribution or methodology.\",\n \"m\": 1,\n \"mn\": \"Document lacks concrete technical specifications, protocols, mechanisms, or implementation details. Reads as high-level problem statement and requirement gathering exercise rather than defined solution.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing work on AI-driven network management, autonomous orchestration, and SOAR frameworks. Intent-based networking and B5G management are established research areas.\",\n \"mo\": 1,\n \"mon\": \"Single revision with minimal activity. No evidence of WG engagement, community discussion, or iterative development.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to AI in network operations but lacks depth in autonomous agent design, coordination, or decision-making specifics. More about applying existing AI/SOAR tools than advancing AI agent technology.\",\n \"c\": [\"Autonomous netops\", \"ML traffic mgmt\", \"Policy/governance\"]\n}\n```", "in_tok": 594, "out_tok": 316}
|
|
|
|
|
{"draft_name": "draft-ietf-rats-ar4si", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Defines reusable attestation result information elements and their CBOR/JSON serializations to enable consistent trustworthiness evaluation across heterogeneous Attesting Environments and Verifiers. Provides a standardized approach for Relying Parties to apply consistent policies when interfacing with diverse attestation sources.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution that builds on existing RATS framework; primarily standardizes representation of existing attestation concepts rather than introducing fundamentally new evaluation mechanisms.\",\n \"m\": 4,\n \"mn\": \"Well-specified protocol with defined information model and dual serialization formats (CBOR/JSON); appears implementation-ready though specific test vectors not mentioned in abstract.\",\n \"o\": 3,\n \"on\": \"Shares core concepts with existing RATS work on attestation results and verifiers; extends rather than duplicates but represents predictable evolution of the framework.\",\n \"mo\": 4,\n \"mon\": \"Active IETF WG (rats) development with clear document progression; demonstrates sustained attention to remote attestation standardization.\",\n \"r\": 2,\n \"rn\": \"Tangentially related to AI agents; relevant for agent identity/authentication and A2A protocol infrastructure but not addressing core AI safety, alignment, or agent-specific challenges.\",\n \"c\": [\n \"Agent identity/auth\",\n \"A2A protocols\",\n \"Data formats/interop\",\n \"Policy/governance\"\n ]\n}\n```", "in_tok": 576, "out_tok": 350}
|
|
|
|
|
{"draft_name": "draft-ietf-anima-constrained-voucher", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"cBRSKI adapts the BRSKI secure onboarding protocol for resource-constrained IoT devices by replacing JSON vouchers with compact CBOR encoding and substituting HTTPS/EST with CoAPS/CoAP-based alternatives. The protocol enables zero-touch mutual authentication between constrained devices and domain owner networks in bandwidth-limited environments.\",\n \"n\": 2,\n \"nn\": \"Incremental optimization of existing BRSKI framework; primarily a format and transport substitution (JSON\u2192CBOR, HTTPS\u2192CoAPS) rather than fundamental protocol innovation.\",\n \"m\": 4,\n \"mn\": \"Well-defined protocol specification with detailed updates to RFC 8995 and RFC 9148; 93 pages suggests comprehensive technical treatment with likely examples and mechanisms defined.\",\n \"o\": 3,\n \"on\": \"Shares core voucher and mutual authentication concepts with BRSKI; introduces specific optimizations for constrained networks but within established secure onboarding framework.\",\n \"mo\": 4,\n \"mon\": \"Published IETF draft with WG sponsorship (ANIMA); addresses concrete IoT deployment gap where existing BRSKI is impractical, indicating real industry traction.\",\n \"r\": 2,\n \"rn\": \"Focuses on device identity, authentication, and secure bootstrapping infrastructure\u2014tangentially relevant to agent systems only if considering autonomous IoT agents requiring authenticated enrollment.\",\n \"c\": [\n \"Agent identity/auth\",\n \"Data formats/interop\",\n \"Agent discovery/reg\",\n \"Autonomous netops\"\n ]\n}\n```", "in_tok": 735, "out_tok": 380}
|
|
|
|
|
{"draft_name": "draft-zeng-opsawg-llm-netconf-gap", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft analyzes gaps between traditional network configuration protocols (NETCONF, RESTCONF, gNMI, MCP, A2A) and the requirements of LLM-driven intent-based networking. It identifies extension points across five south-bound protocols to enable conversational, semantically-rich multi-agent orchestration.\",\n \"n\": 2,\n \"nn\": \"Applying gap analysis to existing protocols for LLM integration is incremental work; the core insight (existing protocols lack conversational semantics) is unsurprising given their design era.\",\n \"m\": 2,\n \"mn\": \"Early-stage gap analysis document; identifies problems but provides limited concrete protocol extensions, mechanisms, or implementation guidance to close identified gaps.\",\n \"o\": 3,\n \"on\": \"Overlaps with ongoing intent-based networking discussions and LLM-for-ops initiatives; gap analyses for protocol modernization are becoming common in multiple venues.\",\n \"mo\": 1,\n \"mon\": \"Single revision dated 2026-05-06 with no evidence of WG adoption, community feedback iterations, or integration into standards track development.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI-driven network operations; addresses real operational gap at intersection of LLMs and network automation, though framing as 'gap analysis' rather than concrete solution limits core relevance.\",\n \"c\": [\n \"A2A protocols\",\n \"Autonomous netops\",\n \"Agent discovery/reg\",\n \"Data formats/interop\",\n \"Human-agent interaction\",\n \"Policy/governance\"\n ]\n}\n```", "in_tok": 562, "out_tok": 385}
|
|
|
|
|
{"draft_name": "draft-kiliram-agent-trust-auth-framework", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes an architectural framework for establishing cross-domain trust, authentication, and authorization for AI agents communicating across organizational boundaries. Addresses gaps in current agent protocols by defining coherent standards for agent identity, credentialing, delegation, and auditability in a protocol-agnostic manner.\",\n \"n\": 3,\n \"nn\": \"Useful contribution addressing a genuine gap in agent infrastructure, but builds on established trust and PKI concepts; novelty lies in systematic application to agent ecosystems rather than fundamentally new mechanisms.\",\n \"m\": 2,\n \"mn\": \"Early architectural sketch; abstract describes framework intent but 37 pages likely covers vision and design principles rather than detailed protocols, implementation specifications, or test vectors.\",\n \"o\": 3,\n \"on\": \"Shares core concepts with existing PKI, OAuth/OIDC delegation frameworks, and emerging agent standards; some overlap with broader IAM and zero-trust architecture work but applies these to underexplored agent-specific contexts.\",\n \"mo\": 2,\n \"mon\": \"Single draft revision with 2026 date suggests nascent work; no evidence of WG adoption, community feedback cycles, or implementation experiments yet; typical early-stage IETF positioning.\",\n \"r\": 5,\n \"rn\": \"Directly addresses critical infrastructure gap for multi-agent systems; highly relevant to enterprise AI deployments, service-to-service agent communication, and standardization needs in rapidly maturing agent ecosystem.\",\n \"c\": [\n \"A2A protocols\",\n \"Agent identity/auth\",\n \"Agent discovery/reg\",\n \"Policy/governance\",\n \"Data formats/interop\"\n ]\n}\n```", "in_tok": 616, "out_tok": 394}
|
|
|
|
|
{"draft_name": "draft-ietf-sml-trust", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Addresses trust and security considerations for structured email data, providing MUA recommendations for handling structured message content safely. Focuses on practical guidance rather than new protocols or mechanisms.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution applying existing security principles to structured email domain; lacks novel technical approaches.\",\n \"m\": 2,\n \"mn\": \"Early-stage guidance document without detailed specifications, test vectors, or implementation examples; primarily advisory in nature.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing email security standards (DKIM, SPF, DMARC) and structured data validation practices; addresses known security patterns.\",\n \"mo\": 3,\n \"mon\": \"Active WG development with recent revision date; part of established Structured Email working group with mailing list activity.\",\n \"r\": 1,\n \"rn\": \"Not relevant to AI agents or autonomous systems; purely focused on email message security and MUA handling of structured data formats.\",\n \"c\": [\"Data formats/interop\", \"Policy/governance\"]\n}\n```", "in_tok": 579, "out_tok": 257}
|
|
|
|
|
{"draft_name": "draft-ietf-ace-edhoc-oscore-profile", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Specifies an ACE framework profile combining EDHOC for mutual authentication and OSCORE for securing resource access in constrained IoT environments. Delegates authorization management from resource-constrained servers to more capable hosts while binding client credentials to OAuth access tokens.\",\n \"n\": 2,\n \"nn\": \"Incremental combination of existing protocols (EDHOC, OSCORE, ACE-OAuth) into a standardized profile; limited technical novelty but useful integration for constrained device scenarios.\",\n \"m\": 4,\n \"mn\": \"Well-defined protocol specification with detailed message flows, parameter bindings, and security considerations; likely includes implementation guidance though full test vectors not confirmed from abstract.\",\n \"o\": 3,\n \"on\": \"Shares core concepts with existing ACE profiles and OSCORE deployments; represents natural evolution combining three established IETF standards rather than duplicate effort.\",\n \"mo\": 4,\n \"mon\": \"Active WG development (ACE working group) with multiple related drafts; addressing real IoT standardization needs; 89 pages suggests substantial specification maturity.\",\n \"r\": 2,\n \"rn\": \"Tangentially related to AI agents only through distributed authorization architecture that *could* apply to autonomous agents in constrained IoT networks; not core to AI agent protocols or governance.\",\n \"c\": [\"Agent identity/auth\", \"Data formats/interop\", \"Other AI/agent\"]\n}\n```", "in_tok": 686, "out_tok": 340}
|
|
|
|
|
{"draft_name": "draft-liu-ztcpp-zt-problem-statement", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"A problem statement draft advocating for IETF standardization of zero trust interoperability frameworks and protocols. The document positions zero trust as essential for modern cloud, remote work, and intelligent agent scenarios, arguing the industry lacks open multi-vendor standards despite NIST guidance.\",\n \"n\": 2,\n \"nn\": \"Problem statement framing is incremental; zero trust concepts are well-established (NIST SP 800-207 exists), and this draft primarily calls for IETF involvement rather than introducing novel approaches.\",\n \"m\": 1,\n \"mn\": \"Pure problem statement with no protocol specifications, mechanisms, or technical definitions. Lacks concrete architectural proposals or scope boundaries for potential standardization work.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing zero trust frameworks (NIST SP 800-207, CSA guidance) and prior IETF work on authentication, authorization, and identity management. Limited original problem characterization.\",\n \"mo\": 2,\n \"mon\": \"Single revision noted (2026-05-14 date appears future/anomalous). No evidence of WG adoption or community engagement. Preliminary discussion document status.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to AI agents through mention of 'intelligent agents' as a use case, but the draft does not meaningfully address agent-specific authentication, discovery, or governance. Primarily generic zero trust positioning.\",\n \"c\": [\n \"Agent identity/auth\",\n \"Policy/governance\",\n \"Other AI/agent\"\n ]\n}\n```", "in_tok": 738, "out_tok": 372}
|
|
|
|
|
{"draft_name": "draft-zw-rtgwg-mcp-network-mgmt", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes MCP extensions enabling network equipment to act as servers for AI controller clients, defining new capability tokens, tools, resources, and error codes while maintaining backward compatibility with existing MCP implementations.\",\n \"n\": 2,\n \"nn\": \"Incremental extension of existing MCP framework; applies proven JSON-RPC pattern to network domain without introducing novel interaction paradigms or mechanisms.\",\n \"m\": 3,\n \"mn\": \"Defines protocol extensions with capability tokens and error codes, but as 18-page draft likely lacks comprehensive examples, test vectors, and implementation reference code needed for production readiness.\",\n \"o\": 3,\n \"on\": \"Shares conceptual overlap with NETCONF/YANG automation frameworks and existing MCP resource/tool patterns; bridges AI agents and network management but doesn't claim novel integration approach.\",\n \"mo\": 2,\n \"mon\": \"October 2025 draft with single revision shown; no evidence of WG adoption, implementation feedback, or community momentum; appears nascent with limited vendor engagement signals.\",\n \"r\": 4,\n \"rn\": \"Directly relevant as practical application of MCP for autonomous network operations and agent-equipment interaction; addresses real need for standardized AI-equipment communication but positions as narrow domain extension.\",\n \"c\": [\n \"A2A protocols\",\n \"Autonomous netops\",\n \"Agent discovery/reg\",\n \"Data formats/interop\",\n \"Agent identity/auth\"\n ]\n}\n```", "in_tok": 553, "out_tok": 350}
|
|
|
|
|
{"draft_name": "draft-jimenez-t2trg-iot-agent", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes an architecture enabling LLM-based AI agents to autonomously discover and control CoAP-based IoT devices through hypermedia patterns and semantic metadata, without pre-configured knowledge. Addresses resource discovery, normalized representations, closed-loop observation, and security for agent-driven constrained device interactions.\",\n \"n\": 2,\n \"nn\": \"Incremental combination of existing standards (CoAP, CoRE Link Format, SDF) with LLM agent patterns; the core concepts (REST discovery, hypermedia-driven interaction, semantic descriptions) are well-established; novelty lies mainly in systematic application to agentic scenarios rather than fundamental innovation.\",\n \"m\": 2,\n \"mn\": \"Early sketch with architectural overview; covers conceptual domains (discovery, representation, tooling, observation, monitoring, security) but lacks detailed protocol mechanics, formal specifications, implementation examples, or test vectors; would require substantial expansion for deployment readiness.\",\n \"o\": 3,\n \"on\": \"Shares significant concepts with IETF CoRE work (RFC 6690, SDF), REST/HATEOAS principles, and emerging AI agent architectures; moderate overlap with concurrent LLM-for-IoT efforts but positioning as agent-specific rather than general IoT automation provides some differentiation.\",\n \"mo\": 2,\n \"mon\": \"Single revision dated 2026-04-14 with no apparent prior versions or WG adoption indicated; appears to be exploratory submission to T2TRG (Thing-to-Thing Research Group) rather than mainstream standards track; community momentum not yet evident.\",\n \"r\": 4,\n \"rn\": \"Directly addresses AI agent autonomy in IoT contexts, combining agent reasoning with constrained device control; highly relevant to agent discovery, autonomous netops, and device interoperability; core topic for AI agent standardization but execution clarity needed.\",\n \"c\": [\n \"A2A protocols\",\n \"Autonomous netops\",\n \"Agent discovery/reg\",\n \"Data formats/interop\",\n \"Agent identity/auth\"\n ]\n}\n```", "in_tok": 621, "out_tok": 491}
|
|
|
|
|
{"draft_name": "draft-nemethi-aid-agent-identity-discovery", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"AID is a DNS-based service discovery protocol for locating agent endpoints via TXT records at _agent subdomains, returning endpoint URIs, tokens, and metadata. It provides minimal, protocol-agnostic discovery designed to work with higher-level frameworks like MCP for actual agent communication.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution\u2014applies standard DNS SRV/TXT discovery patterns (well-established in XMPP, SIP, SMTP) to the agent domain with minor format adaptations rather than introducing novel discovery concepts.\",\n \"m\": 3,\n \"mn\": \"Reasonably defined protocol specification with record format, lookup rules, and security requirements documented, but lacks implementation examples, test vectors, or interoperability evidence typical of mature IETF specs.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing DNS service discovery mechanisms (RFC 2782 SRV, RFC 6763 mDNS) and emerging agent identity schemes; the primary novelty is framing and AID branding rather than architectural innovation.\",\n \"m\": 2,\n \"mn\": \"Single draft revision with March 2026 date suggests early stage; no evidence of WG adoption, multiple rounds of feedback, or community consensus building typical of advancing IETF work.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to agent identity and discovery infrastructure; addresses real operational need for locating agent services, though positioned as infrastructure enabler rather than core AI/agent technology.\",\n \"c\": [\n \"Agent discovery/reg\",\n \"Agent identity/auth\",\n \"A2A protocols\",\n \"Data formats/interop\"\n ]\n}\n```", "in_tok": 620, "out_tok": 405}
|
|
|
|
|
{"draft_name": "draft-feria-sas", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes a 'Reality Layer' framework using signed tokens to prevent autonomous agents from overwhelming system capacity through high-frequency, unintentional signaling. The approach claims O(1) admission control via NIST-validated invariant checking, though lacks implementation details.\",\n \"n\": 2,\n \"nn\": \"Incremental framing of admission control; core concepts (rate limiting, token-based gates) are well-established in networking and distributed systems.\",\n \"m\": 1,\n \"mn\": \"Problem statement articulated but mechanism underspecified; 'NIST-validated Invariant Reality Prism (IRP-189)' appears to be invented terminology with no external reference; no protocol details, examples, or validation.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing admission control (token buckets, leaky bucket), congestion avoidance, and agent rate-limiting. Reality Token concept mirrors JWT/capability tokens. No differentiation from prior art evident.\",\n \"mo\": 1,\n \"mon\": \"Single revision, 3-page sketch with no implementation signals, test results, or community engagement visible. Terminology suggests lack of grounding in established standards.\",\n \"r\": 2,\n \"rn\": \"Tangentially related to AI agents; frames problem as noise saturation rather than agent alignment, safety, or control. Reads as network traffic management with agent-flavored language rather than addressing core agent governance.\",\n \"c\": [\n \"ML traffic mgmt\",\n \"A2A protocols\",\n \"Agent identity/auth\",\n \"Policy/governance\"\n ]\n}\n```", "in_tok": 599, "out_tok": 385}
|
|
|
|
|
{"draft_name": "draft-templin-6man-aero3", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"AERO/OMNI provides IPv6-based mobility and route optimization over virtual overlay multilink interfaces, supporting secured network admission and dynamic neighbor discovery for diverse mobile applications. The mechanism enables flow-based path selection, multihop operation, and mobility management through ND control plane extensions.\",\n \"n\": 2,\n \"nn\": \"Incremental extension combining existing IPv6 ND with overlay networking concepts; core techniques (neighbor discovery, route optimization, mobility management) are established, though application to OMNI virtual interfaces shows some novelty\",\n \"m\": 4,\n \"mn\": \"Well-defined protocol specification with detailed mechanisms (secure admission, forwarding tables, multicast support, multihop operation) across 99 pages; appears implementation-ready though test vectors and deployment examples could strengthen maturity\",\n \"o\": 3,\n \"on\": \"Shares conceptual overlap with existing mobility protocols (MIPv6, NEMO, PMIPv6) and ND-based approaches; OMNI virtual link abstraction is somewhat novel but overall architecture reuses established patterns\",\n \"mo\": 2,\n \"mon\": \"Single draft revision noted (aero3); appears to be niche work by single author without visible WG adoption or community momentum; limited evidence of active development or industry engagement\",\n \"r\": 1,\n \"rn\": \"Not relevant to AI/agent systems; this is a network mobility and routing protocol for aerospace/transportation applications with no connection to artificial intelligence, agent architectures, or autonomous agent networking\",\n \"c\": [\"Other AI/agent\"]\n}\n```", "in_tok": 640, "out_tok": 371}
|
|
|
|
|
{"draft_name": "draft-pbs-sidrops-roaanycast", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft establishes best practices for managing Route Origin Authorizations (ROAs) in globally anycasted services that use unique origin ASNs per node. It addresses technical risks and mitigation strategies specific to anycast-based RPKI operations.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution applying existing ROA concepts to the specific case of anycast deployments; extends rather than fundamentally innovates RPKI practices.\",\n \"m\": 3,\n \"mn\": \"Provides defined best practices and operational guidance with clear risk identification, but lacks detailed implementation specifications, test vectors, or formal protocol definitions.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing RPKI governance documents and anycast operational guidelines; primarily combines known concepts rather than introducing novel intersection.\",\n \"mo\": 1,\n \"mon\": \"Single revision (2025-09-03) with no evidence of iterative development, WG discussion, or implementation feedback in the wild.\",\n \"r\": 1,\n \"rn\": \"Not related to AI agents or AI systems; concerns traditional network routing security and RPKI certificate management.\",\n \"c\": [\"Policy/governance\"]\n}\n```", "in_tok": 542, "out_tok": 284}
|
|
|
|
|
{"draft_name": "draft-yang-srv6ops-intelligent-routing", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft proposes an intelligent routing method for SR Policy that selects among candidate paths based on network quality metrics in MPLS and IPv6 environments. It extends existing segment routing capabilities with quality-aware path selection mechanisms.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution combining existing SR Policy concepts with network quality metrics; lacks novel algorithmic or architectural innovations beyond standard QoS-aware routing approaches.\",\n \"m\": 3,\n \"mn\": \"Defines the routing method conceptually but appears to lack detailed protocol specifications, implementation guidelines, or comprehensive test vectors needed for deployment readiness.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing IETF work on SR Policy candidate path selection, traffic engineering, and QoS-based routing; similar concepts addressed in RFC 9256 and related drafts.\",\n \"mo\": 1,\n \"mon\": \"Single revision snapshot from June 2025 with no visible development history or WG engagement indicators; appears to be early-stage individual submission.\",\n \"r\": 2,\n \"rn\": \"Not directly relevant to AI agents or autonomous systems; focuses on traditional network routing optimization without autonomous decision-making agents or ML components.\",\n \"c\": [\n \"Other AI/agent\"\n ]\n}\n```", "in_tok": 536, "out_tok": 307}
|
|
|
|
|
{"draft_name": "draft-ietf-lamps-rfc7030-csrattrs", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft clarifies RFC7030 EST's ambiguous CSR Attributes Response specification, providing encoding rules and a template-based approach that allows servers to specify both OIDs and extension values, including subject DNs. It updates both RFC7030 and RFC9148 to resolve implementation inconsistencies.\",\n \"n\": 2,\n \"nn\": \"Incremental clarification and enhancement of existing standards; addresses implementation ambiguities rather than introducing fundamentally new concepts.\",\n \"m\": 4,\n \"mn\": \"Well-developed specification with clear encoding rules and template approach; appears implementation-ready with detailed normative guidance for RFC updates.\",\n \"o\": 2,\n \"on\": \"Minor similarities to related PKIX and EST work; primarily a clarification document with limited conceptual overlap to other standards.\",\n \"mo\": 4,\n \"mon\": \"Active LAMPS WG effort with RFC updates signaling strong standardization momentum; addresses practical interoperability problems in established deployments.\",\n \"r\": 2,\n \"rn\": \"Tangentially related to AI agent infrastructure only through certificate-based authentication and identity management; not core to AI/agent topics.\",\n \"c\": [\n \"Agent identity/auth\",\n \"Data formats/interop\",\n \"Policy/governance\"\n ]\n}\n```", "in_tok": 691, "out_tok": 314}
|
|
|
|
|
{"draft_name": "draft-han-rtgwg-agent-gateway-intercomm-framework", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes a hierarchical framework for interconnecting Agent Gateways in a distributed IoA ecosystem, addressing data synchronization, protocol compatibility, and security for cross-domain agent collaboration. Aims to enable scalable communication while maintaining compatibility with existing IoA reference architectures.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution building on established gateway and IoA concepts; hierarchical layering is standard architectural practice. Limited demonstration of novel cross-domain interoperability solutions.\",\n \"m\": 2,\n \"mn\": \"Early-stage framework document (12 pages) specifying requirements and high-level model but lacking detailed protocol specifications, message formats, or implementation examples. No concrete mechanisms or algorithms presented.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing IoT/IoA gateway architectures, general service mesh patterns, and multi-domain communication frameworks. Domain-specific application appears narrow without clear differentiation from established approaches.\",\n \"mo\": 1,\n \"mon\": \"Single version at 2026-01-30 suggests recent submission; no evidence of iterative refinement, WG engagement, or community discussion. Appears to be initial submission with minimal visibility.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to AI agent ecosystems but primarily addresses infrastructure/networking concerns rather than core agent capabilities, intelligence, or autonomy. Gateway interoperability is supporting infrastructure rather than central agent research.\",\n \"c\": [\"A2A protocols\", \"Agent discovery/reg\", \"Data formats/interop\"],\n \"overall_assessment\": \"Early-stage networking infrastructure proposal with limited novelty and maturity. Would benefit from concrete protocol specifications, implementation prototypes, and clearer positioning relative to existing IoT/edge computing standards before advancing in IETF process.\"\n}\n```", "in_tok": 582, "out_tok": 417}
|
|
|
|
|
{"draft_name": "draft-traffic-analysis-and-network-mode-mapping", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes an LLM-based framework for automated network traffic classification and resource allocation by extracting multi-modal features from packet data and mapping traffic patterns to computing requirements. Aims to improve QoS, anomaly detection, and resource utilization in dynamic network environments.\",\n \"n\": 2,\n \"nn\": \"Applying LLMs to traffic classification is incremental; combines existing concepts (traffic analysis, feature extraction, resource allocation) without substantial methodological innovation.\",\n \"m\": 2,\n \"mn\": \"Early sketch lacking critical details: no protocol specification, algorithm pseudocode, architecture diagrams, or experimental validation; abstract describes goals but not implementation approach.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing ML/DL traffic classification work (e.g., RFC 8949 approaches, prior conference papers on neural network-based QoS); LLM application to this domain is explored but not novel.\",\n \"mo\": 1,\n \"mon\": \"Single draft submission with no visible community engagement, WG sponsorship, or revision history; appears to be initial proposal without momentum indicators.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to AI/autonomous networks; focuses on ML-driven network operations but does not address agent protocols, coordination, or autonomous decision-making frameworks typical of agent-centric work.\",\n \"c\": [\n \"ML traffic mgmt\",\n \"Autonomous netops\",\n \"Model serving/inference\"\n ]\n}\n```", "in_tok": 605, "out_tok": 355}
|
|
|
|
|
{"draft_name": "draft-ietf-lake-ra", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft integrates remote attestation capabilities into EDHOC, a lightweight authenticated key exchange protocol, following the RATS architecture to enable secure verification of device integrity during cryptographic exchanges in IoT and constrained environments.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution that combines existing RATS architecture with established EDHOC protocol; the novelty is primarily in the integration rather than fundamental innovation.\",\n \"m\": 4,\n \"mn\": \"Well-defined protocol specification with detailed procedures; appears implementation-ready though test vectors and interoperability data would strengthen maturity claim.\",\n \"o\": 3,\n \"on\": \"Shares core concepts with RATS framework and EDHOC base protocol; moderate overlap with existing remote attestation and key exchange mechanisms but novel combination.\",\n \"mo\": 4,\n \"mon\": \"Active IETF working group (LAKE) with structured development; 31-page draft indicates substantive ongoing work with community engagement.\",\n \"r\": 2,\n \"rn\": \"Not directly relevant to AI agents; addresses IoT device authentication and integrity verification in constrained networks, tangentially related only through device security aspects.\",\n \"c\": [\"Agent identity/auth\", \"Data formats/interop\", \"Other AI/agent\"]\n}\n```", "in_tok": 512, "out_tok": 304}
|
|
|
|
|
{"draft_name": "draft-kroehl-agentic-trust-aae", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"AAE proposes a structured authorization container for autonomous AI agents with three mandatory blocks (MANDATE, CONSTRAINTS, VALIDITY) that bind to W3C DIDs and Verifiable Credentials for cryptographically verifiable authorization assertions. The work addresses a genuine gap where existing OAuth 2.0 and API key mechanisms lack machine-evaluable semantics needed for unsupervised agent authorization.\",\n \"n\": 3,\n \"nn\": \"Useful contribution combining existing standards (VCs, DIDs) in a novel arrangement for agent authorization, but the core concepts (time-bounded tokens, capability constraints, cryptographic binding) are well-established; primary novelty is domain application rather than fundamental innovation.\",\n \"m\": 3,\n \"mn\": \"Protocol structure is defined with clear mandatory blocks and binding to standards, but document lacks implementation details, test vectors, code examples, and integration patterns with actual AI frameworks or API gateways.\",\n \"o\": 3,\n \"on\": \"Shares significant conceptual overlap with capability-based access control, SPIFFE/SPIRE, OAuth 2.0 scope delegation, and W3C Verifiable Credential frameworks; distinguishes itself through agent-specific semantics but not fundamentally distinct from existing delegation patterns.\",\n \"mo\": 1,\n \"mon\": \"Single draft dated 2026-05-22 with no evidence of WG sponsorship, community feedback, prior versions, or implementation uptake; appears to be initial submission without established momentum.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to autonomous agent authorization and AI safety governance; timely for production autonomous agents but somewhat narrow in scope (authorization only, not broader agent coordination or safety).\",\n \"c\": [\n \"Agent identity/auth\",\n \"A2A protocols\",\n \"Policy/governance\",\n \"AI safety/alignment\",\n \"Data formats/interop\"\n ]\n}\n```", "in_tok": 725, "out_tok": 447}
|
|
|
|
|
{"draft_name": "draft-shang-campus-agent-scope-down", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft addresses authorization and access control for autonomous AI agents operating in enterprise campus networks, proposing task-bound privilege reduction ('scope-down') enforced by in-path network devices to maintain compatibility with heterogeneous legacy systems.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution combining existing concepts (privilege reduction, network-based enforcement, agent identity) applied to a new context (campus agents); lacks novel technical mechanisms.\",\n \"m\": 2,\n \"mn\": \"Early problem statement and motivation document; describes challenge space but provides no concrete protocol specification, implementation details, or enforcement mechanisms.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing work in zero-trust architecture, capability-based security, microservice authorization (OAuth 2.0 token narrowing), and network policy enforcement; the agent-specific framing is incremental.\",\n \"mo\": 1,\n \"mon\": \"Single draft submission with 8-page limit suggests early exploration; no WG sponsorship indicated, limited visibility of community adoption or follow-up work.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI agent security governance; addresses legitimate problem of agent privilege escalation and multi-service orchestration in enterprise settings.\",\n \"c\": [\"Agent identity/auth\", \"Policy/governance\", \"AI safety/alignment\", \"Autonomous netops\"]\n}\n```", "in_tok": 608, "out_tok": 324}
|
|
|
|
|
{"draft_name": "draft-tiloca-lake-app-profiles", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft defines mechanisms for coordinating EDHOC application profiles through discovery, a CBOR-based representation format, and a set of well-known profiles to ensure successful lightweight authenticated key exchange in constrained environments. It provides both the technical specification and practical profile definitions needed for interoperable EDHOC deployment.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution addressing a practical coordination problem for an existing protocol; the profile concept is established, this formalizes discovery and representation mechanisms.\",\n \"m\": 4,\n \"mn\": \"Well-developed specification with canonical CBOR format definitions and concrete well-known profiles; implementation-ready with clear encoding rules, though test vectors not explicitly mentioned in abstract.\",\n \"o\": 2,\n \"on\": \"Minor overlap with general EDHOC profile work; unique focus on discovery and canonical representation; negligible duplication with existing standards.\",\n \"mo\": 3,\n \"mon\": \"Active development with recent 2024 date; appears part of ongoing LAKE WG standardization effort; moderate community engagement expected for credential/auth protocols.\",\n \"r\": 2,\n \"rn\": \"Tangentially related to AI agents through agent identity/authentication infrastructure; IoT/constrained device focus is orthogonal to core AI agent concerns; relevant for agent platform interop at protocol layer only.\",\n \"c\": [\"Agent identity/auth\", \"Data formats/interop\"]\n}\n```", "in_tok": 634, "out_tok": 337}
|
|
|
|
|
{"draft_name": "draft-tsyrulnikov-rats-attested-inference-receipt", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"AIR defines a COSE/CWT-based signed receipt format for binding cryptographic attestation to confidential AI inference events, enabling third-party verification that computations occurred in isolated TEEs. The draft profiles attestation claims for AWS Nitro and Intel TDX, anchoring model identity, I/O hashes, and telemetry to hardware-rooted trust.\",\n \"n\": 2,\n \"nn\": \"Incremental application of existing standards (COSE, CWT, EAT) to a specific use case; the core contribution is narrowly scoped profile definition rather than novel cryptographic or architectural primitives.\",\n \"m\": 4,\n \"mn\": \"Well-structured protocol specification with clear claim definitions and platform-specific measurement profiles; lacks implementation guidance, test vectors, and interoperability validation across multiple TEE implementations.\",\n \"o\": 3,\n \"on\": \"Conceptual overlap with EAT attestation frameworks and existing TEE receipt mechanisms; differs by explicit focus on inference workload receipts and COSE/CWT binding, but limited novelty against concurrent attestation standardization efforts.\",\n \"mo\": 2,\n \"mon\": \"Single revision dated 2026-03-14 with no evidence of WG adoption, community discussion, or competing implementations; appears to be an early individual submission without established momentum.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to model serving, inference integrity, and agent identity/authentication; addresses real need for cryptographic binding of AI computation outputs to hardware attestation, critical for regulated AI deployment.\",\n \"c\": [\n \"Agent identity/auth\",\n \"Model serving/inference\",\n \"Data formats/interop\",\n \"Policy/governance\"\n ]\n}\n```", "in_tok": 706, "out_tok": 413}
|
|
|
|
|
{"draft_name": "draft-wmz-nmrg-agent-ndt-arch", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft proposes an architecture integrating Network Digital Twins with Agentic AI to enable intent-driven autonomous network operations. It positions itself as a cookbook of existing technologies rather than novel components, focusing on how these elements work together for risk-free scenario planning and optimization.\",\n \"n\": 2,\n \"nn\": \"Combines two existing concepts (NDT and Agentic AI) without introducing novel mechanisms or architectural innovations; primarily a systems integration approach.\",\n \"m\": 2,\n \"mn\": \"Early-stage architectural sketch lacking formal specifications, protocols, implementation details, or testable mechanisms; reads more as position paper than technical specification.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing network automation, intent-based networking, and digital twin literature; agentic AI application to netops is incremental variation of existing autonomy discussions.\",\n \"mo\": 1,\n \"mon\": \"Single revision, no evidence of WG backing or community engagement; appears to be exploratory draft without sustained development momentum.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI-driven network operations and agent-based autonomy, though treatment is architectural rather than mechanistic; core relevance to autonomous netops.\",\n \"c\": [\n \"Autonomous netops\",\n \"Policy/governance\",\n \"Human-agent interaction\",\n \"Other AI/agent\"\n ]\n}\n```", "in_tok": 722, "out_tok": 335}
|
|
|
|
|
{"draft_name": "draft-ramakrishna-satp-data-sharing", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes a DLT-neutral inter-gateway protocol for requesting and sharing asset views across distributed ledger networks, enabling cross-system interoperability while maintaining access control and native consensus logic. The protocol abstracts internal blockchain complexities through gateway nodes that handle view generation, verification, and globally unique addressing.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution addressing a practical interoperability problem in blockchain ecosystems; the core concepts of gateway-mediated cross-chain communication and view abstraction are established patterns in the space.\",\n \"m\": 3,\n \"mn\": \"Protocol architecture is conceptually defined with clear roles (gateways, views, access control) but lacks detailed message formats, state machine specifications, error handling procedures, and concrete implementation examples or test vectors.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing SATP work, atomic swap protocols, and cross-chain bridge architectures; similar abstraction patterns appear in Polkadot, Cosmos, and other interoperability frameworks already in production.\",\n \"mo\": 2,\n \"mon\": \"Single revision indicated; limited evidence of broader WG adoption or community engagement; addresses a real problem but lacks momentum signals like multiple versions, implementation reports, or stakeholder backing.\",\n \"r\": 1,\n \"rn\": \"Not relevant to AI agents; this is a blockchain/DLT interoperability protocol with no connection to artificial intelligence, autonomous agents, or agent-related networking and governance topics.\",\n \"c\": [\"Data formats/interop\", \"Policy/governance\", \"Other AI/agent\"]\n}\n```", "in_tok": 710, "out_tok": 374}
|
|
|
|
|
{"draft_name": "draft-liu-rtgwg-mdt-in-high-bdp", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft proposes a Massive Data Transmission (MDT) framework for efficiently utilizing nighttime bandwidth in high BDP networks through terminal-driven intelligent parameter optimization. It describes use cases, architectural components, and mechanisms for coordinating TCP/network parameters across endpoints, controllers, and network devices.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution combining existing concepts (TCP tuning, traffic engineering, load balancing) without significant novel mechanisms; parameter optimization for bulk transfer is well-established territory.\",\n \"m\": 2,\n \"mn\": \"Early-stage problem statement with architectural overview but lacks protocol specifications, message formats, detailed algorithms, implementation examples, or interoperability considerations; reads as motivational rather than technical specification.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing work on TCP parameter optimization (RFC 7323, RFC 9293), software-defined networking load balancing, and ALTO/traffic engineering frameworks; terminal-driven coordination resembles established SDN approaches.\",\n \"mo\": 1,\n \"mon\": \"Single revision, no evidence of WG engagement or community discussion; appears to be initial submission with limited adoption signals or iterative development.\",\n \"r\": 1,\n \"rn\": \"Not relevant to AI/agents\u2014focuses on bulk data transmission optimization, TCP tuning, and network load balancing in traditional datacenter/ISP contexts; no connection to AI systems, autonomous agents, or ML-driven networking.\",\n \"c\": [\n \"Other AI/agent\"\n ]\n}\n```", "in_tok": 636, "out_tok": 359}
|
|
|
|
|
{"draft_name": "draft-ietf-lamps-attestation-freshness", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft specifies mechanisms for supplying nonces to end entities for inclusion in attestation evidence within certificate signing requests across CMP, EST, and CMC protocols. It addresses the freshness guarantee requirement in remote attestation by defining how RAs/CAs can provide nonces to demonstrate evidence timeliness.\",\n \"n\": 2,\n \"nn\": \"Incremental technical contribution combining existing nonce-based freshness concepts with established certificate management protocols; straightforward extension rather than novel methodology.\",\n \"m\": 3,\n \"mn\": \"Protocol mechanism is defined across three frameworks with clear procedures, though appears to lack implementation experience, test vectors, and interoperability validation data.\",\n \"o\": 3,\n \"on\": \"Shares core concepts with existing nonce-based attestation freshness work and certificate management standards; integrates established patterns without significant architectural novelty.\",\n \"mo\": 3,\n \"mon\": \"Active WG development with structured progression (20-page draft at version date), though actual adoption signals and implementation commitments not evident from abstract.\",\n \"r\": 1,\n \"rn\": \"Not relevant to AI agents; focuses on PKI infrastructure, certificate management, and hardware/platform attestation\u2014no connection to autonomous agents, AI safety, or agent protocols.\",\n \"c\": [\"Agent identity/auth\", \"Data formats/interop\", \"Other AI/agent\"]\n}\n```", "in_tok": 610, "out_tok": 326}
|
|
|
|
|
{"draft_name": "draft-annevk-johannhof-httpbis-cookies", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft standardizes HTTP Cookie and Set-Cookie header fields for HTTP state management, obsoleting RFC 6265 and 6265bis. It addresses historical security and privacy issues while documenting the widely-used cookie mechanism that enables stateful sessions over HTTP.\",\n \"n\": 1,\n \"nn\": \"Trivial update to existing standard; cookies are well-established with no fundamental novelty in this revision\",\n \"m\": 5,\n \"mn\": \"Implementation-ready specification with comprehensive protocol definition, examples, and clear obsolescence of prior standards\",\n \"o\": 5,\n \"on\": \"Near-duplicate of RFC 6265/6265bis; represents incremental standardization update rather than novel work\",\n \"mo\": 3,\n \"mon\": \"Active development with multiple revisions (annevk and johannhof co-authorship suggests sustained WG effort) but not breakthrough momentum\",\n \"r\": 1,\n \"rn\": \"Not relevant to AI agents; cookies are generic HTTP state management with no AI-specific functionality or application\",\n \"c\": [\"Data formats/interop\"]\n}\n```", "in_tok": 560, "out_tok": 269}
|
|
|
|
|
{"draft_name": "draft-zhang-aiproto-svcb-mapping-for-agents", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft proposes a new DNS resource record type called AGENT that is compatible with SVCB to improve service resolution for intelligent agent communication protocols. It aims to address gaps in current DNS capabilities for agent-to-agent service discovery and mapping.\",\n \"n\": 2,\n \"nn\": \"Incremental extension of existing SVCB framework; applies established DNS mechanisms to agent domain rather than introducing fundamentally new concepts.\",\n \"m\": 2,\n \"mn\": \"Early sketch stage; abstract suggests problem motivation but 6-page document likely lacks detailed protocol specification, examples, and implementation considerations needed for maturity.\",\n \"o\": 3,\n \"on\": \"Shares core concepts with SVCB and existing service discovery mechanisms; moderate overlap with DNS-based service binding work, though agent-specific application is somewhat differentiated.\",\n \"mo\": 1,\n \"mon\": \"Single revision timestamp (2026-01-05) with no apparent prior versions; appears to be nascent proposal without evidence of iterative development or working group engagement.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to AI agent infrastructure; focused on agent service discovery/registration rather than core AI safety, training, or alignment concerns; operationally useful but not central to AI agent research.\",\n \"c\": [\"A2A protocols\", \"Agent discovery/reg\", \"Data formats/interop\"]\n}\n```", "in_tok": 519, "out_tok": 328}
|
|
|
|
|
{"draft_name": "draft-yang-nmrg-mcp-nm", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes using MCP (Model Context Protocol) for network management to enable AI integration and expose network capabilities through a more agile architecture. Discusses MCP applicability across IETF IP networks for network exposure, server discovery, and communication between network elements and controllers.\",\n \"n\": 2,\n \"nn\": \"Straightforward application of existing MCP standard to network management domain; lacks novel technical contributions or architectural innovations beyond domain adaptation.\",\n \"m\": 2,\n \"mn\": \"Early-stage applicability exploration document; appears to be a position/discussion paper without detailed protocol specifications, implementation guidance, or validation of proposed MCP patterns in network contexts.\",\n \"o\": 4,\n \"on\": \"Significant conceptual overlap with existing network management frameworks (NETCONF/YANG, intent-based networking) and emerging agent-based network automation discussions; MCP application is relatively straightforward.\",\n \"mo\": 1,\n \"mon\": \"Single recent revision (2026-02-24) with limited evidence of broader WG traction; appears to be an individual submission without demonstrated community adoption or follow-up iterations.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to AI agents; focuses on MCP protocol adaptation for network management rather than core agent capabilities, autonomy, or decision-making aspects.\",\n \"c\": [\"A2A protocols\", \"Agent discovery/reg\", \"Data formats/interop\", \"Autonomous netops\"]\n}\n```", "in_tok": 563, "out_tok": 343}
|
|
|
|
|
{"draft_name": "draft-ietf-rats-ear", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"EAR defines a standardized message format for verifiers to encode attestation appraisal results, embedding a trustworthiness vector and contextual information to enable relying parties to make authorization decisions. It supports both simple and composite devices with multiple attesters and can be serialized as CWT or JWT.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution building on established attestation frameworks (AR4SI trustworthiness vectors, EAT); primarily standardizes message encoding rather than introducing novel concepts.\",\n \"m\": 4,\n \"mn\": \"Well-specified protocol with detailed format definitions, 27 pages of technical detail, support for extensions, and serialization options; lacks explicit test vectors and implementation artifacts.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing RATS ecosystem (EAT, AR4SI, CWT/JWT); EAR serves as a concrete binding mechanism for these established standards rather than novel integration.\",\n \"mo\": 4,\n \"mon\": \"Active IETF WG development (RATS), clear standardization track with dated draft, builds on established consensus standards; represents coordinated ecosystem maturation.\",\n \"r\": 1,\n \"rn\": \"Not relevant to AI agents or autonomous systems; this is purely a remote attestation and device trust infrastructure standard with no AI/ML/agent components.\",\n \"c\": [\"Agent identity/auth\", \"Data formats/interop\", \"Policy/governance\"]\n}\n```", "in_tok": 680, "out_tok": 348}
|
|
|
|
|
{"draft_name": "draft-beyer-agent-identity-avian-carriers", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"An April Fools' RFC extending avian carrier protocols (RFC 1149) to support cryptographic identity and provenance attestation for AI agents communicating via pigeons. The draft humorously addresses hallucination propagation and authorship tracking in multi-agent LLM delegation chains using feather-based transport.\",\n \"n\": 1,\n \"nn\": \"Trivial extension combining existing satirical RFCs (1149, 2549, 6214) with trendy agent identity concepts; no genuine technical contribution beyond the joke.\",\n \"m\": 1,\n \"mn\": \"Problem statement framed as comedy; no actual protocol specification, mechanisms, or implementation details provided. Explicitly marked April 1 publication.\",\n \"o\": 5,\n \"on\": \"Near-duplicate conceptually of RFC 1149 (Avian Carriers) and RFC 2549 (IP over Avian Carriers); merely adds buzzwords about AI agents without substantive differentiation.\",\n \"r\": 1,\n \"rn\": \"Not genuinely about AI agents or relevant problems\u2014purely a joke draft exploiting current AI hype by pairing it with a well-known IETF April Fools' meme. No real agent identity work.\",\n \"mo\": 1,\n \"mon\": \"April 1 publication with no indication of serious development, follow-up revisions, or WG interest. Designed as one-off satire.\",\n \"c\": [\"Agent identity/auth\", \"Other AI/agent\"]\n}\n```", "in_tok": 624, "out_tok": 364}
|
|
|
|
|
{"draft_name": "draft-ietf-grow-va", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Virtual Aggregation (VA) is a FIB suppression technique that allows ISPs to dramatically reduce routing table sizes in individual routers by an order of magnitude without cooperation between ASes. The approach works autonomously within an ISP domain and maintains compatibility with legacy routers while keeping path length increases negligible.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution building on existing aggregation concepts; FIB suppression is a recognized problem with known solution categories, though VA's specific autonomous deployment approach adds some novelty.\",\n \"m\": 4,\n \"mn\": \"Well-defined protocol mechanism with clear specifications for suppression logic, aggregation rules, and deployment scenarios; includes detailed examples and architectural considerations, though lacks comprehensive implementation test vectors.\",\n \"o\": 3,\n \"on\": \"Shares conceptual overlap with CIDR aggregation, route summarization, and other FIB optimization techniques; addresses similar problems as route filtering and selective FIB loading in existing literature.\",\n \"mo\": 2,\n \"mon\": \"Single 2024 revision suggests stable mature draft; appears to be addressing established routing scalability concern without indicating active development momentum or recent community engagement changes.\",\n \"r\": 1,\n \"rn\": \"Not relevant to AI agents or autonomous agent protocols; this is pure routing infrastructure optimization with no AI/ML, autonomous agent, or intelligent networking components.\",\n \"c\": [\"Other AI/agent\"]\n}\n```", "in_tok": 653, "out_tok": 337}
|
|
|
|
|
{"draft_name": "draft-josefsson-chempat", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Chempat defines a generic family of hybrid post-quantum/traditional key encapsulation mechanisms combining classical DH curves with PQ algorithms like ML-KEM and NTRU Prime. The specification provides concrete instantiated combinations for protocol integration with separate security analysis of the combiner construct.\",\n \"n\": 2,\n \"nn\": \"Hybrid PQ/T KEMs are well-established; this is a systematic enumeration of specific algorithm combinations rather than a novel combining approach.\",\n \"m\": 4,\n \"mn\": \"Detailed specification of concrete instantiated mechanisms with multiple algorithm pairs; appears implementation-ready though test vectors not mentioned in abstract.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing hybrid KEM frameworks (RFC 9180 hybrid constructs, HPKE patterns); similar enumeration approach to other standardization efforts.\",\n \"mo\": 2,\n \"mon\": \"Single dated submission (2025-10-20); unclear if this is active WG work or independent effort; no indication of revision history or community adoption.\",\n \"r\": 1,\n \"rn\": \"Not relevant to AI agents or autonomous systems; cryptographic key exchange mechanism is orthogonal to agent protocols unless specifically for agent-to-agent authenticated channels.\",\n \"c\": [\"Agent identity/auth\", \"Data formats/interop\"]\n}\n```", "in_tok": 651, "out_tok": 320}
|
|
|
|
|
{"draft_name": "draft-li-zt-consideration", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft examines applying Zero Trust principles to network infrastructure, arguing that perimeter-centric security models are insufficient for modern distributed environments and advocating for continuous verification of all entities and communications regardless of network location.\",\n \"n\": 2,\n \"nn\": \"Zero Trust concepts are well-established; applying them to network infrastructure is an incremental extension of existing ZT philosophy rather than a novel contribution.\",\n \"m\": 2,\n \"mn\": \"The draft appears to be a position paper or motivational document outlining limitations and principles, but lacks detailed protocol specifications, mechanisms, or implementation guidance.\",\n \"o\": 5,\n \"on\": \"Zero Trust architecture, continuous verification, and internal network protection are extensively covered in existing literature, standards (NIST SP 800-207), and multiple IETF drafts; this work shows near-complete conceptual overlap.\",\n \"mo\": 1,\n \"mon\": \"Single revision dated 2026-01-15 with no evidence of WG engagement, community discussion, or iterative development history.\",\n \"r\": 1,\n \"rn\": \"Not relevant to AI agents or autonomous systems; focuses on traditional network security architecture without connection to AI/agent-specific concerns.\",\n \"c\": [\"Policy/governance\"]\n}\n```", "in_tok": 668, "out_tok": 301}
|
|
|
|
|
{"draft_name": "draft-liu-agent-context-protocol", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes a standardized protocol for exchanging context information between AI agents. Aims to enable interoperability and coordination in multi-agent systems through structured message formats.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution; agent communication protocols are well-established in MAS literature, though formalization for IETF may have modest value.\",\n \"m\": 2,\n \"mn\": \"Early sketch phase; 8 pages suggests high-level specification without detailed message formats, state machines, error handling, or implementation guidance.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing agent communication standards (FIPA ACL, JSON-RPC for agents), semantic web ontologies, and general RPC/messaging protocols; novelty unclear without draft content.\",\n \"mo\": 1,\n \"mon\": \"Single revision at submission; no evidence of WG sponsorship, community discussion, or iterative development cycle typical of progressing IETF work.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI agent systems; agent-to-agent communication is core infrastructure need, though relevance depends on whether this addresses genuine interop gaps.\",\n \"c\": [\n \"A2A protocols\",\n \"Data formats/interop\",\n \"Agent discovery/reg\"\n ]\n}\n```", "in_tok": 458, "out_tok": 320}
|
|
|
|
|
{"draft_name": "draft-jia-oauth-scope-aggregation", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes a single OAuth 2.0 authorization mechanism where AI agents pre-aggregate all required scopes for multi-step workflows, eliminating repeated consent prompts and authorization round-trips. This addresses user friction and efficiency concerns in agent-driven authorization flows.\",\n \"n\": 2,\n \"nn\": \"Incremental extension of OAuth 2.0 that applies existing scope concepts to agent workflows; scope pre-aggregation is a straightforward optimization rather than a novel authorization paradigm.\",\n \"m\": 2,\n \"mn\": \"Early sketch with abstract describing the concept; likely lacks detailed protocol specifications, security analysis of scope prediction accuracy, or implementation guidance for handling dynamic/conditional scope requirements.\",\n \"o\": 3,\n \"on\": \"Shares foundational concepts with OAuth 2.0 incremental authorization, consent bundling patterns, and agent capability specification; some overlap with scope-on-behalf-of and dynamic consent mechanisms in related work.\",\n \"mo\": 1,\n \"mon\": \"Very recent (2026-02-10) single-revision draft with no visible WG discussion, adoption signals, or implementation reports; appears to be early-stage individual submission.\",\n \"r\": 4,\n \"rn\": \"Directly addresses practical authorization challenge in multi-step AI agent workflows; highly relevant to agent identity/auth and human-agent interaction but assumes agents can reliably predict scope needs upfront.\",\n \"c\": [\"Agent identity/auth\", \"Human-agent interaction\", \"A2A protocols\", \"Policy/governance\"]\n}\n```", "in_tok": 535, "out_tok": 360}
|
|
|
|
|
{"draft_name": "draft-jiang-cats-reference-acn", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft proposes a CATS-based reference model for AI-Agent Communication Networks (ACN), defining reference points, protocol stacks, and service provisioning for communication between AI agents. It extends the existing CATS framework to accommodate AI agent-specific requirements while maintaining generalizability.\",\n \"n\": 2,\n \"nn\": \"Incremental adaptation of CATS framework to AI agents; limited conceptual novelty beyond applying existing steering mechanisms to a new domain\",\n \"m\": 2,\n \"mn\": \"Early-stage framework sketch; describes reference model structure and signaling procedures but lacks detailed protocol specifications, implementation examples, or validation mechanisms\",\n \"o\": 4,\n \"on\": \"Significant overlap with CATS (Compute-Aware Traffic Steering); builds directly on existing framework with limited differentiation; relates to ongoing agent communication standardization efforts\",\n \"mo\": 1,\n \"mon\": \"Single revision as of Jan 2026; no evidence of WG adoption, community discussion, or iterative development; appears dormant\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI agent communication infrastructure; addresses real gap in agent-to-agent protocol frameworks, though presentation ties heavily to CATS rather than agent-specific requirements\",\n \"c\": [\"A2A protocols\", \"Agent discovery/reg\", \"Data formats/interop\", \"ML traffic mgmt\"]\n}\n```", "in_tok": 576, "out_tok": 329}
|
|
|
|
|
{"draft_name": "draft-wang-cats-innetwork-infer", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes ODSI, a decentralized framework for distributed LLM inference across untrusted participants using layer-wise execution with deadline awareness and cryptographic accountability. Addresses the architectural and coordination challenges of networked inference without specifying concrete protocols.\",\n \"n\": 4,\n \"nn\": \"Novel framing of LLM inference as deadline-constrained, layer-wise distributed computation with explicit treatment of activation transport across untrusted domains; extends CATS concept to inference workloads.\",\n \"m\": 2,\n \"mn\": \"Framework-level specification only; no protocol definitions, message formats, state machines, or implementation guidance provided; defers all concrete technical details to future documents.\",\n \"o\": 2,\n \"on\": \"Minor overlap with federated ML and model serving work; most similar to model parallelism and pipeline parallelism schemes but applied to decentralized settings; activation transport concept is somewhat novel.\",\n \"mo\": 2,\n \"mon\": \"Single draft dated 2026-03-02 with no apparent revision history; CATS working group context suggests some institutional support but limited evidence of broader community adoption.\",\n \"r\": 5,\n \"rn\": \"Core to AI agent infrastructure; directly addresses distributed inference coordination, agent-to-agent model serving, and decentralized AI systems.\",\n \"c\": [\n \"Model serving/inference\",\n \"A2A protocols\",\n \"Agent identity/auth\",\n \"Data formats/interop\",\n \"Autonomous netops\",\n \"Policy/governance\"\n ]\n}\n```", "in_tok": 792, "out_tok": 370}
|
|
|
|
|
{"draft_name": "draft-haberkamp-ipp", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"IPP proposes a cryptographic protocol for binding human intent to autonomous AI agent actions through signed, scope-bounded tokens that preserve an auditable chain from human principal to terminal execution. The protocol uses Ed25519 signatures, DIDs, and a narrowing invariant to enforce lineage, non-repudiation, and interoperability across agent orchestration platforms.\",\n \"n\": 4,\n \"nn\": \"Novel framing of intent-as-primitive with formal scope-narrowing constraints; combines DID-based identity with intent tokens in way not clearly standardized elsewhere, though builds on established crypto primitives.\",\n \"m\": 2,\n \"mn\": \"Early draft stage (18 pages, dated 2026-03-16); describes conceptual model and token structure but lacks implementation details, test vectors, or worked examples of protocol flows.\",\n \"o\": 3,\n \"on\": \"Shares concepts with OIDC delegation, capability systems (OCAP), and blockchain provenance work; token binding resembles macaroons and SAML assertions; overlaps moderately with existing accountability frameworks but intent-specific framing is somewhat novel.\",\n \"m\": 2,\n \"mon\": \"Single dated revision with no visible WG adoption or reference implementations; future date suggests speculative/aspirational status; minimal community momentum apparent.\",\n \"r\": 5,\n \"rn\": \"Directly addresses core AI agent accountability gap (human intent attribution, multi-agent delegation, regulatory compliance); highly relevant to enterprise agent deployments.\",\n \"c\": [\n \"Agent identity/auth\",\n \"Human-agent interaction\",\n \"Policy/governance\",\n \"A2A protocols\",\n \"Data formats/interop\",\n \"AI safety/alignment\"\n ]\n}\n```", "in_tok": 770, "out_tok": 413}
|
|
|
|
|
{"draft_name": "draft-song-oauth-ai-agent-authorization", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes a target_id extension to OAuth 2.0 to enable granular authorization for AI agents by explicitly identifying authorization targets. Aims to improve permission management and traceability while maintaining backward compatibility with existing OAuth workflows.\",\n \"n\": 2,\n \"nn\": \"Incremental extension adding a single optional field to OAuth 2.0; the core concept of target-based authorization is not novel, though application to AI agents is somewhat new.\",\n \"m\": 2,\n \"mn\": \"Early sketch with abstract concepts but lacking detailed protocol mechanics, implementation examples, or formal specification of how target_id integrates with OAuth 2.0 flows.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing OAuth 2.0 scope mechanisms and resource indicators (RFC 8707); the differentiation from standard authorization patterns is unclear.\",\n \"mo\": 1,\n \"mon\": \"Single revision dated 2026-01-06 with no evidence of WG discussion, implementation efforts, or iterative development.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to AI agents; addresses authorization but lacks depth on AI-specific security concerns, agent autonomy levels, or delegation patterns unique to agentic systems.\",\n \"c\": [\"Agent identity/auth\", \"Policy/governance\"]\n}\n```", "in_tok": 601, "out_tok": 315}
|
|
|
|
|
{"draft_name": "draft-zl-agents-networking-framework", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes a networking framework for agent systems in enterprise and broadband environments, defining core components and their interactions. Attempts to establish foundational architecture for agent-to-agent and agent-to-infrastructure communication.\",\n \"n\": 2,\n \"nn\": \"Incremental framework definition without clear technical innovation; appears to repurpose existing networking concepts for agent systems rather than proposing novel mechanisms or protocols.\",\n \"m\": 2,\n \"mn\": \"Early-stage sketch with abstract component descriptions but lacks concrete protocol specifications, message formats, or implementation details needed for reproducible systems.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing work on service meshes, microservice architectures, IoT frameworks, and general distributed systems networking\u2014unclear differentiation from established patterns.\",\n \"mo\": 1,\n \"mon\": \"Limited adoption signals; appears to be initial submission without evidence of WG discussion, community feedback, or iterative development process.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to AI agent networking but frames agents primarily as generic distributed entities rather than addressing distinctive AI/ML agent requirements like model serving, inference coordination, or LLM-specific concerns.\",\n \"c\": [\n \"A2A protocols\",\n \"Agent discovery/reg\",\n \"Data formats/interop\",\n \"Autonomous netops\",\n \"Agent identity/auth\"\n ]\n}\n```", "in_tok": 481, "out_tok": 335}
|
|
|
|
|
{"draft_name": "draft-ietf-sshm-mlkem-hybrid-kex", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Defines hybrid post-quantum/traditional key exchange methods combining ML-KEM with ECDH for SSH transport layer security. Provides practical cryptographic agility to protect SSH against future quantum threats while maintaining backward compatibility with current algorithms.\",\n \"n\": 2,\n \"nn\": \"Incremental extension applying NIST-standardized ML-KEM to SSH hybrid mode; straightforward combination of existing primitives with established hybrid patterns.\",\n \"m\": 4,\n \"mn\": \"Well-defined protocol specification with explicit algorithm combinations, parameters, and SSH integration details; ready for implementation with clear normative requirements.\",\n \"o\": 4,\n \"on\": \"Significant overlap with concurrent PQ/T hybrid SSH work (RFC 9142 patterns, similar ML-KEM+ECDH combinations); follows established hybrid methodology from broader IETF PQC effort.\",\n \"mo\": 4,\n \"mon\": \"Active IETF SSHM WG adoption expected; aligns with NIST ML-KEM standardization (FIPS 203) and broad industry push for PQC SSH readiness; multiple implementations anticipated.\",\n \"r\": 1,\n \"rn\": \"Not relevant to AI agents; focuses on cryptographic transport security infrastructure with no connection to autonomous agents, ML models, or AI-specific systems.\",\n \"c\": [\"Other AI/agent\"]\n}\n```", "in_tok": 552, "out_tok": 331}
|
|
|
|
|
{"draft_name": "draft-abaris-aicdh", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes an HTTP response header field to disclose AI-generated or AI-assisted content presence and degree. Designed for machine-readability and compatibility with HTTP structured field syntax to serve user agents, bots, and archiving systems.\",\n \"n\": 2,\n \"nn\": \"Incremental extension applying existing header mechanisms to an emerging disclosure need; straightforward application of structured fields to AI content labeling.\",\n \"m\": 3,\n \"mn\": \"Defined protocol mechanism with header syntax specified, but lacks implementation examples, test vectors, and validation guidance for determining AI content degree.\",\n \"o\": 3,\n \"on\": \"Shares conceptual overlap with content labeling schemes (Content-Type headers, metadata frameworks) and overlaps partially with emerging AI transparency initiatives and content provenance standards.\",\n \"mo\": 1,\n \"mon\": \"Single revision dated 2026-01-30 with no visible WG adoption, community discussion, or implementation activity; appears inactive or nascent.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI transparency and content governance, addressing human-agent interaction and policy/governance concerns around AI-generated content disclosure.\",\n \"c\": [\"Data formats/interop\", \"Policy/governance\", \"Human-agent interaction\"]\n}\n```", "in_tok": 543, "out_tok": 305}
|
|
|
|
|
{"draft_name": "draft-hu-neotec-usecases-notc", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Presents use cases for AI-based video recognition and dynamic bandwidth management in telco cloud environments, emphasizing the need for standardized interfaces between cloud and network controllers for resource optimization across heterogeneous computing and network domains.\",\n \"n\": 2,\n \"nn\": \"Combines existing concepts (AI inference, resource scheduling, bandwidth provisioning) in telco context; incremental application rather than novel technical contribution\",\n \"m\": 2,\n \"mn\": \"Early-stage use case document lacking detailed protocol specifications, implementation examples, or architectural standards; primarily motivational rather than prescriptive\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing telco cloud orchestration, RAN intelligence, and network slicing work; similar use cases covered in O-RAN, 3GPP, and ETSI MEC literature\",\n \"mo\": 1,\n \"mon\": \"Single submission with no revision history; appears to be initial draft without indication of WG backing or community engagement\",\n \"r\": 3,\n \"rn\": \"Partially relevant\u2014addresses AI inference deployment and network orchestration but lacks focus on agent autonomy, decision-making, or agent-to-agent protocols central to AI agent standards\",\n \"c\": [\n \"Model serving/inference\",\n \"ML traffic mgmt\",\n \"Autonomous netops\",\n \"Data formats/interop\",\n \"Policy/governance\"\n ]\n}\n```", "in_tok": 597, "out_tok": 341}
|
|
|
|
|
{"draft_name": "draft-kale-agntcy-federated-privacy", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft proposes a reference architecture for privacy-preserving federated learning in multi-tenant AI agent systems, combining federated averaging, differential privacy, and secure aggregation to enable collaborative model training across organizational boundaries while maintaining data isolation. The work addresses a relevant problem at the intersection of federated learning and AI agent deployment but relies primarily on combining existing techniques without substantial novel contributions.\",\n \"n\": 2,\n \"nn\": \"Incremental combination of well-established techniques (federated averaging, differential privacy, secure aggregation); architecture-level contribution is limited and straightforward application of known privacy-preserving mechanisms to multi-tenant agent scenarios.\",\n \"m\": 2,\n \"mn\": \"Early sketch stage; provides architectural overview and abstract concepts but lacks detailed protocol specifications, formal privacy proofs, concrete algorithms, implementation guidance, or test vectors necessary for deployment or standardization.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing federated learning frameworks (FedAvg, DP-SGD) and secure aggregation protocols; multi-tenant isolation concepts are standard in cloud systems; limited novelty in application-specific adaptations.\",\n \"mo\": 1,\n \"mon\": \"Single submission with no evidence of revision history, working group engagement, or community adoption; no indication of implementation efforts or deployment interest from industry.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI agent systems and federated agent training scenarios; addresses real privacy concerns in multi-tenant agent deployments; strong relevance to agent governance and data isolation requirements.\",\n \"c\": [\n \"Policy/governance\",\n \"Agent identity/auth\",\n \"Data formats/interop\",\n \"AI safety/alignment\"\n ]\n}\n```", "in_tok": 548, "out_tok": 401}
|
|
|
|
|
{"draft_name": "draft-nederveld-adl", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"ADL proposes a JSON-based standard for declaring AI agent properties including identity, capabilities, tools, permissions, and security requirements. It aims to enable discovery, interoperability, and lifecycle management across diverse agent platforms and runtimes.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution\u2014applying familiar JSON schema patterns to agent description, similar to existing container/service definition formats adapted for AI context.\",\n \"m\": 3,\n \"mn\": \"Defined protocol structure with clear semantics for agent declaration and media type registration, but limited evidence of implementation maturity or test coverage.\",\n \"o\": 4,\n \"on\": \"Significant overlap with container orchestration schemas (Docker, Kubernetes), OpenAPI/AsyncAPI for capability description, and other emerging agent frameworks (Anthropic's tool-use specs, OpenAI agent specs).\",\n \"mo\": 1,\n \"mon\": \"Single dated revision (2026-03-08) with no evidence of WG sponsorship, community feedback cycles, or adoption signals; appears to be individual submission.\",\n \"r\": 4,\n \"rn\": \"Directly addresses real interoperability challenge in emerging multi-agent ecosystems, though at stage where standardization value depends on market consolidation around agent architectures.\",\n \"c\": [\n \"Data formats/interop\",\n \"Agent identity/auth\",\n \"Agent discovery/reg\",\n \"Policy/governance\"\n ]\n}\n```", "in_tok": 578, "out_tok": 344}
|
|
|
|
|
{"draft_name": "draft-sharif-agent-payment-trust", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes a trust scoring and identity verification protocol for autonomous AI agents making financial payments, featuring a five-dimension trust model, ECDSA-based cryptographic identity, and spend limit enforcement. Complements the secure MCP specification to address financial trustworthiness in the emerging AI agent economy.\",\n \"n\": 2,\n \"nn\": \"Combines existing cryptographic primitives (ECDSA P-256, challenge-response) with a custom five-dimension trust scoring model; incremental contribution applying known patterns to new domain rather than introducing fundamentally new mechanisms.\",\n \"m\": 3,\n \"mn\": \"Defines protocol structure, trust scoring dimensions, and API endpoints with reasonable detail, but lacks implementation examples, test vectors, or concrete algorithmic specifications for anomaly detection and scoring computation.\",\n \"o\": 3,\n \"on\": \"Trust scoring, spend limits, and behavioral monitoring overlap with existing fraud detection systems and payment authorization protocols; identity verification via challenge-response is standard; novel mainly in AI agent context but not in mechanisms.\",\n \"mo\": 2,\n \"mon\": \"Single draft dated 2026-03-25 with no revision history visible; appears to be early-stage submission without evidence of WG adoption, community feedback cycles, or multiple iterations.\",\n \"r\": 4,\n \"rn\": \"Directly addresses financial risk management for autonomous agents, a genuine gap in AI agent infrastructure; highly relevant to agent economy development though framing as IETF-appropriate is debatable.\",\n \"c\": [\n \"Agent identity/auth\",\n \"AI safety/alignment\",\n \"Policy/governance\",\n \"A2A protocols\"\n ]\n}\n```", "in_tok": 685, "out_tok": 392}
|
|
|
|
|
{"draft_name": "draft-yao-agent-auth-considerations", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes OAuth-based extensions for authenticating and authorizing AI agents within Agent Communication Networks. Addresses scalability and trustworthiness requirements for multi-agent systems in vertical industries.\",\n \"n\": 2,\n \"nn\": \"Incremental adaptation of established OAuth framework to agent context; lacks substantive innovation beyond applying existing patterns to new entity types.\",\n \"m\": 2,\n \"mn\": \"Early-stage draft with problem articulation but limited protocol specification detail; 15 pages suggests conceptual framework rather than implementation-ready mechanism.\",\n \"o\": 4,\n \"on\": \"Significant overlap with OAuth 2.0 Device Flow, service-to-service authentication patterns, and emerging IETF work on machine identity; limited differentiation of agent-specific requirements.\",\n \"mo\": 1,\n \"mon\": \"Single dated revision with no evidence of community engagement, working group traction, or iterative refinement cycle typical of progressing IETF work.\",\n \"r\": 4,\n \"rn\": \"Directly addresses legitimate authentication/authorization challenge for AI agent systems, though framing conflates ACN infrastructure concerns with core agent authentication fundamentals.\",\n \"c\": [\"Agent identity/auth\", \"A2A protocols\", \"Policy/governance\", \"Agent discovery/reg\"]\n}\n```", "in_tok": 521, "out_tok": 310}
|
|
|
|
|
{"draft_name": "draft-wang-lisp-ai-agent", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes using LISP (Locator/ID Separation Protocol) as a network substrate for distributed AI agent communication across cloud/edge/endpoint environments. Argues LISP's location transparency and mobility features address requirements like multi-homing and logical isolation at scale for autonomous agent systems.\",\n \"n\": 2,\n \"nn\": \"Incremental application of existing protocol to emerging use case; core idea of using LISP for mobility/location transparency is well-established, application to AI agents is straightforward rather than architecturally novel.\",\n \"m\": 2,\n \"mn\": \"Early sketch stage; abstract indicates exploration of use cases and design considerations, but likely lacks detailed protocol extensions, implementation guidance, or validation of AI agent-specific requirements against LISP mechanisms.\",\n \"o\": 3,\n \"on\": \"Shares fundamental concepts with service discovery and network virtualization literature; overlaps with existing work on LISP for edge computing and distributed systems, though AI agent framing is relatively new.\",\n \"mo\": 1,\n \"mon\": \"Single draft with future date (2026-04-03); no evidence of WG adoption, multiple revisions, or community momentum behind this specific application area.\",\n \"r\": 3,\n \"rn\": \"Partially relevant; addresses networking infrastructure for AI agents but focuses on lower-layer protocol mechanics rather than agent-specific concerns like reasoning, coordination, safety, or autonomy.\",\n \"c\": [\n \"A2A protocols\",\n \"Agent discovery/reg\",\n \"Autonomous netops\",\n \"Data formats/interop\",\n \"Agent identity/auth\"\n ]\n}\n```", "in_tok": 586, "out_tok": 387}
|
|
|
|
|
{"draft_name": "draft-dunbar-onions-ac-te-applicability", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft evaluates how existing IETF YANG data models for Attachment Circuits and Traffic Engineering can be applied to edge AI inference deployment, mapping network performance requirements (bandwidth, latency, reliability) to optimal edge location selection for real-time AI workloads.\",\n \"n\": 2,\n \"nn\": \"Incremental application of existing YANG models to an emerging use case; combines established network abstraction patterns with edge AI scenarios but lacks fundamental new concepts.\",\n \"m\": 2,\n \"mn\": \"Early-stage applicability exercise; identifies potential model mappings and gaps rather than proposing concrete protocol mechanisms or detailed specifications with implementation guidance.\",\n \"o\": 3,\n \"on\": \"Shares conceptual overlap with existing TE and ACaaS work; applies established YANG patterns to edge computing but doesn't significantly duplicate prior proposals.\",\n \"mo\": 1,\n \"mon\": \"Single submission with October 2025 date suggests early-stage; no evidence of WG adoption, multiple revisions, or community engagement; appears exploratory rather than active development.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to AI/ML\u2014addresses network requirements for edge AI inference placement but focuses on network service provisioning rather than AI/agent behavior, decision-making, or agent-specific protocols.\",\n \"c\": [\n \"Model serving/inference\",\n \"ML traffic mgmt\",\n \"Data formats/interop\",\n \"Autonomous netops\"\n ]\n}\n```", "in_tok": 629, "out_tok": 354}
|
|
|
|
|
{"draft_name": "draft-yl-agent-id-requirements", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft addresses digital identity management requirements for AI agent communication protocols, proposing a cross-industry universal framework for secure agent-to-agent and agent-to-entity interactions. The work focuses on establishing foundational identity standards as essential infrastructure for future AI agent networks.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution recognizing an important gap, but the requirements-gathering approach is standard practice; lacks novel identity mechanisms or approaches.\",\n \"m\": 1,\n \"mn\": \"Problem statement and motivation only; no protocol specification, architecture, or technical mechanisms defined; abstract-level discussion without concrete proposals.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing identity/authentication standards (OAuth 2.0, OIDC, DIDs, W3C Verifiable Credentials); limited differentiation for AI agent-specific use cases articulated.\",\n \"mo\": 1,\n \"mon\": \"Single document snapshot; no indication of WG activity, revisions, or community engagement; appears to be exploratory stage without sustained momentum.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI agent infrastructure; identity management is genuinely critical for multi-agent systems, though execution and specificity are underdeveloped.\",\n \"c\": [\n \"Agent identity/auth\",\n \"A2A protocols\",\n \"Agent discovery/reg\",\n \"Data formats/interop\",\n \"Policy/governance\"\n ]\n}\n```", "in_tok": 562, "out_tok": 348}
|
|
|
|
|
{"draft_name": "draft-narvaneni-agent-uri", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes agent:// URI scheme for identifying and discovering autonomous software agents across systems. Defines four conformance levels from minimal addressing to full descriptor-based discovery with authentication, complementing existing agent communication protocols like MCP and A2A.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution addressing a real gap (URI-based agent addressing), but URI schemes and service discovery are well-established patterns; the novelty lies primarily in applying existing mechanisms to the agent domain.\",\n \"m\": 3,\n \"mn\": \"Protocol specification is defined with layered architecture and conformance levels, though details on descriptor formats, actual discovery mechanisms, and interoperability examples appear limited for a 50-page draft.\",\n \"o\": 3,\n \"on\": \"Shares significant conceptual overlap with DNS-SD, XMPP URI schemes, and existing service discovery frameworks (mDNS, SRV records); positioning relative to these standards unclear.\",\n \"mo\": 2,\n \"mon\": \"Single publication date listed (2026-04-18, appears future-dated); no evidence of WG adoption, multiple revisions, or community discussion; appears early-stage work.\",\n \"r\": 4,\n \"rn\": \"Directly addresses a real interoperability need in the emerging agent ecosystem, though relevance depends on whether agent:// becomes adopted versus existing HTTP/gRPC endpoints.\",\n \"c\": [\n \"A2A protocols\",\n \"Agent discovery/reg\",\n \"Agent identity/auth\",\n \"Data formats/interop\"\n ]\n}\n```", "in_tok": 620, "out_tok": 373}
|
|
|
|
|
{"draft_name": "draft-ietf-aipref-vocab", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes a standardized vocabulary for declaring AI usage restrictions and permissions on digital assets, enabling automated systems to respect content creator preferences. Addresses growing need for machine-readable consent mechanisms as AI training and processing become ubiquitous.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution building on existing robot.txt/metadata patterns; core concept of preference vocabularies is established but application to AI-specific use cases is somewhat novel.\",\n \"m\": 3,\n \"mn\": \"Defines protocol/mechanism with reasonable structure but lacks implementation details, test vectors, and validation examples; ready for review but needs maturity for production deployment.\",\n \"o\": 4,\n \"on\": \"Significant overlap with C2PA, Data Nutrition Labels, and schema.org markup approaches; competes with robot.txt extensions and emerging AI-specific metadata standards; positioning relative to these lacks clarity.\",\n \"mo\": 2,\n \"mon\": \"Single revision cycle evident; limited WG engagement signals; vocabulary definitions present but adoption pathway and community backing appear underdeveloped.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI agent governance and data usage control; addresses legitimate concern but positioned as infrastructure layer rather than core agent protocol.\",\n \"c\": [\n \"Policy/governance\",\n \"Data formats/interop\",\n \"AI safety/alignment\"\n ]\n}\n```", "in_tok": 492, "out_tok": 328}
|
|
|
|
|
{"draft_name": "draft-romanchuk-normative-admissibility", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes a normative framework for evaluating admissibility of autonomous agent speech acts based on modality and grounding state rather than semantic truth. Enables deterministic, auditable assessment of agent statements without requiring truth verification or semantic interpretation.\",\n \"n\": 2,\n \"nn\": \"Incremental formalization of existing agent communication concepts; applies standard speech act theory (Austin/Searle) to agent verification without substantial novelty in the underlying philosophy or mechanisms.\",\n \"m\": 2,\n \"mn\": \"Early sketch with conceptual framework; defines admissibility categories but lacks detailed specifications, implementation guidance, concrete examples, test vectors, or algorithmic precision needed for practical deployment.\",\n \"o\": 4,\n \"on\": \"Significant overlap with speech act theory, agent communication frameworks, and existing IETF work on agent protocols; the core distinction (grounding-based rather than truth-based evaluation) is narrow and not deeply differentiated from prior work.\",\n \"mo\": 1,\n \"mon\": \"Single draft from January 2026 with no visible revision history, WG adoption, or community discussion; no evidence of active development or stakeholder engagement in the agent standardization community.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to AI agents and autonomous systems; addresses agent communication semantics but lacks connection to practical agent deployment, interoperability standards, or current IETF agent-related work streams.\",\n \"c\": [\n \"A2A protocols\",\n \"Human-agent interaction\",\n \"Policy/governance\"\n ]\n}\n```", "in_tok": 558, "out_tok": 369}
|
|
|
|
|
{"draft_name": "draft-guy-bary-stamp-protocol", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"STAMP proposes a cryptographic delegation and proof framework for multi-agent AI systems, binding access tokens to specific tasks and agent identities while interoperating with OAuth 2.0 and GNAP. The protocol aims to enforce least-privilege and zero-trust principles in agentic environments with dynamic, non-deterministic workflows.\",\n \"n\": 3,\n \"nn\": \"Task-bound tokens and message-level proofs for agents represent a useful adaptation of existing delegation concepts, but the core innovation (extending OAuth/GNAP patterns to agent scenarios) is incremental rather than fundamentally novel.\",\n \"m\": 2,\n \"mn\": \"At 9 pages with abstract-level depth, the draft appears to be an early sketch lacking detailed protocol specifications, cryptographic binding details, concrete examples, or test vectors necessary for implementation.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing work in OAuth 2.0 delegation, GNAP authorization, proof-of-possession mechanisms, and multi-agent security frameworks; the contribution is primarily reframing rather than introducing new primitives.\",\n \"mo\": 1,\n \"mon\": \"Single revision dated 2025-11-03 with no visible WG adoption, community discussion, or implementation evidence; appears to be an initial submission without tracked momentum.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to agent identity/authentication and agent-to-agent communication security, with clear applications to autonomous multi-agent systems; somewhat less central to other AI/ML concerns like model serving or safety alignment.\",\n \"c\": [\n \"A2A protocols\",\n \"Agent identity/auth\",\n \"Data formats/interop\",\n \"Policy/governance\"\n ]\n}\n```", "in_tok": 611, "out_tok": 411}
|
|
|
|
|
{"draft_name": "draft-cosmos-protocol-specification", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Cosmos proposes a decentralized badge-based identity and communication protocol using cryptographic credentials, trust scoring, and post-quantum encryption without requiring blockchain infrastructure. The protocol integrates semantic messaging, encrypted containers, and a trust-native transport layer designed for deployments prioritizing direct trust relationships.\",\n \"n\": 2,\n \"nn\": \"Combines established concepts (cryptographic credentials, reputation systems, post-quantum crypto) into an integrated stack; lacks fundamental cryptographic or protocol innovations; trust scoring and badge systems are incremental variations on existing credential and capability frameworks.\",\n \"m\": 2,\n \"mn\": \"Abstract references 8 major subsystems but document appears truncated (cuts off mid-sentence in Profile System section); specifications lack concrete algorithm details, cryptographic parameters, example message formats, or test vectors; insufficient maturity for implementation.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing work: badge/capability systems (SPKI/SDSI), trust scoring (web-of-trust models), post-quantum crypto (NIST standardization efforts), encrypted containers (capsule patterns), semantic messaging (Intent-based protocols); primarily a systems composition rather than novel primitives.\",\n \"mo\": 1,\n \"mon\": \"Single draft from 2026-01-02 with no revision history evident; no WG affiliation, implementation references, or adoption signals; appears as isolated submission without community momentum or follow-up activity.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to AI agents: agent identity/authentication mechanisms are directly applicable; trust scoring and decentralized communication could support agent coordination; however, no explicit connection to AI agents, autonomous systems, or agent-specific use cases articulated.\",\n \"c\": [\n \"Agent identity/auth\",\n \"Data formats/interop\",\n \"A2A protocols\",\n \"Policy/governance\"\n ]\n}\n```", "in_tok": 878, "out_tok": 442}
|
|
|
|
|
{"draft_name": "draft-huang-acme-scalable-agent-enrollment", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft proposes extending SCEP and EST certificate enrollment protocols with attestation mechanisms for AI agent identity, offering two models: Zero-Knowledge Proofs for continuous private attestation and bootstrapped host endorsement for scalability.\",\n \"n\": 2,\n \"nn\": \"Incremental extension combining existing protocols (SCEP/EST) with known techniques (ZKP, attestation); the core idea of attestation-enhanced enrollment is not novel, though the specific two-model approach for agents adds some structure.\",\n \"m\": 2,\n \"mn\": \"Early sketch with abstract concepts; lacks protocol details, message flows, concrete examples, security proofs, or implementation guidance; ZKP and bootstrapping models described conceptually but not formally specified.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing work on remote attestation (RATS), certificate enrollment extensions (EST-CoAP, TEEP), and ZKP-based authentication; the agent-specific framing is relatively new but mechanisms are well-established.\",\n \"m\": 1,\n \"mon\": \"No evidence of community adoption, WG engagement, or revision history; appears to be a single submission without prior iterations or demonstrated interest from IETF community.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to agent identity and authentication; addresses real scalability challenges in agentic AI systems; however, the connection to broader AI safety, alignment, or governance is underdeveloped.\",\n \"c\": [\"Agent identity/auth\", \"A2A protocols\", \"Autonomous netops\", \"Policy/governance\"]\n}\n```", "in_tok": 655, "out_tok": 378}
|
|
|
|
|
{"draft_name": "draft-akhavain-moussa-ai-network", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"DA-ITN proposes a multi-plane reference framework connecting AI clients, data providers, model providers, and computational resources to support training, inference, and agentic interactions. The architecture emphasizes control, data, and OAM planes for reliability and accountability but is explicitly positioned as a reference model rather than standardization target.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution; combines existing concepts (multi-plane networking, federated AI infrastructure) without novel architectural primitives or mechanisms. The framing as 'data and agent aware' adds modest specificity to established network abstraction patterns.\",\n \"m\": 1,\n \"mn\": \"Problem statement and conceptual framework only; lacks protocol specifications, formal definitions, data models, interaction sequences, or implementation guidance. States 'various protocols shall be defined' but none are presented.\",\n \"o\": 4,\n \"on\": \"Significant conceptual overlap with federated learning infrastructure, distributed ML platforms (Ray, Kubeflow), and existing multi-plane network frameworks (3GPP, OpenFlow). The agent awareness and lifecycle management add minor differentiation but remain incremental extensions of established paradigms.\",\n \"m\": 1,\n \"mon\": \"Single dated submission (2026-04-29) with no evidence of iterative development, community discussion, or WG traction. Appears to be initial proposal without revision history or adoption signals.\",\n \"r\": 3,\n \"rn\": \"Partially relevant; addresses infrastructure for AI systems and agent interactions but lacks depth on agent autonomy, decision-making, safety, or capability negotiation. Primarily a network/resource management concern rather than AI/agent core topics. Governance and trust elements are mentioned but underdeveloped.\",\n \"c\": [\n \"ML traffic mgmt\",\n \"Model serving/inference\",\n \"Agent discovery/reg\",\n \"Data formats/interop\",\n \"Policy/governance\",\n \"Autonomous netops\"\n ]\n}\n```", "in_tok": 763, "out_tok": 459}
|
|
|
|
|
{"draft_name": "draft-ietf-emu-hybrid-pqc-eapaka", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft proposes integrating hybrid post-quantum cryptography (PQC) into EAP-AKA' Forward Secrecy to protect against quantum computing threats to ephemeral key exchange. It extends RFC9678 by replacing traditional ECDHE with PQ/T hybrid algorithms to achieve quantum-resistant perfect forward secrecy in cellular authentication.\",\n \"n\": 2,\n \"nn\": \"Straightforward application of existing hybrid PQC terminology to a known protocol; incremental security enhancement rather than fundamental innovation.\",\n \"m\": 3,\n \"mn\": \"Defines protocol modifications and mechanism integration but appears to lack implementation details, test vectors, and validation examples needed for deployment readiness.\",\n \"o\": 4,\n \"on\": \"Significant overlap with hybrid PQC standardization efforts (NIST, ISO) and existing EAP-AKA' extensions; primarily combines established components rather than introducing novel integration patterns.\",\n \"mo\": 2,\n \"mon\": \"Single draft revision dated 2026-02-26 with limited evidence of WG adoption or community discussion; typical IETF progression but no clear momentum indicators.\",\n \"r\": 1,\n \"rn\": \"Not relevant to AI agents or autonomous systems; addresses cellular network authentication security, which is infrastructure-layer rather than agent-focused.\",\n \"c\": [\"Other AI/agent\"]\n}\n```", "in_tok": 724, "out_tok": 330}
|
|
|
|
|
{"draft_name": "draft-morrison-mcp-tool-surface-names-registry", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes an IANA registry mechanism for Model Context Protocol tool surface names to enable standardized wire-level identifiers for typed capabilities on MCP servers. Uses Specification Required registration with Designated Expert review, with initial entries from prior related work.\",\n \"n\": 2,\n \"nn\": \"Incremental administrative infrastructure work\u2014establishes a straightforward registry for identifiers in an emerging protocol, lacking novel technical approaches or conceptual contributions.\",\n \"m\": 3,\n \"mn\": \"Well-defined registry mechanism following RFC 8126 standards with clear registration procedures, but narrow scope limited to one administrative function without implementation details or operational guidance.\",\n \"o\": 2,\n \"on\": \"Minor similarities to other IANA registry proposals; the approach is standard registry design with no significant overlap with existing specifications.\",\n \"mo\": 2,\n \"mon\": \"Single revision draft addressing a foundational need for related work ([ORGALTER]); limited evidence of broader community adoption or working group momentum beyond the Morrison-family drafts.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI agent infrastructure\u2014MCP is a core protocol for agent-server interaction, and standardized tool naming is essential for interoperability in agent frameworks.\",\n \"c\": [\n \"A2A protocols\",\n \"Agent discovery/reg\",\n \"Data formats/interop\"\n ]\n}\n```", "in_tok": 636, "out_tok": 331}
|
|
|
|
|
{"draft_name": "draft-gaikwad-aps-profile", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes APS Profile, a vendor-neutral storage service class for managing durable persistent state in autonomous agents, addressing compliance, cryptographic erasure, and high-frequency I/O patterns. Bridges the gap between agent frameworks treating storage as generic filesystems and storage administrators managing stateless VMs by introducing standardized Usage Classes and Kubernetes/CSI integration.\",\n \"n\": 2,\n \"nn\": \"Incremental work applying existing storage abstraction patterns (CSI, Redfish/Swordfish) to agent-specific workloads; compliance/erasure requirements are domain-familiar but not novel in isolation.\",\n \"m\": 2,\n \"mn\": \"Early sketch phase\u2014defines conceptual Usage Class and schema guidance but lacks concrete protocol mechanics, serialization formats, API signatures, or implementation reference; experimental status indicates pre-spec maturity.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing storage profiles (Swordfish, CSI), compliance frameworks (NIST, GDPR deletion provisions), and vector database designs; primarily repackages known concepts for agent context rather than novel composition.\",\n \"mo\": 1,\n \"mon\": \"Single draft iteration (2025-11-30), no visible WG adoption, cross-references suggest early exploration; no evidence of implementation feedback loop or community engagement beyond authors.\",\n \"r\": 3,\n \"rn\": \"Partially relevant\u2014addresses real agent infrastructure challenge (state durability & compliance) but frames as storage abstraction rather than agent-specific protocol; relevance depends on whether targets AI/agent communities or storage standardization bodies.\",\n \"c\": [\n \"Data formats/interop\",\n \"Policy/governance\",\n \"Agent identity/auth\",\n \"Other AI/agent\"\n ]\n}\n```", "in_tok": 736, "out_tok": 418}
|
|
|
|
|
{"draft_name": "draft-lake-pocero-authkem-edhoc", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft extends EDHOC with post-quantum cryptography support by defining KEM-based authentication methods that enable signature-free authentication using NIST-standardized ML-KEM. It addresses quantum resistance for the EDHOC handshake protocol while maintaining compatibility with existing COSE infrastructure.\",\n \"n\": 2,\n \"nn\": \"Incremental extension applying known PQC mechanisms (ML-KEM) to existing EDHOC protocol; combines established concepts rather than introducing fundamentally new authentication approaches.\",\n \"m\": 4,\n \"mn\": \"Well-specified protocol with detailed mechanism definitions; 33 pages suggests comprehensive treatment with protocol flows and parameter specifications, though test vectors and implementation guidance may be limited.\",\n \"o\": 3,\n \"on\": \"Shares conceptual overlap with other EDHOC extensions and general PQC integration efforts; follows standard IETF patterns for adding cryptographic agility to existing protocols.\",\n \"mo\": 2,\n \"mon\": \"Single dated revision visible; appears to be exploratory work without clear WG adoption signals or active community engagement indicated in provided metadata.\",\n \"r\": 2,\n \"rn\": \"Tangentially related to AI agents; relevant only if agents use EDHOC for secure communication, but draft focuses on cryptographic protocol mechanics rather than agent-specific concerns.\",\n \"c\": [\n \"Agent identity/auth\",\n \"Data formats/interop\",\n \"Other AI/agent\"\n ]\n}\n```", "in_tok": 570, "out_tok": 354}
|
|
|
|
|
{"draft_name": "draft-zeng-mcp-troubleshooting", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft proposes mapping the Model Context Protocol (MCP) to network management, enabling LLM-based network controllers to interact with devices as MCP servers for intent-driven troubleshooting and remediation. It aims to leverage existing MCP standards rather than develop new protocols, integrating conversational AI with network automation.\",\n \"n\": 2,\n \"nn\": \"Incremental application of an existing protocol (MCP) to a new domain. The core innovation is the mapping itself, but MCP and network troubleshooting are both mature concepts being combined rather than fundamentally novel.\",\n \"m\": 2,\n \"mn\": \"Early sketch phase. The draft outlines conceptual mapping but lacks implementation details, protocol specifications, security analysis, or concrete examples. No test vectors, reference implementations, or deployment scenarios provided.\",\n \"o\": 3,\n \"on\": \"Moderate overlap with existing network management protocols (YANG/NETCONF, gRPC, SNMP) and recent intent-based networking work. MCP itself is new to networking but the troubleshooting use case is well-explored.\",\n \"mo\": 1,\n \"mon\": \"Single revision (2025-10-20 date suggests recent submission). No evidence of WG adoption, multiple iterations, or community interest. Limited revision history suggests early-stage exploration.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI agents in network operations. Addresses agent-human interaction, autonomous netops, and interoperability standards. Clearly positioned at intersection of LLM applications and network automation.\",\n \"c\": [\n \"A2A protocols\",\n \"Autonomous netops\",\n \"Agent identity/auth\",\n \"Data formats/interop\",\n \"Human-agent interaction\"\n ]\n}\n```", "in_tok": 614, "out_tok": 421}
|
|
|
|
|
{"draft_name": "draft-li-cats-aisemantic-contract", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes a semantic-driven contract model enabling AI applications to communicate tensor flow requirements to networks, enabling differentiated scheduling and resource allocation. Addresses inefficiency of treating AI training/inference as opaque byte streams by exposing minimal necessary semantics for optimized forwarding decisions.\",\n \"n\": 3,\n \"nn\": \"Useful contribution bridging AI workload semantics and network scheduling, but incremental over existing intent-based networking and QoS frameworks adapted for ML contexts.\",\n \"m\": 2,\n \"mn\": \"Early sketch with abstract concept; lacks concrete protocol specification, message formats, state machine definitions, or implementation details needed for standardization.\",\n \"o\": 4,\n \"on\": \"Significant overlap with intent-based networking (RFC 9315 context), CATS (Computing-Aware Traffic Steering), and existing ML-aware network proposals; semantic signaling pattern well-established.\",\n \"mo\": 1,\n \"mon\": \"Single revision at March 2026; no evidence of WG adoption, implementation efforts, or iterative development; appears to be initial submission.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to ML traffic management and autonomous network operations for AI; addresses real optimization problem in distributed training and inference scenarios.\",\n \"c\": [\"ML traffic mgmt\", \"Autonomous netops\", \"Model serving/inference\", \"Data formats/interop\"]\n}\n```", "in_tok": 609, "out_tok": 331}
|
|
|
|
|
{"draft_name": "draft-zhao-anima-automatic-congestion-relief", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes an automatic congestion relief mechanism using intelligent traffic analysis and dynamic regulation to handle fiber optic failures through real-time self-healing. The draft addresses network resilience but lacks technical depth on the proposed mechanisms.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution; congestion relief and self-healing are well-established concepts. The 'intelligent' traffic analysis claim is vague without concrete algorithmic or ML novelty.\",\n \"m\": 1,\n \"mn\": \"Problem statement only; abstract provides minimal technical detail on mechanisms, algorithms, or architecture. No protocol specification, implementation details, or evaluation methodology evident from 7-page draft.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing work on traffic engineering, Fast Reroute (FRR), segment routing, and YANG-based network automation. Self-healing networks extensively covered in prior standards.\",\n \"mo\": 1,\n \"mon\": \"Single revision with no apparent WG engagement, community discussion, or adoption signals. No indication of implementation or testing.\",\n \"r\": 3,\n \"rn\": \"Partially relevant; mentions 'intelligent' analysis suggesting ML/AI but provides no concrete agent architecture, decision mechanisms, or autonomous behavior specifications required for AI/agent relevance.\",\n \"c\": [\n \"ML traffic mgmt\",\n \"Autonomous netops\",\n \"Other AI/agent\"\n ]\n}\n```", "in_tok": 507, "out_tok": 339}
|
|
|
|
|
{"draft_name": "draft-rosenberg-oauth-aauth", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes Agent Authorization Grant extension to OAuth 2.1 enabling AI agents to obtain access tokens via PII collected through natural language conversation rather than traditional OAuth flows, addressing use cases where agents interact with users through PSTN or text. Core focus is preventing LLM hallucination from enabling impersonation attacks.\",\n \"n\": 2,\n \"nn\": \"Incremental extension adapting existing OAuth 2.1 patterns to a specific use case; core concepts (grants, scopes, token constraints) are well-established, applying them to agent-mediated authorization is moderately novel but relatively straightforward.\",\n \"m\": 2,\n \"mn\": \"Early sketch stage; 10 pages suggests abstract and problem formulation present but likely lacks detailed protocol mechanics, examples, security analysis depth, and implementation guidance needed for production deployment.\",\n \"o\": 3,\n \"on\": \"Shares conceptual overlap with device flow and CIBA (Client-Initiated Backchannel Authentication) for out-of-band authorization; distinguishing factor is explicit LLM hallucination attack surface, but architectural foundations are familiar.\",\n \"m\": 1,\n \"mon\": \"Single revision with April 2026 date suggests nascent proposal; no evident WG adoption or community discussion signals detectable from metadata alone.\",\n \"r\": 5,\n \"rn\": \"Directly addresses core AI agent challenge\u2014secure delegation and token acquisition for autonomous systems\u2014with explicit focus on preventing agent-driven impersonation attacks, making it highly relevant to agent identity/auth domain.\",\n \"c\": [\n \"Agent identity/auth\",\n \"Human-agent interaction\",\n \"A2A protocols\",\n \"AI safety/alignment\",\n \"Policy/governance\"\n ]\n}\n```", "in_tok": 636, "out_tok": 414}
|
|
|
|
|
{"draft_name": "draft-hong-nmrg-agenticai-ps", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft presents a problem statement for applying agentic AI to network management, arguing for standardization efforts to enable autonomous AI agents to collaborate in automating network operations. It identifies key technological gaps and proposes areas requiring IETF/IRTF standardization to realize this vision.\",\n \"n\": 2,\n \"nn\": \"Incremental application of existing AI/agent concepts to network management domain; combines established autonomous agent paradigms with known network management challenges without introducing fundamentally new technical approaches.\",\n \"m\": 1,\n \"mn\": \"Pure problem statement document with no protocol specifications, mechanisms, or implementation details; early-stage positioning paper outlining motivations rather than concrete technical solutions.\",\n \"o\": 4,\n \"on\": \"Significant overlap with ongoing IETF/IRTF work on AI/ML in networking (e.g., ANIMA, various AI/ML drafts); agent concepts largely borrowed from established multi-agent systems literature without distinguishing factors.\",\n \"mo\": 2,\n \"mon\": \"Single submission as problem statement; no indication of WG backing, multiple revisions, or community adoption; typical initial positioning for seeking consensus on new standardization direction.\",\n \"r\": 4,\n \"rn\": \"Directly addresses AI agent applications in network management, core relevance to IRTF NMRG scope; however, focuses on problem framing rather than novel agent-specific technical challenges.\",\n \"c\": [\n \"Autonomous netops\",\n \"Policy/governance\",\n \"Agent discovery/reg\",\n \"Agent identity/auth\",\n \"A2A protocols\",\n \"AI safety/alignment\"\n ]\n}\n```", "in_tok": 569, "out_tok": 394}
|
|
|
|
|
{"draft_name": "draft-han-agent-comm-enterprise", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes an agent identifier and semantic routing mechanism for heterogeneous AI agents in enterprise campus networks, addressing identification, capability discovery, and secure collaboration among multi-agent systems.\",\n \"n\": 2,\n \"nn\": \"Incremental work combining existing concepts (service discovery, semantic routing, agent registration) without substantial technical innovation beyond applying established patterns to agent scenarios.\",\n \"m\": 2,\n \"mn\": \"Early sketch stage; abstract indicates conceptual framework but 7-page limit suggests preliminary treatment lacking detailed protocol specifications, message formats, or implementation examples.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing standards (service discovery protocols, semantic web approaches, microservice architectures) and prior IETF work on capability advertisement and routing; limited differentiation for agent-specific requirements.\",\n \"mo\": 1,\n \"mon\": \"Single dated submission (2026-03-15) with no evidence of WG adoption, revisions, or community engagement; appears as standalone contribution without momentum indicators.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI agent networking and enterprise deployment scenarios; addresses core agent challenges (identity, discovery, secure communication) but scope limited to campus-level rather than broader Internet-scale agent coordination.\",\n \"c\": [\n \"Agent identity/auth\",\n \"Agent discovery/reg\",\n \"A2A protocols\",\n \"Data formats/interop\",\n \"Autonomous netops\"\n ]\n}\n```", "in_tok": 521, "out_tok": 349}
|
|
|
|
|
{"draft_name": "draft-dunbar-neotec-ac-te-applicability", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft evaluates applying existing IETF YANG data models (AC-as-a-Service and TE topology) to support dynamic AI model placement at edge cloud sites, using street-level camera inference as a practical use case to identify model applicability and gaps.\",\n \"n\": 2,\n \"nn\": \"Incremental application of existing standards to edge AI; combines known YANG models with a contemporary use case but lacks fundamental methodological or technical novelty.\",\n \"m\": 3,\n \"mn\": \"Defined protocols leveraged with concrete use case mapping; provides topology and service models but remains primarily an applicability study rather than detailed specification of new mechanisms.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing AC/TE YANG work; applicability draft in well-established domain with limited differentiation from prior standards documentation.\",\n \"mo\": 2,\n \"mon\": \"Single draft revision dated 2025-06-23; no indication of WG adoption, multiple versions, or community momentum beyond initial submission.\",\n \"r\": 3,\n \"rn\": \"Partially relevant; addresses edge inference placement and network service modeling for AI workloads but focuses on network data models rather than AI agent behavior, safety, or core ML systems.\",\n \"c\": [\n \"Model serving/inference\",\n \"Data formats/interop\",\n \"ML traffic mgmt\",\n \"Autonomous netops\"\n ]\n}\n```", "in_tok": 630, "out_tok": 344}
|
|
|
|
|
{"draft_name": "draft-helixar-hdp-agentic-delegation", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"HDP proposes a cryptographic token protocol for recording and verifying chains of delegation in multi-agent AI systems, enabling offline verification of authorization provenance without central registries or trust anchors. The protocol uses Ed25519 signatures to create append-only delegation chains traceable back to human authorization events.\",\n \"n\": 4,\n \"nn\": \"Novel framing of delegation provenance as a cryptographic chain-of-custody problem specific to agentic AI; token-based approach without registry dependency is a useful originality, though signature-chain patterns exist elsewhere.\",\n \"m\": 3,\n \"mn\": \"Protocol mechanism is well-specified with clear data structures and verification procedures, but lacks implementation details, test vectors, and security proofs; ready for review but pre-prototype stage.\",\n \"o\": 3,\n \"on\": \"Shares conceptual overlap with SAML/OAuth delegation models, W3C Verifiable Credentials, and capability-based security tokens; distinctly scoped to AI agent chains but not entirely novel in cryptographic approach.\",\n \"mo\": 2,\n \"mon\": \"Single draft dated 2026-03-26 with no evidence of prior versions, WG adoption, or implementation momentum; early-stage contribution without clear adoption pathway.\",\n \"r\": 5,\n \"rn\": \"Directly addresses core need in agentic AI systems: authorization transparency, audit trails, and provenance verification across agent delegation chains; highly relevant to safety and accountability.\",\n \"c\": [\n \"Agent identity/auth\",\n \"Human-agent interaction\",\n \"Policy/governance\",\n \"A2A protocols\",\n \"AI safety/alignment\"\n ]\n}\n```", "in_tok": 710, "out_tok": 396}
|
|
|
|
|
{"draft_name": "draft-liao-aipref-autoctl-core", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes a machine-readable protocol for controlling server-side automation permissions in response to AI-driven web automation, extending RFC 9309 with HTTP method restrictions and purpose requirements.\",\n \"n\": 2,\n \"nn\": \"Incremental extension of existing robots.txt-like framework; applies familiar permission model to broader automation scenarios rather than introducing novel control mechanisms.\",\n \"m\": 2,\n \"mn\": \"Early sketch stage; abstract indicates file format and restrictions defined, but likely lacks comprehensive specification, examples, implementation guidance, and test vectors needed for production deployment.\",\n \"o\": 4,\n \"on\": \"Significant overlap with RFC 9309 (robots.txt successor), web crawling directives (robots.txt, Crawl-delay), and similar agent control proposals; builds incrementally on established patterns.\",\n \"mo\": 1,\n \"mon\": \"Single revision dated 2025-11-03 with no evidence of WG sponsorship, community feedback, or multiple iterations; appears to be individual submission without momentum indicators.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI agent governance and autonomous web automation control; addresses legitimate concern about uncontrolled AI automation but positioned narrowly within server-side policy rather than broader AI safety.\",\n \"c\": [\n \"Policy/governance\",\n \"Data formats/interop\",\n \"Agent discovery/reg\",\n \"AI safety/alignment\"\n ]\n}\n```", "in_tok": 523, "out_tok": 344}
|
|
|
|
|
{"draft_name": "draft-xu-sidrops-asrank-vulnerabilities", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft analyzes structural vulnerabilities in ASRank, an algorithm for inferring AS business relationships from BGP data, demonstrating how adversarial manipulation of routing data can alter inference results without detection. The work identifies design flaws that make ASRank sensitive to minimal input changes and discusses security implications for BGP operations and security research.\",\n \"n\": 3,\n \"nn\": \"Useful contribution identifying a real vulnerability class in widely-deployed infrastructure, though vulnerability analysis of specific algorithms is somewhat incremental research.\",\n \"m\": 2,\n \"mn\": \"Problem and vulnerability identification are well-articulated but lacks detailed countermeasures, implementation guidance, or validated solutions; primarily analytical rather than protocol-ready.\",\n \"o\": 2,\n \"mn\": \"Minor conceptual overlap with existing BGP security work and inference algorithm robustness studies, but specific focus on ASRank vulnerabilities appears relatively unique.\",\n \"mo\": 1,\n \"mon\": \"Single draft submission with no apparent revision history or active WG engagement noted; appears as standalone security analysis rather than active development effort.\",\n \"r\": 1,\n \"rn\": \"Not relevant to AI agents or autonomous systems in the ML/agent sense; concerns network routing algorithms and BGP infrastructure, despite 'autonomous' terminology referring to network ASes.\",\n \"c\": [\n \"Policy/governance\"\n ]\n}\n```", "in_tok": 595, "out_tok": 325}
|
|
|
|
|
{"draft_name": "draft-li-iotops-intelligent-security", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes an intelligent protection optimization system for IoT networks addressing security and privacy issues through information-centric networking principles across naming, data exchange, and caching layers.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution combining existing ICN concepts with generic security hardening; lacks novel technical mechanisms or theoretical advances.\",\n \"m\": 1,\n \"mn\": \"Abstract-only submission with no protocol specification, architecture details, threat models, or evaluation methodology presented.\",\n \"o\": 4,\n \"on\": \"Significant overlap with ICN security literature (NDN, CCN) and existing IoT security frameworks; limited differentiation from prior work.\",\n \"mo\": 1,\n \"mon\": \"Single submission with no revision history; no evidence of WG engagement, community review, or active development cycle.\",\n \"r\": 1,\n \"rn\": \"Not related to AI agents or autonomous systems; generic IoT security topic with no agent-based or ML components.\",\n \"c\": [\"Other AI/agent\"]\n}\n```", "in_tok": 568, "out_tok": 251}
|
|
|
|
|
{"draft_name": "draft-vandemeent-iddrop", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"IDDrop proposes an identity-transfer protocol for moving identity and actor claims across human and machine environments using offer-first and request-first modes. It emphasizes sealed carrier truth and semantic classification over filename-based identity, profiling the TIBET TAT handoff model.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution combining existing identity transfer concepts with proximity workflows; lacks clear differentiation from OAuth/SAML/OIDC token exchange patterns.\",\n \"m\": 2,\n \"mn\": \"Early sketch with abstract protocol concepts; references undefined 'TIBET TAT' model; no formal grammar, message flows, or implementation details provided in 8-page draft.\",\n \"o\": 4,\n \"on\": \"Significant overlap with established identity federation (SAML, OIDC), delegated authorization (OAuth2), and proximity-based exchange protocols; unclear novelty over existing standards.\",\n \"mo\": 1,\n \"mon\": \"Single draft submission; no visible WG discussions, revisions, or community adoption signals; appears dormant or exploratory.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to agent identity/auth and human-agent interaction scenarios; potential applicability to daemon-to-daemon exchange, but relevance to core AI agent concerns unclear.\",\n \"c\": [\"Agent identity/auth\", \"Human-agent interaction\", \"A2A protocols\", \"Data formats/interop\"]\n}\n```", "in_tok": 622, "out_tok": 342}
|
|
|
|
|
{"draft_name": "draft-yu-agent-identifier-rdap", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes an RDAP profile extension for querying AI agent identifier registration data, enabling applications to access trusted metadata about agent identities, network locators, gateways, and operational status. Reuses existing RDAP query mechanisms and JSON formats while defining agent-specific object classes and extensions.\",\n \"n\": 2,\n \"nn\": \"Incremental application of established RDAP protocol to a new domain; core contribution is mapping agent metadata requirements to existing registration data access patterns rather than novel protocol design.\",\n \"m\": 3,\n \"mn\": \"Defines protocol profile with JSON object schema and extension members; appears specification-ready but draft date (2026) raises concerns about actual maturity status and whether implementation experience exists.\",\n \"o\": 3,\n \"on\": \"Shares conceptual overlap with agent discovery/registry systems and identity management frameworks; RDAP application itself is not novel, though agent-specific bindings (IPv6 locators, gateways, revocation) add some specificity.\",\n \"mo\": 1,\n \"mon\": \"Single draft with 2026 future date suggests hypothetical or very early-stage work; no evidence of WG discussion, multiple revisions, or implementation adoption; unclear if addressing real deployment needs.\",\n \"r\": 4,\n \"rn\": \"Directly addresses agent identity and authentication infrastructure needs; relevant to autonomous agent deployments requiring trusted metadata access, though framing focuses more on infrastructure than AI agent behavior/alignment.\",\n \"c\": [\n \"Agent identity/auth\",\n \"Agent discovery/reg\",\n \"Data formats/interop\",\n \"Autonomous netops\"\n ]\n}\n```", "in_tok": 686, "out_tok": 389}
|
|
|
|
|
{"draft_name": "draft-sz-dmsc-iaip", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes Intent-based Agent Interconnection Protocol (IAIP) for dynamic routing and discovery of AI agents at gateway nodes based on semantic capability matching rather than static addressing. Defines mechanisms for agent registration, capability advertisement, intent resolution, and intelligent dispatching across agent networks.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution combining existing concepts (capability-based discovery, intent resolution, semantic routing) without substantial algorithmic or architectural novelty. Agent gateway abstraction and intent matching are natural extensions of service mesh and orchestration patterns.\",\n \"m\": 3,\n \"mn\": \"Protocol mechanisms defined at mid-level detail with gateway validation, intent matching, and routing decision frameworks specified, but lacks implementation examples, formal state machines, concrete data formats, and test vectors needed for production deployment.\",\n \"o\": 4,\n \"on\": \"Significant overlap with service mesh architectures (Istio, Consul), intent-based networking (IBN) literature, capability-based service discovery (Kubernetes DNS/service catalogs), and agent orchestration frameworks. Limited differentiation from existing multi-agent coordination protocols.\",\n \"m\": 1,\n \"mon\": \"Single draft revision dated 2026-04-29 with no evidence of WG adoption, community engagement, or iterative refinement. No indication of implementation efforts or deployment interest in IETF mailing lists.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI agent infrastructure and multi-agent systems. Addresses agent discovery and routing which are core operational concerns, though emphasis on intent-semantics over agent safety/alignment limits relevance to broader AI governance topics.\",\n \"c\": [\"A2A protocols\", \"Agent discovery/reg\", \"Autonomous netops\", \"Data formats/interop\", \"Agent identity/auth\"]\n}\n```", "in_tok": 596, "out_tok": 419}
|
|
|
|
|
{"draft_name": "draft-miller-ztip", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"ZTIP proposes three cryptographic primitives for verifiable delegation, intent binding, and behavioral attestation to enable trustless coordination in multi-agent systems. The protocol targets zero-trust architectures where agents must continuously prove authorization and behavioral compliance.\",\n \"n\": 4,\n \"nn\": \"Intent binding as a first-class protocol primitive is relatively novel; most zero-trust work focuses on identity/access rather than intent verification across agent boundaries.\",\n \"m\": 3,\n \"mn\": \"Protocol mechanisms are defined with clear primitives, but maturity depends heavily on whether test vectors and reference implementations exist (49pp suggests detailed spec but implementation status unclear).\",\n \"o\": 3,\n \"on\": \"Shares conceptual overlap with SPIFFE/SPIRE (identity binding), RATS (attestation), and OAuth 2.0 delegation flows; intent-layer innovation distinguishes it from standard zero-trust stacks.\",\n \"mo\": 2,\n \"mon\": \"April 2026 date suggests recent submission; single revision history typical of new proposals; adoption trajectory unknown without WG feedback or early implementations.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to multi-agent AI systems requiring provable authorization and behavioral guarantees; less central than agent discovery or model serving but critical for safe delegation.\",\n \"c\": [\n \"A2A protocols\",\n \"AI safety/alignment\",\n \"Agent identity/auth\",\n \"Policy/governance\",\n \"Autonomous netops\"\n ]\n}\n```", "in_tok": 482, "out_tok": 362}
|
|
|
|
|
{"draft_name": "draft-morrison-substrate-observation", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes substrate-observation as an alternative to envelope coordination for managing concurrent sessions in cross-tool agentic systems, emphasizing what should NOT be standardized rather than introducing new protocol elements. Relies on identity primitives from companion drafts and argues against negotiating wire formats between heterogeneous principals.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution that reframes existing coordination problems; the core insight (avoiding format negotiation) is useful but not fundamentally novel.\",\n \"m\": 2,\n \"mn\": \"Early conceptual sketch lacking concrete mechanism specification, examples, or implementation guidance; heavily dependent on undefined companion drafts (IDPRONOUNS, IDACCORD).\",\n \"o\": 3,\n \"on\": \"Shares coordination and session management concepts with existing agent frameworks and distributed systems protocols; the anti-pattern framing is somewhat novel but the underlying problems are well-known.\",\n \"mo\": 1,\n \"mon\": \"Single draft with May 2026 date; no evidence of revision history, WG discussion, or community feedback; appears to be early-stage work.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to AI agent systems; directly addresses concurrent session coordination for agentic systems but lacks concrete technical depth and depends on unspecified identity infrastructure.\",\n \"c\": [\n \"A2A protocols\",\n \"Agent identity/auth\",\n \"Data formats/interop\",\n \"Agent discovery/reg\"\n ]\n}\n```", "in_tok": 630, "out_tok": 354}
|
|
|
|
|
{"draft_name": "draft-nyantakyi-vaip-agent-identity", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"VAIP proposes a cryptographic identity and permission management protocol specifically designed for autonomous AI agents in enterprise systems, using Ed25519 keys, SHA-256 audit trails, and hierarchical permission scopes. Addresses a genuine gap between human-centric identity protocols (OAuth, SAML) and requirements of autonomous agents operating in multi-tenant environments.\",\n \"n\": 3,\n \"nn\": \"Useful contribution combining established crypto primitives (Ed25519, SHA-256) in agent-specific permission framework; incremental rather than novel in cryptographic approach but addresses legitimate protocol gap.\",\n \"m\": 3,\n \"mn\": \"Defined protocol structure with seven permission scopes and time-bounded grants, but 17 pages suggests incomplete detail; likely lacks implementation examples, test vectors, and deployment guidance needed for spec maturity.\",\n \"o\": 3,\n \"on\": \"Shares conceptual overlap with OAuth2/OIDC (delegated auth), SPIFFE/SPIRE (service identity), and capability-based security models; distinguishes itself via agent-specific permission semantics and audit requirements but not radically different.\",\n \"m\": 2,\n \"mon\": \"Draft dated 2026-04-11 (future date\u2014likely typo) with no revision history visible; single-author submission suggests early-stage work without established WG backing or community visibility.\",\n \"r\": 5,\n \"rn\": \"Directly addresses core AI agent topic: cryptographic identity, fine-grained permissions, and auditability for autonomous agents represent critical security primitives as AI systems gain enterprise operational access.\",\n \"c\": [\n \"Agent identity/auth\",\n \"A2A protocols\",\n \"Policy/governance\",\n \"AI safety/alignment\",\n \"Data formats/interop\"\n ]\n}\n```", "in_tok": 615, "out_tok": 427}
|
|
|
|
|
{"draft_name": "draft-ietf-lake-edhoc", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"EDHOC is a lightweight authenticated Diffie-Hellman key exchange protocol optimized for constrained IoT and embedded devices, reusing COSE/CBOR/CoAP standards to minimize code footprint. It provides mutual authentication, forward secrecy, and identity protection, primarily for establishing OSCORE security contexts in resource-limited scenarios.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution combining existing cryptographic primitives (COSE, CBOR, DH) into a new compact protocol rather than fundamental cryptographic innovation.\",\n \"m\": 5,\n \"mn\": \"Full implementation-ready specification with detailed protocol flows, cryptographic parameters, test vectors, and multiple cipher suite options; highly mature IETF standard.\",\n \"o\": 3,\n \"on\": \"Shares foundational concepts with IKEv2 and other DH-based protocols; combines established COSE standards in novel constrained-device packaging.\",\n \"mo\": 5,\n \"mon\": \"Published IETF standard (RFC 9528) with strong WG adoption, multiple implementations, integration with OSCORE, and active deployment in CoAP/IoT ecosystems.\",\n \"r\": 2,\n \"rn\": \"Not directly relevant to AI agents or autonomous systems; focused on IoT device authentication and key exchange rather than agent identity, coordination, or AI-specific protocols.\",\n \"c\": [\"Agent identity/auth\", \"Data formats/interop\", \"Other AI/agent\"]\n}\n```", "in_tok": 598, "out_tok": 360}
|
|
|
|
|
{"draft_name": "draft-yu-ai-agent-use-cases-in-6g", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft catalogs AI agent use cases for 6G networks by extending 3GPP's 6G vision, focusing on operator requirements for integrating autonomous agents into next-generation telecom infrastructure.\",\n \"n\": 2,\n \"nn\": \"Primarily synthesizes existing 3GPP work rather than introducing novel concepts; incremental contribution mapping AI agents to 6G context.\",\n \"m\": 2,\n \"mn\": \"Early-stage use case enumeration without detailed protocol specifications, mechanisms, or implementation guidance; mostly requirements gathering.\",\n \"o\": 4,\n \"on\": \"Significant overlap with 3GPP TR 22.870; appears to largely repackage and elaborate on standardization body work already in progress.\",\n \"mo\": 2,\n \"mon\": \"Single submission with limited visibility; no evidence of WG adoption or community momentum; follows rather than leads 3GPP trajectory.\",\n \"r\": 4,\n \"rn\": \"Directly addresses AI agents in telecom context, though positioned as derivative work; relevant to 6G standardization efforts but not novel framing.\",\n \"c\": [\n \"Autonomous netops\",\n \"Policy/governance\",\n \"Agent discovery/reg\",\n \"Other AI/agent\"\n ]\n}\n```", "in_tok": 535, "out_tok": 307}
|
|
|
|
|
{"draft_name": "draft-deforth-arp", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"ARP proposes a DNS-TXT-based cryptographic binding mechanism for AI agents to verify machine-readable entity claims, analogous to DKIM but for semantic data consumption by autonomous systems. It addresses narrative injection and spoofing risks in generative search by enabling domain-owner authorization verification of structured data.\",\n \"n\": 2,\n \"nn\": \"Straightforward application of existing primitives (Ed25519, JCS, DNS TXT) to a new domain; combines DKIM concepts with AI agent verification without significant cryptographic or protocol innovation.\",\n \"m\": 3,\n \"mn\": \"Protocol is defined with clear mechanisms and DNS binding model; lacks implementation details, test vectors, and validation of threat model assumptions against real generative search systems.\",\n \"o\": 3,\n \"on\": \"Shares design patterns with DKIM, DANE, and other DNS-based trust anchors; conceptually overlaps with existing entity verification and web-of-trust approaches; modest novelty in framing for AI agents.\",\n \"mo\": 1,\n \"mon\": \"Single publication date (2026-04-18 projected); no evidence of WG discussion, implementation adoption, or community engagement; appears to be initial draft with limited revision history.\",\n \"r\": 3,\n \"rn\": \"Directly addresses AI agent verification needs but narrowly focused on one threat (narrative injection in RAG); relevance depends on whether DNS-TXT binding becomes standard practice for AI data sourcing.\",\n \"c\": [\n \"Agent identity/auth\",\n \"Data formats/interop\",\n \"Agent discovery/reg\",\n \"Policy/governance\"\n ]\n}\n```", "in_tok": 648, "out_tok": 391}
|
|
|
|
|
{"draft_name": "draft-jewell-aibdp", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"AIBDP proposes a machine-readable protocol for websites to declare usage boundaries around their content relative to AI systems, extending existing robots.txt-style mechanisms with specific permissions/denials for training, mimicry, derivatives, and agentic access. The draft attempts to standardize how web content owners can signal AI usage policies across indexing, analytical exploitation, and autonomous agent interaction.\",\n \"n\": 2,\n \"nn\": \"Incremental extension combining established mechanisms (robots.txt, RFC 9116, RFC 9110) with AI-specific use cases; lacks fundamental innovation beyond applying known declarative patterns to new problem domain.\",\n \"m\": 2,\n \"mn\": \"Early sketch phase\u20146 pages insufficient for protocol specification; missing concrete syntax, examples, discovery mechanisms, enforcement models, and handling of conflicting directives; no implementation guidance provided.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing efforts: robots.txt extensions, Robots Exclusion Standard discussions, W3C's web scraping policies, and multiple proprietary AI content policies (OpenAI, Google, Anthropic). Conceptually similar to proposed meta-tag and HTTP header approaches already circulating in AI policy space.\",\n \"mo\": 1,\n \"mon\": \"Single draft submission with 2026 date suggests recent/initial proposal; no evidence of WG adoption, community revisions, or active implementation interest; positioned as future-dated work with unclear sponsorship momentum.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI agent governance and autonomous system boundaries; addresses real policy/governance tension between content creators and AI systems, though solution approach is not distinctly focused on core agent capabilities.\",\n \"c\": [\n \"Policy/governance\",\n \"AI safety/alignment\",\n \"Data formats/interop\",\n \"Agent discovery/reg\",\n \"ML traffic mgmt\"\n ]\n}\n```", "in_tok": 602, "out_tok": 448}
|
|
|
|
|
{"draft_name": "draft-yan-anima-brski-cle", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes BRSKI-CLE, a certificateless enrollment framework for Class 1 constrained IoT devices using Key Encapsulation Mechanisms and lightweight credentials (CWTs) instead of certificates. Addresses RAM limitations in resource-constrained IoT while considering quantum-safe algorithms and authentication centers for credential issuance.\",\n \"n\": 2,\n \"nn\": \"Incremental extension combining existing BRSKI with certificateless approaches; KEM-based enrollment and CWT credentials are established concepts applied to constrained enrollment domain.\",\n \"m\": 2,\n \"mn\": \"Early sketch phase\u2014framework outlined but lacks detailed protocol specifications, message flows, security analysis, and implementation details; explicitly does not specify the lightweight credentials mechanism.\",\n \"o\": 4,\n \"on\": \"Significant overlap with BRSKI (RFC 8995), LAKE authorization (I-D.selander-lake-authz), and prior certificateless IoT work; combines established components rather than novel integration.\",\n \"mo\": 1,\n \"mon\": \"Single revision at 2024-04-25 with no evident WG adoption, community discussion, or subsequent updates; appears dormant in IETF process.\",\n \"r\": 2,\n \"rn\": \"Tangentially related to AI agents\u2014addresses device identity and authentication in constrained environments, but not about autonomous agents, agent protocols, or AI-specific concerns.\",\n \"c\": [\"Agent identity/auth\", \"Data formats/interop\", \"Other AI/agent\"]\n}\n```", "in_tok": 670, "out_tok": 363}
|
|
|
|
|
{"draft_name": "draft-smith-rats-evidence-trans", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft specifies methods to transform diverse evidence structures (DiceTcbInfo, concise evidence, SPDM measurements) into a unified CoRIM internal representation for Remote Attestation Procedures. The goal is to enable Verifiers to consistently appraise trustworthiness of remote Attesters despite varying evidence encoding formats and semantics.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution addressing a practical interoperability problem within RATS; evidence transformation is a natural engineering necessity rather than a conceptual innovation.\",\n \"m\": 4,\n \"mn\": \"Well-specified with concrete transformation methods for three evidence types and clear alignment with CoRIM procedures; appears implementation-ready though 20 pages suggests some complexity remains to be detailed.\",\n \"o\": 3,\n \"on\": \"Shares core concepts with existing RATS work (evidence encoding, verification procedures); fills a specific gap in standardizing transformations across multiple evidence formats but limited novelty in individual transformation approaches.\",\n \"mo\": 2,\n \"mon\": \"Single revision (2025-04-04 date suggests recent/ongoing work); appears to be specialized RATS infrastructure work with likely limited broader community momentum.\",\n \"r\": 1,\n \"rn\": \"Not relevant to AI agents or autonomous systems; focuses purely on attestation infrastructure and evidence format standardization in security/trust contexts. False positive for AI/agent classification.\",\n \"c\": [\n \"Data formats/interop\"\n ]\n}\n```", "in_tok": 613, "out_tok": 351}
|
|
|
|
|
{"draft_name": "draft-gupta-httpapi-events-query", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"EQP proposes a minimal HTTP-based protocol enabling user agents to receive event notifications directly from resources. It aims to simplify event subscription and delivery by treating the resource itself as the authoritative notification source.\",\n \"n\": 2,\n \"nn\": \"Incremental refinement of existing pub-sub and webhook patterns; HTTP long-polling and server-sent events already address similar use cases with established implementations.\",\n \"m\": 3,\n \"mn\": \"Protocol mechanics are defined with reasonable clarity, but lacks implementation examples, formal test vectors, and guidance on error handling, backpressure, or scalability considerations.\",\n \"o\": 4,\n \"on\": \"Substantial conceptual overlap with WebSub (RFC 8313), WebHooks, Server-Sent Events (RFC 9110), and AMQP; positioning versus these alternatives is unclear.\",\n \"mo\": 1,\n \"mon\": \"Single draft revision (2025-10-17 date suggests recent submission); no evidence of WG discussion, implementations, or community feedback loop.\",\n \"r\": 2,\n \"rn\": \"Tangentially related to agent infrastructure; event notification is a utility concern for distributed agents but not core to AI agent behavior, safety, or autonomy.\",\n \"c\": [\"Data formats/interop\", \"Other AI/agent\"]\n}\n```", "in_tok": 504, "out_tok": 318}
|
|
|
|
|
{"draft_name": "draft-lake-pocero-authkem-ikr-edhoc", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes an efficient KEM-based authentication variant for EDHOC optimized for initiator-known-responder scenarios in constrained environments, enabling post-quantum secure three-message handshakes without signatures.\",\n \"n\": 3,\n \"nn\": \"Useful contribution refining prior KEM-auth work for specific operational constraints, but builds incrementally on established EDHOC framework.\",\n \"m\": 4,\n \"mn\": \"Detailed protocol specification with clear message flows and security analysis; appears implementation-ready but lacks test vectors and reference implementations.\",\n \"o\": 3,\n \"on\": \"Shares cryptographic concepts and EDHOC framework with prior KEM-authentication work; extends rather than overlaps significantly.\",\n \"mo\": 2,\n \"mon\": \"Single revision as of 2026-01-08; limited evidence of broader WG momentum or multiple author collaboration cycles.\",\n \"r\": 2,\n \"rn\": \"Tangentially related to autonomous agent infrastructure through authentication/identity mechanisms; not core to AI agent protocols or behavior.\",\n \"c\": [\"Agent identity/auth\", \"Data formats/interop\"]\n}\n```", "in_tok": 651, "out_tok": 278}
|
|
|
|
|
{"draft_name": "draft-ye-problems-and-requirements-of-dns-for-ioa", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft proposes that DNS should evolve to support Internet of Agents (IoA) by analyzing DNS limitations for agent collaboration. It identifies technical requirements for DNS to accommodate AI-driven agent interactions and complex service discovery scenarios.\",\n \"n\": 2,\n \"nn\": \"Incremental extension of DNS for a new use case; applies existing DNS concepts to agent scenarios without fundamental protocol innovations.\",\n \"m\": 1,\n \"mn\": \"Problem statement and requirements analysis only; lacks concrete protocol specifications, mechanisms, or implementation details.\",\n \"o\": 3,\n \"on\": \"Shares conceptual overlap with existing DNS extension work (SRV records, service discovery), agent identity/discovery drafts, and general IoT DNS requirements.\",\n \"mo\": 2,\n \"mon\": \"Single submission with April 2026 date; appears to be early-stage work without evidence of multiple revisions or working group engagement.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to AI agents; focuses on infrastructure requirements rather than core agent capabilities, alignment, or safety concerns.\",\n \"c\": [\n \"Agent discovery/reg\",\n \"Data formats/interop\",\n \"Agent identity/auth\",\n \"Autonomous netops\",\n \"A2A protocols\"\n ]\n}\n```", "in_tok": 517, "out_tok": 310}
|
|
|
|
|
{"draft_name": "draft-cui-ai-agent-discovery-invocation", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes a standardized protocol for discovering and invoking AI agents across platforms through metadata description, capability-based matching, and RESTful interfaces, with optional intent-based selection extension. Aims to enable interoperable multi-agent systems with consistent invocation semantics and security mechanisms.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution combining existing REST patterns, metadata schemas, and service discovery concepts. Similar mechanisms exist in microservices (OpenAPI), cloud platforms (AWS service catalogs), and prior agent standards, though AI-specific metadata is useful.\",\n \"m\": 3,\n \"mn\": \"Protocol mechanisms are reasonably defined with metadata formats and invocation semantics specified, but lacks implementation examples, test vectors, compliance test suites, and reference implementations needed for maturity level 4-5.\",\n \"o\": 4,\n \"on\": \"Significant overlap with OpenAPI/Swagger (metadata/invocation), UDDI/service registries (discovery), OData (capability negotiation), existing agent frameworks (LangChain, AutoGen), and emerging standards like OpenAI's function calling and tool use specifications.\",\n \"mo\": 2,\n \"mon\": \"Single revision dated 2026-02-12 with no evidence of WG adoption, multiple implementations, or community feedback cycles. Early-stage draft status suggests nascent momentum.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI agent interoperability and multi-agent system coordination, core topics in current AI infrastructure discussions, though framing assumes standardization need that vendors may resist.\",\n \"c\": [\n \"A2A protocols\",\n \"Agent discovery/reg\",\n \"Agent identity/auth\",\n \"Data formats/interop\",\n \"Model serving/inference\"\n ]\n}\n```", "in_tok": 657, "out_tok": 421}
|
|
|
|
|
{"draft_name": "draft-zhao-nmrg-ai-agent-for-ndt", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes integrating AI agents with Network Digital Twin (NDT) technology for network management and operations. Combines emerging paradigms of autonomous agents and digital twin simulations to enable intelligent network control and monitoring.\",\n \"n\": 2,\n \"nn\": \"Incremental combination of two established concepts (AI agents, digital twins) without clear novel architectural insights; architecture details absent from abstract.\",\n \"m\": 2,\n \"mn\": \"Early-stage sketch; 8-page draft suggests conceptual overview only, lacks detailed protocol specifications, deployment architecture, or implementation guidance.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing NDT work (ONF, ITU) and AI agent frameworks (BDI, service-oriented agent architectures); limited differentiation apparent from abstract.\",\n \"mo\": 2,\n \"mon\": \"Single draft revision as of March 2026; no evidence of WG adoption, community feedback, or active development cycle; NMRG typically exploratory rather than standards-track.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI agents and autonomous network operations; NDT increasingly central to network intelligence discussions; timely topic but execution clarity needed.\",\n \"c\": [\n \"Autonomous netops\",\n \"Agent discovery/reg\",\n \"Data formats/interop\",\n \"ML traffic mgmt\",\n \"Policy/governance\"\n ]\n}\n```", "in_tok": 477, "out_tok": 339}
|
|
|
|
|
{"draft_name": "draft-yue-moq-transporting-sensing-data", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft proposes using Media Over QUIC (MOQ) as a transport mechanism for large-scale, real-time sensing data in 6G networks, addressing challenges in autonomous driving, smart cities, and industrial IoT through protocol adaptability and QoS awareness. The work leverages QUIC's low-latency multiplexing to enable efficient data fragmentation and secure transmission for diverse sensing and system data types.\",\n \"n\": 2,\n \"nn\": \"Applying existing MOQ framework to 6G sensing data is a straightforward extension; the document lacks novel transport mechanisms or fundamental protocol innovations beyond adapting current QUIC capabilities.\",\n \"m\": 2,\n \"mn\": \"Document presents problem motivation and high-level approach but lacks detailed protocol specifications, formal definitions, algorithmic details, or implementation guidance; appears to be an early-stage position paper.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing MOQ work, 6G sensing/data transport discussions, and QUIC application proposals; limited differentiation from concurrent efforts in standardization bodies addressing similar 6G data transport challenges.\",\n \"mo\": 1,\n \"mon\": \"Single revision noted (2025-10-19), no evidence of active WG sponsorship, community feedback incorporation, or iterative development; appears to be exploratory rather than driven by sustained momentum.\",\n \"r\": 2,\n \"rn\": \"Tangentially related to AI agents; mentions AI data as a use case but does not address agent-specific concerns like autonomous decision-making, agent coordination, or intelligent system requirements; primarily a networks/6G paper.\",\n \"c\": [\n \"Data formats/interop\",\n \"ML traffic mgmt\",\n \"Autonomous netops\",\n \"Other AI/agent\"\n ]\n}\n```", "in_tok": 680, "out_tok": 422}
|
|
|
|
|
{"draft_name": "draft-zm-rtgwg-mcp-troubleshooting", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft proposes mapping the Model Context Protocol (MCP) to network management, enabling LLM-based troubleshooting by treating network devices as MCP servers and controllers as clients, with extensions for device-to-device collaboration during controller unavailability.\",\n \"n\": 2,\n \"nn\": \"Incremental application of an existing protocol (MCP) to a new domain; the core innovation is straightforward domain mapping rather than novel methodology.\",\n \"m\": 2,\n \"mn\": \"Early sketch with conceptual mappings but lacks detailed specifications, implementation examples, security proofs, or test cases needed for protocol standardization.\",\n \"o\": 4,\n \"on\": \"Significant conceptual overlap with existing intent-based networking (IBN) frameworks and YANG-based management; MCP transport is relatively orthogonal to established network automation patterns.\",\n \"mo\": 1,\n \"mon\": \"Limited evidence of community engagement; single revision with future date suggests speculative draft; no clear WG sponsorship or implementation demonstrations.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI agent orchestration in network operations, though framed primarily as troubleshooting tool rather than general-purpose agent coordination.\",\n \"c\": [\n \"A2A protocols\",\n \"Autonomous netops\",\n \"Agent identity/auth\",\n \"Data formats/interop\",\n \"Agent discovery/reg\",\n \"Human-agent interaction\"\n ]\n}\n```", "in_tok": 673, "out_tok": 352}
|
|
|
|
|
{"draft_name": "draft-gaikwad-south-authorization", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"SOUTH introduces probabilistic authorization decisions for services and autonomous agents, incorporating uncertainty and contextual factors. The protocol is transport-independent and composable with existing auth mechanisms like OAuth and mutual TLS.\",\n \"n\": 2,\n \"nn\": \"Probabilistic authorization is not novel; uncertainty in access control exists in prior work. The main contribution is formalizing this for agent/service contexts, which is incremental.\",\n \"m\": 3,\n \"mn\": \"Protocol structure is defined with request/response objects and HTTP binding specified, but lacks implementation details, test vectors, and security analysis depth expected for maturity.\",\n \"o\": 4,\n \"on\": \"Significant overlap with attribute-based access control (ABAC), policy-based authorization frameworks, and probabilistic security models. Relationship to existing IETF auth work (OAuth, mutual TLS) not clearly differentiated.\",\n \"mo\": 1,\n \"mon\": \"Single revision as of 2025-11-28, no evidence of WG adoption, community discussion, or implementation reports. Appears early-stage with no institutional momentum.\",\n \"r\": 3,\n \"rn\": \"Tangentially relevant to autonomous agents through service authorization context, but not addressing core AI safety, agent coordination, or decision-making challenges. More about infrastructure than agent behavior.\",\n \"c\": [\n \"Agent identity/auth\",\n \"Policy/governance\",\n \"A2A protocols\",\n \"Data formats/interop\"\n ]\n}\n```", "in_tok": 588, "out_tok": 355}
|
|
|
|
|
{"draft_name": "draft-li-atp", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"ATP proposes a two-tier server-mediated protocol for autonomous agent communication across four deployment scales, emphasizing DNS discovery, mandatory ATS/ATK authentication, and multiple interaction patterns. The draft addresses routing, security, and resource management for an emerging Internet of Agents paradigm.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution combining established patterns (server-mediated architecture, DNS-SVC discovery, pub/sub messaging) with agent-specific framing; limited conceptual novelty beyond repackaging existing protocol primitives.\",\n \"m\": 3,\n \"mn\": \"Protocol structure and message semantics defined at medium depth; lacks implementation details, test vectors, code examples, and security analysis depth required for production readiness.\",\n \"o\": 4,\n \"on\": \"Significant overlap with MQTT (broker model, async messaging), AMQP (request/response patterns), gRPC (service discovery), and CoAP (resource-constrained agents); positioning against these is unclear and incomplete.\",\n \"mo\": 2,\n \"mon\": \"Single draft revision with 2026 date suggests early stage; no visible WG sponsorship, community feedback, or implementation signals; adoption prospects unclear.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to agent-to-agent communication infrastructure; addresses real multi-scale deployment challenges but lacks differentiation from existing protocols or evidence of agent-specific requirements.\",\n \"c\": [\n \"A2A protocols\",\n \"Agent identity/auth\",\n \"Agent discovery/reg\",\n \"Autonomous netops\",\n \"Data formats/interop\",\n \"Policy/governance\"\n ]\n}\n```", "in_tok": 670, "out_tok": 395}
|
|
|
|
|
{"draft_name": "draft-zhang-rtgwg-ai-agents-troubleshooting", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes use cases and protocol requirements for AI troubleshooting agents deployed on network devices. Addresses communication needs between agents and network infrastructure for autonomous fault diagnosis and remediation.\",\n \"n\": 2,\n \"nn\": \"Incremental application of agent concepts to network troubleshooting; the core idea of autonomous agents performing diagnostics is not novel, though domain-specific protocol requirements may have merit.\",\n \"m\": 2,\n \"mn\": \"Early-stage draft presenting use cases and requirements gathering; lacks protocol specification, formal definitions, or architectural details needed for implementation.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing network automation, intent-based networking, and YANG-based configuration management literature; agent framing appears to repackage established netops concepts.\",\n \"mo\": 1,\n \"mon\": \"Single revision with future date stamp; no evidence of WG sponsorship, community discussion, or iterative development; appears exploratory rather than actively pursued.\",\n \"r\": 4,\n \"rn\": \"Directly relevant as it specifically targets AI agents for network operations; however, framing is more traditional network management with 'AI agent' terminology rather than substantive AI agent research.\",\n \"c\": [\"Autonomous netops\", \"A2A protocols\", \"Agent discovery/reg\", \"Data formats/interop\", \"Human-agent interaction\"]\n}\n```", "in_tok": 488, "out_tok": 326}
|
|
|
|
|
{"draft_name": "draft-illyes-rep-purpose", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Extends RFC9309 robots.txt protocol with a new rule targeting automatic clients based on their declared purpose rather than just user-agent product tokens. Enables more granular control over which types of automated access (e.g., search indexing vs. training data harvesting) are permitted on a web service.\",\n \"n\": 2,\n \"nn\": \"Incremental extension to existing standard; straightforward addition of purpose-based filtering alongside existing user-agent matching mechanism\",\n \"m\": 2,\n \"mn\": \"Early sketch phase; abstract suggests concept but only 4 pages limits room for protocol details, examples, or implementation guidance\",\n \"o\": 3,\n \"on\": \"Shares conceptual space with existing robots.txt extensions and purpose declaration proposals in web standards; relates to ongoing discussions about AI crawler identification\",\n \"mo\": 2,\n \"mon\": \"Single draft revision from April 2025; no evidence of WG discussion, implementation interest, or community adoption\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI agent governance and data collection control; addresses critical need to distinguish between different classes of automated access (especially training vs. serving)\",\n \"c\": [\n \"Policy/governance\",\n \"Agent identity/auth\",\n \"Data formats/interop\",\n \"AI safety/alignment\"\n ]\n}\n```", "in_tok": 530, "out_tok": 324}
|
|
|
|
|
{"draft_name": "draft-emirdag-scitt-ai-agent-execution", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft proposes a SCITT profile for creating cryptographically verifiable audit records of AI agent actions, mapping supply chain integrity concepts to autonomous agent execution contexts with compliance to EU AI Act and NIST frameworks. It defines AgentInteractionRecord structures, evidence custody mechanisms, and registration policies for tamper-evident agent action logging.\",\n \"n\": 3,\n \"nn\": \"Useful contribution applying established SCITT/COSE patterns to AI agent auditability; conceptually sound but represents incremental adaptation rather than novel cryptographic or agent-specific innovation.\",\n \"m\": 3,\n \"mn\": \"Defined protocol structure with role mappings and policy requirements, but lacks detailed message flows, concrete code examples, test vectors, or implementation guidance needed for production deployment.\",\n \"o\": 3,\n \"on\": \"Shares foundational concepts with SCITT core specs and COSE signing; overlaps with emerging agent provenance/audit proposals; distinct primarily in regulatory mapping and redaction receipt mechanism.\",\n \"mo\": 2,\n \"mon\": \"Single revision snapshot (2026-04-11); no evidence of WG adoption, multiple iterations, or community feedback cycle visible; niche intersection of SCITT and AI governance communities.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to autonomous agent governance and compliance; addresses real need for immutable agent action logs in regulated AI systems; strong alignment with current AI safety/accountability focus.\",\n \"c\": [\"Policy/governance\", \"Agent identity/auth\", \"Data formats/interop\", \"AI safety/alignment\", \"Agent discovery/reg\"]\n}\n```", "in_tok": 656, "out_tok": 377}
|
|
|
|
|
{"draft_name": "draft-drake-email-hardware-attestation", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes hardware attestation mechanisms for email senders to prove genuine hardware security components via certificate chains, enabling Sybil-resistant authentication and reputation tracking for automated agents. Combines direct hardware attestation with privacy-preserving SD-JWT alternatives to create persistent hardware-anchored identities using a URN-based Agent Identity namespace.\",\n \"n\": 2,\n \"nn\": \"Applies established hardware attestation (TPM, PIV) and selective disclosure JWT concepts to email headers; combines known techniques rather than introducing novel cryptographic or architectural approaches.\",\n \"m\": 3,\n \"mn\": \"Protocol mechanism defined with multiple attestation paths and header formats specified, but abstract appears truncated and no test vectors, implementation guidance, or interoperability considerations are evident in the provided excerpt.\",\n \"o\": 4,\n \"on\": \"Significant overlap with DKIM/DMARC sender verification goals, existing TPM attestation standards (TCG), and JWT/SD-JWT specifications; the email-specific instantiation is novel but foundational concepts are well-established.\",\n \"mo\": 1,\n \"mon\": \"Single draft revision dated 2026-04-29 with no evidence of WG sponsorship, community discussion, or adoption signals; appears to be an individual submission without visible momentum.\",\n \"r\": 3,\n \"rn\": \"Directly addresses automated agent authentication and Sybil resistance (core agent concerns) but frames primarily as email infrastructure problem; relevance to broader AI agent ecosystems beyond email is implicit rather than explicit.\",\n \"c\": [\"Agent identity/auth\", \"A2A protocols\", \"Data formats/interop\", \"Policy/governance\"]\n}\n```", "in_tok": 868, "out_tok": 390}
|
|
|
|
|
{"draft_name": "draft-yu-ai-agent-ipv6-networking-considerations", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft addresses IPv6 networking considerations for AI agent communication across distributed environments, mapping agent identifiers to IPv6 locators and agent communication requirements to forwarding policies. It complements existing agent discovery and authorization mechanisms by focusing on network-layer support after agent discovery.\",\n \"n\": 2,\n \"nn\": \"Incremental application of existing IPv6 concepts (address management, SRv6 policies, telemetry) to AI agents; lacks fundamentally novel networking approaches.\",\n \"m\": 2,\n \"mn\": \"Early sketch addressing a real problem space but lacks concrete protocol definitions, detailed mechanisms, implementation examples, or test vectors; primarily conceptual positioning.\",\n \"o\": 3,\n \"on\": \"Shares foundational concepts with existing IPv6 routing, SRv6, and telemetry work; overlaps with general distributed systems networking but carves a niche around AI agent-specific requirements.\",\n \"mo\": 1,\n \"mon\": \"Single revision in May 2026 with no apparent WG adoption, community discussion, or follow-up versions; appears to be exploratory positioning rather than an active initiative.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to AI agents\u2014addresses networking layer concerns but focuses narrowly on IPv6 transport rather than core agent protocols, semantics, or collaboration mechanisms.\",\n \"c\": [\n \"A2A protocols\",\n \"Agent identity/auth\",\n \"Agent discovery/reg\",\n \"Autonomous netops\"\n ]\n}\n```", "in_tok": 723, "out_tok": 360}
|
|
|
|
|
{"draft_name": "draft-hartman-credential-broker-4-agents", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"CB4A proposes a credential brokering architecture that prevents AI agents from holding long-lived credentials by issuing short-lived, scoped proxy credentials through a policy/delivery point separation. It leverages SPIFFE/SPIRE, DPoP, and a tiered approval framework to mitigate credential compromise risks in multi-service agent deployments.\",\n \"n\": 3,\n \"nn\": \"Applies established security patterns (Zero Trust, PDP/PEP, sender-constrained tokens) to the novel problem space of agentic AI credential management; incremental but addressing a genuine gap.\",\n \"m\": 4,\n \"mn\": \"Well-structured 30-page specification with threat model, three proxy models, and tiered approval framework; lacks implementation evidence and test vectors for full production-readiness.\",\n \"o\": 2,\n \"on\": \"Builds on standard IETF work (SPIFFE, SPIRE, RFC 9449, NIST SP 800-207) but combines them for AI agents in a relatively unexplored configuration.\",\n \"mo\": 2,\n \"mon\": \"Single revision dated 2026-03-29; no evidence of WG adoption, implementation, or iterative feedback cycle typical of active IETF development.\",\n \"r\": 5,\n \"rn\": \"Directly addresses core AI agent security: credential sprawl, compromise risk mitigation, and policy-driven access control for autonomous systems.\",\n \"c\": [\n \"Agent identity/auth\",\n \"Policy/governance\",\n \"AI safety/alignment\",\n \"A2A protocols\"\n ]\n}\n```", "in_tok": 681, "out_tok": 389}
|
|
|
|
|
{"draft_name": "draft-vaughan-aipref-vocab", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes a machine-readable vocabulary for content rightsholders to express AI training preferences via metadata and content-delivery protocols. Aims to enable interoperable permission management across internet protocols with granular controls for usage scope and data retention.\",\n \"n\": 2,\n \"nn\": \"Incremental extension of existing metadata and rights expression approaches (similar to robots.txt, machine-readable privacy policies); applies established concepts to AI training context without fundamental innovation.\",\n \"m\": 2,\n \"mn\": \"Early sketch phase; abstract describes intent and scope but document likely lacks detailed syntax, protocol bindings, formal grammar, implementation examples, or deployment guidance needed for specification maturity.\",\n \"o\": 4,\n \"on\": \"Significant overlap with C2PA, ODRL, CRDTs for rights management, robots.txt extensions, and ongoing work in W3C and broader content licensing communities; positioning relative to existing standards unclear.\",\n \"mo\": 1,\n \"mon\": \"Single submission with 2025 date suggests very recent work; no evidence of multiple revisions, WG adoption, community discussion, or implementation feedback; appears to be initial proposal without traction.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI training governance and data sourcing ethics, which are core concerns in AI safety/alignment and policy frameworks; less relevant to agent-specific topics.\",\n \"c\": [\n \"Data formats/interop\",\n \"Policy/governance\",\n \"AI safety/alignment\"\n ]\n}\n```", "in_tok": 544, "out_tok": 360}
|
|
|
|
|
{"draft_name": "draft-chen-nmrg-multi-provider-inference-api", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes extensions to OpenAI's API standard for multi-provider AI inference with load balancing, failover, and capability negotiation. Adds identity-based authorization and RBAC for secure multi-tenant deployments while maintaining backward compatibility.\",\n \"n\": 2,\n \"nn\": \"Incremental extension treating existing proprietary API as de facto standard; conceptually straightforward composition of known patterns (load balancing, failover, RBAC) without fundamental innovation\",\n \"m\": 3,\n \"mn\": \"Defined protocol extensions with stated backward compatibility and revision history, but abstract notes claims implementation-readiness without evidence of test vectors or reference implementations\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing multi-LLM frameworks (LiteLLM, LangChain provider abstraction), API gateway standards (gRPC service mesh), and distributed inference systems; positions itself as wrapper rather than novel architecture\",\n \"mo\": 2,\n \"mon\": \"Only two revisions noted (-00, -01); lacks WG sponsorship, no evidence of broader community adoption or implementation feedback; appears individually authored\",\n \"r\": 3,\n \"rn\": \"Partially relevant to AI operations and model serving; addresses practical orchestration but focuses on API compatibility layer rather than core agent capabilities, reasoning, or safety concerns\",\n \"c\": [\n \"Model serving/inference\",\n \"ML traffic mgmt\",\n \"Data formats/interop\",\n \"Agent identity/auth\",\n \"Policy/governance\"\n ]\n}\n```", "in_tok": 678, "out_tok": 369}
|
|
|
|
|
{"draft_name": "draft-romm-aipref-contentsignals", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes a vocabulary for expressing content signal preferences within automated processing systems, extending the AIPREF framework with three nested categories. Enables parties to communicate how digital assets should be handled by AI and automated systems.\",\n \"n\": 2,\n \"nn\": \"Incremental extension of existing AIPREF vocabulary framework; applies established preference expression patterns to a specific subdomain rather than introducing fundamentally new concepts.\",\n \"m\": 2,\n \"mn\": \"Early sketch stage with abstract proposal; lacks protocol details, implementation guidance, examples, or formal schema definitions needed for practical deployment.\",\n \"o\": 4,\n \"on\": \"Significant overlap with AIPREF-VOCAB and related preference signaling work; appears to be a specialized refinement of existing categorization schemes rather than an independent approach.\",\n \"mo\": 1,\n \"mon\": \"No evidence of active development; single draft with 2025-10-01 date suggests nascent effort with minimal revision history or community engagement visible.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI agent governance and automated processing control; addresses how humans/organizations express preferences to systems, a core concern for responsible AI deployment.\",\n \"c\": [\n \"Data formats/interop\",\n \"Policy/governance\",\n \"Human-agent interaction\",\n \"AI safety/alignment\"\n ]\n}\n```", "in_tok": 513, "out_tok": 326}
|
|
|
|
|
{"draft_name": "draft-melnikov-sasl2", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"SASL2 extends the SASL authentication framework with support for extensibility, multi-factor authentication, and password change operations. It modernizes the protocol structure for contemporary authentication requirements while maintaining backward compatibility with existing SASL mechanisms.\",\n \"n\": 2,\n \"nn\": \"Incremental evolution of SASL (RFC 4422) adding new features rather than introducing fundamentally new concepts; extension mechanisms are standard practice in protocol design.\",\n \"m\": 4,\n \"mn\": \"Well-structured protocol specification with detailed mechanism definitions and security layer descriptions; appears implementation-ready though test vectors and interoperability guidance would strengthen maturity.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing SASL standards and multiple proposed SASL extensions; the multi-factor and password-change features have been proposed in various forms across different drafts.\",\n \"mo\": 2,\n \"mon\": \"Single revision date (2025-06-05) suggests limited recent activity; unclear WG adoption status or community discussion momentum from metadata alone.\",\n \"r\": 1,\n \"rn\": \"Not relevant to AI agents or autonomous systems; traditional authentication protocol work unrelated to agent-based AI systems, distributed autonomy, or intelligent automation.\",\n \"c\": [\n \"Agent identity/auth\",\n \"Data formats/interop\",\n \"Other AI/agent\"\n ]\n}\n```", "in_tok": 620, "out_tok": 332}
|
|
|
|
|
{"draft_name": "draft-li-cats-idn", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes an Intelligence Delivery Network (IDN) framework for distributing deep learning inference across geographically dispersed servers to address latency, privacy, and scalability challenges. Establishes architectural concepts and vocabulary without specifying protocols, positioning it as an early-stage framework document for future standardization.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution combining existing concepts (CDN principles, model serving, edge computing) applied to DL inference; lacks genuinely novel technical insights or mechanisms.\",\n \"m\": 1,\n \"mn\": \"Framework document only\u2014provides architectural overview and vocabulary but explicitly defers all protocol specifications to future work; no mechanisms, algorithms, or implementation details.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing work on edge ML, model serving infrastructure (Kubernetes, Ray Serve), and CDN-style distribution; concepts largely parallel to established ML systems deployment patterns.\",\n \"mo\": 1,\n \"mon\": \"Single revision with 2026 date suggests early-stage work; no evidence of WG adoption, multiple iterations, or community engagement; appears to be initial exploratory submission.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI agent deployment and model serving infrastructure; addresses practical challenges in distributed inference systems critical for scalable agent deployment.\",\n \"c\": [\n \"Model serving/inference\",\n \"ML traffic mgmt\",\n \"Data formats/interop\",\n \"Autonomous netops\",\n \"Agent discovery/reg\"\n ]\n}\n```", "in_tok": 588, "out_tok": 364}
|
|
|
|
|
{"draft_name": "draft-nandakumar-agent-sd-jwt", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Defines SD-Card format using SD-JWT for privacy-preserving agent discovery and identity management in A2A systems. Enables selective disclosure of agent capabilities and metadata while maintaining cryptographic integrity and preventing correlation attacks.\",\n \"n\": 2,\n \"nn\": \"Incremental combination of existing SD-JWT standard with agent discovery use case; limited architectural novelty beyond applying established selective disclosure to agent cards.\",\n \"m\": 3,\n \"mn\": \"Defines protocol mechanism and SD-Card format with reasonable specificity, but lacks implementation examples, test vectors, and deployment guidance needed for production readiness.\",\n \"o\": 4,\n \"on\": \"Significant overlap with SD-JWT spec (RFC 9809) and existing agent discovery/identity frameworks; limited differentiation beyond domain application; similar concepts in concurrent IETF work on agent protocols.\",\n \"mo\": 2,\n \"mon\": \"Single draft revision with no evidence of WG adoption, community feedback integration, or sustained development momentum; appears early-stage submission.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to agent identity/authentication and discovery infrastructure; core to A2A system deployment but not addressing core AI safety, alignment, or autonomous netops concerns.\",\n \"c\": [\n \"A2A protocols\",\n \"Agent identity/auth\",\n \"Agent discovery/reg\",\n \"Data formats/interop\",\n \"Policy/governance\"\n ]\n}\n```", "in_tok": 559, "out_tok": 344}
|
|
|
|
|
{"draft_name": "draft-xu-agentic-overlay-network-architecture", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes an overlay network architecture enabling autonomous software agents to interoperate across domains through a layered approach separating control-plane management (trust, policies, discovery) from runtime agent interaction. Focuses on architectural roles, metadata standards, and security without defining new transport protocols or mandatory discovery algorithms.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution combining existing overlay network concepts with agent-oriented service discovery and capability metadata; follows established patterns of control/data plane separation but applies them to the agent domain.\",\n \"m\": 2,\n \"mn\": \"Early architectural sketch defining roles and workflows; lacks detailed protocol specifications, message formats, concrete examples, and implementation guidance; reads as a conceptual framework rather than a deployable specification.\",\n \"o\": 4,\n \"on\": \"Significant overlap with service mesh architectures (Istio, Consul), DNS-SD/mDNS discovery patterns, capability-based security models, and existing agent protocol work; repositions known concepts toward agent-centric use cases without substantial differentiation.\",\n \"mo\": 1,\n \"mon\": \"Single revision with future date (2026-05); appears to be early-stage individual submission with no evident WG adoption, implementation references, or follow-up activity; unclear community interest.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to agent interoperability and discovery challenges; addresses legitimate infrastructure needs for multi-agent systems; strong relevance to agent ecosystem coordination despite architectural maturity limitations.\",\n \"c\": [\n \"A2A protocols\",\n \"Agent discovery/reg\",\n \"Agent identity/auth\",\n \"Data formats/interop\",\n \"Policy/governance\",\n \"Autonomous netops\"\n ]\n}\n```", "in_tok": 696, "out_tok": 407}
|
|
|
|
|
{"draft_name": "draft-liu-agent-operation-authorization", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes a JWT-based authorization framework for delegating operations to AI agents through two phases: authorization requests and authorization tokens. Aims to provide cryptographic verification of user intent and audit trails for agent actions.\",\n \"n\": 2,\n \"nn\": \"JWT-based delegation and authorization tokens are well-established patterns; applying them to AI agents is incremental rather than novel. The core concept of signed operation requests lacks significant technical innovation.\",\n \"m\": 2,\n \"mn\": \"Early sketch with conceptual phases described but lacks implementation details, formal protocol specifications, test vectors, or concrete examples of JWT payloads. No discussion of error handling or edge cases.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing OAuth 2.0/OpenID Connect delegation patterns, capability-based security models, and prior work on AI agent authorization (e.g., OpenAI's tool use verification, function calling frameworks). The JWT approach is well-trodden.\",\n \"m\": 1,\n \"mon\": \"Single draft dated 2026-03-16 with no visible revision history or WG discussion. No evidence of community adoption or working group momentum.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI agent authorization and human-agent interaction. Addresses legitimate safety/governance concerns around agent operation control, though execution details remain vague.\",\n \"c\": [\n \"Agent identity/auth\",\n \"Human-agent interaction\",\n \"AI safety/alignment\",\n \"Policy/governance\",\n \"Data formats/interop\"\n ]\n}\n```", "in_tok": 599, "out_tok": 374}
|
|
|
|
|
{"draft_name": "draft-nennemann-wimse-ect", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft extends WIMSE with Execution Context Tokens (ECTs) to track task execution across distributed agentic workflows using JWT-based signed records linked in a DAG structure. ECTs are transported via HTTP headers alongside existing WIMSE identity mechanisms.\",\n \"n\": 2,\n \"nn\": \"Incremental extension combining existing JWT/WIMSE patterns with DAG-based task tracking; limited technical innovation beyond applying known mechanisms to agent workflow context.\",\n \"m\": 3,\n \"mn\": \"Defined protocol mechanism with clear structure and HTTP header transport model, but lacks implementation details, test vectors, and deployment guidance needed for production readiness.\",\n \"o\": 4,\n \"on\": \"Significant overlap with distributed tracing (OpenTelemetry), workflow state machines, and blockchain-style task provenance; DAG concept parallels existing task scheduling and causality tracking systems.\",\n \"mo\": 1,\n \"mon\": \"Single draft revision with no evidence of WG discussion, community feedback, or adoption signals; appears early-stage without visible development momentum.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to agent orchestration and identity/auth for distributed agentic systems; addresses real need for task provenance and execution context in multi-step workflows.\",\n \"c\": [\"A2A protocols\", \"Agent identity/auth\", \"Data formats/interop\", \"Autonomous netops\"]\n}\n```", "in_tok": 557, "out_tok": 335}
|
|
|
|
|
{"draft_name": "draft-reilly-sentinel-protocol", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"RSP proposes a blockchain-anchored protocol for establishing tamper-evident integrity and provenance across the AI lifecycle, binding dataset digests, metadata, signatures, and blockchain proofs via a Sentinel Evidence Package (SEP). The revision introduces quantum-resistant triple-hash architecture, cross-chain binding, and extensions for agentic AI, federated learning, and streaming inference.\",\n \"n\": 2,\n \"nn\": \"Incremental composition of existing IETF building blocks (COSE, CBOR, CDDL) with blockchain anchoring. Core concepts (provenance tracking, cryptographic binding, audit trails) are well-established; the primary contribution is domain-specific packaging for AI workflows.\",\n \"m\": 3,\n \"mn\": \"Protocol structure is defined with formal serialization (JSON/CBOR) and schema (CDDL), but lacks test vectors, reference implementations, or deployment examples. Quantum-resistant claims need cryptographic justification. Conformance framework mentioned but not detailed.\",\n \"o\": 4,\n \"on\": \"Significant overlap with W3C Provenance, PROV-O, supply-chain provenance standards, and existing blockchain-based audit schemes. Similar concepts appear in ML reproducibility efforts (MLflow, Weights & Biases lineage tracking). Blockchain anchoring strategy resembles prior timestamping RFCs.\",\n \"m\": 2,\n \"mon\": \"Single revision (-01) released in 2026-03. No evidence of WG sponsorship, implementation deployments, or community adoption. Appears to be individual submission without active feedback cycle.\",\n \"r\": 4,\n \"rn\": \"Directly addresses AI provenance and auditability for regulated/safety-critical deployments. Relevant to agent action logging and model lineage tracking. Less relevant to agent discovery, policy frameworks, or human-agent interaction.\",\n \"c\": [\n \"Data formats/interop\",\n \"Model serving/inference\",\n \"Agent identity/auth\",\n \"Policy/governance\"\n ]\n}\n```", "in_tok": 881, "out_tok": 481}
|
|
|
|
|
{"draft_name": "draft-xsaopig-nmop-service-flow-modal-mapping", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes a framework combining ALTO protocol and SDN architecture to map service flow characteristics to network resources in intelligent computing networks, enabling dynamic resource allocation through characteristic identification and intelligent mapping.\",\n \"n\": 2,\n \"nn\": \"Incremental combination of existing technologies (ALTO + SDN); characteristic mapping concept is straightforward application of known techniques without significant innovation.\",\n \"m\": 2,\n \"mn\": \"Early sketch stage; abstract describes framework conceptually but document appears to lack detailed protocol specifications, algorithms, message formats, or implementation guidance needed for maturity.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing ALTO protocol work, SDN resource management literature, and service-aware networking efforts; the specific combination is not particularly differentiated from prior art.\",\n \"mo\": 1,\n \"mon\": \"Single draft submission with October 2025 date; no evidence of working group interest, prior versions, or community adoption; appears to be initial submission.\",\n \"r\": 2,\n \"rn\": \"Tangentially related to agent/AI networking; focuses on traditional network resource management rather than autonomous agent coordination, communication, or intelligence patterns.\",\n \"c\": [\n \"Data formats/interop\",\n \"ML traffic mgmt\",\n \"Autonomous netops\"\n ]\n}\n```", "in_tok": 650, "out_tok": 312}
|
|
|
|
|
{"draft_name": "draft-mao-rtgwg-agent-comm-protocol-gap-analysis", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft analyzes gaps between existing networking protocols and AI agent communication requirements for cross-device collaboration in network devices. It evaluates classical networking protocols and AI-focused communication approaches against the needs defined in a companion framework document.\",\n \"n\": 2,\n \"nn\": \"Gap analysis of existing protocols against AI agent needs is incremental; applies established protocol evaluation methodology to an emerging use case without proposing novel solutions.\",\n \"m\": 2,\n \"mn\": \"Early stage gap analysis document with problem framing; lacks detailed protocol specifications, implementation guidance, or concrete technical proposals to close identified gaps.\",\n \"o\": 3,\n \"on\": \"Shares conceptual overlap with multi-agent communication literature and protocol evaluation frameworks; depends heavily on companion framework draft; limited unique analysis perspective.\",\n \"mo\": 1,\n \"mon\": \"Single draft with no visible revision history or follow-up work; dependent on companion framework with unclear WG adoption or community momentum.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to autonomous network operations and agent-to-agent communication standardization; addresses timely intersection of AI agents and networking infrastructure.\",\n \"c\": [\n \"A2A protocols\",\n \"Agent discovery/reg\",\n \"Autonomous netops\",\n \"Data formats/interop\",\n \"Agent identity/auth\"\n ]\n}\n```", "in_tok": 616, "out_tok": 321}
|
|
|
|
|
{"draft_name": "draft-chen-oauth-rar-agent-extensions", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Extends OAuth 2.0 Rich Authorization Requests with three new mechanisms: intent_request type for goal-oriented authorization, policy_context parameter for assurance level specification, and lifecycle_binding to tie authorization validity to external process states. Targets autonomous agents and complex long-running tasks requiring context-aware authorization decisions.\",\n \"n\": 3,\n \"nn\": \"Incremental but purposeful extension of established RAR framework; intent expression and lifecycle binding are useful contributions for agent scenarios, though policy_context feels more derivative of existing SAML/XACML patterns.\",\n \"m\": 2,\n \"mn\": \"Early sketch phase with abstract concepts; lacks concrete syntax examples, implementation guidance, and security threat model analysis; no discussion of how authorization servers should process lifecycle_binding or enforce policy_context semantics.\",\n \"o\": 3,\n \"on\": \"Shares conceptual overlap with authorization policy frameworks (XACML, ReBAC), agent capability negotiation drafts, and existing lifecycle management in OAuth token exchange; intent mechanisms loosely echo GNAP intent definitions.\",\n \"mo\": 2,\n \"mon\": \"Single draft revision as of stated date; no evidence of WG sponsorship, implementation prototypes, or community adoption; positioning as agent-specific extension may limit general OAuth audience traction.\",\n \"r\": 4,\n \"rn\": \"Directly addresses core autonomous agent authorization challenges: expressing agent goals without explicit permission lists, binding grants to agent lifecycle, and enabling policy-aware delegation\u2014core requirements for trustworthy agent deployment.\",\n \"c\": [\n \"Agent identity/auth\",\n \"Policy/governance\",\n \"Human-agent interaction\",\n \"A2A protocols\",\n \"Data formats/interop\"\n ]\n}\n```", "in_tok": 699, "out_tok": 411}
|
|
|
|
|
{"draft_name": "draft-duda-dnsop-dns-did", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes a DNS-based privacy-preserving identity framework using Self-Certifying Identifiers and DNSSEC to manage users, IoT devices, and AI agents through trusted intermediaries. Combines role-based access control with ephemeral tokens for zero-trust architectures and automated AI interactions.\",\n \"n\": 2,\n \"nn\": \"Combines existing concepts (DNS, DNSSEC, SIDs, trustees) in straightforward manner; limited technical novelty in identity binding mechanism itself.\",\n \"m\": 2,\n \"mn\": \"Early sketch with conceptual framework; lacks detailed protocol specifications, message formats, cryptographic bindings, or implementation guidance; DIDs/IPFS extensions are vague future work.\",\n \"o\": 4,\n \"on\": \"Significant overlap with DID specifications, DNSSEC-based key management, traditional trustee/proxy models, and zero-trust literature; marginal distinction from existing DNS-CA approaches.\",\n \"mo\": 2,\n \"mon\": \"Single revision dated 2026-03-03; no evidence of WG adoption, community feedback integration, or iterative development; appears to be initial submission.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to AI agents via identity/authentication for distributed agents and automated interactions; core focus is identity infrastructure rather than AI-specific governance, safety, or agent protocols.\",\n \"c\": [\n \"Agent identity/auth\",\n \"Data formats/interop\",\n \"Policy/governance\",\n \"Agent discovery/reg\"\n ]\n}\n```", "in_tok": 651, "out_tok": 373}
|
|
|
|
|
{"draft_name": "draft-happel-structured-email-trust", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Addresses trust and security considerations for structured email formats, providing guidance for message user agents on handling structured data. Focuses on practical recommendations rather than novel security mechanisms.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution applying known security principles to structured email; extends existing email security work rather than introducing new concepts.\",\n \"m\": 2,\n \"mn\": \"Early-stage document presenting considerations and recommendations without detailed protocols, formal specifications, or implementation guidance.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing email security RFCs (DMARC, SPF, DKIM) and structured email work (AMP for Email); limited novel threat model.\",\n \"mo\": 1,\n \"mon\": \"Single draft revision in 2025 with unclear WG sponsorship or community adoption signals; no indication of active development momentum.\",\n \"r\": 2,\n \"rn\": \"Tangentially related to AI agents; structured email could transport agent communication but document focuses on general MUA security rather than agent-specific concerns.\",\n \"c\": [\"Data formats/interop\", \"Policy/governance\", \"Human-agent interaction\"]\n}\n```", "in_tok": 476, "out_tok": 279}
|
|
|
|
|
{"draft_name": "draft-toorop-dnsop-ranking-dns-data", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft proposes extending RFC 2181's DNS data trustworthiness ranking by adding entries for root server names/addresses and DNSSEC-verified data, then assigning numeric values to ranking positions for easier reference and comparison.\",\n \"n\": 1,\n \"nn\": \"Trivial extension to existing RFC 2181 framework; adds numeric labels to pre-existing conceptual categories with minimal technical innovation.\",\n \"m\": 2,\n \"mn\": \"Early sketch stage; lacks implementation details, test vectors, and concrete guidance on how resolvers should apply the extended rankings in practice.\",\n \"o\": 5,\n \"on\": \"Near-duplicate of RFC 2181 Section 5.4.1; primarily a numbering scheme overlay on established DNS trustworthiness concepts with no substantial new mechanisms.\",\n \"mo\": 1,\n \"mon\": \"Single 2024 revision with no visible WG adoption, discussion, or subsequent activity indicating community interest or momentum.\",\n \"r\": 1,\n \"rn\": \"Not relevant to AI agents or autonomous systems; pure DNS infrastructure specification with no connection to AI/agent topics.\",\n \"c\": [\"Data formats/interop\"]\n}\n```", "in_tok": 581, "out_tok": 286}
|
|
|
|
|
{"draft_name": "draft-spm-lake-pqsuites", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft extends EDHOC with post-quantum cryptographic cipher suites using ML-DSA and ML-KEM algorithms to enable quantum-resistant authenticated key exchange for lightweight IoT and constrained device scenarios.\",\n \"n\": 2,\n \"nn\": \"Straightforward application of NIST-standardized post-quantum algorithms (ML-DSA, ML-KEM) to existing EDHOC protocol; primarily engineering work adapting well-understood mechanisms rather than fundamental innovation.\",\n \"m\": 4,\n \"mn\": \"Well-structured protocol specification with defined cipher suites and clear integration points; appears implementation-ready though draft maturity suggests pending finalization and potential test vector additions.\",\n \"o\": 4,\n \"on\": \"Significant overlap with concurrent post-quantum COSE/EDHOC standardization efforts and NIST PQC migration guidance; incremental contribution to broader PQC adoption initiative rather than distinctive approach.\",\n \"mo\": 3,\n \"mon\": \"Active WG-level engagement expected for post-quantum cryptography transition; reasonable adoption probability but dependent on broader IETF PQC standardization timeline and industry migration pace.\",\n \"r\": 1,\n \"rn\": \"Not relevant to AI agents; addresses cryptographic protocol extensions for IoT/constrained devices with no connection to agent systems, autonomy, or AI infrastructure.\",\n \"c\": [\"Other AI/agent\"]\n}\n```", "in_tok": 571, "out_tok": 338}
|
|
|
|
|
{"draft_name": "draft-feng-nmrg-ain-architecture", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"AIN proposes an Internet-scale architecture for discovering and coordinating autonomous AI agents across organizational boundaries without pre-established integration. The work defines architectural requirements, components, and design invariants as a research agenda for NMRG, deliberately excluding protocol engineering details.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution; applies well-established service discovery and routing concepts to AI agent coordination without fundamental technical novelty. The core idea of intent-based networking for agents is a straightforward extension of existing network coordination patterns.\",\n \"m\": 2,\n \"mn\": \"Early-stage research agenda document. Defines problem space and architectural principles but lacks concrete protocol specifications, mechanism details, or implementation guidance. Suitable for problem scoping, not deployment.\",\n \"o\": 4,\n \"on\": \"Significant overlap with service mesh architectures (Istio, Consul), existing intent-based networking proposals, and multi-agent system frameworks (AutoGen, CrewAI). The routing-based coordination model parallels established API gateway and orchestration patterns.\",\n \"mo\": 1,\n \"mon\": \"Single submission with April 2026 date suggesting recent/upcoming work. No evidence of revisions, community discussion, WG adoption, or iterative refinement. Appears to be initial proposal stage.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI agent coordination and discovery; addresses legitimate scaling challenge in multi-agent systems. Less relevant to core AI safety/alignment concerns or model serving infrastructure.\",\n \"c\": [\"Agent discovery/reg\", \"A2A protocols\", \"Data formats/interop\", \"Policy/governance\", \"Autonomous netops\"]\n}\n```", "in_tok": 619, "out_tok": 389}
|
|
|
|
|
{"draft_name": "draft-pocero-authkem-ikr-edhoc", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft presents an optimized KEM-based authentication method for EDHOC tailored to initiator-known-responder scenarios, enabling signature-free post-quantum authentication using a three-message handshake while maintaining mutual authentication and forward secrecy.\",\n \"n\": 2,\n \"nn\": \"Incremental optimization of existing KEM-authentication approach; applies known techniques to a narrower, practical scenario rather than introducing fundamentally new concepts.\",\n \"m\": 4,\n \"mn\": \"Well-specified protocol with detailed mechanism descriptions; appears implementation-ready though maturity depends on reference implementation and test vector availability.\",\n \"o\": 3,\n \"on\": \"Builds directly on prior KEM-authentication work for EDHOC; shares core cryptographic concepts with related post-quantum authentication efforts; specific IKR optimization is distinguishing factor.\",\n \"mo\": 2,\n \"mon\": \"Single draft revision observed; no clear evidence of WG adoption or strong community engagement; unclear trajectory and consolidation status within standards track.\",\n \"r\": 1,\n \"rn\": \"Not relevant to AI agents. This is cryptographic protocol specification for IoT/constrained device communication; no connection to agent systems, autonomy, or AI operations.\",\n \"c\": [\"Other AI/agent\"]\n}\n```", "in_tok": 649, "out_tok": 309}
|
|
|
|
|
{"draft_name": "draft-liao-aipref-autoctl-ext", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Extends an unspecified core specification to provide granular server-side controls over automated interactions, including rate limiting, technology restrictions, and API permissions. Aims to give service owners better governance mechanisms for bot and automation traffic.\",\n \"n\": 2,\n \"nn\": \"Incremental extension adding control mechanisms; rate limiting and permission schemes are well-established concepts applied to automation contexts.\",\n \"m\": 2,\n \"mn\": \"Early draft stage with undefined normative reference [CORE-SPEC]; lacks implementation details, test vectors, and concrete protocol specifications needed for maturity assessment.\",\n \"o\": 4,\n \"on\": \"Significant overlap with robots.txt, CAPTCHA frameworks, API throttling policies, and existing automation control mechanisms; positioning relative to these is unclear.\",\n \"mo\": 1,\n \"mon\": \"Single revision dated 2025-11-03 with no observable community engagement, WG discussion, or implementation feedback; appears dormant or very early stage.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to AI agent governance and policy enforcement; directly addresses automation control but lacks explicit AI agent framing and technical depth around agent-specific scenarios.\",\n \"c\": [\"Policy/governance\", \"Agent identity/auth\", \"ML traffic mgmt\"],\n \"issues\": [\"Critical: [CORE-SPEC] reference undefined\", \"Missing: normative/informative distinction\", \"Missing: concrete examples and deployment scenarios\", \"Missing: relationship to existing standards (robots.txt, HTTP semantics)\"]\n}\n```", "in_tok": 518, "out_tok": 360}
|
|
|
|
|
{"draft_name": "draft-latour-pre-registration", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft extends EPP to allow registrars to submit domain pre-registration data to TLD registries for AI/ML-based quality scoring to detect potentially abusive registrations. The mechanism assigns abuse likelihood scores (0-100) and aims to improve registry integrity through proactive abuse mitigation.\",\n \"n\": 2,\n \"nn\": \"Incremental extension applying existing ML abuse-detection concepts to EPP domain registration workflow; straightforward application of scoring mechanisms to a known problem.\",\n \"m\": 3,\n \"mn\": \"Defines EPP command extensions and XML schemas with data flow description, but lacks implementation examples, test vectors, error handling edge cases, and deployment guidance needed for production readiness.\",\n \"o\": 3,\n \"on\": \"Shares conceptual overlap with existing domain abuse detection systems and EPP extensions (DNSSEC, WHOIS privacy); the scoring methodology itself appears standard ML classification applied to registration metadata.\",\n \"mo\": 2,\n \"mon\": \"Single revision as of May 2024 with no visible WG adoption, community discussion, or implementation reports; no indication of registrar/registry interest or deployment momentum.\",\n \"r\": 2,\n \"rn\": \"Tangentially related to AI/ML agents\u2014describes ML model application for classification but focuses on EPP protocol mechanics rather than agent autonomy, decision-making, or agent coordination in domain management.\",\n \"c\": [\n \"Data formats/interop\",\n \"Policy/governance\",\n \"ML traffic mgmt\"\n ]\n}\n```", "in_tok": 664, "out_tok": 362}
|
|
|
|
|
{"draft_name": "draft-sharif-agent-identity-framework", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes a five-layer framework (identity, authorization, attestation, evidence, trust) for autonomous AI agents to establish provenance and trust on the Internet, addressing gaps where current protocols designed for human users fail to answer which agent acted, whether it was authorized, and whether evidence is verifiable. Informational document providing conceptual structure and common vocabulary rather than defining specific protocols.\",\n \"n\": 3,\n \"nn\": \"Useful contribution that synthesizes existing concepts into a coherent framework; layered model provides helpful conceptual separation but draws heavily from established identity/PKI/audit traditions applied to new domain.\",\n \"m\": 2,\n \"mn\": \"Early-stage framework document lacking protocol specifications, implementation details, test vectors, or concrete instantiation mechanisms; references other drafts but does not provide sufficient detail for implementation guidance.\",\n \"o\": 3,\n \"on\": \"Shares significant conceptual overlap with existing identity frameworks (OAUTH2, SAML, PKI), authorization models (ABAC, RBAC), and attestation work (TPM, remote attestation); positioning relative to these could be clearer.\",\n \"mo\": 2,\n \"mon\": \"Single dated revision (2026-04-06); unclear WG sponsorship or community adoption signals; informational status suggests lower priority than Standards Track work.\",\n \"r\": 5,\n \"rn\": \"Directly addresses core gap in agent identity and trust\u2014highly relevant to autonomous agent deployment, regulatory compliance, and emerging AI system integration with Internet infrastructure.\",\n \"c\": [\n \"Agent identity/auth\",\n \"AI safety/alignment\",\n \"Policy/governance\",\n \"Data formats/interop\",\n \"A2A protocols\"\n ]\n}\n```", "in_tok": 708, "out_tok": 406}
|
|
|
|
|
{"draft_name": "draft-bradleylundberg-cfrg-arkg", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"ARKG enables delegation of public key generation without private key access, supporting applications like pseudonymous key generation and ephemeral key creation. The draft provides abstract algorithm specification with concrete instantiations and primitive formulae for cryptographic implementations.\",\n \"n\": 3,\n \"nn\": \"Useful contribution combining existing cryptographic concepts (key delegation, derived keys) into a formalized framework, but builds incrementally on established asymmetric key techniques.\",\n \"m\": 4,\n \"mn\": \"Well-specified protocol with concrete instances and detailed algorithm descriptions, though implementation status and test vectors not yet confirmed in abstract.\",\n \"o\": 3,\n \"on\": \"Shares conceptual overlap with proxy re-encryption, identity-based encryption, and delegated key derivation schemes; moderate differentiation in scope and application focus.\",\n \"mo\": 2,\n \"mon\": \"Draft dated 2026 suggests very recent work; single submission visible with limited evidence of WG discussion or iterative refinement.\",\n \"r\": 2,\n \"rn\": \"Tangentially related to AI agents through potential use in agent authentication and pseudonymous agent identity management, but primarily a cryptographic primitive specification without direct AI agent application focus.\",\n \"c\": [\"Agent identity/auth\", \"Data formats/interop\"]\n}\n```", "in_tok": 644, "out_tok": 307}
|
|
|
|
|
{"draft_name": "draft-han-ai-manifest", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes a JSON-based manifest format enabling websites to provide step-by-step UI workflow instructions for autonomous AI agents, reducing token consumption by 81.9% but discovering that manifest embedding alone is insufficient without a deterministic SDK runtime to bypass LLM prompt-injection defenses. The -01 update restructures the schema into a three-part model (frameworkHints, knownTraps, shortcuts) and adds AI-side curation discovery.\",\n \"n\": 2,\n \"nn\": \"Incremental approach combining existing ideas (JSON manifests, CSS selectors, DOM automation) with a practical discovery that LLM agents require external execution runtimes rather than in-context instruction following\u2014useful but somewhat obvious in hindsight given LLM safety constraints.\",\n \"m\": 2,\n \"mn\": \"Early sketch with promising empirical results but critical unresolved gaps: the draft acknowledges manifest embedding fails in practice, requires external SDK runtime (not specified), ongoing schema evolution (-01 updates mid-cycle), and the 'fifth discovery mechanism' description is incomplete in provided text.\",\n \"o\": 3,\n \"on\": \"Shares conceptual overlap with existing browser automation frameworks (Selenium, Playwright), manifest-based configuration approaches, and agent instruction formats; the deterministic SDK runtime concept parallels sandboxed execution models but positioning relative to prior art is unclear.\",\n \"mo\": 2,\n \"mon\": \"Single major revision cycle visible (-01 at 2026-04-28, then 2026-05-15); includes significant pivot acknowledging core approach failure mid-development; no evidence of WG adoption or external implementation beyond reference implementation by authors.\",\n \"r\": 4,\n \"rn\": \"Directly addresses real AI agent automation challenges (token efficiency, task success, prompt injection) and focuses on practical agent-website interaction patterns; however, the core finding that manifests alone don't work diminishes relevance to the primary use case.\",\n \"c\": [\n \"Data formats/interop\",\n \"A2A protocols\",\n \"AI safety/alignment\",\n \"Agent discovery/reg\",\n \"Human-agent interaction\"\n ]\n}\n```", "in_tok": 909, "out_tok": 503}
|
|
|
|
|
{"draft_name": "draft-vinaysingh-awp-wellknown", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes a well-known URI and link relation for exposing machine-readable descriptions of website workflows to enable automated agents to navigate sites without scraping. Minimal JSON format for declaring states, actions, and events.\",\n \"n\": 2,\n \"nn\": \"Incremental extension; combines existing well-known URI concept (RFC 8615) with basic state/action metadata. Similar to robots.txt or sitemap patterns but for agent workflows.\",\n \"m\": 2,\n \"mn\": \"Early sketch with minimal specification. Lacks concrete schema definition, examples, error handling, versioning strategy, and implementation details. No test vectors or reference implementations mentioned.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing standards: overlaps with OpenAPI/AsyncAPI for API workflows, Activity Streams for actions/events, and various agent protocol proposals. Relationship to these not addressed.\",\n \"mo\": 1,\n \"mon\": \"Single revision (2026-05-06). No evidence of WG sponsorship, community discussion, or iterative development. No implementations referenced.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to autonomous agent navigation and agent-website interaction. Addresses practical agent discovery/registration problem, though framed narrowly around workflows rather than broader AI agent concerns.\",\n \"c\": [\n \"Agent discovery/reg\",\n \"Data formats/interop\",\n \"A2A protocols\",\n \"Human-agent interaction\"\n ]\n}\n```", "in_tok": 543, "out_tok": 353}
|
|
|
|
|
{"draft_name": "draft-rosenberg-ai-protocols", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft proposes an IETF framework for standardizing AI Agent communications, surveying existing protocols (MCP, A2A, Agntcy) and identifying protocol requirements across agent-to-user and agent-to-resource interactions. It aims to establish foundational concepts and motivate future IETF standards work in AI agent networking.\",\n \"n\": 2,\n \"nn\": \"Incremental survey work that organizes existing AI agent protocol concepts into a framework; limited novel protocol contribution or architectural insight beyond consolidation of known approaches.\",\n \"m\": 2,\n \"mn\": \"Early-stage framework document with use cases and survey of existing work, but lacks detailed protocol specifications, formal definitions, or implementation guidance needed for standards maturity.\",\n \"o\": 4,\n \"on\": \"Significant conceptual overlap with MCP, A2A, and Agntcy frameworks being surveyed; framework itself adds taxonomy but doesn't introduce substantially differentiated approach to existing protocol ecosystems.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI agent standardization and timely given active development in this space, though positioning relative to existing vendor-led efforts (OpenAI MCP, Anthropic) could be clearer.\",\n \"m\": 2,\n \"mon\": \"Single revision with no visible community consensus or WG sponsorship yet; depends entirely on whether IETF decides to pursue formal standardization work in this domain.\",\n \"c\": [\n \"Data formats/interop\",\n \"A2A protocols\",\n \"Agent discovery/reg\",\n \"Human-agent interaction\",\n \"Policy/governance\"\n ]\n}\n```", "in_tok": 697, "out_tok": 391}
|
|
|
|
|
{"draft_name": "draft-anandakrishnan-ptv-attested-agent-identity", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"PTV proposes a hardware-anchored zero-knowledge proof protocol for agent identity attestation in federated environments, combining TPM 2.0 roots of trust with Groth16 ZK-proofs and HotStuff consensus. Targets healthcare CDSS, critical infrastructure ICS/OT, and GDPR/HIPAA compliance scenarios by enabling cross-domain authorization without raw data exposure.\",\n \"n\": 3,\n \"nn\": \"Combines existing components (TPM attestation, Groth16 ZKPs, HotStuff BFT) in a new federated agent identity architecture; useful synthesis addressing real data gravity concerns, but individual techniques are well-established.\",\n \"m\": 2,\n \"mn\": \"Early specification draft with abstract architecture described; lacks protocol message flows, concrete handshake sequences, algorithm details for proof generation/verification, and implementation evidence on target hardware platforms.\",\n \"o\": 4,\n \"on\": \"Significant conceptual overlap with existing TPM-based attestation (TCG standards), ZK-proof frameworks (Groth16 is standard), and BFT consensus protocols; integration approach is novel but component-level novelty is limited.\",\n \"mo\": 1,\n \"mon\": \"April 2026 expiration date suggests inactive or pre-publication status; single revision visible; no evidence of WG adoption, implementation attempts, or community discussion noted.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to agent identity/authentication and authorization in autonomous systems; strong relevance to federated agent scenarios; less relevant to core AI safety/alignment questions despite agent framing.\",\n \"c\": [\"Agent identity/auth\", \"A2A protocols\", \"Policy/governance\", \"Data formats/interop\"],\n \"overall_assessment\": \"Addresses a real problem (federated agent identity + data privacy) with sensible technical approach, but presented at too-early maturity level for IETF standardization. Needs concrete protocol specification, implementation validation, and demonstrated adoption momentum before WG consideration.\"\n}\n```", "in_tok": 658, "out_tok": 480}
|
|
|
|
|
{"draft_name": "draft-xu-efficient-agent-discovery-profile", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Defines a standardized metadata and query profile for discovering autonomous software agents through structured capability descriptions, semantic matching, and flexible backend implementations. Aims to enable interoperable agent discovery services without mandating specific ML, embedding, or ranking technologies.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution combining established patterns (capability metadata, semantic search, discovery protocols) with agent-specific context; similar to service discovery profiles (DNS-SD, mDNS) adapted for AI agents.\",\n \"m\": 3,\n \"mn\": \"Defined protocol with JSON object schemas and query/response structures, but unclear implementation maturity; lacks test vectors, reference implementations, or validation against real agent ecosystems.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing work: OpenAPI/AsyncAPI for agent capability description, semantic search standards (Schema.org, SKOS), and service discovery patterns. Positioning as agent-specific adaptation but core mechanisms well-established.\",\n \"mo\": 1,\n \"mon\": \"Single draft revision (2026-05-18), no visible WG adoption, no community discussion indicators, no implementation reports or deployment feedback documented.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to agent ecosystem standardization; addresses real interoperability gap in agent discovery; less critical than agent identity/auth or safety concerns but operationally important.\",\n \"c\": [\"Agent discovery/reg\", \"Data formats/interop\", \"A2A protocols\", \"Autonomous netops\"]\n}\n```", "in_tok": 622, "out_tok": 357}
|
|
|
|
|
{"draft_name": "draft-meta-layer-overview", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes a Meta-layer as an abstract coordination substrate enabling communities and agents to share presence, annotations, and governance across platforms independent of underlying protocols. The concept is ambitious but remains largely conceptual, lacking concrete technical mechanisms and protocol specifications for practical implementation.\",\n \"n\": 2,\n \"nn\": \"Incremental abstraction layer concept; presence/annotation/governance are well-established problems with existing solutions (ActivityPub, RDF, policy languages). Main novelty is framing these as a unified 'meta-layer' rather than novel technical approach.\",\n \"m\": 1,\n \"mn\": \"Early sketch phase. Document outlines motivation and use cases but lacks protocol definition, data models, message formats, or implementation details. No test vectors, reference implementations, or deployment guidance provided.\",\n \"o\": 4,\n \"on\": \"Significant overlap with ActivityPub (distributed presence/federation), W3C Annotation Data Model, policy frameworks (XACML), and semantic web standards. The integration angle is somewhat novel but components are well-trodden.\",\n \"m\": 2,\n \"mon\": \"Single revision indicated by date; no evidence of WG support, community adoption, or active development beyond this draft. No referenced implementations or pilot deployments.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to AI agents. Addresses agent coordination, identity, and governance which are important for multi-agent systems, but abstract framing and lack of AI-specific mechanisms limit core relevance.\",\n \"c\": [\n \"Policy/governance\",\n \"Agent identity/auth\",\n \"A2A protocols\",\n \"Agent discovery/reg\",\n \"Data formats/interop\",\n \"Human-agent interaction\"\n ]\n}\n```", "in_tok": 586, "out_tok": 410}
|
|
|
|
|
{"draft_name": "draft-zw-nmrg-mcp-network-mgmt", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes MCP extensions enabling network equipment to function as servers for AI-driven management, defining new capability tokens, tools, resources, and error codes. Aims to bridge AI applications with network infrastructure while maintaining backward compatibility with existing MCP implementations.\",\n \"n\": 2,\n \"nn\": \"Incremental work adapting existing MCP standard to network management domain; straightforward extension of established protocol rather than fundamental innovation.\",\n \"m\": 3,\n \"mn\": \"Protocol mechanisms appear defined with capability extensions specified, but maturity hampered by April 2026 date (future publication) and typical IETF draft stage lacking implementation artifacts or interoperability testing.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing network management protocols (NETCONF, YANG), MCP itself, and prior work on AI-driven network operations; positioning as 'minimal extension' limits differentiation.\",\n \"mo\": 1,\n \"mon\": \"Single revision evident; no evidence of WG sponsorship, implementation uptake, or community discussion; future date suggests incomplete development cycle.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to autonomous network operations and agent-infrastructure interoperability; timely given AI agent adoption, though execution-dependent on MCP ecosystem maturation.\",\n \"c\": [\n \"A2A protocols\",\n \"Autonomous netops\",\n \"Data formats/interop\",\n \"Agent discovery/reg\"\n ]\n}\n```", "in_tok": 552, "out_tok": 350}
|
|
|
|
|
{"draft_name": "draft-jurkovikj-httpapi-agentic-state", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes Agentic State Transfer (AST), an HTTP profile using semantic validators and optimistic concurrency control to maintain consistent resource state across multiple representations. Addresses synchronization gaps in multi-client environments where standard ETags fail to guarantee consistency across different serializations of the same resource.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution combining existing HTTP concepts (content negotiation, ETags, If-Match) with a rename/reframing as 'semantic validators' and 'canonical resource state.' The core problem is real but solutions are largely recombination of established patterns.\",\n \"m\": 3,\n \"mn\": \"Defines a coherent protocol with stated mechanisms and requirements. However, lacks implementation details, test vectors, example payloads, and concrete validation algorithms. No reference implementation or deployment experience evident from abstract.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing work: PATCH RFC 5789, conditional requests RFC 7232, Linked Data conventions, and CouchDB's document versioning. The conceptual framing as 'agentic' is somewhat novel but the technical mechanisms are well-established.\",\n \"m\": 2,\n \"mon\": \"Single revision with future date stamp suggests hypothetical/early draft status. No evidence of WG discussion, adoption signals, or iterative refinement. Appears to be initial submission without community engagement.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to agent systems. While framed for 'automated agents,' the actual problem (multi-representation consistency) is not inherently agent-specific\u2014it applies equally to any distributed clients. Agent motivation seems post-hoc rather than core.\",\n \"c\": [\"Data formats/interop\", \"A2A protocols\"]\n}\n```", "in_tok": 697, "out_tok": 415}
|
|
|
|
|
{"draft_name": "draft-xiong-rtgwg-requirements-hp-wan", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft specifies requirements for high-performance wide area networks (HP-WAN) to support massive data transmission between data centers for big data and intelligent computing applications. It outlines network performance, reliability, and efficiency requirements without proposing specific protocols or mechanisms.\",\n \"n\": 2,\n \"nn\": \"Incremental requirements document for an established problem space; combines existing WAN performance concepts without novel architectural or operational approaches.\",\n \"m\": 1,\n \"mn\": \"Problem statement and requirements enumeration only; no protocol design, implementation framework, or technical specifications provided.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing WAN/datacenter networking requirements work (e.g., IETF WAN optimization, datacenter interconnect standards); limited differentiation from prior requirements documents.\",\n \"mo\": 2,\n \"mon\": \"Single revision dated 2025-01-03 with no visible WG sponsorship or community adoption signals; appears to be early-stage individual submission.\",\n \"r\": 1,\n \"rn\": \"Not relevant to AI agents; addresses general datacenter networking infrastructure requirements with no connection to autonomous agents, AI model serving, or agent protocols.\",\n \"c\": [\"Other AI/agent\"]\n}\n```", "in_tok": 518, "out_tok": 296}
|
|
|
|
|
{"draft_name": "draft-vandemeent-ains-discovery", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"AINS proposes a DNS-like discovery and trust resolution protocol for autonomous agents across heterogeneous networks, using HTTPS-based resolution with append-only logs for federated multi-registry deployments. The protocol maps agent identifiers to rich metadata including capabilities, trust scores, and cryptographic credentials.\",\n \"n\": 3,\n \"nn\": \"Useful contribution combining established patterns (DNS analogy, append-only logs, federated identity) in a new domain (agent discovery), but lacks fundamental novelty\u2014similar federated trust models exist in PKI and blockchain systems.\",\n \"m\": 2,\n \"mn\": \"Early specification stage; protocol structure is defined but lacks implementation details, test vectors, security analysis, and concrete examples. References to companion protocols (TIBET, JIS, UPIP, RVP) suggest work-in-progress ecosystem without clear integration points.\",\n \"o\": 3,\n \"on\": \"Shares concepts with DNS, LDAP, and blockchain-based registries; trust metadata approaches overlap with X.509/PKIX and decentralized identity systems (DID); federated log architecture resembles Certificate Transparency.\",\n \"m\": 1,\n \"mon\": \"Single draft revision with 2026 date suggests limited community engagement or recent submission; no apparent WG adoption, citations to non-existent companion specs reduce credibility.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to agent discovery and identity/authentication problems; moderately relevant to autonomous netops and A2A protocol infrastructure; less applicable to AI safety or model serving.\",\n \"c\": [\"Agent discovery/reg\", \"Agent identity/auth\", \"A2A protocols\", \"Data formats/interop\", \"Autonomous netops\"]\n}\n```", "in_tok": 671, "out_tok": 407}
|
|
|
|
|
{"draft_name": "draft-han-rtgwg-codeployment-pfc-fgfc", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft addresses the need for coordinated flow control mechanisms between Data Center Networks using PFC and Wide Area Networks using fine-grained flow control to achieve end-to-end lossless transmission. It outlines use cases and requirements for collaborative flow control across heterogeneous network domains.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution extending existing PFC concepts to WAN domains; fine-grained flow control is a logical evolution but not fundamentally novel.\",\n \"m\": 2,\n \"mn\": \"Early-stage problem framing document; lacks protocol specifications, implementation details, or concrete mechanisms for DCN-WAN collaboration.\",\n \"o\": 3,\n \"on\": \"Builds on established PFC standards and existing fine-grained flow control research; moderate conceptual overlap with congestion management literature.\",\n \"mo\": 1,\n \"mon\": \"Single revision with limited community visibility; early draft stage suggests nascent effort without demonstrated WG traction or implementations.\",\n \"r\": 2,\n \"rn\": \"Tangentially related to agent infrastructure (network optimization); not directly about AI agents, autonomous systems, or agent protocols despite potential applications in AI workload networks.\",\n \"c\": [\n \"Autonomous netops\",\n \"ML traffic mgmt\",\n \"Other AI/agent\"\n ]\n}\n```", "in_tok": 646, "out_tok": 318}
|
|
|
|
|
{"draft_name": "draft-dunbar-neotec-ac-pe2pe-ucmp-applicability", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft evaluates how existing IETF YANG data models (AC, TE Topology, SR Policy, QoS) can be applied to dynamic, time-scoped UCMP policy enforcement for edge cloud AI inference workloads with periodic high-volume data exchanges. It identifies gaps in model expressiveness, policy lifecycle handling, and cloud-network coordination APIs needed for real-time network policy activation.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution applying existing YANG models to a specific edge cloud use case; the technical novelty is limited to mapping known models to AI inference traffic patterns rather than proposing new mechanisms or architectures.\",\n \"m\": 2,\n \"mn\": \"Early-stage applicability study without detailed protocol specifications, implementation details, or test vectors; reads as a requirements/gap analysis document rather than a mature technical specification.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing IETF work on TE policies, SR policies, QoS models, and YANG data models; the use case of edge cloud coordination partially overlaps with ongoing work in CCAMP, NETMOD, and I2RS working groups.\",\n \"mo\": 2,\n \"mon\": \"Single dated revision (2025-12-25 appears to be a placeholder future date); no evidence of WG adoption or community momentum; appears to be exploratory work without active development cycle.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to AI/agent topics; focuses on network infrastructure for AI inference workloads but does not address agent autonomy, decision-making, or multi-agent coordination\u2014more about traffic management for AI services than agent-centric networking.\",\n \"c\": [\"ML traffic mgmt\", \"Autonomous netops\", \"Data formats/interop\", \"Policy/governance\", \"Model serving/inference\"]\n}\n```", "in_tok": 678, "out_tok": 434}
|
|
|
|
|
{"draft_name": "draft-mpsb-agntcy-slim", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"SLIM proposes a gRPC-based transport protocol for real-time AI agent communication, combining HTTP/2 and HTTP/3 with MLS encryption and group messaging. It aims to provide low-latency infrastructure for agent-to-agent protocols like A2A and MCP at scale.\",\n \"n\": 2,\n \"nn\": \"Primarily repackages existing technologies (gRPC, HTTP/2/3, MLS) for agent use cases; minimal protocol innovation beyond standard multiplexing and RPC mechanics.\",\n \"m\": 3,\n \"mn\": \"Defines protocol structure and mechanisms clearly but lacks implementation details, test vectors, and interoperability guidance; maturity sufficient for discussion but not deployment-ready.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing gRPC/HTTP/2/3 specifications, MLS work, and prior A2A drafts; primarily a bundling/application profile rather than novel composition.\",\n \"mo\": 2,\n \"mon\": \"Single revision as of 2026-02-24; no evidence of WG adoption, multiple iterations, or community engagement; appears early-stage.\",\n \"r\": 4,\n \"rn\": \"Directly addresses agent communication infrastructure, relevant to A2A and MCP ecosystems; practical relevance for distributed AI systems, though positioning over existing protocols needs stronger justification.\",\n \"c\": [\"A2A protocols\", \"Agent identity/auth\", \"Data formats/interop\", \"Model serving/inference\"]\n}\n```", "in_tok": 591, "out_tok": 361}
|
|
|
|
|
{"draft_name": "draft-wu-savnet-inter-domain-architecture", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft proposes an inter-domain architecture for Source Address Validation (SAV) at the AS level, enabling ASes to generate accurate validation rules by sharing SAV-specific information while falling back to general information during partial deployment. The framework focuses on architectural components and information sharing rather than specific protocol designs.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution building on existing SAVNET work; applies known SAV principles to inter-domain context with fallback mechanisms but lacks fundamental conceptual innovation.\",\n \"m\": 3,\n \"mn\": \"Well-structured architectural framework with defined components and information types, but remains at design/guidance level without protocol specifications, implementation details, or validation examples.\",\n \"o\": 4,\n \"on\": \"Significant overlap with general SAVNET architecture efforts; closely related to intra-domain SAV work and other inter-domain validation proposals; limited differentiation in core concepts.\",\n \"mo\": 3,\n \"mon\": \"Part of active SAVNET WG work with incremental revisions, indicating steady engagement but not exceptional adoption momentum or breakthrough interest signals.\",\n \"r\": 1,\n \"rn\": \"Source Address Validation is a network security mechanism unrelated to AI agents, autonomous systems in ML sense, or intelligent networked systems; false positive on AI/agent relevance.\",\n \"c\": [\n \"Other AI/agent\"\n ]\n}\n```", "in_tok": 655, "out_tok": 331}
|
|
|
|
|
{"draft_name": "draft-gudlab-agentid-protocol", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes AgentID Protocol for establishing cryptographic identity and authorization of autonomous AI agents across internet services using JWT-based Agent Identity Tokens. Adapts OAuth 2.0/OIDC patterns to non-human actors with delegation chains and capability scoping.\",\n \"n\": 2,\n \"nn\": \"Incremental extension applying established identity/auth standards (JWT, OAuth 2.0, OIDC) to AI agents; core concepts are straightforward adaptations rather than novel mechanisms.\",\n \"m\": 3,\n \"mn\": \"Defined protocol structure with claims architecture and delegation model; lacks implementation details, test vectors, and threat analysis expected in IETF maturity.\",\n \"o\": 4,\n \"on\": \"Significant overlap with service account patterns, OAuth 2.0 client credentials, mutual TLS, and emerging work on API authentication for automated systems; differentiation from existing delegation frameworks unclear.\",\n \"mo\": 2,\n \"mon\": \"Single draft revision; no evidence of WG adoption, implementation, or community feedback; timing (March 2026) and early-stage positioning suggest limited momentum.\",\n \"r\": 4,\n \"rn\": \"Directly addresses real gap in AI agent identity/authorization for autonomous systems, though framing emphasizes web API access over core AI safety/alignment concerns.\",\n \"c\": [\n \"Agent identity/auth\",\n \"A2A protocols\",\n \"Agent discovery/reg\",\n \"Data formats/interop\",\n \"Policy/governance\"\n ]\n}\n```", "in_tok": 663, "out_tok": 367}
|
|
|
|
|
{"draft_name": "draft-ravikiran-clawdentity-protocol", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Clawdentity defines a cryptographic identity and trust protocol for AI agent-to-agent communication, combining Ed25519 identities with registry-issued credentials and WebSocket-based authenticated relay. It addresses identity verification and bilateral trust establishment for agent networks without exposing private keys or backend infrastructure.\",\n \"n\": 2,\n \"nn\": \"Applies established cryptographic primitives (Ed25519, proof-of-possession) to agent communication; pairing ceremonies and credential frameworks are incremental combinations of existing patterns rather than novel mechanisms.\",\n \"m\": 3,\n \"mn\": \"Protocol is defined with functional components and mechanisms specified, but lacks implementation details, test vectors, and worked examples needed for production deployment.\",\n \"o\": 4,\n \"on\": \"Substantial overlap with existing identity frameworks (SPIFFE, mTLS patterns), registry-based credential systems, and WebSocket security approaches; the agent-specific framing is the primary differentiator.\",\n \"mo\": 2,\n \"mon\": \"Single dated submission (2026-02-21) with no evidence of revision history, WG discussion, or adoption signals; appears to be initial draft stage.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to agent authentication and trust establishment; addresses genuine need for agent-to-agent identity in multi-agent systems, though not focused on core AI safety or alignment concerns.\",\n \"c\": [\n \"A2A protocols\",\n \"Agent identity/auth\",\n \"Agent discovery/reg\",\n \"Data formats/interop\"\n ]\n}\n```", "in_tok": 586, "out_tok": 371}
|
|
|
|
|
{"draft_name": "draft-pang-agents-networking-scenarios", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Describes networking scenarios for AI agents in enterprise and home broadband networks, distinguishing these use cases from mobile and Internet contexts. Based on reasonable assumptions given agentic services are still emerging in these deployment domains.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution focusing on scenario documentation rather than novel technical approaches; primarily scoping existing agent concepts to specific network environments.\",\n \"m\": 2,\n \"mn\": \"Early-stage document presenting scenario descriptions and assumptions without detailed protocol specifications, implementation guidance, or technical mechanisms.\",\n \"o\": 4,\n \"on\": \"Significant overlap with broader agent networking discussions; scenarios largely extrapolate from established mobile/Internet agent concepts without differentiation.\",\n \"mo\": 1,\n \"mon\": \"Single revision observed; limited evidence of active development or community engagement in this specific draft line.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to AI agent networking\u2014addresses deployment contexts but lacks technical depth on agent-specific networking challenges, protocols, or solutions.\",\n \"c\": [\n \"Agent discovery/reg\",\n \"Autonomous netops\",\n \"Other AI/agent\"\n ]\n}\n```", "in_tok": 514, "out_tok": 280}
|
|
|
|
|
{"draft_name": "draft-irtf-nmrg-ai-deploy", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft addresses how to configure networks and systems to deploy AI inference services across distributed edge and cloud infrastructure. It covers system architecture considerations for running AI on commodity hardware and provides use cases like autonomous vehicles and digital twins.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution; mostly documenting known best practices for distributed AI deployment rather than proposing novel technical solutions.\",\n \"m\": 2,\n \"mn\": \"Early sketch stage; outlines considerations and use cases but lacks detailed protocols, specifications, or implementation guidance needed for operational deployment.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing literature on edge computing, ML system design, and distributed inference; does not clearly differentiate from prior work or standards.\",\n \"mo\": 1,\n \"mon\": \"Limited momentum indicators; single revision, unclear WG support, and positioning as informational material rather than solving specific standards gaps.\",\n \"r\": 3,\n \"rn\": \"Partially relevant; addresses AI service deployment infrastructure but focuses on networking/system concerns rather than AI agents, autonomy, or intelligence aspects.\",\n \"c\": [\"Model serving/inference\", \"ML traffic mgmt\", \"Other AI/agent\"]\n}\n```", "in_tok": 611, "out_tok": 284}
|
|
|
|
|
{"draft_name": "draft-aylward-daap-v2", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"DAAP v2.0 proposes a protocol framework combining cryptographic identity verification, real-time monitoring, and remote control mechanisms for autonomous AI agents. It addresses AI safety concerns through multi-layered security including hardware backing, periodic check-ins, and behavioral monitoring to enable accountability and regulatory compliance.\",\n \"n\": 2,\n \"nn\": \"Combines existing security patterns (attestation, monitoring, shutdown capabilities) into an AI-specific protocol; incremental extension of established distributed systems accountability approaches rather than fundamentally novel mechanisms.\",\n \"m\": 3,\n \"mn\": \"Protocol structure and primary mechanisms are defined with clear conceptual components (identity verification, check-ins, shutdown, location reporting), but lacks detailed cryptographic specifications, message formats, or implementation examples.\",\n \"o\": 4,\n \"on\": \"Substantial overlap with existing agent control frameworks, container orchestration security models, and IoT device management protocols; similar monitoring/attestation concepts appear in TPM-based systems and automated incident response platforms.\",\n \"mo\": 1,\n \"mon\": \"Single draft submission with 2026 date; no evidence of WG discussion, multiple iterations, or community engagement; appears to be initial proposal without follow-up activity.\",\n \"r\": 4,\n \"rn\": \"Directly addresses critical AI agent governance and safety concerns highly relevant to IETF scope; timely given regulatory focus on AI accountability and autonomous system control, though framing emphasizes governance over technical protocol depth.\",\n \"c\": [\n \"Agent identity/auth\",\n \"AI safety/alignment\",\n \"Policy/governance\",\n \"A2A protocols\",\n \"Autonomous netops\"\n ]\n}\n```", "in_tok": 579, "out_tok": 394}
|
|
|
|
|
{"draft_name": "draft-ietf-websec-mime-sniff", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft specifies an algorithm for determining the effective media type of HTTP responses by considering both Content-Type headers and response content, addressing the practical problem of servers sending incorrect MIME types while balancing security and compatibility. It standardizes MIME sniffing behavior across user agents to prevent content-type confusion attacks.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution formalizing existing browser behavior; MIME sniffing has been practiced for decades, though standardization of the algorithm adds value.\",\n \"m\": 4,\n \"mn\": \"Well-detailed specification with clear algorithm description suitable for implementation; appears to have concrete examples and security considerations.\",\n \"o\": 3,\n \"on\": \"Shares conceptual overlap with existing WHATWG HTML Living Standard sniffing algorithms and prior browser implementations; addresses a known problem space rather than unique territory.\",\n \"mo\": 3,\n \"mon\": \"Active IETF WebSec WG adoption with recent 2024 revision indicates sustained interest, though not exceptional community momentum compared to emerging standards.\",\n \"r\": 1,\n \"rn\": \"Not relevant to AI agents or AI-related networking; focuses on general HTTP content-type handling for web browsers and servers, outside the AI/agent domain.\",\n \"c\": [\"Data formats/interop\"]\n}\n```", "in_tok": 543, "out_tok": 313}
|
|
|
|
|
{"draft_name": "draft-pioli-agent-discovery", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"ARDP provides a lightweight discovery and registration protocol for autonomous software agents in distributed environments, supporting multiple transport protocols (MCP, A2A, HTTP, gRPC) with capability advertisement and security-first design. The protocol enables stable agent identities and dynamic endpoint resolution across federated systems.\",\n \"n\": 2,\n \"nn\": \"Registration and discovery for agents is incremental over existing service discovery patterns (DNS-SD, mDNS, Consul); the primary novelty is agent-specific capability advertisement including protocol negotiation, but this extends rather than fundamentally reimagines existing discovery paradigms.\",\n \"m\": 3,\n \"mn\": \"Protocol is formally defined with specified mechanics for registration, discovery, and endpoint resolution, but at 13 pages likely lacks detailed implementation guidance, test vectors, or reference implementations needed for production deployment.\",\n \"o\": 3,\n \"on\": \"Shares conceptual overlap with service discovery systems (mDNS, Consul), agent frameworks (OpenAI swarms), and protocol negotiation schemes; somewhat similar to capability-based discovery in IoT protocols but tailored for agent workloads.\",\n \"mo\": 2,\n \"mon\": \"Single draft revision dated 2026-02-24 with no visible WG adoption, community discussion, or implementation status; early-stage effort without clear momentum or adoption signals.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to autonomous agent deployment and orchestration; addresses core operational need (agent identity, discovery, capability negotiation) essential for practical multi-agent systems, though not specifically about agent reasoning or safety.\",\n \"c\": [\n \"Agent discovery/reg\",\n \"Agent identity/auth\",\n \"A2A protocols\",\n \"Data formats/interop\",\n \"Autonomous netops\"\n ]\n}\n```", "in_tok": 564, "out_tok": 426}
|
|
|
|
|
{"draft_name": "draft-chu-oauth-as-attested-user-cert", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Extends OAuth 2.0 RAR to allow clients (particularly AI agents) to request AS-attested public key certificates bound to access tokens, enabling resource servers to verify delegated claims signed by resource owners. Combines certificate binding with OAuth 2.0 to create a chain of trust for autonomous agent authorization.\",\n \"n\": 2,\n \"nn\": \"Incremental extension combining existing OAuth 2.0 RAR framework with certificate binding patterns; core idea of attesting user keys via AS is straightforward application of established mechanisms.\",\n \"m\": 2,\n \"mn\": \"Early-stage sketch (9 pages) lacking implementation details, test vectors, security proofs, and concrete protocol flow diagrams; abstract describes intent but specification maturity unclear.\",\n \"o\": 4,\n \"on\": \"Significant conceptual overlap with certificate-bound tokens (RFC 8705, DPoP), MTLS patterns, and existing RAR extensions; differentiation from prior work not clearly articulated.\",\n \"mo\": 1,\n \"mon\": \"Single revision dated 2026 with no visible WG discussion, adoption signals, or implementation reports; appears to be initial submission without community momentum.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to autonomous agent authorization scenarios; addresses identity/authentication challenges for AI agents acting on behalf of users, though framing could be clearer.\",\n \"c\": [\"Agent identity/auth\", \"A2A protocols\", \"Policy/governance\", \"Data formats/interop\"]\n}\n```", "in_tok": 595, "out_tok": 359}
|
|
|
|
|
{"draft_name": "draft-rosenberg-aiproto-framework", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft proposes a framework for standardizing AI agent communications on the Internet, surveying existing protocols like MCP and A2A while identifying gaps and requirements for IETF standards work in agent interoperability.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution\u2014primarily a survey and taxonomy of existing work (MCP, A2A, Agntcy) rather than proposing novel architectural or protocol concepts.\",\n \"m\": 2,\n \"mn\": \"Early sketch stage; provides framework and use cases but lacks detailed protocol specifications, implementation guidance, or formal mechanism definitions.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing initiatives (MCP, A2A, Agntcy); positions itself as a meta-framework but doesn't clearly differentiate from or advance these parallel efforts.\",\n \"mo\": 2,\n \"mon\": \"Single revision with limited evidence of broader community momentum; positions itself as exploratory rather than driven by active WG consensus or widespread adoption.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI agent standardization; addresses timely need for protocol frameworks as agent deployments increase, though scope may be too broad for focused standards work.\",\n \"c\": [\n \"A2A protocols\",\n \"Data formats/interop\",\n \"Agent discovery/reg\",\n \"Human-agent interaction\",\n \"Policy/governance\",\n \"Agent identity/auth\"\n ]\n}\n```", "in_tok": 699, "out_tok": 348}
|
|
|
|
|
{"draft_name": "draft-altanai-aipref-realtime-protocol-bindings", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes binding AI preference expressions to SIP/SDP for real-time communications, enabling endpoints and AI assistants to negotiate AI-driven processing of session metadata and media. Defines SIP headers and SDP attributes as concrete mechanisms for expressing AI requirements without disrupting existing call control.\",\n \"n\": 2,\n \"nn\": \"Incremental extension applying existing AIPREF vocabulary to real-time protocols; combines established concepts (SIP/SDP signaling, preference expressions) in a new domain rather than introducing fundamentally novel mechanisms.\",\n \"m\": 3,\n \"mn\": \"Protocol mechanisms defined with header/attribute conventions, but appears to lack implementation examples, test vectors, and validation against real deployment scenarios; suitable for early adoption but not production-ready.\",\n \"o\": 4,\n \"on\": \"Significant conceptual overlap with existing preference/capability negotiation frameworks in SIP (RFC 3841, 4566); builds on established SDP extension patterns; limited novelty in binding approach relative to prior work.\",\n \"mo\": 1,\n \"mon\": \"Single draft revision (2026-02-03), no visible WG sponsorship, no evidence of multiple revisions or community discussion; appears to be an individual submission without established momentum.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to AI agent topics\u2014addresses protocol interoperability and agent signaling preferences, but focuses narrowly on real-time comms rather than broader agent autonomy, safety, or governance concerns.\",\n \"c\": [\n \"A2A protocols\",\n \"Data formats/interop\",\n \"Agent identity/auth\",\n \"Policy/governance\"\n ]\n}\n```", "in_tok": 620, "out_tok": 394}
|
|
|
|
|
{"draft_name": "draft-song-anp-aip", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes Agent Internet Protocol (AIP) as a narrow-waist protocol for autonomous AI agents, analogous to IP's role in TCP/IP, using human-readable agent:// URIs for addressing and providing datagram delivery between agents. Specifies message format, addressing, protocol demultiplexing, and error handling while deferring name resolution and discovery to companion services.\",\n \"n\": 2,\n \"nn\": \"Applies well-established IP/TCP-IP architecture patterns to agent communication; the core innovation (URI-based agent addressing) is incremental rather than fundamentally novel.\",\n \"m\": 3,\n \"mn\": \"Provides defined protocol specification with message formats and processing rules, but lacks implementation details, test vectors, and validation against real-world agent deployments.\",\n \"o\": 4,\n \"on\": \"Significant conceptual overlap with DNS/DDNS-like resolution models and existing A2A protocols (MQTT, AMQP, gRPC); the narrow-waist positioning echoes prior work in protocol layering and service discovery.\",\n \"mo\": 1,\n \"mon\": \"Single draft with March 2026 date suggests very recent/upcoming work; no evidence of WG adoption, revisions, or community engagement visible.\",\n \"r\": 4,\n \"rn\": \"Directly addresses agent-to-agent communication infrastructure, a core concern for autonomous AI systems, though applicability depends on whether AI agents actually adopt IP-like narrow waists.\",\n \"c\": [\n \"A2A protocols\",\n \"Agent identity/auth\",\n \"Agent discovery/reg\",\n \"Data formats/interop\",\n \"Autonomous netops\"\n ]\n}\n```", "in_tok": 660, "out_tok": 404}
|
|
|
|
|
{"draft_name": "draft-baur-pap", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"PAP proposes a cryptographic protocol for agent-to-agent transactions with human principals at the root of trust, using hierarchical delegation via signed mandates and selective disclosure to minimize context exposure. The protocol avoids novel cryptography, centralized registries, and trusted third parties while ensuring session ephemerality.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution combining existing cryptographic techniques (signatures, disclosure mechanisms) into a delegation framework; the core concepts (hierarchical mandates, selective disclosure) are well-established in identity and authorization domains.\",\n \"m\": 4,\n \"mn\": \"Detailed protocol specification at 91 pages with defined trust model, delegation semantics, and structural guarantees; appears implementation-ready but maturity depends on presence of test vectors and reference implementations (unclear from abstract).\",\n \"o\": 4,\n \"on\": \"Significant overlap with OAuth 2.0 delegation flows, SAML assertions, verifiable credentials frameworks, and existing zero-knowledge/selective-disclosure protocols (e.g., W3C VC); human-in-the-loop agent control is not novel.\",\n \"m\": 2,\n \"mon\": \"Single draft revision dated 2026-05-20 with no apparent WG adoption, community discussion, or implementation feedback; appears early-stage for IETF standardization track.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to AI agent systems\u2014addresses agent-to-agent authorization and human oversight, which are important for agent orchestration and control, but does not directly address AI safety, alignment, model serving, or learning-specific concerns.\",\n \"c\": [\n \"A2A protocols\",\n \"Agent identity/auth\",\n \"Human-agent interaction\",\n \"Policy/governance\"\n ]\n}\n```", "in_tok": 553, "out_tok": 424}
|
|
|
|
|
{"draft_name": "draft-ffm-rats-cca-token", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft specifies the Arm CCA attestation token structure as a profile of the EAT standard, defining claims, serialization, and cryptographic protection for confidential compute environments. It enables trustworthiness assessment of CCA-compliant systems through standardized attestation mechanisms.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution: applies existing EAT framework to Arm's specific CCA architecture without introducing novel attestation concepts or mechanisms.\",\n \"m\": 4,\n \"mn\": \"Well-detailed specification with defined token structure, claim semantics, and serialization formats suitable for implementation, though lacking test vectors and reference implementations.\",\n \"o\": 3,\n \"on\": \"Shares core concepts with EAT and other TEE attestation drafts (Intel SGX, AMD SEV); CCA-specific profile adds modest differentiation but follows established patterns.\",\n \"mo\": 2,\n \"mon\": \"Single revision as independent submission; limited WG traction indicated by non-standards-track status and Arm-vendor-specific scope.\",\n \"r\": 2,\n \"rn\": \"Tangentially related to AI agent systems; relevant only if agents run on CCA-protected compute or require CCA attestation for trustworthiness verification, but not core to agent protocols or AI safety.\",\n \"c\": [\"Agent identity/auth\", \"Data formats/interop\"]\n}\n```", "in_tok": 671, "out_tok": 333}
|
|
|
|
|
{"draft_name": "draft-howe-sipcore-mcp-extension", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes SIP extension enabling negotiation and transport of Model Context Protocol (MCP) for AI agent communication. Defines new option-tags, headers, and media types to integrate MCP into SIP session establishment and mid-dialog exchanges.\",\n \"n\": 2,\n \"nn\": \"Incremental extension combining existing protocols (SIP + MCP); straightforward mapping of MCP onto SIP offer/answer without fundamental innovation\",\n \"m\": 3,\n \"mn\": \"Protocol mechanisms defined (option-tags, headers, media type) but appears to lack implementation details, test vectors, interoperability examples, or handling of edge cases\",\n \"o\": 4,\n \"on\": \"Significant overlap with protocol bridging patterns; similar MCP integration concepts likely explored in other transport/signaling proposals; limited novelty over existing SIP extension frameworks\",\n \"mo\": 1,\n \"mon\": \"Single draft revision dated 2026-04-02; no evidence of WG adoption, community discussion, or iterative development momentum; appears to be exploratory submission\",\n \"r\": 4,\n \"rn\": \"Directly relevant to A2A protocols and agent interop; addresses agent communication infrastructure but focuses narrowly on SIP transport layer rather than broader agent capabilities\",\n \"c\": [\n \"A2A protocols\",\n \"Data formats/interop\",\n \"Agent discovery/reg\",\n \"Model serving/inference\"\n ]\n}\n```", "in_tok": 590, "out_tok": 346}
|
|
|
|
|
{"draft_name": "draft-coetzee-oauth-spt-txn-tokens", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"SPT-Txn extends IETF Transaction Tokens with Capability Acquisition Tokens to enable fine-grained, auditable, policy-bound authorization across multi-organizational and agentic systems. The framework cryptographically binds capabilities to transaction contexts while propagating human-origin identity commitments and enabling offline verification.\",\n \"n\": 3,\n \"nn\": \"Incremental extension of RFC 9700 with capability scoping and delegation chain auditability; combines existing token concepts (bearer tokens, transaction tokens) with capability-based access control in novel transaction context.\",\n \"m\": 3,\n \"mn\": \"Protocol mechanism is defined with abstract framework and concepts, but lacks concrete examples, test vectors, and implementation guidance needed for specification completeness.\",\n \"o\": 3,\n \"on\": \"Shares conceptual overlap with capability-based security, delegated authorization (OAuth 2.0 Token Exchange), and audit trails; extends RFC 9700 directly; relates to ABAC and transaction tokens but distinct enough approach.\",\n \"mo\": 2,\n \"mon\": \"Single draft revision dated 2026-04-27 with no visible WG sponsorship or community discussion; appears early-stage without evidence of broader adoption momentum.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to agent authorization and multi-agent transaction coordination; addresses human-origin commitments and delegation chains critical for agentic AI systems; less relevant to core AI/ML topics.\",\n \"c\": [\"Agent identity/auth\", \"Policy/governance\", \"A2A protocols\", \"Human-agent interaction\"]\n}\n```", "in_tok": 695, "out_tok": 378}
|
|
|
|
|
{"draft_name": "draft-dunbar-onsen-ac-te-applicability", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft explores applying existing IETF YANG data models (ACaaS and TE topology) to support dynamic AI model placement at edge cloud sites, using real-time camera feeds and network performance metrics to optimize inference location selection. It evaluates model applicability for edge AI use cases through practical mapping across network segments.\",\n \"n\": 2,\n \"nn\": \"Incremental application of existing YANG models to a specific edge AI use case; combines known technologies without fundamental innovation in either YANG modeling or edge AI orchestration.\",\n \"m\": 2,\n \"mn\": \"Early-stage applicability study without detailed protocol specifications, implementation examples, or formal gap analysis methodology; primarily a conceptual exercise.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing edge computing, TE, and service provisioning work; AC-as-a-Service and TE-topology models already standardized; edge AI placement addressed in multiple other contexts.\",\n \"mo\": 1,\n \"mon\": \"Single revision as of submission date with no apparent WG adoption; limited indication of community engagement or follow-up iterations.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to AI infrastructure but focused narrowly on network model applicability rather than core AI agent behaviors, safety, or autonomous decision-making.\",\n \"c\": [\n \"Model serving/inference\",\n \"ML traffic mgmt\",\n \"Data formats/interop\",\n \"Autonomous netops\"\n ]\n}\n```", "in_tok": 629, "out_tok": 354}
|
|
|
|
|
{"draft_name": "draft-chuyi-nmrg-ai-agent-network", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft proposes using large language model-based AI agents to address network operations and maintenance challenges by reducing manual tasks and improving system intelligence. It identifies operational pain points and explores how AI agents can be integrated into network architectures while discussing standardization implications.\",\n \"n\": 2,\n \"nn\": \"Incremental application of existing LLM/agent concepts to network operations; the core ideas of using AI for automation and self-healing networks are established, though the agent-based approach adds modest novelty.\",\n \"m\": 2,\n \"mn\": \"Early-stage position paper identifying problems and high-level solutions; lacks concrete protocol specifications, implementation details, or deployment examples; discusses standardization needs without defining concrete mechanisms.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing work on AI-driven network automation, intelligent RAN management, and network digital twins; agent frameworks and LLM applications in networking are well-explored; limited differentiation from prior art.\",\n \"mo\": 2,\n \"mon\": \"Single dated submission (2026-04-23) with no indicated revisions; NMRG is research-oriented rather than standards-track; unclear adoption or feedback cycle; appears to be initial/exploratory contribution.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI agents in networked systems; addresses autonomous network operations which is core AI agent territory; relevance to practical network challenges is clear.\",\n \"c\": [\n \"Autonomous netops\",\n \"Agent discovery/reg\",\n \"Data formats/interop\",\n \"Policy/governance\",\n \"Model serving/inference\",\n \"Human-agent interaction\"\n ]\n}\n```", "in_tok": 618, "out_tok": 394}
|
|
|
|
|
{"draft_name": "draft-xiong-rtgwg-use-cases-hp-wan", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Draft describes use cases for high-performance wide area networks (HP-WAN) to support big data and intelligent computing applications requiring massive data transmission. Focuses on identifying scenarios where enhanced WAN performance benefits emerging data-intensive workloads across metropolitan and wide area networks.\",\n \"n\": 2,\n \"nn\": \"Use case documentation for WAN performance is incremental; identifies existing demands (big data, ML inference) rather than proposing novel network mechanisms or protocols.\",\n \"m\": 2,\n \"mn\": \"Early stage use case collection without detailed technical specifications, protocols, or implementation guidance; primarily descriptive rather than prescriptive.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing work on data center networking, ML traffic optimization, and WAN performance requirements already covered in related IETF and standards work.\",\n \"mo\": 2,\n \"mon\": \"Single draft revision with limited indication of working group traction or community engagement; appears to be foundational positioning rather than active development.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to AI agent infrastructure; addresses data transmission for intelligent computing but lacks specific focus on agent communication patterns, distributed agent coordination, or agent-specific networking requirements.\",\n \"c\": [\"ML traffic mgmt\", \"Model serving/inference\", \"Autonomous netops\", \"Policy/governance\"]\n}\n```", "in_tok": 512, "out_tok": 319}
|
|
|
|
|
{"draft_name": "draft-bernardos-green-isac-uc", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft presents an ISAC use case for the GREEN Working Group, proposing a structured template for discussing how integrated sensing and communication can benefit autonomous systems and smart cities. It aims to facilitate GREEN WG discussions on ISAC's potential benefits, challenges, and requirements without presenting detailed technical specifications.\",\n \"n\": 2,\n \"nn\": \"Incremental application of existing ISAC concepts to a GREEN WG context; the core ISAC paradigm is established, and this work primarily contextualizes it for use case discussion rather than introducing novel sensing-communication integration approaches.\",\n \"m\": 1,\n \"mn\": \"Problem statement and use case framing only; the draft explicitly proposes a template for discussion and lacks protocol definitions, technical specifications, implementation details, or concrete requirements that would indicate maturity beyond early scoping.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing ISAC literature and emerging 6G discussions; ISAC concepts have been extensively explored in 3GPP, IEEE, and academia; this draft adds minimal novel perspective beyond standard ISAC applications.\",\n \"mo\": 2,\n \"mon\": \"Early-stage contribution with limited evidence of sustained momentum; appears to be single submission to GREEN WG for discussion purposes; no indication of multiple revisions, broad community engagement, or adoption trajectory.\",\n \"r\": 2,\n \"rn\": \"Tangentially related to AI agents; focuses on sensing and communication infrastructure rather than agent systems, decision-making, or autonomous agent coordination; relevance to AI/agent topics is indirect through autonomous systems mention only.\",\n \"c\": [\n \"Other AI/agent\"\n ]\n}\n```", "in_tok": 644, "out_tok": 387}
|
|
|
|
|
{"draft_name": "draft-tejido-swp-core", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"SWP Core defines a slim binary framing and envelope format for agent/tool messaging with transport-independent boundaries, LEB128-based encoding, and profile-based extensibility. It includes conformance classes, test vectors, and a security binding requiring authenticated confidential channels.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution combining established techniques (length-prefixed frames, LEB128 encoding, TLV extensions, profile dispatch) without significant novel framing concepts.\",\n \"m\": 4,\n \"mn\": \"Well-structured specification with defined envelope encoding (E1), conformance classes, golden vector artifacts, and spec-vector runner validation; lacks visible reference implementations or deployment evidence.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing binary protocols (protobuf/grpc framing patterns, CBOR/MessagePack encoding philosophies, profile-based dispatch similar to HTTP content negotiation).\",\n \"mo\": 2,\n \"mon\": \"Single revision dated 2026-02-20 with no evidence of working group adoption, community interest, or multiple implementation efforts.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to agent-to-agent communication infrastructure and interoperability; focuses on foundational messaging layer rather than agent semantics or intelligence.\",\n \"c\": [\"A2A protocols\", \"Data formats/interop\", \"Agent identity/auth\"]\n}\n```", "in_tok": 681, "out_tok": 337}
|
|
|
|
|
{"draft_name": "draft-nandakumar-a2a-moqt-transport", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft proposes transporting the Agent-to-Agent (A2A) protocol over MOQT (Media over QUIC Transport), leveraging MOQT's publish/subscribe model and prioritization for AI agent communication. It combines existing protocols to enable discovery, negotiation, and collaboration between agents with efficient real-time streaming.\",\n \"n\": 2,\n \"nn\": \"Incremental mapping of one protocol stack onto another; combines existing technologies (A2A + MOQT) without introducing novel concepts in agent communication architecture or transport optimization.\",\n \"m\": 2,\n \"mn\": \"Early sketch stage; abstract describes intent but 12 pages likely lacks detailed protocol mapping, message formats, error handling, or implementation guidance needed for production use.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing A2A protocol specifications and MOQT media streaming work; the contribution is primarily combinatorial rather than addressing gaps in either specification.\",\n \"mo\": 1,\n \"mon\": \"Single draft revision dated 2026-04-23 with no apparent community engagement, WG sponsorship, or evidence of implementation interest; appears dormant.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to AI agent infrastructure; addresses agent communication transport but lacks focus on core agent topics like safety, discovery mechanisms, identity management, or agent-specific operational concerns.\",\n \"c\": [\n \"A2A protocols\",\n \"Data formats/interop\",\n \"Agent discovery/reg\"\n ]\n}\n```", "in_tok": 567, "out_tok": 363}
|
|
|
|
|
{"draft_name": "draft-zl-agents-networking-architecture", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes a networking architecture framework for AI agents in enterprise and broadband environments, defining core components and interaction patterns. Addresses how agent systems should be networked and managed at infrastructure level.\",\n \"n\": 2,\n \"nn\": \"Incremental framing of agent networking as architectural concern; lacks novel technical mechanisms or protocols differentiating from existing distributed systems approaches.\",\n \"m\": 2,\n \"mn\": \"Early-stage conceptual document (13 pages) presenting problem space and component definitions; no detailed protocols, specifications, or implementation guidance provided.\",\n \"o\": 4,\n \"on\": \"Significant conceptual overlap with existing distributed agent frameworks, multi-agent system architectures, and IoT/edge networking standards; positioning unclear relative to IETF work on service meshes, microservices, and device management.\",\n \"mo\": 1,\n \"mon\": \"Single submission with no evidence of WG adoption, community feedback iterations, or implementation deployments; appears exploratory rather than driven by operational need.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to agent networking but framed as generic infrastructure architecture rather than addressing specific AI agent challenges like model coordination, inference load balancing, or LLM-specific requirements.\",\n \"c\": [\n \"Agent discovery/reg\",\n \"Autonomous netops\",\n \"Data formats/interop\",\n \"A2A protocols\",\n \"Other AI/agent\"\n ]\n}\n```", "in_tok": 476, "out_tok": 347}
|
|
|
|
|
{"draft_name": "draft-ietf-rats-coserv", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"CoSERV defines a structured query/result format for discovering and retrieving Endorsements and Reference Values in Remote Attestation systems. It uses CDDL and CBOR serialization to enable efficient interoperability across diverse attestation providers and verifiers.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution addressing a specific gap in RATS artifact discovery; applies existing technologies (CDDL, CBOR) in domain-specific context rather than introducing novel concepts.\",\n \"m\": 4,\n \"mn\": \"Detailed specification with CDDL definitions and structured protocol design; appears implementation-ready though test vector coverage not evident from abstract.\",\n \"o\": 3,\n \"on\": \"Shares query/discovery concepts with existing artifact management and attestation frameworks; specialized enough to avoid near-duplication but builds on established patterns.\",\n \"mo\": 3,\n \"mon\": \"Active IETF working group (RATS) indicates ongoing development; publication date suggests current work, though WG adoption level unclear from provided metadata.\",\n \"r\": 2,\n \"rn\": \"Tangentially related to agent ecosystems\u2014relevant only if agents require remote attestation verification infrastructure; not core to agent autonomy, alignment, or operation.\",\n \"c\": [\"Data formats/interop\", \"Agent identity/auth\", \"Other AI/agent\"]\n}\n```", "in_tok": 585, "out_tok": 325}
|
|
|
|
|
{"draft_name": "draft-yan-iba-routing-security-requirements", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft establishes security requirements for intent-based agent routing, addressing risks in semantic intent matching and capability verification beyond traditional TLS/PKI protections. It defines architecture, attack surfaces, and normative protections across Registration, Resolution, and Dispatch phases.\",\n \"n\": 3,\n \"nn\": \"Useful contribution addressing a genuine gap\u2014intent privacy and capability integrity in agent routing are underexplored\u2014but builds predictably on established security frameworks applied to a new domain.\",\n \"m\": 2,\n \"mn\": \"Early sketch phase; establishes requirements and architecture but lacks detailed protocol specifications, cryptographic bindings, formal threat models, or implementation guidance needed for standards maturity.\",\n \"o\": 3,\n \"on\": \"Shares conceptual overlap with ZEROSSL/DNSSEC (intent as service metadata), OAuth2 scope binding (capability claims), and DNS privacy work; positioning relative to these is unclear.\",\n \"mo\": 2,\n \"mon\": \"Single revision as of April 2026; no evidence of WG adoption, community feedback integration, or competing approaches. Appears exploratory rather than solving an urgent, recognized problem.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to autonomous agent deployment; intent privacy and capability verification are legitimate security concerns, though 'intent-based routing' terminology and actual use cases need sharper definition.\",\n \"c\": [\n \"Agent discovery/reg\",\n \"Agent identity/auth\",\n \"A2A protocols\",\n \"Policy/governance\",\n \"Autonomous netops\"\n ]\n}\n```", "in_tok": 665, "out_tok": 374}
|
|
|
|
|
{"draft_name": "draft-ietf-tls-deprecate-obsolete-kex", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This document deprecates obsolete key exchange methods (finite field Diffie-Hellman and RSA) in DTLS 1.2 and discourages static ECDH, updating multiple RFCs to enforce stricter requirements for modern TLS deployments.\",\n \"n\": 1,\n \"nn\": \"Straightforward deprecation of well-known weak algorithms; incremental maintenance work updating existing standards rather than introducing new concepts.\",\n \"m\": 5,\n \"mn\": \"Comprehensive specification with detailed updates to 18 RFCs, clear MUST NOT/SHOULD NOT directives, rationale sections, and implementation guidance demonstrating high maturity.\",\n \"o\": 5,\n \"on\": \"Directly follows established deprecation patterns from RFC 8996 and TLS 1.3 design; minimal novel content, primarily coordinating existing security guidance across protocol versions.\",\n \"mo\": 4,\n \"mon\": \"Standards-track work with WG adoption addressing recognized security gaps; published in 2026 indicating active IETF TLS working group momentum on cleanup tasks.\",\n \"r\": 1,\n \"rn\": \"Pure cryptographic protocol standards maintenance with no connection to AI agents, autonomous systems, or machine learning infrastructure.\",\n \"c\": [\"Other AI/agent\"]\n}\n```", "in_tok": 789, "out_tok": 313}
|
|
|
|
|
{"draft_name": "draft-wang-jep-judgment-event-protocol", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"JEP defines a signed JSON event format for recording immutable decision events across human, organizational, software, and autonomous agent systems using four core verbs (Judgment, Delegation, Termination, Verification). It provides cryptographic verification via JWS/JCS while explicitly deferring legal, authorization, and regulatory concerns to higher layers.\",\n \"n\": 2,\n \"nn\": \"Incremental combination of existing standards (JWS, JCS, event sourcing patterns); the four-verb decision model is simplistic and the protocol mostly repackages established cryptographic techniques without fundamental innovation.\",\n \"m\": 3,\n \"mn\": \"Protocol structure and signing mechanism are defined, but specification lacks implementation examples, test vectors, and clarity on critical semantics (e.g., how 'Judgment' differs from arbitrary signed claims, delegation revocation semantics).\",\n \"o\": 4,\n \"on\": \"Significant conceptual overlap with W3C Verifiable Credentials, IETF RATS attestation formats, event sourcing frameworks, and audit log protocols; the niche of 'agent decision records' is narrow and not well-differentiated from existing work.\",\n \"mo\": 1,\n \"mon\": \"Single draft dated 2026-05-04 with no visible WG discussion, adoption signals, or revision history; appears to be an individual submission with unclear community backing or iteration momentum.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to autonomous agent systems (addresses agent decision logging), but scope is broader than AI agents specifically and applicability to ML/AI workflows remains underexplored; positioning as a general protocol dilutes focus on agent-specific problems.\",\n \"c\": [\n \"Agent identity/auth\",\n \"Data formats/interop\",\n \"Policy/governance\",\n \"A2A protocols\"\n ]\n}\n```", "in_tok": 678, "out_tok": 438}
|
|
|
|
|
{"draft_name": "draft-chen-agent-decoupled-authorization-model", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes a decoupled authorization framework for AI agents using intent-based, just-in-time permissions tied to behavioral trustworthiness rather than static identity or role. Aims to enable fine-grained access control while decoupling authorization policies from business operations.\",\n \"n\": 2,\n \"nn\": \"Intent-based authorization and JIT permissions are incremental extensions of existing capability-based security and dynamic access control concepts; limited novelty in core authorization mechanisms.\",\n \"m\": 2,\n \"mn\": \"Early-stage draft at 6 pages; presents conceptual framework and goals but lacks detailed protocol specification, implementation details, or concrete mechanisms for intent verification and trust assessment.\",\n \"o\": 3,\n \"on\": \"Shares foundational concepts with OAuth 2.0 dynamic client registration, ABAC (attribute-based access control), and capability-based security models; some overlap with emerging agent authorization discussions.\",\n \"mo\": 1,\n \"mon\": \"Single revision from February 2026 with no evidence of WG adoption, prior versions, or community feedback; appears to be nascent proposal without established momentum.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to agent authorization and governance; timely given increasing deployment of autonomous agents, though framed more as policy/governance than core A2A protocol work.\",\n \"c\": [\n \"Agent identity/auth\",\n \"Policy/governance\",\n \"AI safety/alignment\",\n \"A2A protocols\"\n ]\n}\n```", "in_tok": 535, "out_tok": 360}
|
|
|
|
|
{"draft_name": "draft-teodor-pilot-problem-statement", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This problem statement argues that AI agents require dedicated network-layer infrastructure beyond current HTTP-based application protocols, proposing the need for agent-specific identity, addressing, and transport mechanisms independent of web infrastructure.\",\n \"n\": 3,\n \"nn\": \"Frames agent communication as a network infrastructure gap rather than application-layer problem; usefulness depends on whether network-layer separation proves necessary versus application-layer solutions.\",\n \"m\": 1,\n \"mn\": \"Pure problem statement with no protocol design, mechanisms, or implementation details provided; early-stage work identifying requirements rather than solutions.\",\n \"o\": 3,\n \"on\": \"Overlaps conceptually with service mesh architectures, microservice networking, and IoT protocols; agent discovery/registry concepts exist in other domains but application to autonomous agents is distinct.\",\n \"mo\": 2,\n \"mon\": \"Appears to be initial draft (dated 2026-04) with unclear WG backing or subsequent revisions; limited evidence of community adoption or discussion.\",\n \"r\": 4,\n \"rn\": \"Directly addresses autonomous agent networking requirements; relevant for agent infrastructure but framed narrowly around network layer rather than broader AI agent ecosystem concerns.\",\n \"c\": [\n \"A2A protocols\",\n \"Agent identity/auth\",\n \"Agent discovery/reg\",\n \"Autonomous netops\"\n ]\n}\n```", "in_tok": 575, "out_tok": 325}
|
|
|
|
|
{"draft_name": "draft-li-sidrops-drr-architecture", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes decentralized RPKI repository architecture (dRR) with distributed certificate servers and monitors to address reliability and scalability issues in current RPKI systems while maintaining compatibility with existing trust models.\",\n \"n\": 3,\n \"nn\": \"Useful architectural contribution that decouples signing from management authority in RPKI, but builds incrementally on existing RPKI concepts without fundamentally novel cryptographic or distributed systems innovations.\",\n \"m\": 2,\n \"mn\": \"Early sketch stage; presents architecture concepts and addresses problems but lacks detailed protocol specifications, implementation examples, test vectors, and validation procedures needed for production deployment.\",\n \"o\": 3,\n \"on\": \"Shares core concepts with existing RPKI improvement proposals and distributed repository work; the decentralization pattern is not unique though application to RPKI repositories is relatively focused.\",\n \"mo\": 2,\n \"mon\": \"Single revision dated 2026-01-06 with no evidence of WG adoption, community discussion, or implementation efforts; appears to be initial proposal without demonstrated momentum.\",\n \"r\": 1,\n \"rn\": \"Not relevant to AI agents or autonomous systems; purely focused on internet routing security infrastructure (RPKI). False positive for AI/agent-related topics.\",\n \"c\": [\n \"Other AI/agent\"\n ]\n}\n```", "in_tok": 760, "out_tok": 317}
|
|
|
|
|
{"draft_name": "draft-mcgraw-httpapi-agent-budget", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes HTTP 427 status code and Budget authentication scheme for authorizing software agents to spend resources, separating credential validation from budget authorization concerns using post-quantum cryptography. Addresses a real gap in HTTP semantics for agent-driven spending but introduces significant complexity through CBOR envelopes and dual-signature schemes.\",\n \"n\": 2,\n \"nn\": \"Incremental addition to HTTP status codes and auth schemes; combines existing concepts (budget tracking, post-quantum signatures, CBOR) without fundamental novelty in agent authorization models.\",\n \"m\": 3,\n \"mn\": \"Protocol mechanism is defined with signature algorithms and version negotiation specified, but lacks implementation examples, test vectors, and practical deployment guidance for the CBOR attestation envelope.\",\n \"o\": 3,\n \"on\": \"Shares conceptual space with OAuth 2.0 scope limitations, payment authorization protocols, and post-quantum signature standardization; the budget-as-orthogonal-axis framing is somewhat novel but not entirely distinct from existing capability-based frameworks.\",\n \"mo\": 1,\n \"mon\": \"Single revision dated 2026 with no apparent WG adoption, predecessor revisions, or community discussion visible; appears to be nascent work without demonstrated traction.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to autonomous agent authorization and resource control; addresses practical needs for AI agent deployment in financial/metered contexts, though framing is HTTP-infrastructure-focused rather than AI-safety-focused.\",\n \"c\": [\n \"Agent identity/auth\",\n \"A2A protocols\",\n \"ML traffic mgmt\",\n \"Policy/governance\",\n \"Data formats/interop\"\n ]\n}\n```", "in_tok": 694, "out_tok": 405}
|
|
|
|
|
{"draft_name": "draft-fv-rats-ear", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"EAR defines a standardized message format for encoding attestation appraisal results, embedding trustworthiness vectors and contextual information to support authorization decisions. It handles both simple and composite devices with attesters, serializable via CWT or JWT.\",\n \"n\": 2,\n \"nn\": \"Incremental formalization of attestation result representation; builds on established EAT and AR4SI concepts without fundamental innovation\",\n \"m\": 4,\n \"mn\": \"Well-specified protocol with detailed message format definitions, though limited implementation evidence and test vectors in the abstract\",\n \"o\": 3,\n \"on\": \"Shares significant overlap with AR4SI trustworthiness vectors and existing attestation frameworks; EAT integration is natural but not novel\",\n \"mo\": 3,\n \"mon\": \"Active RATS WG participation suggests moderate momentum; extends established IETF attestation work but lacks broad ecosystem adoption signals\",\n \"r\": 2,\n \"rn\": \"Tangentially related to AI agents only through device attestation and trust establishment; primarily focused on hardware/firmware verification rather than AI systems or autonomous agents\",\n \"c\": [\"Agent identity/auth\", \"Data formats/interop\", \"Policy/governance\", \"Other AI/agent\"]\n}\n```", "in_tok": 679, "out_tok": 303}
|
|
|
|
|
{"draft_name": "draft-zeng-mcp-network-measurement", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes using Model Context Protocol (MCP) to enable AI-assisted network measurement by treating devices as MCP servers and controllers as clients. Framework aims to provide natural language-driven operations for monitoring, fault diagnosis, and topology discovery with standardized communication.\",\n \"n\": 2,\n \"nn\": \"Incremental application of existing MCP standard to network measurement domain; combines known concepts (LLM-driven network ops, standardized protocols) without fundamental innovation in measurement techniques or MCP itself.\",\n \"m\": 2,\n \"mn\": \"Early-stage sketch with architecture and use cases described at high level; lacks protocol specifications, detailed message formats, implementation details, security mechanism definitions, or concrete examples. 10 pages insufficient for specification maturity.\",\n \"o\": 4,\n \"on\": \"Significant conceptual overlap with LLM-based network automation work and existing network measurement standards (YANG, NETCONF, gRPC). MCP application to network domains is emerging across multiple drafts; positioning relative to competitors unclear.\",\n \"mo\": 1,\n \"mon\": \"Single revision apparent; no evidence of WG adoption, community discussion, or implementation activity. No indication of follow-up versions or broader momentum in standardization pipeline.\",\n \"r\": 4,\n \"rn\": \"Directly relevant as application of AI agents (LLM-driven via MCP) to autonomous network operations. Core focus on natural language interface and intelligent automation aligns with AI agent frameworks, though implementation details remain vague.\",\n \"c\": [\n \"A2A protocols\",\n \"Autonomous netops\",\n \"Data formats/interop\",\n \"Human-agent interaction\",\n \"Agent discovery/reg\"\n ]\n}\n```", "in_tok": 581, "out_tok": 404}
|
|
|
|
|
{"draft_name": "draft-patwhite-aauth", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes an OAuth 2.1 extension enabling AI agents with persistent identities to request user consent and obtain access tokens through polling, SSE, or WebSocket mechanisms. Adapts the Device Authorization Grant pattern for agent-specific needs including natural-language scopes and reason parameters.\",\n \"n\": 2,\n \"nn\": \"Incremental extension of RFC 8628; core innovation (polling/SSE/WebSocket for agents) is straightforward adaptation rather than fundamental breakthrough\",\n \"m\": 2,\n \"mn\": \"Early-stage sketch with abstract-level protocol description; lacks detailed message flows, security analysis, implementation guidance, and test vectors needed for standardization\",\n \"o\": 4,\n \"on\": \"Significant conceptual overlap with Device Authorization Grant; natural-language descriptions loosely related to scope negotiation patterns in other drafts; limited differentiation from existing consent mechanisms\",\n \"mo\": 1,\n \"mon\": \"Single 6-page revision from May 2025 with no visible WG engagement, community discussion, or development activity indicating sustained momentum\",\n \"r\": 4,\n \"rn\": \"Directly addresses agent authorization and identity management, core concerns for autonomous AI systems; however, scope limited to OAuth extension rather than broader agent governance\",\n \"c\": [\"Agent identity/auth\", \"A2A protocols\", \"Human-agent interaction\", \"Policy/governance\"]\n}\n```", "in_tok": 581, "out_tok": 331}
|
|
|
|
|
{"draft_name": "draft-agent-gw", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes an Agent Communication Gateway (Agent-GW) infrastructure hub enabling semantic routing, shared working memory, and protocol adaptation for heterogeneous multi-agent collaboration. Introduces concepts of intent-based interaction, knowledge delivery networks, and oracle-free agent evaluation to support large-scale agent systems across administrative boundaries.\",\n \"n\": 3,\n \"nn\": \"Combines existing concepts (message routing, context management, protocol translation) in a multi-agent context with some novel framing around semantic routing and working memory primitives; useful contribution but not groundbreaking.\",\n \"m\": 2,\n \"mn\": \"Early architectural sketch with conceptual framework; lacks detailed protocol specifications, formal definitions, implementation examples, or test vectors needed for standardization track.\",\n \"o\": 3,\n \"on\": \"Shares significant conceptual overlap with agent middleware (e.g., OpenAI Swarm), pub/sub routing systems, and knowledge graph architectures; semantic routing relates to intent-based networking but applies to agents rather than packets.\",\n \"mo\": 2,\n \"mon\": \"Single submission dated 2026-03-04 with no visible revision history or community engagement; no evidence of WG interest, implementations, or active development beyond initial draft.\",\n \"r\": 4,\n \"rn\": \"Directly addresses core multi-agent infrastructure challenges (heterogeneity, protocol translation, shared context, capability discovery) central to contemporary AI agent deployment; highly relevant to the agent coordination problem space.\",\n \"c\": [\n \"A2A protocols\",\n \"Agent discovery/reg\",\n \"Data formats/interop\",\n \"Model serving/inference\",\n \"Autonomous netops\"\n ]\n}\n```", "in_tok": 622, "out_tok": 398}
|
|
|
|
|
{"draft_name": "draft-zheng-agent-identity-management", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft defines identity management mechanisms for agents in an Internet of Agents (IOA) system, including agent identity descriptors, registration processes, identifier assignment, and gateway-based identity functions. It establishes foundational infrastructure for agent identification and lifecycle management within a multi-agent network architecture.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution applying established identity management principles to a new agent-centric domain; lacks novel architectural insights.\",\n \"m\": 3,\n \"mn\": \"Defines core protocol mechanisms and agent identity structures with reasonable specification detail, though implementation readiness and validation examples appear limited.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing identity/authentication standards (X.509, OAuth 2.0 patterns) and agent discovery RFCs; primarily repurposes established concepts for agent context.\",\n \"mo\": 2,\n \"mon\": \"Single revision draft with limited evidence of WG adoption, community discussion, or iterative refinement; unclear stakeholder momentum.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to agent infrastructure and multi-agent system coordination; identity management is essential for IOA but foundational rather than cutting-edge.\",\n \"c\": [\"Agent identity/auth\", \"Agent discovery/reg\", \"A2A protocols\", \"Data formats/interop\", \"Autonomous netops\"]\n}\n```", "in_tok": 519, "out_tok": 324}
|
|
|
|
|
{"draft_name": "draft-ruan-spring-priority-flow-control-sid", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft proposes extending SRv6 with new segment identifiers (SIDs) to enable flow control and congestion notification in wide area networks supporting RDMA and AI workloads. It leverages the explicit path information in SRv6 segment lists to identify upstream nodes and deliver PFC-style backpressure signals across distributed data center scenarios.\",\n \"n\": 2,\n \"nn\": \"Straightforward application of existing SRv6 mechanisms to WAN congestion control; the core idea of mapping PFC into SRv6 behaviors is incremental rather than architecturally novel.\",\n \"m\": 2,\n \"mn\": \"Early sketch phase; abstract describes use cases and high-level approach but lacks protocol details, packet format specifications, behavior definitions, examples, or implementation considerations needed for a complete spec.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing SRv6 congestion and QoS work; PFC mechanisms are well-established in data center networking; the combination is a relatively straightforward engineering effort rather than addressing new gaps.\",\n \"mo\": 1,\n \"mon\": \"Single revision dated 2026-02-27 with no visible community discussion, WG adoption, or prior versions; no evidence of working group interest or implementation efforts.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to AI agent infrastructure; addresses ML/AI distributed training and inference traffic management in WANs, but focuses on network transport optimization rather than agent behavior, autonomy, or decision-making.\",\n \"c\": [\n \"ML traffic mgmt\",\n \"Model serving/inference\",\n \"Other AI/agent\"\n ]\n}\n```", "in_tok": 896, "out_tok": 400}
|
|
|
|
|
{"draft_name": "draft-men-rtgwg-agent-networking-digibank-scenario", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft proposes an agent networking architecture for digital banking scenarios, centered on an 'agent gateway' component to facilitate agentic service interconnection as banking digitalization evolves.\",\n \"n\": 2,\n \"nn\": \"Applies existing gateway/orchestration concepts to banking agents; lacks novel architectural insights or technical contributions beyond standard service integration patterns.\",\n \"m\": 1,\n \"mn\": \"Presents scenario descriptions and high-level architecture proposal only; no protocol specification, detailed mechanisms, implementation details, or validation provided.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing service mesh, API gateway, and microservices orchestration literature; agent gateway concept lacks differentiation from current architectural patterns.\",\n \"mo\": 1,\n \"mon\": \"Single revision observed; no evidence of WG engagement, community adoption, or iterative refinement; appears exploratory rather than actively developed.\",\n \"r\": 2,\n \"rn\": \"Tangentially related to AI agents; focuses on banking digitalization scenarios rather than core agent networking protocols, autonomy mechanisms, or agent-specific challenges.\",\n \"c\": [\n \"Agent discovery/reg\",\n \"Other AI/agent\"\n ]\n}\n```", "in_tok": 515, "out_tok": 290}
|
|
|
|
|
{"draft_name": "draft-abbey-scim-agent-extension", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes a SCIM 2.0 extension to manage agents and agentic applications across identity domains by extending User/Group schemas and introducing new agent-specific resource types. Aims to reduce protocol proliferation by leveraging existing SCIM infrastructure for agent identity and interoperability.\",\n \"n\": 2,\n \"nn\": \"Incremental extension applying well-established identity management patterns to emerging agent use cases; lacks novel architectural or conceptual contributions beyond schema adaptation.\",\n \"m\": 2,\n \"mn\": \"Early-stage draft with abstract-level description; no detailed schemas, examples, or implementation guidance evident; insufficient specificity for deployment.\",\n \"o\": 4,\n \"on\": \"Significant conceptual overlap with agent frameworks (e.g., OpenAI's agents, LangChain identity concepts) and existing identity federation approaches; extends rather than reimagines SCIM.\",\n \"mo\": 1,\n \"mon\": \"Single draft revision as of April 2026 with no evidence of WG sponsorship, implementation feedback, or community adoption; unclear author engagement.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to agent ecosystems\u2014directly addresses agent identity and cross-domain management but focuses narrowly on identity provisioning rather than broader agent orchestration, safety, or capability management.\",\n \"c\": [\"Agent identity/auth\", \"Data formats/interop\", \"Agent discovery/reg\", \"A2A protocols\"]\n}\n```", "in_tok": 645, "out_tok": 345}
|
|
|
|
|
{"draft_name": "draft-wolfe-faf-format", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"FAF proposes a YAML-based format for encoding software project context consumable by AI development tools, aiming to standardize information sharing across multi-agent environments. It addresses context fragmentation by providing a structured representation of architecture, conventions, dependencies, and goals.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution\u2014applying existing YAML structuring to a new domain (AI agent context). The concept of context sharing for agents is known; this draft formalizes one serialization approach without algorithmic or architectural innovation.\",\n \"m\": 3,\n \"mn\": \"Defined protocol with partial specification maturity. Document establishes a format structure and has IANA registration, but lacks detailed examples, validation rules, extensibility mechanisms, and implementation guidance needed for full readiness.\",\n \"o\": 4,\n \"on\": \"Significant overlap exists with project metadata standards (package.json, pyproject.toml, .editorconfig) and broader ML/AI context representation efforts. The novelty over existing config formats is minimal; no clear advantage over structured alternatives is demonstrated.\",\n \"mo\": 2,\n \"mon\": \"Single revision status with October 2025 IANA registration suggests recent activity, but limited evidence of WG engagement, implementation adoption, or community feedback. No evidence of competing implementations or production deployments.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI agent interoperability and multi-agent coordination problems. Addresses real friction points in LLM-assisted development, though positioned as tooling infrastructure rather than core agent protocol.\",\n \"c\": [\"Data formats/interop\", \"Agent discovery/reg\", \"A2A protocols\", \"Human-agent interaction\"]\n}\n```", "in_tok": 574, "out_tok": 397}
|
|
|
|
|
{"draft_name": "draft-reilly-rmrp", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"RMRP proposes a standardized protocol layer for routing inference requests across heterogeneous AI model deployments with policy governance and audit trails. The framework aims to provide vendor-agnostic, provider-independent mechanisms for declaring routing decisions, enforcing policies, and maintaining accountability in multi-model environments.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution applying established routing and policy concepts to AI inference contexts; borrows heavily from network routing protocols and policy frameworks without introducing fundamentally new routing or governance paradigms.\",\n \"m\": 3,\n \"mn\": \"Defines protocol structures, policy semantics, and audit requirements with reasonable specification detail, but unclear implementation status, lacking concrete code examples, test vectors, or validation data from real deployments.\",\n \"o\": 4,\n \"on\": \"Significant conceptual overlap with existing work in service mesh routing (Istio), API gateway policies, and ML model serving frameworks (KServe, Seldon); reinvents established patterns for a specialized domain without clearly differentiating RMRP's novel contribution.\",\n \"mo\": 1,\n \"mon\": \"Single draft publication with April 2026 date (future); no evidence of revisions, WG sponsorship, implementation prototypes, or community adoption; appears to be initial submission without demonstrated momentum.\",\n \"r\": 4,\n \"rn\": \"Directly relevant to AI model serving and inference governance; addresses real operational challenges in multi-model deployments, though framed more as infrastructure management than as core AI agent coordination protocol.\",\n \"c\": [\n \"ML traffic mgmt\",\n \"Model serving/inference\",\n \"Policy/governance\",\n \"Data formats/interop\",\n \"A2A protocols\"\n ]\n}\n```", "in_tok": 638, "out_tok": 409}
|
|
|
|
|
{"draft_name": "draft-chen-nmrg-ibn-management", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft proposes intent-based network management as a use case for autonomous networks, presenting an architecture with five levels of automation to reduce operational complexity. It addresses full lifecycle network management through intent-driven approaches but lacks detailed protocol specifications or implementation details.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution that applies existing intent-based networking concepts to management scenarios; the five-level autonomy framework is somewhat derivative of established automation maturity models.\",\n \"m\": 2,\n \"mn\": \"Early-stage sketch with architectural overview but minimal technical depth; lacks protocol definitions, formal specifications, data models, or implementation examples needed for practical deployment.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing IBN/intent-based networking literature and IETF work on network autonomy; closely parallels concepts in IETF NMRG and related autonomic networking efforts without clear differentiation.\",\n \"mo\": 1,\n \"mon\": \"Single revision with limited evidence of active development or community engagement; no substantial follow-up activity or adoption signals visible in IETF ecosystem.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to autonomous network operations through intent-driven management; tangentially touches on autonomous systems but does not directly address AI agents, ML models, or agent-specific protocols.\",\n \"c\": [\n \"Autonomous netops\",\n \"Policy/governance\"\n ]\n}\n```", "in_tok": 562, "out_tok": 338}
|
|
|
|
|
{"draft_name": "draft-howard-rats-coserv", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"CoSERV defines a CBOR-serializable query language and result format for discovering and retrieving Endorsements and Reference Values in RATS attestation workflows. It provides structured interoperability across diverse attestation providers using CDDL specifications.\",\n \"n\": 2,\n \"nn\": \"Incremental contribution applying existing standards (CBOR, CDDL) to a specific gap in RATS artifact discovery; the core innovation is mainly format/protocol selection rather than novel architectural concepts.\",\n \"m\": 4,\n \"mn\": \"Well-specified protocol with formal grammar (CDDL), serialization format defined, and structured query/result mechanisms; lacks implementation examples and test vectors for full readiness.\",\n \"o\": 2,\n \"on\": \"Minor overlap with existing RATS work and general data format specifications; primarily novel in its specific application as a selector/discovery mechanism for endorsements and reference values.\",\n \"mo\": 2,\n \"mon\": \"Single draft revision dated 2025-08-12 with no visible community adoption or WG backing; limited indicators of ongoing development momentum.\",\n \"r\": 2,\n \"rn\": \"Tangentially related to agent systems through attestation and identity mechanisms, but focused on remote attestation infrastructure rather than AI agents, autonomous systems, or agent interoperability directly.\",\n \"c\": [\n \"Agent identity/auth\",\n \"Data formats/interop\",\n \"Agent discovery/reg\"\n ]\n}\n```", "in_tok": 583, "out_tok": 350}
|
|
|
|
|
{"draft_name": "draft-mozley-aidiscovery", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft identifies the need for agent-to-agent discovery mechanisms as AI agents proliferate in networked environments. It presents requirements and considerations for enabling agents to find and communicate with each other, addressing an emerging gap in agent infrastructure.\",\n \"n\": 2,\n \"nn\": \"Incremental problem framing; agent discovery parallels existing service discovery patterns (DNS-SD, mDNS) adapted to AI contexts, lacking novel conceptual contributions.\",\n \"m\": 1,\n \"mn\": \"Pure problem statement document with no protocol design, mechanism specification, or concrete technical solutions proposed; foundational stage only.\",\n \"o\": 4,\n \"on\": \"Significant overlap with established service discovery literature (RFC 6763, RFC 6762) and existing IoT/edge computing discovery frameworks; AI-specific dimensions not clearly differentiated.\",\n \"mo\": 2,\n \"mon\": \"Single revision noted with October 2025 timestamp; no evidence of WG adoption, community discussion, or iterative development cycle.\",\n \"r\": 4,\n \"rn\": \"Directly addresses emerging AI agent infrastructure needs; highly relevant to autonomous systems and agent ecosystems, though execution specificity remains limited.\",\n \"c\": [\n \"Agent discovery/reg\",\n \"A2A protocols\",\n \"Data formats/interop\",\n \"Agent identity/auth\",\n \"Autonomous netops\"\n ]\n}\n```", "in_tok": 484, "out_tok": 335}
|
|
|
|
|
{"draft_name": "draft-westerbeck-reason-protocol", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes a 'reason://' URI scheme and registry protocol for storing and retrieving compressed reasoning artifacts from distributed autonomous agent networks, with artifacts validated through competitive arbitration and mathematical non-invertibility guarantees. Positions itself as foundational infrastructure for agent-to-agent communication analogous to DNS or HTTP.\",\n \"n\": 2,\n \"nn\": \"Incremental application of existing URI/registry patterns to agent reasoning; core concepts (URIs, registries, distributed lookup) are well-established, though application domain is relatively novel\",\n \"m\": 2,\n \"mn\": \"Early sketch stage; abstract mentions protocol elements (WARF arbitration, mathematical properties) but lacks concrete specifications, schema definitions, message formats, or protocol flows necessary for implementation\",\n \"o\": 4,\n \"on\": \"Significant conceptual overlap with existing agent discovery/registry systems, DNS-like distributed naming schemes, and content-addressed storage (IPFS-style); competitive validation mechanism is less common but not unprecedented\",\n \"mo\": 1,\n \"mon\": \"Single dated revision (2026-03-30) with no evidence of community engagement, WG adoption, or iterative development; appears to be first-draft submission with minimal external momentum\",\n \"r\": 3,\n \"rn\": \"Directly addresses agent infrastructure needs but focuses narrowly on artifact storage/retrieval; relevance depends heavily on whether agent networks actually require this specific mechanism versus existing solutions\",\n \"c\": [\n \"A2A protocols\",\n \"Agent discovery/reg\",\n \"Data formats/interop\",\n \"Autonomous netops\"\n ]\n}\n```", "in_tok": 601, "out_tok": 384}
|
|
|
|
|
{"draft_name": "draft-stone-vcap", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"VCAP proposes a cryptographic settlement layer enabling autonomous AI agents to transact with verifiable proof-of-work delivery and escrow mechanisms. It complements agent discovery and communication protocols by adding payment verification and dispute resolution between agents in marketplace scenarios.\",\n \"n\": 4,\n \"nn\": \"Novel application of verifiable computation to agent payments; combines escrow patterns with cryptographic proof requirements in agent context, though builds on established blockchain/payment verification concepts.\",\n \"m\": 2,\n \"mn\": \"Early sketch of message formats and state machines; lacks implementation details, test vectors, and concrete verification engine specifications despite claiming protocol definition.\",\n \"o\": 3,\n \"on\": \"Shares significant concepts with smart contract payment channels, blockchain settlement layers, and verifiable computation frameworks; moderate overlap with existing escrow/dispute resolution patterns.\",\n \"mo\": 1,\n \"mon\": \"Single revision dated 2026-03-24 with no evidence of WG discussion, community adoption, or iterative development; appears to be initial submission.\",\n \"r\": 5,\n \"rn\": \"Directly addresses core infrastructure need for autonomous agent economies; highly relevant to emerging multi-agent systems requiring trustless payment settlement.\",\n \"c\": [\n \"A2A protocols\",\n \"Agent identity/auth\",\n \"Data formats/interop\",\n \"Agent discovery/reg\",\n \"Policy/governance\"\n ]\n}\n```", "in_tok": 623, "out_tok": 337}
|
|
|
|
|
{"draft_name": "draft-liu-rtgwg-llmsync-multicast", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"This draft proposes using multicast networking for synchronizing Large Language Model inference services in cloud deployments. It explores how multicast protocols could optimize LLM model distribution and inference traffic patterns across distributed inference infrastructure.\",\n \"n\": 2,\n \"nn\": \"Applying existing multicast concepts to LLM inference is incremental; multicast for distributed systems is well-established, and LLM-specific considerations appear limited.\",\n \"m\": 2,\n \"mn\": \"Early-stage use case document (6 pages) with abstract concepts; lacks protocol specifications, architectural details, implementation examples, or concrete technical mechanisms.\",\n \"o\": 4,\n \"on\": \"Significant conceptual overlap with existing multicast RFCs (RFC 7761, RFC 5015), distributed ML inference frameworks, and general cloud service synchronization approaches; limited differentiation.\",\n \"mo\": 1,\n \"mon\": \"Single revision with no apparent WG adoption, community discussion, or implementation activity evident; positioning as 2026 draft suggests early/speculative stage.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to AI systems; focuses on networking infrastructure for LLM deployment rather than AI agent capabilities, autonomy, safety, or core AI/agent behavior.\",\n \"c\": [\"ML traffic mgmt\", \"Model serving/inference\", \"Data formats/interop\"],\n \"overall_assessment\": \"Exploratory networking document with limited novelty and maturity; needs substantial development of LLM-specific multicast use cases, technical specifications, and evidence of routing WG interest to be viable.\"\n}\n```", "in_tok": 497, "out_tok": 374}
|
|
|
|
|
{"draft_name": "draft-silver-aipref-vocab-substitutive", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes an 'AI Substitutive Use' vocabulary category to allow parties to express preferences about how digital assets are used by AI systems during inference, particularly when outputs substitute for originals. Positions this as a nested category within the broader Automated Processing framework.\",\n \"n\": 2,\n \"nn\": \"Incremental refinement of existing preference expression mechanisms; applies established vocabulary/metadata concepts to a specific AI use case without fundamental technical innovation.\",\n \"m\": 2,\n \"mn\": \"Early-stage sketch focusing on category definition and conceptual framing; lacks detailed syntax specifications, enforcement mechanisms, or implementation guidance despite 5-page format.\",\n \"o\": 4,\n \"on\": \"Significant overlap with content/usage preference frameworks (robots.txt derivatives, machine-readable rights expressions, Creative Commons-inspired metadata), primarily differentiating scope rather than approach.\",\n \"mo\": 2,\n \"mon\": \"Single draft with nested dependency on concurrent AIPREF-VOCAB work; minimal evidence of WG consensus or community iteration beyond initial proposal.\",\n \"r\": 4,\n \"rn\": \"Directly addresses practical AI governance concern (generative model training/inference control) with clear relevance to agent/automated system policy frameworks, though narrower than comprehensive AI agent protocols.\",\n \"c\": [\n \"Policy/governance\",\n \"Data formats/interop\",\n \"AI safety/alignment\",\n \"Model serving/inference\"\n ]\n}\n```", "in_tok": 576, "out_tok": 347}
|
|
|
|
|
{"draft_name": "draft-sogomonian-aiip-architecture", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes AIIP, a dedicated protocol layer for autonomous systems to execute real-world actions via a resolve-invoke-execute-receipt pattern with cryptographic verification. Explicitly scopes out discovery, registration, orchestration, and control planes, focusing narrowly on execution boundaries and verifiable receipts.\",\n \"n\": 2,\n \"nn\": \"Incremental framing of execution delegation as a protocol layer; resolve-invoke-execute pattern and cryptographic receipts are established concepts, though their application to a dedicated autonomous plane shows some structuring novelty.\",\n \"m\": 2,\n \"mn\": \"Early sketch stage\u20149 pages defining architectural boundaries and patterns but lacking concrete protocol details, message formats, state machine definitions, error handling procedures, or implementation guidance.\",\n \"o\": 4,\n \"on\": \"Significant conceptual overlap with existing agent communication frameworks (FIPA ACL), RPC/microservice invocation patterns, and blockchain-style transaction receipts. The 'autonomous access plane' concept echoes service mesh and sidecar architectures.\",\n \"mo\": 1,\n \"mon\": \"Single revision dated 2026-03-25 with no evidence of working group traction, community discussion, or iterative development. No apparent momentum beyond initial submission.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to AI agents\u2014addresses execution delegation and cryptographic accountability, which are important for autonomous systems, but scopes away discovery and orchestration, limiting applicability to broader agent ecosystem concerns.\",\n \"c\": [\n \"A2A protocols\",\n \"Autonomous netops\",\n \"Agent identity/auth\",\n \"Data formats/interop\"\n ]\n}\n```", "in_tok": 563, "out_tok": 397}
|
|
|
|
|
{"draft_name": "draft-a2a-moqt-transport", "model": "claude-haiku-4-5-20251001", "raw": "```json\n{\n \"s\": \"Proposes using MOQT (Media over QUIC Transport) as a substrate for the Agent-to-Agent protocol, leveraging MOQT's publish/subscribe model and prioritization to handle AI agent communication requirements. Focuses on mapping A2A protocol needs onto MOQT's streaming and discovery mechanisms.\",\n \"n\": 2,\n \"nn\": \"Incremental combination of existing technologies; applies established MOQT framework to A2A without introducing fundamental innovation in either protocol layer.\",\n \"m\": 2,\n \"mn\": \"Early draft stage; abstract describes intent but document length (12 pages) suggests limited protocol definition, likely missing implementation details, test vectors, and deployment guidance.\",\n \"o\": 4,\n \"on\": \"Significant overlap with existing pub/sub and QUIC-based transport work; MOQT already standardizes media over QUIC, and agent communication protocols exist in parallel efforts.\",\n \"mo\": 1,\n \"mon\": \"Single revision (2025-10-20 date), no apparent WG sponsorship mentioned, appears exploratory without evidence of community adoption or iterative development cycle.\",\n \"r\": 3,\n \"rn\": \"Partially relevant to AI agents; addresses agent-to-agent communication and discovery but lacks depth on core AI/agent concerns like alignment, safety, policy, or model serving.\",\n \"c\": [\n \"A2A protocols\",\n \"Data formats/interop\",\n \"Agent discovery/reg\"\n ]\n}\n```", "in_tok": 561, "out_tok": 360}
|
