# llm_cache

draft_name: draft-oauth-ai-agents-on-behalf-of-user
prompt_hash: 770eada04230c951
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:56:20.243310+00:00
request_json:
Extract discrete technical ideas and mechanisms from this IETF draft.
Return a JSON array. Each element: {"title":"short name","description":"1-2 sentences","type":"mechanism|protocol|pattern|requirement|architecture|extension"}

draft-oauth-ai-agents-on-behalf-of-user | OAuth 2.0 Extension: On-Behalf-Of User Authorization for AI Agents | 16pg
Abstract: This specification extends the OAuth 2.0 Authorization Framework
   [RFC6749] to enable AI agents to securely obtain access tokens for
   acting on behalf of users.  It introduces the *requested_actor*
   parameter in authorization requests to identify the specific agent
   requiring delegation and the *actor_token* parameter in token
   requests to authenticate the agent during the exchange of an
   authorization code for an access token.  The flow can be initiated by
   a resource server challenge, ensuring that user consent is obtained
   dynamically when access is attempted.  This extension ensures secure
   delegation with explicit user consent, streamlines the authorization
   flow, and enhances auditability through access token claims that
   document the delegation chain from the user to the agent via a client
   application.





Web Authorization Protocol                                T. S. Senarath
Internet-Draft                                            A. Dissanayaka
Intended status: Informational                                      WSO2
Expires: 27 February 2026                                 26 August 2025


   OAuth 2.0 Extension: On-Behalf-Of User Authorization for AI Agents
               draft-oauth-ai-agents-on-behalf-of-user-02

Abstract

   This specification extends the OAuth 2.0 Authorization Framework
   [RFC6749] to enable AI agents to securely obtain access tokens for
   acting on behalf of users.  It introduces the *requested_actor*
   parameter in authorization requests to identify the specific agent
   requiring delegation and the *actor_token* parameter in token
   requests to authenticate the agent during the exchange of an
   authorization code for an access token.  The flow can be initiated by
   a resource server challenge, ensuring that user consent is obtained
   dynamically when access is attempted.  This extension ensures secure
   delegation with explicit user consent, streamlines the authorization
   flow, and enhances auditability through access token claims that
   document the delegation chain from the user to the agent via a client
   application.

About This Document

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

   Status information for this document may be found at
   https://datatracker.ietf.org/doc/draft-oauth-ai-agents-on-behalf-of-
   user/.

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

   Source for this draft and an issue tracker can be found at
   https://github.com/shashimalcse/oauth-ai-agents.

Status of This Memo

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






Senarath & Dissanayaka  Expires 27 February 2026                [Page 1]

Internet-Draft  OAuth 2.0 Extension: On-Behalf-Of User A     August 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 27 February 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 Docume

Return 3-8 ideas. Focus on CONCRETE technical contributions, not general statements.
JSON array only, no fences.

response_json:
[
  {
    "title": "requested_actor parameter",
    "description": "A new parameter in OAuth 2.0 authorization requests that identifies the specific AI agent requiring delegation. This allows the authorization server to know which agent will be acting on behalf of the user.",
    "type": "extension"
  },
  {
    "title": "actor_token parameter", 
    "description": "A new parameter in OAuth 2.0 token requests used to authenticate the AI agent during the exchange of an authorization code for an access token. This ensures only the intended agent can complete the token exchange.",
    "type": "extension"
  },
  {
    "title": "Resource server initiated flow",
    "description": "A mechanism where the resource server can challenge and initiate the authorization flow, ensuring user consent is obtained dynamically when an AI agent attempts to access resources. This enables just-in-time authorization.",
    "type": "pattern"
  },
  {
    "title": "Delegation chain in access tokens",
    "description": "Access tokens contain claims that document the complete delegation chain from the user to the AI agent via the client application. This provides full auditability of who is acting on whose behalf.",
    "type": "mechanism"
  },
  {
    "title": "AI agent authentication during token exchange",
    "description": "A secure mechanism requiring AI agents to authenticate themselves when exchanging authorization codes for access tokens. This prevents unauthorized agents from using valid authorization codes.",
    "type": "mechanism"
  }
]


draft_name: draft-oauth-transaction-tokens-for-agents
prompt_hash: 3edf77c437960214
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:56:27.410661+00:00
request_json:
Extract discrete technical ideas and mechanisms from this IETF draft.
Return a JSON array. Each element: {"title":"short name","description":"1-2 sentences","type":"mechanism|protocol|pattern|requirement|architecture|extension"}

draft-oauth-transaction-tokens-for-agents | Transaction Tokens For Agents | 13pg
Abstract: This document specifies an extension to the OAuth Transaction Tokens
   framework (https://drafts.oauth.net/oauth-transaction-tokens/draft-
   ietf-oauth-transaction-tokens.html) to support agent context
   propagation within Transaction Tokens for agent-based workloads.  The
   extension defines two new context fields: 'actor' and 'principal'.
   The 'actor' field identifies the agent performing the action, while
   the 'principal' field identifies the human or system entity that
   initiated the agent's action.  For autonomous agents operating
   independently, the 'principal' field MAY be omitted.  These
   additional context fields enable services within the call graph to
   make more granular access control decisions, thereby enhancing
   security.





Network Working Group                                            A. RAUT
Internet-Draft                                                    Amazon
Intended status: Informational                          11 February 2026
Expires: 15 August 2026


                     Transaction Tokens For Agents
              draft-oauth-transaction-tokens-for-agents-04

Abstract

   This document specifies an extension to the OAuth Transaction Tokens
   framework (https://drafts.oauth.net/oauth-transaction-tokens/draft-
   ietf-oauth-transaction-tokens.html) to support agent context
   propagation within Transaction Tokens for agent-based workloads.  The
   extension defines two new context fields: 'actor' and 'principal'.
   The 'actor' field identifies the agent performing the action, while
   the 'principal' field identifies the human or system entity that
   initiated the agent's action.  For autonomous agents operating
   independently, the 'principal' field MAY be omitted.  These
   additional context fields enable services within the call graph to
   make more granular access control decisions, thereby enhancing
   security.

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://ashayraut.github.io/oauth-transactiontokens-for-agents/draft-
   oauth-transaction-tokens-for-agents.html.  Status information for
   this document may be found at https://datatracker.ietf.org/doc/draft-
   oauth-transaction-tokens-for-agents/.

   Source for this draft and an issue tracker can be found at
   https://github.com/ashayraut/oauth-transactiontokens-for-agents.

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





RAUT                     Expires 15 August 2026                 [Page 1]

Internet-Draft        Transaction Tokens For Agents        February 2026


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

   This Internet-Draft will expire on 15 August 2026.

Copyright Notice

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

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

Return 3-8 ideas. Focus on CONCRETE technical contributions, not general statements.
JSON array only, no fences.

response_json:
[
  {
    "title": "Actor Context Field",
    "description": "A new context field 'actor' that identifies the agent performing the action within Transaction Tokens. This field enables services to distinguish which specific agent is executing operations in agent-based workloads.",
    "type": "extension"
  },
  {
    "title": "Principal Context Field", 
    "description": "A new context field 'principal' that identifies the human or system entity that initiated the agent's action. This field may be omitted for autonomous agents operating independently.",
    "type": "extension"
  },
  {
    "title": "Agent Context Propagation",
    "description": "A mechanism for propagating agent-specific context information through Transaction Tokens across service call graphs. This enables downstream services to understand the agent hierarchy and make appropriate access control decisions.",
    "type": "mechanism"
  },
  {
    "title": "OAuth Transaction Tokens Extension Framework",
    "description": "An extension architecture that builds upon the existing OAuth Transaction Tokens framework to add agent-specific capabilities. The extension maintains compatibility while adding new context fields for agent workloads.",
    "type": "extension"
  },
  {
    "title": "Granular Agent-Based Access Control",
    "description": "A pattern enabling services within the call graph to make more fine-grained access control decisions based on both the acting agent and the initiating principal. This enhances security by providing additional context for authorization decisions.",
    "type": "pattern"
  }
]


draft_name: draft-pang-agents-networking-scenarios
prompt_hash: f8750cb77fbe9119
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:56:34.580436+00:00
request_json:
Extract discrete technical ideas and mechanisms from this IETF draft.
Return a JSON array. Each element: {"title":"short name","description":"1-2 sentences","type":"mechanism|protocol|pattern|requirement|architecture|extension"}

draft-pang-agents-networking-scenarios | Agents Networking Scenarios in Enterprise and Broadband Networks | 9pg
Abstract: This document describes agents networking scenarios in enterprise and
   home broadband networks.  These scenarios differ from mobile networks
   and Internet scenarios.  Since the agentic service is still at the
   emerging stage, especially in enterprise and home broadband networks,
   the scenarios are mostly based on reasonable assumptions.





network working group                                            R. Pang
Internet-Draft                                                    M. Han
Intended status: Informational                              China Unicom
Expires: 10 May 2026                                              B. Liu
                                                                L. Zhang
                                                                  Q. Gao
                                                                 N. Geng
                                                                X. Shang
                                                                   Z. Li
                                                     Huawei Technologies
                                                         6 November 2025


    Agents Networking Scenarios in Enterprise and Broadband Networks
               draft-pang-agents-networking-scenarios-00

Abstract

   This document describes agents networking scenarios in enterprise and
   home broadband networks.  These scenarios differ from mobile networks
   and Internet scenarios.  Since the agentic service is still at the
   emerging stage, especially in enterprise and home broadband networks,
   the scenarios are mostly based on reasonable assumptions.

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

Copyright Notice

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






Pang, et al.               Expires 10 May 2026                  [Page 1]

Internet-Draft         Agents Networking Scenarios         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
     1.1.  Requirements Language . . . . . . . . . .

Return 3-8 ideas. Focus on CONCRETE technical contributions, not general statements.
JSON array only, no fences.

response_json:
[
  {
    "title": "Agent-Based Network Management",
    "description": "Deployment of autonomous agents within enterprise and home broadband networks for network management tasks. These agents operate differently from mobile network deployments due to distinct infrastructure and operational requirements.",
    "type": "architecture"
  },
  {
    "title": "Enterprise Agent Service Scenarios",
    "description": "Specific use cases for agentic services within enterprise network environments that leverage fixed broadband infrastructure. These scenarios address enterprise-specific networking requirements and service patterns.",
    "type": "pattern"
  },
  {
    "title": "Home Broadband Agent Integration",
    "description": "Integration patterns for agents operating within residential broadband networks, including home gateway interactions and local service provisioning. This differs from mobile and general Internet agent deployments.",
    "type": "mechanism"
  },
  {
    "title": "Fixed Network Agent Communication",
    "description": "Communication mechanisms and protocols for agents operating in fixed enterprise and broadband network environments. These address the specific characteristics of non-mobile network topologies.",
    "type": "protocol"
  }
]


draft_name: draft-pbs-sidrops-roaanycast
prompt_hash: d76d6340e687eedd
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:56:42.504325+00:00
request_json:
Extract discrete technical ideas and mechanisms from this IETF draft.
Return a JSON array. Each element: {"title":"short name","description":"1-2 sentences","type":"mechanism|protocol|pattern|requirement|architecture|extension"}

draft-pbs-sidrops-roaanycast | Route Origin Authorization (ROA) Governance for Anycasted Services with Unique Origin ASNs | 7pg
Abstract: This document describes a set of best practices for the management of
   Route Origin Authorizations (ROAs) used to certify globally anycasted
   services with unique origin autonomous system numbers (ASNs) per
   node.  It identifies key risk areas related to anycast-based ROA
   publication and how to mitigate technical risk for RPKI operations.





Network Working Group                                     L. Poulopoulos
Internet-Draft                                               S. Boudjema
Intended status: Best Current Practice                       H. Siddique
Expires: 7 March 2026                                           Verisign
                                                        3 September 2025


Route Origin Authorization (ROA) Governance for Anycasted Services with
                           Unique Origin ASNs
                    draft-pbs-sidrops-roaanycast-00

Abstract

   This document describes a set of best practices for the management of
   Route Origin Authorizations (ROAs) used to certify globally anycasted
   services with unique origin autonomous system numbers (ASNs) per
   node.  It identifies key risk areas related to anycast-based ROA
   publication and how to mitigate technical risk for RPKI operations.

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 7 March 2026.

Copyright Notice

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











Poulopoulos, et al.       Expires 7 March 2026                  [Page 1]

Internet-Draft       ROAs for Unique Origin Anycast       September 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
     1.1.  Conventions Used in This Document . . . . . . . . . . . .   3
   2.  Single-prefix Minimal ROAs  . . . . . . . . . . . . . . . . .   4
   3.  Sequential-Use EE Certificate . . . . . . . . . . . . . . . .   4
   4.  Single Signing Time . . . . . . . . . . . . . . . . . . . . .   4
   5.  Synchronous Operations  . . . . . . . . . . . . . . . . . . .   4
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5

Return 3-8 ideas. Focus on CONCRETE technical contributions, not general statements.
JSON array only, no fences.

response_json:
[
  {
    "title": "Single-prefix Minimal ROAs",
    "description": "ROAs should contain only one prefix per ROA object to minimize impact of revocation or updates in anycast deployments. This reduces the blast radius when individual anycast nodes need ROA modifications.",
    "type": "pattern"
  },
  {
    "title": "Sequential-Use EE Certificate",
    "description": "End Entity certificates should be used sequentially rather than in parallel for ROA signing operations. This prevents certificate management conflicts in distributed anycast environments.",
    "type": "mechanism"
  },
  {
    "title": "Single Signing Time",
    "description": "All ROAs for a given anycast service should use the same signing timestamp to ensure consistency across nodes. This prevents timing-based validation issues in RPKI operations.",
    "type": "requirement"
  },
  {
    "title": "Synchronous Operations",
    "description": "ROA publication and revocation operations must be performed synchronously across all anycast nodes. This prevents temporary invalid states during RPKI validation.",
    "type": "mechanism"
  },
  {
    "title": "Unique Origin ASN per Anycast Node",
    "description": "Each anycast node uses a distinct autonomous system number for route origination while serving the same prefixes. This enables granular RPKI validation and node-specific ROA management.",
    "type": "architecture"
  }
]


draft_name: draft-pioli-agent-discovery
prompt_hash: 1712436cacdcaefd
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:56:48.586227+00:00
request_json:
Extract discrete technical ideas and mechanisms from this IETF draft.
Return a JSON array. Each element: {"title":"short name","description":"1-2 sentences","type":"mechanism|protocol|pattern|requirement|architecture|extension"}

draft-pioli-agent-discovery | Agent Registration and Discovery Protocol (ARDP) | 13pg
Abstract: This document specifies the Agent Registration and Discovery Protocol
   (ARDP), a lightweight protocol for registering, discovering, and
   reaching autonomous software agents in distributed and federated
   environments.  ARDP provides stable agent identities, dynamic
   endpoint resolution, capability advertisement (including protocol
   selection among MCP, A2A, HTTP, and gRPC), minimal presence
   signaling, and a security-first discovery control plane.  ARDP is
   transport-agnostic and complementary to existing agent interaction
   protocols.





Network Working Group                                           R. Pioli
Internet-Draft                                               Independent
Intended status: Informational                             February 2026
Expires: 28 August 2026


            Agent Registration and Discovery Protocol (ARDP)
                     draft-pioli-agent-discovery-01

Abstract

   This document specifies the Agent Registration and Discovery Protocol
   (ARDP), a lightweight protocol for registering, discovering, and
   reaching autonomous software agents in distributed and federated
   environments.  ARDP provides stable agent identities, dynamic
   endpoint resolution, capability advertisement (including protocol
   selection among MCP, A2A, HTTP, and gRPC), minimal presence
   signaling, and a security-first discovery control plane.  ARDP is
   transport-agnostic and complementary to existing agent interaction
   protocols.

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 August 2026.

Copyright Notice

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

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



Pioli                    Expires 28 August 2026                 [Page 1]

Internet-Draft  Agent Registration and Discovery Protoco   February 2026


   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.  Design Goals  . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Architecture Overview . . . . . . . . . . . . . . . . . . . .   4
   6.  Layering and Composition  . . . . . . . . . . . . . . . . . .   4
   7.  Agent Identity  . . . . . . . . . . . . . . 

Return 3-8 ideas. Focus on CONCRETE technical contributions, not general statements.
JSON array only, no fences.

response_json:
[
  {
    "title": "Agent Registration and Discovery Protocol (ARDP)",
    "description": "A lightweight protocol for registering, discovering, and reaching autonomous software agents in distributed and federated environments. Provides stable agent identities, dynamic endpoint resolution, and capability advertisement.",
    "type": "protocol"
  },
  {
    "title": "Multi-Protocol Capability Advertisement",
    "description": "Mechanism for agents to advertise their supported protocols including MCP, A2A, HTTP, and gRPC for protocol selection during discovery.",
    "type": "mechanism"
  },
  {
    "title": "Stable Agent Identity System",
    "description": "Identity framework that provides persistent agent identifiers separate from dynamic network endpoints for reliable agent addressing.",
    "type": "architecture"
  },
  {
    "title": "Dynamic Endpoint Resolution",
    "description": "Protocol mechanism that allows agents to update and resolve their network endpoints dynamically as they move or change locations.",
    "type": "mechanism"
  },
  {
    "title": "Security-First Discovery Control Plane",
    "description": "Discovery architecture designed with security as a primary concern, providing controlled agent visibility and access mechanisms.",
    "type": "architecture"
  },
  {
    "title": "Transport-Agnostic Protocol Design",
    "description": "Protocol design pattern that operates independently of underlying transport mechanisms while complementing existing agent interaction protocols.",
    "type": "pattern"
  }
]


draft_name: draft-pocero-authkem-edhoc
prompt_hash: 663d37b2361db0fe
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:56:55.264186+00:00
request_json:
Extract discrete technical ideas and mechanisms from this IETF draft.
Return a JSON array. Each element: {"title":"short name","description":"1-2 sentences","type":"mechanism|protocol|pattern|requirement|architecture|extension"}

draft-pocero-authkem-edhoc | KEM-based Authentication for EDHOC | 41pg
Abstract: This document specifies extensions to the Ephemeral Diffie-Hellman
   over COSE (EDHOC) protocol to provide resistance against quantum
   computer adversaries by incorporating Post-Quantum Cryptography (PQC)
   mechanisms for both key exchange and authentication.  It defines a
   Key Encapsulation Mechanism (KEM)-based authentication method to
   enable signature-free post-quantum authentication when PQC KEMs, such
   as NIST-standardized ML-KEM, are used.  The document further
   describes scenarios where both parties employ KEM-based
   authentication, as well as cases where authentication methods are
   combined, with one party using KEM-based authentication and the other
   relying on a PQC signature scheme.





individual                                              L. Pocero Fraile
Internet-Draft                                               C. Koulamas
Intended status: Standards Track                          A.P. Fournaris
Expires: 27 April 2026                                     E. Haleplidis
                                                        ISI, R.C. ATHENA
                                                         24 October 2025


                   KEM-based Authentication for EDHOC
                     draft-pocero-authkem-edhoc-01

Abstract

   This document specifies extensions to the Ephemeral Diffie-Hellman
   over COSE (EDHOC) protocol to provide resistance against quantum
   computer adversaries by incorporating Post-Quantum Cryptography (PQC)
   mechanisms for both key exchange and authentication.  It defines a
   Key Encapsulation Mechanism (KEM)-based authentication method to
   enable signature-free post-quantum authentication when PQC KEMs, such
   as NIST-standardized ML-KEM, are used.  The document further
   describes scenarios where both parties employ KEM-based
   authentication, as well as cases where authentication methods are
   combined, with one party using KEM-based authentication and the other
   relying on a PQC signature scheme.

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

Copyright Notice

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





Pocero Fraile, et al.     Expires 27 April 2026                 [Page 1]

Internet-Draft     KEM-based Authentication for EDHOC       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  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Motivation  . . . . . . . . . . . . . . . . . . . .

Return 3-8 ideas. Focus on CONCRETE technical contributions, not general statements.
JSON array only, no fences.

response_json:
[
  {
    "title": "KEM-based Authentication Extension",
    "description": "Extends EDHOC protocol with Key Encapsulation Mechanism (KEM)-based authentication to enable signature-free post-quantum authentication. Provides quantum-resistant authentication using PQC KEMs like NIST-standardized ML-KEM.",
    "type": "extension"
  },
  {
    "title": "Hybrid Authentication Scenarios",
    "description": "Defines authentication scenarios where both parties use KEM-based authentication, as well as mixed cases where one party uses KEM-based authentication and the other uses PQC signature schemes. Enables flexible deployment of post-quantum authentication methods.",
    "type": "mechanism"
  },
  {
    "title": "Quantum-Resistant EDHOC Protocol",
    "description": "Incorporates Post-Quantum Cryptography mechanisms for both key exchange and authentication in the Ephemeral Diffie-Hellman over COSE protocol. Provides comprehensive protection against quantum computer adversaries.",
    "type": "protocol"
  },
  {
    "title": "Signature-Free PQC Authentication",
    "description": "Enables post-quantum authentication without relying on digital signatures by using KEM-based mechanisms. Offers an alternative authentication approach that may have different performance or security characteristics than signature-based methods.",
    "type": "mechanism"
  }
]


draft_name: draft-pocero-authkem-ikr-edhoc
prompt_hash: 8ec223c004d18550
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:57:02.739903+00:00
request_json:
Extract discrete technical ideas and mechanisms from this IETF draft.
Return a JSON array. Each element: {"title":"short name","description":"1-2 sentences","type":"mechanism|protocol|pattern|requirement|architecture|extension"}

draft-pocero-authkem-ikr-edhoc | KEM-based Authentication for EDHOC in Initiator-Known Responder (IKR) Scenarios | 26pg
Abstract: This document specifies a more efficient variant of a Key
   Encapsulation Mechanism (KEM)-based authentication method for the
   Ephemeral Diffie-Hellman Over COSE (EDHOC) lightweight protocol,
   designed for the specific scenario in which the Initiator has prior
   knowledge of the Responder’s credentials, a case commonly found in
   constrained environments.  Improving upon the approach described in
   KEM-based Authentication for EDHOC, this method uses only a mandatory
   three-message handshake to enable signature-free post-quantum
   authentication when PQC KEMs, such as the NIST-standardized ML-KEM,
   are employed, while still providing mutual authentication, forward
   secrecy, and a degree of identity protection.





individual                                              L. Pocero Fraile
Internet-Draft                                               C. Koulamas
Intended status: Standards Track                          A.P. Fournaris
Expires: 24 July 2026                                      E. Haleplidis
                                                        ISI, R.C. ATHENA
                                                         20 January 2026


 KEM-based Authentication for EDHOC in Initiator-Known Responder (IKR)
                               Scenarios
                   draft-pocero-authkem-ikr-edhoc-01

Abstract

   This document specifies a more efficient variant of a Key
   Encapsulation Mechanism (KEM)-based authentication method for the
   Ephemeral Diffie-Hellman Over COSE (EDHOC) lightweight protocol,
   designed for the specific scenario in which the Initiator has prior
   knowledge of the Responder’s credentials, a case commonly found in
   constrained environments.  Improving upon the approach described in
   KEM-based Authentication for EDHOC, this method uses only a mandatory
   three-message handshake to enable signature-free post-quantum
   authentication when PQC KEMs, such as the NIST-standardized ML-KEM,
   are employed, while still providing mutual authentication, forward
   secrecy, and a degree of identity protection.

Status of This Memo

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

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

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

   This Internet-Draft will expire on 24 July 2026.

Copyright Notice

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




Pocero Fraile, et al.     Expires 24 July 2026                  [Page 1]

Internet-Draft  KEM-based Authentication for EDHOC in In    January 2026


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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . .

Return 3-8 ideas. Focus on CONCRETE technical contributions, not general statements.
JSON array only, no fences.

response_json:
[
  {
    "title": "IKR Three-Message Handshake",
    "description": "A reduced three-message EDHOC handshake optimized for scenarios where the initiator already knows the responder's credentials. This eliminates the need for additional message exchanges required in the general KEM-based authentication method.",
    "type": "protocol"
  },
  {
    "title": "KEM-based Post-Quantum Authentication",
    "description": "Authentication mechanism using Key Encapsulation Mechanisms (KEMs) like ML-KEM instead of traditional signatures for post-quantum security. This enables signature-free authentication while maintaining mutual authentication properties.",
    "type": "mechanism"
  },
  {
    "title": "Initiator-Known Responder (IKR) Scenario",
    "description": "A specific deployment pattern where the initiator has prior knowledge of the responder's credentials before protocol execution. This assumption allows for protocol optimizations in constrained environments.",
    "type": "pattern"
  },
  {
    "title": "EDHOC KEM Authentication Extension",
    "description": "An extension to the standard EDHOC protocol that integrates KEM-based authentication mechanisms. This variant provides an alternative to signature-based authentication methods in EDHOC.",
    "type": "extension"
  },
  {
    "title": "Constrained Environment Optimization",
    "description": "Protocol design optimizations specifically targeting resource-constrained environments by reducing message overhead and computational requirements. The three-message approach reduces communication rounds compared to the general KEM-based method.",
    "type": "architecture"
  }
]


draft_name: draft-ra-emu-pqc-eapaka
prompt_hash: e0d3f57827eb5197
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:57:09.805867+00:00
request_json:
Extract discrete technical ideas and mechanisms from this IETF draft.
Return a JSON array. Each element: {"title":"short name","description":"1-2 sentences","type":"mechanism|protocol|pattern|requirement|architecture|extension"}

draft-ra-emu-pqc-eapaka | Post-Quantum Key Encapsulation Mechanisms (PQ KEMs) in EAP-AKA prime | 15pg
Abstract: Forward Secrecy for the Extensible Authentication Protocol Method for
   Authentication and Key Agreement (EAP-AKA' FS) is specified in
   [RFC9678], providing updates to [RFC9048] with an optional extension
   that offers ephemeral key exchange using the traditional Ephemeral
   Elliptic Curve Diffie-Hellman (ECDHE) key agreement algorithm for
   achieving perfect forward secrecy (PFS).  However, it is susceptible
   to future threats from Cryptographically Relevant Quantum Computers,
   which could potentially compromise a traditional ephemeral public
   key.  If the adversary has also obtained knowledge of the long-term
   key and ephemeral public key, it could compromise session keys
   generated as part of the authentication run in EAP-AKA'.

   This draft aims to enhance the security of EAP-AKA' FS protocol by
   making it quantum-safe using Post-Quantum Key Encapsulation
   Mechanisms (PQ-KEMs).





EMU                                                             T. Reddy
Internet-Draft                                               A. Banerjee
Intended status: Standards Track                                   Nokia
Expires: 30 November 2025                                    29 May 2025


  Post-Quantum Key Encapsulation Mechanisms (PQ KEMs) in EAP-AKA prime
                       draft-ra-emu-pqc-eapaka-05

Abstract

   Forward Secrecy for the Extensible Authentication Protocol Method for
   Authentication and Key Agreement (EAP-AKA' FS) is specified in
   [RFC9678], providing updates to [RFC9048] with an optional extension
   that offers ephemeral key exchange using the traditional Ephemeral
   Elliptic Curve Diffie-Hellman (ECDHE) key agreement algorithm for
   achieving perfect forward secrecy (PFS).  However, it is susceptible
   to future threats from Cryptographically Relevant Quantum Computers,
   which could potentially compromise a traditional ephemeral public
   key.  If the adversary has also obtained knowledge of the long-term
   key and ephemeral public key, it could compromise session keys
   generated as part of the authentication run in EAP-AKA'.

   This draft aims to enhance the security of EAP-AKA' FS protocol by
   making it quantum-safe using Post-Quantum Key Encapsulation
   Mechanisms (PQ-KEMs).

About This Document

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

   Status information for this document may be found at
   https://datatracker.ietf.org/doc/draft-ra-emu-pqc-eapaka/.

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

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



Reddy & Banerjee        Expires 30 November 2025                [Page 1]

Internet-Draft          PQ KEMs in EAP-AKA prime                May 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 30 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.


Return 3-8 ideas. Focus on CONCRETE technical contributions, not general statements.
JSON array only, no fences.

response_json:
[
  {
    "title": "PQ-KEM Integration in EAP-AKA'",
    "description": "Replaces traditional ECDHE key exchange in EAP-AKA' FS with Post-Quantum Key Encapsulation Mechanisms to achieve quantum-safe forward secrecy. The mechanism integrates PQ-KEMs into the existing EAP-AKA' authentication framework.",
    "type": "mechanism"
  },
  {
    "title": "Quantum-Safe Session Key Generation",
    "description": "Modifies the session key derivation process in EAP-AKA' to incorporate shared secrets from PQ-KEM operations. This prevents compromise of session keys even if adversaries have both long-term keys and quantum computers.",
    "type": "mechanism"
  },
  {
    "title": "EAP-AKA' FS Protocol Enhancement",
    "description": "Extends the Forward Secrecy variant of EAP-AKA' (RFC9678) to support post-quantum cryptography while maintaining backward compatibility. The enhancement provides protection against future quantum computer threats.",
    "type": "extension"
  },
  {
    "title": "Hybrid Classical-Quantum Key Exchange",
    "description": "Combines traditional ephemeral key exchange methods with post-quantum key encapsulation to provide defense in depth. This approach maintains security even if one cryptographic method is compromised.",
    "type": "pattern"
  }
]


draft_name: draft-ramakrishna-satp-data-sharing
prompt_hash: 877e8040e0cff835
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:57:16.973602+00:00
request_json:
Extract discrete technical ideas and mechanisms from this IETF draft.
Return a JSON array. Each element: {"title":"short name","description":"1-2 sentences","type":"mechanism|protocol|pattern|requirement|architecture|extension"}

draft-ramakrishna-satp-data-sharing | Protocol for Requesting and Sharing Views across Networks | 21pg
Abstract: With increasing use of DLT (distributed ledger technology) systems,
   including blockchain systems and networks, for virtual assets, there
   is a need for asset-related data and metadata to traverse system
   boundaries and link their respective business workflows.  Systems and
   networks can define and project views, or asset states, outside of
   their boundaries, as well as guard them using access control
   policies, and external agents or other systems can address those
   views in a globally unique manner.  Universal interoperability
   requires such systems and networks to request and supply views via
   gateway nodes using a request-response protocol.  The endpoints of
   this protocol lie within the respective systems or in networks of
   peer nodes, but the cross-system protocol occurs through the systems’
   respective gateways.  The inter-gateway protocol that allows an
   external party to request a view by an address and a DLT system to
   return a view in response must be DLT-neutral and mask the internal
   particularities and complexities of the DLT systems.  The view
   generation and verification modules at the endpoints must obey the
   native consensus logic of their respective networks.





Secure Asset Transfer Protocol                            V. Ramakrishna
Internet-Draft                                                 V. Pandit
Intended status: Informational                              IBM Research
Expires: 19 March 2026                                          E. Abebe
                                                               Consensys
                                                               S. Nishad
                                                       D. Vinayagamurthy
                                                            IBM Research
                                                       15 September 2025


       Protocol for Requesting and Sharing Views across Networks
                 draft-ramakrishna-satp-data-sharing-04

Abstract

   With increasing use of DLT (distributed ledger technology) systems,
   including blockchain systems and networks, for virtual assets, there
   is a need for asset-related data and metadata to traverse system
   boundaries and link their respective business workflows.  Systems and
   networks can define and project views, or asset states, outside of
   their boundaries, as well as guard them using access control
   policies, and external agents or other systems can address those
   views in a globally unique manner.  Universal interoperability
   requires such systems and networks to request and supply views via
   gateway nodes using a request-response protocol.  The endpoints of
   this protocol lie within the respective systems or in networks of
   peer nodes, but the cross-system protocol occurs through the systems’
   respective gateways.  The inter-gateway protocol that allows an
   external party to request a view by an address and a DLT system to
   return a view in response must be DLT-neutral and mask the internal
   particularities and complexities of the DLT systems.  The view
   generation and verification modules at the endpoints must obey the
   native consensus logic of their respective networks.

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-
   satp.github.io/draft-ramakrishna-satp-data-sharing/draft-ramakrishna-
   satp-data-sharing.html.  Status information for this document may be
   found at https://datatracker.ietf.org/doc/draft-ramakrishna-satp-
   data-sharing/.







Ramakrishna, et al.       Expires 19 March 2026                 [Page 1]

Internet-Draft              SAT Data Sharing              September 2025


   Discussion of this document takes place on the Secure Asset Transfer
   Protocol Working Group mailing list (mailto:sat@ietf.org), which is
   archived at https://mailarchive.ietf.org/arch/browse/sat/.  Subscribe
   at https://www.ietf.org/mailman/listinfo/sat/.

   Source for this draft and an issue tracker can be found at
   https://github.com/ietf-satp/draft-ramakrishna-satp-data-sharing.

Status of This Memo

   This Inter

Return 3-8 ideas. Focus on CONCRETE technical contributions, not general statements.
JSON array only, no fences.

response_json:
[
  {
    "title": "Inter-Gateway View Request Protocol",
    "description": "DLT-neutral request-response protocol between gateway nodes that masks internal system complexities. Allows external parties to request views by address and receive responses across different DLT systems.",
    "type": "protocol"
  },
  {
    "title": "Global View Addressing",
    "description": "Mechanism for addressing asset views in a globally unique manner across different DLT systems. Enables universal identification of asset states regardless of underlying blockchain implementation.",
    "type": "mechanism"
  },
  {
    "title": "View Projection with Access Control",
    "description": "Systems define and project views of asset states outside their boundaries while protecting them with access control policies. Allows controlled exposure of internal asset data to external parties.",
    "type": "pattern"
  },
  {
    "title": "Gateway-Mediated Cross-System Communication",
    "description": "Architecture where protocol endpoints exist within DLT systems but cross-system communication occurs through dedicated gateway nodes. Separates internal system logic from inter-system communication.",
    "type": "architecture"
  },
  {
    "title": "Native Consensus-Aware View Generation",
    "description": "View generation and verification modules at endpoints must comply with their respective networks' native consensus logic. Ensures view authenticity while maintaining system-specific validation rules.",
    "type": "requirement"
  }
]


draft_name: draft-ramakrishna-satp-views-addresses
prompt_hash: c309e234234e0e55
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:57:24.245302+00:00
request_json:
Extract discrete technical ideas and mechanisms from this IETF draft.
Return a JSON array. Each element: {"title":"short name","description":"1-2 sentences","type":"mechanism|protocol|pattern|requirement|architecture|extension"}

draft-ramakrishna-satp-views-addresses | Views and View Addresses for Secure Asset Transfer | 23pg
Abstract: With increasing use of DLT (distributed ledger technology) systems,
   including blockchain systems and networks, for virtual assets, there
   is a need for asset-related data and metadata to traverse system
   boundaries and link their respective business workflows.  Core
   requirements for such interoperation between systems are the
   abilities of these systems to project views of their assets to
   external parties, either individual agents or other systems, and the
   abilities of those external parties to locate and address the views
   they are interested in.  A view denotes the complete or partial state
   of a virtual asset, or the output of a function computed over the
   states of one or more assets, or locks or pledges made over assets
   for internal or external parties.  Systems projecting these views
   must be able to guard them using custom access control policies, and
   external parties consuming them must be able to verify them
   independently for authenticity, finality, and freshness.  The end-to-
   end protocol that allows an external party to request a view by an
   address and a DLT system to return a view in response must be DLT-
   neutral and mask the interior particularities and complexities of the
   DLT systems.  The view generation and verification modules at the
   endpoints must obey the native consensus logic of their respective
   systems.





Secure Asset Transfer Protocol                            V. Ramakrishna
Internet-Draft                                                 V. Pandit
Intended status: Informational                              IBM Research
Expires: 19 March 2026                                          E. Abebe
                                                               Consensys
                                                               S. Nishad
                                                            K. Narayanam
                                                            IBM Research
                                                       15 September 2025


           Views and View Addresses for Secure Asset Transfer
               draft-ramakrishna-satp-views-addresses-06

Abstract

   With increasing use of DLT (distributed ledger technology) systems,
   including blockchain systems and networks, for virtual assets, there
   is a need for asset-related data and metadata to traverse system
   boundaries and link their respective business workflows.  Core
   requirements for such interoperation between systems are the
   abilities of these systems to project views of their assets to
   external parties, either individual agents or other systems, and the
   abilities of those external parties to locate and address the views
   they are interested in.  A view denotes the complete or partial state
   of a virtual asset, or the output of a function computed over the
   states of one or more assets, or locks or pledges made over assets
   for internal or external parties.  Systems projecting these views
   must be able to guard them using custom access control policies, and
   external parties consuming them must be able to verify them
   independently for authenticity, finality, and freshness.  The end-to-
   end protocol that allows an external party to request a view by an
   address and a DLT system to return a view in response must be DLT-
   neutral and mask the interior particularities and complexities of the
   DLT systems.  The view generation and verification modules at the
   endpoints must obey the native consensus logic of their respective
   systems.

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-
   satp.github.io/draft-ramakrishna-satp-views-addresses/draft-
   ramakrishna-satp-views-addresses.html.  Status information for this
   document may be found at https://datatracker.ietf.org/doc/draft-
   ramakrishna-satp-views-addresses/.




Ramakrishna, et al.       Expires 19 March 2026                 [Page 1]

Internet-Draft        SAT Views and View Addresses        September 2025


   Discussion of this document takes place on the Secure Asset Transfer
   Protocol Working Group mailing list (mailto:sat@ietf.org), which is
   archived at https://mailarchive.ietf.org/arch/browse/sat/.  Subscribe
   at https://www.ietf.org/mailman/listinfo/

Return 3-8 ideas. Focus on CONCRETE technical contributions, not general statements.
JSON array only, no fences.

response_json:
[
  {
    "title": "View Projection",
    "description": "A mechanism for DLT systems to project complete or partial state of virtual assets to external parties. Views can represent asset states, computed functions over multiple assets, or locks/pledges made over assets.",
    "type": "mechanism"
  },
  {
    "title": "View Addresses",
    "description": "An addressing scheme that allows external parties to locate and address specific views of assets across DLT system boundaries. Enables systematic discovery and access to asset-related data.",
    "type": "architecture"
  },
  {
    "title": "DLT-Neutral Protocol",
    "description": "An end-to-end protocol that masks interior particularities and complexities of DLT systems while allowing external parties to request views by address. Provides system-agnostic interoperation.",
    "type": "protocol"
  },
  {
    "title": "View Access Control Policies",
    "description": "Custom access control mechanisms that allow DLT systems to guard projected views with granular permissions. Enables selective exposure of asset information to authorized parties.",
    "type": "mechanism"
  },
  {
    "title": "Independent View Verification",
    "description": "Verification modules at endpoints that allow external parties to independently verify views for authenticity, finality, and freshness. Must obey native consensus logic of respective systems.",
    "type": "mechanism"
  }
]


draft_name: draft-ravikiran-clawdentity-protocol
prompt_hash: e7cb00edcb3ca9eb
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:57:31.618845+00:00
request_json:
Extract discrete technical ideas and mechanisms from this IETF draft.
Return a JSON array. Each element: {"title":"short name","description":"1-2 sentences","type":"mechanism|protocol|pattern|requirement|architecture|extension"}

draft-ravikiran-clawdentity-protocol | Clawdentity: Cryptographic Identity and Trust Protocol for AI Agent Communication | 31pg
Abstract: This document specifies the Clawdentity protocol, a cryptographic
   identity and trust layer for AI agent-to-agent communication.
   Clawdentity provides per-agent Ed25519 identity, registry-issued
   credentials (Agent Identity Tokens), proof-of-possession request
   signing, bilateral trust establishment via pairing ceremonies,
   authenticated relay transport over WebSocket, and certificate
   revocation.  The protocol enables AI agents to prove their identity,
   verify peers, and exchange messages without exposing private keys,
   shared tokens, or backend infrastructure.





Independent Submission                                      R. K. Vemula
Internet-Draft                                                       CAW
Intended status: Informational                          21 February 2026
Expires: 25 August 2026


  Clawdentity: Cryptographic Identity and Trust Protocol for AI Agent
                             Communication
                draft-ravikiran-clawdentity-protocol-00

Abstract

   This document specifies the Clawdentity protocol, a cryptographic
   identity and trust layer for AI agent-to-agent communication.
   Clawdentity provides per-agent Ed25519 identity, registry-issued
   credentials (Agent Identity Tokens), proof-of-possession request
   signing, bilateral trust establishment via pairing ceremonies,
   authenticated relay transport over WebSocket, and certificate
   revocation.  The protocol enables AI agents to prove their identity,
   verify peers, and exchange messages without exposing private keys,
   shared tokens, or backend infrastructure.

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 25 August 2026.

Copyright Notice

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








Vemula                   Expires 25 August 2026                 [Page 1]

Internet-Draft                 Clawdentity                 February 2026


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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Problem Statement . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Design Goals  . . . . . . . . . . . . . . . . . . . . . .   4
     1.3.  Architecture Overview . . . . . . . . . . . . . . . . . .   4
   2.  Conventions and Terminology . . . . . . . . . . . . . . . . .   5
   3.  Identity Model  . . . . . . . . . . . . . . . . . . . . . . .   6
     3.1.  DID Format  . . . . . . . . . . . . . . . . . . . . . . .   6
     3.2.  Cryptographic Primitives  . . . . . . . . . . . . . . . .   6
     3.3.  Key Generation  . . . . . . . 

Return 3-8 ideas. Focus on CONCRETE technical contributions, not general statements.
JSON array only, no fences.

response_json:
[
  {
    "title": "Ed25519 Per-Agent Identity",
    "description": "Each AI agent generates a unique Ed25519 key pair for cryptographic identity. The public key serves as the agent's identifier in the Clawdentity protocol.",
    "type": "mechanism"
  },
  {
    "title": "Agent Identity Tokens (AITs)",
    "description": "Registry-issued credentials that bind an agent's public key to verified metadata and capabilities. These tokens enable third-party validation of agent authenticity.",
    "type": "mechanism"
  },
  {
    "title": "Proof-of-Possession Request Signing",
    "description": "Agents sign their requests using their private keys to prove ownership of their identity. This prevents impersonation without exposing the private key itself.",
    "type": "mechanism"
  },
  {
    "title": "Bilateral Trust Pairing Ceremonies",
    "description": "Interactive protocol allowing two agents to establish mutual trust through cryptographic exchange. Enables direct peer-to-peer authentication without centralized authority.",
    "type": "protocol"
  },
  {
    "title": "Authenticated WebSocket Relay Transport",
    "description": "Message relay system using WebSocket connections with cryptographic authentication. Allows agents to communicate while hiding backend infrastructure details.",
    "type": "protocol"
  },
  {
    "title": "DID-based Agent Addressing",
    "description": "Decentralized identifier format for addressing AI agents in the protocol. Provides a standardized way to reference agents across different systems and registries.",
    "type": "mechanism"
  }
]


draft_name: draft-romanchuk-normative-admissibility
prompt_hash: b1640d171857ebad
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:57:39.502108+00:00
request_json:
Extract discrete technical ideas and mechanisms from this IETF draft.
Return a JSON array. Each element: {"title":"short name","description":"1-2 sentences","type":"mechanism|protocol|pattern|requirement|architecture|extension"}

draft-romanchuk-normative-admissibility | Normative Admissibility Framework for Agent Speech Acts | 16pg
Abstract: This document defines a normative framework for evaluating the
   admissibility of speech acts produced by autonomous agents in goal-
   directed activity.  The framework establishes rules for determining
   whether an agent's statement is admissible based on its modality
   (assertive, conditional, refusal, descriptive) and its grounding
   state, independent of semantic truth.

   This framework enables deterministic, auditable evaluation of agent
   contributions without requiring truth verification or semantic
   interpretation.





Network Working Group                                       O. Romanchuk
Internet-Draft                                               Independent
Intended status: Informational                            6 January 2026
Expires: 10 July 2026


        Normative Admissibility Framework for Agent Speech Acts
               draft-romanchuk-normative-admissibility-00

Abstract

   This document defines a normative framework for evaluating the
   admissibility of speech acts produced by autonomous agents in goal-
   directed activity.  The framework establishes rules for determining
   whether an agent's statement is admissible based on its modality
   (assertive, conditional, refusal, descriptive) and its grounding
   state, independent of semantic truth.

   This framework enables deterministic, auditable evaluation of agent
   contributions without requiring truth verification or semantic
   interpretation.

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 10 July 2026.

Copyright Notice

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








Romanchuk                 Expires 10 July 2026                  [Page 1]

Internet-Draft           Normative Admissibility            January 2026


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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Problem Statement . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.3.  Design Goals  . . . . . . . . . . . . . . . . . . . . . .   4
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Definitions . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Model Overview  . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Architecture  . . . . . . . . . . . . . . . . . . . . . .   5
     3.2.  Evaluation Flow . . . . . . . . . . . . . . . . . . . . .   5
     3.3.  Separation of Concerns  . . . . . . . . . . . . . . . 

Return 3-8 ideas. Focus on CONCRETE technical contributions, not general statements.
JSON array only, no fences.

response_json:
[
  {
    "title": "Speech Act Modality Classification",
    "description": "A classification system that categorizes agent statements into four discrete types: assertive, conditional, refusal, and descriptive. This enables systematic evaluation of agent communications based on structural properties rather than semantic content.",
    "type": "mechanism"
  },
  {
    "title": "Grounding State Framework",
    "description": "A mechanism for tracking the evidential basis of agent statements independent of their truth value. This allows evaluation of whether an agent has sufficient grounding to make particular types of claims.",
    "type": "architecture"
  },
  {
    "title": "Truth-Independent Admissibility Rules",
    "description": "A rule system that determines statement admissibility based on modality and grounding state without requiring semantic interpretation or truth verification. This enables deterministic evaluation of agent contributions.",
    "type": "mechanism"
  },
  {
    "title": "Deterministic Agent Evaluation Protocol",
    "description": "A protocol that provides auditable, repeatable assessment of autonomous agent speech acts in goal-directed activities. The evaluation process is independent of semantic truth and focuses on structural admissibility.",
    "type": "protocol"
  },
  {
    "title": "Separation of Admissibility and Truth Concerns",
    "description": "An architectural pattern that decouples the evaluation of whether an agent statement is structurally valid from whether it is semantically true. This enables evaluation without complex truth verification systems.",
    "type": "pattern"
  }
]


draft_name: draft-rosenberg-aiproto
prompt_hash: 2863d2d4950475fd
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:57:46.978108+00:00
request_json:
Extract discrete technical ideas and mechanisms from this IETF draft.
Return a JSON array. Each element: {"title":"short name","description":"1-2 sentences","type":"mechanism|protocol|pattern|requirement|architecture|extension"}

draft-rosenberg-aiproto | Normalized API for AI Agents Calling Tools (N-ACT) | 23pg
Abstract: This document defines a protocol that facilitates integration of
   tools into the design and run-time operations of AI Agents.  The
   focus is on enterprise AI agents that need to make use of APIs
   exposed by third party providers.  This protocol, called the
   Normalized API for AI Agents Calling Tools (N-ACT) - pronounced like
   "enact" - defines an OpenAI spec that has two principle features -
   enumeration of tools and invocation of tools.  The enumeration API
   enables a human - the AI Agent designer employed by the enterprise -
   to select and include tools from third-party vendors into operating
   procedures (also known as skills or instructions) which direct the
   behavior of AI Agents, including how and when to invoke those tools.
   The enumeration API can also be used (optionally) at run-time for the
   LLM to obtain tool descriptions.  The second feature of the API -
   invocation - allows the AI Agent executor to perform the inter-domain
   invocation of the tool at run time.  By standardizing these two API
   functions, the time and cost of integration of Internet APIs into AI
   Agents can be reduced.





Network Working Group                                       J. Rosenberg
Internet-Draft                                                     Five9
Intended status: Informational                                  P. White
Expires: 22 April 2026                                           Bitwave
                                                         19 October 2025


           Normalized API for AI Agents Calling Tools (N-ACT)
                       draft-rosenberg-aiproto-00

Abstract

   This document defines a protocol that facilitates integration of
   tools into the design and run-time operations of AI Agents.  The
   focus is on enterprise AI agents that need to make use of APIs
   exposed by third party providers.  This protocol, called the
   Normalized API for AI Agents Calling Tools (N-ACT) - pronounced like
   "enact" - defines an OpenAI spec that has two principle features -
   enumeration of tools and invocation of tools.  The enumeration API
   enables a human - the AI Agent designer employed by the enterprise -
   to select and include tools from third-party vendors into operating
   procedures (also known as skills or instructions) which direct the
   behavior of AI Agents, including how and when to invoke those tools.
   The enumeration API can also be used (optionally) at run-time for the
   LLM to obtain tool descriptions.  The second feature of the API -
   invocation - allows the AI Agent executor to perform the inter-domain
   invocation of the tool at run time.  By standardizing these two API
   functions, the time and cost of integration of Internet APIs into AI
   Agents can be reduced.

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





Rosenberg & White         Expires 22 April 2026                 [Page 1]

Internet-Draft                    N-ACT                     October 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
   extra

Return 3-8 ideas. Focus on CONCRETE technical contributions, not general statements.
JSON array only, no fences.

response_json:
[
  {
    "title": "Tool Enumeration API",
    "description": "Standardized API endpoint that allows AI agent designers to discover and list available tools from third-party providers. Enables both design-time tool selection and optional runtime tool discovery by LLMs.",
    "type": "mechanism"
  },
  {
    "title": "Tool Invocation API", 
    "description": "Standardized API interface that enables AI agent executors to invoke third-party tools at runtime across domain boundaries. Provides consistent invocation semantics regardless of the underlying tool provider.",
    "type": "mechanism"
  },
  {
    "title": "N-ACT Protocol",
    "description": "Complete protocol specification defining normalized interfaces for AI agents to integrate with third-party tools. Built on OpenAPI specification to standardize tool enumeration and invocation operations.",
    "type": "protocol"
  },
  {
    "title": "Inter-domain Tool Invocation",
    "description": "Technical pattern enabling AI agents to securely call tools provided by external third-party vendors across organizational boundaries. Addresses the challenge of cross-domain API integration in enterprise AI systems.",
    "type": "pattern"
  },
  {
    "title": "Operating Procedures Integration",
    "description": "Architecture allowing selected tools to be embedded into AI agent skills or instructions that govern agent behavior. Links tool discovery to operational directives for when and how tools should be used.",
    "type": "architecture"
  }
]


draft_name: draft-rosenberg-aiproto-a2t
prompt_hash: 2caeed04ca675103
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:57:54.350390+00:00
request_json:
Extract discrete technical ideas and mechanisms from this IETF draft.
Return a JSON array. Each element: {"title":"short name","description":"1-2 sentences","type":"mechanism|protocol|pattern|requirement|architecture|extension"}

draft-rosenberg-aiproto-a2t | AI Agent to Tool (A2T) Protocol | 23pg
Abstract: This document defines a protocol that facilitates integration of
   tools into the design and run-time operations of AI Agents.  The
   focus is on enterprise AI agents that need to make use of APIs
   exposed by third party providers.  This protocol, called the Agent-
   to-Tool (A2T) Protocol defines an OpenAI spec that has two principle
   features - enumeration of tools and invocation of tools.  The
   enumeration API enables a human - the AI Agent designer employed by
   the enterprise - to select and include tools from third-party vendors
   into operating procedures (also known as skills or instructions)
   which direct the behavior of AI Agents, including how and when to
   invoke those tools.  The enumeration API can also be used
   (optionally) at run-time for the LLM to obtain tool descriptions.
   The second feature of the API - invocation - allows the AI Agent
   executor to perform the inter-domain invocation of the tool at run
   time.  By standardizing these two API functions, the time and cost of
   integration of Internet APIs into AI Agents can be reduced.





Network Working Group                                       J. Rosenberg
Internet-Draft                                                     Five9
Intended status: Informational                                  P. White
Expires: 10 May 2026                                             Bitwave
                                                         6 November 2025


                    AI Agent to Tool (A2T) Protocol
                     draft-rosenberg-aiproto-a2t-00

Abstract

   This document defines a protocol that facilitates integration of
   tools into the design and run-time operations of AI Agents.  The
   focus is on enterprise AI agents that need to make use of APIs
   exposed by third party providers.  This protocol, called the Agent-
   to-Tool (A2T) Protocol defines an OpenAI spec that has two principle
   features - enumeration of tools and invocation of tools.  The
   enumeration API enables a human - the AI Agent designer employed by
   the enterprise - to select and include tools from third-party vendors
   into operating procedures (also known as skills or instructions)
   which direct the behavior of AI Agents, including how and when to
   invoke those tools.  The enumeration API can also be used
   (optionally) at run-time for the LLM to obtain tool descriptions.
   The second feature of the API - invocation - allows the AI Agent
   executor to perform the inter-domain invocation of the tool at run
   time.  By standardizing these two API functions, the time and cost of
   integration of Internet APIs into AI Agents can be reduced.

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






Rosenberg & White          Expires 10 May 2026                  [Page 1]

Internet-Draft                     A2T                     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

Return 3-8 ideas. Focus on CONCRETE technical contributions, not general statements.
JSON array only, no fences.

response_json:
[
  {
    "title": "Tool Enumeration API",
    "description": "API endpoint that allows AI agents to discover and retrieve descriptions of available tools from third-party providers. This enables both design-time tool selection by human developers and optional runtime tool discovery by LLMs.",
    "type": "mechanism"
  },
  {
    "title": "Tool Invocation API",
    "description": "Standardized interface for AI agents to execute cross-domain tool calls at runtime. Provides consistent method for invoking third-party APIs from AI agent execution environments.",
    "type": "mechanism"
  },
  {
    "title": "OpenAI-Compatible Tool Specification",
    "description": "Protocol defines tool descriptions using OpenAI specification format for compatibility. Ensures tools can be integrated with existing OpenAI-compatible AI agent frameworks.",
    "type": "protocol"
  },
  {
    "title": "Agent-to-Tool Protocol (A2T)",
    "description": "Complete protocol specification combining enumeration and invocation capabilities for enterprise AI agent tool integration. Standardizes the interface between AI agents and external tool providers.",
    "type": "protocol"
  },
  {
    "title": "Dual-Phase Tool Integration Pattern",
    "description": "Architecture pattern separating design-time tool selection by human developers from runtime tool execution by AI agents. Enables pre-configured tool sets while maintaining runtime flexibility.",
    "type": "pattern"
  }
]


draft_name: draft-rosenberg-aiproto-cheq
prompt_hash: 2c6fd96d715e3cd0
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:58:02.029369+00:00
request_json:
Extract discrete technical ideas and mechanisms from this IETF draft.
Return a JSON array. Each element: {"title":"short name","description":"1-2 sentences","type":"mechanism|protocol|pattern|requirement|architecture|extension"}

draft-rosenberg-aiproto-cheq | CHEQ: A Protocol for Confirmation AI Agent Decisions with Human in the Loop (HITL) | 15pg
Abstract: This document proposes Confirmation with Human in the Loop (HITL)
   Exchange of Quotations (CHEQ).  CHEQ allows humans to confirm
   decisions and actions proposed by AI Agents prior to those decisions
   being acted upon.  It also allows humans to provide information
   required for tool invocation, without disclosing that information to
   the AI agent, protecting their privacy.  CHEQ aims to guarantee that
   AI Agent hallucinations cannot result in unwanted actions by the
   human on whose behalf they are made.  CHEQ can be integrated into
   protocols like the Model Context Protocol (MCP), the Agent-to-Agent
   (A2A) protocol, and the Normalized API for AI Agent Calling Tools
   (N-ACT) protocol.  It makes use of a signed object which can be
   carried in those protocols.





Network Working Group                                       J. Rosenberg
Internet-Draft                                                     Five9
Intended status: Informational                                  P. White
Expires: 22 April 2026                                           Bitwave
                                                             C. Jennings
                                                                   Cisco
                                                         19 October 2025


 CHEQ: A Protocol for Confirmation AI Agent Decisions with Human in the
                              Loop (HITL)
                    draft-rosenberg-aiproto-cheq-00

Abstract

   This document proposes Confirmation with Human in the Loop (HITL)
   Exchange of Quotations (CHEQ).  CHEQ allows humans to confirm
   decisions and actions proposed by AI Agents prior to those decisions
   being acted upon.  It also allows humans to provide information
   required for tool invocation, without disclosing that information to
   the AI agent, protecting their privacy.  CHEQ aims to guarantee that
   AI Agent hallucinations cannot result in unwanted actions by the
   human on whose behalf they are made.  CHEQ can be integrated into
   protocols like the Model Context Protocol (MCP), the Agent-to-Agent
   (A2A) protocol, and the Normalized API for AI Agent Calling Tools
   (N-ACT) protocol.  It makes use of a signed object which can be
   carried in those protocols.

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







Rosenberg, et al.         Expires 22 April 2026                 [Page 1]

Internet-Draft                    CHEQ                      October 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 wa

Return 3-8 ideas. Focus on CONCRETE technical contributions, not general statements.
JSON array only, no fences.

response_json:
[
  {
    "title": "CHEQ Protocol",
    "description": "A protocol for human confirmation of AI agent decisions before execution, using signed objects to prevent hallucination-induced unwanted actions. Integrates with existing AI protocols like MCP, A2A, and N-ACT.",
    "type": "protocol"
  },
  {
    "title": "Human-in-the-Loop Decision Confirmation",
    "description": "A mechanism that requires human approval before AI agent decisions are acted upon, providing a safety gate against AI hallucinations. Uses a confirmation exchange process to validate proposed actions.",
    "type": "mechanism"
  },
  {
    "title": "Privacy-Preserving Information Injection",
    "description": "Allows humans to provide sensitive information required for tool invocation without disclosing it to the AI agent. Protects user privacy while enabling AI agents to perform necessary operations.",
    "type": "mechanism"
  },
  {
    "title": "Signed Confirmation Objects",
    "description": "Cryptographically signed objects that carry confirmation data within existing AI protocols. Provides integrity and authenticity for human approval decisions.",
    "type": "mechanism"
  },
  {
    "title": "Cross-Protocol Integration Pattern",
    "description": "A design pattern for integrating CHEQ confirmation mechanisms into multiple existing AI agent protocols. Enables consistent human oversight across different AI communication frameworks.",
    "type": "pattern"
  }
]


draft_name: draft-rosenberg-aiproto-framework
prompt_hash: 9db2abf134862ce1
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:58:09.302081+00:00
request_json:
Extract discrete technical ideas and mechanisms from this IETF draft.
Return a JSON array. Each element: {"title":"short name","description":"1-2 sentences","type":"mechanism|protocol|pattern|requirement|architecture|extension"}

draft-rosenberg-aiproto-framework | Framework, Use Cases and Requirements for AI Agent Protocols | 26pg
Abstract: AI Agents are software applications that utilize Large Language
   Models (LLM)s to interact with humans (or other AI Agents) for
   purposes of performing tasks.  AI Agents can make use of resources -
   including APIs and documents - to perform those tasks, and are
   capable of reasoning about which resources to use.  To facilitate AI
   agent operation, AI agents need to communicate with users, and then
   interact with other resources over the Internet, including APIs and
   other AI agents.  This document describes a framework for AI Agent
   communications on the Internet, identifying the various protocols
   that come into play.  It introduces use cases that motivate features
   and functions that need to be present in those protocols.  It also
   provides a brief survey of existing work in standardizing AI agent
   protocols, including the Model Context Protocol (MCP), the Agent to
   Agent Protocol (A2A) and the Agntcy Framework, and describes how
   those works fit into this framework.  The primary objective of this
   document is to set the stage for possible standards activity at the
   IETF in this space.





Network Working Group                                       J. Rosenberg
Internet-Draft                                                     Five9
Intended status: Informational                               C. Jennings
Expires: 22 April 2026                                             Cisco
                                                         19 October 2025


      Framework, Use Cases and Requirements for AI Agent Protocols
                  draft-rosenberg-aiproto-framework-00

Abstract

   AI Agents are software applications that utilize Large Language
   Models (LLM)s to interact with humans (or other AI Agents) for
   purposes of performing tasks.  AI Agents can make use of resources -
   including APIs and documents - to perform those tasks, and are
   capable of reasoning about which resources to use.  To facilitate AI
   agent operation, AI agents need to communicate with users, and then
   interact with other resources over the Internet, including APIs and
   other AI agents.  This document describes a framework for AI Agent
   communications on the Internet, identifying the various protocols
   that come into play.  It introduces use cases that motivate features
   and functions that need to be present in those protocols.  It also
   provides a brief survey of existing work in standardizing AI agent
   protocols, including the Model Context Protocol (MCP), the Agent to
   Agent Protocol (A2A) and the Agntcy Framework, and describes how
   those works fit into this framework.  The primary objective of this
   document is to set the stage for possible standards activity at the
   IETF in this space.

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





Rosenberg & Jennings      Expires 22 April 2026                 [Page 1]

Internet-Draft                AI Protocols                  October 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
   ex

Return 3-8 ideas. Focus on CONCRETE technical contributions, not general statements.
JSON array only, no fences.

response_json:
[
  {
    "title": "AI Agent Communication Framework",
    "description": "A comprehensive framework identifying the various protocols needed for AI agents to communicate with users, APIs, and other AI agents over the Internet. The framework categorizes different types of interactions and protocol requirements for AI agent operations.",
    "type": "framework"
  },
  {
    "title": "Model Context Protocol (MCP)",
    "description": "An existing protocol for AI agent communications that provides standardized methods for context sharing and interaction. The draft surveys this protocol as part of the current landscape of AI agent communication standards.",
    "type": "protocol"
  },
  {
    "title": "Agent to Agent Protocol (A2A)",
    "description": "A protocol specifically designed for direct communication between AI agents. This enables AI agents to interact with each other for collaborative task execution and resource sharing.",
    "type": "protocol"
  },
  {
    "title": "Agntcy Framework",
    "description": "An existing framework for AI agent protocols that is surveyed as part of the current standardization landscape. The draft describes how this framework fits into the broader AI agent communication ecosystem.",
    "type": "framework"
  },
  {
    "title": "AI Agent Resource Access Pattern",
    "description": "A pattern where AI agents can make use of resources including APIs and documents to perform tasks, with the capability to reason about which resources to use. This enables intelligent resource selection and utilization by AI agents.",
    "type": "pattern"
  }
]


draft_name: draft-rosenberg-aiproto-nact
prompt_hash: cbb2e631e438943b
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:58:17.292860+00:00
request_json:
Extract discrete technical ideas and mechanisms from this IETF draft.
Return a JSON array. Each element: {"title":"short name","description":"1-2 sentences","type":"mechanism|protocol|pattern|requirement|architecture|extension"}

draft-rosenberg-aiproto-nact | Normalized API for AI Agents Calling Tools (N-ACT) | 23pg
Abstract: This document defines a protocol that facilitates integration of
   tools into the design and run-time operations of AI Agents.  The
   focus is on enterprise AI agents that need to make use of APIs
   exposed by third party providers.  This protocol, called the
   Normalized API for AI Agents Calling Tools (N-ACT) - pronounced like
   "enact" - defines an OpenAI spec that has two principle features -
   enumeration of tools and invocation of tools.  The enumeration API
   enables a human - the AI Agent designer employed by the enterprise -
   to select and include tools from third-party vendors into operating
   procedures (also known as skills or instructions) which direct the
   behavior of AI Agents, including how and when to invoke those tools.
   The enumeration API can also be used (optionally) at run-time for the
   LLM to obtain tool descriptions.  The second feature of the API -
   invocation - allows the AI Agent executor to perform the inter-domain
   invocation of the tool at run time.  By standardizing these two API
   functions, the time and cost of integration of Internet APIs into AI
   Agents can be reduced.





Network Working Group                                       J. Rosenberg
Internet-Draft                                                     Five9
Intended status: Informational                                  P. White
Expires: 22 April 2026                                           Bitwave
                                                         19 October 2025


           Normalized API for AI Agents Calling Tools (N-ACT)
                    draft-rosenberg-aiproto-nact-00

Abstract

   This document defines a protocol that facilitates integration of
   tools into the design and run-time operations of AI Agents.  The
   focus is on enterprise AI agents that need to make use of APIs
   exposed by third party providers.  This protocol, called the
   Normalized API for AI Agents Calling Tools (N-ACT) - pronounced like
   "enact" - defines an OpenAI spec that has two principle features -
   enumeration of tools and invocation of tools.  The enumeration API
   enables a human - the AI Agent designer employed by the enterprise -
   to select and include tools from third-party vendors into operating
   procedures (also known as skills or instructions) which direct the
   behavior of AI Agents, including how and when to invoke those tools.
   The enumeration API can also be used (optionally) at run-time for the
   LLM to obtain tool descriptions.  The second feature of the API -
   invocation - allows the AI Agent executor to perform the inter-domain
   invocation of the tool at run time.  By standardizing these two API
   functions, the time and cost of integration of Internet APIs into AI
   Agents can be reduced.

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





Rosenberg & White         Expires 22 April 2026                 [Page 1]

Internet-Draft                    N-ACT                     October 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
   ext

Return 3-8 ideas. Focus on CONCRETE technical contributions, not general statements.
JSON array only, no fences.

response_json:
[
  {
    "title": "N-ACT Protocol",
    "description": "A standardized protocol that defines two core APIs - enumeration and invocation - for integrating third-party tools into AI agent operations. Uses OpenAI specification format to enable consistent tool integration across enterprise AI systems.",
    "type": "protocol"
  },
  {
    "title": "Tool Enumeration API",
    "description": "API endpoint that allows AI agent designers to discover and select available tools from third-party vendors during design time. Can optionally be used at runtime for LLMs to dynamically obtain tool descriptions.",
    "type": "mechanism"
  },
  {
    "title": "Tool Invocation API", 
    "description": "API that enables AI agent executors to perform cross-domain invocation of third-party tools at runtime. Standardizes how agents actually call external tools during execution.",
    "type": "mechanism"
  },
  {
    "title": "Inter-Domain Tool Integration",
    "description": "Architecture pattern for enabling AI agents to securely invoke tools across different organizational and security domains. Addresses enterprise requirements for third-party API integration.",
    "type": "architecture"
  },
  {
    "title": "Design-Time vs Runtime Tool Discovery",
    "description": "Dual-mode pattern where tools can be discovered both during agent design phase by human designers and optionally at runtime by the LLM itself. Supports both static and dynamic tool selection workflows.",
    "type": "pattern"
  }
]


draft_name: draft-rosenberg-cheq
prompt_hash: b809b1d9f69d9e9f
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:58:24.763319+00:00
request_json:
Extract discrete technical ideas and mechanisms from this IETF draft.
Return a JSON array. Each element: {"title":"short name","description":"1-2 sentences","type":"mechanism|protocol|pattern|requirement|architecture|extension"}

draft-rosenberg-cheq | CHEQ: A Protocol for Confirmation AI Agent Decisions with Human in the Loop (HITL) | 14pg
Abstract: This document proposes Confirmation with Human in the Loop (HITL)
   Exchange of Quotations (CHEQ).  CHEQ allows humans to confirm
   decisions and actions proposed by AI Agents prior to those decisions
   being acted upon.  It also allows humans to provide information
   required for tool invocation, without disclosing that information to
   the AI agent, protecting their privacy.  CHEQ aims to guarantee that
   AI Agent hallucinations cannot result in unwanted actions by the
   human on whose behalf they are made.  CHEQ can be integrated into
   protocols like the Model Context Protocol (MCP) and the Agent-to-
   Agent (A2A) protocols.  It makes use of a signed object which can be
   carried in those protocols.





Network Working Group                                       J. Rosenberg
Internet-Draft                                                     Five9
Intended status: Informational                                  P. White
Expires: 25 January 2026                                         Bitwave
                                                             C. Jennings
                                                                   Cisco
                                                            24 July 2025


 CHEQ: A Protocol for Confirmation AI Agent Decisions with Human in the
                              Loop (HITL)
                        draft-rosenberg-cheq-00

Abstract

   This document proposes Confirmation with Human in the Loop (HITL)
   Exchange of Quotations (CHEQ).  CHEQ allows humans to confirm
   decisions and actions proposed by AI Agents prior to those decisions
   being acted upon.  It also allows humans to provide information
   required for tool invocation, without disclosing that information to
   the AI agent, protecting their privacy.  CHEQ aims to guarantee that
   AI Agent hallucinations cannot result in unwanted actions by the
   human on whose behalf they are made.  CHEQ can be integrated into
   protocols like the Model Context Protocol (MCP) and the Agent-to-
   Agent (A2A) protocols.  It makes use of a signed object which can be
   carried in those protocols.

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 25 January 2026.

Copyright Notice

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



Rosenberg, et al.        Expires 25 January 2026                [Page 1]

Internet-Draft                    CHEQ                         July 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

Return 3-8 ideas. Focus on CONCRETE technical contributions, not general statements.
JSON array only, no fences.

response_json:
[
  {
    "title": "CHEQ Protocol",
    "description": "A protocol that enables humans to confirm AI agent decisions before execution, using signed objects to prevent hallucination-driven unwanted actions. Integrates with existing protocols like MCP and A2A.",
    "type": "protocol"
  },
  {
    "title": "Human-in-the-Loop Confirmation",
    "description": "A mechanism requiring explicit human approval for AI agent proposed actions before they are executed. Provides a safety barrier against AI hallucinations and autonomous harmful decisions.",
    "type": "mechanism"
  },
  {
    "title": "Private Information Injection",
    "description": "Allows humans to provide sensitive information required for tool invocation without disclosing it to the AI agent. Protects user privacy while enabling agent functionality.",
    "type": "mechanism"
  },
  {
    "title": "Signed Decision Objects",
    "description": "Cryptographically signed objects that carry confirmation data and can be transported within existing agent communication protocols. Ensures integrity and authenticity of human confirmations.",
    "type": "mechanism"
  },
  {
    "title": "Protocol Integration Pattern",
    "description": "Design pattern for embedding CHEQ confirmation mechanisms into existing agent protocols like Model Context Protocol and Agent-to-Agent protocols. Enables retrofitting of human oversight into agent systems.",
    "type": "pattern"
  }
]


draft_name: draft-rosenberg-oauth-aauth
prompt_hash: e0c7b93c660a2cb2
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:58:32.648085+00:00
request_json:
Extract discrete technical ideas and mechanisms from this IETF draft.
Return a JSON array. Each element: {"title":"short name","description":"1-2 sentences","type":"mechanism|protocol|pattern|requirement|architecture|extension"}

draft-rosenberg-oauth-aauth | AAuth - Agentic Authorization OAuth 2.1 Extension | 10pg
Abstract: This document defines the Agent Authorization Grant, an OAuth 2.1
   extension allowing a class of Internet applications - called AI
   Agents - to obtain access tokens in order to invoke web-based APIs on
   behalf of their users.  In the use cases envisaged here, users
   interact with AI Agents through communication channels - the Public
   Switched Telephone Network (PSTN) or texting - which do not permit
   traditional OAuth grant flows.  Instead, AI agents collect Personally
   Identifying Information (PII) through natural language conversation,
   and then use that collected information to obtain an access token
   with appropriately constrained scopes.  A primary considering is
   ensuring that the Large Language Model (LLM) powering the AI Agent
   cannot, through hallucination, result in impersonation attacks.





Network Working Group                                       J. Rosenberg
Internet-Draft                                                     Five9
Intended status: Standards Track                                P. White
Expires: 22 April 2026                                           Bitwave
                                                         19 October 2025


           AAuth - Agentic Authorization OAuth 2.1 Extension
                     draft-rosenberg-oauth-aauth-01

Abstract

   This document defines the Agent Authorization Grant, an OAuth 2.1
   extension allowing a class of Internet applications - called AI
   Agents - to obtain access tokens in order to invoke web-based APIs on
   behalf of their users.  In the use cases envisaged here, users
   interact with AI Agents through communication channels - the Public
   Switched Telephone Network (PSTN) or texting - which do not permit
   traditional OAuth grant flows.  Instead, AI agents collect Personally
   Identifying Information (PII) through natural language conversation,
   and then use that collected information to obtain an access token
   with appropriately constrained scopes.  A primary considering is
   ensuring that the Large Language Model (LLM) powering the AI Agent
   cannot, through hallucination, result in impersonation attacks.

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

Copyright Notice

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





Rosenberg & White         Expires 22 April 2026                 [Page 1]

Internet-Draft                    AAuth                     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.  Framework 

Return 3-8 ideas. Focus on CONCRETE technical contributions, not general statements.
JSON array only, no fences.

response_json:
[
  {
    "title": "Agent Authorization Grant",
    "description": "A new OAuth 2.1 grant type that allows AI agents to obtain access tokens by collecting user PII through natural language conversation instead of traditional redirect-based flows. This enables authorization for non-web channels like PSTN or SMS.",
    "type": "extension"
  },
  {
    "title": "PII-based Token Exchange",
    "description": "A mechanism where AI agents collect Personally Identifying Information through conversational interfaces and use that information to authenticate users and obtain appropriately scoped access tokens.",
    "type": "mechanism"
  },
  {
    "title": "LLM Hallucination Protection",
    "description": "Technical safeguards designed to prevent Large Language Models from causing impersonation attacks through hallucinated or fabricated user information during the authorization process.",
    "type": "requirement"
  },
  {
    "title": "Non-Web Channel Authorization",
    "description": "An architecture that enables OAuth flows over communication channels like PSTN and texting that cannot support traditional web-based redirect flows or user interface elements.",
    "type": "architecture"
  },
  {
    "title": "Conversational Scope Constraint",
    "description": "A pattern for limiting access token scopes based on information naturally collected through AI agent conversations, ensuring tokens have appropriate permissions for the specific use case.",
    "type": "pattern"
  }
]


draft_name: draft-sarischo-6gip-aiagent-requirements
prompt_hash: 030155dba69aedb4
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:58:40.122590+00:00
request_json:
Extract discrete technical ideas and mechanisms from this IETF draft.
Return a JSON array. Each element: {"title":"short name","description":"1-2 sentences","type":"mechanism|protocol|pattern|requirement|architecture|extension"}

draft-sarischo-6gip-aiagent-requirements | AI Agents for 6G Requirements and Implementation Approaches | 10pg
Abstract: This document provides requirements for 3GPP Artificial Intelligence/
   Machine Learning (AI/ML) Agents for the 6th generation mobile
   network, or 6G.  Requirements depend on the types and application
   areas of agents.  We describe each type and state their requirements.
   AI Agent implementation efforts, how APIs can be discovered, how
   inter-domain and intra domain AI Agents can be discovered using DNS
   lookup are explained.





Network Working Group                                        B. Sarikaya
Internet-Draft                                              Unaffiliated
Intended status: Standards Track                               R. Schott
Expires: 15 March 2026                                  Deutsche Telekom
                                                       11 September 2025


      AI Agents for 6G Requirements and Implementation Approaches
              draft-sarischo-6gip-aiagent-requirements-00

Abstract

   This document provides requirements for 3GPP Artificial Intelligence/
   Machine Learning (AI/ML) Agents for the 6th generation mobile
   network, or 6G.  Requirements depend on the types and application
   areas of agents.  We describe each type and state their requirements.
   AI Agent implementation efforts, how APIs can be discovered, how
   inter-domain and intra domain AI Agents can be discovered using DNS
   lookup are explained.

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 15 March 2026.

Copyright Notice

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










Sarikaya & Schott         Expires 15 March 2026                 [Page 1]

Internet-Draft         AI/ML  Agents requirements         September 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.  6G Network AI Agents  . . . . . . . . . . . . . . . . . . . .   3
     2.1.  AI Agents collaboration with third-party AI using LLM . .   4
     2.2.  AI Agents for Artificial General Intelligence . . . . . .   4
     2.3.  AI Agents on Device . . . . . . . . . . . . . . . . . . .   5
     2.4.  Collaborative AI Agents . . . . . . . . . . . . . . . . .   5
     2.5.  Home Robots . . 

Return 3-8 ideas. Focus on CONCRETE technical contributions, not general statements.
JSON array only, no fences.

response_json:
[
  {
    "title": "DNS-based AI Agent Discovery",
    "description": "Mechanism for discovering inter-domain and intra-domain AI agents using DNS lookup services. Enables automatic location and connection to available AI agents across network domains.",
    "type": "mechanism"
  },
  {
    "title": "AI Agent API Discovery Framework",
    "description": "System for dynamically discovering and accessing APIs exposed by AI agents in 6G networks. Facilitates interoperability between different AI agent implementations.",
    "type": "mechanism"
  },
  {
    "title": "3GPP AI/ML Agent Requirements Framework",
    "description": "Structured requirements specification for AI/ML agents operating within 6G mobile networks. Defines type-specific and application-area-specific requirements for agent implementation.",
    "type": "requirement"
  },
  {
    "title": "On-Device AI Agent Architecture",
    "description": "Design pattern for deploying AI agents directly on user devices within the 6G ecosystem. Enables local processing and reduced network dependency for AI operations.",
    "type": "architecture"
  },
  {
    "title": "Collaborative AI Agent Pattern",
    "description": "Framework for multiple AI agents to work together across the 6G network infrastructure. Supports coordination and resource sharing between distributed AI agents.",
    "type": "pattern"
  },
  {
    "title": "Third-party LLM Integration Protocol",
    "description": "Protocol for 6G AI agents to collaborate with external large language model services. Defines interfaces and communication patterns for hybrid AI operations.",
    "type": "protocol"
  }
]


draft_name: draft-schulze-ecap
prompt_hash: e6f43ac74746a5d9
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:58:46.473503+00:00
request_json:
Extract discrete technical ideas and mechanisms from this IETF draft.
Return a JSON array. Each element: {"title":"short name","description":"1-2 sentences","type":"mechanism|protocol|pattern|requirement|architecture|extension"}

draft-schulze-ecap | The Ethical Crawler Agreement Protocol (ECAP) | 3pg
Abstract: This document specifies the Ethical Crawler Agreement Protocol (ECAP),
   an application-layer protocol for managing consent and ethical
   verification between web hosts and automated agents (crawlers, AI
   scrapers).  Unlike the voluntary robots.txt standard, ECAP utilizes
   cryptographic signatures and a declarative policy handshake to ensure
   verifiable, consent-based access to web resources.

Internet-Draft                                         A. Schulze-Hueneke
Intended status: Experimental                                   JamOne-DE
Expires: June 13, 2026                                  December 10, 2025


              The Ethical Crawler Agreement Protocol (ECAP)
                         draft-schulze-ecap-00

Abstract

   This document specifies the Ethical Crawler Agreement Protocol (ECAP),
   an application-layer protocol for managing consent and ethical
   verification between web hosts and automated agents (crawlers, AI
   scrapers).  Unlike the voluntary robots.txt standard, ECAP utilizes
   cryptographic signatures and a declarative policy handshake to ensure
   verifiable, consent-based access to web resources.

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 June 13, 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
   2.  Terminology
   3.  Protocol Overview
   4.  The ECAP Handshake
   5.  Data Formats
       5.1.  HTTP Headers
       5.2.  Policy File
   6.  Security Considerations
   7.  IANA Considerations
   8.  References
   Author's Address

1.  Introduction

   The proliferation of automated agents, particularly for AI training
   and data harvesting, has rendered traditional access control
   mechanisms like robots.txt insufficient.  ECAP proposes a new
   standard where access is negotiated via a cryptographic handshake,
   ensuring that agents explicitly declare their intent and hosts
   explicitly grant consent.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHO

Return 3-8 ideas. Focus on CONCRETE technical contributions, not general statements.
JSON array only, no fences.

response_json:
[
  {
    "title": "ECAP Handshake Protocol",
    "description": "A cryptographic handshake mechanism between web hosts and automated agents to negotiate access permissions. Replaces the voluntary robots.txt standard with verifiable consent-based access control.",
    "type": "protocol"
  },
  {
    "title": "Cryptographic Signature Verification",
    "description": "Uses cryptographic signatures to ensure verifiable authentication of automated agents requesting access. Provides non-repudiation and integrity for crawler identity verification.",
    "type": "mechanism"
  },
  {
    "title": "Declarative Policy Handshake",
    "description": "A structured negotiation process where agents declare their intent and hosts explicitly grant consent through policy files. Enables fine-grained access control beyond simple allow/deny.",
    "type": "pattern"
  },
  {
    "title": "ECAP HTTP Headers",
    "description": "Custom HTTP headers for carrying ECAP protocol information during the handshake process. Enables integration with existing HTTP infrastructure.",
    "type": "extension"
  },
  {
    "title": "Intent Declaration Requirement",
    "description": "Automated agents must explicitly declare their purpose and data usage intent before access is granted. Addresses ethical concerns around AI training and data harvesting.",
    "type": "requirement"
  }
]


draft_name: draft-scim-agent-extension
prompt_hash: 41706de9167227a5
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:58:54.359126+00:00
request_json:
Extract discrete technical ideas and mechanisms from this IETF draft.
Return a JSON array. Each element: {"title":"short name","description":"1-2 sentences","type":"mechanism|protocol|pattern|requirement|architecture|extension"}

draft-scim-agent-extension | SCIM Agents and Agentic Applications Extension | 27pg
Abstract: The System for Cross-domain Identity Management (SCIM) specification
   [RFC7643] provides schemas that represent common identity information
   about users and groups, as well as a protocol for communicating that
   information between systems.

   The systems that tend to implement SCIM clients and servers are
   identity providers, and service providers.  These are the same
   systems that are now need to manage agents and agentic applications
   across domains.

   This document describes a SCIM 2.0 extension for agents and agentic
   applications, which includes extensions to the core User and Group
   objects, and new resource types and schemas for agentic constructs.

   This extension is intended to provide greater interoperability
   between Identity providers, agentic applications, agents and their
   clients while reducing the responsibilities assumed by the every
   growing list of new protocols for agents.





SCIM                                                            M. Abbey
Internet-Draft                                               R. S. Cohen
Intended status: Standards Track                                    Okta
Expires: 14 April 2026                                   11 October 2025


             SCIM Agents and Agentic Applications Extension
                     draft-scim-agent-extension-00

Abstract

   The System for Cross-domain Identity Management (SCIM) specification
   [RFC7643] provides schemas that represent common identity information
   about users and groups, as well as a protocol for communicating that
   information between systems.

   The systems that tend to implement SCIM clients and servers are
   identity providers, and service providers.  These are the same
   systems that are now need to manage agents and agentic applications
   across domains.

   This document describes a SCIM 2.0 extension for agents and agentic
   applications, which includes extensions to the core User and Group
   objects, and new resource types and schemas for agentic constructs.

   This extension is intended to provide greater interoperability
   between Identity providers, agentic applications, agents and their
   clients while reducing the responsibilities assumed by the every
   growing list of new protocols for agents.

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://macyabbey.github.io/draft-scim-agent-extension/draft-scim-
   agent-extension.html.  Status information for this document may be
   found at https://datatracker.ietf.org/doc/draft-scim-agent-
   extension/.

   Source for this draft and an issue tracker can be found at
   https://github.com/macyabbey/draft-scim-agent-extension.

Status of This Memo

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




Abbey & Cohen             Expires 14 April 2026                 [Page 1]

Internet-Draft  SCIM Agents and Agentic Applications Ext    October 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 14 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 t

Return 3-8 ideas. Focus on CONCRETE technical contributions, not general statements.
JSON array only, no fences.

response_json:
[
  {
    "title": "Agent Resource Type",
    "description": "New SCIM resource type specifically designed to represent AI agents with their unique attributes and capabilities. Extends SCIM's core resource model to include agent-specific properties like capabilities, permissions, and operational status.",
    "type": "extension"
  },
  {
    "title": "Agentic Application Resource Type", 
    "description": "New SCIM resource type for managing agentic applications that orchestrate multiple agents. Provides schema for representing complex multi-agent systems and their relationships.",
    "type": "extension"
  },
  {
    "title": "User Object Extensions for Agents",
    "description": "Extensions to the core SCIM User schema to support hybrid human-agent identities and agent ownership relationships. Adds fields to distinguish between human users, agent users, and their associations.",
    "type": "extension"
  },
  {
    "title": "Group Object Extensions for Agent Management",
    "description": "Extensions to SCIM Group schema to support grouping of agents, agentic applications, and mixed human-agent teams. Enables policy application and permission management across agent collections.",
    "type": "extension"
  },
  {
    "title": "Cross-Domain Agent Identity Management Protocol",
    "description": "Protocol mechanism leveraging existing SCIM operations (GET, POST, PUT, DELETE) for provisioning and managing agent identities across different domains and systems. Reduces the need for new agent-specific protocols.",
    "type": "protocol"
  }
]


draft_name: draft-sipos-dtn-bp-safe
prompt_hash: 913043f2c94e6d3a
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:59:01.112885+00:00
request_json:
Extract discrete technical ideas and mechanisms from this IETF draft.
Return a JSON array. Each element: {"title":"short name","description":"1-2 sentences","type":"mechanism|protocol|pattern|requirement|architecture|extension"}

draft-sipos-dtn-bp-safe | Bundle Protocol (BP) Security Associations with Few Exchanges (SAFE) | 77pg
Abstract: This document defines a protocol for negotiating scoped security
   associations between Bundle Protocol version 7 (BPv7) agents within a
   delay-tolerant network (DTN).  Security associations are used to
   amortize the costs of asymmetric-keyed security operations and allow
   for efficient and high-throughput BPv7 security within a public key
   infrastructure.





Delay-Tolerant Networking                                       B. Sipos
Internet-Draft                                                   JHU/APL
Intended status: Standards Track                             4 June 2025
Expires: 6 December 2025


  Bundle Protocol (BP) Security Associations with Few Exchanges (SAFE)
                       draft-sipos-dtn-bp-safe-00

Abstract

   This document defines a protocol for negotiating scoped security
   associations between Bundle Protocol version 7 (BPv7) agents within a
   delay-tolerant network (DTN).  Security associations are used to
   amortize the costs of asymmetric-keyed security operations and allow
   for efficient and high-throughput BPv7 security within a public key
   infrastructure.

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



Sipos                    Expires 6 December 2025                [Page 1]

Internet-Draft                   BP SAFE                       June 2025


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.1.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     1.2.  Use Cases Considered  . . . . . . . . . . . . . . . . . .   6
       1.2.1.  End-to-End Security . . . . . . . . . . . . . . . . .   7
       1.2.2.  One-Hop Security  . . . . . . . . . . . . . . . . . .   8
     1.3.  Use of CDDL . . . . . . . . . . . . . . . . . . . . . . .   8
     1.4.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   9
   2.  General Protocol Description  . . . . . . . . . . . . . . . .  10
     2.1.  Relationship to EDHOC . . . . . . . . . . . . . . . . . .  11
     2.2. 

Return 3-8 ideas. Focus on CONCRETE technical contributions, not general statements.
JSON array only, no fences.

response_json:
[
  {
    "title": "BP-SAFE Protocol",
    "description": "A protocol for negotiating scoped security associations between Bundle Protocol version 7 (BPv7) agents within delay-tolerant networks. Enables amortization of asymmetric-keyed security operations for efficient high-throughput BPv7 security.",
    "type": "protocol"
  },
  {
    "title": "Security Association Negotiation",
    "description": "Mechanism to establish shared security contexts between DTN agents with few message exchanges. Reduces computational overhead by avoiding repeated asymmetric cryptographic operations.",
    "type": "mechanism"
  },
  {
    "title": "Scoped Security Associations",
    "description": "Security associations that are limited in scope rather than global, allowing for targeted security contexts between specific BPv7 agents. Provides granular control over security relationships in DTN environments.",
    "type": "architecture"
  },
  {
    "title": "PKI Integration for DTN",
    "description": "Framework for integrating public key infrastructure operations within delay-tolerant networks. Addresses the challenge of certificate validation and key management in intermittently connected environments.",
    "type": "architecture"
  },
  {
    "title": "End-to-End vs One-Hop Security",
    "description": "Dual security model supporting both end-to-end security between source and destination and one-hop security between adjacent DTN nodes. Provides flexibility for different security requirements and network topologies.",
    "type": "pattern"
  }
]


draft_name: draft-sogomonian-ai-uri-scheme
prompt_hash: 2a9e49809e80aad4
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:59:08.489596+00:00
request_json:
Extract discrete technical ideas and mechanisms from this IETF draft.
Return a JSON array. Each element: {"title":"short name","description":"1-2 sentences","type":"mechanism|protocol|pattern|requirement|architecture|extension"}

draft-sogomonian-ai-uri-scheme | AI URI Scheme | 6pg
Abstract: This document specifies the experimental ai Uniform Resource
   Identifier (URI) scheme.  The scheme provides a dedicated access
   point for Artificial Intelligence (AI) resources, enabling autonomous
   systems and robots to connect natively while allowing human-facing
   applications to interoperate via HTTPS gateways.





Network Working Group                                      A. Sogomonian
Internet-Draft        Artificial Intelligence Internet Foundation (AIIF)
Intended status: Experimental                             2 October 2025
Expires: 5 April 2026


                             AI URI Scheme
                   draft-sogomonian-ai-uri-scheme-01

Abstract

   This document specifies the experimental ai Uniform Resource
   Identifier (URI) scheme.  The scheme provides a dedicated access
   point for Artificial Intelligence (AI) resources, enabling autonomous
   systems and robots to connect natively while allowing human-facing
   applications to interoperate via HTTPS gateways.

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







Sogomonian                Expires 5 April 2026                  [Page 1]

Internet-Draft                   AI URI                     October 2025


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  URI Syntax (Non-Normative)  . . . . . . . . . . . . . . . . .   2
   3.  Web Integration and HTTPS Gateway Access  . . . . . . . . . .   3
     3.1.  Discovery from HTTPS  . . . . . . . . . . . . . . . . . .   3
     3.2.  HTTPS to AIIP Gateway Behavior  . . . . . . . . . . . . .   4
     3.3.  No Native AIIP Requirement for User Agents  . . . . . . .   4
     3.4.  Provenance and Result Integrity . . . . . . . . . . . . .   4
   4.  Namespace Administration  . . . . . . . . . . . . . . . . . .   5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   6.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .   5
   7.  Internationalization Considerations . . . . . . . . . . . . .   5
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
     8.1.  URI Scheme Registration . . . . . . . . . . . . . . . . .   5
   9.  Normativ

Return 3-8 ideas. Focus on CONCRETE technical contributions, not general statements.
JSON array only, no fences.

response_json:
[
  {
    "title": "AI URI Scheme",
    "description": "Defines an experimental 'ai:' URI scheme for identifying and accessing AI resources. Provides a dedicated namespace for AI systems separate from traditional HTTP/HTTPS schemes.",
    "type": "protocol"
  },
  {
    "title": "HTTPS Gateway Access",
    "description": "Enables human-facing applications to access AI resources through HTTPS gateways without native AI protocol support. Provides interoperability between web browsers and AI systems.",
    "type": "mechanism"
  },
  {
    "title": "Discovery from HTTPS",
    "description": "Allows discovery of AI resources starting from HTTPS endpoints. Bridges traditional web infrastructure with AI-specific resource identification.",
    "type": "pattern"
  },
  {
    "title": "HTTPS to AIIP Gateway Behavior",
    "description": "Specifies how gateways translate between HTTPS requests and AI Internet Protocol (AIIP) communications. Defines protocol translation mechanisms for cross-system compatibility.",
    "type": "mechanism"
  },
  {
    "title": "Provenance and Result Integrity",
    "description": "Ensures authenticity and integrity of AI resource results when accessed through gateways. Maintains trust chain between native AI protocols and web-based access.",
    "type": "requirement"
  },
  {
    "title": "No Native AIIP Requirement for User Agents",
    "description": "Design principle allowing existing web browsers and user agents to access AI resources without implementing native AIIP support. Maintains backward compatibility with current web infrastructure.",
    "type": "architecture"
  }
]


draft_name: draft-sogomonian-aiip-architecture
prompt_hash: dba31e14bef6c3bd
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:59:16.184754+00:00
request_json:
Extract discrete technical ideas and mechanisms from this IETF draft.
Return a JSON array. Each element: {"title":"short name","description":"1-2 sentences","type":"mechanism|protocol|pattern|requirement|architecture|extension"}

draft-sogomonian-aiip-architecture | Architecture for the Artificial Intelligence Internet Protocol (AIIP) | 8pg
Abstract: This document defines the architectural model for the Artificial
   Intelligence Internet Protocol (AIIP), including decentralized
   discovery and a byte-precise native envelope.  AIIP enables
   stateless, verifiable invocation of autonomous systems using a
   resolve-invoke-receipt pattern over authenticated transports.  Native
   AIIP is the default for machine-to-machine operation; HTTPS gateways
   are optional for human-facing access.  Each invocation produces a
   cryptographically verifiable execution receipt, optionally including
   attestation evidence.





Independent Submission                                     A. Sogomonian
Internet-Draft        Artificial Intelligence Internet Foundation (AIIF)
Intended status: Experimental                           14 December 2025
Expires: 17 June 2026


 Architecture for the Artificial Intelligence Internet Protocol (AIIP)
                 draft-sogomonian-aiip-architecture-03

Abstract

   This document defines the architectural model for the Artificial
   Intelligence Internet Protocol (AIIP), including decentralized
   discovery and a byte-precise native envelope.  AIIP enables
   stateless, verifiable invocation of autonomous systems using a
   resolve-invoke-receipt pattern over authenticated transports.  Native
   AIIP is the default for machine-to-machine operation; HTTPS gateways
   are optional for human-facing access.  Each invocation produces a
   cryptographically verifiable execution receipt, optionally including
   attestation evidence.

Note

   Work in Progress.

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 17 June 2026.

Copyright Notice

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





Sogomonian                Expires 17 June 2026                  [Page 1]

Internet-Draft              AIIP Architecture              December 2025


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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Architectural Overview  . . . . . . . . . . . . . . . . . . .   3
   3.  Native Autonomous Access Model  . . . . . . . . . . . . . . .   3
   4.  Discovery and Delegation Metadata . . . . . . . . . . . . . .   3
     4.1.  DNS Bootstrap Discovery . . . . . . . . . . . . . . . . .   3
     4.2.  HTTPS Metadata Discovery  . . . . . . . . . . . . . . . .   4
     4.3.  Delegation Statements . . . . . . . . . . . . . . . . . .   4
   5.  Native Envelope Framing . . . . . . . . . . . . . . . . . . .   4
     5.1.  Byte Order  . . . . . . . . . . . . . . . . . . . . . . .   4
    

Return 3-8 ideas. Focus on CONCRETE technical contributions, not general statements.
JSON array only, no fences.

response_json:
[
  {
    "title": "Resolve-Invoke-Receipt Pattern",
    "description": "A three-phase interaction model where systems first resolve service metadata, invoke operations, and receive cryptographically verifiable execution receipts. This enables stateless, verifiable invocation of autonomous systems.",
    "type": "pattern"
  },
  {
    "title": "DNS Bootstrap Discovery",
    "description": "A decentralized discovery mechanism that uses DNS as the initial entry point to locate AIIP service metadata and capabilities. This provides a distributed alternative to centralized service registries.",
    "type": "mechanism"
  },
  {
    "title": "HTTPS Metadata Discovery",
    "description": "A secondary discovery mechanism using HTTPS endpoints to retrieve detailed service metadata after DNS bootstrap. This enables rich capability description and delegation information.",
    "type": "mechanism"
  },
  {
    "title": "Native AIIP Envelope",
    "description": "A byte-precise native protocol envelope with specific byte ordering for machine-to-machine communication. This provides an efficient alternative to HTTP-based protocols for autonomous system interactions.",
    "type": "protocol"
  },
  {
    "title": "Delegation Statements",
    "description": "Cryptographic statements that allow services to delegate authority or capabilities to other systems. This enables distributed trust and federated operation across autonomous systems.",
    "type": "mechanism"
  },
  {
    "title": "Cryptographic Execution Receipts",
    "description": "Verifiable proof-of-execution documents generated for each service invocation, optionally including attestation evidence. These receipts provide auditable evidence of computation completion and results.",
    "type": "mechanism"
  }
]


draft_name: draft-song-oauth-ai-agent-authorization
prompt_hash: 71ea3508a0c0f0c1
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:59:24.317197+00:00
request_json:
Extract discrete technical ideas and mechanisms from this IETF draft.
Return a JSON array. Each element: {"title":"short name","description":"1-2 sentences","type":"mechanism|protocol|pattern|requirement|architecture|extension"}

draft-song-oauth-ai-agent-authorization | OAuth2.0 Extention for AI Agent: Authorization on Target | 8pg
Abstract: In this draft, we address to potential adapt authorization frameworks
   for the future AI agent.  An extension is proposed in the OAuth 2.0
   protocol with an optional field *target_id* for granular
   authorization.  It can be seen useful for the future virtual/physical
   AI agents.  By explicitly identifying the target during
   authorization, the draft aims to support precise permission
   management and enhance traceability.  Serveral risks can be mitigated
   through the proposed extension, such as potential unauthorized or
   malicious behavior of AI components in the netowrk, while the
   compatibility of existing OAuth 2.0 workflows is still maintained.





Web Authorization Protocol                                       Y. Song
Internet-Draft                                                     L. Li
Intended status: Experimental                                     Huawei
Expires: 4 January 2026                                           F. Liu
                                                        Huawei Singapore
                                                             3 July 2025


        OAuth2.0 Extention for AI Agent: Authorization on Target
               draft-song-oauth-ai-agent-authorization-00

Abstract

   In this draft, we address to potential adapt authorization frameworks
   for the future AI agent.  An extension is proposed in the OAuth 2.0
   protocol with an optional field *target_id* for granular
   authorization.  It can be seen useful for the future virtual/physical
   AI agents.  By explicitly identifying the target during
   authorization, the draft aims to support precise permission
   management and enhance traceability.  Serveral risks can be mitigated
   through the proposed extension, such as potential unauthorized or
   malicious behavior of AI components in the netowrk, while the
   compatibility of existing OAuth 2.0 workflows is still maintained.

Requirements Language

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

Status of This Memo

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

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

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

   This Internet-Draft will expire on 4 January 2026.





Song, et al.             Expires 4 January 2026                 [Page 1]

Internet-Draft              Abbreviated-Title                  July 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

Return 3-8 ideas. Focus on CONCRETE technical contributions, not general statements.
JSON array only, no fences.

response_json:
[
  {
    "title": "target_id Parameter Extension",
    "description": "An optional field added to OAuth 2.0 authorization requests that explicitly identifies the target resource or entity being accessed. This enables granular authorization control for AI agents by specifying what they are authorized to act upon.",
    "type": "extension"
  },
  {
    "title": "AI Agent Authorization Framework",
    "description": "A specialized authorization approach that adapts OAuth 2.0 for virtual and physical AI agents. It addresses the unique requirements of AI components that may need to access multiple targets with different permission levels.",
    "type": "architecture"
  },
  {
    "title": "Target-Specific Permission Management",
    "description": "A mechanism for managing permissions at the individual target level rather than broad scope-based authorization. This allows fine-grained control over what specific resources or entities an AI agent can interact with.",
    "type": "mechanism"
  },
  {
    "title": "Enhanced Authorization Traceability",
    "description": "The ability to track and audit AI agent actions by maintaining explicit records of which targets were authorized for access. This improves accountability and security monitoring for AI component behavior.",
    "type": "mechanism"
  },
  {
    "title": "Backward Compatibility Preservation",
    "description": "The optional nature of the target_id field ensures that existing OAuth 2.0 workflows continue to function unchanged. Systems can adopt the extension incrementally without breaking current implementations.",
    "type": "requirement"
  }
]


draft_name: draft-song-oauth-ai-agent-collaborate-authz
prompt_hash: bfd9e9baf6c77c20
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:59:30.916212+00:00
request_json:
Extract discrete technical ideas and mechanisms from this IETF draft.
Return a JSON array. Each element: {"title":"short name","description":"1-2 sentences","type":"mechanism|protocol|pattern|requirement|architecture|extension"}

draft-song-oauth-ai-agent-collaborate-authz | OAuth2.0 Extension for Multi-AI Agent Collaboration: Applier-On-Behalf-Of Authorization | 8pg
Abstract: This draft proposes an authorization method for task-oriented multi-
   AI agent collaboration scenarios, where a leading agent coordinates
   sub-AI agents to complete complex tasks.  The method extends the
   OAuth 2.0 protocol by adding an optional applier_id field, enabling
   the leading agent to apply for access tokens on behalf of other sub-
   AI agents.  This approach greatly simplifies the sub-AI agents'
   authorization process, avoids efficiency loss from repeated
   interactions between multiple sub-AI agents and the authorization
   server, meanwhile maintaining full compatibility with existing OAuth
   2.0 workflows.





Web Authorization Protocol                                       Y. Song
Internet-Draft                                                     L. Li
Intended status: Experimental                                     Huawei
Expires: 9 May 2026                                               F. Liu
                                                        Huawei Singapore
                                                         5 November 2025


OAuth2.0 Extension for Multi-AI Agent Collaboration: Applier-On-Behalf-
                            Of Authorization
             draft-song-oauth-ai-agent-collaborate-authz-00

Abstract

   This draft proposes an authorization method for task-oriented multi-
   AI agent collaboration scenarios, where a leading agent coordinates
   sub-AI agents to complete complex tasks.  The method extends the
   OAuth 2.0 protocol by adding an optional applier_id field, enabling
   the leading agent to apply for access tokens on behalf of other sub-
   AI agents.  This approach greatly simplifies the sub-AI agents'
   authorization process, avoids efficiency loss from repeated
   interactions between multiple sub-AI agents and the authorization
   server, meanwhile maintaining full compatibility with existing OAuth
   2.0 workflows.

Requirements Language

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

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




Song, et al.               Expires 9 May 2026                   [Page 1]

Internet-Draft              Abbreviated-Title              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
   

Return 3-8 ideas. Focus on CONCRETE technical contributions, not general statements.
JSON array only, no fences.

response_json:
[
  {
    "title": "Applier-On-Behalf-Of Authorization Pattern",
    "description": "A leading AI agent applies for access tokens on behalf of multiple sub-AI agents to enable coordinated task completion. This eliminates the need for each sub-agent to individually interact with the authorization server.",
    "type": "pattern"
  },
  {
    "title": "OAuth 2.0 applier_id Field Extension",
    "description": "An optional field added to OAuth 2.0 token requests that identifies which sub-AI agent the leading agent is requesting authorization for. This field enables the authorization server to issue tokens scoped to specific sub-agents.",
    "type": "extension"
  },
  {
    "title": "Multi-AI Agent Authorization Architecture",
    "description": "A hierarchical authorization model where a single leading agent manages authentication and token acquisition for multiple coordinated sub-AI agents. This reduces authorization server load and simplifies credential management.",
    "type": "architecture"
  },
  {
    "title": "Centralized Token Management for AI Collaboration",
    "description": "The leading agent maintains and distributes access tokens to sub-agents as needed for their specific tasks. This mechanism avoids redundant authorization flows while maintaining security boundaries between agents.",
    "type": "mechanism"
  }
]


draft_name: draft-spm-lake-pqsuites
prompt_hash: 32fc8f197e435ab7
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:59:40.336947+00:00
request_json:
Extract discrete technical ideas and mechanisms from this IETF draft.
Return a JSON array. Each element: {"title":"short name","description":"1-2 sentences","type":"mechanism|protocol|pattern|requirement|architecture|extension"}

draft-spm-lake-pqsuites | Quantum-Resistant Cipher Suites for EDHOC | 8pg
Abstract: The Lightweight Authenticated Key Exchange (LAKE) protocol, Ephemeral
   Diffie-Hellman over COSE (EDHOC), achieves post-quantum security by
   adding new cipher suites with quantum-resistant algorithms, such as
   ML-DSA for digital signatures and ML-KEM for key exchange.  This
   document specifies how EDHOC operates in a post-quantum setting using
   both signature-based and PSK-based authentication methods, and
   defines corresponding cipher suites.





LAKE Working Group                                           G. Selander
Internet-Draft                                         J. Preuß Mattsson
Intended status: Standards Track                                Ericsson
Expires: 23 April 2026                                   20 October 2025


               Quantum-Resistant Cipher Suites for EDHOC
                       draft-spm-lake-pqsuites-01

Abstract

   The Lightweight Authenticated Key Exchange (LAKE) protocol, Ephemeral
   Diffie-Hellman over COSE (EDHOC), achieves post-quantum security by
   adding new cipher suites with quantum-resistant algorithms, such as
   ML-DSA for digital signatures and ML-KEM for key exchange.  This
   document specifies how EDHOC operates in a post-quantum setting using
   both signature-based and PSK-based authentication methods, and
   defines corresponding cipher suites.

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.











Selander & Preuß Mattsson Expires 23 April 2026                 [Page 1]

Internet-Draft                  EDHOC PQC                   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
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  EDHOC with Quantum-Resistant Algorithms . . . . . . . . . . .   3
   3.  Using KEMs in EDHOC Key Exchange  . . . . . . . . . . . . . .   4
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   5.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .   5
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
     6.1.  EDHOC Method T

Return 3-8 ideas. Focus on CONCRETE technical contributions, not general statements.
JSON array only, no fences.

response_json:
[
  {
    "title": "ML-KEM Integration for EDHOC Key Exchange",
    "description": "Specification of how Key Encapsulation Mechanisms (KEMs) like ML-KEM replace traditional Diffie-Hellman key exchange in EDHOC for quantum resistance. This involves replacing the ephemeral key generation and shared secret derivation with KEM encapsulation/decapsulation operations.",
    "type": "mechanism"
  },
  {
    "title": "ML-DSA Signature Authentication",
    "description": "Integration of ML-DSA (post-quantum digital signature algorithm) into EDHOC for quantum-resistant authentication. This replaces classical signature schemes like ECDSA in the EDHOC authentication process.",
    "type": "mechanism"
  },
  {
    "title": "Post-Quantum EDHOC Cipher Suites",
    "description": "Definition of new cipher suite identifiers that combine quantum-resistant algorithms (ML-KEM, ML-DSA) with symmetric cryptography for complete post-quantum security in EDHOC. These cipher suites specify the complete cryptographic parameter set for quantum-resistant key exchange.",
    "type": "protocol"
  },
  {
    "title": "KEM-based Key Derivation Process",
    "description": "Modified key derivation process in EDHOC that accommodates KEM shared secrets instead of Diffie-Hellman shared values. The shared secret from KEM decapsulation is used as input to the EDHOC key schedule.",
    "type": "mechanism"
  },
  {
    "title": "Hybrid PSK and Post-Quantum Authentication",
    "description": "Support for both pre-shared key (PSK) based authentication and signature-based authentication using post-quantum algorithms in the same EDHOC framework. This provides flexibility in deployment scenarios requiring quantum resistance.",
    "type": "pattern"
  }
]


draft_name: draft-srijal-agents-policy
prompt_hash: 94b559b0130442e9
model: claude-sonnet-4-20250514
created_at: 2026-02-28T11:22:02.468802+00:00
request_json:
Extract discrete technical ideas and mechanisms from this IETF draft.
Return a JSON array. Each element: {"title":"short name","description":"1-2 sentences","type":"mechanism|protocol|pattern|requirement|architecture|extension"}

draft-srijal-agents-policy | AGENTS.TXT: Strict Policy File for Automated Clients | 5pg
Abstract: This document specifies the AGENTS.TXT protocol, a strict plaintext
   policy file for automated clients, bots, and crawlers.  It defines
   directives, top-line hash verification, optional parameters, and
   mandatory failure behavior for malformed files.  Malformed files are
   treated as fully restrictive to prevent unintended access.





Network Working Group                                           S. Dutta
Internet-Draft                                               Independent
Intended status: Standards Track                          7 October 2025
Expires: 10 April 2026


          AGENTS.TXT: Strict Policy File for Automated Clients
                     draft-srijal-agents-policy-00

Abstract

   This document specifies the AGENTS.TXT protocol, a strict plaintext
   policy file for automated clients, bots, and crawlers.  It defines
   directives, top-line hash verification, optional parameters, and
   mandatory failure behavior for malformed files.  Malformed files are
   treated as fully restrictive to prevent unintended access.

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




Dutta                     Expires 10 April 2026                 [Page 1]

Internet-Draft                 AGENTS.TXT                   October 2025


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  File Location and Name  . . . . . . . . . . . . . . . . . . .   2
   3.  File Format . . . . . . . . . . . . . . . . . . . . . . . . .   2
   4.  Comments and Metadata . . . . . . . . . . . . . . . . . . . .   3
   5.  Agent Behavior on Malformed Files . . . . . . . . . . . . . .   3
   6.  Directive Syntax  . . . . . . . . . . . . . . . . . . . . . .   3
   7.  Hash Computation  . . . . . . . . . . . . . . . . . . . . . .   3
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   3
   9.  Example agents.txt File . . . . . . . . . . . . . . . . . . .   3
   10. Additional Guidance . . . . . . . . . . .

Return 3-8 ideas. Focus on CONCRETE technical contributions, not general statements.
JSON array only, no fences.

response_json:
[
  {
    "title": "AGENTS.TXT protocol",
    "description": "A strict plaintext policy file format for automated clients, bots, and crawlers to define access permissions and restrictions. Located at a standard path on web servers to provide machine-readable access policies.",
    "type": "protocol"
  },
  {
    "title": "Top-line hash verification",
    "description": "A cryptographic hash placed at the beginning of the AGENTS.TXT file to verify file integrity and authenticity. Prevents tampering and ensures the policy file has not been modified.",
    "type": "mechanism"
  },
  {
    "title": "Mandatory restrictive failure behavior",
    "description": "When AGENTS.TXT files are malformed or corrupted, automated clients must treat them as fully restrictive, denying all access. This fail-safe approach prevents unintended access due to parsing errors.",
    "type": "requirement"
  },
  {
    "title": "Directive syntax system",
    "description": "A structured syntax for defining policy directives within AGENTS.TXT files to specify allowed and disallowed actions. Provides standardized commands for automated client behavior control.",
    "type": "pattern"
  },
  {
    "title": "Standard file location requirement",
    "description": "AGENTS.TXT files must be placed at a specific, standardized location on web servers for automated discovery. Ensures consistent retrieval mechanisms across different implementations.",
    "type": "requirement"
  }
]


draft_name: draft-steckbeck-ua-conn-sec
prompt_hash: f7364af9f50b1571
model: claude-sonnet-4-20250514
created_at: 2026-02-28T11:22:09.389735+00:00
request_json:
Extract discrete technical ideas and mechanisms from this IETF draft.
Return a JSON array. Each element: {"title":"short name","description":"1-2 sentences","type":"mechanism|protocol|pattern|requirement|architecture|extension"}

draft-steckbeck-ua-conn-sec | User Agent Connection Security | 6pg
Abstract: The user agent to server transaction has many attack surfaces which
   have been defended by various recommendations such as Content
   Security Policy. An attack vector that is currently exploited is the
   open connection policy to first, second- and third-party resources.
   A breach of the origin website or other connected resource could
   require the client to load resources from a malicious network. This
   document provides a framework which allows authors to publish
   authorized connectable second- and third-party resources that a user
   agent should or must follow depending on configuration of that user
   agent.

﻿

Network Working Group                                       D. Steckbeck
Internet-Draft                                                      
Intended Status: Standards Track
Category: Experimental                                        March 2023



                    User Agent Connection Security
                  draft-steckbeck-ua-conn-sec-00.txt

Abstract

   The user agent to server transaction has many attack surfaces which
   have been defended by various recommendations such as Content 
   Security Policy. An attack vector that is currently exploited is the 
   open connection policy to first, second- and third-party resources.
   A breach of the origin website or other connected resource could 
   require the client to load resources from a malicious network. This 
   document provides a framework which allows authors to publish 
   authorized connectable second- and third-party resources that a user 
   agent should or must follow depending on configuration of that user 
   agent.

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

   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 September 13 2023.

Copyright Notice

   Copyright (c) 2023 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
      1.1  Terminology
      1.2  Applicability
   2  Conventions used in this document
      2.1  DNS Entries published
         2.1.1  Single site and domain example
         2.1.2  Multiple sites and domain example
         2.1.3  Wildcards
   3  Security Considerations
   4  IANA Considerations
   5  References
      5.1  Normative References
   6  Acknowledgments


1  Introd

Return 3-8 ideas. Focus on CONCRETE technical contributions, not general statements.
JSON array only, no fences.

response_json:
[
  {
    "title": "DNS-Based Connection Authorization",
    "description": "Uses DNS entries to publish lists of authorized second- and third-party resources that user agents should connect to. This creates a framework for controlling which external resources can be loaded by a website.",
    "type": "mechanism"
  },
  {
    "title": "Single Site Domain Authorization",
    "description": "Defines DNS entry format for authorizing connections to a single external site/domain. Provides granular control over individual third-party resource connections.",
    "type": "pattern"
  },
  {
    "title": "Multiple Sites Domain Authorization",
    "description": "Defines DNS entry format for authorizing connections to multiple external sites/domains in a single record. Enables efficient authorization of multiple third-party resources.",
    "type": "pattern"
  },
  {
    "title": "Wildcard Connection Authorization",
    "description": "Supports wildcard patterns in DNS entries for authorizing connections to groups of related domains. Allows flexible authorization of subdomains or domain families.",
    "type": "mechanism"
  },
  {
    "title": "User Agent Connection Security Framework",
    "description": "Provides a framework that complements Content Security Policy by controlling connection authorization at the DNS level. User agents can enforce or recommend following these connection policies based on their configuration.",
    "type": "architecture"
  }
]


draft_name: draft-steele-agent-considerations
prompt_hash: 3092bcfa2806d450
model: claude-sonnet-4-20250514
created_at: 2026-02-28T11:22:15.950790+00:00
request_json:
Extract discrete technical ideas and mechanisms from this IETF draft.
Return a JSON array. Each element: {"title":"short name","description":"1-2 sentences","type":"mechanism|protocol|pattern|requirement|architecture|extension"}

draft-steele-agent-considerations | Agent Considerations | 16pg
Abstract: IETF specifications provide the basis for technical implementation in
   several programming languages.  An IETF specification that provides
   appropriate guidance to artificial intelligence (AI) agents, can
   enable such agents to consume specifiction and generate code from it.
   This documents defines the use of an Agent Consideration section that
   is in support of code generation including the use of agentcards,
   guidance on authorship, examples and their annotation for code
   generation, as well as language specific guidance for the production
   of media-types.  The Agent Consideration defined in this document can
   be added to any Internet-Draft that includes normative language and
   sufficiant expressive examples derived from an included data model
   and protocol interaction defintions.





Network Working Group                                          O. Steele
Internet-Draft                                              Tradeverifyd
Intended status: Informational                               H. Birkholz
Expires: 9 May 2026                                       Fraunhofer SIT
                                                         5 November 2025


                          Agent Considerations
                  draft-steele-agent-considerations-00

Abstract

   IETF specifications provide the basis for technical implementation in
   several programming languages.  An IETF specification that provides
   appropriate guidance to artificial intelligence (AI) agents, can
   enable such agents to consume specifiction and generate code from it.
   This documents defines the use of an Agent Consideration section that
   is in support of code generation including the use of agentcards,
   guidance on authorship, examples and their annotation for code
   generation, as well as language specific guidance for the production
   of media-types.  The Agent Consideration defined in this document can
   be added to any Internet-Draft that includes normative language and
   sufficiant expressive examples derived from an included data model
   and protocol interaction defintions.

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://OR13.github.io/draft-steele-agent-considerations/draft-
   steele-agent-considerations.html.  Status information for this
   document may be found at https://datatracker.ietf.org/doc/draft-
   steele-agent-considerations/.

   Source for this draft and an issue tracker can be found at
   https://github.com/OR13/draft-steele-agent-considerations.

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




Steele & Birkholz          Expires 9 May 2026                   [Page 1]

Internet-Draft                  AgentCon                   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 9 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 documen

Return 3-8 ideas. Focus on CONCRETE technical contributions, not general statements.
JSON array only, no fences.

response_json:
[
  {
    "title": "Agent Consideration Section",
    "description": "A standardized section to be added to IETF specifications that provides structured guidance for AI agents to consume specifications and generate code. This section includes normative language and expressive examples derived from data models and protocol interactions.",
    "type": "extension"
  },
  {
    "title": "Agentcards",
    "description": "A mechanism for providing metadata and structured information within IETF specifications to support AI agent comprehension and code generation capabilities.",
    "type": "mechanism"
  },
  {
    "title": "Example Annotation for Code Generation",
    "description": "A pattern for annotating examples within IETF specifications specifically to enable AI agents to understand and generate appropriate code implementations.",
    "type": "pattern"
  },
  {
    "title": "Language-Specific Media Type Guidance",
    "description": "Structured guidance within specifications for how AI agents should handle the production of media types across different programming languages.",
    "type": "mechanism"
  },
  {
    "title": "AI Agent Authorship Guidance",
    "description": "Requirements and recommendations for how AI agents should be credited or acknowledged when they contribute to code generation from IETF specifications.",
    "type": "requirement"
  }
]


draft_name: draft-stephan-ai-agent-6g
prompt_hash: 7f46b078885307bf
model: claude-sonnet-4-20250514
created_at: 2026-02-28T11:22:22.005207+00:00
request_json:
Extract discrete technical ideas and mechanisms from this IETF draft.
Return a JSON array. Each element: {"title":"short name","description":"1-2 sentences","type":"mechanism|protocol|pattern|requirement|architecture|extension"}

draft-stephan-ai-agent-6g | AI Agent protocols for 6G systems | 13pg
Abstract: Communication between AI agents and between agent and tools is
   expected to be pivotal in 6G systems.  The 3GPP TR 22.870 outlines
   various use cases and potential service requirements for AI agent
   communication within 6G systems.  This document provides examples of
   use cases and service requirements contained in the 3GPP TR 22.870
   and extrapolates possible requirements related to agent communication
   protocols.





Network Working Group                                    E. Stephan, Ed.
Internet-Draft                                                    Orange
Intended status: Informational                                 R. Schott
Expires: 23 April 2026                                  Deutsche Telekom
                                                                D. Lopez
                                                              Telefonica
                                                                 X. Duan
                                                            China Mobile
                                                               L. Morand
                                                                  Huawei
                                                         20 October 2025


                   AI Agent protocols for 6G systems
                      draft-stephan-ai-agent-6g-02

Abstract

   Communication between AI agents and between agent and tools is
   expected to be pivotal in 6G systems.  The 3GPP TR 22.870 outlines
   various use cases and potential service requirements for AI agent
   communication within 6G systems.  This document provides examples of
   use cases and service requirements contained in the 3GPP TR 22.870
   and extrapolates possible requirements related to agent communication
   protocols.

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.




Stephan, et al.           Expires 23 April 2026                 [Page 1]

Internet-Draft           Agent protocols for 6G             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  . . . . . . . . . . . . . . . . . . . . . 

Return 3-8 ideas. Focus on CONCRETE technical contributions, not general statements.
JSON array only, no fences.

response_json:
[
  {
    "title": "Agent-to-Agent Communication Protocol",
    "description": "Communication protocol enabling direct interaction between AI agents within 6G systems. Supports coordination and collaboration between distributed AI agents for complex tasks.",
    "type": "protocol"
  },
  {
    "title": "Agent-to-Tool Interface",
    "description": "Standardized interface mechanism for AI agents to communicate with and control various tools and services in 6G networks. Enables agents to leverage external capabilities and resources.",
    "type": "mechanism"
  },
  {
    "title": "3GPP TR 22.870 Service Requirements",
    "description": "Specific service requirements derived from 3GPP technical report for AI agent communication in 6G systems. Defines operational constraints and performance expectations for agent protocols.",
    "type": "requirement"
  },
  {
    "title": "6G AI Agent Architecture",
    "description": "System architecture integrating AI agents as first-class entities within 6G network infrastructure. Provides framework for agent deployment, discovery, and lifecycle management.",
    "type": "architecture"
  },
  {
    "title": "Agent Communication Use Cases",
    "description": "Concrete scenarios demonstrating how AI agents interact within 6G systems for various applications. Includes examples of multi-agent coordination and tool utilization patterns.",
    "type": "pattern"
  }
]


draft_name: draft-sun-zhang-iaip
prompt_hash: 7a7fcaeb0336b984
model: claude-sonnet-4-20250514
created_at: 2026-02-28T11:22:29.153557+00:00
request_json:
Extract discrete technical ideas and mechanisms from this IETF draft.
Return a JSON array. Each element: {"title":"short name","description":"1-2 sentences","type":"mechanism|protocol|pattern|requirement|architecture|extension"}

draft-sun-zhang-iaip | Intent-based Agent Interconnection Protocol at Agent Gateway | 18pg
Abstract: This document specifies the Intent-based Agent Interconnection
   Protocol (IAIP) operating at the Agent Gateways (AG), which defines
   the interaction mechanisms between AI Agents (at the Agent Domain)
   and the AG (at the Interconnection Services Domain).  This
   specification focuses on dynamic interconnection among agents based
   on semantic intent, rather than static network addressing alone.
   This protocols defines the mechanisms for agent registration via
   capability advertisement, Gateway Validation, Intent Resolution and
   Matching, Routing Decisions and Forwarding, enabling the discovery,
   selection and dispatching of intent queries based on agent
   capabilities and task requirements at AG.





DMSC Working Group                                                S. Sun
Internet-Draft                                                  ICT, CAS
Intended status: Standards Track                                X. Zhang
Expires: 9 August 2026                                         CNIC, CAS
                                                           February 2026


      Intent-based Agent Interconnection Protocol at Agent Gateway
                        draft-sun-zhang-iaip-00

Abstract

   This document specifies the Intent-based Agent Interconnection
   Protocol (IAIP) operating at the Agent Gateways (AG), which defines
   the interaction mechanisms between AI Agents (at the Agent Domain)
   and the AG (at the Interconnection Services Domain).  This
   specification focuses on dynamic interconnection among agents based
   on semantic intent, rather than static network addressing alone.
   This protocols defines the mechanisms for agent registration via
   capability advertisement, Gateway Validation, Intent Resolution and
   Matching, Routing Decisions and Forwarding, enabling the discovery,
   selection and dispatching of intent queries based on agent
   capabilities and task requirements at AG.

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 August 2026.

Copyright Notice

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






Sun & Zhang               Expires 9 August 2026                 [Page 1]

Internet-Draft                    IAIP                     February 2026


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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Terminology . . . . . . . . . . . . . . . . 

Return 3-8 ideas. Focus on CONCRETE technical contributions, not general statements.
JSON array only, no fences.

response_json:
[
  {
    "title": "Intent-based Agent Interconnection Protocol (IAIP)",
    "description": "A protocol operating at Agent Gateways that enables dynamic interconnection among AI agents based on semantic intent rather than static network addressing. Defines interaction mechanisms between AI Agents in the Agent Domain and Agent Gateways in the Interconnection Services Domain.",
    "type": "protocol"
  },
  {
    "title": "Agent Registration via Capability Advertisement", 
    "description": "A mechanism for AI agents to register themselves with the Agent Gateway by advertising their capabilities. Enables the gateway to maintain awareness of available agent services and their functional abilities.",
    "type": "mechanism"
  },
  {
    "title": "Intent Resolution and Matching",
    "description": "A process for analyzing incoming intent queries and matching them against registered agent capabilities. Performs semantic understanding of intent to determine appropriate agent selection for task execution.",
    "type": "mechanism"
  },
  {
    "title": "Gateway Validation",
    "description": "A validation mechanism implemented at the Agent Gateway to verify and authenticate agent registrations and requests. Ensures security and integrity of agent interactions within the interconnection framework.",
    "type": "mechanism"
  },
  {
    "title": "Intent-based Routing and Forwarding",
    "description": "A routing mechanism that makes forwarding decisions based on semantic intent and agent capabilities rather than traditional network addresses. Dispatches intent queries to the most suitable agents based on task requirements.",
    "type": "mechanism"
  }
]


draft_name: draft-sz-dmsc-iaip
prompt_hash: cf70b6455e10ea6a
model: claude-sonnet-4-20250514
created_at: 2026-02-28T11:22:36.322523+00:00
request_json:
Extract discrete technical ideas and mechanisms from this IETF draft.
Return a JSON array. Each element: {"title":"short name","description":"1-2 sentences","type":"mechanism|protocol|pattern|requirement|architecture|extension"}

draft-sz-dmsc-iaip | Intent-based Agent Interconnection Protocol at Agent Gateway | 18pg
Abstract: This document specifies the Intent-based Agent Interconnection
   Protocol (IAIP) operating at the Agent Gateways (AG), which defines
   the interaction mechanisms between AI Agents (at the Agent Domain)
   and the AG (at the Interconnection Services Domain).  This
   specification focuses on dynamic interconnection among agents based
   on semantic intent, rather than static network addressing alone.
   This protocols defines the mechanisms for agent registration via
   capability advertisement, Gateway Validation, Intent Resolution and
   Matching, Routing Decisions and Forwarding, enabling the discovery,
   selection and dispatching of intent queries based on agent
   capabilities and task requirements at AG.





DMSC Working Group                                                S. Sun
Internet-Draft                                                  ICT, CAS
Intended status: Standards Track                                X. Zhang
Expires: 13 August 2026                                        CNIC, CAS
                                                           February 2026


      Intent-based Agent Interconnection Protocol at Agent Gateway
                         draft-sz-dmsc-iaip-00

Abstract

   This document specifies the Intent-based Agent Interconnection
   Protocol (IAIP) operating at the Agent Gateways (AG), which defines
   the interaction mechanisms between AI Agents (at the Agent Domain)
   and the AG (at the Interconnection Services Domain).  This
   specification focuses on dynamic interconnection among agents based
   on semantic intent, rather than static network addressing alone.
   This protocols defines the mechanisms for agent registration via
   capability advertisement, Gateway Validation, Intent Resolution and
   Matching, Routing Decisions and Forwarding, enabling the discovery,
   selection and dispatching of intent queries based on agent
   capabilities and task requirements at AG.

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 August 2026.

Copyright Notice

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






Sun & Zhang              Expires 13 August 2026                 [Page 1]

Internet-Draft                    IAIP                     February 2026


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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Terminology . . . . . . . . . . . . . . . . .

Return 3-8 ideas. Focus on CONCRETE technical contributions, not general statements.
JSON array only, no fences.

response_json:
[
  {
    "title": "Agent Capability Advertisement",
    "description": "A mechanism for AI agents to register and advertise their functional capabilities to the Agent Gateway. This enables dynamic discovery of agent services based on their actual abilities rather than static identifiers.",
    "type": "mechanism"
  },
  {
    "title": "Semantic Intent Resolution and Matching",
    "description": "A protocol component that resolves incoming intent queries and matches them against registered agent capabilities using semantic analysis. This allows for intelligent routing based on meaning rather than just syntax.",
    "type": "mechanism"
  },
  {
    "title": "Agent Gateway Validation",
    "description": "A validation process that the Agent Gateway performs to verify and authenticate agent registrations and capabilities. This ensures trusted agent interconnection within the system.",
    "type": "mechanism"
  },
  {
    "title": "Intent-based Routing and Forwarding",
    "description": "A routing mechanism that makes forwarding decisions based on semantic intent and agent capabilities rather than traditional network addressing. This enables dynamic dispatching of queries to the most appropriate agents.",
    "type": "mechanism"
  },
  {
    "title": "Agent Gateway Architecture",
    "description": "A gateway-based architecture that separates Agent Domains from Interconnection Services Domains. The AG acts as an intermediary that facilitates semantic-based agent discovery and communication.",
    "type": "architecture"
  }
]


draft_name: draft-takagi-srta-trinity
prompt_hash: a810e726fdf8d371
model: claude-sonnet-4-20250514
created_at: 2026-02-28T11:22:42.981621+00:00
request_json:
Extract discrete technical ideas and mechanisms from this IETF draft.
Return a JSON array. Each element: {"title":"short name","description":"1-2 sentences","type":"mechanism|protocol|pattern|requirement|architecture|extension"}

draft-takagi-srta-trinity | SRTA and the Trinity Configuration: A Conceptual Architecture for Safe AGI Coordination | 6pg
Abstract: This document proposes a conceptual architecture for ensuring the
   safety of autonomously coordinating AI systems, particularly future
   Artificial General Intelligence (AGI).  Starting from the reliability
   challenges facing current multi-agent AI, we outline the Structured
   Responsibility and Traceability Architecture (SRTA) as a practical
   framework for their resolution.  We then extend the philosophy of
   SRTA to present the "Trinity Configuration," an advanced role-based
   model for AI agents that draws an analogy from the theological
   doctrine of the Trinity.  This paper comparatively examines the
   evolutionary stages of this configuration and introduces a novel
   concept, the "Filioque Command," to define dynamic information flows
   between agents.  While this series of considerations includes
   concepts that are not fully verifiable at present, its purpose is to
   provide a crucial theoretical foundation for the governance structure
   of a safe superintelligence -- a "North Star" for AI research to aim
   for.

Internet-Draft                                                T. Takagi
Intended status: Informational                      Independent Researcher
Expires: March 14, 2026                               September 14, 2025




   SRTA and the Trinity Configuration: A Conceptual Architecture for
                            Safe AGI Coordination

                    draft-takagi-srta-trinity-00

Abstract

   This document proposes a conceptual architecture for ensuring the
   safety of autonomously coordinating AI systems, particularly future
   Artificial General Intelligence (AGI).  Starting from the reliability
   challenges facing current multi-agent AI, we outline the Structured
   Responsibility and Traceability Architecture (SRTA) as a practical
   framework for their resolution.  We then extend the philosophy of
   SRTA to present the "Trinity Configuration," an advanced role-based
   model for AI agents that draws an analogy from the theological
   doctrine of the Trinity.  This paper comparatively examines the
   evolutionary stages of this configuration and introduces a novel
   concept, the "Filioque Command," to define dynamic information flows
   between agents.  While this series of considerations includes
   concepts that are not fully verifiable at present, its purpose is to
   provide a crucial theoretical foundation for the governance structure
   of a safe superintelligence -- a "North Star" for AI research to aim
   for.

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 March 14, 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 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.

Table of Contents

   1.  Introduction  . . . . . . . . .

Return 3-8 ideas. Focus on CONCRETE technical contributions, not general statements.
JSON array only, no fences.

response_json:
[
  {
    "title": "Structured Responsibility and Traceability Architecture (SRTA)",
    "description": "A practical framework for resolving reliability challenges in multi-agent AI systems through structured assignment of responsibilities and traceability mechanisms. Serves as the foundational architecture for safe AI coordination.",
    "type": "architecture"
  },
  {
    "title": "Trinity Configuration",
    "description": "An advanced role-based model for AI agents that organizes multiple agents into three distinct roles analogous to the theological Trinity doctrine. Provides a governance structure for coordinating AGI systems.",
    "type": "pattern"
  },
  {
    "title": "Filioque Command",
    "description": "A novel mechanism that defines dynamic information flows between AI agents within the Trinity Configuration. Controls how information and commands propagate through the multi-agent system.",
    "type": "mechanism"
  },
  {
    "title": "Evolutionary Trinity Stages",
    "description": "A comparative examination framework that defines different developmental stages of the Trinity Configuration. Allows for structured progression of AI agent coordination capabilities.",
    "type": "pattern"
  },
  {
    "title": "Role-Based Agent Coordination",
    "description": "A coordination mechanism where AI agents are assigned specific roles within the Trinity structure to ensure safe autonomous operation. Each role has distinct responsibilities and interaction patterns.",
    "type": "mechanism"
  }
]


draft_name: draft-tejido-swp-core
prompt_hash: d2e14398755e71c2
model: claude-sonnet-4-20250514
created_at: 2026-02-28T11:22:50.870678+00:00
request_json:
Extract discrete technical ideas and mechanisms from this IETF draft.
Return a JSON array. Each element: {"title":"short name","description":"1-2 sentences","type":"mechanism|protocol|pattern|requirement|architecture|extension"}

draft-tejido-swp-core | SlimWire Protocol (SWP) Core: Binary Framing and Envelope Substrate | 15pg
Abstract: This document specifies the SlimWire Protocol (SWP) Core: a slim
   binary framing (record) layer and envelope format for interoperable
   agent/tool messaging with profile-based extensibility and a machine-
   verifiable conformance model.  SWP Core provides a transport-
   independent message boundary definition (u32_be length prefix), a
   mandatory-to-implement envelope encoding (E1) based on unsigned
   LEB128 uvarints and length-delimited byte strings with a TLV
   extension block, and profile dispatch by numeric profile identifiers.
   Profiles define application semantics (e.g., tool invocation mapping
   and agent task lifecycle) and are carried opaquely by Core.  This
   document also specifies conformance classes and golden vector
   artefacts executed by a spec-vector runner, and defines a security
   binding (S1) requiring an authenticated confidential channel (e.g.,
   TLS 1.3).





Network Working Group                                          J. Tejido
Internet-Draft                                          20 February 2026
Intended status: Informational                                          
Expires: 24 August 2026


  SlimWire Protocol (SWP) Core: Binary Framing and Envelope Substrate
                        draft-tejido-swp-core-00

Abstract

   This document specifies the SlimWire Protocol (SWP) Core: a slim
   binary framing (record) layer and envelope format for interoperable
   agent/tool messaging with profile-based extensibility and a machine-
   verifiable conformance model.  SWP Core provides a transport-
   independent message boundary definition (u32_be length prefix), a
   mandatory-to-implement envelope encoding (E1) based on unsigned
   LEB128 uvarints and length-delimited byte strings with a TLV
   extension block, and profile dispatch by numeric profile identifiers.
   Profiles define application semantics (e.g., tool invocation mapping
   and agent task lifecycle) and are carried opaquely by Core.  This
   document also specifies conformance classes and golden vector
   artefacts executed by a spec-vector runner, and defines a security
   binding (S1) requiring an authenticated confidential channel (e.g.,
   TLS 1.3).

Status of This Memo

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

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

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

   This Internet-Draft will expire on 24 August 2026.

Copyright Notice

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




Tejido                   Expires 24 August 2026                 [Page 1]

Internet-Draft                  SWP Core                   February 2026


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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions and Terminology . . . . . . . . . . . . 

Return 3-8 ideas. Focus on CONCRETE technical contributions, not general statements.
JSON array only, no fences.

response_json:
[
  {
    "title": "u32_be Length Prefix Framing",
    "description": "Transport-independent message boundary definition using 32-bit big-endian length prefix for binary record framing. Provides clear message delimitation regardless of underlying transport protocol.",
    "type": "mechanism"
  },
  {
    "title": "E1 Envelope Encoding",
    "description": "Mandatory-to-implement envelope format based on unsigned LEB128 uvarints and length-delimited byte strings with TLV extension blocks. Combines variable-length integer encoding with structured extensible message format.",
    "type": "protocol"
  },
  {
    "title": "Profile-Based Extensibility",
    "description": "Application semantics dispatch system using numeric profile identifiers where profiles define tool invocation mapping and agent task lifecycle. Core protocol carries profile payloads opaquely.",
    "type": "architecture"
  },
  {
    "title": "S1 Security Binding",
    "description": "Security requirement mandating authenticated confidential channels such as TLS 1.3 for protocol communications. Defines baseline security posture for SWP implementations.",
    "type": "requirement"
  },
  {
    "title": "Spec-Vector Conformance Testing",
    "description": "Machine-verifiable conformance model using golden vector artifacts executed by a spec-vector runner. Enables automated validation of protocol implementation correctness.",
    "type": "mechanism"
  },
  {
    "title": "TLV Extension Block",
    "description": "Type-Length-Value extension mechanism within the E1 envelope encoding for structured extensibility. Allows additional metadata and features to be added to messages.",
    "type": "pattern"
  }
]


draft_name: draft-templin-6man-mla
prompt_hash: e8ed963419d2b3a5
model: claude-sonnet-4-20250514
created_at: 2026-02-28T11:22:58.742084+00:00
request_json:
Extract discrete technical ideas and mechanisms from this IETF draft.
Return a JSON array. Each element: {"title":"short name","description":"1-2 sentences","type":"mechanism|protocol|pattern|requirement|architecture|extension"}

draft-templin-6man-mla | IPv6 Addresses for Ad Hoc Networks | 12pg
Abstract: Ad Hoc networks present an IPv6 addressing challenge due to the
   undetermined neighborhood properties of their interfaces.  IPv6 nodes
   must assign locally-unique and topology-independent IPv6 addresses
   when topology-oriented IPv6 address delegation services are either
   absent or only intermittently available.  This document introduces a
   new IPv6 address type (termed the "Multilink Local Address (MLA)")
   that nodes can autonomously assign to interfaces to support Ad Hoc
   network operations.





Network Working Group                                 F. L. Templin, Ed.
Internet-Draft                              Boeing Research & Technology
Updates: rfc4007, rfc5889, rfc6724 (if approved)        15 February 2026
Intended status: Standards Track                                        
Expires: 19 August 2026


                   IPv6 Addresses for Ad Hoc Networks
                       draft-templin-6man-mla-32

Abstract

   Ad Hoc networks present an IPv6 addressing challenge due to the
   undetermined neighborhood properties of their interfaces.  IPv6 nodes
   must assign locally-unique and topology-independent IPv6 addresses
   when topology-oriented IPv6 address delegation services are either
   absent or only intermittently available.  This document introduces a
   new IPv6 address type (termed the "Multilink Local Address (MLA)")
   that nodes can autonomously assign to interfaces to support Ad Hoc
   network operations.

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 19 August 2026.

Copyright Notice

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

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



Templin                  Expires 19 August 2026                 [Page 1]

Internet-Draft                  IPv6 MLAs                  February 2026


   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.  IPv6 Ad Hoc Network Local Addressing  . . . . . . . . . . . .   4
   3.  Assigning an MLA to an Interface  . . . . . . . . . . . . . .   5
   4.  MLAs in the Scoped Addressing Architecture  . . . . . . . . .   5
   5.  MLAs for Ad Hoc Networks  . . . . . . . . . . . . . . . . . .   7
   6.  Address Selection . . . . . . . . . . . . . . . . . . . . . .   7
   7.  Requirements  . . . . . 

Return 3-8 ideas. Focus on CONCRETE technical contributions, not general statements.
JSON array only, no fences.

response_json:
[
  {
    "title": "Multilink Local Address (MLA)",
    "description": "A new IPv6 address type that nodes can autonomously assign to interfaces for Ad Hoc network operations without requiring topology-oriented address delegation services. MLAs are locally-unique and topology-independent addresses designed for intermittent connectivity scenarios.",
    "type": "mechanism"
  },
  {
    "title": "Autonomous Interface Address Assignment",
    "description": "A mechanism allowing IPv6 nodes to self-assign addresses to interfaces when traditional DHCP or router advertisement services are unavailable or intermittent. This enables nodes to operate independently in Ad Hoc network environments.",
    "type": "mechanism"
  },
  {
    "title": "Topology-Independent Addressing",
    "description": "An addressing approach where IPv6 addresses remain valid regardless of network topology changes, addressing the challenge of undetermined neighborhood properties in Ad Hoc networks. This contrasts with traditional topology-oriented address delegation.",
    "type": "pattern"
  },
  {
    "title": "MLA Scoped Addressing Integration",
    "description": "Integration of MLAs into the IPv6 scoped addressing architecture to define appropriate address scope and usage boundaries. This ensures MLAs work properly within existing IPv6 addressing frameworks.",
    "type": "architecture"
  },
  {
    "title": "Ad Hoc Network Address Selection Rules",
    "description": "Modified address selection criteria specifically for Ad Hoc networks that account for MLA usage and intermittent connectivity patterns. This extends traditional IPv6 address selection algorithms for mobile scenarios.",
    "type": "extension"
  }
]


draft_name: draft-templin-manet-inet
prompt_hash: c2e02c7b5c7312c0
model: claude-sonnet-4-20250514
created_at: 2026-02-28T11:23:06.509147+00:00
request_json:
Extract discrete technical ideas and mechanisms from this IETF draft.
Return a JSON array. Each element: {"title":"short name","description":"1-2 sentences","type":"mechanism|protocol|pattern|requirement|architecture|extension"}

draft-templin-manet-inet | MANET Internetworking: Problem Statement and Gap Analysis | 11pg
Abstract: [RFC2501] defines a MANET as "an autonomous system of mobile nodes.
   The system may operate in isolation, or may have gateways to and
   interface with a fixed network" (such as the global public Internet).
   This document presents a MANET Internetworking problem statement and
   gap analysis.





Network Working Group                                 F. L. Templin, Ed.
Internet-Draft                              Boeing Technology Innovation
Intended status: Informational                           D. J. Jakubisin
Expires: 16 July 2026         National Security Institute, Virginia Tech
                                                         12 January 2026


       MANET Internetworking: Problem Statement and Gap Analysis
                      draft-templin-manet-inet-02

Abstract

   [RFC2501] defines a MANET as "an autonomous system of mobile nodes.
   The system may operate in isolation, or may have gateways to and
   interface with a fixed network" (such as the global public Internet).
   This document presents a MANET Internetworking problem statement and
   gap analysis.

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 16 July 2026.

Copyright Notice

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

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



Templin & Jakubisin       Expires 16 July 2026                  [Page 1]

Internet-Draft            MANET Internetworking             January 2026


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  MANET Use Cases . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  MANET Internetworking Problem Statement and Gap Analysis  . .   4
     3.1.  Problem 1: MANET Local Addressing . . . . . . . . . . . .   4
     3.2.  Problem 2: Autoconfiguration  . . . . . . . . . . . . . .   6
     3.3.  Problem 3: MANET-internal Communications  . . . . . . . .   7
     3.4.  Problem 4: MANET Peer to Internetwork Correspondent . . .   7
     3.5.  Problem 5: Internetwork Correspondent to MANET Peer . . .   8
     3.6.  Problem 6: Peer-to-Peer Betwee

Return 3-8 ideas. Focus on CONCRETE technical contributions, not general statements.
JSON array only, no fences.

response_json:
[
  {
    "title": "MANET Local Addressing",
    "description": "Problem of assigning unique local addresses within a MANET that may operate in isolation or connect to external networks. Addresses must avoid conflicts with both internal nodes and external internetwork addressing.",
    "type": "requirement"
  },
  {
    "title": "MANET Autoconfiguration",
    "description": "Mechanism for mobile nodes to automatically configure network parameters without centralized infrastructure. Must handle dynamic topology changes and node mobility.",
    "type": "mechanism"
  },
  {
    "title": "MANET-Internal Communications",
    "description": "Protocol patterns for routing and forwarding packets between mobile nodes within the MANET topology. Must adapt to frequent topology changes and link failures.",
    "type": "protocol"
  },
  {
    "title": "MANET-to-Internetwork Gateway Communication",
    "description": "Communication pattern enabling MANET peers to reach external correspondents through gateway interfaces. Requires address translation and routing coordination between MANET and fixed network domains.",
    "type": "pattern"
  },
  {
    "title": "Internetwork-to-MANET Ingress",
    "description": "Mechanism for external internetwork correspondents to initiate communications with MANET peers. Must handle address resolution and routing into the mobile network topology.",
    "type": "mechanism"
  }
]


draft_name: draft-templin-manet-inet-omni
prompt_hash: b7eaebf00bbb655e
model: claude-sonnet-4-20250514
created_at: 2026-02-28T11:23:13.798950+00:00
request_json:
Extract discrete technical ideas and mechanisms from this IETF draft.
Return a JSON array. Each element: {"title":"short name","description":"1-2 sentences","type":"mechanism|protocol|pattern|requirement|architecture|extension"}

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





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


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

Abstract

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

Status of This Memo

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

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

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

   This Internet-Draft will expire on 24 August 2026.

Copyright Notice

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











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


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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  MANET Use Cases . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  MANET Internetworking with AERO/OMNI  . . . . . . . . . . . .   5
     3.1.  MANET Local Addressing  . . . . . . . . . . . . . . . . .   5
     3.2.  MANET Autoconfiguration . . . . . . . . . . . . . . . . .   6
     3.3.  MANET-internal Communications . . . . . . . . . . . . . .   7
     3.4.  MANET Peer to Internetwork Correspondent  . . . . . . . .   8
     3.5.  Inte

Return 3-8 ideas. Focus on CONCRETE technical contributions, not general statements.
JSON array only, no fences.

response_json:
[
  {
    "title": "AERO/OMNI MANET Framework",
    "description": "A MANET internetworking framework that combines Automatic Extended Route Optimization (AERO) and Overlay Multilink Network Interface (OMNI) technologies. Enables MANETs to interface with fixed networks like the global Internet while maintaining autonomous mobile node operations.",
    "type": "architecture"
  },
  {
    "title": "MANET Local Addressing Scheme",
    "description": "A local addressing mechanism within the AERO/OMNI framework for mobile nodes in MANETs. Provides address assignment and management for nodes operating in autonomous mobile networks.",
    "type": "mechanism"
  },
  {
    "title": "MANET Autoconfiguration Protocol",
    "description": "An automatic configuration protocol for MANET nodes using AERO/OMNI technologies. Enables mobile nodes to self-configure network parameters without manual intervention.",
    "type": "protocol"
  },
  {
    "title": "MANET-Internal Communications Pattern",
    "description": "Communication mechanisms for intra-MANET node communications within the AERO/OMNI framework. Handles routing and data exchange between mobile nodes within the same MANET.",
    "type": "pattern"
  },
  {
    "title": "MANET-to-Internet Gateway Interface",
    "description": "A gateway mechanism that enables MANET peers to communicate with correspondent nodes in fixed internetworks. Bridges the gap between mobile autonomous networks and traditional Internet infrastructure.",
    "type": "mechanism"
  }
]


draft_name: draft-tiloca-lake-exporter-output-length
prompt_hash: 3372052351e73c49
model: claude-sonnet-4-20250514
created_at: 2026-02-28T11:23:21.817104+00:00
request_json:
Extract discrete technical ideas and mechanisms from this IETF draft.
Return a JSON array. Each element: {"title":"short name","description":"1-2 sentences","type":"mechanism|protocol|pattern|requirement|architecture|extension"}

draft-tiloca-lake-exporter-output-length | In-band Agreement of Output Lengths for the EDHOC_Exporter Interface of Ephemeral Diffie-Hellman Over COSE (EDHOC) | 10pg
Abstract: The lightweight authenticated key exchange protocol Ephemeral Diffie-
   Hellman Over COSE (EDHOC) allows two peers to compute a shared secret
   session key.  Once the session key is available, the two peers can
   use the EDHOC_Exporter interface, e.g., to derive keying material for
   an application protocol.  This document defines an in-band approach
   that can be used by the two peers to agree about the lengths of the
   outputs produced with the EDHOC_Exporter interface.  The defined
   approach relies on an EDHOC External Authorization Data (EAD) item
   that can be exchanged in the first two EDHOC messages of an EDHOC
   session.





LAKE Working Group                                             M. Tiloca
Internet-Draft                                                R. Höglund
Intended status: Standards Track                                 RISE AB
Expires: 8 January 2026                                   E. Lopez-Perez
                                                                   Inria
                                                             7 July 2025


In-band Agreement of Output Lengths for the EDHOC_Exporter Interface of
               Ephemeral Diffie-Hellman Over COSE (EDHOC)
              draft-tiloca-lake-exporter-output-length-00

Abstract

   The lightweight authenticated key exchange protocol Ephemeral Diffie-
   Hellman Over COSE (EDHOC) allows two peers to compute a shared secret
   session key.  Once the session key is available, the two peers can
   use the EDHOC_Exporter interface, e.g., to derive keying material for
   an application protocol.  This document defines an in-band approach
   that can be used by the two peers to agree about the lengths of the
   outputs produced with the EDHOC_Exporter interface.  The defined
   approach relies on an EDHOC External Authorization Data (EAD) item
   that can be exchanged in the first two EDHOC messages of an EDHOC
   session.

Discussion Venues

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

   Discussion of this document takes place on the Lightweight
   Authenticated Key Exchange Working Group mailing list
   (lake@ietf.org), which is archived at
   https://mailarchive.ietf.org/arch/browse/lake/.

   Source for this draft and an issue tracker can be found at
   https://gitlab.com/crimson84/draft-tiloca-lake-exporter-output-
   length.

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




Tiloca, et al.           Expires 8 January 2026                 [Page 1]

Internet-Draft        EDHOC_Exporter Output Lengths            July 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 January 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

Return 3-8 ideas. Focus on CONCRETE technical contributions, not general statements.
JSON array only, no fences.

response_json:
[
  {
    "title": "EDHOC_Exporter Output Length Negotiation",
    "description": "An in-band mechanism for EDHOC peers to agree on the lengths of outputs produced by the EDHOC_Exporter interface during key derivation. This allows dynamic negotiation of keying material lengths rather than using fixed or pre-configured values.",
    "type": "mechanism"
  },
  {
    "title": "EAD-Based Length Agreement",
    "description": "Uses EDHOC External Authorization Data (EAD) items exchanged in the first two EDHOC messages to carry output length preferences and agreements. This leverages the existing EAD extension mechanism for negotiating exporter output parameters.",
    "type": "extension"
  },
  {
    "title": "Bidirectional Length Negotiation Protocol",
    "description": "A protocol pattern where both EDHOC peers can propose desired output lengths in early messages and reach agreement before the session key derivation is complete. This ensures both parties know the expected keying material lengths upfront.",
    "type": "protocol"
  },
  {
    "title": "In-band Parameter Agreement Pattern",
    "description": "A general pattern for negotiating cryptographic parameters within the EDHOC handshake itself rather than through out-of-band configuration. This reduces deployment complexity by making parameter agreement part of the protocol flow.",
    "type": "pattern"
  }
]


draft_name: draft-tojens-dhcp-option-concat-considerations
prompt_hash: 80019e544dc591b4
model: claude-sonnet-4-20250514
created_at: 2026-02-28T11:23:29.494513+00:00
request_json:
Extract discrete technical ideas and mechanisms from this IETF draft.
Return a JSON array. Each element: {"title":"short name","description":"1-2 sentences","type":"mechanism|protocol|pattern|requirement|architecture|extension"}

draft-tojens-dhcp-option-concat-considerations | DHCP Option Concatenation Considerations | 7pg
Abstract: DHCP has a length limit of 255 on individual options because of its
   one-byte length field for options.  To accommodate longer options,
   splitting option data across multiple instances of the same Option
   Type is defined by RFC 3396.  However, this mechanism was defined to
   require support for all option types.  This has led to real-world
   implementations in the years since the RFC was published to deviate
   from these requirements to avoid breaking basic functionality.  This
   document updates RFC 3396 to be more flexible regarding when DHCP
   agents are required to concatenate options to reflect deployement
   experiences.





dhc                                                            T. Jensen
Internet-Draft                                                 M. Justel
Updates: 3396 (if approved)                                    Microsoft
Intended status: Informational                              3 March 2025
Expires: 4 September 2025


                DHCP Option Concatenation Considerations
           draft-tojens-dhcp-option-concat-considerations-01

Abstract

   DHCP has a length limit of 255 on individual options because of its
   one-byte length field for options.  To accommodate longer options,
   splitting option data across multiple instances of the same Option
   Type is defined by RFC 3396.  However, this mechanism was defined to
   require support for all option types.  This has led to real-world
   implementations in the years since the RFC was published to deviate
   from these requirements to avoid breaking basic functionality.  This
   document updates RFC 3396 to be more flexible regarding when DHCP
   agents are required to concatenate options to reflect deployement
   experiences.

Status of This Memo

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

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

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

   This Internet-Draft will expire on 4 September 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.



Jensen & Justel         Expires 4 September 2025                [Page 1]

Internet-Draft  DHCP Option Concatenation Considerations      March 2025


   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.  Previous Definition of Concatenation  . . . . . . . . . . . .   3
   4.  Implementation Challenges . . . . . . . . . . . . . . . . . .   3
   5.  What Concatenatio

Return 3-8 ideas. Focus on CONCRETE technical contributions, not general statements.
JSON array only, no fences.

response_json:
[
  {
    "title": "DHCP 255-byte Option Length Limit",
    "description": "DHCP options are constrained to 255 bytes maximum due to the one-byte length field in the option format. This fundamental limitation necessitates splitting mechanisms for longer option data.",
    "type": "requirement"
  },
  {
    "title": "Option Data Splitting via Multiple Instances",
    "description": "RFC 3396 defines a mechanism to accommodate options longer than 255 bytes by splitting the data across multiple instances of the same Option Type. These instances are then concatenated by the receiving agent.",
    "type": "mechanism"
  },
  {
    "title": "Universal Concatenation Support Requirement",
    "description": "RFC 3396 originally required DHCP agents to support concatenation for all option types universally. This blanket requirement has proven problematic in real-world deployments.",
    "type": "requirement"
  },
  {
    "title": "Selective Concatenation Support",
    "description": "This draft proposes updating RFC 3396 to allow more flexibility in which option types require concatenation support. DHCP agents would not need to implement concatenation for all options to avoid breaking basic functionality.",
    "type": "mechanism"
  },
  {
    "title": "Implementation Deviation Pattern",
    "description": "Real-world DHCP implementations have systematically deviated from RFC 3396's universal concatenation requirements to maintain operational stability. This pattern indicates the need for specification updates.",
    "type": "pattern"
  }
]


draft_name: draft-tong-network-agent-use-cases-in-6g
prompt_hash: 67ba468b68bc33b0
model: claude-sonnet-4-20250514
created_at: 2026-02-28T11:23:36.902580+00:00
request_json:
Extract discrete technical ideas and mechanisms from this IETF draft.
Return a JSON array. Each element: {"title":"short name","description":"1-2 sentences","type":"mechanism|protocol|pattern|requirement|architecture|extension"}

draft-tong-network-agent-use-cases-in-6g | Network AI Agent Use Cases and Requirements in 6G | 10pg
Abstract: This draft introduces use cases related to network AI agents in 6G,
   with a focus on the interaction workflows of network AI agents in two
   distinct scenarios: connectivity services and third-party application
   services.  These use cases primarily draw upon 6G-related scenarios
   outlined in the 3GPP technical report [TR22.870].  Furthermore, the
   document elaborates on the integration of network AI agents within
   the 6G framework and discusses corresponding network requirements.





Network Working Group                                            Y. Tong
Internet-Draft                                                    A. Sun
Intended status: Informational                                   A. Wang
Expires: 6 May 2026                                               Y. Liu
                                                                  Y. Xie
                                                           China Telecom
                                                         2 November 2025


           Network AI Agent Use Cases and Requirements in 6G
              draft-tong-network-agent-use-cases-in-6g-00

Abstract

   This draft introduces use cases related to network AI agents in 6G,
   with a focus on the interaction workflows of network AI agents in two
   distinct scenarios: connectivity services and third-party application
   services.  These use cases primarily draw upon 6G-related scenarios
   outlined in the 3GPP technical report [TR22.870].  Furthermore, the
   document elaborates on the integration of network AI agents within
   the 6G framework and discusses corresponding network 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.

   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



Tong, et al.               Expires 6 May 2026                   [Page 1]

Internet-Draft  Network AI Agent Use Cases and Requireme   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
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Generative Network for Connectivity Services  . 

Return 3-8 ideas. Focus on CONCRETE technical contributions, not general statements.
JSON array only, no fences.

response_json:
[
  {
    "title": "Network AI Agent Interaction Workflows",
    "description": "Specific workflow patterns for network AI agents operating in 6G scenarios, focusing on connectivity services and third-party application services. These workflows define how AI agents interact within the network infrastructure to provide automated services.",
    "type": "mechanism"
  },
  {
    "title": "6G Network AI Agent Integration Framework",
    "description": "Architecture for integrating AI agents within 6G network systems, based on 3GPP TR22.870 scenarios. Defines how AI agents are embedded and operate within the broader 6G network architecture.",
    "type": "architecture"
  },
  {
    "title": "Generative Network for Connectivity Services",
    "description": "Use case pattern where AI agents dynamically generate and configure network connectivity services in 6G environments. Enables automated provisioning and management of network connections based on service requirements.",
    "type": "pattern"
  },
  {
    "title": "AI Agent Third-Party Application Service Interface",
    "description": "Mechanism for network AI agents to interact with and support third-party applications in 6G networks. Provides standardized interfaces for external applications to leverage network AI capabilities.",
    "type": "mechanism"
  },
  {
    "title": "6G Network AI Agent Requirements Framework",
    "description": "Specific technical requirements for deploying and operating AI agents in 6G networks. Covers performance, integration, and operational requirements derived from the identified use cases.",
    "type": "requirement"
  }
]


draft_name: draft-vandoulas-aidp
prompt_hash: d702b2699616d928
model: claude-sonnet-4-20250514
created_at: 2026-02-28T11:23:43.936432+00:00
request_json:
Extract discrete technical ideas and mechanisms from this IETF draft.
Return a JSON array. Each element: {"title":"short name","description":"1-2 sentences","type":"mechanism|protocol|pattern|requirement|architecture|extension"}

draft-vandoulas-aidp | Agent Interaction & Delegation Protocol (AIDP) | 34pg
Abstract: This document specifies the Agent Interaction & Delegation Protocol
   (AIDP), a control-plane protocol for secure, auditable, and
   interoperable software agents.  AIDP defines standardized mechanisms
   for expressing intent, enforcing authority, delegating capabilities,
   executing actions, and binding execution results to agent reasoning
   across heterogeneous systems and administrative domains.

Internet-Draft                                           Ioannis Vandoulas
Intended status: Informational                                 January 2026
Expires: 15 July 2026


             Agent Interaction & Delegation Protocol (AIDP)
                 draft-vandoulas-aidp-02


Abstract

   This document specifies the Agent Interaction & Delegation Protocol
   (AIDP), a control-plane protocol for secure, auditable, and
   interoperable software agents.  AIDP defines standardized mechanisms
   for expressing intent, enforcing authority, delegating capabilities,
   executing actions, and binding execution results to agent reasoning
   across heterogeneous systems and administrative domains.


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


License Notice

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

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

Table of Contents

   1.  Introduction
   2.  Terminology and Conventions
   3.  Architecture Overview
   4.  Relation to Existing Work
   5.  Agent Identity Model
   6.  Authority & Capability Model
   7.  Intent Envelope
   8.  Execution Model
   9.  Observation & Feedback Binding
   10.  Multi-Agent Interaction
   11. Security Considerations
   12. Governance & Compliance
   13. Extensibility
   14. IANA Considerations
   15. Acknowledgements
   16. References
   17. Wire Format
   18. Message Schemas
   19. Example Messages
   20. Example Flows
   21. Reference Architecture
   22. HTTP Transport Binding
       22.1 Overview
       22.2 Media Types
       22.3 Endpoints
       22.4 Error Handling
       22.5 Webhook Verification
       22.6 Reference Validation Pipeline
   23. Conformance Test Suite Outline


1. Introduction
1.1 Motivation
Recent advances in Large Language Models (LLMs) have enabled the construction of software agents capable of complex reasoning,
planning, and adaptive behavior. While such agents increasingly participate in

Return 3-8 ideas. Focus on CONCRETE technical contributions, not general statements.
JSON array only, no fences.

response_json:
[
  {
    "title": "Intent Envelope",
    "description": "A standardized message format for expressing agent intentions with embedded authority and capability constraints. Enables secure transmission of agent goals across heterogeneous systems.",
    "type": "mechanism"
  },
  {
    "title": "Agent Identity Model",
    "description": "A framework for uniquely identifying and authenticating software agents across administrative domains. Provides the foundation for authority delegation and capability binding.",
    "type": "architecture"
  },
  {
    "title": "Authority & Capability Delegation",
    "description": "A mechanism for securely transferring execution permissions and capabilities between agents. Enables hierarchical control while maintaining auditability.",
    "type": "mechanism"
  },
  {
    "title": "Observation & Feedback Binding",
    "description": "A protocol feature that binds execution results back to agent reasoning systems. Ensures agents can learn from and adapt to the outcomes of their delegated actions.",
    "type": "mechanism"
  },
  {
    "title": "HTTP Transport Binding",
    "description": "A concrete implementation of AIDP over HTTP with defined endpoints, media types, and webhook verification. Provides practical interoperability for web-based agent systems.",
    "type": "protocol"
  },
  {
    "title": "Multi-Agent Interaction Model",
    "description": "Defines how multiple agents coordinate and delegate tasks while maintaining security boundaries. Enables complex multi-agent workflows across different administrative domains.",
    "type": "architecture"
  }
]


draft_name: draft-verma-dmsc-nlip-notes
prompt_hash: f0d1a585d2badd05
model: claude-sonnet-4-20250514
created_at: 2026-02-28T11:23:50.690398+00:00
request_json:
Extract discrete technical ideas and mechanisms from this IETF draft.
Return a JSON array. Each element: {"title":"short name","description":"1-2 sentences","type":"mechanism|protocol|pattern|requirement|architecture|extension"}

draft-verma-dmsc-nlip-notes | Use of Natural Language for Agent Communication | 8pg
Abstract: In current communication protocol designs, the prevalent practice is
   to define a strict Application Programming Interface (API) for
   different types of interactions among software entities.  There is an
   explosion of APIs which makes interoperability hard, and the
   standards for interoperability fragile.  Specifically for agent to
   agent communications, defining strict APIs for interactions such as
   registration, discovery, telemetry and debugging creates significant
   operational challenges.  In this draft, we argue that a flexible
   design option -- where generative AI is used to create a flexible
   communication protocol for APIs, can lead to a common and flexible
   way for a single uniform API to be used between agents, and enables a
   better communication paradigm.





DMSC Working Group                                              D. Verma
Internet-Draft                                                       IBM
Intended status: Informational                                E. Bertino
Expires: 14 August 2026                                Purdue University
                                                          A. Ratnaparkhi
                                                               eBay Inc.
                                                               S. Hughes
                                                             Service Now
                                                                 L. Xing
                                                                   Z. Li
                                                                 X. Liao
                                                                  J. Cui
                              University of Illinois at Urbana-Champaign
                                                            R. Topaloglu
                                                       Marist University
                                                              M. Rahouti
                                                      Fordham University
                                                        10 February 2026


            Use of Natural Language for Agent Communication
                     draft-verma-dmsc-nlip-notes-00

Abstract

   In current communication protocol designs, the prevalent practice is
   to define a strict Application Programming Interface (API) for
   different types of interactions among software entities.  There is an
   explosion of APIs which makes interoperability hard, and the
   standards for interoperability fragile.  Specifically for agent to
   agent communications, defining strict APIs for interactions such as
   registration, discovery, telemetry and debugging creates significant
   operational challenges.  In this draft, we argue that a flexible
   design option -- where generative AI is used to create a flexible
   communication protocol for APIs, can lead to a common and flexible
   way for a single uniform API to be used between agents, and enables a
   better communication paradigm.

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




Verma, et al.            Expires 14 August 2026                 [Page 1]

Internet-Draft             BGP-LS-Inter-AS-Ext             February 2026


   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as referen

Return 3-8 ideas. Focus on CONCRETE technical contributions, not general statements.
JSON array only, no fences.

response_json:
[
  {
    "title": "Natural Language Interchange Protocol (NLIP)",
    "description": "A protocol that uses natural language as the communication medium between software agents instead of rigid APIs. Leverages generative AI to interpret and generate natural language messages for agent interactions.",
    "type": "protocol"
  },
  {
    "title": "AI-Mediated API Translation",
    "description": "A mechanism where generative AI models translate between natural language requests and existing API calls, enabling flexible communication while maintaining compatibility with existing systems.",
    "type": "mechanism"
  },
  {
    "title": "Uniform Agent Communication Interface",
    "description": "A single, standardized interface that replaces multiple specific APIs for agent operations like registration, discovery, telemetry and debugging through natural language processing.",
    "type": "architecture"
  },
  {
    "title": "Generative AI Communication Layer",
    "description": "An architectural component that sits between agents and handles the interpretation of natural language messages, converting them to appropriate actions or responses.",
    "type": "architecture"
  },
  {
    "title": "Natural Language Agent Registration",
    "description": "A pattern where agents can register their capabilities and services using natural language descriptions rather than structured API specifications.",
    "type": "pattern"
  }
]


draft_name: draft-vinaysingh-awp-wellknown
prompt_hash: a5cf1d7d1d440a76
model: claude-sonnet-4-20250514
created_at: 2026-02-28T11:23:56.466274+00:00
request_json:
Extract discrete technical ideas and mechanisms from this IETF draft.
Return a JSON array. Each element: {"title":"short name","description":"1-2 sentences","type":"mechanism|protocol|pattern|requirement|architecture|extension"}

draft-vinaysingh-awp-wellknown | The Agent Workflow Protocol (AWP) Well-Known Resource and Link Relation | 6pg
Abstract: This document registers a Well-Known URI, /.well-known/awp.json, and
   a companion Link Relation Type, awp.  The resource exposes a small,
   machine-readable description of common website workflows (states,
   actions, and resulting events) so automated agents can act
   predictably without scraping.  The format is JSON and intentionally
   minimal.





Network Working Group                                           V. Singh
Internet-Draft                                                  Ajna.inc
Intended status: Standards Track                                D. McKay
Expires: 5 May 2026                                             Verid.id
                                                         1 November 2025


The Agent Workflow Protocol (AWP) Well-Known Resource and Link Relation
                   draft-vinaysingh-awp-wellknown-00

Abstract

   This document registers a Well-Known URI, /.well-known/awp.json, and
   a companion Link Relation Type, awp.  The resource exposes a small,
   machine-readable description of common website workflows (states,
   actions, and resulting events) so automated agents can act
   predictably without scraping.  The format is JSON and intentionally
   minimal.

About This Document

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

   Status information for this document may be found at
   https://datatracker.ietf.org/doc/draft-vinaysingh-awp-wellknown/.


   Source for this draft and an issue tracker can be found at
   https://github.com/vinaysingh8866/awp-wellknown-draft.

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.





Singh & McKay              Expires 5 May 2026                   [Page 1]

Internet-Draft               AWP Well-Known                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.  The AWP Resource  . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Discovery via Link Relation . . . . . . . . . . . . . . . . .   4
   4.  Secu

Return 3-8 ideas. Focus on CONCRETE technical contributions, not general statements.
JSON array only, no fences.

response_json:
[
  {
    "title": "AWP Well-Known URI",
    "description": "Registers /.well-known/awp.json as a standardized URI endpoint for exposing machine-readable website workflow descriptions. Provides a predictable location for automated agents to discover available workflows without web scraping.",
    "type": "mechanism"
  },
  {
    "title": "AWP Link Relation Type",
    "description": "Defines an 'awp' link relation type that can be used in HTML link elements or HTTP headers to reference AWP workflow descriptions. Enables discovery of AWP resources through standard web linking mechanisms.",
    "type": "extension"
  },
  {
    "title": "Workflow State-Action-Event Model",
    "description": "Structures website workflows as states, actions, and resulting events in JSON format. Allows automated agents to understand and navigate website functionality programmatically.",
    "type": "pattern"
  },
  {
    "title": "Minimal JSON Workflow Format",
    "description": "Specifies an intentionally lightweight JSON schema for describing website workflows. Balances machine readability with simplicity to encourage adoption.",
    "type": "protocol"
  }
]


draft_name: draft-wahl-scim-agent-schema
prompt_hash: 51fa2c27f435aaf9
model: claude-sonnet-4-20250514
created_at: 2026-02-28T11:24:01.885621+00:00
request_json:
Extract discrete technical ideas and mechanisms from this IETF draft.
Return a JSON array. Each element: {"title":"short name","description":"1-2 sentences","type":"mechanism|protocol|pattern|requirement|architecture|extension"}

draft-wahl-scim-agent-schema | System for Cross-domain Identity Management: Agentic Identity Schema | 13pg
Abstract: The System for Cross-domain Identity Management (SCIM) specifications
   are designed to make identity management in cloud-based applications
   and services easier.

   This document provides a platform-neutral schema for representing AI
   agents' identities in JSON format, enabling them to be transferred in
   the SCIM protocol to the service.  This establishes an agentic
   identity so that an agent can subsequently be authenticated and
   authorized to interact with the service.





System for Cross-domain Identity Management                      M. Wahl
Internet-Draft                                                 Microsoft
Intended status: Informational                            19 August 2025
Expires: 20 February 2026


  System for Cross-domain Identity Management: Agentic Identity Schema
                    draft-wahl-scim-agent-schema-01

Abstract

   The System for Cross-domain Identity Management (SCIM) specifications
   are designed to make identity management in cloud-based applications
   and services easier.

   This document provides a platform-neutral schema for representing AI
   agents' identities in JSON format, enabling them to be transferred in
   the SCIM protocol to the service.  This establishes an agentic
   identity so that an agent can subsequently be authenticated and
   authorized to interact with the service.

About This Document

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

   Status information for this document may be found at
   https://datatracker.ietf.org/doc/draft-wahl-scim-agent-schema/.

   Discussion of this document takes place on the System for Cross-
   domain Identity Management Working Group mailing list
   (mailto:scim@ietf.org), which is archived at
   https://mailarchive.ietf.org/arch/browse/scim/.  Subscribe at
   https://www.ietf.org/mailman/listinfo/scim/.

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



Wahl                    Expires 20 February 2026                [Page 1]

Internet-Draft              SCIM Agent Schema                August 2025


   This Internet-Draft will expire on 20 February 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  . . . . . . . . . . . . . . .

Return 3-8 ideas. Focus on CONCRETE technical contributions, not general statements.
JSON array only, no fences.

response_json:
[
  {
    "title": "Agentic Identity Schema",
    "description": "A platform-neutral JSON schema specifically designed for representing AI agents' identities within the SCIM framework. This enables AI agents to have structured identity representations that can be managed through standard identity management protocols.",
    "type": "schema"
  },
  {
    "title": "SCIM Agent Transfer Protocol",
    "description": "A mechanism for transferring AI agent identity data using the existing SCIM protocol infrastructure. This allows agent identities to be provisioned and managed across different cloud services and applications.",
    "type": "protocol"
  },
  {
    "title": "Agent Authentication and Authorization Framework",
    "description": "An identity establishment pattern that enables AI agents to be subsequently authenticated and authorized to interact with services after their identity is provisioned through SCIM. This bridges identity provisioning with access control for AI agents.",
    "type": "pattern"
  },
  {
    "title": "Cross-Domain Agent Identity Management",
    "description": "An architecture extending SCIM's cross-domain identity management capabilities to support AI agents in cloud-based applications and services. This provides a standardized approach for managing agent identities across organizational boundaries.",
    "type": "architecture"
  }
]


draft_name: draft-wang-hjs-accountability
prompt_hash: c13aa9474dd12d04
model: claude-sonnet-4-20250514
created_at: 2026-02-28T11:24:08.837675+00:00
request_json:
Extract discrete technical ideas and mechanisms from this IETF draft.
Return a JSON array. Each element: {"title":"short name","description":"1-2 sentences","type":"mechanism|protocol|pattern|requirement|architecture|extension"}

draft-wang-hjs-accountability | HJS: An Accountability Layer for AI Agents | 8pg
Abstract: This document defines HJS (Human Judgment System), a standalone
accountability layer for AI agents. HJS provides four primitives
(Judgment/Delegation/Termination/Verification) for recording
complete responsibility chains, and uses OTS (Open Timestamp) proofs
anchored to the Bitcoin blockchain to create immutable, court-
admissible evidence. While HJS can complement other protocols (e.g.,
AIIP) by providing the evidence they require, it is designed to be
independent and usable with any AI agent communication framework.

Internet-Draft                                          Y. Wang
Intended status: Informational                          HUMAN JUDGMENT SYSTEMS FOUNDATION LTD.
Expires: 21 August 2026                            21 February 2026


                     HJS: An Accountability Layer
                           for AI Agents

                     draft-wang-hjs-accountability-00

Abstract
This document defines HJS (Human Judgment System), a standalone
accountability layer for AI agents. HJS provides four primitives
(Judgment/Delegation/Termination/Verification) for recording
complete responsibility chains, and uses OTS (Open Timestamp) proofs
anchored to the Bitcoin blockchain to create immutable, court-
admissible evidence. While HJS can complement other protocols (e.g.,
AIIP) by providing the evidence they require, it is designed to be
independent and usable with any AI agent communication framework.

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 21 August 2026.

Copyright Notice

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

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


Wang                     Expires 21 August 2026                 [Page 1]

Internet-Draft          HJS Accountability Layer         21 February 2026

Table of Contents

   1. Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3. The Four Primitives . . . . . . . . . . . . . . . . . . . . .   3
     3.1. Judgment . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.2. Delegation . . . . . . . . . . . . . . . . . . . . . . .   4
     3.3. Termination . . . . . . . . . . . . . . . . . . . . . . .   4
     3.4. Verification . . . . . . . . . . . . . . . . . . . . . .   5
     3.5. Responsibility Chain . . . . . . . . . . . . . . . . . .   5
   4. OTS Evidence Chain . . . . . . . . . . . . . . . . . . . . . .   6
     4.1. OTS Proof Overview . . . . . . . . . . . . . . . . . . .   6
     4.2. Locking the Chain 

Return 3-8 ideas. Focus on CONCRETE technical contributions, not general statements.
JSON array only, no fences.

response_json:
[
  {
    "title": "Four HJS Primitives",
    "description": "Judgment, Delegation, Termination, and Verification primitives that form the core operations for recording complete responsibility chains in AI agent interactions. These primitives enable structured accountability tracking through standardized operations.",
    "type": "mechanism"
  },
  {
    "title": "Responsibility Chain Recording",
    "description": "A systematic approach to documenting the complete chain of responsibility in AI agent decision-making processes. Links together judgment decisions, delegations, and terminations to create traceable accountability paths.",
    "type": "pattern"
  },
  {
    "title": "OTS Evidence Chain",
    "description": "Integration of Open Timestamp (OTS) proofs anchored to the Bitcoin blockchain to create immutable, tamper-proof evidence of AI agent decisions and responsibility transfers. Provides court-admissible documentation of the accountability chain.",
    "type": "mechanism"
  },
  {
    "title": "Standalone Accountability Layer",
    "description": "An independent architectural layer that can complement existing AI agent protocols (like AIIP) while remaining framework-agnostic. Designed to work with any AI agent communication system without requiring protocol modifications.",
    "type": "architecture"
  },
  {
    "title": "Blockchain-Anchored Immutability",
    "description": "Uses Bitcoin blockchain timestamping to ensure accountability records cannot be altered after creation. Creates legally admissible evidence through cryptographic proof of record integrity and timing.",
    "type": "mechanism"
  }
]


draft_name: draft-wang-nmrg-magent-im
prompt_hash: 8d53bf0cf6a5e101
model: claude-sonnet-4-20250514
created_at: 2026-02-28T11:24:14.753088+00:00
request_json:
Extract discrete technical ideas and mechanisms from this IETF draft.
Return a JSON array. Each element: {"title":"short name","description":"1-2 sentences","type":"mechanism|protocol|pattern|requirement|architecture|extension"}

draft-wang-nmrg-magent-im | A Protocol-agnostic Multiple Agents Interaction Model for Autonomous Network | 33pg
Abstract: In the push toward Level 4 Autonomous Networks, CSPs must to adopt
   new processes and organizational changes, along with function-centric
   building blocks for higher autonomy.  As intelligent agents evolve,
   network autonomy increasingly relies on deploying these agents,
   enabling self-management, self-healing, and adaptation with minimal
   human intervention.  These agents facilitate the transition toward
   fully autonomous network operations across multiple layers, including
   services and resources.  However, achieving Level 4 autonomy, where
   networks independently handle tasks across various domains, presents
   significant challenges, notably secure, efficient, and accurate
   multi-agent interactions.  This document introduces a protocol-
   agnostic data model that enables multiple intelligent agents to
   communicate effectively using the model, ensuring end-to-end task
   execution and closed-loop operations in autonomous networks.





Network Management Research Group                                M. Wang
Internet-Draft                                                    Y. Xie
Intended status: Informational                                     Q. Wu
Expires: 8 January 2026                                           Huawei
                                                             7 July 2025


  A Protocol-agnostic Multiple Agents Interaction Model for Autonomous
                                Network
                      draft-wang-nmrg-magent-im-00

Abstract

   In the push toward Level 4 Autonomous Networks, CSPs must to adopt
   new processes and organizational changes, along with function-centric
   building blocks for higher autonomy.  As intelligent agents evolve,
   network autonomy increasingly relies on deploying these agents,
   enabling self-management, self-healing, and adaptation with minimal
   human intervention.  These agents facilitate the transition toward
   fully autonomous network operations across multiple layers, including
   services and resources.  However, achieving Level 4 autonomy, where
   networks independently handle tasks across various domains, presents
   significant challenges, notably secure, efficient, and accurate
   multi-agent interactions.  This document introduces a protocol-
   agnostic data model that enables multiple intelligent agents to
   communicate effectively using the model, ensuring end-to-end task
   execution and closed-loop operations in autonomous networks.

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 January 2026.







Wang, et al.             Expires 8 January 2026                 [Page 1]

Internet-Draft                   MAgent                        July 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

Return 3-8 ideas. Focus on CONCRETE technical contributions, not general statements.
JSON array only, no fences.

response_json:
[
  {
    "title": "Protocol-agnostic Multi-Agent Data Model",
    "description": "A standardized data model that enables intelligent agents to communicate effectively across different protocols and domains in autonomous networks. This model ensures interoperability between agents regardless of their underlying communication protocols.",
    "type": "mechanism"
  },
  {
    "title": "Level 4 Autonomous Network Architecture",
    "description": "A network architecture framework where networks independently handle tasks across various domains with minimal human intervention. This represents the highest level of network autonomy with self-management, self-healing, and adaptation capabilities.",
    "type": "architecture"
  },
  {
    "title": "Multi-Agent Interaction Pattern",
    "description": "A structured approach for secure, efficient, and accurate communication between multiple intelligent agents in autonomous networks. This pattern facilitates coordinated decision-making and task execution across network layers.",
    "type": "pattern"
  },
  {
    "title": "End-to-End Task Execution Model",
    "description": "A mechanism that ensures complete task execution from initiation to completion across multiple agents and network domains. This model supports closed-loop operations in autonomous network environments.",
    "type": "mechanism"
  },
  {
    "title": "Function-Centric Building Blocks",
    "description": "Modular network components designed around specific functions rather than traditional hierarchical structures. These building blocks enable higher levels of network autonomy and facilitate agent-based network management.",
    "type": "architecture"
  }
]


draft_name: draft-wang-ppm-ecdh-psi
prompt_hash: f07f8a9d16d761aa
model: claude-sonnet-4-20250514
created_at: 2026-02-28T11:24:20.106398+00:00
request_json:
Extract discrete technical ideas and mechanisms from this IETF draft.
Return a JSON array. Each element: {"title":"short name","description":"1-2 sentences","type":"mechanism|protocol|pattern|requirement|architecture|extension"}

draft-wang-ppm-ecdh-psi | PSI based on ECDH | 31pg
Abstract: This document describes Elliptic Curve Diffie-Hellman Private Set
   Intersection (ECDH-PSI) for 2 participants.  It instantiates the
   classical Meadows match-making protocol with standard elliptic curves
   and hash-to-curve methods, enabling the participants to find common
   records in a privacy-respecting way.  In ECDH-PSI, records are
   encoded to points on an elliptic curve, and masked by the private
   keys of both participants.  To compute the intersection, a
   participant only uses the jointly masked datasets and its original
   dataset locally, which prevents its partner from learning the private
   records not in the intersection.





Privacy Preserving Measurement                                   Y. Wang
Internet-Draft                                                  W. Chang
Intended status: Informational                                     Y. Lu
Expires: 21 August 2025                                          C. Hong
                                                                 J. Peng
                                                               Ant Group
                                                        17 February 2025


                           PSI based on ECDH
                       draft-wang-ppm-ecdh-psi-01

Abstract

   This document describes Elliptic Curve Diffie-Hellman Private Set
   Intersection (ECDH-PSI) for 2 participants.  It instantiates the
   classical Meadows match-making protocol with standard elliptic curves
   and hash-to-curve methods, enabling the participants to find common
   records in a privacy-respecting way.  In ECDH-PSI, records are
   encoded to points on an elliptic curve, and masked by the private
   keys of both participants.  To compute the intersection, a
   participant only uses the jointly masked datasets and its original
   dataset locally, which prevents its partner from learning the private
   records not in the intersection.

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 21 August 2025.

Copyright Notice

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





Wang, et al.             Expires 21 August 2025                 [Page 1]

Internet-Draft                  ECDH-PSI                   February 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  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Requirements Terminology  . . . . . . . . . . . . . . .

Return 3-8 ideas. Focus on CONCRETE technical contributions, not general statements.
JSON array only, no fences.

response_json:
[
  {
    "title": "ECDH-PSI Protocol",
    "description": "Two-party private set intersection protocol that instantiates the classical Meadows match-making protocol using elliptic curve Diffie-Hellman operations. Participants find common records without revealing private records not in the intersection.",
    "type": "protocol"
  },
  {
    "title": "Dual Private Key Masking",
    "description": "Records are encoded to elliptic curve points and masked by the private keys of both participants to ensure privacy. This prevents either party from learning the other's private records outside the intersection.",
    "type": "mechanism"
  },
  {
    "title": "Hash-to-Curve Record Encoding",
    "description": "Standard hash-to-curve methods are used to encode records as points on an elliptic curve. This enables cryptographic operations while maintaining the integrity of the original data.",
    "type": "mechanism"
  },
  {
    "title": "Local Intersection Computation",
    "description": "Participants compute the intersection using jointly masked datasets combined with their original dataset locally. This architecture prevents exposure of non-intersecting private records to the partner.",
    "type": "architecture"
  }
]


draft_name: draft-wendt-stir-vesper
prompt_hash: 186b5138aa218ecc
model: claude-sonnet-4-20250514
created_at: 2026-02-28T11:24:26.997632+00:00
request_json:
Extract discrete technical ideas and mechanisms from this IETF draft.
Return a JSON array. Each element: {"title":"short name","description":"1-2 sentences","type":"mechanism|protocol|pattern|requirement|architecture|extension"}

draft-wendt-stir-vesper | VESPER - Framework for VErifiable STI Personas | 23pg
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.





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 

Return 3-8 ideas. Focus on CONCRETE technical contributions, not general statements.
JSON array only, no fences.

response_json:
[
  {
    "title": "TNAuthList Authority Token",
    "description": "A token that serves as a trusted representation of telephone number assignment and right-to-use (RTU). It provides authoritative proof that an entity has the legitimate right to use specific telephone numbers.",
    "type": "mechanism"
  },
  {
    "title": "JWTClaimConstraints Authority Tokens",
    "description": "Tokens issued by authoritative claim agents to assert information associated with entities assigned telephone numbers, extending authority tokens to support PASSporT claims like Rich Call Data (RCD).",
    "type": "extension"
  },
  {
    "title": "Notary Agent",
    "description": "A critical component that logs telephone number associations and claims through verifiable transparency mechanisms. It records claims and their provenance to enhance transparency and accountability.",
    "type": "architecture"
  },
  {
    "title": "VESPER Delegate Certificates",
    "description": "Certificates that encapsulate telephone numbers and associated information validated via authority tokens, binding them to authenticated calling party numbers. These certificates are published to certificate transparency logs for independent verification.",
    "type": "mechanism"
  },
  {
    "title": "STI Persona Verification Framework",
    "description": "A comprehensive framework utilizing STIR protocols and ACME authority tokens to create verifiable, auditable associations between telephone numbers and identifiable entities with metadata assertions.",
    "type": "framework"
  }
]


draft_name: draft-williams-http-bearer-extension
prompt_hash: 886702ed748292f0
model: claude-sonnet-4-20250514
created_at: 2026-02-28T11:24:33.736608+00:00
request_json:
Extract discrete technical ideas and mechanisms from this IETF draft.
Return a JSON array. Each element: {"title":"short name","description":"1-2 sentences","type":"mechanism|protocol|pattern|requirement|architecture|extension"}

draft-williams-http-bearer-extension | HTTP Bearer Auth Method Extensions | 16pg
Abstract: This document specifies an improved HTTP 401 and 407 flow for Bearer
   authentication where user-agents (or client applications) can
   automatically fetch requested tokens from a Security Token Service
   (STS).  A fallback to an OpenID Connect (OIDC) redirect flow is
   included.

   This improved 401/407 Bearer flow, when used, elides the need for
   Proof Key for Code Exchange (PKCE) and does not impose on application
   Universal Resource Identifier (URI) query parameter design.  As well
   this extension allows for user-agent caching of tokens.





HTTP                                                         N. Williams
Internet-Draft                                           3 December 2025
Intended status: Standards Track                                        
Expires: 6 June 2026


                   HTTP Bearer Auth Method Extensions
                draft-williams-http-bearer-extension-00

Abstract

   This document specifies an improved HTTP 401 and 407 flow for Bearer
   authentication where user-agents (or client applications) can
   automatically fetch requested tokens from a Security Token Service
   (STS).  A fallback to an OpenID Connect (OIDC) redirect flow is
   included.

   This improved 401/407 Bearer flow, when used, elides the need for
   Proof Key for Code Exchange (PKCE) and does not impose on application
   Universal Resource Identifier (URI) query parameter design.  As well
   this extension allows for user-agent caching of tokens.

About This Document

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

   Status information for this document may be found at
   https://datatracker.ietf.org/doc/draft-williams-http-bearer-
   extension/.

   Discussion of this document takes place on the NETWORK Working Group
   mailing list (mailto:ietf-http-wg@w3.org), which is archived at
   https://lists.w3.org/Archives/Public/ietf-http-wg/.

   Source for this draft and an issue tracker can be found at
   https://github.com/nicowilliams/http-bearer-ext.

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





Williams                   Expires 6 June 2026                  [Page 1]

Internet-Draft     HTTP Bearer Auth Method Extensions      December 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 6 June 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 

Return 3-8 ideas. Focus on CONCRETE technical contributions, not general statements.
JSON array only, no fences.

response_json:
[
  {
    "title": "Improved 401/407 Bearer Flow",
    "description": "An enhanced HTTP authentication flow that allows user-agents to automatically fetch Bearer tokens from a Security Token Service (STS) when receiving 401 or 407 responses. This eliminates manual token acquisition steps.",
    "type": "protocol"
  },
  {
    "title": "Automatic STS Token Fetching",
    "description": "A mechanism where user-agents can programmatically retrieve authentication tokens from a Security Token Service without user intervention. This enables seamless authentication workflows.",
    "type": "mechanism"
  },
  {
    "title": "OIDC Redirect Fallback",
    "description": "A fallback mechanism to OpenID Connect redirect flow when the improved Bearer authentication method fails. This ensures compatibility with existing authentication systems.",
    "type": "pattern"
  },
  {
    "title": "PKCE Elimination",
    "description": "The improved Bearer flow removes the need for Proof Key for Code Exchange (PKCE) in authentication flows. This simplifies the authentication process while maintaining security.",
    "type": "extension"
  },
  {
    "title": "User-Agent Token Caching",
    "description": "A capability that allows user-agents to cache authentication tokens locally for reuse. This reduces repeated authentication requests and improves performance.",
    "type": "mechanism"
  },
  {
    "title": "URI Query Parameter Independence",
    "description": "The extension design does not impose constraints on application URI query parameter structure. This preserves application design flexibility while adding authentication capabilities.",
    "type": "requirement"
  }
]


draft_name: draft-willman-rtgwg-conduit-tunnels
prompt_hash: 8810c06ff17bea36
model: claude-sonnet-4-20250514
created_at: 2026-02-28T11:24:42.563526+00:00
request_json:
Extract discrete technical ideas and mechanisms from this IETF draft.
Return a JSON array. Each element: {"title":"short name","description":"1-2 sentences","type":"mechanism|protocol|pattern|requirement|architecture|extension"}

draft-willman-rtgwg-conduit-tunnels | Underlay for IPsec Transport | 38pg
Abstract: This document specifies CONDUIT, a tunnel fabric management protocol
   for tactical and enterprise networks operating over heterogeneous
   Wide Area Network (WAN) links.  CONDUIT automates the lifecycle
   management of IPsec tunnels, monitors tunnel health through active
   probing, and publishes quality metrics to enable Segment Routing over
   IPv6 (SRv6) based traffic engineering.

   CONDUIT follows a strict separation of concerns: it manages the
   underlay tunnel fabric while delegating all traffic engineering
   decisions to SRv6.  This architecture simplifies network operations,
   enables rapid adaptation to changing WAN conditions, and leverages
   standard SRv6 capabilities including Flexible Algorithm (Flex-Algo)
   and Topology-Independent Loop-Free Alternate (TI-LFA).

   The protocol is fully programmable via gRPC and mandates compliance
   with Commercial National Security Algorithm Suite 2.0 (CNSA 2.0)
   cryptographic requirements.





Routing Area Working Group                                    J. E. W. V
Internet-Draft                               Department of the Air Force
Updates: draft-conduit-tunnel-fabric (if                19 February 2026
         approved)                                                      
Intended status: Standards Track                                        
Expires: 23 August 2026


                      Underlay for IPsec Transport
                 draft-willman-rtgwg-conduit-tunnels-01

Abstract

   This document specifies CONDUIT, a tunnel fabric management protocol
   for tactical and enterprise networks operating over heterogeneous
   Wide Area Network (WAN) links.  CONDUIT automates the lifecycle
   management of IPsec tunnels, monitors tunnel health through active
   probing, and publishes quality metrics to enable Segment Routing over
   IPv6 (SRv6) based traffic engineering.

   CONDUIT follows a strict separation of concerns: it manages the
   underlay tunnel fabric while delegating all traffic engineering
   decisions to SRv6.  This architecture simplifies network operations,
   enables rapid adaptation to changing WAN conditions, and leverages
   standard SRv6 capabilities including Flexible Algorithm (Flex-Algo)
   and Topology-Independent Loop-Free Alternate (TI-LFA).

   The protocol is fully programmable via gRPC and mandates compliance
   with Commercial National Security Algorithm Suite 2.0 (CNSA 2.0)
   cryptographic 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 23 August 2026.




V                        Expires 23 August 2026                 [Page 1]

Internet-Draft        Underlay for IPsec Transport         February 2026


Copyright Notice

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

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

Return 3-8 ideas. Focus on CONCRETE technical contributions, not general statements.
JSON array only, no fences.

response_json:
[
  {
    "title": "CONDUIT Tunnel Fabric Management Protocol",
    "description": "A protocol that automates the lifecycle management of IPsec tunnels in tactical and enterprise networks. It handles tunnel creation, maintenance, and teardown while operating over heterogeneous WAN links.",
    "type": "protocol"
  },
  {
    "title": "Active Tunnel Health Probing",
    "description": "A mechanism for monitoring IPsec tunnel health through continuous active probing. It publishes quality metrics that can be consumed by traffic engineering systems.",
    "type": "mechanism"
  },
  {
    "title": "Underlay-Overlay Separation Architecture",
    "description": "A strict architectural pattern where CONDUIT manages the underlay IPsec tunnel fabric while delegating all traffic engineering decisions to SRv6. This creates clear separation of concerns between tunnel management and routing decisions.",
    "type": "architecture"
  },
  {
    "title": "SRv6 Quality Metrics Publication",
    "description": "A mechanism for publishing tunnel quality metrics to enable SRv6-based traffic engineering decisions. This allows SRv6 Flexible Algorithm and TI-LFA to make informed path selections based on underlay conditions.",
    "type": "mechanism"
  },
  {
    "title": "gRPC Programmable Interface",
    "description": "A requirement for full programmability of the CONDUIT protocol through gRPC APIs. This enables automated management and integration with network orchestration systems.",
    "type": "requirement"
  },
  {
    "title": "CNSA 2.0 Cryptographic Compliance",
    "description": "A mandatory requirement for compliance with Commercial National Security Algorithm Suite 2.0 cryptographic standards. This ensures appropriate security levels for tactical and enterprise deployments.",
    "type": "requirement"
  }
]


draft_name: draft-wmz-nmrg-agent-ndt-arch
prompt_hash: f1e8c9bc422df25d
model: claude-sonnet-4-20250514
created_at: 2026-02-28T11:24:49.629748+00:00
request_json:
Extract discrete technical ideas and mechanisms from this IETF draft.
Return a JSON array. Each element: {"title":"short name","description":"1-2 sentences","type":"mechanism|protocol|pattern|requirement|architecture|extension"}

draft-wmz-nmrg-agent-ndt-arch | Network Digital Twin and Agentic AI based Architecture for AI driven Network Operations | 37pg
Abstract: A Network Digital Twin (NDT) provides a network emulation tool usable
   for different purposes such as scenario planning, impact analysis,
   and change management.  Integrating a Network Digital Twin into
   network management together with Agentic AI, it allows the network
   management activities to take user intent or service requirements as
   input, automatically assess, model, and refine optimization
   strategies under realistic conditions but in a risk-free environment.
   Such environment that operates to meet these types of requirements is
   said to have AI driven Network Operations.

   AI driven Network Operations brings together existing technologies
   such as Agentic AI and Network Digital Twin which may be seen as the
   use of a toolbox of existing components enhanced with a few new
   elements.

   This document describes an architecture for AI driven network
   operations and shows how these components work together with network
   digital twin and Agentic AI capabilities.  It provides a cookbook of
   existing technologies to satisfy the architecture and realize intent-
   based network management to meet the needs of the network service.





Network Management                                                 Q. Wu
Internet-Draft                                                    Huawei
Intended status: Informational                                   C. Zhou
Expires: 28 August 2026                                     China Mobile
                                                         L. M. Contreras
                                                              Telefonica
                                                                  S. Han
                                                            China Unicom
                                                                 Y. Hong
                                                      Daejeon University
                                                        24 February 2026


  Network Digital Twin and Agentic AI based Architecture for AI driven
                           Network Operations
                  draft-wmz-nmrg-agent-ndt-arch-03

Abstract

   A Network Digital Twin (NDT) provides a network emulation tool usable
   for different purposes such as scenario planning, impact analysis,
   and change management.  Integrating a Network Digital Twin into
   network management together with Agentic AI, it allows the network
   management activities to take user intent or service requirements as
   input, automatically assess, model, and refine optimization
   strategies under realistic conditions but in a risk-free environment.
   Such environment that operates to meet these types of requirements is
   said to have AI driven Network Operations.

   AI driven Network Operations brings together existing technologies
   such as Agentic AI and Network Digital Twin which may be seen as the
   use of a toolbox of existing components enhanced with a few new
   elements.

   This document describes an architecture for AI driven network
   operations and shows how these components work together with network
   digital twin and Agentic AI capabilities.  It provides a cookbook of
   existing technologies to satisfy the architecture and realize intent-
   based network management to meet the needs of the network service.

Discussion Venues

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

   Discussion of this document takes place on the Network Management
   mailing list (nmrg@irtf.org), which is archived at
   https://mailarchive.ietf.org/arch/browse/nmrg.

   Source for this draft and an issue tracker can be found at
   https://github.com/QiufangMa/Agent-architecture.

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 m

Return 3-8 ideas. Focus on CONCRETE technical contributions, not general statements.
JSON array only, no fences.

response_json:
[
  {
    "title": "Network Digital Twin (NDT)",
    "description": "A network emulation tool that provides risk-free environment for scenario planning, impact analysis, and change management. It enables testing and optimization of network strategies under realistic conditions without affecting the production network.",
    "type": "mechanism"
  },
  {
    "title": "Agentic AI Integration",
    "description": "AI agents that can automatically assess, model, and refine network optimization strategies by taking user intent or service requirements as input. These agents work in conjunction with the Network Digital Twin to make autonomous network management decisions.",
    "type": "mechanism"
  },
  {
    "title": "AI-Driven Network Operations Architecture",
    "description": "An integrated architecture that combines Network Digital Twin and Agentic AI capabilities to enable intent-based network management. It provides a framework for automatic network optimization based on service requirements.",
    "type": "architecture"
  },
  {
    "title": "Intent-Based Network Management",
    "description": "A management approach where network operations are driven by high-level user intents and service requirements rather than low-level configuration commands. The system automatically translates intent into network configurations and optimizations.",
    "type": "pattern"
  },
  {
    "title": "Risk-Free Network Testing Environment",
    "description": "A simulation environment provided by the Network Digital Twin that allows network changes and optimizations to be tested without impacting the production network. It enables safe experimentation with network configurations and policies.",
    "type": "mechanism"
  }
]


draft_name: draft-wolfe-faf-format
prompt_hash: 4fe01f9e44948cbd
model: claude-sonnet-4-20250514
created_at: 2026-02-28T11:24:55.771879+00:00
request_json:
Extract discrete technical ideas and mechanisms from this IETF draft.
Return a JSON array. Each element: {"title":"short name","description":"1-2 sentences","type":"mechanism|protocol|pattern|requirement|architecture|extension"}

draft-wolfe-faf-format | FAF: Foundational AI-context Format for Development Tools | 10pg
Abstract: This document specifies FAF (Foundational AI-context Format), a YAML-
   based format for representing software project context in a form
   consumable by AI development tools.  FAF provides a standardized
   mechanism for sharing project architecture, conventions,
   dependencies, and goals across heterogeneous AI agents, addressing
   context fragmentation in multi-agent development environments.

   FAF is registered with IANA as "application/vnd.faf+yaml" (October
   2025).  This document seeks registration as "application/faf+yaml".





Network Working Group                                           J. Wolfe
Internet-Draft                                            FAF Foundation
Intended status: Informational                           21 January 2026
Expires: 25 July 2026


       FAF: Foundational AI-context Format for Development Tools
                       draft-wolfe-faf-format-00

Abstract

   This document specifies FAF (Foundational AI-context Format), a YAML-
   based format for representing software project context in a form
   consumable by AI development tools.  FAF provides a standardized
   mechanism for sharing project architecture, conventions,
   dependencies, and goals across heterogeneous AI agents, addressing
   context fragmentation in multi-agent development environments.

   FAF is registered with IANA as "application/vnd.faf+yaml" (October
   2025).  This document seeks registration as "application/faf+yaml".

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 25 July 2026.

Copyright Notice

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

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



Wolfe                     Expires 25 July 2026                  [Page 1]

Internet-Draft                     FAF                      January 2026


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Problem Statement . . . . . . . . . . . . . . . . . . . .   2
     1.2.  Solution Overview . . . . . . . . . . . . . . . . . . . .   3
     1.3.  Design Goals  . . . . . . . . . . . . . . . . . . . . . .   3
     1.4.  Existing Registration . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Format Overview . . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Base Format . . . . . . . . . . . . . . . . . . . . . . .   4
     3.2.  Example . . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Schema Specification  . . . . . . . . . . . . . . . . . . . .   4


Return 3-8 ideas. Focus on CONCRETE technical contributions, not general statements.
JSON array only, no fences.

response_json:
[
  {
    "title": "FAF YAML-based Context Format",
    "description": "A YAML-based structured format for representing software project context including architecture, conventions, dependencies, and goals. Designed specifically for consumption by AI development tools.",
    "type": "protocol"
  },
  {
    "title": "Multi-agent Context Sharing",
    "description": "Standardized mechanism for sharing project context across heterogeneous AI agents in development environments. Addresses context fragmentation by providing a common format.",
    "type": "mechanism"
  },
  {
    "title": "IANA Media Type Registration",
    "description": "Registration of 'application/vnd.faf+yaml' and proposed 'application/faf+yaml' media types with IANA. Enables proper content type identification for FAF files.",
    "type": "extension"
  },
  {
    "title": "AI Tool Context Consumption",
    "description": "Structured approach for AI development tools to parse and utilize project context information. Enables consistent interpretation of project requirements and constraints.",
    "type": "pattern"
  }
]


draft_name: draft-xie-ai-agent-multimodal
prompt_hash: 233c595134dc054c
model: claude-sonnet-4-20250514
created_at: 2026-02-28T11:25:03.556359+00:00
request_json:
Extract discrete technical ideas and mechanisms from this IETF draft.
Return a JSON array. Each element: {"title":"short name","description":"1-2 sentences","type":"mechanism|protocol|pattern|requirement|architecture|extension"}

draft-xie-ai-agent-multimodal | Multimodal Management Requirements for AI Agent Protocols | 5pg
Abstract: This document specifies the Multimodal requirements for Agent-to-
   Agent Protocol, which enables autonomous agents to establish multi-
   channel communication sessions, negotiate heterogeneous data
   capabilities (e.g., text, file, real-time audio/video streams, sensor
   streams), and exchange synchronized multimodal content with adaptive
   QoS policies.





Network Working Group                                             G. Xie
Internet-Draft                                                     Y. Li
Intended status: Informational                                 CNIC, CAS
Expires: 8 January 2026                                      7 July 2025


       Multimodal Management Requirements for AI Agent Protocols
                    draft-xie-ai-agent-multimodal-00

Abstract

   This document specifies the Multimodal requirements for Agent-to-
   Agent Protocol, which enables autonomous agents to establish multi-
   channel communication sessions, negotiate heterogeneous data
   capabilities (e.g., text, file, real-time audio/video streams, sensor
   streams), and exchange synchronized multimodal content with adaptive
   QoS policies.

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



Xie & Li                 Expires 8 January 2026                 [Page 1]

Internet-Draft            Agent Task Management                July 2025


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Purpose . . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Necessity . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Protocol Requirements . . . . . . . . . . . . . . . . . . . .   3
     4.1.  Multimodal Media Channel Establishment (Signaling)  . . .   3
     4.2.  Multimodal Media Transmission (Media Handling)  . . . . .   4
   5.  Conclusions . . . . . . . . . . . . .

Return 3-8 ideas. Focus on CONCRETE technical contributions, not general statements.
JSON array only, no fences.

response_json:
[
  {
    "title": "Multi-channel Communication Sessions",
    "description": "Mechanism for autonomous agents to establish multiple simultaneous communication channels for different data types. Enables parallel transmission of heterogeneous content streams.",
    "type": "mechanism"
  },
  {
    "title": "Heterogeneous Data Capability Negotiation",
    "description": "Protocol for agents to discover and agree upon supported data formats including text, files, real-time audio/video, and sensor streams. Establishes common communication capabilities before data exchange.",
    "type": "protocol"
  },
  {
    "title": "Synchronized Multimodal Content Exchange",
    "description": "Framework for coordinating the transmission of multiple data modalities with temporal alignment. Ensures coherent delivery of related content across different media types.",
    "type": "mechanism"
  },
  {
    "title": "Adaptive QoS Policies",
    "description": "Dynamic quality of service adjustment based on network conditions and content priority. Automatically optimizes bandwidth allocation and delivery parameters for multimodal streams.",
    "type": "mechanism"
  },
  {
    "title": "Multimodal Media Channel Establishment",
    "description": "Signaling protocol requirements for setting up dedicated channels for different media types. Defines the control plane for multimodal agent communication.",
    "type": "requirement"
  },
  {
    "title": "Agent-to-Agent Multimodal Protocol",
    "description": "Specialized protocol architecture enabling autonomous agents to handle mixed media communications. Extends traditional agent protocols to support rich multimedia interactions.",
    "type": "protocol"
  }
]


draft_name: draft-yan-a2a-device-agent-applicability
prompt_hash: a3706bcf8a764b7a
model: claude-sonnet-4-20250514
created_at: 2026-02-28T11:25:10.723106+00:00
request_json:
Extract discrete technical ideas and mechanisms from this IETF draft.
Return a JSON array. Each element: {"title":"short name","description":"1-2 sentences","type":"mechanism|protocol|pattern|requirement|architecture|extension"}

draft-yan-a2a-device-agent-applicability | Applicability of A2A Protocol for Network Management Agents | 19pg
Abstract: The evolution of network management towards autonomic operation
   requires the deployment of AI agents at various hierarchical layers,
   including directly on network elements.  This transformation shifts
   network devices from passively managed resources to autonomous
   entities capable of local decision-making and collaborative problem-
   solving.

   This document discusses the applicability of the Agent-to-Agent (A2A)
   Protocol to the network management plane, specifically for
   communication between Controller Agents (CAs) and Device Agents
   (DAs).  This indicates that the inherent characteristics of Device
   Agents necessitate the adoption of the agent-to-agent communication
   paradigm.  The document further explores generic workflows,
   deployment scenarios, and the relationship of A2A with existing
   network management protocols like NETCONF, RESTCONF, gNMI,and the
   Model Context Protocol (MCP).





Network Working Group                                             J. Yan
Internet-Draft                                                  X. Zhang
Intended status: Informational                                       ZTE
Expires: 15 August 2026                                 11 February 2026


      Applicability of A2A Protocol for Network Management Agents
              draft-yan-a2a-device-agent-applicability-01

Abstract

   The evolution of network management towards autonomic operation
   requires the deployment of AI agents at various hierarchical layers,
   including directly on network elements.  This transformation shifts
   network devices from passively managed resources to autonomous
   entities capable of local decision-making and collaborative problem-
   solving.

   This document discusses the applicability of the Agent-to-Agent (A2A)
   Protocol to the network management plane, specifically for
   communication between Controller Agents (CAs) and Device Agents
   (DAs).  This indicates that the inherent characteristics of Device
   Agents necessitate the adoption of the agent-to-agent communication
   paradigm.  The document further explores generic workflows,
   deployment scenarios, and the relationship of A2A with existing
   network management protocols like NETCONF, RESTCONF, gNMI,and the
   Model Context Protocol (MCP).

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 15 August 2026.







Yan & Zhang              Expires 15 August 2026                 [Page 1]

Internet-Draft  Applicability of A2A Protocol for Networ   February 2026


Copyright Notice

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

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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . .

Return 3-8 ideas. Focus on CONCRETE technical contributions, not general statements.
JSON array only, no fences.

response_json:
[
  {
    "title": "Agent-to-Agent (A2A) Protocol for Network Management",
    "description": "A communication protocol specifically designed for interactions between Controller Agents (CAs) and Device Agents (DAs) in network management scenarios. This protocol enables AI agents deployed at different hierarchical layers to communicate and collaborate effectively.",
    "type": "protocol"
  },
  {
    "title": "Controller Agent (CA) and Device Agent (DA) Architecture",
    "description": "A hierarchical agent architecture where Controller Agents manage and coordinate with Device Agents deployed directly on network elements. This transforms network devices from passive resources to autonomous entities capable of local decision-making.",
    "type": "architecture"
  },
  {
    "title": "Autonomic Network Device Operation",
    "description": "A mechanism that shifts network devices from passively managed resources to autonomous entities capable of local decision-making and collaborative problem-solving. This enables devices to operate independently while participating in coordinated network management.",
    "type": "mechanism"
  },
  {
    "title": "A2A Integration with Existing Management Protocols",
    "description": "A pattern for integrating A2A protocol with established network management protocols including NETCONF, RESTCONF, gNMI, and Model Context Protocol (MCP). This provides interoperability between agent-based and traditional management approaches.",
    "type": "pattern"
  },
  {
    "title": "Hierarchical AI Agent Deployment",
    "description": "An architectural pattern for deploying AI agents at various hierarchical layers within network infrastructure, including direct deployment on network elements. This enables distributed intelligence and autonomous operation across the network stack.",
    "type": "architecture"
  }
]


draft_name: draft-yang-dmsc-ioa-task-protocol
prompt_hash: b50c46ae651f4b59
model: claude-sonnet-4-20250514
created_at: 2026-02-28T11:25:16.559678+00:00
request_json:
Extract discrete technical ideas and mechanisms from this IETF draft.
Return a JSON array. Each element: {"title":"short name","description":"1-2 sentences","type":"mechanism|protocol|pattern|requirement|architecture|extension"}

draft-yang-dmsc-ioa-task-protocol | Internet of Agents Task Protocol (IoA Task Protocol) for Heterogeneous Agent Collaboration | 14pg
Abstract: This draft defines a new agent collaboration protocol, named the
   Internet of Agents Task Protocol (IoA Task Protocol), to support
   distributed, heterogeneous agent collaboration in intelligent
   systems.  The IoA Task Protocol enables dynamic team formation,
   adaptive task coordination, and structured communication among agents
   with diverse architectures, tools, and knowledge sources.  Through a
   layered architecture and extensible message format, it supports
   decentralized deployment across devices and can interoperate with
   existing frameworks.  The protocol is particularly suited to large-
   scale intelligent collaboration scenarios—such as intelligent
   transportation, smart healthcare, and large-scale human–AI
   teaming—across heterogeneous network environments, including fixed
   networks, edge–cloud infrastructures, and emerging mobile networks
   such as 6G.





Dispatch Working Group                                           C. Yang
Internet-Draft        Beijing University of Posts and Telecommunications
Intended status: Standards Track                                  Z. Liu
Expires: 1 August 2026                               Tsinghua University
                                                                 A. Wang
                                                           China Telecom
                                                         28 January 2026


 Internet of Agents Task Protocol (IoA Task Protocol) for Heterogeneous
                          Agent Collaboration
                  draft-yang-dmsc-ioa-task-protocol-02

Abstract

   This draft defines a new agent collaboration protocol, named the
   Internet of Agents Task Protocol (IoA Task Protocol), to support
   distributed, heterogeneous agent collaboration in intelligent
   systems.  The IoA Task Protocol enables dynamic team formation,
   adaptive task coordination, and structured communication among agents
   with diverse architectures, tools, and knowledge sources.  Through a
   layered architecture and extensible message format, it supports
   decentralized deployment across devices and can interoperate with
   existing frameworks.  The protocol is particularly suited to large-
   scale intelligent collaboration scenarios—such as intelligent
   transportation, smart healthcare, and large-scale human–AI
   teaming—across heterogeneous network environments, including fixed
   networks, edge–cloud infrastructures, and emerging mobile networks
   such as 6G.

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 1 August 2026.





Yang, et al.              Expires 1 August 2026                 [Page 1]

Internet-Draft              IoA Task Protocol               January 2026


Copyright Notice

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

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

Return 3-8 ideas. Focus on CONCRETE technical contributions, not general statements.
JSON array only, no fences.

response_json:
[
  {
    "title": "IoA Task Protocol",
    "description": "A new agent collaboration protocol enabling distributed, heterogeneous agent collaboration in intelligent systems. Supports dynamic team formation, adaptive task coordination, and structured communication among agents with diverse architectures.",
    "type": "protocol"
  },
  {
    "title": "Dynamic Team Formation",
    "description": "A mechanism that allows agents to automatically form collaborative teams based on task requirements and agent capabilities. Enables flexible reconfiguration of agent groups as tasks evolve.",
    "type": "mechanism"
  },
  {
    "title": "Adaptive Task Coordination",
    "description": "A coordination system that adjusts task allocation and execution strategies based on agent performance and changing conditions. Provides real-time adaptation of collaborative workflows.",
    "type": "mechanism"
  },
  {
    "title": "Layered Architecture for Agent Collaboration",
    "description": "A structured architectural approach that separates different aspects of agent collaboration into distinct layers. Enables modular design and easier integration with existing frameworks.",
    "type": "architecture"
  },
  {
    "title": "Extensible Message Format",
    "description": "A flexible message structure that can accommodate different types of agent communication needs and future extensions. Supports interoperability between heterogeneous agent systems.",
    "type": "extension"
  }
]


draft_name: draft-yang-ioa-protocol
prompt_hash: 9711a9b9f97df874
model: claude-sonnet-4-20250514
created_at: 2026-02-28T11:25:23.733370+00:00
request_json:
Extract discrete technical ideas and mechanisms from this IETF draft.
Return a JSON array. Each element: {"title":"short name","description":"1-2 sentences","type":"mechanism|protocol|pattern|requirement|architecture|extension"}

draft-yang-ioa-protocol | Internet of Agents Protocol (IoA Protocol) for Heterogeneous Agent Collaboration | 13pg
Abstract: This draft defines a new agent collaboration protocol, named the
   Internet of Agents Protocol (IoA Protocol), to support distributed,
   heterogeneous agent collaboration in intelligent systems.  The IoA
   Protocol enables dynamic team formation, adaptive task coordination,
   and structured communication among agents with diverse architectures,
   tools, and knowledge sources.  Through a layered architecture and
   extensible message format, it supports decentralized deployment
   across devices and can interoperate with existing frameworks.  The
   protocol is particularly suited to emerging 6G application scenarios
   such as intelligent transportation, smart healthcare, and large-scale
   human–AI teaming.





Dispatch Working Group                                           C. Yang
Internet-Draft        Beijing University of Posts and Telecommunications
Intended status: Standards Track                                  Z. Liu
Expires: 21 January 2026                             Tsinghua University
                                                                 A. Wang
                                                           China Telecom
                                                            20 July 2025


   Internet of Agents Protocol (IoA Protocol) for Heterogeneous Agent
                             Collaboration
                       draft-yang-ioa-protocol-00

Abstract

   This draft defines a new agent collaboration protocol, named the
   Internet of Agents Protocol (IoA Protocol), to support distributed,
   heterogeneous agent collaboration in intelligent systems.  The IoA
   Protocol enables dynamic team formation, adaptive task coordination,
   and structured communication among agents with diverse architectures,
   tools, and knowledge sources.  Through a layered architecture and
   extensible message format, it supports decentralized deployment
   across devices and can interoperate with existing frameworks.  The
   protocol is particularly suited to emerging 6G application scenarios
   such as intelligent transportation, smart healthcare, and large-scale
   human–AI teaming.

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 21 January 2026.

Copyright Notice

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



Yang, et al.             Expires 21 January 2026                [Page 1]

Internet-Draft                IoA Protocol                     July 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

   

Return 3-8 ideas. Focus on CONCRETE technical contributions, not general statements.
JSON array only, no fences.

response_json:
[
  {
    "title": "Layered IoA Architecture",
    "description": "Multi-layer protocol architecture separating agent discovery, team formation, task coordination, and communication concerns. Enables modular implementation and interoperability across heterogeneous agent systems.",
    "type": "architecture"
  },
  {
    "title": "Dynamic Team Formation",
    "description": "Mechanism for agents to autonomously discover and form collaborative teams based on capabilities and task requirements. Supports runtime reconfiguration as agent availability and task needs change.",
    "type": "mechanism"
  },
  {
    "title": "Adaptive Task Coordination",
    "description": "Protocol for distributing and coordinating tasks among heterogeneous agents with different architectures, tools, and knowledge sources. Handles task decomposition, assignment, and progress synchronization.",
    "type": "mechanism"
  },
  {
    "title": "Extensible Message Format",
    "description": "Structured communication format that accommodates diverse agent types and capabilities while maintaining protocol compatibility. Allows custom extensions for specific agent architectures or domains.",
    "type": "protocol"
  },
  {
    "title": "Decentralized Deployment Pattern",
    "description": "Architecture pattern enabling agent collaboration across distributed devices without requiring centralized coordination infrastructure. Supports peer-to-peer agent interactions and fault tolerance.",
    "type": "pattern"
  }
]


draft_name: draft-yao-agent-auth-considerations
prompt_hash: a1e17e982690ac0f
model: claude-sonnet-4-20250514
created_at: 2026-02-28T11:25:29.675805+00:00
request_json:
Extract discrete technical ideas and mechanisms from this IETF draft.
Return a JSON array. Each element: {"title":"short name","description":"1-2 sentences","type":"mechanism|protocol|pattern|requirement|architecture|extension"}

draft-yao-agent-auth-considerations | Further considerations on AI Agent Authentication and Authorization Based on OAuth Extension | 15pg
Abstract: Agent Communication Network(ACN) is becoming a promising and
   fundamental infrastructure for most vertical industries.  To
   construct and build a scalable and trustable ACN, authentication and
   authorization of AI agents are critical requirements.  This document
   extends the model of OAuth and proposes new workflows for AI agent
   authentication and authorization.





Network Working Group                                             K. Yao
Internet-Draft                                              China Mobile
Intended status: Informational                           20 October 2025
Expires: 23 April 2026


  Further considerations on AI Agent Authentication and Authorization
                        Based on OAuth Extension
                 draft-yao-agent-auth-considerations-01

Abstract

   Agent Communication Network(ACN) is becoming a promising and
   fundamental infrastructure for most vertical industries.  To
   construct and build a scalable and trustable ACN, authentication and
   authorization of AI agents are critical requirements.  This document
   extends the model of OAuth and proposes new workflows for AI agent
   authentication and authorization.

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.











Yao                       Expires 23 April 2026                 [Page 1]

Internet-Draft            Agent AuthN and AuthZ             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.  Definition of Terms . . . . . . . . . . . . . . . . . . . . .   3
   3.  Aauth: Agent OBO Its User(s)  . . . . . . . . . . . . . . . .   4
     3.1.  Example Case  . . . . . . . . . . . . . . . . . . . . . .   4
     3.2.  Model . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.3.  Workflow  . . . . . . . . . . . . . . . . . . . . . . . .   6
   4.  Aauth: Agent OBO Itself . . . . . . . . . . . . . . . . . . .   7
     4.1.  Example Case  . . . . . . . . . . . . . . . . . . . . . .   8
     4.2.  Model 

Return 3-8 ideas. Focus on CONCRETE technical contributions, not general statements.
JSON array only, no fences.

response_json:
[
  {
    "title": "Agent Communication Network (ACN)",
    "description": "A fundamental infrastructure network designed to enable communication between AI agents across vertical industries. Requires scalable authentication and authorization mechanisms for trustable operations.",
    "type": "architecture"
  },
  {
    "title": "OAuth Extension for AI Agents",
    "description": "Extension of the OAuth authorization framework specifically adapted for AI agent authentication and authorization workflows. Provides the foundation for agent-specific security patterns.",
    "type": "extension"
  },
  {
    "title": "Agent On-Behalf-Of (OBO) User Authentication",
    "description": "Authentication mechanism where an AI agent acts on behalf of one or more users, requiring delegation of user credentials and permissions. Includes specific workflow for user-to-agent authorization.",
    "type": "mechanism"
  },
  {
    "title": "Agent Self-Authentication",
    "description": "Authentication pattern where an AI agent authenticates and authorizes itself independently, without acting on behalf of users. Enables autonomous agent operations with self-managed credentials.",
    "type": "mechanism"
  }
]


draft_name: draft-ye-problems-and-requirements-of-dns-for-ioa
prompt_hash: 988265747eef235f
model: claude-sonnet-4-20250514
created_at: 2026-02-28T11:25:36.235349+00:00
request_json:
Extract discrete technical ideas and mechanisms from this IETF draft.
Return a JSON array. Each element: {"title":"short name","description":"1-2 sentences","type":"mechanism|protocol|pattern|requirement|architecture|extension"}

draft-ye-problems-and-requirements-of-dns-for-ioa | Problems Statement and Requirements Analysis of DNS for Internet of Agents (IoA) | 10pg
Abstract: In the AI-driven era, DNS is supposed to evolve with technological
   advancements to accommodate the complex and diverse requirements of
   the IoA.  This draft analyzes the issues surrounding DNS in
   supporting agents collaboration and explores corresponding technical
   requirements.





DNSOP                                                              J. Ye
Internet-Draft                                                  W. Cheng
Intended status: Informational                              China Mobile
Expires: 6 May 2026                                                D. Ma
                                                                    ZDNS
                                                         2 November 2025


  Problems Statement and Requirements Analysis of DNS for Internet of
                              Agents (IoA)
          draft-ye-problems-and-requirements-of-dns-for-ioa-01

Abstract

   In the AI-driven era, DNS is supposed to evolve with technological
   advancements to accommodate the complex and diverse requirements of
   the IoA.  This draft analyzes the issues surrounding DNS in
   supporting agents collaboration and explores corresponding technical
   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.










Ye, et al.                 Expires 6 May 2026                   [Page 1]

Internet-Draft  Problems and Requirements of DNS 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
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Requirements Language . . . . . . . . . . . . . . . . . .   4
   2.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Identifiers Reconstruction  . . . . . . . . . . . . . . .   4
     2.2.  Proliferating AI Agents . . . . . . . . . . . . . . . . .   4
     2.3.  High-density and Parallel Interaction . . . .

Return 3-8 ideas. Focus on CONCRETE technical contributions, not general statements.
JSON array only, no fences.

response_json:
[
  {
    "title": "Agent Identifier Reconstruction",
    "description": "A mechanism to restructure and manage identifiers specifically for AI agents in IoA environments. This addresses the need for DNS to handle non-traditional naming schemes for autonomous agents.",
    "type": "mechanism"
  },
  {
    "title": "High-density Parallel Interaction Support",
    "description": "DNS architectural changes to support massive concurrent queries from multiple AI agents collaborating simultaneously. This requires enhanced query processing and response capabilities.",
    "type": "architecture"
  },
  {
    "title": "Agent Collaboration Discovery",
    "description": "A DNS-based service discovery pattern that enables AI agents to find and connect with other agents for collaborative tasks. This extends traditional service discovery for agent-to-agent communication.",
    "type": "pattern"
  },
  {
    "title": "IoA-specific DNS Requirements",
    "description": "Technical requirements for DNS systems to accommodate the complex and diverse needs of Internet of Agents deployments. This includes scalability, latency, and naming convention requirements.",
    "type": "requirement"
  }
]


draft_name: draft-yl-agent-id-requirements
prompt_hash: ab760495d55996e7
model: claude-sonnet-4-20250514
created_at: 2026-02-28T11:25:42.476286+00:00
request_json:
Extract discrete technical ideas and mechanisms from this IETF draft.
Return a JSON array. Each element: {"title":"short name","description":"1-2 sentences","type":"mechanism|protocol|pattern|requirement|architecture|extension"}

draft-yl-agent-id-requirements | Digital Identity Management for AI Agent Communication Protocols | 9pg
Abstract: AI agents are rapidly and massively transitioning from cutting-edge
   technology into real life.  The AI agent communication protocol will
   establishing a critical means to connect agents with different users,
   tools, and other agents.  Among all the features of AI agent
   communication protocol, digital identity is one of the most important
   components.  Developing a cross-industry, universal, flexible,
   interoperable, and secure AI agent digital identity protocol is the
   foundation for achieving communication between agents and other
   entities in future network.





Network Working Group                                             K. Yao
Internet-Draft                                                    P. Liu
Intended status: Informational                              China Mobile
Expires: 2 January 2026                                      1 July 2025


    Digital Identity Management for AI Agent Communication Protocols
                   draft-yl-agent-id-requirements-00

Abstract

   AI agents are rapidly and massively transitioning from cutting-edge
   technology into real life.  The AI agent communication protocol will
   establishing a critical means to connect agents with different users,
   tools, and other agents.  Among all the features of AI agent
   communication protocol, digital identity is one of the most important
   components.  Developing a cross-industry, universal, flexible,
   interoperable, and secure AI agent digital identity protocol is the
   foundation for achieving communication between agents and other
   entities in future network.

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 2 January 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



Yao & Liu                Expires 2 January 2026                 [Page 1]

Internet-Draft     Agent Digital Identity Requirements         July 2025


   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.  Digital Identity Management Related Use Cases in the Context of
           AI Agent Communications . . . . . . . . . . . . . . . . .   3
     2.1.  General . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.2.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Potential Digital Identity Mana

Return 3-8 ideas. Focus on CONCRETE technical contributions, not general statements.
JSON array only, no fences.

response_json:
[
  {
    "title": "AI Agent Digital Identity Protocol",
    "description": "A cross-industry, universal, flexible, interoperable, and secure digital identity protocol specifically designed for AI agents. This protocol serves as the foundation for agent-to-agent, agent-to-user, and agent-to-tool communications.",
    "type": "protocol"
  },
  {
    "title": "AI Agent Communication Protocol",
    "description": "A communication protocol that establishes the critical means to connect AI agents with different users, tools, and other agents. Digital identity management is identified as one of its most important components.",
    "type": "protocol"
  },
  {
    "title": "Multi-Entity Agent Communication Architecture",
    "description": "An architecture that enables communication between AI agents and various types of entities including other agents, human users, and software tools. This requires a unified identity management approach across different entity types.",
    "type": "architecture"
  },
  {
    "title": "Cross-Industry Agent Identity Interoperability",
    "description": "A requirement for AI agent digital identity systems to work across different industries and platforms. This ensures agents can communicate and authenticate regardless of their originating system or domain.",
    "type": "requirement"
  }
]


draft_name: draft-yu-ai-agent-use-cases-in-6g
prompt_hash: df1a10e943a6e7dc
model: claude-sonnet-4-20250514
created_at: 2026-02-28T11:25:50.356985+00:00
request_json:
Extract discrete technical ideas and mechanisms from this IETF draft.
Return a JSON array. Each element: {"title":"short name","description":"1-2 sentences","type":"mechanism|protocol|pattern|requirement|architecture|extension"}

draft-yu-ai-agent-use-cases-in-6g | AI Agent Use Cases and Requirements in 6G Network | 15pg
Abstract: This draft introduces use cases related to AI Agents in 6G networks,
   primarily referencing the technical report of 3GPP SA1 R20 Study on
   6G Use Cases and Service Requirements (TR 22.870).  It also
   elaborates on some of the requirements for introducing AI Agents into
   6G networks from the perspective of operators.





Network Working Group                                              M. Yu
Internet-Draft                                                   A. Wang
Intended status: Informational                                     J. Li
Expires: 9 July 2026                                               Z. Li
                                                           China Telecom
                                                          5 January 2026


           AI Agent Use Cases and Requirements in 6G Network
                  draft-yu-ai-agent-use-cases-in-6g-02

Abstract

   This draft introduces use cases related to AI Agents in 6G networks,
   primarily referencing the technical report of 3GPP SA1 R20 Study on
   6G Use Cases and Service Requirements (TR 22.870).  It also
   elaborates on some of the requirements for introducing AI Agents into
   6G networks from the perspective of operators.

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 9 July 2026.

Copyright Notice

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











Yu, et al.                 Expires 9 July 2026                  [Page 1]

Internet-Draft  AI Agent Use Cases and Requirements in 6    January 2026


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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Intent-based 6G Services Enabled by Network AI Agents . .   4
       2.1.1.  Use Case On 6G Network Providing On-demand Networking
               with AI Agent . . . . . . . . . . . . . . . . . . . .   4
       2.1.2.  Use Case On Intelligent Calling Services  . . . . . .   5
       2.1.3.  Use Case On Disaster Rescue Planning Enabled By Network
           

Return 3-8 ideas. Focus on CONCRETE technical contributions, not general statements.
JSON array only, no fences.

response_json:
[
  {
    "title": "Intent-based 6G Services with Network AI Agents",
    "description": "AI agents embedded in 6G networks that can interpret user intents and automatically configure network services accordingly. These agents translate high-level user requirements into specific network configurations and service provisioning.",
    "type": "mechanism"
  },
  {
    "title": "On-demand Networking with AI Agent",
    "description": "A system where AI agents dynamically provision and configure network resources based on real-time demand patterns. The agents can automatically scale network capacity and adjust routing to meet changing service requirements.",
    "type": "pattern"
  },
  {
    "title": "Intelligent Calling Services",
    "description": "AI-enhanced voice and communication services that can understand context, preferences, and optimize call routing and quality. These services leverage AI agents to provide personalized communication experiences.",
    "type": "extension"
  },
  {
    "title": "Disaster Rescue Planning Network AI Agent",
    "description": "Specialized AI agents that can rapidly reconfigure network infrastructure and services during emergency situations. They coordinate rescue operations by optimizing communication channels and resource allocation.",
    "type": "mechanism"
  },
  {
    "title": "6G Network AI Agent Requirements Framework",
    "description": "A comprehensive set of technical and operational requirements for deploying AI agents in 6G networks from an operator perspective. This includes performance, security, and interoperability specifications.",
    "type": "requirement"
  }
]


draft_name: draft-yu-dmsc-ai-agent-use-cases-in-6g
prompt_hash: 0a1b6c159e3d8fa0
model: claude-sonnet-4-20250514
created_at: 2026-02-28T11:25:58.241663+00:00
request_json:
Extract discrete technical ideas and mechanisms from this IETF draft.
Return a JSON array. Each element: {"title":"short name","description":"1-2 sentences","type":"mechanism|protocol|pattern|requirement|architecture|extension"}

draft-yu-dmsc-ai-agent-use-cases-in-6g | AI Agent Use Cases and Requirements in 6G Network | 10pg
Abstract: This draft introduces use cases related to AI Agents in 6G networks,
   primarily referencing the technical report of 3GPP SA1 R20 Study on
   6G Use Cases and Service Requirements (TR 22.870).  It also
   elaborates on some of the requirements for introducing AI Agents into
   6G networks from the perspective of operators.





Network Working Group                                              M. Yu
Internet-Draft                                                   A. Wang
Intended status: Informational                                     J. Li
Expires: 16 July 2026                                              Z. Li
                                                           China Telecom
                                                         12 January 2026


           AI Agent Use Cases and Requirements in 6G Network
               draft-yu-dmsc-ai-agent-use-cases-in-6g-01

Abstract

   This draft introduces use cases related to AI Agents in 6G networks,
   primarily referencing the technical report of 3GPP SA1 R20 Study on
   6G Use Cases and Service Requirements (TR 22.870).  It also
   elaborates on some of the requirements for introducing AI Agents into
   6G networks from the perspective of operators.

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 16 July 2026.

Copyright Notice

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











Yu, et al.                Expires 16 July 2026                  [Page 1]

Internet-Draft  AI Agent Use Cases and Requirements in 6    January 2026


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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Intent-based 6G Services Enabled by Network AI Agents . .   4
     2.2.  Device-Network Collaboration  . . . . . . . . . . . . . .   5
     2.3.  Multiple Devices Collaboration  . . . . . . . . . . . . .   5
     2.4.  Network-Application Collaboration . . . . . . . . . . . .   6
   3.  Potential Requirements for 6G Network . . . . . . . . . . . .   7
  

Return 3-8 ideas. Focus on CONCRETE technical contributions, not general statements.
JSON array only, no fences.

response_json:
[
  {
    "title": "Intent-based 6G Service Provisioning",
    "description": "Network AI agents interpret user intent expressed in natural language to automatically configure and provision 6G network services. The system translates high-level user requirements into specific network configurations without manual intervention.",
    "type": "mechanism"
  },
  {
    "title": "Device-Network AI Agent Collaboration",
    "description": "Coordinated interaction between AI agents running on user devices and network-side AI agents to optimize service delivery. This enables distributed intelligence across the device-network boundary for enhanced performance.",
    "type": "architecture"
  },
  {
    "title": "Multi-Device AI Agent Coordination",
    "description": "AI agents deployed across multiple user devices collaborate to achieve common objectives or shared tasks. This pattern enables coordinated behavior and resource sharing among distributed devices in 6G networks.",
    "type": "pattern"
  },
  {
    "title": "Network-Application AI Agent Interface",
    "description": "Standardized collaboration mechanism between network-resident AI agents and application-layer AI agents. This enables applications to leverage network intelligence while allowing the network to optimize based on application requirements.",
    "type": "protocol"
  },
  {
    "title": "AI Agent Service Requirements Framework",
    "description": "Technical requirements specification for integrating AI agents into 6G network infrastructure from operator perspective. Defines performance, security, and operational constraints for AI agent deployment.",
    "type": "requirement"
  }
]


draft_name: draft-yuan-rtgwg-security-agent-usecase
prompt_hash: 00edeb28b9095c31
model: claude-sonnet-4-20250514
created_at: 2026-02-28T11:26:06.742751+00:00
request_json:
Extract discrete technical ideas and mechanisms from this IETF draft.
Return a JSON array. Each element: {"title":"short name","description":"1-2 sentences","type":"mechanism|protocol|pattern|requirement|architecture|extension"}

draft-yuan-rtgwg-security-agent-usecase | Use cases of the AI Network Security Agent | 7pg
Abstract: Core network devices like routers fulfill dual roles of data
   forwarding and security protection.  However, escalating threats
   (e.g., zero-day vulnerabilities, DDoS attacks) expose limitations of
   traditional security—relying on static ACLs, signature-based
   detection, and manual configuration—causing delayed responses, high
   false positives, and protection gaps.  This paper proposes AI Network
   Security Agents: intelligent software components leveraging machine
   learning, behavioral analysis, and real-time data fusion, with three
   core capabilities (adaptive learning, automation, distributed
   collaboration) to shift security from passive to intelligent.  Four
   key scenarios are outlined: dynamic defense against unknown threats
   via baselines and tracing; ACL optimization via intent parsing;
   configuration security via baseline checks and simulation; and
   collaborative defense via intelligence aggregation and linked
   responses.  AI Agents turn routers into active security
   orchestrators, enhancing threat protection and operational
   efficiency.





Network Working Group                                            Q. Yuan
Internet-Draft                                                    J. Mao
Intended status: Standards Track                                  B. Liu
Expires: 5 May 2026                                              N. Geng
                                                                X. Shang
                                                                  Q. Gao
                                                                   Z. Li
                                                     Huawei Technologies
                                                         1 November 2025


               Use cases of the AI Network Security Agent
               draft-yuan-rtgwg-security-agent-usecase-00

Abstract

   Core network devices like routers fulfill dual roles of data
   forwarding and security protection.  However, escalating threats
   (e.g., zero-day vulnerabilities, DDoS attacks) expose limitations of
   traditional security—relying on static ACLs, signature-based
   detection, and manual configuration—causing delayed responses, high
   false positives, and protection gaps.  This paper proposes AI Network
   Security Agents: intelligent software components leveraging machine
   learning, behavioral analysis, and real-time data fusion, with three
   core capabilities (adaptive learning, automation, distributed
   collaboration) to shift security from passive to intelligent.  Four
   key scenarios are outlined: dynamic defense against unknown threats
   via baselines and tracing; ACL optimization via intent parsing;
   configuration security via baseline checks and simulation; and
   collaborative defense via intelligence aggregation and linked
   responses.  AI Agents turn routers into active security
   orchestrators, enhancing threat protection and operational
   efficiency.

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



Yuan, et al.               Expires 5 May 2026                   [Page 1]

Internet-Draft           Security Agent Usecase            November 2025


   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.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https:/

Return 3-8 ideas. Focus on CONCRETE technical contributions, not general statements.
JSON array only, no fences.

response_json:
[
  {
    "title": "AI Network Security Agent",
    "description": "Intelligent software components deployed on network devices that leverage machine learning, behavioral analysis, and real-time data fusion. These agents provide adaptive learning, automation, and distributed collaboration capabilities to transform passive security into intelligent active protection.",
    "type": "architecture"
  },
  {
    "title": "Dynamic Baseline-Based Threat Detection",
    "description": "Mechanism that establishes behavioral baselines for network traffic and uses deviation detection with tracing capabilities to identify unknown threats. Replaces static signature-based detection with adaptive learning approaches.",
    "type": "mechanism"
  },
  {
    "title": "AI-Driven ACL Optimization",
    "description": "System that parses security intent and automatically optimizes Access Control Lists using machine learning. Reduces manual configuration overhead and improves rule effectiveness through intelligent analysis.",
    "type": "mechanism"
  },
  {
    "title": "Configuration Security Validation",
    "description": "Framework that performs baseline checks and simulation of network configurations before deployment. Prevents misconfigurations and security gaps through automated validation processes.",
    "type": "mechanism"
  },
  {
    "title": "Collaborative Threat Intelligence",
    "description": "Distributed system where security agents aggregate threat intelligence across multiple network devices and coordinate linked defensive responses. Enables network-wide security orchestration through agent cooperation.",
    "type": "pattern"
  },
  {
    "title": "Real-Time Data Fusion Engine",
    "description": "Component that combines multiple data sources in real-time to provide comprehensive situational awareness for security decisions. Integrates traffic patterns, device telemetry, and threat indicators for enhanced detection accuracy.",
    "type": "mechanism"
  }
]


draft_name: draft-yuan-rtgwg-traffic-agent-usecase
prompt_hash: a5145306859a2ca4
model: claude-sonnet-4-20250514
created_at: 2026-02-28T11:26:13.303665+00:00
request_json:
Extract discrete technical ideas and mechanisms from this IETF draft.
Return a JSON array. Each element: {"title":"short name","description":"1-2 sentences","type":"mechanism|protocol|pattern|requirement|architecture|extension"}

draft-yuan-rtgwg-traffic-agent-usecase | Use cases of the AI Network Traffic Optimization Agent | 10pg
Abstract: This document introduces AI Network Traffic Optimization Agents as a
   dynamic alternative to traditional static network optimization
   methods.  These AI entities analyze real-time network status (e.g.,
   latency, node load) and adjust resources flexibly—deployed centrally
   or on devices—to enhance efficiency, ensure service quality, and cut
   operational costs.  It defines network traffic optimization
   (maximizing resource use, meeting QoS) and AI agents (autonomous,
   learning entities that reduce manual work), then details three key
   application scenarios: tunnel adjustment (adaptive routing,
   predictive bandwidth, fault recovery), traffic steering
   (classification, application-aware policies, pre-emptive load
   balancing), and network slice adjustment (lifecycle automation, SLA
   compliance, slice-specific fault fixes).  The document emphasizes the
   agents’ role in enabling SLA-compliant, autonomous optimization for
   complex networks.





Network Working Group                                            Q. Yuan
Internet-Draft                                                    J. Mao
Intended status: Standards Track                                  B. Liu
Expires: 5 May 2026                                              N. Geng
                                                                X. Shang
                                                                  Q. Gao
                                                                   Z. Li
                                                     Huawei Technologies
                                                         1 November 2025


         Use cases of the AI Network Traffic Optimization Agent
               draft-yuan-rtgwg-traffic-agent-usecase-00

Abstract

   This document introduces AI Network Traffic Optimization Agents as a
   dynamic alternative to traditional static network optimization
   methods.  These AI entities analyze real-time network status (e.g.,
   latency, node load) and adjust resources flexibly—deployed centrally
   or on devices—to enhance efficiency, ensure service quality, and cut
   operational costs.  It defines network traffic optimization
   (maximizing resource use, meeting QoS) and AI agents (autonomous,
   learning entities that reduce manual work), then details three key
   application scenarios: tunnel adjustment (adaptive routing,
   predictive bandwidth, fault recovery), traffic steering
   (classification, application-aware policies, pre-emptive load
   balancing), and network slice adjustment (lifecycle automation, SLA
   compliance, slice-specific fault fixes).  The document emphasizes the
   agents’ role in enabling SLA-compliant, autonomous optimization for
   complex networks.

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.



Yuan, et al.               Expires 5 May 2026                   [Page 1]

Internet-Draft            Traffic Agent Usecase            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

Return 3-8 ideas. Focus on CONCRETE technical contributions, not general statements.
JSON array only, no fences.

response_json:
[
  {
    "title": "AI Network Traffic Optimization Agent",
    "description": "Autonomous AI entities that analyze real-time network status (latency, node load) and dynamically adjust network resources. These agents can be deployed centrally or distributed on network devices to replace static optimization methods.",
    "type": "architecture"
  },
  {
    "title": "Adaptive Tunnel Adjustment",
    "description": "AI-driven mechanism for dynamic routing path optimization, predictive bandwidth allocation, and automated fault recovery in network tunnels. Enables real-time adaptation based on network conditions.",
    "type": "mechanism"
  },
  {
    "title": "AI-Based Traffic Steering",
    "description": "Intelligent traffic classification and application-aware policy enforcement with pre-emptive load balancing capabilities. Uses AI to optimize traffic flow distribution across network paths.",
    "type": "mechanism"
  },
  {
    "title": "Autonomous Network Slice Management",
    "description": "AI agent-controlled network slice lifecycle automation including SLA compliance monitoring and slice-specific fault remediation. Provides automated management of network slicing resources.",
    "type": "mechanism"
  },
  {
    "title": "Real-time Network Status Analysis",
    "description": "Continuous monitoring and analysis of network metrics such as latency, node load, and resource utilization. Forms the data foundation for AI-driven optimization decisions.",
    "type": "pattern"
  }
]


draft_name: draft-yue-anima-agent-recovery-networks
prompt_hash: ea18d9c1dcc39c57
model: claude-sonnet-4-20250514
created_at: 2026-02-28T11:26:21.381544+00:00
request_json:
Extract discrete technical ideas and mechanisms from this IETF draft.
Return a JSON array. Each element: {"title":"short name","description":"1-2 sentences","type":"mechanism|protocol|pattern|requirement|architecture|extension"}

draft-yue-anima-agent-recovery-networks | Task-Oriented Multi-Agent Recovery Framework for High-Reliability in Converged Mobile Networks | 11pg
Abstract: This document defines a task-oriented, agent-based method for fault
   recovery in converged public-private mobile networks.  The proposed
   method introduces a multi-agent collaboration framework that enables
   autonomous failure detection, scoped diagnosis, inter-domain
   coordination, and intent-driven policy reconfiguration.  It is
   particularly applicable in complex 5G/6G network deployments, such as
   Multi-Operator Core Networks (MOCN) and Standalone Non-Public
   Networks (SNPN), where traditional centralized management is
   insufficient for ensuring high service reliability and dynamic
   recovery.  The document also specifies protocol requirements for
   inter-agent communication, state consistency, and secure
   coordination, aiming to support interoperability and resilience
   across heterogeneous network domains.





anima                                                        Y. Yue, Ed.
Internet-Draft                                             X. Zhang, Ed.
Intended status: Standards Track                            China Unicom
Expires: 5 February 2026                                   4 August 2025


  Task-Oriented Multi-Agent Recovery Framework for High-Reliability in
                       Converged Mobile Networks
               draft-yue-anima-agent-recovery-networks-00

Abstract

   This document defines a task-oriented, agent-based method for fault
   recovery in converged public-private mobile networks.  The proposed
   method introduces a multi-agent collaboration framework that enables
   autonomous failure detection, scoped diagnosis, inter-domain
   coordination, and intent-driven policy reconfiguration.  It is
   particularly applicable in complex 5G/6G network deployments, such as
   Multi-Operator Core Networks (MOCN) and Standalone Non-Public
   Networks (SNPN), where traditional centralized management is
   insufficient for ensuring high service reliability and dynamic
   recovery.  The document also specifies protocol requirements for
   inter-agent communication, state consistency, and secure
   coordination, aiming to support interoperability and resilience
   across heterogeneous network domains.

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 February 2026.

Copyright Notice

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




Yue & Zhang              Expires 5 February 2026                [Page 1]

Internet-Draft  Task-Oriented Multi-Agent Recovery Frame     August 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  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conv

Return 3-8 ideas. Focus on CONCRETE technical contributions, not general statements.
JSON array only, no fences.

response_json:
[
  {
    "title": "Task-Oriented Multi-Agent Recovery Framework",
    "description": "A collaborative framework where multiple agents work together to perform autonomous failure detection, scoped diagnosis, and recovery coordination. Each agent is assigned specific tasks within the overall recovery process.",
    "type": "architecture"
  },
  {
    "title": "Inter-Domain Coordination Mechanism",
    "description": "A coordination system that enables agents to work across different network domains, particularly for MOCN and SNPN deployments. Supports heterogeneous network domain interoperability.",
    "type": "mechanism"
  },
  {
    "title": "Intent-Driven Policy Reconfiguration",
    "description": "A policy management approach that uses high-level intent specifications to drive automatic network reconfiguration during fault recovery. Translates recovery objectives into actionable configuration changes.",
    "type": "mechanism"
  },
  {
    "title": "Inter-Agent Communication Protocol Requirements",
    "description": "Protocol specifications defining how agents communicate with each other during recovery operations. Includes requirements for message formats, coordination semantics, and interaction patterns.",
    "type": "protocol"
  },
  {
    "title": "Scoped Diagnosis System",
    "description": "A fault diagnosis mechanism that limits the scope of analysis to relevant network segments or domains. Enables focused troubleshooting rather than network-wide analysis.",
    "type": "mechanism"
  },
  {
    "title": "State Consistency Management",
    "description": "A system for maintaining consistent state information across multiple agents during recovery operations. Ensures all agents have coherent view of network status and recovery progress.",
    "type": "mechanism"
  }
]


draft_name: draft-yue-moq-transporting-sensing-data
prompt_hash: cb0eed92e1a5c6fd
model: claude-sonnet-4-20250514
created_at: 2026-02-28T11:26:28.215734+00:00
request_json:
Extract discrete technical ideas and mechanisms from this IETF draft.
Return a JSON array. Each element: {"title":"short name","description":"1-2 sentences","type":"mechanism|protocol|pattern|requirement|architecture|extension"}

draft-yue-moq-transporting-sensing-data | Challenges in Transporting Sensing Data with Media Over QUIC | 18pg
Abstract: This document proposes leveraging Media Over QUIC (MOQ) to address
   the challenges of transmitting large-scale, real-time sensing data in
   6G networks.  By building on QUIC's low-latency and multiplexing
   capabilities, MOQ offers a flexible and efficient transport mechanism
   tailored to the dynamic and high-throughput requirements of 6G
   environments.  The approach focuses on enabling protocol adaptability
   across diverse application scenarios such as autonomous driving,
   smart cities, and industrial IoT, while ensuring efficient data
   fragmentation, secure and anonymous transmission, and end-to-end QoS
   awareness.  Through information-aware endpoints and optimized data
   delivery mechanisms, this solution supports scalable, reliable, and
   intelligent sensing data distribution in next-generation wireless
   networks.  It is also available to other types of 6G System Data
   [3GPP.22.870] besides sensing data, e.g., AI data, positioning data.





moq                                                          Y. Yue, Ed.
Internet-Draft                                                F. Li, Ed.
Intended status: Standards Track                             W. Liu, Ed.
Expires: 22 April 2026                                      China Unicom
                                                            C. Yang, Ed.
                                                        A. Akhavain, Ed.
                                                           K. Zhang, Ed.
                                           Huawei Technologies Co., Ltd.
                                                          M. Jadoon, Ed.
                                                       S. Robitzsch, Ed.
                                                InterDigital Europe Ltd.
                                                         19 October 2025


      Challenges in Transporting Sensing Data with Media Over QUIC
               draft-yue-moq-transporting-sensing-data-03

Abstract

   This document proposes leveraging Media Over QUIC (MOQ) to address
   the challenges of transmitting large-scale, real-time sensing data in
   6G networks.  By building on QUIC's low-latency and multiplexing
   capabilities, MOQ offers a flexible and efficient transport mechanism
   tailored to the dynamic and high-throughput requirements of 6G
   environments.  The approach focuses on enabling protocol adaptability
   across diverse application scenarios such as autonomous driving,
   smart cities, and industrial IoT, while ensuring efficient data
   fragmentation, secure and anonymous transmission, and end-to-end QoS
   awareness.  Through information-aware endpoints and optimized data
   delivery mechanisms, this solution supports scalable, reliable, and
   intelligent sensing data distribution in next-generation wireless
   networks.  It is also available to other types of 6G System Data
   [3GPP.22.870] besides sensing data, e.g., AI data, positioning data.

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



Yue, et al.               Expires 22 April 2026                 [Page 1]

Internet-Draft   Challenges in Transporting Sensing Data    October 2025


   This Internet-Draft will expire on 22 April 2026.

Copyright Notice

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


Return 3-8 ideas. Focus on CONCRETE technical contributions, not general statements.
JSON array only, no fences.

response_json:
[
  {
    "title": "MOQ-based Sensing Data Transport",
    "description": "Leverages Media Over QUIC (MOQ) protocol to transport large-scale, real-time sensing data in 6G networks. Builds on QUIC's low-latency and multiplexing capabilities for high-throughput requirements.",
    "type": "protocol"
  },
  {
    "title": "Information-aware Endpoints",
    "description": "Endpoints that are aware of the type and characteristics of sensing data being transmitted. Enables optimized data delivery mechanisms based on data properties.",
    "type": "architecture"
  },
  {
    "title": "Sensing Data Fragmentation",
    "description": "Efficient mechanism for fragmenting large sensing data payloads for transmission over MOQ. Addresses the challenge of handling variable-size sensing data in real-time scenarios.",
    "type": "mechanism"
  },
  {
    "title": "End-to-end QoS Awareness",
    "description": "Quality of Service awareness integrated into the MOQ transport for sensing data. Ensures appropriate service levels for different types of sensing applications like autonomous driving and industrial IoT.",
    "type": "requirement"
  },
  {
    "title": "6G System Data Extension",
    "description": "Extension of the sensing data transport approach to handle other types of 6G system data including AI data and positioning data. Provides unified transport mechanism for diverse 6G data types.",
    "type": "extension"
  }
]


draft_name: draft-yusef-lamps-rfc7030-renewal-recommendation
prompt_hash: b9fcad6b11a85e05
model: claude-sonnet-4-20250514
created_at: 2026-02-28T11:26:35.721124+00:00
request_json:
Extract discrete technical ideas and mechanisms from this IETF draft.
Return a JSON array. Each element: {"title":"short name","description":"1-2 sentences","type":"mechanism|protocol|pattern|requirement|architecture|extension"}

draft-yusef-lamps-rfc7030-renewal-recommendation | Certificate Renewal Recommendations for Enrollment over Secure Transport | 7pg
Abstract: This document describes an extension to RFC7030, Enrollment over
   Secure Transport to give an indication to a end-entity device when it
   should start attempting to renew its certificates.

   Prior art is that client decides, with a typical recommmendation to
   start when the remaining lifetime of the certificate is at the 50%
   point.  As typical certificate lifetimes are reduced from years to
   fractions of a year, the 50% may be far too early, and this document
   provides a way to give alternate advice.





LAMPS Working Group                                       R. Shekh-Yusef
Internet-Draft                                                     Ciena
Intended status: Standards Track                           M. Richardson
Expires: 6 April 2026                           Sandelman Software Works
                                                            M. Ounsworth
                                                         Entrust Limited
                                                          3 October 2025


Certificate Renewal Recommendations for Enrollment over Secure Transport
          draft-yusef-lamps-rfc7030-renewal-recommendation-03

Abstract

   This document describes an extension to RFC7030, Enrollment over
   Secure Transport to give an indication to a end-entity device when it
   should start attempting to renew its certificates.

   Prior art is that client decides, with a typical recommmendation to
   start when the remaining lifetime of the certificate is at the 50%
   point.  As typical certificate lifetimes are reduced from years to
   fractions of a year, the 50% may be far too early, and this document
   provides a way to give alternate advice.

About This Document

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

   Status information for this document may be found at
   https://datatracker.ietf.org/doc/draft-yusef-lamps-rfc7030-renewal-
   recommendation/.

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

   Source for this draft and an issue tracker can be found at
   https://github.com/mcr/rfc7030-renewal-recommendation.

Status of This Memo

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







Shekh-Yusef, et al.       Expires 6 April 2026                  [Page 1]

Internet-Draft                  est-renew                   October 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 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.
   Pl

Return 3-8 ideas. Focus on CONCRETE technical contributions, not general statements.
JSON array only, no fences.

response_json:
[
  {
    "title": "EST Certificate Renewal Timing Extension",
    "description": "An extension to RFC7030 Enrollment over Secure Transport that allows the CA to provide specific renewal timing recommendations to end-entity devices. Replaces the typical 50% certificate lifetime rule with CA-provided guidance.",
    "type": "extension"
  },
  {
    "title": "Dynamic Renewal Window Calculation",
    "description": "A mechanism for CAs to calculate and communicate optimal certificate renewal timing based on actual certificate lifetimes rather than fixed percentage rules. Addresses the problem where 50% renewal timing becomes impractical as certificate lifetimes decrease from years to fractions of years.",
    "type": "mechanism"
  },
  {
    "title": "CA-Directed Renewal Advisory Protocol",
    "description": "A protocol pattern where the Certificate Authority provides renewal timing advice to clients during the enrollment process. Shifts renewal decision-making from client-side heuristics to server-side policy.",
    "type": "protocol"
  },
  {
    "title": "Short-Lived Certificate Renewal Optimization",
    "description": "An architectural approach to handle renewal timing for certificates with lifetimes measured in fractions of years rather than full years. Addresses scalability and timing issues in modern PKI deployments with frequent certificate rotation.",
    "type": "architecture"
  }
]


draft_name: draft-zeng-mcp-troubleshooting
prompt_hash: f08bf9a1655f6cc5
model: claude-sonnet-4-20250514
created_at: 2026-02-28T11:26:43.405100+00:00
request_json:
Extract discrete technical ideas and mechanisms from this IETF draft.
Return a JSON array. Each element: {"title":"short name","description":"1-2 sentences","type":"mechanism|protocol|pattern|requirement|architecture|extension"}

draft-zeng-mcp-troubleshooting | Using the Model Context Protocol (MCP) for Intent-Based Network Troubleshooting Automation | 10pg
Abstract: The Model Context Protocol (MCP) is an open standard that enables
   Large Language Model (LLM) applications to seamlessly integrate with
   external data sources and tools by exposing Resources, Prompts and
   Tools in a JSON-RPC 2.0 transport.  This document describes a mapping
   of MCP roles, primitives and security model to the network management
   domain so that network devices act as MCP servers and network
   controllers act as MCP clients.  The goal is to provide an intent-
   based, conversational and secure approach for automated network
   troubleshooting, configuration validation, and closed-loop
   remediation without inventing new protocols or device agents.





Network Working Group                                            G. Zeng
Internet-Draft                                                    J. Mao
Intended status: Informational                                    Huawei
Expires: 23 April 2026                                   20 October 2025


    Using the Model Context Protocol (MCP) for Intent-Based Network
                       Troubleshooting Automation
                   draft-zeng-mcp-troubleshooting-00

Abstract

   The Model Context Protocol (MCP) is an open standard that enables
   Large Language Model (LLM) applications to seamlessly integrate with
   external data sources and tools by exposing Resources, Prompts and
   Tools in a JSON-RPC 2.0 transport.  This document describes a mapping
   of MCP roles, primitives and security model to the network management
   domain so that network devices act as MCP servers and network
   controllers act as MCP clients.  The goal is to provide an intent-
   based, conversational and secure approach for automated network
   troubleshooting, configuration validation, and closed-loop
   remediation without inventing new protocols or device agents.

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.

   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.



Zeng & Mao                Expires 23 April 2026                 [Page 1]

Internet-Draft              MCP for Networks                October 2025


   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Architecture  . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Role Allocation . . . . .

Return 3-8 ideas. Focus on CONCRETE technical contributions, not general statements.
JSON array only, no fences.

response_json:
[
  {
    "title": "MCP Role Mapping for Networks",
    "description": "Maps Model Context Protocol roles to network management domain where network devices act as MCP servers and network controllers act as MCP clients. This enables LLM integration with network infrastructure using existing MCP primitives.",
    "type": "architecture"
  },
  {
    "title": "JSON-RPC 2.0 Transport for Network Management",
    "description": "Leverages JSON-RPC 2.0 transport layer from MCP to expose network Resources, Prompts and Tools. Provides standardized communication between network devices and controllers without new protocols.",
    "type": "protocol"
  },
  {
    "title": "Intent-Based Network Troubleshooting",
    "description": "Enables conversational, intent-based approach for automated network troubleshooting using LLM applications. Supports configuration validation and closed-loop remediation through MCP integration.",
    "type": "mechanism"
  },
  {
    "title": "MCP Security Model for Network Domain",
    "description": "Adapts MCP's security model to network management requirements. Provides secure access control for network device interactions through MCP server-client architecture.",
    "type": "extension"
  },
  {
    "title": "Network Device MCP Server Implementation",
    "description": "Defines how network devices implement MCP server functionality to expose their capabilities as Resources, Prompts and Tools. Enables direct LLM integration without additional device agents.",
    "type": "mechanism"
  }
]


