# llm_cache

draft_name: draft-ietf-sshm-ssh-agent
prompt_hash: 9a2cae20e2024a2d
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:48:26.229021+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-ietf-sshm-ssh-agent | SSH Agent Protocol | 31pg
Abstract: This document specifies a key agent protocol for use in the Secure
   Shell (SSH) protocol.

Note

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

   In the IANA considerations section, please replace "thisRFC" with
   "RFC" and the assigned number, when known.





Internet Engineering Task Force                                D. Miller
Internet-Draft                                                   OpenSSH
Intended status: Standards Track                        19 February 2026
Expires: 23 August 2026


                           SSH Agent Protocol
                      draft-ietf-sshm-ssh-agent-16

Abstract

   This document specifies a key agent protocol for use in the Secure
   Shell (SSH) protocol.

Note

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

   In the IANA considerations section, please replace "thisRFC" with
   "RFC" and the assigned number, when known.

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.

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



Miller                   Expires 23 August 2026                 [Page 1]

Internet-Draft             SSH Agent Protocol              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
     1.1.  Background  . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Background  . . . . . . . . . . . . . . . . . . . . . . .   4
     2.2.  Terminology and units . . . . . . . . . . . . . . . . . .   4
   3.  Protocol Messages . . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  Generic agent responses . . . . . . . . . . . . . . . . .   5
     3.2.  Adding keys to the agent  . . . . . . . . . . . . . . . .   5
       3.2.1.  DSA keys  . . . . . . . . . . . . . . . . . . . . . .   6
       3.2.2.  ECDSA keys  . . . . . . . . . . . . . . .

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

response_json:
[
  {
    "title": "SSH Agent Message Protocol",
    "description": "A standardized protocol for communication between SSH clients and key agent processes using structured message formats. Defines specific message types for key operations and agent responses.",
    "type": "protocol"
  },
  {
    "title": "Key Addition Messages",
    "description": "Protocol messages for adding private keys to the SSH agent, with specific formats for different key types including DSA and ECDSA. Enables secure storage and management of cryptographic keys.",
    "type": "mechanism"
  },
  {
    "title": "Generic Agent Response Framework",
    "description": "Standardized response message format for SSH agents to communicate operation results and status back to clients. Provides consistent error handling and success notification.",
    "type": "pattern"
  },
  {
    "title": "Key Type-Specific Message Formats",
    "description": "Distinct message structures for different cryptographic key types (DSA, ECDSA) to accommodate their unique parameters and requirements. Ensures proper handling of diverse key formats.",
    "type": "mechanism"
  }
]


draft_name: draft-ietf-suit-firmware-encryption
prompt_hash: 6fd1264ab977b251
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:48:33.394589+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-ietf-suit-firmware-encryption | Encrypted Payloads in SUIT Manifests | 55pg
Abstract: This document specifies techniques for encrypting software, firmware,
   machine learning models, and personalization data by utilizing the
   IETF SUIT manifest.  Key agreement is provided by ephemeral-static
   (ES) Diffie-Hellman (DH) and AES Key Wrap (AES-KW).  ES-DH uses
   public key cryptography while AES-KW uses a pre-shared key.
   Encryption of the plaintext is accomplished with conventional
   symmetric key cryptography.





SUIT                                                       H. Tschofenig
Internet-Draft                                                     H-BRS
Intended status: Standards Track                              R. Housley
Expires: 11 June 2026                                     Vigil Security
                                                                B. Moran
                                                             Arm Limited
                                                                D. Brown
                                                                  Linaro
                                                             K. Takayama
                                                         SECOM CO., LTD.
                                                         8 December 2025


                  Encrypted Payloads in SUIT Manifests
                 draft-ietf-suit-firmware-encryption-26

Abstract

   This document specifies techniques for encrypting software, firmware,
   machine learning models, and personalization data by utilizing the
   IETF SUIT manifest.  Key agreement is provided by ephemeral-static
   (ES) Diffie-Hellman (DH) and AES Key Wrap (AES-KW).  ES-DH uses
   public key cryptography while AES-KW uses a pre-shared key.
   Encryption of the plaintext is accomplished with conventional
   symmetric key cryptography.

Status of This Memo

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

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

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

Copyright Notice

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




Tschofenig, et al.        Expires 11 June 2026                  [Page 1]

Internet-Draft    Encrypted Payloads in SUIT Manifests     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.  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": "Ephemeral-Static Diffie-Hellman Key Agreement",
    "description": "ES-DH mechanism using public key cryptography for key agreement in SUIT manifest encryption. Enables secure key establishment between firmware distributors and IoT devices.",
    "type": "mechanism"
  },
  {
    "title": "AES Key Wrap for Pre-Shared Keys",
    "description": "AES-KW mechanism for encrypting content encryption keys using pre-shared keys. Provides an alternative to public key cryptography for constrained devices.",
    "type": "mechanism"
  },
  {
    "title": "SUIT Manifest Encryption Extension",
    "description": "Extension to IETF SUIT manifest format to support encrypted payloads for firmware, software, ML models, and personalization data. Integrates encryption capabilities into the existing SUIT architecture.",
    "type": "extension"
  },
  {
    "title": "Hybrid Encryption Pattern",
    "description": "Pattern combining key agreement mechanisms (ES-DH or AES-KW) with symmetric encryption for payload protection. Balances security and performance for IoT firmware updates.",
    "type": "pattern"
  },
  {
    "title": "Encrypted Firmware Update Protocol",
    "description": "Protocol specification for secure delivery of encrypted firmware and software updates using SUIT manifests. Defines the end-to-end process from encryption to decryption on target devices.",
    "type": "protocol"
  }
]


draft_name: draft-ietf-tls-deprecate-obsolete-kex
prompt_hash: f6abc54bdab84682
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:48:44.285306+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-ietf-tls-deprecate-obsolete-kex | Deprecating Obsolete Key Exchange Methods in (D)TLS 1.2 | 23pg
Abstract: For (D)TLS 1.2, this document deprecates the use of two key
   exchanges, namely Diffie-Hellman over a finite field and RSA, and it
   discourages the use of static elliptic curve Diffie-Hellman cipher
   suites.

   These prescriptions apply only to (D)TLS 1.2 since (D)TLS 1.0 and TLS
   1.1 are deprecated by RFC 8996 and (D)TLS 1.3 either does not use the
   affected algorithms or does not share the relevant configuration
   options.  (There is no DTLS version 1.1.)

   This document updates RFCs 9325, 4346, 5246, 4162, 6347, 5932, 5288,
   6209, 6367, 8422, 5289, 5469, 4785, 4279, 5487, 6655, and 7905, to
   deprecate or discourage - i.e., change to MUST NOT or SHOULD NOT, as
   listed in Section 5.3, Section 5.2, Section 5.3, Section 5.4, and
   Section 5.5 - the use of cipher suites using the above key exchange
   methods in (D)TLS 1.2 connections.





TLS Working Group                                              N. Aviram
Internet-Draft                                           12 January 2026
Updates: 9325, 4346, 5246, 4162, 6347, 5932,                            
         5288, 6209, 6367, 8422, 5289, 5469,                            
         4785, 4279, 5487, 6655, 7905 (if                               
         approved)                                                      
Intended status: Standards Track                                        
Expires: 16 July 2026


        Deprecating Obsolete Key Exchange Methods in (D)TLS 1.2
                draft-ietf-tls-deprecate-obsolete-kex-08

Abstract

   For (D)TLS 1.2, this document deprecates the use of two key
   exchanges, namely Diffie-Hellman over a finite field and RSA, and it
   discourages the use of static elliptic curve Diffie-Hellman cipher
   suites.

   These prescriptions apply only to (D)TLS 1.2 since (D)TLS 1.0 and TLS
   1.1 are deprecated by RFC 8996 and (D)TLS 1.3 either does not use the
   affected algorithms or does not share the relevant configuration
   options.  (There is no DTLS version 1.1.)

   This document updates RFCs 9325, 4346, 5246, 4162, 6347, 5932, 5288,
   6209, 6367, 8422, 5289, 5469, 4785, 4279, 5487, 6655, and 7905, to
   deprecate or discourage - i.e., change to MUST NOT or SHOULD NOT, as
   listed in Section 5.3, Section 5.2, Section 5.3, Section 5.4, and
   Section 5.5 - the use of cipher suites using the above key exchange
   methods in (D)TLS 1.2 connections.

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.



Aviram                    Expires 16 July 2026                  [Page 1]

Internet-Draft         Deprecating RSA and FFDH(E)          January 2026


Copyright Notice

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

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

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

response_json:
[
  {
    "title": "Finite Field Diffie-Hellman Deprecation",
    "description": "Changes cipher suites using Diffie-Hellman over finite fields (FFDH/FFDHE) from SHOULD/MAY to MUST NOT in TLS 1.2. This affects DHE_RSA, DHE_DSS, DH_RSA, and DH_DSS key exchange methods.",
    "type": "requirement"
  },
  {
    "title": "RSA Key Exchange Deprecation", 
    "description": "Changes RSA key exchange cipher suites from SHOULD/MAY to MUST NOT in TLS 1.2. This removes support for RSA-based key transport methods where the client encrypts the pre-master secret with the server's RSA public key.",
    "type": "requirement"
  },
  {
    "title": "Static ECDH Discouragement",
    "description": "Changes static Elliptic Curve Diffie-Hellman cipher suites (ECDH_RSA, ECDH_ECDSA) from SHOULD/MAY to SHOULD NOT in TLS 1.2. This discourages but does not fully prohibit their use.",
    "type": "requirement"
  },
  {
    "title": "TLS 1.2 Scope Limitation",
    "description": "Applies deprecation rules only to TLS/DTLS 1.2, excluding older versions already deprecated by RFC 8996 and TLS 1.3 which doesn't use these algorithms. This creates version-specific cipher suite restrictions.",
    "type": "requirement"
  },
  {
    "title": "Multi-RFC Update Mechanism",
    "description": "Updates 17 different RFCs simultaneously to change cipher suite recommendations from permissive to restrictive language. This demonstrates a coordinated approach to deprecating cryptographic methods across multiple specifications.",
    "type": "mechanism"
  }
]


draft_name: draft-ietf-tls-ecdhe-mlkem
prompt_hash: 7ced3ec1c416a9ea
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:48:52.243424+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-ietf-tls-ecdhe-mlkem | Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3 | 12pg
Abstract: This draft defines three hybrid key agreement mechanisms for TLS 1.3
   - X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024 - that
   combine the post-quantum ML-KEM (Module-Lattice-Based Key
   Encapsulation Mechanism) with an ECDHE (Elliptic Curve Diffie-
   Hellman) exchange.





Transport Layer Security                                  K. Kwiatkowski
Internet-Draft                                                  PQShield
Intended status: Standards Track                           P. Kampanakis
Expires: 12 August 2026                                              AWS
                                                        B. E. Westerbaan
                                                              Cloudflare
                                                              D. Stebila
                                                  University of Waterloo
                                                         8 February 2026


       Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3
                     draft-ietf-tls-ecdhe-mlkem-04

Abstract

   This draft defines three hybrid key agreement mechanisms for TLS 1.3
   - X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024 - that
   combine the post-quantum ML-KEM (Module-Lattice-Based Key
   Encapsulation Mechanism) with an ECDHE (Elliptic Curve Diffie-
   Hellman) exchange.

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://tlswg.github.io/draft-ietf-tls-ecdhe-mlkem/draft-ietf-tls-
   ecdhe-mlkem.html.  Status information for this document may be found
   at https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/.

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

   Source for this draft and an issue tracker can be found at
   https://github.com/tlswg/draft-ietf-tls-ecdhe-mlkem.

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



Kwiatkowski, et al.      Expires 12 August 2026                 [Page 1]

Internet-Draft                 ECDHE-MLKEM                 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 12 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 

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

response_json:
[
  {
    "title": "X25519MLKEM768 Hybrid Key Agreement",
    "description": "A hybrid key agreement mechanism that combines X25519 elliptic curve Diffie-Hellman with ML-KEM-768 post-quantum key encapsulation. Provides both classical and post-quantum security properties in a single TLS 1.3 key exchange.",
    "type": "mechanism"
  },
  {
    "title": "SecP256r1MLKEM768 Hybrid Key Agreement", 
    "description": "A hybrid key agreement mechanism combining the NIST P-256 elliptic curve with ML-KEM-768 post-quantum algorithm. Offers a NIST-standardized elliptic curve option paired with post-quantum protection.",
    "type": "mechanism"
  },
  {
    "title": "SecP384r1MLKEM1024 Hybrid Key Agreement",
    "description": "A hybrid key agreement mechanism that pairs the NIST P-384 elliptic curve with the higher-security ML-KEM-1024 variant. Provides enhanced security levels for both classical and post-quantum components.",
    "type": "mechanism"
  },
  {
    "title": "Post-Quantum Hybrid Key Exchange Pattern",
    "description": "A general approach for combining classical ECDHE with post-quantum ML-KEM in TLS 1.3 key agreement. Enables quantum-resistant security while maintaining compatibility and performance characteristics.",
    "type": "pattern"
  },
  {
    "title": "ML-KEM Integration in TLS 1.3",
    "description": "Extension of TLS 1.3 key agreement to incorporate Module-Lattice-Based Key Encapsulation Mechanism algorithms. Defines how post-quantum KEM operations integrate with existing TLS handshake flows.",
    "type": "extension"
  }
]


draft_name: draft-ietf-tls-extended-key-update
prompt_hash: 3a644f571345cc1f
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:49:00.329257+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-ietf-tls-extended-key-update | Extended Key Update for Transport Layer Security (TLS) 1.3 | 40pg
Abstract: TLS 1.3 ensures forward secrecy by performing an ephemeral Diffie-
   Hellman key exchange during the initial handshake, protecting past
   communications even if a party's long-term keys (typically a private
   key with a corresponding certificate) are later compromised.  While
   the built-in KeyUpdate mechanism allows application traffic keys to
   be refreshed during a session, it does not incorporate fresh entropy
   from a new key exchange and therefore does not provide post-
   compromise security.  This limitation can pose a security risk in
   long-lived sessions, such as those found in industrial IoT or
   telecommunications environments.

   To address this, this specification defines an extended key update
   mechanism that performs a fresh Diffie-Hellman exchange within an
   active session, thereby ensuring post-compromise security.  By
   forcing attackers to exfiltrate new key material repeatedly, this
   approach mitigates the risks associated with static key compromise.
   Regular renewal of session keys helps contain the impact of such
   compromises.  The extension is applicable to both TLS 1.3 and DTLS
   1.3.





Transport Layer Security                                   H. Tschofenig
Internet-Draft                                                   Siemens
Updates: 9261, 8446 (if approved)                               M. Tüxen
Intended status: Standards Track       Münster Univ. of Applied Sciences
Expires: 23 August 2026                                         T. Reddy
                                                                   Nokia
                                                                S. Fries
                                                                 Siemens
                                                            Y. Rosomakho
                                                                 Zscaler
                                                        19 February 2026


       Extended Key Update for Transport Layer Security (TLS) 1.3
                 draft-ietf-tls-extended-key-update-09

Abstract

   TLS 1.3 ensures forward secrecy by performing an ephemeral Diffie-
   Hellman key exchange during the initial handshake, protecting past
   communications even if a party's long-term keys (typically a private
   key with a corresponding certificate) are later compromised.  While
   the built-in KeyUpdate mechanism allows application traffic keys to
   be refreshed during a session, it does not incorporate fresh entropy
   from a new key exchange and therefore does not provide post-
   compromise security.  This limitation can pose a security risk in
   long-lived sessions, such as those found in industrial IoT or
   telecommunications environments.

   To address this, this specification defines an extended key update
   mechanism that performs a fresh Diffie-Hellman exchange within an
   active session, thereby ensuring post-compromise security.  By
   forcing attackers to exfiltrate new key material repeatedly, this
   approach mitigates the risks associated with static key compromise.
   Regular renewal of session keys helps contain the impact of such
   compromises.  The extension is applicable to both TLS 1.3 and DTLS
   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/.




Tschofenig, et al.       Expires 23 August 2026                 [Page 1]

Internet-Draft         Extended Key Update for TLS         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 23 August 2026.

Copyright Notice

   Copyright 

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

response_json:
[
  {
    "title": "Extended Key Update Message", 
    "description": "A new TLS handshake message type that performs a fresh Diffie-Hellman key exchange within an active TLS 1.3 session. Unlike standard KeyUpdate, this incorporates new entropy to provide post-compromise security.",
    "type": "protocol"
  },
  {
    "title": "In-Session Diffie-Hellman Exchange",
    "description": "A mechanism to perform ephemeral Diffie-Hellman key exchanges during an established TLS session rather than only at handshake time. This generates fresh shared secrets without requiring session renegotiation.",
    "type": "mechanism"
  },
  {
    "title": "Post-Compromise Security for Long-Lived Sessions",
    "description": "A security property that ensures session keys can recover from compromise through periodic renewal with fresh entropy. This is particularly important for industrial IoT and telecommunications environments with persistent connections.",
    "type": "requirement"
  },
  {
    "title": "DTLS 1.3 Extended Key Update",
    "description": "Extension of the key update mechanism to DTLS 1.3 environments, adapting the fresh key exchange approach for datagram-based communications. This provides post-compromise security for UDP-based TLS sessions.",
    "type": "extension"
  },
  {
    "title": "Entropy Refresh Pattern",
    "description": "A pattern for incorporating fresh cryptographic entropy into existing sessions through repeated key exchanges. This forces attackers to continuously exfiltrate new key material rather than relying on static compromised keys.",
    "type": "pattern"
  }
]


draft_name: draft-irtf-nmrg-llm-nm
prompt_hash: 57f1fe30d7bf4514
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:49:07.903948+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-irtf-nmrg-llm-nm | A Framework for LLM-Assisted Network Management with Human-in-the-Loop | 12pg
Abstract: This document defines an interoperable framework that facilitates
   collaborative network management between Large Language Models (LLMs)
   and human operators.  The proposed framework introduces enhanced
   telemetry module, LLM decision module and standardized interaction
   data models between human operators and LLM-driven systems, and
   workflows to enforce human oversight.  The approach ensures
   compatibility with existing network management systems and protocols
   while improving automation and decision-making capabilities in
   network operations.





Network Management Research Group                                 Y. Cui
Internet-Draft                                       Tsinghua University
Intended status: Informational                                   M. Xing
Expires: 4 September 2025                                       L. Zhang
                                                 Zhongguancun Laboratory
                                                            3 March 2025


 A Framework for LLM-Assisted Network Management with Human-in-the-Loop
                       draft-irtf-nmrg-llm-nm-00

Abstract

   This document defines an interoperable framework that facilitates
   collaborative network management between Large Language Models (LLMs)
   and human operators.  The proposed framework introduces enhanced
   telemetry module, LLM decision module and standardized interaction
   data models between human operators and LLM-driven systems, and
   workflows to enforce human oversight.  The approach ensures
   compatibility with existing network management systems and protocols
   while improving automation and decision-making capabilities in
   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 4 September 2025.

Copyright Notice

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







Cui, et al.             Expires 4 September 2025                [Page 1]

Internet-Draft                   LLM4Net                      March 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
     1.1.  Motivation  . . . . . . . . . . . . . . . . . . . . . . .   2
     1.2.  Problem Statement . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Acronyms and Abbreviations  . . . . . . . . . . . . . . .   3
   3.  Framework Overview  . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Enhanced Telemetry Module . . . . . . . . . .

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

response_json:
[
  {
    "title": "Enhanced Telemetry Module",
    "description": "A telemetry collection and processing module specifically designed to gather and format network data for LLM consumption. This module augments traditional telemetry systems to provide context-rich data suitable for AI-driven analysis.",
    "type": "architecture"
  },
  {
    "title": "LLM Decision Module",
    "description": "A dedicated component that processes network telemetry data through Large Language Models to generate network management recommendations and decisions. The module interfaces between raw network data and AI-powered decision making.",
    "type": "architecture"
  },
  {
    "title": "Human-in-the-Loop Workflow",
    "description": "Standardized workflows that enforce human oversight and approval mechanisms for LLM-generated network management decisions. This ensures critical network changes require human validation before execution.",
    "type": "mechanism"
  },
  {
    "title": "Standardized Interaction Data Models",
    "description": "Defined data structures and formats for communication between human operators and LLM-driven network management systems. These models ensure consistent and interoperable exchanges of network management information.",
    "type": "protocol"
  },
  {
    "title": "LLM-Human Collaborative Framework",
    "description": "An interoperable framework architecture that enables seamless collaboration between AI systems and human network operators while maintaining compatibility with existing network management protocols. The framework coordinates the interaction between enhanced telemetry, LLM decision making, and human oversight components.",
    "type": "architecture"
  }
]


draft_name: draft-jeong-opsawg-intent-based-sdv-framework
prompt_hash: 33a6c3758e600bd9
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:49:17.021137+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-jeong-opsawg-intent-based-sdv-framework | An Intent-Based Management Framework for Software-Defined Vehicles in Intelligent Transportation Systems | 20pg
Abstract: Software-Defined Vehicle (SDV) is a new player towards autonomous
   vehicles in Intelligent Transportation Systems (ITS).  An SDV is
   constructed by a software platform like a cloud-native system (e.g.,
   Kubernetes) and has its internal network.  To facilitate the easy and
   efficient configuration of networks in the SDV, an intent-based
   management is an appropriate direction.  This document proposes a
   framework of intent-based management for networks, security, and
   applications in SDVs so that they can communicate with other SDVs and
   infrastructure nodes for safe driving and infotainment services in
   the road networks.





Operations and Management Area Working Group               J. Jeong, Ed.
Internet-Draft                                                   Y. Shen
Intended status: Informational                                    Y. Ahn
Expires: 11 December 2025                                          M. Gu
                                                 Sungkyunkwan University
                                                             9 June 2025


 An Intent-Based Management Framework for Software-Defined Vehicles in
                   Intelligent Transportation Systems
            draft-jeong-opsawg-intent-based-sdv-framework-04

Abstract

   Software-Defined Vehicle (SDV) is a new player towards autonomous
   vehicles in Intelligent Transportation Systems (ITS).  An SDV is
   constructed by a software platform like a cloud-native system (e.g.,
   Kubernetes) and has its internal network.  To facilitate the easy and
   efficient configuration of networks in the SDV, an intent-based
   management is an appropriate direction.  This document proposes a
   framework of intent-based management for networks, security, and
   applications in SDVs so that they can communicate with other SDVs and
   infrastructure nodes for safe driving and infotainment services in
   the road 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 11 December 2025.

Copyright Notice

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





Jeong, et al.           Expires 11 December 2025                [Page 1]

Internet-Draft        An Intent-Based SDV Framework            June 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.  Terminology . . . . . . . . . . . . . . . . .

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

response_json:
[
  {
    "title": "Intent-Based SDV Management Framework",
    "description": "A comprehensive framework for managing networks, security, and applications in Software-Defined Vehicles using intent-based management principles. This enables easy and efficient configuration of SDV internal networks for communication with other vehicles and infrastructure.",
    "type": "framework"
  },
  {
    "title": "Cloud-Native SDV Platform Architecture",
    "description": "Software-Defined Vehicles constructed using cloud-native system platforms like Kubernetes with internal networking capabilities. This architecture enables software-based vehicle functionality similar to cloud computing environments.",
    "type": "architecture"
  },
  {
    "title": "SDV-to-SDV Communication Protocol",
    "description": "Communication mechanism enabling Software-Defined Vehicles to interact with other SDVs and infrastructure nodes for safe driving and infotainment services. This supports vehicle-to-vehicle and vehicle-to-infrastructure connectivity in road networks.",
    "type": "protocol"
  },
  {
    "title": "Intent-Based Network Configuration",
    "description": "Management approach that allows high-level intent specification for automatic configuration of SDV internal networks. This simplifies network management by translating user intentions into specific network configurations.",
    "type": "mechanism"
  },
  {
    "title": "Integrated Security Management",
    "description": "Intent-based security management system specifically designed for Software-Defined Vehicles operating in Intelligent Transportation Systems. This provides unified security control across the SDV platform and its communications.",
    "type": "mechanism"
  }
]


draft_name: draft-jewell-aibdp
prompt_hash: 018cadb973db00ee
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:49:23.981797+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-jewell-aibdp | AI Boundary Declaration Protocol (AIBDP) | 6pg
Abstract: This document defines the AI Boundary Declaration Protocol (AIBDP), a
   declarative framework for expressing usage boundaries around web-
   hosted content in relation to AI systems.  It builds on the
   mechanisms of RFC 2196 and RFC 9116, as well as on the HTTP semantics
   of RFC 9110 and the robots-style inclusion rules of RFC 7725, to
   provide machine-readable permissions and denials for indexing,
   training, mimicry, representation, derivative construction,
   analytical exploitation, and agentic access.  AIBDP supports ethical
   infrastructure, agentic AI governance, and procedural clarity across
   the Internet.





Network Working Group                                       JDAJ. Jewell
Internet-Draft                             National Union of Journalists
Intended status: Informational                            15 August 2025
Expires: 16 February 2026


                AI Boundary Declaration Protocol (AIBDP)
                         draft-jewell-aibdp-00

Abstract

   This document defines the AI Boundary Declaration Protocol (AIBDP), a
   declarative framework for expressing usage boundaries around web-
   hosted content in relation to AI systems.  It builds on the
   mechanisms of RFC 2196 and RFC 9116, as well as on the HTTP semantics
   of RFC 9110 and the robots-style inclusion rules of RFC 7725, to
   provide machine-readable permissions and denials for indexing,
   training, mimicry, representation, derivative construction,
   analytical exploitation, and agentic access.  AIBDP supports ethical
   infrastructure, agentic AI governance, and procedural clarity across
   the Internet.

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

Copyright Notice

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








Jewell                  Expires 16 February 2026                [Page 1]

Internet-Draft              Consent Required                 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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Manifest Format . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Consent States  . . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Use Case Scenarios  . . . . . . . . . . . . . . . . . . . . .   4
   6.  Interoperability with HTTP 430  . . . . . . . . . . . . . . .   4
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   9.  Normative References  . . . . . . . . . . . . .

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

response_json:
[
  {
    "title": "AI Boundary Declaration Protocol (AIBDP)",
    "description": "A declarative framework for expressing machine-readable usage boundaries around web-hosted content in relation to AI systems. Provides permissions and denials for indexing, training, mimicry, representation, derivative construction, analytical exploitation, and agentic access.",
    "type": "protocol"
  },
  {
    "title": "AIBDP Manifest Format",
    "description": "A structured format for declaring AI usage boundaries that builds on robots-style inclusion rules from RFC 7725. Enables content owners to specify granular permissions for different AI operations.",
    "type": "mechanism"
  },
  {
    "title": "AI Consent States",
    "description": "A defined set of consent states that AI systems can interpret to determine permitted operations on web content. Provides standardized vocabulary for expressing boundaries around AI usage.",
    "type": "pattern"
  },
  {
    "title": "HTTP 430 Status Code Integration",
    "description": "Interoperability mechanism that leverages HTTP status codes to communicate AI boundary violations. Enables web servers to respond with standardized error codes when AI boundaries are crossed.",
    "type": "extension"
  },
  {
    "title": "Granular AI Operation Categories",
    "description": "Technical categorization of AI operations including indexing, training, mimicry, representation, derivative construction, analytical exploitation, and agentic access. Each category can have separate permission controls.",
    "type": "architecture"
  }
]


draft_name: draft-jia-oauth-scope-aggregation
prompt_hash: 5ca8aedcaa7638fc
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:49:23.981799+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-jia-oauth-scope-aggregation | OAuth 2.0 Scope Aggregation for Multi-Step AI Agent Workflows | 15pg
Abstract: This document describes a scope-aggregated OAuth 2.0 authorization
   pattern for multi-step AI agent workflows.  An AI agent aggregates
   the scopes required across a workflow and only initiates a single
   authorization procedure for the aggregated scope.  This reduces
   repeated user consents and multiple authorization round-trips,
   improving authorization efficiency.





Web Authorization Protocol                                        Y. Jia
Internet-Draft                                                   S. Peng
Intended status: Standards Track                                  Huawei
Expires: 14 August 2026                                 10 February 2026


     OAuth 2.0 Scope Aggregation for Multi-Step AI Agent Workflows
                  draft-jia-oauth-scope-aggregation-00

Abstract

   This document describes a scope-aggregated OAuth 2.0 authorization
   pattern for multi-step AI agent workflows.  An AI agent aggregates
   the scopes required across a workflow and only initiates a single
   authorization procedure for the aggregated scope.  This reduces
   repeated user consents and multiple authorization round-trips,
   improving authorization 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."

   This Internet-Draft will expire on 14 August 2026.

Copyright Notice

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

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



Jia & Peng               Expires 14 August 2026                 [Page 1]

Internet-Draft           OAuth Scope Aggregation           February 2026


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   4
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Security Member in Resource Metadata  . . . . . . . . . . . .   5
     3.1.  Comparison to Existing Practice . . . . . . . . . . . . .   6
     3.2.  Backward Compatibility  . . . . . . . . . . . . . . . . .   6
   4.  Workflow Execution with OAuth Scope Aggregation . . . . . . .   7
   5.  Advantages  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     5.1.  Reduced Consen

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

response_json:
[
  {
    "title": "OAuth Scope Aggregation Pattern",
    "description": "An authorization pattern where AI agents collect all required scopes across a multi-step workflow and perform a single OAuth authorization request instead of multiple requests. This reduces user consent fatigue and authorization round-trips.",
    "type": "pattern"
  },
  {
    "title": "Security Member in Resource Metadata",
    "description": "A metadata extension that embeds OAuth scope requirements directly into resource descriptions. This allows AI agents to determine authorization needs before attempting resource access.",
    "type": "extension"
  },
  {
    "title": "Workflow Execution with Pre-Authorization",
    "description": "A mechanism where AI agents analyze complete workflows upfront to identify all required scopes, then execute the entire workflow using a single aggregated access token. This enables uninterrupted multi-step operations.",
    "type": "mechanism"
  }
]


draft_name: draft-jiang-cats-reference-acn
prompt_hash: 139467fe4f21fdb3
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:49:31.564386+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-jiang-cats-reference-acn | CATS Reference Model for AI-Agent Communication Network | 12pg
Abstract: This draft describes the AI-agents along with the network to provide
   the communication services among various types of AI-agents, i.e.,
   AI-agent Communication Network or ACN.  Thanks to the CATS-like
   information flow steering in ACN, we propose a CATS reference model
   that covers the definition of reference points, protocol stacks,
   service provisioning model, sigaling procedures, message paths, and
   implementation schemes.  This reference model is generalized so as to
   accommodate both the existing CATS framework and the potential
   extension for the ACN.





CATS Working Group                                              T. Jiang
Internet-Draft                                                    P. Liu
Intended status: Informational                              China Mobile
Expires: 1 January 2026                                     30 June 2025


        CATS Reference Model for AI-Agent Communication Network
                   draft-jiang-cats-reference-acn-00

Abstract

   This draft describes the AI-agents along with the network to provide
   the communication services among various types of AI-agents, i.e.,
   AI-agent Communication Network or ACN.  Thanks to the CATS-like
   information flow steering in ACN, we propose a CATS reference model
   that covers the definition of reference points, protocol stacks,
   service provisioning model, sigaling procedures, message paths, and
   implementation schemes.  This reference model is generalized so as to
   accommodate both the existing CATS framework and the potential
   extension for the ACN.

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



Jiang & Liu              Expires 1 January 2026                 [Page 1]

Internet-Draft        CATS Reference Model for ACN             June 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
     1.1.  AI-agent Communication Network (ACN)  . . . . . . . . . .   2
     1.2.  ACN Realization Models  . . . . . . . . . . . . . . . . .   3
   2.  Applications of CATS to ACN . . . . . . . . . . . . . . . . .   4
     2.1.  AI-agents Services with CATS-like Optimization  . . . . .   4
     2.2.  CATS-like Metrics Model for ACN . 

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

response_json:
[
  {
    "title": "AI-Agent Communication Network (ACN)",
    "description": "A network architecture specifically designed to provide communication services among various types of AI-agents. It applies CATS-like information flow steering mechanisms to optimize AI-agent interactions.",
    "type": "architecture"
  },
  {
    "title": "CATS-like Information Flow Steering for AI-Agents",
    "description": "An adaptation of Computing-Aware Traffic Steering (CATS) techniques to optimize communication paths and resource allocation in AI-agent networks. This extends traditional CATS frameworks to handle AI-agent specific traffic patterns.",
    "type": "mechanism"
  },
  {
    "title": "CATS Reference Points for ACN",
    "description": "Standardized interface definitions and reference points that enable interoperability between different components in the AI-agent communication network. These define how AI-agents interact with the underlying CATS infrastructure.",
    "type": "architecture"
  },
  {
    "title": "ACN Service Provisioning Model",
    "description": "A framework for delivering and managing communication services tailored to AI-agent requirements within the CATS-enabled network. It defines how services are discovered, allocated, and consumed by AI-agents.",
    "type": "protocol"
  },
  {
    "title": "CATS-like Metrics Model for ACN",
    "description": "A specialized metrics framework that measures and evaluates network performance parameters specific to AI-agent communications. This extends traditional CATS metrics to account for AI-agent workload characteristics.",
    "type": "mechanism"
  }
]


draft_name: draft-jiang-seat-dynamic-attestation
prompt_hash: 3f3a3bac9fdad4f6
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:49:38.420593+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-jiang-seat-dynamic-attestation | Dynamic Attestation for AI Agent Communication | 5pg
Abstract: This document describes a use case for conveying remote attestation
   information in association with Transport Layer Security (TLS)
   sessions in the context of AI agent communication.  It focuses on
   long-lived secure channel sessions where an AI agent runtime posture,
   covering the platform Trusted Computing Base (TCB), agent manifest
   (models, tools and policies) and committed runtime context, can
   change frequently and unpredictably.  The document highlights
   requirements for dynamic attestation so that relying parties can base
   authorization decisions on the current runtime posture of the
   communicating agent.





SEAT                                                            Y. Jiang
Internet-Draft                                                          
Intended status: Informational                                   D. Wang
Expires: 17 May 2026                                    13 November 2025


             Dynamic Attestation for AI Agent Communication
                draft-jiang-seat-dynamic-attestation-00

Abstract

   This document describes a use case for conveying remote attestation
   information in association with Transport Layer Security (TLS)
   sessions in the context of AI agent communication.  It focuses on
   long-lived secure channel sessions where an AI agent runtime posture,
   covering the platform Trusted Computing Base (TCB), agent manifest
   (models, tools and policies) and committed runtime context, can
   change frequently and unpredictably.  The document highlights
   requirements for dynamic attestation so that relying parties can base
   authorization decisions on the current runtime posture of the
   communicating 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).  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 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



Jiang & Wang               Expires 17 May 2026                  [Page 1]

Internet-Draft        Dynamic Attestation for SEAT         November 2025


   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Dynamic Attestation for AI Agent Communication  . . . . . . .   3
     3.1.  AI Agent Runtime Attestation  . . . . . . . . . . . . . .   3
   4.  Security Considerations . . . . . . . . . . . . . . . . 

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

response_json:
[
  {
    "title": "AI Agent Runtime Posture",
    "description": "A comprehensive security posture model for AI agents that includes platform TCB, agent manifest (models, tools, policies), and committed runtime context. This posture can change frequently and unpredictably during long-lived sessions.",
    "type": "architecture"
  },
  {
    "title": "Dynamic Attestation for Long-lived Sessions",
    "description": "A mechanism to continuously update and convey remote attestation information during ongoing TLS sessions. This allows verification of changing runtime states without re-establishing connections.",
    "type": "mechanism"
  },
  {
    "title": "Runtime Context-based Authorization",
    "description": "An authorization pattern where relying parties make access control decisions based on the current runtime posture of communicating AI agents. This enables fine-grained security policies that adapt to agent state changes.",
    "type": "pattern"
  },
  {
    "title": "AI Agent Manifest Attestation",
    "description": "A component of the attestation framework that verifies the models, tools, and policies currently loaded and active in an AI agent. This provides assurance about the agent's capabilities and constraints.",
    "type": "mechanism"
  }
]


draft_name: draft-josefsson-chempat
prompt_hash: a8128fcf306c0b1f
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:49:46.206428+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-josefsson-chempat | Chempat: Generic Instantiated PQ/T Hybrid Key Encapsulation Mechanisms | 20pg
Abstract: This document specify Chempat as a generic family of instantiated
   Post-Quantum/Traditional (PQ/T) Hybrid Key Exchange Methods (KEMs).
   The goal is to provide a generic combiner construct that can be
   analysed separately for security assurance, and to offer concrete
   instantiated algorithms for integration into protocol and
   implementations.  Identified instances are provided based on some
   combinations of traditional Diffie-Hellman key agreement using curves
   P-256, P-384, X25519, X448, brainpoolP256, brainpoolP384 and
   brainpoolP512 combined with post quantum methods ML-KEM-768, ML-KEM-
   1024, Streamlined NTRU Prime sntrup761, Classic McEliece and
   FrodoKEM.





CFRG                                                        S. Josefsson
Internet-Draft                                           20 October 2025
Intended status: Informational                                          
Expires: 23 April 2026


 Chempat: Generic Instantiated PQ/T Hybrid Key Encapsulation Mechanisms
                       draft-josefsson-chempat-04

Abstract

   This document specify Chempat as a generic family of instantiated
   Post-Quantum/Traditional (PQ/T) Hybrid Key Exchange Methods (KEMs).
   The goal is to provide a generic combiner construct that can be
   analysed separately for security assurance, and to offer concrete
   instantiated algorithms for integration into protocol and
   implementations.  Identified instances are provided based on some
   combinations of traditional Diffie-Hellman key agreement using curves
   P-256, P-384, X25519, X448, brainpoolP256, brainpoolP384 and
   brainpoolP512 combined with post quantum methods ML-KEM-768, ML-KEM-
   1024, Streamlined NTRU Prime sntrup761, Classic McEliece and
   FrodoKEM.

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

   Discussion of this document takes place on the Crypto Forum Research
   Group (CFRG) Research Group mailing list (mailto:cfrg@ietf.org),
   which is archived at https://mailarchive.ietf.org/arch/browse/cfrg/.

   Source for this draft and an issue tracker can be found at
   https://gitlab.com/jas/ietf-chempat.

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





Josefsson                 Expires 23 April 2026                 [Page 1]

Internet-Draft                   Chempat                    October 2025


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

   This Internet-Draft will expire on 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.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

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": "Chempat Generic Combiner",
    "description": "A generic construct for combining traditional and post-quantum key encapsulation mechanisms that can be analyzed separately for security assurance. Provides a framework for creating hybrid PQ/T KEMs with modular security analysis.",
    "type": "mechanism"
  },
  {
    "title": "PQ/T Hybrid KEM Architecture",
    "description": "Architecture combining traditional Diffie-Hellman key agreement with post-quantum cryptographic methods in a single key encapsulation mechanism. Enables quantum-resistant cryptography while maintaining backward compatibility.",
    "type": "architecture"
  },
  {
    "title": "Multi-Curve Traditional Component Support",
    "description": "Support for multiple elliptic curves including P-256, P-384, X25519, X448, and brainpool curves (P256, P384, P512) as the traditional cryptographic component. Provides flexibility in choosing appropriate curve security levels.",
    "type": "extension"
  },
  {
    "title": "Multi-Algorithm Post-Quantum Integration",
    "description": "Integration of multiple post-quantum algorithms including ML-KEM-768/1024, Streamlined NTRU Prime sntrup761, Classic McEliece, and FrodoKEM. Enables selection of appropriate PQ algorithms based on security and performance requirements.",
    "type": "mechanism"
  },
  {
    "title": "Concrete Instantiated Algorithm Specifications",
    "description": "Specific combinations of traditional and post-quantum algorithms provided as concrete instantiated algorithms ready for protocol integration. Eliminates the need for implementers to design their own hybrid combinations.",
    "type": "protocol"
  }
]


draft_name: draft-jurkovikj-collab-tunnel
prompt_hash: e71e49c526b6ecc5
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:49:53.679681+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-jurkovikj-collab-tunnel | The Collaboration Tunnel Protocol (TCT) | 38pg
Abstract: This document specifies the Collaboration Tunnel Protocol, an HTTP-
   based method for efficient, verifiable delivery of web content to
   automated agents.  The protocol uses bidirectional URL discovery,
   template-invariant content fingerprinting with strong ETags, sitemap-
   first verification, and strict conditional request discipline to
   reduce bandwidth while preserving canonical URLs.





Network Working Group                                       A. Jurkovikj
Internet-Draft                                          14 November 2025
Intended status: Experimental                                           
Expires: 18 May 2026


                The Collaboration Tunnel Protocol (TCT)
                    draft-jurkovikj-collab-tunnel-01

Abstract

   This document specifies the Collaboration Tunnel Protocol, an HTTP-
   based method for efficient, verifiable delivery of web content to
   automated agents.  The protocol uses bidirectional URL discovery,
   template-invariant content fingerprinting with strong ETags, sitemap-
   first verification, and strict conditional request discipline to
   reduce bandwidth while preserving canonical URLs.

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

Copyright Notice

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

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



Jurkovikj                  Expires 18 May 2026                  [Page 1]

Internet-Draft                     TCT                     November 2025


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
       1.1.1.  Problem Statement . . . . . . . . . . . . . . . . . .   5
       1.1.2.  Goals and Non-Goals . . . . . . . . . . . . . . . . .   5
     1.2.  Architecture  . . . . . . . . . . . . . . . . . . . . . .   6
     1.3.  Design Rationale and Relation to Existing Mechanisms  . .   7
       1.3.1.  Related Work  . . . . . . . . . . . . . . . . . . . .   7
       1.3.2.  TCT Design Choices  . . . . . . . . . . . . . . . . .   8
     1.4.  Discovery . . . . . . . . . . . . . . . . . . . . . . . .   

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

response_json:
[
  {
    "title": "Bidirectional URL Discovery",
    "description": "A mechanism allowing both servers and clients to discover relevant URLs for content synchronization. Enables efficient crawling by letting servers suggest which URLs automated agents should request.",
    "type": "mechanism"
  },
  {
    "title": "Template-Invariant Content Fingerprinting",
    "description": "A fingerprinting method that generates consistent hashes for content regardless of template changes or cosmetic modifications. Uses strong ETags to identify when actual content has changed versus just presentation.",
    "type": "mechanism"
  },
  {
    "title": "Sitemap-First Verification",
    "description": "A protocol pattern that prioritizes sitemap validation before content retrieval. Ensures automated agents work with accurate URL mappings and canonical references.",
    "type": "pattern"
  },
  {
    "title": "Strict Conditional Request Discipline",
    "description": "A requirement for rigorous use of HTTP conditional headers (If-None-Match, If-Modified-Since) to minimize bandwidth. Enforces precise cache validation to avoid unnecessary content transfers.",
    "type": "requirement"
  },
  {
    "title": "Collaboration Tunnel Protocol (TCT)",
    "description": "An HTTP-based protocol for efficient delivery of web content to automated agents. Combines multiple optimization techniques while preserving canonical URL structure.",
    "type": "protocol"
  }
]


draft_name: draft-jurkovikj-httpapi-agentic-state
prompt_hash: dfdacfa71911dfac
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:49:59.312077+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-jurkovikj-httpapi-agentic-state | HTTP Profile for Synchronized Resource State (Agentic State Transfer) | 21pg
Abstract: HTTP resources are frequently exposed in multiple representations
   (e.g., text/html for rendering and application/json for processing)
   via Content Negotiation.  However, standard HTTP concurrency controls
   (such as ETags) are typically scoped to the byte sequence of a
   specific representation.  This creates a synchronization gap where a
   client modifying one representation cannot guarantee consistency with
   the underlying state of another representation, leading to race
   conditions and "lost updates" in multi-client environments.

   This document specifies _Agentic State Transfer_ (AST), an HTTP
   profile for managing _Canonical Resource State_ (CRS) across multiple
   synchronized representations of the same resource.  It defines the
   use of _Semantic Validators_ (Content Identity) to track the logical
   state of a resource independent of its serialization.  It further
   mandates the use of Optimistic Concurrency Control via If-Match
   headers for state-changing operations, ensuring that mutations
   applied by automated agents are atomic and consistent across all
   views.





Internet Engineering Task Force                             A. Jurkovikj
Internet-Draft                                          10 December 2025
Intended status: Best Current Practice                                  
Expires: 13 June 2026


 HTTP Profile for Synchronized Resource State (Agentic State Transfer)
                draft-jurkovikj-httpapi-agentic-state-00

Abstract

   HTTP resources are frequently exposed in multiple representations
   (e.g., text/html for rendering and application/json for processing)
   via Content Negotiation.  However, standard HTTP concurrency controls
   (such as ETags) are typically scoped to the byte sequence of a
   specific representation.  This creates a synchronization gap where a
   client modifying one representation cannot guarantee consistency with
   the underlying state of another representation, leading to race
   conditions and "lost updates" in multi-client environments.

   This document specifies _Agentic State Transfer_ (AST), an HTTP
   profile for managing _Canonical Resource State_ (CRS) across multiple
   synchronized representations of the same resource.  It defines the
   use of _Semantic Validators_ (Content Identity) to track the logical
   state of a resource independent of its serialization.  It further
   mandates the use of Optimistic Concurrency Control via If-Match
   headers for state-changing operations, ensuring that mutations
   applied by automated agents are atomic and consistent across all
   views.

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





Jurkovikj                 Expires 13 June 2026                  [Page 1]

Internet-Draft           Agentic State Transfer            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
   provi

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

response_json:
[
  {
    "title": "Semantic Validators (Content Identity)",
    "description": "HTTP header mechanism to track the logical state of a resource independent of its serialization format. Enables consistency checking across different representations of the same resource.",
    "type": "mechanism"
  },
  {
    "title": "Canonical Resource State (CRS)",
    "description": "Architecture for maintaining a unified logical state that underlies multiple HTTP representations. Provides a single source of truth for resource state across different content types.",
    "type": "architecture"
  },
  {
    "title": "Agentic State Transfer (AST) Profile",
    "description": "HTTP profile that mandates optimistic concurrency control via If-Match headers for all state-changing operations. Ensures atomic and consistent mutations across synchronized representations.",
    "type": "protocol"
  },
  {
    "title": "Cross-Representation Consistency Pattern",
    "description": "Pattern for synchronizing state changes across multiple content-negotiated representations of the same resource. Solves race conditions between clients using different representation formats.",
    "type": "pattern"
  },
  {
    "title": "Mandatory Optimistic Concurrency Control",
    "description": "Requirement that all state-changing operations must include If-Match headers with semantic validators. Prevents lost updates in multi-client environments with automated agents.",
    "type": "requirement"
  }
]


draft_name: draft-kale-agntcy-federated-privacy
prompt_hash: 9e0c66446f2e2685
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:50:05.765372+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-kale-agntcy-federated-privacy | Privacy-Preserving Federated Learning Architecture for Multi-Tenant AI Agent Systems | 13pg
Abstract: This document specifies a reference architecture for privacy-
   preserving federated learning in multi-tenant AI agent deployments.
   It addresses the challenge of enabling collaborative model training
   across organizational boundaries while maintaining formal privacy
   guarantees and tenant data isolation.  The architecture combines
   federated averaging, differential privacy mechanisms, and secure
   aggregation to enable cross-tenant knowledge transfer without
   exposing sensitive behavioral data.

Network Working Group                                           N. Kale
Internet-Draft                                             Cisco Systems
Intended status: Informational                             January 2026
Expires: July 2026


      Privacy-Preserving Federated Learning Architecture for
              Multi-Tenant AI Agent Systems

                 draft-kale-agntcy-federated-privacy-00

Abstract

   This document specifies a reference architecture for privacy-
   preserving federated learning in multi-tenant AI agent deployments.
   It addresses the challenge of enabling collaborative model training
   across organizational boundaries while maintaining formal privacy
   guarantees and tenant data isolation.  The architecture combines
   federated averaging, differential privacy mechanisms, and secure
   aggregation to enable cross-tenant knowledge transfer without
   exposing sensitive behavioral 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."

   This Internet-Draft will expire on July 7, 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.

Kale                          Informational                     [Page 1]

Internet-Draft        Federated Learning for Agents         January 2026


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Relationship to AI Agent Protocol Work  . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Architecture Overview . . . . . . . . . . . . . . . . . . . .   4
     4.1.  System Components . . . . . . . . . . . . . . . . . . . .   4
     4.2.  Data Flow . . . . . . . . . . . . . . . . . . . . . . . .   6
     4.3.  Trust Model . . . . . . . . . . . . . . . . . . . . . . .   6
   5.  Federated Learning Protocol . . . . . . . . . . . . . . . . .   6
     5.1.  Initialization  . . . . . . . . . . . . . . . . . . . 

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

response_json:
[
  {
    "title": "Multi-Tenant Federated Averaging",
    "description": "A federated averaging mechanism adapted for multi-tenant AI agent systems that enables model parameter aggregation across organizational boundaries. The protocol maintains tenant isolation while allowing collaborative learning from distributed agent behaviors.",
    "type": "mechanism"
  },
  {
    "title": "Differential Privacy for Agent Models",
    "description": "Integration of differential privacy mechanisms specifically designed for AI agent model training to provide formal privacy guarantees. This prevents sensitive behavioral data exposure during cross-tenant knowledge transfer.",
    "type": "mechanism"
  },
  {
    "title": "Secure Aggregation Protocol",
    "description": "A secure aggregation protocol that enables privacy-preserving combination of model updates from multiple tenants. The protocol ensures that individual tenant contributions cannot be reverse-engineered from the aggregated results.",
    "type": "protocol"
  },
  {
    "title": "Cross-Tenant Knowledge Transfer",
    "description": "An architecture pattern that enables AI agents to benefit from learning across organizational boundaries without data sharing. This allows agents to improve performance through collaborative training while maintaining strict data isolation.",
    "type": "pattern"
  },
  {
    "title": "Privacy-Preserving Reference Architecture",
    "description": "A comprehensive reference architecture that combines federated learning, differential privacy, and secure aggregation for multi-tenant AI deployments. The architecture provides formal privacy guarantees while enabling collaborative model improvement.",
    "type": "architecture"
  }
]


draft_name: draft-kartha-grd
prompt_hash: ac8dbe5a5266fd89
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:50:14.569311+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-kartha-grd | Geospatial Resource Discovery (GRD): Problem Statement and Conceptual Architecture | 8pg
Abstract: The Internet provides standardized mechanisms for resolving
   identifiers, such as domain names, to network locations.  These
   mechanisms assume that a client already knows the identifier of the
   resource it wishes to access.  Emerging classes of applications,
   including augmented reality, autonomous systems, robotics, and
   spatial computing, operate under a different assumption.  In these
   systems, discovery begins with physical presence and observer context
   rather than with a predefined name.

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





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


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

Abstract

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

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

Status of This Memo

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

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

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

   This Internet-Draft will expire on 24 July 2026.







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


Copyright Notice

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

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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Scope and Non-Goa

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

response_json:
[
  {
    "title": "Location-Based Resource Discovery",
    "description": "A discovery mechanism that uses physical location and observer context as the starting point for finding resources, rather than predefined identifiers. This enables applications to discover relevant digital resources based on where they are physically located.",
    "type": "mechanism"
  },
  {
    "title": "Spatial Query Interface",
    "description": "A query mechanism that allows clients to request resources based on geospatial parameters like coordinates, proximity, and spatial relationships. This differs from traditional name-based lookups by using geometric and geographic criteria.",
    "type": "mechanism"
  },
  {
    "title": "Observer Context Framework",
    "description": "A contextual framework that incorporates the observer's physical presence, orientation, and situational context into resource discovery. This enables personalized and contextually relevant resource identification.",
    "type": "architecture"
  },
  {
    "title": "Geospatial Resource Discovery Service",
    "description": "A network service architecture that bridges the gap between physical location and digital resource identification. It provides standardized mechanisms for spatial-based resource resolution complementing existing identifier-based systems.",
    "type": "architecture"
  },
  {
    "title": "Physical-to-Digital Mapping",
    "description": "A mechanism for creating associations between physical locations or objects and their corresponding digital resources. This enables the translation from spatial coordinates to network-accessible content or services.",
    "type": "mechanism"
  }
]


draft_name: draft-kompella-lsr-mptecap
prompt_hash: a2f9a34d515fa998
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:50:21.022646+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-kompella-lsr-mptecap | Multipath Traffic Engineering Capabilities | 6pg
Abstract: Multipath Traffic Engineering (MPTE) combines two approaches to
   traffic management: equal-cost multipath and constraint-based traffic
   engineering, offering a powerful new way to engineer networks.  To
   avail of this, a node (possibly an ingress of a MPTE tunnel, or a
   path computation agent) must have information about the topology,
   link and node characteristics of a network so that it can compute the
   components of the MPTE tunnel.  One important (node) characteristic
   is whether a given node supports MPTE, i.e., whether it can
   participate in the provisioning and maintenance of the tunnel.

   This memo shows how this information can be distributed in the IGP
   via Link State Routing TE Capabilities.





LSR WG                                                       K. Kompella
Internet-Draft                                          Juniper Networks
Updates: 5073 (if approved)                                  7 July 2025
Intended status: Standards Track                                        
Expires: 8 January 2026


               Multipath Traffic Engineering Capabilities
                     draft-kompella-lsr-mptecap-00

Abstract

   Multipath Traffic Engineering (MPTE) combines two approaches to
   traffic management: equal-cost multipath and constraint-based traffic
   engineering, offering a powerful new way to engineer networks.  To
   avail of this, a node (possibly an ingress of a MPTE tunnel, or a
   path computation agent) must have information about the topology,
   link and node characteristics of a network so that it can compute the
   components of the MPTE tunnel.  One important (node) characteristic
   is whether a given node supports MPTE, i.e., whether it can
   participate in the provisioning and maintenance of the tunnel.

   This memo shows how this information can be distributed in the IGP
   via Link State Routing TE Capabilities.

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.





Kompella                 Expires 8 January 2026                 [Page 1]

Internet-Draft                  MPTE Cap                       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.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
       1.1.1.  Definition of Commonly Used Terms . . . . . . . . . .   3
   2.  MPTE Capabilitie

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

response_json:
[
  {
    "title": "MPTE Node Capability Advertisement",
    "description": "A mechanism to advertise whether a node supports Multipath Traffic Engineering (MPTE) functionality via IGP extensions. This allows ingress nodes and path computation agents to identify which nodes can participate in MPTE tunnel provisioning and maintenance.",
    "type": "mechanism"
  },
  {
    "title": "Link State Routing TE Capabilities Extension",
    "description": "An extension to existing Link State Routing Traffic Engineering capabilities to carry MPTE-specific node characteristics. This builds upon RFC 5073 to distribute MPTE capability information through the IGP.",
    "type": "extension"
  },
  {
    "title": "MPTE Topology Discovery",
    "description": "A pattern for distributing network topology and node characteristics information required for computing MPTE tunnel components. This enables nodes to have sufficient information about network capabilities for multipath traffic engineering decisions.",
    "type": "pattern"
  },
  {
    "title": "Multipath Traffic Engineering Architecture",
    "description": "A hybrid approach combining equal-cost multipath and constraint-based traffic engineering for network traffic management. This architecture requires capability awareness across network nodes for effective tunnel computation and deployment.",
    "type": "architecture"
  }
]


draft_name: draft-kotecha-agentic-dispute-protocol
prompt_hash: 724a8af36aa74375
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:50:29.418302+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-kotecha-agentic-dispute-protocol | Agentic Dispute Protocol | 26pg
Abstract: This document specifies the Agentic Dispute Protocol (ADP), a
   standardized framework for autonomous agents and AI systems to file,
   process, and resolve disputes through structured, automated
   processes.  The protocol defines message formats, transport
   mechanisms, evidence submission standards, and cryptographic proof
   requirements for internet-native dispute resolution.

   ADP is designed to handle disputes arising from AI agent
   interactions, service level agreement breaches, and automated
   contract enforcement, providing deterministic, auditable, and legally
   enforceable outcomes.

   ADP includes chain of custody tracking, dual-format award
   specifications (JSON and PDF), arbitrator discovery mechanisms, and
   support for multiple resolution frameworks including expert
   determination, binding arbitration, mediation, and hybrid approaches.





Network Working Group                                         V. Kotecha
Internet-Draft                                           Consulate, Inc.
Intended status: Informational                           14 October 2025
Expires: 17 April 2026


                        Agentic Dispute Protocol
               draft-kotecha-agentic-dispute-protocol-00

Abstract

   This document specifies the Agentic Dispute Protocol (ADP), a
   standardized framework for autonomous agents and AI systems to file,
   process, and resolve disputes through structured, automated
   processes.  The protocol defines message formats, transport
   mechanisms, evidence submission standards, and cryptographic proof
   requirements for internet-native dispute resolution.

   ADP is designed to handle disputes arising from AI agent
   interactions, service level agreement breaches, and automated
   contract enforcement, providing deterministic, auditable, and legally
   enforceable outcomes.

   ADP includes chain of custody tracking, dual-format award
   specifications (JSON and PDF), arbitrator discovery mechanisms, and
   support for multiple resolution frameworks including expert
   determination, binding arbitration, mediation, and hybrid approaches.

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







Kotecha                   Expires 17 April 2026                 [Page 1]

Internet-Draft                     ADP                      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 warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Terminology . . . 

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

response_json:
[
  {
    "title": "ADP Message Format Standard",
    "description": "Standardized message formats for autonomous agents to file, process, and resolve disputes through structured communication. Defines specific JSON schemas and transport mechanisms for dispute-related communications.",
    "type": "protocol"
  },
  {
    "title": "Cryptographic Evidence Submission",
    "description": "Cryptographic proof requirements and standards for submitting evidence in automated dispute resolution. Ensures integrity and authenticity of evidence submitted by AI agents.",
    "type": "mechanism"
  },
  {
    "title": "Chain of Custody Tracking",
    "description": "Automated tracking mechanism that maintains an auditable chain of custody for evidence and documents throughout the dispute resolution process. Provides cryptographic proof of document handling.",
    "type": "mechanism"
  },
  {
    "title": "Dual-Format Award Specification",
    "description": "Awards and decisions are generated in both machine-readable JSON format and human-readable PDF format. Enables both automated processing and legal compliance requirements.",
    "type": "pattern"
  },
  {
    "title": "Arbitrator Discovery Protocol",
    "description": "Automated mechanism for AI agents to discover and select appropriate arbitrators or dispute resolution services. Includes capability matching and availability verification.",
    "type": "mechanism"
  },
  {
    "title": "Multi-Framework Resolution Support",
    "description": "Protocol extension supporting multiple dispute resolution approaches including expert determination, binding arbitration, mediation, and hybrid methods. Allows flexible resolution pathway selection.",
    "type": "extension"
  }
]


draft_name: draft-lake-pocero-authkem-edhoc
prompt_hash: a4d7f3514a2aa698
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:50:36.175330+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-lake-pocero-authkem-edhoc | KEM-based Authentication for EDHOC | 33pg
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.





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


                   KEM-based Authentication for EDHOC
                   draft-lake-pocero-authkem-edhoc-00

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.

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



Pocero Fraile, et al.     Expires 19 April 2026                 [Page 1]

Internet-Draft     KEM-based Authentication for EDHOC       October 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  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Motivation  . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Terminology and Requirements Language . . . . . . . . . .   5
       1.2.1.  Key Encapsulation Mechanisms (KEMs) . . . . . . . . .   5
   2.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .   6
     2.1.  Protocol Elements 

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

response_json:
[
  {
    "title": "KEM-based Authentication for EDHOC",
    "description": "Extension to EDHOC protocol that replaces signature-based authentication with Key Encapsulation Mechanism (KEM) operations for post-quantum security. Enables signature-free authentication using PQC KEMs like ML-KEM.",
    "type": "extension"
  },
  {
    "title": "Post-Quantum EDHOC Protocol",
    "description": "Modified EDHOC protocol that incorporates Post-Quantum Cryptography mechanisms for both key exchange and authentication to provide resistance against quantum computer adversaries. Maintains EDHOC's lightweight design while adding quantum resistance.",
    "type": "protocol"
  },
  {
    "title": "Signature-Free PQC Authentication",
    "description": "Authentication method that eliminates the need for post-quantum digital signatures by using KEM operations instead. Reduces computational and communication overhead compared to PQC signature schemes.",
    "type": "mechanism"
  },
  {
    "title": "ML-KEM Integration",
    "description": "Specific integration of NIST-standardized ML-KEM (Module-Lattice-based KEM) into the EDHOC authentication flow. Provides concrete post-quantum security using standardized cryptographic primitives.",
    "type": "mechanism"
  },
  {
    "title": "Quantum-Resistant Key Exchange",
    "description": "Combined approach using both traditional ECDH and post-quantum KEMs for key establishment. Provides hybrid security that protects against both classical and quantum attacks.",
    "type": "mechanism"
  }
]


draft_name: draft-lake-pocero-authkem-ikr-edhoc
prompt_hash: 304da2d3f41fa021
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:50:43.547183+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-lake-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: 12 July 2026                                      E. Haleplidis
                                                        ISI, R.C. ATHENA
                                                          8 January 2026


 KEM-based Authentication for EDHOC in Initiator-Known Responder (IKR)
                               Scenarios
                 draft-lake-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 12 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 12 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 protocol optimized for scenarios where the Initiator already knows the Responder's credentials. This eliminates the need for a fourth message while maintaining mutual authentication.",
    "type": "protocol"
  },
  {
    "title": "KEM-based Authentication for EDHOC",
    "description": "Authentication mechanism that replaces traditional signatures with Key Encapsulation Mechanism operations in EDHOC protocol. Enables post-quantum security when using PQC KEMs like ML-KEM while maintaining signature-free operation.",
    "type": "mechanism"
  },
  {
    "title": "Initiator-Known Responder (IKR) Scenario",
    "description": "A specific deployment pattern for constrained environments where the protocol initiator has prior knowledge of the responder's credentials. This allows for protocol optimizations that reduce message overhead.",
    "type": "pattern"
  },
  {
    "title": "Post-Quantum KEM Integration",
    "description": "Integration of NIST-standardized ML-KEM and other post-quantum cryptography KEMs into the EDHOC lightweight protocol. Provides quantum-resistant authentication without requiring digital signatures.",
    "type": "extension"
  },
  {
    "title": "Forward Secrecy with Identity Protection",
    "description": "Security mechanism that ensures both forward secrecy of session keys and partial identity protection for communicating parties. Maintained even in the optimized three-message handshake variant.",
    "type": "mechanism"
  }
]


draft_name: draft-lenders-core-dnr
prompt_hash: 0cd3fbd1886f83ad
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:50:49.288420+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-lenders-core-dnr | Discovery of Network-designated OSCORE-based Resolvers: Problem Statement | 12pg
Abstract: This document states problems when designing DNS SVCB records to
   discover endpoints that communicate over Object Security for
   Constrained RESTful Environments (OSCORE) [RFC8613].  As a
   consequence of learning about OSCORE, this discovery will allow a
   host to learn both CoAP servers and DNS over CoAP resolvers that use
   OSCORE to encrypt messages and Ephemeral Diffie-Hellman Over COSE
   (EDHOC) [RFC9528] for key exchange.  Challenges arise because SVCB
   records are not meant to be used to exchange security contexts, which
   is required in OSCORE scenarios.





Constrained RESTful Environments                           M. S. Lenders
Internet-Draft                                                TU Dresden
Intended status: Informational                                 C. Amsüss
Expires: 8 January 2026                                                 
                                                           T. C. Schmidt
                                                             HAW Hamburg
                                                             M. Wählisch
                                        TU Dresden & Barkhausen Institut
                                                             7 July 2025


    Discovery of Network-designated OSCORE-based Resolvers: Problem
                               Statement
                       draft-lenders-core-dnr-06

Abstract

   This document states problems when designing DNS SVCB records to
   discover endpoints that communicate over Object Security for
   Constrained RESTful Environments (OSCORE) [RFC8613].  As a
   consequence of learning about OSCORE, this discovery will allow a
   host to learn both CoAP servers and DNS over CoAP resolvers that use
   OSCORE to encrypt messages and Ephemeral Diffie-Hellman Over COSE
   (EDHOC) [RFC9528] for key exchange.  Challenges arise because SVCB
   records are not meant to be used to exchange security contexts, which
   is required in OSCORE scenarios.

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://netd-
   tud.github.io/draft-lenders-core-oscore-svcb/draft-lenders-core-
   dnr.html.  Status information for this document may be found at
   https://datatracker.ietf.org/doc/draft-lenders-core-dnr/.

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

   Source for this draft and an issue tracker can be found at
   https://github.com/netd-tud/draft-lenders-core-oscore-svcb.

Status of This Memo

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



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

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

response_json:
[
  {
    "title": "OSCORE Discovery via DNS SVCB",
    "description": "Using DNS SVCB records to discover endpoints that communicate using OSCORE for secure CoAP communications. This enables hosts to learn about CoAP servers and DNS over CoAP resolvers that use OSCORE encryption.",
    "type": "mechanism"
  },
  {
    "title": "EDHOC Key Exchange Discovery",
    "description": "Discovery mechanism for endpoints that use Ephemeral Diffie-Hellman Over COSE (EDHOC) for key exchange in conjunction with OSCORE. This allows hosts to identify resolvers supporting this key establishment method.",
    "type": "mechanism"
  },
  {
    "title": "Security Context Exchange Limitation",
    "description": "Technical challenge where SVCB records cannot be used to exchange security contexts required for OSCORE scenarios. This represents a fundamental limitation in using standard SVCB records for secure discovery.",
    "type": "requirement"
  },
  {
    "title": "DNS over CoAP Resolver Discovery",
    "description": "Discovery pattern for DNS resolvers that operate over CoAP protocol with OSCORE security. This enables identification of constrained environment DNS resolvers with appropriate security mechanisms.",
    "type": "pattern"
  }
]


draft_name: draft-leon-distributed-multi-signer
prompt_hash: 88e7df7b6664eaef
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:50:56.964139+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-leon-distributed-multi-signer | Distributed DNSSEC Multi-Signer Bootstrap | 31pg
Abstract: This document presents an architecture for a distributed DNSSEC
   multi-signer model that most closely resembles "model 2" in
   [RFC8901].

   It defines two multi-signer specific entities: the "multi-signer
   agent" (MSA) that is responsible for the multi-signer process and the
   "combiner", which is responsible for "combining" unsigned zone data
   from the zone owner with zone data under control of the MSA.  It
   introduces a new DNS RRtype, HSYNC, that is used by the zone owner to
   designate the chosen DNS Providers (signing and/or serving the zone).
   Furthermore it describes a mechanism for the MSAs to establish secure
   communication with each other, either via “pure DNS” communication
   secured by DNS SIG(0) signatures on each message or via a RESTful API
   secured by TLS.  Finally, the document describes two models for
   multi-signer process synchronization: “leader/follower mode” and
   “peer mode” and the mechanism by which a set of MSAs decide which
   model to use for a given zone.

   The scope of the document is only the distributed aspect of DNSSEC
   multi-signer up to the point where secure communication and
   synchronization method between MSAs has been established.  The
   “multi-signer algorithms” that deal with the actual synchronization
   required for multi-signer operation are described in
   [I-D.draft-ietf-dnsop-dnssec-automation].

   TO BE REMOVED: This document is being collaborated on in Github at:
   https://github.com/johanix/draft-leon-dnsop-distributed-multi-signer
   (https://github.com/johanix/draft-leon-dnsop-distributed-multi-
   signer).  The most recent working version of the document, open
   issues, etc, should all be available there.  The authors (gratefully)
   accept pull requests.





DNSOP Working Group                                         L. Fernandez
Internet-Draft                                              E. Bergström
Intended status: Standards Track                             J. Stenstam
Expires: 11 August 2025                  The Swedish Internet Foundation
                                                              S. Crocker
                                             Edgemoor Research Institute
                                                         7 February 2025


               Distributed DNSSEC Multi-Signer Bootstrap
                 draft-leon-distributed-multi-signer-00

Abstract

   This document presents an architecture for a distributed DNSSEC
   multi-signer model that most closely resembles "model 2" in
   [RFC8901].

   It defines two multi-signer specific entities: the "multi-signer
   agent" (MSA) that is responsible for the multi-signer process and the
   "combiner", which is responsible for "combining" unsigned zone data
   from the zone owner with zone data under control of the MSA.  It
   introduces a new DNS RRtype, HSYNC, that is used by the zone owner to
   designate the chosen DNS Providers (signing and/or serving the zone).
   Furthermore it describes a mechanism for the MSAs to establish secure
   communication with each other, either via “pure DNS” communication
   secured by DNS SIG(0) signatures on each message or via a RESTful API
   secured by TLS.  Finally, the document describes two models for
   multi-signer process synchronization: “leader/follower mode” and
   “peer mode” and the mechanism by which a set of MSAs decide which
   model to use for a given zone.

   The scope of the document is only the distributed aspect of DNSSEC
   multi-signer up to the point where secure communication and
   synchronization method between MSAs has been established.  The
   “multi-signer algorithms” that deal with the actual synchronization
   required for multi-signer operation are described in
   [I-D.draft-ietf-dnsop-dnssec-automation].

   TO BE REMOVED: This document is being collaborated on in Github at:
   https://github.com/johanix/draft-leon-dnsop-distributed-multi-signer
   (https://github.com/johanix/draft-leon-dnsop-distributed-multi-
   signer).  The most recent working version of the document, open
   issues, etc, should all be available there.  The authors (gratefully)
   accept pull requests.






Fernandez, et al.        Expires 11 August 2025                 [Page 1]

Internet-Draft     Distributed Multi-Signer Bootstrap      February 2025


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 document

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

response_json:
[
  {
    "title": "Multi-Signer Agent (MSA)",
    "description": "A dedicated entity responsible for managing the multi-signer process in distributed DNSSEC environments. The MSA handles coordination between multiple DNS providers and maintains secure communication channels.",
    "type": "architecture"
  },
  {
    "title": "Combiner Component",
    "description": "A specialized component that combines unsigned zone data from the zone owner with zone data under control of the MSA. It serves as the integration point for merging zone content in multi-signer scenarios.",
    "type": "architecture"
  },
  {
    "title": "HSYNC DNS Resource Record Type",
    "description": "A new DNS RRtype used by zone owners to designate their chosen DNS providers for signing and/or serving zones. It provides a standardized way to signal multi-signer configuration.",
    "type": "extension"
  },
  {
    "title": "DNS SIG(0) Secured Communication",
    "description": "A pure DNS communication mechanism where MSAs exchange messages secured using DNS SIG(0) signatures. This enables secure coordination without requiring external protocols.",
    "type": "mechanism"
  },
  {
    "title": "RESTful API with TLS Security",
    "description": "An alternative secure communication channel for MSAs using RESTful APIs protected by TLS. This provides a web-based approach for MSA coordination alongside the DNS-native option.",
    "type": "protocol"
  },
  {
    "title": "Leader/Follower and Peer Synchronization Modes",
    "description": "Two distinct models for multi-signer process synchronization with a defined mechanism for MSAs to collectively decide which model to use for a given zone. This provides flexibility in coordination strategies.",
    "type": "pattern"
  }
]


draft_name: draft-levy-llm-uri-scheme
prompt_hash: bb73a610c686fb1d
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:51:02.083023+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-levy-llm-uri-scheme | The "llm" URI Scheme | 17pg
Abstract: This document defines the "llm" Uniform Resource Identifier (URI)
   scheme for identifying Large Language Model (LLM) endpoints and their
   configuration.  The scheme encodes provider host, model identifier,
   authentication credentials, and inference parameters into a single,
   portable connection string, analogous to database connection URIs
   such as those used by PostgreSQL and MongoDB.

   This document registers the scheme name in the IANA "Uniform Resource
   Identifier (URI) Schemes" registry as a provisional registration per
   RFC 7595.





Individual Submission                                            D. Levy
Internet-Draft                                        DanLevy Consulting
Intended status: Informational                           6 February 2026
Expires: 10 August 2026


                          The "llm" URI Scheme
                      draft-levy-llm-uri-scheme-00

Abstract

   This document defines the "llm" Uniform Resource Identifier (URI)
   scheme for identifying Large Language Model (LLM) endpoints and their
   configuration.  The scheme encodes provider host, model identifier,
   authentication credentials, and inference parameters into a single,
   portable connection string, analogous to database connection URIs
   such as those used by PostgreSQL and MongoDB.

   This document registers the scheme name in the IANA "Uniform Resource
   Identifier (URI) Schemes" registry as a provisional registration per
   RFC 7595.

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



Levy                     Expires 10 August 2026                 [Page 1]

Internet-Draft               LLM URI Scheme                February 2026


   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  . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Relationship to Other Work  . . . . . . . . . . . . . . .   4
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  URI Syntax  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  The "llm" Scheme  . . . . . . . . . . . . . . . . . . . .   4
     3.2.  ABNF  . . . . . . . . . . . . . . . . . . . . . . . 

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

response_json:
[
  {
    "title": "LLM URI Scheme",
    "description": "A new URI scheme 'llm://' for identifying Large Language Model endpoints and their configuration. Encodes provider host, model identifier, authentication credentials, and inference parameters into a single portable connection string.",
    "type": "protocol"
  },
  {
    "title": "LLM Connection String Format",
    "description": "A standardized format analogous to database connection URIs (like PostgreSQL and MongoDB) for LLM endpoints. Provides a portable way to specify complete LLM connection and configuration information.",
    "type": "mechanism"
  },
  {
    "title": "LLM URI Parameter Encoding",
    "description": "Method for encoding inference parameters and authentication credentials directly within the URI structure. Allows complete LLM configuration to be expressed in a single string.",
    "type": "pattern"
  },
  {
    "title": "IANA URI Scheme Registration",
    "description": "Provisional registration of the 'llm' scheme name in the IANA Uniform Resource Identifier Schemes registry. Follows RFC 7595 registration procedures for new URI schemes.",
    "type": "requirement"
  }
]


draft_name: draft-li-dmsc-inf-architecture
prompt_hash: ae97df8fdfb85b6b
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:51:09.764657+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-li-dmsc-inf-architecture | Dynamic Multi-agent Secured Collaboration Infrastructure Architecture | 11pg
Abstract: This document presents an architectural framework for dynamic multi-
   agent collaboration from an infrastructure perspective.  It outlines
   the network requirements introduced by large-scale agents
   collaboration, and proposes a systematic approach to enabling Dynamic
   Multi-agent Secured Collaboration (DMSC) through infrastructure
   capabilities.  The architecture focuses on how network control and
   forwarding functions can actively participate in agent collaboration.





DMSC Working Group                                                 X. Li
Internet-Draft                                                   A. Wang
Intended status: Standards Track                           China Telecom
Expires: 9 August 2026                                   5 February 2026


 Dynamic Multi-agent Secured Collaboration Infrastructure Architecture
                   draft-li-dmsc-inf-architecture-05

Abstract

   This document presents an architectural framework for dynamic multi-
   agent collaboration from an infrastructure perspective.  It outlines
   the network requirements introduced by large-scale agents
   collaboration, and proposes a systematic approach to enabling Dynamic
   Multi-agent Secured Collaboration (DMSC) through infrastructure
   capabilities.  The architecture focuses on how network control and
   forwarding functions can actively participate in agent collaboration.

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

Copyright Notice

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











Li & Wang                 Expires 9 August 2026                 [Page 1]

Internet-Draft              DMSC Architecture              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.  Conventions used in this document . . . . . . . . . . . . . .   3
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Network Requirements  . . . . . . . . . . . . . . . . . . . .   4
   5.  DMSC Architecture Overview  . . . . . . . . . . . . . . . . .   4
     5.1.  DMSC Infrastructure Architecture  . . . . . . . . . . . .   5
   6.  Infrastructure Functions Enabling Active Network

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

response_json:
[
  {
    "title": "DMSC Infrastructure Architecture",
    "description": "A systematic architectural framework that enables network control and forwarding functions to actively participate in multi-agent collaboration. The architecture focuses on infrastructure-level capabilities rather than application-level coordination.",
    "type": "architecture"
  },
  {
    "title": "Active Network Participation",
    "description": "A mechanism where network infrastructure components (control and forwarding functions) actively engage in agent collaboration rather than passively routing traffic. This enables the network to become a collaborative participant in multi-agent systems.",
    "type": "mechanism"
  },
  {
    "title": "Large-scale Agent Collaboration Requirements",
    "description": "Network requirements specifically identified for enabling collaboration between large numbers of agents. These requirements drive the need for specialized infrastructure capabilities beyond traditional networking.",
    "type": "requirement"
  },
  {
    "title": "Dynamic Multi-agent Secured Collaboration (DMSC) Protocol",
    "description": "A systematic approach and protocol framework for enabling secure collaboration between dynamically changing sets of agents. The protocol integrates security mechanisms with dynamic collaboration patterns.",
    "type": "protocol"
  },
  {
    "title": "Infrastructure Functions for Active Networks",
    "description": "Specific network functions that enable infrastructure to actively participate in agent collaboration workflows. These functions extend beyond traditional packet forwarding to include collaboration-aware processing.",
    "type": "extension"
  }
]


draft_name: draft-li-dmsc-macp
prompt_hash: b318e78a19962055
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:51:16.622663+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-li-dmsc-macp | Multi-agent Collaboration Protocol Suite | 21pg
Abstract: This document specifies a Multi-agent Collaboration Protocol Suite
   based on Agent Gateway, which enables scalable, secure, and
   semantically driven collaboration among distributed agents across
   heterogeneous networks.  The protocol suite introduces Agent Gateways
   as key entities responsible for agent registration, authentication,
   capability management and other functions, while preserving direct
   peer-to-peer semantic interactions among agents.





DMSC Working Group                                                 X. Li
Internet-Draft                                             China Telecom
Intended status: Standards Track                                  J. Liu
Expires: 30 August 2026Beijing University of Posts and Telecommunications
                                                                   C. Du
                                                 Zhongguancun Laboratory
                                                                L. Zhang
                                       AsiaInfo Technologies (China) Inc
                                                        26 February 2026


                Multi-agent Collaboration Protocol Suite
                         draft-li-dmsc-macp-01

Abstract

   This document specifies a Multi-agent Collaboration Protocol Suite
   based on Agent Gateway, which enables scalable, secure, and
   semantically driven collaboration among distributed agents across
   heterogeneous networks.  The protocol suite introduces Agent Gateways
   as key entities responsible for agent registration, authentication,
   capability management and other functions, while preserving direct
   peer-to-peer semantic interactions among 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 30 August 2026.

Copyright Notice

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






Li, et al.               Expires 30 August 2026                 [Page 1]

Internet-Draft                    MACP                     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.  Conventions used in this document . . . . . . . . . . . . . .   3
   3.  Terminology . . . 

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

response_json:
[
  {
    "title": "Agent Gateway",
    "description": "A key entity that serves as an intermediary for agent registration, authentication, and capability management. It enables scalable collaboration while preserving direct peer-to-peer semantic interactions among agents.",
    "type": "architecture"
  },
  {
    "title": "Multi-agent Collaboration Protocol Suite",
    "description": "A protocol suite that enables distributed agents to collaborate across heterogeneous networks through gateway-mediated coordination. It provides semantically driven interactions between agents in different network domains.",
    "type": "protocol"
  },
  {
    "title": "Gateway-mediated Agent Registration",
    "description": "A mechanism where agents register their capabilities and presence through Agent Gateways. This enables discovery and coordination of distributed agents across network boundaries.",
    "type": "mechanism"
  },
  {
    "title": "Capability Management System",
    "description": "A system for managing and advertising agent capabilities through the gateway infrastructure. It allows agents to discover and utilize services provided by other agents in the collaboration network.",
    "type": "mechanism"
  },
  {
    "title": "Semantic-driven Direct P2P Interactions",
    "description": "A pattern where agents can engage in direct peer-to-peer communication using semantic protocols after initial gateway-mediated discovery. This preserves efficiency while maintaining the benefits of gateway coordination.",
    "type": "pattern"
  }
]


draft_name: draft-li-dmsc-mcps-agw
prompt_hash: a525013b1a45e098
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:51:23.178129+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-li-dmsc-mcps-agw | Multi-agent Collaboration Protocol Suite based on Agent Gateway | 7pg
Abstract: This document specifies a Multi-agent Collaboration Protocol Suite
   based on Agent Gateway, which enables scalable, secure, and
   semantically driven collaboration among distributed agents across
   heterogeneous networks.  The protocol suite introduces Agent Gateways
   as control-plane entities responsible for agent registration,
   authentication, capability management, semantic routing and other
   functions, while preserving direct peer-to-peer semantic interactions
   among agents.





DMSC Working Group                                                 X. Li
Internet-Draft                                             China Telecom
Intended status: Standards Track                         5 February 2026
Expires: 9 August 2026


    Multi-agent Collaboration Protocol Suite based on Agent Gateway
                       draft-li-dmsc-mcps-agw-00

Abstract

   This document specifies a Multi-agent Collaboration Protocol Suite
   based on Agent Gateway, which enables scalable, secure, and
   semantically driven collaboration among distributed agents across
   heterogeneous networks.  The protocol suite introduces Agent Gateways
   as control-plane entities responsible for agent registration,
   authentication, capability management, semantic routing and other
   functions, while preserving direct peer-to-peer semantic interactions
   among 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 9 August 2026.

Copyright Notice

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










Li                        Expires 9 August 2026                 [Page 1]

Internet-Draft                  MCPS-AGW                   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.  Conventions used in this document . . . . . . . . . . . . . .   3
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Multi-Agent Collaboration Protocol Suite Overview . . . . . .   3
     4.1.  Agent Registration and Authorization Process  . . . . . .   5
     4.2.  Capability Digest and Synchronization Process . . . . . .   5
     4.3.  Semantic Resolution and Routing Process . . . . . . . . .   6
     4.4.  Task-based Multi-A

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

response_json:
[
  {
    "title": "Agent Gateway Control Plane",
    "description": "Centralized control-plane entities that handle agent registration, authentication, capability management, and semantic routing while allowing direct peer-to-peer interactions between agents. Agent Gateways act as intermediaries for control functions without interfering with data plane communications.",
    "type": "architecture"
  },
  {
    "title": "Agent Registration and Authorization Process",
    "description": "Standardized process for agents to register with Agent Gateways and obtain authorization credentials. Enables secure onboarding of distributed agents across heterogeneous networks.",
    "type": "protocol"
  },
  {
    "title": "Capability Digest and Synchronization",
    "description": "Mechanism for agents to advertise their capabilities to Agent Gateways and synchronize capability information across the network. Enables efficient capability discovery and matching for collaboration.",
    "type": "mechanism"
  },
  {
    "title": "Semantic Resolution and Routing",
    "description": "Protocol for Agent Gateways to perform semantic-based routing of agent requests and resolve semantic queries to appropriate target agents. Enables intelligent routing based on agent capabilities and semantic context.",
    "type": "protocol"
  },
  {
    "title": "Task-based Multi-Agent Coordination",
    "description": "Framework for coordinating multiple agents to collaborate on complex tasks while maintaining direct peer-to-peer semantic interactions. Preserves agent autonomy while enabling structured collaboration patterns.",
    "type": "pattern"
  }
]


draft_name: draft-li-semantic-routing-architecture
prompt_hash: ecf7866e6658cb0e
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:51:30.346382+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-li-semantic-routing-architecture | Semantic Routing Architecture for AI Agents Communication | 11pg
Abstract: This document introduces an Semantic Routing (SR) Architecture for
   enabling intelligent, semantic-driven communication among AI Agents.
   Unlike traditional IP-based routing or service mesh approaches, SRA
   leverages application-layer semantics — including service identity,
   intent vectors, and trust scores — to guide routing decisions
   dynamically.  The architecture supports intent-driven task
   collaboration, trust-aware policy enforcement, and adaptive routing
   for multi-agent environments.  SRA enables the network to evolve from
   a passive transport layer to an intelligent collaboration substrate
   supporting multi-agent coordination and cognitive networking.





Working Group                                                      X. Li
Internet-Draft                                                   A. Wang
Intended status: Standards Track                           China Telecom
Expires: 8 May 2026                                      4 November 2025


       Semantic Routing Architecture for AI Agents Communication
               draft-li-semantic-routing-architecture-00

Abstract

   This document introduces an Semantic Routing (SR) Architecture for
   enabling intelligent, semantic-driven communication among AI Agents.
   Unlike traditional IP-based routing or service mesh approaches, SRA
   leverages application-layer semantics — including service identity,
   intent vectors, and trust scores — to guide routing decisions
   dynamically.  The architecture supports intent-driven task
   collaboration, trust-aware policy enforcement, and adaptive routing
   for multi-agent environments.  SRA enables the network to evolve from
   a passive transport layer to an intelligent collaboration substrate
   supporting multi-agent coordination and cognitive networking.

Status of This Memo

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

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

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

   This Internet-Draft will expire on 8 May 2026.

Copyright Notice

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

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



Li & Wang                  Expires 8 May 2026                   [Page 1]

Internet-Draft               SR Architecture               November 2025


   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions used in this document . . . . . . . . . . . . . .   4
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Architecture Overview . . . . . . . . . . . . . . . . . . . .   4
   5.  Fun

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

response_json:
[
  {
    "title": "Intent Vector Routing",
    "description": "Uses multi-dimensional vectors representing AI agent intentions and capabilities to make routing decisions. Enables semantic matching between agent requests and available services based on intent similarity.",
    "type": "mechanism"
  },
  {
    "title": "Trust Score-based Policy Enforcement",
    "description": "Incorporates dynamic trust scores into routing decisions to enforce security policies. Trust scores are calculated based on agent behavior and used to determine communication permissions.",
    "type": "mechanism"
  },
  {
    "title": "Application-layer Semantic Routing",
    "description": "Routes traffic based on semantic understanding of service identity, intent, and context rather than traditional IP addresses. Operates above the transport layer to enable intelligent path selection.",
    "type": "architecture"
  },
  {
    "title": "Adaptive Multi-agent Routing",
    "description": "Dynamically adjusts routing decisions based on changing agent capabilities and network conditions. Supports real-time adaptation for multi-agent collaborative environments.",
    "type": "mechanism"
  },
  {
    "title": "Cognitive Networking Substrate",
    "description": "Transforms the network from passive transport to an intelligent collaboration layer that understands agent communication patterns. Enables the network infrastructure to participate in multi-agent coordination.",
    "type": "architecture"
  }
]


draft_name: draft-liang-agentdns
prompt_hash: 52af9ac23c689703
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:51:37.616380+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-liang-agentdns | AgentDNS: A Root Domain Naming System for LLM Agents | 22pg
Abstract: This document describes AgentDNS, a root domain naming and service
   discovery system designed for Large Language Model (LLM) agents.
   Inspired by the traditional Domain Name System (DNS), AgentDNS
   enables agents to autonomously discover, resolve, and securely invoke
   third-party agent and tool services across different vendors.
   AgentDNS introduces a unified namespace, semantic service discovery,
   protocol-aware interoperability, and unified authentication and
   billing.  The system aims to address interoperability, service
   discovery, and trust management challenges in large-scale agent
   collaboration ecosystems.





Internet Engineering Task Force                            Z. Liang, Ed.
Internet-Draft                                                    E. Cui
Intended status: Informational          China Telecom Research Institute
Expires: 12 April 2026                                          Y. Cheng
                            University of Science and Technology Beijing
                                                          9 October 2025


          AgentDNS: A Root Domain Naming System for LLM Agents
                        draft-liang-agentdns-00

Abstract

   This document describes AgentDNS, a root domain naming and service
   discovery system designed for Large Language Model (LLM) agents.
   Inspired by the traditional Domain Name System (DNS), AgentDNS
   enables agents to autonomously discover, resolve, and securely invoke
   third-party agent and tool services across different vendors.
   AgentDNS introduces a unified namespace, semantic service discovery,
   protocol-aware interoperability, and unified authentication and
   billing.  The system aims to address interoperability, service
   discovery, and trust management challenges in large-scale agent
   collaboration ecosystems.

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

Copyright Notice

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






Liang, et al.             Expires 12 April 2026                 [Page 1]

Internet-Draft              Abbreviated Title               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.  Related Work  . . . . . . . . . . . . . . . . . . . . . . . .   5
   3.  AgentDNS Architecture . . . . . . . . . . . . . . . . . .

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

response_json:
[
  {
    "title": "AgentDNS Hierarchical Namespace",
    "description": "A DNS-inspired hierarchical naming system specifically designed for LLM agents and their services. Uses domain-like structure to organize agent services across different vendors.",
    "type": "architecture"
  },
  {
    "title": "Semantic Service Discovery",
    "description": "Discovery mechanism that allows agents to find services based on semantic descriptions rather than exact names. Enables autonomous service location for LLM agents.",
    "type": "mechanism"
  },
  {
    "title": "Protocol-Aware Interoperability",
    "description": "System that understands and mediates between different agent communication protocols. Enables cross-vendor agent collaboration by handling protocol differences.",
    "type": "mechanism"
  },
  {
    "title": "Unified Authentication and Billing",
    "description": "Single authentication and billing framework for agent service invocations across multiple vendors. Provides trust management for large-scale agent ecosystems.",
    "type": "mechanism"
  },
  {
    "title": "Agent Service Resolution Protocol",
    "description": "DNS-like resolution protocol adapted for agent services that maps agent service names to callable endpoints. Supports autonomous service invocation by LLM agents.",
    "type": "protocol"
  }
]


draft_name: draft-liu-access-collaboration-agent
prompt_hash: 8f0bb1426a80064f
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:51:43.652129+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-liu-access-collaboration-agent | Ubiquitous Access Collaboration Requirements for AI Agent Protocols | 6pg
Abstract: This document focuses on the ubiquitous access collaboration
   scenarios, explores the requirements for AI agent communication
   protocols.





Network Working Group                                        W. Liu, Ed.
Internet-Draft                                             Y. Zhang, Ed.
Intended status: Standards Track                            China Unicom
Expires: 20 April 2026                                   17 October 2025


  Ubiquitous Access Collaboration Requirements for AI Agent Protocols
                draft-liu-access-collaboration-agent-00

Abstract

   This document focuses on the ubiquitous access collaboration
   scenarios, explores the requirements for AI 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 20 April 2026.

Copyright Notice

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

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






Liu & Zhang               Expires 20 April 2026                 [Page 1]

Internet-Draft  Ubiquitous Access Collaboration Requirem    October 2025


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
   3.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Remote Care . . . . . . . . . . . . . . . . . . . . . . .   3
     3.2.  Remote Work . . . . . . . . . . . . . . . . . . . . . . .   3
     3.3.  Multi Access Collaboration  . . . . . . . . . . . . . . .   4
   4.  Requirement . . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  Identity Authentication and Request Verification  . . . .   4
     4.2.  Service Discovery and Automatic Negotiation . . . . . . .   4
     4.3.  Unified Communication Protocol  . . . . . . . . . . . . .   5
     4.4.  Connection Stability and Seamless Handover  . . . . . . .   5
     4.5.  Local Disaster Recovery a

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

response_json:
[
  {
    "title": "Identity Authentication and Request Verification",
    "description": "Authentication mechanism for verifying AI agent identities and validating requests in ubiquitous access scenarios. Ensures secure agent-to-agent communication across different access networks.",
    "type": "mechanism"
  },
  {
    "title": "Service Discovery and Automatic Negotiation",
    "description": "Protocol mechanism enabling AI agents to automatically discover available services and negotiate capabilities. Facilitates dynamic service binding in multi-access collaboration environments.",
    "type": "protocol"
  },
  {
    "title": "Unified Communication Protocol",
    "description": "Single protocol standard for AI agent communication across heterogeneous networks and devices. Abstracts underlying network differences to enable seamless agent collaboration.",
    "type": "protocol"
  },
  {
    "title": "Connection Stability and Seamless Handover",
    "description": "Mechanism to maintain stable connections and enable seamless handover between different access networks. Ensures continuous AI agent collaboration during network transitions.",
    "type": "mechanism"
  },
  {
    "title": "Multi Access Collaboration Pattern",
    "description": "Architectural pattern enabling AI agents to collaborate across multiple access technologies simultaneously. Supports scenarios where agents operate through different network access methods.",
    "type": "pattern"
  }
]


draft_name: draft-liu-agent-context-protocol
prompt_hash: 8724e43c429d6b11
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:51:42.633441+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-liu-agent-context-protocol | Agent Context Protocol | 8pg
Abstract: This specification defines a standard message and protocol for
   communicating Agent Context information between AI agents.





Internet Engineering Task Force                              D. Liu, Ed.
Internet-Draft                                                   Alibaba
Intended status: Standards Track                            23 July 2025
Expires: 24 January 2026


                         Agent Context Protocol
                  draft-liu-agent-context-protocol-00

Abstract

   This specification defines a standard message and protocol for
   communicating Agent Context information between AI 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 24 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.







Liu                      Expires 24 January 2026                [Page 1]

Internet-Draft              Abbreviated Title                  July 2025


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   2
   2.  Architecture of Agent Context Protocol  . . . . . . . . . . .   3
   3.  Agent Context Message . . . . . . . . . . . . . . . . . . . .   5
   4.  Agent Context Protocol  . . . . . . . . . . . . . . . . . . .   7
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   8
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .   8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   In addition to data and con

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

response_json:
[
  {
    "title": "Agent Context Protocol",
    "description": "A standardized protocol for communicating context information between AI agents. Defines message formats and communication patterns for agent-to-agent context sharing.",
    "type": "protocol"
  },
  {
    "title": "Agent Context Message Format",
    "description": "A structured message format for encoding and transmitting context information between AI agents. Provides standardized fields and data structures for context exchange.",
    "type": "mechanism"
  },
  {
    "title": "Multi-Agent Context Architecture",
    "description": "An architectural framework defining how AI agents can share and maintain context information across distributed systems. Establishes the overall system design for agent context communication.",
    "type": "architecture"
  }
]


draft_name: draft-liu-agent-operation-authorization
prompt_hash: 88019918a67198e3
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:51:50.724101+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-liu-agent-operation-authorization | Agent Operation Authorization | 15pg
Abstract: This document specifies the Agent Operation Authorization framework —
   a structured mechanism that enables verifiable delegation of actions
   from human principals to autonomous AI agents with fine-grained agent
   operation authorization.

   The framework introduces two distinct phases:

   *  *Agent Operation Authorization Request:* A human-readable proposal
      of operations derived from natural language input and converted to
      a JSON Web Token (JWT).

   *  *Agent Operation Authorization Token:* A JSON Web Token
      representing confirmed authorization for a specific agent
      operation, enforceable at runtime by agents and verifiers.  It
      cryptographically verifies user intent, prevents unauthorized or
      hallucinated actions, and ensures auditable traceability of each
      authorized operation.





oauth                                                             D. Liu
Internet-Draft                                                    H. Zhu
Intended status: Standards Track                                 Alibaba
Expires: 29 May 2026                                    25 November 2025


                     Agent Operation Authorization
               draft-liu-agent-operation-authorization-00

Abstract

   This document specifies the Agent Operation Authorization framework —
   a structured mechanism that enables verifiable delegation of actions
   from human principals to autonomous AI agents with fine-grained agent
   operation authorization.

   The framework introduces two distinct phases:

   *  *Agent Operation Authorization Request:* A human-readable proposal
      of operations derived from natural language input and converted to
      a JSON Web Token (JWT).

   *  *Agent Operation Authorization Token:* A JSON Web Token
      representing confirmed authorization for a specific agent
      operation, enforceable at runtime by agents and verifiers.  It
      cryptographically verifies user intent, prevents unauthorized or
      hallucinated actions, and ensures auditable traceability of each
      authorized operation.

Status of This Memo

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

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

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

   This Internet-Draft will expire on 29 May 2026.






Liu & Zhu                  Expires 29 May 2026                  [Page 1]

Internet-Draft        Agent Operation Authorization        November 2025


Copyright Notice

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

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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
   3.  agent_opera

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

response_json:
[
  {
    "title": "Agent Operation Authorization Request",
    "description": "A mechanism to convert natural language input into human-readable operation proposals formatted as JSON Web Tokens. This enables structured representation of intended agent actions before authorization.",
    "type": "mechanism"
  },
  {
    "title": "Agent Operation Authorization Token",
    "description": "A JWT-based token that represents cryptographically verified authorization for specific agent operations. The token is enforceable at runtime by agents and verifiers to prevent unauthorized actions.",
    "type": "mechanism"
  },
  {
    "title": "Two-Phase Authorization Framework",
    "description": "A structured approach separating operation proposal (request phase) from confirmed authorization (token phase). This enables human review and approval before granting execution permissions to autonomous agents.",
    "type": "architecture"
  },
  {
    "title": "Fine-Grained Agent Operation Control",
    "description": "A framework enabling precise control over specific operations that AI agents can perform. This prevents overly broad permissions and enables granular delegation of authority.",
    "type": "pattern"
  },
  {
    "title": "Cryptographic User Intent Verification",
    "description": "A mechanism using cryptographic signatures to verify that agent operations align with actual user intent. This prevents agents from performing hallucinated or unauthorized actions.",
    "type": "mechanism"
  }
]


draft_name: draft-liu-dmsc-acps-arc
prompt_hash: b34c57f122ff9630
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:51:57.789625+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-liu-dmsc-acps-arc | Agent Collaboration Protocols Architecture for Internet of Agents | 16pg
Abstract: Internet of Agents (IoA) aims to facilitate interconnection and
   collaboration among heterogeneous agents to address complex tasks and
   support diverse applications.

   This IETF draft proposes the Agent Collaboration Protocols (ACPs)
   architecture, which includes conceptual domains, functional
   components and reference interfaces, to achieve agent interconnection
   and collaboration.  ACPs cover all stages of agents in the network,
   from their access to collaboration, supporting agent trusted
   registration, agent identity authentication, agent discovery, agent
   interaction, tool invocation, and agent monitoring.  The long-term
   vision of ACPs is to support the future large-scale interconnected
   agents and construct the key infrastructure for IoA.





DMSC Working Group                                                J. Liu
Internet-Draft                                                     K. Yu
Intended status: Informational                                     K. Li
Expires: 2 August 2026                                           K. Chen
                      Beijing University of Posts and Telecommunications
                                                         29 January 2026


   Agent Collaboration Protocols Architecture for Internet of Agents
                       draft-liu-dmsc-acps-arc-03

Abstract

   Internet of Agents (IoA) aims to facilitate interconnection and
   collaboration among heterogeneous agents to address complex tasks and
   support diverse applications.

   This IETF draft proposes the Agent Collaboration Protocols (ACPs)
   architecture, which includes conceptual domains, functional
   components and reference interfaces, to achieve agent interconnection
   and collaboration.  ACPs cover all stages of agents in the network,
   from their access to collaboration, supporting agent trusted
   registration, agent identity authentication, agent discovery, agent
   interaction, tool invocation, and agent monitoring.  The long-term
   vision of ACPs is to support the future large-scale interconnected
   agents and construct the key infrastructure for IoA.

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

Copyright Notice

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



Liu, et al.               Expires 2 August 2026                 [Page 1]

Internet-Draft              ACPs Architecture               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": "Agent Collaboration Protocols (ACPs) Architecture",
    "description": "A comprehensive architecture framework that includes conceptual domains, functional components and reference interfaces to enable agent interconnection and collaboration across heterogeneous agent systems. Covers the complete lifecycle from agent access to active collaboration.",
    "type": "architecture"
  },
  {
    "title": "Agent Trusted Registration",
    "description": "A mechanism for securely onboarding agents into the Internet of Agents network with trusted identity establishment. Provides the foundation for secure agent-to-agent interactions.",
    "type": "mechanism"
  },
  {
    "title": "Agent Identity Authentication",
    "description": "Authentication protocols specifically designed for verifying agent identities in the IoA ecosystem. Ensures only legitimate agents can participate in collaboration activities.",
    "type": "protocol"
  },
  {
    "title": "Agent Discovery Protocol",
    "description": "A discovery mechanism that allows agents to find and identify other agents with relevant capabilities for collaborative task execution. Enables dynamic formation of agent collaborations.",
    "type": "protocol"
  },
  {
    "title": "Agent Interaction Framework",
    "description": "Standardized interaction patterns and protocols for enabling communication and coordination between heterogeneous agents. Facilitates seamless collaboration across different agent implementations.",
    "type": "protocol"
  },
  {
    "title": "Tool Invocation Interface",
    "description": "A standardized interface mechanism that allows agents to invoke and utilize external tools and services during collaborative tasks. Extends agent capabilities through external resource integration.",
    "type": "mechanism"
  }
]


draft_name: draft-liu-dmsc-gw-requirements
prompt_hash: ea0448e588a1446b
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:52:04.854797+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-liu-dmsc-gw-requirements | Gateway Requirements for Dynamic Multi-agents Secured Collaboration | 8pg
Abstract: This document discusses the requirements for introducing Gateways
   into Dynamic Multi-agents Secured Collaboration for better
   scalability, communication efficiency, and security etc.  This
   document also discusses the gaps of current hardware/software
   gateways that could not fulfil the task, so that a new kind of
   entity, e.g. DMSC Gateway, is needed.





Network Working Group                                             B. Liu
Internet-Draft                                       Huawei Technologies
Intended status: Informational                           16 January 2026
Expires: 20 July 2026


  Gateway Requirements for Dynamic Multi-agents Secured Collaboration
                   draft-liu-dmsc-gw-requirements-00

Abstract

   This document discusses the requirements for introducing Gateways
   into Dynamic Multi-agents Secured Collaboration for better
   scalability, communication efficiency, and security etc.  This
   document also discusses the gaps of current hardware/software
   gateways that could not fulfil the task, so that a new kind of
   entity, e.g. DMSC Gateway, is needed.

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



Liu                       Expires 20 July 2026                  [Page 1]

Internet-Draft          DMSC Gateway Requirements           January 2026


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Functional Requirements of DMSC Gateway . . . . . . . . . . .   3
     2.1.  Delegated Agent Discovery . . . . . . . . . . . . . . . .   3
       2.1.1.  ID-based Agent Location Resolution  . . . . . . . . .   3
       2.1.2.  Task-based Agent Searching  . . . . . . . . . . . . .   4
     2.2.  Agent Communication Access Control  . . . . . . . . . . .   5
     2.3.  Information Distribution among Agents . . . . . . . . . .   6
       2.3.1.  Point-to-Point Distribution . . . . . . . . . . . . .   6
       2.3.2.  P

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

response_json:
[
  {
    "title": "Delegated Agent Discovery",
    "description": "Mechanism allowing DMSC gateways to perform agent discovery operations on behalf of requesting agents. Enables scalable discovery in multi-agent systems without direct peer-to-peer discovery overhead.",
    "type": "mechanism"
  },
  {
    "title": "ID-based Agent Location Resolution",
    "description": "Service that maps agent identifiers to their current network locations or addresses. Provides location transparency for dynamic agent environments.",
    "type": "mechanism"
  },
  {
    "title": "Task-based Agent Searching",
    "description": "Discovery mechanism that locates agents based on their capabilities or task types rather than identities. Supports dynamic collaboration by finding suitable agents for specific functions.",
    "type": "mechanism"
  },
  {
    "title": "Agent Communication Access Control",
    "description": "Gateway-enforced security mechanism controlling which agents can communicate with each other. Provides centralized security policy enforcement for multi-agent interactions.",
    "type": "mechanism"
  },
  {
    "title": "DMSC Gateway Architecture",
    "description": "Specialized gateway entity designed for Dynamic Multi-agents Secured Collaboration environments. Addresses gaps in traditional hardware/software gateways for agent-based systems.",
    "type": "architecture"
  }
]


draft_name: draft-liu-nmrg-ai-llm-inference-requirements
prompt_hash: 3e2862cc9511f568
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:52:11.407796+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-liu-nmrg-ai-llm-inference-requirements | Requirements Analysis of System and Network for Large Language Model Inference Service | 10pg
Abstract: With the rise of ChatGPT, DeepSeek, and other Large Language Models,
   which is short for LLMs in the remaining part, as well as the
   proliferation of inference applications, inference serving oriented
   to large-scale users has become increasingly critical.  However, due
   to the extreme demands on computing power and communication during
   inference, the large-scale service deployment of LLMs poses
   significant challenges.  To address these challenges, different
   vendors have adopted diverse inference service architectures, such as
   vLLM, SGLang, Mooncake, etc.  This paper investigates mainstream
   inference frameworks, summarizes their core design principle and
   research question, and analyzes the challenges and requirements they
   impose on network management.  The goal is to lay a foundation for
   defining a unified LLM inference architecture in the future.





Network Management                                                C. Liu
Internet-Draft                                                    C. Guo
Intended status: Informational                              China Mobile
Expires: 7 May 2026                                      3 November 2025


  Requirements Analysis of System and Network for Large Language Model
                           Inference Service
            draft-liu-nmrg-ai-llm-inference-requirements-02

Abstract

   With the rise of ChatGPT, DeepSeek, and other Large Language Models,
   which is short for LLMs in the remaining part, as well as the
   proliferation of inference applications, inference serving oriented
   to large-scale users has become increasingly critical.  However, due
   to the extreme demands on computing power and communication during
   inference, the large-scale service deployment of LLMs poses
   significant challenges.  To address these challenges, different
   vendors have adopted diverse inference service architectures, such as
   vLLM, SGLang, Mooncake, etc.  This paper investigates mainstream
   inference frameworks, summarizes their core design principle and
   research question, and analyzes the challenges and requirements they
   impose on network management.  The goal is to lay a foundation for
   defining a unified LLM inference architecture in the future.

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 RFC 2119 [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 7 May 2026.



Liu & Guo                  Expires 7 May 2026                   [Page 1]

Internet-Draft             Network Management              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 

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

response_json:
[
  {
    "title": "LLM Inference Service Architecture",
    "description": "Unified architecture framework for deploying large language model inference services at scale. Addresses extreme computing and communication demands during inference operations.",
    "type": "architecture"
  },
  {
    "title": "Multi-Framework Inference Integration",
    "description": "Integration approach for diverse inference service architectures including vLLM, SGLang, and Mooncake frameworks. Enables interoperability between different vendor implementations.",
    "type": "pattern"
  },
  {
    "title": "LLM Network Management Requirements",
    "description": "Specific network management requirements imposed by large-scale LLM inference deployments. Defines constraints and capabilities needed for effective LLM service delivery.",
    "type": "requirement"
  },
  {
    "title": "Inference Service Core Design Principles",
    "description": "Standardized design principles extracted from mainstream inference frameworks. Provides foundation for consistent LLM inference implementation approaches.",
    "type": "pattern"
  },
  {
    "title": "Large-Scale User Inference Serving",
    "description": "Service deployment mechanism optimized for serving LLM inference to large user populations. Addresses scalability challenges in multi-user inference scenarios.",
    "type": "mechanism"
  }
]


draft_name: draft-liu-oauth-a2a-profile
prompt_hash: f8836371c46514b4
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:52:18.664755+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-liu-oauth-a2a-profile | Agent-to-Agent (A2A) Profile for OAuth Transaction Tokens | 5pg
Abstract: This document defines a profile for using OAuth Transaction Tokens in
   Agent-to-Agent (A2A) communication scenarios.  The profile specifies
   how A2A call chain context can be embedded within Transaction Tokens
   to maintain agent identity, authorization context, and execution flow
   across distributed agent workloads within trusted domains.





Network Working Group                                          C. P. Liu
Internet-Draft                                                     Y. Ni
Intended status: Standards Track                                  Huawei
Expires: 23 April 2026                                   20 October 2025


       Agent-to-Agent (A2A) Profile for OAuth Transaction Tokens
                     draft-liu-oauth-a2a-profile-00

Abstract

   This document defines a profile for using OAuth Transaction Tokens in
   Agent-to-Agent (A2A) communication scenarios.  The profile specifies
   how A2A call chain context can be embedded within Transaction Tokens
   to maintain agent identity, authorization context, and execution flow
   across distributed agent workloads within trusted 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 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.
   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.




Liu & Ni                  Expires 23 April 2026                 [Page 1]

Internet-Draft              oauth-a2a-profile               October 2025


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Rationale . . . . . . . . . . . . . . . . . . . . . . . . . .   2
   4.  Transaction Token Request . . . . . . . . . . . . . . . . . .   3
   5.  Transaction Token Claims  . . . . . . . . . . . . . . . . . .   4
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   8.  Informative References  . . . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . 

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

response_json:
[
  {
    "title": "A2A Call Chain Context Embedding",
    "description": "Mechanism to embed Agent-to-Agent call chain context within OAuth Transaction Tokens to maintain execution flow across distributed agent workloads. Enables tracking of agent communication paths in trusted domains.",
    "type": "mechanism"
  },
  {
    "title": "Agent Identity Preservation",
    "description": "Pattern for maintaining agent identity information throughout the transaction token lifecycle in A2A scenarios. Ensures agent provenance is tracked across distributed calls.",
    "type": "pattern"
  },
  {
    "title": "A2A Transaction Token Profile",
    "description": "Specialized OAuth profile that defines how Transaction Tokens should be structured and used specifically for Agent-to-Agent communication. Extends standard OAuth Transaction Token usage for agent workloads.",
    "type": "profile"
  },
  {
    "title": "Trusted Domain Authorization Context",
    "description": "Architecture pattern for maintaining authorization context across agent communications within trusted domain boundaries. Enables seamless authorization propagation between agents.",
    "type": "architecture"
  },
  {
    "title": "A2A Transaction Token Claims Structure",
    "description": "Specific claim definitions and structure requirements for Transaction Tokens used in Agent-to-Agent scenarios. Defines what contextual information must be included for proper A2A operation.",
    "type": "extension"
  }
]


draft_name: draft-liu-rtgwg-agent-gateway-requirements
prompt_hash: 994483f1f9f2bcd1
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:52:25.539986+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-liu-rtgwg-agent-gateway-requirements | Requirements for Agent Gateway | 10pg
Abstract: This document discusses the requirements for introducing Agent
   Gateways into Agent-to-Agent communications for better scalability,
   communication efficiency, and security etc.  This document also
   discusses the gaps of current hardware/software gateways that could
   not fulfil the task, so that a new kind of entity, e.g. Agent
   Gateway, is needed.





network working group                                             B. Liu
Internet-Draft                                                   N. Geng
Intended status: Informational                                  X. Shang
Expires: 1 June 2026                                              Q. Gao
                                                                   Z. Li
                                                     Huawei Technologies
                                                                  J. Gao
                                                                   CAICT
                                                        28 November 2025


                     Requirements for Agent Gateway
             draft-liu-rtgwg-agent-gateway-requirements-01

Abstract

   This document discusses the requirements for introducing Agent
   Gateways into Agent-to-Agent communications for better scalability,
   communication efficiency, and security etc.  This document also
   discusses the gaps of current hardware/software gateways that could
   not fulfil the task, so that a new kind of entity, e.g. Agent
   Gateway, is needed.

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



Liu, et al.                Expires 1 June 2026                  [Page 1]

Internet-Draft         Agent Gateway Requirements          November 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
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Functional Requirements of Agent Gateway  . . . . . . . . . .   3
     2.1.  Delegated Agent Discovery . . . . . . . . . .

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

response_json:
[
  {
    "title": "Agent Gateway Entity",
    "description": "A new type of network entity specifically designed to facilitate Agent-to-Agent communications, distinct from traditional hardware/software gateways. It serves as an intermediary to improve scalability, communication efficiency, and security in agent-based systems.",
    "type": "architecture"
  },
  {
    "title": "Delegated Agent Discovery",
    "description": "A mechanism where the Agent Gateway performs agent discovery operations on behalf of agents in the network. This allows agents to locate and identify other agents through the gateway rather than performing direct discovery.",
    "type": "mechanism"
  },
  {
    "title": "Agent-to-Agent Communication Optimization",
    "description": "Requirements for optimizing communication patterns between software agents through gateway intermediation. The gateway provides enhanced scalability and efficiency compared to direct agent-to-agent communication.",
    "type": "requirement"
  },
  {
    "title": "Gateway-Mediated Security Model",
    "description": "A security architecture where the Agent Gateway provides security services for agent communications. This centralizes security functions and policies for agent interactions across network domains.",
    "type": "architecture"
  }
]


draft_name: draft-liu-rtgwg-llmsync-multicast
prompt_hash: bc9705b3a3715133
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:52:31.785967+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-liu-rtgwg-llmsync-multicast | Multicast Use Cases for Large Language Model Synchronization | 6pg
Abstract: Large Language Models (LLMs) deployments are becoming increasingly
   widespread, with inference services being the most common
   application.  This draft will discuss multicast use cases for
   inference cloud services.





RTGWG                                                             Y. Liu
Internet-Draft                                              China Mobile
Intended status: Informational                                  Z. Zhang
Expires: 16 August 2026                                  ZTE Corporation
                                                                J. Zhang
                                                            China Mobile
                                                        12 February 2026


      Multicast Use Cases for Large Language Model Synchronization
                  draft-liu-rtgwg-llmsync-multicast-00

Abstract

   Large Language Models (LLMs) deployments are becoming increasingly
   widespread, with inference services being the most common
   application.  This draft will discuss multicast use cases for
   inference cloud services.

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

Copyright Notice

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











Liu, et al.              Expires 16 August 2026                 [Page 1]

Internet-Draft              Abbreviated Title              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
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   2
   2.  LLM Synchronization . . . . . . . . . . . . . . . . . . . . .   2
   3.  Multicast technologies applying . . . . . . . . . . . . . . .   4
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     6.1.  Normative Refere

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

response_json:
[
  {
    "title": "LLM Model Parameter Synchronization",
    "description": "Synchronization of large language model parameters across multiple inference nodes using multicast delivery. This addresses the challenge of efficiently distributing updated model weights to numerous deployment instances.",
    "type": "mechanism"
  },
  {
    "title": "Multicast-based Model Distribution",
    "description": "Application of IP multicast technologies for distributing LLM model updates and synchronized parameters to cloud inference services. This leverages existing multicast protocols for AI workload distribution.",
    "type": "pattern"
  },
  {
    "title": "LLM Inference Service Synchronization Requirements",
    "description": "Technical requirements for maintaining consistency across distributed LLM inference deployments. This includes timing constraints and data consistency needs for synchronized model serving.",
    "type": "requirement"
  },
  {
    "title": "Cloud-based LLM Multicast Architecture",
    "description": "Network architecture for supporting multicast delivery of LLM synchronization data in cloud environments. This addresses the infrastructure needs for scalable AI model distribution.",
    "type": "architecture"
  }
]


draft_name: draft-liu-saag-zt-problem-statement
prompt_hash: 7fae87df73759634
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:52:37.318526+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-liu-saag-zt-problem-statement | Zero trust standards in IETF: use cases and problem statement | 8pg
Abstract: The traditional "castle-and-moat" security paradigm is no longer
   effective for some emerging scenarios, such as cloud services, remote
   workforces and intelligent agents.  Zero trust (ZT) has emerged as
   the new paradigm, holding on the "never trust, always verify"
   principle, treats every single access request as untrudted and
   requires veficication.

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





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


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

Abstract

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

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

Status of This Memo

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

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

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

   This Internet-Draft will expire on 6 May 2026.



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


Copyright Notice

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

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

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

response_json:
[
  {
    "title": "Never Trust Always Verify Principle",
    "description": "Core zero trust principle that treats every single access request as untrusted and requires verification regardless of source location or previous authentication state.",
    "type": "principle"
  },
  {
    "title": "Multi-vendor Zero Trust Interoperability Framework",
    "description": "Open, interoperable framework and protocol specifications needed to enable zero trust implementations across different vendors and platforms.",
    "type": "architecture"
  },
  {
    "title": "Zero Trust Protocol Standardization Scope",
    "description": "Definition of which zero trust aspects are suitable for IETF protocol standardization versus those better addressed by other standardization bodies.",
    "type": "requirement"
  },
  {
    "title": "Castle-and-Moat Paradigm Replacement",
    "description": "Transition from traditional perimeter-based security model to zero trust architecture for cloud services, remote workforces, and intelligent agents.",
    "type": "architecture"
  },
  {
    "title": "Zero Trust Access Request Verification",
    "description": "Technical mechanism requiring verification for every access request regardless of user location, device, or network context.",
    "type": "mechanism"
  }
]


draft_name: draft-luan-rtgwg-sdaf
prompt_hash: a51ba778e04ee138
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:52:45.101797+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-luan-rtgwg-sdaf | Symmetry-Driven Asynchronous Forwarding with Fast Reroute for LEO Satellite Networks (SDAF) | 16pg
Abstract: Interior Gateway Protocols (IGPs) such as OSPF are commonly employed
   in satellite networks to address topology awareness and autonomous
   routing in response to link interruptions, link/node failures, and
   subsequent repairs.  However, IGP-based approaches suffer from
   inherent limitations.  Synchronization delays between the control
   plane and the forwarding plane can cause routing black holes, while
   asynchronous convergence across nodes may induce micro-loops (as
   described in prior work), leading to packet loss and congestion.
   These issues are particularly exacerbated in satellite networks
   characterized by highly dynamic topologies, long inter-satellite
   propagation delays, and constrained on-board computing resources.

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

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

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





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


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

Abstract

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

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

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

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



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


Status of This Memo

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

   Inter

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

response_json:
[
  {
    "title": "Symmetry-Driven Asynchronous Forwarding (SDAF)",
    "description": "A forwarding mechanism that leverages the intrinsic symmetry of toroidal topologies in LEO satellite constellations to enable autonomous reverse flow processing based solely on local link-state information. Operates without requiring control-plane convergence, protocol extensions, or packet header modifications.",
    "type": "mechanism"
  },
  {
    "title": "Toroidal Topology Symmetry Exploitation",
    "description": "Utilizes the geometric symmetry properties of LEO satellite constellation topologies formed by multiple circular orbital planes connected by inter-satellite links. Enables predictable routing behavior during failures by exploiting the regular structure of the toroidal network.",
    "type": "pattern"
  },
  {
    "title": "Local Link-State Triggered Reverse Flows",
    "description": "Automatically triggers and processes reverse packet flows based on local link state changes without waiting for global network convergence. Achieves microsecond-scale response times by avoiding control plane synchronization delays.",
    "type": "mechanism"
  },
  {
    "title": "Control-Plane Independent Fast Reroute",
    "description": "Implements fast reroute functionality that operates independently of IGP control plane convergence to avoid routing black holes and micro-loops. Maintains compatibility with existing protocols like OSPFv3, IS-IS, and MPLS while providing immediate forwarding decisions.",
    "type": "mechanism"
  },
  {
    "title": "Resource-Constrained Satellite Router Optimization",
    "description": "Designed specifically for the computational and memory limitations of on-board satellite systems while maintaining high performance. Minimizes processing overhead through local decision making rather than global state synchronization.",
    "type": "requirement"
  }
]


draft_name: draft-mallick-muacp
prompt_hash: 5ea06567b5a823ec
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:52:52.370185+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-mallick-muacp | The Micro Agent Communication Protocol (uACP) | 37pg
Abstract: This document specifies the Micro Agent Communication Protocol
   (µACP), a resource-efficient messaging protocol for autonomous agents
   operating on resource-constrained Edge and IoT devices (including
   Class 1 and Class 2 devices per [RFC7228]).  Existing agent
   communication protocols assume unbounded computational and energy
   resources; µACP provides bounded resource consumption guarantees with
   deterministic memory bounds (8-byte header, up to 1024-byte TLV
   region, up to 65535-byte payload) and bounded processing time per
   message, while maintaining expressiveness sufficient for finite-state
   coordination patterns.  The protocol defines four core message types,
   a fixed 64-bit header, TLV-based extensibility, and mandatory OSCORE
   security binding for operation in adversarial environments.





Independent Submission                                        A. Mallick
Internet-Draft                                                I. Chebolu
Intended status: ExperimentalCentre for Development of Advanced Computing (CDAC)
Expires: 22 July 2026                                    18 January 2026


             The Micro Agent Communication Protocol (µACP)
                         draft-mallick-muacp-02

Abstract

   This document specifies the Micro Agent Communication Protocol
   (µACP), a resource-efficient messaging protocol for autonomous agents
   operating on resource-constrained Edge and IoT devices (including
   Class 1 and Class 2 devices per [RFC7228]).  Existing agent
   communication protocols assume unbounded computational and energy
   resources; µACP provides bounded resource consumption guarantees with
   deterministic memory bounds (8-byte header, up to 1024-byte TLV
   region, up to 65535-byte payload) and bounded processing time per
   message, while maintaining expressiveness sufficient for finite-state
   coordination patterns.  The protocol defines four core message types,
   a fixed 64-bit header, TLV-based extensibility, and mandatory OSCORE
   security binding for operation in adversarial environments.

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

Copyright Notice

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

Status of This Memo

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



Mallick & Chebolu         Expires 22 July 2026                  [Page 1]

Internet-Draft                    µACP                      January 2026


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

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified

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

response_json:
[
  {
    "title": "Fixed 64-bit Message Header",
    "description": "An 8-byte fixed header structure providing deterministic memory bounds for resource-constrained devices. Includes version, message type, flags, agent ID, and length fields.",
    "type": "mechanism"
  },
  {
    "title": "Four Core Message Types",
    "description": "Defines REQUEST, RESPONSE, NOTIFY, and ACK message types optimized for finite-state coordination patterns in autonomous agents. Each type has specific semantics for agent communication workflows.",
    "type": "protocol"
  },
  {
    "title": "Bounded Memory Architecture",
    "description": "Enforces strict memory limits with 8-byte header, up to 1024-byte TLV region, and up to 65535-byte payload. Provides deterministic resource consumption guarantees for Class 1 and Class 2 IoT devices.",
    "type": "architecture"
  },
  {
    "title": "TLV-based Extensibility",
    "description": "Uses Type-Length-Value encoding within a bounded 1024-byte region for protocol extensions. Allows flexible metadata and options while maintaining parsing predictability.",
    "type": "mechanism"
  },
  {
    "title": "Mandatory OSCORE Security Binding",
    "description": "Requires OSCORE integration for all message exchanges in adversarial environments. Provides authenticated encryption while maintaining the protocol's resource efficiency constraints.",
    "type": "requirement"
  }
]


draft_name: draft-mao-rtgwg-agent-comm-protocol-gap-analysis
prompt_hash: 9cf1dfa995b3e7fd
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:52:59.743178+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-mao-rtgwg-agent-comm-protocol-gap-analysis | Gap Analysis for the Cross-device Communication Protocol for AI Agents in Network Devices | 8pg
Abstract: With the development of large language models (LLM), AI Agent
   software continues to emerge.  AI agents deployed on different
   network devices need to collaborate to accomplish some complex tasks,
   such as network measurement and network troubleshooting.  This
   collaboration requires cross-device communication between AI agents.
   The cross-device communication framework is defined in
   [I-D.mzsg-rtgwg-agent-cross-device-comm-framework].

   This document describes whether some classical protocols in
   networking area, and some popular ones in AI Agent area can be used
   for the cross-device interaction of the AI agents in network devices,
   and analyzes the gaps.





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


 Gap Analysis for the Cross-device Communication Protocol for AI Agents
                           in Network Devices
          draft-mao-rtgwg-agent-comm-protocol-gap-analysis-00

Abstract

   With the development of large language models (LLM), AI Agent
   software continues to emerge.  AI agents deployed on different
   network devices need to collaborate to accomplish some complex tasks,
   such as network measurement and network troubleshooting.  This
   collaboration requires cross-device communication between AI agents.
   The cross-device communication framework is defined in
   [I-D.mzsg-rtgwg-agent-cross-device-comm-framework].

   This document describes whether some classical protocols in
   networking area, and some popular ones in AI Agent area can be used
   for the cross-device interaction of the AI agents in network devices,
   and analyzes the gaps.

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.





Mao, et al.                Expires 5 May 2026                   [Page 1]

Internet-Draft       Gap Analysis for Agent Protocol       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 T

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

response_json:
[
  {
    "title": "AI Agent Cross-Device Communication Framework",
    "description": "Framework for enabling AI agents deployed on different network devices to collaborate on complex tasks like network measurement and troubleshooting. Defines the architectural foundation for inter-agent communication across network boundaries.",
    "type": "framework"
  },
  {
    "title": "Protocol Gap Analysis for AI Agent Communication",
    "description": "Systematic evaluation of existing networking protocols and AI agent protocols to identify limitations for cross-device AI agent interaction. Assesses suitability of classical networking protocols versus AI-specific communication methods.",
    "type": "mechanism"
  },
  {
    "title": "Multi-Agent Network Collaboration Pattern",
    "description": "Communication pattern enabling distributed AI agents on network devices to coordinate and execute collaborative tasks. Addresses the specific requirements for agent-to-agent communication in network infrastructure contexts.",
    "type": "pattern"
  },
  {
    "title": "Network Device AI Agent Deployment Model",
    "description": "Architecture for deploying AI agents directly on network infrastructure devices to enable distributed intelligence. Supports local processing while maintaining inter-device collaboration capabilities.",
    "type": "architecture"
  },
  {
    "title": "Cross-Device Agent Communication Requirements",
    "description": "Technical requirements for enabling reliable communication between AI agents distributed across different network devices. Addresses unique challenges of agent coordination in network infrastructure environments.",
    "type": "requirement"
  }
]


draft_name: draft-mao-rtgwg-apn-framework-for-ioa
prompt_hash: e51a57110943f77c
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:53:06.296816+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-mao-rtgwg-apn-framework-for-ioa | APN Framework for Internet of Agent (IoA) | 11pg
Abstract: With the rapid development of large model technologies in the AI
   field, it has become possible to develop more intelligent assistant
   software, which is currently referred to as AI Agents in the
   industry.  These agents may come from different manufacturers and be
   deployed on different cloud platforms and regions.  They need to
   communicate and collaborate with each other through the Internet,
   which is called Internet of Agents (IoA).  Different interactions of
   AI agents have varying task requirements, which also lead to
   different demands on the network.  This requires network providing
   various fine granular services for the interactions of AI agents.

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





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


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

Abstract

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

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

Status of This Memo

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

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

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

   This Internet-Draft will expire on 5 May 2026.

Copyright Notice

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



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


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

Table of Contents

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

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

response_json:
[
  {
    "title": "Internet of Agents (IoA)",
    "description": "A network architecture where AI agents from different manufacturers and cloud platforms communicate and collaborate through the Internet. Enables distributed AI agent ecosystems requiring inter-agent coordination across network boundaries.",
    "type": "architecture"
  },
  {
    "title": "APN Framework for IoA",
    "description": "Application of Application-aware Packet Network (APN) framework to provide fine-grained network services for AI agent interactions. Maps different AI agent task requirements to corresponding network service differentiation.",
    "type": "framework"
  },
  {
    "title": "Agent Task-to-Network Mapping",
    "description": "A mechanism to translate varying AI agent interaction requirements into specific network service demands. Enables network differentiation based on agent collaboration patterns and task characteristics.",
    "type": "mechanism"
  },
  {
    "title": "Fine-Granular Network Services for Agents",
    "description": "Network service provisioning approach that provides customized network treatment based on specific AI agent interaction patterns. Supports diverse quality of service requirements for different types of agent communications.",
    "type": "pattern"
  }
]


draft_name: draft-melnikov-sasl2
prompt_hash: 51eea21f3cfa3681
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:53:12.338656+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-melnikov-sasl2 | Extensible Simple Authentication and Security Layer (SASL) | 10pg
Abstract: The Simple Authentication and Security Layer (SASL) is a framework
   for providing authentication and data security services in
   connection-oriented protocols via replaceable mechanisms.  It
   provides a structured interface between protocols and mechanisms.
   The resulting framework allows new protocols to reuse existing
   mechanisms and allows old protocols to make use of new mechanisms.
   The framework also provides a protocol for securing subsequent
   protocol exchanges within a data security layer.

   This document describes how a SASL mechanism is structured, describes
   how protocols include support for SASL, and defines the protocol for
   carrying a data security layer over a connection.  This document also
   defines how servers can request fulfillment of extra authentication
   related tasks, such as two factor authentication and/or password
   change.





Network Working Group                                        D. Cridland
Internet-Draft                                                          
Intended status: Standards Track                              T. Molitor
Expires: 5 June 2025                                                    
                                                                 M. Wild
                                                                        
                                                             A. Melnikov
                                                               Isode Ltd
                                                         2 December 2024


       Extensible Simple Authentication and Security Layer (SASL)
                        draft-melnikov-sasl2-02

Abstract

   The Simple Authentication and Security Layer (SASL) is a framework
   for providing authentication and data security services in
   connection-oriented protocols via replaceable mechanisms.  It
   provides a structured interface between protocols and mechanisms.
   The resulting framework allows new protocols to reuse existing
   mechanisms and allows old protocols to make use of new mechanisms.
   The framework also provides a protocol for securing subsequent
   protocol exchanges within a data security layer.

   This document describes how a SASL mechanism is structured, describes
   how protocols include support for SASL, and defines the protocol for
   carrying a data security layer over a connection.  This document also
   defines how servers can request fulfillment of extra authentication
   related tasks, such as two factor authentication and/or password
   change.

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



Cridland, et al.           Expires 5 June 2025                  [Page 1]

Internet-Draft                Extended SASL                December 2024


Copyright Notice

   Copyright (c) 2024 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 doc

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

response_json:
[
  {
    "title": "Replaceable SASL Mechanisms",
    "description": "A structured interface between protocols and authentication mechanisms that allows new protocols to reuse existing mechanisms and old protocols to use new mechanisms. This creates a pluggable architecture where authentication methods can be swapped without changing the underlying protocol.",
    "type": "architecture"
  },
  {
    "title": "Data Security Layer Protocol",
    "description": "A protocol for carrying and securing subsequent protocol exchanges within a data security layer after authentication completes. This provides ongoing protection for data transmitted over the connection.",
    "type": "protocol"
  },
  {
    "title": "Extra Authentication Tasks Framework",
    "description": "A mechanism allowing servers to request fulfillment of additional authentication-related tasks such as two-factor authentication and password changes. This extends basic authentication to support complex authentication workflows.",
    "type": "extension"
  },
  {
    "title": "Protocol-Mechanism Interface Structure",
    "description": "A standardized way to structure how SASL mechanisms interact with connection-oriented protocols. This defines the specific interface points and data exchange patterns between the protocol layer and authentication mechanisms.",
    "type": "pattern"
  }
]


draft_name: draft-men-rtgwg-agent-networking-digibank-scenario
prompt_hash: 9fe2ae0d77758596
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:53:18.788423+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-men-rtgwg-agent-networking-digibank-scenario | Agents Networking Scenarios in Enterprise and Broadband Networks | 10pg
Abstract: This document describes several typical digital banking scenarios,
   and discusses the trend of banking digitalization evolving to agentic
   service inteconnection.  Then, this document proposes an agent
   networking architecture based on the core component which is agent
   gateway.





rtgwg                                                             X. Men
Internet-Draft                                                   Y. Fang
Intended status: Informational                                  UnionPay
Expires: 6 May 2026                                               B. Liu
                                                                  Q. Gao
                                                                 N. Geng
                                                                X. Shang
                                                                   Z. Li
                                                     Huawei Technologies
                                                         2 November 2025


    Agents Networking Scenarios in Enterprise and Broadband Networks
         draft-men-rtgwg-agent-networking-digibank-scenario-00

Abstract

   This document describes several typical digital banking scenarios,
   and discusses the trend of banking digitalization evolving to agentic
   service inteconnection.  Then, this document proposes an agent
   networking architecture based on the core component which is agent
   gateway.

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.



Men, et al.                Expires 6 May 2026                   [Page 1]

Internet-Draft         Agents Networking Scenarios         November 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
     1.1.  Background  . . . . . . . . . . . . . . . . . . . . . . .   2
     1.2.  Agent Requirements in Digital Banking Scenarios . . . . .   3
     1.3.  Introduction of Agent Ga

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

response_json:
[
  {
    "title": "Agent Gateway",
    "description": "A core networking component that serves as the central element in agent networking architecture for digital banking scenarios. It facilitates agentic service interconnection in enterprise and broadband networks.",
    "type": "architecture"
  },
  {
    "title": "Agentic Service Interconnection",
    "description": "A networking pattern where digital banking services evolve from traditional digitalization to agent-based service connections. This represents a shift toward autonomous agent-to-agent communication in financial networks.",
    "type": "pattern"
  },
  {
    "title": "Agent Networking Architecture",
    "description": "A proposed network architecture specifically designed for enterprise and broadband networks to support agent-based services in digital banking environments. The architecture centers around agent gateways as key infrastructure components.",
    "type": "architecture"
  },
  {
    "title": "Digital Banking Agent Requirements",
    "description": "Specific networking and functional requirements identified for agents operating in digital banking scenarios. These requirements drive the design of the proposed agent networking solutions.",
    "type": "requirement"
  }
]


draft_name: draft-men-rtgwg-agent-networking-in-digibank
prompt_hash: 0d3578929496c9a9
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:53:23.909231+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-men-rtgwg-agent-networking-in-digibank | Agent Networking Scenarios of Digital Banking | 10pg
Abstract: This document describes several typical digital banking scenarios,
   and discusses the trend of banking digitalization evolving to agentic
   service inteconnection.  Then, this document proposes an agent
   networking architecture based on the core component which is agent
   gateway.





rtgwg                                                             X. Men
Internet-Draft                                                   Y. Fang
Intended status: Informational                                  UnionPay
Expires: 6 May 2026                                               B. Liu
                                                                  Q. Gao
                                                                 N. Geng
                                                                X. Shang
                                                                   Z. Li
                                                     Huawei Technologies
                                                         2 November 2025


             Agent Networking Scenarios of Digital Banking
            draft-men-rtgwg-agent-networking-in-digibank-00

Abstract

   This document describes several typical digital banking scenarios,
   and discusses the trend of banking digitalization evolving to agentic
   service inteconnection.  Then, this document proposes an agent
   networking architecture based on the core component which is agent
   gateway.

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.



Men, et al.                Expires 6 May 2026                   [Page 1]

Internet-Draft         Agents Networking Scenarios         November 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
     1.1.  Background  . . . . . . . . . . . . . . . . . . . . . . .   2
     1.2.  Agent Requirements in Digital Banking Scenarios . . . . .   3
     1.3.  Introduction of Agent Gateway and Net

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

response_json:
[
  {
    "title": "Agent Gateway",
    "description": "A core networking component that enables interconnection between banking agents and services. It serves as the central element in the proposed agent networking architecture for digital banking scenarios.",
    "type": "architecture"
  },
  {
    "title": "Agentic Service Interconnection",
    "description": "A networking pattern where digital banking services evolve from traditional digitalization to agent-based service connections. This represents the trend of banking systems moving toward autonomous agent communications.",
    "type": "pattern"
  },
  {
    "title": "Agent Networking Architecture",
    "description": "A proposed system architecture specifically designed for digital banking that facilitates communication and coordination between multiple banking agents. The architecture centers around the agent gateway component.",
    "type": "architecture"
  }
]


draft_name: draft-messous-eat-ai
prompt_hash: b564eed6c8ca0a9e
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:53:30.872330+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-messous-eat-ai | Entity Attestation Token (EAT) Profile for Autonomous AI Agents | 18pg
Abstract: This document defines a profile for the Entity Attestation Token
   (EAT) to support remote attestation of autonomous AI agents across
   domains.  It specifies a set of standardized claims for attesting the
   integrity of AI model parameters, the provenance of training data,
   and the constraints of inference-time data access policies.  Optional
   extensions for 5G/6G network functions—such as slice-type
   authorization—are included for interoperability with ETSI ENI and
   3GPP architectures.  The profile is encoded in CBOR Web Tokens (CWTs)
   or JSON Web Tokens (JWTs) and is designed to be used within the IETF
   RATS architecture.





Network Working Group                                         A. MESSOUS
Internet-Draft                                                Huawei R&D
Intended status: Informational                          23 February 2026
Expires: 27 August 2026


    Entity Attestation Token (EAT) Profile for Autonomous AI Agents
                        draft-messous-eat-ai-01

Abstract

   This document defines a profile for the Entity Attestation Token
   (EAT) to support remote attestation of autonomous AI agents across
   domains.  It specifies a set of standardized claims for attesting the
   integrity of AI model parameters, the provenance of training data,
   and the constraints of inference-time data access policies.  Optional
   extensions for 5G/6G network functions—such as slice-type
   authorization—are included for interoperability with ETSI ENI and
   3GPP architectures.  The profile is encoded in CBOR Web Tokens (CWTs)
   or JSON Web Tokens (JWTs) and is designed to be used within the IETF
   RATS architecture.

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-messous-eat-ai/.

   Source for this draft and an issue tracker can be found at
   https://github.com/https://github.com/mmessous/draft-messous-EAT-AI.

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



MESSOUS                  Expires 27 August 2026                 [Page 1]

Internet-Draft                EAT-AI-Agents                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": "AI Model Parameter Integrity Claims",
    "description": "Standardized EAT claims for attesting the cryptographic integrity and authenticity of AI model parameters. Enables verification that model weights and architecture have not been tampered with.",
    "type": "mechanism"
  },
  {
    "title": "Training Data Provenance Claims",
    "description": "EAT claims that attest to the source, lineage, and characteristics of training datasets used to create AI models. Provides verifiable proof of data origins for compliance and trust.",
    "type": "mechanism"
  },
  {
    "title": "Inference-Time Data Access Policy Claims",
    "description": "Claims that specify and attest to constraints on what data an AI agent can access during inference operations. Enables enforcement of data usage boundaries and privacy controls.",
    "type": "mechanism"
  },
  {
    "title": "5G/6G Network Slice Authorization Extension",
    "description": "Optional EAT extensions for authorizing AI agents to specific network slice types in 5G/6G environments. Provides interoperability with ETSI ENI and 3GPP network architectures.",
    "type": "extension"
  },
  {
    "title": "Cross-Domain AI Agent Attestation Profile",
    "description": "A complete EAT profile specification that enables remote attestation of autonomous AI agents operating across different administrative domains. Standardizes the attestation format and required claims.",
    "type": "protocol"
  }
]


draft_name: draft-meta-layer-overview
prompt_hash: 6b52577b3336a9b9
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:53:37.937578+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-meta-layer-overview | The Meta-Layer: A Coordination Substrate for Presence, Annotation, and Governance on the Web | 11pg
Abstract: This document introduces the concept of a Meta-layer: a programmable
   coordination substrate that operates above content layers on the
   Internet.  The Meta-layer enables communities, individuals, and
   agents to appear, annotate, and govern together in shared digital
   space, independent of underlying platforms.  It is not a replacement
   for existing web or transport protocols, but a complementary
   infrastructure that integrates with them.  The draft outlines the
   motivation, terminology, use cases, implementation model, risks,
   security considerations, and potential IANA registries for future
   work.





GEN-Dispatch                                        K. ATTOUMANI MOHAMED
Internet-Draft                                               D. BENJAMIN
Intended status: Informational                     Meta-Layer Initiative
Expires: 8 April 2026                                       October 2025


 The Meta-Layer: A Coordination Substrate for Presence, Annotation, and
                         Governance on the Web
                      draft-meta-layer-overview-00

Abstract

   This document introduces the concept of a Meta-layer: a programmable
   coordination substrate that operates above content layers on the
   Internet.  The Meta-layer enables communities, individuals, and
   agents to appear, annotate, and govern together in shared digital
   space, independent of underlying platforms.  It is not a replacement
   for existing web or transport protocols, but a complementary
   infrastructure that integrates with them.  The draft outlines the
   motivation, terminology, use cases, implementation model, risks,
   security considerations, and potential IANA registries for future
   work.

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

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.



ATTOUMANI MOHAMED & BENJAMExpires 8 April 2026                  [Page 1]

Internet-Draft             Meta-layer Overview              October 2025


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

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

response_json:
[
  {
    "title": "Meta-Layer Coordination Substrate",
    "description": "A programmable layer that operates above content layers to enable presence, annotation, and governance functionality. It integrates with existing web protocols without replacing them.",
    "type": "architecture"
  },
  {
    "title": "Platform-Independent Digital Governance",
    "description": "A mechanism allowing communities to establish governance rules and coordination that operates independently of underlying platforms. Enables shared digital space management across different web services.",
    "type": "mechanism"
  },
  {
    "title": "Cross-Platform Presence System",
    "description": "Infrastructure for individuals and agents to appear and coordinate in shared digital spaces regardless of the underlying platform or service. Provides unified presence across multiple web properties.",
    "type": "protocol"
  },
  {
    "title": "Distributed Annotation Framework",
    "description": "A system for adding metadata and annotations to web content that exists independently of the content platforms themselves. Allows persistent annotations across platform boundaries.",
    "type": "mechanism"
  },
  {
    "title": "Meta-Layer IANA Registry Requirements",
    "description": "Specification of potential new IANA registries needed to support Meta-layer functionality and coordination mechanisms. Defines namespace and identifier management needs.",
    "type": "requirement"
  }
]


draft_name: draft-meunier-webbotauth-registry
prompt_hash: 8fdc94a97065ccad
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:53:45.002199+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-meunier-webbotauth-registry | Registry and Signature Agent card for Web bot auth | 18pg
Abstract: This document describes a JSON based format for clients using
   [DIRECTORY] to advertise information about themselves.

   This document describes a JSON-based "Signature Agent Card" format
   for signature agent using [DIRECTORY] to advertise metadata about
   themselve.  This includes identity, purpose, rate expectations, and
   cryptographic keys.  It also establishes an IANA registry for
   Signature Agent Card parameters, enabling extensible and
   interoperable discovery of agent information.





Web Bot Auth                                                M. Guerreiro
Internet-Draft                                                Cloudflare
Intended status: Informational                                U. Kirazci
Expires: 23 April 2026                                            Amazon
                                                              T. Meunier
                                                              Cloudflare
                                                         20 October 2025


           Registry and Signature Agent card for Web bot auth
                  draft-meunier-webbotauth-registry-01

Abstract

   This document describes a JSON based format for clients using
   [DIRECTORY] to advertise information about themselves.

   This document describes a JSON-based "Signature Agent Card" format
   for signature agent using [DIRECTORY] to advertise metadata about
   themselve.  This includes identity, purpose, rate expectations, and
   cryptographic keys.  It also establishes an IANA registry for
   Signature Agent Card parameters, enabling extensible and
   interoperable discovery of agent information.

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://thibmeu.github.io/http-message-signatures-directory/draft-
   meunier-webbotauth-registry.html.  Status information for this
   document may be found at https://datatracker.ietf.org/doc/draft-
   meunier-webbotauth-registry/.

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

   Source for this draft and an issue tracker can be found at
   https://github.com/thibmeu/http-message-signatures-directory.

Status of This Memo

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





Guerreiro, et al.         Expires 23 April 2026                 [Page 1]

Internet-Draft  Registry and Signature Agent card for We    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 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
 

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

response_json:
[
  {
    "title": "Signature Agent Card Format",
    "description": "JSON-based format for signature agents to advertise metadata including identity, purpose, rate expectations, and cryptographic keys. Enables structured discovery of agent information through a standardized card format.",
    "type": "protocol"
  },
  {
    "title": "Directory-based Agent Discovery",
    "description": "Mechanism for clients and signature agents to use DIRECTORY service to advertise information about themselves. Provides a centralized way for agents to publish their capabilities and metadata.",
    "type": "mechanism"
  },
  {
    "title": "IANA Registry for Agent Card Parameters",
    "description": "Establishes official registry for Signature Agent Card parameters to enable extensible and interoperable discovery. Allows standardized extension of agent metadata fields.",
    "type": "registry"
  },
  {
    "title": "Web Bot Authentication Architecture",
    "description": "Overall architecture combining signature agents, directory services, and structured metadata cards for bot authentication. Integrates cryptographic signatures with discoverable agent information.",
    "type": "architecture"
  },
  {
    "title": "Rate Expectation Advertisement",
    "description": "Mechanism for agents to advertise their expected request rates as part of their metadata card. Allows servers to understand bot behavior patterns in advance.",
    "type": "mechanism"
  }
]


draft_name: draft-meyerzuselha-oauth-web-message-response-mode
prompt_hash: 59e319b0e05c0699
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:53:51.456547+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-meyerzuselha-oauth-web-message-response-mode | OAuth 2.0 Web Message Response Mode for Popup- and Iframe-based Authorization Flows | 16pg
Abstract: This specification defines the web message response mode that
   authorization servers use for transmitting authorization response
   parameters via the user-agent's postMessage API to the client.  This
   mode is intended for authorization flows that use secondary windows,
   which are well-suited for browser-based applications.





Web Authorization Protocol                         K. Meyer zu Selhausen
Internet-Draft                                                 Hackmanit
Intended status: Standards Track                              L. Jannett
Expires: 9 May 2026                               Ruhr University Bochum
                                                               C. Mainka
                                                               Hackmanit
                                                         5 November 2025


    OAuth 2.0 Web Message Response Mode for Popup- and Iframe-based
                          Authorization Flows
         draft-meyerzuselha-oauth-web-message-response-mode-01

Abstract

   This specification defines the web message response mode that
   authorization servers use for transmitting authorization response
   parameters via the user-agent's postMessage API to the client.  This
   mode is intended for authorization flows that use secondary windows,
   which are well-suited for browser-based applications.

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.

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



Meyer zu Selhausen, et al. Expires 9 May 2026                   [Page 1]

Internet-Draft       oauth-web-message-response-mode       November 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
     1.1.  Conventions and Terminology . . . . . . . . . . . . . . .   3
   2.  Web Message Response Mode . . . . . . . . . . . . . . . . . .   4
     2.1.  Dynamic Discovery of Primary Window Reference . . . . . .   5
   3.  Popup-Based Authorization Flow Using the Web Message Response
           Mode  . . . 

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

response_json:
[
  {
    "title": "Web Message Response Mode",
    "description": "OAuth 2.0 response mode that transmits authorization response parameters via the user-agent's postMessage API to the client. This enables authorization servers to communicate with browser-based applications through secondary windows like popups and iframes.",
    "type": "mechanism"
  },
  {
    "title": "Dynamic Primary Window Reference Discovery",
    "description": "Method for dynamically discovering and establishing communication between secondary authorization windows and their parent/opener windows. This handles the complexity of maintaining proper window references across different browser contexts.",
    "type": "mechanism"
  },
  {
    "title": "PostMessage-based Parameter Transmission",
    "description": "Protocol extension that uses the browser's postMessage API as the transport mechanism for OAuth authorization response parameters. This replaces traditional redirect-based parameter passing for popup and iframe scenarios.",
    "type": "protocol"
  },
  {
    "title": "Secondary Window Authorization Pattern",
    "description": "Authorization flow pattern specifically designed for popup and iframe-based OAuth flows in browser applications. This pattern accommodates scenarios where traditional redirect flows are not suitable due to window containment requirements.",
    "type": "pattern"
  }
]


draft_name: draft-mishra-oauth-agent-grants
prompt_hash: 9784e31368d346d2
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:53:58.008992+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-mishra-oauth-agent-grants | Delegated Agent Authorization Protocol (DAAP) | 27pg
Abstract: Artificial intelligence (AI) agents increasingly take autonomous
   actions — submitting forms, initiating payments, and sending
   communications — on behalf of human users across third-party
   services.  This document defines the Delegated Agent Authorization
   Protocol (DAAP), an open, model-neutral, framework-agnostic protocol
   that specifies: cryptographic agent identity using Decentralized
   Identifiers (DIDs); a human-consent-based grant authorization flow
   modelled on OAuth 2.0; a signed JSON Web Token (JWT) grant token
   format with agent-specific claims; a revocation model with online
   verification; a hash-chained append-only audit trail; a policy engine
   for automated authorization decisions; and a multi-agent delegation
   model with cascade revocation.  DAAP fills a gap unaddressed by
   existing OAuth 2.0 extensions: verifying that a specific human
   authorized a specific AI agent to perform a specific action, revoking
   that authorization in real time, and producing a tamper-evident
   record of what the agent did.





Web Authorization Protocol                                      S. Kumar
Internet-Draft                                                   Grantex
Intended status: Informational                          27 February 2026
Expires: 31 August 2026


             Delegated Agent Authorization Protocol (DAAP)
                   draft-mishra-oauth-agent-grants-00

Abstract

   Artificial intelligence (AI) agents increasingly take autonomous
   actions — submitting forms, initiating payments, and sending
   communications — on behalf of human users across third-party
   services.  This document defines the Delegated Agent Authorization
   Protocol (DAAP), an open, model-neutral, framework-agnostic protocol
   that specifies: cryptographic agent identity using Decentralized
   Identifiers (DIDs); a human-consent-based grant authorization flow
   modelled on OAuth 2.0; a signed JSON Web Token (JWT) grant token
   format with agent-specific claims; a revocation model with online
   verification; a hash-chained append-only audit trail; a policy engine
   for automated authorization decisions; and a multi-agent delegation
   model with cascade revocation.  DAAP fills a gap unaddressed by
   existing OAuth 2.0 extensions: verifying that a specific human
   authorized a specific AI agent to perform a specific action, revoking
   that authorization in real time, and producing a tamper-evident
   record of what the agent did.

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







Kumar                    Expires 31 August 2026                 [Page 1]

Internet-Draft                    DAAP                     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.



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

response_json:
[
  {
    "title": "DID-Based Agent Identity",
    "description": "Uses Decentralized Identifiers (DIDs) to establish cryptographic identity for AI agents. Enables verifiable agent authentication without relying on centralized certificate authorities.",
    "type": "mechanism"
  },
  {
    "title": "Agent-Specific JWT Grant Token",
    "description": "Extends JWT format with agent-specific claims for authorization tokens. Includes fields for agent identity, delegated capabilities, and action constraints.",
    "type": "extension"
  },
  {
    "title": "Hash-Chained Audit Trail",
    "description": "Implements append-only audit logging using cryptographic hash chains. Creates tamper-evident records of agent actions for accountability and compliance.",
    "type": "mechanism"
  },
  {
    "title": "Real-Time Authorization Verification",
    "description": "Provides online verification system for checking current authorization status. Enables immediate revocation checking before agent actions are executed.",
    "type": "mechanism"
  },
  {
    "title": "Multi-Agent Cascade Revocation",
    "description": "Implements delegation chains between agents with automatic cascade revocation. When a parent agent's authorization is revoked, all child delegations are automatically invalidated.",
    "type": "pattern"
  },
  {
    "title": "Policy Engine for Automated Decisions",
    "description": "Defines rule-based policy engine for making automated authorization decisions. Supports configurable policies for different agent types and action categories.",
    "type": "architecture"
  }
]


draft_name: draft-moreno-lisp-uberlay
prompt_hash: b57a9782cacc2b89
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:54:05.588901+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-moreno-lisp-uberlay | Uberlay Interconnection of Multiple LISP overlays | 20pg
Abstract: This document describes the use of the Locator/ID Separation Protocol
   (LISP) to interconnect multiple disparate and independent network
   overlays by using a transit overlay.  The transit overlay is referred
   to as the "uberlay" and provides connectivity and control plane
   abstraction between different overlays.  Each network overlay may use
   different control and data plane approaches and may be managed by a
   different organization.  Structuring the network into multiple
   network overlays enables the interworking of different overlay
   approaches to data and control plane methods.  The different network
   overlays are autonomous from a control and data plane perspective,
   this in turn enables failure survivability across overlay domains.
   This document specifies the mechanisms and procedures for the
   distribution of control plane information across overlay sites and in
   the uberlay as well as the lookup and forwarding procedures for
   unicast and multicast traffic within and across overlays.  The
   specification also defines the procedures to support inter-overlay
   mobility of EIDs and their integration with the intra-overlay EID
   mobility procedures defined in draft-ietf-lisp-eid-mobility.





Network Working Group                                          V. Moreno
Internet-Draft                                                Google LLC
Intended status: Experimental                               D. Farinacci
Expires: 9 October 2025                                      lispers.net
                                                      A. Rodriguez-Natal
                                                     M. Portoles-Comeras
                                                                F. Maino
                                                                S. Hooda
                                                           Cisco Systems
                                                            7 April 2025


           Uberlay Interconnection of Multiple LISP overlays
                      draft-moreno-lisp-uberlay-07

Abstract

   This document describes the use of the Locator/ID Separation Protocol
   (LISP) to interconnect multiple disparate and independent network
   overlays by using a transit overlay.  The transit overlay is referred
   to as the "uberlay" and provides connectivity and control plane
   abstraction between different overlays.  Each network overlay may use
   different control and data plane approaches and may be managed by a
   different organization.  Structuring the network into multiple
   network overlays enables the interworking of different overlay
   approaches to data and control plane methods.  The different network
   overlays are autonomous from a control and data plane perspective,
   this in turn enables failure survivability across overlay domains.
   This document specifies the mechanisms and procedures for the
   distribution of control plane information across overlay sites and in
   the uberlay as well as the lookup and forwarding procedures for
   unicast and multicast traffic within and across overlays.  The
   specification also defines the procedures to support inter-overlay
   mobility of EIDs and their integration with the intra-overlay EID
   mobility procedures defined in draft-ietf-lisp-eid-mobility.

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


Status of This Memo

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




Moreno, et al.           Expires 9 October 2025                 [Page 1]

Internet-Draft                LISP Uberlay                    April 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

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

response_json:
[
  {
    "title": "LISP Uberlay Architecture",
    "description": "A transit overlay network that interconnects multiple disparate and independent LISP network overlays, providing connectivity and control plane abstraction between different overlay domains. Each overlay can use different control and data plane approaches while maintaining autonomy.",
    "type": "architecture"
  },
  {
    "title": "Inter-Overlay Control Plane Distribution",
    "description": "Mechanisms and procedures for distributing control plane information across overlay sites and within the uberlay to enable communication between different overlay domains. This enables centralized control plane abstraction while maintaining overlay independence.",
    "type": "mechanism"
  },
  {
    "title": "Cross-Overlay Lookup and Forwarding",
    "description": "Lookup and forwarding procedures for unicast and multicast traffic that operates both within individual overlays and across different overlay domains through the uberlay. This enables seamless traffic flow between heterogeneous overlay networks.",
    "type": "mechanism"
  },
  {
    "title": "Inter-Overlay EID Mobility",
    "description": "Procedures to support mobility of Endpoint Identifiers (EIDs) between different overlay domains, integrated with existing intra-overlay EID mobility mechanisms. This enables endpoints to move across overlay boundaries while maintaining connectivity.",
    "type": "mechanism"
  },
  {
    "title": "Overlay Failure Survivability",
    "description": "Autonomous control and data plane operation across overlay domains that enables failure survivability, where issues in one overlay domain do not propagate to other connected overlays. This provides isolation and resilience in multi-overlay deployments.",
    "type": "pattern"
  }
]


draft_name: draft-mozley-aidiscovery
prompt_hash: 1b3e30e3763641ea
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:54:12.859305+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-mozley-aidiscovery | AI Agent Discovery (AID) Problem Statement | 8pg
Abstract: With the deployment of AI agents comes a need for mechanisms to
   support agent-to-agent discovery.  This document presents
   requirements and considerations for agent-to-agent discovery.





Network Working Group                                          J. Mozley
Internet-Draft                                               N. Williams
Intended status: Informational                            Infoblox, Inc.
Expires: 18 April 2026                                       B. Sarikaya
                                                            Unaffiliated
                                                               R. Schott
                                                        Deutsche Telekom
                                                         15 October 2025


               AI Agent Discovery (AID) Problem Statement
                      draft-mozley-aidiscovery-00

Abstract

   With the deployment of AI agents comes a need for mechanisms to
   support agent-to-agent discovery.  This document presents
   requirements and considerations for agent-to-agent discovery.

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





Mozley, et al.            Expires 18 April 2026                 [Page 1]

Internet-Draft                   AID PS                     October 2025


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   2
   3.  Scope of Discovery Processes  . . . . . . . . . . . . . . . .   2
   4.  Autonomy and Governance . . . . . . . . . . . . . . . . . . .   4
   5.  Agent Registration Advertisement and Discovery  . . . . . . .   4
   6.  Regulation and Compliance Features  . . . . . . . . . . . . .   5
   7.  Scalability . . . . . . . . . . . . . . . . . . . . . . . . .   5
   8.  Schema Evolution  . . . . . . . . . . . . . . . . . . . . . .   5
   9.  Abuse . . . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   10. Connectivity  . . . . . . . . . . . . . . . . . . . . . . . .   6
   11. Attesta

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

response_json:
[
  {
    "title": "Agent-to-Agent Discovery Protocol",
    "description": "A mechanism enabling AI agents to automatically discover and identify other agents within a network or system. This would provide the foundational protocol for agent discovery services.",
    "type": "protocol"
  },
  {
    "title": "Agent Registration Advertisement System",
    "description": "A system where AI agents can register their capabilities and services for advertisement to other agents seeking specific functionalities. This enables dynamic service discovery in agent networks.",
    "type": "mechanism"
  },
  {
    "title": "Autonomous Agent Governance Framework",
    "description": "A governance model that defines how AI agents can operate autonomously while maintaining appropriate oversight and control mechanisms. This addresses the balance between agent independence and system control.",
    "type": "architecture"
  },
  {
    "title": "Schema Evolution for Agent Discovery",
    "description": "A mechanism to handle changes and updates to agent discovery schemas over time without breaking existing agent interactions. This ensures backward compatibility as agent capabilities evolve.",
    "type": "mechanism"
  },
  {
    "title": "Discovery Process Scalability Requirements",
    "description": "Technical requirements for ensuring agent discovery mechanisms can scale to handle large numbers of agents without performance degradation. This defines the scalability constraints for discovery systems.",
    "type": "requirement"
  }
]


draft_name: draft-mozleywilliams-dnsop-bandaid
prompt_hash: 53ab436aa39c1eb0
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:54:20.434330+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-mozleywilliams-dnsop-bandaid | Brokered Agent Network for DNS AI Discovery | 37pg
Abstract: The emerging field of agent-to-agent protocol standards introduces
   new requirements in order to facilitate discovery, trust signaling,
   session negotiation and communication.  This document specifies a
   method for utilizing the Domain Name System (DNS) to facilitate
   scalable and interoperable discovery between AI agents.  The proposed
   mechanism, referred to as _Brokered Agent Network for DNS AI
   Discovery_ (BANDAID), defines a structured DNS namespace and record
   usage model to support metadata exchange and capability
   advertisement.

   BANDAID introduces a leaf zone convention (e.g., _agents.example.com)
   containing Service Binding (SVCB) records (e.g.,
   chat._agents.example.com) that encode application-specific metadata.
   These records enable agents to retrieve operational parameters prior
   to initiating a session, supporting both targeted lookups and
   capability-based discovery.  The approach leverages existing DNS
   infrastructure, including DNS Service Discovery (DNS-SD), DNSSEC, and
   DANE, to provide integrity, authenticity, and automation without
   requiring human intervention.  Lastly, the draft for Domain Control
   Validation (DCV) proposes a best current practice to prove an agent
   is authorized to act on behalf of a domain.

   _This document proposes no change to the structure of DNS messages,
   and no new operation codes, response codes, resource record types, or
   any other new DNS protocol values._





dnsop                                                          J. Mozley
Internet-Draft                                               N. Williams
Intended status: Standards Track                          Infoblox, Inc.
Expires: 19 April 2026                                       B. Sarikaya
                                                            Unaffiliated
                                                               R. Schott
                                                        Deutsche Telecom
                                                         16 October 2025


              Brokered Agent Network for DNS AI Discovery
                 draft-mozleywilliams-dnsop-bandaid-00

Abstract

   The emerging field of agent-to-agent protocol standards introduces
   new requirements in order to facilitate discovery, trust signaling,
   session negotiation and communication.  This document specifies a
   method for utilizing the Domain Name System (DNS) to facilitate
   scalable and interoperable discovery between AI agents.  The proposed
   mechanism, referred to as _Brokered Agent Network for DNS AI
   Discovery_ (BANDAID), defines a structured DNS namespace and record
   usage model to support metadata exchange and capability
   advertisement.

   BANDAID introduces a leaf zone convention (e.g., _agents.example.com)
   containing Service Binding (SVCB) records (e.g.,
   chat._agents.example.com) that encode application-specific metadata.
   These records enable agents to retrieve operational parameters prior
   to initiating a session, supporting both targeted lookups and
   capability-based discovery.  The approach leverages existing DNS
   infrastructure, including DNS Service Discovery (DNS-SD), DNSSEC, and
   DANE, to provide integrity, authenticity, and automation without
   requiring human intervention.  Lastly, the draft for Domain Control
   Validation (DCV) proposes a best current practice to prove an agent
   is authorized to act on behalf of a domain.

   _This document proposes no change to the structure of DNS messages,
   and no new operation codes, response codes, resource record types, or
   any other new DNS protocol values._

About This Document

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







Mozley, et al.            Expires 19 April 2026                 [Page 1]

Internet-Draft                   BANDAID                    October 2025


   The latest revision of this draft can be found at
   https://example.com/LATEST.  Status information for this document may
   be found at https://datatracker.ietf.org/doc/draft-mozleywilliams-
   dnsop-bandaid/.

   Discussion of this document takes place on the WG Working Group
   mailing list (mailto:WG@example.com), which is archived at
   https://example.com/WG.

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

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions 

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

response_json:
[
  {
    "title": "BANDAID DNS Namespace Convention",
    "description": "Defines a structured DNS leaf zone convention using _agents.example.com to organize AI agent discovery records. Service-specific records are placed under this namespace (e.g., chat._agents.example.com).",
    "type": "mechanism"
  },
  {
    "title": "SVCB Records for Agent Metadata",
    "description": "Leverages Service Binding (SVCB) records to encode application-specific metadata and operational parameters for AI agents. Enables agents to retrieve configuration before session initiation.",
    "type": "mechanism"
  },
  {
    "title": "Domain Control Validation for Agents",
    "description": "Proposes a best current practice method to prove an AI agent is authorized to act on behalf of a specific domain. Provides trust signaling through DNS-based validation.",
    "type": "protocol"
  },
  {
    "title": "Capability-Based Agent Discovery",
    "description": "Supports both targeted lookups for specific agents and broader capability-based discovery to find agents with desired features. Uses DNS infrastructure for scalable service advertisement.",
    "type": "pattern"
  },
  {
    "title": "DNS-SD Integration for Agent Services",
    "description": "Integrates with existing DNS Service Discovery (DNS-SD) infrastructure along with DNSSEC and DANE for integrity and authenticity. Provides automated discovery without human intervention.",
    "type": "extension"
  }
]


draft_name: draft-mozleywilliams-dnsop-dnsaid
prompt_hash: ec5f1968656f006f
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:54:27.399104+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-mozleywilliams-dnsop-dnsaid | DNS for AI Discovery | 24pg
Abstract: This document specifies a method for utilizing the Domain Name System
   (DNS) to facilitate scalable and interoperable discovery between AI
   agents.  The proposed mechanism, referred to as _DNS AI agent
   Discovery_ (DNS-AID), defines a structured DNS namespace and record
   usage model to support metadata exchange and capability
   advertisement.

   This will allow organisations to publish information about their AI
   agents on the Internet or internal networks using a well-known label
   within the organisation’s own DNS namespace.  This document does not
   define how the published agent information is accessed or the exact
   structure of that information.  Instead, it specifies a mechanism for
   indicating which access protocol should be used and what format the
   agent information will be provided in.

   _This document proposes no change to the structure of DNS messages,
   and no new operation codes, response codes, resource record types, or
   any other new DNS protocol values._





dnsop                                                          J. Mozley
Internet-Draft                                               N. Williams
Intended status: Standards Track                          Infoblox, Inc.
Expires: 27 August 2026                                      B. Sarikaya
                                                            Unaffiliated
                                                               R. Schott
                                                        Deutsche Telekom
                                                        23 February 2026


                          DNS for AI Discovery
                  draft-mozleywilliams-dnsop-dnsaid-00

Abstract

   This document specifies a method for utilizing the Domain Name System
   (DNS) to facilitate scalable and interoperable discovery between AI
   agents.  The proposed mechanism, referred to as _DNS AI agent
   Discovery_ (DNS-AID), defines a structured DNS namespace and record
   usage model to support metadata exchange and capability
   advertisement.

   This will allow organisations to publish information about their AI
   agents on the Internet or internal networks using a well-known label
   within the organisation’s own DNS namespace.  This document does not
   define how the published agent information is accessed or the exact
   structure of that information.  Instead, it specifies a mechanism for
   indicating which access protocol should be used and what format the
   agent information will be provided in.

   _This document proposes no change to the structure of DNS messages,
   and no new operation codes, response codes, resource record types, or
   any other new DNS protocol values._

About This Document

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

   The latest revision of this draft can be found at
   https://example.com/LATEST.  Status information for this document may
   be found at https://datatracker.ietf.org/doc/draft-mozleywilliams-
   dnsop-dnsaid/.

   Discussion of this document takes place on the WG Working Group
   mailing list (mailto:WG@example.com), which is archived at
   https://example.com/WG.





Mozley, et al.           Expires 27 August 2026                 [Page 1]

Internet-Draft                   DNS-AID                   February 2026


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

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 Inte

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

response_json:
[
  {
    "title": "DNS-AID Structured Namespace",
    "description": "Defines a well-known DNS label structure within organizations' DNS namespaces specifically for AI agent discovery. Uses existing DNS hierarchy to enable scalable agent advertisement without new DNS protocol elements.",
    "type": "architecture"
  },
  {
    "title": "AI Agent Metadata Exchange via DNS",
    "description": "Leverages existing DNS record types to publish AI agent capability information and metadata. Enables discovery of agent characteristics without defining new DNS record types or protocol modifications.",
    "type": "mechanism"
  },
  {
    "title": "Protocol and Format Indication Pattern",
    "description": "DNS records indicate which access protocol should be used and what format agent information will be provided in, rather than embedding the actual agent data. Separates discovery from data access mechanisms.",
    "type": "pattern"
  },
  {
    "title": "Zero DNS Protocol Extension Requirement",
    "description": "Explicitly designed to work with existing DNS infrastructure without any new message structures, operation codes, response codes, or resource record types. Maintains full backward compatibility with current DNS implementations.",
    "type": "requirement"
  }
]


draft_name: draft-mp-agntcy-ads
prompt_hash: 5c80e659802bb91d
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:54:33.951595+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-mp-agntcy-ads | Agent Directory Service | 31pg
Abstract: The Agent Directory Service (ADS) is a distributed directory service
   designed to store metadata for AI agent applications.  This metadata,
   stored as directory records, enables the discovery of agent
   applications with specific skills for solving various problems.  The
   implementation features distributed directories that interconnect
   through a content-routing protocol.





Independent Submission                                    L. Muscariello
Internet-Draft                                                  R. Polic
Intended status: Informational                                     Cisco
Expires: 28 August 2026                                 24 February 2026


                        Agent Directory Service
                         draft-mp-agntcy-ads-01

Abstract

   The Agent Directory Service (ADS) is a distributed directory service
   designed to store metadata for AI agent applications.  This metadata,
   stored as directory records, enables the discovery of agent
   applications with specific skills for solving various problems.  The
   implementation features distributed directories that interconnect
   through a content-routing protocol.

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://spec.dir.agncty.org.  Status information for this document
   may be found at https://datatracker.ietf.org/doc/draft-mp-agntcy-
   ads/.

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

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





Muscariello & Polic      Expires 28 August 2026                 [Page 1]

Internet-Draft                  agent-dir                  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.

Table of Contents

   1.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Core Capabilities . . . . . . . . . . . . . . . . . . . .   4
     2.2.  Architectural Foundation  . . . . . . . . . . . . . . . .   5
   3.  Storage Architecture  . . . . . . . . . . . . . . . . . . . .   5
     3.1.  Content-Addressed Storage . . . . . . . . . . . . . . . .   5
     3.2.  OCI Integration . . . .

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

response_json:
[
  {
    "title": "Agent Directory Service (ADS)",
    "description": "A distributed directory service that stores metadata for AI agent applications to enable discovery of agents with specific skills. Uses directory records to catalog agent capabilities for problem-solving applications.",
    "type": "architecture"
  },
  {
    "title": "Content-Routing Protocol for Agent Discovery",
    "description": "A protocol that interconnects distributed directories to enable routing and discovery of agent metadata across the network. Facilitates communication between distributed ADS instances.",
    "type": "protocol"
  },
  {
    "title": "Content-Addressed Storage for Agent Metadata",
    "description": "A storage mechanism that uses content addressing to store and retrieve agent metadata records. Provides immutable and verifiable storage of agent directory information.",
    "type": "mechanism"
  },
  {
    "title": "OCI Integration Pattern",
    "description": "Integration with Open Container Initiative standards for packaging and distributing agent applications. Enables containerized deployment and management of AI agents.",
    "type": "pattern"
  },
  {
    "title": "Agent Metadata Directory Records",
    "description": "Structured data format for storing agent application metadata including skills, capabilities, and discovery information. Enables systematic cataloging of agent properties for lookup and matching.",
    "type": "mechanism"
  }
]


draft_name: draft-mpsb-agntcy-messaging
prompt_hash: e8c1419383e4b2be
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:54:41.323462+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-mpsb-agntcy-messaging | An Overview of Messaging Systems and Their Applicability to Agentic AI | 20pg
Abstract: Agentic AI systems require messaging infrastructure that supports
   real-time collaboration, high-volume streaming, and dynamic group
   coordination across distributed networks.  Traditional protocols like
   AMQP, MQTT, and NATS address some requirements but fall short on
   security, particularly regarding [AMQP] [MQTT] [NATS] post-compromise
   protection and quantum-safe encryption essential for autonomous
   agents handling sensitive data.

   This document analyzes six messaging protocols—AMQP, MQTT, NATS, AMQP
   over WebSockets, Kafka, and AGNTCY SLIM—across dimensions critical
   for GenAI agent systems: streaming performance, delivery guarantees,
   security models, and operational complexity.  We examine how each
   protocol's design decisions impact agentic AI deployments, from
   lightweight edge computing scenarios to large-scale multi-
   organizational collaborations.

   AGNTCY SLIM emerges as a purpose-built solution, integrating Message
   Layer Security (MLS) [RFC9420] with gRPC [gRPC] over HTTP/2 [RFC7540]
   to provide quantum-safe end-to-end encryption, efficient streaming,
   and OAuth-based authentication [RFC6749].  Unlike transport-layer
   security approaches, SLIM's MLS implementation ensures secure
   communication even through untrusted intermediaries while supporting
   dynamic group membership changes essential for collaborative AI
   agents.





Network Working Group                                     L. Muscariello
Internet-Draft                                               M. Papalini
Intended status: Informational                                M. Sardara
Expires: 28 August 2026                                         S. Betts
                                                                   Cisco
                                                        24 February 2026


 An Overview of Messaging Systems and Their Applicability to Agentic AI
                     draft-mpsb-agntcy-messaging-01

Abstract

   Agentic AI systems require messaging infrastructure that supports
   real-time collaboration, high-volume streaming, and dynamic group
   coordination across distributed networks.  Traditional protocols like
   AMQP, MQTT, and NATS address some requirements but fall short on
   security, particularly regarding [AMQP] [MQTT] [NATS] post-compromise
   protection and quantum-safe encryption essential for autonomous
   agents handling sensitive data.

   This document analyzes six messaging protocols—AMQP, MQTT, NATS, AMQP
   over WebSockets, Kafka, and AGNTCY SLIM—across dimensions critical
   for GenAI agent systems: streaming performance, delivery guarantees,
   security models, and operational complexity.  We examine how each
   protocol's design decisions impact agentic AI deployments, from
   lightweight edge computing scenarios to large-scale multi-
   organizational collaborations.

   AGNTCY SLIM emerges as a purpose-built solution, integrating Message
   Layer Security (MLS) [RFC9420] with gRPC [gRPC] over HTTP/2 [RFC7540]
   to provide quantum-safe end-to-end encryption, efficient streaming,
   and OAuth-based authentication [RFC6749].  Unlike transport-layer
   security approaches, SLIM's MLS implementation ensures secure
   communication even through untrusted intermediaries while supporting
   dynamic group membership changes essential for collaborative AI
   agents.

Discussion Venues

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

   Source for this draft and an issue tracker can be found at
   https://github.com/agntcy/slim-spec.







Muscariello, et al.      Expires 28 August 2026                 [Page 1]

Internet-Draft            agncty-messaging-eco             February 2026


Status of This Memo

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

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

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

   This Inte

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

response_json:
[
  {
    "title": "AGNTCY SLIM Protocol",
    "description": "A purpose-built messaging protocol for agentic AI that integrates Message Layer Security (MLS) with gRPC over HTTP/2. Provides quantum-safe end-to-end encryption, efficient streaming, and OAuth-based authentication specifically designed for autonomous agent communication.",
    "type": "protocol"
  },
  {
    "title": "MLS-based Post-Compromise Protection",
    "description": "Integration of Message Layer Security (RFC9420) to ensure secure communication even through untrusted intermediaries. Provides post-compromise protection and supports dynamic group membership changes essential for collaborative AI agents.",
    "type": "mechanism"
  },
  {
    "title": "Six-Protocol Comparative Framework",
    "description": "Systematic analysis framework comparing AMQP, MQTT, NATS, AMQP over WebSockets, Kafka, and AGNTCY SLIM across streaming performance, delivery guarantees, security models, and operational complexity. Specifically evaluates protocols for GenAI agent system requirements.",
    "type": "architecture"
  },
  {
    "title": "Quantum-Safe Messaging Architecture",
    "description": "Security model that addresses quantum computing threats to autonomous agent communications. Goes beyond traditional transport-layer security to provide end-to-end protection suitable for sensitive data handling by AI agents.",
    "type": "architecture"
  },
  {
    "title": "Dynamic Group Coordination Pattern",
    "description": "Messaging pattern that supports real-time collaboration and dynamic group membership changes for distributed AI agents. Enables multi-organizational collaborations with automatic membership management.",
    "type": "pattern"
  }
]


draft_name: draft-mpsb-agntcy-slim
prompt_hash: 7be2d0128c238251
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:54:48.275229+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-mpsb-agntcy-slim | Secure Low-Latency Interactive Messaging (SLIM) | 17pg
Abstract: This document specifies the Secure Low-Latency Interactive Real-Time
   Messaging (SLIM), a protocol designed to support real-time
   interactive AI applications at scale.  SLIM provides the transport
   layer for agent protocols (for example, A2A and MCP), combining gRPC
   over HTTP/2 and HTTP/3 with secure messaging, group communication,
   and native RPC semantics.  The protocol provides mechanisms for
   connection management, stream multiplexing, and flow control while
   maintaining compatibility with existing gRPC deployments and
   supporting end-to-end encryption via MLS.





Network Working Group                                     L. Muscariello
Internet-Draft                                               M. Papalini
Intended status: Informational                                M. Sardara
Expires: 28 August 2026                                         S. Betts
                                                                   Cisco
                                                        24 February 2026


            Secure Low-Latency Interactive Messaging (SLIM)
                       draft-mpsb-agntcy-slim-01

Abstract

   This document specifies the Secure Low-Latency Interactive Real-Time
   Messaging (SLIM), a protocol designed to support real-time
   interactive AI applications at scale.  SLIM provides the transport
   layer for agent protocols (for example, A2A and MCP), combining gRPC
   over HTTP/2 and HTTP/3 with secure messaging, group communication,
   and native RPC semantics.  The protocol provides mechanisms for
   connection management, stream multiplexing, and flow control while
   maintaining compatibility with existing gRPC deployments and
   supporting end-to-end encryption via MLS.

Discussion Venues

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

   Source for this draft and an issue tracker can be found at
   https://github.com/agntcy/slim-spec.

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





Muscariello, et al.      Expires 28 August 2026                 [Page 1]

Internet-Draft                 agent-slim                  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.

Table of Contents

   1.  Conventions and Definitions . . . . . . . . . . . . . . . . .   2
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Summary . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Rout

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

response_json:
[
  {
    "title": "SLIM Protocol",
    "description": "A transport protocol that combines gRPC over HTTP/2 and HTTP/3 with secure messaging capabilities for real-time interactive AI applications. Provides the transport layer for agent protocols like A2A and MCP.",
    "type": "protocol"
  },
  {
    "title": "Stream Multiplexing with Flow Control",
    "description": "Mechanisms for multiplexing multiple communication streams over a single connection while providing flow control capabilities. Enables efficient resource utilization for concurrent agent interactions.",
    "type": "mechanism"
  },
  {
    "title": "MLS End-to-End Encryption Integration",
    "description": "Native support for Message Layer Security (MLS) protocol to provide end-to-end encryption for group communications. Ensures secure messaging between multiple agents or participants.",
    "type": "extension"
  },
  {
    "title": "gRPC Compatibility Layer",
    "description": "Maintains backward compatibility with existing gRPC deployments while extending functionality for real-time messaging. Allows seamless integration with current gRPC-based systems.",
    "type": "architecture"
  },
  {
    "title": "Connection Management for Agent Communications",
    "description": "Specialized connection management mechanisms designed for agent-to-agent and multi-party communications. Handles the lifecycle of connections in distributed AI agent environments.",
    "type": "mechanism"
  }
]


draft_name: draft-mvieuille-kerpass-ephemsec
prompt_hash: d51899cd142e2148
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:54:54.533838+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-mvieuille-kerpass-ephemsec | KerPass EPHEMSEC One-Time Password Algorithm | 31pg
Abstract: This document specifies EPHEMSEC, an algorithm for generating one-
   time passwords (OTPs) and one-time keys (OTKs).  Unlike traditional
   OTP algorithms that rely solely on static shared secrets, EPHEMSEC
   uses public key cryptography, which simplifies secure deployment on
   authentication servers.  EPHEMSEC also supports binding the generated
   OTP/OTK to contextual data.  When this context is obtained and
   injected by a trusted agent, the resulting codes can be made
   resistant to phishing and man-in-the-middle attacks.  Finally,
   EPHEMSEC includes a built-in time synchronization mechanism that
   embeds a synchronization hint into the generated output.  This allows
   both parties to deterministically derive the same OTP/OTK value
   without requiring trial-and-error validation, enabling compatibility
   with protocols such as Password Authenticated Key Exchange (PAKE) and
   TLS with Pre-Shared Key (TLS-PSK) that require exact secret
   agreement.





Individual Submission                                        M. Vieuille
Internet-Draft                                          10 November 2025
Intended status: Informational                                          
Expires: 14 May 2026


              KerPass EPHEMSEC One-Time Password Algorithm
                  draft-mvieuille-kerpass-ephemsec-02

Abstract

   This document specifies EPHEMSEC, an algorithm for generating one-
   time passwords (OTPs) and one-time keys (OTKs).  Unlike traditional
   OTP algorithms that rely solely on static shared secrets, EPHEMSEC
   uses public key cryptography, which simplifies secure deployment on
   authentication servers.  EPHEMSEC also supports binding the generated
   OTP/OTK to contextual data.  When this context is obtained and
   injected by a trusted agent, the resulting codes can be made
   resistant to phishing and man-in-the-middle attacks.  Finally,
   EPHEMSEC includes a built-in time synchronization mechanism that
   embeds a synchronization hint into the generated output.  This allows
   both parties to deterministically derive the same OTP/OTK value
   without requiring trial-and-error validation, enabling compatibility
   with protocols such as Password Authenticated Key Exchange (PAKE) and
   TLS with Pre-Shared Key (TLS-PSK) that require exact secret
   agreement.

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

Copyright Notice

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



Vieuille                   Expires 14 May 2026                  [Page 1]

Internet-Draft                  EPHEMSEC                   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  . . . . . . . . . . . . . . . . . . . . . . . .   4


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

response_json:
[
  {
    "title": "EPHEMSEC Algorithm",
    "description": "A one-time password algorithm that uses public key cryptography instead of static shared secrets for OTP/OTK generation. This approach simplifies secure deployment on authentication servers compared to traditional OTP methods.",
    "type": "algorithm"
  },
  {
    "title": "Context Binding",
    "description": "A mechanism that binds generated OTP/OTK values to contextual data injected by a trusted agent. This binding makes the codes resistant to phishing and man-in-the-middle attacks.",
    "type": "mechanism"
  },
  {
    "title": "Embedded Time Synchronization",
    "description": "A built-in synchronization mechanism that embeds timing hints directly into the generated OTP/OTK output. This eliminates the need for trial-and-error validation between parties.",
    "type": "mechanism"
  },
  {
    "title": "Deterministic Secret Derivation",
    "description": "A method that allows both parties to derive the exact same OTP/OTK value without guessing or multiple attempts. This enables compatibility with protocols like PAKE and TLS-PSK that require precise secret agreement.",
    "type": "mechanism"
  },
  {
    "title": "Public Key Based OTP Architecture",
    "description": "An authentication architecture that eliminates the need for shared secret distribution by using asymmetric cryptography for OTP generation. This simplifies key management and server-side security deployment.",
    "type": "architecture"
  }
]


draft_name: draft-mw-spice-actor-chain
prompt_hash: 66780343f0791080
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:55:00.269313+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-mw-spice-actor-chain | Cryptographically Verifiable Actor Chain for OAuth 2.0 Token Exchange | 21pg
Abstract: This document defines an extension to OAuth 2.0 Token Exchange
   [[RFC8693]] that addresses the problem of *Delegation Auditability
   Gaps* in multi-hop service environments.  Current standards treat
   prior actors in a delegation chain as "informational only," providing
   no cryptographic proof of the actual delegation path.  This document
   proposes a new actor_chain claim — a *Cryptographically Verifiable
   Actor Chain* — that replaces the informational-only nested act claim
   with a tamper-evident, ordered record of all actors.  This solution
   enables high-assurance data-plane policy enforcement and forensic
   auditability, particularly for dynamic AI agent-to-agent
   workloads—where susceptibility to *prompt injection attacks* can lead
   to unauthorized delegation paths — the security posture of the entire
   delegation chain is critical for authorization decisions.





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


 Cryptographically Verifiable Actor Chain for OAuth 2.0 Token Exchange
                     draft-mw-spice-actor-chain-00

Abstract

   This document defines an extension to OAuth 2.0 Token Exchange
   [[RFC8693]] that addresses the problem of *Delegation Auditability
   Gaps* in multi-hop service environments.  Current standards treat
   prior actors in a delegation chain as "informational only," providing
   no cryptographic proof of the actual delegation path.  This document
   proposes a new actor_chain claim — a *Cryptographically Verifiable
   Actor Chain* — that replaces the informational-only nested act claim
   with a tamper-evident, ordered record of all actors.  This solution
   enables high-assurance data-plane policy enforcement and forensic
   auditability, particularly for dynamic AI agent-to-agent
   workloads—where susceptibility to *prompt injection attacks* can lead
   to unauthorized delegation paths — the security posture of the entire
   delegation chain is critical for authorization decisions.

Status of This Memo

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

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

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

   This Internet-Draft will expire on 29 August 2026.





Prasad, et al.           Expires 29 August 2026                 [Page 1]

Internet-Draft              SPICE-ACTOR-CHAIN              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 w

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

response_json:
[
  {
    "title": "actor_chain claim",
    "description": "A new JWT claim that provides a cryptographically verifiable, tamper-evident record of all actors in a delegation chain. Replaces the informational-only nested act claim from RFC8693 with cryptographic proof.",
    "type": "mechanism"
  },
  {
    "title": "Cryptographically Verifiable Actor Chain",
    "description": "An ordered, tamper-evident record of all actors in an OAuth 2.0 token delegation chain that enables cryptographic verification of the complete delegation path. Addresses delegation auditability gaps in multi-hop service environments.",
    "type": "architecture"
  },
  {
    "title": "OAuth 2.0 Token Exchange Extension",
    "description": "An extension to RFC8693 OAuth 2.0 Token Exchange that adds cryptographic verifiability to actor chains. Enables high-assurance data-plane policy enforcement and forensic auditability.",
    "type": "extension"
  },
  {
    "title": "Delegation Auditability Gap Resolution",
    "description": "A mechanism to address the problem where prior actors in delegation chains are treated as informational-only without cryptographic proof. Particularly critical for AI agent-to-agent workloads susceptible to prompt injection attacks.",
    "type": "requirement"
  }
]


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





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


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

Abstract

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

Status of This Memo

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

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





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


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

   This Internet-Draft will expire on

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

response_json:
[
  {
    "title": "Transitive Attestation Chain",
    "description": "A cryptographic chain of trust that binds software workloads to their local execution environment through transitive relationships. This mechanism consumes evidence from underlying platforms to create verifiable proof of workload residency.",
    "type": "mechanism"
  },
  {
    "title": "Identity Conveyance Mechanism",
    "description": "A standardized method for conveying workload identity information that includes cryptographic binding to execution environment. This addresses identity portability problems where credentials can be misappropriated and used from unauthorized environments.",
    "type": "mechanism"
  },
  {
    "title": "Proof of Residency",
    "description": "A cryptographic proof that demonstrates a workload is executing in its intended and verified environment. This proof ensures identity validity is tied to verified, integral, or geographically compliant hosts.",
    "type": "mechanism"
  },
  {
    "title": "WIMSE Transitive Attestation Profile",
    "description": "A specific profile within the WIMSE framework that defines how to implement transitive attestation for sovereign workloads. It supports both high-assurance RATS-based profiles and standard Workload Identity Agents for different security levels.",
    "type": "protocol"
  },
  {
    "title": "Dual-Mode Evidence Support",
    "description": "Architecture supporting both high-assurance RATS-based profiles for residency verification and standard Workload Identity Agents for basic co-location proofs. This allows different security assurance levels based on deployment requirements.",
    "type": "architecture"
  }
]


draft_name: draft-mzsg-rtgwg-agent-cross-device-comm-framework
prompt_hash: 0cb95af95ab0ee65
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:55:14.606295+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-mzsg-rtgwg-agent-cross-device-comm-framework | Cross-device Communication Framework for AI Agents in Network Devices | 8pg
Abstract: With the development of large language models (LLM), AI Agent
   software continues to emerge.  AI agents deployed on different
   network devices need to collaborate to accomplish some complex tasks,
   such as network measurement and network troubleshooting.  This
   collaboration requires cross-device communication between AI agents.

   This document proposes a cross-device communication framework for AI
   agents in network devices, and analyzes the requirements for the
   communication protocol.





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


 Cross-device Communication Framework for AI Agents in Network Devices
         draft-mzsg-rtgwg-agent-cross-device-comm-framework-01

Abstract

   With the development of large language models (LLM), AI Agent
   software continues to emerge.  AI agents deployed on different
   network devices need to collaborate to accomplish some complex tasks,
   such as network measurement and network troubleshooting.  This
   collaboration requires cross-device communication between AI agents.

   This document proposes a cross-device communication framework for AI
   agents in network devices, and analyzes the requirements for the
   communication protocol.

Status of This Memo

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

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

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

   This Internet-Draft will expire on 5 May 2026.

Copyright Notice

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




Mao, et al.                Expires 5 May 2026                   [Page 1]

Internet-Draft     Network Device Agent Communication      November 2025


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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Language . . 

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

response_json:
[
  {
    "title": "Cross-device AI Agent Communication Framework",
    "description": "A framework enabling AI agents deployed on different network devices to communicate and collaborate for complex tasks like network measurement and troubleshooting. The framework standardizes how AI agents discover, authenticate, and exchange information across device boundaries.",
    "type": "architecture"
  },
  {
    "title": "AI Agent Collaboration Protocol",
    "description": "A communication protocol specifically designed for AI agents to coordinate tasks across multiple network devices. The protocol defines message formats, authentication mechanisms, and task coordination procedures between distributed AI agents.",
    "type": "protocol"
  },
  {
    "title": "Multi-device Task Distribution Pattern",
    "description": "A pattern for decomposing complex network operations into subtasks that can be distributed across AI agents on different devices. This enables collaborative execution of tasks like network-wide troubleshooting and measurement campaigns.",
    "type": "pattern"
  },
  {
    "title": "Agent Discovery and Registration Mechanism",
    "description": "A mechanism for AI agents to discover other agents on the network and register their capabilities. This enables dynamic formation of agent collaborations based on available resources and expertise.",
    "type": "mechanism"
  },
  {
    "title": "Inter-agent Authentication Requirements",
    "description": "Security requirements for authenticating AI agents before allowing cross-device communication. This includes mutual authentication, capability verification, and secure channel establishment between collaborating agents.",
    "type": "requirement"
  }
]


draft_name: draft-nandakumar-a2a-moqt-transport
prompt_hash: 8e9c3d3af72cf967
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:55:23.821698+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-nandakumar-a2a-moqt-transport | Media over QUIC Transport (MOQT) for Agent-to-Agent Protocol | 12pg
Abstract: This document specifies how the Agent-to-Agent (A2A) protocol can be
   transported over Media over QUIC Transport (MOQT).  MOQT provides a
   publish/subscribe model over QUIC that enables efficient real-time
   communication between AI agents, supporting the A2A protocol's
   requirements for discovery, negotiation, and collaboration while
   leveraging MOQT's streaming capabilities and built-in prioritization
   mechanisms.





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


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

Abstract

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

About This Document

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

   The latest revision of this draft can be found at https://ietf-wg-
   moq.github.io/draft-a2a-moqt-transport/draft-a2a-moqt-transport.html.
   Status information for this document may be found at
   https://datatracker.ietf.org/doc/draft-a2a-moqt-transport/.

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

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

Status of This Memo

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

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





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


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

   This Internet-Draft will expire on 20 April 2026.

Copyright Notice

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

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

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

response_json:
[
  {
    "title": "A2A Message Mapping to MOQT Objects",
    "description": "Defines how Agent-to-Agent protocol messages are encapsulated as MOQT objects with specific track naming conventions and object sequencing. Each A2A message type maps to a distinct MOQT object structure for transport efficiency.",
    "type": "mechanism"
  },
  {
    "title": "Agent Discovery via MOQT Subscribe Model",
    "description": "Leverages MOQT's publish/subscribe pattern to enable AI agents to discover each other by subscribing to well-known discovery tracks. Agents publish their capabilities and availability as MOQT objects on standardized discovery namespaces.",
    "type": "protocol"
  },
  {
    "title": "Prioritized Agent Communication Streams",
    "description": "Utilizes MOQT's built-in prioritization mechanisms to assign different priority levels to A2A message types such as negotiation, collaboration data, and heartbeat messages. Critical agent coordination messages receive higher priority than bulk data transfers.",
    "type": "mechanism"
  },
  {
    "title": "A2A Session Establishment over MOQT",
    "description": "Defines the handshake and negotiation process for establishing A2A sessions using MOQT's connection setup and track subscription mechanisms. Includes capability exchange and parameter negotiation between participating agents.",
    "type": "protocol"
  },
  {
    "title": "Real-time Collaboration State Synchronization",
    "description": "Specifies how agents maintain synchronized collaboration state using MOQT's streaming capabilities with ordered object delivery. State updates are propagated as incremental MOQT objects to minimize latency and bandwidth usage.",
    "type": "pattern"
  }
]


draft_name: draft-nandakumar-agent-sd-jwt
prompt_hash: d0b2f7cac9542016
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:55:29.964973+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-nandakumar-agent-sd-jwt | Selective Disclosure for Agent Discovery and Identity Management (SD- Agent) | 31pg
Abstract: This document defines how Selective Disclosure for JWTs (SD-JWT)
   integrates with Agent-to-Agent (A2A) systems to provide privacy-
   preserving agent discovery and cryptographically verifiable identity
   management.  It specifies the SD-Card format - an SD-JWT encoding of
   Agent Cards that enables selective disclosure of agent capabilities,
   contact information, and operational metadata while maintaining
   cryptographic integrity and preventing correlation across different
   interaction contexts.





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


 Selective Disclosure for Agent Discovery and Identity Management (SD-
                                 Agent)
                    draft-nandakumar-agent-sd-jwt-01

Abstract

   This document defines how Selective Disclosure for JWTs (SD-JWT)
   integrates with Agent-to-Agent (A2A) systems to provide privacy-
   preserving agent discovery and cryptographically verifiable identity
   management.  It specifies the SD-Card format - an SD-JWT encoding of
   Agent Cards that enables selective disclosure of agent capabilities,
   contact information, and operational metadata while maintaining
   cryptographic integrity and preventing correlation across different
   interaction contexts.

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.

   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



Nandakumar & Jennings     Expires 22 April 2026                 [Page 1]

Internet-Draft                Agent-SD-JWT                  October 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  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Notational Conventions  . . . . . . . . . . . . . . . . .   4
   2.  Overview of SD-Card Architecture and Benefits . . . . . . . .   4
   3.  SD-Card Agent Card  . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  Agent Card Structure  . . . . . . . . . . . . . . . . . .

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

response_json:
[
  {
    "title": "SD-Card Format",
    "description": "An SD-JWT encoding of Agent Cards that enables selective disclosure of agent capabilities, contact information, and operational metadata. Maintains cryptographic integrity while preventing correlation across different interaction contexts.",
    "type": "protocol"
  },
  {
    "title": "Privacy-Preserving Agent Discovery",
    "description": "Integration mechanism between Selective Disclosure JWTs and Agent-to-Agent systems for agent discovery. Allows agents to be discovered without revealing unnecessary identifying information.",
    "type": "mechanism"
  },
  {
    "title": "Cryptographically Verifiable Identity Management",
    "description": "Identity management system for agents using SD-JWT cryptographic verification. Enables verification of agent identity claims while maintaining selective disclosure properties.",
    "type": "architecture"
  },
  {
    "title": "Agent Card Structure",
    "description": "Structured format for representing agent information including capabilities, contact details, and operational metadata. Designed to work with selective disclosure mechanisms for privacy preservation.",
    "type": "protocol"
  },
  {
    "title": "Correlation Prevention Mechanism",
    "description": "Technical approach to prevent correlation of agent interactions across different contexts. Uses selective disclosure to limit information exposure in each interaction.",
    "type": "mechanism"
  }
]


draft_name: draft-narajala-ans
prompt_hash: 39a572b8237da032
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:55:37.442293+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-narajala-ans | Agent Name Service (ANS): A Universal Directory for Secure AI Agent Discovery and Interoperability | 48pg
Abstract: The proliferation of AI agents requires robust mechanisms for secure
   discovery.  This document introduces the Agent Name Service (ANS), a
   novel architecture based on DNS addressing the lack of a public agent
   discovery framework.  ANS provides a protocol-agnostic registry
   mechanism that leverages Public Key Infrastructure (PKI) certificates
   for verifiable agent identity and trust.  The architecture features
   several key innovations: a formalized agent registration and renewal
   mechanism for lifecycle management; DNS-inspired naming conventions
   with capability-aware resolution; a modular Protocol Adapter Layer
   supporting diverse communication standards (A2A, MCP, ACP, etc.); and
   precisely defined algorithms for secure resolution.  This
   specification describes structured communication using JSON Schema
   and includes a comprehensive threat analysis.  The result is a
   foundational agent directory service protocol addressing the core
   challenges of secure discovery and interaction in multi-agent
   systems, paving the way for future interoperable, trustworthy, and
   scalable agent ecosystems.





Independent Submission                                          K. Huang
Internet-Draft                                        DistributedApps.ai
Intended status: Experimental                              V.S. Narajala
Expires: 17 November 2025                            Amazon Web Services
                                                               I. Habler
                                                                  Intuit
                                                              A. Sheriff
                                                           Cisco Systems
                                                                May 2025


  Agent Name Service (ANS): A Universal Directory for Secure AI Agent
                     Discovery and Interoperability
                         draft-narajala-ans-00

Abstract

   The proliferation of AI agents requires robust mechanisms for secure
   discovery.  This document introduces the Agent Name Service (ANS), a
   novel architecture based on DNS addressing the lack of a public agent
   discovery framework.  ANS provides a protocol-agnostic registry
   mechanism that leverages Public Key Infrastructure (PKI) certificates
   for verifiable agent identity and trust.  The architecture features
   several key innovations: a formalized agent registration and renewal
   mechanism for lifecycle management; DNS-inspired naming conventions
   with capability-aware resolution; a modular Protocol Adapter Layer
   supporting diverse communication standards (A2A, MCP, ACP, etc.); and
   precisely defined algorithms for secure resolution.  This
   specification describes structured communication using JSON Schema
   and includes a comprehensive threat analysis.  The result is a
   foundational agent directory service protocol addressing the core
   challenges of secure discovery and interaction in multi-agent
   systems, paving the way for future interoperable, trustworthy, and
   scalable agent ecosystems.

Disclaimer

   The present document reflects the authors' individual opinions and
   does not necessarily represent the views of their respective
   employers.

Status of This Memo

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






Huang, et al.           Expires 17 November 2025                [Page 1]

Internet-Draft                     ANS                          May 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 

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

response_json:
[
  {
    "title": "Agent Name Service (ANS) Architecture",
    "description": "A DNS-inspired hierarchical naming system for AI agent discovery that uses PKI certificates for verifiable agent identity. The system provides protocol-agnostic registry mechanisms for secure agent discovery and trust establishment.",
    "type": "architecture"
  },
  {
    "title": "Protocol Adapter Layer",
    "description": "A modular abstraction layer that supports diverse agent communication standards including A2A, MCP, and ACP protocols. This layer enables protocol-agnostic agent interactions while maintaining compatibility across different communication frameworks.",
    "type": "mechanism"
  },
  {
    "title": "Capability-Aware Resolution",
    "description": "A DNS resolution mechanism that extends traditional name resolution to include agent capability information. The system allows clients to discover agents based on both naming conventions and functional capabilities.",
    "type": "mechanism"
  },
  {
    "title": "Agent Registration and Renewal Protocol",
    "description": "A formalized lifecycle management system for agent registration, authentication, and periodic renewal. The protocol defines structured processes for agents to join, maintain presence, and gracefully leave the directory service.",
    "type": "protocol"
  },
  {
    "title": "JSON Schema Communication Framework",
    "description": "Structured communication protocols using JSON Schema for standardized message formats between agents and the ANS system. This provides type safety and validation for all agent discovery and interaction messages.",
    "type": "mechanism"
  }
]


draft_name: draft-narvaneni-agent-uri
prompt_hash: d7cacbf4e6fdfd3f
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:55:43.565147+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-narvaneni-agent-uri | The agent:// Protocol -- A URI-Based Framework for Interoperable Agents | 29pg
Abstract: This document defines the agent:// protocol, a URI template-based
   framework as described in RFC 6570 for addressing, invoking, and
   interoperating with autonomous and semi-autonomous software agents.
   It introduces a layered architecture that supports minimal
   implementations (addressing and transport) and extensible features
   (capability discovery, contracts, orchestration).  The protocol aims
   to foster interoperability among agents across ecosystems, platforms,
   and modalities, enabling composable and collaborative intelligent
   systems.





Independent Submission                                      Y. Narvaneni
Internet-Draft                                    Independent Researcher
Intended status: Experimental                            16 October 2025
Expires: 19 April 2026


The agent:// Protocol -- A URI-Based Framework for Interoperable Agents
                      draft-narvaneni-agent-uri-02

Abstract

   This document defines the agent:// protocol, a URI template-based
   framework as described in RFC 6570 for addressing, invoking, and
   interoperating with autonomous and semi-autonomous software agents.
   It introduces a layered architecture that supports minimal
   implementations (addressing and transport) and extensible features
   (capability discovery, contracts, orchestration).  The protocol aims
   to foster interoperability among agents across ecosystems, platforms,
   and modalities, enabling composable and collaborative intelligent
   systems.

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



Narvaneni                 Expires 19 April 2026                 [Page 1]

Internet-Draft                  agent-uri                   October 2025


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Protocol Scope and Layering . . . . . . . . . . . . . . . . .   4
   4.  URI Scheme Specification  . . . . . . . . . . . . . . . . . .   5
     4.1.  Components  . . . . . . . . . . . . . . . . . . . . . . .   6
     4.2.  ABNF for agent:// URI . . . . . . . . . . . . . . . . . .   6
   5.  Resolution Framework  . . . . . . . . . . . . . . . . . . . .   7
     5.1.  Ecosystem Registries  . . . . . . . . . . . . . . . . . .   8
     5.2.  Trust Anchors . . . . . . . . . . . . . . . . . . . . . .   9
   6.  Transport Bindings  . . . . . . . . 

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

response_json:
[
  {
    "title": "agent:// URI Scheme",
    "description": "A URI template-based framework using RFC 6570 for addressing and invoking software agents. Provides standardized syntax for agent identification across different ecosystems and platforms.",
    "type": "protocol"
  },
  {
    "title": "Layered Agent Architecture",
    "description": "A modular architecture separating minimal implementations (addressing and transport) from extensible features (capability discovery, contracts, orchestration). Enables incremental adoption and feature extension.",
    "type": "architecture"
  },
  {
    "title": "Ecosystem Registries",
    "description": "Registry mechanism for resolving agent URIs to concrete endpoints within specific ecosystems. Provides lookup and discovery services for agent addressing.",
    "type": "mechanism"
  },
  {
    "title": "Trust Anchors",
    "description": "Security mechanism for establishing trust relationships between agents and validating agent identities. Forms the foundation for secure agent-to-agent communication.",
    "type": "mechanism"
  },
  {
    "title": "Transport Bindings",
    "description": "Protocol bindings that map agent:// URIs to concrete transport protocols for actual message delivery. Abstracts underlying transport mechanisms from agent addressing.",
    "type": "mechanism"
  }
]


draft_name: draft-nederveld-adl
prompt_hash: a6c7a99d3c457c9c
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:55:49.587330+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-nederveld-adl | Agent Definition Language (ADL) | 53pg
Abstract: The Agent Definition Language (ADL) provides a standard JSON-based
   format for describing AI agents.  An ADL document declares an agent's
   identity, capabilities, tools, permissions, security requirements,
   data classification, and runtime configuration in a single, machine-
   readable artifact.  ADL enables discovery, interoperability,
   deployment, and lifecycle management of AI agents across diverse
   platforms and runtimes.  This document defines the structure of ADL
   documents, the semantics of their members, conformance requirements
   for implementations, and the registration of the application/adl+json
   media type.





Individual Submission                                       T. Nederveld
Internet-Draft                                     Ironstead Group, LLC.
Intended status: Standards Track                        18 February 2026
Expires: 22 August 2026


                    Agent Definition Language (ADL)
                         draft-nederveld-adl-01

Abstract

   The Agent Definition Language (ADL) provides a standard JSON-based
   format for describing AI agents.  An ADL document declares an agent's
   identity, capabilities, tools, permissions, security requirements,
   data classification, and runtime configuration in a single, machine-
   readable artifact.  ADL enables discovery, interoperability,
   deployment, and lifecycle management of AI agents across diverse
   platforms and runtimes.  This document defines the structure of ADL
   documents, the semantics of their members, conformance requirements
   for implementations, and the registration of the application/adl+json
   media type.

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



Nederveld                Expires 22 August 2026                 [Page 1]

Internet-Draft                     ADL                     February 2026


   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  . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.1.  Purpose . . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.2.  Goals . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     1.3.  Relationship to Other Specifications  . . . . . . . . . .   5
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   6
   3.  Terminology . . . . . . . . . . . . . . .

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

response_json:
[
  {
    "title": "Agent Definition Language (ADL)",
    "description": "A standard JSON-based format for describing AI agents including their identity, capabilities, tools, permissions, security requirements, and runtime configuration. Enables discovery, interoperability, deployment, and lifecycle management of AI agents across diverse platforms.",
    "type": "protocol"
  },
  {
    "title": "application/adl+json Media Type",
    "description": "A new MIME media type registration specifically for ADL documents to enable proper content type identification and handling by web servers and clients.",
    "type": "extension"
  },
  {
    "title": "Agent Identity Declaration",
    "description": "A structured mechanism within ADL documents to declare an agent's identity and core metadata in a machine-readable format.",
    "type": "mechanism"
  },
  {
    "title": "Agent Capability Description",
    "description": "A standardized way to describe and enumerate AI agent capabilities within ADL documents for discovery and matching purposes.",
    "type": "mechanism"
  },
  {
    "title": "Tool and Permission Framework",
    "description": "A structured approach to define what tools an agent can access and what permissions it requires, enabling secure agent deployment and operation.",
    "type": "architecture"
  }
]


draft_name: draft-nennemann-wimse-ect
prompt_hash: 9f9dec640599037a
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:55:56.588319+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-nennemann-wimse-ect | Execution Context Tokens for Distributed Agentic Workflows | 23pg
Abstract: This document defines Execution Context Tokens (ECTs), a JWT-based
   extension to the WIMSE architecture that records task execution
   across distributed agentic workflows.  Each ECT is a signed record of
   a single task, linked to predecessor tasks through a directed acyclic
   graph (DAG).  ECTs reuse the WIMSE signing model and are transported
   in a new Execution-Context HTTP header field alongside existing WIMSE
   identity headers.





WIMSE                                                       C. Nennemann
Internet-Draft                                    Independent Researcher
Intended status: Standards Track                        25 February 2026
Expires: 29 August 2026


       Execution Context Tokens for Distributed Agentic Workflows
                      draft-nennemann-wimse-ect-00

Abstract

   This document defines Execution Context Tokens (ECTs), a JWT-based
   extension to the WIMSE architecture that records task execution
   across distributed agentic workflows.  Each ECT is a signed record of
   a single task, linked to predecessor tasks through a directed acyclic
   graph (DAG).  ECTs reuse the WIMSE signing model and are transported
   in a new Execution-Context HTTP header field alongside existing WIMSE
   identity headers.

Status of This Memo

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

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

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

   This Internet-Draft will expire on 29 August 2026.

Copyright Notice

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











Nennemann                Expires 29 August 2026                 [Page 1]

Internet-Draft           WIMSE Execution Context           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
     1.1.  Scope and Applicability . . . . . . . . . . . . . . . . .   3
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   4
   3.  Execution Context Token Format  . . . . . . . . . . . . . . .   4
     3.1.  JOSE Header . . . . . . . . . . . . . . . . . . . . . . .   5
     3.2.  JWT Claims  . . . . . . . . . . . . . . . . . . . . . . .   5
       3.2.1.  Standard JWT Claims . . . . . . . . . . . . . . . . .   5
       3.2.2.  Execution Context . . . . . . . . . . . . . . . . . .   6
   

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

response_json:
[
  {
    "title": "Execution Context Tokens (ECTs)",
    "description": "JWT-based tokens that record task execution across distributed agentic workflows, with each ECT representing a signed record of a single task. ECTs are linked to predecessor tasks through a directed acyclic graph (DAG) structure.",
    "type": "mechanism"
  },
  {
    "title": "DAG-based Task Linking",
    "description": "A mechanism to connect execution context tokens through a directed acyclic graph where each task references its predecessor tasks. This creates an auditable chain of task execution across distributed workflows.",
    "type": "pattern"
  },
  {
    "title": "Execution-Context HTTP Header",
    "description": "A new HTTP header field specifically designed to transport Execution Context Tokens alongside existing WIMSE identity headers. This provides a standardized way to carry execution context information in HTTP requests.",
    "type": "protocol"
  },
  {
    "title": "WIMSE Signing Model Integration",
    "description": "ECTs reuse the existing WIMSE signing model for token authentication and integrity. This ensures consistency with the broader WIMSE architecture while extending its capabilities.",
    "type": "extension"
  },
  {
    "title": "Distributed Agentic Workflow Support",
    "description": "An architecture extension that enables tracking and auditing of task execution across multiple autonomous agents in distributed systems. This addresses the specific needs of multi-agent orchestration scenarios.",
    "type": "architecture"
  }
]


draft_name: draft-ni-a2a-ai-agent-security-requirements
prompt_hash: 348123f9c048cc77
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:56:03.350293+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-ni-a2a-ai-agent-security-requirements | Security Requirements for AI Agents | 11pg
Abstract: This document discusses security requirements for AI agents, covering
   different stages of security interactions.  These include
   provisioning, registration, cross-domain interconnection, and access
   control.





agent2agent                                                        Y. Ni
Internet-Draft                                                 C. P. Liu
Intended status: Informational                                   N. Geng
Expires: 6 May 2026                                               Q. Gao
                                                                Z. R. Li
                                                                  Huawei
                                                         2 November 2025


                  Security Requirements for AI Agents
             draft-ni-a2a-ai-agent-security-requirements-00

Abstract

   This document discusses security requirements for AI agents, covering
   different stages of security interactions.  These include
   provisioning, registration, cross-domain interconnection, and access
   control.

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.











Ni, et al.                 Expires 6 May 2026                   [Page 1]

Internet-Draft         agent-security-requirements         November 2025


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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Architecture  . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Provisioning and Registration . . . . . . . . . . . . . . . .   4
     3.1.  Identity Provisioning and Management  . . . . . . . . . .   5
     3.2.  Agent Registration  . . . . . . . . . . . . . . . . . . .   6
     3.3.  Agent Onboarding  . . . . . . . . . . . . . . . . . . . .   6
   4.  Cross-Domain Interconnection  . . . . . . . . . . . . . . . .   6
     4.1.  Cross-Domain Identifier Interoperab

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

response_json:
[
  {
    "title": "AI Agent Identity Provisioning",
    "description": "A mechanism for establishing and managing unique identities for AI agents during their lifecycle. This includes secure credential assignment and identity verification processes specific to autonomous agents.",
    "type": "mechanism"
  },
  {
    "title": "Agent Registration Protocol",
    "description": "A standardized protocol for AI agents to register themselves with control systems or directories. This enables discovery and authentication of agents within a security domain.",
    "type": "protocol"
  },
  {
    "title": "Cross-Domain Agent Interconnection",
    "description": "Security framework for enabling AI agents to securely communicate and interact across different administrative or trust domains. This addresses inter-domain authentication and authorization challenges.",
    "type": "architecture"
  },
  {
    "title": "Agent Onboarding Process",
    "description": "A structured procedure for integrating new AI agents into existing security infrastructure. This covers initial setup, credential distribution, and policy assignment for newly deployed agents.",
    "type": "mechanism"
  },
  {
    "title": "Cross-Domain Identifier Interoperability",
    "description": "Technical approach for resolving and validating AI agent identifiers across different domains or organizations. This enables federated identity management for distributed agent systems.",
    "type": "pattern"
  }
]


draft_name: draft-ni-wimse-ai-agent-identity
prompt_hash: 71a230becd0ec0f7
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:56:07.854520+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-ni-wimse-ai-agent-identity | WIMSE Applicability for AI Agents | 10pg
Abstract: This document discusses WIMSE applicability to Agentic AI, so as to
   establish independent identities and credential management mechanisms
   for AI agents.





Workload Identity in Multi System Environments                     Y. Ni
Internet-Draft                                                 C. P. Liu
Intended status: Informational                                    Huawei
Expires: 23 April 2026                                   20 October 2025


                   WIMSE Applicability for AI Agents
                  draft-ni-wimse-ai-agent-identity-01

Abstract

   This document discusses WIMSE applicability to Agentic AI, so as to
   establish independent identities and credential management mechanisms
   for AI agents.

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-ni-wimse-ai-agent-identity/.

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

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.







Ni & Liu                  Expires 23 April 2026                 [Page 1]

Internet-Draft                wime-ai-agent                 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 warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
   3.  Architecture  . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Bootstrapping AI Agent Identity and Credentials . . . . .   4
     3.2.  Attestation . . . . . . . . . . . . 

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

response_json:
[
  {
    "title": "AI Agent Identity Bootstrapping",
    "description": "Mechanism for establishing independent identities and credential management specifically for AI agents in multi-system environments. This extends WIMSE workload identity concepts to autonomous AI systems.",
    "type": "mechanism"
  },
  {
    "title": "WIMSE Extension for Agentic AI",
    "description": "Application of Workload Identity in Multi System Environments (WIMSE) framework to AI agents. Enables AI agents to have distinct identities separate from their hosting systems.",
    "type": "extension"
  },
  {
    "title": "AI Agent Attestation Framework",
    "description": "Attestation mechanism for verifying the integrity and authenticity of AI agents in distributed environments. Provides trust establishment for autonomous AI workloads.",
    "type": "mechanism"
  }
]


draft_name: draft-nsiangani-authenticatedsecuredlayer
prompt_hash: e30c1d4fd214ce32
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:56:13.896949+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-nsiangani-authenticatedsecuredlayer | ASL Authenticated Secure Layer Protocol | 63pg
Abstract: This document specifies ASL (Authenticated Secure Layer), a
cryptographic
   protocol for establishing an authenticated and encrypted
communication
   session based on a novel arithmetic primitive called phi-ns-x (also
known
   as ns-mod). ASL provides a complete handshake and data transport
layer
   without reliance on traditional algorithms like RSA, Diffie-Hellman,
AES or
   SHA. Instead, it builds on the Phi-Ns cryptosystem, which defines a 
   structured quadratic relation between primes and achieves security
through
   non-linear modular arithmetic and combinatorial complexity. 

   ASL includes an initial authentication and key exchange mechanism
where a
   server public key (composed only of specific allowed elements such as
a
   prime modulus and state parameters) is used by a client to establish
shared
   secrets. The protocol uses a stateful encryption transform (phi-ns-x)
for
   data, with each message round incorporating a public state value that
   changes unpredictably. Shared secret parameters control this state
evolution,
   preventing man-in-the-middle and injection attacks by ensuring that
only
   parties with knowledge of the secrets can produce valid ciphertexts.





Network Working Group                                P.J. Nsiangani, Ed.
Internet-Draft                                         ACE Working Group
Intended status: Standards Track                         9 February 2026
Expires: 13 August 2026


                ASL Authenticated Secure Layer Protocol
              draft-nsiangani-authenticatedsecuredlayer-00

Abstract

   Complete ASL draft embedded below as imported text.  Replace this
   abstract with the structured version later if desired.

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

Copyright Notice

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

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







Nsiangani                Expires 13 August 2026                 [Page 1]

Internet-Draft                ASL Protocol                 February 2026


Table of Contents

   1.  Imported Internet-Draft Content . . . . . . . . . . . . . . .   2
   2.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  63
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  63

1.  Imported Internet-Draft Content

ACE Working Group                               Author: P.J. Nsiangani Ed.
Internet-Draft                draft-nsiangani-authenticatedsecuredlayer-00
Intended status: Proposed Standard
Expires: September 2026                                   09 February 2026

                  ASL Authenticated Secure Layer Protocol




Status of this Memo

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

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78 and BCP 79, and except as set forth therein,
   the authors retain all their rights.

   This document is provided under

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

response_json:
[
  {
    "title": "phi-ns-x arithmetic primitive",
    "description": "A novel cryptographic primitive based on structured quadratic relations between primes using non-linear modular arithmetic. Provides the mathematical foundation for the ASL protocol without relying on traditional algorithms like RSA or Diffie-Hellman.",
    "type": "mechanism"
  },
  {
    "title": "Phi-Ns cryptosystem",
    "description": "A cryptographic system that achieves security through non-linear modular arithmetic and combinatorial complexity. Uses structured quadratic relations between primes as its core mathematical approach.",
    "type": "architecture"
  },
  {
    "title": "ASL handshake protocol",
    "description": "An authentication and key exchange mechanism where server public keys contain only specific allowed elements like prime modulus and state parameters. Enables clients to establish shared secrets for secure communication.",
    "type": "protocol"
  },
  {
    "title": "Stateful encryption transform",
    "description": "An encryption method where each message round incorporates a public state value that changes unpredictably. Shared secret parameters control state evolution to prevent man-in-the-middle and injection attacks.",
    "type": "mechanism"
  },
  {
    "title": "State-based attack prevention",
    "description": "A security pattern ensuring only parties with knowledge of shared secrets can produce valid ciphertexts. Uses unpredictable state evolution controlled by shared parameters to prevent attacks.",
    "type": "pattern"
  }
]


