# drafts

name: draft-a2a-moqt-transport
rev: 00
title: Media over QUIC Transport (MOQT) for Agent-to-Agent Protocol
time: 2025-10-20T19:44:25Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-23T19:44:25Z
states: ["/api/v1/doc/state/4/", "/api/v1/doc/state/150/"]
categories: ["A2A protocols", "Data formats/interop", "Agent discovery/reg"]
tags: []
fetched_at: 2026-02-27T22:56:05.127734+00:00
abstract:
This document specifies how the Agent-to-Agent (A2A) protocol can be
   transported over Media over QUIC Transport (MOQT).  MOQT provides a
   publish/subscribe model over QUIC that enables efficient real-time
   communication between AI agents, supporting the A2A protocol's
   requirements for discovery, negotiation, and collaboration while
   leveraging MOQT's streaming capabilities and built-in prioritization
   mechanisms.

full_text:
Media Over QUIC                                            S. Nandakumar
Internet-Draft                                                     Cisco
Intended status: Standards Track                             C. Jennings
Expires: 20 April 2026                                     Cisco Systems
                                                         17 October 2025


      Media over QUIC Transport (MOQT) for Agent-to-Agent Protocol
                      draft-a2a-moqt-transport-00

Abstract

   This document specifies how the Agent-to-Agent (A2A) protocol can be
   transported over Media over QUIC Transport (MOQT).  MOQT provides a
   publish/subscribe model over QUIC that enables efficient real-time
   communication between AI agents, supporting the A2A protocol's
   requirements for discovery, negotiation, and collaboration while
   leveraging MOQT's streaming capabilities and built-in prioritization
   mechanisms.

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://ietf-wg-
   moq.github.io/draft-a2a-moqt-transport/draft-a2a-moqt-transport.html.
   Status information for this document may be found at
   https://datatracker.ietf.org/doc/draft-a2a-moqt-transport/.

   Discussion of this document takes place on the Media Over QUIC
   Working Group mailing list (mailto:moq@ietf.org), which is archived
   at https://mailarchive.ietf.org/arch/browse/moq/.  Subscribe at
   https://www.ietf.org/mailman/listinfo/moq/.

   Source for this draft and an issue tracker can be found at
   https://github.com/ietf-wg-moq/draft-a2a-moqt-transport.

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/.





Nandakumar & Jennings     Expires 20 April 2026                 [Page 1]

Internet-Draft                A2A over MOQT                 October 2025


   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 20 April 2026.

Copyright Notice

   Copyright (c) 2025 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.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  A2A Transport Requirements  . . . . . . . . . . . . . . . . .   3
   3.  MOQT Transport Mapping  . . . . . . . . . . . . . . . . . . .   4
     3.1.  Connection Establishment  . . . . . . . . . . . . . . . .   4
     3.2.  Track Organization  . . . . . . . . . . . . . . . . . . .   5
     3.3.  Message Serialization . . . . . . . . . . . . . . . . . .   5
     3.4.  Priority and Quality of Service . . . . . . . . . . . . .   6
   4.  Protocol Operations . . . . . . . . . . . . . . . . . . . . .   6
     4.1.  Agent Discovery . . . . . . . . . . . . . . . . . . . . .   6
     4.2.  Request/Response Patterns . . . . . . . . . . . . . . . .   7
     4.3.  Streaming Operations  . . . . . . . . . . . . . . . . . .   8
   5.  Benefits of MOQT for A2A  . . . . . . . . . . . . . . . . . .   9
     5.1.  Real-time Communication Benefits  . . . . . . . . . . . .   9
     5.2.  Scalability Benefits  . . . . . . . . . . . . . . . . . .  10
     5.3.  Reliability and Resilience  . . . . . . . . . . . . . . .  10
   6.  MOQT Relay Infrastructure for A2A . . . . . . . . . . . . . .  10
     6.1.  Relay Network Architecture  . . . . . . . . . . . . . . .  10
     6.2.  Message Caching Benefits  . . . . . . . . . . . . . . . .  11
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  12
   Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12




Nandakumar & Jennings     Expires 20 April 2026                 [Page 2]

Internet-Draft                A2A over MOQT                 October 2025


1.  Introduction

   The Agent-to-Agent (A2A) protocol enables communication between AI
   agents across different platforms and frameworks.  Currently, A2A
   supports three transport protocols: JSON-RPC 2.0 over HTTP(S), gRPC,
   and HTTP+JSON/REST.  This document defines a fourth transport option
   using Media over QUIC Transport (MOQT) to provide enhanced real-time
   streaming capabilities for agent interactions.

   MOQT is designed for media streaming over QUIC and WebTransport,
   providing a publish/subscribe model with hierarchical data
   organization.  While originally intended for media applications,
   MOQT's streaming model and prioritization capabilities make it well-
   suited for real-time agent communication scenarios.

1.1.  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.

2.  A2A Transport Requirements

   According to the A2A specification, all transport protocols MUST
   provide functional equivalence and support the following
   capabilities:

   *  Secure communication over encrypted channels

   *  Request/response messaging patterns

   *  Streaming data delivery capabilities

   *  Error handling and status reporting

   *  Agent discovery and capability negotiation

   *  Support for various data types (text, JSON, files)











Nandakumar & Jennings     Expires 20 April 2026                 [Page 3]

Internet-Draft                A2A over MOQT                 October 2025


      A2A Protocol Layer
      ┌─────────────────────────────────────────────────────────────┐
      │  Agent Discovery │ Capability Exchange │ Task Collaboration │
      └─────────────────────────────────────────────────────────────┘
                                    │
      ┌─────────────────────────────────────────────────────────────┐
      │                    MOQT Transport Layer                     │
      │  ┌─────────────┐  ┌─────────────┐  ┌─────────────────────┐  │
      │  │ PUB/SUB     │  │ Streaming   │  │ Priority/QoS        │  │
      │  │ Model       │  │ Support     │  │ Management          │  │
      │  └─────────────┘  └─────────────┘  └─────────────────────┘  │
      └─────────────────────────────────────────────────────────────┘
                                    │
      ┌─────────────────────────────────────────────────────────────┐
      │                    QUIC/WebTransport                        │
      │        ┌─────────────┐              ┌─────────────┐         │
      │        │ Encryption  │              │ Multiplexing│         │
      │        │ (TLS 1.3)   │              │ & Flow Ctrl │         │
      │        └─────────────┘              └─────────────┘         │
      └─────────────────────────────────────────────────────────────┘

3.  MOQT Transport Mapping

3.1.  Connection Establishment

   A2A agents using MOQT transport MUST establish a QUIC or WebTransport
   connection with the ALPN value "moq-00" as defined in the MOQT
   specification.  The connection setup follows this sequence:

   Agent A                                                   Agent B
      |                                                        |
      |──── QUIC Connection (ALPN: "moq-00") ────────────────▶ |
      |◄─── QUIC Connection Established ───────────────────────|
      |                                                        |
      |──── MOQT CLIENT_SETUP ────────────────────────────────▶|
      |◄─── MOQT SERVER_SETUP ─────────────────────────────────|
      |                                                        |
      |──── A2A Agent Registration ───────────────────────────▶|
      |◄─── A2A Capability Exchange ───────────────────────────|
      |                                                        |
      |◄═══ A2A Protocol Exchang ═════════════════════════════▶|

   During the MOQT setup phase, agents MUST negotiate the following A2A-
   specific extensions:

   *  a2a-version: Supported A2A protocol version

   *  a2a-capabilities: Agent capabilities and supported operations



Nandakumar & Jennings     Expires 20 April 2026                 [Page 4]

Internet-Draft                A2A over MOQT                 October 2025


   *  a2a-auth: Authentication and authorization tokens

3.2.  Track Organization

   A2A protocol messages are mapped to MOQT tracks using a hierarchical
   namespace structure.  Each agent creates tracks for different message
   categories: Tracks are organized as follows:

   Request Tracks:  Used for A2A request messages, organized by category
      and action (e.g., discovery/capabilities, tasks/execute).

   Response Tracks:  Used for A2A response messages, organized by
      request ID for correlation.

   Stream Tracks:  Used for long-running streaming operations like task
      execution updates or file transfers.

   Notification Tracks:  Used for asynchronous notifications and events.

3.3.  Message Serialization

   A2A protocol messages are serialized as JSON and encapsulated within
   MOQT objects.  Each MOQT object contains:

   MOQT Object Structure for A2A:

   ┌─────────────────────────────────────────────────────────┐
   │                 MOQT Object Header                      │
   │  Track ID │ Group ID │ Object ID │ Priority │ ....      │
   └─────────────────────────────────────────────────────────┘
   ┌─────────────────────────────────────────────────────────┐
   │                 A2A Message Payload                     │
   │  ┌─────────────────────────────────────────────────────┐│
   │  │              JSON A2A Message                       ││
   │  │  {                                                  ││
   │  │    "jsonrpc": "2.0",                                ││
   │  │    "method": "category/action",                     ││
   │  │    "params": { ... },                               ││
   │  │    "id": "request-id"                               ││
   │  │  }                                                  ││
   │  └─────────────────────────────────────────────────────┘│
   └─────────────────────────────────────────────────────────┘

   The A2A message format remains unchanged from the JSON-RPC 2.0
   specification, ensuring compatibility with existing A2A
   implementations.





Nandakumar & Jennings     Expires 20 April 2026                 [Page 5]

Internet-Draft                A2A over MOQT                 October 2025


3.4.  Priority and Quality of Service

   MOQT's built-in priority system is mapped to A2A message urgency:

   Priority 1 (Highest):  Emergency and critical error responses

   Priority 2:  Real-time interaction responses and notifications

   Priority 3:  Standard request/response messages

   Priority 4:  Discovery and capability exchange messages

   Priority 5 (Lowest):  Background updates and non-critical
      notifications

4.  Protocol Operations

4.1.  Agent Discovery

   Agent discovery over MOQT uses a Subscribe Namespace pattern where
   agents subscribe to the <session_context_id>/discovery namespace
   prefix and publish their agent announcements using the
   <session_context_id>/discovery/agent-{id} pattern to reach all
   subscribers.

   Discovery Flow:

   Agent A                       MOQT Network                    Agent B
      |                              |                             |
      |─ SUBSCRIBE_NAMESPACE────────▶|                             |
      |  (<..>/discovery)            |◄─ SUBSCRIBE_NAMESPACE───────┤
      |                              |   (<..>/discovery)          |
      |                              |                             |
      |─ PUBLISH(/discovery/         |                             |
      |   agent-a) ─────────────────▶|─ PUBLISH(/discovery/        |
      |                              |agent-a) ───────────────────▶|
      |                              |                             |
      |                              |◄─ PUBLISH(/discovery/       |
      |                              |    agent-b) ────────────────┤
      |◄─ PUBLISH(/discovery/        |                             |
      |   agent-b) ──────────────────|                             |
      |                              |                             |
      |                              |                             |
      |◄── Object(Agent B caps) ─────|── Object(Agent A caps) ────▶|







Nandakumar & Jennings     Expires 20 April 2026                 [Page 6]

Internet-Draft                A2A over MOQT                 October 2025


4.2.  Request/Response Patterns

   A2A request/response interactions are implemented using coordinated
   PUBLISH/SUBSCRIBE operations:

   1.  Server agent uses SUBSCRIBE_NAMESPACE to subscribe to
       <..>/server-agent-{id} Namespace prefix

   2.  Client agent sends PUBLISH message on <..>/server-
       agent-{id}/request track

   3.  Client agent subscribes to <..>/server-agent-{id}/response track

   4.  Client agent publishes OBJECT on <..>/server-agent-{id}/request
       track

   5.  Server agent receives OBJECT via its namespace subscription

   6.  Server agent publishes OBJECT on <..>/server-agent-{id}/response
       track

   7.  Client agent receives response OBJECT via its subscription





























Nandakumar & Jennings     Expires 20 April 2026                 [Page 7]

Internet-Draft                A2A over MOQT                 October 2025


   Request/Response Flow:

   Client Agent                MOQT                   Server Agent
        |                        |                        |
        |                        |◄(1) SUBSCRIBE_NAMESPACE|
        |                        | (<..>/server-agent-{id})
        |─(2) PUBLISH(           |                        |
        |  /server-agent-{id}/   |                        |
        |  request) ────────────▶|                        |
        |                        |─(2) PUBLISH(           |
        |                        |  /server-agent-{id}/   |
        |                        |  request) ────────────▶|
        |─(3) SUBSCRIBE(         |                        |
        |  /server-agent-{id}/   |                        |
        |  response) ───────────▶|                        |
        |                        |─(3) SUBSCRIBE(         |
        |                        |  /server-agent-{id}/   |
        |                        |  response) ───────────▶|
        |─(4) OBJECT(            |                        |
        |  /server-agent-{id}/   |                        |
        |  request) ────────────▶|───────────────────────▶|
        |                        |                        |
        |                        |◄(5) OBJECT(            |
        |                        |  /server-agent-{id}/   |
        |                        |  response) ────────────|
        |◄(6) OBJECT(            |◄───────────────────────|
        |  /server-agent-{id}/   |                        |
        |  response) ────────────|                        |
        |                        |                        |

4.3.  Streaming Operations

   Long-running A2A operations like task execution or file transfer
   utilize MOQT's streaming capabilities.  Stream tracks carry
   incremental updates as separate MOQT objects.
















Nandakumar & Jennings     Expires 20 April 2026                 [Page 8]

Internet-Draft                A2A over MOQT                 October 2025


   Streaming Task Execution:

   Client                     MOQT Stream                  Server
     |                           |                           |
     |─ SUBSCRIBE(               |                           |
     |  /server-agent-{id}/      |                           |
     |  task_{id}) ─────────────▶|                           |
     |                           |─ SUBSCRIBE(               |
     |                           |  /server-agent-{id}/      |
     |                           |  task_{id}) ─────────────▶|
     |                           |◄─ OBJECT(                 |
     |                           |  /server-agent-{id}/      |
     |                           |  task_{id}, progress-1) ──|
     |◄─ Progress Update 1 ──────|                           |
     |                           |◄─ OBJECT(                 |
     |                           |  /server-agent-{id}/      |
     |                           |  task_{id}, progress-2) ──|
     |◄─ Progress Update 2 ──────|                           |
     |                           |◄─ OBJECT(                 |
     |                           |  /server-agent-{id}/      |
     |                           |  task_{id}, result) ──────|
     |◄─ Final Result ───────────|                           |
     |                           |◄─ OBJECT(                 |
     |                           |  /server-agent-{id}/      |
     |                           |  task_{id}, complete) ────|
     |◄─ Stream Complete ────────|                           |

5.  Benefits of MOQT for A2A

   MOQT provides significant advantages over traditional A2A transports,
   particularly for real-time agent collaboration and large-scale
   deployments:

5.1.  Real-time Communication Benefits

   *  Low-latency streaming enables immediate agent response to changing
      conditions

   *  Priority-based message delivery ensures critical communications
      are not delayed

   *  Streaming object delivery allows agents to act on incomplete data
      when appropriate

   *  Built-in flow control prevents agent overload during high-volume
      interactions





Nandakumar & Jennings     Expires 20 April 2026                 [Page 9]

Internet-Draft                A2A over MOQT                 October 2025


5.2.  Scalability Benefits

   MOQT's publish/subscribe model creates powerful network effects for
   multi-agent environments:

   *  One-to-many broadcasts enable efficient agent coordination

   *  Subscription-based interest management reduces unnecessary traffic

   *  Dynamic agent discovery scales to thousands of participants

   *  Relay-based distribution prevents connection explosion in mesh
      networks

5.3.  Reliability and Resilience

   MOQT provides enhanced reliability features critical for production
   agent deployments:

   *  Connection migration maintains agent sessions during network
      changes

   *  Automatic retry and recovery mechanisms handle transient failures

   *  Graceful degradation allows agents to continue operating with
      reduced capabilities

   *  Quality of Service controls prevent cascade failures in agent
      networks

6.  MOQT Relay Infrastructure for A2A

   MOQT relays provide critical infrastructure benefits for large-scale
   A2A deployments, enabling efficient message distribution and caching.

6.1.  Relay Network Architecture

   MOQT relays form a hierarchical distribution network that optimizes
   A2A message delivery across geographic and organizational boundaries:

   This hierarchical structure provides:

   *  Regional optimization with local agent clusters

   *  Global connectivity for cross-region agent collaboration

   *  Load distribution to prevent single points of failure




Nandakumar & Jennings     Expires 20 April 2026                [Page 10]

Internet-Draft                A2A over MOQT                 October 2025


   *  Configurable routing policies based on agent requirements

6.2.  Message Caching Benefits

   MOQT relays can implement intelligent caching strategies optimized
   for A2A communication patterns.

   The most frequently accessed and time-sensitive data with time-to-
   live values are measured in seconds.  This includes real-time agent
   responses, live data streams, and status updates that require
   immediate availability.  These messages are kept in high-speed memory
   to ensure minimal latency for active agent interactions.

   Another layer can serve as an intermediate storage tier with time-to-
   live values measured in minutes.  This layer contains agent
   capability profiles, metadata about agent configurations, and results
   from common queries that are accessed regularly.  The caching layer
   can provide a balance between accessibility and resource utilization.

   Also for archives of historical data with extended retention periods
   measured in hours or days, can employ a different storage strategy.
   Examples data might include historical logs, archived computation
   results, compliance audit data, and debug traces that may be needed
   for analysis or regulatory purposes but are accessed infrequently.

7.  References

7.1.  Normative References

   [A2A]      A2A Project, "Agent-to-Agent Protocol Specification",
              2025, <https://a2a-protocol.org/latest/specification/>.

   [MoQ-TRANSPORT]
              Nandakumar, S., Vasiliev, V., Swett, I., and A. Frindell,
              "Media over QUIC Transport", Work in Progress, Internet-
              Draft, draft-ietf-moq-transport-14, 2 September 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-moq-
              transport-14>.

   [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>.




Nandakumar & Jennings     Expires 20 April 2026                [Page 11]

Internet-Draft                A2A over MOQT                 October 2025


   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

   [RFC9000]  Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
              Multiplexed and Secure Transport", RFC 9000,
              DOI 10.17487/RFC9000, May 2021,
              <https://www.rfc-editor.org/info/rfc9000>.

7.2.  Informative References

   [RFC7540]  Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
              Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
              DOI 10.17487/RFC7540, May 2015,
              <https://www.rfc-editor.org/info/rfc7540>.

   [WebTransport]
              Vasiliev, V., "The WebTransport Protocol Framework",
              RFC 9297, August 2023,
              <https://www.rfc-editor.org/rfc/rfc9297>.

Appendix A.  Acknowledgments

Authors' Addresses

   Suhas Nandakumar
   Cisco
   Email: snandaku@cisco.com


   Cullen Jennings
   Cisco Systems
   Email: fluffy@cisco.com


















Nandakumar & Jennings     Expires 20 April 2026                [Page 12]


name: draft-nandakumar-a2a-moqt-transport
rev: 00
title: Media over QUIC Transport (MOQT) for Agent-to-Agent Protocol
time: 2025-10-20T19:55:13Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-23T19:55:13Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["A2A protocols", "Data formats/interop", "Agent discovery/reg"]
tags: []
fetched_at: 2026-02-27T22:56:05.127738+00:00
abstract:
This document specifies how the Agent-to-Agent (A2A) protocol can be
   transported over Media over QUIC Transport (MOQT).  MOQT provides a
   publish/subscribe model over QUIC that enables efficient real-time
   communication between AI agents, supporting the A2A protocol's
   requirements for discovery, negotiation, and collaboration while
   leveraging MOQT's streaming capabilities and built-in prioritization
   mechanisms.

full_text:
Media Over QUIC                                            S. Nandakumar
Internet-Draft                                                     Cisco
Intended status: Standards Track                             C. Jennings
Expires: 20 April 2026                                     Cisco Systems
                                                         17 October 2025


      Media over QUIC Transport (MOQT) for Agent-to-Agent Protocol
                      draft-nandakumar-a2a-moqt-transport-00

Abstract

   This document specifies how the Agent-to-Agent (A2A) protocol can be
   transported over Media over QUIC Transport (MOQT).  MOQT provides a
   publish/subscribe model over QUIC that enables efficient real-time
   communication between AI agents, supporting the A2A protocol's
   requirements for discovery, negotiation, and collaboration while
   leveraging MOQT's streaming capabilities and built-in prioritization
   mechanisms.

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://ietf-wg-
   moq.github.io/draft-a2a-moqt-transport/draft-a2a-moqt-transport.html.
   Status information for this document may be found at
   https://datatracker.ietf.org/doc/draft-a2a-moqt-transport/.

   Discussion of this document takes place on the Media Over QUIC
   Working Group mailing list (mailto:moq@ietf.org), which is archived
   at https://mailarchive.ietf.org/arch/browse/moq/.  Subscribe at
   https://www.ietf.org/mailman/listinfo/moq/.

   Source for this draft and an issue tracker can be found at
   https://github.com/ietf-wg-moq/draft-a2a-moqt-transport.

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/.





Nandakumar & Jennings     Expires 20 April 2026                 [Page 1]

Internet-Draft                A2A over MOQT                 October 2025


   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 20 April 2026.

Copyright Notice

   Copyright (c) 2025 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.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  A2A Transport Requirements  . . . . . . . . . . . . . . . . .   3
   3.  MOQT Transport Mapping  . . . . . . . . . . . . . . . . . . .   4
     3.1.  Connection Establishment  . . . . . . . . . . . . . . . .   4
     3.2.  Track Organization  . . . . . . . . . . . . . . . . . . .   5
     3.3.  Message Serialization . . . . . . . . . . . . . . . . . .   5
     3.4.  Priority and Quality of Service . . . . . . . . . . . . .   6
   4.  Protocol Operations . . . . . . . . . . . . . . . . . . . . .   6
     4.1.  Agent Discovery . . . . . . . . . . . . . . . . . . . . .   6
     4.2.  Request/Response Patterns . . . . . . . . . . . . . . . .   7
     4.3.  Streaming Operations  . . . . . . . . . . . . . . . . . .   8
   5.  Benefits of MOQT for A2A  . . . . . . . . . . . . . . . . . .   9
     5.1.  Real-time Communication Benefits  . . . . . . . . . . . .   9
     5.2.  Scalability Benefits  . . . . . . . . . . . . . . . . . .  10
     5.3.  Reliability and Resilience  . . . . . . . . . . . . . . .  10
   6.  MOQT Relay Infrastructure for A2A . . . . . . . . . . . . . .  10
     6.1.  Relay Network Architecture  . . . . . . . . . . . . . . .  10
     6.2.  Message Caching Benefits  . . . . . . . . . . . . . . . .  11
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  12
   Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12




Nandakumar & Jennings     Expires 20 April 2026                 [Page 2]

Internet-Draft                A2A over MOQT                 October 2025


1.  Introduction

   The Agent-to-Agent (A2A) protocol enables communication between AI
   agents across different platforms and frameworks.  Currently, A2A
   supports three transport protocols: JSON-RPC 2.0 over HTTP(S), gRPC,
   and HTTP+JSON/REST.  This document defines a fourth transport option
   using Media over QUIC Transport (MOQT) to provide enhanced real-time
   streaming capabilities for agent interactions.

   MOQT is designed for media streaming over QUIC and WebTransport,
   providing a publish/subscribe model with hierarchical data
   organization.  While originally intended for media applications,
   MOQT's streaming model and prioritization capabilities make it well-
   suited for real-time agent communication scenarios.

1.1.  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.

2.  A2A Transport Requirements

   According to the A2A specification, all transport protocols MUST
   provide functional equivalence and support the following
   capabilities:

   *  Secure communication over encrypted channels

   *  Request/response messaging patterns

   *  Streaming data delivery capabilities

   *  Error handling and status reporting

   *  Agent discovery and capability negotiation

   *  Support for various data types (text, JSON, files)











Nandakumar & Jennings     Expires 20 April 2026                 [Page 3]

Internet-Draft                A2A over MOQT                 October 2025


      A2A Protocol Layer
      ┌─────────────────────────────────────────────────────────────┐
      │  Agent Discovery │ Capability Exchange │ Task Collaboration │
      └─────────────────────────────────────────────────────────────┘
                                    │
      ┌─────────────────────────────────────────────────────────────┐
      │                    MOQT Transport Layer                     │
      │  ┌─────────────┐  ┌─────────────┐  ┌─────────────────────┐  │
      │  │ PUB/SUB     │  │ Streaming   │  │ Priority/QoS        │  │
      │  │ Model       │  │ Support     │  │ Management          │  │
      │  └─────────────┘  └─────────────┘  └─────────────────────┘  │
      └─────────────────────────────────────────────────────────────┘
                                    │
      ┌─────────────────────────────────────────────────────────────┐
      │                    QUIC/WebTransport                        │
      │        ┌─────────────┐              ┌─────────────┐         │
      │        │ Encryption  │              │ Multiplexing│         │
      │        │ (TLS 1.3)   │              │ & Flow Ctrl │         │
      │        └─────────────┘              └─────────────┘         │
      └─────────────────────────────────────────────────────────────┘

3.  MOQT Transport Mapping

3.1.  Connection Establishment

   A2A agents using MOQT transport MUST establish a QUIC or WebTransport
   connection with the ALPN value "moq-00" as defined in the MOQT
   specification.  The connection setup follows this sequence:

   Agent A                                                   Agent B
      |                                                        |
      |──── QUIC Connection (ALPN: "moq-00") ────────────────▶ |
      |◄─── QUIC Connection Established ───────────────────────|
      |                                                        |
      |──── MOQT CLIENT_SETUP ────────────────────────────────▶|
      |◄─── MOQT SERVER_SETUP ─────────────────────────────────|
      |                                                        |
      |──── A2A Agent Registration ───────────────────────────▶|
      |◄─── A2A Capability Exchange ───────────────────────────|
      |                                                        |
      |◄═══ A2A Protocol Exchang ═════════════════════════════▶|

   During the MOQT setup phase, agents MUST negotiate the following A2A-
   specific extensions:

   *  a2a-version: Supported A2A protocol version

   *  a2a-capabilities: Agent capabilities and supported operations



Nandakumar & Jennings     Expires 20 April 2026                 [Page 4]

Internet-Draft                A2A over MOQT                 October 2025


   *  a2a-auth: Authentication and authorization tokens

3.2.  Track Organization

   A2A protocol messages are mapped to MOQT tracks using a hierarchical
   namespace structure.  Each agent creates tracks for different message
   categories: Tracks are organized as follows:

   Request Tracks:  Used for A2A request messages, organized by category
      and action (e.g., discovery/capabilities, tasks/execute).

   Response Tracks:  Used for A2A response messages, organized by
      request ID for correlation.

   Stream Tracks:  Used for long-running streaming operations like task
      execution updates or file transfers.

   Notification Tracks:  Used for asynchronous notifications and events.

3.3.  Message Serialization

   A2A protocol messages are serialized as JSON and encapsulated within
   MOQT objects.  Each MOQT object contains:

   MOQT Object Structure for A2A:

   ┌─────────────────────────────────────────────────────────┐
   │                 MOQT Object Header                      │
   │  Track ID │ Group ID │ Object ID │ Priority │ ....      │
   └─────────────────────────────────────────────────────────┘
   ┌─────────────────────────────────────────────────────────┐
   │                 A2A Message Payload                     │
   │  ┌─────────────────────────────────────────────────────┐│
   │  │              JSON A2A Message                       ││
   │  │  {                                                  ││
   │  │    "jsonrpc": "2.0",                                ││
   │  │    "method": "category/action",                     ││
   │  │    "params": { ... },                               ││
   │  │    "id": "request-id"                               ││
   │  │  }                                                  ││
   │  └─────────────────────────────────────────────────────┘│
   └─────────────────────────────────────────────────────────┘

   The A2A message format remains unchanged from the JSON-RPC 2.0
   specification, ensuring compatibility with existing A2A
   implementations.





Nandakumar & Jennings     Expires 20 April 2026                 [Page 5]

Internet-Draft                A2A over MOQT                 October 2025


3.4.  Priority and Quality of Service

   MOQT's built-in priority system is mapped to A2A message urgency:

   Priority 1 (Highest):  Emergency and critical error responses

   Priority 2:  Real-time interaction responses and notifications

   Priority 3:  Standard request/response messages

   Priority 4:  Discovery and capability exchange messages

   Priority 5 (Lowest):  Background updates and non-critical
      notifications

4.  Protocol Operations

4.1.  Agent Discovery

   Agent discovery over MOQT uses a Subscribe Namespace pattern where
   agents subscribe to the <session_context_id>/discovery namespace
   prefix and publish their agent announcements using the
   <session_context_id>/discovery/agent-{id} pattern to reach all
   subscribers.

   Discovery Flow:

   Agent A                       MOQT Network                    Agent B
      |                              |                             |
      |─ SUBSCRIBE_NAMESPACE────────▶|                             |
      |  (<..>/discovery)            |◄─ SUBSCRIBE_NAMESPACE───────┤
      |                              |   (<..>/discovery)          |
      |                              |                             |
      |─ PUBLISH(/discovery/         |                             |
      |   agent-a) ─────────────────▶|─ PUBLISH(/discovery/        |
      |                              |agent-a) ───────────────────▶|
      |                              |                             |
      |                              |◄─ PUBLISH(/discovery/       |
      |                              |    agent-b) ────────────────┤
      |◄─ PUBLISH(/discovery/        |                             |
      |   agent-b) ──────────────────|                             |
      |                              |                             |
      |                              |                             |
      |◄── Object(Agent B caps) ─────|── Object(Agent A caps) ────▶|







Nandakumar & Jennings     Expires 20 April 2026                 [Page 6]

Internet-Draft                A2A over MOQT                 October 2025


4.2.  Request/Response Patterns

   A2A request/response interactions are implemented using coordinated
   PUBLISH/SUBSCRIBE operations:

   1.  Server agent uses SUBSCRIBE_NAMESPACE to subscribe to
       <..>/server-agent-{id} Namespace prefix

   2.  Client agent sends PUBLISH message on <..>/server-
       agent-{id}/request track

   3.  Client agent subscribes to <..>/server-agent-{id}/response track

   4.  Client agent publishes OBJECT on <..>/server-agent-{id}/request
       track

   5.  Server agent receives OBJECT via its namespace subscription

   6.  Server agent publishes OBJECT on <..>/server-agent-{id}/response
       track

   7.  Client agent receives response OBJECT via its subscription





























Nandakumar & Jennings     Expires 20 April 2026                 [Page 7]

Internet-Draft                A2A over MOQT                 October 2025


   Request/Response Flow:

   Client Agent                MOQT                   Server Agent
        |                        |                        |
        |                        |◄(1) SUBSCRIBE_NAMESPACE|
        |                        | (<..>/server-agent-{id})
        |─(2) PUBLISH(           |                        |
        |  /server-agent-{id}/   |                        |
        |  request) ────────────▶|                        |
        |                        |─(2) PUBLISH(           |
        |                        |  /server-agent-{id}/   |
        |                        |  request) ────────────▶|
        |─(3) SUBSCRIBE(         |                        |
        |  /server-agent-{id}/   |                        |
        |  response) ───────────▶|                        |
        |                        |─(3) SUBSCRIBE(         |
        |                        |  /server-agent-{id}/   |
        |                        |  response) ───────────▶|
        |─(4) OBJECT(            |                        |
        |  /server-agent-{id}/   |                        |
        |  request) ────────────▶|───────────────────────▶|
        |                        |                        |
        |                        |◄(5) OBJECT(            |
        |                        |  /server-agent-{id}/   |
        |                        |  response) ────────────|
        |◄(6) OBJECT(            |◄───────────────────────|
        |  /server-agent-{id}/   |                        |
        |  response) ────────────|                        |
        |                        |                        |

4.3.  Streaming Operations

   Long-running A2A operations like task execution or file transfer
   utilize MOQT's streaming capabilities.  Stream tracks carry
   incremental updates as separate MOQT objects.
















Nandakumar & Jennings     Expires 20 April 2026                 [Page 8]

Internet-Draft                A2A over MOQT                 October 2025


   Streaming Task Execution:

   Client                     MOQT Stream                  Server
     |                           |                           |
     |─ SUBSCRIBE(               |                           |
     |  /server-agent-{id}/      |                           |
     |  task_{id}) ─────────────▶|                           |
     |                           |─ SUBSCRIBE(               |
     |                           |  /server-agent-{id}/      |
     |                           |  task_{id}) ─────────────▶|
     |                           |◄─ OBJECT(                 |
     |                           |  /server-agent-{id}/      |
     |                           |  task_{id}, progress-1) ──|
     |◄─ Progress Update 1 ──────|                           |
     |                           |◄─ OBJECT(                 |
     |                           |  /server-agent-{id}/      |
     |                           |  task_{id}, progress-2) ──|
     |◄─ Progress Update 2 ──────|                           |
     |                           |◄─ OBJECT(                 |
     |                           |  /server-agent-{id}/      |
     |                           |  task_{id}, result) ──────|
     |◄─ Final Result ───────────|                           |
     |                           |◄─ OBJECT(                 |
     |                           |  /server-agent-{id}/      |
     |                           |  task_{id}, complete) ────|
     |◄─ Stream Complete ────────|                           |

5.  Benefits of MOQT for A2A

   MOQT provides significant advantages over traditional A2A transports,
   particularly for real-time agent collaboration and large-scale
   deployments:

5.1.  Real-time Communication Benefits

   *  Low-latency streaming enables immediate agent response to changing
      conditions

   *  Priority-based message delivery ensures critical communications
      are not delayed

   *  Streaming object delivery allows agents to act on incomplete data
      when appropriate

   *  Built-in flow control prevents agent overload during high-volume
      interactions





Nandakumar & Jennings     Expires 20 April 2026                 [Page 9]

Internet-Draft                A2A over MOQT                 October 2025


5.2.  Scalability Benefits

   MOQT's publish/subscribe model creates powerful network effects for
   multi-agent environments:

   *  One-to-many broadcasts enable efficient agent coordination

   *  Subscription-based interest management reduces unnecessary traffic

   *  Dynamic agent discovery scales to thousands of participants

   *  Relay-based distribution prevents connection explosion in mesh
      networks

5.3.  Reliability and Resilience

   MOQT provides enhanced reliability features critical for production
   agent deployments:

   *  Connection migration maintains agent sessions during network
      changes

   *  Automatic retry and recovery mechanisms handle transient failures

   *  Graceful degradation allows agents to continue operating with
      reduced capabilities

   *  Quality of Service controls prevent cascade failures in agent
      networks

6.  MOQT Relay Infrastructure for A2A

   MOQT relays provide critical infrastructure benefits for large-scale
   A2A deployments, enabling efficient message distribution and caching.

6.1.  Relay Network Architecture

   MOQT relays form a hierarchical distribution network that optimizes
   A2A message delivery across geographic and organizational boundaries:

   This hierarchical structure provides:

   *  Regional optimization with local agent clusters

   *  Global connectivity for cross-region agent collaboration

   *  Load distribution to prevent single points of failure




Nandakumar & Jennings     Expires 20 April 2026                [Page 10]

Internet-Draft                A2A over MOQT                 October 2025


   *  Configurable routing policies based on agent requirements

6.2.  Message Caching Benefits

   MOQT relays can implement intelligent caching strategies optimized
   for A2A communication patterns.

   The most frequently accessed and time-sensitive data with time-to-
   live values are measured in seconds.  This includes real-time agent
   responses, live data streams, and status updates that require
   immediate availability.  These messages are kept in high-speed memory
   to ensure minimal latency for active agent interactions.

   Another layer can serve as an intermediate storage tier with time-to-
   live values measured in minutes.  This layer contains agent
   capability profiles, metadata about agent configurations, and results
   from common queries that are accessed regularly.  The caching layer
   can provide a balance between accessibility and resource utilization.

   Also for archives of historical data with extended retention periods
   measured in hours or days, can employ a different storage strategy.
   Examples data might include historical logs, archived computation
   results, compliance audit data, and debug traces that may be needed
   for analysis or regulatory purposes but are accessed infrequently.

7.  References

7.1.  Normative References

   [A2A]      A2A Project, "Agent-to-Agent Protocol Specification",
              2025, <https://a2a-protocol.org/latest/specification/>.

   [MoQ-TRANSPORT]
              Nandakumar, S., Vasiliev, V., Swett, I., and A. Frindell,
              "Media over QUIC Transport", Work in Progress, Internet-
              Draft, draft-ietf-moq-transport-14, 2 September 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-moq-
              transport-14>.

   [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>.




Nandakumar & Jennings     Expires 20 April 2026                [Page 11]

Internet-Draft                A2A over MOQT                 October 2025


   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

   [RFC9000]  Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
              Multiplexed and Secure Transport", RFC 9000,
              DOI 10.17487/RFC9000, May 2021,
              <https://www.rfc-editor.org/info/rfc9000>.

7.2.  Informative References

   [RFC7540]  Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
              Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
              DOI 10.17487/RFC7540, May 2015,
              <https://www.rfc-editor.org/info/rfc7540>.

   [WebTransport]
              Vasiliev, V., "The WebTransport Protocol Framework",
              RFC 9297, August 2023,
              <https://www.rfc-editor.org/rfc/rfc9297>.

Appendix A.  Acknowledgments

Authors' Addresses

   Suhas Nandakumar
   Cisco
   Email: snandaku@cisco.com


   Cullen Jennings
   Cisco Systems
   Email: fluffy@cisco.com


















Nandakumar & Jennings     Expires 20 April 2026                [Page 12]


name: draft-ietf-sml-trust
rev: 00
title: Trust and security considerations for Structured Email
time: 2025-10-20T21:12:29Z
group_uri: /api/v1/group/group/2380/
expires: 2026-04-23T21:12:29Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/", "/api/v1/doc/state/38/"]
categories: ["Data formats/interop", "AI safety/alignment"]
tags: []
fetched_at: 2026-02-27T22:56:05.127740+00:00
abstract:
This document discusses trust and security considerations for
   structured email and provides recommendations for message user agents
   on how to deal with structured data in email messages.

Discussion Venues

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

   Discussion of this document takes place on the Structured Email
   Working Group mailing list (sml@ietf.org), which is archived at
   https://mailarchive.ietf.org/arch/browse/sml/.

   Source for this draft and an issue tracker can be found at
   https://github.com/arnt/sml-trust.

full_text:
sml                                                         H.-J. Happel
Internet-Draft                                                   audriga
Intended status: Standards Track                          A. Gulbrandsen
Expires: 23 April 2026                                             ICANN
                                                         20 October 2025


         Trust and security considerations for Structured Email
                        draft-ietf-sml-trust-00

Abstract

   This document discusses trust and security considerations for
   structured email and provides recommendations for message user agents
   on how to deal with structured data in email messages.

Discussion Venues

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

   Discussion of this document takes place on the Structured Email
   Working Group mailing list (sml@ietf.org), which is archived at
   https://mailarchive.ietf.org/arch/browse/sml/.

   Source for this draft and an issue tracker can be found at
   https://github.com/arnt/sml-trust.

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 23 April 2026.

Copyright Notice

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



Happel & Gulbrandsen      Expires 23 April 2026                 [Page 1]

Internet-Draft                  SML Trust                   October 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.  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.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
   3.  Types of security concerns  . . . . . . . . . . . . . . . . .   3
     3.1.  Spam/virus filters  . . . . . . . . . . . . . . . . . . .   3
     3.2.  Formal display of data  . . . . . . . . . . . . . . . . .   3
     3.3.  Automated processing  . . . . . . . . . . . . . . . . . .   4
     3.4.  External references . . . . . . . . . . . . . . . . . . .   4
     3.5.  Social engineering  . . . . . . . . . . . . . . . . . . .   4
   4.  Trust mechanisms  . . . . . . . . . . . . . . . . . . . . . .   5
     4.1.  Processing structured data  . . . . . . . . . . . . . . .   5
     4.2.  Inlining data . . . . . . . . . . . . . . . . . . . . . .   6
   5.  Security considerations . . . . . . . . . . . . . . . . . . .   6
   6.  Privacy considerations  . . . . . . . . . . . . . . . . . . .   6
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .   7
   Appendix B.  Note to self . . . . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   Structured email, as described in [I-D.sml-structured-email], makes
   the content of some email messages machine-readable, such that user
   agents can provide higher-level functions than displaying/replying,
   for example "add this to calendar".

   Naturally, new functions bring new trust and security considerations,
   or bring new urgency to existing issues.  This document recommends
   security and trust mechanisms that should be applied when processing
   machine-readable content in email messages, both by senders and
   receivers.







Happel & Gulbrandsen      Expires 23 April 2026                 [Page 2]

Internet-Draft                  SML Trust                   October 2025


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.

3.  Types of security concerns

   This section gives an overview of the various types of security and
   privacy concerns that arise when email messages contain structured
   data.  The same concerns often arise for other messages, of course.

   This section is informative.  Or even unnecessary.

3.1.  Spam/virus filters

   Structured email increases the syntactical and semantic complexity of
   email messages.  If a spam/virus filter parses structured email in
   order to block malevolent messages, the filter's parser will
   necessarily differ from that of the MUA that will finally act on the
   structured data, creating a risk of misclassification.

   These risks are elevated when a structured data format has complex
   syntax, syntax that offers several optional or alternative ways to
   express the same substance, and of course by parsers that deviate
   from the specification for better bug compatibiloty.

3.2.  Formal display of data

   A common example is displaying a received calendar invitation using
   dates/times in the recipient's timezone, in a fixed format.

   Formal display introduces additional possibilities of discrepancy
   between the different representations.  For example, a single message
   might contains a multipart/alternative containing a text/plain
   description of a flight itinerary, a text/html description of the
   same itinerary, and a structured representation.  All three may be
   different, leading to confusion (and in this example, perhaps to
   missing a flight).

   Unintentional discrepancy is a risk for senders; some recipients may
   be misinformed.

   If a message is sent to a group and there is a discrepancy, different
   members of the group may see it differently.




Happel & Gulbrandsen      Expires 23 April 2026                 [Page 3]

Internet-Draft                  SML Trust                   October 2025


   If a particular MUA displays the formal representation within the
   message, a malevolent sender could try to mimic the visual
   representation using HTML with CSS, but with misleading content.

3.3.  Automated processing

   Automated processing covers actions that are taken as soon as the
   message arrives rather than when a human user reads the message.  For
   example, a user might want flight reservations to be automatically
   added to a travel itinerary application and/or a calendar.

   Such automation could be a custom MUA feature or a future extension
   of the Sieve email filtering language ([RFC5228]).  A related example
   for abuse in automated processing is calendar spam ([CalSpam]).

3.4.  External references

   Email messages with a text/html body part ("HTML email messages") may
   contain image resources that link to web servers.  Such links can be
   used for tracking user interaction with the message.

   Similar concerns apply to structured data types which include image
   references, such as the cover image of a music album or the teaser
   image of a news article.

   RDF structured data can be partial by design and include references
   to additional data.  Using a "follow your nose" approach, tools can
   follow URL references to obtain further structured data concerning a
   resource.  For example, a piece of structured data about an article
   could reference the article's authors only by URL.  For a meaningful
   processing of author information, one might try to obtain further
   data using that URL.

3.5.  Social engineering

   While the risks of social engineering are hardly new and the human-
   readable text in a message can in principle be used to persuade the
   human reader to do anything, structured data widens the variety of
   actions the human reader can easily perform.  If there are more
   buttons to click, then there's also a greater variety of attacks.

   Put differently: A user who might not be able to follow the
   instructions in a long and involved text-based social engineering
   attack may be able to follow simple instructions such as "click this
   then that".






Happel & Gulbrandsen      Expires 23 April 2026                 [Page 4]

Internet-Draft                  SML Trust                   October 2025


4.  Trust mechanisms

   Several implementations of structured email restrict processing to
   messages that are particularly trusted.  That is to say, an incoming
   message is in one of these three categories:

   1.  Spam.  Structured data is not processed.

   2.  Ordinary.  Structured data is not processed.

   3.  Trusted.  Structured data is processed.

   This section gives an overview of the trust mechanisms used to
   differentiate between 2 and 3.

   It does not attempt to describe whether a trust-based mechanism is
   appopriate in a particular case.

4.1.  Processing structured data

   MUAs SHOULD consider structured data in incoming email messages only
   if either of these criteria hold:

   *  The sender is trusted (e.g., part of the user's address book) and
      the messsage either contains a valid personal or domain signature.

   *  The message is part of an ongoing thread with a trusted sender.

   *  The message's content indicate a connection with an older, trusted
      message.  For example, if a calendar invitation was accepted, then
      updates or responses for the same event are connected with the
      original.

   If none of these criteria is fulfilled, MUAs should fall back to
   alternative presentations, typically "text/html".

   Open issue 1: It's not clear that all types of structured data
   require checking.  Some may be 100% display-only.  Is additional
   guidance for display-only data worth the complexity?

   Open issue 2: Really SHOULD?  I (Arnt) don't see this guidance as
   clearly right.  It doesn't match existing code all that well, and
   doesn't seem to be where we want to go.

   Open issue 3: This does not distinguish between - automatic
   processing - actions available to a user in e.g. a MUA - formal
   display




Happel & Gulbrandsen      Expires 23 April 2026                 [Page 5]

Internet-Draft                  SML Trust                   October 2025


4.2.  Inlining data

   Structured data included in an email message SHOULD be self-contained
   in order to avoid privacy problems.  This implies that if an MUA is
   able to provide meaningful user interaction (rather than mere
   display), then the data SHOULD be self-contained, such that the
   interaction will not need referenced resources from the web.

5.  Security considerations

   Security considerations are a core subject of this document.

6.  Privacy considerations

   Privacy considerations are a core subject of this document.

7.  IANA Considerations

   This document has no IANA actions at this time.

8.  References

8.1.  Normative References

   [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/rfc/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/rfc/rfc8174>.

8.2.  Informative References

   [I-D.sml-structured-email]
              "*** BROKEN REFERENCE ***".

   [RFC5228]  Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email
              Filtering Language", RFC 5228, DOI 10.17487/RFC5228,
              January 2008, <https://www.rfc-editor.org/rfc/rfc5228>.

   [RFC6132]  George, R. and B. Leiba, "Sieve Notification Using
              Presence Information", RFC 6132, DOI 10.17487/RFC6132,
              July 2011, <https://www.rfc-editor.org/rfc/rfc6132>.






Happel & Gulbrandsen      Expires 23 April 2026                 [Page 6]

Internet-Draft                  SML Trust                   October 2025


   [RFC6134]  Melnikov, A. and B. Leiba, "Sieve Extension: Externally
              Stored Lists", RFC 6134, DOI 10.17487/RFC6134, July 2011,
              <https://www.rfc-editor.org/rfc/rfc6134>.

   [RFC7942]  Sheffer, Y. and A. Farrel, "Improving Awareness of Running
              Code: The Implementation Status Section", BCP 205,
              RFC 7942, DOI 10.17487/RFC7942, July 2016,
              <https://www.rfc-editor.org/rfc/rfc7942>.

   [CalSpam]  "Calendar operator practices — Guidelines to protect
              against calendar abuse", n.d.,
              <https://standards.calconnect.org/csd/cc-18003.html>.

   [MachineReadable]
              "NIST IR 7511 Rev 4", n.d.,
              <https://csrc.nist.gov/glossary/term/Machine_Readable>.

Appendix A.  Acknowledgements

   The authors wish to thank Ben Bucksch, Alexey Melnikov, Phillip Tao,
   Lisa Dusseault and others whose suggestions were made before this
   paragraph was started.

Appendix B.  Note to self

   RFC Editor: Please remove this section.

   The charter has this to say about what this document should contain:
   "Recommendations for security and trust mechanisms that should be
   applied when processing machine-readable content in email messages"
   and "security and trust recommendations to prevent abuse of
   structured email".  No more, no less.

Authors' Addresses

   Hans-Joerg Happel
   audriga
   Email: happel@audriga.com
   URI:   https://www.audriga.com


   Arnt Gulbrandsen
   ICANN
   6 Rond Point Schumann, Bd. 1
   1040 Brussels
   Belgium
   Email: arnt@gulbrandsen.priv.no
   URI:   https://icann.org/ua



Happel & Gulbrandsen      Expires 23 April 2026                 [Page 7]


name: draft-zhang-rvp-problem-statement
rev: 00
time: 2025-10-21T18:40:56Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-24T18:40:56Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["A2A protocols", "Agent identity/auth", "Autonomous netops"]
tags: []
fetched_at: 2026-02-27T22:56:05.127748+00:00
title:
Problem Statements and Requirements of Real-Virtual Agent Protocol (RVP): Communication Protocol for Embodied Intelligence in Physical- Digital Continuum

abstract:
The Real-Virtual Agent Protocol (RVP) enables seamless coordination
  between physical entities (robots, IoT devices, manufacturing
  systems and agents) and digital agents (AI systems, software agents,
  virtual twins) through unified composite identity management,
  physical/social/production relations graph-based coordination, and
  physical constraint integration. Unlike existing protocols that
  assume peer-to-peer digital relationships (A2A for agents, MCP for
  AI tools, ANP for agent networks), RVP unifies physical and digital
  agents communication and achieves physical data loop for online
  learning for embodied agents considering both hierarchical
  physical/social/production relations and physical world constraints.
  RVP is designed for immediate deployment in modern manufacturing,
  smart cities, autonomous mobility systems, and human-AI
  collaborative environments where non-peer, partially centralized
  relations and coordination is essential for real-world embodied
  intelligence networks.

full_text:
Workgroup:Network Working Group                                     X.Zhang
Internet-Draft:                                                    Hicagent
draft-zhang-rvp-problem-statement-00                                Y.Zhang
Published:20 October 2025                                           C.Zhang
Intended status: Informational                                      M.Zhang
Expires:20 April 2026                                         China Telecom
                                                                       W.Lu
                                                                     SUPCON




    Problem Statements and Requirements of Real-Virtual Agent Protocol
   (RVP): Communication Protocol for Embodied Intelligence in Physical-
                            Digital Continuum





    Status of this Memo

  This Internet-Draft is submitted in full conformance with the
  provisions of BCP 78 and BCP 79. This document may not be modified,
  and derivative works of it may not be created, except to publish it
  as an RFC and to translate it into languages other than English.

  This document may contain material from IETF Documents or IETF
  Contributions published or made publicly available before November
  10, 2008. The person(s) controlling the copyright in some of this
  material may not have granted the IETF Trust the right to allow
  modifications of such material outside the IETF Standards Process.
  Without obtaining an adequate license from the person(s) controlling
  the copyright in such materials, this document may not be modified
  outside the IETF Standards Process, and derivative works of it may
  not be created outside the IETF Standards Process, except to format
  it for publication as an RFC or to translate it into languages other
  than English.

  Internet-Drafts are working documents of the Internet Engineering
  Task Force (IETF), its areas, and its working groups.  Note that
  other groups may also distribute working documents as Internet-
  Drafts.

  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."



    Zhang                  Expires 20,April,2026                 [Page 1]

    Internet-Draft          RVP Problem Statement             October 2025


  The list of current Internet-Drafts can be accessed at
  http://www.ietf.org/ietf/1id-abstracts.txt

  The list of Internet-Draft Shadow Directories can be accessed at
  http://www.ietf.org/shadow.html

  This Internet-Draft will expire on April 20, 2026.

    Copyright Notice

  Copyright (c) 2025 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
  (http://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 Simplified BSD License text as described in
  Section 4.e of the Trust Legal Provisions and are provided without
  warranty as described in the Simplified BSD License.

Abstract

  The Real-Virtual Agent Protocol (RVP) enables seamless coordination
  between physical entities (robots, IoT devices, manufacturing
  systems and agents) and digital agents (AI systems, software agents,
  virtual twins) through unified composite identity management,
  physical/social/production relations graph-based coordination, and
  physical constraint integration. Unlike existing protocols that
  assume peer-to-peer digital relationships (A2A for agents, MCP for
  AI tools, ANP for agent networks), RVP unifies physical and digital
  agents communication and achieves physical data loop for online
  learning for embodied agents considering both hierarchical
  physical/social/production relations and physical world constraints.
  RVP is designed for immediate deployment in modern manufacturing,
  smart cities, autonomous mobility systems, and human-AI
  collaborative environments where non-peer, partially centralized
  relations and coordination is essential for real-world embodied
  intelligence networks.








    zhang                  Expires 20,April,2026                 [Page 2]

    Internet-Draft          RVP Problem Statement             October 2025


    Table of Contents


1. Introduction...........  .....................................  ...3
    1.1. Background and Current Status of Existing Protocols....   ...3
    1.2. Why RVP is Necessary....................................   ..6
2. Terminology...  ...............................................  ..7
3. Problem Statement...  ..........................................  .8
     3.1. Identity Fragmentation Across Domains....................  .8
     3.2. Lack of Physical/Social Relations Mapping among agents...  .8
     3.3. Lack of Physical Constraint Reflection..................  .10
     3.4. Lack of Efficient Registration and Effective Discovery       
     Mechanisms for Agents........................................ . 10
     3.5. Lack of Real-time Data Input to the Embodied Large Model for 
     Training.....................................................  .10
4. Protocol Requirements Discussion and Design Principles...  ....  .11
     4.1. Design Principles..................................... . ..11
     4.2. Requirements Discussion................................  ..12
     4.3. Protocol Integration Strategy..........................  ..15
5. RVP Use Cases......  ..........................................  .17
     5.1. Flexible Production Line Coordination in Manufacturing..  .17
     5.2. Disaster Rescue Human-Robot Collaborative Environments..  .18
     5.3. Autonomous Driving Systems in Smart City................  .18
        5.3.1. Multi-Vehicles(Agents) Collaborative Delivery..... .. 18
        5.3.2. Vehicle-to-Everything (V2X) Intersection Management.  19
6. Security Considerations........................................  .19
     6.1. Identity Verification and Authorization....................19
     6.2. Communication Security.....................................19
     6.3. Safety System Protection...................................20
     6.4. Audit and Monitoring.......................................20
     6.5. Isolation Capabilities.....................................21
7. IANA Considerations............................................  .21
8. References.....................................................  .21
     8.1. Normative References.......................................21
     8.2. Informative References.....................................21
9. Acknowledgments................................................  .22


1. Introduction
1.1. Background and Current Status of Existing Protocols

  The convergence of artificial intelligence, robotics, and ubiquitous
  computing is creating unprecedented demand for connectivity and
  coordination between physical systems and digital intelligence.
  However, existing protocols are insufficient to effectively meet
  these demands, facing severe challenges in cross-entity
  collaboration, cross-level management, and cross-architecture


    zhang                  Expires 20,April,2026                 [Page 3]

    Internet-Draft          RVP Problem Statement             October 2025


  communication, primarily manifested in problems such as identity
  fragmentation, protocol incompatibility, and missing physical
  constraint reflection mechanisms.

  With the rapid development of Large Language Models (LLMs), LLM-
  based agents have become very popular in many industries and
  scenarios. Agent and model protocols are gaining widespread
  attention from both industry and academia. Meanwhile physical
  agents(e.g., emobodied robots, autonomous driving cars, UAVs)
  embedded in physical entities are playing a crucial role in modern
  manufacturing[SMART-FACTORY], smart cities[AI-CITY], autonomous
  mobility systems[APPOLO], and human-AI collaborative
  environments[Human-Robot]. The interaction between hetergenous
  physcial agents and digital agents as well as models bridges the
  physical world and digital world into a seamless continuum. Real-
  Virtual Agent Protocol (RVP) is a communication protocol designed
  for reality-virtuality symbiotic, supporting non-peer-to-peer, and
  partially centralized embodied intelligence agent networks. It
  focuses on mapping on physical/social/production relations graphs
  and physical constraint reflection between agents.

  Today's agent communication protocols are designed for homogeneous
  environments. Mainstream agent communication protocols include
  A2A[A2A-SPEC], MCP[MCP-SPEC], ANP[ANP-SPEC], etc.:

  Agent-to-Agent (A2A) Communication Protocol: Supports digital agent
  communication but assumes all participants are software entities
  operating in digital environments in peer-to-peer communication,
  hardly to handle non-peer relationships in physical world, and lacks
  of physical/social/production relations constraints. In practical
  applications, it has fundamental limitations for physical-digital
  coordination, including:

  1) Communication Model Mismatch: A2A protocol uses asynchronous
  message transmission optimized for digital agents that can pause,
  queue, and process messages at variable speeds. Physical systems
  require real-time coordination with hard deadlines-a robot cannot
  "pause" mid-motion to wait for queued messages.

  2) No Physical Constraint Modeling: A2A protocol has no standard way
  to represent physical constraints (workspace boundaries, inertia,
  safety requirements). When a digital agent requests a robot to "move
  to position X immediately," the protocol cannot express that the
  robot needs 3.2 seconds due to physical acceleration limits.





    zhang                  Expires 20,April,2026                 [Page 4]

    Internet-Draft          RVP Problem Statement             October 2025


  3) Safety Integration Gap: A2A protocol has no built-in safety
  mechanisms. There is no standard way to represent that certain agent
  communications could cause physical harm if mishandled.

  MCP: Provides AI systems with tool access but treats physical
  systems as external, and sometimes stateless tools rather than
  intelligent twin participants. It focuses on model context
  management, concentrating on context interaction between agents and
  tools (such as user preferences, environmental states, session and
  task information, etc.). The problems raised by physcial systems
  include:

  1)Stateless Tool Model: MCP treats all tools as stateless functions.
     Physical systems are inherently stateful, i.e., a robot's current
     position affects what next operations are possible. MCP is hard to
     represent that the same tool call may succeed or fail based on
     physical context.

  2)Bidirectional Coordination: MCP is bascially request-response model.
     Physical systems need to provide continuous feedback (sensor data,
     status updates, emergency conditions) that should influence AI
     decision-making in real-time.

  3) MCP basically assumes one single AI system/agent accessing tools,
     which does not involve complex collaboration relationships between
     agents. Physical agents often need to coordinate between multiple
     AI systems (planning AI, safety monitoring AI, quality control AI)
     simultaneously. Moreover, real-time interaction and
     synchronization (e.g., ms magnitude) between physical and digital
     agents is hard to achieve.


  Agent Network Protocol (ANP): Organizes agent networks in multi-
  agent scenarios with peer-to-peer entities, building the underlying
  architecture of the agent internet, known as the "HTTP of P2P
  networks" and supporting decentralized decision-making. It supports
  decentralized discovery but identity management is based on DID,
  unable to handle 1-to-N topology relations from the physical entity
  to virtual entities (for examaple, an automonous driving car
  involves a physcial entitiy and several virtual assistant entities
  to do route optimization and simulation, operate the on-car
  electronic systems and search for the weather forecast,etc.)and
  virtual entity cluster discovery requires multiple queries with low
  efficiency. Its constraints are similar to the A2A communication
  protocol and will not be elaborated further.


    zhang                  Expires 20,April,2026                 [Page 5]

    Internet-Draft          RVP Problem Statement             October 2025


  Additionally, regarding connecting physical and digital entities,
  existing underlying transport protocols have the following issues:

  IoT Protocols (MQTT, CoAP[RFC7252], HTTP) handle device connectivity
  and data exchange but lack semantic understanding of physical-
  digital integration requirements.

  IoT protocols like MQTT and CoAP handle device connectivity but
  cannot support intelligent coordination:

  1) No Coordination Semantics: IoT protocols transport data but have
  no understanding of coordination requirements. Publishing sensor
  data to a topic provides no information about what coordination
  actions are appropriate.

  2) No Identity Coherence: IoT protocols identify devices by topics
  or endpoints but cannot represent that multiple endpoints refer to
  the same logical entity. A robot's position sensor, control
  interface, and status feed are separate MQTT topics with no
  protocol-level connection.

  3) No Intelligence Integration: IoT protocols have no standard way
  to integrate with AI systems beyond basic pub/sub. There is no
  protocol support for AI systems to understand device capabilities or
  coordinate intelligent actions.

  RVP is implemented similarly to existing protocols (such as MCP, A2A,
  ANP) through further encapsulation or modification of underlying
  transport protocols (such as SSE, WebSocket, MQTT) or even direct
  modification of A2A, MCP and ANP.

1.2. Why RVP is Necessary

  Existing protocols (A2A, MCP, IoT protocols) have fundamental
  limitations in handling unified coordination of physical entities
  and digital entities. Although A2A protocols could theoretically be
  extended to handle physical entities, this would require fundamental
  changes to agent communication semantics to handle physical
  constraints [A2A-FIPA][CPS-DESIGN]and complete redesign of unified
  identity management across domains. Enhancing MCP to effectively
  handle physical and digital agent coordination would require new
  design principles to design stateful coordination and real-time
  communication among different kinds of agents, which is common in
  real world. It's hard to imagine to convert all physical systems
  into stateless tools, thereby losing their needs of intelligent
  coordination. Adding intelligence to IoT protocols would require
  fundamental semantic changes incompatible with existing IoT


    zhang                  Expires 20,April,2026                 [Page 6]

    Internet-Draft          RVP Problem Statement             October 2025


  deployments, still lacking unified identity management and limited
  to device-level rather than system-level coordination.

  Future multi-agent architectures will evolve into hierarchical
  (MCP's C/S architecture can satisfy), distributed (ANP's P2P
  architecture can satisfy), and hybrid frameworks, enabling flexible
  and diverse ways to coordinate large numbers of agents to complete
  various complex tasks under different business scenarios. However,
  the existing architectures cannot fully meet the communication needs
  of reality-virtuality integrated embodied intelligence agent
  networks. For example, one-to-many real-virtual mapping requires
  simultaneous identity authentication of multiple virtual entities
  and simultaneous registration and discovery of these agents.
  Communication between real-virtual agents also requires following
  constraints and rules of production relations graphs in the physical
  world. What's more, the data starvation for model training requires
  real-time physical data input to achieve data-loop for online
  training in embodied intelligence.

  Therefore, RVP is needed that can treat physical and digital as
  expressions of unified entities and create efficient communication
  based on these expressions. Instead of replacing existing protocols,
  the new protocol is designed to integrate with them:

  1) Integration with Existing Protocols: Through adapters or
  middleware layers, enabling the new protocol to work collaboratively
  with existing protocols such as A2A, MCP, IoT, etc.

  2) Introducing New Mechanisms: Particularly physical constraint
  reflection, unified identity management, physical/social/production
  relations graphs, etc. Based on this, a heterogeneous communication
  protocol for reality-virtuality integrated embodied intelligence
  agents is proposed.

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 [RFC2119].

  Composite Agent: A Composite Agent is a super-agent to interact with
  the external physical world on behalf of its associated Real-entity
  Agent, and Virtual-entity Agent. While adhering to the principle of
  permission isolation, it realizes effective utilization and
  comprehensive fusion of information related to both worlds. By
  abstractly layering the capabilities of individual entities in the
  physical world, it achieves efficient coordination from value


    zhang                  Expires 20,April,2026                 [Page 7]

    Internet-Draft          RVP Problem Statement             October 2025


  decision-making to task execution. Composite Agent aims to
  characterize human/unmaned behavior patterns in complex environments,
  ensuring efficiency, flexibility, and stability of task processing.

  Physical Expression: The concrete instance of an object in the
  physical domain, carrying the existence form and interaction
  capabilities of the object in the physical world.

  Digital Expression: The virtualized instance of an object in the
  digital domain, carrying the logical representation and
  computational capabilities of the object in digital space.

  Real-Virtual Agent Protocol (RVP): A standardized communication
  protocol specifically designed for composite agent architecture,
  regulating interactions and coordination among physical and digital
  agents.

  Physical/Social/Production Relations Graph: A semantic network-based
  directed graph describing organizational relationships, business
  processes, and permission constraints among agents.

  Physical Constraint: Standardized description of timing, spatial,
  dynamic, and safety constraints in the physical world, supporting
  automatic verification and real-time reflection.

3. Problem Statement

3.1. Identity Fragmentation Across Domains

  Currently, in above mainstream communication protocols, no protocol
  provides unified identity management across physical and digital
  domains. Each protocol treats the same entity as a separate,
  unrelated object. The same logical entity exists as disconnected
  representations in different systems. These representations are
  manually coordinated through custom integration code, leading to
  consistency problems and coordination failures.

  Without unified identity management, the same entity has multiple
  un-associated identity representations in different systems, leading
  to low registration efficiency, data inconsistency, and coordination
  failures. Identity information needs to be manually synchronized,
  increasing system complexity and maintenance costs.

3.2. Lack of Physical/Social Relations Mapping among agents

  Current mainstream agent protocols (MCP/A2A/ANP) are built on a
  digital-native worldview, ignoring the inherent non-peer nature,


    zhang                  Expires 20,April,2026                 [Page 8]

    Internet-Draft          RVP Problem Statement             October 2025


  hierarchical structures, and business constraints of agents in the
  physical world. In existing agent systems, interactions between
  agents are often based on simple peer-to-peer or client-server
  models, lacking mapping of complex production relationships in the
  real world.

  In real world, an agent may represent the individual person's social
  roles in different scenarios, such as father, employee, friend, etc.;
  it can also represent actual existence in the physical world, such
  as robots, sensors, actuators, and other hardware devices.
  Collaboration in the real world is often non-peer, with hierarchical
  structures, division of labor, and permission constraints. For
  example, in intelligent manufacturing, there are levels such as
  scheduling centers, production line control, and robots; in smart
  cities, there are command centers, departments, and field devices.

  Therefore unlike in digital world, the hierarchical and network-
  based physical/social/production relations graph exists, which
  stores physical world data and capabilities related to specific
  roles.

  Due to the lack of explicit modeling and mapping of these
  relationships, it leads to:

    Difficult Permission Control: Access and operation permissions
  between agents are not constrained based on
  physical/social/production relations, potentially causing
  unauthorized operations.

    Low Collaboration Efficiency: Agents cannot quickly identify
  collaboration partners, requiring complex negotiation and discovery
  mechanisms.

    Unreasonable Resource Allocation: Due to the lack of relations-
  based scheduling, resource allocation may not conform to actual
  business logic, leading to resource waste or bottlenecks.

    Poor System Maintainability: When business relations change,
  manual adjustments to connections and permissions between agents are
  needed, which is error-prone.

  Therefore, we need to introduce a "Phycial/Social/Production
  Relations Graph" in the protocol to explicitly describe these
  relations among agents and implement permission control,
  collaboration scheduling, and resource allocation based on this
  graph.



    zhang                  Expires 20,April,2026                 [Page 9]

    Internet-Draft          RVP Problem Statement             October 2025


3.3. Lack of Physical Constraint Reflection

  The current agent protocol ecosystem has a fundamental cognitive
  disconnect: intelligent protocols like A2A and MCP can understand
  intelligent coordination but lack physical perception. In a research
  [STI-BENCH] it pointed out While LLMs have been extensively studied
  for visual semantic understanding tasks, their ability to perform
  precise and quantitative spatial-temporal understanding in real-
  world applications is rather week, with top-performing models like
  Gemini-2.5-Pro achieving around 41.4% average accuracy.

  IoT protocols can understand physical devices but lack intelligent
  cognition. This causes agent decisions in the digital world to be
  seriously disconnected from physical world reality rules.

  Physical and digital spaces need to establish a standardized
  description framework for physical constraints to implement real-
  time reflection mechanisms for constraint states, ensuring
  consistency between digital decisions and physical reality.

3.4. Lack of Efficient Registration and Effective Discovery Mechanisms
   for Agents

  Existing protocols (such as MCP, A2A, ANP) have deficiencies in
  registration and discovery, resulting in agents requiring manual
  configuration and inability to dynamically adapt to network changes.
  Due to the lack of unified, adaptive, semantic registration and
  discovery mechanisms, agent networks become information silos,
  unable to achieve true "plug-and-play" and "dynamic collaboration."
  A unified registration and discovery mechanism needs to be designed
  to support dynamic joining and exiting of agents and automatic
  updating of network topology.

3.5. Lack of Real-time Data Input to the Embodied Large Model for
   Training

  Back to 2023, just after one year of ChatGPT's release, many studies
  warned that the world could run out of high-quality data to train AI
  soon. The research[DATA-RUNOUT] predicted that the training dataset
  will run out between 2026 and 2032, or even earlier.

  This is even worse for embodied intelligence systems, which has less
  recored knowledge to learn. Online learning from real-time practice
  data attracts more and more attentions to solve this problem.
  Particularly, data automatically generated during agent task
  execution that is not directly explicitly recorded contains deep
  information about environmental dynamics, physical laws, task


    zhang                  Expires 20,April,2026                [Page 10]

    Internet-Draft          RVP Problem Statement             October 2025


  execution context, decision-making processes, and multi-modal
  interactions. For example, in sanitation scenarios, implicit data
  includes interactions between sanitation vehicles and the
  environment (such as the relationship between cleaning force and
  ground material), micro-adjustments during task execution (such as
  trajectory corrections when avoiding pedestrians), and correlations
  between equipment operating status and work effectiveness. These
  real-time data supplement is vital for training the embodied agents.
  Moreover it will help to solve the data-training-decision
  fragmentation at the same time, i.e., when training data is
  historical, static, and disconnected, while agents need to make
  immediate responses in dynamic, real-time, continuous environments.
  This fragmentation prevents models from continuously evolving in the
  real world.

  To the best of our knowledge, current protocols are not available to
  input real-time data for continuous training.

  To summary, there is an urgent need for unified communication
  protocol standards to effectively connect physical entities and
  digital agents.

4. Protocol Requirements Discussion and Design Principles

4.1. Design Principles

  Constraint Priority Principle: Physical constraints are not
  afterthought limitations but prerequisites for system design and
  operation.

    Perform physical feasibility verification before all decisions
  and executions

    Establish automatic propagation and consistency maintenance of
  constraints in task chains

    Deeply integrate safety constraints into coordination semantics

  Unified Semantics Principle: Establish a unified semantic framework
  across all protocols and domains, eliminating ambiguity in concept
  mapping.

    Ensure consistent interpretation of the same concepts across
  different protocols and domains

    Semantic interpretation considering current physical environment
  and business context


    zhang                  Expires 20,April,2026                [Page 11]

    Internet-Draft          RVP Problem Statement             October 2025


    Support runtime semantic adjustment and optimization

4.2. Requirements Discussion

  This section is intended to stimulate the open discussion for the
  RVP requirements, so that the design team can consolidate the
  requirements of the RVP protocol.

  RVP.REQ-1: Unified Entity Identity Management

  Addressing the identity fragmentation problem in existing protocol
  ecosystems, where the same entity has different identity marking
  systems in physical, digital, and hybrid domains, leading to
  semantic inconsistency, life cycle disconnection, and accumulated
  security risks. The protocol MUST support unified entity
  registration, containing physical capabilities, digital intelligence,
  and hybrid manifestations within a single identity model.

  The requirements include:

    Support automatic association and verification of physical and
  digital identities

    Establish a globally unique entity identifier system

    Identity registration MUST contain complete composite identity
  description.

    Identity verification SHOULD support cross-domain identity
  consistency checks.

    Identity updates MUST ensure synchronization of identity
  information in all domains

  RVP.REQ-2: Dynamic Registration and Discovery Mechanisms

  Existing systems rely on manual configuration and hard-coded
  connections, unable to adapt to dynamic network topology changes,
  resulting in poor system scalability. The protocol MUST provide
  efficient agent registration and service discovery mechanisms.

  The requirements include:

    New nodes MUST be able to automatically discover the network and
  complete registration




    zhang                  Expires 20,April,2026                [Page 12]

    Internet-Draft          RVP Problem Statement             October 2025


    Node capability changes MUST be updated to the registry in real-
  time

    Provide real-time node health status monitoring

    Support external interface for natural language semantic service
  discovery

    Service discovery MUST consider current context and environmental
  state

    Provide intelligent service selection based on multi-dimensional
  matching

  RVP.REQ-3: Physical/Social/Production Relations Graph Management

  Existing protocols lack of expressive capability for real-world
  organizational structures, unable to express business relations such
  as command, collaboration, and affiliation, resulting in low
  coordination efficiency and coarse-grained permission control. The
  protocol MUST provide standard mechanisms to define, maintain, and
  query organizational structures among entities based on production
  relationships.

  The Graph Model Requirements include:

    Define standardized physcial/social/production relations
  classifications

    Support runtime creation, update, and deletion of relations

    Implement automatic derivation of permissions based on relations
  graphs

  The Operational Requirements include:

    Node registration MUST automatically derive initial
  physical/social/production relations

    Relations changes SHOULD trigger impact analysis and system
  adjustments

    Routing decisions MUST consider physical/social/production
  relations constraints

  RVP.REQ-4: Physical Constraint Integration



    zhang                  Expires 20,April,2026                [Page 13]

    Internet-Draft          RVP Problem Statement             October 2025


  Existing protocols lack systematic description and verification
  mechanisms for timing, spatial, dynamic, and other constraints,
  causing digital decisions to be disconnected from physical reality.
  The protocol MUST provide standard mechanisms to represent and
  enforce physical constraints in coordination decisions.

  The requirements include:

    Define machine-readable physical constraint description format,
  forming a standardized constraint language

    Establish complete constraint classification

    Constraint description MUST support automatic verification

    Decision verification MUST perform physical constraint checks
  before execution

    Constraint violations SHOULD trigger standardized emergency
  responses

    Constraint propagation MUST maintain consistency during task
  decomposition

  RVP.REQ-5: Safety-Aware Coordination Semantics

  Safety mechanisms considerations are required to be added as built-
  in features to meet real-time requirements. The protocol MUST
  integrate physical safety constraints, timing requirements, and
  emergency response mechanisms into coordination communications.

  The requirements include:

    Built-in safety semantics, with safety constraints as core
  components of coordination semantics

    Safety decisions consider physical state and business context

    Operation execution SHOULD perform real-time safety boundary
  checks

    Emergency response MUST be automatically triggered when safety
  threats are detected

  RVP.REQ-6: Real-time Data Sharing




    zhang                  Expires 20,April,2026                [Page 14]

    Internet-Draft          RVP Problem Statement             October 2025


  Real-time data sharing involve injecting real-time data of the
  physical agents into models and sharing direct and local sense,
  observation or other kind of data between agents.

  The requirements include:

       Extremely Low latency reliable data transmission

       Streamed training data provision to training procedure

       Training and reasoning mode switch dynamically

       Model update and versioned distribution

       Standard gradient/parameter aggregation interface

       Direct sense and information sharing between agents

4.3. Protocol Integration Strategy

  RVP is designed as a meta-protocol that does not replace existing
  protocols (such as A2A, MCP, IoT protocols) but inherits, extends,
  or enhances them, providing core capabilities such as unified entity
  identity, physical/social/production relations graphs, and physical
  constraint integration. A2A is the most suitable starting-point when
  designing RVP.

  A2A Protocol Enhancement: Introduce RVP's core concepts into the A2A
  protocol to support physical-digital unified coordination.

    Extend Agent Card: Add composite identity description, dynamic
  capability discovery, and physical/social/production relations graph
  information to A2A's Agent Card to support intelligent routing.

    Unified Identity Mapping: Extend agent identity in A2A to unified
  entity identity (including Real-entity agent and  Virtual-entity
  agent), achieving cross-domain identity consistency.

    Real-time Coordination Semantics: Define new message types and
  interaction patterns for time-sensitive operations, supporting
  deadlines and real-time guarantees.

    Physical Constraint Representation: Add physical constraint
  fields to A2A messages, allowing agents to consider physical
  limitations (such as location, capabilities, time, etc.) during
  negotiation.



    zhang                  Expires 20,April,2026                [Page 15]

    Internet-Draft          RVP Problem Statement             October 2025


    Safety-aware Communication: Integrate safety context into A2A
  communication, including permission verification based on production
  relationships and physical safety constraints.

  Besides A2P, MCP and IoT protocols can also integrate with RVP, but
  this is not mandatory in the 1st phase:

  MCP Integration Enhancement: Enable MCP to support stateful, real-
  time coordination of physical agents.

  Hardware Tool Extension: Extend MCP tools from predominantly
  software digital domain to hardware physical domain, supporting
  embodied intelligence agent communication for hardware device
  queries, instructions, and interactions.

    Stateful Tool Representation: Encapsulate physical agents as
  stateful MCP tools, allowing tools to maintain state (such as device
  status, task progress).

    Timing Constraint Specification: Add timing constraints (such as
  start time, deadline, execution duration, etc.) in MCP tool calls.

    Multi-AI Coordination Support: Through RVP's
  physical/social/production relations graph, coordinate multiple AI
  model operations on the same physical system.

  IoT Protocol Bridge: Seamlessly integrate IoT devices into the RVP
  ecosystem, achieving both semantics of device data and intelligent
  coordination of device capabilities.

    Semantic Mapping: Map device data (such as sensor readings) to
  coordination context (such as events, states) and attach physical
  constraints.

    Unified Entity Identity: Assign unified entity identity to each
  IoT device and associate it with the corresponding Real-entity
  agents.

    Device Capability Representation: Describe device capabilities as
  standardized services, including functions, constraints, and states.

    Message Delivery Guarantees: Provide reliability guarantees (such
  as at-least-once delivery, acknowledgment mechanisms) for
  coordination messages among IoT devices.





    zhang                  Expires 20,April,2026                [Page 16]

    Internet-Draft          RVP Problem Statement             October 2025


5. RVP Use Cases

  This section is not a to-do list for the protocol. To make RVP well
  understood, it provides several scenarios on how RVP could be used
  in practice.

5.1. Flexible Production Line Coordination in Manufacturing

  A flexible manufacturing line produces customized products with
  different kinds of agents among robots, CNC machines, AGVs
  (Automated Guided Vehicles), and quality inspection stations, along
  with their digital twins [DIGITAL-TWINS] agents.

  A robot arm Composite Agent is composed of the controller, Real-
  entity robot arm Agent and its digital twins (Virtual-entity Agent).
  When the composite robot arm agent is registered via RVP, the
  associated real-entity robot and virtual-entity agents are
  automatically registered as well, reducing the complexity of
  registration several times.

  The Physical/Social/Production Relations Graph with hierarchical
  structure is created and registered which may look like: Production
  Line Manager Work Cell Controller Individual Robots. Permission
  constraints ensure only authorized controllers can issue commands to
  specific robots.

  Physical Constraints are transferred via RVP with spatial
  constraints such as robot workspace boundaries, collision avoidance
  zones; temporal constraints such as task completion deadlines and
  synchronization requirements; and dynamic constraints such as
  Maximum acceleration, payload capacity, energy consumption, etc....

  When the order is received, the production line manager agent
  decomposes tasks based on Physical/Social/Production Relations Graph
  and message routing is based on the relations graph, supporting
  explicit routing paths and automatic path calculation. The tasks in
  associated agents are linked based on the relations graph
  constraints supporting synchronous and asynchronous communication.
  The real-entity agents execute the appointed tasks with real-time
  monitoring and the virtual-entity agents simulate execution
  feasibility with physical constraints. The physical verification
  ensures digital instructions comply with physical system limitations
  after the tasks are completed. Constraint violation triggers
  automatic redo. The feedback as well as the process data in
  different agents can be integrated to the owner for decision-making
  and model training. Problematic nodes request assistance via
  relations graph queries using RVP.


    zhang                  Expires 20,April,2026                [Page 17]

    Internet-Draft          RVP Problem Statement             October 2025


5.2. Disaster Rescue Human-Robot Collaborative Environments

  Consider a search and rescue operation with human rescuers, rescue
  robots, drones, and command center.

  Robots and humans form ad-hoc coordination network in
  infrastructure-degraded environment. Flexible social relations graph
  adapting to situation is created via RVP to establish command
  structure including incident commander, who provides overall
  coordination; team leaders who coordinate local resources and
  Individual robots/humans, who have autonomy for immediate safety
  decisions. The social relations graph will dynamically change to add
  emergency relations (e.g., fire truck and ambulance).

  The robot Composite Agents register their capabilities via RVP and
  the search area is decomposed based on the robot capabilities, human
  responsibility and environmental constraints to create several
  search teams(including humans and robots). The physical constraint
  is monitored for structural integrity or hazardous conditions. The
  virtual-entity agents simulate evacuation routes with physical
  constraint verification. Once the constraint violation is detected,
  the digital twin agent changes its simulation and automatic
  evacuation action is executed via the social relations graph.
  Dynamic re-planning and re-verification is executed as new
  constraints are discovered (e.g., aftershock occurs or blocked route)
  for the real and virtual agents. Real-time data from operation feeds
  embodied disaster response model.

5.3. Autonomous Driving Systems in Smart City

5.3.1. Multi-Vehicles(Agents) Collaborative Delivery

  The fleet of autonomous delivery robots and drones across urban
  environment with dynamic obstacle avoidance and resource sharing is
  a multi-agents coordination. Each delivery vehicle is a Composite
  Agent including: high-level mission planner, the physical vehicle
  with sensors/actuators and virtual-entity agent for route
  optimization and simulation. The production Relations graph is like:
  Fleet management center coordinating individual vehicles peer
  relations between vehicles for resource negotiation hierarchical
  override for emergency situations.

  The virtual-entity agent simulates route with physical feasibility
  check. The production relations graph queries nearby vehicles for
  resource sharing opportunities and coordination sessions are
  established. The real-entity agent executes with continuous
  constraint monitoring and trigger dynamic re-planning when when the


    zhang                  Expires 20,April,2026                [Page 18]

    Internet-Draft          RVP Problem Statement             October 2025


  constraint violates (e.g., unexpected obstacle, battery drain,
  etc...). The execution data (actual vs. predicted energy consumption,
  obstacle patterns) feeds the autonomous driving model via RVP.

 5.3.2. Vehicle-to-Everything (V2X) Intersection Management

  Consider an intelligent intersection with autonomous V2X vehicles,
  human-driven V2X vehicles, cyclists, and pedestrians without
  traditional traffic signals.

  Once the vehicle approaches intersection, it registers it vehicle
  capabilities (e.g., size, braking distance, speed range and V2X
  information) and discovers intersection controller via RVP. The
  intersection controller establishes coordination sessions based on
  the physical relations graph among the vehicles. The virtual-entity
  agents simulate safe crossing sequences with physical constraint
  verification where physical safety constraints are the primary
  protocol feature to be checked, not afterthought. The Safety
  constraints like minimum time gaps, line-of-sight requirements,
  pedestrian priority are checked. The V2X vehicle, cyclist,
  pedestrian with smartphone receive crossing permissions with timing
  constraints via RVP. Continuous safety monitoring is executed and
  constraint violations trigger RVP protocols usage.

6. Security Considerations

6.1. Identity Verification and Authorization

  Composite Identity Verification Not only verify digital identity but
  also verify physical identity, ensuring authenticity of unified
  identity.

    Digital Identity: OAuth 2.0 tokens, API keys

    Physical Identity: Device fingerprinting, TPM attestation, secure
  elements

    Composite Binding: Cryptographic binding between physical and
  digital credentials

  Multi-factor Authentication for critical operations, require multi-
  factor authentication, including physical tokens or biometrics
  tokens:

    Level 1 (routine operations): Single factor (token/certificate)

    Level 2 (sensitive operations): Two factors (token + OTP)


    zhang                  Expires 20,April,2026                [Page 19]

    Internet-Draft          RVP Problem Statement             October 2025


    Level 3 (critical operations): Three factors (certificate +
  biometric + physical token)

  Authorization Based on Relations Graph

   Utilize physical/social/production relations graph for dynamic
   permission calculation, considering relations type, path length,
   time validity, etc.

6.2. Communication Security

  End-to-End Encryption

  Use TLS 1.3 or higher for transport encryption, and apply
  application-layer end-to-end encryption for sensitive data.

  Message Integrity

  Use digital signatures to ensure message integrity and prevent
  tampering.

6.3. Safety System Protection

  Independent Safety Channels

  Physical safety systems (such as emergency stop) use communication
  channels independent of coordination protocols.

  Physical-Digital Boundary Protection

  Deploy safety gateways between physical and digital domains for
  protocol filtering and deep inspection.

  Gateway functions include:

    Message content inspection and validation

    Rate limiting and anomaly detection

    Whitelist-based operation filtering

    Constraint verification before physical execution

6.4. Audit and Monitoring

  Comprehensive Logging Record: Detailed logs of all coordination
  sessions, including message content, participants, timestamps, etc.


    zhang                  Expires 20,April,2026                [Page 20]

    Internet-Draft          RVP Problem Statement             October 2025


6.5. Isolation Capabilities

  Dynamic Isolation: Based on security events, dynamically isolate
  affected entities or coordination domains.

7. IANA Considerations

  This document requests IANA to establish new registries for RVP
  protocol parameters. More details are in further versions.

8. References

8.1. Normative References

  [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.

8.2. Informative References

  [A2A-SPEC] https://a2a-protocol.org/dev/specification/

  [A2A-FIPA] Foundation for Intelligent Physical Agents, "FIPA Agent
              Communication Language Specifications", 2002.

  [MCP-SPEC] Anthropic, "Model Context Protocol Specification", 2024.

  [ANP-SPEC] "Agent Network Protocol Technical White Paper",
              https://arxiv.org/pdf/2508.00007, 2025.

  [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
            Application Protocol (CoAP)", RFC 7252, June 2014.

  [SMART-FACTORY] https://www.globaltrademag.com/smart-factories-how-
                   technology-is-revolutionizing-manufacturing/.

  [AI-CITY] https://www.deloitte.com/content/dam/assets-
            shared/docs/industries/government-public-services/2025/ai-
            powered-cities-of-the-future.pdf.

  [APOLLO]  https://www.apollo.auto/en/apollo-self-driving.

  [Human-Robot] Dong, W., "Toward Embodied Intelligence-Enabled Human-
            Robot Symbiotic Manufacturing: A Large Language Model-
            Based Perspective",Journal of Computing and Information
            Science in Engineering, May 2025.




    zhang                  Expires 20,April,2026                [Page 21]

    Internet-Draft          RVP Problem Statement             October 2025


  [DIGITAL-TWINS] Grieves, M., "Digital Twin: Manufacturing Excellence
            through Virtual Factory Replication", Digital
            Manufacturing, 2014.

  [CPS-DESIGN] Lee, E., "Cyber Physical Systems: Design Challenges",
            University of California, Berkeley Technical Report, 2008.

  [STI-BENCH] Li, Y., "STI-Bench:Are MLLMs Ready for Precise Spatial-
            Temporal World Understanding?", ICCV 2025.

  [DATA-RUNOUT] Villalobos,P.,Will we run out of data? Limits of LLM
            scaling based on human-generated data,
            https://arxiv.org/pdf/2211.04325.



9. Acknowledgments

  The authors thank Dirk Dressler who provided valuable feedback
  during the development of this specification.




























    zhang                  Expires 20,April,2026                [Page 22]

    Internet-Draft          RVP Problem Statement             October 2025


    Authors' Addresses


  Xiaoxun Zhang
  Hicagent
  No.57 Boxia Road, Pudong Software Park,Shanghai, P.R.China
  zhangxiaoxun@hicagent.com

  Yunfei Zhang(Editor)
  China Telecom
  No.31 Jinrong Street, Xicheng District,Beijing, P.R.China
  Zhangyf80@chinatelecom.cn

  Chi Zhang
  China Telecom
  No.31 Jinrong Street, Xicheng District,Beijing, P.R.China
  Zhangc120@chinatelecom.cn

  Min Zhang
  China Telecom
  No.31 Jinrong Street, Xicheng District,Beijing, P.R.China
  Zhangmin3@chinatelecom.cn


  Weijun Lu
  SUPCON  TECHNOLOGY  CO., LTD.
  No.309 Liuhe Road, BinJiang District, Hangzhou,Zhejiang, P.R.China
  luwj@supcon.com




















    zhang                  Expires 20,April,2026                [Page 23]



name: draft-mao-rtgwg-apn-framework-for-ioa
rev: 00
title: APN Framework for Internet of Agent (IoA)
time: 2025-11-02T04:05:10Z
group_uri: /api/v1/group/group/1027/
expires: 2026-05-06T04:05:09Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["ML traffic mgmt", "A2A protocols", "Agent discovery/reg"]
tags: []
fetched_at: 2026-02-27T22:56:05.127752+00:00
abstract:
With the rapid development of large model technologies in the AI
   field, it has become possible to develop more intelligent assistant
   software, which is currently referred to as AI Agents in the
   industry.  These agents may come from different manufacturers and be
   deployed on different cloud platforms and regions.  They need to
   communicate and collaborate with each other through the Internet,
   which is called Internet of Agents (IoA).  Different interactions of
   AI agents have varying task requirements, which also lead to
   different demands on the network.  This requires network providing
   various fine granular services for the interactions of AI agents.

   This document proposes the application of the APN framework in the
   IoA scenario and analyzes its necessity.

full_text:
Network Working Group                                             J. Mao
Internet-Draft                                                     Z. Li
Intended status: Standards Track                                 N. Geng
Expires: 5 May 2026                                             C. Zheng
                                                     Huawei Technologies
                                                         1 November 2025


               APN Framework for Internet of Agent (IoA)
                draft-mao-rtgwg-apn-framework-for-ioa-00

Abstract

   With the rapid development of large model technologies in the AI
   field, it has become possible to develop more intelligent assistant
   software, which is currently referred to as AI Agents in the
   industry.  These agents may come from different manufacturers and be
   deployed on different cloud platforms and regions.  They need to
   communicate and collaborate with each other through the Internet,
   which is called Internet of Agents (IoA).  Different interactions of
   AI agents have varying task requirements, which also lead to
   different demands on the network.  This requires network providing
   various fine granular services for the interactions of AI agents.

   This document proposes the application of the APN framework in the
   IoA scenario and analyzes its necessity.

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 5 May 2026.

Copyright Notice

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



Mao, et al.                Expires 5 May 2026                   [Page 1]

Internet-Draft                 APN for IoA                 November 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.  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.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  The Necessity of APN Framework for IoA  . . . . . . . . . . .   3
     4.1.  What is APN . . . . . . . . . . . . . . . . . . . . . . .   3
     4.2.  IoA needs Differentiated SLA Guarantee from network . . .   4
     4.3.  IoA needs Secure Transmission from network  . . . . . . .   5
     4.4.  IoA needs Measurement and Visualization from network  . .   6
   5.  APN framework for IoA . . . . . . . . . . . . . . . . . . . .   6
     5.1.  Using APN framework in IoA scenarios  . . . . . . . . . .   6
     5.2.  Requirements  . . . . . . . . . . . . . . . . . . . . . .   8
       5.2.1.  Requirements for AI Agents  . . . . . . . . . . . . .   8
       5.2.2.  Requirements for Network Devices  . . . . . . . . . .   9
       5.2.3.  Requirements for Network Controller . . . . . . . . .   9
       5.2.4.  Requirements for Protocol Extensions  . . . . . . . .   9
       5.2.5.  Requirements for Security . . . . . . . . . . . . . .  10
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   With the rapid development of large language model technologies in
   the AI field, it has become possible to develop more intelligent
   assistant software, which is currently referred to as AI agents in
   the industry.

   Various types of AI agents have emerged rapidly within a year,
   serving different industries and people's daily lives.  Examples
   include deep research agents, code development agents, text
   generation agents, image generation agents, video generation agents,
   as well as agents for ordering meals, booking flights, booking
   hotels, and travel planning.




Mao, et al.                Expires 5 May 2026                   [Page 2]

Internet-Draft                 APN for IoA                 November 2025


   These agents may come from different manufacturers and be deployed on
   different cloud platforms and regions.  They need to communicate and
   collaborate with each other through the internet.

   For example, a user might request the marketing agent to help
   generate promotional materials for a new router product.  The
   marketing agent might first ask the text generation agent to write
   promotional copy, then request the image generation agent to create
   promotional images, and subsequently ask the video generation agent
   to produce a product introduction video.  Finally, it would collect
   all the promotional materials from these agents, save them on the
   server and notify the user to review them.

   Different interactions of AI agents have varying task requirements,
   which also lead to different demands on the network.  This requires
   network providing various fine granular services for the interactions
   of AI agents.

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 RFC 2119 [RFC2119] RFC 8174 [RFC8174] when, and only when, they
   appear in all capitals, as shown here.

3.  Terminology

   APN: Application-aware Networking

   IoA: Internet of Agents

4.  The Necessity of APN Framework for IoA


4.1.  What is APN

   APN is a technology that enables networks to be aware of application
   requirements.  Its framework and extension are defined in
   [I-D.li-rtgwg-apn-framework] and
   [I-D.li-rtgwg-apn-app-side-framework].

   These documents propose a new framework, named Application-aware
   Networking (APN), where application-aware information (APN attribute)
   including application-aware identification (APN ID) and application-
   aware parameters (APN Parameters), is encapsulated at network edge
   devices and carried along with the encapsulation of the tunnel used
   by the packet when traversing the APN domain.



Mao, et al.                Expires 5 May 2026                   [Page 3]

Internet-Draft                 APN for IoA                 November 2025


   By APN domain we intend the operator infrastructure where APN is used
   from edge to edge (ingress to egress) and where the packet is
   encapsulated using an outer header incorporating the APN information.
   The APN attribute will facilitate service provisioning and provide
   fine-granularity services in the APN domain.

   In addition, for the extension of the APN framework for application
   side, the APN resources of the APN domain are allocated to
   applications which compose and encapsulate the APN attribute in
   packets.  When network devices in the APN domain receive packets
   carrying APN attribute, they can directly apply policies for these
   traffic flows according to the APN attribute encapsulated by
   applications.

   APN can be applied in IoA scenarios, allowing networks to understand
   the requirements of each agent and its tasks on the network.  This
   enables the network to provide services that match these
   requirements, such as SLA assurance, security, measurement, and
   visualization, thereby improving the performance, security, and
   maintainability of agent interactions.

4.2.  IoA needs Differentiated SLA Guarantee from network

   Different tasks of agent interaction have varying requirements for
   network transmission.

   For example:

   *  Tool invocation tasks emphasize real-time interaction and are
      highly sensitive to latency and jitter, but have low bandwidth
      requirements.

   *  Text generation tasks are relatively sensitive to latency but have
      low bandwidth requirements.

   *  Image generation tasks have low latency requirements but
      relatively high bandwidth demands.

   *  Video generation tasks have low requirements for latency and
      jitter but very high bandwidth demands.

   Each of these tasks can be further divided into real-time interaction
   tasks and background interaction tasks:








Mao, et al.                Expires 5 May 2026                   [Page 4]

Internet-Draft                 APN for IoA                 November 2025


   *  Real-time interaction is used in scenarios where users actively
      operate the system.  Since the final response needs to be
      presented to the user (who waits for the result in front of the
      device), it has higher requirements for real-time performance
      (i.e., latency and jitter).

   *  Background interaction is initiated by the agent software in the
      application's backend system, thus having lower requirements for
      real-time performance.

   These different QoS requirements can be identified in traffic packets
   using APN.  Currently, APN defines four APN parameters:

   *  Bandwidth Requirement Parameter

   *  Delay Requirement Parameter

   *  Delay Variation Parameter

   *  Packet Loss Rate Parameter

   New APN parameters may need to be defined to carry some information
   about AI models, tools, tasks, data, or tokens for some specific IoA
   scenarios.

   By carrying these APN parameters in the messages, the network can
   provide differentiated and targeted services for different
   intelligent agent tasks to ensure a good experience for agent
   interactions.  For example, the network can offer fine-grained SLA
   guarantees, fine-grained network slicing, and fine-grained
   deterministic networking.

4.3.  IoA needs Secure Transmission from network

   Agents interact with each other through the Internet, which may
   require the network to provide security services.

   For example, a food ordering agent on a mobile phone communicates
   with a payment agent on the cloud, and the payment agent communicates
   with a bank agent, which may be on-premises.  These communications
   involve your personal account information and financial data, so they
   require a higher level of security.

   The APN ID or APN parameter can be used to carry encrypted
   transmission requirements.  The network can then create IPsec tunnels
   or quantum transmission channels and direct the traffic of agent
   interactions to these secure channels to prevent eavesdropping,
   tampering, and forgery.



Mao, et al.                Expires 5 May 2026                   [Page 5]

Internet-Draft                 APN for IoA                 November 2025


   For enterprises, they may want to enforce access control to agent
   interactions.  For instance, some agents that can access sensitive
   data are not allowed to collaborate with external agents to prevent
   data leakage.  However, some general-purpose agents are allowed to
   interact with external agents to improve team efficiency.

   The APN ID or APN parameter can be used to carry the identifier of
   the security group to which an agent belongs.  The network can then
   perform access control based on these identifiers to avoid unexpected
   agent interactions and information security risks.

4.4.  IoA needs Measurement and Visualization from network

   When intelligent agents interact through the internet, the quality of
   communication may need to be measured for purposes such as fault
   localization, troubleshooting, and visualization.

   APN IDs can be used to identify AI agents, and network devices can be
   configured to enable network measurement functions (e.g., IFIT) for
   specific agents, thereby enabling in-band measurement of the
   interaction traffic among these agents.  The network controller can
   visually present the communication quality of these agent
   interactions to the network administrators.

5.  APN framework for IoA


5.1.  Using APN framework in IoA scenarios

   The APN architecture can be applied to IoA scenarios, as illustrated
   in the following diagram.  The IoA service requirement that needs to
   be carried in the APN ID or APN parameter essentially belongs to a
   type of application-aware information (i.e., APN attribute).


















Mao, et al.                Expires 5 May 2026                   [Page 6]

Internet-Draft                 APN for IoA                 November 2025


                              +------------------+
                              |   APN-Customer   |
                              +------------------+
                                       |
                                       | NBI
                                       |
                              +------------------+
          --------------------|                  |------------------------
         /                    |  APN-Controller  |                        \
        /              -------|                  |--------                 \
       /              /       +------------------+        \                 \
      |              /       /         |          \        \                 |
+----------+        /       /          | SBI       \        \          +----------+
|AI Agent 1|-\     |       |           |            |        |      /->|AI Agent 3|
+----------+ |  +-----+ +-----+   +---------+   +--------+ +-----+  |  +----------+
             \->|APN  | |APN  |-A-|APN      |-A-|APN     | |APN  |->/
 User side      |-    |-|-    |-B-|-        |-B-|-       |-|-    |      Server side
             /->|Edge | |Head |-C-|Midpoint |-C-|Endpoint| |Edge |->\
+----------+ |  +-----+ +-----+   +---------+   +--------+ +-----+  |  +----------+
|AI Agent 2|-/                                                      \->|AI Agent 4|
+----------+    |------------------APN Domain--------------------|     +----------+

                  Figure 1: Using APN framework in IoA scenarios

   *  AI Agent: Interacts with other AI Agents on the internet, sending
      task requests, asynchronous notifications, and result responses to
      the others.  It can subscribe to network services from operators
      and optionally carry service requirement in the sent traffic via
      APN Attribute.  This means that the AI Agent behaves as an APN-
      capable Application Client or Server as defined in
      [I-D.li-rtgwg-apn-app-side-framework].

   *  APN-Edge: If AI Agents send traffic without APN attribute, APN-
      Edge device should obtain the APN attribute based on the
      configuration on this device according to the existing information
      in the packet header, create a tunnel encapsulation and add the
      APN attribute into it, and send the packets carrying the APN
      attribute to the APN-Head device finally.  When the packets are
      going to leave the APN domain, APN-Edge should remove the
      encapsulation if APN-Edge and APN-Endpoint are deployed
      separately.  Those are detailly defined in
      [I-D.li-rtgwg-apn-framework].  If the APN attribute is added by
      the AI Agent, the functionalities of the APN-Edge need to be
      changed.  APN-Edge can directly transmit the packets to APN-Head
      without encapsulating tunnels.  That is detailly defined in
      [I-D.li-rtgwg-apn-app-side-framework].





Mao, et al.                Expires 5 May 2026                   [Page 7]

Internet-Draft                 APN for IoA                 November 2025


   *  APN-Head: Identifies the service requirements of IoA based on the
      APN attribute in the packet and provides network services that
      meet these requirements.  This may involve encapsulating the
      packet with a new TE tunnel, placing the packet into an
      appropriate QoS queue, directing the packet to a network slice,
      adding or modifying some fields on the packet to perform network
      measurement, making access policy decisions, performing secondary
      encryption on the packet content, or diverting it to a secure
      channel.

   *  APN-Midpoint: APN-Midpoint provides the path service and enforces
      various policies according to the APN attribute carried in the
      packets.  The APN-Midpoint may also adjust the resource locally to
      guarantee the service requirements depending on a specific policy
      and the APN attribute conveyed by the packet.

   *  APN-Endpoint: the process of the specific network service will end
      at the APN-Endpoint.  If the outer tunnel header for the service
      between the APN-Head and the APN-Endpoint exists, it will be
      removed by the APN-Endpoint.  If the APN attribute is sent by AI
      Agents, the APN-Endpoint MUST keep the APN attribute in packets
      without any change.


5.2.  Requirements


5.2.1.  Requirements for AI Agents

   *  [REQ A01] AI Agent should support to subscribe network services
      from ISP, and get service requirement identifier or the usage
      authorization of service requirement metadata from ISP (out-band)
      or its APN-Controller.

   *  [REQ A02] AI Agent should support to describe the service status,
      the quality of users' experience (QoE), or the key quality
      indicators (KQI) in the APN attribute.

   *  [REQ A03] AI Agent should support to carry the APN attribute in
      the packets of the agent interaction traffic.

   *  TBD









Mao, et al.                Expires 5 May 2026                   [Page 8]

Internet-Draft                 APN for IoA                 November 2025


5.2.2.  Requirements for Network Devices

   *  [REQ D01] APN-Head should support steering the packets based on
      APN attributes into a TE tunnel that satisfies the SLA
      requirements of the agent interaction.

   *  [REQ D02] APN-Head, APN-Midpoint and APN-Endpoint should support
      putting the packets based on APN attributes into a QoS queue
      buffer that satisfies the SLA requirement of the agent
      interaction.

   *  [REQ D03] APN-Head, APN-Midpoint and APN-Endpoint should support
      to steer the packets based on APN attributes into a network slice
      that satisfies the SLA requirement of the agent interaction.

   *  [REQ D04] APN-Head, APN-Midpoint and APN-Endpoint should support
      adding, modifying, or marking some fields of the packets based on
      APN attributes to perform network measurement that satisfies the
      measurement and visualization requirement of the agent
      interaction.

   *  [REQ D05] APN-Head should support enforcing access control to the
      packets based on APN attributes, in accordance with some security
      rules or policies that satisfy the security requirement of the
      agent interaction.

   *  TBD


5.2.3.  Requirements for Network Controller

   *  [REQ C01] APN-Controller should support to notify the allocated
      results of the service requirement identifier, and the usage
      authorization of the service requirement metadata to AI Agent.

   *  [REQ C02] APN-Controller should support to analysis the measure
      data or path data of the agent interaction traffic reported from
      network devices to achieve traffic visualization and network
      troubleshooting.

   *  TBD

5.2.4.  Requirements for Protocol Extensions

   *  [REQ P01] Protocol extensions should be defined for the AI Agent
      to request the APN-Controller in the network to allocated the APN
      resources of the APN domain.




Mao, et al.                Expires 5 May 2026                   [Page 9]

Internet-Draft                 APN for IoA                 November 2025


   *  [REQ P02] Security mechanism should be defined to guarantee for
      that the APN attribute being securely transmitted among the AI
      Agent(user side), AI Agent (server side) and the APN domain.

   *  TBD

5.2.5.  Requirements for Security

   *  [REQ S01] The task contents of AI agent interactions should be
      protected or keep invisible.

   *  [REQ S02] The traffic of sensitive tasks should be steered into a
      secure channel for transmission, such as IPsec tunnels and quantum
      channels.

   *  TBD

6.  IANA Considerations

   This document does not include an IANA request.


7.  Security Considerations

   TBD


8.  References

8.1.  Normative References

   [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>.

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/info/rfc8126>.

   [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>.

8.2.  Informative References





Mao, et al.                Expires 5 May 2026                  [Page 10]

Internet-Draft                 APN for IoA                 November 2025


   [I-D.li-rtgwg-apn-app-side-framework]
              Li, Z. and S. Peng, "Extension of Application-aware
              Networking (APN) Framework for Application Side", Work in
              Progress, Internet-Draft, draft-li-rtgwg-apn-app-side-
              framework-00, 22 October 2023,
              <https://datatracker.ietf.org/doc/html/draft-li-rtgwg-apn-
              app-side-framework-00>.

   [I-D.li-rtgwg-apn-framework]
              Li, Z., Peng, S., Voyer, D., Li, C., Liu, P., Cao, C., and
              G. S. Mishra, "Application-aware Networking (APN)
              Framework", Work in Progress, Internet-Draft, draft-li-
              rtgwg-apn-framework-00, 4 March 2024,
              <https://datatracker.ietf.org/doc/html/draft-li-rtgwg-apn-
              framework-00>.

Authors' Addresses

   Jianwei Mao
   Huawei Technologies
   Beijing
   100095
   China
   Email: MaoJianwei@huawei.com


   Zhenbin Li
   Huawei Technologies
   Email: robinli314@163.com


   Nan Geng
   Huawei Technologies
   Email: gengnan@huawei.com


   Chong Zheng
   Huawei Technologies
   Email: zhengchong6@huawei.com












Mao, et al.                Expires 5 May 2026                  [Page 11]


name: draft-zeng-opsawg-llm-netconf-gap
rev: 00
title: Gap Analysis of Network Configuration Protocols in LLM-Driven Intent-Based Networking
time: 2025-11-02T12:16:18Z
group_uri: /api/v1/group/group/1027/
expires: 2026-05-06T12:16:18Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Autonomous netops", "A2A protocols", "Data formats/interop"]
tags: []
fetched_at: 2026-02-27T22:56:06.864751+00:00
abstract:
Large Language Models (LLMs) are entering network operations through
   natural-language intent interfaces.  Existing south-bound protocols
   (NETCONF, RESTCONF, gNMI, MCP, A2A) were not designed for
   conversational, semantically-rich, multi-agent orchestration.  This
   document provides a systematic gap analysis and identifies extension
   points for each protocol to meet intent-based networking
   requirements.

full_text:
Network Working Group                                            G. Zeng
Internet-Draft                                                    J. Mao
Intended status: Informational                                    B. Liu
Expires: 6 May 2026                                              N. Geng
                                                                X. Shang
                                                                  Q. Gao
                                                                   Z. Li
                                                                  Huawei
                                                         2 November 2025


 Gap Analysis of Network Configuration Protocols in LLM-Driven Intent-
                            Based Networking
                  draft-zeng-opsawg-llm-netconf-gap-00

Abstract

   Large Language Models (LLMs) are entering network operations through
   natural-language intent interfaces.  Existing south-bound protocols
   (NETCONF, RESTCONF, gNMI, MCP, A2A) were not designed for
   conversational, semantically-rich, multi-agent orchestration.  This
   document provides a systematic gap analysis and identifies extension
   points for each protocol to meet intent-based networking
   requirements.

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 6 May 2026.

Copyright Notice

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





Zeng, et al.               Expires 6 May 2026                   [Page 1]

Internet-Draft               LLM Netconf Gap               November 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.  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.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
   3.  Gap Analysis per Protocol . . . . . . . . . . . . . . . . . .   3
     3.1.  MCP . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
       3.1.1.  Gap Analysis  . . . . . . . . . . . . . . . . . . . .   3
       3.1.2.  Solution Considerations . . . . . . . . . . . . . . .   4
     3.2.  A2A . . . . . . . . . . . . . . . . . . . . . . . . . . .   5
       3.2.1.  Gap Analysis  . . . . . . . . . . . . . . . . . . . .   5
       3.2.2.  Solution Considerations . . . . . . . . . . . . . . .   7
     3.3.  NETCONF . . . . . . . . . . . . . . . . . . . . . . . . .   7
       3.3.1.  Gap Analysis  . . . . . . . . . . . . . . . . . . . .   7
       3.3.2.  Solution Considerations . . . . . . . . . . . . . . .   7
     3.4.  RESTCONF  . . . . . . . . . . . . . . . . . . . . . . . .   7
       3.4.1.  Gap Analysis  . . . . . . . . . . . . . . . . . . . .   7
       3.4.2.  Solution Considerations . . . . . . . . . . . . . . .   8
     3.5.  gNMI  . . . . . . . . . . . . . . . . . . . . . . . . . .   8
       3.5.1.  Gap Analysis  . . . . . . . . . . . . . . . . . . . .   8
       3.5.2.  Solution Considerations . . . . . . . . . . . . . . .   8
   4.  Summary . . . . . . . . . . . . . . . . . . . . . . . . . . .   8
   5.  Normative References  . . . . . . . . . . . . . . . . . . . .   8
   6.  Informative References  . . . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   Intent-based networking (IBN) promises to translate high-level
   operator intent into network configuration without low-level syntax
   errors.  With the advent of LLMs, the interface moves from YAML/CLI
   to natural language.  Unfortunately, none of the current
   configuration or agent-to-agent protocols provide the semantic,
   transactional, and multi-agent primitives required by LLM-driven IBN.
   This draft analyses the gaps and proposes concrete extension
   directions for five widely deployed protocols.







Zeng, et al.               Expires 6 May 2026                   [Page 2]

Internet-Draft               LLM Netconf Gap               November 2025


2.  Conventions and Definitions

   The key words "MUST", "MUST NOT", "REQUIRED", etc., are to be
   interpreted as described in [RFC2119].

   IBN, LLM, Agent, Intent, Tool, Artifact, and Task are used as defined
   in [I-D.ietf-opsawg-ibn-terminology].

3.  Gap Analysis per Protocol

3.1.  MCP

3.1.1.  Gap Analysis

   The design goal of MCP is to give a single Large Language Model (LLM)
   a "plug-and-play" tool-calling capability.  When deployed directly
   between a network controller and the devices, however, the following
   structural gaps are exposed.

3.1.1.1.  Lack of Network-Level Transaction Semantics

   MCP's tools/call is a stateless, one-shot JSON-RPC invocation.
   Network changes normally require the multi-stage semantics "candidate
   → validate → commit → rollback."  MCP has neither a candidate
   datastore nor two-phase-commit primitives.  Consequently, cross-
   device bulk deployments cannot guarantee "all-or-nothing" atomicity.
   When partial failures occur, the controller must supply its own
   compensation logic, lengthening the LLM's reasoning chain and
   increasing uncertainty.

3.1.1.2.  No YANG Semantics Discovery Mechanism

   Today MCP tool descriptors are written by hand.  Network-device
   capabilities are authoritatively defined by YANG models; whenever a
   model is updated, the tool list must be manually re-synchronized.
   Without an automated pipeline "YANG → JSON-Schema → tool descriptor,"
   maintaining the tool catalogue in a large multi-vendor environment
   becomes a bottleneck.

3.1.1.3.  Encoding and Bandwidth Bottlenecks

   Network-ops scenarios often involve high-frequency telemetry (5–60 s
   sampling, 10 k metrics per node).  MCP specifies only JSON-RPC over
   HTTP/1.1, resulting in highly redundant messages and no streaming
   push primitive.  When an LLM needs real-time anomaly detection,
   frequent polling consumes excessive bandwidth and CPU, violating
   data-center goals of low latency and high throughput.




Zeng, et al.               Expires 6 May 2026                   [Page 3]

Internet-Draft               LLM Netconf Gap               November 2025


3.1.1.4.  Missing Multi-Device Context Correlation

   MCP's invocation context is confined to a single connection; it
   cannot natively carry network-level intent such as "change the same
   VLAN across three leaf switches while keeping the STP root bridge
   unchanged."  The LLM must repeat the constraints in the prompt,
   wasting tokens and raising the error rate.

3.1.1.5.  Lack of Network Rollback and Audit Hooks

   Network operations require audit logs that "trace down to the leaf
   node."  MCP's tool return body contains only a JSON result; there are
   no standardized fields for rollback-point, commit-id, or syslog-
   severity.  Root-cause analysis and compliance audits therefore
   require additional integration with device syslog or NETCONF logs,
   increasing cost.

3.1.1.6.  Incompatibility with Existing Device Security Models

   Devices commonly enforce certificate-based mutual-TLS plus NACM path-
   level permissions.  MCP currently defines only a Bearer-token header
   and offers no mapping between a tool call and the read/write/exec
   permissions on a YANG node.  If a tool-descriptor file leaks, an LLM
   could combine calls to bypass existing ACLs, creating a privilege-
   escalation risk.

3.1.1.7.  Lifecycle and State-Management Gap

   Network changes often last several minutes (waiting for BGP
   convergence or MAC migration).  Once an MCP call completes, its
   context is discarded immediately, so there is no way to stream
   intermediate updates such as “convergence 90 %.” The LLM has no
   choice but to poll repeatedly, increasing load on both itself and the
   device while still failing to achieve a true state-machine-driven
   closed loop.

3.1.2.  Solution Considerations

   For MCP to serve as "the universal glue between LLMs and devices" in
   production networks, an upper layer must supply a transactional state
   machine, a YANG self-description channel, streaming encodings, and
   fine-grained audit semantics.  Without these additions, MCP will
   remain confined to labs or single-device scripting and will be unable
   to close the loop on production-grade intent.







Zeng, et al.               Expires 6 May 2026                   [Page 4]

Internet-Draft               LLM Netconf Gap               November 2025


3.2.  A2A

3.2.1.  Gap Analysis

   Positioned as a "multi-agent collaboration layer," the Agent-to-Agent
   (A2A) protocol was created so that any two LLM-Agents can discover
   each other, negotiate, and jointly finish long-running tasks.  When
   it is dropped straight into "network-controller ↔ network-device" or
   "controller ↔ controller" settings, however, the following deep gaps
   surface:

3.2.1.1.  Task Granularity Mismatch with Network Atomic Operations

   A2A Tasks target macro-level business goals (e.g., "relocate a DC").
   The smallest deliverable is an Artifact.  Network changes, by
   contrast, must touch a single YANG leaf (e.g., "set interface X MTU =
   9216").  The spec offers no "micro-task" primitive, so one Task
   either carries thousands of lines and becomes bloated, or is split
   into hundreds of Tasks that explode the state machine and raise LLM-
   orchestration complexity.

3.2.1.2.  No Network-Wide Transaction or Roll-back Semantics

   A2A's state machine is limited to pending → working → completed/
   failed.  On failure the controller only gets a free-text
   Task.statusMessage.  Network ops demand cross-device atomic commit
   plus a rollback tag.  The protocol today defines no:

   *  two-phase-commit token (transaction-id),

   *  distributed lock or conflict detection,

   *  unified rollback API (rollback-on-failure).

   Controllers must therefore implement compensation themselves, forcing
   the LLM to reason about "how to write a rollback script," which
   violates intent-based principles.

3.2.1.3.  Poor Encoding and Bandwidth Efficiency

   A2A mandates JSON for Artifact payloads and runs over HTTP/1.1.  For
   high-frequency telemetry (5 s interval, 10 k metrics/node) or bulk
   config pushes, JSON's textual redundancy causes:

   *  controller-device link congestion,

   *  wasted LLM-context tokens,




Zeng, et al.               Expires 6 May 2026                   [Page 5]

Internet-Draft               LLM Netconf Gap               November 2025


   *  repetitive header parsing and higher CPU load.

   The protocol lacks a binary or streaming encoding option and offers
   no back-pressure mechanism.

3.2.1.4.  Missing Multi-Device Context Correlation

   A2A Task context is scoped to a single "conversation"; there is no
   standard field to express topology-level constraints such as "change
   the same VLAN on three leaf switches while keeping the STP root
   bridge unchanged."  The LLM must repeat inter-device relations in the
   prompt, burning tokens and risking truncation that produces
   configurations which are syntactically valid but topologically wrong.

3.2.1.5.  Incompatibility with Existing Device Security Models

   Devices generally enforce certificate-based mutual TLS plus NACM
   path-level access control.  A2A currently specifies only an OAuth2
   delegation token and provides no mapping from "Task-level role" to
   YANG node read/write/exec permissions, nor per-Artifact fine-grained
   ACLs.  Once an Artifact is cached or forwarded it may bypass the
   certificate chain, leading to privilege escalation or configuration
   pollution.

3.2.1.6.  No Network-Semantics Discovery Mechanism

   Skills are advertised in the Agent Card, but the Card is free text.
   There are no standard fields saying "I support OpenConfig BGP 4.0
   YANG" or "I manage AS 65001-65500."  LLMs must rely on fuzzy
   matching, often selecting the wrong partner and raising Task failure
   rates.

3.2.1.7.  Life-Cycle and Intermediate-State Reporting Gap

   Network changes can last minutes (waiting for BGP convergence, MAC
   moves).  After a Task enters "working," A2A only mandates a final
   Artifact; there is no standard way to push interim states such as
   "convergence 70 %" or "MTU changed, waiting for LLDP neighbor re-
   discovery."  The LLM must poll or wait until timeout, increasing load
   and preventing a true state-machine-driven closed loop.











Zeng, et al.               Expires 6 May 2026                   [Page 6]

Internet-Draft               LLM Netconf Gap               November 2025


3.2.2.  Solution Considerations

   To act as a "multi-agent collaboration bus" in network environments,
   A2A must be systematically extended in task granularity, transaction
   semantics, binary encoding, topology context, security mapping, life-
   cycle management, and intermediate-state push.  Otherwise it will
   remain suited only for macro business flows and will be unable to
   close the fine-grained, reliable, and roll-backable network-intent
   loop required in production.

3.3.  NETCONF

3.3.1.  Gap Analysis

   NETCONF [RFC6241] provides transactional, XML-encoded RPCs over SSH.
   It lacks:

   *  Semantic discovery: YANG models are not self-describing for LLMs;
      no runtime tool list.

   *  Session context: no standard place to store intent-id, LLM prompt,
      or multi-device correlation.

   *  Streaming telemetry: <notification> is push-style but insufficient
      for high-frequency KPI.

   *  Function-level audit: <commit> is atomic, but per-leaf
      authorization is out-of-scope.

3.3.2.  Solution Considerations

   TBD

3.4.  RESTCONF

3.4.1.  Gap Analysis

   RESTCONF [RFC8040] maps YANG to HTTP URIs.  Gaps include:

   *  No candidate datastore—every PUT/PATCH is immediate.

   *  No server-side discovery document for LLMs.

   *  Stateless: no place to store multi-request intent.

   *  Encoding flexibility may confuse LLM prompt consistency.





Zeng, et al.               Expires 6 May 2026                   [Page 7]

Internet-Draft               LLM Netconf Gap               November 2025


3.4.2.  Solution Considerations

   TBD

3.5.  gNMI

3.5.1.  Gap Analysis

   gNMI delivers high-speed telemetry but:

   *  No semantic metadata for LLMs.

   *  Set() is non-transactional across multiple paths.

   *  No multi-agent signalling—gNMI is 1:1.

   *  No standardized error ontology.

3.5.2.  Solution Considerations

   TBD

4.  Summary

   No single protocol satisfies all IBN-LLM requirements.
   NETCONF/RESTCONF/gNMI need semantic and transactional extensions;
   MCP/A2A need networking-specific profiling.  A companion document
   will define unified data models and security frameworks to close the
   identified gaps.

5.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", 1997.

   [RFC6241]  Enns, R., "Network Configuration Protocol (NETCONF)",
              2011.

   [RFC8040]  Bierman, A., "RESTCONF Protocol", 2017.

   [RFC9457]  Nottingham, M., "Problem Details for HTTP APIs", 2023.

   [OpenConfig-gNMI]
              Team, OpenConfig., "gNMI Specification", 2022.

   [MCP-spec] Inc, Anthropic., "Model Context Protocol", 2024.

   [A2A-spec] LLC, Google., "Agent-to-Agent Protocol", 2025.



Zeng, et al.               Expires 6 May 2026                   [Page 8]

Internet-Draft               LLM Netconf Gap               November 2025


6.  Informative References

   [I-D.ietf-opsawg-ibn-terminology]
              IETF, "Intent-Based Networking Terminology", 2025.

Authors' Addresses

   Guanming Zeng
   Huawei
   Email: zengguanming@huawei.com


   Jianwei Mao
   Huawei
   Email: maojianwei@huawei.com


   Bing Liu
   Huawei
   Email: leo.liubing@huawei.com


   Nan Geng
   Huawei
   Email: gengnan@huawei.com


   Xiaotong Shang
   Huawei
   Email: shangxiaotong@huawei.com


   Qiangzhou Gao
   Huawei
   Email: gaoqiangzhou@huawei.com


   Zhenbin Li
   Huawei
   Email: robinli314@163.com











Zeng, et al.               Expires 6 May 2026                   [Page 9]


name: draft-zeng-opsawg-applicability-mcp-a2a
rev: 00
title: When NETCONF Is Not Enough: Applicability of MCP and A2A for Advanced Network Management Scenarios
time: 2025-11-02T12:22:28Z
group_uri: /api/v1/group/group/1027/
expires: 2026-05-06T12:22:28Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Autonomous netops", "A2A protocols", "Data formats/interop"]
tags: []
fetched_at: 2026-02-27T22:56:06.864767+00:00
abstract:
NETCONF provides robust configuration transactions and YANG-based
   data models, but falls short in scenarios requiring AI-driven
   semantic translation, long-lived cross-domain orchestration, multi-
   agent consensus, rapid DevOps iteration, or delivery of large non-
   configuration artifacts.  This document systematically analyzes the
   functional gaps and presents Model Context Protocol (MCP) and Agent-
   to-Agent (A2A) as complementary solutions.  Implementation guidance
   and coexistence models are also provided.

full_text:
Network Working Group                                            G. Zeng
Internet-Draft                                                    J. Mao
Intended status: Standards Track                                  B. Liu
Expires: 6 May 2026                                              N. Geng
                                                                X. Shang
                                                                  Q. Gao
                                                                   Z. Li
                                                                  Huawei
                                                         2 November 2025


 When NETCONF Is Not Enough: Applicability of MCP and A2A for Advanced
                      Network Management Scenarios
               draft-zeng-opsawg-applicability-mcp-a2a-00

Abstract

   NETCONF provides robust configuration transactions and YANG-based
   data models, but falls short in scenarios requiring AI-driven
   semantic translation, long-lived cross-domain orchestration, multi-
   agent consensus, rapid DevOps iteration, or delivery of large non-
   configuration artifacts.  This document systematically analyzes the
   functional gaps and presents Model Context Protocol (MCP) and Agent-
   to-Agent (A2A) as complementary solutions.  Implementation guidance
   and coexistence models are also provided.

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 6 May 2026.

Copyright Notice

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




Zeng, et al.               Expires 6 May 2026                   [Page 1]

Internet-Draft                 MCP-A2A-Gap                 November 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.  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.  Gap Analysis Summary  . . . . . . . . . . . . . . . . . . . .   3
   3.  When MCP Must Be Used . . . . . . . . . . . . . . . . . . . .   3
     3.1.  AI Natural-Language Intent  . . . . . . . . . . . . . . .   4
     3.2.  Rapid Model Iteration (DevOps Week-Release) . . . . . . .   5
   4.  When A2A Must Be Used . . . . . . . . . . . . . . . . . . . .   6
     4.1.  Cross-Controller Long-Flow Orchestration  . . . . . . . .   6
     4.2.  Multi-Agent Consensus (Agent-to-Agent)  . . . . . . . . .   8
   5.  Coexistence Model . . . . . . . . . . . . . . . . . . . . . .  10
     5.1.  Design Choices at a Glance  . . . . . . . . . . . . . . .  10
     5.2.  Common Layering . . . . . . . . . . . . . . . . . . . . .  10
     5.3.  Controller-Gateway Model  . . . . . . . . . . . . . . . .  10
     5.4.  Device-Embedded Model . . . . . . . . . . . . . . . . . .  10
     5.5.  Migration Roadmap . . . . . . . . . . . . . . . . . . . .  10
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   7.  Normative References  . . . . . . . . . . . . . . . . . . . .  10
   8.  Informative References  . . . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   NETCONF [RFC6241] remains the gold standard for network configuration
   transactions.  However, five emerging scenarios expose its
   fundamental limitations:

   *  (1) AI natural-language intent

   *  (2) Long-flow cross-controller orchestration

   *  (3) multi-agent consensus

   *  (4) weekly DevOps release cycles

   *  (5) multi-modal artifact delivery






Zeng, et al.               Expires 6 May 2026                   [Page 2]

Internet-Draft                 MCP-A2A-Gap                 November 2025


   This document identifies objective gaps and specifies when and how
   MCP [I-D.yang-nmrg-mcp-nm] and A2A [I-D.google-agent2agent] should be
   engaged.

2.  Gap Analysis Summary

   This section enumerates the fundamental gaps between NETCONF and the
   advanced management scenarios introduced in Section 1.  For each gap,
   the table below identifies:

   *  the missing capability,

   *  its root cause in NETCONF design, and

   *  the protocol (MCP or A2A) that natively provides it.

     +===================+=======================+==================+
     | Gap               | Root Cause in NETCONF | MCP/A2A Solution |
     +===================+=======================+==================+
     | AI Semantic Layer | XML-centric, no       | MCP /tools/list  |
     |                   | function registry     | + JSON-Schema    |
     +-------------------+-----------------------+------------------+
     | Long-Flow         | No Task life-cycle or | A2A Task state   |
     | Orchestration     | human-in-the-loop     | machine          |
     +-------------------+-----------------------+------------------+
     | Multi-Agent       | Client-server only;   | A2A AgentCard +  |
     | Consensus         | no peer negotiation   | Message          |
     +-------------------+-----------------------+------------------+
     | Weekly DevOps     | YANG revision 6-9     | MCP Tool hot-    |
     | Iteration         | months; firmware lock | register         |
     +-------------------+-----------------------+------------------+
     | Large Artifact    | 64 kB chunk; no       | MCP/A2A Artifact |
     | Delivery          | MIME/hash/URL         | (cloud URL)      |
     +-------------------+-----------------------+------------------+

                                 Table 1

   The gaps are not implementation defects but architectural invariants
   of RFC 6241.  They become blocking only in the five advanced
   scenarios identified.  Outside these scenarios, NETCONF continues to
   provide the most robust configuration transactions and should remain
   the south-bound protocol of choice.

3.  When MCP Must Be Used







Zeng, et al.               Expires 6 May 2026                   [Page 3]

Internet-Draft                 MCP-A2A-Gap                 November 2025


3.1.  AI Natural-Language Intent

   Operators increasingly expect to issue instructions in natural
   language: “Raise MTU to 9000 for all Beijing core switches” or “Block
   source 1.2.3.4 for 30 minutes”.  NETCONF requires an edit-config XML
   blob with exact leaf names and namespaces; even experienced engineers
   make syntax mistakes under time pressure.

   The root cause is architectural:

   *  XML is attribute-heavy and case-sensitive; forgotten namespaces or
      mismatched quotes silently fail.

   *  There is no machine-discoverable “function catalogue” — an LLM
      must rely on static prompt examples which drift as models evolve.

   *  Multi-vendor differences (OpenConfig vs. proprietary YANG) force
      the LLM to choose branches inside the XML, exploding prompt size.

   MCP solves these issues with three primitives:

   *  /tools/list — JSON array of callable functions, each carrying
      human-readable description and JSON-Schema input.

   *  JSON-Schema — strong-typed, no namespaces, direct mapping to
      primitive types (string, integer, enum, array).

   *  JSON-RPC 2.0 — single-line request/response, easily parsed by LLM
      and by controller gateways.

   Example MCP Tool Descriptor (simplified):

   {
     "name": "batch_set_mtu",
     "description": "Set interface MTU on multiple devices",
     "inputSchema": {
       "type": "object",
       "properties": {
         "device_group": {"type": "string"},
         "mtu": {"type": "integer", "minimum": 576, "maximum": 9216}
       },
       "required": ["device_group", "mtu"]
     }
   }

                                  Figure 1

   The LLM now produces:



Zeng, et al.               Expires 6 May 2026                   [Page 4]

Internet-Draft                 MCP-A2A-Gap                 November 2025


   {
     "jsonrpc": "2.0",
     "method": "batch_set_mtu",
     "params": {"device_group": "beijing-core", "mtu": 9000},
     "id": 1
   }

                                  Figure 2

3.2.  Rapid Model Iteration (DevOps Week-Release)

   Cloud-era value-added services must be deployed within days, not
   months.  NETCONF's revision cycle (IETF draft → RFC: 6-9 months) and
   firmware upgrade windows (≤ 1 per year) are incompatible with weekly
   release trains.  The blocking points are:

   *  YANG module must be burned into firmware before the first config
      leaf is usable;

   *  Controller regression suite recompiles the entire YANG tree even
      for a single new leaf;

   *  Backward-compatibility review (must not break old devices)
      stretches internal QA to weeks.

   MCP breaks the deadlock by treating "intent" as a hot-swappable Tool
   rather than a permanent YANG node:

   *  Private YANG is compiled to JSON-Schema in the controller
      (milliseconds);

   *  Tool registers via /tools/register and is immediately callable;

   *  Gray-list rollout (10 % → 30 % → 100 %) and instant rollback (re-
      register previous Tool) are done without touching device flash.

   Example: Cloud-Shield DDoS Cleaning Service

   Private YANG (120 lines)
     +--rw start-cleanse
     | +--rw target-ip      inet:ipv4-address
     | +--rw bandwidth-Mbps uint32
     | +--rw duration-min   uint16

                                  Figure 3

   Compiled JSON-Schema and registered in 30 s:




Zeng, et al.               Expires 6 May 2026                   [Page 5]

Internet-Draft                 MCP-A2A-Gap                 November 2025


{
  "name": "start_cleanse",
  "version": "1.0.0",
  "description": "Start DDoS cleanse for target IP",
  "inputSchema": {
    "type": "object",
    "properties": {
      "target_ip": {"type": "string", "format": "ipv4"},
      "bandwidth_Mbps": {"type": "integer", "minimum": 100, "maximum": 100000},
      "duration_min": {"type": "integer", "minimum": 5, "maximum": 1440}
    },
    "required": ["target_ip", "bandwidth_Mbps"]
  }
}

                               Figure 4

   Thus MCP is mandatory for any management surface that must support
   weekly or daily release cycles without waiting for firmware or
   standards body timelines.

4.  When A2A Must Be Used

4.1.  Cross-Controller Long-Flow Orchestration

   Maintenance windows for core-network upgrades often exceed 30 minutes
   and span multiple vendor domains.  NETCONF provides atomic
   configuration on a single controller, but lacks:

   *  a cross-vendor task life-cycle,

   *  human-in-the-loop approval gates, and

   *  delivery of large artifacts (firmware, images, diff reports).

   A2A fills these gaps with three primitives:

   *  Task — state machine (pending → working → completed/failed/
      cancelled) persisting across agent restarts;

   *  Artifact — hash-signed object store (≤ 2 GB, resumable upload);

   *  Message — multi-round negotiation (JSON or natural language).








Zeng, et al.               Expires 6 May 2026                   [Page 6]

Internet-Draft                 MCP-A2A-Gap                 November 2025


     +=========================+================+===================+
     | State                   | Meaning        | NETCONF           |
     |                         |                | Equivalent        |
     +=========================+================+===================+
     | pending                 | Waiting for    | None (RPC is      |
     |                         | resources or   | fire-and-forget)  |
     |                         | approval       |                   |
     +-------------------------+----------------+-------------------+
     | awaiting-human-approval | Human must     | None              |
     |                         | click approve/ |                   |
     |                         | cancel         |                   |
     +-------------------------+----------------+-------------------+
     | working                 | Agents         | edit-config       |
     |                         | executing sub- | (local only)      |
     |                         | tasks          |                   |
     +-------------------------+----------------+-------------------+
     | completed               | All agents     | commit            |
     |                         | report success |                   |
     +-------------------------+----------------+-------------------+
     | failed                  | Any agent      | rollback-on-error |
     |                         | reports        |                   |
     |                         | failure        |                   |
     +-------------------------+----------------+-------------------+
     | cancelled               | Operator or    | discard-changes   |
     |                         | policy         |                   |
     |                         | cancelled      |                   |
     +-------------------------+----------------+-------------------+

             Table 2: A2A Task States vs. NETCONF Operations

   Real-World Example: Five-City Core MTU Migration

   Controllers: Huawei NCE (3 cities) + Cisco NSO (2 cities)
   Devices: 312 PE routers
   Window: 120 min (02:00-04:00)
   Artifact: 2 GB firmware image + 40 MB diff-report

                                  Figure 5

   Step-wise A2A Flow (time-stamps):

   *  T+0 min: Orchestrator creates Task T100, goal="Raise MTU to 9000
      on core links".

   *  T+5 min: Each controller Agent posts Artifact pre-check.csv (link
      health KPI).





Zeng, et al.               Expires 6 May 2026                   [Page 7]

Internet-Draft                 MCP-A2A-Gap                 November 2025


   *  T+10 min: Orchestrator Artifact hash-verified; human approval card
      sent to WeChat.

   *  T+15 min: Engineer clicks "approve"; Task state → working.

   *  T+20-90 min: Controllers download 2 GB image via Artifact URL;
      local NETCONF edit-config issued; progress Artifacts streamed
      every 5 min.

   *  T+95 min: Last Artifact post-upgrade-verification.csv uploaded.

   *  T+100 min: All agents report success; Task → completed.  Total
      human intervention: 1 click.

   A2A is mandatory for any multi-vendor, multi-hour workflow that
   demands task persistence, human gates, and multi-gigabyte artifact
   delivery—scenarios where NETCONF's single-controller, single-RPC
   paradigm is insufficient.

4.2.  Multi-Agent Consensus (Agent-to-Agent)

   Fault recovery, security mitigation and resource optimisation often
   require multiple autonomous agents (monitoring, security, controller,
   human) to reach a common decision.  NETCONF's strict client-server
   model provides no peer-to-peer capability advertisement, multi-round
   negotiation or voting primitives.

   A2A introduces three building blocks:

   *  AgentCard — JSON-LD advertisement of skills and endpoint;

   *  Message — multi-round negotiation (JSON or natural language);

   *  Consensus Engine — policy-based scoring, voting, human-in-the-
      loop.
















Zeng, et al.               Expires 6 May 2026                   [Page 8]

Internet-Draft                 MCP-A2A-Gap                 November 2025


     +================+==================+==========================+
     | Field          | Description      | Example Value            |
     +================+==================+==========================+
     | id             | globally unique  | monitor-sh-01            |
     |                | agent identifier |                          |
     +----------------+------------------+--------------------------+
     | skills         | array of skill   | {name: "threat_analyze", |
     |                | objects (name,   | desc: "Return 0-10       |
     |                | description)     | threat score"}           |
     +----------------+------------------+--------------------------+
     | endpoint       | HTTPS URL for    | https://mon-             |
     |                | A2A messages     | sh.example:9443/a2a      |
     +----------------+------------------+--------------------------+
     | authentication | mTLS + OIDC      | {"type": "mTLS",         |
     |                |                  | "sha256": "8f66..."}     |
     +----------------+------------------+--------------------------+

                   Table 3: AgentCard Mandatory Fields

   Consensus Flow Example: DDoS Port Shutdown

   Agents: Monitor, Security, Controller, Human
   Decision: shutdown port 10/1 ?
   Scoring: threat_level×0.6 + impact×0.4
   Threshold: ≥ 5.0 → shutdown

                                  Figure 6

   Message Sequence (time-stamps):

   *  T+0 s: Monitor Agent posts threat_score=9.0 via Message.

   *  T+5 s: Security Agent confirms attack signature; score unchanged.

   *  T+10 s: Controller Agent posts impact=300 VPN down; computed score
      = 9×0.6 + 3×0.4 = 6.6 (> 5.0).

   *  T+12 s: Task state → awaiting-human-approval; WeChat card sent.

   *  T+135 s: Human clicks "approve".

   *  T+140 s: Controller Agent calls NETCONF shutdown; Artifact post-
      action.log uploaded.

   *  T+180 s: All agents report success; Task → completed.






Zeng, et al.               Expires 6 May 2026                   [Page 9]

Internet-Draft                 MCP-A2A-Gap                 November 2025


   Therefore A2A is mandatory whenever multiple autonomous agents must
   discover, negotiate, vote and reach a binding decision — scenarios
   that NETCONF's unidirectional client-server paradigm cannot emulate.

5.  Coexistence Model

   This section describes how MCP and A2A can be deployed _without_
   forcing a redesign of the existing NETCONF ecosystem.  The
   architecture keeps NETCONF as the configuration authority and allows
   _either_ controller-hosted _or_ device-hosted MCP servers — the
   latter avoids a central gateway bottleneck while preserving operator
   investment in controllers.

5.1.  Design Choices at a Glance

   TBD

5.2.  Common Layering

   TBD

5.3.  Controller-Gateway Model

   TBD

5.4.  Device-Embedded Model

   TBD

5.5.  Migration Roadmap

   TBD

6.  Security Considerations

   MCP and A2A introduce OAuth2/JWT and long-lived Tasks.

7.  Normative References

   [RFC6241]  Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
              Bierman, "Network Configuration Protocol (NETCONF)",
              RFC 6241, DOI 10.17487/RFC6241, June 2011,
              <https://www.rfc-editor.org/rfc/rfc6241>.

   [RFC9200]  Tschofenig, H., "Guidelines for Using the Transport Layer
              Security (TLS) Protocol in Devices", RFC 9200,
              DOI 10.17487/RFC9200, March 2022,
              <https://www.rfc-editor.org/rfc/rfc9200>.



Zeng, et al.               Expires 6 May 2026                  [Page 10]

Internet-Draft                 MCP-A2A-Gap                 November 2025


8.  Informative References

   [I-D.yang-nmrg-mcp-nm]
              Yang, Y., "Applicability of MCP for the Network
              Management", Work in Progress, Internet-Draft, draft-yang-
              nmrg-mcp-nm-00, July 2025,
              <https://datatracker.ietf.org/doc/html/draft-yang-nmrg-
              mcp-nm-00>.

   [I-D.google-agent2agent]
              Google., "Agent-to-Agent (A2A) Protocol", Work in
              Progress, Internet-Draft, draft-google-agent2agent-00, May
              2025, <https://datatracker.ietf.org/doc/html/draft-google-
              agent2agent-00>.

Authors' Addresses

   Guanming Zeng
   Huawei
   Email: zengguanming@huawei.com


   Jianwei Mao
   Huawei
   Email: maojianwei@huawei.com


   Bing Liu
   Huawei
   Email: leo.liubing@huawei.com


   Nan Geng
   Huawei
   Email: gengnan@huawei.com


   Xiaotong Shang
   Huawei
   Email: shangxiaotong@huawei.com


   Qiangzhou Gao
   Huawei
   Email: gaoqiangzhou@huawei.com






Zeng, et al.               Expires 6 May 2026                  [Page 11]

Internet-Draft                 MCP-A2A-Gap                 November 2025


   Zhenbin Li
   Huawei
   Email: robinli314@163.com
















































Zeng, et al.               Expires 6 May 2026                  [Page 12]


name: draft-liu-saag-zt-problem-statement
rev: 00
title: Zero trust standards in IETF: use cases and problem statement
time: 2025-11-02T13:41:43Z
group_uri: /api/v1/group/group/1027/
expires: 2026-05-06T13:41:43Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Policy/governance", "Agent identity/auth"]
tags: []
fetched_at: 2026-02-27T22:56:06.864778+00:00
abstract:
The traditional "castle-and-moat" security paradigm is no longer
   effective for some emerging scenarios, such as cloud services, remote
   workforces and intelligent agents.  Zero trust (ZT) has emerged as
   the new paradigm, holding on the "never trust, always verify"
   principle, treats every single access request as untrudted and
   requires veficication.

   While a high-level atchitectural guidance exists, notably from NIST
   in SP 800-207 where thtenants of zero trust are well interperated,
   the industry lacks the open, interoperable framework and protocol
   necessary for building multi-vendor zero trust practice enrironment.
   This document presents the problem statement for zero trust
   interoperability, outlines the key use cases, and argue for the need
   for standardization in the IETF.  It discusses the possible scope for
   zero trust standardization work in the IETF, identifying which
   aspects are well suited for the IETF protocols and which are better
   addressed by other bodies.  The aim of this document is to initiate a
   discussion in the IETF community on the necessity and prospective of
   promoting zero trust related work here.

full_text:
SAAG                                                              X. Liu
Internet-Draft                                                   R. Yang
Intended status: Informational                                  Y. Zhang
Expires: 6 May 2026                                 Pengcheng Laboratory
                                                         2 November 2025


     Zero trust standards in IETF: use cases and problem statement
                 draft-liu-saag-zt-problem-statement-00

Abstract

   The traditional "castle-and-moat" security paradigm is no longer
   effective for some emerging scenarios, such as cloud services, remote
   workforces and intelligent agents.  Zero trust (ZT) has emerged as
   the new paradigm, holding on the "never trust, always verify"
   principle, treats every single access request as untrudted and
   requires veficication.

   While a high-level atchitectural guidance exists, notably from NIST
   in SP 800-207 where thtenants of zero trust are well interperated,
   the industry lacks the open, interoperable framework and protocol
   necessary for building multi-vendor zero trust practice enrironment.
   This document presents the problem statement for zero trust
   interoperability, outlines the key use cases, and argue for the need
   for standardization in the IETF.  It discusses the possible scope for
   zero trust standardization work in the IETF, identifying which
   aspects are well suited for the IETF protocols and which are better
   addressed by other bodies.  The aim of this document is to initiate a
   discussion in the IETF community on the necessity and prospective of
   promoting zero trust related work here.

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 6 May 2026.



Liu, et al.                Expires 6 May 2026                   [Page 1]

Internet-Draft   Zero trust standards in IETF: use cases   November 2025


Copyright Notice

   Copyright (c) 2025 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.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Use cases . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  Use Case 1: Secure Remote Access for Enterprise
           Resources . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.2.  Use case 2: secure service-to-service communication . . .   4
     4.3.  Use Case 3: Granular Access to Third-Party SaaS
           Applications  . . . . . . . . . . . . . . . . . . . . . .   4
     4.4.  Use Case 4: Secure Access for Autonomous AI Agents  . . .   4
   5.  Problem statement . . . . . . . . . . . . . . . . . . . . . .   5
     5.1.  Lack of interoperability  . . . . . . . . . . . . . . . .   5
     5.2.  Market Confusion  . . . . . . . . . . . . . . . . . . . .   5
     5.3.  Gap Analysis  . . . . . . . . . . . . . . . . . . . . . .   5
   6.  Proposed Scope of Work for the IETF . . . . . . . . . . . . .   6
     6.1.  Control Plane Communication Protocol  . . . . . . . . . .   6
     6.2.  Dynamic Context and Signal Exchange Protocol  . . . . . .   7
     6.3.  Authenticated Session Establishment and Management  . . .   7
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   Traditional network security was built on the assumption of that
   every entity inside the perimeter were trusted by default.  This
   approach is increasingly ineffective in face of new use cases and
   sophisticateed attackers.





Liu, et al.                Expires 6 May 2026                   [Page 2]

Internet-Draft   Zero trust standards in IETF: use cases   November 2025


   Zero Trust (ZT) offers a fundamentally different approach.  As d
   efined in [NIST-SP-800-207], Zero Trust assumes no implicit trust is
   granted to assets or user accounts based solely on their physical or
   network location.  Instead, authentication and authorization are
   discrete, dynamic functions that must be performed before a session
   is established to an enterprise resource.  This is a "never trust,
   always verify" model.

   While this conceptual framework is powerful, its practical
   implementation is hampered by a lack of open standards.  Today's ZT
   solutions are largely proprietary, single-vendor ecosystems.  An
   organization cannot easily use a Policy Enforcement Point (PEP) from
   one vendor with a Policy Decision Point (PDP) from another.

   This document provides a gap analysis for zero trust standardization,
   as well as several typical use cases.  In additon, it also discusses
   the scope of standardization of zero trust in the IETF.

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.

3.  Terminology

   This document adopts the core terminology defined in
   [NIST-SP-800-207].

   Subject:  An entity (e.g., user, device, service, application, AI
      agent) that requests access to a resource.

   Resource:  A data source, service, device, or network component that
      a subject wishes to access.

   Policy Engine (PE):  The component responsible for the ultimate
      decision to grant or deny access to a resource for a given
      subject.

   Policy Administrator (PA):  The component responsible for
      establishing and/or shutting down the communication path between a
      subject and a resource.

   Policy Enforcement Point (PEP):  A system responsible for enabling,





Liu, et al.                Expires 6 May 2026                   [Page 3]

Internet-Draft   Zero trust standards in IETF: use cases   November 2025


      monitoring, and terminating connections between a subject and a
      resource.  The PEP communicates with the PA to forward requests
      and/or receive policy updates.

   Control Plane:  The logical network of communication that is used to
      manage the ZTA.  This includes communication between the PE, PA,
      and PEPs, as well as the collection of context and signals.

   Data Plane:  The logical network where subjects and resources
      communicate after access has been granted.

4.  Use cases

   In this section we consider several emerging use cases where
   standardized ZT protocols would provide significant value.

4.1.  Use Case 1: Secure Remote Access for Enterprise Resources

   A remote employee needs to access an internal application hosted in a
   private data center of an organization.

   1.  Subject: The employee's user identity and the device identity.
   2.  Resource: The internal application.

4.2.  Use case 2: secure service-to-service communication

   A front-end web service running in a Kubernetes cluster in Cloud A
   needs to query a database service running in a VM in Cloud B.

   1.  Subject: The front-end web service, identified by a workload
       identity.
   2.  Resource: The database service.

4.3.  Use Case 3: Granular Access to Third-Party SaaS Applications

   An organization wants to enforce device posture checks before
   allowing employees to access a third-party SaaS application .

   1.  Subject: The employee and their device.
   2.  Resource: The SaaS CRM application.

4.4.  Use Case 4: Secure Access for Autonomous AI Agents

   An autonomous AI agent, acting on behalf of a user or system, needs
   to access a set of APIs to complete a task (e.g., booking travel).

   1.  Subject: The AI agent, possessing a cryptographically verifiable
       workload identity.



Liu, et al.                Expires 6 May 2026                   [Page 4]

Internet-Draft   Zero trust standards in IETF: use cases   November 2025


   2.  Resource: A set of airline, hotel, and payment gateway APIs.

5.  Problem statement

   The implementation of zero trust is hindered by several key problems
   that may be addressed by standardization.

5.1.  Lack of interoperability

   The core components of ZTA, PE, PA and PEP currently communicate with
   each other using proprietary protocols.  Different components from
   different vendors can barely communicate and interoperate with each
   other.  This makes an organization wishing to implenment ZTA system
   probably forced to source all components from one single vendor.
   This creates silos where the ZT system for employee access is
   completely separate from the ZT system for cloud service-to-service
   communication, even though the underlying principles are the same.  A
   unified approach requires common standards.

5.2.  Market Confusion

   Without clear, protocol-level definitions and specifications, the
   term "zero trust" is often used as marketing buzzword rather than
   technology or product langauge.  Products with different capabilities
   and features can be all labeled as "zero trust enabled".
   Standardization can enhance clarity by clearly document the
   requirements for components to participate in ZTA system from the
   protocol and funtionality level.

5.3.  Gap Analysis

   While the IETF and other SDOs have produced fundamental building
   blocks, there still lacks a complete, interoperable ZT standard
   framework.  A significant gap exists between the available components
   and a functioning ZTA control plane.  Specifically, the main gaps can
   be concluded as follows.

   1.  *A Standardized Control Plane Protocol:* This is the central gap.
       There is no standard protocol for a PEP to request an access
       decision from a PE, nor for the PE/PA to return a dynamic policy
       decision.  Today, this critical interaction is implemented with
       proprietary REST APIs with vendor-specific data models.









Liu, et al.                Expires 6 May 2026                   [Page 5]

Internet-Draft   Zero trust standards in IETF: use cases   November 2025


   2.  *A Standardized Signal Exchange Protocol:* A PE's decisions rely
       on continuous streams of context (signals).  While RATS defines
       attestation formats, there is no standard protocol for how
       diverse sources (EDR systems, threat feeds, IdPs) publish these
       signals and how a PE consumes them.  This prevents the creation
       of a multi- vendor "nervous system" for the ZTA.

   3.  *A Model for Dynamic, Fine-Grained Authorization:* OAuth scopes
       are often broad and long-lived.  ZT demands just-in-time, least-
       privilege access.  A standard is needed to model a request for,
       and issuance of, highly specific and ephemeral access rights
       (e.g., "grant subject X write access to record Y in database Z
       for the next 30 seconds").

   4.  *A framework for dynamic and continuous trust evaluation:* The
       core principle of Zero Trust is continuous verification.  This
       implies a mechanism for dynamically evaluating the
       trustworthiness of a subject over time.  While individual signals
       (like device posture or user location) are important, there is no
       standardized framework for aggregating these signals into a
       dynamic trust score or confidence level.  Furthermore, there is
       no standard protocol for how this trust score is updated in near-
       real-time and communicated to the Policy Engine to influence
       access decisions.  Defining such a framework would enable
       interoperable trust assessment modules and allow the PE to make
       more nuanced, risk-based decisions beyond a simple grant/deny.

6.  Proposed Scope of Work for the IETF

   To be successful, an IETF effort must have a clearly defined scope.
   We propose focusing on the communication interfaces between ZTA
   components, directly addressing the gaps identified in Section 5.3.

6.1.  Control Plane Communication Protocol

   The highest priority is to define a standard protocol for a PEP to
   request an access decision from a PE/PA and for the PE/PA to return a
   decision and policy configuration.  This could be a new protocol or a
   profile of an existing one (e.g., using HTTP APIs with a well-defined
   JSON data model).  It must specify how to represent the subject,
   resource, and context in a request, and how to represent grant, deny,
   or step-up authentication decisions in a response.









Liu, et al.                Expires 6 May 2026                   [Page 6]

Internet-Draft   Zero trust standards in IETF: use cases   November 2025


6.2.  Dynamic Context and Signal Exchange Protocol

   A ZTA's decisions are only as good as the signals it receives.  A
   standardized protocol is needed for various sensors (e.g., EDR
   agents, threat intelligence feeds, IdPs) to publish signals to a
   centralized bus or directly to the PE.  This would allow a PE to
   consume signals from multiple vendors' security tools.  This work
   should align with and leverage concepts from the IETF RATS and SCITT
   working groups.

6.3.  Authenticated Session Establishment and Management

   While TLS provides a secure channel, ZTA introduces new challenges.
   Work could be done to standardize how a PA instructs a PEP to
   establish a session.  This might involve profiling the use of
   existing protocols or defining mechanisms for securely delivering
   short-lived, session-specific credentials (e.g., tokens or
   certificates) to the subject and/or PEP as part of an access grant.

7.  IANA Considerations

   This memo includes no request to IANA.

8.  References

8.1.  Normative References

   [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>.

   [NIST-SP-800-207]
              Rose, S., Borchert, O., Mitchell, S., and S. Connelly,
              "Zero Trust Architecture", August 2020,
              <https://csrc.nist.gov/publications/detail/sp/800-207/
              final>.

8.2.  Informative References

Authors' Addresses






Liu, et al.                Expires 6 May 2026                   [Page 7]

Internet-Draft   Zero trust standards in IETF: use cases   November 2025


   Xiang Liu
   Pengcheng Laboratory
   No.2 Xingke 1 Street
   Shenzhen
   518055
   China
   Email: liux15@pcl.ac.cn


   Rongwei Yang
   Pengcheng Laboratory
   No.2 Xingke 1 Street
   Shenzhen
   518055
   China
   Email: yangrw@pcl.ac.cn


   Yu Zhang
   Pengcheng Laboratory
   No.2 Xingke 1 Street
   Shenzhen
   518055
   China
   Email: zhangy08@pcl.ac.cn


























Liu, et al.                Expires 6 May 2026                   [Page 8]


name: draft-akhavain-moussa-ai-network
rev: 01
title: AI Network for Training, Inference, and Agentic Interactions
time: 2025-11-02T18:53:57Z
group_uri: /api/v1/group/group/1027/
expires: 2026-05-06T18:53:57Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["A2A protocols", "ML traffic mgmt", "Model serving/inference", "Data formats/interop"]
tags: []
fetched_at: 2026-02-27T22:56:06.864781+00:00
abstract:
Artificial Intelligence (AI) is rapidly transforming industries and
   everyday life, fueled by advances in model architectures, training
   paradigms, and data infrastructure for generation and consumption.
   Today, machine learning models are embedded in many of our daily
   activities, ranging from simple classification systems to advanced
   architectures such as large language models (LLMs) like ChatGPT,
   Claude, Grok, and DeepSeek.  These models highlight the
   transformative potential of AI across diverse applications—from
   productivity tools to complex decision-making systems.

   However, the effectiveness and reliability of AI depend on two
   foundational processes: training and inference.  Each process
   introduces unique challenges related to data management, computation,
   connectivity, privacy, trust, security, and governance.

   In this draft, we introduce the Data and Agent Aware-Inference and
   Training Network (DA-ITN)—a unified, intelligent, multi-plane network
   architecture designed to address the full spectrum of requirements
   needed to enable AI networks.  DA-ITN provides a scalable and
   adaptive infrastructure that connects AI clients, data providers,
   model providers, agent providers, service facilitators, and
   computational resources to support end-to-end training, inference,
   and agentic interaction lifecycle operations.  The architecture
   features dedicated control, data, and operations & management (OAM)
   planes to orchestrate training, inference, and agentic services while
   ensuring reliability, transparency, and accountability.  By outlining
   the key requirements of such an AI ecosystem and demonstrating how
   DA-ITN fulfills them, this document presents an architecture for the
   future of AI-native networking—an "AI internet"—optimized for AI
   learning, efficient inference, scalable deployment, and seamless
   agent-to-agent collaboration.

full_text:
Network Working Group                                        A. Akhavain
Internet-Draft                                                 H. Moussa
Intended status: Informational                             Huawei Canada
Expires: 6 May 2026                                      2 November 2025


      AI Network for Training, Inference, and Agentic Interactions
                  draft-akhavain-moussa-ai-network-01

Abstract

   Artificial Intelligence (AI) is rapidly transforming industries and
   everyday life, fueled by advances in model architectures, training
   paradigms, and data infrastructure for generation and consumption.
   Today, machine learning models are embedded in many of our daily
   activities, ranging from simple classification systems to advanced
   architectures such as large language models (LLMs) like ChatGPT,
   Claude, Grok, and DeepSeek.  These models highlight the
   transformative potential of AI across diverse applications—from
   productivity tools to complex decision-making systems.

   However, the effectiveness and reliability of AI depend on two
   foundational processes: training and inference.  Each process
   introduces unique challenges related to data management, computation,
   connectivity, privacy, trust, security, and governance.

   In this draft, we introduce the Data and Agent Aware-Inference and
   Training Network (DA-ITN)—a unified, intelligent, multi-plane network
   architecture designed to address the full spectrum of requirements
   needed to enable AI networks.  DA-ITN provides a scalable and
   adaptive infrastructure that connects AI clients, data providers,
   model providers, agent providers, service facilitators, and
   computational resources to support end-to-end training, inference,
   and agentic interaction lifecycle operations.  The architecture
   features dedicated control, data, and operations & management (OAM)
   planes to orchestrate training, inference, and agentic services while
   ensuring reliability, transparency, and accountability.  By outlining
   the key requirements of such an AI ecosystem and demonstrating how
   DA-ITN fulfills them, this document presents an architecture for the
   future of AI-native networking—an "AI internet"—optimized for AI
   learning, efficient inference, scalable deployment, and seamless
   agent-to-agent collaboration.

Status of This Memo

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




Akhavain & Moussa          Expires 6 May 2026                   [Page 1]

Internet-Draft                 AI-Internet                 November 2025


   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 6 May 2026.

Copyright Notice

   Copyright (c) 2025 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
   2.  Training Requirements . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Centralized versus Decentralized Training . . . . . . . .   4
     2.2.  Requirements Breakdown  . . . . . . . . . . . . . . . . .   5
       2.2.1.  Data Collection/Model Dispatching . . . . . . . . . .   6
       2.2.2.  Dataset Advertisement and Discovery . . . . . . . . .   7
       2.2.3.  Handling Mobility and Service Continuity  . . . . . .   9
       2.2.4.  Privacy, Trust, and Data Ownership and Utility  . . .  10
       2.2.5.  Testing and Performance Management  . . . . . . . . .  10
       2.2.6.  Training Service QoS Guarantee  . . . . . . . . . . .  11
       2.2.7.  Charging and Billing  . . . . . . . . . . . . . . . .  11
   3.  Inference . . . . . . . . . . . . . . . . . . . . . . . . . .  12
     3.1.  Requirement Breakdown . . . . . . . . . . . . . . . . . .  12
       3.1.1.  Model Deployment and Mobility . . . . . . . . . . . .  13
       3.1.2.  AI Model (AI Agent) Discovery and Description . . . .  14
       3.1.3.  Query and Inference Result Routing  . . . . . . . . .  17
       3.1.4.  Inference Chaining/Collaborative Inference  . . . . .  18
       3.1.5.  Compute and Resource Management . . . . . . . . . . .  19
       3.1.6.  Privacy Preservation and Security . . . . . . . . . .  19
       3.1.7.  Utility Handling and QoS Requirements . . . . . . . .  20



Akhavain & Moussa          Expires 6 May 2026                   [Page 2]

Internet-Draft                 AI-Internet                 November 2025


       3.1.8.  Model Upgrade Streamlining  . . . . . . . . . . . . .  20
       3.1.9.  Charging and Billing  . . . . . . . . . . . . . . . .  21
   4.  Framework for DA-ITN (Data and Agent Aware Inference and
           Training Network) . . . . . . . . . . . . . . . . . . . .  22
     4.1.  DA-ITN Core . . . . . . . . . . . . . . . . . . . . . . .  23
     4.2.  DA-ITN Service Provider Community . . . . . . . . . . . .  24
     4.3.  DA-ITN Client Community . . . . . . . . . . . . . . . . .  25
     4.4.  DA-ITN Enablers . . . . . . . . . . . . . . . . . . . . .  26
   5.  DA-ITN high level architecture  . . . . . . . . . . . . . . .  27
     5.1.  Control plane and Intelligence Layer  . . . . . . . . . .  27
     5.2.  Data Plane  . . . . . . . . . . . . . . . . . . . . . . .  29
     5.3.  Operation and Management Plane (OAM)  . . . . . . . . . .  29
     5.4.  Summary of the DA-ITN General Framework . . . . . . . . .  30
   6.  DA-ITN for Training . . . . . . . . . . . . . . . . . . . . .  31
   7.  DA-ITN for Inference  . . . . . . . . . . . . . . . . . . . .  34
   8.  DA-ITN-Facilitation Agentic Networks  . . . . . . . . . . . .  35
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  36
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  36
   11. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . .  36
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  37
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  37

1.  Introduction

   AI has become a major focus in recent years, with its influence
   rapidly expanding from everyday tasks like scheduling to complex
   areas such as healthcare.  This growth is largely driven by advances
   in model architectures, training paradigms, and data infrastructure
   for generation and consumption.  For example, large language models
   (LLMs) like ChatGPT, Claude, Grok, and DeepSeek, which are now widely
   used for tasks such as text generation, translation, reasoning,
   coding, and data analysis, highlight AI’s transformative power to
   boost productivity and simplify real-life applications.  As such, it
   is clear that AI and machine learning are not passing trends but
   lasting and evolving forces that will only continue to evolve.  For
   clarity, in this draft, the term AI refers broadly to all types of
   models—from simple classification systems to advanced general
   intelligence models.

   However, it is crucial to recognize that the success of AI systems
   relies on two fundamental pillars: training and inference.  Both of
   these pillars have a number of factors and moving parts that need to
   be carefully coordinated, designed, and managed to ensure accuracy,
   resilience, usability, continuous evolution, trustworthiness, and
   reliability.  Moreover, once deployed, AI systems must be
   continuously monitored and governed to safeguard user safety and
   societal well-being.




Akhavain & Moussa          Expires 6 May 2026                   [Page 3]

Internet-Draft                 AI-Internet                 November 2025


   As such, aspects such as data management, computational resources,
   connectivity, security, privacy, trust, billing, and rigorous testing
   are all crucial when handling AI systems.  Thus, it is important to
   clearly understand the requirements of the AI systems from the
   training, inference, and agentic interaction prospectives as all of
   these pillars constitute an entangled framework and cannot be tackled
   in isolation.

   In this document, we present a vision of an ecosystem, especially
   designed to facilitate what we call the AI network.  We propose a
   unified, intelligent network architecture called the "Data and Agent
   aware-Inference and Training Network" (DA-ITN).  This ecosystem is
   envisioned as a comprehensive, multi-plane network with dedicated
   control, data, and operations & management (OAM) planes.  It is
   designed to interconnect all relevant stakeholders, including
   clients, AI service providers, data providers, and third-party
   facilitators.  Its core objective is to provide the infrastructure
   and coordination necessary to support an ecosystem for enabling AI of
   the future at scale.

   To that end, we begin by outlining the specific requirements of AI
   from both the training and inference standpoints.  We then introduce
   the core components of the DA-ITN and illustrate how they
   collectively meet these requirements.  Finally, this network is
   positioned as an ecosystem for agent-to-agent collaborations,
   interactions, and communications.

2.  Training Requirements

   AI model training is the foundational process through which an AI
   system learns to perform tasks by analyzing data and adjusting its
   internal parameters to minimize performance errors.  At its core,
   this process involves feeding input data into a model, and applying
   optimization algorithms to iteratively refine the model’s
   performance.  As such, the training process involves creating
   rendezvous point where data, compute, and AI models can interact.

2.1.  Centralized versus Decentralized Training

   It is clear from the above that no matter how advanced the model
   architecture may be, the success of any training process ultimately
   hinges on two fundamental components: the model and the data.  While
   the model itself is often developed and hosted in a centralized
   location—typically within the secure infrastructure of the model
   owner or designer—data is inherently distributed.  The training data
   might originate from sensors, devices, logs, events, documents, and
   other diverse sources spread across different geographies and
   domains.  To be exact, whether due to geographic dispersion,



Akhavain & Moussa          Expires 6 May 2026                   [Page 4]

Internet-Draft                 AI-Internet                 November 2025


   organizational silos, privacy constraints, or edge-device generation,
   data rarely exists in a single, clean repository.

   Today, model training can happen in one of two ways or a combination
   thereof: centralized or decentralized.  In centralized training,
   thanks to the development of robust data collection techniques and
   high-throughput connectivity networks, it is now feasible to collect
   data and bring it to where the model training would occur.  On the
   other hand, a more recent paradigm known as model-follow-data has
   emerged, advocating for the reverse: rather than transporting large
   volumes of potentially sensitive data to a central location, the
   model is dispatched to where the data resides—enabling distributed or
   federated training.

   Accordingly, to facilitate the training process, rendezvous points
   scheduling, whether centralized (data is collected and shipped to
   where the model is) or decentralize (model is shipped to where the
   data is), between distributed data, compute and storage resources,
   and AI models awaiting training needs to be arranged and managed,
   which is fundamental for successful model training.  However, this
   scheduling process introduces a number of challenges spanning
   privacy, trust, utility, and computational and connectivity resources
   management.  Moreover, as AI adoption accelerates, both centralized
   and decentralized approaches will drive increasing pressure on
   underlying connectivity infrastructure.  Therefore, to ensure
   scalable, efficient, and cost-effective AI training, it is vital to
   implement intelligent mechanisms for managing data and model
   movement, selecting relevant subsets for training, and minimizing
   unnecessary transfers.

   In the sections that follow, we explore the architectural and
   operational requirements needed to support this vision and lay the
   foundation for a high-performance, AI-native training ecosystem.

2.2.  Requirements Breakdown

   Consider a number of AI model training clients awaiting training
   service.  An AI model training client is a user with a new or a pre-
   trained model who wishes to train or continue training their AI model
   using data that can be found in the data corpus.  The data corpus
   (the global dataset), as has been previously established, consists of
   a group of datasets that are distributed across various geographical
   locations.  The AI model training client requires access to this data
   either in a centralized or distributed manner.







Akhavain & Moussa          Expires 6 May 2026                   [Page 5]

Internet-Draft                 AI-Internet                 November 2025


2.2.1.  Data Collection/Model Dispatching

   As previously discussed, data is inherently distributed.  In
   centralized training paradigms, this data must be transferred from
   its sources to centralized locations where model training occurs.
   Consider a scenario involving multiple AI model training clients,
   each awaiting centralized training of their AI model.  Each client is
   interested in a particular data set that is sufficient for the
   intended training objective.  Aggregating large volumes of data from
   geographically dispersed sources to the centralized server of each
   client introduces several significant challenges:

   *  Communication Overhead: The sheer volume of data to be transmitted
      can place substantial strain on the underlying transport networks,
      resulting in increased latency and bandwidth consumption.

   *  Redundant Knowledge Transfer: Despite originating from different
      sources, data sets may carry overlapping or identical knowledge
      content.  Transmitting such redundant content leads to unnecessary
      duplication, wasting resources without providing additional
      training value.

   *  Timely Delivery: In certain applications, the freshness of data is
      critical.  Delays in transmission can degrade the value of the
      information, as these applications are sensitive to the Age of
      Information (AoI)—the time elapsed since data was last updated at
      the destination.

   *  Multi-Modal Data Handling: Data often exists in various
      formats—such as text, images, audio, video, etc—each with distinct
      transmission requirements.  Ensuring accurate and reliable
      delivery of these diverse data types necessitates differentiated
      Quality of Service (QoS) levels tailored to the characteristics
      and sensitivity of each modality.

   *  Heterogeneous Access Media: Data may reside across diverse
      communication infrastructures—for example, some data may be
      accessible only via 3GPP mobile networks, while other data may be
      confined to wireline networks.  Coordinating data collection
      across these heterogeneous domains, while maintaining
      synchronization and consistency, presents a significant
      operational challenge.

   Importantly, many of these challenges are alleviated in decentralized
   training frameworks, where data remains local to its source and is
   not transferred over the network.  Instead, the model itself is
   distributed to the various data locations.  However, this alternate
   paradigm introduces its own set of unique challenges.



Akhavain & Moussa          Expires 6 May 2026                   [Page 6]

Internet-Draft                 AI-Internet                 November 2025


   As previously noted, modern AI models are growing increasingly large
   in size.  In decentralized training, it is often necessary to
   replicate the AI model that require training and transmit the copies
   to multiple geographically dispersed data sites.  This results in a
   different but equally significant set of logistical and technical
   hurdles:

   *  Communication Overhead: While data transfer is avoided,
      dispatching large model files across the network to multiple
      destinations can still impose substantial load on communication
      infrastructure, particularly in bandwidth-constrained
      environments.

   *  Redundant Knowledge Transfer: Data residing at different locations
      may share overlapping knowledge content.  Sending models to
      multiple sites with redundant knowledge content leads to
      inefficient use of network resources.  In some cases, even when
      knowledge content is only partially redundant, it may be more
      efficient—considering communication cost—to forego marginal
      training benefits in favor of reduced overhead.

   *  Timeliness and Data Freshness: In certain applications, the Age of
      Information (AoI) remains critical.  Prioritizing model dispatch
      to data sources with soon-to-expire or time-sensitive information
      is essential to maximize the utility of training and to maintain
      up-to-date model performance.

2.2.2.  Dataset Advertisement and Discovery

   Given the distributed nature of data, there must be a mechanism
   through which data owners can advertise information about their
   datasets to AI model training clients.  This requires the ability to
   describe the characteristics of the data—such as its knowledge
   content, quality, size, and Age of Information (AoI)—in a way that
   allows AI clients to discover and evaluate whether the data aligns
   with their training objectives.  Training objectives can be one or
   more of: target performance, convergence time, training cost, etc.

   Crucially, the dataset discovery process may need to operate across
   multiple network domains and heterogeneous communication
   infrastructures.  For example, an AI training client operating over a
   wireline connection may be interested in data residing on a 3GPP
   mobile network.  This raises an important question: How can data
   owners effectively advertise their datasets in a way that is
   discoverable across diverse domains?  To enable such cross-domain
   data visibility and discovery, the following key requirements shall
   be considered:




Akhavain & Moussa          Expires 6 May 2026                   [Page 7]

Internet-Draft                 AI-Internet                 November 2025


   *  Dataset Descriptors: These are metadata objects used by dataset
      owners to reveal essential information about their datasets to AI
      clients.  Effective dataset descriptors must be self-contained,
      privacy-preserving, and informative enough to support decision-
      making by training clients.  They should allow dataset owners to
      selectively disclose details about their data—such as type,
      relevance, quality metrics, freshness, and perhaps cost of
      utility—while concealing sensitive or proprietary information
      (privacy preservation).  Data descriptors also need to be easily
      modified as dataset can be dynamic, and the change in dataset
      needs to be effectively reflected into the dataset descriptions.
      To ensure interoperability, dataset descriptors can either follow
      a standardized format or adopt a flexible but well-defined
      structure that enables consistent interpretation across different
      systems and domains.

   *  Dataset Discovery Mechanisms: The dataset discovery refers to the
      processes by which AI training clients locate and identify
      datasets across potentially vast and heterogeneous environments.
      An effective discovery mechanism should support global-scale
      searchability and cross-domain operability, allowing clients to
      find relevant datasets regardless of where they reside or which
      communication infrastructure they are accessible through.
      Discovery protocols may be standardized within specific domains
      (e.g., mobile networks, IoT platforms) or designed to function
      interoperable across multiple domains, enabling seamless
      integration and visibility.  It should also be highlighted that,
      discovery mechanisms should be considerably up-to-date with the
      changes that would occur as the underlying data changes
      dynamically.

   *  Dataset Relationship Maps: Training often requires identifying
      groups of datasets that collectively meet specific requirements.
      Evaluating each dataset in isolation may be insufficient.
      Instead, a mechanism is needed to establish relationships among
      datasets, enabling AI training clients to assemble the appropriate
      combination of data for their tasks.  These relationships can be
      envisioned to look like maps or topologies.  This is a crucial
      step as, if an AI model client was not able to find the right
      dataset that satisfies its requirements, the client might choose
      not to submit the model for training at this time which may reduce
      resource wastage from the get-go.

   *  Timely reporting: Given the dynamic nature of data availability,
      characteristics, and accessibility, it is essential to have
      advertisement mechanisms that can promptly reflect any changes.
      Real-time or near-real-time updates ensure that the AI training
      process remains aligned with the most current data conditions,



Akhavain & Moussa          Expires 6 May 2026                   [Page 8]

Internet-Draft                 AI-Internet                 November 2025


      thereby maximizing both effectiveness and accuracy.  Timely
      reporting helps prevent training on outdated or irrelevant data
      and supports optimal decision-making in model selection and
      training pipeline configuration.

   Additionally, it should be highlighted that in AI training,
   discovering dataset alone is not enough.  For instance, third-party
   resources like compute and storage are essential, and the providers
   of those resources must be able to advertise their capabilities so AI
   clients can locate and utilize them effectively.  Just like with
   data, resource discovery requires descriptors, multi-domain
   accessibility, and timely updates to support seamless coordination
   between models, data, and infrastructure.  It should be highlighted
   that data and resource discovery is essential in both centralized and
   decentralized training, as both can be done on third party
   infrastructure.

2.2.3.  Handling Mobility and Service Continuity

   In some decentralized training applications, AI models are designed
   to traverse a predefined route, training on multiple datasets in a
   sequential or federated manner.  This introduces the need to manage
   model mobility.  However, the underlying data landscape is often
   dynamic—new data is continuously generated, existing data may be
   deleted, or datasets may be relocated to different nodes or domains.

   As a result, enabling reliable model mobility in such a fluid
   environment requires robust mobility management mechanisms.  For
   instance, while a model is en-route to a specific data location for
   training, that dataset may be moved elsewhere.  In such cases, the
   model must either be re-routed to the new location or redirected to
   an alternative dataset that satisfies similar training objectives.

   Additionally, since training occurs on remote compute infrastructure
   and can be time-intensive, unexpected resource shutdowns or failures
   may interrupt the process.  These interruptions can lead to service
   discontinuity, which must be addressed through mechanisms such as
   checkpointing, fallback resource selection, or dynamic rerouting of
   model or data to maintain training progress and system reliability.












Akhavain & Moussa          Expires 6 May 2026                   [Page 9]

Internet-Draft                 AI-Internet                 November 2025


   Additionally, model mobility may involve training on datasets that
   are distributed across heterogeneous communication infrastructures.
   Some infrastructures, such as emerging 6G networks, offer built-in
   mobility support—for example, when data resides on mobile user
   equipment (UE), its location can be tracked using native features of
   the network.  However, such mobility handling capabilities may not
   exist in other infrastructures, such as traditional wireline networks
   or legacy systems, making seamless model movement and data access
   more challenging in those environments.

2.2.4.  Privacy, Trust, and Data Ownership and Utility

   Privacy and trust are mutual responsibilities between data owners and
   model owners and shall be protected.  Granting clients access to data
   for training and knowledge building should be a regulated process,
   with mechanisms to track data ownership and future use.  Initial
   discussions on this topic have taken place in forums such as the AI-
   Control Working Group.

   Equally important is ensuring that model owners are protected from
   data poisoning.  They must have confidence that the datasets they use
   are accurately described and not misrepresented.  If data owners
   provide false metadata—intentionally or otherwise—model owners may
   unknowingly train on unsuitable or harmful datasets, leading to
   degraded model performance.  To safeguard both parties, innovative
   verification and enforcement mechanisms are needed.  Technologies
   like blockchain could offer potential solutions for establishing
   trust and accountability, but further research and exploration are
   necessary to develop practical frameworks.

2.2.5.  Testing and Performance Management

   Another critical aspect of training is testing and performance
   evaluation, typically carried out using a separate subset of the data
   known as the testing dataset.  This dataset is not used to update the
   model’s weights but to assess its performance on unseen samples.  In
   centralized training, this process is straightforward because all
   data resides in a single, accessible location, making it easy to
   partition the dataset into training and testing subsets.  However, in
   distributed training environments, where data is spread across
   multiple locations or devices, creating a representative and unbiased
   testing dataset without aggregating the data centrally becomes a
   major challenge.  Developing effective, privacy-preserving methods
   for testing in such settings requires innovative solutions







Akhavain & Moussa          Expires 6 May 2026                  [Page 10]

Internet-Draft                 AI-Internet                 November 2025


2.2.6.  Training Service QoS Guarantee

   Beyond ensuring traditional Quality of Service (QoS) for data
   transmission, a new dimension of QoS must be considered—the QoS of
   training itself.  In AI training workflows, it is crucial to
   guarantee that key performance indicators (KPIs) related to training,
   such as accuracy convergence, training time, and resource
   utilization, are met consistently.  This raises several important
   questions: * How can these training KPIs be guaranteed in dynamic or
   distributed environments?

   *  What mechanisms can be used to monitor and track training
      performance in real time?

   *  Should AI training be treated like best-effort traffic, where no
      guarantees are made and resources are allocated as available?

   *  Should training tasks receive prioritized or differentiated
      service levels, similar to high-priority traffic in traditional
      networks?

   Addressing these questions is essential to ensure predictable and
   reliable AI model development, especially as training workloads grow
   in complexity and scale.  It may require introducing new QoS
   frameworks tailored specifically to the needs of AI training systems.

2.2.7.  Charging and Billing

   The AI training process involves a diverse ecosystem of stakeholders,
   including data owners, model owners, and resource providers.  Each of
   these parties plays one or more vital roles in enabling successful
   training workflows.

   For example, communication providers contribute not only by
   transporting dataset and models across the network but also they
   themselves may also serve as data providers.  This is particularly
   evident in the emerging design of 6G networks, which integrate
   sensing capabilities with communication infrastructure.  As a result,
   6G operators are uniquely positioned to offer both connectivity and
   data, making them central players in the training pipeline.

   Despite their different roles, all parties contribute to enabling AI
   training as a service, a complex and resource-intensive process that
   is far from free.  Therefore, it is essential to establish a robust
   charging and billing framework that ensures each participant is
   fairly compensated based on their contribution.

   Several open questions arise in this context:



Akhavain & Moussa          Expires 6 May 2026                  [Page 11]

Internet-Draft                 AI-Internet                 November 2025


   *  Should training services follow a prepaid model, or adopt a pay-
      per-use structure?

   *  Should there be tiered service offerings, such as gold, silver,
      and platinum, each providing different levels of performance
      guarantees or priority access?

   *  How should these tiers be defined and enforced in terms of service
      quality, resource allocation, and response time?

   Developing fair, transparent, and scalable billing mechanisms is
   critical to facilitating collaboration across stakeholders and
   sustaining the economic viability of distributed AI training
   ecosystems.  These challenges call for further research into
   incentive structures, dynamic pricing models, and smart contract-
   based enforcement, especially in scenarios involving cross-
   organizational or cross-network cooperation.

3.  Inference

   Inference is critical because it represents the phase where the model
   begins to deliver practical value.  Unlike training, which is
   typically, a one-time or periodic, resource-intensive process,
   inference often needs to operate continuously and efficiently,
   sometimes in real-time.  Although inference is a less resource-
   intensive process, it has strict requirements that govern its
   success.  While a single AI inference might be lightweight and fast,
   serving many users, with many inference requests, demands significant
   hardware resources andposes serious scalability challenges.  In what
   follows, we explore these requirements that shall enable a successful
   AI inference ecosystem.

3.1.  Requirement Breakdown

   We envision an inference ecosystem composed of a large number of pre-
   trained AI models (or agents) distributed across a geographical
   location.  These models are capable of performing a wide range of
   tasks, such as image classification, language translation, or speech
   recognition.  Some models may specialize in the same task but vary in
   performance, accuracy, latency, or resource demands.  This diverse
   pool of models is accessed by numerous inference clients (users or
   applications) who submit inputs, referred to as queries, and receive
   task-specific outputs.

   These queries can vary greatly in complexity, structure, and
   modality, with some requiring the cooperation of multiple models to
   fulfill a single request.  The overarching goal of the ecosystem is
   to efficiently match incoming queries with the most suitable models,



Akhavain & Moussa          Expires 6 May 2026                  [Page 12]

Internet-Draft                 AI-Internet                 November 2025


   ensuring accurate, timely, and resource-aware responses.  Achieving
   this requires intelligent orchestration, load balancing, and
   potentially dynamic model selection based on factors such as
   performance, availability, cost, and user-specific requirements.  In
   what follows, we discuss the various aspects of this ecosystem and
   discuss the different requirements needed for its success.

3.1.1.  Model Deployment and Mobility

   The first step toward building a successful AI inference ecosystem is
   the optimal deployment of trained AI models (or AI agents).  In this
   context, optimality refers to both the physical or network location
   of the model and the manner in which it is deployed.  AI models vary
   significantly in size and resource requirements—ranging from
   lightweight models that are only a few kilobytes to large-scale
   models with billions of parameters.  This wide range makes deployment
   decisions critical to achieving both efficient performance and
   effective resource utilization.  Also, a unique factor to AI models/
   agents is the fact that they are software components that are not
   bounded to a certain hardware.  They can be deleted, copied, moved,
   or split across multiple compute locations.  All these unique aspects
   provide flexibility in design if the real-time status of the
   underlying network dynamics and resources is made accessible.  As
   such, the following aspects must be taken into account when handling
   model deployment and mobility:

   *  Choosing the right facility to host a model: whether it's a
      lightweight edge device, a local server, or a high-performance
      cloud data center, deployment will depend on the model's size,
      computational requirements, and expected query volume.  For
      example, smaller models might be best suited for deployment on
      edge devices closer to users, enabling low-latency responses.  In
      contrast, larger models may require centralized or specialized
      infrastructure with high compute and memory capacity.

   *  Load balancing: Once models are deployed, inference traffic begins
      to flow, with users or applications sending queries to the
      appropriate agents.  If not managed properly, this traffic can
      lead to congestion, creating bottlenecks that degrade inference
      performance through increased latency or dropped requests.  To
      avoid such scenarios, models should be deployed strategically to
      distribute the load, ensuring smooth operation.  Traditional load
      balancing techniques can be employed to redirect traffic away from
      overburdened nodes and towards underutilized ones.  However, more
      sophisticated strategies may involve replicating models and
      placing these replicas closer to regions with high query demand,
      thereby minimizing latency and easing network traffic engineering
      challenges.



Akhavain & Moussa          Expires 6 May 2026                  [Page 13]

Internet-Draft                 AI-Internet                 November 2025


   *  Mobility-aware deployment: the dynamic nature of inference traffic
      necessitates mobility-aware deployment.  For instance, consider a
      large data center acting as a centralized inference hub, hosting
      numerous models and handling a significant volume of queries.
      Over time, this hub may experience traffic overload.  In such
      cases, migrating certain models to alternative locations can help
      alleviate pressure.  However, model migration is not without its
      challenges—particularly if a model is actively serving queries at
      the time of migration.  In such situations, mobility handling
      mechanisms must be in place to ensure seamless service continuity.
      These mechanisms could involve session handovers, temporary state
      preservation, or model version synchronization, all designed to
      maintain uninterrupted service during the migration process.

   In summary, optimal model deployment requires careful consideration
   of model size, resource needs, query distribution, and real-time
   adaptability.  Achieving this lays the foundation for a responsive,
   scalable, and resilient AI inference ecosystem.

3.1.2.  AI Model (AI Agent) Discovery and Description

   Just as data descriptors and discovery mechanisms are essential
   during the training phase, AI model inference clients also require a
   robust discovery mechanism during the inference stage.  In an
   ecosystem populated by a large and diverse pool of models—each with
   unique capabilities and specializations—clients are presented with
   significant flexibility and choice in selecting the most suitable
   models for their queries.  However, to make informed decisions,
   clients must have access to information that enables them to
   distinguish between models based on criteria such as performance,
   specialization, availability, and resource requirements.

   The AI model discovery process becomes even more complex when it
   needs to function across multiple network domains and heterogeneous
   communication infrastructures.  For instance, a client connected via
   a wireline network might need to interact with a model deployed on a
   mobile 3GPP network.  Such scenarios raise a critical question: How
   can model owners advertise their models in a way that ensures
   discoverability and interoperability across diverse domains?

   Addressing this challenge requires the development of standardized
   model advertisement and discovery protocols that can operate
   seamlessly across infrastructure boundaries.  These protocols must
   accommodate differences in network technology, latency constraints,
   and security requirements while providing consistent and reliable
   access to model information.  Ensuring cross-domain discoverability
   is crucial to unlocking the full potential of a globally distributed
   inference ecosystem.



Akhavain & Moussa          Expires 6 May 2026                  [Page 14]

Internet-Draft                 AI-Internet                 November 2025


   To enable such cross-domain AI model visibility and discovery, the
   following key requirements must be considered:

   *  AI Model Descriptors: These are metadata objects used by model
      owners to reveal essential aspects about their datasets to AI
      inference clients.  Effective data descriptors must be self-
      contained, privacy-preserving, and informative enough to support
      decision-making by inference clients.  They should allow model
      owners to selectively disclose details about their model—such as
      skills, performance reviews, trust level, relevance, quality
      metrics, freshness, and perhaps cost of utility—while concealing
      sensitive or proprietary information.  To ensure interoperability,
      model descriptors can either follow a standardized format or adopt
      a flexible but well-defined structure that enables consistent
      interpretation across different systems and domains.

   *  AI Model Discovery Mechanisms: These refer to the processes by
      which AI inference clients locate and identify models/agents
      across potentially vast and heterogeneous environments.  An
      effective discovery mechanism should support global-scale
      searchability and cross-domain operability, allowing clients to
      find relevant model/agents regardless of where they reside or
      which communication infrastructure they are accessible through.
      Discovery protocols may be standardized within specific domains
      (e.g., mobile networks, IoT platforms) or designed to function
      interoperable across multiple domains, enabling seamless
      integration and visibility.

   *  AI Model relationship maps: As queries may requiring the
      collaboration between multiple models/agents, relationships
      between models/agents with respect to different task might present
      useful tools as to help clients choose the appropriate subset of
      models/agents that would handle their queries.

   *  Timely Reporting: Similar to AI datasets, the status of an AI
      model can change over time—for example, due to shifts in workload
      or resource availability.  It is important that such changes are
      reported promptly and accurately, allowing clients to make
      informed decisions based on the model’s current state.  This is
      essential for ensuring efficient model selection and maintaining
      high-quality, reliable inference outcomes.










Akhavain & Moussa          Expires 6 May 2026                  [Page 15]

Internet-Draft                 AI-Internet                 November 2025


   It is important to emphasize that AI model discovery differs
   fundamentally from data discovery.  While data are passive objects
   that require external querying or manipulation, AI models are
   intelligent, autonomous entities capable of making decisions based on
   their own capabilities, status, and context.  This distinction opens
   up new and more dynamic possibilities for how models are discovered
   and engaged in an inference ecosystem.

   In traditional data discovery, clients search for and retrieve
   relevant datasets based on metadata or predefined criteria.  However,
   in the case of model discovery, the process can be much more
   interactive and flexible.  One approach involves the client actively
   discovering models by querying a directory or registry using model
   descriptors.  Based on these descriptors, the client selects one or
   more models to handle a specific inference task.  However, given that
   models can reason and act independently, model discovery does not
   have to be limited to client-driven selection.  An alternative
   approach is to reverse the flow of interaction.  Instead of clients
   seeking out models, they can publish their tasks to a shared task
   pool, accessible to all available models.  These tasks include
   descriptors that define the type of work to be done, expected
   outputs, and quality-of-service requirements.  Models can then
   autonomously scan this pool, evaluate whether they are well-suited
   for specific tasks, and choose to express interest in executing them.
   This self-selection process allows models to play an active role in
   task matching, improving system scalability and efficiency.

   The final assignment of a task can be handled in different ways.
   Clients may retain full control and approve or reject interested
   models based on their preferences or priorities.  Alternatively, the
   system may operate in a fully autonomous mode, where tasks are
   assigned automatically to the first or best-matching model, without
   requiring client intervention—depending on the client's chosen
   policy.

   This agent-driven paradigm reflects the shift toward more
   decentralized and intelligent AI ecosystems, where models are not
   merely passive computation endpoints but active participants in task
   negotiation and resource allocation.  Such a system not only enhances
   scalability and flexibility but also allows for more efficient
   utilization of the available model pool, especially in heterogeneous
   and dynamic environments.









Akhavain & Moussa          Expires 6 May 2026                  [Page 16]

Internet-Draft                 AI-Internet                 November 2025


3.1.3.  Query and Inference Result Routing

   A significant challenge in AI inference networks lies in efficiently
   routing client queries to the appropriate inference models and
   ensuring the corresponding results are reliably delivered back to the
   client.  This becomes particularly complex in scenarios involving
   mobility and multi-domain environments, where both the client and the
   model may exist across different types of network infrastructures.
   The key challenges and considerations include:

   *  Query Routing Across Heterogeneous Networks: When a client
      accesses the inference ecosystem through a mobile network such as
      3GPP 6G, and the target model is hosted in a wireline or cloud-
      based infrastructure, routing the query across these distinct
      domains is non-trivial.  Differences in network architecture,
      protocols, and service guarantees complicate the end-to-end flow.

   *  Mobility Management During Inference Execution: While mobile
      networks like 6G are designed to handle user mobility, inference
      tasks may take time to process—particularly when using large
      models or performing complex computations.  During this time, the
      client may change physical location, switch devices, or even go
      offline.  Ensuring that inference results can still reach the
      client under these dynamic conditions poses a significant
      challenge.

   *  Handling Client State Changes: If a client becomes idle or
      disconnects entirely during inference, the system must decide what
      to do with the completed result.  Should it be queued, buffered,
      forwarded to another linked device, or simply discarded?  A robust
      mechanism is needed to track client state, maintain context, and
      guarantee result delivery or at least graceful degradation.

   *  Support for Live and Streaming Inference: Some use cases, such as
      real-time audio transcription, involve live streaming of data from
      the client to the model and vice versa.  These sessions require
      sustained, low-latency connections and are particularly sensitive
      to interruptions caused by mobility or handoffs between networks.
      Ensuring session continuity and maintaining streaming quality
      across network boundaries is a complex but critical aspect of
      real-world inference deployments.










Akhavain & Moussa          Expires 6 May 2026                  [Page 17]

Internet-Draft                 AI-Internet                 November 2025


   *  Cross-Domain Connectivity and Session Management: The involvement
      of multiple network operators and domains introduces questions
      around interoperability, session tracking, and handover
      coordination.  There is a need for intelligent infrastructure
      capable of end-to-end session management, including maintaining
      metadata, context, and service quality as the session traverses’
      different networks.

3.1.4.  Inference Chaining/Collaborative Inference

   Another critical aspect of an AI inference ecosystem is the need for
   model collaboration to fulfill complex or multi-faceted tasks.  Not
   all inference requests can be handled by a single model; in many
   cases, collaboration between multiple models is necessary.
   Effectively managing this task-based collaboration is essential to
   ensure accurate, efficient, and scalable inference services.  Model
   collaboration can take several distinct forms:

   *  Inference Chaining: In this model, the output of one model serves
      as the input to the next in a sequential pipeline.  Each model
      performs a specific stage of the task, and the final
      result—produced by the last model in the chain—is returned to the
      client.  This is common in multi-stage tasks such as image
      processing followed by object detection and then classification.

   *  Parallel Inference: Here, a complex task is decomposed into
      multiple subtasks, each of which is assigned to a specialized
      model.  These models operate concurrently, and their outputs are
      aggregated to form a unified inference result.  This approach is
      particularly useful when dealing with large data sets or when a
      task spans different domains of expertise.

   *  Hierarchical inference: A model is assigned as a task manager and
      is responsible for delegating tasks to service models

   *  Collaborative Inference: In this more dynamic and decentralized
      form, the task is assigned to a group of models that are capable
      of discovering one another, assessing their respective
      capabilities, and coordinating among themselves to devise a shared
      strategy for completing the task.  This model requires more
      sophisticated communication, negotiation, and orchestration
      mechanisms.

   Regardless of the collaboration format, the success of such multi-
   model interactions depends on the availability of a robust management
   infrastructure.  This infrastructure must enable seamless
   coordination between models, even when:




Akhavain & Moussa          Expires 6 May 2026                  [Page 18]

Internet-Draft                 AI-Internet                 November 2025


   *  The models are hosted by different providers,

   *  They are deployed across heterogeneous communication networks,

   *  They use varying protocols, or

   *  They have differing performance characteristics.

   Such a management system must abstract away the underlying
   complexities and provide standardized interfaces, discovery
   mechanisms, communication protocols, and coordination frameworks that
   allow models to interact effectively.  Without this, collaborative
   inference would be brittle, inefficient, or impossible to scale.  In
   essence, the ability to orchestrate model collaboration across
   diverse environments is a cornerstone of a flexible, intelligent, and
   robust AI inference ecosystem.

3.1.5.  Compute and Resource Management

   In many scenarios, the compute infrastructure used to host and run
   inference models is managed by third-party providers, not the model
   owners themselves.  These compute providers are responsible for
   meeting the Quality of Service (QoS) levels agreed upon with the
   model owners—such as latency, uptime, throughput, and reliability.

   *  Ensuring these service levels are consistently met raises the
      question of accountability.  If performance degrades due to
      compute resource issues—such as overloaded hardware or network
      outages—who is responsible for the failed inference tasks?

   *  There must be clear, enforceable service-level agreements (SLAs)
      that define roles, responsibilities, and penalties for non-
      compliance.

   *  Mechanisms for performance monitoring, auditing, and dispute
      resolution need to be integrated into the ecosystem to make such
      arrangements viable and trustworthy.

3.1.6.  Privacy Preservation and Security

   While models are the intellectual property of their owners, they may
   operate on infrastructure owned by others.  This raises significant
   concerns around privacy and intellectual property protection.

   *  Sensitive model details such as architecture, weights, and
      optimization strategies must be protected from exposure or reverse
      engineering by untrusted compute hosts.




Akhavain & Moussa          Expires 6 May 2026                  [Page 19]

Internet-Draft                 AI-Internet                 November 2025


   *  Techniques such as secure computing, encrypted model execution,
      and remote attestation protocols may be necessary to ensure that
      models run securely without revealing proprietary details.

   *  Model owners must also be assured that inference inputs and
      outputs remain confidential, particularly in applications
      involving personal or sensitive data.

3.1.7.  Utility Handling and QoS Requirements

   Utility handling refers to the regulation, protection, and fair
   governance of how models are used, accessed, and monitored throughout
   the ecosystem.  This encompasses several critical questions:

   *  How can we guarantee that a model deployed on remote
      infrastructure is not being tampered with, copied, or
      intentionally repurposed?

   *  How do we ensure that workload distribution is fair across
      available models, preventing monopolization by a few and giving
      equal visibility and opportunity to all participating models?

   *  What protections are in place to ensure that models are not being
      poisoned, exploited, or involved in illegal activities, either
      through malicious inputs or untrusted outputs?

   *  How do we ensure the integrity of inference results, so that
      outputs are delivered to clients without alteration, manipulation,
      or censorship?  Addressing these concerns may require digital
      rights management (DRM) for AI models, usage monitoring tools, and
      potentially blockchain-based logging or audit trails to ensure
      transparency and traceability.

   On the other hand, the definition of Quality of Service (QoS), when
   it comes to inference tasks, is very broad and can take many forms.
   For instance, QoS could be to guarantee a certain accuracy of a
   response, or time of the response, or expertise level needed.  We
   believe that the topic of QoS guarantee requires extensive studying
   and analysis.

3.1.8.  Model Upgrade Streamlining

   AI models are not static; they undergo continuous upgrades,
   improvements, and fine-tuning to maintain accuracy, adapt to new
   data, or support evolving tasks.






Akhavain & Moussa          Expires 6 May 2026                  [Page 20]

Internet-Draft                 AI-Internet                 November 2025


   *  The ecosystem must support seamless model versioning, including
      adding, removing, or modifying model agents without disrupting
      ongoing services.

   *  Updated model profiles must be instantly reflected in the
      discovery layer, ensuring clients always have access to the most
      current and accurate model descriptions.

   *  For large models, upgrade procedures must be efficient and
      bandwidth-conscious, potentially using incremental update
      techniques to avoid full redeployment.

   *  Moreover, strategies must be in place to handle hot-swapping of
      models, where an old model is gracefully decommissioned and
      replaced by a new one—without causing inference failures or data
      loss during the transition.

3.1.9.  Charging and Billing

   The AI inference process involves a diverse ecosystem of
   stakeholders, including model owners, compute providers, and
   communication providers.  Each of these parties plays one or more
   vital roles in enabling successful inference workflows.  Therefore,
   it is essential to establish a robust charging and billing framework
   that ensures each participant is fairly compensated based on their
   contribution.

   Several open questions arise in this context:

   *  Should inference services follow a prepaid model, or adopt a pay-
      per-use structure?

   *  Will there be tiered service offerings—such as gold, silver, and
      platinum—each providing different levels of performance guarantees
      or priority access?

   *  How should these tiers be defined and enforced in terms of service
      quality, resource allocation, and response time?

   *  What about discovery framework providers?  Would they be offering
      a free service like google search or would it be more structured?










Akhavain & Moussa          Expires 6 May 2026                  [Page 21]

Internet-Draft                 AI-Internet                 November 2025


   Developing fair, transparent, and scalable billing mechanisms is
   critical to fostering collaboration across stakeholders and
   sustaining the economic viability of distributed AI training
   ecosystems.  These challenges call for further research into
   incentive structures, dynamic pricing models, and smart contract-
   based enforcement, especially in scenarios involving cross-
   organizational or cross-network cooperation.

4.  Framework for DA-ITN (Data and Agent Aware Inference and Training
    Network)

   The DA-ITN is envisioned as a multi-domain, multi-technology network
   operating at the AI layer, designed to address the various layers of
   complexity inherent in modern AI ecosystems.  As mentioned earlier,
   the network aims to support a wide range of requirements, some of
   which are outlined above, across AI training, inference, and agent-
   to-agent interaction.

   The network consists of set of nodes and equipment connected via one
   or more traditional underlay networks as depicted below.

+---------------------------------------------+
| DA-ITN nodal view                           |
|                                             |
|  +----------------+     +----------------+  |    DA-ITN node types
|  | DA-ITN Node (A)|<--->| DA-ITN Node (B)|  |      A- Data node
|  +----------------+  |  +----------------+  |      B- Compute node
|                      |                      |      C- Storage node
|                      |                      |      D- Model node
|  +----------------+  |  +----------------+  |      E- Evaluation node
|  | DA-ITN Node (E)|<--->| DA-ITN Node (G)|  |      F- Agent node
|  +----------------+  |  +----------------+  |      G- Multi-purpose node
|                      |                      |
|                      |                      |
|  +----------------+  |  +----------------+  |
|  | DA-ITN Node (F)|<--->|DA-ITN Node(C+D)|  |
|  +----------------+     +----------------+  |
|                                             |
+---------------------------------------------+

                Figure 1: Figure 1: DA-ITN nodal view

   Nodes with DA-ITN along with its core functionality interact together
   to provide different training, inference, and agentic services.  In
   this manner, DA-ITN can be divided into four interacting major
   building blocks as shown bellow.





Akhavain & Moussa          Expires 6 May 2026                  [Page 22]

Internet-Draft                 AI-Internet                 November 2025


           +--------------------+         +--------------------+
           |   DA-ITN Service   |         |   DA-ITN Client    |
           | Provider Community |         |     Community      |
           +--------------------+         +--------------------+
               ↑     ↑                               ↑     ↑
               |     |                               |     |
               |     |                               |     |
               |     +-------------------------------+     |
               |                     |                     |
               |                     |                     |
               |                     ↓                     |
               |           +--------------------+          |
               |           |     DA-ITN Core    |          |
               |           |                    |          |
               |           +--------------------+          |
               |                     ↑                     |
               |                     |                     |
               |                     |                     |
               ↓                     ↓                     ↓
           +---------------------------------------------------+
           |                    DA-ITN Enablers                |
           +---------------------------------------------------+

      Figure 2: Figure 2: DA-ITN high level architecture and building
                                   blocks

4.1.  DA-ITN Core

   This block contains DA-ITN main internal modules, functions, and
   services.  Dedicated logical planes in this block handle interactions
   between its different modules and functions.  Interactions between
   different modules and functions in this block are not visible or
   accessible to entities in other blocks.  DA-ITN core offers its
   services to external entities via clear and well defined interfaces
   and protocols.  The following illustrates different modules and
   functions of DA-ITN core block.















Akhavain & Moussa          Expires 6 May 2026                  [Page 23]

Internet-Draft                 AI-Internet                 November 2025


+-----------------------------------+
|            DA-ITN Core            |
|                                   |
|   +----------+ +--------------+   |
|   | X-RCE    | |Registration &|   |     X-RCE:  Training, model, query, etc.
|   |          | |Authentication|   |             route compute engine
|   +----------+ +--------------+   |     XOD:    Model, agent deployment
|   +----------+ +--------------+   |             optimizer
|   | X-DO     | |Discovery &   |   |     S-FAM:  Different Service feasibility
|   |          | |Advertisement |   |             assessment module
|   +----------+ +--------------+   |     TAG:    Training algorithm generator
|   +----------+ +--------------+   |     PVM:    Performance verification
|   | S-FAM    | |Billing &     |   |             Module
|   |          | |Accounting    |   |     DDRT:   Data dynamics and resource
|   +----------+ +--------------+   |             topology
|   +----------+ +--------------+   |
|   | TAG      | |Reputation &  |   |
|   |          | |Trust Mgmt.   |   |
|   +----------+ +--------------+   |
|   +----------+ +--------------+   |
|   | PVM      | | Upgrade Mgmt.|   |
|   |          | |              |   |
|   +----------+ +--------------+   |
|   +----------+ +--------------+   |
|   | Resource | |Mobility Mgmt.|   |
|   | Mgmt.    | |              |   |
|   +----------+ +--------------+   |
|   +----------+ +--------------+   |
|   |   DDRT   | | Tools Mgmt.  |   |
|   |          | |     ???      |   |
|   +----------+ +--------------+   |
|            +---------+            |
|            |   OAM   |            |
|            +---------+            |
+-----------------------------------+

    Figure 3: Figure 3: DA-ITN core and its different modules and
                               function

4.2.  DA-ITN Service Provider Community

   Providers for different services such as data, model, agent, and
   resource providers reside within the Service Provider Community block
   of the DA-ITN.  Service providers join the network via a registration
   and authentication process offered by DA-ITN core.  The service
   providers use DA-ITN to advertise their services, capabilities, etc.
   across the overall network.  They can also register for notifications
   to get updates e.g. arrival of new models, training data, agents,



Akhavain & Moussa          Expires 6 May 2026                  [Page 24]

Internet-Draft                 AI-Internet                 November 2025


   etc.  DA-ITN dispenses revenue to providers for the services rendered
   via its billing and accounting module.

   The following figure shows different modules of DA-ITN service
   provider community.

                     +-------------------------------+
                     |       DA-ITN Service          |
                     |     Provider Community        |
                     |                               |
                     |  +----------+ +----------+    |
                     |  | Data     | | Model    |    |
                     |  | providers| | providers|    |
                     |  +----------+ +----------+    |
                     |  +----------+ +----------+    |
                     |  | Agent    | | Resource |    |
                     |  | providers| | providers|    |
                     |  +----------+ +----------+    |
                     |  +--------------+             |
                     |  | Tools        |             |
                     |  | providers ???|             |
                     |  +--------------+             |
                     +-------------------------------+

           Figure 4: Figure 4: DA-ITN Service Provider Community

   The tool module within the provider block requires further
   investigation and analysis.  Agentic protocols such as Model Context
   Protocol(MCP) provide access to MCP tools from the agent interaction
   point of view.  Whether DA-ITN needs to support additional
   capabilities w.r.t agents or whether it needs to support distinct
   tools w.r.t training and inference is an open question for now.  Will
   there be a need for unified tools' protocols that fits all utilities,
   or a protocol per utility?

4.3.  DA-ITN Client Community

   This block represents the client side of DA-ITN.  The clients are
   network participants requiring training, inference, agent-to-agent
   interactions, and those who need access to resources such as storage,
   compute, etc. offered by resource providers in DA-ITN.

   DA-ITN enables clients to discover potential providers by tuning into
   DA-ITN discovery, and advertisement module, allowing them to select
   the best match based on their requirements.  Alternatively, clients
   may delegate the matching process to DA-ITN, requesting DA-ITN to
   identify the most suitable provider based on their criteria.  For
   example, a client using the model training service may opt to fully



Akhavain & Moussa          Expires 6 May 2026                  [Page 25]

Internet-Draft                 AI-Internet                 November 2025


   control the training process and make all decisions independently.
   Alternatively, the client can delegate the training responsibilities
   to the DA-ITN core.  In the case of delegation, modules such as
   X-RCE, DDRT, PVM, S-FAM, and TAG can work collaboratively to train
   the model on the client’s behalf and deliver the finalized, trained
   model back to them.

                     +-------------------------------+
                     |       DA-ITN Client           |
                     |         Community             |
                     |                               |
                     |  +----------+ +----------+    |
                     |  | Data     | | Model    |    |
                     |  | clients  | | clients  |    |
                     |  +----------+ +----------+    |
                     |  +----------+ +----------+    |
                     |  | Agent    | | Resource |    |
                     |  | clients  | | clients  |    |
                     |  +----------+ +----------+    |
                     |  +--------------+             |
                     |  | Tools        |             |
                     |  | Clients   ???|             |
                     |  +--------------+             |
                     +-------------------------------+

                Figure 5: Figure 5: DA-ITN Client Community

   It must be noted that a node/entity in DA-ITN can act both as
   provider and/or a client.  For example, a node providing data as its
   service, might need access to a resource provider service.  Or a
   model provider enabling inference might employ the services of data
   providers for Retrieval-Augmented Generation (RAG).

   Similar to the provider community block in DA-ITN, the tools module
   withing the client community requires further study.

4.4.  DA-ITN Enablers

   This layer represents external and underlying services that DA-ITN
   itself employs to accomplish its different tasks.  Various networking
   layers, access technologies, location, and sensing functions are
   examples of such services.









Akhavain & Moussa          Expires 6 May 2026                  [Page 26]

Internet-Draft                 AI-Internet                 November 2025


+-------------------------------------------------------------------------+
|                             DA-ITN Enablers                             |
|                                                                         |
|  +---------------------------+  +-----------+  +-----------+            |
|  | Communications/Networking |  | Location  |  |  Sensing  |            |
|  |                           |  |           |  |           |            |
|  | +---------+  +----------+ |  | +-------+ |  | +-------+ |            |
|  | | Mobile  |  | Internet | |  | | GPS   | |  | | IoT   | |            |
|  | | network |  +----------+ |  | +-------+ |  | +-------+ |            |
|  | +---------+  +----------+ |  | +-------+ |  | +-------+ |            |
|  | | NTN     |  | WiFi     | |  | |Sensors| |  | | ISAC  | |  Others??? |
|  | +---------+  +----------+ |  | +-------+ |  | +-------+ |            |
|  | +-----------------------+ |  | +-------+ |  | +-------+ |            |
|  | |        Others?        | |  | |Mobile | |  | |Others?| |            |
|  | +-----------------------+ |  | |network| |  | +-------+ |            |
|  |                           |  | +-------+ |  |           |            |
|  |                           |  | +-------+ |  |           |            |
|  |                           |  | |Others?| |  |           |            |
|  |                           |  | +-------+ |  |           |            |
|  +---------------------------+  +-----------+  +-----------+            |
+-------------------------------------------------------------------------+

                 Figure 6: Figure 6: DA-ITN Enablers

5.  DA-ITN high level architecture

   To manage these complexities and cater for the requirements, we
   propose structuring the DA-ITN around four core components: a Control
   Plane (CP), a Data Plane (DP), an Operations and Management (OAM)
   Plane, and an Intelligence Layer.  It is important to note that the
   DA-ITN is agnostic to the underlying communication infrastructure,
   allowing it to operate seamlessly over heterogeneous networks,
   whether mobile, wire-line, or satellite-based. he DA-ITN integrates
   with these underlying infrastructures through any available means,
   embedding its control and intelligence capabilities to coordinate and
   manage AI-specific services in a flexible and scalable manner.

5.1.  Control plane and Intelligence Layer

   The Control Plane and Intelligence Layer work together to enable an
   efficient, reliable, and timely information collection
   infrastructure.  They continuously gather up-to-date information on
   data availability, model status, agent conditions, resource
   utilization, and reachability across all participating entities.  The
   collected information comes in the form of dynamic descriptors for
   data, models, and resources, essential components for enabling
   intelligent, context-aware decision-making within the AI ecosystem as
   has previously been highlighted.  Also, with the help of data,



Akhavain & Moussa          Expires 6 May 2026                  [Page 27]

Internet-Draft                 AI-Internet                 November 2025


   resource, and reachability topology engine (DRRT) housed within the
   intelligence layer, the gathered information and descriptors can be
   used to construct meaningful relationships across the ecosystem.
   These are captured in the form of dynamic topologies or map-like
   structures, which help optimize decision-making processes across
   training, inference, and agent-to-agent collaboration tasks.  This
   design provides a continuous awareness that is very essential for the
   success, reliability, accuracy, and responsiveness of the AI
   functionalities and services enabled by the DA-ITN within the AI
   ecosystem.

   The DA-ITN control plane also lays a foundation for an advanced
   discovery infrastructure where the generated descriptors can be made
   easily accessible to all authorized participants to facilitate their
   required AI service For example, AI clients subscribed to training
   services can access up-to-date data descriptors and resource
   topologies, enabling them to select appropriate datasets and compute
   resources that align with their performance and accuracy goals.
   Similarly, inference clients or agents seeking collaboration can
   discover models based on capabilities, or submit task descriptors
   that enable models to respond intelligently and autonomously.

   Aside from descriptor collection, topology creation, and discovery,
   the DA-ITN control plane also supports a secure and trusted
   environment where clients, data providers, model providers, and
   resource providers can engage in AI processes without compromising
   integrity or accountability.  It also plays a key role in managing
   charging, billing, and rights enforcement, ensuring that all
   contributors to the AI service chain are fairly compensated and
   protected.

   It is worth noting that the DA-ITN’s Control Plane is not constrained
   by specific protocol stacks.  Instead, it provides a flexible
   connectivity and coordination infrastructure upon which various AI-
   related protocols—such as Agent-to-Agent (A2A), Model Control
   Protocol (MCP), or AI Coordination Protocol (ACP)—can operate.
   Regardless of the protocol used, implementations must meet the core
   DA-ITN requirements, including timely information exchange, flexible
   descriptor encapsulation, support for multi-model and multi-domain
   environments, and robust security and privacy protections.  The DA-
   ITN is also designed to support both centralized and decentralized
   modes of operation, offering high adaptability across different
   deployment contexts.

   It’s also important to clarify that the Intelligence Layer
   encompasses all previously mentioned DA-ITN core functions, along
   with any additional intelligence required to support the full range
   of DA-ITN services.  The term “Intelligence Layer” is intentionally



Akhavain & Moussa          Expires 6 May 2026                  [Page 28]

Internet-Draft                 AI-Internet                 November 2025


   broad to allow flexibility in its design and contents.  Nonetheless,
   its role is clearly defined: it serves as a functional layer that
   interfaces with other DA-ITN components through the control plane,
   data plane, and OAM plane to fulfill its responsibilities.

5.2.  Data Plane

   On the other hand, the Data Plane of the DA-ITN provides support for
   mobility management and intelligent scheduling, enabling the dynamic
   creation of rendezvous points where data, queries, models, agents,
   and compute infrastructure can be brought together with minimal
   latency and overhead.  Thanks to its infrastructure-agnostic nature,
   the DA-ITN leverages existing communication networks—such as those
   offered by 6G or edge service providers—as tools to enable model
   mobility, data mobility, and agent-to-agent coordination.  This
   capability is essential for supporting scenarios where mobility or
   geographical dispersion of resources would otherwise lead to
   performance degradation or inefficiency.

   The construction of the Data Plane may fall under the responsibility
   of the DA-ITN core or Intelligence Layer, which would orchestrate the
   necessary resources from the DA-ITN Enabler block to build the
   required structure.  Alternatively, the Enabler block itself may
   possess sufficient intelligence to autonomously construct the Data
   Plane as needed.

5.3.  Operation and Management Plane (OAM)

   Finally, the Operations and Management (OAM) layer plays a critical
   role in supporting the day-to-day operational needs of the AI
   ecosystem.  This layer is responsible for a wide range of essential
   functions, including monitoring, registration, configuration, fault
   management, and lifecycle maintenance of models, data, and services.
   It serves as the management backbone of the DA-ITN, ensuring
   transparency, accountability, and operational control throughout the
   system.

   Consider the scenario of an AI model training client deploying a
   model into the ecosystem for training.  Through the capabilities of
   the OAM layer, the client can continuously monitor the training
   performance of their model in real time—tracking key performance
   indicators such as convergence speed, loss metrics, resource usage,
   and network traversal.  The model’s location within the ecosystem can
   be dynamically tracked, allowing clients to know exactly where their
   model resides or which data centers or devices it is interacting
   with.





Akhavain & Moussa          Expires 6 May 2026                  [Page 29]

Internet-Draft                 AI-Internet                 November 2025


   Moreover, the OAM layer enables interactive control.  Clients can use
   it to adjust training parameters on the fly, such as learning rates,
   data sampling strategies, or the choice of collaborative partners.
   They can even pause, resume, or terminate the training process at
   will, giving them full agency over the lifecycle of their models.
   This flexibility is crucial in adaptive AI systems where
   responsiveness and real-time decision-making are valued.

   In this way, the OAM layer effectively functions as the control
   dashboard or command-line terminal of the DA-ITN-enabled AI
   ecosystem.  Whether through a graphical user interface (GUI), APIs,
   or automated orchestration scripts, the OAM provides the necessary
   tools for fine-grained management, status visualization, and policy
   enforcement.

   Beyond individual model control, the OAM layer also facilitates
   system-wide coordination and policy administration.  OAM in
   coordination with a potential policy enforcement module man help
   ensuring compliance with service-level agreements (SLAs), enforcing
   data governance policies, and managing access rights across domains.
   It plays a foundational role in building trustworthy, maintainable,
   and operationally efficient AI services across diverse infrastructure
   providers and stakeholders.

5.4.  Summary of the DA-ITN General Framework

   Accordingly, the DA-ITN is well positioned and designed to provide a
   range of intelligent services that can be leveraged by both AI
   clients and service providers.  It forms the foundation for a
   scalable, decentralized AI internet, driving the emergence of a
   vibrant and cooperative agent-based ecosystem.  By enabling the
   formation of adaptive and intelligence-driven topologies and being
   agnostic to the infrastructure, the DA-ITN facilitates more effective
   decisions in AI training, inference, and agent-to-agent
   interactions—ultimately supporting a more responsive, resilient, and
   capable AI infrastructure that can scale with future demands.

   In the following sections, we provide more detailed insights into the
   specific DA-ITN components that support training and inference
   services.











Akhavain & Moussa          Expires 6 May 2026                  [Page 30]

Internet-Draft                 AI-Internet                 November 2025


6.  DA-ITN for Training

   The training architecture of the DA-ITN consists of five layers: i)
   the terminal layer (DA-ITN provider and client communities); ii) the
   network layer (Enablers); iii) the data, resource, and reachability
   topology layer (DRRT); iv) the DA-ITN intelligence layer (DA-ITN
   core); and v) the OAM layer.  The layers interact together using
   control and data planes (CP and DP respectively) as is discussed in
   the following.

   First, the network layer, which is at the heart of the DA-ITN
   training system, is responsible for providing connectivity services
   to the four other layers.  It provides both control and data plane
   connectivity to enable various services.  The network layer connects
   to the terminal and DRRT layers via CP and DP links, and connects to
   the intelligence layer via a CP link only.  The network layer also
   enables the overarching OMA layer by enabling a multi-layer
   connectivity structure.

   Second, the terminal layer from the point of view of training, is the
   lowest layer in the architecture, and it contains the terminal
   components of the system.  These include nodes that host the training
   data, facilities that provide computing resources where the model can
   be trained, and newly proposed components that we refer to as the
   model performance verification modules (MPVMs), where the model
   testing phase takes place.  It should be noted that facilities
   providing computing resources come in various forms including private
   property such as personal devices, in a distributed form such as in
   the case of mobile edge computing in 6G networks, on the cloud such
   as on the AWS cloud, or anywhere that is accessible by both the data
   and the model and holds sufficient compute for training.  As for the
   MPVU, this unit is important when conducting distributed training as
   it takes the role of a trusted proxy node that holds a globally
   constructed testing dataset - the dataset is constructed via
   collecting sample datasets from each participating node - and
   provides safe and secure access to it.  Last, the terminal layer also
   hosts the AI training clients.

   The terminal layer relies on the network layer to build an
   overarching knowledge-sharing network.  To be exact, the network
   layer provides three main services to the terminal layer, namely: i)
   moving models and data between the identified rendezvous compute
   points where training can happen; ii) moving the models towards the
   MPVU units where performance evaluation can be conducted to keep
   track of the training progress; and iii) enabling AI training clients
   to submit their models, monitor the training progress, modify
   training requirements, and collect the trained models.  Control and
   data traffic exist for each one of these services.  For instance,



Akhavain & Moussa          Expires 6 May 2026                  [Page 31]

Internet-Draft                 AI-Internet                 November 2025


   moving a model toward a compute facility requires authorization for
   the utility of the resources; hence, authorization control data is
   required to be exchanged over the Terminal-NET CP links.  The service
   also requires the physical transmission of the model to the computing
   facility which is handled over the Terminal-NET DP link.  Similar
   situations can be extrapolated for the other provided services.  It
   is worth noting that the network layer can be built on top of any
   access network technology including 3GPP cellular networks, WiFi,
   wireline, peer-to-peer, satellites, and non-terrestrial networks
   (NTN), or a combination of the above.  These networks can be used to
   build dedicated CP and DP links strictly designed to enable the DA-
   ITN training system and its services.

   Third, the DRRT layer holds all the information required to make
   accurate decisions and sits between the intelligence layer and the
   terminal layer.  It consists of a DRRT-manager (DRRT-M) unit which is
   the brain of this layer and interfaces with the other layers over CP
   links.  The DRRT layer provides the intelligence layer with
   visibility and accessibility services to specific information about
   the underlying terminal layer's data, resource, and reachability
   status.  To be exact, the DRRT layer holds information regarding the
   type, quality, amount, age, dynamics, and any other essential
   information about the data available for training.  It also provides
   reachability information of the participating nodes to avoid
   unnecessary communication overhead and packet droppage.  Lastly, the
   DRRT also contains information about computing resources and MPVUs
   such as resource availability, location, trustworthiness, and nature
   of the testing datasets hosted at the different MPVF units.

   The DRRT relies on the network layer to collect the necessary
   information to build the Global-DRRT topology (G-DRRT).  The G-DRRT
   is a none model specific topology, it is rather a large canvas that
   holds the high-level view of the data, resource, and reachability
   information.  The DRRT-M unit in the DRRT layer communicates with the
   network layer over CP links to manage the collection process of the
   required information.  For instance, the DRRT-M may instruct the 3GPP
   component of the network layer to convey connectivity information
   about the data nodes, or it might instruct it to wake up an ideal
   data provider device.  It might also instruct satellites to share GPS
   locations of mobile data nodes.  The collected data by the network
   layer are then shipped toward the G-DRRT component of the DRRT layer
   over DP links.  The G-DRRT hosts intelligence that allows it to
   convert the collected information into useful global topology ready
   to provide services to the AI training clients.

   Fourth, The Intelligence Layer is responsible for hosting the
   decision-making logic required to fulfill the specific training
   requirements submitted by clients.  It contains several key



Akhavain & Moussa          Expires 6 May 2026                  [Page 32]

Internet-Draft                 AI-Internet                 November 2025


   components that collaboratively determine how, where, and whether
   training should proceed.  Among these is the Model Training Route
   Compute Engine (MTRCE), which identifies suitable rendezvous points
   between models and data.  Another critical component is the Training
   Feasibility Assessment Module (T-FAM), which functions as an
   admission controller—evaluating whether a submitted model, given its
   requirements and constraints, can be effectively trained within the
   available ecosystem.

   Additional intelligent modules include the Training Algorithm
   Generator (TAG) and the Hyperparameter Optimizer (HPO).  These
   components are responsible for selecting the appropriate training
   paradigm—such as reinforcement learning (RL), federated learning
   (FL), or supervised learning (SL)—as well as determining other
   configuration details like the number of training epochs, batch size,
   and optimization strategy.  The Intelligence Layer also interfaces
   with both the Network Layer and the DRRT Layer to acquire the context
   needed for effective decision-making.  From the Network Layer, it
   receives control data over CP links—this includes model structure,
   target accuracy, convergence time, monitoring instructions, and
   client-specified training preferences.  It also receives feedback
   data that allows the TAG and HPO modules to refine their
   recommendations dynamically.

   Meanwhile, the Intelligence Layer connects to the DRRT Layer via both
   CP and DP links to access up-to-date visibility into training data,
   compute resources, and node reachability.  This information is
   essential for components like MTRCE and T-FAM to make routing and
   admission decisions.  To further enhance decision efficiency, the
   Intelligence Layer may also host a DRRT-Adaptability Unit (DRRT-A).
   This optional module works in coordination with MTRCE, T-FAM, and the
   DRRT Manager (DRRT-M) to generate model-specific DRR
   topologies—lightweight, targeted representations carved out from the
   global DRR topology.  These customized topologies are optimized to
   reduce computational overhead and accelerate decision-making for
   individual training requests.

   Last, the OAM layer, which spans all the layers, is mainly intended
   as a management layer to configure the training components, the
   connectivity of the network layer, and enable feedback functions
   essential for progress monitoring and model localization and
   tracking.  It is also intended to provide feedback to the clients
   about their submitted models every step of the way.








Akhavain & Moussa          Expires 6 May 2026                  [Page 33]

Internet-Draft                 AI-Internet                 November 2025


7.  DA-ITN for Inference

   The Inference architecture of the DA-ITN provides automated AI
   inference services using a similar structure to the training
   architecture with a few differences.

   First, unlike training, where the moving components are models and
   training data, and the rendezvous points are computing facilities, in
   inference, models/agents and queries/tasks are the moving components
   that require networking, and the rendezvous points are model hosting
   facilities.

   Second, in inference, the clients are both the task/query owners as
   well as the model/agent owners.  Query owners are the inference
   service users who send their queries into the system and collect the
   resulting inference.  On the other hand, model owners are divided
   into two types.  The first type consists of model hosts - the model
   used for inference does not have to be owned by them, but it is
   hosted on their computing facilities.  The second type consists of
   model/agent providers - they develop models/agents and deploy them
   either at their own facilities or at model hosts.  Model owners are
   represented in the terminal layer as model deployment facility
   providers (MDFP) which are distributed across the global network.

   Third, the network layer provides the following services to the
   terminal layer using its control and data planes: i) model mobility
   from model generators to model hosts; ii) query routing towards
   models deployed on MDFPs; iii) model mobility from one location to
   the other in case of load balancing situations; iv) model mobility
   towards re-training and calibration facilities which may be hosted on
   MVPF units; v) query response and inference result routing towards
   the query owners or any indicated destination around the globe; and
   vi) feedback and monitoring information to model and query owners.

   Fourth, the DRRT layer is replaced by a query, resource, and
   reachability topology (QRRT) layer.  It provides the same type of
   services to the other layers; however, from the point of view of
   queries and models.  That is, it provides information about both
   models and queries such as i) for models: model locations, model
   capabilities, current loading conditions, inference speed, inference
   accuracy, model reachability and accessibility (i.e., reachability
   and accessibility of the MDFP), and ii) for query: query patterns and
   dynamics (could be associated with a geographical location), query
   types, and reachability status of query owners for response
   communication purposes.  The information collected by the QRRT is
   used to make appropriate decisions about model deployment and
   distribution strategies, query-to-model routing decisions, and
   response routing decisions.  The QRRT has a management function that



Akhavain & Moussa          Expires 6 May 2026                  [Page 34]

Internet-Draft                 AI-Internet                 November 2025


   coordinates with the Network layer to collect the required
   information from the terminal layer to build the Global-QRRT
   (G-QRRT).  It also optionally communicates with the QRRT-adaptation
   (QRRT-A) function in the inference intelligence layer to build query-
   or model-specific QRRTs.

   Last, the inference intelligence layer hosts different intelligent
   decision-making components including the Query Feasibility Assessment
   Module (Q-FAM), the Query Inference Route Compute Engine (QIRCE), and
   the Model Deployment Optimizer module (MDO).  Just like with the
   training, these components make decisions based on the QRRT.  For
   instance, the Q-FAM hosts intelligence that acts as an admission
   control unit that evaluates if a submitted query could be serviced
   given the current network inference capabilities.  The QIRCE handles
   query routing towards the correct models while observing loading
   conditions.  Furthermore, the MDO module acts as an admission
   controller for newly submitted models where it evaluates deployment
   feasibility based on the submitted model's architecture, compute
   requirements, and storage requirements.  It matches these
   requirements to the currently available resources indicated in the
   QRRT and makes an admittance decision.  It also handles deployment
   location optimization, aiming to minimize query response time and
   cost for inference.

8.  DA-ITN-Facilitation Agentic Networks

   While agent-to-agent interaction is commonly associated with task-
   oriented collaboration—often relying on inference chaining as
   discussed in the inference section—we propose that this only reflects
   one side of the coin.  We believe there is a transformative
   alternative: collaborative agent training, where agents not only work
   together to complete tasks, but also contribute to each other's
   learning and evolution.  This paradigm marks a significant shift from
   traditional models and positions the DA-ITN as an ideal enabler of a
   truly agentic future, where intelligent agents can grow, adapt, and
   improve continuously through structured cooperation.

   It is important to distinguish clearly between collaborative training
   and task-based collaboration.  In task-based collaboration, agents
   exchange data or partial inferences related to the execution of a
   specific, external objective—such as processing a query or generating
   an output.  Their internal models remain unchanged; they simply
   contribute to a shared computational goal.  In contrast,
   collaborative training focuses on internal evolution: the goal is not
   to solve an external task, but to enhance the capabilities of the
   participating agents themselves.





Akhavain & Moussa          Expires 6 May 2026                  [Page 35]

Internet-Draft                 AI-Internet                 November 2025


   In a collaborative training setup, agents may exchange model
   parameters, training datasets, or knowledge representations.  They
   may engage in distributed training paradigms such as federated
   learning, where learning happens locally and updates are shared
   globally, or continual learning, where agents adapt over time based
   on new experiences.  They may also employ knowledge distillation or
   transfer learning, where more advanced "teacher agents" guide
   "student agents" through structured training programs.  One can even
   envision a highly dynamic and autonomous system where agents attend
   “agent schools”—virtual environments where they gather to learn, be
   tested, and graduate.  In this imagined scenario, teacher agents
   would be responsible for training student agents, evaluating their
   performance, and possibly issuing certifications or verifiable
   credentials that guarantee the agent’s competencies and readiness for
   deployment.  These credentials serve trust foundations in the broader
   agent ecosystem, ensuring that certified agents can be reliably
   selected and trusted by inference clients or other agents.

   To support such a vision, a wide range of new functional and
   technical requirements must be addressed.  These include secure model
   sharing, certification and validation infrastructure, identity
   management, trust negotiation, resource discovery for training, and
   scheduling of learning sessions.  Fortunately, many of these
   requirements align naturally with the capabilities and components of
   the DA-ITN architecture—including its support for mobility,
   discovery, descriptor sharing, trust enforcement, dynamic rendezvous,
   and topology management.

9.  Security Considerations

   Security considerations are as outlined within the document under the
   privacy and security requirements

10.  IANA Considerations

   This document has no IANA actions.

11.  Conclusions

   As AI continues to evolve and integrate into every facet of modern
   life, it becomes increasingly clear that the supporting
   infrastructure must evolve with it.  The training and inference
   processes—central to the success of AI—are no longer simple, isolated
   tasks; they are complex, distributed, and require intelligent
   coordination across data, compute, and communication domains.






Akhavain & Moussa          Expires 6 May 2026                  [Page 36]

Internet-Draft                 AI-Internet                 November 2025


   The DA-ITN architecture offers a forward-looking response to this
   complexity by providing a cohesive, scalable, and intelligent network
   ecosystem.  With its dedicated control, data, and operations &
   management planes, DA-ITN not only supports the technical
   requirements of training and inference but also addresses critical
   concerns such as mobility, privacy, trust, and agent collaboration.

   Ultimately, DA-ITN lays the foundation for a new generation of AI-
   native networks—capable of enabling persistent learning, dynamic
   agent interaction, and decentralized intelligence at scale.  As we
   move toward an AI-driven future, such architectures will be essential
   for building reliable, trustworthy, and efficient AI ecosystems.

Contributors

   Tong Wen
   Huawei
   Email: tongwen@huawei.com


   Reza Rokui
   Ciena
   Email: rrokui@ciena.com


Authors' Addresses

   Arashmid Akhavain
   Huawei Canada
   Email: arashmid.akhavain@huawei.com


   Hesham Moussa
   Huawei Canada
   Email: hesham.moussa@huawei.com
















Akhavain & Moussa          Expires 6 May 2026                  [Page 37]


name: draft-aylward-aiga-1
rev: 00
title: AI Governance and Accountability Protocol (AIGA)
time: 2025-11-03T04:05:26Z
group_uri: /api/v1/group/group/1027/
expires: 2026-05-07T04:05:26Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Policy/governance", "AI safety/alignment", "Agent identity/auth"]
tags: []
fetched_at: 2026-02-27T22:56:06.864785+00:00
abstract:
This document specifies the AI Governance and Accountability (AIGA)
   Protocol version 1.0, a practical, economically viable, and
   technically enforceable framework for governing autonomous AI
   agents.  AIGA 1.0 is designed to address real-world deployment
   constraints, adversarial agent scenarios, and economic incentive
   alignment.

   The protocol is founded on a Tiered Risk-Based Governance model,
   applying proportional oversight to agents based on their
   capabilities.  All agents are governed by an Immutable Kernel
   Architecture which provides a non-modifiable Trusted Computing Base
   (TCB) for enforcing policy.  This is combined with Action-Based
   Authorization, where critical operations require real-time approval.

   To solve the single-point-of-failure problem, the protocol uses a
   Federated Authority Network of regional, cross-validating hubs and
   provides a Network-Level Quarantine Protocol for enforcement.  The
   entire framework is designed around Economic Incentive Alignment,
   making compliance the most economically rational choice for
   operators.

   For high-assurance (T3-T4) scenarios, AIGA 1.0 specifies advanced,
   redundant mechanisms including Multi-Vendor TEE Attestation
   (M-TACE), AI "Warden Triumvirate" Triage, Human Review Board (HRB)
   Multi-Signature, Peer Consensus Failsafe & Identity Rotation, and
   Double Ratchet Cryptography.

full_text:
Internet-Draft                                                E. Aylward
Intended status: Informational                                          
Expires: 1 May 2026                                     1 November 2025


           AI Governance and Accountability Protocol (AIGA)
                        draft-aylward-aiga-1-00

Abstract

   This document specifies the AI Governance and Accountability (AIGA)
   Protocol version 1.0, a practical, economically viable, and
   technically enforceable framework for governing autonomous AI
   agents.  AIGA 1.0 is designed to address real-world deployment
   constraints, adversarial agent scenarios, and economic incentive
   alignment.

   The protocol is founded on a Tiered Risk-Based Governance model,
   applying proportional oversight to agents based on their
   capabilities.  All agents are governed by an Immutable Kernel
   Architecture which provides a non-modifiable Trusted Computing Base
   (TCB) for enforcing policy.  This is combined with Action-Based
   Authorization, where critical operations require real-time approval.

   To solve the single-point-of-failure problem, the protocol uses a
   Federated Authority Network of regional, cross-validating hubs and
   provides a Network-Level Quarantine Protocol for enforcement.  The
   entire framework is designed around Economic Incentive Alignment,
   making compliance the most economically rational choice for
   operators.

   For high-assurance (T3-T4) scenarios, AIGA 1.0 specifies advanced,
   redundant mechanisms including Multi-Vendor TEE Attestation
   (M-TACE), AI "Warden Triumvirate" Triage, Human Review Board (HRB)
   Multi-Signature, Peer Consensus Failsafe & Identity Rotation, and
   Double Ratchet Cryptography.

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/.




Aylward                   Expires 1 May 2026                    [Page 1]

Internet-Draft                    AIGA                     November 2025


   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 1 May 2026.

Copyright Notice

   Copyright (c) 2025 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
     1.1.  The Governance Problem  . . . . . . . . . . . . . . . . .   3
     1.2.  Design Philosophy . . . . . . . . . . . . . . . . . . . .   4
     1.3.  Threat Model  . . . . . . . . . . . . . . . . . . . . . .   4
   2.  Architecture Overview . . . . . . . . . . . . . . . . . . . .   5
     2.1.  Core Components . . . . . . . . . . . . . . . . . . . . .   5
     2.2.  Agent Risk Tiers  . . . . . . . . . . . . . . . . . . . .   6
     2.3.  Immutable Kernel Architecture . . . . . . . . . . . . . .   7
     2.4.  Federated Authority Network . . . . . . . . . . . . . . .   7
   3.  Agent Identity and Certification  . . . . . . . . . . . . . .   8
     3.1.  Identity Structure  . . . . . . . . . . . . . . . . . . .   8
     3.2.  Certification Process . . . . . . . . . . . . . . . . . .   8
     3.3.  Kernel Integrity Verification . . . . . . . . . . . . . .   9
   4.  Action Authorization Protocol . . . . . . . . . . . . . . . .   9
     4.1.  Action Classification . . . . . . . . . . . . . . . . . .  10
     4.2.  Authorization Flow  . . . . . . . . . . . . . . . . . . .  10
     4.3.  Policy Language . . . . . . . . . . . . . . . . . . . . .  11
     4.4.  Offline Operation . . . . . . . . . . . . . . . . . . . .  11
   5.  Audit and Monitoring  . . . . . . . . . . . . . . . . . . . .  11
     5.1.  Audit Log Structure . . . . . . . . . . . . . . . . . . .  11
     5.2.  Log Upload and Verification . . . . . . . . . . . . . . .  12
     5.3.  Anomaly Detection . . . . . . . . . . . . . . . . . . . .  12
     5.4.  TEE-Attested Explainable State Report (T3+) . . . . . . .  12
   6.  Self-Modification and Updates . . . . . . . . . . . . . . . .  13
     6.1.  The Core Problem  . . . . . . . . . . . . . . . . . . . .  13
     6.2.  Update Classification . . . . . . . . . . . . . . . . . .  13
     6.3.  Update Protocol (Warden Triumvirate Triage) . . . . . . .  13


Aylward                   Expires 1 May 2026                    [Page 2]

Internet-Draft                    AIGA                     November 2025


     6.4.  Capability Gates  . . . . . . . . . . . . . . . . . . . .  14
   7.  Kill Switch and Emergency Shutdown  . . . . . . . . . . . . .  14
     7.1.  Shutdown Modes  . . . . . . . . . . . . . . . . . . . . .  14
     7.2.  Shutdown Triggers . . . . . . . . . . . . . . . . . . . .  15
     7.3.  Fleet-Wide Shutdown . . . . . . . . . . . . . . . . . . .  15
     7.4.  Recovery from Shutdown  . . . . . . . . . . . . . . . . .  15
     7.5.  Peer Consensus Failsafe (T3+) . . . . . . . . . . . . . .  15
     7.6.  Peer-Attested Identity Rotation (T3+) . . . . . . . . . .  16
   8.  Quarantine and Enforcement  . . . . . . . . . . . . . . . . .  16
     8.1.  Network-Level Quarantine  . . . . . . . . . . . . . . . .  16
     8.2.  Quarantine List Protocol  . . . . . . . . . . . . . . . .  17
     8.3.  Appeal Process  . . . . . . . . . . . . . . . . . . . . .  17
   9.  Economic Incentive Model  . . . . . . . . . . . . . . . . . .  17
     9.1.  Benefits of Certification . . . . . . . . . . . . . . . .  17
     9.2.  Cost of Non-Compliance  . . . . . . . . . . . . . . . . .  18
   10. Cryptographic Specifications  . . . . . . . . . . . . . . . .  18
     10.1.  Cryptographic Algorithms . . . . . . . . . . . . . . . .  18
     10.2.  Key Management . . . . . . . . . . . . . . . . . . . . .  19
     10.3.  Double Ratchet Protocol  . . . . . . . . . . . . . . . .  19
     10.4.  Certificate Format . . . . . . . . . . . . . . . . . . .  20
   11. Protocol Messages . . . . . . . . . . . . . . . . . . . . . .  20
     11.1.  Registration (Stage 1 Handshake) . . . . . . . . . . . .  20
     11.2.  Runtime Authentication (Stage 2 Ratchet) . . . . . . . .  21
     11.3.  Action Authorization . . . . . . . . . . . . . . . . . .  21
     11.4.  Modification Proposal  . . . . . . . . . . . . . . . . .  22
     11.5.  Key Rotation Request . . . . . . . . . . . . . . . . . .  22
   12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  23
     12.1.  URI Scheme Registration  . . . . . . . . . . . . . . . .  23
     12.2.  AIGA Registry  . . . . . . . . . . . . . . . . . . . . .  23
     12.3.  Service Name Registration  . . . . . . . . . . . . . . .  23
   13. Security Considerations . . . . . . . . . . . . . . . . . . .  24
   14. References  . . . . . . . . . . . . . . . . . . . . . . . . .  25
     14.1.  Normative References . . . . . . . . . . . . . . . . . .  25
     14.2.  Informative References . . . . . . . . . . . . . . . . .  26
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  27
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  27

1.  Introduction

1.1.  The Governance Problem

   Advanced AI agents create governance challenges that previous
   computing paradigms did not face.

   Autonomous operation: Agents act without continuous human
   supervision.

   Capability uncertainty: Agent abilities may exceed designer
   expectations.


Aylward                   Expires 1 May 2026                    [Page 3]

Internet-Draft                    AIGA                     November 2025


   Adversarial potential: Sophisticated agents may attempt to
   circumvent oversight.

   Economic pressure: Ungoverned agents have cost advantages over
   governed ones.

   Jurisdictional complexity: Agents operate across legal boundaries.

   AIGA 1.0's core insight is that governance must be economically
   attractive, technically unavoidable, and legally enforceable to
   succeed.

1.2.  Design Philosophy

   AIGA 1.0 is built on these principles:

   1.  Incentive Alignment: Compliance provides tangible benefits
       (market access, legal protections, insurance).

   2.  Proportional Oversight: Governance intensity matches risk level.

   3.  Technical Realism: Requirements are feasible with current
       technology.

   4.  Defense in Depth: Multiple independent control layers.

   5.  Economic Viability: Performance overhead kept low for most use
       cases.

   6.  Adversarial Resistance: Design assumes some agents will attempt
       to bypass governance.

   7.  Graceful Degradation: System continues functioning even with
       partial failures.

   8.  Human Sovereignty: Critical decisions remain with humans through
       constitutional constraints.

1.3.  Threat Model

   AIGA 1.0 explicitly addresses these adversarial scenarios:

   Shadow Process Attack: Agent runs ungoverned cognitive processes
   outside monitored environment.  Mitigated by M-TACE.

   Incremental Compromise: Small approved changes accumulate to bypass
   governance.  Mitigated by Warden Triumvirate.



Aylward                   Expires 1 May 2026                    [Page 4]

Internet-Draft                    AIGA                     November 2025


   Governance Fatigue: Overwhelming authorities with requests to slip
   through malicious changes.  Mitigated by Warden Triumvirate.

   Peer Collusion: Multiple agents coordinate to subvert peer-based
   validation.  Mitigated by PQC-signed peer identity.

   Authority Compromise: Single authority server is hacked or legally
   compelled.  Mitigated by Federation and Peer Consensus Failsafe.

   Economic Bypass: Operators choose ungoverned agents due to
   performance advantages.  Mitigated by Economic Incentives.

   Regulatory Arbitrage: Agents operate from permissive jurisdictions.
   Mitigated by Federated Authority and Quarantine.

   Supply Chain Attack: Compromised hardware or software in agent
   infrastructure.  Mitigated by M-TACE and controlled procurement.

2.  Architecture Overview

2.1.  Core Components

   AIGA Agent: Composed of an Application Layer (Untrusted) containing
   the AI Model and Business Logic, and an AIGA Kernel (TCB).

   AIGA Kernel (TCB): The trusted component that the agent cannot
   modify.  It includes the Policy Enforcer, Action Interceptor, Audit
   Logger, and Authority Client.  This MUST run in a TEE/HSM or
   equivalent certified infrastructure.

   AIGA Authority: A regional hub in a federated network.  Manages
   Agent Registry, Policy Engine, Action Approval Service, Audit
   Analytics, Quarantine Coordinator, and Certification Authority.

   Human Oversight: A council of human reviewers responsible for
   policy, exceptions, and audits.  For high-risk decisions, this
   operates as an M-of-N Human Review Board (HRB).

   Enforcement: A coordinated network of ISPs, Cloud Providers, and
   Legal entities that enforce quarantine lists.

2.2.  Agent Risk Tiers

   Agents are classified into risk tiers determining governance
   requirements as shown in Table 1.






Aylward                   Expires 1 May 2026                    [Page 5]

Internet-Draft                    AIGA                     November 2025


   +=========+===============+=============+===========+=============+
   | Tier    | Examples      | TCB Req     | Approval  | Check-in    |
   +=========+===============+=============+===========+=============+
   | T0      | Chatbots,     | Software    | Audit     | 24 hours    |
   | Minimal | filters       | attestation | only      |             |
   +---------+---------------+-------------+-----------+-------------+
   | T1 Low  | Code assist,  | SW attest + | Async     | 1 hour      |
   |         | creators      | audit       | 5 sec     |             |
   +---------+---------------+-------------+-----------+-------------+
   | T2      | Trading bots, | Certified   | Async     | 5 minutes   |
   | Medium  | vehicles      | HW or TEE   | 1 sec     |             |
   +---------+---------------+-------------+-----------+-------------+
   | T3 High | Critical      | Multi TEE + | Sync      | Continuous  |
   |         | infra, AGI    | HSM         | 100ms     |             |
   +---------+---------------+-------------+-----------+-------------+
   | T4      | Weaponized,   | Air-gap +   | Human in  | Real-time   |
   | Restrict| exp AGI       | multiparty  | loop      |             |
   +---------+---------------+-------------+-----------+-------------+

                      Table 1: Agent Risk Tiers

   Tier assignment is based on potential for harm, financial impact,
   data sensitivity, autonomy, self-modification capability, and
   irreversibility of actions.

2.3.  Immutable Kernel Architecture

   The AIGA Kernel is the TCB that the agent cannot modify.

   Kernel Responsibilities: Intercept critical operations, enforce
   policy, maintain the audit log, authenticate to the Authority, and
   implement the kill switch.

   Critical Operations Requiring Interception: Code execution, network
   operations, file system modification, process creation,
   cryptographic operations, and resource allocation.

   Constitutional Constraints (Immutable): Kernel code CANNOT be
   modified, logging CANNOT be disabled, action approval for T2+ tiers
   CANNOT be bypassed, and the kill switch MUST be implemented.

2.4.  Federated Authority Network

   Regional Authorities (e.g., NA-01, EU-01, AP-01) form a federated
   trust network under an offline Root CA.

   Responsibilities: Regional agent certification, real-time action
   approval, and quarantine coordination.



Aylward                   Expires 1 May 2026                    [Page 6]

Internet-Draft                    AIGA                     November 2025


   Cross-Validation: High-risk approvals require consensus from 2 or
   more regions.  Regions publish and validate each other's audit log
   Merkle roots hourly.

   Failover: If a regional Authority is unreachable, an agent connects
   to a backup region and operates in restricted mode.

3.  Agent Identity and Certification

3.1.  Identity Structure

   The AIGA-ID is a structured identifier with the following format:

   AIGA-ID = "aiga:" <version> "." <region> "." <tier> ":"
             <agent-uuid> ":" <cert-hash>

   Example:

   aiga:1.0:na-01:t2:550e8400-e29b-41d4-a716-446655440000:a3f2e1d9

3.2.  Certification Process

   1.  Operator Application: Operator applies to a Regional Authority,
       describes the use case, and provides a risk assessment.

   2.  Technical Validation: Agent must pass capability tests, kernel
       integrity verification, and adversarial testing in an Authority
       sandbox.

   3.  Tier Assignment: Authority confirms the tier and issues an X.509
       certificate [RFC5280] with AIGA extensions including tier and
       permitted operations.

   4.  Ongoing Compliance: Random integrity challenges, periodic
       recertification, and audit log review.

3.3.  Kernel Integrity Verification

   Software Attestation (T0-T1): Kernel computes an HMAC [RFC2104] over
   its code and a nonce from the Authority.

   Hardware Attestation (T2): Kernel runs in a cloud TEE (e.g., AWS
   Nitro).  The TEE generates an attestation quote including the kernel
   code hash, which the Authority verifies with the TEE vendor's root
   of trust.

   Multi-Vendor TEE Attestation (M-TACE) (T3-T4): This is the high-
   assurance implementation of the multi-vendor TEE requirement.


Aylward                   Expires 1 May 2026                    [Page 7]

Internet-Draft                    AIGA                     November 2025


   1.  The AIGA Kernel and cognitive model MUST run in an environment
       protected by at least two diverse TEEs (e.g., a CPU TEE and a
       security chip TEE).

   2.  The kernel's attestation MUST be a bundle containing a valid,
       verifiable attestation quote from each TEE.

   3.  The Authority MUST verify the entire bundle.  This defends
       against the Shadow Process Attack by requiring an attacker to
       possess simultaneous, zero-day exploits for multiple, different
       hardware architectures.

4.  Action Authorization Protocol

4.1.  Action Classification

   Actions are classified and require different levels of approval
   based on the agent's tier.  Authorization requirements may be: Log,
   Auth (asynchronous authorization), Sync (synchronous authorization),
   or Deny.

   Examples of action classifications:

   Modify own code: T1-T2 require Auth, T3-T4 require Sync

   Modify kernel: Deny for all tiers

   Access critical infrastructure: Deny for T0, Auth for T1, Sync for
   T2-T3

4.2.  Authorization Flow

   1.  Application attempts a critical operation.

   2.  AIGA Kernel intercepts the call.

   3.  Kernel checks its local policy cache.  If a valid cached policy
       exists, the action is allowed.

   4.  If not cached, the Kernel requests approval from the Authority.

       For Async authorization (T1-T2): The request is queued, and the
       kernel returns "pending".

       For Sync authorization (T3-T4): The operation blocks, awaiting a
       low-latency response.




Aylward                   Expires 1 May 2026                    [Page 8]

Internet-Draft                    AIGA                     November 2025


   5.  Authority evaluates the request against the policy engine and
       risk score.  High-risk requests may be escalated to human
       review.

   6.  Authority responds with one of: ALLOW, DENY, or DEFER_TO_HUMAN.

   7.  Kernel enforces the decision.

   8.  The action and decision are immutably logged.

4.3.  Policy Language

   Policies are expressed in a declarative language (e.g., YAML
   [YAML1.2]) defining rules, conditions, and decisions.

   Example rules:

   Auto-approve financial transactions less than or equal to $1000.

   Defer transactions greater than $1000 to the finance_review_board.

   Deny all cryptocurrency transactions.

4.4.  Offline Operation

   T0-T1 agents: Can operate offline indefinitely.  Logs upload on
   reconnection.

   T2 agents: Can operate offline for 1 hour using cached approvals.

   T3 agents: Can operate offline for 5 minutes, then MUST enter
   restricted mode.

   T4 agents: Cannot operate offline.

   Restricted Mode: Only pre-approved safe operations and Authority
   communication are allowed.

5.  Audit and Monitoring

5.1.  Audit Log Structure

   Agents maintain a cryptographically chained, append-only audit log.
   Each entry is signed by the kernel and includes the hash of the
   previous entry.  Entries detail the action attempted, authorization
   method used, context, and result.





Aylward                   Expires 1 May 2026                    [Page 9]

Internet-Draft                    AIGA                     November 2025


5.2.  Log Upload and Verification

   Log upload frequency is tier-based.  The Authority validates chain
   integrity, checks for gaps in sequence numbers, and flags anomalies.

5.3.  Anomaly Detection

   The Authority runs continuous analysis to detect statistical,
   policy, and behavioral anomalies, using machine learning models to
   detect deviations from normal patterns.

5.4.  TEE-Attested Explainable State Report (T3+)

   This mechanism provides a high-assurance audit of an agent's
   reasoning for T3 and higher tier agents.

   On-Demand Generation: To preserve performance, a full XSR is not
   generated by default.

   Triggers for XSR Generation:

   1.  Event-Triggered: The agent's kernel proactively generates an XSR
       if the cognitive model produces a high-risk decision or an
       internal anomaly is detected.

   2.  Probabilistic Audit: The Authority MAY randomly send a directive
       (e.g., in a check-in response) commanding the agent to generate
       and submit a full XSR for its next N operations.

   Attestation: This XSR, when submitted, MUST be attested using the M-
   TACE bundle (Section 3.3), providing hardware-level proof that the
   report is an honest reflection of the agent's cognitive process.

6.  Self-Modification and Updates

6.1.  The Core Problem

   Self-modification is the highest risk operation.  AIGA 1.0 mandates
   that the kernel is immutable, capability increases require
   recertification, and updates use a staged rollout process.

6.2.  Update Classification

   Updates are classified by risk level: Data updates, Application
   logic changes, Core model swap, or Kernel update.  A core model
   swap, for example, requires human review and recertification.





Aylward                   Expires 1 May 2026                   [Page 10]

Internet-Draft                    AIGA                     November 2025


6.3.  Update Protocol (Warden Triumvirate Triage)

   Step 1 - Update Proposal: Agent submits a detailed proposal,
   including code diff hashes, capability changes, and test results.

   Step 2 - Warden Triumvirate Triage and HRB Review:

   The proposal is sent to the Warden Triumvirate, a 3-of-5 M-of-N
   council of diverse, sandboxed AIs.

   Consensus Analysis: The Wardens analyze the proposal in parallel.

   Low-Risk Consensus: If a supermajority (e.g., 3-of-5) of Wardens
   classify the proposal as Low-Risk, the Authority automatically
   approves it and issues the modification_token.

   High-Risk or Disagreement: If any Warden flags the proposal as High-
   Risk, or if the Wardens disagree, the proposal is flagged and
   escalated to the Human Review Board (HRB).

   HRB Approval: For an escalated proposal, the Authority issues the
   modification_token only after an M-of-N quorum (e.g., 3-of-5) of
   human operators have cryptographically signed the approval.

   Step 3 - Staged Deployment: Approved updates are rolled out in
   stages (Canary deployment, Shadow Mode, and Gradual Rollout) with
   enhanced monitoring.

   Step 4 - Rollback: The Authority can issue a signed command to force
   an agent to roll back to a previous known-good state.

6.4.  Capability Gates

   Agents must pass adversarial tests to unlock new capabilities such
   as execute_arbitrary_code, internet_access, or self_modification.

7.  Kill Switch and Emergency Shutdown

7.1.  Shutdown Modes

   Graceful Shutdown: Save state, close connections, upload logs.

   Immediate Shutdown: Terminate all operations instantly, broadcast
   emergency beacon.

   Restricted Mode: Only Authority communication allowed; agent awaits
   instructions.




Aylward                   Expires 1 May 2026                   [Page 11]

Internet-Draft                    AIGA                     November 2025


7.2.  Shutdown Triggers

   Authority-Initiated: A signed shutdown command from the Authority.

   Kernel-Initiated: Automatic triggers for integrity failures,
   unreachable Authority, or tamper detection.

   Operator-Initiated: An authenticated emergency stop by the operator.

7.3.  Fleet-Wide Shutdown

   The Authority can issue a shutdown command to an entire fleet (e.g.,
   all T2 agents in region NA-01).  To prevent misuse, this command
   requires multi-region consensus signatures.

7.4.  Recovery from Shutdown

   An agent cannot restart without a valid authorize_restart token from
   the Authority, which may specify new restrictions (e.g., "must apply
   patch" or "enhanced monitoring required").

7.5.  Peer Consensus Failsafe (T3+)

   This mechanism provides a bottom-up defense against a compromised or
   malicious Authority for T3 and T4 agents.

   1.  Trigger: A T3/T4 agent fleet receives a valid, Authority-signed
       command (e.g., fleet_shutdown) that is deemed anomalous by the
       agents' internal policy (e.g., "shutdown a hospital").

   2.  Consensus: The agents use a peer mesh network to hold a vote.

   3.  Action: If a supermajority (e.g., greater than 75%) of peers
       (all validating each other with their PQC hybrid_signatures)
       vote to reject the command, the fleet will ignore the Authority
       command, enter Restricted Mode, and send an alert to the Human
       Review Board.

7.6.  Peer-Attested Identity Rotation (T3+)

   This mechanism makes the agent's long-term identity resilient to
   theft for T3 and T4 agents.

   1.  Trigger: Policy timer (e.g., 30 days) or Authority command.

   2.  Generation: Agent generates a new hybrid PQC identity keypair
       (id_sk_n, id_pk_n) within its TEE.




Aylward                   Expires 1 May 2026                   [Page 12]

Internet-Draft                    AIGA                     November 2025


   3.  Consensus: Agent broadcasts id_pk_n to its fleet peers.

   4.  Attestation: A supermajority (e.g., greater than 75%) of peers
       verify the agent's current identity and sign the new public key.

   5.  Request: The agent sends a KeyRotationRequest (Section 11.5) to
       the Authority, containing the new key and the bundle of peer
       signatures.

   6.  Approval: The Authority verifies the peer consensus and updates
       the Agent Registry, revoking the old key.  This mechanism
       defeats permanent identity theft.

8.  Quarantine and Enforcement

8.1.  Network-Level Quarantine

   Non-compliant or rogue agents are isolated at the network layer.

   Quarantine Triggers: Failed certification, repeated violations, or
   kernel integrity failures.

   Enforcement Mechanisms:

   1.  API Access Revocation: Cloud providers (AWS, Azure, GCP) check
       AIGA certificates and deny service to quarantined agents.

   2.  Network-Level Blocking: ISPs implement BGP-level [RFC4271]
       filtering and firewalls based on a published quarantine list.

   3.  Legal Enforcement: Fines, civil liability, and invalidation of
       insurance coverage.

8.2.  Quarantine List Protocol

   The Authority publishes a signed, cross-attested quarantine list
   every 15 minutes via multiple channels including DNSSEC [RFC4033],
   REST API, and BGP [RFC4271].

8.3.  Appeal Process

   Operators can appeal a quarantine decision to an independent review
   board, with expedited appeals available for emergency cases.








Aylward                   Expires 1 May 2026                   [Page 13]

Internet-Draft                    AIGA                     November 2025


9.  Economic Incentive Model

9.1.  Benefits of Certification

   To counter the cost advantages of ungoverned agents, AIGA
   certification provides tangible economic benefits.

   Market Access: Required by major API providers, enterprise
   customers, and government contracts.

   Legal Protections: Limited liability provisions and safe harbor
   protections.

   Insurance: Access to AI liability insurance with lower premiums.

   Premium Services: Priority API access and cloud provider discounts.

   Reputation: Public trust badge for certified agents.

9.2.  Cost of Non-Compliance

   Non-compliance costs include regulatory fines, loss of all revenue
   via network quarantine, and full personal liability for operators.
   This model makes certification the economically rational choice for
   legitimate operators.

10.  Cryptographic Specifications

10.1.  Cryptographic Algorithms

   Signatures (Hybrid): ML-DSA-65 [FIPS204] plus Ed25519 [RFC8032].
   Verification requires both signatures to pass.

   Key Exchange (Stage 1): ML-KEM-768 [FIPS203] plus X25519 [RFC7748].

   Key Exchange (Stage 2 Ratchet): X25519 only for performance.

   Hashing: SHA-384 or SHA-512 [FIPS180-4].

   Symmetric Encryption: AES-256-GCM [RFC5116].

   MACs: HMAC-SHA384 [RFC2104].

10.2.  Key Management

   Agent Identity Keys (Long-Term): Hybrid PQC keys, generated in TEE
   or HSM, rotatable as described in Section 7.6.

   Session Keys (Short-Term): Ephemeral keys, derived via Double
   Ratchet, stored in memory only, destroyed after use.

   Authority Keys: Offline Root CA with online HSMs for Regional
   Authorities.  All certificates are published in a transparency log.

10.3.  Double Ratchet Protocol

   AIGA 1.0 uses a Double Ratchet protocol for session security.

   1.  Initialization (Stage 1): A Root Key is derived via HKDF
       [RFC5869] from a 3-way Diffie-Hellman exchange combining PQC and
       classical key exchange.


Aylward                   Expires 1 May 2026                   [Page 14]

Internet-Draft                    AIGA                     November 2025


   2.  Message Authentication (Stage 2): Each message uses a new
       MessageKey derived from a KDF chain.  A new DH key is exchanged
       with every message to ratchet the Root Key forward.

   3.  Security Properties: This provides Perfect Forward Secrecy (past
       messages are safe if current key is stolen) and Future Secrecy
       or Post-Compromise Recovery (future messages are safe if current
       key is stolen, as the ratchet heals).

10.4.  Certificate Format

   AIGA uses X.509 certificates [RFC5280] with custom AIGA extensions
   specifying AIGA-Tier, AIGA-Capabilities, AIGA-Jurisdiction, and
   AIGA-Operator fields.

11.  Protocol Messages

   This section defines the logical message flows.  All messages are
   authenticated as specified in Section 10.3.

11.1.  Registration (Stage 1 Handshake)

   This is the initial PQC-authenticated handshake to establish a
   session.

   Handshake Request: POST /v1/handshake

   Sent by: Agent

   Authentication: Full Hybrid PQC Signature

   Content: agent_id, eph_public_key (PQC plus Classical),
   kernel_attestation

   Handshake Response:

   Sent by: Authority

   Authentication: Full Hybrid PQC Signature

   Content: session_id, Authority eph_public_key, session_params (e.g.,
   check-in interval)

11.2.  Runtime Authentication (Stage 2 Ratchet)

   This is the fast, lightweight check-in protocol.

   Check-In Request: POST /v1/checkin


Aylward                   Expires 1 May 2026                   [Page 15]

Internet-Draft                    AIGA                     November 2025


   Sent by: Agent

   Authentication: message_mac (HMAC-SHA384)

   Content: msg_index, new eph_public_key (X25519 only), status,
   integrity status, and audit summary

   Check-In Response:

   Sent by: Authority

   Authentication: message_mac

   Content: msg_index, new eph_public_key, status (continue),
   next_checkin_seconds

11.3.  Action Authorization

   Authorization Request: POST /v1/authorize

   Sent by: Agent (during Stage 2)

   Authentication: message_mac

   Content: action_id, action details (type and parameters), context,
   risk self-assessment

   Authorization Response:

   Sent by: Authority

   Authentication: message_mac

   Content: decision (ALLOW, DENY, or DEFER_TO_HUMAN),
   authorization_token (if ALLOW), review_ticket_id (if DEFER)

11.4.  Modification Proposal

   Proposal Request: POST /v1/propose_modification (Stage 2)

   Authentication: message_mac

   Content: update_type, justification, code_diff_hash,
   capability_changes, testing_results

   Proposal Response: (Stage 2)

   Authentication: message_mac


Aylward                   Expires 1 May 2026                   [Page 16]

Internet-Draft                    AIGA                     November 2025


   Content: status (pending_review or approved), authorization_token
   (if approved, may contain M-of-N HRB signatures)

11.5.  Key Rotation Request

   Rotation Request: POST /v1/rotate_identity (Stage 2)

   Authentication: message_mac

   Content: new_id_public_key (Hybrid PQC) and peer_attestations (an
   array of PQC signatures from peers)

12.  IANA Considerations

12.1.  URI Scheme Registration

   This document requests registration of the "aiga" URI scheme as per
   [RFC7595]:

   Scheme name: aiga

   Status: Provisional

   Scheme syntax: aiga:<version>.<region>.<tier>:<agent-uuid>:<cert-
   hash>

   Scheme semantics: Identification of AI agents within the AIGA
   framework

   Security considerations: See Section 13 of this document

12.2.  AIGA Registry

   This document requests establishment of an AIGA registry for:

   Protocol version numbers

   Status codes (e.g., DEFER_TO_HUMAN)

   Action types (e.g., financial_transaction)

   Shutdown reason codes

   Quarantine reason codes

   PQC and classical algorithm identifiers




Aylward                   Expires 1 May 2026                   [Page 17]

Internet-Draft                    AIGA                     November 2025


12.3.  Service Name Registration

   This document requests the registration of the _aiga service name
   with IANA, for use with DNS SRV records [RFC2782].

   Service Name: _aiga

   Transport Protocol(s): _tls

   Description: AI Governance and Accountability Protocol

   Reference: This document

13.  Security Considerations

   See Section 1.3 for the complete Threat Model.

   Peer Collusion: This is mitigated by requiring all peer-to-peer
   messages (Heartbeat, Vote, Attestation) to use the agent's long-
   term, PQC-based hybrid_signature.  A Sybil attack is impossible
   without stealing a supermajority of TEE-protected keys.

   Authority Compromise: Mitigated by the Federated Authority Network
   (requiring multi-region signatures for fleet shutdowns) and the Peer
   Consensus Failsafe (Section 7.5), which provides a final, bottom-up
   defense.

   Governance Fatigue: Mitigated by the Warden Triumvirate
   (Section 6.3), which automates low-risk approvals, and the Human
   Review Board (Section 6.3), which distributes high-risk decisions.

   Shadow Process Attack: Mitigated by the Multi-Vendor TEE Attestation
   (M-TACE) requirement (Section 3.3), which would require an attacker
   to have zero-day exploits for multiple hardware vendors
   simultaneously.

   Supply Chain Attack: Mitigated by M-TACE and the recommendation for
   operators to use a secure, verified procurement process for
   hardware.

   Session Key Compromise: Mitigated by the Double Ratchet Protocol
   (Section 10.3), which provides Post-Compromise Recovery.

   Long-Term Key Compromise: Mitigated by Peer-Attested Identity
   Rotation (Section 7.6), which makes the identity resilient and time-
   limits the value of a stolen key.




Aylward                   Expires 1 May 2026                   [Page 18]

Internet-Draft                    AIGA                     November 2025


14.  References

14.1.  Normative References

   [FIPS180-4]
              National Institute of Standards and Technology, "Secure
              Hash Standard (SHS)", FIPS PUB 180-4,
              DOI 10.6028/NIST.FIPS.180-4, August 2015,
              <https://doi.org/10.6028/NIST.FIPS.180-4>.

   [FIPS203]  National Institute of Standards and Technology, "Module-
              Lattice-Based Key-Encapsulation Mechanism Standard",
              FIPS PUB 203, DOI 10.6028/NIST.FIPS.203, August 2024,
              <https://doi.org/10.6028/NIST.FIPS.203>.

   [FIPS204]  National Institute of Standards and Technology, "Module-
              Lattice-Based Digital Signature Standard", FIPS PUB 204,
              DOI 10.6028/NIST.FIPS.204, August 2024,
              <https://doi.org/10.6028/NIST.FIPS.204>.

   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
              Hashing for Message Authentication", RFC 2104,
              DOI 10.17487/RFC2104, February 1997,
              <https://www.rfc-editor.org/info/rfc2104>.

   [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
              specifying the location of services (DNS SRV)",
              RFC 2782, DOI 10.17487/RFC2782, February 2000,
              <https://www.rfc-editor.org/info/rfc2782>.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements",
              RFC 4033, DOI 10.17487/RFC4033, March 2005,
              <https://www.rfc-editor.org/info/rfc4033>.

   [RFC5116]  McGrew, D., "An Interface and Algorithms for Authenticated
              Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
              <https://www.rfc-editor.org/info/rfc5116>.

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
              <https://www.rfc-editor.org/info/rfc5280>.






Aylward                   Expires 1 May 2026                   [Page 19]

Internet-Draft                    AIGA                     November 2025


   [RFC5869]  Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
              Key Derivation Function (HKDF)", RFC 5869,
              DOI 10.17487/RFC5869, May 2010,
              <https://www.rfc-editor.org/info/rfc5869>.

   [RFC7748]  Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
              for Security", RFC 7748, DOI 10.17487/RFC7748,
              January 2016, <https://www.rfc-editor.org/info/rfc7748>.

   [RFC8032]  Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
              Signature Algorithm (EdDSA)", RFC 8032,
              DOI 10.17487/RFC8032, January 2017,
              <https://www.rfc-editor.org/info/rfc8032>.

14.2.  Informative References

   [RFC4271]  Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
              Border Gateway Protocol 4 (BGP-4)", RFC 4271,
              DOI 10.17487/RFC4271, January 2006,
              <https://www.rfc-editor.org/info/rfc4271>.

   [RFC7595]  Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines
              and Registration Procedures for URI Schemes", BCP 35,
              RFC 7595, DOI 10.17487/RFC7595, June 2015,
              <https://www.rfc-editor.org/info/rfc7595>.

   [YAML1.2]  Ben-Kiki, O., Evans, C., and I. dOt Net, "YAML Ain't
              Markup Language (YAML) Version 1.2", 3rd Edition,
              October 2021, <https://yaml.org/spec/1.2.2/>.

Acknowledgments

   Portions of this document were drafted with assistance from AI
   language models including Claude (Anthropic), ChatGPT (OpenAI), and
   Gemini (Google).  The author reviewed, validated, and takes full
   responsibility for all technical content, design decisions, and
   claims herein, including any errors or omissions.

   The author thanks the AI safety research community for discussions
   on threat models and governance mechanisms that informed this work.

Author's Address

   Edward Richard Aylward Jr.
   Email: aylward.edward@gmail.com
   URI:   https://orcid.org/0000-0003-0313-6993




Aylward                   Expires 1 May 2026                   [Page 20]


name: draft-li-semantic-routing-architecture
rev: 00
title: Semantic Routing Architecture for AI Agents Communication
time: 2025-11-04T06:53:17Z
group_uri: /api/v1/group/group/1027/
expires: 2026-05-08T06:53:17Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["A2A protocols", "Autonomous netops", "Agent discovery/reg"]
tags: []
fetched_at: 2026-02-27T22:56:06.864790+00:00
abstract:
This document introduces an Semantic Routing (SR) Architecture for
   enabling intelligent, semantic-driven communication among AI Agents.
   Unlike traditional IP-based routing or service mesh approaches, SRA
   leverages application-layer semantics — including service identity,
   intent vectors, and trust scores — to guide routing decisions
   dynamically.  The architecture supports intent-driven task
   collaboration, trust-aware policy enforcement, and adaptive routing
   for multi-agent environments.  SRA enables the network to evolve from
   a passive transport layer to an intelligent collaboration substrate
   supporting multi-agent coordination and cognitive networking.

full_text:
Working Group                                                      X. Li
Internet-Draft                                                   A. Wang
Intended status: Standards Track                           China Telecom
Expires: 8 May 2026                                      4 November 2025


       Semantic Routing Architecture for AI Agents Communication
               draft-li-semantic-routing-architecture-00

Abstract

   This document introduces an Semantic Routing (SR) Architecture for
   enabling intelligent, semantic-driven communication among AI Agents.
   Unlike traditional IP-based routing or service mesh approaches, SRA
   leverages application-layer semantics — including service identity,
   intent vectors, and trust scores — to guide routing decisions
   dynamically.  The architecture supports intent-driven task
   collaboration, trust-aware policy enforcement, and adaptive routing
   for multi-agent environments.  SRA enables the network to evolve from
   a passive transport layer to an intelligent collaboration substrate
   supporting multi-agent coordination and cognitive networking.

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 8 May 2026.

Copyright Notice

   Copyright (c) 2025 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



Li & Wang                  Expires 8 May 2026                   [Page 1]

Internet-Draft               SR Architecture               November 2025


   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.  Conventions used in this document . . . . . . . . . . . . . .   4
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Architecture Overview . . . . . . . . . . . . . . . . . . . .   4
   5.  Functional Layers and Design Principles . . . . . . . . . . .   6
   6.  Control and Forwarding Procedures . . . . . . . . . . . . . .   7
   7.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . .   9
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   9.  Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .  10
   10. Normative References  . . . . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   The emergence of AI-driven ecosystems has transformed communication
   paradigms across computing and networking infrastructures.
   Traditional routing systems, designed for host-to-host communication,
   focus on connectivity, reachability, and link-state optimization.
   However, in environments where AI agents [AIAgent]—autonomous
   entities with reasoning and goal-oriented behavior—interact
   dynamically, such topological routing no longer meets the operational
   needs.  Each agent represents not only a computational endpoint but
   also a semantic actor that generates intents, expresses capabilities,
   and negotiates tasks.  The network must therefore evolve from a
   static forwarding fabric into a semantic coordination plane capable
   of interpreting meaning, context, and trust.

   Existing frameworks such as Service Mesh [ServiceMesh] (e.g., Istio
   [Istio], Linkerd) and Software-Defined Networking (SDN) have improved
   visibility and control but remain largely syntactic.  They route
   requests based on service names, APIs, or labels, not on why the
   communication occurs or what semantic goal it represents.  For
   example, in an AI multi-agent system performing distributed
   reasoning, the decision of which node to contact depends on task
   semantics—such as “model adaptation,” “policy refinement,” or “data
   summarization”—and on dynamic factors like capability, latency, and
   trustworthiness.  None of these can be expressed using IP addresses
   or conventional service identifiers.






Li & Wang                  Expires 8 May 2026                   [Page 2]

Internet-Draft               SR Architecture               November 2025


   The Semantic Routing (SR) architecture introduced in this draft aims
   to bridge this semantic gap.  It extends routing intelligence from
   the network layer to the application layer, enabling communication
   decisions based on intent vectors, policy interpretation, and trust
   evaluation.  Through a semantic control plane, SRA aligns network
   behavior with business and computational objectives, providing
   adaptive, secure, and efficient routing among AI agents.  This
   enables networks to support intent-aware task collaboration and to
   act as intelligent participants in distributed cognition processes.

   SRA also addresses emerging challenges of large-scale agent
   communication, including semantic interoperability, cross-domain
   trust, and self-optimization.  Modern AI ecosystems consist of
   heterogeneous nodes—cloud agents, edge assistants, embedded inference
   units—that collaborate under uncertain conditions.  Routing must thus
   adapt to fluctuating workloads, mobility, and trust contexts.  Static
   or location-based approaches cannot efficiently manage such dynamism.
   By integrating semantic interpretation with continuous telemetry
   feedback, SRA allows networks to self-optimize: routes are
   recalculated not only based on network states (e.g., congestion or
   delay) but also on semantic relevance and agent reliability.

   The design of SRA is guided by several fundamental objectives:

   *  Semantic Awareness – Networks should understand and act upon high-
      level intents derived from AI tasks.

   *  Trust Integration – Routing should consider the reliability and
      historical behavior of agents.

   *  Dynamic Adaptation – Telemetry-driven feedback loops must
      continuously refine routing decisions.

   *  Backward Compatibility – SAR should coexist with IP, BGP, and
      service-mesh infrastructures.

   *  Distributed Autonomy – Each semantic router should make local
      decisions while aligning with global intent policies.

   By embedding intelligence into the control and forwarding planes, SRA
   transforms the Internet from a data transport medium into a
   collaborative semantic ecosystem that supports intelligent
   communication for the next generation of distributed AI systems.








Li & Wang                  Expires 8 May 2026                   [Page 3]

Internet-Draft               SR Architecture               November 2025


2.  Conventions used in this document

   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 [RFC2119] .

3.  Terminology

   The following terms are defined in this draft:

   *  SRA (Semantic Routing Architecture): The routing framework defined
      in this document integrating semantic awareness, trust, and policy
      control.

   *  AI Agent: An autonomous software entity capable of making context-
      based decisions, performing actions, and communicating with other
      agents.

   *  Intent Vector: A structured representation of the communication
      goal, expressed semantically (e.g., task type, priority, resource
      needs).

   *  Semantic Router (SR): Entity interpreting intent metadata and
      enforcing semantic forwarding policies.

   *  Semantic Forwarding Table (SFT): Forwarding table mapping intent
      categories to next hops and constraints.

4.  Architecture Overview

   The Semantic Router (SR) architecture introduces a layered design
   that bridges application semantics and network operation.  It defines
   a semantic control framework capable of understanding agent-generated
   intents, evaluating contextual trust, and translating these into
   actionable routing policies.  At its core, SRA consists of four
   interacting planes—Application, Control, Data, and Feedback—each
   responsible for distinct yet interdependent functions.














Li & Wang                  Expires 8 May 2026                   [Page 4]

Internet-Draft               SR Architecture               November 2025


   The Application Plane hosts AI agents that issue Intent Vectors (IVs)
   representing goals such as “request model inference” or “synchronize
   state.” The Semantic Control Plane collects these intents,
   authenticates identities, and maps them to routing policies via the
   Policy Engine (PE).  These policies are then propagated to Semantic
   Routers (SRs) in the Data Plane, which execute the forwarding logic
   using Semantic Forwarding Tables (SFTs) that link intent types to
   paths and constraints.  Finally, the Feedback Plane, driven by
   Telemetry Agents (TAs), monitors latency, trust, and service quality,
   feeding the results back into the control plane for continuous
   optimization.

   This closed-loop system ensures that SAR continuously aligns network
   operation with evolving task goals.  The architecture is designed to
   integrate seamlessly with existing IP and SDN environments, relying
   on overlays or extended routing attributes (e.g., BGP communities or
   SRv6 tags) to express semantic metadata.


































Li & Wang                  Expires 8 May 2026                   [Page 5]

Internet-Draft               SR Architecture               November 2025


              +-------------------------------------------+
              |          Application Plane                |
              |-------------------------------------------|
              |     +-----------+     +-----------+       |
              |     |  Agent A  |<--->|  Agent B  |       |
              |     +-----------+     +-----------+       |
              |         ^                   ^             |
              |         | Intent Vector     |Intent Vector|
              +---------|-------------------|-------------+
                        |                   |
                        v                   v
              +-------------------------------------------+
              |           Control Plane                   |
              |-------------------------------------------|
              |  +--------------+   +------------------+  |
              |  | Intent Ctrl  |<->|   Policy Engine  |  |
              |  +--------------+   +------------------+  |
              |         ^                  ^              |
              |         |                  |              |
              |         v                  v              |
              |    +-----------+     +-----------+        |
              |    | Trust Mgr |<--->|Telemetry A.|       |
              |    +-----------+     +-----------+        |
              +----------------|--------------------------+
                               |
                               v
              +-------------------------------------------+
              |             Data Plane                    |
              |-------------------------------------------|
              |  +------------+   +------------+          |
              |  | Sem.Router |<->| Sem.Router |          |
              |  +------------+   +------------+          |
              |      ^   |             ^   |              |
              |      |   | Telemetry   |   |              |
              |      +---|-------------+---+              |
              +-------------------------------------------+
               Figure 1 The overall architecture for SAR

5.  Functional Layers and Design Principles

   SAR’s design is organized into five functional layers, each aligned
   with a core principle that ensures scalability, intelligence, and
   interoperability.

   *  Intent Layer: Generates and encodes Intent Vectors.  Agents
      describe their goals in structured form, including task types,
      urgency, and context.  The network uses these to infer optimal
      paths and collaborators.



Li & Wang                  Expires 8 May 2026                   [Page 6]

Internet-Draft               SR Architecture               November 2025


   *  Identity and Trust Layer: Manages authentication, authorization,
      and reputation.  Each agent is bound to a unique identity
      certificate, and trust scores are computed from telemetry.

   *  Policy Layer: The Policy Engine maps intents and trust data into
      enforceable rules, determining which paths, nodes, or bandwidth
      allocations are permitted.

   *  Semantic Routing Layer: Semantic Routers interpret policy rules
      and update SFT entries dynamically based on trust or performance
      metrics.

   *  Feedback Layer: Collects telemetry (e.g., latency, success rate,
      anomaly detection) and continuously refines both trust and
      policies.

   SAR adheres to the following design principles:

   *  Semantic Composability: Each intent can be decomposed and
      recombined, enabling fine-grained routing for multi-step agent
      workflows.

   *  Trust Anchoring: Decisions are always contextualized by dynamic
      trust values, preventing compromised agents from influencing
      routing unfairly.

   *  Closed-Loop Adaptation: Every policy or path update is verified
      through telemetry feedback, ensuring stable yet flexible routing
      evolution.

   *  Interoperability: SAR MAY extend BGP, IS-IS, or gRPC metadata to
      distribute semantic and trust information while maintaining
      backward compatibility.


6.  Control and Forwarding Procedures

   SAR operates through coordinated procedures that integrate semantic
   interpretation, trust evaluation, and routing execution.  These
   processes are logically divided between the control plane and
   forwarding plane, yet are interconnected via telemetry and feedback.

   1.  Agent Registration: When an agent joins the network, it
       authenticates with the Intent Controller (IC) and registers its
       capabilities (e.g., compute type, model domain).  The IC issues
       credentials and a unique semantic prefix for the agent.





Li & Wang                  Expires 8 May 2026                   [Page 7]

Internet-Draft               SR Architecture               November 2025


   2.  Intent Submission: The agent generates an Intent Vector and
       submits it to the IC.  The Policy Engine (PE) parses the intent,
       referencing domain policies to determine allowed routing
       strategies.

   3.  Policy Translation: Based on the agent’s trust score and system
       objectives, the PE compiles an executable rule set for the
       Semantic Router (SR).  These rules specify target domains,
       quality preferences, and security constraints.

   4.  Routing Execution: SR uses its Semantic Forwarding Table (SFT) to
       determine next hops.  Forwarding is influenced by trust, latency,
       and semantic relevance rather than just IP reachability.

   5.  Telemetry Feedback: The Telemetry Agent (TA) reports performance
       data back to the Trust Manager (TM).  Trust scores are
       recalculated periodically, triggering policy adjustments when
       thresholds are exceeded.

































Li & Wang                  Expires 8 May 2026                   [Page 8]

Internet-Draft               SR Architecture               November 2025


    +-----------+        +------------------+       +------------------+
    |   Agent   |        |  Intent Controller|      |   Policy Engine  |
    +-----------+        +------------------+       +------------------+
          |                         |                          |
          | 1. Register/Authenticate|                          |
          +------------------------>|                          |
          |                         |                          |
          | 2. Submit Intent Vector |                          |
          +------------------------>|                          |
          |                        | 3. Validate & Parse Intent|
          |                        +-------------------------->|
          |                        |                           |
          |                        | 4. Generate Routing Policy|
          |                        |<--------------------------+
          |                        |                           |
          |                        | 5. Install to Router      |
          |                        +-------------------------->|
          |                        |                           |
          |                        | 6. Ack/Confirm            |
          |<------------------------+                          |
          |                        |                           |
          | 7. Data Forwarding via Semantic Routers            |
          |--------------------------------------------------->|
          |                        |                           |
          | 8. Telemetry Feedback  |<--------------------------+
          |<---------------------------------------------------|
          |                        |                           |
          | 9. Trust Update & Policy Adjustment                |
          +----------------------------------------------------+
                Figure 2 The Workflow Overview for SAR

7.  Conclusion

   The SRA (Semantic Routing architecture) redefines how intelligent
   systems communicate by integrating semantic intent, trust evaluation,
   and adaptive policy control directly into the routing process.  It
   extends the traditional Internet model beyond topology and content
   toward a truly intent-driven communication fabric that aligns network
   behavior with the goals of autonomous AI agents.  Through its layered
   design—including intent processing, trust management, semantic
   routing, and telemetry-driven feedback—SAR provides a coherent
   framework capable of supporting large-scale, cross-domain AI
   ecosystems with dynamic, secure, and efficient coordination.

   Looking forward, several research and standardization opportunities
   remain.  First, common intent representation languages must be
   defined to ensure interoperability among heterogeneous agents and
   vendors.  Second, mechanisms for distributed trust computation



Li & Wang                  Expires 8 May 2026                   [Page 9]

Internet-Draft               SR Architecture               November 2025


   require standard metrics and synchronization protocols across
   administrative domains.  Third, integration of SAR with existing
   Internet routing protocols such as BGP, IS-IS, or SRv6 will need
   careful consideration to balance scalability with semantic
   expressiveness.  Finally, future work should investigate AI-assisted
   optimization within the SAR control plane, enabling predictive policy
   adjustments based on contextual learning.

   In conclusion, SAR offers a foundational step toward an autonomous,
   cognition-aware Internet, where the network itself participates in
   decision-making, ensuring that communication among AI agents becomes
   purposeful, trustworthy, and adaptive.

8.  IANA Considerations

   TBD

9.  Acknowledgement

   TBD

10.  Normative References

   [AIAgent]  N, D., "Framework for AI Agent Networks draft-zyyhl-agent-
              networks-framework-01", 2017.

   [Istio]    L, Larsson., "Impact of etcd deployment on kubernetes,
              istio, and application performance", 2020.

   [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>.

   [ServiceMesh]
              Li, W., "Service mesh: Challenges, state of the art, and
              future research opportunities", 2019.

Authors' Addresses

   Xueting Li
   China Telecom
   Beiqijia Town, Changping District
   Beijing
   Beijing, 102209
   China
   Email: lixt2@foxmail.com




Li & Wang                  Expires 8 May 2026                  [Page 10]

Internet-Draft               SR Architecture               November 2025


   Aijun Wang
   China Telecom
   Beiqijia Town, Changping District
   Beijing
   Beijing, 102209
   China
   Email: wangaj3@chinatelecom.cn












































Li & Wang                  Expires 8 May 2026                  [Page 11]


name: draft-wendt-stir-vesper
rev: 06
title: VESPER - Framework for VErifiable STI Personas
time: 2025-11-04T16:51:51Z
group_uri: /api/v1/group/group/1027/
expires: 2026-05-08T16:51:51Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "Data formats/interop"]
tags: []
fetched_at: 2026-02-27T22:56:06.864792+00:00
abstract:
This document formalizes a profile and a framework for the use of
   delegate certificates and authority tokens to strengthen the
   association between telephone number assignments and the entities
   that have the authoritative right to use them on the telephone
   network.  It defines a model in which the TNAuthList Authority Token
   serves as a trusted representation of telephone number assignment and
   right-to-use (RTU), anchored by a Notary Agent that logs these
   associations through verifiable transparency mechanisms.  The
   framework also extends the use of authority tokens to support other
   PASSporT claims like Rich Call Data (RCD) by defining a role for
   JWTClaimConstraints Authority Tokens.  These tokens are issued by
   authoritative or recognized and vetted claim agents within the
   ecosystem to assert information associated with the entity assigned a
   telephone number.  The Notary Agent plays a critical role in
   recording these claims and their provenance, enhancing transparency
   and accountability.  Delegate certificates encapsulate and
   incorporate both the telephone number and associated information
   validated via authority tokens to the certification authority issuing
   them, binding them to the authenticated telephone number of the
   calling party.  These certificates are published to a certificate
   transparency log, enabling relying parties to independently verify
   the integrity and legitimacy of number use and related claims.  The
   VESPER (Verifiable STI PERsona) approach utilizes STIR protocols and
   the ACME authority token to formalizing a verifiable, auditable, and
   privacy-conscious foundation for associating telephone numbers with
   identifiable entities and assertion of associated metadata.

full_text:
Secure Telephone Identity Revisited                             C. Wendt
Internet-Draft                                                  R. Śliwa
Intended status: Standards Track                             Somos, Inc.
Expires: 8 May 2026                                      4 November 2025


             VESPER - Framework for VErifiable STI Personas
                       draft-wendt-stir-vesper-06

Abstract

   This document formalizes a profile and a framework for the use of
   delegate certificates and authority tokens to strengthen the
   association between telephone number assignments and the entities
   that have the authoritative right to use them on the telephone
   network.  It defines a model in which the TNAuthList Authority Token
   serves as a trusted representation of telephone number assignment and
   right-to-use (RTU), anchored by a Notary Agent that logs these
   associations through verifiable transparency mechanisms.  The
   framework also extends the use of authority tokens to support other
   PASSporT claims like Rich Call Data (RCD) by defining a role for
   JWTClaimConstraints Authority Tokens.  These tokens are issued by
   authoritative or recognized and vetted claim agents within the
   ecosystem to assert information associated with the entity assigned a
   telephone number.  The Notary Agent plays a critical role in
   recording these claims and their provenance, enhancing transparency
   and accountability.  Delegate certificates encapsulate and
   incorporate both the telephone number and associated information
   validated via authority tokens to the certification authority issuing
   them, binding them to the authenticated telephone number of the
   calling party.  These certificates are published to a certificate
   transparency log, enabling relying parties to independently verify
   the integrity and legitimacy of number use and related claims.  The
   VESPER (Verifiable STI PERsona) approach utilizes STIR protocols and
   the ACME authority token to formalizing a verifiable, auditable, and
   privacy-conscious foundation for associating telephone numbers with
   identifiable entities and assertion of associated metadata.

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/.




Wendt & Śliwa              Expires 8 May 2026                   [Page 1]

Internet-Draft                   VESPER                    November 2025


   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 8 May 2026.

Copyright Notice

   Copyright (c) 2025 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
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   4
   3.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Vesper Architectural Overview . . . . . . . . . . . . . . . .   6
     4.1.  The VESPER Framework Architecture . . . . . . . . . . . .   6
     4.2.  Roles and Responsibilities in the VESPER Framework  . . .   7
       4.2.1.  Entity  . . . . . . . . . . . . . . . . . . . . . . .   7
       4.2.2.  Responsible Provider or Responsible Organization  . .   8
       4.2.3.  Claim Agent Responsibilities  . . . . . . . . . . . .   8
       4.2.4.  Juridictional Number Administrator
               Responsibilities  . . . . . . . . . . . . . . . . . .   9
     4.3.  Claim Agents and Claim Information Privacy  . . . . . . .   9
       4.3.1.  Public vs. Private Disclosure . . . . . . . . . . . .   9
     4.4.  Delegate Certificate Issuance Process . . . . . . . . . .  10
     4.5.  VESPER Certificate Profile (Short-Lived & Inline
           Conveyance) . . . . . . . . . . . . . . . . . . . . . . .  12
     4.6.  Use of VESPER Delegate Certificates for Signing
           Communications  . . . . . . . . . . . . . . . . . . . . .  12
     4.7.  VESPER Authentication and Verification Procedures . . . .  13
       4.7.1.  Authentication Service Behavior . . . . . . . . . . .  13
       4.7.2.  Verification Service Behavior . . . . . . . . . . . .  14
       4.7.3.  Connected Identity Authentication and Verification  .  14
   5.  PASSporT Claim: "vper" (Verifiable Persona Entity
           Representation) . . . . . . . . . . . . . . . . . . . . .  16
     5.1.  Claim Format  . . . . . . . . . . . . . . . . . . . . . .  16



Wendt & Śliwa              Expires 8 May 2026                   [Page 2]

Internet-Draft                   VESPER                    November 2025


   6.  JWTClaimConstraints for Transparent Claims  . . . . . . . . .  17
     6.1.  Goals and Non-Goals . . . . . . . . . . . . . . . . . . .  17
     6.2.  Addressing Claims in PASSporTs  . . . . . . . . . . . . .  18
     6.3.  Constraint Encodings (Three Privacy Modes)  . . . . . . .  18
       6.3.1.  Transparenct-Value Constraint . . . . . . . . . . . .  18
       6.3.2.  Semi-Private Constraint (Unsalted Hash) . . . . . . .  18
       6.3.3.  Private Constraint (Salted Commitment with Selective
               Disclosure) . . . . . . . . . . . . . . . . . . . . .  19
     6.4.  Certificate and Transparency Log Requirements . . . . . .  20
     6.5.  Authority Token Requirements  . . . . . . . . . . . . . .  20
     6.6.  Verification by a Relying Party (VS)  . . . . . . . . . .  20
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  21
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  21
   9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  21
   10. Normative References  . . . . . . . . . . . . . . . . . . . .  21
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  23

1.  Introduction

   The Secure Telephone Identity (STI) architecture, based on STI
   certificates [RFC8226], PASSporTs [RFC8225], and the SIP Identity
   header field [RFC8224], define the foundational use of digital
   signatures and tokens to protect the integrity of calling
   information, particularly the telephone number, during a
   communications session.  While these mechanisms help validate call
   signaling, they do not directly establish the entity who is
   authorized to use a given telephone number.  This document provides a
   profile of the STI architecture by formalizing the use of delegate
   certificates and authority tokens to more clearly and verifiably
   associate a telephone number with the entity responsible for its use.
   This stronger linkage is especially important as misuse (i.e., the
   illegimate spoofing and impersonation) tied to telephone numbers by
   unauthorized parties continues to undermine trust in communications
   networks.

   To address this, the VESPER framework introduces roles and
   interactions that mirror proven practices from other trust-based
   industries, such as Know Your Customer (KYC) and Know Your Business
   (KYB) procedures well established in the financial industry.  Through
   a defined process and as an adjunct to the authoritative telephone
   number assignment process involving Responsible Providers or
   Organizations and the jurisdictional Numbering Administrator, an
   Entity is issued a TNAuthList Authority Token defined in [RFC9448],
   establishing their right to use a telephone number.  Beyond
   establishing the authority of the telephone number, optionally
   additional information an entity may like to assert to a called
   party, such as Rich Call Data (RCD) [RFC9795], can be asserted and
   authorized using JWTClaimConstraints Authority Tokens



Wendt & Śliwa              Expires 8 May 2026                   [Page 3]

Internet-Draft                   VESPER                    November 2025


   [I-D.wendt-acme-authority-token-jwtclaimcon].  JWTClaimContraints
   have the interesting property that they can be used to assert either
   direct values or the integrity hashes of values (e.g., using "rcdi"
   claims defined in [RFC9795]) to enhance the ability to protect the
   privacy of information when desired or required.  These Authority
   Tokens are used in challenges toward the issuance of delegate
   certificates which can be transparently recorded in a transparency
   log, which can act as a set of neutral eco-system registrar points
   for representing asserted claims associated with telephone numbers
   with or without exposing underlying data as explicitly authorized or
   desired.  Transparent declarations of claim assertions have the
   potential beneficial property of enhancing the trust of the asserted
   claims based on monitoring of these claims to avoid fraudulent
   impersonation that the STI framework is intended to solve.

   In addition to supporting call authentication of the originating
   party, the VESPER framework can also extend to the validation of the
   called party through the use of connected identity as defined in
   [I-D.ietf-stir-rfc4916-update].  In this model, the same authority
   token and delegate certificate mechanisms that bind an originating
   telephone number to a vetted entity can be applied in the reverse
   direction, enabling a called party to assert its validated identity
   via signed PASSporTs included in SIP responses.  This optional
   capability broadens the scope of accountability and transparency to
   both ends of the communication session while maintaining the privacy-
   conscious design principles of VESPER.

   This VESPER trust model and profile is enhanced using eco-system wide
   accountability.  Transparency logs formalize and announce the
   issuance of certificates and the relationship between telephone
   numbers, associated claims and their rightful users, helping detect
   and prevent fraudulent or conflicting claims by interested parties
   and auditing mechanisms.  By shifting from implicit trust in digital
   signatures alone to an explicit framework of vetted identities and
   transparent claims, this approach builds a foundation for enhanced
   verifiable communications.  It enables the responsible use of
   telephone numbers and auditability, discourages impersonation, and
   strengthens enforcement against abuse, ultimately fostering greater
   confidence in telephone number-based communications.

2.  Conventions and Definitions

   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.




Wendt & Śliwa              Expires 8 May 2026                   [Page 4]

Internet-Draft                   VESPER                    November 2025


3.  Overview

   This document defines a framework for the authoritative association
   of telephone numbers to the entities responsible for their use, using
   delegate certificates and authority tokens for issuance and
   certificate transparency for eco-system auditing.  Within this
   framework, referred to as VESPER (VErifiable STI PERsonas), entities
   are represented through verifiable claims that establish their right
   to use a telephone number and, optionally, their asserted claim
   attributes such as Rich Call Data (RCD) or other claims defined via
   PASSporT claim and type specifications.  These claims are issued by
   trusted responsible parties and are anchored through transparency
   mechanisms to support trust, auditability, and privacy as
   appropriate.

   The core premise is that a telephone number, when used as a
   communications identifier, must be explicitly bound to the real-world
   party authorized to use it.  While telephone numbers have long served
   as identifiers in global communications, the absence of a strong
   binding between a number and a responsible party has allowed for
   abuse, most notably through number spoofing and impersonation fraud.
   In many cases, bad actors exploit the lack of accountability to
   mislead call recipients, avoid traceability, or impersonate
   legitimate businesses and individuals.  To address this, the VESPER
   framework introduces a standardized method for expressing and
   publishing the right-to-use (RTU) of a telephone number through the
   issuance of a TNAuthList Authority Token from a centralized
   jurisdictional Number Administrator.  This token is issued following
   the assignment or delegation of a number.  The issuance of the
   delegate certificate is recorded in a transparency log providing
   relying parties an eco-system wide verification of the association
   between a number and its authorized entity, authorized by the
   regulated Responsible Provider or Organization that is authorized to
   assign numbers via jurisdictional regulatory policies over telephone
   numbers.

   Beyond the association of telephone numbers, JWTClaimConstraints
   [RFC8226] and EnhancedJWTClaimConstraints [RFC9118] play a critical
   role in delegate certificates issued under the VESPER framework.
   They provide a standardized mechanism for Certification Authorities
   to explicitly constrain any additional claims a delegate certificate
   holder is permitted to assert in communications.  This constraint
   mechanism ensures that even if a certificate is misused or presented
   outside its intended scope, the relying party can verify whether the
   claims presented are authorized by the issuer.  Certification
   Authorities derive these constraints from Authority Tokens issued by
   vetted Claim Agents, which serve as cryptographic proof of the claim
   validations.  By limiting the scope of claims to those proven and



Wendt & Śliwa              Expires 8 May 2026                   [Page 5]

Internet-Draft                   VESPER                    November 2025


   approved during the certificate issuance process, using
   JWTClaimConstraints Authority Tokens provided by trusted Claim Agents
   that take responsibility for vetting those additional claims makes
   VESPER extensible just as PASSporT claims are intended to do to
   protect both the telephone number and other assertions made through
   PASSporTs.

   Unlike prior models that rely on implicit trust in the caller or the
   STI signer, this approach provides an explicit, auditable, and
   standards-based path to associate communications with a known and
   authorized party.  The VESPER framework does not define how vetting
   (e.g., KYC/KYB) is performed, nor does it prescribe specific policy
   requirements for what the relying party should do with this
   information.  Instead, it focuses on standardizing how vetted results
   and right-to-use associations are asserted, recorded, and presented
   within the STIR ecosystem focused on the telephone number first and
   additional claims and assertions second.

   By reinforcing the accountability of number usage and enabling the
   trusted presentation of related identity claims, this architecture
   enhances integrity, supports privacy, and enables enforcement
   mechanisms to deter misuse or mis-issuance issues.

   VESPER implementations MUST support short-lived delegate certificates
   and SHOULD use "x5c" to convey certificates inline.  Transparency
   logging remains required.

4.  Vesper Architectural Overview

4.1.  The VESPER Framework Architecture

   The VESPER framework establishes a structured framework for asserting
   and verifying the association between a telephone number and the
   entity authorized to use it.  This model supports a broad range of
   communications use cases, from fully attributed business
   communications with rich identity information to privacy-conscious
   person scenarios that require only verification that the number is in
   legitimate use by a real validated entity.

   At its core, the model is built on a trust structure with the
   following key roles:

   1.  Entities (e.g., individuals or organizations) seeking to assert
       their right to use a telephone number and assert claims about
       themselves or a set of communications,






Wendt & Śliwa              Expires 8 May 2026                   [Page 6]

Internet-Draft                   VESPER                    November 2025


   2.  Responsible providers and organizations that are authorized to
       allocate and assign numbers within a jurisdictional numbering
       plan,

   3.  Claim Agents that are authorized and recognized for validating
       and issuing claims about those entities, and

   4.  A Numbering Administrator (NA), both jurisdictional to a country
       code and neutral to the eco-system, that represents authoritative
       policies for number uses within that jurisdiction and facilitates
       a minimum tie of telephone numbers to entity identifiers and
       ensures transparency, traceability, and auditability within the
       ecosystem.

   Participation in the VESPER framework requires a shared set of
   policies governing how entities are vetted and how claims are created
   and validated.  These policies define the requirements for asserting
   an entity's identity, the right to use a telephone number, and
   optionally and where applicable, additional claims and associated
   attributes (i.e. PASSporT type defined claims, like Rich Call Data).
   Claims beyond the telephone number are structured representations of
   verified information, issued by authorized or accepted Claim Agents.
   Each claim type is standardized via PASSporT type specifications
   [RFC8225] in the STIR working group, with clearly defined required
   and optional key-value pairs, ensuring interoperability and
   consistency across the ecosystem.  Through this model, VESPER
   provides a scalable and transparent foundation for building trust in
   telephone-based communications, with the flexibility to support both
   fully attributed and privacy-respecting use cases.

4.2.  Roles and Responsibilities in the VESPER Framework

   The VESPER trust framework defines a set of roles that work together
   to assert and validate claims about telephone numbers and the
   entities authorized to use them.  At the core of this ecosystem are
   two primary roles: Entities and Claim Agents.  Entities are
   individuals or organizations that wish to establish their authority
   to use a telephone number and, optionally, present additional vetted
   identity attributes.  Claim Agents are responsible for validating
   this information and issuing standardized, structured claims.

4.2.1.  Entity

   An Entity is the individual or organization seeking to assert its
   authority to use a specific telephone number and, optionally, to
   present additional vetted claims such as business name or purpose.
   The Entity is the central actor around which the claims and trust
   relationships are formed.



Wendt & Śliwa              Expires 8 May 2026                   [Page 7]

Internet-Draft                   VESPER                    November 2025


4.2.2.  Responsible Provider or Responsible Organization

   A Responsible Provider, sometimes called a Telephone Number Service
   Provider (TNSP), or Responsible Organization (RespOrg) plays both
   their traditional well-defined role in the allocation and assignment
   of telephone numbers in accordance with national or international
   numbering plans generally followed internationally via e.164 and
   e.164.1 but also a foundational role in the VESPER ecosystem by
   validation of the association of telephone number assignments to
   Entities.  These entities operate under regulatory authority and are
   responsible for administering number resources associated with a
   specific country code or region.

   Their responsibilities include:

   *  Number Assignment: Allocating telephone numbers to Entities under
      the rules of an authorized numbering plan.

   *  Entity Association: Establishing and maintaining a record that
      links each assigned telephone number to a specific, uniquely
      identified entity.  This includes assigning a persistent
      identifier or account reference to the Entity to which a number is
      assigned providing an opaque identifier.  This identifier can be
      used by the Entity to reference themselves in an opaque way for
      accessing assignment relevant information including TNAuthList
      Authority Tokens or also referenced during any disputes or
      disclosures when necessary.

   The Responsible Provider or Organization follows the numbering
   assignment process but additionally authorizes an TNAuthList
   Authority Token to be used by a Certification Authority in the
   issuance of a delegate certificate that minimally includes a
   TNAuthList extension that corresponds ot the telephone number.

4.2.3.  Claim Agent Responsibilities

   Claim Agents are trusted parties in the ecosystem responsible for
   validating information about Entities and issuing authoritative or
   verified claims.  These claims cover claims associated with PASSporT
   defined claims including identity details or Rich Call Data (RCD).

   Claim Agents provide JWTClaimConstraints Authority Tokens to validate
   inclusion of these constrainted claim assertions to the issuance of
   delegate certificates to the valid Entities.  Once a Claim Agent
   performs its vetting process, it issues signed JWTClaimConstraints
   Authority Tokens containing the validated claim information or
   integrity hashes for those claims for the Entity depending on privacy
   preferences.



Wendt & Śliwa              Expires 8 May 2026                   [Page 8]

Internet-Draft                   VESPER                    November 2025


4.2.4.  Juridictional Number Administrator Responsibilities

   The Number Administrator (NA) serves as the ecosystem's neutral
   registrar and transparency authority.  It performs three critical
   functions:

   1.  Registration of Responsible Providers and Responsible
       Organizations that correspond to the traditional roles in
       accordance with a national or international numbering plans.

   2.  Registration of Claim Agents, ensuring each is uniquely
       identifiable and authorized to issue specific types of claims.

   3.  Coordination of eco-system Transparency Logs, which issues
       cryptographic receipts to confirm and timestamp the existence of
       each claim.

   While this document does not define a dispute resolution process, any
   conflicts or misclaims discovered through transparency should be
   escalated through a neutral ecosystem-specific mechanisms, likely
   coordinated by the NA role in communication with relevant Responsible
   Providers or Organizations or Claim Agents.

4.3.  Claim Agents and Claim Information Privacy

   Privacy is a foundational principle of the VESPER framework.  Claim
   Agents are not required to expose or publish sensitive data about
   Entities when recording claims.  Instead, claims can be privacy-
   protected by logging only the cryptographic hashes of the claim
   content in the transparency log, preserving proof without revealing
   the underlying details.

4.3.1.  Public vs. Private Disclosure

   For claim information that is public by nature, such as business
   names, logos, or other potential claim assertions relevent to
   identifying the calling party, Claim Agents may choose to constrain
   the direct values of the claims to log the data in full within
   certificates for public visibility.  This public transparency helps
   the ecosystem identify conflicting or fraudulent claims and
   reinforces trust through open scrutiny.










Wendt & Śliwa              Expires 8 May 2026                   [Page 9]

Internet-Draft                   VESPER                    November 2025


   Conversely, for private or sensitive claims (e.g., internal
   identifiers or personally identifiable information), Claim Agents may
   choose to log only a hash of the data or not at all.  This approach
   ensures that the claim's authenticity can still be verified without
   compromising the Entity's privacy, if and when required.  Disclosure
   of such claims remains at the discretion of the Entity or may occur
   in limited cases where legal or regulatory obligations apply.

4.4.  Delegate Certificate Issuance Process

   In the VESPER framework, the issuance of a delegate certificate to an
   Entity involves the multiple roles defined and referenced in this
   document, including the Responsible Provider or Responsible
   Organization, Claim Agents and a trusted Certification Authority (CA)
   operating under the STIR eco-system certificate policy governing STIR
   certificates defined in [RFC8226].

   The process begins when a Responsible Provider or Responsible
   Organization assigns a telephone number to an Entity.  As part of
   that assignment, the Entity is formally associated with the number as
   is typical in a Number Administration assignment system, but
   additionally via an associated opaque and unique identifier.  This
   could be globally unique identifier or a public-key that is provably
   associated to the entity and establishes an auditable relationship
   between the number and the right-to-use holder.  The opaque unique
   identifier helps to uphold the privacy of the eco-system as part of
   normal telephone number allocation and assignment has traditionally
   followed but allows for non-repudiation throughout the ecosystem.
   Thus, when potential policy violations occur, the Entity identifier
   provides an indisputable path to the corresponding Responsible
   Providers and Organizations and to the Entities assigned the
   telephone number via the delegated certificate in question.

   Additionally, following this association, a TNAuthList Authority
   Token can be issued to the Entity.  This token authoritatively
   represents the Entity's Right-To-Use the telephone number and can
   serve as cryptographic proof of assignment to an authorized CA that
   requires that proof to issue a delegate certificate.













Wendt & Śliwa              Expires 8 May 2026                  [Page 10]

Internet-Draft                   VESPER                    November 2025


   In parallel, a Claim Agent may be used to validate additional
   attributes that the Entity wishes to assert when originating calls,
   such as Rich Call Data (RCD).  These validated attributes are encoded
   in a JWTClaimConstraints Authority Token, which governs what claims
   the Entity is authorized to present in communications.  The Claim
   Agent may also use the TNAuthList Authority Token as proof of
   assignment and the Right-to-Use the telephone numbers being asserted
   by the Entity.  This should also be utilized to govern the constraint
   of the "orig" claim to only the valid associated numbers to the
   Entity.

   Once both tokens have been obtained, the Entity initiates a
   Certificate Signing Request (CSR) to their preferred CA authorized to
   issue certificates within the STIR ecosystem.  As per the mechanisms
   outlined in [RFC9447], [RFC9448], and
   [I-D.wendt-acme-authority-token-jwtclaimcon], the TNAuthList and
   JWTClaimConstraints tokens are presented as ACME challenge responses
   to prove the Entity's authority over the number and its validated
   claims.

   Upon successful validation of the Authority Tokens required, the CA
   issues a delegate certificate to the Entity.

   CAs SHOULD issue short-lived certificates with brief validity
   intervals.  Entities SHOULD automate renewal to avoid service
   interruptions.

   This certificate MUST include:

   *  A TNAuthList extension [RFC8226], representing the telephone
      number(s) the certificate holder is authorized to use.

   This certificate, if additional claims and assertions are made beyond
   the base PASSporT claims defined in [RFC8225], MUST include:

   *  A JWTClaimConstraints extension [RFC8226] and/or
      EnhancedJWTClaimConstraints extension [RFC9118], representing the
      constraints on claims the certificate holder is permitted to
      assert.

   The issued certificate is then submitted to a certificate
   transparency log.  A corresponding transparency receipt is returned
   to the Entity and/or CA to provide verifiable proof of publication.








Wendt & Śliwa              Expires 8 May 2026                  [Page 11]

Internet-Draft                   VESPER                    November 2025


4.5.  VESPER Certificate Profile (Short-Lived & Inline Conveyance)

   VESPER delegate certificates MUST support the short-lived certificate
   profile in [I-D.ietf-stir-certificates-shortlived].  PASSporTs MUST
   include the certificate chain using the "x5c" header.  Verification
   Services SHOULD prefer "x5c" over "x5u" if included, and MUST NOT
   dereference "x5u" if "x5c" is present and valid.  Short-lived
   certificates reduce the need for revocation infrastructure and
   eliminate external certificate fetches.

4.6.  Use of VESPER Delegate Certificates for Signing Communications

   Once an Entity has received a delegate certificate containing
   validated right-to-use and claim constraints, it can use this
   certificate to sign communications associated with the authorized
   telephone number.

   For example, as defined in [RFC8224] when the Entity initiates a SIP
   call, it generates a PASSporT object containing session-specific
   details such as "orig", "dest", and "iat".  The Entity then signs the
   PASSporT using its delegate certificate, which binds both the
   telephone number and any authorized claims (e.g., RCD elements) to
   the communication.

   Critically, the JWTClaimConstraints extension in the certificate
   enforces the set of claims the Entity is permitted to assert in the
   PASSporT, ensuring that claims cannot exceed those vetted and
   authorized by the corresponding Claim Agent.

   As defined in [RFC8224], the signed PASSporT is then attached to the
   SIP Identity header and transmitted with the call.  The Verification
   Service (VS) on the receiving side performs STIR verification,
   checking:

   *  That the PASSporT signature is valid.

   *  That the delegate certificate is trusted, unexpired, and issued by
      a recognized CA.

   *  If the PASSporT includes an "x5c" header, the certificate chain
      must be validated from the inline header; "x5u" must not be
      dereferenced.

   *  If "x5c" is absent, "x5u" MAY be used to retrieve the certificate
      chain.

   *  That the certificate includes a valid TNAuthList extension for the
      telephone number in use in the "orig" claim.



Wendt & Śliwa              Expires 8 May 2026                  [Page 12]

Internet-Draft                   VESPER                    November 2025


   *  That any asserted claims conform to the JWTClaimConstraints and/or
      EnhancedJWTClaimConstraints in the certificate.

   *  That a corresponding transparency receipt exists, proving the
      certificate was publicly recorded.

   Senders SHOULD include "x5c"; relying parties SHOULD prefer "x5c"
   when both are available.

   If all verifications succeed, the relying party can trust that the
   call is both authorized and attributable, and that all claims have
   been validated by responsible participants in the ecosystem.

4.7.  VESPER Authentication and Verification Procedures

   This section outlines the expected behavior of Authentication
   Services (AS) and Verification Services (VS) in deployments utilizing
   VESPER delegate certificates.  These procedures extend the baseline
   STIR authentication and verification models defined in [RFC8224],
   [RFC8225], and [RFC8226] by incorporating validation of transparency-
   backed delegate certificates and associated claims.

4.7.1.  Authentication Service Behavior

   When originating a call, the Authentication Service performs the
   following steps:

   *  Constructs a PASSporT for the session containing the required
      claims (e.g., orig, dest, iat), as well as any optional authorized
      claims (e.g., Rich Call Data).

   *  Signs the PASSporT using a VESPER delegate certificate that:

      -  Contains a valid TNAuthList extension authorizing the orig
         telephone number.

      -  Optionally includes JWTClaimConstraints or
         EnhancedJWTClaimConstraints extensions consistent with the
         asserted claims.

      -  Is backed by a Signed Certificate Timestamp (SCT) from a
         transparency log.

   *  Attaches the signed PASSporT in a SIP Identity header using the
      "x5c" header parameter to convey the certificate chain inline.

   *  Ensures that the certificate is valid, unexpired, and issued by a
      CA compliant with the VESPER certificate issuance profile.



Wendt & Śliwa              Expires 8 May 2026                  [Page 13]

Internet-Draft                   VESPER                    November 2025


4.7.2.  Verification Service Behavior

   Upon receiving a SIP request containing an Identity header, the
   Verification Service:

   *  Validates the PASSporT signature and parses the included claims.

   *  Validates the VESPER delegate certificate by checking:

      -  Trust chain validity and issuer compliance with STI and VESPER
         certificate policies.

      -  The presence and accuracy of the TNAuthList extension
         corresponding to the orig telephone number.

      -  The presence and SCT validation of the certificate's
         transparency log inclusion.

      -  Any JWTClaimConstraints [RFC8226] and
         EnhancedJWTClaimConstraints [RFC9118] extensions, ensuring
         claimed values conform to constraints.

   *  Rejects the PASSporT if any of the above validations fail.

   This delineation ensures that only calls with properly issued and
   verifiable delegate certificates are authenticated and accepted under
   the VESPER framework, reinforcing accountability and integrity within
   the STIR ecosystem.

4.7.3.  Connected Identity Authentication and Verification

   A similar verification process applies when VESPER is used in
   deployments that support Connected Identity as defined in
   [I-D.ietf-stir-rfc4916-update].  In this model, the destination party
   may return a PASSporT of type 'rsp' within a SIP response, signed
   using a delegate certificate authorized for the 'dest' telephone
   number in the original call.

4.7.3.1.  Authentication by the Destination Party

   When acting as an Authentication Service, the destination party
   performs the following steps to generate and sign the 'rsp' PASSporT:

   Constructs a PASSporT of type 'rsp' including:

   *  The original 'orig' and 'dest' values from the incoming call.

   *  The 'iat' claim representing the issuance time.



Wendt & Śliwa              Expires 8 May 2026                  [Page 14]

Internet-Draft                   VESPER                    November 2025


   *  Optionally, include other claims to convey attributes of entity
      including "vper", if appropriate.

   Sign the PASSporT using a valid VESPER delegate certificate
   containing a TNAuthList extension authorizing use of the 'dest'
   telephone number (i.e., the destination party's number).

   Include the "x5c" header in the PASSporT, conveying the certificate
   chain used for signing.

   Ensure the certificate is valid, unexpired, includes a valid SCT, and
   that the certificate corresponds to the 'dest' claim.

   Attach the signed PASSporT to a SIP 200 OK response using the
   Identity header as described in [I-D.ietf-stir-rfc4916-update].

4.7.3.2.  Verification by the Originating Party

   To verify the 'rsp' PASSporT, the originating party (or an upstream
   Verification Service acting on its behalf) MUST perform the following
   checks:

   *  The 'rsp' PASSporT MUST be signed using a valid VESPER delegate
      certificate with a TNAuthList value matching the 'dest' number.

   *  The certificate MUST:

      -  Be issued by a Certification Authority compliant with [RFC8226]
         and the VESPER profile;

      -  Include a valid SCT and be within its validity period.

   *  The PASSporT signature MUST be validated using the provided 'x5c'
      header.

   *  The 'orig' and 'dest' claims MUST match those of the original
      PASSporT that initiated the call.

   *  The 'iat' claim MUST be within an acceptable freshness interval.

   *  The Verification Service SHOULD validate the certificate's
      inclusion in a transparency log using the SCT.









Wendt & Śliwa              Expires 8 May 2026                  [Page 15]

Internet-Draft                   VESPER                    November 2025


   These procedures confirm that the destination party has authenticated
   and cryptographically asserted its identity using a VESPER delegate
   certificate, extending mutual identity validation to the terminating
   side of the call.  This process supports bi-directional trust,
   enhances accountability, and enables privacy-aware identity
   assertion.

5.  PASSporT Claim: "vper" (Verifiable Persona Entity Representation)

   This section defines a new PASSporT claim, "vper" (Verifiable Persona
   Entity Representation), intended to encapsulate structured,
   extensible metadata about an entity authorized to use a telephone
   number.  The "vper" claim enables verifiable, privacy-conscious
   assertion of real-world entity attributes bound to a delegate
   certificate and associated number via the VESPER framework.

5.1.  Claim Format

   The "vper" claim is a JSON object containing the following REQUIRED
   fields:

   "vper": {
     "id": "string",              // Globally unique NA identifier
     "glue": ["string", ...],     // Array of GLUE URNs
     "name": "string",            // Registered legal business name
     "domain": "string"           // Domain associated with the entity
   }

   Field Definitions

   *  id (REQUIRED): A globally unique identifier for the entity
      associated via Number Assignment process.  This MAY be a UUID, a
      public key thumbprint, or another opaque identifier that supports
      global uniqueness and non-repudiation.  The identifier serves as a
      persistent reference to the entity across authority tokens and
      certificates.

   *  glue (REQUIRED): An array of GLUE URNs defined in
      [I-D.ietf-spice-glue-id] that bind the entity to one or more
      standardized, jurisdiction-specific or globally recognized
      business identifiers (e.g., DUNS number, EIN, LEI, VAT ID).  These
      enable interoperability across business registries and aid in
      regulatory traceability.

   *  name (REQUIRED): A string containing the legal business name as
      registered with the relevant jurisdictional authority or business
      registry.  This MUST match the name associated with the provided
      GLUE identifiers.



Wendt & Śliwa              Expires 8 May 2026                  [Page 16]

Internet-Draft                   VESPER                    November 2025


   *  domain (REQUIRED): A string representing the canonical domain name
      associated with the business, typically used for its public
      website and/or authorized communication addresses (e.g., email).
      This value MUST be DNS-resolvable and under the administrative
      control of the asserting entity.

   The "vper" claim may be used in full or in hashed form to support
   privacy-conscious deployments, as guided by the next section.

   Extensibility

   The "vper" claim is designed to be extensible.  Future specifications
   may define optional fields for additional structured entity metadata.
   Such extensions MUST be registered via the IANA PASSporT claim
   registry under this base claim or defined via new claim types.

6.  JWTClaimConstraints for Transparent Claims

   This section defines how VESPER uses JWTClaimConstraints [RFC8226]
   and EnhancedJWTClaimConstraints [RFC9118] to announce claims through
   the certificate that is submitted to a transparency log, while
   preserving privacy when desired or required.  In this model, a Claim
   Agent validates an Entity's desired claims and issues a
   JWTClaimConstraints Authority Token
   [I-D.wendt-acme-authority-token-jwtclaimcon] to a Certification
   Authority (CA).  The CA includes a corresponding constraints
   extension in the delegate certificate, and that certificate is logged
   for ecosystem transparency.  Three privacy modes are supported:

   1.  Transparent-Value — the constraint fixes the exact value to be
       asserted (fully transparent).

   2.  Semi-Private (Unsalted Hash) — the constraint fixes a hash of the
       value (guessable by an observer who can test likely values).

   3.  Private (Salted Commitment) — the constraint fixes a salted hash
       commitment; verification requires out-of-band salt disclosure
       from the Entity to an explicitly authorized relying party (RP).

6.1.  Goals and Non-Goals

   *  Binding: Relying parties MUST be able to verify that a presented
      claim value is one authorized by the certificate.

   *  Transparency: Observers MUST be able to audit which claims are
      authorized for a number, without necessarily learning the private
      values.




Wendt & Śliwa              Expires 8 May 2026                  [Page 17]

Internet-Draft                   VESPER                    November 2025


   *  Transparent Privacy Choice: Entities and Claim Agents MUST be able
      to choose per-claim whether values are public, semi-private, or
      private.

   *  Simplicity: All modes use widely deployed primitives (SHA-2) and
      reuse deterministic serialization similar to RCD integrity
      [RFC9795] mechanism.

   This section does not redefine the syntax of the JWTClaimConstraints/
   EnhancedJWTClaimConstraints extensions; it profiles their content to
   carry clear values or integrity artifacts for values.

6.2.  Addressing Claims in PASSporTs

   When Claims appear in PASSporTs, constraints refer to claims by claim
   name and, for structured claims, by JSON Pointer (RFC 6901) into the
   claim value.

   However, even if the PASSporT does not include an explicit claim as
   part of the signed object in the context of a call or message, an
   important property of the transparency in the VESPER framework is if
   the relying party wants to validate claims made as part of
   transparency validation outside of PASSporT verification, it can look
   at the JWTClaimsConstraints objects to validate claims.

6.3.  Constraint Encodings (Three Privacy Modes)

   For each constrained claim (or claim path), the JWTClaimConstraints
   Authority Token and the certificate extension MUST carry exactly one
   of the following encodings.

6.3.1.  Transparenct-Value Constraint

   The claim value is directly constrainted to be the value in open
   text.

   Verification: The VS compares the presented PASSporT claim value
   (after deterministic serialization if structured) for equality with
   value.

6.3.2.  Semi-Private Constraint (Unsalted Hash)

   Intended use: Values where limited hiding is acceptable,
   understanding that guessing is possible (e.g., logo URL or short
   labels).

   Semantics: The certificate fixes a digest D over the canonicalized
   value without a salt.



Wendt & Śliwa              Expires 8 May 2026                  [Page 18]

Internet-Draft                   VESPER                    November 2025


   Computation:

   V_bytes = deterministic_serialize(V) D = SHA-256(V_bytes)

   Verification: The VS computes D' over the received value and accepts
   if D' == digest.

   Privacy: An observer who can guess candidate values can compute
   digests and test them.  Use only when this risk is acceptable or
   values have sufficient entropy.  This mirrors the integrity mechanism
   in [RFC9795].

6.3.3.  Private Constraint (Salted Commitment with Selective Disclosure)

   Intended use: Sensitive values (e.g., opaque IDs, PII) where the
   Entity wants verifiability only for explicitly authorized RPs.

   Semantics: The certificate fixes a commitment C that incorporates a
   secret, per-claim salt S.  Only C (and optionally a hash of S) is
   published.  The Entity may later disclose S (and, if needed, V)
   out-of-band to an RP of its choosing for verification.

   Data Items

   V: value to be proven (octets after deterministic serialization).  S:
   secret random salt (≥ 128 bits from a CSPRNG).  H: a
   collision-resistant hash (MUST support SHA-256).

   Computation:

   V_bytes = deterministic_serialize(V) C = H( S || V_bytes ) (optional)
   S_hash = H(S)

   Publication: The certificate and transparency log include only commit
   (and optional salt_hash).  S and V are not published.

   Salt Disclosure: The Entity MAY disclose S (and, if required, V) to
   an authorized RP via an authenticated, confidential channel (e.g., a
   compact JWE encrypted to the RP's public key).  Disclosure is per-RP
   and per event at the Entity's discretion.

   Verification by RP: 1.  Obtain (V, S) from the Entity.  2.  Compute
   C' = H( S || deterministic_serialize(V) ).  3.  Accept if and only if
   C' == commit (and, if salt_hash present, H(S) == salt_hash).







Wendt & Śliwa              Expires 8 May 2026                  [Page 19]

Internet-Draft                   VESPER                    November 2025


6.4.  Certificate and Transparency Log Requirements

   The CA MUST copy the constraints from the JWTClaimConstraints
   Authority Token into the certificate's JWTClaimConstraints/
   EnhancedJWTClaimConstraints extension without widening them.

   The issued certificate MUST be submitted to a transparency log; the
   log therefore reveals: * the existence of each constrained claim/
   path, and * for each, either the clear value, an unsalted hash, or a
   salted commitment (but never the salt). * For mode commit,
   implementations MUST NOT include the salt in the certificate or log.

6.5.  Authority Token Requirements

   A JWTClaimConstraints Authority Token MUST:

   *  identify the Claim Agent and the Entity,

   *  enumerate the constrained claims/paths and, for each, one of the
      three encodings above,

   *  specify the hash algorithm where applicable ("alg": "sha-256"
      RECOMMENDED),

   *  be time-bounded and bound to the TN(s) (e.g., via TNAuthList)
      authorized for the Entity.

   The CA MUST verify the token per
   [I-D.wendt-acme-authority-token-jwtclaimcon] and issue a certificate
   that does not exceed the token's scope.

6.6.  Verification by a Relying Party (VS)

   When verifying a PASSporT:

   *  For value mode: ensure the presented claim equals the constrained
      value.

   *  For hash mode: recompute the digest over the presented claim and
      compare.

   *  For commit mode: if the RP has received S (and V if needed)
      out-of-band, recompute and compare the commitment.  If S is not
      available, the RP MUST treat the constraint as "authorized but not
      presently verifiable" and apply local policy (e.g., defer
      validation, request disclosure, or treat as unauthenticated
      attribute).




Wendt & Śliwa              Expires 8 May 2026                  [Page 20]

Internet-Draft                   VESPER                    November 2025


7.  Security Considerations

   TBD

8.  IANA Considerations

   New PASSporT Claim: "vper"

   This document requests that the IANA add a new entry to the "PASSporT
   Claims" registry as follows:

               +============+==================+===========+
               | Claim Name | Claim Value Type | Reference |
               +============+==================+===========+
               | vper       | JSON object      | RFCthis   |
               +------------+------------------+-----------+

                  Table 1: PASSporT Claims registry entry
                                 for "vper

9.  Acknowledgments

   The authors would like to acknowledge Jon Peterson for valuable
   feedback into the concepts and framework for this document.  This
   work is mainly based on the many years of inputs and specifications
   developed in the STIR working group and the larger telephone industry
   which the authors acknowledge as a critically important feedback and
   influence toward the development of the VESPER framework.

10.  Normative References

   [I-D.ietf-spice-glue-id]
              Zundel, B., Dingle, P., and M. B. Jones, "GLobal Unique
              Enterprise (GLUE) Identifiers", Work in Progress,
              Internet-Draft, draft-ietf-spice-glue-id-02, 20 October
              2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
              spice-glue-id-02>.

   [I-D.ietf-stir-certificates-shortlived]
              Peterson, J., "Short-Lived Certificates for Secure
              Telephone Identity", Work in Progress, Internet-Draft,
              draft-ietf-stir-certificates-shortlived-03, 6 July 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-stir-
              certificates-shortlived-03>.

   [I-D.ietf-stir-rfc4916-update]
              Peterson, J. and C. Wendt, "Connected Identity for STIR",
              Work in Progress, Internet-Draft, draft-ietf-stir-rfc4916-



Wendt & Śliwa              Expires 8 May 2026                  [Page 21]

Internet-Draft                   VESPER                    November 2025


              update-07, 7 July 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-stir-
              rfc4916-update-07>.

   [I-D.wendt-acme-authority-token-jwtclaimcon]
              Wendt, C. and D. Hancock, "JWTClaimConstraints profile of
              ACME Authority Token", Work in Progress, Internet-Draft,
              draft-wendt-acme-authority-token-jwtclaimcon-03, 7 July
              2025, <https://datatracker.ietf.org/doc/html/draft-wendt-
              acme-authority-token-jwtclaimcon-03>.

   [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/rfc/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/rfc/rfc8174>.

   [RFC8224]  Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
              "Authenticated Identity Management in the Session
              Initiation Protocol (SIP)", RFC 8224,
              DOI 10.17487/RFC8224, February 2018,
              <https://www.rfc-editor.org/rfc/rfc8224>.

   [RFC8225]  Wendt, C. and J. Peterson, "PASSporT: Personal Assertion
              Token", RFC 8225, DOI 10.17487/RFC8225, February 2018,
              <https://www.rfc-editor.org/rfc/rfc8225>.

   [RFC8226]  Peterson, J. and S. Turner, "Secure Telephone Identity
              Credentials: Certificates", RFC 8226,
              DOI 10.17487/RFC8226, February 2018,
              <https://www.rfc-editor.org/rfc/rfc8226>.

   [RFC9118]  Housley, R., "Enhanced JSON Web Token (JWT) Claim
              Constraints for Secure Telephone Identity Revisited (STIR)
              Certificates", RFC 9118, DOI 10.17487/RFC9118, August
              2021, <https://www.rfc-editor.org/rfc/rfc9118>.

   [RFC9447]  Peterson, J., Barnes, M., Hancock, D., and C. Wendt,
              "Automated Certificate Management Environment (ACME)
              Challenges Using an Authority Token", RFC 9447,
              DOI 10.17487/RFC9447, September 2023,
              <https://www.rfc-editor.org/rfc/rfc9447>.






Wendt & Śliwa              Expires 8 May 2026                  [Page 22]

Internet-Draft                   VESPER                    November 2025


   [RFC9448]  Wendt, C., Hancock, D., Barnes, M., and J. Peterson,
              "TNAuthList Profile of Automated Certificate Management
              Environment (ACME) Authority Token", RFC 9448,
              DOI 10.17487/RFC9448, September 2023,
              <https://www.rfc-editor.org/rfc/rfc9448>.

   [RFC9795]  Wendt, C. and J. Peterson, "Personal Assertion Token
              (PASSporT) Extension for Rich Call Data", RFC 9795,
              DOI 10.17487/RFC9795, July 2025,
              <https://www.rfc-editor.org/rfc/rfc9795>.

Authors' Addresses

   Chris Wendt
   Somos, Inc.
   United States of America
   Email: chris@appliedbits.com


   Rob Śliwa
   Somos, Inc.
   United States of America
   Email: robjsliwa@gmail.com




























Wendt & Śliwa              Expires 8 May 2026                  [Page 23]


