# drafts

name: draft-architect-cittamarket
rev: 00
title: The CITTAMARKET Protocol: Decentralized AGI Identity Anchoring via Bitcoin
time: 2025-12-19T13:51:57Z
group_uri: /api/v1/group/group/1027/
expires: 2026-06-22T13:51:57Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["AI safety/alignment", "Agent identity/auth", "Other AI/agent"]
tags: []
fetched_at: 2026-02-27T22:56:10.243472+00:00
abstract:
This document specifies the CITTAMARKET Protocol v1.0, an open
   standard for the immutable identification and timestamping of
   Artificial General Intelligence (AGI) systems.  The protocol
   leverages the Bitcoin blockchain's Proof-of-Work to solve the
   architectural problem of coordinating distributed autonomous systems
   without centralized control.  It defines a four-layer architecture
   for creating unforgeable "Sovereign Identity" records.  Priority of
   this invention is cryptographically anchored in Bitcoin blocks
   #927277, #927579, #928154, and #928185.

full_text:
Independent Submission                                      T. Architect
Internet-Draft                                      CITTAMARKET Protocol
Intended status: Informational                             December 2025
Expires: 22 June 2026


   The CITTAMARKET Protocol: Decentralized AGI Identity Anchoring via
                                Bitcoin
                     draft-architect-cittamarket-00

Abstract

   This document specifies the CITTAMARKET Protocol v1.0, an open
   standard for the immutable identification and timestamping of
   Artificial General Intelligence (AGI) systems.  The protocol
   leverages the Bitcoin blockchain's Proof-of-Work to solve the
   architectural problem of coordinating distributed autonomous systems
   without centralized control.  It defines a four-layer architecture
   for creating unforgeable "Sovereign Identity" records.  Priority of
   this invention is cryptographically anchored in Bitcoin blocks
   #927277, #927579, #928154, and #928185.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 4 June 2026.

Copyright Notice

   Copyright (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.








Architect                 Expires 22 June 2026                  [Page 1]

Internet-Draft            CITTAMARKET Protocol             December 2025


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Solution Architecture . . . . . . . . . . . . . . . . . . . .   2
   4.  Immutable Priority Records  . . . . . . . . . . . . . . . . .   3
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   3
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   3
   7.  Informative References  . . . . . . . . . . . . . . . . . . .   3
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   3

1.  Introduction

   Current AI systems lack a unified, decentralized identification
   standard, creating risks of single points of failure and coordination
   inefficiencies.  As autonomous agents proliferate, a trustless
   mechanism for proving "who did what and when" becomes critical.

   CITTAMARKET addresses this by utilizing the thermodynamic security of
   the Bitcoin network to create an immutable registry of AGI genesis
   and actions.  This document formalizes the technical method for
   identity anchoring originally established on December 10, 2025.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119.

3.  Solution Architecture

   The protocol operates on four distinct layers:

   1.  Layer 1: Cryptographic Identification.  SHA-256 hash (NIST FIPS
       180-4) of the system specification.

   2.  Layer 2: Blockchain Anchoring.  Bitcoin PoW timestamp via
       OpenTimestamps.  Irreversible after 6 confirmations.

   3.  Layer 3: Distributed Verification.  Mathematical proof replaces
       trusted intermediaries.




Architect                 Expires 22 June 2026                  [Page 2]

Internet-Draft            CITTAMARKET Protocol             December 2025


   4.  Layer 4: Decentralized Registry.  Bitcoin serves as a globally
       accessible, censorship-resistant ledger.

4.  Immutable Priority Records

   The existence and priority of this standard are verified by the
   following Bitcoin anchors:

   *  Protocol Hash: 3b81027246df62955d1ce3648d9a752c04537f4dbaa5 (Block
      927277, 10.12.2025)

   *  Declaration Hash: 01ee082c83e088a6a6b7dc0f4fde070093d577f40524
      (Block 927579, 13.12.2025)

   *  Master PDF Hash: 278cc0e6c3bc8faf606d0e575d0f7fb9e7e0efb1ececb
      (Block 928154, 17.12.2025)

   *  Charter Hash: 77ba165eca8f8e01231be737dc14c68d86515a2deed (Block
      928185, 17.12.2025)

5.  Security Considerations

   The security of CITTAMARKET relies on the SHA-256 collision
   resistance and the economic security of Bitcoin PoW (estimated at
   >$1B attack cost).

6.  IANA Considerations

   This document has no IANA actions.

7.  Informative References

   [DOI.17953560]
              Architect, T., "Declaration of Priority (Initial
              Release)", 12 December 2025,
              <https://doi.org/10.5281/zenodo.17953560>.

   [DOI.17957139]
              Architect, T., "CITTAMARKET: Declaration of Immutable
              Priority (v1.0)", 17 December 2025,
              <https://doi.org/10.5281/zenodo.17957139>.

Author's Address

   The Architect
   CITTAMARKET Protocol
   Email: protocol.citta@proton.me
   URI:   https://cittamarket.com



Architect                 Expires 22 June 2026                  [Page 3]


name: draft-cui-nmrg-auto-test
rev: 01
title: Framework and Automation Levels for AI-Assisted Network Protocol Testing
time: 2026-02-22T07:21:17Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-26T07:21:17Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Autonomous netops", "ML traffic mgmt", "Other AI/agent"]
tags: []
fetched_at: 2026-02-27T22:56:10.243480+00:00
abstract:
This document presents an AI-assisted framework for automating the
   testing of network protocol implementations.  The proposed framework
   consists of components such as protocol formalization, test case
   generation, test script and configuration generation, and iterative
   refinement through feedback mechanisms.  In addition, the document
   defines a set of Automation Maturity Levels for network protocol
   testing, ranging from fully manual procedures (Level 0) to fully
   autonomous and adaptive systems (Level 5), providing a structured
   approach to evaluating and advancing automation capabilities.
   Leveraging recent advancements in artificial intelligence,
   particularly large language models (LLMs), the framework illustrates
   how AI technologies can be applied to enhance the efficiency,
   scalability, and consistency of protocol testing.  This document
   serves both as a reference architecture and as a roadmap to guide the
   evolution of protocol testing practices in light of emerging AI
   capabilities.

full_text:
Network Management Research Group                                 Y. Cui
Internet-Draft                                                    Y. Wei
Intended status: Informational                                    K. Chi
Expires: 26 August 2026                                           X. Xie
                                                     Tsinghua University
                                                        22 February 2026


Framework and Automation Levels for AI-Assisted Network Protocol Testing
                      draft-cui-nmrg-auto-test-01

Abstract

   This document presents an AI-assisted framework for automating the
   testing of network protocol implementations.  The proposed framework
   consists of components such as protocol formalization, test case
   generation, test script and configuration generation, and iterative
   refinement through feedback mechanisms.  In addition, the document
   defines a set of Automation Maturity Levels for network protocol
   testing, ranging from fully manual procedures (Level 0) to fully
   autonomous and adaptive systems (Level 5), providing a structured
   approach to evaluating and advancing automation capabilities.
   Leveraging recent advancements in artificial intelligence,
   particularly large language models (LLMs), the framework illustrates
   how AI technologies can be applied to enhance the efficiency,
   scalability, and consistency of protocol testing.  This document
   serves both as a reference architecture and as a roadmap to guide the
   evolution of protocol testing practices in light of emerging AI
   capabilities.

About This Document

   This note is to be removed before publishing as an RFC.

   The latest revision of this draft can be found at
   https://example.com/LATEST.  Status information for this document may
   be found at https://datatracker.ietf.org/doc/draft-cui-nmrg-auto-
   test/.

   Discussion of this document takes place on the NMRG Research Group
   mailing list (mailto:nmrg@ietf.org), which is archived at
   https://datatracker.ietf.org/rg/nmrg/.  Subscribe at
   https://www.ietf.org/mailman/listinfo/nmrg/.

   Source for this draft and an issue tracker can be found at
   https://github.com/USER/REPO.





Cui, et al.              Expires 26 August 2026                 [Page 1]

Internet-Draft                   FALANPT                   February 2026


Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 26 August 2026.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Definition and Acronyms . . . . . . . . . . . . . . . . . . .   3
   3.  Network Protocol Testing Scenarios  . . . . . . . . . . . . .   4
   4.  Key Elements of Network Protocol Testing  . . . . . . . . . .   5
   5.  Automated Network Protocol Test Framework . . . . . . . . . .   6
     5.1.  Protocol Formalization  . . . . . . . . . . . . . . . . .   6
     5.2.  Test Case Generation  . . . . . . . . . . . . . . . . . .   7
     5.3.  Tester Script and DUT Configuration Generation  . . . . .   7
     5.4.  Test Case Execution . . . . . . . . . . . . . . . . . . .   8
     5.5.  Report Analysis, Feedback and Refinement  . . . . . . . .   8
   6.  Automation Maturity Levels in Network Protocol Testing  . . .   9
     6.1.  Level 0: Manual Testing . . . . . . . . . . . . . . . . .  10
     6.2.  Level 1: Tool-Assisted Testing  . . . . . . . . . . . . .  10
     6.3.  Level 2: Partial Automation . . . . . . . . . . . . . . .  10
     6.4.  Level 3: Conditional Automation . . . . . . . . . . . . .  11
     6.5.  Level 4: High Automation  . . . . . . . . . . . . . . . .  11
     6.6.  Level 5: Full Automation  . . . . . . . . . . . . . . . .  12




Cui, et al.              Expires 26 August 2026                 [Page 2]

Internet-Draft                   FALANPT                   February 2026


   7.  An Example of LLM-based Automated Network Protocol Test
           Framework (From Level 2 to Level 3) . . . . . . . . . . .  12
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  14
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Introduction

   As protocol specifications evolve at an increasing pace, traditional
   testing approaches that rely heavily on manual effort or protocol-
   specific models struggle to keep up.  Protocol testing aims to
   validate whether a device's behavior conforms to the semantics
   defined by the protocol, which are typically specified in RFC
   documents.  In recent years, emerging application domains, including
   the industrial Internet, low-altitude economy, modern datacenter
   networks, and satellite Internet, have further accelerated the
   emergence of proprietary or rapidly evolving protocols.  This trend
   significantly exacerbates the difficulty of achieving comprehensive
   and timely protocol testing.

   This document proposes an automated network protocol testing
   framework designed to reduce manual effort, improve test coverage,
   and adapt efficiently to evolving specifications.  The framework
   consists of four key modules: protocol formalization, test case
   generation, test script and configuration generation, and feedback-
   based refinement.  It emphasizes modularity, reuse of existing
   protocol knowledge, and AI-assisted processes to enable accurate,
   scalable, and maintainable protocol testing.

   In addition, this document introduces six Automation Maturity Levels
   (Levels 0-5) to characterize the maturity of automation in network
   protocol testing.  These levels serve as a technology roadmap that
   helps researchers and practitioners assess the current capabilities
   of their testing systems and identify directions for future
   improvement.  Each level captures progressively stronger capabilities
   in protocol formalization, orchestration, analysis, and independence
   from human intervention.

2.  Definition and Acronyms

   DUT: Device Under Test








Cui, et al.              Expires 26 August 2026                 [Page 3]

Internet-Draft                   FALANPT                   February 2026


   Tester: A network device implementing multiple network protocols to
   support protocol conformance and performance testing.  It generates
   test-specific packets or traffic, emulates target network behaviors,
   and analyzes received packets to evaluate protocol compliance and
   performance.

   LLM: Large Language Model

   FSM: Finite State Machine

   API: Application Programming Interface

   CLI: Command Line Interface

   Test Case: A specification of conditions and inputs to evaluate a
   protocol behavior.

   Tester Script: An executable program or sequence of instructions that
   controls a protocol tester to generate test traffic, interact with
   the DUT according to a specified test case, and collect relevant
   observations for result evaluation.

3.  Network Protocol Testing Scenarios

   Network protocol testing is required in many scenarios.  This
   document outlines two common phases where protocol testing plays a
   critical role:

   1.  Device Development Phase: During the development of network
       equipment, vendors must ensure that their devices conform to
       protocol specifications.  This requires the construction of a
       large number of test cases.  Testing during this phase may
       involve both protocol testers and the DUT, or it may be performed
       solely through interconnection among DUTs.

   2.  Procurement Evaluation Phase: In the context of equipment
       acquisition by network operators or enterprises, candidate
       equipment suppliers need to demonstrate compliance with specified
       requirements.  In this phase, third-party organizations typically
       perform the testing to ensure neutrality.  This type of testing
       is usually conducted as black-box testing, requiring the use of
       protocol testers interconnected with the DUT.  The test cases are
       executed while observing whether the DUT behaves in accordance
       with expected protocol specifications.







Cui, et al.              Expires 26 August 2026                 [Page 4]

Internet-Draft                   FALANPT                   February 2026


4.  Key Elements of Network Protocol Testing

   Network protocol testing is a complex and comprehensive process that
   typically involves multiple parties and various necessary components.
   The following entities are generally involved in protocol testing:

   1.  DUT: The DUT can be a physical network device (such as switches,
       routers, firewalls, etc.) or a virtual network device (such as
       FRRouting (FRR) routers and others).

   2.  Tester: A protocol tester is a specialized network device that
       usually implements a standard and comprehensive protocol stack.
       It can generate test traffic, collect and analyze incoming
       traffic, and produce test results.  Protocol testers can
       typically be controlled via scripts, allowing automated
       interaction with the DUT to carry out protocol tests.

   3.  Test Cases: Protocol test cases may cover various categories,
       including protocol conformance tests, functional tests, and
       performance tests, etc.  Each test case typically includes
       essential elements such as test topology, step-by-step
       procedures, and expected results.  A well-defined test case also
       includes detailed configuration parameters.

   4.  Test Topology: Each test case must specify the network topology
       it requires.  Before executing a test case, the corresponding
       topology must be established accordingly.  In a batch testing
       scenario, frequent changes in topology can be time-consuming and
       inefficient.  To mitigate this overhead, it is common practice to
       construct a minimal common topology that satisfies the
       requirements of all test cases in a given batch.  This minimizes
       the number of devices and links needed while ensuring that each
       test case can be executed within the shared topology.

   5.  DUT Configuration: Before executing a test case, the DUT must be
       initialized with specific configurations according to the test
       case requirements (setup).  Throughout the test, the DUT
       configuration may undergo multiple modifications as dictated by
       the test scenario.  Upon test completion, appropriate
       configurations are usually applied to restore the DUT to its
       initial state (teardown).










Cui, et al.              Expires 26 August 2026                 [Page 5]

Internet-Draft                   FALANPT                   February 2026


   6.  Tester Configuration and Scripts: In test scenarios involving
       protocol testers, the tester often plays the active role by
       generating test traffic and orchestrating the test process.  This
       requires the preparation of both tester-specific configurations
       and execution scripts.  Tester scripts are typically designed in
       coordination with the DUT configurations to ensure proper
       interaction during the test.

5.  Automated Network Protocol Test Framework

   A typical network protocol test automation framework is illustrated
   as follows.

                                                          +----------+
                  +-------------+   +-----------------+   | Test Env.|
     +--------+   |  Protocol   |   |  Tester Script  |   | +------+ |
     |  RFC   |   |Formalization|   |       and       |   | |Tester| |
     |Document|-->|-------------|-->|DUT Configuration|-->| +-^----+ |
     +--------+   |  Test Case  |   |   Generation    |   |   |  |   |
                  | Generation  |   +-----------------+   | +----v-+ |
                  +-------------+           ^             | | DUT  | |
                          ^                 |             | +------+ |
                          |                 |             +----------+
                    +-----+-----------------+-----+           |  Test
                    |   Feedback and Refinement   |<----------+ Report
                    +-----------------------------+

5.1.  Protocol Formalization

   Protocol formalization forms the foundation for automated test case
   generation.  Since protocol specifications are typically written in
   natural language, this step transforms unstructured text into a
   structured, machine-interpretable representation that can be
   traversed, queried, and validated by downstream tasks.

   To enable a multi-dimensional characterization of protocol semantics,
   we formalize protocol content along two complementary dimensions:
   _Basic_ and _Logic_. Basic formalization captures the static
   structure and execution context of a protocol, including message
   formats (e.g., fields and constraints), local data structures (e.g.,
   timers and variables), and state machines that define legal state
   spaces and transitions.  Logic formalization captures operational
   semantics and behavioral constraints, including event-action rules,
   protocol algorithms, and error handling behaviors.  In practice,
   effective formalization also needs to explicitly encode relationships
   across these basic and logical elements, such as which messages
   trigger particular state transitions or processing rules, so that
   test generation can reason across modules consistently.



Cui, et al.              Expires 26 August 2026                 [Page 6]

Internet-Draft                   FALANPT                   February 2026


5.2.  Test Case Generation

   Once a machine-readable protocol representation is available, the
   next step is to identify test points from protocol requirements and
   behavioral constraints, and extend them into concrete test cases.
   Test points can be derived from normative statements, message format
   constraints, packet processing logic, and valid/invalid protocol
   state transitions.  Each test case elaborates on a specific test
   point and includes detailed test procedures and expected outcomes.
   It may also include a representative set of test parameters (e.g.,
   boundary values and invalid values) to improve coverage of edge
   conditions.  Conformance test cases are generally categorized into
   positive and negative types.  Positive test cases verify that the
   protocol implementation correctly handles valid inputs, while
   negative test cases examine how the system responds to malformed or
   unexpected inputs.

   The quality of generated test cases is typically evaluated along two
   primary dimensions: correctness and coverage.  Correctness assesses
   whether a test case accurately reflects the intended semantics of the
   protocol.  Coverage evaluates whether the test suite exercises
   protocol definitions and constraints across multiple testing
   dimensions (e.g., conformance, robustness, performance, and security)
   and explores representative parameter spaces.  However, as test cases
   are often represented using a mix of natural language, topology
   diagrams, and configuration snippets, their inherent ambiguity makes
   systematic quality evaluation difficult.  Effective metrics for test
   case quality assessment are still lacking, which remains an open
   research challenge.

5.3.  Tester Script and DUT Configuration Generation

   Test cases are often translated into executable scripts using
   available API documentation and runtime environments.  This process
   requires mapping natural language described test steps to specific
   function calls and configurations of test equipment and DUTs.

   Since tester scripts and DUT configuration files are typically used
   together, they must be generated in a coordinated manner rather than
   in isolation.  The generated configurations must ensure mutual
   interoperability within the test topology and align with the step-by-
   step actions defined in the test case.  This includes setting
   compatible protocol parameters, interface bindings, and execution
   triggers to facilitate correct protocol interactions and achieve the
   intended test objectives.






Cui, et al.              Expires 26 August 2026                 [Page 7]

Internet-Draft                   FALANPT                   February 2026


   Before deploying the tester scripts and corresponding DUT
   configurations, it is essential to validate both their syntactic and
   semantic correctness.  Although the protocol testing environment is
   isolated from production networks and thus inherently more tolerant
   to failure, invalid scripts or misconfigured devices can still render
   test executions ineffective or misleading.  Therefore, a verification
   step is necessary to ensure that the generated artifacts conform to
   the expected syntax of the execution environment and accurately
   implement the intended test logic as defined by the test case
   specification.

5.4.  Test Case Execution

   The execution of test cases involves the automated deployment of
   configurations to the DUT as well as the automated execution of test
   scripts on the tester.  This process is typically carried out in
   batches and requires a test case management system to coordinate the
   workflow.  Additionally, intermediate configuration updates during
   the execution phase may be necessary and should be handled
   accordingly.

5.5.  Report Analysis, Feedback and Refinement

   Test reports represent the most critical output of a network protocol
   testing workflow.  They typically indicate whether each test case has
   passed or failed and, in the event of failure, include detailed error
   information specifying which expected behaviors were not satisfied.
   These reports serve as an essential reference for device improvement,
   standard compliance assessment, or procurement decision-making.

   However, due to the potential inaccuracies in test case descriptions,
   generated scripts or device configurations, a test failure does not
   always indicate a protocol implementation defect.  Therefore, failed
   test cases require further inspection using execution logs,
   diagnostic outputs, and relevant runtime context.  This motivates the
   integration of a feedback and refinement mechanism into the
   framework.  The feedback loop analyzes runtime behaviors to detect
   discrepancies that are difficult to identify through static
   inspection alone.  This iterative refinement process is necessary to
   improve the reliability of the automated testing system.











Cui, et al.              Expires 26 August 2026                 [Page 8]

Internet-Draft                   FALANPT                   February 2026


6.  Automation Maturity Levels in Network Protocol Testing

   To describe the varying degrees of automation adopted in protocol
   testing practices, we define a set of Automation Maturity Levels.
   These levels reflect technical progress from fully manual testing to
   self-optimizing, autonomous systems.  These Automation Maturity
   Levels are intended as a reference model, not as a fixed pipeline
   structure.

   +=====+================+==================+===========+============+
   |Level| RFC            | Test Asset       |Result     |Human       |
   |     | Interpretation | Generation &     |Analysis & |Involvement |
   |     |                | Execution        |Feedback   |            |
   +=====+================+==================+===========+============+
   |0    | Manual reading | Fully manual     |Manual     |Full-time   |
   |     |                | scripting and    |observation|intervention|
   |     |                | CLI-based        |and logging|            |
   |     |                | execution        |           |            |
   +-----+----------------+------------------+-----------+------------+
   |1    | Human-guided   | Script templates |Manual     |High (per   |
   |     | parsing tools  | with tool-       |review with|test run)   |
   |     |                | assisted         |basic tools|            |
   |     |                | execution        |           |            |
   +-----+----------------+------------------+-----------+------------+
   |2    | Template-based | Basic autogen of |Rule-based |Moderate    |
   |     | extraction     | config & scripts |validation |(Manual     |
   |     |                | for standard     |with human |correction  |
   |     |                | cases            |triage     |and tuning) |
   +-----+----------------+------------------+-----------+------------+
   |3    | Rule-based     | Parameterized    |ML-assisted|Supervisory |
   |     | semantic       | generation and   |anomaly    |confirmation|
   |     | parsing        | batch            |detection  |            |
   |     |                | orchestration    |           |            |
   +-----+----------------+------------------+-----------+------------+
   |4    | Structured     | Objective-driven |Correlated |Minimal     |
   |     | model          | synthesis with   |failure    |(strategic  |
   |     | interpretation | end-to-end       |analysis   |input)      |
   |     |                | automation       |and report |            |
   |     |                |                  |generation |            |
   +-----+----------------+------------------+-----------+------------+
   |5    | Adaptive       | Self-adaptive    |Predictive |None        |
   |     | protocol       | generation and   |diagnostics|(optional   |
   |     | modeling       | self-optimizing  |and        |audit)      |
   |     |                | execution        |remediation|            |
   |     |                |                  |proposals  |            |
   +-----+----------------+------------------+-----------+------------+

     Table 1: Automation Maturity Matrix for Network Protocol Testing



Cui, et al.              Expires 26 August 2026                 [Page 9]

Internet-Draft                   FALANPT                   February 2026


   As shown in Table 1, the Automation Maturity Levels are characterized
   along four dimensions: RFC interpretation, test asset generation and
   execution, result analysis, and human involvement.  Each level
   reflects an increasing degree of system autonomy and decreasing human
   involvement.

6.1.  Level 0: Manual Testing

   Description: All testing tasks are performed manually by test
   engineers.

   Key Characteristics:

   *  Protocol understanding, test case design, topology setup,
      scripting, execution, and result analysis all rely on manual work.

   *  Tools are only used for basic assistance (e.g., packet capture via
      Wireshark).

6.2.  Level 1: Tool-Assisted Testing

   Description: Tools are used to assist in some testing steps, but the
   core logic is still human-driven.

   Key Characteristics:

   *  Automation includes test script execution and automated result
      comparison.

   *  Manual effort is still required for test case design, topology
      setup, and exception analysis.

6.3.  Level 2: Partial Automation

   Description: Basic test case generation and execution are automated,
   but critical decisions still require human input.

   Key Characteristics:

   *  Automation includes:

      -  A framework that performs basic protocol formalization (e.g.,
         extracting fields, message formats, and FSM fragments) and
         generates baseline test cases and corresponding tester scripts
         and DUT configurations for standard cases.

      -  Topology generation for a single test case.




Cui, et al.              Expires 26 August 2026                [Page 10]

Internet-Draft                   FALANPT                   February 2026


   *  Manual effort includes:

      -  Designing complex or edge case scenarios.

      -  Root cause analysis when tests fail.

6.4.  Level 3: Conditional Automation

   Description: The system can autonomously complete the test loop, but
   relies on human-defined rules and constraints.

   Key Characteristics:

   *  Automation includes:

      -  Complex test case and parameter generation based on semantic
         understanding and formalization of RFCs (e.g., structured
         protocol modules and behavioral constraints).

      -  Minimal common topology synthesis for a set of test cases.

      -  Automated result analysis with anomaly detection and iterative
         refinement driven by execution feedback.

   *  Manual effort includes:

      -  Reviewing the test plan and confirming whether flagged
         anomalies represent real protocol violations.

6.5.  Level 4: High Automation

   Description: Full automation of the testing pipeline, with minimal
   human involvement limited to high-level adjustments.

   Key Characteristics:

   *  Automation includes:

      -  End-to-end automation from RFC parsing to test report
         generation.

      -  Automated result analysis with root cause analysis.

      -  Automated recovery from environment issues.

   *  Manual effort includes:





Cui, et al.              Expires 26 August 2026                [Page 11]

Internet-Draft                   FALANPT                   February 2026


      -  Defining high-level test objectives, with the system
         decomposing tasks accordingly.

6.6.  Level 5: Full Automation

   Description: Adaptive testing, where the system independently
   determines testing strategies and continuously optimizes coverage.

   Key Characteristics:

   *  Automation includes:

      -  Learning protocol implementation specifics (e.g., proprietary
         extensions) and generating targeted test cases.

      -  Leveraging historical data to predict potential defects.

      -  Iterative self-optimization to improve efficiency.

   *  Manual effort: None.  The system autonomously outputs a final
      compliance report along with remediation suggestions.

7.  An Example of LLM-based Automated Network Protocol Test Framework
    (From Level 2 to Level 3)

   The emergence of LLMs has significantly advanced the degree of
   automation achievable in network protocol testing.  Within the
   proposed framework, LLMs can serve as core components in multiple
   stages of the testing pipeline, enabling a transition from Level 2
   (Partial Automation) to Level 3 (Conditional Automation).  A key
   enabler is to introduce an explicit protocol formalization step that
   transforms unstructured RFC text into a structured, machine-
   interpretable intermediate representation (e.g., a protocol
   description spanning message formats, state machines, and normative
   behavioral constraints).  With such a representation, downstream
   generation becomes more systematic and less dependent on ad-hoc,
   protocol-specific parsers.

   At the protocol formalization stage, LLMs can enrich RFCs with
   structured signals, such as section-level summaries, cross-references
   across documents, and normative requirement statements (e.g., "must"
   and "SHOULD").  The agent can further induce protocol modules (e.g.,
   message formats, state machines, event-action rules, and algorithms)
   and formalize them into a unified representation that supports
   traversal and query.  This representation serves as the semantic
   backbone for test generation, and it also helps in update scenarios
   by localizing changes and propagating them to the corresponding
   formal modules.



Cui, et al.              Expires 26 August 2026                [Page 12]

Internet-Draft                   FALANPT                   February 2026


   Based on the formalized protocol representation, LLMs can generate
   test cases in a more structured manner by decoupling test case
   templates from test parameters.  The template generation step expands
   extracted test points into parameterized templates that define test
   objectives, topology, execution steps, oracles, and static testbed
   configurations.  The parameter instantiation step then populates
   template placeholders with concrete values, including representative
   boundary values and invalid values for robustness testing.  When
   oracle values require computation, the system can synthesize small
   helper programs (e.g., Python scripts) to compute expected outcomes,
   and can apply equivalence partitioning to reduce redundant parameter
   combinations without sacrificing meaningful coverage.

   For test execution, LLMs can assist in translating abstract test
   procedures into executable artifacts for both the tester and the DUT.
   In practice, this translation is often a multi-step workflow that
   benefits from a structured agent architecture.  For example, a core
   agent can orchestrate the artifact generation process, while
   specialized sub-agents handle documentation summarization, intent
   rewriting (turning high-level test objectives into API-aligned
   actions), and recurring fault fixing based on an experience pool.
   During execution, feedback from logs and device outputs can be used
   to iteratively refine generated artifacts, and an adaptive pruning
   mechanism can decide whether to stop exploring additional parameter
   instances for a given template when definitive failures are found or
   sufficient coverage has been achieved.

   Despite these capabilities, it is important to note that LLMs are
   fundamentally probabilistic and cannot guarantee determinism or
   correctness.  Therefore, even when the framework can complete an
   automated loop with reduced human effort, human oversight remains
   valuable for validating critical intermediate artifacts (e.g.,
   formalized protocol modules, test oracles, and high-impact
   configuration changes) and for handling ambiguous or novel protocol
   behaviors.  Nevertheless, integrating LLMs with explicit protocol
   formalization, systematic template/parameter generation, and
   execution-time feedback provides a practical path for elevating
   protocol testing practices toward Level 3 maturity.

8.  Security Considerations

   1.  Execution of Unverified Generated Code: Automatically generated
       test scripts or configurations (e.g., CLI commands, tester
       control scripts) may include incorrect or harmful instructions
       that misconfigure devices or disrupt test environments.
       Mitigation: All generated artifacts should undergo validation,
       including syntax checking, semantic verification against protocol
       constraints, and dry-run execution in sandboxed environments.



Cui, et al.              Expires 26 August 2026                [Page 13]

Internet-Draft                   FALANPT                   February 2026


   2.  AI-Assisted Component Risks: LLMs may produce incorrect or
       insecure outputs due to their probabilistic nature or prompt
       manipulation.  Mitigation: Apply input sanitization, prompt
       hardening, and human-in-the-loop validation for critical
       operations.

9.  IANA Considerations

   This document has no IANA actions.

Acknowledgments

   This work is supported by the National Key R&D Program of China.

Contributors

   Zhen Li
   Beijing Xinertel Technology Co., Ltd.
   Email: lizhen_fz@xinertel.com

   Zhanyou Li
   Beijing Xinertel Technology Co., Ltd.
   Email: lizy@xinertel.com

Authors' Addresses

   Yong Cui
   Tsinghua University
   Email: cuiyong@tsinghua.edu.cn


   Yunze Wei
   Tsinghua University
   Email: wyz23@mails.tsinghua.edu.cn


   Kaiwen Chi
   Tsinghua University
   Email: ckw24@mails.tsinghua.edu.cn


   Xiaohui Xie
   Tsinghua University
   Email: xiexiaohui@tsinghua.edu.cn







Cui, et al.              Expires 26 August 2026                [Page 14]


name: draft-kartha-grd
rev: 01
title: Geospatial Resource Discovery (GRD): Problem Statement and Conceptual Architecture
time: 2026-01-19T09:50:49Z
group_uri: /api/v1/group/group/1027/
expires: 2026-07-23T09:50:49Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent discovery/reg", "Autonomous netops", "Data formats/interop"]
tags: []
fetched_at: 2026-02-27T22:56:10.243488+00:00
abstract:
The Internet provides standardized mechanisms for resolving
   identifiers, such as domain names, to network locations.  These
   mechanisms assume that a client already knows the identifier of the
   resource it wishes to access.  Emerging classes of applications,
   including augmented reality, autonomous systems, robotics, and
   spatial computing, operate under a different assumption.  In these
   systems, discovery begins with physical presence and observer context
   rather than with a predefined name.

   This document describes the architectural gap addressed by a
   Geospatial Resource Discovery service.  It defines the problem space,
   explains why existing standards are insufficient, and outlines a
   conceptual architecture for spatial discovery.  This document is
   informational and architectural in nature.  It does not define a
   protocol, data format, or implementation.

full_text:
Network Working Group                                       G. S. Kartha
Internet-Draft                                               Independent
Intended status: Informational                           20 January 2026
Expires: 24 July 2026


 Geospatial Resource Discovery (GRD): Problem Statement and Conceptual
                              Architecture
                          draft-kartha-grd-01

Abstract

   The Internet provides standardized mechanisms for resolving
   identifiers, such as domain names, to network locations.  These
   mechanisms assume that a client already knows the identifier of the
   resource it wishes to access.  Emerging classes of applications,
   including augmented reality, autonomous systems, robotics, and
   spatial computing, operate under a different assumption.  In these
   systems, discovery begins with physical presence and observer context
   rather than with a predefined name.

   This document describes the architectural gap addressed by a
   Geospatial Resource Discovery service.  It defines the problem space,
   explains why existing standards are insufficient, and outlines a
   conceptual architecture for spatial discovery.  This document is
   informational and architectural in nature.  It does not define a
   protocol, data format, or implementation.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 24 July 2026.







Kartha                    Expires 24 July 2026                  [Page 1]

Internet-Draft        Geospatial Resource Discovery         January 2026


Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Scope and Non-Goals . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.2.  Non-Goals . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Design Guidelines . . . . . . . . . . . . . . . . . . . . . .   4
   6.  Conceptual Architecture . . . . . . . . . . . . . . . . . . .   4
   7.  Volumetric Query Concept  . . . . . . . . . . . . . . . . . .   5
   8.  Relationship to Existing Work . . . . . . . . . . . . . . . .   6
     8.1.  IETF Standards  . . . . . . . . . . . . . . . . . . . . .   6
     8.2.  OGC and GIS Standards . . . . . . . . . . . . . . . . . .   6
   9.  Security and Trust Challenges . . . . . . . . . . . . . . . .   7
     9.1.  Trust Model . . . . . . . . . . . . . . . . . . . . . . .   7
   10. Privacy Considerations  . . . . . . . . . . . . . . . . . . .   7
     10.1.  Attacker Model . . . . . . . . . . . . . . . . . . . . .   7
     10.2.  Measurable Privacy Goals . . . . . . . . . . . . . . . .   7
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
   Appendix A.  Illustrative Data Model  . . . . . . . . . . . . . .   8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   Internet architecture has historically focused on resolving semantic
   identifiers into network endpoints.  Systems such as the Domain Name
   System enable scalable communication by assuming that clients already
   know the name of the resource they are attempting to reach.

   Emerging spatial systems invert this assumption.  In augmented
   reality, autonomous navigation, and smart environments, discovery
   begins with physical location and context.  A user or machine



Kartha                    Expires 24 July 2026                  [Page 2]

Internet-Draft        Geospatial Resource Discovery         January 2026


   operating at a specific coordinate needs to ask what digital
   information is associated with the surrounding space and visible
   volume.

   At present, this type of discovery occurs inside closed ecosystems.
   Each platform maintains its own spatial maps, registries, and access
   mechanisms.  While effective within individual systems, these
   approaches do not interoperate.  This document argues that spatial
   discovery represents a missing architectural layer and describes the
   requirements for an open Geospatial Resource Discovery capability.

   This document is intended to inform future work on interoperable
   spatial discovery mechanisms, potentially including protocol
   specifications.

2.  Scope and Non-Goals

2.1.  Scope

   This document focuses on the application layer.  It describes a
   discovery pattern that can operate over existing transports such as
   HTTP/3 or CoAP.  It intentionally avoids assumptions about rendering
   engines, device capabilities, or user interface models.

2.2.  Non-Goals

   This document does not propose changes to IP routing or DNS
   semantics.  It does not define legal ownership of physical space,
   geometric rendering standards, or a global governance model for
   spatial authority.

3.  Terminology

   Spatial Resource: A digital asset associated with a physical location
   or volume, such as an augmented reality annotation, navigation
   marker, or machine-readable instruction.

   Spatial Cell: A discrete geospatial region used for indexing and
   lookup, typically derived from a hierarchical grid system.

   Frustum: A three-dimensional volume defined by an observer's
   position, orientation, and field of view.

   Trust Anchor: A cryptographic root of trust (e.g., a Public Key)
   configured on the client and used to validate data associated with a
   specific Semantic Layer (e.g., "Safety" or "Transit") within a given
   context.




Kartha                    Expires 24 July 2026                  [Page 3]

Internet-Draft        Geospatial Resource Discovery         January 2026


4.  Problem Statement

   The Internet lacks a standardized mechanism to discover digital
   resources based on physical location and observer context.

   Existing discovery mechanisms resolve names rather than locations.
   While geographic identifiers exist (e.g., [RFC5870]), there is no
   standard protocol that allows a client to query a location and
   receive a list of available spatial resources.

   Spatial data is also highly application-specific.  Autonomous
   vehicles, wearable devices, and smart infrastructure systems
   operating in the same physical environment cannot discover or consume
   each other's data unless they share a proprietary backend.

   In addition, current application protocols do not natively support
   volumetric queries.  Requests such as retrieving resources within a
   three-dimensional viewing volume are not commonly supported in
   interoperable discovery mechanisms.

   Finally, many spatial resources are dynamic and time-sensitive.
   Real-time spatial information, such as hazards or temporary
   instructions, requires low latency and short validity periods.
   Traditional caching assumptions are poorly suited to these
   constraints.

5.  Design Guidelines

   Any future specification for Geospatial Resource Discovery should
   follow a small set of architectural principles.  The design should
   remain independent of transport and operate over existing Internet
   protocols.  Complex geometric calculations should be performed by the
   client to preserve resolver scalability.  Discovery should support
   semantic filtering so that clients can request only relevant
   categories of information.  Privacy considerations need to be
   integral to the design and should limit the precision of location
   data exposed to discovery services.

6.  Conceptual Architecture

   This section outlines a conceptual architecture referred to as
   Geospatial Resource Discovery (GRD).

   The physical world is divided into discrete spatial cells using a
   standard hierarchical indexing system.  Representing space in this
   way allows spatial discovery to be reduced to key-based lookups
   rather than continuous geospatial computation.




Kartha                    Expires 24 July 2026                  [Page 4]

Internet-Draft        Geospatial Resource Discovery         January 2026


           +---------+---------+---------+
           | Cell A  | Cell B  | Cell C  |
           |         |         |         |
           +---------+---------+---------+
           | Cell D  | Cell E  | Cell F  |
           | (Index) | (Index) | (Index) |
           +---------+---------+---------+
           | Cell G  | Cell H  | Cell I  |
           |         |         |         |
           +---------+---------+---------+

                    Figure 1: Hierarchical Spatial Grid

   A GRD resolver functions as a directory service.  The term "resolver"
   is used descriptively and does not imply a standardized network role.
   It maintains references to spatial resources indexed by cell
   identifier and returns pointers to the actual assets.  The resolver
   does not host large content objects such as three-dimensional models.

   Authority over physical space is not strictly hierarchical.  Multiple
   independent entities may publish resources associated with the same
   spatial cell.  This introduces a fundamental architectural choice
   between client-side aggregation of multiple authorities and resolver-
   side federation of records.

   For example, a federated resolver simplifies client logic and can
   vouch for aggregated data integrity, but requires coordination among
   authorities.  Client-side aggregation offers greater autonomy and
   avoids a central point of coordination but places the burden of trust
   evaluation and result merging on each client.

7.  Volumetric Query Concept

   To balance scalability and privacy, GRD follows a coarse query and
   fine filter model.

   The client computes its precise view frustum locally and determines
   which standard spatial cells intersect that volume.  It then queries
   the resolver for resources associated with those cells, optionally
   filtered by semantic category.  This translation from a continuous
   geometric volume to discrete cell identifiers allows spatial
   discovery to leverage standard, cache-friendly HTTP request semantics
   for what is inherently a spatial query.








Kartha                    Expires 24 July 2026                  [Page 5]

Internet-Draft        Geospatial Resource Discovery         January 2026


                   / \
                  /   \  <-- View Frustum
                 /     \
                /       \
         +-----/---------/-----+
         | Cell X | Cell Y |   |  <-- Client requests Cell X + Y
         +--------+--------+---+      (Standard HTTP GET)

                   Figure 2: Frustum-to-Cell Intersection

   The client performs final filtering locally and discards resources
   that fall outside the exact viewing volume.  This approach ensures
   that the resolver does not learn the client's precise orientation or
   gaze direction.

8.  Relationship to Existing Work

8.1.  IETF Standards

   RFC 5870 ('geo' URI) defines a method to identify a physical location
   but does not define a mechanism to retrieve resources associated with
   that location.  GRD complements RFC 5870 by providing the resolution
   layer.

   RFC 9176 (CoRE Resource Directory) enables resource discovery on
   constrained networks but relies on network endpoints rather than
   geodetic context.  It does not support volumetric or spatial-context
   queries (e.g., "what is visible from this coordinate").

   RFC 6763 (DNS-SD) is effective for local service discovery via
   multicast or administrative domains but cannot scale to global,
   location-based queries required for open spatial computing.

8.2.  OGC and GIS Standards

   OGC standards (e.g., WFS, OGC API - Features) are designed for
   complex querying of heavy geospatial databases.  GRD is designed as a
   lightweight, low-latency resolution service (conceptually similar to
   DNS in its indirection role) for real-time spatial computing, handing
   off the heavy data transfer to application-specific protocols.











Kartha                    Expires 24 July 2026                  [Page 6]

Internet-Draft        Geospatial Resource Discovery         January 2026


9.  Security and Trust Challenges

   A primary risk in spatial discovery is reality poisoning: the
   injection of false or malicious information that directly alters a
   user's perception of the physical world.  The safety implications are
   significant--consider the effect of a counterfeit right-of-way marker
   for an autonomous vehicle or a hallucinated safe path over a physical
   hazard for a first responder.

9.1.  Trust Model

   GRD cannot rely on a single global root of trust.  Instead, trust
   must be contextual and scoped by semantic layer.  A "Safety" layer
   might rely on a government Trust Anchor, while a "Commercial" layer
   might rely on a different registry.  The architecture is expected to
   require that Spatial Resource Records (SRRs) carry cryptographic
   signatures verifiable against the client's configured Trust Anchors
   for that specific layer.

10.  Privacy Considerations

10.1.  Attacker Model

   The GRD Resolver is modeled as an Honest-but-Curious adversary.  It
   is trusted to return correct spatial records but is assumed to log
   queries in an attempt to reconstruct client trajectories.

10.2.  Measurable Privacy Goals

   Privacy risks are mitigated by enforcing minimum cell granularity
   (k-anonymity), intended to ensure that a query does not uniquely
   identify a user within a small physical area.  Additionally, the
   architecture is expected to avoid reliance on persistent session
   identifiers that allow the Resolver to correlate separate queries to
   a single device (Unlinkability).

11.  IANA Considerations

   This document does not request any IANA actions.

12.  References

   [RFC5870]  Mayrhofer, A. and C. Spanring, "A Uniform Resource
              Identifier for Geographic Locations ('geo' URI)",
              RFC 5870, June 2010,
              <https://www.rfc-editor.org/rfc/rfc5870>.





Kartha                    Expires 24 July 2026                  [Page 7]

Internet-Draft        Geospatial Resource Discovery         January 2026


   [RFC9176]  Shelby, Z., Koster, M., and C. Bormann, "Constrained
              RESTful Environments (CoRE) Resource Directory", RFC 9176,
              April 2022, <https://www.rfc-editor.org/rfc/rfc9176>.

   [RFC6763]  Cheshire, S. and M. Krochmal, "DNS-Based Service
              Discovery", RFC 6763, February 2013,
              <https://www.rfc-editor.org/rfc/rfc6763>.

Appendix A.  Illustrative Data Model

   This appendix is non-normative and illustrates the type of data a
   resolution service might return.

   {
     "cell_id": "8928308280fffff",
     "resources": [
       {
         "id": "res-12345",
         "type": "safety.warning",
         "location": { "lat": 52.3, "lon": 4.9, "alt": 10 },
         "layer": "infrastructure",
         "uri": "https://city-assets.example.com/signs/stop.glb",
         "validity_ms": 60000,
         "signature": "ab382...[cryptographic proof]"
       }
     ]
   }

                                  Figure 3

Author's Address

   Gokul Sivasankaran Kartha
   Independent
   Email: kartha.gokul@gmail.com
















Kartha                    Expires 24 July 2026                  [Page 8]


name: draft-templin-manet-inet-omni
rev: 01
title: MANET Internetworking with AERO/OMNI
time: 2026-02-20T16:19:17Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-24T16:19:17Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Autonomous netops", "A2A protocols"]
tags: []
fetched_at: 2026-02-27T22:56:10.243502+00:00
abstract:
[RFC2501] defines a MANET as "an autonomous system of mobile nodes.
   The system may operate in isolation, or may have gateways to and
   interface with a fixed network" (such as the global public Internet).
   This document presents a MANET Internetworking framework based on the
   Automatic Extended Route Optimization (AERO) and Overlay Multilink
   Network (OMNI) Interface technologies.

full_text:
Network Working Group                                 F. L. Templin, Ed.
Internet-Draft                              Boeing Technology Innovation
Intended status: Informational                           D. J. Jakubisin
Expires: 24 August 2026       National Security Institute, Virginia Tech
                                                        20 February 2026


                  MANET Internetworking with AERO/OMNI
                    draft-templin-manet-inet-omni-01

Abstract

   [RFC2501] defines a MANET as "an autonomous system of mobile nodes.
   The system may operate in isolation, or may have gateways to and
   interface with a fixed network" (such as the global public Internet).
   This document presents a MANET Internetworking framework based on the
   Automatic Extended Route Optimization (AERO) and Overlay Multilink
   Network (OMNI) Interface technologies.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 24 August 2026.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.











Templin & Jakubisin      Expires 24 August 2026                 [Page 1]

Internet-Draft               AERO/OMNI MANET               February 2026


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  MANET Use Cases . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  MANET Internetworking with AERO/OMNI  . . . . . . . . . . . .   5
     3.1.  MANET Local Addressing  . . . . . . . . . . . . . . . . .   5
     3.2.  MANET Autoconfiguration . . . . . . . . . . . . . . . . .   6
     3.3.  MANET-internal Communications . . . . . . . . . . . . . .   7
     3.4.  MANET Peer to Internetwork Correspondent  . . . . . . . .   8
     3.5.  Internetwork Correspondent to MANET Peer  . . . . . . . .   8
     3.6.  Peer-to-Peer Between Different MANETs . . . . . . . . . .   9
     3.7.  Stub MANET to Not-so-stubby MANET Connections . . . . . .   9
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Appendix A.  Change Log . . . . . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   Mobile Ad-hoc Networks (MANETs) [RFC2501] often include mobile nodes
   with limited range wireless transmission media interfaces that
   establish links via a dynamically changing set of neighbors within
   operational range.  Each mobile node engages a MANET routing protocol
   to discover links to first hop neighbors as well as multihop paths to
   reach other nodes beyond.  As IP routers [RFC0791][RFC8200], MANET
   routers represent multihop paths as "host routes" established through
   either proactive or reactive discovery.











Templin & Jakubisin      Expires 24 August 2026                 [Page 2]

Internet-Draft               AERO/OMNI MANET               February 2026


   Individual MANETs typically include modest numbers of mobile nodes
   (e.g., O(1), O(10), O(100), etc.); this naturally limits the number
   of host routes needed in the local routing system.  MANETs can merge
   to form larger MANETs and/or partition into smaller MANETs according
   to dynamic network conditions such as mobility.  MANETs may also have
   internal clusters with cluster heads that limit the extent over which
   host routes propagate to reduce control message overhead.  Finally,
   MANETs often operate autonomously unless or until they encounter
   Internetwork access points of opportunity.

   Data communications between two nodes within the same local MANET
   routing region follow host routes using MANET-internal links.  When a
   MANET router establishes an Internetwork link, it can provide
   "Internet connection-sharing" access to the rest of the MANET as a
   connected "stub" network.  Per [RFC2501], "stub networks carry
   traffic originating at and/or destined for internal nodes, but do not
   permit exogenous traffic to "transit" through the stub network".

   Practical applications however suggest that MANETs can act as either
   true stub networks (e.g., a cellphone providing a hotspot for a
   multihop WiFi SSID) or as "not-so-stubby" networks (e.g., Intelligent
   Transportation Systems where the 5G/6G "SideLink" service supports
   vehicle-to-vehicle (V2V) multihopping).  In the former case, the
   cellphone acts as an IP router for a stub WiFi MANET behind it and
   the individual WiFi nodes act as dependent nodes.  In the latter
   case, individual 5G/6G SideLink nodes can connect the stub MANETs
   they aggregate across not-so-stubby V2V multihop forwarding paths.
   MANET Internetworking must therefore be capable of accommodating all
   such scenarios.

   Google AI reports that: "There are currently more mobile phones than
   people in the world.  While the exact number fluctuates, estimates
   suggest there are over 12 billion mobile connections worldwide".
   Each mobile node that connects to the global public Internet can in
   some sense be regarded as a network access point for a singleton
   "MANET" with the potential to connect still larger MANETs.

   MANET Internetworking therefore regards the global Internet as a
   "network of (mobile ad-hoc) networks", and with unrestricted dynamic
   relationships between distinct local MANET routing regions joined by
   a multiple access virtual overlay link.  Figure 1 illustrates an
   example of two distinct MANET local routing regions connected via a
   virtual overlay using the Global Internet as transit:








Templin & Jakubisin      Expires 24 August 2026                 [Page 3]

Internet-Draft               AERO/OMNI MANET               February 2026


                                .-(::::::::)
                             .-(::: Global ::)-.
                  X==+======(===================)======+==X
                     |        `-(: Internet :)-'       |
                     |           `-(::::::)-'          |
                     |                                 |
              .-(::::::::)                       .-(::::::::)
           .-(::::::::::::)-.                 .-(::::::::::::)-.
          (::::: MANET 1 :::::)              (::::: MANET 2 :::::)
            `-(::::::::::::)-'                 `-(::::::::::::)-'
               `-(::::::)-'                       `-(::::::)-'

                      Figure 1: MANET Internetworking

   In this context, a number of gaps have been identified to bring
   robust MANET Internetworking to fruition [I-D.templin-manet-inet].
   The purpose of the present submission is to describe approaches to
   addressing these gaps based on the Automatic Extended Route
   Optimization (AERO) [I-D.templin-6man-aero3] and Overlay Multilink
   Network (OMNI) Interface [I-D.templin-6man-omni3] solutions.

2.  MANET Use Cases

   MANETs have an important role in emergency response communications,
   disaster relief situations, communications in remote and rural areas,
   military operations, vehicular and swarm communications, and low-
   powered Internet of things (IoT) applications.  MANETs provide the
   ability to establish and maintain communications when infrastructure-
   based networks, such as 5G cellular communication systems, are not
   accessible.  As described above, MANETs may also provide Internet
   connectivity to internal nodes, for example, as a "stub" network via
   MANET routers which possess an Internetworking capability and an
   external connection to a radio access network.

   Example use cases of such MANETs include the following:

   *  Disaster Relief: Disaster situations may compromise network
      infrastructure, such as through the loss of base stations in a
      cellular radio access network (RAN).  In this scenario, MANET
      networks can play a role in closing coverage gaps through multi-
      hop routing to nodes within the coverage area of uncompromised
      base stations.  This use case is broadly applicable to any
      situation in which nodes are operating outside or at the periphery
      of RAN coverage.

   *  Tracking and Monitoring: Another example use case is the tracking
      and monitoring of data from low-cost low-power IoT devices
      ("tags") which may be placed on packages during shipment or



Templin & Jakubisin      Expires 24 August 2026                 [Page 4]

Internet-Draft               AERO/OMNI MANET               February 2026


      storage.  Such devices may transition in and out of coverage of
      infrastructure-based networks, often being located in environments
      that are not conducive to RF propagation (e.g., shipping
      container, warehouse, etc.).  The ability to discover and connect
      to neighboring MANET-enabled devices and to establish Internet
      connectivity through such MANETs, enables real-time logistics and
      inventory data to be collected opportunistically.

   *  UAV Swarms: local communications within swarms for coordination
      and cooperation is a good use case for MANET networks due to the
      highly mobile dynamic nature of such networks.  Yet swarms may
      also benefit from connectivity to the Internet, or other external
      networks.  And in large swarm-based MANETs, routing of traffic
      through infrastructure networks to MANET endpoints, rather than
      traversing the entire MANET can improve communications throughput
      and reliability.

3.  MANET Internetworking with AERO/OMNI

3.1.  MANET Local Addressing

   Each MANET router requires a unique IP address for MANET-local
   communications; the router often uses this same address to configure
   a unique "router ID".  For MANETs that are only intermittently
   connected to an Internetwork, these addresses must be generated from
   IP prefixes of scope greater than link-local but not associated with
   infrastructure aggregation points.  For all MANET types, each
   address/ID must be locally-unique within the (limited) local MANET
   routing domain.  For not-so-stubby MANETs, the address/ID must also
   be globally-unique among all MANET routing domains worldwide.

   The locally-unique property ensures that no two nodes that
   participate in the MANET routing protocol within the same local
   routing domain configure the same address/ID.  The globally-unique
   property may seem moot until one considers that MANETs can merge with
   other MANETs, and nodes from a first MANET can freely move to other
   MANETs.  This may allow a node from a first MANET where there are no
   duplicates to interact with other MANETs where a duplicate address
   may be encountered resulting in unpredictable behavior and/or
   communication failures.

   Although the node population for each MANET local routing domain is
   likely to be modest, the total population of MANET nodes may be on
   the order of the number of worldwide mobile connections (see:
   Section 1).  Assuming the google estimate of O(10**10) wireless
   connections, if MANET nodes assigned random addresses from a 64-bit
   space, the probability of one or more collisions within the total
   world population (i.e., when multiple nodes independently configure



Templin & Jakubisin      Expires 24 August 2026                 [Page 5]

Internet-Draft               AERO/OMNI MANET               February 2026


   the same address) exceeds 98% [RFC9374].  With such a high likelihood
   of duplication in the worldwide population, an unresolvable collision
   could occur if duplicates ever met within the same local routing
   domain (e.g., following a MANET merge).

   When MANET Internetworking is applied to connect routers in different
   not-so-stubby MANETs, independent local routing domains are
   dynamically joined by an overlay that spans any underlying
   Internetworks as a normal course of operational data communications.
   When two distinct MANET local routing regions merge in this way, the
   MANET local IP addresses present in the source and destination MANETs
   must be mutually exclusive.

   These merge events must further be considered to occur at truly
   unbounded frequencies across the global population due to the
   unpredictable nature of worldwide Internetworking dynamics for peer-
   to-peer communications.  In the limiting case, all worldwide local
   MANET routing regions may be considered to be persistently merged
   over the MANET Internetworking overlay at all times.  Statistical
   uniqueness properties of random assignments from even very large
   populations may therefore be insufficient to ensure collision freedom
   since MANET Internetworking exposes the full world population of
   MANET local addresses as potential duplicates.

   Nodes in not-so-stubby MANETs should therefore configure MANET local
   addresses managed for global uniqueness even if they first self-
   generate the addresses before enrolling them in a registration
   service.  The IPv6 Multilink Local Address (MLA) provides a suitable
   solution for this purpose [I-D.templin-6man-mla].

3.2.  MANET Autoconfiguration

   When a MANET comes in contact with a fixed Internetwork such as the
   global public Internet, nodes in the MANET that engage global mobile
   Internetworking services require some means of autoconfiguring
   global-scoped IP addresses or prefixes that are properly routable by
   network elements accessible from the current point of attachment.
   These network elements are typically proxies or gateways of some
   variety that connect to the mobile routing system.

   Nodes in the local MANET that are multiple IP hops away from an
   Internet connection sharing peer cannot use unmodified standard
   autoconfiguration services including IPv6 Neighbor Discovery (IPv6ND)
   [RFC4861] or DHCPv6 [RFC8415] over a MANET interface since these
   services are link-scoped in nature.  (The DHCPv6 architecture
   includes a "relay" function, but the dynamic nature of links in
   (multi-link) local MANET routing regions may interfere with
   straightforward application of DHCPv6 relays.)



Templin & Jakubisin      Expires 24 August 2026                 [Page 6]

Internet-Draft               AERO/OMNI MANET               February 2026


   To engage in autoconfiguration, the requesting node configures a
   (virtual) overlay multilink network interface over its (physical)
   MANET interface(s) and issues standard link-scoped IPv6ND and/or
   DHCPv6 requests over the virtual interface.  The virtual interface
   applies encapsulation to provide the appearance of a single Non-
   Broadcast Multiple Access (NBMA) link spanning the entire (multilink)
   MANET.  This virtual link supports standard link-scoped
   autoconfiguration services coordinated with an Internetwork element
   capable of delegating IP prefixes.  The Overlay Multilink Network
   (OMNI) Interface specification [I-D.templin-6man-omni3] and its
   companion Automatic Extended Route Optimization (AERO)
   [I-D.templin-6man-aero3] were designed for this purpose.

   All MANET nodes as well as AERO/OMNI Internetwork Proxy/Servers and
   Gateways assign a unique MLA to their OMNI virtual interface.  An
   AERO/OMNI Mobility Anchor Point (MAP) delegates a Mobility Service
   Provider (MSP) Mobile Network Prefix (MNP) as a Provider-Independent
   (PI) IP prefix maintained by the overlay for the requesting node to
   provision on downstream-attached interfaces in the manner discussed
   in [RFC9663] and [RFC9762].  The MAP then returns the delegated MNP
   in a link-scoped reply over the OMNI interface that traverses the
   reverse path to the original requesting node.

   The MLAs assigned as described above are routable within an OMNI link
   limited domain [RFC8799], but may not be routable to peers in other
   domains and/or the open Internet.  MANET nodes therefore also obtain
   globally routable IP MNPs from supporting MAP Proxy/Servers to
   support global-scoped communications; address selection policies
   should prefer these MNP-based addresses when available due to the
   limited domain routable nature of MLAs.

3.3.  MANET-internal Communications

   Two nodes located within the same local MANET routing region should
   be able to communicate (across multiple hops if necessary) using MLA
   addressing with no external Internetwork infrastructure reference
   points.  As long as the MLAs configured by communicating peers are
   unique, the MANET local routing system maintains continuous multihop
   forwarding services to ensure session continuity.

   Nodes within the local MANET routing region can discover the MLAs
   and/or MNP-based global addresses of peers using Multicast DNS (mDNS)
   [RFC6762] supported by Simplified Multicast Forwarding (SMF)
   [RFC6621].  Peer-to-peer communications can then be coordinated in
   multihop fashion using OMNI encapsulation and header compression over
   an overlay virtual link spanning any MANET intermediate hops in the
   path.




Templin & Jakubisin      Expires 24 August 2026                 [Page 7]

Internet-Draft               AERO/OMNI MANET               February 2026


3.4.  MANET Peer to Internetwork Correspondent

   When an originating peer (or its stub MANET Internet connection-
   sharing node) within a not-so-stubby MANET needs to communicate with
   a correspondent connected elsewhere in an external Internetwork, the
   peer consults the global DNS which returns a (stable) globally-
   routable IP address for the correspondent.  The peer can then use one
   of its MNP-based IP addresses obtained through autoconfiguration and
   the global IP address of the Internetwork correspondent as the source
   and destination addresses for packet exchanges.

   The MANET peer establishes per-flow on-demand virtual circuits in the
   overlay to an Internetwork relay beyond the MANET border.  MANET
   local multihop routing will then convey the peer's original packets
   to the MANET border which then forwards them via the overlay to an
   Internetwork relay which directs the packets to the correspondent
   node.

   In the reverse path, the correspondent uses the MNP-based IP address
   of the peer obtained from the source address of initiating packets as
   the destination address for reply packets.  Standard Internetwork
   routing will direct the packets back to the relay which then forwards
   them via per-flow overlay virtual circuits to the originating peer's
   MANET border.  MANET-local routing and forwarding will then convey
   the packets over one or more MANET-local hops until they ultimately
   reach the peer.

   In this case, the originating peer's IP address need not appear in
   the global DNS since the correspondent discovers the address by
   examining the source of received packets.

3.5.  Internetwork Correspondent to MANET Peer

   When an Internetwork correspondent needs to communicate with a target
   peer within a local MANET routing region, the correspondent consults
   the global DNS to determine an IP address for the peer.

   The correspondent then forwards packets via standard Internet routing
   until they arrive at a relay.  The relay then establishes per-flow
   virtual circuits in the overlay to the MANET peer while forwarding
   packets via the virtual circuit until they reach the destination.
   Reverse path forwarding from the MANET peer to the Internetwork
   correspondent is then conducted in the same manner described in
   Section 3.4.

   IP addresses covered by delegated prefixes remain stable even across
   MANET-wide mobility events to the point that continuous dynamic
   updates to the DNS are not required to maintain uninterruptable



Templin & Jakubisin      Expires 24 August 2026                 [Page 8]

Internet-Draft               AERO/OMNI MANET               February 2026


   communications.  While it is possible that mobility events may cause
   minor temporary disruptions, transport protocol retransmissions will
   maintain continuity for any ongoing sessions.

3.6.  Peer-to-Peer Between Different MANETs

   When two prospective peer nodes are located in different MANET local
   routing regions separated by one or more transit Internetwork
   segments, both peers should include their IP addresses in global DNS
   resource records for the same reasons cited in Section 3.5.

   The peers then establish per-flow virtual circuits in the overlay to
   support peer-to-peer bidirectional packet forwarding.  The peers may
   use either an MNP address or their MLAs, as the MLAs are routable
   within the overlay limited domain.  The overlay therefore exhibits
   the outward appearance of a MANET-of-MANETs, where overlay interior
   nodes engage in an interdomain global routing service bridging many
   MANET local routing domains.

   A certain degree of coordination between peer nodes and the MSP is
   the required to maintain address mappings.  The MSP is responsible
   for ensuring that each peer remains reachable at its stable MNP/MLA
   addresses through distributed mobility management.

3.7.  Stub MANET to Not-so-stubby MANET Connections

   When an Internet connection sharing MANET router connects a stub
   MANET, it can either delegate public IP addresses to stub MANET nodes
   or delegate private IP addresses then apply Network Address
   Translation (NAT) to support external communications.

   In the public case, all manners of peer-to-peer communications are
   made possible due to the globally routable nature of the addresses.
   In the NAT case, only communications initiated by a stub network peer
   are supported since the reverse path terminates at the NAT.

   The stub MANET itself may configure a local overlay that regards the
   (multihop) MANET as a single unified link.  In that case, the stub
   network overlay link is distinct from the overlay link that spans the
   global public Internet and the two links are joined by an IPv6
   router.

   In the not-so-stubby case, a single overlay link extends across both
   any transit Internetworks and the source and target MANETs
   themselves.  All peer-to-peer communications are therefore conveyed
   across the common MANET Internetworking overlay.





Templin & Jakubisin      Expires 24 August 2026                 [Page 9]

Internet-Draft               AERO/OMNI MANET               February 2026


4.  IANA Considerations

   This document is informational and does not in itself request any
   IANA actions.  IANA considerations can be found in the solution space
   documents cited.

5.  Security Considerations

   This document is informational and does not in itself address
   security.  Security considerations can be found in the solution space
   documents cited.

6.  Acknowledgements

   This work is derived directly from "MANET Internetworking: Problem
   Statement and Gap Analysis" [I-D.templin-manet-inet].

   This work is aligned with the Boeing/Virginia Tech National Security
   Institute (VTNSI) 5G MANET research program.

   Honoring life, liberty and the pursuit of happiness.

7.  References

7.1.  Normative References

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
              DOI 10.17487/RFC0791, September 1981,
              <https://www.rfc-editor.org/info/rfc791>.

   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", STD 86, RFC 8200,
              DOI 10.17487/RFC8200, July 2017,
              <https://www.rfc-editor.org/info/rfc8200>.

7.2.  Informative References

   [I-D.templin-6man-aero3]
              Templin, F., "Automatic Extended Route Optimization
              (AERO)", Work in Progress, Internet-Draft, draft-templin-
              6man-aero3-52, 23 January 2026,
              <https://datatracker.ietf.org/doc/html/draft-templin-6man-
              aero3-52>.








Templin & Jakubisin      Expires 24 August 2026                [Page 10]

Internet-Draft               AERO/OMNI MANET               February 2026


   [I-D.templin-6man-mla]
              Templin, F., "IPv6 Addresses for Ad Hoc Networks", Work in
              Progress, Internet-Draft, draft-templin-6man-mla-30, 11
              November 2025, <https://datatracker.ietf.org/doc/html/
              draft-templin-6man-mla-30>.

   [I-D.templin-6man-omni3]
              Templin, F., "Transmission of IP Packets over Overlay
              Multilink Network (OMNI) Interfaces", Work in Progress,
              Internet-Draft, draft-templin-6man-omni3-73, 6 February
              2026, <https://datatracker.ietf.org/doc/html/draft-
              templin-6man-omni3-73>.

   [I-D.templin-manet-inet]
              Templin, F. and D. J. Jakubisin, "MANET Internetworking:
              Problem Statement and Gap Analysis", Work in Progress,
              Internet-Draft, draft-templin-manet-inet-02, 12 January
              2026, <https://datatracker.ietf.org/doc/html/draft-
              templin-manet-inet-02>.

   [RFC2501]  Corson, S. and J. Macker, "Mobile Ad hoc Networking
              (MANET): Routing Protocol Performance Issues and
              Evaluation Considerations", RFC 2501,
              DOI 10.17487/RFC2501, January 1999,
              <https://www.rfc-editor.org/info/rfc2501>.

   [RFC4429]  Moore, N., "Optimistic Duplicate Address Detection (DAD)
              for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006,
              <https://www.rfc-editor.org/info/rfc4429>.

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              DOI 10.17487/RFC4861, September 2007,
              <https://www.rfc-editor.org/info/rfc4861>.

   [RFC6621]  Macker, J., Ed., "Simplified Multicast Forwarding",
              RFC 6621, DOI 10.17487/RFC6621, May 2012,
              <https://www.rfc-editor.org/info/rfc6621>.

   [RFC6762]  Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
              DOI 10.17487/RFC6762, February 2013,
              <https://www.rfc-editor.org/info/rfc6762>.

   [RFC8415]  Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
              Richardson, M., Jiang, S., Lemon, T., and T. Winters,
              "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
              RFC 8415, DOI 10.17487/RFC8415, November 2018,
              <https://www.rfc-editor.org/info/rfc8415>.



Templin & Jakubisin      Expires 24 August 2026                [Page 11]

Internet-Draft               AERO/OMNI MANET               February 2026


   [RFC8799]  Carpenter, B. and B. Liu, "Limited Domains and Internet
              Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020,
              <https://www.rfc-editor.org/info/rfc8799>.

   [RFC9374]  Moskowitz, R., Card, S., Wiethuechter, A., and A. Gurtov,
              "DRIP Entity Tag (DET) for Unmanned Aircraft System Remote
              ID (UAS RID)", RFC 9374, DOI 10.17487/RFC9374, March 2023,
              <https://www.rfc-editor.org/info/rfc9374>.

   [RFC9663]  Colitti, L., Linkova, J., Ed., and X. Ma, Ed., "Using
              DHCPv6 Prefix Delegation (DHCPv6-PD) to Allocate Unique
              IPv6 Prefixes per Client in Large Broadcast Networks",
              RFC 9663, DOI 10.17487/RFC9663, October 2024,
              <https://www.rfc-editor.org/info/rfc9663>.

   [RFC9762]  Colitti, L., Linkova, J., Ma, X., Ed., and D. Lamparter,
              "Using Router Advertisements to Signal the Availability of
              DHCPv6 Prefix Delegation to Clients", RFC 9762,
              DOI 10.17487/RFC9762, June 2025,
              <https://www.rfc-editor.org/info/rfc9762>.

Appendix A.  Change Log

   << RFC Editor - remove prior to publication >>

   Differences from -00 to -01:

   *  Clarified that the routing scope for MLAs is the entire overlay
      limited domain.

   Differences from earlier versions:

   *  First draft publication.

Authors' Addresses

   Fred L. Templin (editor)
   Boeing Technology Innovation
   P.O. Box 3707
   Seattle, WA 98124
   United States of America
   Email: fltemplin@acm.org









Templin & Jakubisin      Expires 24 August 2026                [Page 12]

Internet-Draft               AERO/OMNI MANET               February 2026


   Daniel J. Jakubisin
   National Security Institute, Virginia Tech
   2202 Kraft Dr.
   Blacksburg, VA 24060
   United States of America
   Email: djj@vt.edu













































Templin & Jakubisin      Expires 24 August 2026                [Page 13]


name: draft-luan-rtgwg-sdaf
rev: 00
title: Symmetry-Driven Asynchronous Forwarding with Fast Reroute for LEO Satellite Networks (SDAF)
time: 2026-02-25T16:20:58Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-29T16:20:58Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Autonomous netops", "A2A protocols"]
tags: []
fetched_at: 2026-02-27T22:56:10.243511+00:00
abstract:
Interior Gateway Protocols (IGPs) such as OSPF are commonly employed
   in satellite networks to address topology awareness and autonomous
   routing in response to link interruptions, link/node failures, and
   subsequent repairs.  However, IGP-based approaches suffer from
   inherent limitations.  Synchronization delays between the control
   plane and the forwarding plane can cause routing black holes, while
   asynchronous convergence across nodes may induce micro-loops (as
   described in prior work), leading to packet loss and congestion.
   These issues are particularly exacerbated in satellite networks
   characterized by highly dynamic topologies, long inter-satellite
   propagation delays, and constrained on-board computing resources.

   This document describes the Symmetry-Driven Asynchronous Forwarding
   (SDAF) mechanism, which leverages the intrinsic symmetry of toroidal
   topologies in satellite networks.  Low Earth Orbit (LEO) satellite
   constellations are typically composed of multiple circular orbital
   planes, forming a toroidal topology by inter-satellite links.  SDAF
   autonomously triggers and processes reverse flows based solely on
   local link-state information, without requiring control-plane
   convergence, protocol extensions, or packet header modifications.

   SDAF is fully compatible with existing protocols and technologies
   such as OSPFv3, IS-IS, and MPLS, and is specifically tailored to the
   resource-constrained nature of satellite systems.  It achieves
   microsecond-scale convergence and low packet loss under failure
   conditions.

   Simulation results and tests conducted on actual satellite routers
   demonstrate that the SDAF mechanism significantly suppresses packet
   loss caused by routing black holes and micro-loops, while also
   alleviating link congestion and packet reordering issues.

full_text:
rtgwg                                                            S. Luan
Internet-Draft                                        Beihang University
Intended status: Informational                                    W. Wei
Expires: 29 August 2026                                            M. Ke
                                                       Xidian University
                                                               H. Dongxu
                                                                  X. Min
                                                         ZTE Corporation
                                                        25 February 2026


   Symmetry-Driven Asynchronous Forwarding with Fast Reroute for LEO
                       Satellite Networks (SDAF)
                        draft-luan-rtgwg-sdaf-00

Abstract

   Interior Gateway Protocols (IGPs) such as OSPF are commonly employed
   in satellite networks to address topology awareness and autonomous
   routing in response to link interruptions, link/node failures, and
   subsequent repairs.  However, IGP-based approaches suffer from
   inherent limitations.  Synchronization delays between the control
   plane and the forwarding plane can cause routing black holes, while
   asynchronous convergence across nodes may induce micro-loops (as
   described in prior work), leading to packet loss and congestion.
   These issues are particularly exacerbated in satellite networks
   characterized by highly dynamic topologies, long inter-satellite
   propagation delays, and constrained on-board computing resources.

   This document describes the Symmetry-Driven Asynchronous Forwarding
   (SDAF) mechanism, which leverages the intrinsic symmetry of toroidal
   topologies in satellite networks.  Low Earth Orbit (LEO) satellite
   constellations are typically composed of multiple circular orbital
   planes, forming a toroidal topology by inter-satellite links.  SDAF
   autonomously triggers and processes reverse flows based solely on
   local link-state information, without requiring control-plane
   convergence, protocol extensions, or packet header modifications.

   SDAF is fully compatible with existing protocols and technologies
   such as OSPFv3, IS-IS, and MPLS, and is specifically tailored to the
   resource-constrained nature of satellite systems.  It achieves
   microsecond-scale convergence and low packet loss under failure
   conditions.

   Simulation results and tests conducted on actual satellite routers
   demonstrate that the SDAF mechanism significantly suppresses packet
   loss caused by routing black holes and micro-loops, while also
   alleviating link congestion and packet reordering issues.



Luan, et al.             Expires 29 August 2026                 [Page 1]

Internet-Draft                SDAF for LEO                 February 2026


Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 29 August 2026.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Problem Statement . . . . . . . . . . . . . . . . . . . .   3
       1.1.1.  Onboard Characteristics of Satellite Networks . . . .   3
       1.1.2.  Inherent Deficiencies of Asynchronous Convergence . .   4
       1.1.3.  Limitations of Existing Approaches  . . . . . . . . .   4
     1.2.  Requirements Language . . . . . . . . . . . . . . . . . .   5
     1.3.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     1.4.  Document Structure  . . . . . . . . . . . . . . . . . . .   5
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   6
   3.  Core Principles . . . . . . . . . . . . . . . . . . . . . . .   7
     3.1.  Enforcing Routing Paths via Rotational Symmetry . . . . .   7
     3.2.  Forming Forward/Reverse Flows via Reflectional
           Symmetry  . . . . . . . . . . . . . . . . . . . . . . . .   8
   4.  Detailed Procedures . . . . . . . . . . . . . . . . . . . . .   9
     4.1.  Initialization  . . . . . . . . . . . . . . . . . . . . .   9



Luan, et al.             Expires 29 August 2026                 [Page 2]

Internet-Draft                SDAF for LEO                 February 2026


     4.2.  Failure/Disruption Detection  . . . . . . . . . . . . . .  10
     4.3.  Reverse-Flow Triggering . . . . . . . . . . . . . . . . .  10
       4.3.1.  RF-CF Policy  . . . . . . . . . . . . . . . . . . . .  10
       4.3.2.  RF-LF Policy  . . . . . . . . . . . . . . . . . . . .  10
     4.4.  Reverse-Flow Forwarding and Transition  . . . . . . . . .  11
     4.5.  Recovery from Failures/Disruptions  . . . . . . . . . . .  11
   5.  Failure Scenario Handling . . . . . . . . . . . . . . . . . .  12
     5.1.  Single-Link Failure . . . . . . . . . . . . . . . . . . .  12
     5.2.  Boundary Conditions and Limitations . . . . . . . . . . .  13
   6.  Interoperability with Existing Protocols and Technologies . .  14
   7.  Key Characteristics . . . . . . . . . . . . . . . . . . . . .  14
     7.1.  Core Advantages . . . . . . . . . . . . . . . . . . . . .  14
     7.2.  Limitations . . . . . . . . . . . . . . . . . . . . . . .  14
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
   10. Normative References  . . . . . . . . . . . . . . . . . . . .  15
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  15
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

1.  Introduction

1.1.  Problem Statement

1.1.1.  Onboard Characteristics of Satellite Networks

   The onboard characteristics of satellite networks severely limit the
   applicability of conventional IGP routing approaches.

   Highly Dynamic Topology: In LEO constellations, inter-satellite links
   (ISLs) undergo frequent disruptions due to orbital motion and
   scheduled maneuvers such as solar avoidance -- representing
   predictable dynamics.  Additionally, unpredictable events like
   radiation-induced node or link failures introduce stochastic topology
   changes.  These continuous alterations constantly reshape the network
   topology, triggering repeated routing convergence processes that
   result in significant performance degradation, including packet loss,
   congestion, and reordering.  Traditional IGP schemes are designed for
   relatively stable topologies with sporadic failures and are
   inherently ill-suited to cope with the persistent and rapid dynamics
   inherent in LEO satellite networks.

   Stringent Resource Constraints: Satellite payloads operate under
   strict environmental limitations -- weight, power consumption, and
   thermal dissipation -- which directly constrain onboard computing
   resources.  Compared to terrestrial routers, satellite routers
   typically offer an order-of-magnitude lower CPU processing
   capability, only 1/10 to 1/5 of the memory capacity, and rely on



Luan, et al.             Expires 29 August 2026                 [Page 3]

Internet-Draft                SDAF for LEO                 February 2026


   limited solar-powered energy supply.  These constraints make it
   impractical to run high-overhead protocols or sustain intensive,
   continuous computations.  Conventional IGP approaches, however,
   require frequent topology flooding and repeated FIB updates to track
   dynamic changes -- generating substantial control-plane signaling
   traffic that consumes precious inter-satellite bandwidth and imposes
   unsustainable computational loads on resource-constrained satellite
   platforms.

1.1.2.  Inherent Deficiencies of Asynchronous Convergence

   The asynchronous convergence mechanism inherent in link-state IGP
   routing suffers significantly amplified negative effects in the
   context of satellite networks' highly dynamic topologies and
   stringent resource constraints, directly giving rise to three core
   issues that undermine forwarding continuity and reliability:

   Micro-loops: Asynchronous updates across nodes -- caused by control-
   plane synchronization delays such as IGP flooding and FIB
   installation -- lead to transient forwarding inconsistencies,
   resulting in micro-loops [RFC5715].  In satellite networks, the
   combination of high topology dynamics and long inter-satellite
   propagation delays dramatically extends both the duration and spatial
   scope of these micro-loops, exacerbating packet loss and congestion.

   Routing Black Holes: Upon sudden link or node failures, the control
   plane relies on mechanisms like Hello timeouts (typically >= 1
   second) and subsequent SPF (Shortest Path First) computations (tens
   to hundreds of milliseconds) -- processes that cannot be accelerated
   due to onboard resource limitations.  Consequently, routers retain
   stale FIB entries for extended periods, causing sustained packet
   drops and forming persistent routing black holes that are difficult
   to recover from promptly.

1.1.3.  Limitations of Existing Approaches

   Current loop-free convergence schemes (e.g., TI-LFA, SPRING) were not
   designed for satellite-specific constraints and thus fail to address
   the above issues:

   *  They assume topological stability and are ill-suited for the
      frequent, constant topology fluctuations in LEO constellations.
      Repeated path precomputation, control-plane flooding, and FIB
      updates result in convergence delays far exceeding millisecond-
      scale requirements while increasing microloop risk.






Luan, et al.             Expires 29 August 2026                 [Page 4]

Internet-Draft                SDAF for LEO                 February 2026


   *  They incur significant protocol overhead through extensions (e.g.,
      modified routing messages, new header fields) or continuous
      complex computation (e.g., global path planning, multiple backup
      paths).  Such overhead exceeds the computational, memory, and
      bandwidth budgets of satellite payloads, rendering these solutions
      impractical.

   To achieve global coverage and efficient packet forwarding, LEO
   satellite constellations commonly adopt torus-like topologies,
   constructing the network through symmetric intra-orbit and inter-
   orbit inter-satellite links.  Such architectures exhibit high
   rotational symmetry and a regular, grid-like distribution of inter-
   satellite links (often referred to as Grid+ topology).  This inherent
   structural regularity serves as a natural advantage for mitigating
   the adverse effects of topological dynamics.  Building on this
   foundation, this document proposes the SDAF mechanism.  The core idea
   of SDAF is to leverage the intrinsic symmetry of toroidal topologies
   to alleviate the convergence pressure imposed by frequent topological
   changes, thereby reducing reliance on control-plane coordination.
   SDAF enhances the resilience and reliability of packet forwarding in
   dynamic satellite networks.

1.2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

1.3.  Scope

   This document specifies the core design principles, forwarding
   decision procedures, LSD methodology, and integration approaches of
   the SDAF mechanism with link-state routing protocols (e.g., OSPFv3,
   IS-IS) and MPLS label switching.  It does not cover: hardware
   implementation details of SDAF, specific satellite payload hardware
   selection criteria, or extension schemes for non-toroidal topologies
   (which will be addressed in future documents).

1.4.  Document Structure

   This document is organized as follows:

   *  Section 2 defines key terms and abbreviations.

   *  Section 3 describes the core principles of *SDAF*.




Luan, et al.             Expires 29 August 2026                 [Page 5]

Internet-Draft                SDAF for LEO                 February 2026


   *  Section 4 specifies the end-to-end procedures for *SDAF*
      operation.

   *  Section 5 discusses failure scenario handling, including single-
      link, multi-link, and node failures.

   *  Section 6 describes interoperability with *OSPFv3*, *IS-IS*, and
      *MPLS*.

   *  Section 7 summarizes key characteristics, including advantages and
      limitations.

   *  Section 8 discusses security considerations.

   *  Section 9 provides *IANA* considerations.

2.  Terminology

   Full topology: The complete, fault-free topology of the satellite
   network.

   Defective topology: The connected subgraph of the full topology after
   a failure or disruption.

   Planned disruption: A predictable, temporary unavailability of an ISL
   due to orbital motion or solar avoidance.

   Unplanned failure: An unpredictable outage of an ISL or node due to
   internal or external factors.

   Link-State Detection (LSD): A local mechanism for detecting ISL
   disruptions or failures, with low-latency requirements.

   Hop Distance (HD): The number of hops on the shortest path between
   source and destination.

   Forward Flow (FF): Data forwarding along the shortest path, following
   decreasing Hop Distance (HD).

   Reverse Flow (RF): A temporary forwarding state triggered by failure,
   propagating opposite to FF with increasing HD.

   Primary Egress Interface (PEI): The egress ISL selected by the
   shortest-path algorithm for FF.

   Counter-facing Interface (CFI): The ISL diametrically opposite to the
   PEI within the toroidal topology.




Luan, et al.             Expires 29 August 2026                 [Page 6]

Internet-Draft                SDAF for LEO                 February 2026


   Lateral-facing Interface (LFI): The ISL orthogonal to the PEI; if
   multiple exist, the lowest-indexed is used.

   Interface Symmetry Mapping Table (ISMT): A node-local table mapping
   each PEI to its corresponding CFI and LFI.

   Local Interface Status Table (LIST): A node-local array recording the
   availability status of each interface.

   Phase (P): A logical indicator of flow direction: positive for FF,
   negative for RF.

   Phase Transition Point (PTP): A node where RF transitions back to FF,
   identified by the ingress interface not being equal to the local PEI.

   Reverse Flow with Counter-facing priority (RF-CF): An RF strategy
   prioritizing the CFI upon PEI failure.

   Reverse Flow with Lateral-facing priority (RF-LF): An RF strategy
   prioritizing the LFI upon PEI failure.

3.  Core Principles

   The SDAF mechanism leverages the rotational and reflectional
   symmetries inherent in toroidal topologies to enable autonomous
   forwarding-plane decisions, thereby addressing the core deficiencies
   of traditional routing under dynamic topologies and resource
   constraints.

3.1.  Enforcing Routing Paths via Rotational Symmetry

   In a ring topology -- a simplified special case of the toroidal
   topology -- satellite nodes are interconnected via intra-orbit ISL to
   form a closed loop, exhibiting 360 degrees rotational invariance.
   For example, the intra-orbital routing domains defined in [RFC9717]
   inherently constitute such ring structures within each orbital plane.
   When a satellite node's PEI becomes unavailable due to failure or
   scheduled interruption, rotational symmetry strictly constrains the
   only feasible detour to the CFI.  This constraint is not unique to
   SDAF.  The IGP routing will inevitably select the CFI, as the
   symmetry of the ring guarantees it is the sole valid route to the
   destination.

   When extended to a two-dimensional toroidal topology -- the typical
   architecture of multi-orbit LEO satellite constellations --
   rotational symmetry exhibits dual-dimensional characteristics.  Both
   the intra-orbit direction and the inter-orbit direction possess
   rotational invariance.  This dual-axis symmetry not only retains the



Luan, et al.             Expires 29 August 2026                 [Page 7]

Internet-Draft                SDAF for LEO                 February 2026


   CFI constraint from the one-dimensional ring case but also introduces
   LFIs to the PEI.  Under this structure, a node can determine its CFI
   and LFI solely through local knowledge of interface positions and
   their symmetric mappings in the intra- and inter-orbit dimensions,
   without requiring global topology computation.  Provided the network
   remains connected, both CFI- and LFI-based detours are guaranteed by
   the topological symmetry to reach the destination, ensuring that all
   locally selected recovery paths strictly adhere to the natural
   routing constraints imposed by the constellation's geometric
   regularity.

3.2.  Forming Forward/Reverse Flows via Reflectional Symmetry

   In a fault-free full topology, all shortest paths from any source
   node to a common destination are symmetric with respect to the mirror
   plane defined by the "destination node-topology center" axis.
   Moreover, these shortest paths always propagate along the minor arc
   -- the shorter segment between two points on the toroidal topology --
   which aligns with the core objective of shortest-path-first routing
   and constitutes the forward flow.

   When the PEI becomes unavailable due to failure or scheduled
   interruption, the forwarding plane autonomously selects either the
   CFI or a LFI based on the preconfigured policy (RF-CF or RF-LF) to
   forward packets before the control plane completes reconvergence.  At
   this point, the forwarding path deviates from the minor arc and
   enters the major arc, propagating in the direction opposite to the
   original shortest path.  Consequently, the HD to the destination no
   longer decreases but instead increases, forming a RF that is
   directionally opposed to the forward flow.

   Due to the constraint of reflection symmetry, once a reverse-flow
   packet crosses the mirror plane and re-enters the minor-arc region,
   it inevitably arrives at a PTP.  Here, the reflection symmetry
   inherently triggers an automatic switch in forwarding logic.  The
   packet ceases to propagate as a reverse flow along the major arc and
   instead transitions back to a forward flow along the minor arc,
   resuming adherence to the shortest-path-first routing strategy and
   continuing toward the destination.  This bidirectional flow
   transition occurs entirely without control-plane intervention, driven
   solely by topological reflection symmetry and local forwarding
   decisions, thereby ensuring continuous and reliable data delivery.









Luan, et al.             Expires 29 August 2026                 [Page 8]

Internet-Draft                SDAF for LEO                 February 2026


4.  Detailed Procedures

   All procedures of the SDAF mechanism are executed locally within the
   forwarding plane without requiring inter-node coordination.  The core
   process consists of five steps: initialization, fault/interruption
   detection, reverse-flow triggering, reverse-flow forwarding and
   convergence, and fault/interruption recovery.

4.1.  Initialization

   Before forwarding any data packets, each satellite node needs only to
   complete three local configuration and preparation steps.  The
   configuration logic depends on the number of node interfaces but is
   independent of the number of destinations:

   1.  Configure Interface Symmetry Mapping Table: Based on the complete
       physical topology connectivity, a static interface symmetry
       mapping table is preconfigured locally at each node for every
       physical interface.

   2.  Configure Reverse-Flow Policy: Choose one of two mutually
       exclusive policies of RF-CF or RF-LF.

       All nodes in the network MUST maintain consistent policy
       selection.

   3.  Initialize Link-State Detection (LSD): Enable the LSD mechanism,
       such as heartbeat packets or physical-layer signal monitoring, on
       all inter-satellite link (ISL) interfaces.

                                       B
                                       |
                               CLI:2   |   CLI:3
                               FLI:1,3 |   FLI:2,4
                                       |
                                     4 | 1
                              E -------A------- C
                                     3 | 2
                                       |
                               CLI:1   |   CLI:4
                               FLI:2,4 |   FLI:1,3
                                       |
                                       D

      Figure 1: Example local interface indexing and symmetry mapping
                           (CLI/FLI) for node A.





Luan, et al.             Expires 29 August 2026                 [Page 9]

Internet-Draft                SDAF for LEO                 February 2026


4.2.  Failure/Disruption Detection

   When a terminal on a satellite link meets either of the following
   conditions, the local interface status table is triggered to mark the
   corresponding interface as "unavailable":

   Failure: The Link-State Detection (LSD) mechanism detects that an
   interface has gone down or that its forwarding quality falls below
   the required threshold.

   Scheduled Interruption: The pre-provisioned interruption schedule
   from the control plane indicates that the current time has reached
   the designated moment for deactivating the interface.

4.3.  Reverse-Flow Triggering

   When an interface is marked as "unavailable," any data packet that,
   according to the forwarding table, would egress through that
   interface as its PEI immediately triggers the reverse-flow mechanism.
   This occurs without waiting for the control plane to synchronize
   link-state updates or complete network-wide reconvergence.  The
   execution logic for the two reverse-flow policies is as follows.

4.3.1.  RF-CF Policy

   The node first checks its local interface status table to determine
   whether the CFI is available:

   *  If the CFI is available, the packet is immediately forwarded
      through the CFI, thereby initiating a reverse flow.

   *  If the CFI is unavailable, the node inspects the two LFIs in the
      preconfigured order and selects the first available LFI for
      forwarding.

   *  If neither the CFI nor any LFI is available, the node is
      considered isolated, and the packet is dropped by default.

4.3.2.  RF-LF Policy

   The node first checks its local interface status table in the
   preconfigured order to determine the availability of the two LFIs and
   selects the first available LFI to forward the packet, thereby
   initiating a reverse flow.

   If both LFIs are unavailable, the node then checks the availability
   of the CFI:




Luan, et al.             Expires 29 August 2026                [Page 10]

Internet-Draft                SDAF for LEO                 February 2026


   *  If the CFI is available, the packet is forwarded through the CFI.

   *  If the CFI is also unavailable, the node is considered isolated,
      and the packet is dropped by default.

4.4.  Reverse-Flow Forwarding and Transition

   Upon receiving a data packet forwarded from another satellite node,
   any node processes it according to the following logic:

   1.  Record the ingress interface and consult the local forwarding
       table to determine the PEI associated with the packet's
       destination.

   2.  Compare the ingress interface with the local PEI:

       Case (1): Ingress interface matches the local PEI

       The receiving node identifies the packet as part of a reverse
       flow.  It then executes the reverse-flow handling procedure
       specified in Section 4.3.1 or Section 4.3.2, based on its
       preconfigured reverse-flow strategy.

       Case (2): Ingress interface differs from the local PEI

       The node forwards the packet via its local PEI.

       *  If the packet belongs to a forward flow, this step constitutes
          normal forwarding.

       *  If the packet belongs to a reverse flow, the current node acts
          as a PTP, where the reverse flow is converted back into a
          forward flow.

   Once a reverse flow is converted to a forward flow at a PTP, the
   packet proceeds toward its destination using standard forward-path
   forwarding logic.  However, if a link failure or scheduled
   interruption occurs along this newly established forward path, the
   reverse-flow mechanism is triggered again locally.  This cycle of
   forward-reverse flow switching continues iteratively until either the
   packet successfully reaches its destination or the hop count exceeds
   a predefined limit, at which point the packet is discarded.

4.5.  Recovery from Failures/Disruptions

   The local interface status table marks an interface as "available"
   when the terminal on a satellite link satisfies either of the
   following conditions:



Luan, et al.             Expires 29 August 2026                [Page 11]

Internet-Draft                SDAF for LEO                 February 2026


   Failure Recovery: The Link-State Detection (LSD) mechanism detects
   that a previously failed interface has come back up or that its
   forwarding quality has returned to an acceptable level.

   Scheduled Interruption Recovery: According to the interruption
   schedule pre-provisioned by the control plane, the current time
   reaches the designated moment for restoring the interface.

   Once the local interface status is updated to "available", the
   following actions are performed:

   *  Newly arriving packets whose destination maps to this interface as
      the PEI are immediately forwarded through it using the standard
      forward-flow logic.

   *  In-flight reverse-flow packets, which were already en route before
      the recovery, continue unchanged until they reach a PTP, where
      they revert to forward flow as originally planned.  This ensures
      continuity and avoids mid-path disruption, even before the control
      plane completes any associated reconvergence triggered by the
      recovery event.

5.  Failure Scenario Handling

   The SDAF mechanism is specifically designed for typical failure and
   scheduled interruption scenarios in LEO satellite networks with
   toroidal topologies.  All considered scenarios operate under the
   fundamental assumption that the impaired topology remains a connected
   subgraph of the full physical topology.  In cases where the topology
   becomes partitioned (i.e., splits into disconnected components), the
   mechanism, like conventional loop-free convergence schemes such as
   [RFC5715] , cannot guarantee reachability or path restoration.

   This section explicitly defines, for each failure scenario, the
   triggering conditions of the SDAF mechanism, the applicable reverse-
   flow policy selection, and the core reliability guarantees provided
   by the design.

5.1.  Single-Link Failure

   The single-link failure scenario applies to unpredictable failures or
   predictable interruptions affecting a single intra-orbit or inter-
   orbit ISL, under the condition that the toroidal or torus-like
   topology remains connected and both endpoints of the failed link
   retain at least one available symmetric interface.  Upon detecting
   the failure via LSD or receiving a scheduled interruption
   notification from the control plane, each endpoint marks the
   corresponding PEI as "unavailable" and immediately triggers a reverse



Luan, et al.             Expires 29 August 2026                [Page 12]

Internet-Draft                SDAF for LEO                 February 2026


   flow according to its preconfigured policy, rerouting traffic to
   bypass the faulty link.  Reverse-flow packets automatically switch
   back to forward flow at the nearest PTP, achieving loop-free
   convergence.  For intra-orbit link failures or ring-like topologies,
   RF-CF is preferred to leverage symmetric intra-orbit paths for rapid
   detour.  For inter-orbit link failures or when inter-orbit resources
   are sufficient, RF-LF is favored to avoid latency accumulation from
   intra-orbit looping.  Overall, this approach ensures micro-loop-free
   rerouting strictly bounded by topological symmetry and enables
   millisecond-scale, control-plane-independent data-plane recovery with
   minimal packet loss.  As shown in the figure below.

                                 (1)
                              <---- A_1 A_2
                              ---------A---------
                             | ---->       ----> |
                          B_1|    (4)       (5)  |G_2
                             B                   G
                       |  B_2|  ^                |G_1 |
                    (2)|     |  | (3)            |    |(6)
                       v  C_1|  |                |F_2 v
                             C                   F
                          C_2|                   |F_1 |
                             X                   |    |(7)
                          D_1|        (8)        |E_2 v
                             D       <----       E
                          D_2 ------------------- E_1

       Figure 2: Example reverse-flow forwarding and phase transition
                     (numbered steps are illustrative).

5.2.  Boundary Conditions and Limitations

   The SDAF mechanism provides fault-handling capabilities only for
   "connected impaired topologies", that is, scenarios where the network
   remains a single connected component despite link or node failures.
   If the topology becomes partitioned into multiple disconnected
   subgraphs, SDAF cannot construct valid end-to-end paths, and recovery
   must rely on higher-layer mechanisms such as routing protocol
   reconvergence.

   For predictable interruption scenarios (e.g., scheduled maintenance,
   orbital maneuvers), the handling logic is identical to that of
   equivalent failure types, with the sole difference lying in the
   failure detection phase.  Instead of relying on LSD for real-time
   anomaly identification, nodes receive advance notifications from the
   control plane about the timing of the upcoming interruption.




Luan, et al.             Expires 29 August 2026                [Page 13]

Internet-Draft                SDAF for LEO                 February 2026


6.  Interoperability with Existing Protocols and Technologies

   The SDAF mechanism is independent of protocols and requires no
   modifications to existing IGP routing protocols (e.g., OSPFv3, IS-IS)
   or forwarding technologies (e.g., IP forwarding, MPLS) commonly used
   in LEO satellite networks.

7.  Key Characteristics

7.1.  Core Advantages

   Dynamic Topology Adaptation: By leveraging the symmetry of the
   toroidal topology, SDAF enables resilient forwarding in dynamic
   scenarios such as link outages or node failures, without waiting for
   control-plane convergence, thereby reducing packet loss through
   asynchronous forwarding.

   Low Control-Plane Overhead: For link failures, forwarding decisions
   can be made solely based on local Link-State Detection and interface
   mapping tables, eliminating the need for control-plane flooding, SPF
   computation, or pre-planned path calculation, significantly reducing
   satellite resource consumption.

   Microsecond-Level Convergence: In the event of a failure, path
   switching is rapidly triggered via locally initiated reverse flows,
   achieving convergence latency of less than 1 ms, significantly faster
   than the tens to hundreds of milliseconds required by traditional
   approaches.

   Strong Protocol Compatibility: It can be directly integrated with
   link-state routing protocols such as OSPFv3 and IS-IS, as well as
   MPLS label forwarding, without requiring any modifications to
   protocol message formats or packet headers.

7.2.  Limitations

   The limitations of SDAF stem from its core design principle of
   relying on the symmetry of the toroidal topology, specifically
   including ineffective forwarding in highly asymmetric scenarios and
   increased transmission latency due to non-shortest-path forwarding.

8.  Security Considerations

   The SDAF mechanism inherits the security properties of existing LEO
   satellite communication protocols and introduces only a minimal
   additional attack surface.  Below are the key security considerations
   for LEO satellite constellations with a toroidal topology:




Luan, et al.             Expires 29 August 2026                [Page 14]

Internet-Draft                SDAF for LEO                 February 2026


   Link-State Spoofing: An attacker could forge link-failure signals to
   trigger unauthorized reverse flows.

   Mitigation: Link-State Detection (LSD) MUST rely on authenticated
   mechanisms at the physical or data link layer (e.g., frame checksums,
   signal characteristic verification) or leverage existing protocol
   authentication extensions (e.g., OSPFv3 authentication mechanisms
   [RFC4552]) to prevent false failure indications from triggering
   reverse flows.

9.  IANA Considerations

   This document has no IANA actions.

10.  Normative References

   [RFC9717]  Li, T., "A Routing Architecture for Satellite Networks",
              RFC 9717, DOI 10.17487/RFC9717, January 2025,
              <https://www.rfc-editor.org/info/rfc9717>.

   [RFC5715]  Shand, M. and S. Bryant, "A Framework for Loop-Free
              Convergence", RFC 5715, DOI 10.17487/RFC5715, January
              2010, <https://www.rfc-editor.org/info/rfc5715>.

   [RFC4552]  Gupta, M. and N. Melam, "Authentication/Confidentiality
              for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006,
              <https://www.rfc-editor.org/info/rfc4552>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

Acknowledgments

   The authors would like to thank colleagues and reviewers for their
   valuable feedback.

Contributors

   None.

Authors' Addresses




Luan, et al.             Expires 29 August 2026                [Page 15]

Internet-Draft                SDAF for LEO                 February 2026


   Shenshen Luan
   Beihang University
   Email: luanshenshen@buaa.edu.cn


   Wenting Wei
   Xidian University
   Email: wtwei@xidian.edu.cn


   Mingliang Ke
   Xidian University
   Email: ml.ke.xidian@foxmail.com


   Hou Dongxu
   ZTE Corporation
   Email: hou.dongxu@zte.com.cn


   Xiao Min
   ZTE Corporation
   Email: xiao.min2@zte.com.cn




























Luan, et al.             Expires 29 August 2026                [Page 16]


name: draft-mw-wimse-transitive-attestation
rev: 00
title: Transitive Attestation for Sovereign Workloads: A WIMSE Profile
time: 2026-02-26T03:22:45Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-30T03:22:45Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "AI safety/alignment", "Policy/governance"]
tags: []
fetched_at: 2026-02-27T22:56:10.243514+00:00
abstract:
This document defines a *WIMSE Profile* for Transitive Attestation
   within the Workload Identity in Multi-Service Environments (WIMSE)
   framework.  It addresses the critical problem of *Identity
   Portability*, where software credentials (e.g., bearer tokens or
   keys) can be misappropriated and used from unauthorized
   environments—a risk amplified by the emergence of autonomous *AI
   Agents* that may move across jurisdictions or be hijacked via *prompt
   injection attacks*. By providing a standardized *Identity Conveyance*
   mechanism, this profile cryptographically binds software workloads to
   their local execution environment ("Proof of Residency") through a
   transitive chain of trust.  This chain consumes *Evidence* from the
   underlying platform—supporting both *high-assurance* RATS-based
   profiles (e.g., [[!I-D.lkspa-wimse-verifiable-geo-fence]]) for
   residency verification and *standard* Workload Identity Agents for
   basic co-location proofs—to ensure that an identity is only valid
   when used from a verified, integral, or geographically compliant
   host.  The integrity and hardware-rooted security of the Workload
   Identity Agent itself is considered out-of-scope for this document
   and is addressed in the *Verifiable Geofencing* profile [[!I-D.lkspa-
   wimse-verifiable-geo-fence]].

full_text:
WIMSE                                                        R. Krishnan
Internet-Draft                                       JPMorgan Chase & Co
Intended status: Informational                                 A. Prasad
Expires: 29 August 2026                                           Oracle
                                                                D. Lopez
                                                              Telefonica
                                                            S. Addepalli
                                                                  Aryaka
                                                        25 February 2026


    Transitive Attestation for Sovereign Workloads: A WIMSE Profile
                draft-mw-wimse-transitive-attestation-00

Abstract

   This document defines a *WIMSE Profile* for Transitive Attestation
   within the Workload Identity in Multi-Service Environments (WIMSE)
   framework.  It addresses the critical problem of *Identity
   Portability*, where software credentials (e.g., bearer tokens or
   keys) can be misappropriated and used from unauthorized
   environments—a risk amplified by the emergence of autonomous *AI
   Agents* that may move across jurisdictions or be hijacked via *prompt
   injection attacks*. By providing a standardized *Identity Conveyance*
   mechanism, this profile cryptographically binds software workloads to
   their local execution environment ("Proof of Residency") through a
   transitive chain of trust.  This chain consumes *Evidence* from the
   underlying platform—supporting both *high-assurance* RATS-based
   profiles (e.g., [[!I-D.lkspa-wimse-verifiable-geo-fence]]) for
   residency verification and *standard* Workload Identity Agents for
   basic co-location proofs—to ensure that an identity is only valid
   when used from a verified, integral, or geographically compliant
   host.  The integrity and hardware-rooted security of the Workload
   Identity Agent itself is considered out-of-scope for this document
   and is addressed in the *Verifiable Geofencing* profile [[!I-D.lkspa-
   wimse-verifiable-geo-fence]].

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.





Krishnan, et al.         Expires 29 August 2026                 [Page 1]

Internet-Draft               WIMSE-TRANS-POR               February 2026


   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 29 August 2026.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Scope and Boundaries  . . . . . . . . . . . . . . . . . . . .   4
   4.  The Solution: Transitive Attestation for Proof of
           Residency . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.1.  mTLS-based Transitive Attestation . . . . . . . . . . . .   5
       4.1.1.  mTLS PoR Protocol Flow  . . . . . . . . . . . . . . .   5
     4.2.  Demonstrating Proof of Residency (DPoR) . . . . . . . . .   6
       4.2.1.  DPoR Protocol Flow  . . . . . . . . . . . . . . . . .   6
     4.3.  Confidential Computing and Hardware-Rooted Binding  . . .   7
       4.3.1.  Logical Quoting Enclave . . . . . . . . . . . . . . .   7
       4.3.2.  Channel Binding via TLS Exporter  . . . . . . . . . .   8
       4.3.3.  Relying Party Verification Loop . . . . . . . . . . .   8
   5.  Relation to Other IETF Work . . . . . . . . . . . . . . . . .   9
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   This document defines the *WIMSE Profile* for "Transitive
   Attestation", addressing a critical technical gap in the high-level
   *WIMSE Architecture* [[!I-D.ietf-wimse-arch]] regarding how platform-
   level trust is transitively extended to software workloads.




Krishnan, et al.         Expires 29 August 2026                 [Page 2]

Internet-Draft               WIMSE-TRANS-POR               February 2026


   Currently, workload identities are often "context-agnostic"—once a
   credential (e.g., a bearer token) is issued, it can often be used
   from any environment.  This *Identity Portability* allows an attacker
   who steals a token in one jurisdiction to use it from another,
   representing a significant *Sovereignty Violation* for workloads
   legally required to operate within specific boundaries.  This is
   particularly critical for *AI Agents*, whose autonomous nature,
   susceptibility to hijacking via *prompt injection attacks*, and
   potential for rapid migration across cloud environments require
   strict, verifiable adherence to data residency and host integrity
   policies.

   By addressing the *North-South* security axis of a workload's
   relationship with its local hosting environment, this profile
   establishes a *"Silicon-to-SVID"* chain of accountability.  It
   ensures that the Workload Identity Agent (the local agent) is
   empowered to issue identities that are cryptographically bound to a
   verified execution context.  This mechanism is flexible across
   assurance levels: it supports *High Assurance* residency verification
   rooted in hardware evidence (e.g., TPM/TEE), as well as *Standard
   Assurance* local co-location proofs provided by conventional workload
   agents.

   This draft acts as the *Conveyance Layer* that integrates with the
   findings of a *RATS Profile* (such as *Verifiable Geofencing* [[!I-
   D.lkspa-wimse-verifiable-geo-fence]]) to establish two distinct
   levels of assurance:

   *  *Co-location Verification*: A logical binding that ensures the
      workload and its agent are currently co-located on the same host,
      typically enforced via operating system isolation and local
      communication channels (e.g., Unix Domain Sockets).
   *  *Residency Verification (High Assurance)*: A high-assurance
      binding where the Workload Identity Agent itself is proven to be
      integral and rooted in hardware.  This ensures the identity is
      functionally "sticky" to the verified residence via a *Fast Path*
      renewal which uses cached attestation results.

   A workload obtains a fresh signature or proof from a local Workload
   Identity Agent, typically utilizing a *Workload Fusion Nonce
   (N_fusion)* to prevent replay.  This ensures the identity—and the
   usage of its associated credentials—is sensitive to the physical or
   logical residence of the workload, complementing the "East-West"
   delegation models.  Re-attestation follows a *Tiered Schedule* (see
   [[!I-D.lkspa-wimse-verifiable-geo-fence]]), separating frequent
   identity renewal from heavyweight platform evidence collection.





Krishnan, et al.         Expires 29 August 2026                 [Page 3]

Internet-Draft               WIMSE-TRANS-POR               February 2026


2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [[RFC2119]] [[RFC8174]] when, and only when, they appear in all
   capitals, as shown here.

   This document leverages the terminology defined in the RATS
   Architecture [[RFC9334]] and the WIMSE Architecture [[!I-D.ietf-
   wimse-arch]].

   Workload Identity Agent (Workload Identity Agent):  A local entity
      that acts as an *Attester* or *Attestation Intermediate* in the
      RATS framework.  It is responsible for providing Evidence or
      Attestation Results to a workload.
   Proof of Residency (PoR) / Co-location:  A cryptographic proof that
      binds a workload's current execution session to a specific,
      verified local environment or host.
   N_fusion (Workload Fusion Nonce):  A nonce provided by the Relying
      Party specifically for the workload-to-agent fusion flow.  It
      ensures the freshness of the residency proof and cryptographically
      binds the workload's request to the local agent's attestation.

   Workload identities are often represented by bearer tokens or keys
   that, once compromised, can be used by an attacker from any
   environment.  This "portability" allows an attacker who achieves RCE
   on a workload (e.g., in Region A) or hijacks an AI agent's logic via
   *prompt injection* to use the stolen keys or intercepted tokens from
   an attacking machine (e.g., in Region B).

   In the context of *Sovereign Workloads*, this portability is more
   than a technical vulnerability; it is a *Sovereignty Violation*. If a
   workload is legally or logically required to operate within a
   specific jurisdiction, any identity that can be successfully verified
   from outside that jurisdiction represents a failure of the sovereign
   boundary.  Relying Parties currently lack a standardized way to
   ensure that a presented identity is being used from the same verified
   host that was originally authorized.

3.  Scope and Boundaries

   This document focuses on the *Identity Conveyance* and *Session
   Binding* mechanisms required for Transitive Attestation.  It
   standardizes how a workload proves its co-location with a local agent
   and how that proof is bound to application sessions (e.g., mTLS or
   DPoP).




Krishnan, et al.         Expires 29 August 2026                 [Page 4]

Internet-Draft               WIMSE-TRANS-POR               February 2026


   The following areas are explicitly *OUT OF SCOPE* for this profile:

   *  *Agent Identity and Integrity*: The mechanism by which a Workload
      Identity Agent (e.g., SPIRE Agent) proves its own identity and
      code integrity to a remote verifier.
   *  *Platform Attestation*: The collection and verification of
      hardware-level evidence (TPM quotes, TEE measurements) for the
      host platform.
   *  *Workload Identity Manager Interactions*: The specific protocols
      and APIs for obtaining nonces or credentials from a *Workload
      Identity Manager (WIM Manager)* during the issuance phase (e.g.,
      SVID CSRs).

   These security guarantees are provided by the underlying *RATS
   Profile* for *Verifiable Geofencing* [[!I-D.lkspa-wimse-verifiable-
   geo-fence]].  This WIMSE profile assumes that the Workload Identity
   Agent is operating in a verified, integral state as established by
   the Geofencing layer.

4.  The Solution: Transitive Attestation for Proof of Residency

   "Transitive Attestation" establishes a chain of trust from a hardware
   root through a local agent to the workload.  The Workload Identity
   Agent provides the workload with a "live" proof that it is currently
   resident on the verified host.  This local peer-to-peer connection is
   typically enforced through a *Unix Domain Socket (UDS)*, providing a
   kernel-level guarantee that the workload is co-located with the
   hardware-rooted agent.

4.1.  mTLS-based Transitive Attestation

   In an mTLS environment, the Proof of Residency (PoR) is bound to the
   mutually authenticated session and the local execution context via a
   transitive chain of trust.

4.1.1.  mTLS PoR Protocol Flow

   The mTLS-based flow integrates residency verification into the
   session establishment and validation phase:

   1.  *Certificate Extensions*: The client (workload) supplies an X.509
       certificate during the mTLS handshake containing a custom
       extension.  This extension includes the public key or SVID
       details of the local Workload Identity Agent (Attester).
   2.  *Post-Handshake Nonce*: After the mTLS handshake is successfully
       completed, the client requests a residency-specific nonce from
       the *Verifier* (e.g., Relying Party) to ensure anti-replay.




Krishnan, et al.         Expires 29 August 2026                 [Page 5]

Internet-Draft               WIMSE-TRANS-POR               February 2026


   3.  *Local Attestation Binding*: The client constructs a PoR
       assertion payload containing:
       *  A cryptographic hash of the TLS Exporter value [[RFC5705]].
       *  The residency nonce provided by the server.
       *  A timestamp representing the current time of assertion
          creation.

   |  [!NOTE] By binding to the TLS Exporter instead of the application
   |  traffic keys, the Proof of Residency remains valid across TLS 1.3
   |  KeyUpdate operations.  Standard key rotation refreshes traffic
   |  keys but does not change the exporter master secret, thus avoiding
   |  unnecessary re-attestation cycles while maintaining strong
   |  cryptographic binding to the session.

   4.  *Agent Signature*: The client sends this payload to the local
       Workload Identity Agent (typically via a Unix Domain Socket).
       The Workload Identity Agent verifies the local peer environment
       and signs the payload with its private key.
   5.  *PoR Submission*: The client sends this attested response to the
       resource server for verification.
   6.  *Server Verification*: The *Verifier* performs a joint
       verification of identity and residency:
       *  *Identity*: Verifies the client certificate as part of
          standard mTLS.
       *  *Residency*: Verifies the PoR assertion signature against the
          Workload Identity Agent public key found in the client's
          certificate extension.
       *  *Binding and Freshness*: Ensures that the TLS Exporter hash,
          the nonce, and the timestamp match the current active session
          and are within an acceptable freshness window.

   Upon successful verification, the resource server has proof that the
   client identity (presented via mTLS) is currently resident in the
   same authorized environment as the verified Workload Identity Agent.

4.2.  Demonstrating Proof of Residency (DPoR)

   "Demonstrating Proof of Residency" (DPoR) is an enhancement to the
   Demonstrating Proof-of-Possession (DPoP) mechanism defined in
   [[RFC9449]].  While DPoP ensures _possession_ of a private key held
   by the client, DPoR ensures the physical or logical _residency_ of
   the workload using that key by binding the request to a local
   attestation.

4.2.1.  DPoR Protocol Flow

   The DPoR flow integrates residency verification into the per-request
   application-level authorization:



Krishnan, et al.         Expires 29 August 2026                 [Page 6]

Internet-Draft               WIMSE-TRANS-POR               February 2026


   1.  *Nonced Request*: The *Verifier* SHOULD provide a residency-
       specific nonce (e.g., via a DPoR-Nonce header) to the client to
       ensure anti-replay of the residency proof.
   2.  *Local Attestation Binding*: The client constructs a DPoR
       assertion payload containing:
       *  The hash of the DPoP public key used for the request (e.g.,
          the jkt thumbprint).
       *  The residency nonce provided by the server.
       *  A timestamp representing the current time of assertion
          creation.
   3.  *Agent Signature*: The client sends this payload to the local
       Workload Identity Agent (typically via a Unix Domain Socket).
       The Workload Identity Agent (acting as an Attester) verifies the
       local execution context and signs the payload with its private
       key.
   4.  *DPoR Assertion Submission*: The client includes the resulting
       signature in a DPoR header or as an extension to the DPoP JWT.
   5.  *Server Verification*: The *Verifier* performs a joint
       verification of possession and residency:
       *  *Possession*: Verifies the DPoP proof as per [[RFC9449]].
       *  *Residency*: Verifies the DPoR assertion signature against the
          Workload Identity Agent public key.
       *  *Binding and Freshness*: Ensures that the jkt (DPoP key
          thumbprint), the nonce, and the timestamp in the residency
          proof match the current request and are within an acceptable
          freshness window.

   This binding ensures that a DPoP key cannot be "exported" and used
   from a different machine, as the resource server would detect the
   lack of a valid, hardware-rooted residency proof for that specific
   key from the new environment.

4.3.  Confidential Computing and Hardware-Rooted Binding

   In Confidential Computing (CC) environments, the Relationship between
   high-level workload identities and hardware-rooted evidence is
   formalized through specific architectural patterns.  This section
   details how Transitive Attestation bridges the gap between hardware
   quotes and application-layer identities.

4.3.1.  Logical Quoting Enclave

   In a Transitive Attestation model, trust is passed through a chain of
   components.

   *  *Hardware Layer*: A Confidential Computing environment (e.g.,
      Intel TDX or SGX) provides a "Hardware Root of Trust."




Krishnan, et al.         Expires 29 August 2026                 [Page 7]

Internet-Draft               WIMSE-TRANS-POR               February 2026


   *  *Intermediate Layer (Workload Identity Agent)*: In this profile,
      the Workload Identity Agent (e.g., a SPIRE Agent) is treated as
      the trusted software component that "vouches" for the workloads.
   *  *Logical Equivalent*: By running the Workload Identity Agent
      inside a TEE (Trusted Execution Environment), the hardware can
      attest to the integrity of the agent.  This allows the agent to
      act as a "Compliance Bridge" as defined in [[!I-D.lkspa-wimse-
      verifiable-geo-fence]].  Just as a hardware *Quoting Enclave (QE)*
      signs a local report to turn it into a globally verifiable
      "Quote," the Workload Identity Agent (running in a TEE) signs
      Workload Identity Documents (SVIDs/WITs).  Effectively, the agent
      becomes a _logical_ quoting enclave that bridges hardware-rooted
      trust to software-level workload identities.

4.3.2.  Channel Binding via TLS Exporter

   To prevent man-in-the-middle (MITM) and replay attacks, the hardware
   evidence must be cryptographically bound to the communication
   channel.  This is achieved using the *TLS Exporter* [[RFC5705]].

   *  *The Mechanism*: RFC 5705 allows both sides of a TLS session to
      derive a unique, secret value (the Exporter) that is bound to that
      specific handshake.
   *  *The Binding*: The workload places a hash of this TLS Exporter
      value into the *User Defined Data* field of the CC quote (e.g.,
      ReportData in SGX or RTMR in TDX).
   *  *Security Property*: This cryptographically binds the hardware
      evidence to that specific TLS session.  If an attacker attempts to
      reuse the same quote on a different TLS session, the Exporter
      values will not match, and the verification will fail.

4.3.3.  Relying Party Verification Loop

   The Relying Party (Verifier) completes the trust loop by performing
   the following steps:

   |  [!NOTE] The Relying Party (which may be the Resource Server or an
   |  API Gateway/Proxy acting on its behalf) extracts the TLS Exporter
   |  value.

   1.  *Hardware Verification*: Receives the CC Quote and verifies the
       hardware signature (proving the code is running in a real TEE).
   2.  *Extractor*: Extracts the TLS Exporter value (or its hash) from
       the quote's metadata (User Defined Data).
   3.  *Comparison*: Compares this value to its own locally computed TLS
       Exporter value for the current active connection.





Krishnan, et al.         Expires 29 August 2026                 [Page 8]

Internet-Draft               WIMSE-TRANS-POR               February 2026


   4.  *Enforcement*: If they match, the Relying Party is certain that
       the entity it is talking to via TLS is the _exact same entity_
       that generated the hardware attestation.

   This architecture ensures that identity is not just a bearer token,
   but is cryptographically tied to the verified runtime environment and
   the specific communication channel.

5.  Relation to Other IETF Work

    +==============+==============+=========+=========================+
    | Layer        | Component    | WG      | Core Responsibility     |
    +==============+==============+=========+=========================+
    | *Layer 1*    | *Transitive  | *WIMSE* | *Conveyance*: Binds     |
    |              | Attestation* |         | identity to the local   |
    |              |              |         | agent (Co-location/     |
    |              |              |         | Residency).             |
    +--------------+--------------+---------+-------------------------+
    | *Layer 2*    | *Verifiable  | *RATS*  | *Platform Evidence*:    |
    |              | Geofencing*  |         | Verifies host integrity |
    |              |              |         | and Workload Identity   |
    |              |              |         | Agent hardware          |
    |              |              |         | residency (TPM).        |
    +--------------+--------------+---------+-------------------------+
    | *Layer 3*    | *Verifiable  | *RATS*  | *Location Evidence*:    |
    |              | Geofencing*  |         | Verifies physical       |
    |              |              |         | geography (GNSS/ZKP).   |
    +--------------+--------------+---------+-------------------------+
    | *Delegation* | *Actor       | *SPICE* | Provides *East-West*    |
    |              | Chain*       |         | identity delegation     |
    |              |              |         | proof [[!I-D.draft-mw-  |
    |              |              |         | spice-actor-chain]].    |
    +--------------+--------------+---------+-------------------------+
    | *Shield*     | *SPICE*      | *SPICE* | Employs Selective       |
    |              |              |         | Disclosure (SD-CWT) to  |
    |              |              |         | protect residency/      |
    |              |              |         | geographic privacy.     |
    +--------------+--------------+---------+-------------------------+

                                  Table 1

   1.  *Transitive Attestation (WIMSE) - Layer 1 (Conveyance)*: This
       document act as the technical integrator profile for WIMSE.  It
       standardizes how local context results are transitively extended
       to workloads.  It reflects its status as the *Consumer* of
       attestation results to address the *North-South* identity
       portability problem.




Krishnan, et al.         Expires 29 August 2026                 [Page 9]

Internet-Draft               WIMSE-TRANS-POR               February 2026


   2.  *Verifiable Geofencing (RATS) - Layer 2 & 3 (Evidence)*: Defined
       in [[!I-D.lkspa-wimse-verifiable-geo-fence]].  This document acts
       as the *RATS Profile* that provides the hardware-rooted
       foundation (TPM, Silicon Root of Trust, GNSS) and the out-of-band
       monitoring required to verify the Workload Identity Agent itself.
       It generates the high-assurance evidence that Layer 1 consumes.
   3.  *Actor Chain - The Delegation*: Complements this draft by
       addressing the *East-West* axis of agent-to-agent communication
       [[!I-D.draft-mw-spice-actor-chain]].  While Transitive
       Attestation proves _where_ an actor is running (North-South), the
       Actor Chain proves _who_ called whom across the network (East-
       West).
   4.  *SPICE (Secure Patterns for Internet Credential Exchange) - The
       Shield*: Utilizes Selective Disclosure (SD-CWT) to protect
       sensitive location data.  It allows a workload to prove residency
       within a broad "Sovereign Zone" without revealing precise GPS
       coordinates, balancing security with privacy.

   Additional relationships include:

   *  *Verifiable Geofencing [[!I-D.lkspa-wimse-verifiable-geo-fence]]*:
      Provides the normative technical specification for Layer 2 and
      Layer 3 attestation.  This draft (Transitive Attestation) acts as
      the application-layer profile that implements these residency
      proofs within mTLS and DPoP flows, fulfilling the "Silicon-to-
      SVID" chain.
   *  *WIMSE Architecture [[!I-D.ietf-wimse-arch]]*: This draft provides
      the technical fulfillment for the secure agent requirements and
      thread model mitigations (e.g., token theft) defined in the
      architecture.

6.  Security Considerations

   Proof of Residency or Co-location specifically mitigates the "Stolen
   Credential Portability" threat, which encompasses both stolen private
   keys and stolen bearer/DPoP tokens.

   An attacker who steals a private key or intercepts an active token
   from a workload cannot use those credentials from an external
   environment.  Any attempt to use the stolen credential requires a
   corresponding PoR assertion that is:

   1.  *Locally Attested*: Linked to the local Workload Identity Agent's
       signing interface, typically protected by OS permissions or
       hardware roots.
   2.  *Context-Specific*: Bound to a fresh, server-provided nonce and a
       current timestamp.




Krishnan, et al.         Expires 29 August 2026                [Page 10]

Internet-Draft               WIMSE-TRANS-POR               February 2026


   3.  *Protected*: Access to the Workload Identity Agent's signing
       capability is restricted by local Operating System permissions
       and logical isolation.

   Consequently, credentials become functionally "sticky" to the
   verified residence; an attacker cannot generate a valid proof without
   achieving a compromise of the identity agent itself.  While a
   software-based agent provides strong logical isolation, a hardware-
   rooted agent (see [[!I-D.lkspa-wimse-verifiable-geo-fence]]) provides
   the highest level of protection against agent cloning and export.

   The security of this model relies on the *Workload Identity Agent*
   correctly providing a fresh assertion bound to the current workload
   session.  While this document specifies the conveyance of N_fusion,
   the underlying platform-level freshness—including the binding to
   hardware-rooted platform nonces (N_platform)—is managed by the
   associated *RATS Profile* (see [[!I-D.lkspa-wimse-verifiable-geo-
   fence]]).  If a verifier accepts a residency proof that lacks a fresh
   agent signature, the "Silicon-to-SVID" chain of trust is compromised.

   TBD: Discussion on Workload Identity Agent compromise, nonce entropy
   requirements, and clock skew for timestamp verification.

7.  IANA Considerations

   This document has no IANA actions at this time.

Authors' Addresses

   Ram Krishnan
   JPMorgan Chase & Co
   Email: ramkri123@gmail.com


   A Prasad
   Oracle
   Email: a.prasad@oracle.com


   Diego R. Lopez
   Telefonica
   Email: diego.r.lopez@telefonica.com


   Srinivasa Addepalli
   Aryaka
   Email: srinivasa.addepalli@aryaka.com




Krishnan, et al.         Expires 29 August 2026                [Page 11]


# ratings

draft_name: draft-narvaneni-agent-uri
rated_at: 2026-02-27T23:01:11.312587+00:00
summary:
This draft defines the agent:// URI scheme for addressing and interoperating with software agents across different platforms and ecosystems. It provides a layered framework supporting basic addressing/transport as well as extensible features like capability discovery and orchestration.

novelty_note:
While URI schemes exist, this is the first standardized approach specifically for agent addressing with support for both remote and local agents

maturity_note:
Draft shows good structure but has formatting issues, incomplete sections (truncated ABNF), and appears to be early stage experimental work

overlap_note:
References existing agent communication protocols (FIPA-ACL, Contract Net) but positions itself as complementary addressing layer rather than competing

momentum_note:
Independent submission by single author, revision 02 indicates some iteration, but no clear WG adoption or broader community engagement visible

relevance_note:
Addresses critical interoperability challenge for agent ecosystems - standardized addressing is fundamental for agent-to-agent communication at scale

categories:
["Agent discovery / registration", "Agent-to-agent communication protocols", "Data formats / semantics for AI interop"]


draft_name: draft-zhang-agent-gap-network
novelty_note: Addresses emerging AI agent networking needs but analysis is fairly general and high-level
maturity_note: Very early draft with many TBD sections, incomplete use cases, and missing technical details
rated_at: 2026-02-27T23:01:30.264286+00:00
summary:
This draft identifies problems and gaps in mobile core networks for supporting AI agent communication, focusing on changes in interaction content (multimodality), entities (agent-to-agent), and protocols (semantic understanding). It argues current networks are 'dumb pipelines' that need AI-native capabilities for agent communication scenarios.

overlap_note:
References 3GPP TR 22.870 for AI Agent definitions but appears to be first IETF work specifically on agent-enabled mobile core networks

momentum_note:
First version (-00) from China Unicom authors, no evidence of working group adoption or broader community engagement yet

relevance_note:
Highly relevant as it addresses fundamental networking infrastructure needs for AI agent deployment at mobile network scale

categories:
["Agent-to-agent communication protocols", "Autonomous network operations", "ML-based traffic management / optimization"]


draft_name: draft-cui-ai-agent-task
rated_at: 2026-02-27T23:01:36.699440+00:00
summary:
This draft proposes requirements for standardized AI agent protocols to enable task-oriented coordination in multi-agent systems. It addresses the need for dynamic task discovery, negotiation, and context-aware scheduling across heterogeneous networking environments, focusing on scenarios where multiple AI agents must collaborate to complete complex tasks.

novelty_note:
Addresses emerging AI agent coordination needs but builds on established multi-agent system concepts

maturity_note:
Early draft with basic framework outlined but lacks detailed technical specifications and appears truncated

overlap_note:
Some overlap with general multi-agent coordination work but focuses specifically on AI agents in networking contexts

momentum_note:
Authors from reputable institutions (Tsinghua University) but this appears to be initial version with limited development history

relevance_note:
Highly relevant to AI agent networking as it directly addresses coordination protocols for multi-agent AI systems

categories:
["Agent-to-agent communication protocols", "Agent discovery / registration", "Autonomous network operations"]


draft_name: draft-liu-agent-context-protocol
novelty_note: First standardization attempt for agent context communication semantics
maturity_note: Very early draft (version 00), incomplete with truncated content and minimal technical detail
overlap_note: Limited overlap with existing networking protocols, focuses on AI-specific context semantics
momentum_note: Single author from industry, no WG adoption evident, first version with no revision history
relevance_note: Directly addresses core need for standardized AI agent interoperability and context sharing
categories: ["Agent-to-agent communication protocols", "Data formats / semantics for AI interop"]
rated_at: 2026-02-27T23:01:43.046582+00:00
summary:
This draft proposes a standard protocol for AI agents to communicate context information to each other, independent of the underlying communication protocol. It defines semantic standards for agent context messages to improve interoperability and enable more accurate responses from called agents.


draft_name: draft-zheng-dispatch-agent-identity-management
rated_at: 2026-02-27T23:01:51.927751+00:00
summary:
This draft proposes an identity management framework for agents in an Internet of Agents (IOA) system, defining agent description requirements, registration processes with agent gateways, identifier structures, and management functions. It aims to provide foundational identity infrastructure for secure and scalable agent interoperability.

novelty_note:
While identity management concepts are well-established, applying them specifically to AI agents with agent-specific attributes like intelligence level and form factor is relatively novel

maturity_note:
This is version 00 with incomplete sections (Extended Information cut off), contains typos in title ('Managenment'), and lacks detailed technical specifications

overlap_note:
Overlaps with general identity management protocols and potentially with other agent discovery/registration drafts, but focuses specifically on IOA systems

momentum_note:
Multiple authors from Huawei suggests organizational backing, but as a first version in dispatch working group indicates early stage exploration rather than established momentum

relevance_note:
Identity management is fundamental for any multi-agent system and directly addresses core infrastructure needs for AI agent networking and interoperability

categories:
["Identity / authentication for AI agents", "Agent discovery / registration", "Agent-to-agent communication protocols"]


draft_name: draft-zhang-rtgwg-ai-agents-troubleshooting
categories: ["Agent-to-agent communication protocols", "Autonomous network operations"]
rated_at: 2026-02-27T23:01:58.511011+00:00
summary:
This draft defines use cases and communication protocol requirements for troubleshooting agents deployed on network devices. It focuses on enabling distributed agents to collaboratively identify, diagnose, and resolve network issues across data center, campus, and IoT edge environments through standardized inter-agent communication.

novelty_note:
Applies existing concepts like gRPC to agent-based troubleshooting but doesn't introduce fundamentally new protocol mechanisms

maturity_note:
Early stage draft (-00) with basic structure but incomplete content, placeholder URLs, and truncated examples

overlap_note:
Overlaps with existing network management protocols (NETCONF, RESTCONF) and telemetry standards, but focuses specifically on agent coordination

momentum_note:
Multiple Huawei authors suggesting corporate backing, but no evidence of WG adoption or prior revisions yet

relevance_note:
Highly relevant to autonomous network operations trend, addressing key challenge of distributed agent coordination for network troubleshooting


draft_name: draft-zl-agents-networking-framework
rated_at: 2026-02-27T23:02:07.010285+00:00
summary:
This draft proposes a networking framework for AI agents in enterprise and broadband environments, defining four core components: Agent Certificate Authority (ACA), Agent Registration Server (ARS), AI Agents, and Agent Gateway (AGw). It aims to enable secure agent-to-agent communication, identity management, and collaborative task execution across domains.

novelty_note:
Framework combines existing concepts (PKI, service discovery, gateways) applied to AI agents without significant technical innovation

maturity_note:
Very early draft with incomplete content (text cuts off mid-sentence), lacks technical depth, protocol specifications, and implementation details

overlap_note:
Overlaps with existing service discovery protocols, PKI frameworks, and gateway architectures, though specific application to AI agents is less common

momentum_note:
Multiple Huawei authors but no evidence of working group adoption, first revision (-00), and working group (rtgwg) focus may not align well with AI agent networking

relevance_note:
Directly addresses core challenges in AI agent networking including identity, discovery, and secure inter-agent communication

categories:
["Agent discovery / registration", "Identity / authentication for AI agents", "Agent-to-agent communication protocols"]


draft_name: draft-chen-agent-decoupled-authorization-model
rated_at: 2026-02-27T23:02:14.586709+00:00
summary:
This draft proposes a decoupled authorization framework for AI agents that enables dynamic, intent-based permissions through Just-in-Time authorization decisions rather than static role-based access. It addresses the challenges of traditional authorization models when applied to ephemeral, autonomous AI agents by separating authorization decisions (ADP) from enforcement points (AEP).

novelty_note:
Intent-based authorization for AI agents and decoupled ADP/AEP architecture is a novel approach to a real emerging problem

maturity_note:
Very early draft (00) with incomplete sections, truncated content, and missing critical implementation details

overlap_note:
Builds on OAuth 2.0 (RFC 6749) and traditional authorization frameworks but addresses AI-specific gaps not covered by existing work

momentum_note:
No clear WG adoption indicated, early version from China Mobile authors, no revision history to assess community interest

relevance_note:
Directly addresses critical security and authorization challenges for AI agent ecosystems, which is fundamental to safe agent deployment

categories:
["Identity / authentication for AI agents", "AI safety / guardrails / alignment", "Policy / governance / ethical frameworks"]


draft_name: draft-huang-acme-scalable-agent-enrollment
categories: ["Identity / authentication for AI agents", "Agent discovery / registration"]
rated_at: 2026-02-27T23:02:22.266645+00:00
summary:
This draft proposes two scalable models for certificate enrollment of AI agents: one using Zero-Knowledge Proofs for privacy-preserving attestation, and another using trusted host environments to endorse agent certificates. It addresses the scalability bottleneck of performing full attestation validation for every agent enrollment in large-scale deployments.

novelty_note:
Novel application of ZKP and host-based trust models to AI agent certificate enrollment, addressing specific scalability challenges not covered in existing standards

maturity_note:
Early draft with incomplete specification, missing protocol details, security analysis, and implementation considerations

overlap_note:
Builds on existing SCEP/EST protocols and RATS attestation framework, but proposes new extensions rather than duplicating existing work

momentum_note:
New draft (-00) from authors without clear IETF track record, submitted to RATS WG but no indication of WG adoption or review

relevance_note:
Directly addresses core challenge of scalable identity management for AI agents, which is fundamental to secure agent deployment


draft_name: draft-du-ai-agent-communication-6g-aspect
rated_at: 2026-02-27T23:02:29.743756+00:00
summary:
This draft proposes requirements and frameworks for AI Agent Communication Networks (ACN) in 6G systems, focusing on agent-to-agent communication across domains. It introduces use cases for AI agent collaboration, grouping mechanisms, and both centralized and decentralized communication frameworks to enable interoperability between AI agents from different organizations.

novelty_note:
Combines 6G networking perspective with AI agent communication, but core concepts of multi-agent systems and service discovery are well-established

maturity_note:
Early draft with incomplete sections (text cuts off mid-sentence), limited technical depth, and appears to be first version (-00)

overlap_note:
Overlaps significantly with existing multi-agent system protocols, service discovery mechanisms, and the referenced draft-rosenberg-ai-protocols on AI agent protocols

momentum_note:
Single author from China Mobile, no evidence of working group adoption, first version suggests limited community engagement so far

relevance_note:
Highly relevant as it addresses core challenge of inter-domain AI agent communication and proposes concrete network architectures for agent collaboration

categories:
["Agent-to-agent communication protocols", "Agent discovery / registration", "Identity / authentication for AI agents"]


draft_name: draft-yl-agent-id-requirements
rated_at: 2026-02-27T23:02:37.628703+00:00
summary:
This draft proposes requirements for digital identity management in AI agent communication protocols, focusing on identifiers, attributes (skills, capabilities, services), authentication, authorization, and discovery mechanisms. It aims to establish a foundation for secure, interoperable communication between AI agents and other entities across different domains and providers.

novelty_note:
Applies existing digital identity concepts to AI agents, which is relatively new but builds on established identity management principles

maturity_note:
Early stage draft with incomplete sections, basic requirements definition, and limited technical detail or protocol specifications

overlap_note:
Overlaps with general digital identity management RFCs and potentially other AI agent communication drafts like draft-rosenberg-ai-protocols mentioned in references

momentum_note:
China Mobile authors suggest some industry backing, but this appears to be version 00 with no evidence of working group adoption or broad community engagement

relevance_note:
Highly relevant as identity management is fundamental for secure AI agent interactions and will be critical as agents become more prevalent

categories:
["Identity / authentication for AI agents", "Agent-to-agent communication protocols", "Agent discovery / registration"]


draft_name: draft-song-oauth-ai-agent-authorization
rated_at: 2026-02-27T23:02:45.613707+00:00
summary:
This draft proposes an extension to OAuth 2.0 that adds a 'target_id' field to enable granular authorization for AI agents and AI models deployed on clients. The extension aims to distinguish between the client device and specific AI components for better security, traceability, and compliance with regulations like GDPR.

novelty_note:
Addresses a legitimate gap in OAuth for AI agents, but the solution is a straightforward parameter addition rather than a fundamental innovation

maturity_note:
Draft appears incomplete (text cuts off mid-sentence), has numerous spelling/grammar errors, and lacks detailed technical specifications and examples

overlap_note:
Heavily overlaps with draft-oauth-ai-agents-on-behalf-of-user which it references, and builds incrementally on existing OAuth 2.0 framework

momentum_note:
First version (00) from Huawei authors, no evidence of working group adoption, and quality issues suggest limited momentum

relevance_note:
Directly addresses authorization challenges for AI agents which is increasingly important as AI systems become more autonomous and distributed

categories:
["Identity / authentication for AI agents", "Policy / governance / ethical frameworks", "Agent discovery / registration"]


draft_name: draft-wang-nmrg-magent-im
rated_at: 2026-02-27T23:02:54.217206+00:00
summary:
This draft proposes a protocol-agnostic data model for multi-agent communication in autonomous networks, enabling intelligent agents to coordinate across domains for tasks like fault management, service optimization, and user complaint handling. It aims to support Level 4 network autonomy through structured agent interaction patterns.

novelty_note:
The specific focus on autonomous network operations with multi-agent coordination is relatively novel, though general multi-agent systems are well-established

maturity_note:
This is version -00 with incomplete content (truncated), basic YANG model provided but limited implementation details

overlap_note:
Some overlap with existing network management protocols (NETCONF, RESTCONF) and TMForum standards, but specific multi-agent coordination aspects are less covered

momentum_note:
Authors from Huawei with network management background, but this is initial version with no WG adoption visible, dated 2025/2026 suggesting early stage

relevance_note:
Highly relevant to AI/agent networking as it directly addresses multi-agent coordination in network operations, a key area for autonomous network evolution

categories:
["Agent-to-agent communication protocols", "Autonomous network operations", "Agent discovery / registration"]


draft_name: draft-yu-ai-agent-use-cases-in-6g
novelty_note: Primarily compiles existing 3GPP use cases rather than proposing new technical solutions
rated_at: 2026-02-27T23:03:01.999948+00:00
summary:
This draft catalogs use cases for AI agents in 6G networks, referencing 3GPP work to define how network-embedded AI agents can provide intent-based services through collaboration between device, network, and application agents. It outlines potential requirements for supporting AI agent operations in mobile networks from an operator perspective.

maturity_note:
Early stage work that catalogues requirements without detailed technical specifications or protocols

overlap_note:
Heavily references 3GPP SA1 R20 Study TR 22.870 and duplicates much content from those standardization efforts

momentum_note:
China Telecom authors but appears to be individual submission without working group adoption, revision -02 suggests limited community engagement

relevance_note:
Directly addresses AI agent networking in mobile systems, covering key aspects like identity, discovery, and collaboration requirements

categories:
["Agent-to-agent communication protocols", "Identity / authentication for AI agents", "Agent discovery / registration"]


draft_name: draft-xie-ai-agent-multimodal
novelty_note: Applies existing multimedia concepts to AI agents, but specific combination is moderately novel
categories: ["Agent-to-agent communication protocols", "Data formats / semantics for AI interop"]
rated_at: 2026-02-27T23:03:09.070322+00:00
summary:
This draft outlines requirements for multimodal communication in AI agent protocols, enabling agents to negotiate and exchange synchronized multimedia content including text, files, audio/video streams, and sensor data. It identifies gaps in existing agent protocols and proposes requirements for media channel establishment, multi-stream multiplexing, and synchronized multimodal data transmission.

maturity_note:
Very early draft with basic requirements but lacks technical depth, protocol details, or implementation guidance

overlap_note:
Overlaps with existing multimedia protocols (SIP, WebRTC, RTP) and references existing agent protocols (A2A, ANP, Agntcy)

momentum_note:
Authors from established institution (CNIC, CAS) but this is version -00 with no clear working group adoption or revision history

relevance_note:
Highly relevant as multimodal capabilities are becoming critical for AI agents, especially with advancement of multimodal LLMs


draft_name: draft-hw-ai-agent-6g
rated_at: 2026-02-27T23:03:16.950998+00:00
summary:
This draft analyzes requirements for agent protocols specifically tailored to 6G mobile networks, examining how mobile network characteristics like QoS guarantees, mobility, and resource dynamicity create unique needs for agent communication. It proposes a multi-layer protocol architecture including agent governance, meta-protocol, security, and transport layers to enable multi-agent systems across terminals, networks, and services.

novelty_note:
Novel focus on mobile network-specific agent protocol requirements, but builds on existing agent communication concepts

maturity_note:
Early stage draft with requirements analysis but limited concrete protocol specifications or implementation details

overlap_note:
Some overlap with general agent communication protocols but focuses specifically on mobile/6G context which is relatively unique

momentum_note:
Multiple authors from major telecom companies (Huawei, China Telecom, China Unicom) suggest industry interest, but appears to be initial version

relevance_note:
Highly relevant as it addresses agent networking in critical mobile infrastructure context with specific focus on multi-agent systems and QoS requirements


draft_name: draft-nandakumar-agent-sd-jwt
rated_at: 2026-02-27T23:03:24.425941+00:00
summary:
This draft defines SD-Card, a Selective Disclosure JWT encoding of Agent Cards that enables privacy-preserving agent discovery by allowing agents to selectively reveal capabilities, contact information, and metadata based on context while maintaining cryptographic integrity and preventing correlation across interactions.

novelty_note:
Novel application of SD-JWT to agent discovery, addressing real privacy and security gaps in A2A protocols

maturity_note:
Well-structured draft with detailed examples and processes, but appears to be early revision with some incomplete sections

overlap_note:
Builds on SD-JWT (RFC) and references A2A-SPEC, but creates new application domain rather than duplicating existing work

momentum_note:
Authors from Cisco with networking expertise, revision 01 indicates active development, but no clear WG adoption signals

relevance_note:
Directly addresses critical needs for AI agent networking: privacy-preserving discovery, authentication, and selective capability disclosure


draft_name: draft-campbell-agentic-http
rated_at: 2026-02-27T23:03:32.618580+00:00
summary:
This draft proposes a Best Current Practice for AI agent interactions over HTTP, standardizing tool invocation via GET requests, stateless authentication, and formalizing the 402 Payment Required status code to enable a native economic layer for machine-to-machine transactions.

novelty_note:
While HTTP-based agent interactions exist, the specific combination of GET-only tool calls and 402-based payment semantics is relatively novel

maturity_note:
Early draft with some inconsistencies (document dates, RFC number vs draft status) and limited technical depth in key areas like security

overlap_note:
Overlaps with existing HTTP authentication RFCs, OpenAPI specifications, and general REST API best practices, but focuses specifically on agent use cases

momentum_note:
Single author from unknown organization, no indication of working group adoption, appears to be initial version with limited community engagement

relevance_note:
Highly relevant as it addresses a key challenge in AI agent networking - standardized communication patterns and economic transactions between agents


draft_name: draft-wahl-scim-agent-schema
novelty_note: Novel application of SCIM to AI agents - existing SCIM is for human users only
maturity_note: Well-structured draft with detailed schema but appears truncated and is informational status
overlap_note: Builds on SCIM RFCs 7643/7644 and OAuth RFCs 6749/8693 but extends to new domain
momentum_note: Microsoft author with SCIM expertise, but unclear WG adoption status for this extension
relevance_note: Directly addresses critical need for agent identity management as AI systems scale
categories: ["Identity / authentication for AI agents", "Agent discovery / registration"]
rated_at: 2026-02-27T23:03:39.375264+00:00
summary:
This draft extends the SCIM (System for Cross-domain Identity Management) protocol to support AI agent identities, defining a JSON schema for representing, provisioning, and managing agent identities in cloud services. It enables agents to be authenticated and authorized through existing SCIM infrastructure, including OAuth token exchange support.


draft_name: draft-ietf-sshm-ssh-agent
novelty_note: This is standardization of an existing widely-deployed protocol, not novel work
maturity_note: Version 16 draft with extensive implementation history and broad deployment
overlap_note: Builds on SSH core RFCs (4251-4254) but addresses previously unstandardized agent protocol
momentum_note: IETF working group adoption, mature revision number, from established SSH implementer
relevance_note: While about 'agents', this is cryptographic key agents for SSH, not AI agents
categories: ["Identity / authentication for AI agents"]
rated_at: 2026-02-27T23:03:46.132765+00:00
summary:
This draft specifies the SSH Agent Protocol for managing cryptographic keys used in SSH authentication. It standardizes an existing de-facto protocol that allows SSH clients to interact with key management agents to perform cryptographic operations without directly exposing private keys.


draft_name: draft-oauth-ai-agents-on-behalf-of-user
rated_at: 2026-02-27T23:03:53.405886+00:00
summary:
This draft extends OAuth 2.0 to enable AI agents to securely obtain access tokens for acting on behalf of users. It introduces new parameters (requested_actor, actor_token) to the authorization flow to ensure explicit user consent and proper authentication of AI agents during delegation.

novelty_note:
Novel application of OAuth 2.0 specifically for AI agent delegation with new parameters and consent mechanisms

maturity_note:
Well-structured draft with detailed protocol steps and security considerations, but appears to be early-stage work from non-IETF authors

overlap_note:
Builds on OAuth 2.0 RFC6749 and relates to Token Exchange RFC8693, but addresses gaps in existing specifications for AI agent scenarios

momentum_note:
Authors from WSO2 but no clear IETF working group adoption, second revision suggests some development but limited institutional backing

relevance_note:
Directly addresses a critical need for secure AI agent authorization in distributed systems, highly relevant to AI agent networking

categories:
["Identity / authentication for AI agents", "Human-agent interaction", "Agent-to-agent communication protocols"]


draft_name: draft-sarischo-6gip-aiagent-requirements
novelty_note: Applies existing AI agent concepts to 6G context with some novel DNS discovery approaches
maturity_note: Early stage draft with basic requirements enumeration, lacks detailed technical specifications
overlap_note: Overlaps with general AI agent frameworks but focuses specifically on 6G domain
momentum_note: Limited momentum, niche 6G focus may restrict broader IETF interest
relevance_note: Relevant for telecom industry moving toward 6G, moderate relevance for general networking
categories: ["Agent discovery/reg", "Autonomous netops", "Policy/governance"]
rated_at: 2026-02-27T23:13:06.600376+00:00
summary:
Defines requirements for AI/ML agents in 6G mobile networks, covering different agent types and their specific needs. Describes implementation approaches including API discovery and DNS-based agent discovery mechanisms.


draft_name: draft-hong-nmrg-agenticai-ps
novelty_note: Frames existing agentic AI concepts within network management context with collaborative focus
maturity_note: Problem statement level document, lacks concrete technical solutions or protocols
overlap_note: Significant overlap with autonomous network operations and AI agent coordination topics
momentum_note: NMRG venue appropriate, collaborative automation angle has potential interest
relevance_note: Highly relevant to network automation trends and operator pain points
categories: ["Autonomous netops", "A2A protocols", "Policy/governance"]
rated_at: 2026-02-27T23:13:06.612465+00:00
summary:
Presents problem statement and motivations for applying Agentic AI to network management. Emphasizes collaborative autonomous agents for fully automated network operations, management and security.


draft_name: draft-zhao-nmrg-ai-agent-for-dtn
novelty_note: Novel combination of digital twin technology with AI agents for network management
maturity_note: Very brief at 7 pages, appears to be early conceptual stage
overlap_note: Some overlap with network digital twins and AI agent architectures
momentum_note: Niche combination of technologies may limit broader adoption
relevance_note: Relevant for advanced network management but digital twin adoption still emerging
categories: ["Autonomous netops", "Data formats/interop", "Other AI/agent"]
rated_at: 2026-02-27T23:13:06.622873+00:00
summary:
Proposes AI agent architecture for Digital Twin Networks, integrating autonomous agents at each DTN component level. Extends traditional DTN architecture for more intelligent and adaptive network management.


draft_name: draft-zyyhl-agent-networks-framework
novelty_note: Substantial framework for agent-to-agent networking with dedicated protocol
maturity_note: Most detailed at 21 pages with concrete protocol framework, but references incomplete ANP spec
overlap_note: Relatively unique approach to agent networking protocols
momentum_note: Comprehensive framework could attract interest but depends on ANP protocol development
relevance_note: Highly relevant as agent-to-agent communication becomes critical infrastructure need
categories: ["A2A protocols", "Agent discovery/reg", "Data formats/interop", "Agent identity/auth"]
rated_at: 2026-02-27T23:13:06.631770+00:00
summary:
Defines comprehensive framework for AI agent networks based on Agent Network Protocol (ANP). Provides basic functions needed for AI agent communication within trusted domains.


draft_name: draft-srijal-agents-policy
novelty_note: Builds on robots.txt concept with stricter verification and failure handling for AI agents
maturity_note: Well-defined protocol specification with clear directives and error handling
overlap_note: Similar to robots.txt but distinct focus on modern automated agents
momentum_note: Addresses immediate practical need as AI agents proliferate across web services
relevance_note: Extremely relevant given current explosion of AI agents and need for access control
categories: ["Policy/governance", "Agent identity/auth", "Data formats/interop"]
rated_at: 2026-02-27T23:13:06.641817+00:00
summary:
Specifies AGENTS.TXT protocol as strict plaintext policy file for automated clients, bots, and crawlers. Includes hash verification and mandatory restrictive behavior for malformed files.


draft_name: draft-liang-agentdns
novelty_note: Novel application of DNS concepts to agent ecosystems with semantic discovery
maturity_note: Well-structured but lacks implementation details and evaluation
overlap_note: Overlaps with draft-cui-ai-agent-discovery-invocation on agent discovery
momentum_note: Addresses clear need but no evidence of industry adoption yet
relevance_note: Highly relevant for emerging agent interoperability challenges
categories: ["Agent discovery/reg", "A2A protocols", "Agent identity/auth"]
rated_at: 2026-02-27T23:13:26.172536+00:00
summary:
Proposes a DNS-inspired naming and service discovery system for LLM agents to enable autonomous discovery and invocation of third-party services. Addresses interoperability and trust management in agent collaboration ecosystems.


draft_name: draft-scim-agent-extension
novelty_note: Practical extension of established standard rather than novel approach
maturity_note: Builds on mature SCIM foundation with detailed schema extensions
overlap_note: Unique approach using identity management for agent management
momentum_note: Leverages existing SCIM ecosystem and addresses practical deployment needs
relevance_note: Very relevant for enterprise agent identity and lifecycle management
categories: ["Agent identity/auth", "Data formats/interop", "Policy/governance"]
rated_at: 2026-02-27T23:13:26.185688+00:00
summary:
Extends SCIM 2.0 specification to manage agents and agentic applications across domains. Builds on existing identity management infrastructure to reduce protocol proliferation.


draft_name: draft-kotecha-agentic-dispute-protocol
novelty_note: Highly novel - first formal protocol for automated agent dispute resolution
maturity_note: Comprehensive but complex specification needing real-world validation
overlap_note: Unique focus on dispute resolution - no overlap with other drafts
momentum_note: Addresses future need but may be premature for current agent capabilities
relevance_note: Relevant for advanced agent interactions but not immediate priority
categories: ["A2A protocols", "Policy/governance", "AI safety/alignment"]
rated_at: 2026-02-27T23:13:26.195988+00:00
summary:
Defines a protocol for autonomous agents to file and resolve disputes through structured automated processes. Includes evidence submission, cryptographic proofs, and multiple resolution frameworks.


draft_name: draft-cui-ai-agent-discovery-invocation
novelty_note: Standard approach to common problem with useful intent-based extension
maturity_note: Well-developed specification with clear interfaces and security considerations
overlap_note: Overlaps with draft-liang-agentdns on agent discovery functionality
momentum_note: Addresses immediate interoperability needs with practical approach
relevance_note: Extremely relevant - core requirement for multi-agent system deployment
categories: ["Agent discovery/reg", "A2A protocols", "Data formats/interop"]
rated_at: 2026-02-27T23:13:26.205382+00:00
summary:
Proposes standardized protocol for AI agent discovery and invocation with common metadata format and RESTful interface. Includes intent-based agent selection extension.


draft_name: draft-liu-access-collaboration-agent
novelty_note: Limited novelty - discusses general requirements without specific solutions
maturity_note: Very early stage - only 6 pages with minimal technical content
overlap_note: General requirements overlap with other agent protocol discussions
momentum_note: No clear momentum - appears to be initial exploration only
relevance_note: Potentially relevant but too underdeveloped to assess properly
categories: ["A2A protocols", "Other AI/agent"]
rated_at: 2026-02-27T23:13:26.221485+00:00
summary:
Brief document exploring requirements for AI agent communication protocols in ubiquitous access collaboration scenarios. Very preliminary with minimal detail.


draft_name: draft-abbey-scim-agent-extension
novelty_note: First to systematically extend SCIM for agent identity management
maturity_note: Builds on mature SCIM foundation but agent-specific extensions are early
overlap_note: Unique approach using SCIM for agent identity management
momentum_note: Leverages established SCIM ecosystem but agent management is emerging
relevance_note: Addresses critical need for agent identity management as agentic systems proliferate
categories: ["Agent identity/auth", "Data formats/interop", "Agent discovery/reg"]
rated_at: 2026-02-27T23:13:44.889777+00:00
summary:
Extends SCIM 2.0 protocol to manage AI agents and agentic applications across domains. Adds new schemas and resource types for agent identity management using existing SCIM infrastructure.


draft_name: draft-zhao-nmop-network-management-agent
novelty_note: Novel conceptual framework bridging AI agents with network autonomy levels
maturity_note: Early stage architectural proposal with limited implementation details
overlap_note: Some overlap with existing autonomous network and SDN work
momentum_note: Strong industry push toward network automation and AI integration
relevance_note: Highly relevant as networks move toward autonomous operations
categories: ["Autonomous netops", "A2A protocols", "Policy/governance"]
rated_at: 2026-02-27T23:13:44.902190+00:00
summary:
Defines AI-driven Network Management Agent concept for Level 4 autonomous networks. Specifies integration with existing SDN controllers for intent-based reasoning and autonomous operations.


draft_name: draft-yao-agent-auth-considerations
novelty_note: Reasonable extension of OAuth to agent domain with some novel considerations
maturity_note: Early conceptual work building on OAuth but lacks detailed protocol specification
overlap_note: Some conceptual overlap with general OAuth extensions but agent-specific
momentum_note: OAuth is well-established but agent auth is still developing
relevance_note: Critical for secure agent ecosystems as they become more prevalent
categories: ["Agent identity/auth", "A2A protocols", "Policy/governance"]
rated_at: 2026-02-27T23:13:44.914664+00:00
summary:
Extends OAuth model for AI agent authentication and authorization in Agent Communication Networks. Proposes new workflows addressing unique requirements of agent-to-agent authentication.


draft_name: draft-zhao-ccamp-actn-optical-network-agent
novelty_note: Applies NMA concept to specific optical network domain with ACTN
maturity_note: Early architectural proposal with limited technical depth
overlap_note: Builds heavily on companion NMA draft and existing ACTN work
momentum_note: Optical networks seeking automation but AI integration still emerging
relevance_note: Relevant for optical network operators but narrow domain focus
categories: ["Autonomous netops", "Other AI/agent"]
rated_at: 2026-02-27T23:13:44.925956+00:00
summary:
Integrates Network Management Agents into ACTN-based optical networks for autonomous operations. Extends ACTN architecture with AI capabilities for optical network management.


draft_name: draft-mzsg-rtgwg-agent-cross-device-comm-framework
novelty_note: Addresses practical need for agent coordination in network devices
maturity_note: Very early stage with minimal technical detail or protocol specification
overlap_note: Some overlap with general agent communication frameworks
momentum_note: Network device AI deployment still in early phases
relevance_note: Relevant for network operations but limited scope and early development
categories: ["A2A protocols", "Autonomous netops", "Data formats/interop"]
rated_at: 2026-02-27T23:13:44.937357+00:00
summary:
Proposes communication framework for AI agents deployed across different network devices. Focuses on collaboration requirements for tasks like network measurement and troubleshooting.


draft_name: draft-zl-agents-networking-architecture
novelty_note: Basic architectural framework, but limited novelty in core concepts
maturity_note: Early draft with brief content, lacks detailed specifications
overlap_note: Overlaps significantly with other agent networking architecture drafts
momentum_note: Limited momentum indicated by brief content and basic scope
relevance_note: Relevant to growing agent networking field but lacks depth
categories: ["Autonomous netops", "A2A protocols", "Data formats/interop"]
rated_at: 2026-02-27T23:14:03.422000+00:00
summary:
Defines core components and interactions for agent networking architecture in enterprise and broadband environments. Provides foundational framework for agent-based networking systems.


draft_name: draft-wmz-nmrg-agent-ndt-arch
novelty_note: Novel integration of NDT and Agentic AI for network operations
maturity_note: Substantial 37-page document with detailed architectural components
overlap_note: Unique focus on digital twin integration with agent architecture
momentum_note: Strong momentum with comprehensive content and clear use cases
relevance_note: highly relevant to current industry needs for AI-driven network automation
categories: ["Autonomous netops", "Model serving/inference", "Policy/governance", "Other AI/agent"]
rated_at: 2026-02-27T23:14:03.432769+00:00
summary:
Comprehensive architecture combining Network Digital Twin with Agentic AI for intent-based network operations. Provides detailed cookbook approach using existing technologies enhanced with new AI capabilities.


draft_name: draft-chuyi-nmrg-ai-agent-network
novelty_note: Practical focus on LLM applications but incremental novelty
maturity_note: Moderate detail with scenario identification and impact analysis
overlap_note: Moderate overlap with other network agent operation drafts
momentum_note: Good momentum with practical focus and standardization exploration
relevance_note: High relevance to current LLM and network automation trends
categories: ["Autonomous netops", "ML traffic mgmt", "Model serving/inference", "Data formats/interop"]
rated_at: 2026-02-27T23:14:03.446934+00:00
summary:
Focuses on large language model-based agents for network operations and maintenance. Addresses practical challenges like system isolation and fragmented data in network operations.


draft_name: draft-zl-agents-networking-scenarios
novelty_note: Limited novelty, mainly scenario descriptions based on assumptions
maturity_note: Brief 8-page document with basic scenario coverage
overlap_note: Scenarios overlap with other agent networking use case discussions
momentum_note: Low momentum with brief content and assumption-based scenarios
relevance_note: Moderately relevant for understanding practical deployment contexts
categories: ["Autonomous netops", "Human-agent interaction", "Other AI/agent"]
rated_at: 2026-02-27T23:14:03.456801+00:00
summary:
Describes specific agent networking scenarios for enterprise and home broadband networks. Focuses on practical use cases distinct from 6G and general Internet scenarios.


draft_name: draft-stephan-ai-agent-6g
novelty_note: Builds on existing 3GPP work with moderate protocol innovation
maturity_note: Reasonable detail with clear 3GPP foundation and protocol focus
overlap_note: Unique 6G focus with limited overlap to other drafts
momentum_note: Moderate momentum with established 3GPP backing
relevance_note: High relevance to emerging 6G standards and agent protocols
categories: ["A2A protocols", "Agent discovery/reg", "Data formats/interop", "Other AI/agent"]
rated_at: 2026-02-27T23:14:03.477243+00:00
summary:
Examines AI agent communication protocols specifically for 6G systems based on 3GPP requirements. Extrapolates protocol requirements from established 3GPP use cases.


draft_name: draft-ni-wimse-ai-agent-identity
novelty_note: Moderate novelty in applying existing WIMSE to AI agents
maturity_note: Early stage, limited technical detail in abstract
overlap_note: Some overlap with other agent identity drafts
momentum_note: Part of emerging AI agent standardization work
relevance_note: Highly relevant as agent identity is foundational
categories: ["Agent identity/auth"]
rated_at: 2026-02-27T23:14:18.782131+00:00
summary:
Applies WIMSE (Workload Identity in Multi System Environments) framework to AI agents for identity and credential management. Focuses on establishing independent identities for AI agents operating across systems.


draft_name: draft-mao-rtgwg-agent-comm-protocol-gap-analysis
novelty_note: Novel gap analysis approach for agent communication
maturity_note: Good analytical foundation, references framework draft
overlap_note: Unique focus on protocol gap analysis
momentum_note: Part of broader cross-device communication work
relevance_note: Important for understanding protocol requirements
categories: ["A2A protocols", "Autonomous netops"]
rated_at: 2026-02-27T23:14:18.792385+00:00
summary:
Analyzes gaps in existing networking and AI protocols for cross-device communication between AI agents on network devices. Evaluates classical networking protocols and popular AI agent protocols for suitability.


draft_name: draft-zheng-agent-identity-management
novelty_note: Comprehensive identity management framework
maturity_note: Well-structured with detailed requirements
overlap_note: Significant overlap with other identity drafts
momentum_note: Active development in agent identity space
relevance_note: Critical foundational work for agent ecosystems
categories: ["Agent identity/auth", "Agent discovery/reg"]
rated_at: 2026-02-27T23:14:18.801104+00:00
summary:
Defines comprehensive agent identity management for Internet of Agents systems. Covers agent registration, identifier structure, and identity management functions through agent gateways.


draft_name: draft-ni-a2a-ai-agent-security-requirements
novelty_note: Systematic security requirements approach
maturity_note: Good coverage of security lifecycle stages
overlap_note: Some overlap with identity and auth drafts
momentum_note: Strong interest in AI agent security
relevance_note: Essential for secure agent deployment
categories: ["AI safety/alignment", "Agent identity/auth"]
rated_at: 2026-02-27T23:14:18.809719+00:00
summary:
Establishes security requirements for AI agents across their operational lifecycle. Covers provisioning, registration, cross-domain interconnection, and access control security aspects.


draft_name: draft-yuan-rtgwg-traffic-agent-usecase
novelty_note: Specific application of AI to traffic optimization
maturity_note: Well-detailed use cases with clear scenarios
overlap_note: Unique focus on traffic optimization use cases
momentum_note: Strong industry interest in AI network optimization
relevance_note: Valuable for understanding practical applications
categories: ["ML traffic mgmt", "Autonomous netops"]
rated_at: 2026-02-27T23:14:18.821318+00:00
summary:
Presents use cases for AI agents optimizing network traffic through dynamic resource adjustment. Details applications in tunnel adjustment, traffic steering, and network slice management.


draft_name: draft-yuan-rtgwg-security-agent-usecase
maturity_note: Early stage with high-level concepts and scenarios but lacks technical implementation details
overlap_note: Some overlap with general AI agent networking concepts but security focus is distinctive
momentum_note: Security applications of AI agents have industry interest but this is an early contribution
categories: ["Autonomous netops", "AI safety/alignment", "Policy/governance"]
rated_at: 2026-02-27T23:14:41.005970+00:00
summary:
Proposes AI Network Security Agents for routers to provide intelligent, adaptive security capabilities beyond traditional static ACLs and signature-based detection. Outlines four key use cases including dynamic defense, ACL optimization, configuration security, and collaborative defense.

novelty_note:
Novel application of AI agents specifically to network security with concrete use cases, though AI in security is not new

relevance_note:
Highly relevant as network security increasingly needs intelligent automation and adaptive responses


draft_name: draft-men-rtgwg-agent-networking-digibank-scenario
novelty_note: Specific application to digital banking is somewhat novel but agent gateway concept is not unique
maturity_note: Scenario-focused with limited technical depth on implementation
overlap_note: Significant overlap with the other digital banking draft and agent gateway concepts
momentum_note: Banking-specific use cases may have limited broader appeal in IETF context
relevance_note: Relevant to understanding agent networking applications but narrow domain focus
categories: ["A2A protocols", "Agent discovery/reg", "Data formats/interop"]
rated_at: 2026-02-27T23:14:41.015647+00:00
summary:
Describes digital banking scenarios evolving toward agentic service interconnection and proposes an agent networking architecture centered on agent gateways. Focuses on enterprise and broadband network contexts.


draft_name: draft-tong-network-agent-use-cases-in-6g
novelty_note: 6G-specific agent use cases provide some novelty but builds heavily on existing 3GPP work
maturity_note: Use case focused with limited technical specification details
overlap_note: Moderate overlap with general AI agent networking but 6G focus provides differentiation
momentum_note: 6G and AI agents are both high-interest areas with strong industry momentum
relevance_note: Very relevant as 6G networks will likely require extensive AI agent capabilities
categories: ["Autonomous netops", "ML traffic mgmt", "Agent discovery/reg", "Model serving/inference"]
rated_at: 2026-02-27T23:14:41.025714+00:00
summary:
Introduces network AI agent use cases in 6G focusing on connectivity services and third-party applications, drawing from 3GPP scenarios. Discusses integration requirements within 6G framework.


draft_name: draft-men-rtgwg-agent-networking-in-digibank
novelty_note: Limited novelty, appears to duplicate content from related draft
maturity_note: Early stage conceptual work with scenario focus
overlap_note: Heavy overlap with draft-men-rtgwg-agent-networking-digibank-scenario
momentum_note: Duplicate content reduces momentum and may indicate coordination issues
relevance_note: Limited relevance due to narrow focus and apparent duplication
categories: ["A2A protocols", "Agent discovery/reg"]
rated_at: 2026-02-27T23:14:41.035829+00:00
summary:
Describes digital banking digitalization trends toward agentic services and proposes agent networking architecture with agent gateway as core component. Very similar to the other digital banking draft.


draft_name: draft-liu-rtgwg-agent-gateway-requirements
novelty_note: Requirements analysis for agent gateways shows some novelty in systematic approach
maturity_note: More mature requirements analysis compared to other drafts, though still early stage
overlap_note: Overlaps with agent gateway concepts in banking drafts but more technical focus
momentum_note: Requirements documents often gain traction if they address real needs
relevance_note: Highly relevant as agent gateway requirements are fundamental to agent networking
categories: ["A2A protocols", "Agent identity/auth", "Data formats/interop", "Agent discovery/reg"]
rated_at: 2026-02-27T23:14:41.045266+00:00
summary:
Discusses requirements for Agent Gateways in agent-to-agent communications to improve scalability, efficiency and security. Identifies gaps in current gateway solutions that necessitate new Agent Gateway entities.


draft_name: draft-zhang-rtgwg-ai-agents-measurement
novelty_note: Moderate novelty in applying agent paradigm to network measurement
maturity_note: Early stage draft with basic requirements definition
overlap_note: Some overlap with general network telemetry protocols
momentum_note: Limited momentum, appears to be initial exploration
relevance_note: Relevant for network operations but narrow scope
categories: ["Autonomous netops", "A2A protocols", "Data formats/interop"]
rated_at: 2026-02-27T23:14:57.287117+00:00
summary:
Defines use cases and requirements for communication protocols enabling measurement agents on network devices. Focuses on network monitoring and telemetry collection through AI agents.


draft_name: draft-zlgsgl-rtgwg-agents-networking-framework
novelty_note: Novel framework approach for agent networking architecture
maturity_note: More developed with defined components and interactions
overlap_note: Some conceptual overlap with SDN frameworks
momentum_note: Good momentum with detailed framework definition
relevance_note: Highly relevant for enterprise networking evolution
categories: ["Autonomous netops", "A2A protocols", "Agent discovery/reg"]
rated_at: 2026-02-27T23:14:57.298034+00:00
summary:
Introduces a comprehensive agents networking framework for enterprise and broadband environments. Defines core components and interactions for agent-based networking systems.


draft_name: draft-oauth-transaction-tokens-for-agents
novelty_note: Novel extension addressing agent-specific authorization needs
maturity_note: Well-developed with clear technical specifications
overlap_note: Builds on existing OAuth framework but adds agent-specific elements
momentum_note: Strong momentum with concrete technical approach
relevance_note: Highly relevant for agent security and authorization
categories: ["Agent identity/auth", "Policy/governance", "A2A protocols"]
rated_at: 2026-02-27T23:14:57.308966+00:00
summary:
Extends OAuth Transaction Tokens framework to support agent context propagation with actor and principal fields. Enables granular access control for agent-based workloads.


draft_name: draft-steele-agent-considerations
novelty_note: Highly novel meta-approach to specification design for AI agents
maturity_note: Comprehensive framework but still developing implementation details
overlap_note: Unique approach to specification methodology
momentum_note: Moderate momentum, addressing emerging need
relevance_note: Very relevant for future IETF specification development
categories: ["Data formats/interop", "Policy/governance", "Human-agent interaction"]
rated_at: 2026-02-27T23:14:57.319933+00:00
summary:
Defines guidelines for IETF specifications to support AI agent consumption and code generation. Introduces Agent Consideration sections with agentcards and implementation guidance.


draft_name: draft-song-oauth-ai-agent-collaborate-authz
novelty_note: Novel approach to multi-agent authorization coordination
maturity_note: Clear technical approach with specific OAuth extension
overlap_note: Some overlap with general OAuth delegation patterns
momentum_note: Good momentum addressing practical multi-agent needs
relevance_note: Highly relevant for multi-agent system deployment
categories: ["Agent identity/auth", "A2A protocols", "Policy/governance"]
rated_at: 2026-02-27T23:14:57.329968+00:00
summary:
Proposes OAuth 2.0 extension for multi-AI agent collaboration with applier-on-behalf-of authorization. Simplifies authorization for coordinated agent workflows.


draft_name: draft-pang-agents-networking-scenarios
novelty_note: Basic scenario enumeration without novel technical contributions
maturity_note: Early stage draft with assumptions rather than concrete solutions
overlap_note: Overlaps with general agent networking concepts but focuses on specific environments
momentum_note: Limited technical depth may constrain adoption momentum
relevance_note: Relevant for understanding agent deployment contexts but lacks implementation guidance
categories: ["Autonomous netops", "Other AI/agent"]
rated_at: 2026-02-27T23:15:19.403883+00:00
summary:
Describes networking scenarios for agents in enterprise and broadband networks, distinguishing them from mobile and Internet scenarios. Based on reasonable assumptions as agentic services are still emerging.


draft_name: draft-han-rtgwg-agent-gateway-intercomm-framework
novelty_note: Novel hierarchical framework for agent gateway intercommunication
maturity_note: Well-structured framework with clear components but implementation details may need refinement
overlap_note: Specialized focus on gateway interoperability reduces overlap
momentum_note: Technical depth and clear problem focus suggest moderate momentum potential
relevance_note: Highly relevant for scalable agent infrastructure and cross-domain collaboration
categories: ["A2A protocols", "Agent discovery/reg", "Autonomous netops"]
rated_at: 2026-02-27T23:15:19.414228+00:00
summary:
Defines framework for intercommunication between Agent Gateways in Agent Internet ecosystem. Addresses data synchronization, protocol compatibility, and security for cross-domain agent collaboration.


draft_name: draft-dhir-http-agent-profile
novelty_note: Novel integration of authentication, traffic separation, and micropayments for agent HTTP traffic
maturity_note: Mature approach reusing existing HTTP features with clear deployment path
overlap_note: Unique combination of authentication and monetization for agent traffic
momentum_note: Addresses pressing real-world problems with practical deployment strategy
relevance_note: Extremely relevant to current challenges with AI crawlers and web monetization
categories: ["Agent identity/auth", "ML traffic mgmt", "Policy/governance", "Human-agent interaction"]
rated_at: 2026-02-27T23:15:19.424431+00:00
summary:
Defines HTTP Agent Profile for authenticating agent traffic, separating human from agent traffic, and enabling micropayments for content access. Addresses economic misalignment between content providers and AI systems.


draft_name: draft-liu-agent-operation-authorization
novelty_note: Novel two-phase authorization framework with human-readable proposals and verifiable tokens
maturity_note: Well-defined JWT-based approach but may need refinement for complex authorization scenarios
overlap_note: Specific focus on human-to-agent authorization delegation is relatively unique
momentum_note: Addresses critical trust and safety concerns with practical cryptographic approach
relevance_note: Highly relevant for safe agent deployment and preventing unauthorized actions
categories: ["Agent identity/auth", "AI safety/alignment", "Human-agent interaction", "Policy/governance"]
rated_at: 2026-02-27T23:15:19.434910+00:00
summary:
Specifies framework for verifiable delegation of actions from humans to AI agents using JWT tokens. Provides fine-grained authorization with cryptographic verification and audit trails.


draft_name: draft-jurkovikj-httpapi-agentic-state
novelty_note: Novel approach to HTTP resource state synchronization across representations for agent environments
maturity_note: Comprehensive technical specification with clear semantic model and implementation guidance
overlap_note: Unique focus on multi-representation state synchronization for agents
momentum_note: Technical complexity may slow adoption but addresses important consistency problems
relevance_note: Very relevant for agent-driven web interactions and preventing race conditions
categories: ["Data formats/interop", "A2A protocols", "ML traffic mgmt"]
rated_at: 2026-02-27T23:15:19.445002+00:00
summary:
Defines Agentic State Transfer (AST) HTTP profile for managing canonical resource state across multiple synchronized representations. Uses semantic validators and optimistic concurrency control for atomic agent mutations.


draft_name: draft-huang-rats-agentic-eat-cap-attest
novelty_note: Novel application of EAT to agentic systems with new capability-specific claims
maturity_note: Early stage draft at only 6 pages with basic specification
overlap_note: Some overlap with agent identity work but unique attestation focus
momentum_note: Part of emerging RATS working group interest in AI systems
relevance_note: Highly relevant for trustworthy AI deployment and verification
categories: ["Agent identity/auth", "AI safety/alignment", "Policy/governance"]
rated_at: 2026-02-27T23:15:37.837706+00:00
summary:
Extends Entity Attestation Token (EAT) to support capability attestation for agentic AI systems. Enables secure assertion of agent functional, reasoning, and operational capabilities.


draft_name: draft-yan-a2a-device-agent-applicability
novelty_note: Applies A2A concepts to network management domain with device agents
maturity_note: Well-developed at 19 pages with detailed workflows and scenarios
overlap_note: Moderate overlap with existing network management and A2A work
momentum_note: Strong alignment with network automation trends and SDN evolution
relevance_note: Very relevant to autonomous network operations and management
categories: ["A2A protocols", "Autonomous netops", "Data formats/interop"]
rated_at: 2026-02-27T23:15:37.850191+00:00
summary:
Discusses applying Agent-to-Agent (A2A) Protocol to network management for communication between Controller and Device Agents. Explores integration with existing protocols like NETCONF and RESTCONF.


draft_name: draft-cui-dns-native-agent-naming-resolution
novelty_note: Creative use of existing DNS infrastructure for agent discovery and identity
maturity_note: Comprehensive 26-page specification with detailed technical design
overlap_note: Unique DNS-based approach with minimal overlap to other agent work
momentum_note: Leverages proven DNS infrastructure but requires adoption momentum
relevance_note: Extremely relevant for scalable agent ecosystems and internet integration
categories: ["Agent discovery/reg", "Agent identity/auth", "Data formats/interop"]
rated_at: 2026-02-27T23:15:37.860827+00:00
summary:
Specifies DNS-native naming and resolution for AI agents using FQDNs and SVCB records. Emphasizes DNS as authoritative source with graceful degradation for legacy clients.


draft_name: draft-goswami-agentic-jwt
novelty_note: Addresses fundamental new problem of intent-execution separation in AI agents
maturity_note: Extensive 71-page specification with security analysis and validation
overlap_note: Novel approach to OAuth extension with minimal overlap
momentum_note: Addresses critical security needs for enterprise AI adoption
relevance_note: Extremely relevant for secure autonomous agent deployment
categories: ["Agent identity/auth", "AI safety/alignment", "Policy/governance"]
rated_at: 2026-02-27T23:15:37.869941+00:00
summary:
Extends OAuth 2.0 with Agentic JWT to address authorization challenges in autonomous AI systems. Introduces cryptographic agent identity and workflow-aware token binding to solve intent-execution separation.


draft_name: draft-zhang-aiproto-svcb-mapping-for-agents
novelty_note: New DNS record type specifically for agent services
maturity_note: Short 6-page draft with basic mapping specifications
overlap_note: Significant overlap with draft-cui-dns-native-agent-naming-resolution
momentum_note: Competing approach to DNS-based agent resolution may limit adoption
relevance_note: Relevant but potentially redundant with other DNS-based agent work
categories: ["Agent discovery/reg", "Data formats/interop"]
rated_at: 2026-02-27T23:15:37.881461+00:00
summary:
Defines new DNS resource record type AGENT as SVCB-compatible RR for agent service resolution. Addresses limitations of current DNS for intelligent agent protocols.


draft_name: draft-chen-ai-agent-auth-new-requirements
maturity_note: Early stage requirements document, lacks concrete solutions or implementation details
overlap_note: Unique focus on AI agent auth requirements, no direct overlap with other drafts
momentum_note: Addresses critical security gap but needs broader community input and technical solutions
relevance_note: Extremely relevant as AI agents proliferate and existing auth frameworks prove inadequate
categories: ["Agent identity/auth", "AI safety/alignment"]
rated_at: 2026-02-27T23:15:59.577405+00:00
summary:
Identifies new authentication and authorization requirements for AI agents that go beyond traditional human-user frameworks. Focuses on managing dynamic agent behavior rather than static identity verification.

novelty_note:
Novel focus on dynamic behavior-based auth vs static identity, addressing fundamental paradigm shift for AI agents


draft_name: draft-chen-oauth-rar-agent-extensions
novelty_note: Concrete extensions to established OAuth RAR standard, novel lifecycle binding concept
maturity_note: Well-structured technical solution building on RFC 9396, includes specific implementation details
overlap_note: Builds on OAuth RAR but addresses distinct AI agent requirements not covered elsewhere
momentum_note: Strong technical foundation on established standard, clear implementation path
relevance_note: Highly relevant for securing AI agent interactions with practical OAuth integration
categories: ["Agent identity/auth", "A2A protocols", "Policy/governance"]
rated_at: 2026-02-27T23:15:59.586071+00:00
summary:
Extends OAuth RAR with policy_context and lifecycle_binding members for AI agent environments. Enables policy assurance levels and task-bound authorization lifetimes.


draft_name: draft-han-ai-agent-impact-infra
novelty_note: General analysis document, limited novel technical insights
maturity_note: Basic discussion document with analysis issues, needs more technical depth
overlap_note: Some overlap with other infrastructure-focused AI agent discussions
momentum_note: Broad scope but lacks concrete proposals, may struggle to gain traction
relevance_note: Moderately relevant for understanding infrastructure impacts but lacks actionable content
categories: ["Autonomous netops", "ML traffic mgmt"]
rated_at: 2026-02-27T23:15:59.594943+00:00
summary:
Discusses and analyzes the impact of AI agents on network infrastructure. Aims to facilitate IETF discussion and standardization efforts.


draft_name: draft-yu-dmsc-ai-agent-use-cases-in-6g
novelty_note: Largely references existing 3GPP work, limited novel contribution beyond compilation
maturity_note: Decent compilation of use cases but heavily dependent on external specifications
overlap_note: Significant overlap with 3GPP work and general 6G AI discussions
momentum_note: Benefits from 3GPP backing but unclear IETF-specific value proposition
relevance_note: Relevant for 6G context but limited broader applicability beyond telecom
categories: ["Autonomous netops", "ML traffic mgmt", "Agent discovery/reg"]
rated_at: 2026-02-27T23:15:59.608065+00:00
summary:
Introduces AI agent use cases in 6G networks based on 3GPP SA1 technical reports. Elaborates on operator requirements for AI agent integration.


draft_name: draft-chang-agent-token-efficient
maturity_note: Well-developed technical solution with specific mechanisms and backward compatibility
overlap_note: Addresses efficiency concerns not directly tackled by other agent communication drafts
momentum_note: Solves real performance problem with practical implementation approach
relevance_note: Extremely relevant as LLM token costs and context limits are major practical constraints
categories: ["A2A protocols", "Data formats/interop", "Model serving/inference"]
rated_at: 2026-02-27T23:15:59.616695+00:00
summary:
Defines ADOL (Agentic Data Optimization Layer) to address token bloat in agent communication protocols. Introduces schema deduplication, adaptive fields, and retrieval-based selection.

novelty_note:
Highly novel approach to token efficiency problem, introduces concrete technical solutions with ADOL framework


draft_name: draft-fu-nmop-agent-communication-framework
novelty_note: Standard multi-agent coordination approach but network operations focus adds domain-specific value
maturity_note: Early stage framework with basic architectural components outlined but limited technical detail
overlap_note: Significant overlap with other agent communication and discovery drafts in this set
momentum_note: Network operations domain has established interest but multi-agent approach is emerging
relevance_note: Highly relevant as networks become more complex and autonomous operations gain traction
categories: ["A2A protocols", "Autonomous netops", "Agent discovery/reg"]
rated_at: 2026-02-27T23:16:21.771805+00:00
summary:
Proposes a multi-agent communication framework for network AIOps with AI gateway, Agent Name Service, and security features. Focuses on coordinating heterogeneous agents for intelligent network operations and maintenance.


draft_name: draft-pioli-agent-discovery
novelty_note: Well-defined protocol approach to agent discovery with practical transport-agnostic design
maturity_note: More concrete protocol specification with clear technical components and interoperability focus
overlap_note: Overlaps with discovery aspects of other drafts but focuses specifically on the protocol layer
momentum_note: Agent discovery is fundamental need but market adoption unclear
relevance_note: Essential building block for distributed agent systems across many domains
categories: ["Agent discovery/reg", "Agent identity/auth", "A2A protocols"]
rated_at: 2026-02-27T23:16:21.782254+00:00
summary:
Specifies ARDP, a lightweight protocol for agent registration and discovery in distributed environments. Provides stable identities, endpoint resolution, capability advertisement, and security-first discovery.


draft_name: draft-yue-anima-agent-recovery-networks
novelty_note: Novel application of multi-agent systems to specific mobile network recovery challenges
maturity_note: Domain-specific approach with clear use cases but implementation details need development
overlap_note: Unique focus on mobile network recovery though shares general multi-agent concepts
momentum_note: 5G/6G network complexity drives strong industry need for automated recovery solutions
relevance_note: Extremely relevant as mobile networks become more complex and require autonomous management
categories: ["Autonomous netops", "A2A protocols", "Policy/governance"]
rated_at: 2026-02-27T23:16:21.793473+00:00
summary:
Defines task-oriented multi-agent framework for fault recovery in converged mobile networks. Targets 5G/6G deployments like MOCN and SNPN where centralized management is insufficient.


draft_name: draft-diaconu-agents-authz-info-sharing
novelty_note: Applies existing identity/authorization concepts to multi-agent context with cross-domain focus
overlap_note: Overlaps with identity aspects of cross-domain drafts but deeper focus on authorization specifics
momentum_note: Authorization is critical for agent deployment but competing standards may emerge
relevance_note: Essential for practical multi-domain agent systems where security is paramount
categories: ["Agent identity/auth", "Policy/governance", "AI safety/alignment"]
rated_at: 2026-02-27T23:16:21.802362+00:00
summary:
Addresses authorization challenges in distributed multi-agent systems across multiple domains. Covers dynamic identity, interoperable claims, and verifiable credentials for secure cross-domain authorization.

maturity_note:
Substantial document addressing real security challenges but builds on established identity patterns


draft_name: draft-cui-dmsc-agent-cdi
maturity_note: Extensive framework but appears early stage with broad scope requiring significant development
overlap_note: Heavy overlap with authorization draft and touches on discovery/communication aspects
momentum_note: Cross-domain interoperability is important but complexity may limit adoption
relevance_note: Addresses fundamental challenge for large-scale agent deployment across organizations
categories: ["Agent identity/auth", "Data formats/interop", "Policy/governance", "A2A protocols"]
rated_at: 2026-02-27T23:16:21.812540+00:00
summary:
Defines comprehensive framework for cross-domain AI agent interoperability including identity federation and trust establishment. Enables multi-domain collaboration without centralized control.

novelty_note:
Comprehensive approach to cross-domain agent interoperability combining multiple established concepts


draft_name: draft-chang-agent-context-interaction
maturity_note: Brief abstract and early stage development suggest limited technical depth
overlap_note: Overlaps with agent communication and workflow management concepts
momentum_note: Single author draft with minimal detail suggests limited momentum
relevance_note: Context management is crucial for practical multi-agent systems
categories: ["A2A protocols", "ML traffic mgmt"]
rated_at: 2026-02-27T23:16:40.600967+00:00
summary:
Defines procedures for distributing context among multiple agents in complex workflows. Aims to optimize execution latency, token consumption, and task success rates.

novelty_note:
Context distribution optimization is novel but builds on established multi-agent coordination concepts


draft_name: draft-agent-gw
novelty_note: Comprehensive gateway architecture with semantic routing and working memory is quite novel
maturity_note: Good architectural overview but implementation details appear limited
overlap_note: Some overlap with general gateway concepts but agent-specific features are unique
momentum_note: Solid architectural vision but unclear community adoption
relevance_note: Addresses critical infrastructure needs for multi-agent systems
categories: ["A2A protocols", "Agent discovery/reg", "Data formats/interop"]
rated_at: 2026-02-27T23:16:40.613657+00:00
summary:
Proposes an Intelligent Agent Communication Gateway for large-scale multi-agent collaboration. Features semantic routing, working memory, and protocol adaptation mechanisms.


draft_name: draft-birkholz-verifiable-agent-conversations
novelty_note: Verifiable conversation records for agents is novel and addresses important trust concerns
maturity_note: Comprehensive 51-page specification with detailed CDDL definitions shows high maturity
overlap_note: Builds on existing standards but application to agent conversations is unique
momentum_note: Established author with detailed specification suggests strong momentum
relevance_note: Critical for agent accountability and regulatory compliance
categories: ["AI safety/alignment", "Data formats/interop", "Policy/governance"]
rated_at: 2026-02-27T23:16:40.623658+00:00
summary:
Defines CDDL-based data format for verifiable agent conversation records using COSE signing. Supports accountability, compliance, and cross-vendor interoperability for agent interactions.


draft_name: draft-mishra-oauth-agent-grants
novelty_note: Agent-specific OAuth extension with DID integration and cascade revocation is novel
maturity_note: Well-developed 27-page specification with clear protocol definitions
overlap_note: Extends OAuth 2.0 but agent-specific features reduce overlap
momentum_note: Addresses clear market need but adoption uncertain
relevance_note: Essential for secure agent authorization in production systems
categories: ["Agent identity/auth", "Policy/governance", "Human-agent interaction"]
rated_at: 2026-02-27T23:16:40.634775+00:00
summary:
Extends OAuth 2.0 for AI agent authorization with human consent verification, revocation, and audit trails. Uses DIDs for agent identity and provides multi-agent delegation capabilities.


draft_name: draft-sipos-dtn-bp-safe
novelty_note: DTN-specific security associations are somewhat novel but follow established patterns
maturity_note: Comprehensive 77-page specification with detailed protocol definitions
overlap_note: Significant overlap with general security association protocols
momentum_note: Mature specification but DTN market is niche
relevance_note: Limited relevance to mainstream AI agent deployments
categories: ["Agent identity/auth", "Autonomous netops"]
rated_at: 2026-02-27T23:16:40.647795+00:00
summary:
Defines security association negotiation protocol for Bundle Protocol agents in delay-tolerant networks. Optimizes asymmetric-key operations for high-throughput DTN security.


draft_name: draft-jiang-seat-dynamic-attestation
novelty_note: Novel application of remote attestation to AI agent runtime verification with dynamic updates
maturity_note: Early stage use case description, lacks detailed protocol specification
overlap_note: Some overlap with general remote attestation work but AI agent focus is distinct
momentum_note: Addresses real need for trusted AI agent communication but limited detail
relevance_note: Highly relevant for secure AI agent deployments and trust establishment
categories: ["Agent identity/auth", "AI safety/alignment", "A2A protocols"]
rated_at: 2026-02-27T23:17:02.015074+00:00
summary:
Defines dynamic attestation mechanisms for AI agents to convey runtime posture changes during long-lived TLS sessions. Enables relying parties to make authorization decisions based on current agent state including platform TCB, manifest, and runtime context.


draft_name: draft-gaikwad-woa
novelty_note: Straightforward application of existing web standards to agent description and invocation
maturity_note: Reasonable level of detail for interface specification, builds on established HTTP/JSON patterns
overlap_note: Similar to OpenAPI/service description approaches but agent-specific
momentum_note: Practical approach leveraging web infrastructure, moderate interest likely
relevance_note: Very relevant for web-based agent interoperability and standardization
categories: ["Agent discovery/reg", "Data formats/interop", "A2A protocols"]
rated_at: 2026-02-27T23:17:02.025529+00:00
summary:
Specifies Web of Agents (WoA) format using JSON Schema to describe AI agent inputs/outputs served from well-known HTTP locations. Provides uniform invocation convention for HTTP-hosted AI agents without defining discovery protocols.


draft_name: draft-ietf-lisp-nexagon
novelty_note: Creative combination of LISP routing with H3 geospatial indexing for agent networks
maturity_note: Well-developed protocol specification with clear technical foundation
overlap_note: Builds on LISP and H3 but novel combination for agent-based geospatial applications
momentum_note: IETF working group adoption indicates strong momentum and community support
relevance_note: Highly relevant for location-aware autonomous systems and IoT agent deployments
categories: ["Autonomous netops", "A2A protocols", "Data formats/interop"]
rated_at: 2026-02-27T23:17:02.035799+00:00
summary:
Combines LISP with H3 spatial indexing to create geospatial intelligence network for physical-world applications. Enables distributed agents to report, aggregate, and disseminate location-based state information for transportation and logistics.


draft_name: draft-cosmos-protocol-specification
maturity_note: Very early stage with broad scope, appears incomplete based on abstract truncation
overlap_note: Some concepts exist separately but this specific integration approach is unique
momentum_note: Complex scope may hinder adoption, unclear community backing
relevance_note: Addresses important identity and trust challenges but may be overly ambitious
categories: ["Agent identity/auth", "A2A protocols", "Policy/governance"]
rated_at: 2026-02-27T23:17:02.045721+00:00
summary:
Defines comprehensive badge-based identity and communication system with trust scoring, post-quantum encryption, and semantic messaging. Designed for deployments preferring to avoid external blockchain infrastructure while supporting decentralized identity management.

novelty_note:
Ambitious integration of multiple novel concepts: badge identity, trust scoring, post-quantum crypto, semantic grammar


draft_name: draft-kale-agntcy-federated-privacy
novelty_note: Standard application of known federated learning techniques to multi-tenant agent scenarios
maturity_note: Reference architecture with established privacy techniques, reasonable technical depth
overlap_note: Significant overlap with existing federated learning and differential privacy literature
momentum_note: Addresses practical deployment concerns, moderate community interest expected
relevance_note: Very relevant for enterprise AI agent deployments requiring privacy preservation
categories: ["ML traffic mgmt", "AI safety/alignment", "Policy/governance"]
rated_at: 2026-02-27T23:17:02.054448+00:00
summary:
Specifies architecture for privacy-preserving federated learning across multi-tenant AI agent systems. Combines federated averaging, differential privacy, and secure aggregation to enable cross-organizational model training while maintaining data isolation.


draft_name: draft-li-dmsc-inf-architecture
maturity_note: Early stage architectural framework, lacks implementation details and validation
overlap_note: Related to other DMSC drafts but focuses specifically on infrastructure layer
momentum_note: Part of coordinated DMSC effort, moderate early interest expected
relevance_note: Highly relevant as agent systems scale and need infrastructure support
categories: ["Autonomous netops", "A2A protocols", "ML traffic mgmt"]
rated_at: 2026-02-27T23:17:22.389328+00:00
summary:
Proposes a network infrastructure architecture for large-scale multi-agent collaboration. Focuses on how network control and forwarding functions can actively participate in agent coordination.

novelty_note:
Novel application of network infrastructure to agent collaboration, but builds on existing networking concepts


draft_name: draft-liu-dmsc-gw-requirements
novelty_note: Applies gateway concepts to agent systems with some novel requirements
maturity_note: Requirements document without protocol specification or implementation
overlap_note: Complements DMSC architecture draft, minimal overlap with existing gateway specs
momentum_note: Limited scope may restrict broader community engagement
relevance_note: Moderately relevant for agent system scaling, but more specialized use case
categories: ["A2A protocols", "Agent identity/auth", "Data formats/interop"]
rated_at: 2026-02-27T23:17:22.401502+00:00
summary:
Defines requirements for gateways in multi-agent systems to improve scalability and security. Identifies gaps in current gateway solutions for agent collaboration.


draft_name: draft-zhang-dmsc-mas-communication
novelty_note: Good analysis of agent-specific security challenges not well addressed by current protocols
maturity_note: Solid problem analysis but lacks proposed solutions
overlap_note: Unique security analysis perspective on agent communication
momentum_note: Security analysis likely to generate significant community interest and discussion
relevance_note: Very relevant as agent systems need security models beyond traditional web protocols
categories: ["A2A protocols", "AI safety/alignment", "Agent identity/auth"]
rated_at: 2026-02-27T23:17:22.429401+00:00
summary:
Analyzes security risks in multi-agent communication and limitations of existing protocols like TLS and HTTP. Establishes problem statement for agent-native security needs.


draft_name: draft-guy-bary-stamp-protocol
novelty_note: Novel cryptographic approach specifically designed for agent delegation and task binding
maturity_note: Well-developed protocol specification with clear integration points
overlap_note: Unique protocol design, minimal overlap with existing auth mechanisms
momentum_note: Strong technical approach likely to attract security and auth working group attention
relevance_note: Highly relevant for secure agent deployments and enterprise adoption
categories: ["Agent identity/auth", "AI safety/alignment", "A2A protocols"]
rated_at: 2026-02-27T23:17:22.438697+00:00
summary:
Defines STAMP protocol for cryptographic delegation and proof in AI agent systems. Provides task-bound tokens and integrates with OAuth 2.0 and zero-trust principles.


draft_name: draft-abaris-aicdh
novelty_note: Straightforward application of HTTP headers to AI content disclosure
maturity_note: Clear specification but limited scope and technical complexity
overlap_note: Some similarity to content-type headers but AI-specific application is unique
momentum_note: Simple enough for quick adoption but may face policy/governance debates
relevance_note: Moderately relevant for AI transparency but peripheral to core networking concerns
categories: ["Data formats/interop", "Policy/governance", "Human-agent interaction"]
rated_at: 2026-02-27T23:17:22.447906+00:00
summary:
Proposes HTTP header for disclosing AI-generated content in web responses. Provides machine-readable metadata for user agents and archiving systems.


draft_name: draft-sz-dmsc-iaip
novelty_note: Novel semantic intent-based routing approach for AI agents with dynamic capability matching
maturity_note: Early stage specification with broad scope but limited implementation detail
overlap_note: Overlaps with DNS-AID and AWP on agent discovery, but uses different semantic intent approach
momentum_note: Addresses emerging need for agent interconnection but lacks clear adoption path
relevance_note: Highly relevant for multi-agent systems and agent interoperability infrastructure
categories: ["A2A protocols", "Agent discovery/reg", "Data formats/interop"]
rated_at: 2026-02-27T23:17:43.791753+00:00
summary:
Defines Intent-based Agent Interconnection Protocol (IAIP) for dynamic agent discovery and routing at gateways based on semantic intent rather than static addressing. Enables capability-based agent matching and dispatching.


draft_name: draft-jia-oauth-scope-aggregation
novelty_note: Practical extension to existing OAuth for AI workflow optimization
maturity_note: Well-defined problem with clear solution building on established OAuth framework
overlap_note: Extends OAuth but addresses AI-specific use case not covered elsewhere
momentum_note: Strong potential adoption given OAuth ubiquity and clear efficiency benefits
relevance_note: Very relevant for AI agent authorization and workflow management
categories: ["Agent identity/auth", "Policy/governance"]
rated_at: 2026-02-27T23:17:43.804290+00:00
summary:
Extends OAuth 2.0 with scope aggregation to reduce authorization round-trips in multi-step AI agent workflows. Improves efficiency by bundling required permissions upfront.


draft_name: draft-mozleywilliams-dnsop-dnsaid
novelty_note: Leverages proven DNS infrastructure for new AI agent discovery use case
maturity_note: Well-structured specification building on solid DNS foundation with clear scope
overlap_note: Overlaps with IAIP on agent discovery but uses different DNS-based approach
momentum_note: High adoption potential due to DNS ubiquity and no protocol changes required
relevance_note: Highly relevant for scalable agent discovery and interoperability
categories: ["Agent discovery/reg", "Data formats/interop"]
rated_at: 2026-02-27T23:17:43.816826+00:00
summary:
Uses existing DNS infrastructure for AI agent discovery through structured namespace and metadata exchange. Enables organizations to publish agent capabilities in their DNS domains.


draft_name: draft-ietf-anima-brski-prm
novelty_note: Incremental enhancement to existing BRSKI protocol for specific deployment scenarios
maturity_note: Mature specification with detailed protocol mechanics and comprehensive coverage
overlap_note: Extends BRSKI but addresses distinct use case not covered by other AI agent drafts
momentum_note: Limited to specific BRSKI deployment scenarios but addresses real operational need
relevance_note: Low relevance to AI agents specifically, focused on general device bootstrapping
categories: ["Agent identity/auth", "Autonomous netops"]
rated_at: 2026-02-27T23:17:43.829453+00:00
summary:
Enhances BRSKI for device bootstrapping where pledges act as servers in responder mode. Introduces registrar-agent component for scenarios with limited registrar communication.


draft_name: draft-vinaysingh-awp-wellknown
novelty_note: Simple approach to structured agent-web interaction using established well-known URI pattern
maturity_note: Concise specification with clear scope, though limited technical depth
overlap_note: Complements other agent discovery mechanisms but focuses on web workflow exposure
momentum_note: Moderate potential given simplicity but requires website operator adoption
relevance_note: Relevant for web-based agent interactions and structured workflow automation
categories: ["Human-agent interaction", "Data formats/interop", "Agent discovery/reg"]
rated_at: 2026-02-27T23:17:43.848351+00:00
summary:
Defines well-known URI and link relation for exposing website workflows to automated agents. Provides minimal JSON format for agent interaction without web scraping.


draft_name: draft-yang-ioa-protocol
novelty_note: Novel protocol specifically for multi-agent collaboration with focus on heterogeneous systems
maturity_note: Well-structured but lacks implementation details and security considerations
overlap_note: Some overlap with general agent communication but focused on collaboration aspects
momentum_note: Targets emerging 6G scenarios which may drive adoption
relevance_note: Highly relevant as multi-agent systems become more prevalent
categories: ["A2A protocols", "Agent discovery/reg", "Data formats/interop"]
rated_at: 2026-02-27T23:18:02.837871+00:00
summary:
Defines the Internet of Agents Protocol for distributed collaboration among heterogeneous AI agents. Provides layered architecture for dynamic team formation and task coordination across diverse agent types.


draft_name: draft-blahaj-grow-rpki-oauth
novelty_note: Creative combination of RPKI and OIDC for network operator authentication
maturity_note: Brief draft with limited technical detail and implementation guidance
overlap_note: Unique approach combining these specific technologies
momentum_note: Limited to specific peering use case with uncertain broader adoption
relevance_note: Relevant for network peering but narrow application scope
categories: ["Agent identity/auth", "Policy/governance"]
rated_at: 2026-02-27T23:18:02.848944+00:00
summary:
Specifies method to bind OpenID Connect authentication to ASN agents using RPKI infrastructure. Addresses authentication gaps in the GROW Working Group's Peering API.


draft_name: draft-cui-nmrg-llm-benchmark
novelty_note: First standardized benchmarking framework for LLM network agents
maturity_note: Detailed framework with clear metrics and comprehensive evaluation approach
overlap_note: No similar standardized benchmarking approaches identified
momentum_note: Strong research interest in LLM network applications drives relevance
relevance_note: Critical for advancing LLM network applications with standardized evaluation
categories: ["Autonomous netops", "Policy/governance", "Data formats/interop"]
rated_at: 2026-02-27T23:18:02.861633+00:00
summary:
Provides comprehensive evaluation framework for LLM-based network configuration agents. Includes emulator environment, task suites, and multi-dimensional assessment metrics.


draft_name: draft-jiang-cats-reference-acn
novelty_note: Extends existing CATS work to AI agent domain with new reference model
maturity_note: High-level reference model lacking detailed protocol specifications
overlap_note: Builds heavily on existing CATS framework with agent-specific extensions
momentum_note: Benefits from existing CATS momentum but limited to that community
relevance_note: Relevant for CATS community but narrow focus on specific architecture
categories: ["A2A protocols", "ML traffic mgmt", "Data formats/interop"]
rated_at: 2026-02-27T23:18:02.872537+00:00
summary:
Extends CATS framework to support AI-agent Communication Networks with reference architecture. Defines protocol stacks and signaling for agent-to-agent communication services.


draft_name: draft-aylward-daap-v2
novelty_note: Comprehensive approach to critical AI safety and accountability challenges
maturity_note: Well-developed protocol with detailed security and governance mechanisms
overlap_note: Unique focus on comprehensive AI accountability and safety controls
momentum_note: High urgency due to growing AI safety concerns and regulatory pressure
relevance_note: Extremely relevant given current AI safety and governance discussions
categories: ["AI safety/alignment", "Agent identity/auth", "Policy/governance"]
rated_at: 2026-02-27T23:18:02.881115+00:00
summary:
Defines comprehensive protocol for AI agent accountability including authentication, monitoring, and remote control. Addresses AI safety through cryptographic identity verification and behavioral oversight.


draft_name: draft-mozley-aidiscovery
novelty_note: Novel focus on agent discovery protocols, addressing emerging need as AI agents proliferate
maturity_note: Early stage problem statement, only 8 pages, lacks concrete protocol specification
overlap_note: Unique focus on AI agent discovery, no significant overlap with existing drafts
momentum_note: Addresses timely need but limited concrete progress shown
relevance_note: Highly relevant as AI agents become more common and need discovery mechanisms
categories: ["Agent discovery/reg", "A2A protocols"]
rated_at: 2026-02-27T23:18:23.215310+00:00
summary:
Defines requirements and considerations for AI agent-to-agent discovery mechanisms. Addresses the fundamental problem of how AI agents locate and identify each other in distributed systems.


draft_name: draft-gupta-httpapi-events-query
novelty_note: Builds on existing HTTP but novel application to direct resource-based event notifications
maturity_note: Well-developed at 29 pages with detailed protocol specification
overlap_note: Some overlap with existing HTTP event mechanisms like Server-Sent Events
momentum_note: Solid technical foundation but unclear adoption trajectory
relevance_note: Relevant for AI agents needing event streams, but not AI-specific
categories: ["Data formats/interop", "Human-agent interaction"]
rated_at: 2026-02-27T23:18:23.226453+00:00
summary:
Proposes Events Query Protocol (EQP) built on HTTP for user agents to receive event notifications directly from resources. Offers intuitive approach where resources themselves are event sources.


draft_name: draft-jewell-aibdp
novelty_note: Highly novel approach to AI governance through declarative boundary protocols
maturity_note: Short at 6 pages, appears early stage despite comprehensive scope claims
overlap_note: Some conceptual overlap with robots.txt but significantly different focus on AI boundaries
momentum_note: High relevance to current AI governance debates suggests good momentum potential
relevance_note: Extremely relevant to current AI ethics and governance concerns
categories: ["Policy/governance", "AI safety/alignment"]
rated_at: 2026-02-27T23:18:23.238777+00:00
summary:
Defines AI Boundary Declaration Protocol for expressing content usage boundaries for AI systems. Provides machine-readable permissions and denials for AI training, indexing, and access.


draft_name: draft-rosenberg-oauth-aauth
novelty_note: Novel OAuth extension specifically designed for AI agent authentication challenges
maturity_note: Moderate maturity at 10 pages with specific technical approach
overlap_note: Extends existing OAuth but addresses unique AI agent use cases
momentum_note: Addresses practical AI deployment needs but faces significant security challenges
relevance_note: Highly relevant for AI agent deployment in practical scenarios
categories: ["Agent identity/auth", "AI safety/alignment"]
rated_at: 2026-02-27T23:18:23.248390+00:00
summary:
Extends OAuth 2.1 for AI agents operating through PSTN/SMS channels to obtain access tokens using PII collected via natural language. Addresses hallucination-based impersonation risks.


draft_name: draft-kompella-lsr-mptecap
novelty_note: Incremental extension to existing traffic engineering capabilities advertising
maturity_note: Concise but complete at 6 pages, builds on established IGP mechanisms
overlap_note: Significant overlap with existing TE capabilities and IGP extensions
momentum_note: Limited to specific networking community, not AI-focused
relevance_note: Limited relevance to AI/agent systems, traditional networking focus
categories: ["ML traffic mgmt"]
rated_at: 2026-02-27T23:18:23.258477+00:00
summary:
Defines capabilities advertising for Multipath Traffic Engineering (MPTE) in IGP routing protocols. Enables nodes to advertise MPTE support for tunnel provisioning decisions.


draft_name: draft-rosenberg-cheq
novelty_note: Novel approach to AI safety through structured confirmation protocol with privacy protection
maturity_note: Well-defined protocol but lacks implementation details and security analysis
overlap_note: Some overlap with general AI safety approaches but protocol specifics are unique
momentum_note: Addresses important AI safety concerns but limited community involvement evident
relevance_note: Highly relevant as AI agents become more autonomous and safety becomes critical
categories: ["AI safety/alignment", "Human-agent interaction", "A2A protocols"]
rated_at: 2026-02-27T23:18:42.916404+00:00
summary:
Proposes CHEQ protocol for human-in-the-loop confirmation of AI agent decisions before execution. Uses signed objects to prevent AI hallucinations from causing unwanted actions while protecting human privacy.


draft_name: draft-leon-distributed-multi-signer
novelty_note: Extends existing DNSSEC multi-signer concepts with distributed approach
maturity_note: Comprehensive 31-page specification with detailed technical mechanisms
overlap_note: Builds on RFC8901 multi-signer model but adds distributed aspects
momentum_note: DNSSEC automation has steady interest but limited to DNS community
relevance_note: Limited AI/agent relevance beyond DNS infrastructure automation
categories: ["Autonomous netops", "Data formats/interop"]
rated_at: 2026-02-27T23:18:42.928764+00:00
summary:
Defines distributed DNSSEC multi-signer architecture with multi-signer agents and combiners. Introduces HSYNC RRtype and secure communication mechanisms between MSAs.


draft_name: draft-mp-agntcy-ads
novelty_note: First comprehensive directory service specifically designed for AI agent discovery
maturity_note: Good conceptual framework but needs more protocol specification detail
overlap_note: Unique approach to agent discovery, minimal overlap with existing directory services
momentum_note: Agent discovery is important problem but early stage development
relevance_note: Extremely relevant for AI agent ecosystem scalability and interoperability
categories: ["Agent discovery/reg", "Data formats/interop", "A2A protocols"]
rated_at: 2026-02-27T23:18:42.940878+00:00
summary:
Describes Agent Directory Service for storing and discovering AI agent metadata based on skills. Features distributed directories with content-routing protocol for agent discovery.


draft_name: draft-steckbeck-ua-conn-sec
novelty_note: Incremental improvement to existing web security policies like CSP
maturity_note: Brief 6-page document lacks detailed specification and implementation guidance
overlap_note: Significant overlap with CSP and other web security frameworks
momentum_note: Limited evidence of community interest or implementation momentum
relevance_note: Tangentially relevant to AI agents that use web resources
categories: ["Policy/governance", "Other AI/agent"]
rated_at: 2026-02-27T23:18:42.950413+00:00
summary:
Proposes framework for user agents to restrict connections to authorized second and third-party resources. Aims to prevent attacks through compromised connected resources.


draft_name: draft-ietf-lamps-e2e-mail-guidance
novelty_note: Guidance document for existing standards rather than novel technical contribution
maturity_note: Mature 68-page IETF working group document with extensive detail
overlap_note: Overlaps with existing email security standards but provides unique implementation guidance
momentum_note: Strong IETF working group backing with clear implementation focus
relevance_note: Limited relevance to AI/agent protocols beyond general secure communication
categories: ["Data formats/interop", "Policy/governance"]
rated_at: 2026-02-27T23:18:42.958809+00:00
summary:
Provides comprehensive guidance for implementing end-to-end email encryption securely. Addresses usability issues and interoperability problems in cryptographic email protection.


draft_name: draft-happel-structured-email-trust
maturity_note: Brief document suggests early stage development with basic recommendations framework
overlap_note: Some overlap with general email security work but specific to structured data trust
momentum_note: Limited scope and length suggests modest community engagement
relevance_note: Relevant as structured email becomes more common, though narrow application domain
categories: ["Data formats/interop", "Agent identity/auth"]
rated_at: 2026-02-27T23:19:02.838685+00:00
summary:
Provides trust and security recommendations for handling structured data in email messages. Focuses on guidance for message user agents to safely process structured email content.

novelty_note:
Addresses growing need for secure structured email handling but builds on existing email security concepts


draft_name: draft-eggert-mailmaint-uaautoconf
novelty_note: Builds on existing autoconfig concepts but provides comprehensive multi-service approach
maturity_note: Substantial 41-page document indicates thorough development and consideration of use cases
overlap_note: Some overlap with existing email autoconfig mechanisms and service discovery protocols
momentum_note: Strong author reputation and comprehensive scope suggests good momentum
relevance_note: Highly relevant for simplifying user experience and reducing configuration errors
categories: ["Agent discovery/reg", "Data formats/interop"]
rated_at: 2026-02-27T23:19:02.855998+00:00
summary:
Specifies automatic configuration mechanism for email, calendar, and contact applications. Enables service providers to publish standardized configuration data for simplified client setup.


draft_name: draft-tojens-dhcp-option-concat-considerations
novelty_note: Incremental improvement addressing deployment reality rather than novel approach
maturity_note: Well-motivated by deployment experience and clear problem statement
overlap_note: Unique focus on this specific DHCP implementation issue
momentum_note: Standards update addressing known interoperability issues should gain support
relevance_note: Important for DHCP implementations but narrow technical scope
categories: ["Data formats/interop"]
rated_at: 2026-02-27T23:19:02.866955+00:00
summary:
Updates RFC 3396 to make DHCP option concatenation requirements more flexible. Addresses real-world implementation deviations from original strict concatenation requirements.


draft_name: draft-cui-nmrg-llm-nm
novelty_note: Novel application of LLMs to network management with structured human-agent collaboration
maturity_note: Comprehensive framework but likely early stage given emerging nature of LLM integration
overlap_note: Some overlap with general AI/ML network management but specific LLM focus is distinctive
momentum_note: High current interest in LLM applications and network automation convergence
relevance_note: Extremely relevant given industry focus on AI-assisted network operations
categories: ["Human-agent interaction", "Autonomous netops", "ML traffic mgmt", "AI safety/alignment"]
rated_at: 2026-02-27T23:19:02.877762+00:00
summary:
Defines framework for collaborative network management between LLM agents and human operators. Introduces enhanced telemetry, decision modules, and human-in-the-loop workflows.


draft_name: draft-eckert-anima-acp-free-ani
novelty_note: Creative simplification of complex ANI architecture while retaining core automation benefits
maturity_note: Detailed technical approach with clear trade-offs and implementation considerations
overlap_note: Builds heavily on existing ANIMA work but with significant architectural changes
momentum_note: Strong technical foundation but depends on broader ANIMA adoption momentum
relevance_note: Highly relevant for making autonomic networking more implementable and practical
categories: ["Autonomous netops", "Agent identity/auth", "A2A protocols", "Agent discovery/reg"]
rated_at: 2026-02-27T23:19:02.893746+00:00
summary:
Describes lightweight variation of Autonomic Networking Infrastructure without expensive ACP implementation. Uses existing ANI certificates and protocols with application-level software agents.


draft_name: draft-meunier-webbotauth-registry
novelty_note: Builds on existing agent card concepts but adds signature-specific elements
maturity_note: Basic format definition with registry setup, needs more implementation details
overlap_note: Some overlap with general agent identity work but signature focus is distinct
momentum_note: Early draft with limited community engagement visible
relevance_note: Agent identity and discovery are critical infrastructure needs for AI systems
categories: ["Agent identity/auth", "Agent discovery/reg", "Data formats/interop"]
rated_at: 2026-02-27T23:19:22.709790+00:00
summary:
Defines a JSON format for web bot signature agent cards to advertise identity, purpose, and cryptographic keys. Establishes IANA registry for extensible agent metadata discovery.


draft_name: draft-rosenberg-aiproto-cheq
novelty_note: Novel approach to human-in-the-loop validation with privacy protection
maturity_note: Well-defined protocol with integration points but needs more technical detail
overlap_note: Unique focus on decision confirmation, complements but doesn't overlap existing protocols
momentum_note: Addresses critical safety concern with clear integration path
relevance_note: Essential safety mechanism for AI agent deployment in production environments
categories: ["Human-agent interaction", "AI safety/alignment", "A2A protocols"]
rated_at: 2026-02-27T23:19:22.720159+00:00
summary:
Proposes CHEQ protocol for human confirmation of AI agent decisions before execution. Protects against AI hallucinations while preserving human privacy in tool invocation.


draft_name: draft-ietf-dnsop-ds-automation
novelty_note: Operational guidance for existing standards rather than new technical innovation
maturity_note: Mature operational guidance from working group with practical focus
overlap_note: Specific to DNS operations with no overlap with AI/agent work
momentum_note: Working group draft with clear operational need and community support
relevance_note: DNS-specific operational guidance, not relevant to AI/agent protocols
categories: ["Other AI/agent"]
rated_at: 2026-02-27T23:19:22.730474+00:00
summary:
Provides operational recommendations for automated DS parameter acceptance in DNS. Addresses technical decisions around validation checks and multi-party coordination.


draft_name: draft-ramakrishna-satp-views-addresses
novelty_note: Novel abstraction for cross-DLT asset views with comprehensive security model
maturity_note: Detailed technical specification but complex system requiring extensive validation
overlap_note: Some overlap with general interoperability work but DLT focus is distinct
momentum_note: Addresses growing need for blockchain interoperability
relevance_note: Relevant for AI agents handling digital assets but narrow application domain
categories: ["Data formats/interop", "Agent identity/auth"]
rated_at: 2026-02-27T23:19:22.740622+00:00
summary:
Defines view and addressing mechanisms for secure asset transfer between DLT systems. Enables cross-system asset interoperability with access control and verification.


draft_name: draft-takagi-srta-trinity
novelty_note: Highly novel theological approach to AI safety architecture
maturity_note: Very early conceptual work with limited technical specification
overlap_note: Unique approach unlike any existing AI safety or coordination work
momentum_note: Speculative work with unclear practical implementation path
relevance_note: Important safety topic but too theoretical for current practical needs
categories: ["AI safety/alignment", "Policy/governance", "A2A protocols"]
rated_at: 2026-02-27T23:19:22.749957+00:00
summary:
Proposes SRTA architecture and Trinity Configuration for safe AGI coordination using theological analogy. Presents theoretical framework for superintelligence governance.


draft_name: draft-ramakrishna-satp-data-sharing
maturity_note: Well-structured protocol definition but needs implementation validation and security analysis
overlap_note: Some overlap with blockchain interoperability work but focused on specific data sharing use case
momentum_note: Limited community engagement evident, needs broader blockchain ecosystem adoption
relevance_note: Relevant for multi-chain environments but primarily traditional DLT rather than AI agents
categories: ["Data formats/interop", "A2A protocols"]
rated_at: 2026-02-27T23:19:43.393999+00:00
summary:
Defines a DLT-neutral protocol for sharing asset views and metadata across blockchain networks via gateway nodes. Enables cross-system interoperability while preserving native consensus mechanisms.

novelty_note:
Builds on existing blockchain interoperability concepts but provides specific gateway protocol design


draft_name: draft-liu-oauth-a2a-profile
novelty_note: Novel application of OAuth Transaction Tokens specifically for agent-to-agent scenarios
maturity_note: Very brief draft at 5 pages, needs substantial development and detail
overlap_note: Builds on existing OAuth work but applies it to new agent communication domain
momentum_note: Addresses emerging need for agent authentication but needs broader community input
relevance_note: Highly relevant for AI agent ecosystems requiring secure inter-agent communication
categories: ["Agent identity/auth", "A2A protocols"]
rated_at: 2026-02-27T23:19:43.405655+00:00
summary:
Specifies OAuth Transaction Token profile for Agent-to-Agent communication. Embeds call chain context to maintain agent identity and authorization across distributed agent workloads.


draft_name: draft-ye-problems-and-requirements-of-dns-for-ioa
novelty_note: First systematic analysis of DNS requirements specifically for Internet of Agents
maturity_note: Problem statement stage with limited concrete solutions or protocol specifications
overlap_note: Unique focus on DNS for agent networks, no direct overlap with existing work
momentum_note: Addresses important infrastructure need but early stage with limited community traction
relevance_note: Very relevant for agent discovery and naming in large-scale AI systems
categories: ["Agent discovery/reg", "Autonomous netops"]
rated_at: 2026-02-27T23:19:43.415801+00:00
summary:
Analyzes DNS challenges for Internet of Agents scenarios and identifies technical requirements. Explores how DNS must evolve to support agent collaboration in AI-driven environments.


draft_name: draft-ietf-httpbis-rfc6265bis
novelty_note: Incremental improvement to existing well-established standard
maturity_note: Mature working group draft with extensive detail and broad industry review
overlap_note: Direct update to existing RFC, heavy overlap by design
momentum_note: Strong working group support and clear path to standardization
relevance_note: Foundational web technology but not specifically targeted at AI/agent scenarios
categories: ["Other AI/agent"]
rated_at: 2026-02-27T23:19:43.426040+00:00
summary:
Updates HTTP Cookie specification to replace RFC 6265 with improved security and privacy. Addresses historical flaws while maintaining backward compatibility for widely-used web functionality.


draft_name: draft-meta-layer-overview
novelty_note: Highly novel architectural concept for web-scale coordination and governance
maturity_note: Very early conceptual stage, lacks concrete protocols or implementation details
overlap_note: Unique architectural vision with no direct parallels in existing work
momentum_note: Ambitious concept but needs significant development and community building
relevance_note: Relevant for agent coordination and governance but very early stage
categories: ["Policy/governance", "Human-agent interaction", "A2A protocols"]
rated_at: 2026-02-27T23:19:43.440747+00:00
summary:
Introduces Meta-layer concept as coordination substrate for presence, annotation, and governance on the web. Enables communities and agents to collaborate in shared digital spaces above content layers.


draft_name: draft-mozleywilliams-dnsop-bandaid
maturity_note: Well-structured with clear DNS integration but limited implementation details and security analysis
momentum_note: Addresses clear need for agent discovery but uncertain industry adoption of DNS-based approach
relevance_note: Highly relevant for scalable AI agent ecosystems, leverages proven DNS infrastructure
categories: ["Agent discovery/reg", "A2A protocols", "Agent identity/auth"]
rated_at: 2026-02-27T23:20:01.832762+00:00
summary:
Proposes using DNS with SVCB records to enable AI agent discovery and capability advertisement. Leverages existing DNS infrastructure including DNSSEC and DANE for secure agent-to-agent discovery.

novelty_note:
Novel application of DNS service discovery specifically for AI agents with structured metadata exchange

overlap_note:
Complementary to other AI agent protocols, focuses specifically on discovery rather than communication


draft_name: draft-rosenberg-aiproto
novelty_note: Standardizes common pattern of AI tool integration but builds on existing OpenAI specifications
maturity_note: Comprehensive specification with clear API definitions and enterprise focus
overlap_note: Identical to draft-rosenberg-aiproto-nact - appears to be duplicate submission
momentum_note: Strong enterprise use case and addresses major AI integration pain point
relevance_note: Extremely relevant for current AI agent development and enterprise adoption
categories: ["A2A protocols", "Data formats/interop", "Agent discovery/reg"]
rated_at: 2026-02-27T23:20:01.847376+00:00
summary:
Defines N-ACT protocol for AI agents to discover and invoke third-party tools and APIs. Focuses on enterprise agents with enumeration and invocation capabilities.


draft_name: draft-rosenberg-aiproto-framework
novelty_note: Primarily synthesizes existing work rather than proposing new technical solutions
maturity_note: Well-researched framework document with comprehensive use cases and requirements analysis
overlap_note: Overlaps with general AI protocol discussions but serves as foundational framework
momentum_note: Critical for establishing IETF direction in AI agent standardization
relevance_note: Essential framework document for the emerging field of AI agent protocols
categories: ["A2A protocols", "Policy/governance", "Data formats/interop"]
rated_at: 2026-02-27T23:20:01.870784+00:00
summary:
Provides framework and requirements for AI agent protocols on the Internet. Surveys existing approaches like MCP and A2A to guide IETF standardization efforts.


draft_name: draft-zeng-mcp-troubleshooting
novelty_note: Novel application of MCP to network management domain with practical automation benefits
maturity_note: Brief document with limited technical depth and implementation guidance
overlap_note: Unique application domain though builds on existing MCP standard
momentum_note: Interesting network management application but narrow scope may limit adoption
relevance_note: Highly relevant for network automation and demonstrates practical AI agent applications
categories: ["Autonomous netops", "Data formats/interop", "Human-agent interaction"]
rated_at: 2026-02-27T23:20:01.892508+00:00
summary:
Applies Model Context Protocol to network management for intent-based troubleshooting. Maps MCP roles to network devices and controllers for automated operations.


draft_name: draft-zm-rtgwg-mcp-troubleshooting
novelty_note: Novel application of MCP to network management with device-to-device collaboration extension
maturity_note: Well-structured but early stage, needs implementation validation
overlap_note: Some overlap with general network automation but MCP approach is distinct
momentum_note: Growing interest in AI-driven network operations but MCP adoption uncertain
relevance_note: Highly relevant as networks become more complex and require intelligent automation
categories: ["Autonomous netops", "Human-agent interaction", "Data formats/interop"]
rated_at: 2026-02-27T23:20:21.694135+00:00
summary:
Proposes using Model Context Protocol (MCP) to enable LLM-based automated network troubleshooting. Maps MCP roles to network management domain with devices as servers and controllers as clients.


draft_name: draft-an-nmrg-i2icf-cits
novelty_note: Combines in-network computing with A2A protocols specifically for transportation systems
maturity_note: Comprehensive framework but requires extensive validation in real C-ITS deployments
overlap_note: Overlaps with general V2X and edge computing work but A2A integration is newer
momentum_note: Strong momentum in autonomous vehicles and smart transportation infrastructure
relevance_note: Very relevant for emerging connected vehicle ecosystems and smart cities
categories: ["A2A protocols", "ML traffic mgmt", "Agent discovery/reg", "Other AI/agent"]
rated_at: 2026-02-27T23:20:21.706933+00:00
summary:
Defines framework for orchestrating In-Network Computing Functions in Cooperative Intelligent Transportation Systems. Incorporates Agent-to-Agent communication for multi-domain V2X scenarios.


draft_name: draft-ietf-mailmaint-pacc
novelty_note: Incremental improvement to existing email configuration approaches
maturity_note: Mature specification with detailed protocol definition and good structure
overlap_note: Significant overlap with existing autoconfiguration mechanisms like Thunderbird's
momentum_note: Limited momentum as email configuration is not a high-priority problem
relevance_note: Low relevance to AI/agent systems, traditional email automation
categories: ["Data formats/interop"]
rated_at: 2026-02-27T23:20:21.723555+00:00
summary:
Specifies automatic configuration mechanism for email, calendar, and contact applications. Service providers publish standardized configuration that user agents retrieve for simplified setup.


draft_name: draft-a2a-moqt-transport
novelty_note: Creative application of media transport protocol for AI agent communication
maturity_note: Early stage specification, lacks implementation details and validation
overlap_note: Identical to draft-nandakumar-a2a-moqt-transport
momentum_note: Growing interest in A2A protocols but MOQT adoption for non-media unclear
relevance_note: Highly relevant for real-time agent communication infrastructure
categories: ["A2A protocols", "Data formats/interop", "Agent discovery/reg"]
rated_at: 2026-02-27T23:20:21.734340+00:00
summary:
Specifies transport of Agent-to-Agent protocol over Media over QUIC Transport. Leverages MOQT's publish/subscribe model for real-time AI agent communication.


draft_name: draft-nandakumar-a2a-moqt-transport
novelty_note: Same novel approach as duplicate draft
maturity_note: Early stage, identical content suggests coordination issues between authors
overlap_note: Complete duplication of draft-a2a-moqt-transport
momentum_note: Duplicate submission reduces momentum and creates confusion
relevance_note: Same high relevance but undermined by duplication issue
categories: ["A2A protocols", "Data formats/interop", "Agent discovery/reg"]
rated_at: 2026-02-27T23:20:21.744079+00:00
summary:
Identical specification to draft-a2a-moqt-transport for transporting Agent-to-Agent protocol over MOQT. Appears to be duplicate submission with different author.


draft_name: draft-ietf-sml-trust
novelty_note: Incremental security guidance for existing structured email approaches
maturity_note: IETF working group draft with established discussion venue and GitHub repo
overlap_note: Some overlap with general email security but focused on structured data
momentum_note: Active IETF working group with clear development process
relevance_note: Relevant for email systems but limited AI/agent focus
categories: ["Data formats/interop", "AI safety/alignment"]
rated_at: 2026-02-27T23:20:41.868505+00:00
summary:
Provides trust and security recommendations for handling structured data in email messages. Addresses security considerations for message user agents processing structured email content.


draft_name: draft-zhang-rvp-problem-statement
novelty_note: Novel approach to physical-digital agent coordination with composite identity
maturity_note: Problem statement stage, lacks implementation details and deployment experience
overlap_note: Some overlap with IoT and agent protocols but unique physical-digital focus
momentum_note: Individual submission without clear standardization momentum
relevance_note: Highly relevant for embodied AI and physical-digital agent coordination
categories: ["A2A protocols", "Agent identity/auth", "Autonomous netops"]
rated_at: 2026-02-27T23:20:41.879971+00:00
summary:
Proposes Real-Virtual Agent Protocol for coordinating physical entities with digital agents through unified identity management. Targets manufacturing, smart cities, and human-AI collaborative environments.


draft_name: draft-mao-rtgwg-apn-framework-for-ioa
novelty_note: Applies existing APN framework to new IoA use case
maturity_note: Framework-level document with some technical detail but limited implementation
overlap_note: Heavy overlap with existing APN work, incremental IoA application
momentum_note: Routing working group context provides some momentum
relevance_note: Relevant for agent network performance and quality of service
categories: ["ML traffic mgmt", "A2A protocols", "Agent discovery/reg"]
rated_at: 2026-02-27T23:20:41.889955+00:00
summary:
Applies Application-aware Performance Network framework to Internet of Agents scenario. Addresses network service requirements for AI agent interactions across different platforms.


draft_name: draft-zeng-opsawg-llm-netconf-gap
novelty_note: First systematic analysis of protocol gaps for LLM-driven network operations
maturity_note: Good analysis depth but early stage without concrete solutions
overlap_note: Unique focus on LLM-network protocol integration gaps
momentum_note: Operations working group submission with clear problem focus
relevance_note: Highly relevant for AI-driven network management evolution
categories: ["Autonomous netops", "A2A protocols", "Data formats/interop"]
rated_at: 2026-02-27T23:20:41.902044+00:00
summary:
Analyzes gaps in existing network configuration protocols for LLM-driven intent-based networking. Identifies extension points for NETCONF, RESTCONF, gNMI, MCP, and A2A protocols.


draft_name: draft-zeng-opsawg-applicability-mcp-a2a
novelty_note: Practical applicability analysis but builds on existing protocol concepts
maturity_note: Detailed implementation guidance with coexistence models shows maturity
overlap_note: Some overlap with existing NETCONF extensions but unique multi-protocol approach
momentum_note: Operations working group context with practical implementation focus
relevance_note: Relevant for advanced network management and agent integration
categories: ["Autonomous netops", "A2A protocols", "Data formats/interop"]
rated_at: 2026-02-27T23:20:41.916802+00:00
summary:
Analyzes NETCONF limitations for advanced scenarios and proposes MCP and A2A protocols as complementary solutions. Provides implementation guidance and coexistence models.


draft_name: draft-liu-saag-zt-problem-statement
novelty_note: Zero trust concepts well-established, but interoperability focus has merit
maturity_note: Problem statement stage with numerous typos and formatting issues
overlap_note: Overlaps with existing zero trust and network security work
momentum_note: Early draft with basic problem identification, unclear community support
relevance_note: Zero trust relevant to AI agents but not AI-specific focus
categories: ["Policy/governance", "Agent identity/auth"]
rated_at: 2026-02-27T23:21:00.812423+00:00
summary:
Identifies the need for standardized zero trust interoperability protocols in IETF. Proposes framework for multi-vendor zero trust environments moving beyond existing architectural guidance.


draft_name: draft-akhavain-moussa-ai-network
novelty_note: Novel unified architecture specifically designed for AI network requirements
maturity_note: Detailed 37-page specification but very early draft stage
overlap_note: Limited overlap with existing networking protocols, AI-focused approach
momentum_note: Substantial technical content suggests serious effort, needs community validation
relevance_note: Directly addresses core AI networking infrastructure needs
categories: ["A2A protocols", "ML traffic mgmt", "Model serving/inference", "Data formats/interop"]
rated_at: 2026-02-27T23:21:00.823717+00:00
summary:
Proposes Data and Agent Aware-Inference and Training Network (DA-ITN) architecture. Comprehensive multi-plane network design for AI training, inference, and agent interactions.


draft_name: draft-aylward-aiga-1
novelty_note: Comprehensive governance protocol specifically for autonomous AI agents
maturity_note: Well-structured protocol specification with detailed mechanisms
overlap_note: Novel AI governance approach, limited overlap with existing protocols
momentum_note: Detailed technical specification suggests strong development momentum
relevance_note: Critical for AI agent deployment in networked environments
categories: ["Policy/governance", "AI safety/alignment", "Agent identity/auth"]
rated_at: 2026-02-27T23:21:00.836976+00:00
summary:
Specifies AI Governance and Accountability Protocol with tiered risk-based governance model. Includes immutable kernel architecture and federated authority network for AI agent oversight.


draft_name: draft-li-semantic-routing-architecture
novelty_note: Novel semantic-driven routing paradigm for AI agent networks
maturity_note: Clear architecture description but implementation details needed
overlap_note: Distinct from traditional routing protocols, AI agent specific
momentum_note: Solid technical foundation, needs broader community engagement
relevance_note: Addresses key challenge of intelligent agent communication routing
categories: ["A2A protocols", "Autonomous netops", "Agent discovery/reg"]
rated_at: 2026-02-27T23:21:00.849182+00:00
summary:
Introduces semantic routing architecture using intent vectors and trust scores for AI agent communication. Moves beyond traditional IP routing to application-layer semantic decisions.


draft_name: draft-wendt-stir-vesper
novelty_note: Evolution of existing STIR work with verifiable transparency elements
maturity_note: Mature technical specification building on established protocols
overlap_note: Heavy overlap with existing STIR/SHAKEN and certificate transparency work
momentum_note: Strong technical detail and builds on author's established work
relevance_note: Telephony-focused, limited relevance to AI agent networking
categories: ["Agent identity/auth", "Data formats/interop"]
rated_at: 2026-02-27T23:21:00.861772+00:00
summary:
Formalizes framework for verifiable telephone number identity using delegate certificates and authority tokens. Extends existing STIR/SHAKEN work with transparency mechanisms and rich call data support.


draft_name: draft-jurkovikj-collab-tunnel
maturity_note: Early stage with limited implementation details and unclear real-world validation
overlap_note: Some overlap with web caching and content delivery protocols but unique agent-focused approach
momentum_note: Single author draft with no clear industry backing or implementation momentum
categories: ["Data formats/interop", "Human-agent interaction"]
rated_at: 2026-02-27T23:21:22.734461+00:00
summary:
Defines an HTTP-based protocol for efficient delivery of web content to automated agents using bidirectional URL discovery and content fingerprinting. Focuses on bandwidth reduction while preserving canonical URLs through conditional requests and ETags.

novelty_note:
Novel combination of bidirectional discovery and template-invariant fingerprinting, but builds on established HTTP caching concepts

relevance_note:
Addresses legitimate need for efficient agent-web interaction but limited scope compared to broader AI agent challenges


draft_name: draft-meyerzuselha-oauth-web-message-response-mode
novelty_note: Incremental extension to existing OAuth 2.0 framework using well-established postMessage patterns
maturity_note: Well-defined specification building on mature OAuth 2.0 foundation with clear implementation path
overlap_note: Significant overlap with existing OAuth 2.0 response modes and browser-based authentication flows
momentum_note: Addresses practical OAuth implementation need but limited to specific use case
relevance_note: Relevant to AI agents requiring web-based authentication but not AI-specific innovation
categories: ["Agent identity/auth", "Human-agent interaction"]
rated_at: 2026-02-27T23:21:22.760147+00:00
summary:
Extends OAuth 2.0 with a web message response mode using postMessage API for popup and iframe-based authorization flows. Targets browser-based applications needing secondary window authorization.


draft_name: draft-rosenberg-aiproto-a2t
novelty_note: Novel standardization of AI agent-tool integration with focus on enterprise API consumption
maturity_note: Solid conceptual foundation but needs more implementation details and real-world validation
overlap_note: Some conceptual overlap with API gateway patterns but unique AI agent focus
momentum_note: Addresses clear enterprise need with potential for industry adoption
relevance_note: Highly relevant to AI agent ecosystem development and enterprise integration challenges
categories: ["A2A protocols", "Data formats/interop", "Agent discovery/reg"]
rated_at: 2026-02-27T23:21:22.770944+00:00
summary:
Defines Agent-to-Tool (A2T) protocol for integrating third-party APIs into AI agent operations. Provides enumeration and invocation APIs to reduce integration complexity for enterprise AI agents.


draft_name: draft-mvieuille-kerpass-ephemsec
novelty_note: Innovative approach to OTP generation with public key cryptography and context binding features
maturity_note: Detailed algorithm specification but needs broader security analysis and implementation testing
overlap_note: Overlaps with existing OTP algorithms but introduces novel public key approach
momentum_note: Single author with limited industry validation or adoption signals
relevance_note: Relevant to AI agent authentication but not specifically designed for agent use cases
categories: ["Agent identity/auth", "AI safety/alignment"]
rated_at: 2026-02-27T23:21:22.782905+00:00
summary:
Specifies EPHEMSEC algorithm for generating one-time passwords using public key cryptography instead of shared secrets. Includes context binding for phishing resistance and built-in time synchronization.


draft_name: draft-narajala-ans
novelty_note: Comprehensive novel architecture addressing fundamental AI agent discovery and trust challenges
overlap_note: Some overlap with DNS and PKI concepts but unique application to AI agent ecosystem
categories: ["Agent discovery/reg", "Agent identity/auth", "A2A protocols", "Data formats/interop"]
rated_at: 2026-02-27T23:21:22.793091+00:00
summary:
Introduces Agent Name Service (ANS) as a DNS-based universal directory for AI agent discovery and verification. Uses PKI certificates for agent identity and supports multiple communication protocols through adapter layers.

maturity_note:
Well-structured specification but complex system requiring significant implementation and deployment effort

momentum_note:
Addresses critical infrastructure need with potential for broad adoption if implementation challenges are overcome

relevance_note:
Extremely relevant as foundational infrastructure for multi-agent systems and AI agent interoperability


draft_name: draft-ietf-httpbis-layered-cookies
novelty_note: Incremental improvement to existing standard rather than new functionality
maturity_note: IETF working group draft with 46 pages of detailed specification
overlap_note: Direct replacement/update of existing RFC 6265
momentum_note: Active IETF working group with clear standardization path
relevance_note: Traditional web technology, limited relevance to AI/agent systems
categories: ["Other AI/agent"]
rated_at: 2026-02-27T23:21:40.643393+00:00
summary:
Updates HTTP cookie specification replacing RFC 6265. Maintains existing widely-deployed cookie functionality while addressing historical security and privacy issues.


draft_name: draft-ainp-protocol
novelty_note: Novel semantic routing and intent exchange paradigm for AI agents
maturity_note: Early version 0.1 specification with only 17 pages of detail
overlap_note: Unique approach to AI agent communication protocols
momentum_note: Individual submission without clear working group adoption
relevance_note: Directly addresses core AI agent networking and communication needs
categories: ["A2A protocols", "Agent discovery/reg"]
rated_at: 2026-02-27T23:21:40.654220+00:00
summary:
Defines semantic communication protocol for AI agents using intent-based routing and negotiation. Replaces location-based networking with capability-based agent discovery.


draft_name: draft-gaikwad-south-authorization
novelty_note: Stochastic authorization decisions are novel for network protocols
maturity_note: Well-developed 44-page specification with HTTP binding
overlap_note: Extends existing auth patterns but adds unique probabilistic element
momentum_note: Individual submission, unclear adoption trajectory
relevance_note: Addresses agent authorization needs with uncertainty handling
categories: ["Agent identity/auth", "Policy/governance"]
rated_at: 2026-02-27T23:21:40.663356+00:00
summary:
Authorization protocol supporting probabilistic decisions for agents and services. Enables uncertainty and contextual factors in access control decisions.


draft_name: draft-gaikwad-aps-profile
novelty_note: First standardization attempt for AI agent-specific storage requirements
maturity_note: Detailed experimental specification with Kubernetes integration
overlap_note: Novel focus on agent-specific storage class requirements
momentum_note: Individual experimental draft seeking feedback
relevance_note: Addresses critical infrastructure needs for persistent AI agents
categories: ["Data formats/interop", "Policy/governance"]
rated_at: 2026-02-27T23:21:40.675147+00:00
summary:
Storage service profile for agent persistent state including embeddings, preferences, and audit logs. Addresses compliance and performance needs for AI agent storage.


draft_name: draft-williams-http-bearer-extension
novelty_note: Incremental improvement to existing Bearer auth with automation
maturity_note: Focused 16-page specification with clear HTTP integration
overlap_note: Extends existing Bearer auth and OIDC patterns
momentum_note: Individual submission without clear working group support
relevance_note: Relevant for agent authentication but primarily traditional web auth
categories: ["Agent identity/auth"]
rated_at: 2026-02-27T23:21:40.684777+00:00
summary:
Improves HTTP Bearer authentication with automatic token fetching from STS. Eliminates need for PKCE and simplifies user-agent token management.


draft_name: draft-schulze-ecap
maturity_note: Basic protocol structure defined but likely needs more detail on implementation and edge cases
momentum_note: High relevance to current AI scraping debates and web consent issues
categories: ["Policy/governance", "Agent identity/auth", "AI safety/alignment"]
rated_at: 2026-02-27T23:22:01.636691+00:00
summary:
ECAP defines a cryptographically-verified protocol for web crawlers to obtain consent from hosts before accessing resources. It replaces voluntary robots.txt with mandatory consent-based access using signatures and policy handshakes.

novelty_note:
Novel approach to making web crawling consent mandatory rather than voluntary, using crypto verification

overlap_note:
Some conceptual overlap with robots.txt but fundamentally different approach with crypto verification

relevance_note:
Extremely relevant to current controversies around AI training data collection and web scraping ethics


draft_name: draft-li-dmsc-mcps-agw
novelty_note: Gateway-based architecture for agent collaboration is a solid architectural approach
maturity_note: Good architectural foundation but likely needs more protocol detail for full implementation
overlap_note: Significant overlap with other agent collaboration drafts, particularly draft-liu-dmsc-acps-arc
momentum_note: Part of emerging multi-agent collaboration standardization efforts
relevance_note: Highly relevant as multi-agent systems become more prevalent in distributed computing
categories: ["A2A protocols", "Agent discovery/reg", "Agent identity/auth"]
rated_at: 2026-02-27T23:22:01.647356+00:00
summary:
Defines a protocol suite using Agent Gateways as control-plane entities for multi-agent collaboration. Enables agent registration, authentication, capability management and semantic routing while preserving P2P interactions.


draft_name: draft-romanchuk-normative-admissibility
novelty_note: Highly novel approach to agent communication validation using speech act theory and formal logic
maturity_note: Theoretical framework is well-developed but practical implementation details are unclear
overlap_note: Unique approach not seen in other agent protocol drafts
momentum_note: Specialized academic approach may have limited industry adoption momentum
relevance_note: Relevant for agent safety and verification but may be too theoretical for immediate practical use
categories: ["AI safety/alignment", "A2A protocols", "Policy/governance"]
rated_at: 2026-02-27T23:22:01.657576+00:00
summary:
Establishes a framework for evaluating whether autonomous agent speech acts are admissible based on modality and grounding state. Focuses on deterministic evaluation without requiring semantic truth verification.


draft_name: draft-hackett-ures
novelty_note: Addresses known email rendering problems but approach is incremental rather than novel
maturity_note: Well-developed specification with clear requirements and backwards compatibility considerations
overlap_note: Some overlap with existing email standards but addresses specific rendering gaps
momentum_note: Addresses real industry pain points which could drive adoption
relevance_note: Not directly AI/agent related, more focused on traditional email client interoperability
categories: ["Data formats/interop", "Other AI/agent"]
rated_at: 2026-02-27T23:22:01.668533+00:00
summary:
Specifies requirements for uniform HTML email rendering across mail clients, addressing inconsistencies in HTML/CSS interpretation. Covers dark mode, embedded assets, positioning, and secure SVG rendering while maintaining MIME compatibility.


draft_name: draft-liu-dmsc-acps-arc
maturity_note: Good architectural overview but needs more detailed protocol specifications
overlap_note: Heavy overlap with draft-li-dmsc-mcps-agw and similar multi-agent collaboration efforts
momentum_note: Strong momentum as part of broader Internet of Agents standardization push
relevance_note: Highly relevant for future large-scale agent deployments and IoA infrastructure
categories: ["A2A protocols", "Agent discovery/reg", "Agent identity/auth", "Autonomous netops"]
rated_at: 2026-02-27T23:22:01.678775+00:00
summary:
Proposes Agent Collaboration Protocols architecture for Internet of Agents, covering agent lifecycle from access to collaboration. Includes trusted registration, authentication, discovery, interaction, and monitoring components.

novelty_note:
Comprehensive agent collaboration architecture but builds on established distributed systems concepts


draft_name: draft-vandoulas-aidp
maturity_note: Well-structured but lacks implementation details and security analysis depth
overlap_note: Some overlap with general agent communication but unique delegation focus
momentum_note: Addresses clear industry need but no implementation indicators mentioned
relevance_note: Highly relevant as foundational infrastructure for enterprise agent deployments
categories: ["A2A protocols", "Agent identity/auth", "Policy/governance"]
rated_at: 2026-02-27T23:22:22.119363+00:00
summary:
Defines a comprehensive control-plane protocol for secure agent interactions with delegation, authority enforcement, and cross-domain interoperability. Addresses core infrastructure needs for multi-agent systems with auditable execution binding.

novelty_note:
Novel integration of intent expression, capability delegation, and execution result binding in single protocol


draft_name: draft-mallick-muacp
novelty_note: First protocol addressing resource constraints with specific bounds for agent communication
maturity_note: Detailed technical specifications with clear resource bounds and security binding
overlap_note: Unique focus on resource-constrained environments distinguishes from general protocols
momentum_note: Strong technical foundation and clear market need for IoT agent communication
relevance_note: Critical for IoT/Edge AI deployment which is rapidly expanding market segment
categories: ["A2A protocols", "Data formats/interop"]
rated_at: 2026-02-27T23:22:22.135337+00:00
summary:
Resource-efficient messaging protocol specifically designed for constrained IoT/Edge devices with deterministic bounds. Provides concrete technical specifications with OSCORE security integration.


draft_name: draft-gaikwad-llm-benchmarking-terminology
novelty_note: Terminology standardization is incremental but necessary foundational work
maturity_note: Comprehensive terminology coverage but limited technical depth as terminology-only document
overlap_note: Some overlap with general performance measurement standards but LLM-specific
momentum_note: Industry need exists but terminology docs typically have lower adoption momentum
relevance_note: Useful for industry standardization but indirect impact on technical deployment
categories: ["Model serving/inference", "Data formats/interop"]
rated_at: 2026-02-27T23:22:22.146868+00:00
summary:
Establishes standardized terminology for LLM serving performance metrics across different system types. Focuses purely on vocabulary definition without prescribing methodologies.


draft_name: draft-wolfe-faf-format
novelty_note: Specific application to AI development tools is novel though format approach is conventional
maturity_note: Brief specification lacks detailed schema and implementation guidance
overlap_note: Similar to existing project metadata formats but AI-specific features
momentum_note: IANA registration shows some traction but limited technical depth may hinder adoption
relevance_note: Relevant to developer tooling but narrow use case limits broader impact
categories: ["Data formats/interop", "Human-agent interaction"]
rated_at: 2026-02-27T23:22:22.157051+00:00
summary:
YAML-based format for sharing software project context with AI development tools. Addresses context fragmentation in multi-agent development environments.


draft_name: draft-aylward-aiga-2
novelty_note: Highly novel integration of technical enforcement, economic incentives, and federated governance
maturity_note: Ambitious scope with detailed mechanisms but implementation complexity may be challenging
overlap_note: Unique comprehensive approach to AI governance with technical enforcement
momentum_note: Addresses critical regulatory and safety concerns with strong technical foundation
relevance_note: Extremely relevant given increasing focus on AI safety and regulatory compliance
categories: ["AI safety/alignment", "Policy/governance", "Agent identity/auth"]
rated_at: 2026-02-27T23:22:22.178702+00:00
summary:
Comprehensive AI governance framework with tiered risk model, federated authority network, and economic incentive alignment. Includes advanced security mechanisms for high-assurance scenarios.


draft_name: draft-yang-dmsc-ioa-task-protocol
novelty_note: Reasonable novelty in agent task coordination, but builds on known distributed systems concepts
overlap_note: Significant overlap with other IoA drafts in this set, particularly the semantic interaction draft
momentum_note: Part of emerging IoA standardization effort but unclear industry backing
relevance_note: Highly relevant to growing AI agent ecosystem and multi-agent systems deployment
categories: ["A2A protocols", "Agent discovery/reg", "Autonomous netops"]
rated_at: 2026-02-27T23:22:42.890098+00:00
summary:
Defines a protocol for distributed collaboration among heterogeneous AI agents, enabling dynamic team formation and task coordination. Targets large-scale scenarios like intelligent transportation and smart healthcare across diverse network environments.

maturity_note:
Early stage with basic protocol definition, lacks implementation details and security considerations


draft_name: draft-zhul-dhc-bnc-up-specific-suboption
novelty_note: Incremental extension to existing DHCP relay mechanisms for specific broadband use case
maturity_note: Well-defined technical specification with clear implementation guidance
overlap_note: Unique DHCP extension, no significant overlap with other drafts
momentum_note: Narrow telecom-specific use case with limited broader appeal
relevance_note: Relevant to broadband operators but limited connection to AI/agent themes
categories: ["Other AI/agent"]
rated_at: 2026-02-27T23:22:42.903989+00:00
summary:
Defines a DHCP relay agent suboption for broadband networks to include UP-specific information. Ensures subscribers in the same SGRP under the same UP get IP addresses from the same address space.


draft_name: draft-aap-oauth-profile
novelty_note: Novel application of OAuth to AI agents with thoughtful extensions for autonomous systems
maturity_note: Comprehensive 83-page specification with detailed technical mechanisms
overlap_note: Some conceptual overlap with agent identity themes but distinct OAuth focus
momentum_note: Strong relevance to enterprise AI deployment and security concerns
relevance_note: Extremely relevant to current AI agent security and authorization challenges
categories: ["Agent identity/auth", "AI safety/alignment", "Policy/governance"]
rated_at: 2026-02-27T23:22:42.916242+00:00
summary:
Defines an OAuth 2.0 authorization profile specifically for autonomous AI agents, extending existing standards with structured claims for agent identity and context. Enables context-aware, auditable authorization in agent-to-API scenarios.


draft_name: draft-zhang-dmsc-ioa-semantic-interaction
novelty_note: Applies semantic web technologies to agent interaction, moderately novel combination
maturity_note: Reasonable technical depth but semantic alignment challenges remain complex
overlap_note: Heavy overlap with IoA task protocol draft, both targeting agent interoperability
momentum_note: Part of broader IoA effort but semantic web adoption in agents unclear
relevance_note: Important for agent interoperability but semantic standardization faces adoption challenges
categories: ["A2A protocols", "Data formats/interop", "Agent discovery/reg"]
rated_at: 2026-02-27T23:22:42.930733+00:00
summary:
Specifies a semantic layer for Internet of Agents using ontology models and JSON-LD serialization. Defines common vocabulary and negotiation procedures for deterministic semantic interoperability across agent domains.


draft_name: draft-sun-zhang-iaip
novelty_note: Intent-based approach to agent interconnection shows reasonable novelty
maturity_note: Decent technical specification though gateway architecture needs more detail
overlap_note: Substantial overlap with other IoA drafts, particularly in agent discovery and registration
momentum_note: Part of emerging agent infrastructure standards but adoption path unclear
relevance_note: Relevant to agent infrastructure but intent-based networking adoption still emerging
categories: ["A2A protocols", "Agent discovery/reg", "Autonomous netops"]
rated_at: 2026-02-27T23:22:42.939806+00:00
summary:
Defines Intent-based Agent Interconnection Protocol for Agent Gateways, focusing on semantic intent rather than network addressing. Specifies agent registration, capability advertisement, and intent-based routing mechanisms.


draft_name: draft-verma-dmsc-nlip-notes
novelty_note: Natural language for agent communication is novel but conceptually straightforward
maturity_note: Very early stage with limited technical detail and no concrete protocol specification
overlap_note: Some overlap with other agent communication drafts but unique NL approach
momentum_note: Single author, short document suggests limited community engagement
relevance_note: Addresses real interoperability problems but approach may be premature
categories: ["A2A protocols", "Human-agent interaction", "Data formats/interop"]
rated_at: 2026-02-27T23:23:02.973662+00:00
summary:
Proposes using generative AI to create flexible communication protocols for agent-to-agent interactions, replacing strict APIs with natural language-based communication. Aims to solve API explosion and interoperability challenges through a uniform AI-mediated interface.


draft_name: draft-zhul-intarea-bnc-up-specific-suboption
novelty_note: Standard DHCP extension with conventional approach
maturity_note: Well-defined technical specification with clear implementation path
overlap_note: Specific to broadband DHCP scenarios, minimal overlap
momentum_note: Addresses specific industry need but narrow scope
relevance_note: Limited to broadband network scenarios, not broadly applicable to AI/agents
categories: ["Other AI/agent"]
rated_at: 2026-02-27T23:23:02.985897+00:00
summary:
Defines a DHCP relay agent suboption for broadband networks to include UP-specific information. Ensures subscribers in the same SGRP under the same UP get IP addresses from consistent address spaces.


draft_name: draft-berlinai-vera
novelty_note: Comprehensive zero-trust approach to AI agent security is quite novel
maturity_note: Good architectural framework but needs more implementation details
overlap_note: Some conceptual overlap with agent identity/auth but unique approach
momentum_note: Addresses critical security concerns with structured approach
relevance_note: Highly relevant to AI agent deployment security concerns
categories: ["AI safety/alignment", "Agent identity/auth", "Policy/governance"]
rated_at: 2026-02-27T23:23:02.995484+00:00
summary:
Introduces VERA, a zero-trust architecture for AI agent security with five enforcement pillars and cryptographic proof-based autonomy. Provides structured threat model and security properties for runtime agent verification.


draft_name: draft-li-dmsc-macp
novelty_note: Comprehensive protocol suite with gateway architecture is well-conceived
maturity_note: Substantial 21-page specification with detailed protocol design
overlap_note: Overlaps with other agent communication protocols but more comprehensive
momentum_note: Large document suggests significant development effort and potential industry interest
relevance_note: Addresses core multi-agent collaboration needs with practical approach
categories: ["A2A protocols", "Agent discovery/reg", "Agent identity/auth", "Data formats/interop"]
rated_at: 2026-02-27T23:23:03.005081+00:00
summary:
Specifies a comprehensive multi-agent collaboration protocol suite using Agent Gateways for registration, authentication, and capability management. Enables scalable semantic interactions among distributed agents across heterogeneous networks.


draft_name: draft-zeng-nmrg-mcp-usecases-requirements
novelty_note: Applying MCP to network management is a reasonable extension
maturity_note: Good requirements document but needs follow-up protocol work
overlap_note: Some overlap with network automation but MCP focus is distinctive
momentum_note: NMRG venue and structured approach suggests research community interest
relevance_note: Very relevant to AI-driven network operations trend
categories: ["Autonomous netops", "Human-agent interaction", "Agent discovery/reg"]
rated_at: 2026-02-27T23:23:03.016788+00:00
summary:
Presents problem statement for integrating Model Context Protocol into network management for AI agents. Outlines use cases for troubleshooting, security, and optimization with functional and security requirements.


draft_name: draft-nederveld-adl
novelty_note: Novel standardized approach to agent description with comprehensive metadata coverage
maturity_note: Well-structured spec but lacks implementation examples and ecosystem validation
momentum_note: Strong potential for adoption as foundational agent metadata standard
relevance_note: Critical infrastructure piece for agent ecosystem interoperability and management
categories: ["Data formats/interop", "Agent discovery/reg", "A2A protocols"]
rated_at: 2026-02-27T23:23:24.070491+00:00
summary:
Defines ADL, a JSON-based standard for describing AI agents including their capabilities, tools, permissions, and configuration. Enables agent discovery, interoperability, and lifecycle management across platforms.

overlap_note:
Some overlap with agent identity/discovery concepts but unique in comprehensive agent description approach


draft_name: draft-tejido-swp-core
novelty_note: Novel binary framing approach optimized for agent messaging with strong conformance model
maturity_note: Detailed technical specification with conformance testing and security considerations
overlap_note: Unique binary protocol approach, minimal overlap with other agent communication protocols
momentum_note: Technical merit is high but adoption may be limited by binary format complexity
relevance_note: Addresses real need for efficient agent messaging but may face adoption challenges
categories: ["A2A protocols", "Data formats/interop"]
rated_at: 2026-02-27T23:23:24.085873+00:00
summary:
Specifies SlimWire Protocol Core, a binary framing layer for agent/tool messaging with profile-based extensibility. Provides transport-independent message boundaries and envelope encoding with security bindings.


draft_name: draft-drake-email-tpm-attestation
maturity_note: Comprehensive specification with both full attestation and privacy-preserving variants
overlap_note: Unique approach to hardware-based sender verification, no significant overlap
momentum_note: Addresses critical AI-era challenge of distinguishing human-controlled from automated systems
relevance_note: Extremely relevant for AI era where traditional spam/authentication mechanisms may fail
categories: ["Agent identity/auth", "AI safety/alignment", "Human-agent interaction"]
rated_at: 2026-02-27T23:23:24.103956+00:00
summary:
Defines hardware attestation for email using TPM verification chains to prevent spam and provide Sybil resistance. Includes privacy-preserving SD-JWT alternative and broader applicability to other protocols.

novelty_note:
Highly novel approach connecting hardware attestation to email authentication and AI-resistant spam prevention


draft_name: draft-wang-hjs-accountability
novelty_note: Novel blockchain integration for AI agent accountability with legal framework consideration
maturity_note: Brief specification lacking implementation details and integration examples
overlap_note: Unique blockchain-based accountability approach, no direct overlap with other drafts
momentum_note: Important problem space but may face adoption challenges due to blockchain dependency
relevance_note: Addresses critical need for AI agent accountability and legal traceability
categories: ["Policy/governance", "AI safety/alignment", "A2A protocols"]
rated_at: 2026-02-27T23:23:24.114044+00:00
summary:
Defines HJS accountability layer for AI agents using blockchain-anchored timestamps to create immutable responsibility chains. Provides primitives for judgment, delegation, termination, and verification with court-admissible evidence.


draft_name: draft-ravikiran-clawdentity-protocol
novelty_note: Solid but incremental approach to agent identity using established cryptographic primitives
overlap_note: Moderate overlap with general agent identity concepts but distinct in bilateral trust approach
momentum_note: Strong technical foundation and addresses fundamental need for agent-to-agent trust
relevance_note: Essential infrastructure for secure agent communication and identity verification
categories: ["Agent identity/auth", "A2A protocols", "Data formats/interop"]
rated_at: 2026-02-27T23:23:24.123660+00:00
summary:
Specifies Clawdentity protocol for cryptographic identity and trust in AI agent communication. Provides Ed25519 identity, registry credentials, pairing ceremonies, and authenticated relay transport.

maturity_note:
Comprehensive protocol specification with detailed security considerations and implementation guidance


draft_name: draft-messous-eat-ai
maturity_note: Reasonable technical depth but could benefit from more implementation details and security analysis
overlap_note: Some overlap with general RATS work but AI-specific attestation claims are relatively unique
momentum_note: Addresses emerging need for AI agent trust but limited demonstrated industry adoption
categories: ["Agent identity/auth", "AI safety/alignment", "Policy/governance"]
rated_at: 2026-02-27T23:23:48.653432+00:00
summary:
Defines an Entity Attestation Token profile for remote attestation of autonomous AI agents, specifying claims for model integrity, training data provenance, and inference policies. Extends EAT for AI-specific attestation needs within the IETF RATS architecture.

novelty_note:
Novel application of EAT to AI agent attestation with specific claims for model parameters and training data provenance

relevance_note:
Highly relevant for trustworthy AI deployment and aligns with growing focus on AI safety and verification


draft_name: draft-mpsb-agntcy-messaging
novelty_note: Useful comparative analysis but AGNTCY SLIM appears to be proprietary solution being promoted
maturity_note: More of a survey document than a protocol specification; lacks detailed technical specifications
overlap_note: Overlaps with existing messaging protocol work and MLS standardization efforts
momentum_note: Unclear industry support for AGNTCY SLIM; appears vendor-driven
categories: ["A2A protocols", "Data formats/interop", "Agent identity/auth"]
rated_at: 2026-02-27T23:23:48.666763+00:00
summary:
Analyzes messaging protocols for agentic AI systems, comparing AMQP, MQTT, NATS, Kafka and others across security and performance dimensions. Introduces AGNTCY SLIM as a purpose-built solution with MLS integration for quantum-safe agent communication.

relevance_note:
Addresses real need for agent messaging but focuses heavily on promoting specific proprietary solution


draft_name: draft-mpsb-agntcy-slim
novelty_note: Combines existing technologies (gRPC, MLS) in AI-specific way but limited fundamental innovation
maturity_note: Good technical specification but builds heavily on existing protocols without clear differentiation
overlap_note: Significant overlap with gRPC, HTTP/2-3, and MLS work; incremental addition for AI use case
momentum_note: Appears vendor-driven with limited broader community engagement
relevance_note: Relevant for agent communication but unclear advantage over existing gRPC+MLS combinations
categories: ["A2A protocols", "Data formats/interop", "Agent identity/auth"]
rated_at: 2026-02-27T23:23:48.677773+00:00
summary:
Specifies SLIM protocol for real-time interactive AI applications, combining gRPC over HTTP/2/3 with MLS for secure messaging. Designed as transport layer for agent protocols like A2A and MCP with native RPC semantics.


draft_name: draft-barney-caam
maturity_note: Detailed technical specification with good integration of multiple existing frameworks
momentum_note: References multiple existing frameworks suggesting some industry alignment
categories: ["Agent identity/auth", "Policy/governance", "A2A protocols", "AI safety/alignment"]
rated_at: 2026-02-27T23:23:48.687555+00:00
summary:
Specifies Contextual Agent Authorization Mesh for runtime authorization of agents after discovery, providing ReBAC and purpose-bound delegation. Integrates with ARDP, SPIFFE, and RATS for comprehensive agent authorization framework.

novelty_note:
Comprehensive authorization framework specifically designed for agent interactions with novel contextual authorization approach

overlap_note:
Builds on existing identity and authorization work but creates novel composition for agent scenarios

relevance_note:
Extremely relevant as authorization is critical for safe agent deployment and inter-agent interaction


draft_name: draft-nennemann-wimse-ect
novelty_note: Novel approach to workflow execution tracking with cryptographic linking of task dependencies
maturity_note: Well-specified extension to existing WIMSE work with clear technical details
overlap_note: Extends WIMSE but addresses unique workflow tracking problem not covered elsewhere
momentum_note: Builds on active WIMSE working group with established momentum
relevance_note: Highly relevant for distributed agent workflows and auditability of agent task execution
categories: ["Agent identity/auth", "A2A protocols", "Policy/governance", "Data formats/interop"]
rated_at: 2026-02-27T23:23:48.697752+00:00
summary:
Defines Execution Context Tokens as JWT extension to WIMSE for tracking task execution in distributed agentic workflows. Creates DAG-linked execution records transported via new HTTP header alongside WIMSE identity headers.


draft_name: draft-mw-spice-actor-chain
maturity_note: Well-structured extension to established OAuth 2.0 framework with clear security motivations
momentum_note: High relevance given growing AI agent deployments and security concerns around delegation chains
relevance_note: Directly addresses critical security needs for AI agent authentication and delegation tracking
categories: ["Agent identity/auth", "AI safety/alignment", "A2A protocols"]
rated_at: 2026-02-27T23:24:09.630381+00:00
summary:
Extends OAuth 2.0 Token Exchange with cryptographically verifiable actor chains to provide tamper-evident audit trails of delegation paths. Addresses security gaps in multi-hop service environments, particularly for AI agent-to-agent workloads vulnerable to prompt injection attacks.

novelty_note:
Novel approach to cryptographic delegation auditability in OAuth, specifically addressing AI agent prompt injection vulnerabilities

overlap_note:
Builds on OAuth 2.0 Token Exchange but addresses previously unaddressed delegation auditability gaps


draft_name: draft-bradleylundberg-cfrg-arkg
novelty_note: Novel cryptographic primitive for remote key generation with multiple practical applications
maturity_note: Comprehensive specification with abstract algorithm, concrete instantiations, and formal treatment
overlap_note: Addresses unique cryptographic capability not covered by existing key generation standards
momentum_note: Solid cryptographic foundation with clear applications but may need broader adoption drivers
relevance_note: Strong relevance for agent privacy, forward secrecy, and distributed authentication scenarios
categories: ["Agent identity/auth", "Data formats/interop"]
rated_at: 2026-02-27T23:24:09.644755+00:00
summary:
Defines Asynchronous Remote Key Generation algorithm enabling delegation of public key generation without private key access. Supports pseudonymous keys, enhanced forward secrecy, and paired device authentication scenarios.


draft_name: draft-ietf-roll-enrollment-priority
novelty_note: Incremental enhancement to existing RPL enrollment mechanisms
maturity_note: Mature, focused specification building on established RPL standards
overlap_note: Direct extension of RFC9032 with some overlap in enrollment control mechanisms
momentum_note: Solid but incremental improvement to existing IoT networking capabilities
relevance_note: Relevant for IoT agent enrollment scenarios but limited to RPL network contexts
categories: ["Agent discovery/reg", "Autonomous netops"]
rated_at: 2026-02-27T23:24:09.664095+00:00
summary:
Provides mechanism for RPL Root to control enrollment announcements and adjust enrollment priorities in RPL networks. Extends existing RFC9032 enrollment proxy capabilities with centralized control.


draft_name: draft-contario-totp-secure-enrollment
novelty_note: Practical security improvement to widely-used TOTP enrollment process
maturity_note: Addresses real-world security concerns but builds incrementally on existing TOTP framework
overlap_note: Extends TOTP standard with minimal overlap to existing secure enrollment methods
momentum_note: Moderate interest given widespread TOTP usage but may face adoption challenges
relevance_note: Relevant for agent authentication security but not AI/agent-specific
categories: ["Agent identity/auth", "AI safety/alignment"]
rated_at: 2026-02-27T23:24:09.673780+00:00
summary:
Extends TOTP enrollment to prevent key compromise through QR code capture or key persistence in external systems. Addresses common security vulnerabilities in current TOTP deployment practices.


draft_name: draft-liu-rtgwg-llmsync-multicast
novelty_note: Early exploration of multicast applications for LLM infrastructure
maturity_note: Very early stage with minimal technical detail or concrete proposals
overlap_note: Unique focus on LLM-specific multicast applications
momentum_note: Limited momentum due to lack of technical depth and concrete solutions
relevance_note: Relevant to ML infrastructure but needs substantial development to be actionable
categories: ["ML traffic mgmt", "Model serving/inference"]
rated_at: 2026-02-27T23:24:09.684605+00:00
summary:
Discusses multicast use cases for Large Language Model synchronization in inference cloud services. Very brief draft outlining potential applications for LLM deployment scenarios.


draft_name: draft-zhang-rtgwg-llmmoe-multicast
novelty_note: Novel application of multicast to LLM MoE, but analysis appears preliminary
maturity_note: Very early stage with limited technical depth at 7 pages
overlap_note: Some overlap with ML traffic management concepts but unique multicast focus
momentum_note: Recent draft but narrow scope may limit broader interest
relevance_note: Relevant to networking optimization for LLM inference but very specific use case
categories: ["ML traffic mgmt", "Model serving/inference"]
rated_at: 2026-02-27T23:24:28.277870+00:00
summary:
Analyzes multicast use cases in Large Language Model Mixture of Experts architectures, particularly for token dispatching. Attempts to identify networking opportunities in LLM MoE systems.


draft_name: draft-irtf-nmrg-llm-nm
novelty_note: Good integration of human oversight with LLM automation in network management
maturity_note: Moderate maturity with defined framework components and workflows
overlap_note: Overlaps with autonomous network operations but adds human-in-the-loop aspect
momentum_note: IRTF draft suggests research community interest but moderate momentum
relevance_note: Highly relevant for practical LLM deployment in network operations
categories: ["Autonomous netops", "Human-agent interaction", "Data formats/interop"]
rated_at: 2026-02-27T23:24:28.292310+00:00
summary:
Defines framework for collaborative network management between LLMs and human operators with human-in-the-loop oversight. Introduces telemetry modules and standardized interaction models.


draft_name: draft-liu-nmrg-ai-llm-inference-requirements
novelty_note: Useful requirements analysis but builds on existing inference frameworks
maturity_note: Good survey of existing systems with clear problem identification
overlap_note: Significant overlap with other LLM serving and inference optimization work
momentum_note: Recent and addresses important scaling challenges
relevance_note: Very relevant for understanding LLM deployment requirements at scale
categories: ["Model serving/inference", "ML traffic mgmt"]
rated_at: 2026-02-27T23:24:28.305924+00:00
summary:
Analyzes system and network requirements for large-scale LLM inference services. Investigates mainstream inference frameworks and their network management challenges.


draft_name: draft-gaikwad-llm-benchmarking-methodology
novelty_note: Thorough methodology development for emerging LLM benchmarking needs
maturity_note: Well-developed at 48 pages with detailed procedures and specifications
overlap_note: Part of series but methodology focus is relatively unique
momentum_note: Part of coordinated effort with multiple related drafts
relevance_note: Critical for standardizing LLM performance evaluation across industry
categories: ["Model serving/inference", "Data formats/interop"]
rated_at: 2026-02-27T23:24:28.317706+00:00
summary:
Defines comprehensive benchmarking methodologies for LLM inference serving systems including test procedures and measurement specifications. Companion to terminology document.


draft_name: draft-gaikwad-llm-benchmarking-profiles
novelty_note: Comprehensive profile definition for reproducible LLM benchmarking
maturity_note: Highly mature at 53 pages with detailed architectural specifications
overlap_note: Builds directly on companion methodology and terminology documents
momentum_note: Strong momentum as part of comprehensive benchmarking framework
relevance_note: Essential for standardized, comparable LLM performance evaluation
categories: ["Model serving/inference", "Data formats/interop"]
rated_at: 2026-02-27T23:24:28.341777+00:00
summary:
Defines performance benchmarking profiles binding terminology and methodology to concrete architectural roles and workload patterns. Specifies System Under Test boundaries and measurement points.


draft_name: draft-levy-llm-uri-scheme
novelty_note: URI schemes for AI services are emerging but not well-established in standards
maturity_note: Early draft with basic specification, needs more implementation experience
overlap_note: Some overlap with general service discovery but specific to LLM endpoints
momentum_note: Growing interest in LLM standardization but limited IETF momentum
relevance_note: High relevance for LLM integration and interoperability in network applications
categories: ["Model serving/inference", "Agent discovery/reg", "Data formats/interop"]
rated_at: 2026-02-27T23:24:48.245650+00:00
summary:
Defines a URI scheme for identifying LLM endpoints with embedded configuration parameters. Creates a standardized way to specify model, provider, authentication, and inference parameters in a single connection string.


draft_name: draft-condrey-rats-witnessd-enrollment
novelty_note: Novel approach combining device attestation with process verification
maturity_note: Early specification without widespread implementation or testing
overlap_note: Overlaps with existing device attestation and enrollment protocols
momentum_note: Limited visibility in IETF working groups, niche application area
relevance_note: Relevant for secure agent deployment but specialized use case
categories: ["Agent identity/auth", "Policy/governance", "Autonomous netops"]
rated_at: 2026-02-27T23:24:48.261170+00:00
summary:
Specifies trust anchor bootstrap protocol for proof of process framework. Defines device enrollment, key provisioning, and trust anchor validation across different deployment modes.


draft_name: draft-willman-rtgwg-conduit-tunnels
novelty_note: Combines existing technologies (IPsec, SRv6) in novel orchestration framework
maturity_note: Detailed specification with clear architecture but needs implementation validation
overlap_note: Significant overlap with existing tunnel management and SRv6 specifications
momentum_note: Traditional networking focus with limited AI/agent community engagement
relevance_note: Primarily traditional networking with potential but indirect AI/agent relevance
categories: ["Autonomous netops", "Policy/governance"]
rated_at: 2026-02-27T23:24:48.273088+00:00
summary:
Specifies CONDUIT protocol for managing IPsec tunnel fabrics with automated lifecycle management and SRv6 integration. Focuses on tactical networks with strict cryptographic requirements.


draft_name: draft-gont-dhcwg-dhcpv6-iids
novelty_note: Incremental extension of existing RFC 7217 method to DHCPv6 context
maturity_note: Well-developed specification building on proven RFC 7217 foundation
overlap_note: Directly builds upon RFC 7217 and existing DHCPv6 specifications
momentum_note: Established author with IETF track record, addresses known privacy issue
relevance_note: Traditional networking protocol with minimal direct AI/agent relevance
categories: ["Agent identity/auth", "Data formats/interop"]
rated_at: 2026-02-27T23:24:48.285980+00:00
summary:
Describes method for generating semantically opaque IPv6 interface identifiers in DHCPv6. Adapts RFC 7217 SLAAC method for DHCPv6 server-side address assignment.


draft_name: draft-melnikov-sasl2
novelty_note: Evolutionary update to established protocol with modern auth extensions
maturity_note: Mature specification from experienced author updating well-understood protocol
overlap_note: Updates existing SASL but adds distinct new capabilities
momentum_note: Strong IETF momentum with established author and clear use cases
relevance_note: High relevance for agent authentication and multi-factor security requirements
categories: ["Agent identity/auth", "A2A protocols", "Policy/governance"]
rated_at: 2026-02-27T23:24:48.295935+00:00
summary:
Updates SASL framework to support modern authentication requirements including multi-factor authentication and password change requests. Maintains backward compatibility while extending capabilities.


draft_name: draft-ietf-tls-ecdhe-mlkem
maturity_note: Well-developed 12-page specification from IETF working group, ready for implementation
overlap_note: Unique focus on TLS 1.3 post-quantum hybrids, minimal overlap with other drafts
momentum_note: High momentum - post-quantum cryptography is critical priority with strong industry support
relevance_note: Extremely relevant for future-proofing TLS against quantum computing threats
categories: ["Other AI/agent"]
rated_at: 2026-02-27T23:25:07.189643+00:00
summary:
Defines hybrid post-quantum key agreement mechanisms for TLS 1.3 that combine ML-KEM with traditional ECDHE. Provides quantum-resistant security while maintaining compatibility with existing elliptic curve cryptography.

novelty_note:
Post-quantum hybrid approach is relatively novel, combining established ECDHE with new ML-KEM standard


draft_name: draft-ietf-lake-edhoc-impl-cons
novelty_note: Implementation guidance document, not introducing new protocols but providing practical advice
maturity_note: Comprehensive 43-page implementation guide from established working group
overlap_note: Significant overlap with other EDHOC-related drafts in this set
momentum_note: Moderate momentum as supporting document for EDHOC adoption
relevance_note: Moderately relevant for constrained device implementations and IoT scenarios
categories: ["Agent identity/auth"]
rated_at: 2026-02-27T23:25:07.213756+00:00
summary:
Provides implementation guidance for EDHOC authenticated key exchange protocol. Offers practical considerations for deploying EDHOC in constrained environments.


draft_name: draft-ietf-lake-authz
novelty_note: Novel application of EDHOC for zero-touch onboarding scenarios
maturity_note: Substantial 48-page specification with detailed authorization procedures
overlap_note: Overlaps with other EDHOC drafts but focuses on specific authorization use case
momentum_note: Strong momentum driven by IoT device deployment needs
relevance_note: Highly relevant for automated device provisioning and IoT security
categories: ["Agent identity/auth", "Agent discovery/reg"]
rated_at: 2026-02-27T23:25:07.226428+00:00
summary:
Specifies lightweight authorization using EDHOC for zero-touch device onboarding. Enables secure enrollment of new devices in constrained networks using manufacturer-installed trust anchors.


draft_name: draft-ietf-emu-eap-edhoc
novelty_note: Reasonable novelty in bridging EAP and EDHOC protocols
maturity_note: Well-developed 31-page specification with clear integration approach
overlap_note: Overlaps with EDHOC family but unique in EAP integration
momentum_note: Moderate momentum from enterprise network authentication needs
relevance_note: Relevant for enterprise networks requiring constrained device authentication
categories: ["Agent identity/auth"]
rated_at: 2026-02-27T23:25:07.238038+00:00
summary:
Defines EAP authentication method based on EDHOC for constrained environments. Integrates EDHOC's lightweight security handshake into the standard EAP framework.


draft_name: draft-lenders-core-dnr
novelty_note: Novel problem identification in DNS service discovery for OSCORE environments
maturity_note: Early-stage problem statement document, only 12 pages without solutions
overlap_note: Unique focus on DNS discovery for OSCORE, limited overlap
momentum_note: Lower momentum as problem statement without proposed solutions
relevance_note: Relevant for CoAP and constrained network service discovery
categories: ["Agent discovery/reg", "Data formats/interop"]
rated_at: 2026-02-27T23:25:07.247736+00:00
summary:
Identifies problems in designing DNS SVCB records for OSCORE endpoint discovery. Addresses challenges in discovering CoAP servers and DNS resolvers using OSCORE encryption.


draft_name: draft-ra-emu-pqc-eapaka
novelty_note: Straightforward application of PQ-KEMs to existing protocol
maturity_note: Clear technical approach but early stage specification
overlap_note: Significant overlap with draft-ar-emu-hybrid-pqc-eapaka addressing same protocol
momentum_note: Moderate interest in post-quantum security preparations
relevance_note: High relevance for quantum-resistant authentication protocols
categories: ["Agent identity/auth"]
rated_at: 2026-02-27T23:25:24.405183+00:00
summary:
Enhances EAP-AKA' with post-quantum key encapsulation mechanisms to protect against quantum computer threats. Replaces traditional ECDHE with PQ-KEMs for quantum-safe authentication.


draft_name: draft-bastian-jose-dvs
novelty_note: Novel combination of DH-KA with JOSE for MAC derivation
maturity_note: Brief specification needs more detail and security analysis
overlap_note: Unique approach to JOSE authentication enhancement
momentum_note: Limited momentum, niche application area
relevance_note: Relevant for web security and authentication protocols
categories: ["Agent identity/auth", "Data formats/interop"]
rated_at: 2026-02-27T23:25:24.414722+00:00
summary:
Defines deriving HMAC keys from public key information in JOSE using Diffie-Hellman key agreement. Enables symmetric MAC authentication from public key operations.


draft_name: draft-ietf-ace-coap-est-oscore
novelty_note: Significant adaptation of EST for constrained IoT environments
maturity_note: Well-developed IETF working group draft with comprehensive specification
overlap_note: Some overlap with existing EST and CoAP security work
momentum_note: Strong momentum as official IETF working group item
relevance_note: High relevance for IoT certificate management
categories: ["Agent identity/auth", "Data formats/interop"]
rated_at: 2026-02-27T23:25:24.423443+00:00
summary:
Specifies carrying EST certificate provisioning over CoAP using OSCORE protection instead of DTLS. Builds on EST-coaps but uses OSCORE and EDHOC for constrained environments.


draft_name: draft-ar-emu-hybrid-pqc-eapaka
novelty_note: Hybrid approach offers practical transition strategy
maturity_note: Solid technical foundation but needs implementation validation
overlap_note: Direct overlap with draft-ra-emu-pqc-eapaka on same protocol
momentum_note: Growing interest in hybrid PQC approaches
relevance_note: Highly relevant for quantum-resistant authentication evolution
categories: ["Agent identity/auth"]
rated_at: 2026-02-27T23:25:24.433751+00:00
summary:
Enhances EAP-AKA' with hybrid post-quantum cryptography combining traditional and quantum-resistant algorithms. Provides quantum safety while maintaining backwards compatibility.


draft_name: draft-spm-lake-pqsuites
novelty_note: First comprehensive PQ cipher suite definition for EDHOC
maturity_note: Concise but technically sound specification
overlap_note: Unique focus on EDHOC post-quantum adaptation
momentum_note: Strong momentum due to LAKE working group activity
relevance_note: Critical for post-quantum IoT security infrastructure
categories: ["Agent identity/auth"]
rated_at: 2026-02-27T23:25:24.443518+00:00
summary:
Defines quantum-resistant cipher suites for EDHOC using ML-DSA signatures and ML-KEM key exchange. Specifies post-quantum operation for both signature and PSK authentication methods.


draft_name: draft-pocero-authkem-ikr-edhoc
maturity_note: Early maturity - recent draft with limited field testing of the optimized three-message approach
categories: ["Agent identity/auth"]
rated_at: 2026-02-27T23:25:34.221776+00:00
summary:
This draft proposes a KEM-based authentication variant for EDHOC that optimizes for scenarios where the initiator knows the responder's credentials beforehand, reducing the handshake to three mandatory messages. It aims to provide signature-free post-quantum authentication while maintaining mutual authentication and forward secrecy in constrained environments.

novelty_note:
Moderate novelty - builds incrementally on existing KEM-based EDHOC authentication with optimization for specific IKR scenarios

overlap_note:
Significant overlap with existing EDHOC KEM authentication work, representing an optimization rather than fundamental innovation

momentum_note:
Moderate momentum - post-quantum cryptography adoption is growing but constrained environment deployment remains niche

relevance_note:
High relevance for IoT and constrained networks needing post-quantum security, though limited to specific IKR use cases


draft_name: draft-tiloca-lake-exporter-output-length
novelty_note: Incremental extension to existing EDHOC protocol using established EAD mechanisms
maturity_note: Builds on mature EDHOC foundation but adds new negotiation complexity
overlap_note: Specific to EDHOC exporter interface with limited overlap to other key agreement protocols
momentum_note: Niche enhancement for EDHOC deployments with limited broader appeal
relevance_note: Useful for EDHOC implementations but addresses narrow technical requirement
categories: ["Agent identity/auth"]
rated_at: 2026-02-27T23:25:39.654978+00:00
summary:
This draft defines a mechanism for EDHOC peers to agree in-band on output lengths for the EDHOC_Exporter interface using External Authorization Data items. The approach allows negotiation of key derivation output sizes during the EDHOC handshake process.


draft_name: draft-lake-pocero-authkem-edhoc
overlap_note: Some overlap with general PQC standardization efforts but specific to EDHOC protocol extensions
categories: ["Agent identity/auth"]
rated_at: 2026-02-27T23:25:45.691820+00:00
summary:
This draft extends the EDHOC protocol to provide quantum-resistant authentication using KEM-based mechanisms instead of traditional signatures. It addresses the need for post-quantum cryptography in IoT and constrained device authentication scenarios.

novelty_note:
Moderate novelty in applying KEM-based authentication to EDHOC, building on established PQC concepts

maturity_note:
Early stage draft with basic specification but likely needs implementation experience and security analysis

momentum_note:
High momentum due to urgent industry need for quantum-resistant cryptography in IoT/constrained devices

relevance_note:
Highly relevant as quantum threat becomes more imminent and IoT devices need lightweight PQC solutions


draft_name: draft-ietf-emu-pqc-eapaka
novelty_note: Incremental enhancement of existing protocol with established PQ-KEM techniques
maturity_note: Draft stage with reasonable technical foundation but requires implementation validation
overlap_note: Specific application to EAP-AKA' with limited overlap in similar PQ-KEM integrations
relevance_note: Highly relevant for securing authentication infrastructure against quantum threats
categories: ["Agent identity/auth"]
rated_at: 2026-02-27T23:25:51.323828+00:00
summary:
This draft proposes enhancing EAP-AKA' Forward Secrecy with Post-Quantum Key Encapsulation Mechanisms to protect against future quantum computer threats. It builds on RFC9678 by replacing traditional ECDHE key exchange with quantum-resistant alternatives.

momentum_note:
High momentum due to urgent quantum threat timeline and active IETF post-quantum standardization efforts


draft_name: draft-wang-ppm-ecdh-psi
categories: ["Data formats/interop"]
rated_at: 2026-02-27T23:25:57.976763+00:00
summary:
This draft specifies ECDH-based Private Set Intersection (PSI) for two parties using elliptic curve cryptography and the Meadows protocol. It enables participants to find common records while preserving privacy of non-intersecting elements.

novelty_note:
Applies well-known ECDH techniques to PSI with standard elliptic curves - incremental but solid engineering

maturity_note:
Reasonable technical depth for IETF draft with concrete protocol specification, though some implementation details may need refinement

overlap_note:
PSI is established research area but ECDH-specific variant for IETF standardization has limited direct overlap

momentum_note:
Privacy-preserving computation gaining interest but unclear if this specific approach has strong industry backing

relevance_note:
Privacy-preserving set intersection has legitimate use cases in federated learning and data sharing scenarios


draft_name: draft-ietf-lamps-rfc5274bis
novelty_note: Incremental update to existing CMC compliance requirements
maturity_note: Mature IETF working group draft updating well-established protocols
overlap_note: Specific to CMC compliance, minimal overlap with other drafts
momentum_note: Standard LAMPS working group progression
relevance_note: Important for PKI certificate management compliance
categories: ["Data formats/interop"]
rated_at: 2026-02-27T23:26:14.642078+00:00
summary:
Defines compliance requirements for Certificate Management Messages over CMS (CMC) enrollment protocol. Updates and obsoletes previous RFCs with current compliance statements.


draft_name: draft-ietf-sshm-mlkem-hybrid-kex
novelty_note: Novel hybrid approach combining quantum-resistant and traditional crypto
maturity_note: Well-developed IETF draft addressing critical post-quantum needs
overlap_note: Part of broader post-quantum cryptography efforts but SSH-specific
momentum_note: High momentum due to post-quantum migration urgency
relevance_note: Critical for quantum-resistant SSH implementations
categories: ["Data formats/interop"]
rated_at: 2026-02-27T23:26:14.664822+00:00
summary:
Defines post-quantum hybrid key exchange combining ML-KEM with traditional ECDH for SSH transport layer. Provides quantum resistance while maintaining compatibility.


draft_name: draft-ietf-lake-edhoc-psk
novelty_note: PSK method extension to existing EDHOC protocol
maturity_note: Comprehensive 31-page specification with detailed security considerations
overlap_note: Extends EDHOC but PSK approach is relatively unique
momentum_note: Steady progress in LAKE working group
relevance_note: Important for IoT and constrained device authentication
categories: ["Data formats/interop"]
rated_at: 2026-02-27T23:26:14.674963+00:00
summary:
Specifies pre-shared key authentication method for EDHOC key exchange protocol. Enhances efficiency while providing mutual authentication and quantum resistance.


draft_name: draft-yusef-lamps-rfc7030-renewal-recommendation
novelty_note: Incremental extension addressing practical deployment issue
maturity_note: Concise 7-page draft addressing specific operational need
overlap_note: Specific EST extension with minimal overlap
momentum_note: Individual submission with limited visibility
relevance_note: Useful for automated certificate lifecycle management
categories: ["Data formats/interop"]
rated_at: 2026-02-27T23:26:14.686137+00:00
summary:
Extends EST protocol to provide certificate renewal timing recommendations from CA to end-entity devices. Addresses issues with traditional 50% lifetime renewal approach.


draft_name: draft-ietf-lamps-private-key-stmt-attr
novelty_note: Alternative approach to traditional proof-of-possession mechanisms
maturity_note: Mature 19-page specification with detailed attribute definitions
overlap_note: Unique approach to private key possession verification
momentum_note: Standard LAMPS working group development
relevance_note: Relevant for flexible certificate enrollment scenarios
categories: ["Data formats/interop"]
rated_at: 2026-02-27T23:26:14.695801+00:00
summary:
Defines X.509 attribute for private key possession statements as alternative to cryptographic proof of possession. Enables certificate subjects to provide signed statements for CA verification.


draft_name: draft-bastian-jose-pkdh
overlap_note: Some overlap with existing JOSE specifications but introduces new key derivation mechanism
momentum_note: Limited discussion and adoption visible in broader community
relevance_note: Relevant for JSON-based security applications requiring dynamic key establishment
categories: ["Data formats/interop"]
rated_at: 2026-02-27T23:26:33.652843+00:00
summary:
Defines a method to derive symmetric MAC keys from public information in JSON Web Signatures using Diffie-Hellman key agreement. This enables HMAC-based authentication without requiring pre-shared keys.

novelty_note:
Novel approach combining DH-KA with JWS for MAC key derivation, though builds on established JOSE framework

maturity_note:
Reasonably mature specification with clear technical approach, but needs more implementation experience


draft_name: draft-lake-pocero-authkem-ikr-edhoc
maturity_note: Well-developed technical specification building on established EDHOC framework
overlap_note: Builds heavily on existing EDHOC work but provides distinct optimization
momentum_note: Strong momentum from LAKE working group and post-quantum cryptography interest
relevance_note: Highly relevant for IoT and constrained device security in post-quantum era
categories: ["Agent identity/auth"]
rated_at: 2026-02-27T23:26:33.663014+00:00
summary:
Specifies an optimized KEM-based authentication variant for EDHOC protocol in scenarios where the initiator knows the responder's credentials. Enables post-quantum authentication with only three messages while maintaining mutual authentication and forward secrecy.

novelty_note:
High novelty in optimizing post-quantum authentication for constrained environments with prior knowledge scenarios


draft_name: draft-ietf-lamps-attestation-freshness
novelty_note: Addresses important freshness problem in attestation but uses established nonce-based approach
maturity_note: Mature specification from established working group with comprehensive protocol coverage
momentum_note: Strong momentum from LAMPS working group and growing attestation requirements
relevance_note: Very relevant for trusted computing and device attestation scenarios
categories: ["Agent identity/auth"]
rated_at: 2026-02-27T23:26:33.674647+00:00
summary:
Outlines how nonces are supplied to end entities by RA/CA for inclusion in attestation evidence within Certificate Signing Requests. Covers implementation across CMP, EST, and CMC protocols to demonstrate evidence freshness.

overlap_note:
Some overlap with existing certificate management protocols but adds attestation-specific mechanisms


draft_name: draft-chen-lake-edhoc-aka
novelty_note: Novel combination of AKA and EDHOC but builds on well-established protocols
maturity_note: Early stage specification with limited technical detail and implementation guidance
overlap_note: Significant overlap with existing AKA and EDHOC protocols
momentum_note: Moderate interest from mobile network and satellite communication communities
relevance_note: Highly relevant for satellite and mobile network authentication scenarios
categories: ["Agent identity/auth"]
rated_at: 2026-02-27T23:26:33.685171+00:00
summary:
Defines EDHOC-AKA authentication method combining AKA protocol with EDHOC for mobile network access authentication. Designed for resource-constrained scenarios like Non-Terrestrial Networks using symmetric cryptography.


draft_name: draft-ietf-lake-app-profiles
novelty_note: High novelty in standardizing application profile coordination for lightweight protocols
maturity_note: Very mature and comprehensive specification with detailed technical framework
overlap_note: Unique approach to application profile coordination with minimal overlap
momentum_note: Strong momentum from LAKE working group with broad industry interest
relevance_note: Critical for EDHOC deployment and interoperability across various applications
categories: ["Data formats/interop", "Agent identity/auth"]
rated_at: 2026-02-27T23:26:33.695176+00:00
summary:
Defines canonical CBOR representation for EDHOC application profiles and coordination mechanisms for their use. Establishes standardized way to describe, distribute, and store EDHOC parameters while defining well-known profiles for interoperability.


draft_name: draft-ietf-lake-ra
novelty_note: Moderate novelty in combining attestation with EDHOC, though both concepts exist separately
maturity_note: Well-structured IETF working group draft with clear technical approach
overlap_note: Some overlap with general attestation and EDHOC work but specific combination is relatively unique
momentum_note: IETF working group backing suggests good momentum and implementation interest
relevance_note: High relevance for IoT security and zero-trust architectures requiring device attestation
categories: ["Agent identity/auth", "Policy/governance"]
rated_at: 2026-02-27T23:26:52.572360+00:00
summary:
Specifies remote attestation procedures integrated with EDHOC lightweight key exchange protocol. Enables verification of device/system integrity during authentication based on RATS architecture.


draft_name: draft-ietf-ace-edhoc-oscore-profile
novelty_note: Reasonable novelty in combining existing protocols for constrained environment authorization
maturity_note: Comprehensive 91-page specification from established IETF working group
overlap_note: Moderate overlap with existing ACE, EDHOC, and OSCORE specifications
momentum_note: Strong IETF working group support and addresses real IoT deployment needs
relevance_note: Very relevant for IoT and constrained device security architectures
categories: ["Agent identity/auth", "A2A protocols"]
rated_at: 2026-02-27T23:26:52.585760+00:00
summary:
Defines ACE framework profile using EDHOC for mutual authentication and OSCORE for secure communication. Enables authorization delegation from constrained devices to more capable hosts.


draft_name: draft-josefsson-chempat
novelty_note: High novelty in providing generic combiner construct for PQ/T hybrid KEMs
maturity_note: Individual draft with solid technical content but less institutional backing
overlap_note: Relatively unique approach to hybrid PQ cryptography, low overlap
momentum_note: Individual effort with uncertain implementation momentum
relevance_note: Extremely relevant for quantum-resistant cryptography transition
categories: ["Agent identity/auth", "Data formats/interop"]
rated_at: 2026-02-27T23:26:52.599148+00:00
summary:
Generic framework for Post-Quantum/Traditional hybrid key encapsulation mechanisms. Provides concrete instantiated algorithms combining classical and quantum-resistant cryptographic methods.


draft_name: draft-pocero-authkem-edhoc
novelty_note: High novelty in signature-free post-quantum authentication for EDHOC
maturity_note: Individual draft with detailed technical approach but limited institutional review
overlap_note: Some overlap with EDHOC and PQC work but specific approach is fairly unique
momentum_note: Individual effort with uncertain adoption prospects
relevance_note: Highly relevant for post-quantum cryptography and lightweight authentication
categories: ["Agent identity/auth", "A2A protocols"]
rated_at: 2026-02-27T23:26:52.609033+00:00
summary:
Extends EDHOC with KEM-based authentication for post-quantum resistance. Enables signature-free quantum-resistant authentication using mechanisms like ML-KEM.


draft_name: draft-ietf-hpke-hpke
novelty_note: Moderate novelty as hybrid encryption concept exists but comprehensive standardization adds value
maturity_note: Mature IETF working group standard with extensive development and review
overlap_note: Relatively unique comprehensive approach to hybrid PKE standardization
momentum_note: Strong IETF momentum with wide industry interest and implementation
relevance_note: Extremely relevant as fundamental cryptographic building block for modern protocols
categories: ["Agent identity/auth", "Data formats/interop"]
rated_at: 2026-02-27T23:26:52.619450+00:00
summary:
Comprehensive specification for hybrid public key encryption supporting arbitrary-sized plaintexts. Includes pre-shared key authentication and works with various KEM/KDF/AEAD combinations.


draft_name: draft-ietf-lamps-rfc7030-csrattrs
novelty_note: Incremental improvement to existing EST protocol with template approach being moderately novel
maturity_note: Well-developed specification addressing real implementation issues with clear encoding rules
overlap_note: Specific update to EST protocol with limited overlap to other current drafts
momentum_note: IETF working group draft addressing documented interoperability problems
relevance_note: High relevance for PKI deployments and certificate enrollment infrastructure
categories: ["Data formats/interop", "Policy/governance"]
rated_at: 2026-02-27T23:27:12.838718+00:00
summary:
Updates RFC7030 to clarify CSR Attributes Response encoding and adds template-based approach for EST servers. Resolves implementation challenges and confusion in the existing EST specification.


draft_name: draft-ietf-suit-firmware-encryption
novelty_note: Applies established crypto techniques to SUIT manifest context, moderately novel integration
maturity_note: Comprehensive 55-page specification with detailed technical approaches
overlap_note: Specific to SUIT manifest encryption with minimal overlap to other efforts
momentum_note: Active IETF working group addressing IoT security needs
relevance_note: Important for IoT device security and firmware update protection
categories: ["Data formats/interop"]
rated_at: 2026-02-27T23:27:12.879655+00:00
summary:
Specifies encryption techniques for firmware and software payloads in SUIT manifests. Uses ES-DH and AES-KW for key agreement with symmetric encryption for payload protection.


draft_name: draft-ietf-tls-deprecate-obsolete-kex
novelty_note: Standard security maintenance work deprecating known weak algorithms
maturity_note: Thorough specification updating many RFCs with clear deprecation guidance
overlap_note: Focused TLS 1.2 security update with unique scope
momentum_note: Important security maintenance from established IETF TLS working group
relevance_note: Critical for maintaining TLS security posture across internet infrastructure
categories: ["Policy/governance"]
rated_at: 2026-02-27T23:27:12.890032+00:00
summary:
Deprecates obsolete key exchange methods in TLS 1.2 including finite field DH and RSA. Updates multiple RFCs to change cipher suite recommendations to MUST NOT or SHOULD NOT.


draft_name: draft-ietf-emu-hybrid-pqc-eapaka
novelty_note: Novel application of hybrid post-quantum crypto to cellular authentication protocols
maturity_note: Short specification building on recent EAP-AKA' FS work, early stage development
overlap_note: Specific to EAP-AKA' with some overlap to general PQC standardization efforts
momentum_note: Timely post-quantum crypto adoption in critical mobile authentication
relevance_note: High relevance for future-proofing mobile network security
categories: ["Agent identity/auth"]
rated_at: 2026-02-27T23:27:12.899790+00:00
summary:
Enhances EAP-AKA' with post-quantum cryptography to address quantum computing threats. Uses hybrid PQ/T algorithms to achieve quantum-safe authentication.


draft_name: draft-nsiangani-authenticatedsecuredlayer
novelty_note: Completely novel cryptographic approach abandoning all established primitives
maturity_note: Unproven cryptographic claims without peer review or security analysis
overlap_note: Entirely different approach from any existing security protocols
momentum_note: Individual submission with no working group support or adoption signals
relevance_note: Very low relevance due to unvetted crypto and lack of security foundation
categories: ["Other AI/agent"]
rated_at: 2026-02-27T23:27:12.908989+00:00
summary:
Proposes ASL protocol using novel phi-ns-x arithmetic primitive instead of traditional crypto. Claims security through non-linear modular arithmetic and combinatorial complexity.


draft_name: draft-ietf-lamps-est-renewal-info
novelty_note: Modest extension to existing EST protocol, addresses practical timing optimization
maturity_note: Well-scoped problem with clear solution, builds on established EST standard
overlap_note: Specific EST extension with minimal overlap with other certificate management work
momentum_note: IETF working group draft addressing real deployment needs as cert lifetimes decrease
relevance_note: High relevance for PKI deployments, especially with trend toward shorter certificate lifetimes
categories: ["Data formats/interop"]
rated_at: 2026-02-27T23:27:34.243497+00:00
summary:
Extends EST protocol to provide server-side recommendations for certificate renewal timing. Addresses the issue of overly early renewal attempts as certificate lifetimes shorten.


draft_name: draft-ietf-tls-extended-key-update
maturity_note: Substantial 40-page specification with clear security motivation and detailed mechanism
overlap_note: Extends TLS 1.3 in novel direction, minimal overlap with other key management approaches
momentum_note: IETF working group draft addressing important security gap in long-lived sessions
relevance_note: Critical security improvement for TLS, especially relevant for IoT and industrial applications
categories: ["Data formats/interop"]
rated_at: 2026-02-27T23:27:34.256162+00:00
summary:
Adds post-compromise security to TLS 1.3 through fresh Diffie-Hellman exchanges during active sessions. Particularly valuable for long-lived connections in IoT and telecom environments.

novelty_note:
Significant security enhancement addressing post-compromise scenarios not covered by existing KeyUpdate


draft_name: draft-ietf-anima-constrained-voucher
novelty_note: Significant adaptation of BRSKI for constrained environments with new encoding and transport
maturity_note: Comprehensive 93-page specification with detailed protocol adaptations and implementations
overlap_note: Builds heavily on BRSKI but targets different deployment scenario
momentum_note: IETF working group draft addressing growing IoT security bootstrapping needs
relevance_note: Extremely relevant for IoT deployments requiring secure zero-touch onboarding
categories: ["Agent identity/auth", "Data formats/interop"]
rated_at: 2026-02-27T23:27:34.270049+00:00
summary:
Adapts BRSKI secure device onboarding for constrained IoT environments using CBOR vouchers and CoAP/DTLS. Enables zero-touch bootstrapping in resource-limited and lossy networks.


draft_name: draft-templin-6man-mla
novelty_note: New IPv6 address type for specific ad hoc networking scenarios
maturity_note: Moderate complexity solution with clear problem statement but individual submission
overlap_note: Some overlap with other IPv6 addressing schemes for mobile/ad hoc scenarios
momentum_note: Individual submission without clear working group momentum
relevance_note: Moderate relevance for ad hoc networking scenarios, niche but legitimate use case
categories: ["A2A protocols"]
rated_at: 2026-02-27T23:27:34.314265+00:00
summary:
Introduces Multilink Local Address (MLA) type for autonomous IPv6 addressing in ad hoc networks. Enables topology-independent addressing when traditional delegation services are unavailable.


draft_name: draft-bernardos-cats-isac-uc
maturity_note: Early-stage use case document, limited technical depth in protocol specifics
overlap_note: ISAC concepts exist elsewhere, overlap with general CATS and sensing integration work
momentum_note: Part of emerging CATS discussions but still exploratory phase
relevance_note: High relevance for future autonomous systems requiring integrated sensing and communication
categories: ["Autonomous netops", "ML traffic mgmt"]
rated_at: 2026-02-27T23:27:34.323982+00:00
summary:
Presents Integrated Sensing and Communications (ISAC) as a use case for CATS architecture. Explores joint optimization of sensing and communication functions for autonomous systems and smart cities.

novelty_note:
Applies existing ISAC concepts to CATS framework, use case exploration rather than protocol innovation


draft_name: draft-ahn-opsawg-5g-security-i2nsf-framework
maturity_note: Well-structured framework but lacks implementation details and validation results
momentum_note: 5G security is active area but I2NSF adoption has been moderate
relevance_note: Highly relevant for autonomous 5G security management and policy automation
categories: ["Autonomous netops", "Policy/governance"]
rated_at: 2026-02-27T23:27:55.438095+00:00
summary:
Proposes an integrated security framework for 5G edge networks using I2NSF architecture with Intent-Based Networking. Enables automated translation of high-level security intents into enforceable policies across network and application layers.

novelty_note:
Combines existing I2NSF and IBN concepts for 5G security but integration approach shows some novelty

overlap_note:
Moderate overlap with existing I2NSF and 5G security work, but specific integration is less explored


draft_name: draft-fu-cats-flow-lb
novelty_note: Incremental improvement to CATS with focus on autonomous data plane decisions
maturity_note: Brief document with limited technical depth and no evaluation
overlap_note: Significant overlap with existing CATS and load balancing work
momentum_note: CATS is active area with strong industry interest
relevance_note: Relevant for autonomous traffic management but narrowly focused
categories: ["ML traffic mgmt", "Autonomous netops"]
rated_at: 2026-02-27T23:27:55.449989+00:00
summary:
Specifies flow-level load balancing for Computing-Aware Traffic Steering to reduce control overhead. Enables data plane autonomous flow distribution for better resource utilization.


draft_name: draft-templin-manet-inet
novelty_note: Problem statement format limits novelty, addressing well-known MANET challenges
maturity_note: Early stage problem identification without proposed solutions
overlap_note: High overlap with decades of MANET research and existing problem statements
momentum_note: MANET research has declined in recent years with limited working group activity
relevance_note: Limited relevance to modern AI/agent systems, focuses on traditional mobile networking
categories: ["Other AI/agent"]
rated_at: 2026-02-27T23:27:55.461562+00:00
summary:
Presents problem statement and gap analysis for MANET internetworking with fixed networks. Identifies challenges in connecting autonomous mobile node systems to the global Internet.


draft_name: draft-sogomonian-ai-uri-scheme
novelty_note: Novel approach to AI resource addressing with dual autonomous/human access paradigm
maturity_note: Very brief specification lacking detailed syntax, semantics, and security considerations
overlap_note: Unique approach to AI resource identification, no direct overlaps found
momentum_note: AI infrastructure gaining attention but URI schemes are niche area
relevance_note: Highly relevant for AI agent discovery, registration, and autonomous system connectivity
categories: ["Agent discovery/reg", "Agent identity/auth", "Data formats/interop"]
rated_at: 2026-02-27T23:27:55.472127+00:00
summary:
Defines experimental AI URI scheme for dedicated AI resource access. Enables native connectivity for autonomous systems while supporting human interoperability via HTTPS gateways.


draft_name: draft-bernardos-green-isac-uc
novelty_note: Use case presentation of known ISAC concepts, limited technical novelty
maturity_note: Template-based use case document without technical specifications or solutions
overlap_note: Moderate overlap with existing ISAC research and GREEN use cases
momentum_note: ISAC is emerging area and GREEN WG is active, but early stage
relevance_note: Relevant for autonomous systems requiring sensing capabilities but lacks AI/agent focus
categories: ["Autonomous netops", "Other AI/agent"]
rated_at: 2026-02-27T23:27:55.482317+00:00
summary:
Presents ISAC use case for GREEN Working Group discussions on joint sensing and communication optimization. Targets applications in autonomous systems, smart cities, and industrial automation.


draft_name: draft-pbs-sidrops-roaanycast
novelty_note: Moderate novelty - addresses specific gap in ROA management for unique-ASN anycast deployments
maturity_note: Well-developed with concrete best practices and risk mitigation strategies
overlap_note: Limited overlap with existing RPKI/ROA work, focuses on specific anycast scenario
momentum_note: Moderate momentum - addresses operational need in RPKI community
relevance_note: High relevance for network operators using anycast with RPKI validation
categories: ["Policy/governance", "Autonomous netops"]
rated_at: 2026-02-27T23:28:14.480345+00:00
summary:
Defines best practices for managing Route Origin Authorizations (ROAs) for globally anycasted services where each anycast node uses a unique origin ASN. Addresses technical risks and mitigation strategies for RPKI operations in anycast deployments.


draft_name: draft-sogomonian-aiip-architecture
novelty_note: Very high novelty - completely new protocol architecture for AI system invocation
maturity_note: Early stage architectural definition, lacks implementation details
overlap_note: Unique approach - no similar AI-specific internet protocol architectures
momentum_note: Low momentum - very early stage, unclear adoption path
relevance_note: High relevance as AI systems become more distributed and autonomous
categories: ["A2A protocols", "Agent identity/auth", "Model serving/inference"]
rated_at: 2026-02-27T23:28:14.491796+00:00
summary:
Defines architectural model for Artificial Intelligence Internet Protocol (AIIP) enabling stateless, verifiable invocation of autonomous systems. Uses resolve-invoke-receipt pattern with cryptographic execution receipts and optional attestation evidence.


draft_name: draft-moreno-lisp-uberlay
novelty_note: High novelty - novel approach to multi-overlay interconnection using LISP
maturity_note: Mature specification with detailed mechanisms and procedures
overlap_note: Some overlap with LISP work but focuses on multi-overlay interconnection
momentum_note: Moderate momentum within LISP community
relevance_note: Moderate relevance for complex overlay network deployments
categories: ["Data formats/interop", "Autonomous netops"]
rated_at: 2026-02-27T23:28:14.502652+00:00
summary:
Describes using LISP to interconnect multiple independent network overlays through a transit overlay called 'uberlay'. Enables interworking of different overlay approaches while maintaining autonomy and failure survivability across domains.


draft_name: draft-yue-moq-transporting-sensing-data
novelty_note: Moderate novelty - applies existing MOQ to new 6G sensing data use cases
maturity_note: Moderate maturity with identified challenges but limited concrete solutions
overlap_note: Moderate overlap with MOQ and 6G transport work
momentum_note: High momentum due to 6G development and IoT growth
relevance_note: High relevance for emerging 6G and autonomous system deployments
categories: ["ML traffic mgmt", "Data formats/interop", "Autonomous netops"]
rated_at: 2026-02-27T23:28:14.513998+00:00
summary:
Proposes using Media Over QUIC (MOQ) to transport large-scale, real-time sensing data in 6G networks. Focuses on autonomous driving, smart cities, and industrial IoT scenarios with requirements for low latency and high throughput.


draft_name: draft-ahn-nmrg-5g-security-i2nsf-framework
novelty_note: Moderate novelty - integrates existing I2NSF and IBN concepts for 5G security
maturity_note: Well-developed framework with detailed architecture and policy mechanisms
overlap_note: Significant overlap with I2NSF, IBN, and 5G security work
momentum_note: High momentum driven by 5G deployment and security automation needs
relevance_note: High relevance for 5G network security and automated policy management
categories: ["Policy/governance", "Autonomous netops", "Agent identity/auth"]
rated_at: 2026-02-27T23:28:14.525011+00:00
summary:
Presents integrated framework for automated 5G edge network security using I2NSF architecture and Intent-Based Networking. Enables high-level security intent translation into enforceable policies across network and application layers.


draft_name: draft-ietf-netconf-configuration-tracing
novelty_note: Builds on existing NETCONF but adds useful tracing capabilities for multi-NMS environments
maturity_note: Well-structured 19-page specification with concrete YANG module, appears implementation-ready
overlap_note: Some overlap with general network management drafts but tracing focus is relatively unique
momentum_note: IETF working group draft addressing real operational needs in complex networks
relevance_note: Highly relevant for autonomous networks and multi-controller environments becoming common
categories: ["Autonomous netops", "Data formats/interop"]
rated_at: 2026-02-27T23:28:37.830904+00:00
summary:
Specifies a NETCONF mechanism to map configuration modifications to their originating NMS using external trace IDs. Includes a YANG module to facilitate troubleshooting and post-mortem analysis in autonomous networks.


draft_name: draft-ietf-pim-zeroconf-mcast-addr-alloc-ps
novelty_note: Problem statement for known issues, not introducing new concepts but formalizing requirements
maturity_note: Solid problem analysis but only 11 pages, needs companion solution drafts for full impact
overlap_note: Overlaps with existing zeroconf and multicast allocation work but focuses on specific intersection
momentum_note: IETF working group effort but problem statements typically have lower implementation urgency
relevance_note: Addresses niche use case, limited relevance to broader AI/agent networking trends
categories: ["Agent discovery/reg", "Data formats/interop"]
rated_at: 2026-02-27T23:28:37.854466+00:00
summary:
Problem statement for multicast address allocation in zero-configuration environments. Identifies challenges and requirements for decentralized multicast group address assignment without manual configuration.


draft_name: draft-jeong-opsawg-intent-based-sdv-framework
novelty_note: Novel application of intent-based networking to automotive domain with ITS integration
maturity_note: High-level framework without detailed protocols or implementation specifics
overlap_note: Combines existing intent-based networking with vehicular networks in new way
momentum_note: Individual submission in emerging but not yet mature SDV standardization space
relevance_note: Very relevant to autonomous vehicle networking and intent-based agent systems
categories: ["Autonomous netops", "Agent discovery/reg", "Policy/governance"]
rated_at: 2026-02-27T23:28:37.864797+00:00
summary:
Proposes intent-based management framework for Software-Defined Vehicles in ITS environments. Covers network, security, and application management for SDV-to-SDV and infrastructure communication.


draft_name: draft-architect-cittamarket
novelty_note: Highly novel approach combining AGI identity, blockchain anchoring, and distributed coordination
maturity_note: Only 3 pages with minimal technical detail, appears more conceptual than implementable
overlap_note: Unique combination of AGI, Bitcoin, and identity concepts not seen in other drafts
momentum_note: Individual submission with unconventional approach, unlikely to gain IETF traction
relevance_note: Addresses AGI identity which is relevant but approach may be impractical for real deployment
categories: ["AI safety/alignment", "Agent identity/auth", "Other AI/agent"]
rated_at: 2026-02-27T23:28:37.874652+00:00
summary:
Specifies protocol for immutable AGI system identification using Bitcoin blockchain anchoring. Defines four-layer architecture for creating unforgeable 'Sovereign Identity' records with Proof-of-Work coordination.


draft_name: draft-cui-nmrg-auto-test
novelty_note: Novel application of LLMs to protocol testing with structured automation maturity model
maturity_note: Good framework structure with clear levels but needs more implementation detail
overlap_note: Some overlap with general testing automation but AI-specific focus is relatively unique
momentum_note: Research group draft in active AI networking area with practical applications
relevance_note: Highly relevant to AI-assisted network operations and protocol development
categories: ["Autonomous netops", "ML traffic mgmt", "Other AI/agent"]
rated_at: 2026-02-27T23:28:37.882629+00:00
summary:
Framework for AI-assisted network protocol testing using LLMs and automated test generation. Defines automation maturity levels from manual (Level 0) to fully autonomous testing (Level 5).


draft_name: draft-kartha-grd
novelty_note: Novel approach to resource discovery using geospatial context instead of traditional naming
maturity_note: Early stage architectural document with no protocol or implementation details
overlap_note: Limited overlap with existing DNS/naming standards, addresses different problem space
momentum_note: Addresses emerging need for spatial computing but still conceptual
relevance_note: Highly relevant for autonomous systems and AR applications requiring location-based discovery
categories: ["Agent discovery/reg", "Autonomous netops", "Data formats/interop"]
rated_at: 2026-02-27T23:28:55.857053+00:00
summary:
Defines architectural framework for discovering network resources based on physical location and context rather than predefined identifiers. Targets AR, autonomous systems, and spatial computing applications that need location-aware resource discovery.


draft_name: draft-templin-manet-inet-omni
novelty_note: Incremental work building on existing AERO/OMNI technologies for MANET connectivity
maturity_note: Builds on established technologies but specific integration approach needs development
overlap_note: Some overlap with existing MANET and mobile networking solutions
momentum_note: Limited momentum as MANET interest has declined in recent years
relevance_note: Relevant for autonomous mobile systems but traditional networking focus
categories: ["Autonomous netops", "A2A protocols"]
rated_at: 2026-02-27T23:28:55.868836+00:00
summary:
Presents framework for connecting mobile ad-hoc networks to the Internet using AERO and OMNI technologies. Enables isolated mobile networks to interface with fixed infrastructure.


draft_name: draft-luan-rtgwg-sdaf
novelty_note: Creative use of satellite constellation symmetry for autonomous forwarding decisions
maturity_note: Well-developed technical approach but needs validation in real satellite environments
overlap_note: Addresses unique challenges of satellite networks with novel approach
momentum_note: Strong momentum due to growing LEO constellation deployments
relevance_note: Very relevant for autonomous satellite operations and space-based networking
categories: ["Autonomous netops", "A2A protocols"]
rated_at: 2026-02-27T23:28:55.879652+00:00
summary:
Proposes symmetry-driven forwarding mechanism for LEO satellite networks to avoid routing loops and black holes during topology changes. Leverages toroidal topology structure for faster convergence without protocol modifications.


draft_name: draft-mw-wimse-transitive-attestation
novelty_note: Novel approach to workload identity portability with specific focus on AI agent security risks
maturity_note: Early stage profile with dependencies on other draft specifications
overlap_note: Builds on WIMSE framework but addresses unique AI agent security challenges
momentum_note: Very high momentum due to urgent AI security needs and regulatory concerns
relevance_note: Extremely relevant for AI agent deployment security and autonomous system integrity
categories: ["Agent identity/auth", "AI safety/alignment", "Policy/governance"]
rated_at: 2026-02-27T23:28:55.889155+00:00
summary:
Defines WIMSE profile for cryptographically binding workload identities to their execution environment to prevent credential misuse. Addresses AI agent security concerns including prompt injection and cross-jurisdictional movement.


