# llm_cache

draft_name: draft-ietf-roll-enrollment-priority
prompt_hash: 071e7086cdcc48a8
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:48:06.567119+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-roll-enrollment-priority | Controlling Secure Network Enrollment in RPL networks | 10pg
  Abstract: [RFC9032] defines a method by which a potential [RFC9031] enrollment
     proxy can announce itself as available for new RPL nodes to enroll on
     a network.  The announcement includes a priority for enrollment.
     This document provides a mechanism by which a Routing Protocol for
     Low-Power and Lossy Networks (RPL) Root can globally disable
     enrollment announcements or adjust the base priority for enrollment
     operations.





  ROLL Working Group                                         M. Richardson
  Internet-Draft                                  Sandelman Software Works
  Intended status: Standards Track                            R. A. Jadhav
  Expires: 28 July 2026                                        Huawei Tech
                                                                P. Thubert
                                                             Cisco Systems
                                                               K. Iwanicki
                                                      University of Warsaw
                                                           24 January 2026


           Controlling Secure Network Enrollment in RPL networks
                   draft-ietf-roll-enrollment-priority-15

  Abstract

     [RFC9032] defines a method by which a potential [RFC9031] enrollment
     proxy can announce itself as available for new RPL nodes to enroll on
     a network.  The announcement includes a priority for enrollment.
     This document provides a mechanism by which a Routing Protocol for
     Low-Power and Lossy Networks (RPL) Root can globally disable
     enrollment announcements or adjust the base priority for enrollment
     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 28 July 2026.

  Copyright Notice

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






  Richardson, et al.        Expires 28 July 2026                  [Page 1]


  Internet-Draft                 join-metric                  January 2026


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

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
       1.1.  Motivation and Overview . . . . . . . . . . . . . . . . .   2
     2.  Terminology . . . . . . . . . . . . . . .

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

response_json:
  [
    {
      "title": "Global Enrollment Disable Control",
      "description": "Mechanism allowing RPL Root to globally disable all enrollment proxy announcements across the network. Provides centralized control over when new devices can join the network.",
      "type": "mechanism"
    },
    {
      "title": "Base Priority Adjustment for Enrollment",
      "description": "System for RPL Root to adjust the base priority value used in enrollment operations by proxy nodes. Allows fine-tuning of enrollment proxy selection preferences.",
      "type": "mechanism"
    },
    {
      "title": "Centralized Enrollment Control Architecture",
      "description": "Architecture where the RPL Root has authority to control enrollment parameters network-wide rather than leaving decisions to individual proxy nodes. Enables coordinated enrollment policies.",
      "type": "architecture"
    },
    {
      "title": "Priority-Based Enrollment Proxy Selection",
      "description": "Extension to RFC9032 enrollment proxy announcements that incorporates Root-controlled priority adjustments. Enhances the existing priority mechanism with centralized oversight.",
      "type": "extension"
    },
    {
      "title": "RPL Root Enrollment Authority",
      "description": "Protocol pattern establishing the RPL Root as the authoritative controller for network enrollment policies. Defines how Root decisions propagate to enrollment proxies.",
      "type": "pattern"
    }
  ]


draft_name: draft-ietf-sml-trust
prompt_hash: 182250515575c1dd
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:48:08.308160+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-sml-trust | Trust and security considerations for Structured Email | 7pg
  Abstract: This document discusses trust and security considerations for
     structured email and provides recommendations for message user agents
     on how to deal with structured data in email messages.

  Discussion Venues

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

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

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





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


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

  Abstract

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

  Discussion Venues

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

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

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

  Status of This Memo

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

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

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

     This Internet-Draft will expire on 23 April 2026.

  Copyright Notice

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



  Happel & Gulbrandsen      Expires 23 April 2026                 [Page 1]


  Internet-Draft                  SML Trust                   October 2025


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

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
     3.  Types of security concerns  . . . . . . . . . . . . . . . . .   3
       3.1.  Spam/virus filters  . . . . . . . . . . . . . . . . . . .   3
       3.2.  Formal display of data  . . . . . . . . . . . . . . . . .   3
    

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

response_json:
  [
    {
      "title": "Structured Email Trust Framework",
      "description": "A security framework for handling structured data embedded within email messages, addressing trust relationships between senders and recipients. Provides guidelines for message user agents to safely process and display structured email content.",
      "type": "architecture"
    },
    {
      "title": "Spam/Virus Filter Integration",
      "description": "Mechanisms for integrating structured email processing with existing spam and virus filtering systems. Ensures that structured data doesn't bypass security controls or create new attack vectors.",
      "type": "mechanism"
    },
    {
      "title": "Formal Data Display Requirements",
      "description": "Requirements for how message user agents should formally display structured data to users. Defines presentation standards to prevent spoofing and ensure clear identification of structured content.",
      "type": "requirement"
    },
    {
      "title": "Structured Email Security Considerations",
      "description": "Comprehensive security analysis of threats and vulnerabilities specific to structured email implementations. Covers attack vectors unique to embedding structured data in email messages.",
      "type": "pattern"
    }
  ]


draft_name: draft-ietf-sshm-mlkem-hybrid-kex
prompt_hash: 6c0469a3026c9a52
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:48:20.494456+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-mlkem-hybrid-kex | PQ/T Hybrid Key Exchange with ML-KEM in SSH | 15pg
  Abstract: This document defines Post-Quantum Traditional (PQ/T) Hybrid key
     exchange methods based on the quantum-resistant Module-Lattice-Based
     Key-Encapsulation Mechanism (ML-KEM) standard and traditional
     Elliptic-curve Diffie–Hellman (ECDH) key exchange schemes.  These
     methods are defined for use in the SSH Transport Layer Protocol.





  SSHM                                                       P. Kampanakis
  Internet-Draft                                                       AWS
  Intended status: Informational                                D. Stebila
  Expires: 30 August 2026                           University of Waterloo
                                                                 T. Hansen
                                                                       AWS
                                                          26 February 2026


                PQ/T Hybrid Key Exchange with ML-KEM in SSH
                    draft-ietf-sshm-mlkem-hybrid-kex-10

  Abstract

     This document defines Post-Quantum Traditional (PQ/T) Hybrid key
     exchange methods based on the quantum-resistant Module-Lattice-Based
     Key-Encapsulation Mechanism (ML-KEM) standard and traditional
     Elliptic-curve Diffie–Hellman (ECDH) key exchange schemes.  These
     methods are defined for use in the SSH Transport Layer 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 30 August 2026.

  Copyright Notice

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










  Kampanakis, et al.       Expires 30 August 2026                 [Page 1]


  Internet-Draft                   PQ SSH                    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 . . . . . . . . . . . . . . . . . .   4
     2.  PQ/T Hybrid Key Exchange  . . . . . . . . . . . . . . . . . .   4
       2.1.  PQ/T Hybrid Key Exchange Method Abstraction . . . . . . .   4
       2.2.  PQ/T Hybrid Key Exchange Message Numbers  . . . . . . . .   5
       2.3.  PQ/T Hybrid Key Exchange Method Names . . . . . . . . . 

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

response_json:
  [
    {
      "title": "PQ/T Hybrid Key Exchange",
      "description": "A key exchange method that combines quantum-resistant ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism) with traditional ECDH for post-quantum security. Both mechanisms are executed in parallel and their shared secrets are combined.",
      "type": "mechanism"
    },
    {
      "title": "ML-KEM Integration in SSH",
      "description": "Integration of the standardized Module-Lattice-Based Key-Encapsulation Mechanism into the SSH Transport Layer Protocol. Provides quantum-resistant key establishment capabilities for SSH connections.",
      "type": "extension"
    },
    {
      "title": "Dual Key Material Combination",
      "description": "A method for securely combining shared secrets from both traditional ECDH and post-quantum ML-KEM key exchanges. Ensures security even if one of the underlying mechanisms is compromised.",
      "type": "mechanism"
    },
    {
      "title": "SSH Transport Layer PQ Extension",
      "description": "Extension to the existing SSH Transport Layer Protocol to support post-quantum cryptographic methods. Maintains backward compatibility while adding quantum-resistant key exchange options.",
      "type": "extension"
    },
    {
      "title": "Hybrid Key Exchange Message Format",
      "description": "Specification of new SSH message formats and message numbers for carrying both traditional and post-quantum key exchange data. Defines the wire protocol for hybrid key exchanges in SSH.",
      "type": "protocol"
    }
  ]


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"
    }
  ]


