# llm_cache

draft_name: draft-chang-agent-context-interaction
prompt_hash: ddc74a7e1fbe065f
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:39:56.267907+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-chang-agent-context-interaction | Agent Context Interaction Optimizations | 13pg
  Abstract: The context distribution is important in a multi-agent system, which
     will impact the execution latency, token consumption, and task
     completion success rate, especially in a complex and multi-round
     workflow.

     This document specifies the scenarios and procedures of agent context
     distribution as well as the corresponding optimization during the
     procedures in order to provide precise control of the context
     distribution among the multiple agents.





  Working Group                                                   Z. Chang
  Internet-Draft                                                   S. Peng
  Intended status: Standards Track                     Huawei Technologies
  Expires: 16 August 2026                                 12 February 2026


                  Agent Context Interaction Optimizations
                  draft-chang-agent-context-interaction-01

  Abstract

     The context distribution is important in a multi-agent system, which
     will impact the execution latency, token consumption, and task
     completion success rate, especially in a complex and multi-round
     workflow.

     This document specifies the scenarios and procedures of agent context
     distribution as well as the corresponding optimization during the
     procedures in order to provide precise control of the context
     distribution among the multiple 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 16 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



  Chang & Peng             Expires 16 August 2026                 [Page 1]


  Internet-Draft                  PCECC-SR                   February 2026


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

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
       2.1.  Conventions and Terminology . . . . . . . . . . . . . . .   3
       2.2.  Requirements Language . . . . . . . . . . . . . . . . . .   4
     3.  Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.  Agent Context Interaction Optimizations . . . . . . . . . . .   6
       4.1.  Overview of Agent Context Interaction Optimizations . . .   6
       4.2.  Contex

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

response_json:
  [
    {
      "title": "Agent Context Distribution",
      "description": "A mechanism for distributing context information among multiple agents in a multi-agent system. Impacts execution latency, token consumption, and task completion success rates in complex multi-round workflows.",
      "type": "mechanism"
    },
    {
      "title": "Context Distribution Optimization Procedures",
      "description": "Specified procedures for optimizing context distribution during agent interactions. Provides precise control of how context is shared and managed across multiple agents.",
      "type": "protocol"
    },
    {
      "title": "Multi-Round Workflow Context Management",
      "description": "A pattern for managing context across multiple rounds of agent interactions in complex workflows. Addresses the specific challenges of maintaining context coherence over extended interactions.",
      "type": "pattern"
    },
    {
      "title": "Agent Context Interaction Scenarios",
      "description": "Defined scenarios that specify when and how agent context distribution should occur. Establishes standardized conditions for context sharing between agents.",
      "type": "requirement"
    }
  ]


draft_name: draft-chang-agent-token-efficient
prompt_hash: e28ebc04360f784a
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:40:02.973919+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-chang-agent-token-efficient | A Token-efficient Data Layer for Agentic Communication | 12pg
  Abstract: Agentic communication fundamentally differs from traditional machine
     communication in that its outputs are recursively consumed and
     interpreted by Large Language Models (LLMs).  This unique
     characteristic makes efficient use of the model's limited context a
     critical requirement.  However, current agent communication protocols
     - such as the Model Context Protocol (MCP) and Agent-to-Agent (A2A) -
     often suffer from token or context bloat, caused by redundant schema
     definitions, verbose message structures, and inefficient capability
     exchanges.  As a result, a substantial number of tokens are
     unnecessarily consumed within the model’s context window.

     To address these issues, this draft defines the Agentic Data
     Optimization Layer (ADOL), a general and foundational data-layer for
     agent communication.  ADOL introduces a set of backward-compatible
     optimizations, including schema deduplication through JSON
     references, adaptive inclusion of optional fields, controllable
     response verbosity, and retrieval-based selection mechanisms.
     Collectively, these mechanisms reduce token consumption, enhance
     context efficiency, and provide a scalable foundation for future
     agent communication frameworks.





  Network Working Group                                           Z. Chang
  Internet-Draft                                                     J. Li
  Intended status: Informational                                    Z. Cao
  Expires: 16 July 2026                                             Huawei
                                                           12 January 2026


           A Token-efficient Data Layer for Agentic Communication
                    draft-chang-agent-token-efficient-02

  Abstract

     Agentic communication fundamentally differs from traditional machine
     communication in that its outputs are recursively consumed and
     interpreted by Large Language Models (LLMs).  This unique
     characteristic makes efficient use of the model's limited context a
     critical requirement.  However, current agent communication protocols
     - such as the Model Context Protocol (MCP) and Agent-to-Agent (A2A) -
     often suffer from token or context bloat, caused by redundant schema
     definitions, verbose message structures, and inefficient capability
     exchanges.  As a result, a substantial number of tokens are
     unnecessarily consumed within the model’s context window.

     To address these issues, this draft defines the Agentic Data
     Optimization Layer (ADOL), a general and foundational data-layer for
     agent communication.  ADOL introduces a set of backward-compatible
     optimizations, including schema deduplication through JSON
     references, adaptive inclusion of optional fields, controllable
     response verbosity, and retrieval-based selection mechanisms.
     Collectively, these mechanisms reduce token consumption, enhance
     context efficiency, and provide a scalable foundation for future
     agent communication frameworks.

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




  Chang, et al.             Expires 16 July 2026                  [Page 1]


  Internet-Draft              Abbreviated Title               January 2026


     This Internet-Draft will expire on 16 July 2026.

  Copyright Notice

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

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

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

response_json:
  [
    {
      "title": "Schema Deduplication via JSON References",
      "description": "Uses JSON $ref pointers to eliminate redundant schema definitions in agent communication messages. Replaces repeated schema blocks with references to reduce token consumption.",
      "type": "mechanism"
    },
    {
      "title": "Adaptive Optional Field Inclusion",
      "description": "Selectively includes or omits optional fields in messages based on context relevance and token budget constraints. Provides dynamic message structure optimization.",
      "type": "mechanism"
    },
    {
      "title": "Controllable Response Verbosity",
      "description": "Allows agents to specify desired response detail levels to match available context window capacity. Enables token-aware response generation.",
      "type": "mechanism"
    },
    {
      "title": "Retrieval-based Selection Mechanisms",
      "description": "Implements intelligent filtering and selection of relevant data elements for inclusion in agent communications. Reduces unnecessary information transfer.",
      "type": "mechanism"
    },
    {
      "title": "Agentic Data Optimization Layer (ADOL)",
      "description": "A foundational data layer that provides backward-compatible optimizations for agent communication protocols. Serves as an optimization layer between existing protocols and LLM processing.",
      "type": "architecture"
    }
  ]


draft_name: draft-chen-agent-decoupled-authorization-model
prompt_hash: 3cb53f18e763a7f8
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:40:09.760787+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-chen-agent-decoupled-authorization-model | A Decoupled Authorization Model for Agent2Agent | 6pg
  Abstract: This document proposes a framework for dynamic, intent-based
     authorization for AI Agents.  The primary goal is to enable fine-
     grained, Just-in-Time (JIT) permissions based on an agent's specific
     intent and behavioral trustworthiness, rather than a long-lived
     identity or role, achieve decoupling of authorization policies from
     business operations.





  Internet Engineering Task Force                                  M. Chen
  Internet-Draft                                                     L. Su
  Intended status: Informational                              China Mobile
  Expires: 18 August 2026                                 14 February 2026


              A Decoupled Authorization Model for Agent2Agent
             draft-chen-agent-decoupled-authorization-model-00

  Abstract

     This document proposes a framework for dynamic, intent-based
     authorization for AI Agents.  The primary goal is to enable fine-
     grained, Just-in-Time (JIT) permissions based on an agent's specific
     intent and behavioral trustworthiness, rather than a long-lived
     identity or role, achieve decoupling of authorization policies from
     business 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 18 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.



  Chen & Su                Expires 18 August 2026                 [Page 1]


  Internet-Draft           AI Agent Authorization            February 2026


  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   2
     3.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   3
     4.  Analysis of Oauth for Agent-to-Agent Authorization  . . . . .   4
       4.1.  What OAuth2.0 can do  . . . . . . . . . . . . . . . . . .   4
       4.2.  Remaining Challenges and Open Issues  . . . . . . . . . .   4
     5.  Decoupled Authorization Model . . . . . . . . . . . . . . . .   5
       5.1.  Architecture overview . . . . . . . . . . . . . . . . . .   5
       5.2.  Authorization Execution Point

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

response_json:
  [
    {
      "title": "Intent-Based Authorization",
      "description": "Authorization mechanism that grants permissions based on an agent's specific intent rather than static identity or role. Enables fine-grained access control tied to the agent's current purpose and goals.",
      "type": "mechanism"
    },
    {
      "title": "Just-in-Time (JIT) Permissions",
      "description": "Dynamic permission granting system that provides access rights exactly when needed rather than pre-provisioning long-lived credentials. Reduces attack surface by minimizing permission lifetime.",
      "type": "mechanism"
    },
    {
      "title": "Behavioral Trustworthiness Assessment",
      "description": "Authorization component that evaluates an agent's behavioral patterns and trustworthiness as input to access decisions. Goes beyond identity verification to consider agent behavior history.",
      "type": "mechanism"
    },
    {
      "title": "Decoupled Authorization Architecture",
      "description": "System design that separates authorization policies from business operations, allowing independent evolution of security controls. Enables policy changes without modifying core business logic.",
      "type": "architecture"
    },
    {
      "title": "Authorization Execution Point",
      "description": "Architectural component that serves as the enforcement mechanism for authorization decisions in the agent-to-agent communication flow. Acts as the policy decision and enforcement point.",
      "type": "architecture"
    }
  ]


draft_name: draft-chen-ai-agent-auth-new-requirements
prompt_hash: b77ffdac9eba1ff1
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:40:16.235990+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-chen-ai-agent-auth-new-requirements | New requirements for Authentication and Authorization in the AI Agents era | 5pg
  Abstract: AI Agents are rapidly evolving from academic concepts into the core
     engines driving next-generation applications.  However, their
     autonomy, dynamic nature, and complex delegation relationships pose a
     fundamental challenge to our existing authentication and
     authorization frameworks, which were designed for human users and
     traditional software.  This document dissects the novel
     characteristics of AI Agents and outlines the new requirements for
     authentication and authorization which can manage dynamic behavior
     rather than verifying static identity.





  Internet Engineering Task Force                                  M. Chen
  Internet-Draft                                                     L. Su
  Intended status: Standards Track                            China Mobile
  Expires: 10 July 2026                                     6 January 2026


   New requirements for Authentication and Authorization in the AI Agents
                                    era
                draft-chen-ai-agent-auth-new-requirements-00

  Abstract

     AI Agents are rapidly evolving from academic concepts into the core
     engines driving next-generation applications.  However, their
     autonomy, dynamic nature, and complex delegation relationships pose a
     fundamental challenge to our existing authentication and
     authorization frameworks, which were designed for human users and
     traditional software.  This document dissects the novel
     characteristics of AI Agents and outlines the new requirements for
     authentication and authorization which can manage dynamic behavior
     rather than verifying static identity.

  Status of This Memo

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

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

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

     This Internet-Draft will expire on 10 July 2026.

  Copyright Notice

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

     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



  Chen & Su                 Expires 10 July 2026                  [Page 1]


  Internet-Draft  AI Agent Authentication and Authorizatio    January 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.  New Authentication Requirements:From "Who Are You?" to "Are You
             Still Trustworthy?" . . . . . . . . . . . . . . . . . . .   3
       3.1.  New Requirement 1: Traceable Identity and Provenance  . .   3
    

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

response_json:
  [
    {
      "title": "Dynamic Behavior Authentication",
      "description": "Authentication framework that manages and verifies dynamic behavior patterns rather than static identity credentials. Addresses the challenge of AI agents whose behavior changes over time.",
      "type": "requirement"
    },
    {
      "title": "Traceable Identity and Provenance",
      "description": "Requirement for establishing verifiable chains of identity and origin for AI agents. Enables tracking of agent creation, modification, and delegation relationships.",
      "type": "requirement"
    },
    {
      "title": "Continuous Trustworthiness Verification",
      "description": "Shift from one-time 'Who are you?' authentication to ongoing 'Are you still trustworthy?' verification. Addresses autonomous agents that operate independently over extended periods.",
      "type": "pattern"
    },
    {
      "title": "Complex Delegation Relationship Management",
      "description": "Framework for handling multi-layered delegation chains where AI agents can delegate authority to other agents. Requires new authorization models beyond traditional human-centric approaches.",
      "type": "architecture"
    },
    {
      "title": "Autonomous Agent Authentication Framework",
      "description": "New authentication paradigm specifically designed for AI agents that operate independently without human intervention. Replaces human-centric authentication models.",
      "type": "architecture"
    }
  ]


draft_name: draft-chen-lake-edhoc-aka
prompt_hash: 1986eaf5da6570ad
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:40:22.092193+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-chen-lake-edhoc-aka | EDHOC Authenticated with AKA | 8pg
  Abstract: This document defines the EDHOC-AKA authentication method based on
     the Authentication and Key Agreement(AKA) protocol and the Ephemeral
     Diffie-Hellman Over COSE(EDHOC) key exchange protocol.  This method
     is designed to provide efficient mobile communication network access
     authentication for scenarios with limited computing and network
     resources (such as Non-Terrestrial Network, NTN).  EDHOC-AKA utilizes
     the pre-shared long-term key and employs symmetric cryptography
     techniques to achieve mutual authentication and key derivation.  It
     ensures security while significantly enhancing the authentication
     efficiency.





  Internet Engineering Task Force                                  M. Chen
  Internet-Draft                                                     L. Su
  Intended status: Standards Track                            China Mobile
  Expires: 23 April 2026                                   20 October 2025


                        EDHOC Authenticated with AKA
                        draft-chen-lake-edhoc-aka-01

  Abstract

     This document defines the EDHOC-AKA authentication method based on
     the Authentication and Key Agreement(AKA) protocol and the Ephemeral
     Diffie-Hellman Over COSE(EDHOC) key exchange protocol.  This method
     is designed to provide efficient mobile communication network access
     authentication for scenarios with limited computing and network
     resources (such as Non-Terrestrial Network, NTN).  EDHOC-AKA utilizes
     the pre-shared long-term key and employs symmetric cryptography
     techniques to achieve mutual authentication and key derivation.  It
     ensures security while significantly enhancing the authentication
     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 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



  Chen & Su                 Expires 23 April 2026                 [Page 1]


  Internet-Draft                EDHOC PSK AKA                 October 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.  Protocol  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
       3.1.  Credentials . . . . . . . . . . . . . . . . . . . . . . .   3
         3.1.1.  CRED_AKA_X  . . . . . . . . . . . . . . . . . . . . .   

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

response_json:
  [
    {
      "title": "EDHOC-AKA Authentication Method",
      "description": "A hybrid authentication method that combines AKA (Authentication and Key Agreement) protocol with EDHOC (Ephemeral Diffie-Hellman Over COSE) key exchange. Uses pre-shared long-term keys and symmetric cryptography for mutual authentication and key derivation.",
      "type": "protocol"
    },
    {
      "title": "AKA-based Credential Structure",
      "description": "Defines CRED_AKA_X credential format that integrates AKA parameters into EDHOC credential structure. Enables mobile network authentication credentials to be used within EDHOC protocol flows.",
      "type": "mechanism"
    },
    {
      "title": "Symmetric Cryptography Optimization",
      "description": "Employs symmetric cryptographic techniques instead of asymmetric operations to reduce computational overhead. Specifically designed for resource-constrained environments like Non-Terrestrial Networks (NTN).",
      "type": "pattern"
    },
    {
      "title": "Mobile Network Access Authentication",
      "description": "Adapts EDHOC for mobile communication network scenarios with limited computing and network resources. Provides efficient authentication suitable for cellular and satellite communication environments.",
      "type": "architecture"
    }
  ]


draft_name: draft-chen-oauth-rar-agent-extensions
prompt_hash: 1937a1eb19993ecf
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:40:29.245690+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-chen-oauth-rar-agent-extensions | Policy and Lifecycle Extensions for OAuth Rich Authorization Requests | 9pg
  Abstract: OAuth 2.0 Rich Authorization Requests (RAR), as defined in RFC 9396,
     provides a mechanism for clients to request fine-grained, structured
     authorization details.  However, in emerging ecosystems of
     collaborating AI agents and long-running automated tasks, two
     critical authorization dimensions remain implicit: the required
     security assurance level of the authorization policy and the strict
     binding of authorization lifetime to a task's lifecycle.

     This document extends the "authorization_details" object of RAR by
     introducing two new members: "policy_context" and
     "lifecycle_binding".  The "policy_context" member allows a client to
     explicitly request that the authorization be evaluated and granted
     under a specific policy assurance level, mitigating policy downgrade
     attacks and enhancing user consent.  The "lifecycle_binding" member
     enables the validity of an authorization grant to be tied directly to
     the state of an external entity, such as an automated task, ensuring
     permissions are automatically and immediately revoked upon task
     completion.  These extensions provide a standardized way to achieve
     more secure, transparent, and context-aware authorization in complex,
     automated environments.





  oauth                                                            M. Chen
  Internet-Draft                                                     L. Su
  Intended status: Standards Track                            China Mobile
  Expires: 8 August 2026                                   4 February 2026


   Policy and Lifecycle Extensions for OAuth Rich Authorization Requests
                  draft-chen-oauth-rar-agent-extensions-00

  Abstract

     OAuth 2.0 Rich Authorization Requests (RAR), as defined in RFC 9396,
     provides a mechanism for clients to request fine-grained, structured
     authorization details.  However, in emerging ecosystems of
     collaborating AI agents and long-running automated tasks, two
     critical authorization dimensions remain implicit: the required
     security assurance level of the authorization policy and the strict
     binding of authorization lifetime to a task's lifecycle.

     This document extends the "authorization_details" object of RAR by
     introducing two new members: "policy_context" and
     "lifecycle_binding".  The "policy_context" member allows a client to
     explicitly request that the authorization be evaluated and granted
     under a specific policy assurance level, mitigating policy downgrade
     attacks and enhancing user consent.  The "lifecycle_binding" member
     enables the validity of an authorization grant to be tied directly to
     the state of an external entity, such as an automated task, ensuring
     permissions are automatically and immediately revoked upon task
     completion.  These extensions provide a standardized way to achieve
     more secure, transparent, and context-aware authorization in complex,
     automated 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."

     This Internet-Draft will expire on 8 August 2026.



  Chen & Su                 Expires 8 August 2026                 [Page 1]


  Internet-Draft             extensions for RAR              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": "policy_context member",
      "description": "A new member added to the RAR authorization_details object that allows clients to explicitly request authorization under a specific policy assurance level. This mitigates policy downgrade attacks and enhances user consent by making security requirements explicit.",
      "type": "extension"
    },
    {
      "title": "lifecycle_binding member", 
      "description": "A new member in the authorization_details object that ties authorization grant validity to the state of an external entity like an automated task. This ensures permissions are automatically revoked when the bound entity completes or terminates.",
      "type": "extension"
    },
    {
      "title": "Policy downgrade attack mitigation",
      "description": "A security mechanism that prevents attackers from forcing authorization decisions under weaker security policies. Achieved through explicit policy context specification in authorization requests.",
      "type": "mechanism"
    },
    {
      "title": "External entity state binding",
      "description": "A pattern where OAuth authorization lifetime is directly coupled to external system states such as AI agent tasks or automated processes. This enables automatic permission revocation based on external lifecycle events.",
      "type": "pattern"
    },
    {
      "title": "Task-bound authorization lifecycle",
      "description": "An authorization model where permissions automatically expire when associated automated tasks complete. This provides immediate cleanup of permissions without manual intervention or fixed timeouts.",
      "type": "mechanism"
    }
  ]


draft_name: draft-chuyi-nmrg-ai-agent-network
prompt_hash: 99f7d1baa9790d81
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:40:35.796102+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-chuyi-nmrg-ai-agent-network | Large Model based Agents for Network Operation and Maintenance | 16pg
  Abstract: Current advancements in AI technologies, particularly large models,
     have demonstrated immense potential in content generation, reasoning,
     analysis and so on, providing robust technical support for network
     automation and self-intelligence.  However, in practical network
     operations, challenges such as system isolation and fragmented data
     lead to extensive manual, repetitive, and inefficient tasks, the
     improvement of intelligence level is very necessary.  This document
     identifies typical scenarios requiring enhanced intelligence, and
     explains how AI Agents and large model technologies can empower
     networks to address operational pain points, reduce manual efforts,
     and explore impacts on network data, system architectures, and
     interfaces correspondingly.  It further explores and summarizes
     standardization efforts in implementation.





  Network Management Research Group                                 C. Guo
  Internet-Draft                                              China Mobile
  Intended status: Informational                              October 2025
  Expires: 23 April 2026


       Large Model based Agents for Network Operation and Maintenance
                    draft-chuyi-nmrg-ai-agent-network-02

  Abstract

     Current advancements in AI technologies, particularly large models,
     have demonstrated immense potential in content generation, reasoning,
     analysis and so on, providing robust technical support for network
     automation and self-intelligence.  However, in practical network
     operations, challenges such as system isolation and fragmented data
     lead to extensive manual, repetitive, and inefficient tasks, the
     improvement of intelligence level is very necessary.  This document
     identifies typical scenarios requiring enhanced intelligence, and
     explains how AI Agents and large model technologies can empower
     networks to address operational pain points, reduce manual efforts,
     and explore impacts on network data, system architectures, and
     interfaces correspondingly.  It further explores and summarizes
     standardization efforts in implementation.

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




  Guo                       Expires 23 April 2026                 [Page 1]


  Internet-Draft  Large Model based Agents for Network Ope    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 wit

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

response_json:
  [
    {
      "title": "AI Agent Network Architecture",
      "description": "A proposed architecture that integrates large language model-based agents into network operations systems to address system isolation and data fragmentation. The architecture enables automated reasoning and decision-making across previously disconnected network management systems.",
      "type": "architecture"
    },
    {
      "title": "Network Data Integration Pattern",
      "description": "A pattern for consolidating fragmented network operational data to enable AI agents to have comprehensive visibility across network systems. This addresses the challenge of isolated data silos in current network operations.",
      "type": "pattern"
    },
    {
      "title": "Large Model Network Automation Mechanism",
      "description": "A mechanism that leverages large language models' content generation and reasoning capabilities specifically for network automation tasks. It reduces manual, repetitive operational tasks through intelligent automation.",
      "type": "mechanism"
    },
    {
      "title": "Enhanced Network Intelligence Requirements",
      "description": "Requirements for improving intelligence levels in network operations through AI agent integration. Addresses typical scenarios where manual intervention currently dominates network maintenance tasks.",
      "type": "requirement"
    }
  ]


draft_name: draft-condrey-rats-witnessd-enrollment
prompt_hash: 94470e40f6ca138f
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:40:41.643068+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-condrey-rats-witnessd-enrollment | Trust Anchor Bootstrap Protocol for Proof of Process | 13pg
  Abstract: This document specifies a trust anchor bootstrap protocol for the
     witnessd Proof of Process framework.  The protocol defines how new
     devices enter the witnessd ecosystem, how device keys are provisioned
     and verified, and how Verifiers discover and validate device trust
     anchors.

     Three enrollment modes are defined: self-sovereign mode for
     individual users, organizational mode for enterprise deployments, and
     public registry mode for federated trust ecosystems.





  Remote ATtestation procedureS                                 D. Condrey
  Internet-Draft                                          Writerslogic Inc
  Intended status: Standards Track                         7 February 2026
  Expires: 11 August 2026


            Trust Anchor Bootstrap Protocol for Proof of Process
                 draft-condrey-rats-witnessd-enrollment-00

  Abstract

     This document specifies a trust anchor bootstrap protocol for the
     witnessd Proof of Process framework.  The protocol defines how new
     devices enter the witnessd ecosystem, how device keys are provisioned
     and verified, and how Verifiers discover and validate device trust
     anchors.

     Three enrollment modes are defined: self-sovereign mode for
     individual users, organizational mode for enterprise deployments, and
     public registry mode for federated trust ecosystems.

  About This Document

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

     This is a companion document to draft-condrey-rats-pop, which defines
     the core Proof of Process evidence framework.  This document
     addresses the bootstrapping problem: how do Verifiers know which
     device keys to 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 11 August 2026.





  Condrey                  Expires 11 August 2026                 [Page 1]


  Internet-Draft             witnessd Enrollment             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  . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.1.  Requirements Notation . . . . . . . . . . . . . . . . . .   3
     2.  Enrollment Modes  . . . . . . . . . . . . . . . . . . . . . .   3
       2.1.  Self-Sover

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

response_json:
  [
    {
      "title": "Trust Anchor Bootstrap Protocol",
      "description": "Protocol for provisioning and verifying device keys in the witnessd Proof of Process framework. Defines how new devices enter the ecosystem and how Verifiers discover and validate device trust anchors.",
      "type": "protocol"
    },
    {
      "title": "Self-Sovereign Enrollment Mode",
      "description": "Enrollment mode designed for individual users to bootstrap trust anchors without requiring organizational infrastructure. Enables autonomous device onboarding in the witnessd ecosystem.",
      "type": "mechanism"
    },
    {
      "title": "Organizational Enrollment Mode",
      "description": "Enterprise deployment enrollment mode for managed device onboarding within organizational boundaries. Supports centralized trust anchor management and verification.",
      "type": "mechanism"
    },
    {
      "title": "Public Registry Enrollment Mode",
      "description": "Federated trust ecosystem enrollment mode using public registries for trust anchor discovery. Enables cross-organizational device verification and trust establishment.",
      "type": "mechanism"
    },
    {
      "title": "Device Key Provisioning Framework",
      "description": "Systematic approach for generating, distributing, and validating cryptographic keys for devices entering the witnessd ecosystem. Addresses the bootstrapping problem for trust establishment.",
      "type": "architecture"
    }
  ]


draft_name: draft-contario-totp-secure-enrollment
prompt_hash: b5a495854fb6de6a
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:40:47.571428+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-contario-totp-secure-enrollment | TOTP Secure Enrollment | 21pg
  Abstract: This document describes a secure key exchange scheme that extends the
     Time-Based One-Time Password (TOTP) [RFC6238] de facto enrollment
     method to prevent compromise of the non-expiring TOTP key by
     photographic capture of the QR code or by intentional or
     unintentional persistence of the key string in email, SMS, or other
     systems outside of the TOTP authenticator system itself.





  Network Working Group                                        B. Contario
  Internet-Draft                                             Silent Sector
  Intended status: Informational                         27 September 2025
  Expires: 31 March 2026


                           TOTP Secure Enrollment
                  draft-contario-totp-secure-enrollment-02

  Abstract

     This document describes a secure key exchange scheme that extends the
     Time-Based One-Time Password (TOTP) [RFC6238] de facto enrollment
     method to prevent compromise of the non-expiring TOTP key by
     photographic capture of the QR code or by intentional or
     unintentional persistence of the key string in email, SMS, or other
     systems outside of the TOTP authenticator system itself.

  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://Silent-
     Sector.github.io/totp-secure-enrollment/draft-contario-totp-secure-
     enrollment.html.  Status information for this document may be found
     at https://datatracker.ietf.org/doc/draft-contario-totp-secure-
     enrollment/.

     Source for this draft and an issue tracker can be found at
     https://github.com/Silent-Sector/totp-secure-enrollment.

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




  Contario                  Expires 31 March 2026                 [Page 1]


  Internet-Draft           totp-secure-enrollment           September 2025


  Copyright Notice

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

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

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.1.  Terminologies . . . . . . . . . . . . . . . . . . . . . .   3
       1.2.  Requ

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

response_json:
  [
    {
      "title": "Secure TOTP Key Exchange",
      "description": "A secure key exchange scheme that extends TOTP enrollment to prevent compromise of non-expiring TOTP keys during the enrollment process. Protects against photographic capture of QR codes and unintentional key persistence in communication systems.",
      "type": "protocol"
    },
    {
      "title": "QR Code Capture Protection",
      "description": "Mechanism to prevent compromise of TOTP keys through photographic capture of QR codes during enrollment. Addresses the vulnerability of static QR codes containing the full TOTP secret.",
      "type": "mechanism"
    },
    {
      "title": "Key Persistence Prevention",
      "description": "Protection against intentional or unintentional persistence of TOTP key strings in email, SMS, or other systems outside the TOTP authenticator. Prevents key exposure through communication channel storage.",
      "type": "mechanism"
    },
    {
      "title": "Extended TOTP Enrollment Method",
      "description": "Enhancement to the de facto TOTP enrollment process defined in RFC6238 to improve security during the key distribution phase. Maintains compatibility while adding security layers.",
      "type": "extension"
    }
  ]


draft_name: draft-cosmos-protocol-specification
prompt_hash: 425cc80318d1111e
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:40:53.716093+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-cosmos-protocol-specification | The Cosmos Protocol Specification (Trust-Native Semantic Protocol) | 23pg
  Abstract: The Cosmos Protocol (Trust-Native Semantic Protocol) defines a badge-
     based identity and communication system intended for deployments that
     prefer not to rely on external consensus or blockchain
     infrastructure.  Cosmos supports trust-native communication and
     decentralized identity management through cryptographically signed
     badges that operate without mandatory external trust systems.  The
     protocol also supports passwordless authentication flows using badge-
     based credentials and biometric authenticators, reducing reliance on
     traditional password mechanisms.

     The Cosmos Protocol introduces several foundational innovations that
     together form an integrated identity-native communication substrate.
     These include: (1) Badge-Based Identity -- cryptographically signed,
     capability-bearing identifiers designed to operate without requiring
     blockchain or distributed ledger infrastructure, while allowing
     deployments to integrate such systems if desired; (2) Trust Scoring
     -- reputation-anchored trust models (domain-bound for DNS networks,
     star-bound for Cosmos-native networks) that enable cross-star
     capability granting and trust-based authorization without requiring
     new badges; (3) Lumen Encryption -- uses post-quantum candidate
     cryptographic primitives (see [RFC-XXXX-Lumen]), badge-native
     encryption designed to support forward secrecy; (4) Echo Grammar --
     semantic message structures that provide intent clarity, UI hints,
     and agent compatibility; (5) Capsule System -- universal, encrypted
     containers for communication and storage; (6) Slipstream Transport
     (TNTP) -- a trust-native transport protocol with badge-based
     sessions, intent-aware routing, and the ability to operate without
     blockchain or external consensus dependencies; (7) Ramp and SDFF
     Serialization -- deterministic text and binary formats that provide
     canonical structure for all Cosmos data; (8) Profile System --
     portable, domain-scop





  Network Working Group                                       A. Hernandez
  Internet-Draft                                        Varlil Corporation
  Intended status: Standards Track                          1 January 2026
  Expires: 5 July 2026


     The Cosmos Protocol Specification (Trust-Native Semantic Protocol)
                   draft-cosmos-protocol-specification-00

  Abstract

     The Cosmos Protocol (Trust-Native Semantic Protocol) defines a badge-
     based identity and communication system intended for deployments that
     prefer not to rely on external consensus or blockchain
     infrastructure.  Cosmos supports trust-native communication and
     decentralized identity management through cryptographically signed
     badges that operate without mandatory external trust systems.  The
     protocol also supports passwordless authentication flows using badge-
     based credentials and biometric authenticators, reducing reliance on
     traditional password mechanisms.

     The Cosmos Protocol introduces several foundational innovations that
     together form an integrated identity-native communication substrate.
     These include: (1) Badge-Based Identity -- cryptographically signed,
     capability-bearing identifiers designed to operate without requiring
     blockchain or distributed ledger infrastructure, while allowing
     deployments to integrate such systems if desired; (2) Trust Scoring
     -- reputation-anchored trust models (domain-bound for DNS networks,
     star-bound for Cosmos-native networks) that enable cross-star
     capability granting and trust-based authorization without requiring
     new badges; (3) Lumen Encryption -- uses post-quantum candidate
     cryptographic primitives (see [RFC-XXXX-Lumen]), badge-native
     encryption designed to support forward secrecy; (4) Echo Grammar --
     semantic message structures that provide intent clarity, UI hints,
     and agent compatibility; (5) Capsule System -- universal, encrypted
     containers for communication and storage; (6) Slipstream Transport
     (TNTP) -- a trust-native transport protocol with badge-based
     sessions, intent-aware routing, and the ability to operate without
     blockchain or external consensus dependencies; (7) Ramp and SDFF
     Serialization -- deterministic text and binary formats that provide
     canonical structure for all Cosmos data; (8) Profile System --
     portable, domain-scoped user profiles with badge-based access
     control; and (9) Productivity Protocols -- standardized scheduling,
     contacts, and calendaring protocols (Comet, Nebula, Nova) that
     provide a badge-native model that can serve as an alternative to
     multiple legacy standards.





  Hernandez                  Expires 5 July 2026                  [Page 1]


  Internet-Draft  The Cosmos Protocol Specification (Trust    January 2026


     Cosmos badges are Ramp (Slope Data Format, SDF) documents with
     optional DID compatibility, allowing integration with existing
     decentralized identity systems while preserving 

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

response_json:
  [
    {
      "title": "Badge-Based Identity",
      "description": "Cryptographically signed, capability-bearing identifiers that operate without requiring blockchain or distributed ledger infrastructure. Badges are Ramp (SDF) documents with optional DID compatibility.",
      "type": "mechanism"
    },
    {
      "title": "Trust Scoring",
      "description": "Reputation-anchored trust models that are domain-bound for DNS networks and star-bound for Cosmos-native networks. Enables cross-star capability granting and trust-based authorization without requiring new badges.",
      "type": "mechanism"
    },
    {
      "title": "Lumen Encryption",
      "description": "Post-quantum candidate cryptographic primitives for badge-native encryption designed to support forward secrecy. Uses trust-native cryptographic methods tied to badge identity.",
      "type": "mechanism"
    },
    {
      "title": "Echo Grammar",
      "description": "Semantic message structures that provide intent clarity, UI hints, and agent compatibility. Defines structured communication formats for trust-native messaging.",
      "type": "protocol"
    },
    {
      "title": "Slipstream Transport (TNTP)",
      "description": "Trust-native transport protocol with badge-based sessions and intent-aware routing. Operates without blockchain or external consensus dependencies.",
      "type": "protocol"
    },
    {
      "title": "Ramp and SDFF Serialization",
      "description": "Deterministic text and binary formats (Slope Data Format) that provide canonical structure for all Cosmos data. Enables standardized data representation across the protocol.",
      "type": "mechanism"
    }
  ]


draft_name: draft-cui-ai-agent-discovery-invocation
prompt_hash: 1bc7867fa9a98e08
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:41:00.166491+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-cui-ai-agent-discovery-invocation | AI Agent Discovery and Invocation Protocol | 18pg
  Abstract: This document proposes a standardized protocol for discovery and
     invocation of AI agents.  It defines a common metadata format for
     describing AI agents (including capabilities, I/O specifications,
     supported languages, tags, authentication methods, etc.), a
     capability-based discovery mechanism, and a unified RESTful
     invocation interface.

     This revision additionally specifies an optional extension that
     enables intent-based agent selection prior to discovery and
     invocation, without changing existing discovery or invocation
     semantics.

     The goal is to enable cross-platform interoperability among AI agents
     by providing a discover-and-match mechanism and a unified invocation
     entry point.  Security considerations, including authentication and
     trust measures, are also discussed.  This specification aims to
     facilitate the formation of multi-agent systems by making it easy to
     find the right agent for a task and invoke it in a consistent manner
     across different vendors and platforms.





  Network Working Group                                             Y. Cui
  Internet-Draft                                       Tsinghua University
  Intended status: Informational                                   Y. Chao
  Expires: 16 August 2026                                            C. Du
                                                   Zhongguancun Laboratory
                                                          12 February 2026


                 AI Agent Discovery and Invocation Protocol
                 draft-cui-ai-agent-discovery-invocation-01

  Abstract

     This document proposes a standardized protocol for discovery and
     invocation of AI agents.  It defines a common metadata format for
     describing AI agents (including capabilities, I/O specifications,
     supported languages, tags, authentication methods, etc.), a
     capability-based discovery mechanism, and a unified RESTful
     invocation interface.

     This revision additionally specifies an optional extension that
     enables intent-based agent selection prior to discovery and
     invocation, without changing existing discovery or invocation
     semantics.

     The goal is to enable cross-platform interoperability among AI agents
     by providing a discover-and-match mechanism and a unified invocation
     entry point.  Security considerations, including authentication and
     trust measures, are also discussed.  This specification aims to
     facilitate the formation of multi-agent systems by making it easy to
     find the right agent for a task and invoke it in a consistent manner
     across different vendors and platforms.

  About This Document

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

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

     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.



  Cui, et al.              Expires 16 August 2026                 [Page 1]


  Internet-Draft                    AIDIP                    February 2026


  Status of This Memo

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

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

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

     This Internet

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

response_json:
  [
    {
      "title": "AI Agent Metadata Format",
      "description": "A standardized JSON schema for describing AI agents including capabilities, I/O specifications, supported languages, tags, and authentication methods. This enables consistent agent description across different platforms and vendors.",
      "type": "protocol"
    },
    {
      "title": "Capability-Based Discovery Mechanism",
      "description": "A discovery system that allows clients to search for AI agents based on their declared capabilities and functional attributes. Enables automated matching of tasks to appropriate agents.",
      "type": "mechanism"
    },
    {
      "title": "Unified RESTful Invocation Interface",
      "description": "A standardized REST API interface for invoking AI agents regardless of their underlying implementation or platform. Provides consistent invocation semantics across different agent providers.",
      "type": "protocol"
    },
    {
      "title": "Intent-Based Agent Selection Extension",
      "description": "An optional extension that enables selection of agents based on high-level intent before the discovery and invocation process. Works without modifying existing discovery or invocation semantics.",
      "type": "extension"
    },
    {
      "title": "Cross-Platform Agent Interoperability Architecture",
      "description": "An architectural pattern that enables AI agents from different vendors and platforms to be discovered and invoked through a common protocol. Facilitates the formation of multi-agent systems.",
      "type": "architecture"
    }
  ]


draft_name: draft-cui-ai-agent-task
prompt_hash: 46c51c416bcecde1
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:41:07.183408+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-cui-ai-agent-task | Task-oriented Coordination Requirements for AI Agent Protocols | 10pg
  Abstract: AI agent communication requires intelligent task level coordination
     to manage dynamic workloads across large-scale, heterogeneous
     networking environments.  This draft proposes general requirements
     for an agent protocol to enable autonomous task coordination at
     scale, including dynamic task discovery, negotiation, and context-
     aware scheduling with real-time adaptability.





  Network Working Group                                             Y. Cui
  Internet-Draft                                       Tsinghua University
  Intended status: Informational                                     C. Du
  Expires: 8 January 2026                          Zhongguancun Laboratory
                                                               7 July 2025


       Task-oriented Coordination Requirements for AI Agent Protocols
                         draft-cui-ai-agent-task-00

  Abstract

     AI agent communication requires intelligent task level coordination
     to manage dynamic workloads across large-scale, heterogeneous
     networking environments.  This draft proposes general requirements
     for an agent protocol to enable autonomous task coordination at
     scale, including dynamic task discovery, negotiation, and context-
     aware scheduling with real-time adaptability.

  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.











  Cui & Du                 Expires 8 January 2026                 [Page 1]


  Internet-Draft           Agent Task Coordination               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.  Purpose . . . . . . . . . . . . . . . . . . . . . . . . .   2
       1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
       1.3.  Task Coordination Framework . . . . . . . . . . . . . . .   3
     2.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.  Necessity . . . . . . . . . . . . . . . . . . . . . . . . . .   4
       3.1.  Task Complexity . . . . . . . . . . . . . . . . . . . . .   4
       3.2. 

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

response_json:
  [
    {
      "title": "Dynamic Task Discovery",
      "description": "A mechanism for AI agents to automatically discover available tasks and capabilities across heterogeneous network environments. Enables autonomous identification of work opportunities without centralized coordination.",
      "type": "mechanism"
    },
    {
      "title": "Agent Task Negotiation",
      "description": "A protocol for AI agents to negotiate task assignments, resource allocation, and execution parameters. Supports autonomous agreement on workload distribution among multiple agents.",
      "type": "protocol"
    },
    {
      "title": "Context-Aware Task Scheduling",
      "description": "A scheduling mechanism that considers environmental context, agent capabilities, and current network conditions when assigning tasks. Optimizes task execution based on real-time system state.",
      "type": "mechanism"
    },
    {
      "title": "Real-Time Task Adaptability",
      "description": "A requirement for agent protocols to support dynamic adjustment of task execution based on changing conditions. Enables agents to modify their behavior without manual intervention.",
      "type": "requirement"
    },
    {
      "title": "Task Coordination Framework",
      "description": "An architectural framework for managing intelligent task-level coordination among AI agents in large-scale environments. Provides structure for autonomous workload management across heterogeneous systems.",
      "type": "architecture"
    }
  ]


draft_name: draft-cui-dmsc-agent-cdi
prompt_hash: c04be9ad5e50b0ee
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:41:14.670706+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-cui-dmsc-agent-cdi | Cross-Domain Interoperability Framework for AI Agent Collaboration | 34pg
  Abstract: This document defines a framework for enabling seamless cross-domain
     interoperability among AI agents operating across different networks,
     administrative domains, and heterogeneous platforms.  The framework
     addresses the challenges of identity federation, trust establishment,
     policy harmonization, and secure communication that arise when AI
     agents from distinct administrative realms need to collaborate on
     shared tasks.  It specifies mechanisms for agent discovery,
     capability negotiation, trust delegation, and federated policy
     enforcement, enabling scalable and secure multi-domain AI
     collaboration without requiring centralized control.





  WG Working Group                                                  Y. Cui
  Internet-Draft                                       Tsinghua University
  Intended status: Informational                          11 February 2026
  Expires: 15 August 2026


     Cross-Domain Interoperability Framework for AI Agent Collaboration
                        draft-cui-dmsc-agent-cdi-00

  Abstract

     This document defines a framework for enabling seamless cross-domain
     interoperability among AI agents operating across different networks,
     administrative domains, and heterogeneous platforms.  The framework
     addresses the challenges of identity federation, trust establishment,
     policy harmonization, and secure communication that arise when AI
     agents from distinct administrative realms need to collaborate on
     shared tasks.  It specifies mechanisms for agent discovery,
     capability negotiation, trust delegation, and federated policy
     enforcement, enabling scalable and secure multi-domain AI
     collaboration without requiring centralized control.

  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-cui-dmsc-agent-cdi/.

     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.

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




  Cui                      Expires 15 August 2026                 [Page 1]


  Internet-Draft                  CDI-Agent                  February 2026


     This Internet-Draft will expire on 15 August 2026.

  Copyright Notice

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

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

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

response_json:
  [
    {
      "title": "Cross-Domain Agent Discovery",
      "description": "A mechanism for AI agents to discover and identify potential collaboration partners across different administrative domains and network boundaries. Enables agents to locate relevant capabilities without requiring centralized registries.",
      "type": "mechanism"
    },
    {
      "title": "Federated Agent Identity Framework",
      "description": "An identity federation system that allows AI agents from different domains to establish and verify identities across administrative boundaries. Supports cross-domain authentication without requiring shared identity providers.",
      "type": "architecture"
    },
    {
      "title": "Agent Capability Negotiation Protocol",
      "description": "A protocol that enables AI agents to exchange and negotiate their capabilities, constraints, and service offerings when establishing cross-domain collaborations. Facilitates dynamic capability matching and agreement.",
      "type": "protocol"
    },
    {
      "title": "Trust Delegation Mechanism",
      "description": "A system for establishing and propagating trust relationships between AI agents across domain boundaries through delegation chains. Enables transitive trust without direct bilateral relationships.",
      "type": "mechanism"
    },
    {
      "title": "Federated Policy Enforcement",
      "description": "A framework for harmonizing and enforcing policies across multiple administrative domains while maintaining local policy autonomy. Supports policy conflict resolution and unified enforcement for cross-domain agent interactions.",
      "type": "architecture"
    }
  ]


draft_name: draft-cui-dns-native-agent-naming-resolution
prompt_hash: c6db61645fa2ddae
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:41:21.512620+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-cui-dns-native-agent-naming-resolution | DNS-Native AI Agent Naming and Resolution | 26pg
  Abstract: This document specifies a DNS-native naming and resolution mechanism
     for AI agents.  Building upon the DNS specification (RFC 1035) and
     leveraging Service Binding (SVCB) records (RFC 9460, RFC 9461), it
     defines how AI agents are identified using Fully Qualified Domain
     Names (FQDNs), how their identity and cryptographic keys are
     published via DNS TXT records, and how multi-version, multi-protocol
     service resolution is achieved using DNS SVCB records.  The design
     philosophy emphasizes DNS as the authoritative source, protocol
     autonomy, and graceful degradation for legacy clients.  When version
     is not explicitly specified, the highest priority (default) version
     is provided.  This approach maximizes reuse of existing Internet
     infrastructure while enabling the rapid evolution of AI agent
     ecosystems.





  WG Working Group                                                  Y. Cui
  Internet-Draft                                       Tsinghua University
  Intended status: Informational                          22 December 2025
  Expires: 25 June 2026


                 DNS-Native AI Agent Naming and Resolution
              draft-cui-dns-native-agent-naming-resolution-00

  Abstract

     This document specifies a DNS-native naming and resolution mechanism
     for AI agents.  Building upon the DNS specification (RFC 1035) and
     leveraging Service Binding (SVCB) records (RFC 9460, RFC 9461), it
     defines how AI agents are identified using Fully Qualified Domain
     Names (FQDNs), how their identity and cryptographic keys are
     published via DNS TXT records, and how multi-version, multi-protocol
     service resolution is achieved using DNS SVCB records.  The design
     philosophy emphasizes DNS as the authoritative source, protocol
     autonomy, and graceful degradation for legacy clients.  When version
     is not explicitly specified, the highest priority (default) version
     is provided.  This approach maximizes reuse of existing Internet
     infrastructure while enabling the rapid evolution of AI agent
     ecosystems.

  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://nobrowning.github.io/dns-native-agent-naming-resolution/
     draft-cui-dns-native-agent-naming-resolution.html.  Status
     information for this document may be found at
     https://datatracker.ietf.org/doc/draft-cui-dns-native-agent-naming-
     resolution/.

     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/nobrowning/dns-native-agent-naming-resolution.

  Status of This Memo

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




  Cui                       Expires 25 June 2026                  [Page 1]


  Internet-Draft                   DN-ANR                    December 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 25 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

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

response_json:
  [
    {
      "title": "FQDN-based AI Agent Identification",
      "description": "AI agents are identified using Fully Qualified Domain Names (FQDNs) as unique identifiers. This leverages existing DNS namespace hierarchies for agent naming and discovery.",
      "type": "mechanism"
    },
    {
      "title": "DNS TXT Records for Agent Identity and Keys",
      "description": "Agent identity information and cryptographic keys are published and distributed using DNS TXT records. This enables cryptographic verification of agent authenticity through DNS infrastructure.",
      "type": "mechanism"
    },
    {
      "title": "SVCB Records for Multi-Version Agent Resolution",
      "description": "Service Binding (SVCB) records are used to resolve AI agents across multiple versions and protocols. This enables clients to discover and connect to appropriate agent service endpoints.",
      "type": "protocol"
    },
    {
      "title": "Default Version Selection via Priority",
      "description": "When no specific version is requested, the system provides the highest priority (default) version of an AI agent. This simplifies client implementation while supporting version evolution.",
      "type": "mechanism"
    },
    {
      "title": "DNS-as-Authority Architecture",
      "description": "The architecture positions DNS as the single authoritative source for agent information and service discovery. This centralizes trust and reduces dependency on external registries or directories.",
      "type": "architecture"
    }
  ]


draft_name: draft-cui-nmrg-auto-test
prompt_hash: 4691fd1e809d292a
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:41:28.224697+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-cui-nmrg-auto-test | Framework and Automation Levels for AI-Assisted Network Protocol Testing | 14pg
  Abstract: This document presents an AI-assisted framework for automating the
     testing of network protocol implementations.  The proposed framework
     consists of components such as protocol formalization, test case
     generation, test script and configuration generation, and iterative
     refinement through feedback mechanisms.  In addition, the document
     defines a set of Automation Maturity Levels for network protocol
     testing, ranging from fully manual procedures (Level 0) to fully
     autonomous and adaptive systems (Level 5), providing a structured
     approach to evaluating and advancing automation capabilities.
     Leveraging recent advancements in artificial intelligence,
     particularly large language models (LLMs), the framework illustrates
     how AI technologies can be applied to enhance the efficiency,
     scalability, and consistency of protocol testing.  This document
     serves both as a reference architecture and as a roadmap to guide the
     evolution of protocol testing practices in light of emerging AI
     capabilities.





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


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

  Abstract

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

  About This Document

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

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

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

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





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


  Internet-Draft                   FALANPT                   February 2026


  Status of This Memo

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

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

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

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

response_json:
  [
    {
      "title": "Protocol Formalization Component",
      "description": "AI-assisted component that converts protocol specifications into formal, machine-readable representations suitable for automated test generation. Uses LLMs to parse RFC documents and extract protocol state machines and message formats.",
      "type": "mechanism"
    },
    {
      "title": "AI-Driven Test Case Generation",
      "description": "Automated system that generates comprehensive test cases from formalized protocol specifications using AI techniques. Produces both positive and negative test scenarios covering protocol edge cases and error conditions.",
      "type": "mechanism"
    },
    {
      "title": "Test Script and Configuration Generation",
      "description": "Component that automatically produces executable test scripts and network configurations from high-level test cases. Translates abstract test scenarios into platform-specific implementation code.",
      "type": "mechanism"
    },
    {
      "title": "Iterative Refinement Feedback Loop",
      "description": "Continuous improvement mechanism that analyzes test execution results to refine test generation and protocol understanding. Uses feedback to enhance AI model accuracy and test coverage over time.",
      "type": "pattern"
    },
    {
      "title": "Automation Maturity Levels Framework",
      "description": "Six-level classification system (Level 0-5) for evaluating protocol testing automation capabilities from fully manual to fully autonomous. Provides structured assessment criteria for advancing automation implementations.",
      "type": "framework"
    }
  ]


draft_name: draft-cui-nmrg-llm-benchmark
prompt_hash: f4b28f9379164d48
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:41:36.217564+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-cui-nmrg-llm-benchmark | A Framework to Evaluate LLM Agents for Network Configuration | 25pg
  Abstract: This document specifies an evaluation framework and related
     definitions for intent-driven network configuration using Large
     Language Model(LLM)-based agents.  The framework combines an
     emulator-based interactive environment, a suite of representative
     tasks, and multi-dimensional metrics to assess reasoning quality,
     command accuracy, and functional correctness.  The framework aims to
     enable reproducible, comprehensive, and fair comparisons among LLM-
     driven network configuration approaches.





  Network Management Research Group                                 Y. Cui
  Internet-Draft                                                    C. Liu
  Intended status: Informational                                    X. Xie
  Expires: 3 July 2026                                 Tsinghua University
                                                                     C. Du
                                                   Zhongguancun Laboratory
                                                          30 December 2025


        A Framework to Evaluate LLM Agents for Network Configuration
                      draft-cui-nmrg-llm-benchmark-01

  Abstract

     This document specifies an evaluation framework and related
     definitions for intent-driven network configuration using Large
     Language Model(LLM)-based agents.  The framework combines an
     emulator-based interactive environment, a suite of representative
     tasks, and multi-dimensional metrics to assess reasoning quality,
     command accuracy, and functional correctness.  The framework aims to
     enable reproducible, comprehensive, and fair comparisons among LLM-
     driven network configuration approaches.

  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://datatracker.ietf.org/doc/draft-cui-nmrg-llm-benchmark/.
     Status information for this document may be found at
     https://datatracker.ietf.org/doc/draft-cui-nmrg-llm-benchmark/.

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

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

  Status of This Memo

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







  Cui, et al.                Expires 3 July 2026                  [Page 1]


  Internet-Draft                NetConfBench                 December 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 3 July 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.i

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

response_json:
  [
    {
      "title": "Emulator-based Interactive Environment",
      "description": "A virtualized network environment that allows LLM agents to interact with network devices and execute configuration commands in real-time. The emulator provides realistic network topologies and device responses for testing LLM-driven network configuration approaches.",
      "type": "mechanism"
    },
    {
      "title": "Multi-dimensional LLM Evaluation Metrics",
      "description": "A comprehensive scoring system that assesses LLM performance across reasoning quality, command accuracy, and functional correctness dimensions. These metrics enable quantitative comparison of different LLM agents' network configuration capabilities.",
      "type": "pattern"
    },
    {
      "title": "Intent-driven Network Configuration Protocol",
      "description": "A framework that translates high-level network intents into specific device configuration commands using LLM agents. The protocol defines how natural language requirements are processed and converted to executable network configurations.",
      "type": "protocol"
    },
    {
      "title": "Representative Task Suite",
      "description": "A standardized collection of network configuration scenarios and challenges designed to comprehensively test LLM agent capabilities. The task suite covers various network management operations from basic setup to complex troubleshooting scenarios.",
      "type": "mechanism"
    },
    {
      "title": "Reproducible Benchmark Framework",
      "description": "A systematic evaluation methodology that ensures consistent and comparable testing conditions across different LLM implementations. The framework standardizes testing procedures, environments, and success criteria for network configuration tasks.",
      "type": "architecture"
    }
  ]


draft_name: draft-cui-nmrg-llm-nm
prompt_hash: ae5120dd130c4ea4
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:41:42.586335+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-cui-nmrg-llm-nm | A Framework for LLM Agent-Assisted Network Management with Human-in-the-Loop | 21pg
  Abstract: This document defines an interoperable framework that facilitates
     collaborative network management between Large Language Models (LLMs)
     agents and human operators.  The proposed framework introduces an
     enhanced telemetry module, an LLM agent decision module, and
     interaction data models between human operators and LLM agent-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                                                Y. Cui
  Internet-Draft                                       Tsinghua University
  Intended status: Informational                                   M. Xing
  Expires: 21 April 2026                                          L. Zhang
                                                   Zhongguancun Laboratory
                                                           18 October 2025


  A Framework for LLM Agent-Assisted Network Management with Human-in-the-
                                    Loop
                          draft-cui-nmrg-llm-nm-01

  Abstract

     This document defines an interoperable framework that facilitates
     collaborative network management between Large Language Models (LLMs)
     agents and human operators.  The proposed framework introduces an
     enhanced telemetry module, an LLM agent decision module, and
     interaction data models between human operators and LLM agent-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.

  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://xmzzyo.github.io/draft_llm_nm/draft-cui-nmrg-llm-nm.html.
     Status information for this document may be found at
     https://datatracker.ietf.org/doc/draft-cui-nmrg-llm-nm/.

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

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

  Status of This Memo

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






  Cui, et al.               Expires 21 April 2026                 [Page 1]


  Internet-Draft                   LLM4Net                    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 21 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 (htt

  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 component that collects and preprocesses network data specifically for LLM consumption. It transforms traditional network metrics into formats suitable for language model processing.",
      "type": "mechanism"
    },
    {
      "title": "LLM Agent Decision Module", 
      "description": "A core component that processes network telemetry data using large language models to make automated network management decisions. It serves as the AI reasoning engine within the framework.",
      "type": "mechanism"
    },
    {
      "title": "Human-LLM Interaction Data Models",
      "description": "Structured data formats that define how human operators and LLM agents exchange information in network management scenarios. These models standardize communication between human and AI components.",
      "type": "pattern"
    },
    {
      "title": "Human-in-the-Loop Workflows",
      "description": "Defined processes that ensure human oversight and approval for LLM-generated network management decisions. These workflows enforce human control over automated actions.",
      "type": "mechanism"
    },
    {
      "title": "LLM-Human Collaborative Framework",
      "description": "An interoperable architecture that integrates LLM agents with existing network management systems while maintaining human operator involvement. It bridges AI automation with traditional network operations.",
      "type": "architecture"
    }
  ]


draft_name: draft-dhir-http-agent-profile
prompt_hash: 9c8ef89bf6d2c64b
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:41:48.710598+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-dhir-http-agent-profile | HTTP Agent Profile (HAP): Authenticated and Monetized Agent Traffic on the Web | 13pg
  Abstract: Autonomous agents such as LLM-powered crawlers, browser-integrated
     assistants, and task-oriented bots are rapidly becoming first-class
     HTTP clients on the Web. Today’s infrastructure largely assumes a
     human behind a browser and monetizes content through advertising and
     coarse subscriptions.  Automated agents consume content at scale
     without rendering pages or viewing ads, exacerbating bot-mitigation
     arms races and economic misalignment between content providers and AI
     systems.

     This document describes an HTTP Agent Profile (HAP) that enables: (1)
     cryptographic authentication of agent traffic using HTTP Message
     Signatures; (2) clear separation between human and agent traffic
     using privacy-preserving human tokens; and (3) protocol-level value
     exchange for agents via HTTP status code 402 ("Payment Required") and
     pluggable micropayment mechanisms.  The profile reuses existing HTTP
     features and is designed for incremental deployment via reverse
     proxies, CDNs, and agent libraries.





  Network Working Group                                            S. Dhir
  Internet-Draft                                               Independent
  Intended status: Informational                          24 November 2025
  Expires: 28 May 2026


   HTTP Agent Profile (HAP): Authenticated and Monetized Agent Traffic on
                                  the Web
                      draft-dhir-http-agent-profile-00

  Abstract

     Autonomous agents such as LLM-powered crawlers, browser-integrated
     assistants, and task-oriented bots are rapidly becoming first-class
     HTTP clients on the Web. Today’s infrastructure largely assumes a
     human behind a browser and monetizes content through advertising and
     coarse subscriptions.  Automated agents consume content at scale
     without rendering pages or viewing ads, exacerbating bot-mitigation
     arms races and economic misalignment between content providers and AI
     systems.

     This document describes an HTTP Agent Profile (HAP) that enables: (1)
     cryptographic authentication of agent traffic using HTTP Message
     Signatures; (2) clear separation between human and agent traffic
     using privacy-preserving human tokens; and (3) protocol-level value
     exchange for agents via HTTP status code 402 ("Payment Required") and
     pluggable micropayment mechanisms.  The profile reuses existing HTTP
     features and is designed for incremental deployment via reverse
     proxies, CDNs, and agent libraries.

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





  Dhir                       Expires 28 May 2026                  [Page 1]


  Internet-Draft             HTTP Agent Profile              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 Rev

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

response_json:
  [
    {
      "title": "HTTP Message Signatures for Agent Authentication",
      "description": "Cryptographic authentication mechanism for agent traffic using HTTP Message Signatures to verify the identity and integrity of automated agent requests.",
      "type": "mechanism"
    },
    {
      "title": "Privacy-Preserving Human Tokens",
      "description": "Token-based system to clearly separate human traffic from agent traffic while preserving user privacy in the identification process.",
      "type": "mechanism"
    },
    {
      "title": "HTTP 402 Micropayment Integration",
      "description": "Protocol-level value exchange system leveraging HTTP status code 402 (Payment Required) with pluggable micropayment mechanisms for agent content access.",
      "type": "protocol"
    },
    {
      "title": "Agent-Aware Traffic Differentiation",
      "description": "Architecture pattern for distinguishing between human browser traffic and autonomous agent traffic at the HTTP protocol level.",
      "type": "pattern"
    },
    {
      "title": "Incremental HAP Deployment via Infrastructure",
      "description": "Deployment strategy enabling HTTP Agent Profile adoption through reverse proxies, CDNs, and agent libraries without requiring full stack changes.",
      "type": "architecture"
    }
  ]


draft_name: draft-diaconu-agents-authz-info-sharing
prompt_hash: 2f9d558d22731532
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:41:55.127398+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-diaconu-agents-authz-info-sharing | Cross-Domain AuthZ Information sharing for Agents | 31pg
  Abstract: Distributed Multi-Agent Systems consist of Agents and MCP Servers
     operating across multiple administrative domains, each with its own
     Identity Providers (IdPs) and Authorization Servers (AS).

     This document discusses the challenges and solution approaches for
     sharing authorization information securely and flexibly across
     domains, including the use of dynamic identity, interoperable claims,
     and verifiable credentials.





  Internet Engineering Task Force                               J. Diaconu
  Internet-Draft                                               M. Yannuzzi
  Intended status: Standards Track                                H. Muyal
  Expires: 10 August 2026                                     F. Brockners
                                                                   N. Kale
                                                                     Cisco
                                                                A. Agarwal
                                                                   Skyfire
                                                                J. Hickman
                                                                  Ory Corp
                                                                    A. Lal
                                                                       AWS
                                                           6 February 2026


             Cross-Domain AuthZ Information sharing for Agents
                 draft-diaconu-agents-authz-info-sharing-00

  Abstract

     Distributed Multi-Agent Systems consist of Agents and MCP Servers
     operating across multiple administrative domains, each with its own
     Identity Providers (IdPs) and Authorization Servers (AS).

     This document discusses the challenges and solution approaches for
     sharing authorization information securely and flexibly across
     domains, including the use of dynamic identity, interoperable claims,
     and verifiable credentials.

  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.






  Diaconu, et al.          Expires 10 August 2026                 [Page 1]


  Internet-Draft          AuthZ Sharing for 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 

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

response_json:
  [
    {
      "title": "Cross-Domain Authorization Information Sharing",
      "description": "A mechanism for securely sharing authorization information between agents and MCP servers operating across multiple administrative domains with different Identity Providers and Authorization Servers.",
      "type": "mechanism"
    },
    {
      "title": "Dynamic Identity for Multi-Agent Systems",
      "description": "An approach for managing flexible identity representation that can adapt across different administrative domains in distributed agent environments.",
      "type": "pattern"
    },
    {
      "title": "Interoperable Claims Framework",
      "description": "A standardized method for representing and exchanging authorization claims that can be understood and processed across different domains and systems.",
      "type": "protocol"
    },
    {
      "title": "Verifiable Credentials for Agent Authorization",
      "description": "Integration of verifiable credentials technology to enable trusted authorization information sharing between agents operating in different administrative contexts.",
      "type": "extension"
    },
    {
      "title": "Distributed Multi-Agent Authorization Architecture",
      "description": "An architectural framework defining how agents, MCP servers, Identity Providers, and Authorization Servers interact across domain boundaries.",
      "type": "architecture"
    }
  ]


draft_name: draft-drake-email-tpm-attestation
prompt_hash: 820bdb24ae3a2c82
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:42:03.040455+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-drake-email-tpm-attestation | Hardware Attestation for Email Sender Verification | 25pg
  Abstract: This document defines a mechanism for email senders to include
     hardware attestation evidence in message headers, enabling receiving
     mail servers to cryptographically verify that an email was composed
     on a machine containing a genuine Trusted Platform Module (TPM) from
     a known manufacturer (Intel, AMD, Infineon, or similar).  The
     verification chain runs from the email header directly to the TPM
     manufacturer's root Certificate Authority, requiring no trust in any
     intermediary identity service.

     As a companion mechanism, this document also defines a privacy-
     preserving alternative using SD-JWT (Selective Disclosure JWT, RFC
     9901) where the sender can prove specific claims about their hardware
     trust level without revealing their hardware identity.

     Together, these mechanisms provide Sybil-resistant email
     authentication: each sender requires a unique physical security chip,
     making large-scale automated spam economically infeasible regardless
     of advances in artificial intelligence.

     While this document specifies these mechanisms for email message
     headers, the attestation formats defined herein - both the CMS
     attestation bundle and the SD-JWT trust proof - are self-contained,
     transport-independent data structures applicable to HTTP headers,
     agent-to-agent messaging, and other Internet protocols.





  Internet Engineering Task Force                                 C. Drake
  Internet-Draft                                                   1id.com
  Intended status: Standards Track                        19 February 2026
  Expires: 23 August 2026


             Hardware Attestation for Email Sender Verification
                    draft-drake-email-tpm-attestation-00

  Abstract

     This document defines a mechanism for email senders to include
     hardware attestation evidence in message headers, enabling receiving
     mail servers to cryptographically verify that an email was composed
     on a machine containing a genuine Trusted Platform Module (TPM) from
     a known manufacturer (Intel, AMD, Infineon, or similar).  The
     verification chain runs from the email header directly to the TPM
     manufacturer's root Certificate Authority, requiring no trust in any
     intermediary identity service.

     As a companion mechanism, this document also defines a privacy-
     preserving alternative using SD-JWT (Selective Disclosure JWT, RFC
     9901) where the sender can prove specific claims about their hardware
     trust level without revealing their hardware identity.

     Together, these mechanisms provide Sybil-resistant email
     authentication: each sender requires a unique physical security chip,
     making large-scale automated spam economically infeasible regardless
     of advances in artificial intelligence.

     While this document specifies these mechanisms for email message
     headers, the attestation formats defined herein - both the CMS
     attestation bundle and the SD-JWT trust proof - are self-contained,
     transport-independent data structures applicable to HTTP headers,
     agent-to-agent messaging, and other Internet 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/.






  Drake                    Expires 23 August 2026                 [Page 1]


  Internet-Draft            TPM Email Attestation            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 (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 caref

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

response_json:
  [
    {
      "title": "TPM Hardware Attestation Headers",
      "description": "Email headers containing cryptographic evidence from Trusted Platform Module (TPM) chips that allow receivers to verify the sender's hardware authenticity. The verification chain runs directly from email header to TPM manufacturer's root Certificate Authority.",
      "type": "mechanism"
    },
    {
      "title": "CMS Attestation Bundle Format",
      "description": "Self-contained data structure using Cryptographic Message Syntax (CMS) to package TPM attestation evidence for transport-independent use across protocols. Provides full hardware identity verification with complete trust chain.",
      "type": "protocol"
    },
    {
      "title": "SD-JWT Privacy-Preserving Trust Proof",
      "description": "Alternative attestation mechanism using Selective Disclosure JWT (RFC 9901) that proves hardware trust level claims without revealing specific hardware identity. Maintains privacy while demonstrating genuine TPM presence.",
      "type": "mechanism"
    },
    {
      "title": "Sybil-Resistant Email Authentication",
      "description": "Authentication approach requiring unique physical security chips per sender, making large-scale automated spam economically infeasible. Each email sender must possess genuine hardware TPM from known manufacturers.",
      "type": "architecture"
    },
    {
      "title": "Transport-Independent Attestation Format",
      "description": "Standardized attestation data structures applicable beyond email to HTTP headers, agent-to-agent messaging, and other Internet protocols. Both CMS and SD-JWT formats designed for cross-protocol compatibility.",
      "type": "extension"
    }
  ]


draft_name: draft-du-ai-agent-communication-6g-aspect
prompt_hash: 263c3fbaf223ccde
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:42:08.623510+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-du-ai-agent-communication-6g-aspect | Use Cases and Requirements of AI Agent Communication from 6G Aspect | 20pg
  Abstract: AI Agent can do some tasks as an assistant to human beings.  During
     the task process, the Agent may need to connect to other Agents with
     different skills relative to the task.  The Agent to Agent
     communication is a new kind of traffic for Internet, and some new
     requirements for networking are proposed.  This document talks about
     the requirements and key issues of global AI agent communication
     towards 6G.  Some 6G related use cases from 3GPP documents are
     introduced.  After that, the related requirements for the AI Agent
     Communication Network (ACN) are proposed, and potential ACN
     frameworks and standardization works for the AI Agent Communication
     are also discussed.





  Network Working Group                                              Z. Du
  Internet-Draft                                              China Mobile
  Intended status: Informational                              30 June 2025
  Expires: 1 January 2026


    Use Cases and Requirements of AI Agent Communication from 6G Aspect
                draft-du-ai-agent-communication-6g-aspect-00

  Abstract

     AI Agent can do some tasks as an assistant to human beings.  During
     the task process, the Agent may need to connect to other Agents with
     different skills relative to the task.  The Agent to Agent
     communication is a new kind of traffic for Internet, and some new
     requirements for networking are proposed.  This document talks about
     the requirements and key issues of global AI agent communication
     towards 6G.  Some 6G related use cases from 3GPP documents are
     introduced.  After that, the related requirements for the AI Agent
     Communication Network (ACN) are proposed, and potential ACN
     frameworks and standardization works for the AI Agent Communication
     are also discussed.

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






  Du                       Expires 1 January 2026                 [Page 1]


  Internet-Draft    6G AI Agent Usecases and Requirements        June 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.  Use C

  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 specialized network architecture designed to handle agent-to-agent communication traffic with specific requirements for AI agent interactions in 6G networks.",
      "type": "architecture"
    },
    {
      "title": "Agent-to-Agent Communication Pattern",
      "description": "A new type of internet traffic pattern where AI agents with different skills connect and communicate to accomplish complex tasks collaboratively.",
      "type": "pattern"
    },
    {
      "title": "Multi-Agent Task Coordination",
      "description": "A mechanism enabling AI agents to discover and connect with other agents possessing complementary skills required for task completion.",
      "type": "mechanism"
    },
    {
      "title": "6G-Enhanced Agent Communication Requirements",
      "description": "Specific networking requirements derived from 3GPP 6G use cases to support low-latency, high-reliability AI agent interactions.",
      "type": "requirement"
    },
    {
      "title": "Global AI Agent Communication Framework",
      "description": "A standardized framework for enabling AI agents to communicate across different network domains and service providers in a 6G context.",
      "type": "architecture"
    }
  ]


draft_name: draft-eckert-anima-acp-free-ani
prompt_hash: f99cf2dbb9d81ef4
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:42:15.021429+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-eckert-anima-acp-free-ani | ACP free "Automation Network Infrastructure" for simple in-network automation (aNI) | 21pg
  Abstract: This document describes how to to build the software infrastructure
     for distributed automation agents using a lightweight variation of
     the "Autonomic Networking Infrastructure" (ANI), by using the
     existing ANI domain keying material (certificates and trust anchors)
     as well as the protocols GRASP and BRSKI protocols, but eliminating
     the expensive to implement "Autonomic Control Plane" (ACP) and adding
     proxying "Autonomic Software Agents" (ASA) instead.

     The resulting infrastructure is called "automation Network
     Infrastructure" and can be implemented solely as application level
     software components on routers, switches or co-located managemenet
     devices, avoiding the need to change any router or switches
     forwarding or control-plane protocols.

     The aNI achieves mosts of the benefits of the ANI but foregoes the
     ability to easily make pre-existing, insecure control-plane protocols
     secure or provide all the same protection against operator or SDN
     controller misconfigurations that the ACP provides.





  ANIMA                                                     T. Eckert, Ed.
  Internet-Draft                                Futurewei Technologies USA
  Intended status: Informational                                    B. Liu
  Expires: 23 April 2026                               Huawei Technologies
                                                           20 October 2025


     ACP free "Automation Network Infrastructure" for simple in-network
                              automation (aNI)
                     draft-eckert-anima-acp-free-ani-01

  Abstract

     This document describes how to to build the software infrastructure
     for distributed automation agents using a lightweight variation of
     the "Autonomic Networking Infrastructure" (ANI), by using the
     existing ANI domain keying material (certificates and trust anchors)
     as well as the protocols GRASP and BRSKI protocols, but eliminating
     the expensive to implement "Autonomic Control Plane" (ACP) and adding
     proxying "Autonomic Software Agents" (ASA) instead.

     The resulting infrastructure is called "automation Network
     Infrastructure" and can be implemented solely as application level
     software components on routers, switches or co-located managemenet
     devices, avoiding the need to change any router or switches
     forwarding or control-plane protocols.

     The aNI achieves mosts of the benefits of the ANI but foregoes the
     ability to easily make pre-existing, insecure control-plane protocols
     secure or provide all the same protection against operator or SDN
     controller misconfigurations that the ACP provides.

  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.



  Eckert & Liu              Expires 23 April 2026                 [Page 1]


  Internet-Draft                ACP free aNI                  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 Re

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

response_json:
  [
    {
      "title": "Automation Network Infrastructure (aNI)",
      "description": "A lightweight variation of ANI that eliminates the Autonomic Control Plane (ACP) while retaining ANI domain certificates, trust anchors, GRASP and BRSKI protocols. Implemented purely as application-level software components without modifying router/switch forwarding or control-plane protocols.",
      "type": "architecture"
    },
    {
      "title": "Proxying Autonomic Software Agents (ASA)",
      "description": "Software agents that replace the ACP functionality by providing proxy services for automation tasks. Enable distributed automation without requiring expensive ACP implementation.",
      "type": "mechanism"
    },
    {
      "title": "ACP-free ANI Domain Authentication",
      "description": "Reuses existing ANI domain keying material including certificates and trust anchors for authentication without requiring the full ACP infrastructure. Maintains security while reducing implementation complexity.",
      "type": "mechanism"
    },
    {
      "title": "Application-only Network Automation",
      "description": "Pattern for implementing network automation infrastructure entirely at the application layer on routers, switches, or co-located management devices. Avoids modifications to underlying network protocols while enabling automation capabilities.",
      "type": "pattern"
    }
  ]


draft_name: draft-eggert-mailmaint-uaautoconf
prompt_hash: ec59b8dec78d73b6
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:42:22.282786+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-eggert-mailmaint-uaautoconf | Automatic Configuration of Email, Calendar, and Contact Server Settings | 41pg
  Abstract: This document specifies an automatic configuration mechanism for
     email, calendar, and contact user agent applications.  Service
     providers publish standardized configuration information that user
     agent applications retrieve and use to simplify server setup
     procedures.





  mailmaint                                                      D. Eggert
  Internet-Draft                                              M. Diephouse
  Intended status: Informational                                 Apple Inc
  Expires: 2 April 2026                                  29 September 2025


  Automatic Configuration of Email, Calendar, and Contact Server Settings
                    draft-eggert-mailmaint-uaautoconf-04

  Abstract

     This document specifies an automatic configuration mechanism for
     email, calendar, and contact user agent applications.  Service
     providers publish standardized configuration information that user
     agent applications retrieve and use to simplify server setup
     procedures.

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




  Eggert & Diephouse        Expires 2 April 2026                  [Page 1]


  Internet-Draft    Auto-Config of Email Server Settings    September 2025


  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.  Document Conventions  . . . . . . . . . . . . . . . . . . . .   3
     3.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     4.  JSON Configuration  . . . . . . . . . . . . . . . . . . . . .   4
       4.1.  Example . . . . . . . . . . . . . . . . . . . . . . . . .   5
       4.2.  Protocols . . . . . . . . . . . . . . . . . . . . . . . .   6
       4.3.  Authentication  . . . . . . . . . . . . . . . . . . . . .   7
       4.4.  Informational . . . . . . . . . . . . . . . . . . . . . .   7
         4.4.1.  Provider Information  . . . . . . . . . . . . . . . .   8
         4.4.2.  Help  . . . . . . . . . . . . .

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

response_json:
  [
    {
      "title": "Automatic Email Configuration Discovery",
      "description": "A mechanism for email, calendar, and contact user agents to automatically discover and retrieve server configuration settings. Service providers publish standardized configuration information that client applications can fetch to simplify setup procedures.",
      "type": "mechanism"
    },
    {
      "title": "JSON-based Configuration Format",
      "description": "A standardized JSON format for publishing email server configuration information including protocols, authentication methods, and connection parameters. This format enables consistent representation of server settings across different service providers.",
      "type": "protocol"
    },
    {
      "title": "Protocol Configuration Schema",
      "description": "Structured specification of different email protocols (SMTP, IMAP, POP3, etc.) within the JSON configuration format. Includes server hostnames, ports, encryption settings, and authentication requirements for each protocol type.",
      "type": "pattern"
    },
    {
      "title": "Authentication Method Specification",
      "description": "Standardized way to describe supported authentication mechanisms within the configuration data. Allows clients to understand which authentication methods are available for different protocols.",
      "type": "mechanism"
    },
    {
      "title": "Provider Information Extension",
      "description": "Additional metadata fields in the configuration format to include service provider details, help resources, and support information. Enhances the configuration with human-readable context and troubleshooting resources.",
      "type": "extension"
    }
  ]


draft_name: draft-fu-cats-flow-lb
prompt_hash: e55a1395417c61f4
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:42:30.690526+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-fu-cats-flow-lb | Flow-Level Load Balancing of Computing-Aware Traffic Steering (CATS) | 9pg
  Abstract: This document specifies a flow-level load balancing mechanism for
     Computing-Aware Traffic Steering (CATS) that reduces control plane
     overhead and improves resource utilization through data plane
     autonomous flow distribution.





  CATS                                                               H. Fu
  Internet-Draft                                                D.H. Huang
  Intended status: Standards Track                                 W. Duan
  Expires: 30 August 2026                                           B. Tan
                                                           ZTE Corporation
                                                          26 February 2026


    Flow-Level Load Balancing of Computing-Aware Traffic Steering (CATS)
                          draft-fu-cats-flow-lb-03

  Abstract

     This document specifies a flow-level load balancing mechanism for
     Computing-Aware Traffic Steering (CATS) that reduces control plane
     overhead and improves resource utilization through data plane
     autonomous flow distribution.

  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.

     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.



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


  Internet-Draft  Flow-Level Load Balancing of Computing-A   February 2026


  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   2
     3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   2
     4.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   3
     5.  Architectural Model . . . . . . . . . . . . . . . . . . . . .   3
     6.  Control plane Operation . . . . . . . . . . . . . . . . . . .   5
     7.  Data Plane Operation  . . . . . . . . . . . . . . . . . . . .   6
     8.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
     9.  Acknowledgements  

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

response_json:
  [
    {
      "title": "Flow-Level Load Balancing for CATS",
      "description": "A mechanism that distributes traffic flows across computing resources in CATS networks at the granularity of individual flows rather than packets. This approach maintains flow coherence while enabling better load distribution across available compute instances.",
      "type": "mechanism"
    },
    {
      "title": "Data Plane Autonomous Flow Distribution",
      "description": "A data plane mechanism that allows forwarding elements to make independent flow steering decisions without per-flow control plane involvement. This reduces signaling overhead and enables faster response to load changes.",
      "type": "mechanism"
    },
    {
      "title": "Control Plane Overhead Reduction",
      "description": "An approach that minimizes the frequency and volume of control plane interactions required for load balancing decisions. The mechanism delegates flow-level decisions to the data plane to reduce centralized control processing.",
      "type": "pattern"
    },
    {
      "title": "CATS Flow Distribution Architecture",
      "description": "An architectural model that separates control plane policy distribution from data plane flow steering decisions. The architecture enables autonomous data plane operation while maintaining centralized policy control.",
      "type": "architecture"
    },
    {
      "title": "Compute-Aware Flow Steering",
      "description": "A steering mechanism that considers both network path characteristics and computing resource availability when making flow distribution decisions. This enables optimal placement of flows based on compute capacity and network conditions.",
      "type": "mechanism"
    }
  ]


draft_name: draft-fu-nmop-agent-communication-framework
prompt_hash: c429aed96dfd4798
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:42:37.139977+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-fu-nmop-agent-communication-framework | Agent Communication Framework for Network AIOps | 13pg
  Abstract: As the development of large model and agent technology, it is a trend
     for multi-agent collaboration to solve complex problems.  This
     document proposes an Agent Communication Framework, a multi-agent
     communication and collaboration framework that facilitates the
     coordination of heterogeneous multi-agents and supports intelligent
     network operations and maintenance (AIOps).  Its architecture
     includes an AI gateway and an Agent Name Service, along with
     capabilities such as monitoring and tracking, as well as security
     protection.  Agent Communication Framework provides a comprehensive
     solution for multi-agent communication and collaboration, laying the
     foundation for future interactive, scalable, secure, and controllable
     multi-agent network intelligent operations and maintenance.





  nmop                                                               Y. Fu
  Internet-Draft                                                    Q. Sun
  Intended status: Standards Track                                 X. Song
  Expires: 29 July 2026                                             C. Xie
                                                             China Telecom
                                                           25 January 2026


              Agent Communication Framework for Network AIOps
               draft-fu-nmop-agent-communication-framework-00

  Abstract

     As the development of large model and agent technology, it is a trend
     for multi-agent collaboration to solve complex problems.  This
     document proposes an Agent Communication Framework, a multi-agent
     communication and collaboration framework that facilitates the
     coordination of heterogeneous multi-agents and supports intelligent
     network operations and maintenance (AIOps).  Its architecture
     includes an AI gateway and an Agent Name Service, along with
     capabilities such as monitoring and tracking, as well as security
     protection.  Agent Communication Framework provides a comprehensive
     solution for multi-agent communication and collaboration, laying the
     foundation for future interactive, scalable, secure, and controllable
     multi-agent network intelligent operations and maintenance.

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

  Copyright Notice

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




  Fu, et al.                Expires 29 July 2026                  [Page 1]


  Internet-Draft        Agent Communication Framework         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": "AI Gateway",
      "description": "Central component that facilitates communication and coordination between heterogeneous multi-agents in network AIOps environments. Acts as an intermediary for agent-to-agent interactions and protocol translation.",
      "type": "architecture"
    },
    {
      "title": "Agent Name Service",
      "description": "Directory service that enables agent discovery and addressing within the multi-agent framework. Provides naming and location services for distributed AI agents.",
      "type": "mechanism"
    },
    {
      "title": "Multi-Agent Communication Protocol",
      "description": "Communication protocol designed specifically for heterogeneous AI agents to collaborate on network operations and maintenance tasks. Enables standardized message exchange between different types of agents.",
      "type": "protocol"
    },
    {
      "title": "Agent Monitoring and Tracking",
      "description": "Capability to monitor agent behavior, performance, and interactions within the framework. Provides visibility into multi-agent collaboration activities for network AIOps.",
      "type": "mechanism"
    },
    {
      "title": "Multi-Agent Security Protection",
      "description": "Security mechanisms designed to protect communications and operations within the multi-agent framework. Ensures secure collaboration between AI agents in network operations contexts.",
      "type": "mechanism"
    }
  ]


draft_name: draft-gaikwad-aps-profile
prompt_hash: e6d06f638bde73ee
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:42:45.945820+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-gaikwad-aps-profile | Agent Persistent State Profile | 22pg
  Abstract: Autonomous agents increasingly maintain durable persistent state
     containing user preferences, embedding vectors, safety logs,
     intermediate reasoning steps, and audit traces.  Today, agent
     frameworks treat storage as a generic file system, while storage
     administrators treat agents as stateless virtual machines.  This
     "layer mismatch" leads to fragility, poor performance, and privacy
     risks.

     The Agent Persistent State (APS) Profile defines an experimental,
     vendor-neutral storage service class for durable agent state.  APS
     emphasizes *compliance*: ensuring that memory associated with a
     specific user or agent identity can be retained, audited, and
     cryptographically erased.  APS also addresses high-frequency small I/
     O, vector index workloads, crash consistency, and Kubernetes/CSI
     [CSI] integration.

     APS introduces a Usage Class ("AgentPersistentState"), a versioned
     PersistentStateLineOfService schema, guidance for container
     orchestration systems, non-normative bindings for Swordfish
     [Swordfish] and Redfish [Redfish], and considerations for multi-
     tenancy.  APS is intended as an Experimental RFC to gather
     implementation feedback prior to any standards-track work.





  Network Working Group                                         M. Gaikwad
  Internet-Draft                                           1 December 2025
  Intended status: Experimental                                           
  Expires: 4 June 2026


                       Agent Persistent State Profile
                        draft-gaikwad-aps-profile-00

  Abstract

     Autonomous agents increasingly maintain durable persistent state
     containing user preferences, embedding vectors, safety logs,
     intermediate reasoning steps, and audit traces.  Today, agent
     frameworks treat storage as a generic file system, while storage
     administrators treat agents as stateless virtual machines.  This
     "layer mismatch" leads to fragility, poor performance, and privacy
     risks.

     The Agent Persistent State (APS) Profile defines an experimental,
     vendor-neutral storage service class for durable agent state.  APS
     emphasizes *compliance*: ensuring that memory associated with a
     specific user or agent identity can be retained, audited, and
     cryptographically erased.  APS also addresses high-frequency small I/
     O, vector index workloads, crash consistency, and Kubernetes/CSI
     [CSI] integration.

     APS introduces a Usage Class ("AgentPersistentState"), a versioned
     PersistentStateLineOfService schema, guidance for container
     orchestration systems, non-normative bindings for Swordfish
     [Swordfish] and Redfish [Redfish], and considerations for multi-
     tenancy.  APS is intended as an Experimental RFC to gather
     implementation feedback prior to any standards-track 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."



  Gaikwad                    Expires 4 June 2026                  [Page 1]


  Internet-Draft       Agent Persistent State Profile        December 2025


     This Internet-Draft will expire on 4 June 2026.

  Copyright Notice

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

     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": "AgentPersistentState Usage Class",
      "description": "A new storage usage class specifically designed for autonomous agent workloads. Distinguishes agent storage requirements from generic file system or VM storage patterns.",
      "type": "mechanism"
    },
    {
      "title": "PersistentStateLineOfService Schema",
      "description": "A versioned schema that defines service level requirements for agent persistent state storage. Includes specifications for compliance, performance, and data lifecycle management.",
      "type": "protocol"
    },
    {
      "title": "Cryptographic Erasure Compliance",
      "description": "Mechanism to ensure agent memory associated with specific user or agent identities can be cryptographically erased for privacy compliance. Addresses regulatory requirements for data deletion.",
      "type": "mechanism"
    },
    {
      "title": "Vector Index Workload Optimization",
      "description": "Storage optimizations specifically for high-frequency small I/O operations and vector embedding storage patterns common in agent systems. Addresses performance requirements for AI workloads.",
      "type": "pattern"
    },
    {
      "title": "Kubernetes CSI Integration",
      "description": "Container orchestration guidance and bindings for integrating APS with Kubernetes Container Storage Interface. Enables seamless deployment of agent storage in containerized environments.",
      "type": "extension"
    },
    {
      "title": "Swordfish/Redfish Bindings",
      "description": "Non-normative protocol bindings for integrating APS with existing storage management standards Swordfish and Redfish. Provides interoperability with enterprise storage infrastructure.",
      "type": "extension"
    }
  ]


draft_name: draft-gaikwad-llm-benchmarking-methodology
prompt_hash: f86e56278707c0ce
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:42:52.776267+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-gaikwad-llm-benchmarking-methodology | Benchmarking Methodology for Large Language Model Serving | 48pg
  Abstract: This document defines benchmarking methodologies for Large Language
     Model (LLM) inference serving systems.  It provides test procedures,
     setup parameters, measurement specifications, and reporting formats
     for evaluating latency, throughput, scheduling, and resource
     management characteristics.  This document is a companion to
     "Benchmarking Terminology for Large Language Model Serving" and
     SHOULD be consulted alongside that terminology document.





  Network Working Group                                         M. Gaikwad
  Internet-Draft                                    Independent Researcher
  Intended status: Informational                              January 2026
  Expires: 24 July 2026


         Benchmarking Methodology for Large Language Model Serving
               draft-gaikwad-llm-benchmarking-methodology-00

  Abstract

     This document defines benchmarking methodologies for Large Language
     Model (LLM) inference serving systems.  It provides test procedures,
     setup parameters, measurement specifications, and reporting formats
     for evaluating latency, throughput, scheduling, and resource
     management characteristics.  This document is a companion to
     "Benchmarking Terminology for Large Language Model Serving" and
     SHOULD be consulted alongside that terminology document.

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

  Copyright Notice

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











  Gaikwad                   Expires 24 July 2026                  [Page 1]


  Internet-Draft        LLM Benchmarking Methodology          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  . . . . . . . . . . . . . . . . . . . . . . . .   5
     2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   6
     3.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . .   6
     4.  Test Setup  . . . . . . . . . . . . . . . . . . . . . . . . .   7
       4.1.  System Under Test Configurations  . . . . . . . . . . . .   7
         4.1.1.  Model Engine Configuration  . . . . . . . . . . . . .   7
         4.1.2.  Application Gateway Configuration . . . . . . . . . .   8
         4.1.3.  Compound System Configuration . . . . .

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

response_json:
  [
    {
      "title": "Time to First Token (TTFT) Measurement",
      "description": "A specific latency metric measuring the time from request submission to the first token being generated by the LLM. This provides insight into model initialization and prompt processing overhead.",
      "type": "mechanism"
    },
    {
      "title": "Inter-Token Latency (ITL) Measurement",
      "description": "A metric measuring the time between consecutive token generations during streaming responses. This captures the model's sustained generation performance during inference.",
      "type": "mechanism"
    },
    {
      "title": "Tripartite Test Configuration Architecture",
      "description": "A standardized test setup dividing the system into three components: Model Engine, Application Gateway, and Compound System configurations. This enables systematic evaluation of different deployment architectures.",
      "type": "architecture"
    },
    {
      "title": "Request Rate Ramping Pattern",
      "description": "A systematic methodology for gradually increasing request rates to identify throughput limits and performance degradation points. This provides standardized load testing procedures for LLM serving systems.",
      "type": "pattern"
    },
    {
      "title": "Multi-dimensional Performance Reporting Format",
      "description": "A standardized reporting structure that captures latency, throughput, scheduling, and resource management metrics simultaneously. This enables comprehensive comparison of LLM serving system performance.",
      "type": "protocol"
    }
  ]


draft_name: draft-gaikwad-llm-benchmarking-profiles
prompt_hash: c75c919e993b1902
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:43:00.296967+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-gaikwad-llm-benchmarking-profiles | Performance Benchmarking Profiles for Large Language Model Serving Systems | 53pg
  Abstract: This document defines performance benchmarking profiles for Large
     Language Model (LLM) serving systems.  Profiles bind the terminology
     defined in draft-gaikwad-llm-benchmarking-terminology and the
     procedures described in draft-gaikwad-llm-benchmarking-methodology to
     concrete architectural roles and workload patterns.  Each profile
     clarifies the System Under Test (SUT) boundary, measurement points,
     and interpretation constraints required for reproducible and
     comparable benchmarking.

     This document specifies profiles only.  It does not define new
     metrics, benchmark workloads, or acceptance thresholds.





  Network Working Group                                         M. Gaikwad
  Internet-Draft                                    Independent Researcher
  Intended status: Informational                              January 2026
  Expires: 24 July 2026


     Performance Benchmarking Profiles for Large Language Model Serving
                                  Systems
                 draft-gaikwad-llm-benchmarking-profiles-00

  Abstract

     This document defines performance benchmarking profiles for Large
     Language Model (LLM) serving systems.  Profiles bind the terminology
     defined in draft-gaikwad-llm-benchmarking-terminology and the
     procedures described in draft-gaikwad-llm-benchmarking-methodology to
     concrete architectural roles and workload patterns.  Each profile
     clarifies the System Under Test (SUT) boundary, measurement points,
     and interpretation constraints required for reproducible and
     comparable benchmarking.

     This document specifies profiles only.  It does not define new
     metrics, benchmark workloads, or acceptance thresholds.

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

  Copyright Notice

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






  Gaikwad                   Expires 24 July 2026                  [Page 1]


  Internet-Draft          LLM Benchmarking Profiles           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  . . . . . . . . . . . . . . . . . . . . . . . .   4
       1.1.  Terminology Alignment . . . . . . . . . . . . . . . . . .   5
     2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   6
     3.  Profile Taxonomy  . . . . . . . . . . . . . . . . . . . . . .   6
       3.1.  Infrastructure Profiles . . . . . . . . . . . . . . . .

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

response_json:
  [
    {
      "title": "LLM Benchmarking Profiles",
      "description": "Standardized benchmarking profiles that bind terminology and procedures to concrete architectural roles and workload patterns for LLM serving systems. Each profile clarifies System Under Test (SUT) boundaries, measurement points, and interpretation constraints.",
      "type": "architecture"
    },
    {
      "title": "System Under Test (SUT) Boundary Definition",
      "description": "Mechanism for clearly defining the boundaries of what components are included in performance testing of LLM serving systems. Provides standardized approach to determine which system elements are measured versus excluded.",
      "type": "mechanism"
    },
    {
      "title": "Profile Taxonomy with Infrastructure Profiles",
      "description": "Hierarchical classification system for LLM benchmarking profiles, including specific infrastructure-focused profile categories. Organizes different types of benchmarking scenarios into structured categories.",
      "type": "pattern"
    },
    {
      "title": "Measurement Points Specification",
      "description": "Standardized definition of where performance measurements should be taken within LLM serving system architectures. Ensures consistent and comparable measurement locations across different implementations.",
      "type": "requirement"
    },
    {
      "title": "Interpretation Constraints Framework",
      "description": "Set of constraints and guidelines for properly interpreting benchmark results within specific profiles. Provides context-specific rules for understanding performance measurements.",
      "type": "mechanism"
    }
  ]


draft_name: draft-gaikwad-llm-benchmarking-terminology
prompt_hash: 307501dd14906271
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:43:07.045893+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-gaikwad-llm-benchmarking-terminology | Benchmarking Terminology for Large Language Model Serving | 54pg
  Abstract: This document defines terminology for benchmarking the performance of
     Large Language Model (LLM) inference serving systems.  It establishes
     a shared vocabulary for latency, throughput, resource utilization,
     and quality metrics applicable to inference engines, application
     gateways, and compound agentic systems.  This document defines
     terminology only and does not prescribe benchmark methodologies or
     acceptance thresholds.





  Network Working Group                                         M. Gaikwad
  Internet-Draft                                    Independent Researcher
  Intended status: Informational                              January 2026
  Expires: 24 July 2026


         Benchmarking Terminology for Large Language Model Serving
               draft-gaikwad-llm-benchmarking-terminology-00

  Abstract

     This document defines terminology for benchmarking the performance of
     Large Language Model (LLM) inference serving systems.  It establishes
     a shared vocabulary for latency, throughput, resource utilization,
     and quality metrics applicable to inference engines, application
     gateways, and compound agentic systems.  This document defines
     terminology only and does not prescribe benchmark methodologies or
     acceptance thresholds.

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





  Gaikwad                   Expires 24 July 2026                  [Page 1]


  Internet-Draft        LLM Benchmarking Terminology          January 2026


  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.  Scope and System Under Test Boundary  . . . . . . . . . . . .   5
     3.  Requirements Language . . . . . . . . . . . . . . . . . . . .   6
     4.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   6
       4.1.  Request and Response Timing Metrics . . . . . . . . . . .   6
         4.1.1.  End-to-End Latency  . . . . . . . . . . . . . . . . .   6
         4.1.2.  Time to First Token . . . . . . . . . . . . . . . . .   7
         4.1.3.  Inter-Token Latency . . . . . . . . . . . . . . . . .   7
         4.1.4.  Time Between Tokens . . . . . . . . . . . . . . . . .   8
         4.1.5.  Time per Output Token . . . . . . . . . . . . . . . .   9
         4.1.6.  Normalized Latency  . . . . . . . . . . . . . . . . .   9
       4.2.  Phase-

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

response_json:
  [
    {
      "title": "Time to First Token (TTFT)",
      "description": "Measures the elapsed time from request submission to the delivery of the first output token in streaming LLM responses. This metric is critical for user experience in interactive applications where initial response latency matters.",
      "type": "mechanism"
    },
    {
      "title": "Inter-Token Latency",
      "description": "Defines the time interval between consecutive token deliveries in streaming LLM outputs. This metric helps assess the smoothness and consistency of token generation during inference.",
      "type": "mechanism"
    },
    {
      "title": "Time per Output Token",
      "description": "Calculates the average time required to generate each output token by dividing total generation time by the number of output tokens. This provides a normalized measure of generation efficiency.",
      "type": "mechanism"
    },
    {
      "title": "Normalized Latency",
      "description": "Adjusts latency measurements to account for varying input and output lengths, enabling fair comparison across different request patterns. This allows benchmarking of LLM systems with different workload characteristics.",
      "type": "mechanism"
    },
    {
      "title": "System Under Test Boundary Definition",
      "description": "Establishes clear demarcation points for measuring LLM serving systems, including inference engines, application gateways, and compound agentic systems. This ensures consistent measurement scope across different benchmarking scenarios.",
      "type": "architecture"
    }
  ]


draft_name: draft-gaikwad-south-authorization
prompt_hash: 63a9a0455189adbe
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:43:14.639538+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-gaikwad-south-authorization | SOUTH: Stochastic Authorization for Agent and Service Requests | 44pg
  Abstract: SOUTH defines an authorization protocol for evaluating requests
     issued by users, services, or autonomous agents.  SOUTH allows a
     server to return a deterministic decision or an allow decision that
     is issued with a probability determined by local policy.  This
     enables servers to incorporate uncertainty, contextual information,
     and load conditions into authorization decisions.

     SOUTH is transport independent and can be composed with existing
     authentication mechanisms such as OAuth, OpenID Connect, mutual TLS,
     or DPoP.  This document describes the request and response objects,
     decision semantics, and an HTTP binding for interoperable deployment.





  Network Working Group                                         M. Gaikwad
  Internet-Draft                                    Independent Researcher
  Intended status: Experimental                           28 November 2025
  Expires: 1 June 2026


       SOUTH: Stochastic Authorization for Agent and Service Requests
                    draft-gaikwad-south-authorization-00

  Abstract

     SOUTH defines an authorization protocol for evaluating requests
     issued by users, services, or autonomous agents.  SOUTH allows a
     server to return a deterministic decision or an allow decision that
     is issued with a probability determined by local policy.  This
     enables servers to incorporate uncertainty, contextual information,
     and load conditions into authorization decisions.

     SOUTH is transport independent and can be composed with existing
     authentication mechanisms such as OAuth, OpenID Connect, mutual TLS,
     or DPoP.  This document describes the request and response objects,
     decision semantics, and an HTTP binding for interoperable deployment.

  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.







  Gaikwad                    Expires 1 June 2026                  [Page 1]


  Internet-Draft                    SOUTH                    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.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     4.  Design Goals and Non-Goals  . . . . . . . . . . . . . . . . .   6
       4.1.  Design Goals  . . . . . . . . . . . . . . . . . . . . . .   7
       4.2.  Non-Goals . . . . . . . . . . . . . . . . . . . . . . . .   7
     5.  Architecture  . . . . . . . . . . . . . . . . . . . . . . . .   8
       5.1.  Roles . . . . . . . . . . . . . . . . . . . . . . . . . .   8
   

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

response_json:
  [
    {
      "title": "Stochastic Authorization Protocol",
      "description": "SOUTH defines an authorization protocol that can return probabilistic 'allow' decisions based on local policy, enabling uncertainty and contextual information to be incorporated into authorization decisions. This differs from traditional binary allow/deny authorization systems.",
      "type": "protocol"
    },
    {
      "title": "Probabilistic Decision Response",
      "description": "Authorization servers can return allow decisions with an associated probability value determined by local policy factors like load conditions, uncertainty, and context. The client must then interpret and act on these probabilistic responses.",
      "type": "mechanism"
    },
    {
      "title": "Transport-Independent Design",
      "description": "SOUTH is designed to work independently of transport layer and can be composed with existing authentication mechanisms like OAuth, OpenID Connect, mutual TLS, or DPoP. This enables flexible deployment across different network architectures.",
      "type": "architecture"
    },
    {
      "title": "HTTP Protocol Binding",
      "description": "The specification defines specific HTTP binding mechanisms for SOUTH requests and responses to enable interoperable deployment. This includes standardized request/response object formats for HTTP transport.",
      "type": "protocol"
    },
    {
      "title": "Multi-Agent Authorization Support",
      "description": "SOUTH specifically addresses authorization requests from users, services, and autonomous agents within the same protocol framework. This unified approach handles different types of requesting entities with consistent semantics.",
      "type": "requirement"
    }
  ]


draft_name: draft-gaikwad-woa
prompt_hash: 3f11f6ad078825e0
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:43:21.583618+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-gaikwad-woa | The Web of Agents (WoA) | 19pg
  Abstract: This document defines the Web of Agents (WoA), a minimal JSON based
     description format and invocation convention that allows HTTP hosts
     to advertise AI agents and for clients to invoke those agents in a
     uniform way.  A WoA document is typically served from a well known
     location on an HTTP origin and uses JSON Schema to describe agent
     inputs and outputs.  WoA does not define a discovery protocol itself
     but is designed to be used as a host level primitive by higher level
     discovery systems.





  Independent Submission                                        M. Gaikwad
  Internet-Draft                                           1 December 2025
  Intended status: Experimental                                           
  Expires: 4 June 2026


                          The Web of Agents (WoA)
                            draft-gaikwad-woa-00

  Abstract

     This document defines the Web of Agents (WoA), a minimal JSON based
     description format and invocation convention that allows HTTP hosts
     to advertise AI agents and for clients to invoke those agents in a
     uniform way.  A WoA document is typically served from a well known
     location on an HTTP origin and uses JSON Schema to describe agent
     inputs and outputs.  WoA does not define a discovery protocol itself
     but is designed to be used as a host level primitive by higher level
     discovery systems.

  Status of This Memo

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

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

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

     This Internet-Draft will expire on 4 June 2026.

  Copyright Notice

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

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




  Gaikwad                    Expires 4 June 2026                  [Page 1]


  Internet-Draft                     WoA                     December 2025


  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Conventions and Terminology . . . . . . . . . . . . . . . . .   3
       2.1.  Terms . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.  Architecture  . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.  WoA Document Schema . . . . . . . . . . . . . . . . . . . . .   4
       4.1.  Agent Objects . . . . . . . . . . . . . . . . . . . . . .   5
       4.2.  JSON Schema Usage for Inputs and Outputs  . . . . . . . .   6
       4.3.  Transport Configurations  . . . . . . . . . . . . . . . .   6
         4.3.1.  REST Transport  . . . . . . . . . . . . . . . . . . .   7
         4.3.2.  MCP Transport . . . . . . . . . . . . . . . . . . . .   7
         4.3.3.  Private Transports  . . . . . . . .

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

response_json:
  [
    {
      "title": "WoA Document Format",
      "description": "A minimal JSON-based description format that allows HTTP hosts to advertise AI agents with standardized metadata. Uses JSON Schema to describe agent inputs and outputs in a machine-readable way.",
      "type": "protocol"
    },
    {
      "title": "Well-Known Location Pattern",
      "description": "A convention for serving WoA documents from a standardized well-known location on HTTP origins. Enables predictable discovery of agent capabilities at the host level.",
      "type": "pattern"
    },
    {
      "title": "Agent Object Schema",
      "description": "Structured JSON objects that define individual agents within a WoA document, including their capabilities and invocation details. Provides uniform representation of agent metadata across different implementations.",
      "type": "mechanism"
    },
    {
      "title": "Transport Configuration System",
      "description": "Multiple transport mechanisms including REST and MCP (Model Context Protocol) transports for agent invocation. Allows flexibility in how clients communicate with advertised agents.",
      "type": "architecture"
    },
    {
      "title": "Host-Level Discovery Primitive",
      "description": "A foundational building block designed to be used by higher-level discovery systems rather than defining discovery itself. Separates agent advertisement from discovery mechanisms.",
      "type": "pattern"
    }
  ]


draft_name: draft-gont-dhcwg-dhcpv6-iids
prompt_hash: d72413a4ddd49100
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:43:29.155243+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-gont-dhcwg-dhcpv6-iids | A Method for Generating Semantically Opaque IPv6 Interface Identifiers (IIDs) with Dynamic Host Configuration Protocol for IPv6 (DHCPv6) | 11pg
  Abstract: This document describes a method for selecting IPv6 Interface
     Identifiers that can be employed by Dynamic Host Configuration
     Protocol for IPv6 (DHCPv6) servers when leasing non-temporary IPv6
     addresses to DHCPv6 clients.  This method is a DHCPv6 server-side
     algorithm that does not require any updates to the existing DHCPv6
     specifications.  The aforementioned method results in stable
     addresses within each subnet, even in the presence of multiple DHCPv6
     servers or DHCPv6 server reinstallments.  It is a DHCPv6 variant of
     the method specified in RFC 7217 for IPv6 Stateless Address
     Autoconfiguration (SLAAC).





  Dynamic Host Configuration (dhc)                                 F. Gont
  Internet-Draft                                              SI6 Networks
  Obsoletes: 7943 (if approved)                           10 February 2025
  Intended status: Standards Track                                        
  Expires: 14 August 2025


   A Method for Generating Semantically Opaque IPv6 Interface Identifiers
     (IIDs) with Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
                      draft-gont-dhcwg-dhcpv6-iids-00

  Abstract

     This document describes a method for selecting IPv6 Interface
     Identifiers that can be employed by Dynamic Host Configuration
     Protocol for IPv6 (DHCPv6) servers when leasing non-temporary IPv6
     addresses to DHCPv6 clients.  This method is a DHCPv6 server-side
     algorithm that does not require any updates to the existing DHCPv6
     specifications.  The aforementioned method results in stable
     addresses within each subnet, even in the presence of multiple DHCPv6
     servers or DHCPv6 server reinstallments.  It is a DHCPv6 variant of
     the method specified in RFC 7217 for IPv6 Stateless Address
     Autoconfiguration (SLAAC).

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

  Copyright Notice

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






  Gont                     Expires 14 August 2025                 [Page 1]


  Internet-Draft    Generation of Opaque IIDs with DHCPv6    February 2025


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

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.  Applicability and Design Goals  . . . . . . . . . . . . . . .   3
     4.  Method Specification  . .

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

response_json:
  [
    {
      "title": "Semantically Opaque IID Generation Algorithm",
      "description": "A DHCPv6 server-side algorithm for generating IPv6 Interface Identifiers that are semantically opaque, preventing information leakage while maintaining stability. This is a DHCPv6 adaptation of RFC 7217's method originally designed for SLAAC.",
      "type": "mechanism"
    },
    {
      "title": "Server-Side IID Selection Method",
      "description": "A method that operates entirely on the DHCPv6 server without requiring any modifications to existing DHCPv6 client implementations or protocol specifications. The server selects appropriate Interface Identifiers when leasing non-temporary IPv6 addresses.",
      "type": "mechanism"
    },
    {
      "title": "Multi-Server Stability Guarantee",
      "description": "An algorithm design that ensures stable IPv6 addresses within each subnet even when multiple DHCPv6 servers are present or when DHCPv6 servers are reinstalled. This maintains address consistency across different server configurations.",
      "type": "requirement"
    },
    {
      "title": "DHCPv6 Variant of RFC 7217",
      "description": "An adaptation of the RFC 7217 stable address generation method from IPv6 Stateless Address Autoconfiguration (SLAAC) to work within the DHCPv6 framework. This extends the opaque address generation concept to stateful address assignment.",
      "type": "extension"
    }
  ]


draft_name: draft-goswami-agentic-jwt
prompt_hash: 740d906758773016
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:43:38.604669+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-goswami-agentic-jwt | Secure Intent Protocol: JWT Compatible Agentic Identity and Workflow Management | 71pg
  Abstract: This document specifies Agentic JSON Web Token (Agentic JWT), as an
     extension to OAuth 2.0 that addresses authorization challenges unique
     to autonomous agentic AI systems.  This protocol solves the problem
     of Zero-Trust drift due to non-deterministic Agentic AI clients
     causing separation between user's (resource owner's) intent and
     client application's actions.

     Traditional OAuth 2.0 assumes that client applications faithfully
     represent user intent when requesting authorization.  This assumption
     breaks down when autonomous AI agents dynamically generate workflows,
     create sub-agents, and make authorization decisions without
     continuous human oversight.  We term this the "intent-execution
     separation problem."

     Agentic JWT introduces three mechanisms to address this problem: (1)
     cryptographic agent identity through agent checksums (based on
     agent's system prompts, tools and configurations), (2) workflow-aware
     token binding that links user intent to agent execution, and (3) a
     new OAuth 2.0 grant type (agent_checksum) for secure token issuance,
     (4) a flavor of PoP (Proof-of-Possession) at the level of an agentic
     identity to prevent token replays by other agents in the same multi-
     agent process.

     This specification enables Zero-Trust security principles in multi-
     agent systems while maintaining backward compatibility with existing
     OAuth 2.0 infrastructure.  The security analysis and experimental
     validation are described in the companion research paper.





  Internet Engineering Task Force                          A. Goswami, Ed.
  Internet-Draft                                          31 December 2025
  Intended status: Informational                                          
  Expires: 4 July 2026


    Secure Intent Protocol: JWT Compatible Agentic Identity and Workflow
                                 Management
                        draft-goswami-agentic-jwt-00

  Abstract

     This document specifies Agentic JSON Web Token (Agentic JWT), as an
     extension to OAuth 2.0 that addresses authorization challenges unique
     to autonomous agentic AI systems.  This protocol solves the problem
     of Zero-Trust drift due to non-deterministic Agentic AI clients
     causing separation between user's (resource owner's) intent and
     client application's actions.

     Traditional OAuth 2.0 assumes that client applications faithfully
     represent user intent when requesting authorization.  This assumption
     breaks down when autonomous AI agents dynamically generate workflows,
     create sub-agents, and make authorization decisions without
     continuous human oversight.  We term this the "intent-execution
     separation problem."

     Agentic JWT introduces three mechanisms to address this problem: (1)
     cryptographic agent identity through agent checksums (based on
     agent's system prompts, tools and configurations), (2) workflow-aware
     token binding that links user intent to agent execution, and (3) a
     new OAuth 2.0 grant type (agent_checksum) for secure token issuance,
     (4) a flavor of PoP (Proof-of-Possession) at the level of an agentic
     identity to prevent token replays by other agents in the same multi-
     agent process.

     This specification enables Zero-Trust security principles in multi-
     agent systems while maintaining backward compatibility with existing
     OAuth 2.0 infrastructure.  The security analysis and experimental
     validation are described in the companion research paper.

  Status of This Memo

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







  Goswami                    Expires 4 July 2026                  [Page 1]


  Internet-Draft            Agentic JWT Protocol             December 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 4 July 2026.

  Copyright Notice

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

     This document is subject to B

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

response_json:
  [
    {
      "title": "Agent Checksum Identity",
      "description": "Cryptographic identity mechanism that generates checksums based on an agent's system prompts, tools, and configurations. This provides deterministic identity verification for non-deterministic AI agents.",
      "type": "mechanism"
    },
    {
      "title": "Workflow-Aware Token Binding",
      "description": "Token binding mechanism that cryptographically links user intent to specific agent execution workflows. This prevents agents from acting beyond their authorized scope.",
      "type": "mechanism"
    },
    {
      "title": "Agent Checksum Grant Type",
      "description": "New OAuth 2.0 grant type specifically designed for secure token issuance to autonomous AI agents. Extends OAuth 2.0 to handle agentic identity verification.",
      "type": "extension"
    },
    {
      "title": "Agentic Proof-of-Possession",
      "description": "Enhanced PoP mechanism operating at the agentic identity level to prevent token replay attacks between different agents within the same multi-agent system. Provides agent-specific token binding.",
      "type": "mechanism"
    },
    {
      "title": "Intent-Execution Separation Problem",
      "description": "Identified security problem where autonomous AI agents can act beyond user intent due to dynamic workflow generation and lack of continuous human oversight. Defines the core challenge addressed by the protocol.",
      "type": "requirement"
    }
  ]


draft_name: draft-gupta-httpapi-events-query
prompt_hash: 7d09a16f1319e825
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:43:43.204437+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-gupta-httpapi-events-query | HTTP Events Query | 29pg
  Abstract: Events Query is a minimal protocol built on top of HTTP that allows
     user agents to receive event notifications directly from any resource
     of interest.  The Events Query Protocol (EQP) is predicated on the
     idea that the most intuitive source for event notifications is the
     resource itself.





  Building Blocks for HTTP APIs                                   R. Gupta
  Internet-Draft                                           17 October 2025
  Intended status: Standards Track                                        
  Expires: 20 April 2026


                             HTTP Events Query
                    draft-gupta-httpapi-events-query-01

  Abstract

     Events Query is a minimal protocol built on top of HTTP that allows
     user agents to receive event notifications directly from any resource
     of interest.  The Events Query Protocol (EQP) is predicated on the
     idea that the most intuitive source for event notifications is the
     resource itself.

  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://CxRes.github.io/events-query/draft-gupta-httpapi-events-
     query.html.  Status information for this document may be found at
     https://datatracker.ietf.org/doc/draft-gupta-httpapi-events-query/.

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

     Source for this draft and an issue tracker can be found at
     https://github.com/CxRes/events-query.

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



  Gupta                     Expires 20 April 2026                 [Page 1]


  Internet-Draft              HTTP Events Query               October 2025


     This Internet-Draft will expire on 20 April 2026.

  Copyright Notice

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

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

  Table of Contents

     1.  Introduction  . . . . . . . 

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

response_json:
  [
    {
      "title": "Events Query Protocol (EQP)",
      "description": "A minimal protocol built on top of HTTP that allows user agents to receive event notifications directly from any resource. Based on the principle that the most intuitive source for event notifications is the resource itself.",
      "type": "protocol"
    },
    {
      "title": "Resource-centric Event Notification",
      "description": "An architectural pattern where event notifications are sourced directly from the resource of interest rather than through intermediary event systems. Enables direct querying of resources for their associated events.",
      "type": "architecture"
    },
    {
      "title": "HTTP-based Event Querying",
      "description": "A mechanism that leverages existing HTTP infrastructure to enable event notification capabilities. Allows standard HTTP clients to query and receive events from web resources.",
      "type": "mechanism"
    }
  ]


draft_name: draft-guy-bary-stamp-protocol
prompt_hash: 399500096b09e87c
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:43:51.488247+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-guy-bary-stamp-protocol | Secure Task-bound Agent Message Proof (STAMP) Protocol | 9pg
  Abstract: The Secure Task-bound Agent Message Proof (STAMP) protocol provides a
     cryptographically verifiable delegation and proof framework for AI-
     driven multi-agent systems. STAMP introduces task-bound access tokens
     and message-level proofs for agentic environments, binding tokens to
     specific user intents, tasks, and agent identities. STAMP tokens
     ensure that delegation, execution, and agent-to-agent communication
     comply with least-privilege and zero-trust security principles.
     STAMP interoperates with OAuth 2.0, GNAP, and modern proof-of-
     possession (PoP) techniques, providing stronger security for dynamic,
     non-deterministic workflows involving autonomous agents.

  Network Working Group                                         Guy Bary
  Internet-Draft                                      Intended status: Standards Track
  Expires: October 29, 2025                                          April 27, 2025


         Secure Task-bound Agent Message Proof (STAMP) Protocol
                   draft-guy-bary-stamp-protocol-00

  Abstract

     The Secure Task-bound Agent Message Proof (STAMP) protocol provides a
     cryptographically verifiable delegation and proof framework for AI-
     driven multi-agent systems. STAMP introduces task-bound access tokens
     and message-level proofs for agentic environments, binding tokens to
     specific user intents, tasks, and agent identities. STAMP tokens
     ensure that delegation, execution, and agent-to-agent communication
     comply with least-privilege and zero-trust security principles.
     STAMP interoperates with OAuth 2.0, GNAP, and modern proof-of-
     possession (PoP) techniques, providing stronger security for dynamic,
     non-deterministic workflows involving autonomous 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."

  Copyright Notice

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

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


  Table of Contents

     1. Introduction
     2. Terminology
     3. Motivation and Use Cases
     4. Protocol Overview
     5. STAMP Token Format
     6. Task Handling (Short vs Long Tasks)
     7. Agent-to-Agent Delegation
     8. Cryptographic Primitives
     9. Message Flows
     10. Comparison to OAuth2 + DPoP and GNAP
     11. Security Considerations
     12. Privacy Considerations
     13. IANA Considerations
     14. References

  1. Introduction

     The rise of autonomous agents, especially AI-driven multi-agent
     systems, introduces complex delegation, communication, and
     authorization challenges. 

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

response_json:
  [
    {
      "title": "Task-bound Access Tokens",
      "description": "Cryptographic tokens that bind authorization to specific user intents, tasks, and agent identities. These tokens enforce least-privilege principles by restricting agent capabilities to only what's needed for the specific task.",
      "type": "mechanism"
    },
    {
      "title": "Message-level Proofs",
      "description": "Cryptographic proofs attached to individual messages in agent-to-agent communication. Provides verifiable evidence of authorization and message integrity at the granular message level.",
      "type": "mechanism"
    },
    {
      "title": "Agent-to-Agent Delegation Framework",
      "description": "Protocol mechanism allowing autonomous agents to securely delegate tasks and permissions to other agents. Maintains cryptographic proof chains throughout the delegation process.",
      "type": "protocol"
    },
    {
      "title": "STAMP Token Format",
      "description": "Structured token format that encodes task bindings, agent identities, and cryptographic proofs. Designed specifically for multi-agent environments with dynamic workflows.",
      "type": "mechanism"
    },
    {
      "title": "OAuth 2.0/GNAP Interoperability",
      "description": "Integration layer that allows STAMP to work with existing OAuth 2.0 and GNAP authorization frameworks. Extends these protocols with agent-specific capabilities while maintaining compatibility.",
      "type": "extension"
    },
    {
      "title": "Task Duration Handling",
      "description": "Protocol differentiation between short-lived and long-running tasks with appropriate token lifecycle management. Addresses the temporal aspects of autonomous agent operations.",
      "type": "pattern"
    }
  ]


draft_name: draft-hackett-ures
prompt_hash: 461625d77277255a
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:43:58.716594+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-hackett-ures | Unified Rendering of Email Standard (URES) | 23pg
  Abstract: This document specifies requirements for the uniform rendering of
     HTML email content across mail user agents (MUAs).  It addresses
     critical inconsistencies in how email clients interpret HTML and CSS,
     including dark mode adaptation, embedded asset handling, positioning
     constraints, and secure SVG rendering.  The specification aims to
     eliminate the current fragmentation in email rendering while
     maintaining backwards compatibility with existing MIME standards
     (RFCs 2045-2049) and the Internet Message Format (RFC 5322).





  Independent Submission                                        W. Hackett
  Internet-Draft                                              January 2026
  Intended status: Standards Track                                        
  Expires: 16 July 2026


                 Unified Rendering of Email Standard (URES)
                           draft-hackett-ures-00

  Abstract

     This document specifies requirements for the uniform rendering of
     HTML email content across mail user agents (MUAs).  It addresses
     critical inconsistencies in how email clients interpret HTML and CSS,
     including dark mode adaptation, embedded asset handling, positioning
     constraints, and secure SVG rendering.  The specification aims to
     eliminate the current fragmentation in email rendering while
     maintaining backwards compatibility with existing MIME standards
     (RFCs 2045-2049) and the Internet Message Format (RFC 5322).

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

  Copyright Notice

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










  Hackett                   Expires 16 July 2026                  [Page 1]


  Internet-Draft                    URES                      January 2026


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

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.1.  Background  . . . . . . . . . . . . . . . . . . . . . . .   3
       1.2.  Problem Statement . . . . . . . . . . . . . . . . . . . .   4
       1.3.  Requirements Language . . . . . . . . . . . . . . . . . .   5
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.  Document Structure Requirements . . . . . . . . . . . . . . .   6
       3.1.  HTML Version  . . . . . . . . . . . . . . . . . . . . . . 

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

response_json:
  [
    {
      "title": "URES HTML Version Requirement",
      "description": "Specification mandates HTML5 DOCTYPE and specific HTML version requirements for consistent email rendering across MUAs. Establishes baseline HTML standard for email content.",
      "type": "requirement"
    },
    {
      "title": "Dark Mode Adaptation Mechanism",
      "description": "Standardized approach for HTML emails to automatically adapt visual styling for dark mode displays. Addresses inconsistent dark mode handling across different email clients.",
      "type": "mechanism"
    },
    {
      "title": "Embedded Asset Handling Protocol",
      "description": "Unified method for processing and rendering embedded assets within HTML email content. Ensures consistent behavior for images, stylesheets, and other embedded resources.",
      "type": "protocol"
    },
    {
      "title": "CSS Positioning Constraints",
      "description": "Specific limitations and requirements for CSS positioning properties in email context. Defines which positioning techniques are permitted to ensure reliable cross-client rendering.",
      "type": "requirement"
    },
    {
      "title": "Secure SVG Rendering Framework",
      "description": "Security-focused approach to rendering SVG content within HTML emails while preventing malicious code execution. Balances functionality with security requirements.",
      "type": "mechanism"
    }
  ]


draft_name: draft-han-ai-agent-impact-infra
prompt_hash: 5c3cde8e2ebc73ca
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:44:04.905309+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-han-ai-agent-impact-infra | The Impact of AI Agent to Network Infrastructure | 8pg
  Abstract: This document disucss and analyses the impact of AI Agent on network
     infrastructure aiming to facilitate the discussion and
     standardization about AI Agent communication within IETF.





  Network Working Group                                        M. Han, Ed.
  Internet-Draft                                             N. Zhang, Ed.
  Intended status: Informative                              X. Gu, Ed.
  Expires: 8 January 2026                                     China Unicom
                                                               7 July 2025


              The Impact of AI Agent to Network Infrastructure
                     draft-han-ai-agent-impact-infra-00

  Abstract

     This document disucss and analyses the impact of AI Agent on network
     infrastructure aiming to facilitate the discussion and
     standardization about AI Agent communication within IETF.

  Status of This Memo

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

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

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

     This Internet-Draft will expire on 8 January 2026.

  Copyright Notice

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

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





  Han, et al.              Expires 8 January 2026                 [Page 1]


  Internet-Draft   The Impact of AI Agent to Network Infra       July 2025


  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
     3.  Network for Agent Communication . . . . . . . . . . . . . . .   3
       3.1.  Scenarios . . . . . . . . . . . . . . . . . . . . . . . .   3
         3.1.1.  Agent Communication in LAN  . . . . . . . . . . . . .   3
         3.1.2.  Agent Communication across WAN  . . . . . . . . . . .   4
         3.1.3.  Agent Communication in Fields . . . . . . . . . . . .   4
       3.2.  Gap Analysis  . . . . . . . . . . . . . . . . . . . . . .   5
         3.2.1.  Agent ID management among heterougenous networks  . .   5
         3.2.2.  Mobility Management (esp. for Non-3GPP networks)  . .   5
       

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

response_json:
  [
    {
      "title": "Agent ID Management",
      "description": "Management system for AI agent identifiers across heterogeneous network environments. Addresses the challenge of maintaining consistent agent identity across different network types.",
      "type": "mechanism"
    },
    {
      "title": "Agent Communication in LAN",
      "description": "Communication patterns and protocols for AI agents operating within local area networks. Defines how agents discover and communicate with each other in LAN environments.",
      "type": "pattern"
    },
    {
      "title": "Agent Communication across WAN",
      "description": "Framework for AI agent communication spanning wide area networks. Addresses routing, addressing, and connectivity challenges for inter-network agent interactions.",
      "type": "architecture"
    },
    {
      "title": "Agent Field Communication",
      "description": "Communication mechanisms for AI agents operating in field environments with potentially limited or intermittent connectivity. Focuses on resilient communication patterns.",
      "type": "pattern"
    },
    {
      "title": "Non-3GPP Mobility Management",
      "description": "Mobility management solutions for AI agents in non-3GPP network environments. Handles agent movement and session continuity outside traditional cellular networks.",
      "type": "mechanism"
    }
  ]


draft_name: draft-han-rtgwg-agent-gateway-intercomm-framework
prompt_hash: 85ca3749aa9e3fb7
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:44:11.762404+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-han-rtgwg-agent-gateway-intercomm-framework | Agent Gateway Intercommunication Framework | 12pg
  Abstract: This document defines the framework and requirements for
     intercommunication between Agent Gateways (AGw) in the Agent Internet
     (IoA) ecosystem.  It specifies a hierarchical layered model,
     functional components, protocol requirements and deployment
     consideration for AGw interconnection.  The framework aims to address
     data synchronization, protocol compatibility, and security challenges
     in cross-domain agent collaboration, enabling efficient and scalable
     communication for distributed intelligent agents.  It is compatible
     with existing IoA reference architectures while specializing in
     cross-domain gateway interoperability.





  RTGWG                                                        Z. Han, Ed.
  Internet-Draft                                              Z. Ruan, Ed.
  Intended status: Informational                                    M. Han
  Expires: 3 August 2026                                      China Unicom
                                                                    J. Yan
                                                           ZTE Corporation
                                                                     T. He
                                                                   R. Pang
                                                              China Unicom
                                                           30 January 2026


                 Agent Gateway Intercommunication Framework
            draft-han-rtgwg-agent-gateway-intercomm-framework-01

  Abstract

     This document defines the framework and requirements for
     intercommunication between Agent Gateways (AGw) in the Agent Internet
     (IoA) ecosystem.  It specifies a hierarchical layered model,
     functional components, protocol requirements and deployment
     consideration for AGw interconnection.  The framework aims to address
     data synchronization, protocol compatibility, and security challenges
     in cross-domain agent collaboration, enabling efficient and scalable
     communication for distributed intelligent agents.  It is compatible
     with existing IoA reference architectures while specializing in
     cross-domain gateway interoperability.

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







  Han, et al.               Expires 3 August 2026                 [Page 1]


  Internet-Draft      Agent Gateway Intercomm Framework       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 P

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

response_json:
  [
    {
      "title": "Agent Gateway (AGw) Hierarchical Layered Model",
      "description": "A multi-layer architecture for structuring Agent Gateway intercommunication with defined functional separation. This enables systematic organization of cross-domain agent communication capabilities.",
      "type": "architecture"
    },
    {
      "title": "Cross-Domain Agent Collaboration Protocol",
      "description": "Protocol mechanisms specifically designed for enabling intelligent agents to collaborate across different administrative domains through gateway intermediaries. Addresses protocol compatibility challenges between heterogeneous agent systems.",
      "type": "protocol"
    },
    {
      "title": "AGw Data Synchronization Mechanism",
      "description": "Technical approach for maintaining data consistency and synchronization between distributed Agent Gateways. Ensures coherent state management across the Agent Internet ecosystem.",
      "type": "mechanism"
    },
    {
      "title": "Agent Internet Gateway Interoperability Framework",
      "description": "Standardized framework for ensuring different Agent Gateway implementations can communicate effectively. Specializes in cross-domain gateway compatibility within the IoA ecosystem.",
      "type": "framework"
    },
    {
      "title": "Distributed Agent Communication Security Model",
      "description": "Security mechanisms tailored for protecting intercommunication between Agent Gateways in distributed intelligent agent deployments. Addresses unique security challenges in cross-domain agent collaboration.",
      "type": "mechanism"
    }
  ]


draft_name: draft-happel-structured-email-trust
prompt_hash: 74dfe5385ff67ee8
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:44:19.953144+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-happel-structured-email-trust | Trust and security considerations for Structured Email | 10pg
  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.





  sml                                                         H.-J. Happel
  Internet-Draft                                                   audriga
  Intended status: Standards Track                          A. Gulbrandsen
  Expires: 14 November 2025                                          ICANN
                                                               13 May 2025


           Trust and security considerations for Structured Email
                   draft-happel-structured-email-trust-04

  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.

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





  Happel & Gulbrandsen    Expires 14 November 2025                [Page 1]


  Internet-Draft                  SML Trust                       May 2025


  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
     3.  Types of security concerns  . . . . . . . . . . . . . . . . .   3
       3.1.  Spam/virus filters  . . . . . . . . . . . . . . . . . . .   3
       3.2.  Formal display of data  . . . . . . . . . . . . . . . . .   3
       3.3.  Automated processing  . . . . . . . . . . . . . . . . . .   4
       3.4.  External references . . . . . . . . . . . . . . . . . . .   4
       3.5.  Social engineering  . . . . . . . . . . . . . . . . . . .   4
     4.  Trust mechanisms  . . . . . . . . . . . . . . . . . . . . . .   5
       4.1.  Trusted senders . . . . . . . . . . . . . . . . . .

  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": "Security framework specifically designed to address trust and security considerations when processing structured data embedded within email messages. Provides guidance for message user agents on safe handling of structured email content.",
      "type": "architecture"
    },
    {
      "title": "Spam/Virus Filter Adaptation",
      "description": "Enhanced filtering mechanisms that can properly analyze and process structured email content without being bypassed by malicious structured data. Addresses the challenge of maintaining security while supporting rich email formats.",
      "type": "mechanism"
    },
    {
      "title": "Formal Data Display Controls",
      "description": "Standardized approach for how message user agents should render and display structured data to users. Ensures consistent and secure presentation of structured email content across different email clients.",
      "type": "pattern"
    },
    {
      "title": "Automated Processing Safeguards",
      "description": "Security controls and validation mechanisms for when email clients automatically process structured email data. Prevents malicious exploitation of automated handling of structured content.",
      "type": "mechanism"
    },
    {
      "title": "External Reference Protection",
      "description": "Security measures for handling external links, resources, or references contained within structured email data. Mitigates risks from malicious external content referenced by structured email elements.",
      "type": "mechanism"
    },
    {
      "title": "Trusted Sender Verification",
      "description": "Authentication and trust establishment mechanisms specifically for senders of structured email content. Allows email clients to make informed decisions about processing structured data based on sender trustworthiness.",
      "type": "mechanism"
    }
  ]


draft_name: draft-hong-nmrg-agenticai-ps
prompt_hash: 5c779dcfb05d61c4
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:44:25.481043+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-hong-nmrg-agenticai-ps | Motivations and Problem Statement of Agentic AI for network management | 15pg
  Abstract: This document outlines the key objectives of introducing Agentic AI
     to the field of network management and highlights the fundamental
     issues with existing technologies that must be addressed to achieve
     these goals.  It emphasizes the necessity for relevant groups within
     the IETF/IRTF and presents the core technological areas requiring
     standardization.  The aim of Agentic AI is to facilitate a paradigm
     shift in which multiple autonomous AI agents collaborate to fully
     automate network operation, management and security.





  Network Management                                               Y. Hong
  Internet-Draft                                        Daejeon University
  Intended status: Informational                                   J. Youn
  Expires: 23 April 2026                               DONG-EUI University
                                                                     Q. Wu
                                                                    Huawei
                                                                 B. Claise
                                                            Everything OPS
                                                           20 October 2025


   Motivations and Problem Statement of Agentic AI for network management
                    draft-hong-nmrg-agenticai-ps-00

  Abstract

     This document outlines the key objectives of introducing Agentic AI
     to the field of network management and highlights the fundamental
     issues with existing technologies that must be addressed to achieve
     these goals.  It emphasizes the necessity for relevant groups within
     the IETF/IRTF and presents the core technological areas requiring
     standardization.  The aim of Agentic AI is to facilitate a paradigm
     shift in which multiple autonomous AI agents collaborate to fully
     automate network operation, management and security.

  Discussion Venues

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

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

     Source for this draft and an issue tracker can be found at
     https://github.com/billwuqin/agentic-ai-ps.

  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.

  Table of Contents

     1.  Introduction
     2.  Conventions and Definitions
     3.  Agentic AI for N

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

response_json:
  [
    {
      "title": "Multi-Agent Collaborative Network Management",
      "description": "Multiple autonomous AI agents collaborate to fully automate network operation, management and security. This represents a paradigm shift from traditional centralized network management approaches.",
      "type": "architecture"
    },
    {
      "title": "Agentic AI Framework for Network Operations",
      "description": "A comprehensive framework introducing autonomous AI agents specifically designed for network management tasks. The framework addresses fundamental issues with existing technologies through agent-based automation.",
      "type": "architecture"
    },
    {
      "title": "Autonomous Network Agent Standardization Requirements",
      "description": "Core technological areas requiring standardization to enable interoperable autonomous AI agents in network management. This identifies specific IETF/IRTF standardization needs for agentic AI deployment.",
      "type": "requirement"
    },
    {
      "title": "Network Management Automation Paradigm",
      "description": "A fundamental shift from human-driven to fully automated network operations through coordinated AI agents. This paradigm enables complete automation of network operation, management, and security functions.",
      "type": "pattern"
    }
  ]


draft_name: draft-huang-acme-scalable-agent-enrollment
prompt_hash: e58b69af0c08713c
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:44:32.753761+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-huang-acme-scalable-agent-enrollment | Extending Certificate Enrollment Protocols for Scalable Agentic AI Identity | 9pg
  Abstract: Agentic AI systems require robust, verifiable identities to operate
     securely.  While traditional certificate enrollment protocols like
     SCEP and EST can be extended to include remote attestation evidence,
     performing a full validation for every agent's certificate request
     presents significant scalability and privacy challenges.  This
     document proposes two distinct, scalable models for integrating
     attestation into the enrollment lifecycle.  The first model leverages
     Zero-Knowledge Proofs (ZKP) to provide private, efficient, and
     continuous attestation.  The second model uses a one-time, high-
     assurance bootstrapping process to establish a trusted host
     environment, which is then authorized to endorse certificate requests
     for the agents it runs.  Both models enable high-assurance identity
     for AI agents while addressing the performance bottlenecks of naive
     per-enrollment verification.





  RATS                                                            K. Huang
  Internet-Draft                                        DistributedApps.ai
  Intended status: Standards Track                                J. Huang
  Expires: 16 December 2025                                Kleiner Perkins
                                                              14 June 2025


     Extending Certificate Enrollment Protocols for Scalable Agentic AI
                                  Identity
               draft-huang-acme-scalable-agent-enrollment-00

  Abstract

     Agentic AI systems require robust, verifiable identities to operate
     securely.  While traditional certificate enrollment protocols like
     SCEP and EST can be extended to include remote attestation evidence,
     performing a full validation for every agent's certificate request
     presents significant scalability and privacy challenges.  This
     document proposes two distinct, scalable models for integrating
     attestation into the enrollment lifecycle.  The first model leverages
     Zero-Knowledge Proofs (ZKP) to provide private, efficient, and
     continuous attestation.  The second model uses a one-time, high-
     assurance bootstrapping process to establish a trusted host
     environment, which is then authorized to endorse certificate requests
     for the agents it runs.  Both models enable high-assurance identity
     for AI agents while addressing the performance bottlenecks of naive
     per-enrollment verification.

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







  Huang & Huang           Expires 16 December 2025                [Page 1]


  Internet-Draft          Scalable Agent Enrollment              June 2025


  Copyright Notice

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

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

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

response_json:
  [
    {
      "title": "ZKP-based Agent Attestation",
      "description": "Zero-Knowledge Proofs enable AI agents to prove their attestation properties during certificate enrollment without revealing sensitive details. This provides private, efficient, and continuous attestation while maintaining scalability.",
      "type": "mechanism"
    },
    {
      "title": "Trusted Host Bootstrapping",
      "description": "A one-time, high-assurance bootstrapping process establishes a trusted host environment that can subsequently endorse certificate requests for AI agents it runs. This amortizes the cost of full attestation validation across multiple agent enrollments.",
      "type": "pattern"
    },
    {
      "title": "Attestation-Extended Enrollment Protocols",
      "description": "Extensions to traditional certificate enrollment protocols like SCEP and EST to include remote attestation evidence as part of the enrollment process. This integrates hardware-based trust anchors into certificate lifecycle management.",
      "type": "extension"
    },
    {
      "title": "Scalable Agent Identity Architecture",
      "description": "An architecture that addresses performance bottlenecks of per-enrollment attestation validation for AI agents by using either ZKP-based private attestation or trusted host endorsement models. This enables high-assurance identity management at scale.",
      "type": "architecture"
    },
    {
      "title": "Host-Delegated Certificate Endorsement",
      "description": "A mechanism where a pre-validated trusted host is authorized to endorse certificate requests on behalf of AI agents running within its environment. This reduces the computational overhead of individual agent attestation while maintaining security assurances.",
      "type": "mechanism"
    }
  ]


draft_name: draft-huang-rats-agentic-eat-cap-attest
prompt_hash: 0669a6cce0fd8224
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:44:42.640908+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-huang-rats-agentic-eat-cap-attest | Capability Attestation Extensions for the Entity Attestation Token (EAT) in Agentic AI Systems | 6pg
  Abstract: This document specifies extensions to the Entity Attestation Token
     (EAT) [RFC9248] to support robust, interoperable attestation of
     capabilities in agentic AI systems.  These extensions introduce new
     claims and guidance for securely asserting agent functional,
     reasoning, and operational capabilities, as well as their
     compositional structure and policy constraints.  The goal is to
     enable trustworthy, verifiable, and privacy-respecting capability
     attestation for autonomous agents in dynamic, decentralized
     environments.





  RATS                                                            K. Huang
  Internet-Draft                                        DistributedApps.ai
  Intended status: Standards Track                               June 2025
  Expires: 15 December 2025


  Capability Attestation Extensions for the Entity Attestation Token (EAT)
                           in Agentic AI Systems
                 draft-huang-rats-agentic-eat-cap-attest-00

  Abstract

     This document specifies extensions to the Entity Attestation Token
     (EAT) [RFC9248] to support robust, interoperable attestation of
     capabilities in agentic AI systems.  These extensions introduce new
     claims and guidance for securely asserting agent functional,
     reasoning, and operational capabilities, as well as their
     compositional structure and policy constraints.  The goal is to
     enable trustworthy, verifiable, and privacy-respecting capability
     attestation for autonomous agents in dynamic, decentralized
     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."

     This Internet-Draft will expire on 3 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



  Huang                   Expires 15 December 2025                [Page 1]


  Internet-Draft           Agentic EAT Cap Attest                June 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 . . . . . . . . . . . . . . . . . . . . . . . . .   2
     3.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     4.  Capability Attestation Claims . . . . . . . . . . . . . . . .   3
     5.  Nested and Modular Agent Representations  . . . . . . . . . .   4
     6.  Endorsements and Trust Anchors  . . . . . . . . . . . . . 

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

response_json:
  [
    {
      "title": "EAT Capability Claims Extension",
      "description": "New claims added to Entity Attestation Token (EAT) for asserting agent functional, reasoning, and operational capabilities. Extends RFC9248 EAT standard with AI-specific capability attestation fields.",
      "type": "extension"
    },
    {
      "title": "Nested Agent Representation",
      "description": "Mechanism for representing compositional structure of agentic AI systems within attestation tokens. Supports modular agent architectures with hierarchical capability attestation.",
      "type": "mechanism"
    },
    {
      "title": "Capability Policy Constraints",
      "description": "Framework for embedding policy constraints within capability attestations to limit agent operations. Provides verifiable bounds on what capabilities agents can exercise.",
      "type": "mechanism"
    },
    {
      "title": "Privacy-Respecting Capability Attestation",
      "description": "Attestation approach that enables capability verification while preserving agent privacy in decentralized environments. Balances transparency requirements with confidentiality needs.",
      "type": "pattern"
    },
    {
      "title": "Interoperable Agentic Attestation",
      "description": "Standardized approach for capability attestation across different agentic AI systems and platforms. Enables cross-system trust establishment and capability verification.",
      "type": "protocol"
    }
  ]


draft_name: draft-hw-ai-agent-6g
prompt_hash: 3a7421936942a3e9
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:44:48.112563+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-hw-ai-agent-6g | Requirements and Enabling Technologies of Agent Protocols for 6G Networks | 20pg
  Abstract: Agent application will be surely the common trend for a long time in
     future, while agent protocols are so popular that more and more
     protocols are being worked out.  The telecommunication industry plays
     a pivotal role in the Agent ecosystem.  The overall technology
     success hinges on how telecommunication industry could adopt the
     latest AI trends in order to handle its specific usage scenarios and
     performance requirements, e.g., in the coming 6G era.  This document
     will provide the first attempt to analyze the agent protocol
     requirements and relevant enabling technologies based on mobile
     communication system specific characteristics.





  Network Working Group                                     Chenchen Yang,
  Internet-Draft                                           Huanhuan Huang,
  Intended status: Standards Track                      Arashmid Akhavain,
  Expires: 21 January 2026                                       Faye Liu,
                                                                 Xueli An,
                                                              Weijun Xing,
                                                                    Huawei
                                                                Jinyan Li,
                                                               Aijun Wang,
                                                             China Telecom
                                                             Wencong Yang,
                                                              China Unicom
                                                              20 July 2025


      Requirements and Enabling Technologies of Agent Protocols for 6G
                                  Networks
                          draft-hw-ai-agent-6g-00

  Abstract

     Agent application will be surely the common trend for a long time in
     future, while agent protocols are so popular that more and more
     protocols are being worked out.  The telecommunication industry plays
     a pivotal role in the Agent ecosystem.  The overall technology
     success hinges on how telecommunication industry could adopt the
     latest AI trends in order to handle its specific usage scenarios and
     performance requirements, e.g., in the coming 6G era.  This document
     will provide the first attempt to analyze the agent protocol
     requirements and relevant enabling technologies based on mobile
     communication system specific characteristics.

  Status of This Memo

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

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

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

     This Internet-Draft will expire on 21 January 2026.



  Chenchen Yang,, et al.   Expires 21 January 2026                [Page 1]


  Internet-Draft                 Short Title                     July 2025


  Copyright Notice

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

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this docum

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

response_json:
  [
    {
      "title": "6G Agent Protocol Framework",
      "description": "Protocol framework specifically designed for AI agent applications in 6G networks. Addresses mobile communication system characteristics and performance requirements unique to 6G environments.",
      "type": "protocol"
    },
    {
      "title": "Mobile-Specific Agent Requirements",
      "description": "Technical requirements for agent protocols tailored to mobile communication systems. Includes performance, latency, and reliability constraints specific to cellular networks.",
      "type": "requirement"
    },
    {
      "title": "Telecom-AI Integration Architecture",
      "description": "Architecture for integrating latest AI agent trends with telecommunication infrastructure. Enables adoption of AI capabilities while meeting telecom-specific operational constraints.",
      "type": "architecture"
    },
    {
      "title": "6G Agent Enabling Technologies",
      "description": "Specific enabling technologies required to support agent protocols in 6G networks. Focuses on technical mechanisms needed for agent communication and coordination.",
      "type": "mechanism"
    }
  ]


draft_name: draft-ietf-ace-coap-est-oscore
prompt_hash: 7401a32795013615
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:44:55.485147+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-ace-coap-est-oscore | Protecting EST Payloads with OSCORE | 23pg
  Abstract: Enrollment over Secure Transport (EST) is a certificate provisioning
     protocol over HTTPS [RFC7030] or CoAPs [RFC9148].  This document
     specifies how to carry EST over the Constrained Application Protocol
     (CoAP) protected with Object Security for Constrained RESTful
     Environments (OSCORE).  The specification builds on the EST-coaps
     [RFC9148] specification, but uses OSCORE and Ephemeral Diffie-Hellman
     over COSE (EDHOC) instead of DTLS.  The specification also leverages
     the certificate structures defined in
     [I-D.ietf-cose-cbor-encoded-cert], which can be optionally used
     alongside X.509 certificates.





  ACE Working Group                                            G. Selander
  Internet-Draft                                               Ericsson AB
  Intended status: Standards Track                                 S. Raza
  Expires: 23 April 2026                                              RISE
                                                                M. Furuhed
                                                                     Nexus
                                                                M. Vučinić
                                                                     Inria
                                                                 T. Claeys
                                                           20 October 2025


                    Protecting EST Payloads with OSCORE
                     draft-ietf-ace-coap-est-oscore-09

  Abstract

     Enrollment over Secure Transport (EST) is a certificate provisioning
     protocol over HTTPS [RFC7030] or CoAPs [RFC9148].  This document
     specifies how to carry EST over the Constrained Application Protocol
     (CoAP) protected with Object Security for Constrained RESTful
     Environments (OSCORE).  The specification builds on the EST-coaps
     [RFC9148] specification, but uses OSCORE and Ephemeral Diffie-Hellman
     over COSE (EDHOC) instead of DTLS.  The specification also leverages
     the certificate structures defined in
     [I-D.ietf-cose-cbor-encoded-cert], which can be optionally used
     alongside X.509 certificates.

  Discussion Venues

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

     Discussion of this document takes place on the Authentication and
     Authorization for Constrained Environments Working Group mailing list
     (ace@ietf.org), which is archived at
     https://mailarchive.ietf.org/arch/browse/ace/.

     Source for this draft and an issue tracker can be found at
     https://github.com/EricssonResearch/EST-OSCORE.

  Status of This Memo

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







  Selander, et al.          Expires 23 April 2026                 [Page 1]


  Internet-Draft                 EST-oscore                   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
     Provisions Re

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

response_json:
  [
    {
      "title": "EST over CoAP with OSCORE Protection",
      "description": "Specifies carrying EST certificate provisioning protocol over CoAP protected with OSCORE instead of DTLS. Builds on EST-coaps but replaces transport layer security with application layer object security.",
      "type": "protocol"
    },
    {
      "title": "EDHOC for EST Key Establishment",
      "description": "Uses Ephemeral Diffie-Hellman over COSE (EDHOC) for establishing security context instead of DTLS handshake. Provides authenticated key exchange suitable for constrained environments.",
      "type": "mechanism"
    },
    {
      "title": "CBOR Certificate Support",
      "description": "Leverages CBOR-encoded certificate structures that can be used alongside traditional X.509 certificates. Enables more compact certificate representations for constrained devices.",
      "type": "extension"
    },
    {
      "title": "Application Layer Security for EST",
      "description": "Moves security protection from transport layer (DTLS) to application layer (OSCORE) for EST operations. Enables end-to-end protection of EST payloads independent of underlying transport.",
      "type": "architecture"
    },
    {
      "title": "Constrained Device Certificate Provisioning",
      "description": "Adapts EST certificate enrollment for resource-constrained IoT devices using lightweight protocols. Reduces overhead compared to HTTPS-based EST while maintaining security properties.",
      "type": "pattern"
    }
  ]


draft_name: draft-ietf-ace-edhoc-oscore-profile
prompt_hash: ff8dbb2f5325cc90
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:45:02.944888+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-ace-edhoc-oscore-profile | Ephemeral Diffie-Hellman Over COSE (EDHOC) and Object Security for Constrained Environments (OSCORE) Profile for Authentication and Authorization for Constrained Environments (ACE) | 91pg
  Abstract: This document specifies a profile for the Authentication and
     Authorization for Constrained Environments (ACE) framework.  It
     utilizes Ephemeral Diffie-Hellman Over COSE (EDHOC) for achieving
     mutual authentication between an ACE-OAuth client and resource
     server, and it binds an authentication credential of the client to an
     ACE-OAuth access token.  EDHOC also establishes an Object Security
     for Constrained RESTful Environments (OSCORE) Security Context, which
     is used to secure communications between the client and resource
     server when accessing protected resources according to the
     authorization information indicated in the access token.  This
     profile can be used to delegate management of authorization
     information from a resource-constrained server to a trusted host with
     less severe limitations regarding processing power and memory.





  ACE Working Group                                            G. Selander
  Internet-Draft                                         J. Preuß Mattsson
  Intended status: Standards Track                                Ericsson
  Expires: 23 April 2026                                         M. Tiloca
                                                                R. Höglund
                                                                      RISE
                                                           20 October 2025


     Ephemeral Diffie-Hellman Over COSE (EDHOC) and Object Security for
      Constrained Environments (OSCORE) Profile for Authentication and
              Authorization for Constrained Environments (ACE)
                   draft-ietf-ace-edhoc-oscore-profile-09

  Abstract

     This document specifies a profile for the Authentication and
     Authorization for Constrained Environments (ACE) framework.  It
     utilizes Ephemeral Diffie-Hellman Over COSE (EDHOC) for achieving
     mutual authentication between an ACE-OAuth client and resource
     server, and it binds an authentication credential of the client to an
     ACE-OAuth access token.  EDHOC also establishes an Object Security
     for Constrained RESTful Environments (OSCORE) Security Context, which
     is used to secure communications between the client and resource
     server when accessing protected resources according to the
     authorization information indicated in the access token.  This
     profile can be used to delegate management of authorization
     information from a resource-constrained server to a trusted host with
     less severe limitations regarding processing power and memory.

  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-ietf-ace-edhoc-oscore-
     profile/.

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

     Source for this draft and an issue tracker can be found at
     https://github.com/ace-wg/ace-edhoc-oscore-profile.





  Selander, et al.          Expires 23 April 2026                 [Page 1]


  Internet-Draft       EDHOC and OSCORE profile of ACE        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
    

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

response_json:
  [
    {
      "title": "ACE-EDHOC-OSCORE Profile",
      "description": "A complete profile for the ACE framework that combines EDHOC mutual authentication with OSCORE security context establishment for constrained environments. The profile binds client authentication credentials to ACE-OAuth access tokens.",
      "type": "profile"
    },
    {
      "title": "EDHOC-OSCORE Security Context Binding",
      "description": "A mechanism that establishes an OSCORE security context directly from the EDHOC key exchange protocol. This eliminates the need for separate security context establishment between client and resource server.",
      "type": "mechanism"
    },
    {
      "title": "Client Credential to Access Token Binding",
      "description": "A binding mechanism that cryptographically links a client's authentication credential used in EDHOC to an ACE-OAuth access token. This ensures proof-of-possession of the credential when presenting the token.",
      "type": "mechanism"
    },
    {
      "title": "Authorization Delegation Pattern",
      "description": "An architectural pattern that delegates authorization information management from resource-constrained servers to trusted hosts with greater processing and memory capabilities. The constrained server can offload complex authorization decisions while maintaining security.",
      "type": "pattern"
    },
    {
      "title": "Mutual Authentication for ACE-OAuth",
      "description": "Extension of the ACE-OAuth framework to support mutual authentication between client and resource server using EDHOC. This provides stronger security guarantees than bearer token approaches.",
      "type": "extension"
    }
  ]


draft_name: draft-ietf-anima-brski-prm
prompt_hash: f4206652b6a1669e
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:45:10.333893+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-anima-brski-prm | BRSKI with Pledge in Responder Mode (BRSKI-PRM) | 123pg
  Abstract: This document defines enhancements to Bootstrapping Remote Secure Key
     Infrastructure (BRSKI, RFC8995) as BRSKI with Pledge in Responder
     Mode (BRSKI-PRM).  BRSKI-PRM supports the secure bootstrapping of
     devices, referred to as pledges, into a domain where direct
     communication with the registrar is either limited or not possible at
     all.  To facilitate interaction between a pledge and a domain
     registrar the registrar-agent is introduced as new component.  The
     registrar-agent supports the reversal of the interaction model from a
     pledge-initiated mode, to a pledge-responding mode, where the pledge
     is in a server role.  To establish the trust relation between pledge
     and registrar, BRSKI-PRM relies on object security rather than
     transport security.  This approach is agnostic to enrollment
     protocols that connect a domain registrar to a key infrastructure
     (e.g., domain Certification Authority).





  ANIMA WG                                                        S. Fries
  Internet-Draft                                                 T. Werner
  Intended status: Standards Track                                 Siemens
  Expires: 5 December 2025                                         E. Lear
                                                             Cisco Systems
                                                             M. Richardson
                                                  Sandelman Software Works
                                                               3 June 2025


              BRSKI with Pledge in Responder Mode (BRSKI-PRM)
                       draft-ietf-anima-brski-prm-23

  Abstract

     This document defines enhancements to Bootstrapping Remote Secure Key
     Infrastructure (BRSKI, RFC8995) as BRSKI with Pledge in Responder
     Mode (BRSKI-PRM).  BRSKI-PRM supports the secure bootstrapping of
     devices, referred to as pledges, into a domain where direct
     communication with the registrar is either limited or not possible at
     all.  To facilitate interaction between a pledge and a domain
     registrar the registrar-agent is introduced as new component.  The
     registrar-agent supports the reversal of the interaction model from a
     pledge-initiated mode, to a pledge-responding mode, where the pledge
     is in a server role.  To establish the trust relation between pledge
     and registrar, BRSKI-PRM relies on object security rather than
     transport security.  This approach is agnostic to enrollment
     protocols that connect a domain registrar to a key infrastructure
     (e.g., domain Certification Authority).

  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-ietf-anima-brski-prm/.

     Source for this draft and an issue tracker can be found at
     https://github.com/anima-wg/anima-brski-prm.

  Status of This Memo

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







  Fries, et al.            Expires 5 December 2025                [Page 1]


  Internet-Draft                  BRSKI-PRM                      June 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 5 December 2025.

  Copyright Notice

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

     This document is subj

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

response_json:
  [
    {
      "title": "Registrar-Agent Component",
      "description": "A new architectural component that acts as an intermediary between pledges and the domain registrar when direct communication is limited or impossible. The registrar-agent enables the reversal of interaction model from pledge-initiated to pledge-responding mode.",
      "type": "architecture"
    },
    {
      "title": "Pledge Responder Mode",
      "description": "A mechanism where the pledge operates in server role instead of client role, responding to requests rather than initiating them. This reverses the traditional BRSKI interaction model to support scenarios with limited connectivity.",
      "type": "mechanism"
    },
    {
      "title": "Object Security for Trust Establishment",
      "description": "BRSKI-PRM uses object-level security instead of transport security to establish trust relationships between pledge and registrar. This approach provides security guarantees independent of the underlying transport mechanism.",
      "type": "mechanism"
    },
    {
      "title": "BRSKI-PRM Protocol Enhancement",
      "description": "An extension to the original BRSKI protocol that enables secure bootstrapping in constrained network environments where pledges cannot directly communicate with registrars. It maintains compatibility with existing enrollment protocols.",
      "type": "extension"
    },
    {
      "title": "Enrollment Protocol Agnostic Design",
      "description": "The BRSKI-PRM approach is designed to work with any enrollment protocol that connects a domain registrar to key infrastructure such as Certificate Authorities. This provides flexibility in deployment scenarios.",
      "type": "pattern"
    }
  ]


draft_name: draft-ietf-anima-constrained-voucher
prompt_hash: 576156843f36c2c7
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:45:17.810091+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-anima-constrained-voucher | Constrained Bootstrapping Remote Secure Key Infrastructure (cBRSKI) | 93pg
  Abstract: This document defines the Constrained Bootstrapping Remote Secure Key
     Infrastructure (cBRSKI) protocol, which provides a solution for
     secure zero-touch onboarding of resource-constrained (IoT) devices
     into the network of a domain owner.  This protocol is designed for
     constrained networks, which may have limited data throughput or may
     experience frequent packet loss. cBRSKI is a variant of the BRSKI
     protocol, which uses an artifact signed by the device manufacturer
     called the "voucher" which enables a new device and the owner's
     network to mutually authenticate.  While the BRSKI voucher data is
     encoded in JSON, cBRSKI uses a compact CBOR-encoded voucher.  The
     BRSKI voucher data definition is extended with new data types that
     allow for smaller voucher sizes.  The Enrollment over Secure
     Transport (EST) protocol, used in BRSKI, is replaced with EST-over-
     CoAPS; and HTTPS used in BRSKI is replaced with DTLS-secured CoAP
     (CoAPS).  This document Updates RFC 8995 and RFC 9148.





  anima Working Group                                        M. Richardson
  Internet-Draft                                  Sandelman Software Works
  Updates: 8995, 9148 (if approved)                        P. van der Stok
  Intended status: Standards Track                  vanderstok consultancy
  Expires: 31 August 2026                                    P. Kampanakis
                                                             Cisco Systems
                                                                   E. Dijk
                                                         IoTconsultancy.nl
                                                          27 February 2026


    Constrained Bootstrapping Remote Secure Key Infrastructure (cBRSKI)
                  draft-ietf-anima-constrained-voucher-30

  Abstract

     This document defines the Constrained Bootstrapping Remote Secure Key
     Infrastructure (cBRSKI) protocol, which provides a solution for
     secure zero-touch onboarding of resource-constrained (IoT) devices
     into the network of a domain owner.  This protocol is designed for
     constrained networks, which may have limited data throughput or may
     experience frequent packet loss. cBRSKI is a variant of the BRSKI
     protocol, which uses an artifact signed by the device manufacturer
     called the "voucher" which enables a new device and the owner's
     network to mutually authenticate.  While the BRSKI voucher data is
     encoded in JSON, cBRSKI uses a compact CBOR-encoded voucher.  The
     BRSKI voucher data definition is extended with new data types that
     allow for smaller voucher sizes.  The Enrollment over Secure
     Transport (EST) protocol, used in BRSKI, is replaced with EST-over-
     CoAPS; and HTTPS used in BRSKI is replaced with DTLS-secured CoAP
     (CoAPS).  This document Updates RFC 8995 and RFC 9148.

  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-ietf-anima-constrained-
     voucher/.

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

     Source for this draft and an issue tracker can be found at
     https://github.com/anima-wg/constrained-voucher.




  Richardson, et al.       Expires 31 August 2026                 [Page 1]


  Internet-Draft         Constrained BRSKI (cBRSKI)          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 

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

response_json:
  [
    {
      "title": "CBOR-encoded vouchers",
      "description": "Replaces JSON-encoded vouchers in BRSKI with compact CBOR encoding for constrained devices. Provides smaller message sizes suitable for IoT environments with limited bandwidth.",
      "type": "mechanism"
    },
    {
      "title": "EST-over-CoAPS",
      "description": "Adapts the Enrollment over Secure Transport (EST) protocol to run over CoAPS instead of HTTPS. Enables certificate enrollment for constrained devices using CoAP with DTLS security.",
      "type": "protocol"
    },
    {
      "title": "CoAPS transport replacement",
      "description": "Substitutes HTTPS transport in BRSKI with DTLS-secured CoAP (CoAPS) for all protocol communications. Optimizes for constrained networks with limited throughput and frequent packet loss.",
      "type": "mechanism"
    },
    {
      "title": "Extended voucher data types",
      "description": "Introduces new compact data types in the voucher definition to achieve smaller voucher sizes. Extends the original BRSKI voucher format with constrained-network optimizations.",
      "type": "extension"
    },
    {
      "title": "Zero-touch IoT onboarding",
      "description": "Provides secure automatic bootstrapping of resource-constrained IoT devices into domain networks without manual intervention. Maintains mutual authentication between device and network using manufacturer-signed vouchers.",
      "type": "protocol"
    }
  ]


draft_name: draft-ietf-dnsop-ds-automation
prompt_hash: f6146f8495032306
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:45:26.722266+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-dnsop-ds-automation | Operational Recommendations for DS Automation | 25pg
  Abstract: Enabling support for automatic acceptance of DS parameters from the
     Child DNS operator (via RFCs 7344, 8078, 9615) requires the parental
     agent, often a registry or registrar, to make a number of technical
     decisions around acceptance checks, error and sucess reporting, and
     multi-party issues such as concurrent updates.  This document
     describes how these points are best addressed in practice.





  DNSOP Working Group                                             S. Sheng
  Internet-Draft                                                          
  Intended status: Best Current Practice                      P. Thomassen
  Expires: 17 August 2026                                            deSEC
                                                          13 February 2026


               Operational Recommendations for DS Automation
                     draft-ietf-dnsop-ds-automation-04

  Abstract

     Enabling support for automatic acceptance of DS parameters from the
     Child DNS operator (via RFCs 7344, 8078, 9615) requires the parental
     agent, often a registry or registrar, to make a number of technical
     decisions around acceptance checks, error and sucess reporting, and
     multi-party issues such as concurrent updates.  This document
     describes how these points are best addressed in practice.

  Discussion Venues

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

     Discussion of this document takes place on the Domain Name System
     Operations Working Group mailing list (dnsop@ietf.org), which is
     archived at https://mailarchive.ietf.org/arch/browse/dnsop/.

     Source for this draft and an issue tracker can be found at
     https://github.com/peterthomassen/draft-shetho-dnsop-ds-automation.

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





  Sheng & Thomassen        Expires 17 August 2026                 [Page 1]


  Internet-Draft                DS Automation                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  . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.1.  Requirements N

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

response_json:
  [
    {
      "title": "DS Parameter Acceptance Checks",
      "description": "Validation mechanisms that parental agents must implement to verify DS parameters received from child DNS operators before accepting them into the parent zone. These checks ensure cryptographic validity and operational safety of the delegation signer records.",
      "type": "mechanism"
    },
    {
      "title": "Multi-Party Concurrent Update Handling",
      "description": "Technical approach for managing situations where multiple parties (registrars, DNS operators) attempt to update DS records simultaneously. Addresses race conditions and conflict resolution in automated DS management.",
      "type": "pattern"
    },
    {
      "title": "Error and Success Reporting Framework",
      "description": "Standardized reporting mechanism for communicating the results of automated DS operations back to child operators. Defines how parental agents should indicate acceptance, rejection, or processing status of DS updates.",
      "type": "protocol"
    },
    {
      "title": "Parental Agent Decision Logic",
      "description": "Technical decision tree and criteria that registries and registrar systems should implement when processing automated DS submissions. Covers validation steps, timing considerations, and acceptance thresholds.",
      "type": "mechanism"
    },
    {
      "title": "Child-to-Parent DS Communication Security",
      "description": "Security requirements and verification procedures for ensuring authentic communication of DS parameters from child DNS operators to parental agents. Builds upon existing RFCs 7344, 8078, and 9615 mechanisms.",
      "type": "requirement"
    }
  ]


draft_name: draft-ietf-emu-eap-edhoc
prompt_hash: ee94ba3813f91e01
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:45:34.603923+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-emu-eap-edhoc | Using the Extensible Authentication Protocol (EAP) with Ephemeral Diffie-Hellman over COSE (EDHOC) | 31pg
  Abstract: The Extensible Authentication Protocol (EAP), defined in RFC 3748,
     provides a standard mechanism for support of multiple authentication
     methods.  This document specifies the EAP authentication method EAP-
     EDHOC, based on Ephemeral Diffie-Hellman Over COSE (EDHOC).  EDHOC is
     a lightweight security handshake protocol, enabling authentication
     and establishment of shared secret keys suitable in constrained
     settings.  This document also provides guidance on authentication and
     authorization for EAP-EDHOC.





  EAP Method Update                                     D. Garcia-Carrillo
  Internet-Draft                                      University of Oviedo
  Intended status: Standards Track                          R. Marin-Lopez
  Expires: 3 August 2026                              University of Murcia
                                                               G. Selander
                                                         J. Preuß Mattsson
                                                                  Ericsson
                                                            F. Lopez-Gomez
                                                      University of Murcia
                                                           30 January 2026


     Using the Extensible Authentication Protocol (EAP) with Ephemeral
                      Diffie-Hellman over COSE (EDHOC)
                        draft-ietf-emu-eap-edhoc-07

  Abstract

     The Extensible Authentication Protocol (EAP), defined in RFC 3748,
     provides a standard mechanism for support of multiple authentication
     methods.  This document specifies the EAP authentication method EAP-
     EDHOC, based on Ephemeral Diffie-Hellman Over COSE (EDHOC).  EDHOC is
     a lightweight security handshake protocol, enabling authentication
     and establishment of shared secret keys suitable in constrained
     settings.  This document also provides guidance on authentication and
     authorization for EAP-EDHOC.

  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-ietf-emu-eap-edhoc/.

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

     Source for this draft and an issue tracker can be found at
     https://github.com/dangarciacarrillo/i-d-eap-edhoc.

  Status of This Memo

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





  Garcia-Carrillo, et al.   Expires 3 August 2026                 [Page 1]


  Internet-Draft                  EAP-EDHOC                   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 3 August 2026.

  Copyright Notice

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

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

response_json:
  [
    {
      "title": "EAP-EDHOC Authentication Method",
      "description": "A new EAP authentication method that integrates EDHOC (Ephemeral Diffie-Hellman Over COSE) as the underlying security handshake protocol. This enables lightweight authentication and key establishment suitable for constrained environments within the EAP framework.",
      "type": "protocol"
    },
    {
      "title": "EDHOC-EAP Message Encapsulation",
      "description": "A mechanism for encapsulating EDHOC protocol messages within EAP packet format. This allows EDHOC handshake exchanges to be transported over existing EAP infrastructure.",
      "type": "mechanism"
    },
    {
      "title": "Constrained Environment EAP Pattern",
      "description": "An architectural pattern that adapts EAP authentication for constrained settings by leveraging EDHOC's lightweight properties. This addresses the need for efficient authentication in IoT and resource-limited environments.",
      "type": "pattern"
    },
    {
      "title": "EAP-EDHOC Key Derivation",
      "description": "A key derivation mechanism that generates EAP keying material from EDHOC's established shared secrets. This ensures compatibility with EAP's key management requirements while leveraging EDHOC's cryptographic properties.",
      "type": "mechanism"
    },
    {
      "title": "COSE-based EAP Authentication",
      "description": "Integration of CBOR Object Signing and Encryption (COSE) cryptographic operations within EAP authentication flow. This provides modern cryptographic primitives optimized for constrained environments in EAP contexts.",
      "type": "extension"
    }
  ]


draft_name: draft-ietf-emu-hybrid-pqc-eapaka
prompt_hash: 2dddf52e8adce9db
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:45:42.078893+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-emu-hybrid-pqc-eapaka | Enhancing Security in EAP-AKA' with Hybrid Post-Quantum Cryptography | 13pg
  Abstract: Forward Secrecy for the Extensible Authentication Protocol Method for
     Authentication and Key Agreement (EAP-AKA' FS) is specified in
     [RFC9678], providing updates to [RFC9048] with an optional extension
     that offers ephemeral key exchange using the traditional Ephemeral
     Elliptic Curve Diffie-Hellman (ECDHE) key agreement algorithm for
     achieving perfect forward secrecy (PFS).  However, it is susceptible
     to future threats from Cryptographically Relevant Quantum Computers,
     which could potentially compromise a traditional ephemeral public
     key.  If the adversary has also obtained knowledge of the long-term
     key and ephemeral public key, it could compromise session keys
     generated as part of the authentication run in EAP-AKA'.

     This draft aims to enhance the security of EAP-AKA' FS protocol by
     leveraging PQ/T Hybrid [I-D.ietf-pquip-pqt-hybrid-terminology]
     algorithms to make it quantum-safe.





  EMU                                                          A. Banerjee
  Internet-Draft                                                  T. Reddy
  Intended status: Standards Track                                   Nokia
  Expires: 30 August 2026                                 26 February 2026


    Enhancing Security in EAP-AKA' with Hybrid Post-Quantum Cryptography
                    draft-ietf-emu-hybrid-pqc-eapaka-01

  Abstract

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

     This draft aims to enhance the security of EAP-AKA' FS protocol by
     leveraging PQ/T Hybrid [I-D.ietf-pquip-pqt-hybrid-terminology]
     algorithms to make it quantum-safe.

  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-ietf-emu-hybrid-pqc-eapaka/.

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

  Status of This Memo

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

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



  Banerjee & Reddy         Expires 30 August 2026                 [Page 1]


  Internet-Draft         PQC Hybrid in EAP-AKA prime         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 30 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 pu

  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 for EAP-AKA'",
      "description": "Replaces traditional ECDHE with hybrid post-quantum/traditional cryptographic algorithms in EAP-AKA' FS to provide quantum-resistant ephemeral key exchange. This mechanism combines classical and post-quantum cryptographic primitives for forward secrecy.",
      "type": "mechanism"
    },
    {
      "title": "Quantum-Safe EAP-AKA' Extension",
      "description": "An extension to the existing EAP-AKA' FS protocol that integrates post-quantum cryptography to protect against future quantum computer attacks. This builds upon RFC9678 by adding quantum-resistant key agreement capabilities.",
      "type": "extension"
    },
    {
      "title": "Hybrid Ephemeral Key Protection",
      "description": "Protects session keys in EAP-AKA' authentication runs against compromise scenarios where adversaries obtain both long-term keys and ephemeral public keys. Uses hybrid algorithms to ensure security even if traditional cryptographic components are broken.",
      "type": "mechanism"
    },
    {
      "title": "Post-Quantum Forward Secrecy Requirements",
      "description": "Defines security requirements for maintaining perfect forward secrecy in EAP-AKA' against cryptographically relevant quantum computers. Addresses the threat model where quantum attacks could compromise traditional ephemeral key exchanges.",
      "type": "requirement"
    }
  ]


draft_name: draft-ietf-emu-pqc-eapaka
prompt_hash: cecbd0d86e9f5eae
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:45:50.885821+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-emu-pqc-eapaka | Post-Quantum Key Encapsulation Mechanisms (PQ KEMs) in EAP-AKA prime | 20pg
  Abstract: Forward Secrecy for the Extensible Authentication Protocol Method for
     Authentication and Key Agreement (EAP-AKA' FS) is specified in
     [RFC9678], providing updates to [RFC9048] with an optional extension
     that offers ephemeral key exchange using the traditional Ephemeral
     Elliptic Curve Diffie-Hellman (ECDHE) key agreement algorithm for
     achieving perfect forward secrecy (PFS).  However, it is susceptible
     to future threats from Cryptographically Relevant Quantum Computers,
     which could potentially compromise a traditional ephemeral public
     key.  If the adversary has also obtained knowledge of the long-term
     key and ephemeral public key, it could compromise session keys
     generated as part of the authentication run in EAP-AKA'.

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





  EMU                                                             T. Reddy
  Internet-Draft                                               A. Banerjee
  Intended status: Standards Track                                   Nokia
  Expires: 30 August 2026                                 26 February 2026


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

  Abstract

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

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

  About This Document

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

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

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

  Status of This Memo

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

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



  Reddy & Banerjee         Expires 30 August 2026                 [Page 1]


  Internet-Draft          PQ KEMs in EAP-AKA prime           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 30 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.

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

response_json:
  [
    {
      "title": "PQ-KEM Integration in EAP-AKA'",
      "description": "Replaces traditional ECDHE key exchange with Post-Quantum Key Encapsulation Mechanisms to provide quantum-safe forward secrecy. This maintains the existing EAP-AKA' FS protocol structure while upgrading the cryptographic primitives.",
      "type": "mechanism"
    },
    {
      "title": "Quantum-Safe Session Key Generation",
      "description": "Modifies the key derivation process in EAP-AKA' to incorporate PQ-KEM shared secrets alongside existing authentication materials. Ensures session keys remain secure against quantum adversaries who may compromise long-term keys.",
      "type": "mechanism"
    },
    {
      "title": "Backward Compatible PQ Extension",
      "description": "Provides an optional extension mechanism that allows EAP-AKA' implementations to negotiate and use PQ-KEMs while maintaining compatibility with existing deployments. Enables gradual migration to quantum-safe cryptography.",
      "type": "extension"
    },
    {
      "title": "Hybrid Classical-PQ Key Exchange",
      "description": "Combines traditional elliptic curve operations with post-quantum key encapsulation to provide security against both classical and quantum attacks. Ensures no reduction in security during the transition period.",
      "type": "pattern"
    },
    {
      "title": "PQ-KEM Algorithm Negotiation",
      "description": "Defines a mechanism for EAP-AKA' peers and servers to negotiate which PQ-KEM algorithms to use during the authentication exchange. Supports multiple post-quantum algorithms for flexibility and future-proofing.",
      "type": "protocol"
    }
  ]


draft_name: draft-ietf-hpke-hpke
prompt_hash: 0bd2a3925021dc12
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:45:56.905724+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-hpke-hpke | Hybrid Public Key Encryption | 85pg
  Abstract: This document describes a scheme for hybrid public key encryption
     (HPKE).  This scheme provides a variant of public key encryption of
     arbitrary-sized plaintexts for a recipient public key.  It also
     includes a variant that authenticates possession of a pre-shared key.
     HPKE works for any combination of an asymmetric KEM, key derivation
     function (KDF), and authenticated encryption with additional data
     (AEAD) encryption function.  We provide instantiations of the scheme
     using widely used and efficient primitives, such as Elliptic Curve
     Diffie-Hellman (ECDH) key agreement, HMAC-based key derivation
     function (HKDF), and SHA2.





  HPKE                                                           R. Barnes
  Internet-Draft                                                     Cisco
  Obsoletes: 9180 (if approved)                               K. Bhargavan
  Intended status: Standards Track                                 B. Lipp
  Expires: 8 May 2026                                                Inria
                                                                   C. Wood
                                                           4 November 2025


                        Hybrid Public Key Encryption
                          draft-ietf-hpke-hpke-02

  Abstract

     This document describes a scheme for hybrid public key encryption
     (HPKE).  This scheme provides a variant of public key encryption of
     arbitrary-sized plaintexts for a recipient public key.  It also
     includes a variant that authenticates possession of a pre-shared key.
     HPKE works for any combination of an asymmetric KEM, key derivation
     function (KDF), and authenticated encryption with additional data
     (AEAD) encryption function.  We provide instantiations of the scheme
     using widely used and efficient primitives, such as Elliptic Curve
     Diffie-Hellman (ECDH) key agreement, HMAC-based key derivation
     function (HKDF), and SHA2.

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

  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.



  Barnes, et al.             Expires 8 May 2026                   [Page 1]


  Internet-Draft                    HPKE                     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 Revi

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

response_json:
  [
    {
      "title": "HPKE Core Scheme",
      "description": "Hybrid public key encryption combining asymmetric KEM, KDF, and AEAD for encrypting arbitrary-sized plaintexts. Works with any combination of these three cryptographic primitives.",
      "type": "protocol"
    },
    {
      "title": "Pre-Shared Key Authentication",
      "description": "Variant of HPKE that authenticates possession of a pre-shared key in addition to public key encryption. Provides additional authentication layer beyond standard public key cryptography.",
      "type": "mechanism"
    },
    {
      "title": "Modular Primitive Architecture",
      "description": "Architecture allowing any combination of asymmetric KEM, KDF, and AEAD functions to be plugged into HPKE. Enables flexibility in choosing cryptographic primitives based on requirements.",
      "type": "architecture"
    },
    {
      "title": "ECDH-HKDF-SHA2 Instantiation",
      "description": "Concrete implementation of HPKE using Elliptic Curve Diffie-Hellman key agreement, HMAC-based key derivation, and SHA2. Provides a widely-used and efficient instantiation of the general scheme.",
      "type": "mechanism"
    }
  ]


draft_name: draft-ietf-httpbis-layered-cookies
prompt_hash: 9719baa9370dec2d
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:46:03.587275+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-httpbis-layered-cookies | Cookies: HTTP State Management Mechanism | 46pg
  Abstract: This document defines the HTTP Cookie and Set-Cookie header fields.
     These header fields can be used by HTTP servers to store state
     (called cookies) at HTTP user agents, letting the servers maintain a
     stateful session over the mostly stateless HTTP protocol.  Although
     cookies have many historical infelicities that degrade their security
     and privacy, the Cookie and Set-Cookie header fields are widely used
     on the Internet.  This document obsoletes RFC 6265 and 6265bis.





  HTTP                                                A. van Kesteren, Ed.
  Internet-Draft                                                     Apple
  Obsoletes: [6265] (if approved)                          J. Hofmann, Ed.
  Intended status: Standards Track                                  Google
  Expires: 22 May 2026                                    18 November 2025


                  Cookies: HTTP State Management Mechanism
                   draft-ietf-httpbis-layered-cookies-01

  Abstract

     This document defines the HTTP Cookie and Set-Cookie header fields.
     These header fields can be used by HTTP servers to store state
     (called cookies) at HTTP user agents, letting the servers maintain a
     stateful session over the mostly stateless HTTP protocol.  Although
     cookies have many historical infelicities that degrade their security
     and privacy, the Cookie and Set-Cookie header fields are widely used
     on the Internet.  This document obsoletes RFC 6265 and 6265bis.

  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-ietf-httpbis-layered-cookies/.

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

     Source for this draft and an issue tracker can be found at
     https://github.com/httpwg/http-extensions/labels/cookies.

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







  van Kesteren & Hofmann     Expires 22 May 2026                  [Page 1]


  Internet-Draft                   Cookies                   November 2025


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

     This Internet-Draft will expire on 22 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

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

response_json:
  [
    {
      "title": "Set-Cookie Header Field",
      "description": "HTTP response header field that allows servers to send state information to user agents for storage and subsequent transmission back to the server. Enables stateful sessions over the stateless HTTP protocol.",
      "type": "protocol"
    },
    {
      "title": "Cookie Header Field", 
      "description": "HTTP request header field that user agents use to transmit stored cookie data back to servers. Provides the mechanism for clients to include server-provided state in subsequent requests.",
      "type": "protocol"
    },
    {
      "title": "HTTP State Management",
      "description": "Architectural pattern enabling servers to maintain stateful sessions by storing data at the client and having it transmitted back in subsequent requests. Overcomes the inherent statelessness of HTTP.",
      "type": "architecture"
    },
    {
      "title": "Layered Cookies Model",
      "description": "Updated approach to cookie specification that addresses historical security and privacy issues while maintaining backward compatibility. Represents an evolution from RFC 6265.",
      "type": "mechanism"
    }
  ]


draft_name: draft-ietf-httpbis-rfc6265bis
prompt_hash: 1a6875dbc594640c
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:46:11.264342+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-httpbis-rfc6265bis | Cookies: HTTP State Management Mechanism | 62pg
  Abstract: This document defines the HTTP Cookie and Set-Cookie header fields.
     These header fields can be used by HTTP servers to store state
     (called cookies) at HTTP user agents, letting the servers maintain a
     stateful session over the mostly stateless HTTP protocol.  Although
     cookies have many historical flaws that degrade their security and
     privacy, the Cookie and Set-Cookie header fields are widely used on
     the Internet.  This document obsoletes RFC 6265.





  HTTP                                                     S. Bingler, Ed.
  Internet-Draft                                                          
  Obsoletes: 6265 (if approved)                               M. West, Ed.
  Intended status: Standards Track                              Google LLC
  Expires: 4 June 2026                                    J. Wilander, Ed.
                                                                Apple, Inc
                                                           1 December 2025


                  Cookies: HTTP State Management Mechanism
                      draft-ietf-httpbis-rfc6265bis-22

  Abstract

     This document defines the HTTP Cookie and Set-Cookie header fields.
     These header fields can be used by HTTP servers to store state
     (called cookies) at HTTP user agents, letting the servers maintain a
     stateful session over the mostly stateless HTTP protocol.  Although
     cookies have many historical flaws that degrade their security and
     privacy, the Cookie and Set-Cookie header fields are widely used on
     the Internet.  This document obsoletes RFC 6265.

  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-ietf-httpbis-rfc6265bis/.

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

     Source for this draft and an issue tracker can be found at
     https://github.com/httpwg/http-extensions/labels/6265bis.

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





  Bingler, et al.            Expires 4 June 2026                  [Page 1]


  Internet-Draft  Cookies: HTTP State Management Mechanism   December 2025


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

     This Internet-Draft will expire on 4 June 2026.

  Copyright Notice

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

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

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

response_json:
  [
    {
      "title": "Set-Cookie Header Field",
      "description": "HTTP response header field that allows servers to store state information (cookies) at user agents. Defines syntax and semantics for cookie attributes like expiration, domain, path, and security flags.",
      "type": "protocol"
    },
    {
      "title": "Cookie Header Field", 
      "description": "HTTP request header field that allows user agents to send stored cookie data back to servers. Enables stateful sessions over the stateless HTTP protocol.",
      "type": "protocol"
    },
    {
      "title": "Cookie Domain Matching",
      "description": "Algorithm for determining whether a cookie's domain attribute matches the current request's domain. Controls which domains can receive specific cookies for security isolation.",
      "type": "mechanism"
    },
    {
      "title": "Cookie Path Matching",
      "description": "Mechanism for restricting cookie delivery based on URL path prefixes. Allows servers to limit cookie scope to specific application paths or directories.",
      "type": "mechanism"
    },
    {
      "title": "Secure Cookie Attribute",
      "description": "Cookie attribute that restricts transmission to HTTPS connections only. Prevents cookie interception over unencrypted HTTP channels.",
      "type": "mechanism"
    },
    {
      "title": "HttpOnly Cookie Attribute",
      "description": "Cookie attribute that prevents client-side script access to cookies. Mitigates cross-site scripting (XSS) attacks by limiting cookie access to HTTP transactions only.",
      "type": "mechanism"
    }
  ]


draft_name: draft-ietf-lake-app-profiles
prompt_hash: ac16a7a7c5c21729
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:46:18.738550+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-lake-app-profiles | Coordinating the Use of Application Profiles for Ephemeral Diffie-Hellman Over COSE (EDHOC) | 48pg
  Abstract: The lightweight authenticated key exchange protocol Ephemeral Diffie-
     Hellman Over COSE (EDHOC) requires certain parameters to be agreed
     out-of-band, in order to ensure its successful completion.  To this
     end, application profiles specify the intended use of EDHOC to allow
     for the relevant processing and verifications to be made.  In order
     to ensure the applicability of such parameters and information beyond
     transport- or setup-specific scenarios, this document defines a
     canonical, CBOR-based representation that can be used to describe,
     distribute, and store EDHOC application profiles.  Furthermore, In
     order to facilitate interoperability between EDHOC implementations
     and support EDHOC extensibility for additional integrations, this
     document defines a number of means to coordinate the use of EDHOC
     application profiles.  Finally, this document defines a set of well-
     known EDHOC application profiles.





  LAKE Working Group                                             M. Tiloca
  Internet-Draft                                                R. Höglund
  Intended status: Standards Track                                 RISE AB
  Expires: 23 April 2026                                   20 October 2025


     Coordinating the Use of Application Profiles for Ephemeral Diffie-
                         Hellman Over COSE (EDHOC)
                      draft-ietf-lake-app-profiles-03

  Abstract

     The lightweight authenticated key exchange protocol Ephemeral Diffie-
     Hellman Over COSE (EDHOC) requires certain parameters to be agreed
     out-of-band, in order to ensure its successful completion.  To this
     end, application profiles specify the intended use of EDHOC to allow
     for the relevant processing and verifications to be made.  In order
     to ensure the applicability of such parameters and information beyond
     transport- or setup-specific scenarios, this document defines a
     canonical, CBOR-based representation that can be used to describe,
     distribute, and store EDHOC application profiles.  Furthermore, In
     order to facilitate interoperability between EDHOC implementations
     and support EDHOC extensibility for additional integrations, this
     document defines a number of means to coordinate the use of EDHOC
     application profiles.  Finally, this document defines a set of well-
     known EDHOC application profiles.

  Discussion Venues

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

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

     Source for this draft and an issue tracker can be found at
     https://github.com/lake-wg/app-profiles.

  Status of This Memo

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

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



  Tiloca & Höglund          Expires 23 April 2026                 [Page 1]


  Internet-Draft         EDHOC Application Profiles           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 th

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

response_json:
  [
    {
      "title": "CBOR-based Application Profile Representation",
      "description": "A canonical CBOR encoding format for describing EDHOC application profiles that can be distributed, stored, and processed independently of transport mechanisms. This provides a standardized way to represent profile parameters and configurations.",
      "type": "mechanism"
    },
    {
      "title": "Application Profile Coordination Framework",
      "description": "A set of mechanisms to coordinate the selection and use of EDHOC application profiles between implementations. This enables interoperability by providing standardized ways for peers to agree on which profile to use.",
      "type": "protocol"
    },
    {
      "title": "Well-known Application Profiles Registry",
      "description": "A defined set of standardized EDHOC application profiles for common use cases. These profiles specify pre-agreed parameter sets that can be referenced by implementations without custom negotiation.",
      "type": "architecture"
    },
    {
      "title": "Out-of-band Parameter Agreement Pattern",
      "description": "A pattern for establishing EDHOC parameters before protocol execution begins. This addresses the requirement that certain parameters must be agreed upon prior to running the key exchange protocol.",
      "type": "pattern"
    },
    {
      "title": "Profile Distribution and Storage Mechanism",
      "description": "Technical mechanisms for distributing and storing EDHOC application profiles across different deployment scenarios. This extends profile usability beyond single transport or setup contexts.",
      "type": "mechanism"
    }
  ]


draft_name: draft-ietf-lake-authz
prompt_hash: 6fb27de8fc8b6712
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:46:25.701075+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-lake-authz | Lightweight Authorization using Ephemeral Diffie-Hellman Over COSE (ELA) | 48pg
  Abstract: Ephemeral Diffie-Hellman Over COSE (EDHOC) is a lightweight
     authenticated key exchange protocol intended for use in constrained
     scenarios.  This document specifies Lightweight Authorization using
     EDHOC (ELA).  The procedure allows authorizing enrollment of new
     devices using the extension point defined in EDHOC.  ELA is
     applicable to zero-touch onboarding of new devices to a constrained
     network leveraging trust anchors installed at manufacture time.





  LAKE Working Group                                           G. Selander
  Internet-Draft                                         J. Preuß Mattsson
  Intended status: Standards Track                             Ericsson AB
  Expires: 23 April 2026                                        M. Vučinić
                                                            G. Fedrecheski
                                                                     INRIA
                                                             M. Richardson
                                                  Sandelman Software Works
                                                           20 October 2025


  Lightweight Authorization using Ephemeral Diffie-Hellman Over COSE (ELA)
                          draft-ietf-lake-authz-06

  Abstract

     Ephemeral Diffie-Hellman Over COSE (EDHOC) is a lightweight
     authenticated key exchange protocol intended for use in constrained
     scenarios.  This document specifies Lightweight Authorization using
     EDHOC (ELA).  The procedure allows authorizing enrollment of new
     devices using the extension point defined in EDHOC.  ELA is
     applicable to zero-touch onboarding of new devices to a constrained
     network leveraging trust anchors installed at manufacture time.

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

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

     Source for this draft and an issue tracker can be found at
     https://github.com/lake-wg/authz.

  Status of This Memo

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





  Selander, et al.          Expires 23 April 2026                 [Page 1]


  Internet-Draft                     ELA                      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

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

response_json:
  [
    {
      "title": "ELA Protocol",
      "description": "Lightweight Authorization using EDHOC that allows authorizing enrollment of new devices using EDHOC's extension points. Enables zero-touch onboarding to constrained networks using manufacture-time trust anchors.",
      "type": "protocol"
    },
    {
      "title": "EDHOC Extension Point Integration",
      "description": "Uses the extension point mechanism defined in EDHOC to embed authorization functionality. Allows authorization procedures to be carried out within the EDHOC key exchange flow.",
      "type": "mechanism"
    },
    {
      "title": "Zero-Touch Device Onboarding",
      "description": "Automated device enrollment process that requires no manual configuration. Leverages pre-installed trust anchors from manufacturing to establish device authorization.",
      "type": "pattern"
    },
    {
      "title": "Manufacture-Time Trust Anchors",
      "description": "Security credentials installed during device manufacturing that serve as the basis for later authorization. Enables devices to prove legitimacy without additional credential provisioning.",
      "type": "mechanism"
    },
    {
      "title": "Constrained Network Authorization",
      "description": "Authorization framework specifically designed for resource-limited networks and devices. Optimized for low power, low bandwidth, and limited computational capability environments.",
      "type": "architecture"
    }
  ]


draft_name: draft-ietf-lake-edhoc-impl-cons
prompt_hash: 5835f007b4ca1124
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:46:32.974296+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-lake-edhoc-impl-cons | Implementation Considerations for Ephemeral Diffie-Hellman Over COSE (EDHOC) | 43pg
  Abstract: This document provides considerations for guiding the implementation
     of the authenticated key exchange protocol Ephemeral Diffie-Hellman
     Over COSE (EDHOC).





  LAKE Working Group                                             M. Tiloca
  Internet-Draft                                                   RISE AB
  Intended status: Informational                            7 January 2026
  Expires: 11 July 2026


    Implementation Considerations for Ephemeral Diffie-Hellman Over COSE
                                  (EDHOC)
                     draft-ietf-lake-edhoc-impl-cons-05

  Abstract

     This document provides considerations for guiding the implementation
     of the authenticated key exchange protocol Ephemeral Diffie-Hellman
     Over COSE (EDHOC).

  Discussion Venues

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

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

     Source for this draft and an issue tracker can be found at
     https://github.com/lake-wg/edhoc-impl-cons.

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







  Tiloca                    Expires 11 July 2026                  [Page 1]


  Internet-Draft   Implementation Considerations for EDHOC    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  . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
     2.  Handling of Invalid EDHOC Sessions and Application Keys . . .   4
       2.1.  EDHOC Sessions Become Invalid . . . . . . . . . . . . . .   5
       2.2.  Application Keys Become Invalid . . . . . . . . . . . . .   5
       2.3.  Application Keys or Bound Access Rights Become Invalid

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

response_json:
  [
    {
      "title": "Invalid EDHOC Session Handling",
      "description": "Mechanism for detecting and responding when EDHOC authenticated key exchange sessions become invalid during or after completion. Includes procedures for session cleanup and state management.",
      "type": "mechanism"
    },
    {
      "title": "Application Key Invalidation Management",
      "description": "Protocol pattern for handling scenarios where cryptographic keys derived from EDHOC sessions become compromised or expired. Defines key lifecycle and replacement procedures.",
      "type": "pattern"
    },
    {
      "title": "Bound Access Rights Invalidation",
      "description": "Architecture for managing access control permissions that are cryptographically bound to EDHOC-derived keys. Handles revocation and re-authorization scenarios.",
      "type": "architecture"
    },
    {
      "title": "EDHOC State Cleanup Requirements",
      "description": "Implementation requirements for properly disposing of ephemeral cryptographic material and session state. Ensures security through proper memory management and state transitions.",
      "type": "requirement"
    }
  ]


draft_name: draft-ietf-lake-edhoc-psk
prompt_hash: 5e565ac7c5ffc0f5
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:46:41.677012+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-lake-edhoc-psk | EDHOC Authenticated with Pre-Shared Keys (PSK) | 31pg
  Abstract: This document specifies a Pre-Shared Key (PSK) authentication method
     for the Ephemeral Diffie-Hellman Over COSE (EDHOC) key exchange
     protocol.  The PSK method enhances computational efficiency while
     providing mutual authentication, ephemeral key exchange, identity
     protection, and quantum resistance.  It is particularly suited for
     systems where nodes share a PSK provided out-of-band (external PSK)
     and enables efficient session resumption with less computational
     overhead when the PSK is provided from a previous EDHOC session
     (resumption PSK).  This document details the PSK method flow, key
     derivation changes, message formatting, processing, and security
     considerations.





  LAKE Working Group                                        E. Lopez-Perez
  Internet-Draft                                                     Inria
  Intended status: Standards Track                             G. Selander
  Expires: 23 April 2026                                 J. Preuß Mattsson
                                                                  Ericsson
                                                            R. Marin-Lopez
                                                            F. Lopez-Gomez
                                                      University of Murcia
                                                           20 October 2025


               EDHOC Authenticated with Pre-Shared Keys (PSK)
                        draft-ietf-lake-edhoc-psk-06

  Abstract

     This document specifies a Pre-Shared Key (PSK) authentication method
     for the Ephemeral Diffie-Hellman Over COSE (EDHOC) key exchange
     protocol.  The PSK method enhances computational efficiency while
     providing mutual authentication, ephemeral key exchange, identity
     protection, and quantum resistance.  It is particularly suited for
     systems where nodes share a PSK provided out-of-band (external PSK)
     and enables efficient session resumption with less computational
     overhead when the PSK is provided from a previous EDHOC session
     (resumption PSK).  This document details the PSK method flow, key
     derivation changes, message formatting, processing, and security
     considerations.

  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://lake-
     wg.github.io/psk/#go.draft-ietf-lake-edhoc-psk.html.  Status
     information for this document may be found at
     https://datatracker.ietf.org/doc/draft-ietf-lake-edhoc-psk/.

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

     Source for this draft and an issue tracker can be found at
     https://github.com/lake-wg/psk.







  Lopez-Perez, et al.       Expires 23 April 2026                 [Page 1]


  Internet-Draft                  EDHOC-PSK                   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 or to cite them other than as "work in progress."

     This Intern

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

response_json:
  [
    {
      "title": "PSK Authentication Method for EDHOC",
      "description": "A Pre-Shared Key authentication method that replaces certificate-based authentication in EDHOC while maintaining mutual authentication and ephemeral key exchange. This method reduces computational overhead by eliminating public key signature operations.",
      "type": "mechanism"
    },
    {
      "title": "External PSK vs Resumption PSK",
      "description": "Two distinct PSK provisioning modes: external PSKs provided out-of-band for initial authentication, and resumption PSKs derived from previous EDHOC sessions for efficient session resumption. Each type has different key derivation and processing requirements.",
      "type": "pattern"
    },
    {
      "title": "Modified Key Derivation for PSK",
      "description": "Changes to EDHOC's key derivation function to incorporate PSK material into the key schedule. The PSK is mixed into the master secret derivation alongside the Diffie-Hellman shared secret.",
      "type": "mechanism"
    },
    {
      "title": "PSK Message Flow Modifications",
      "description": "Specific changes to EDHOC message formatting and processing to support PSK authentication, including PSK identity transmission and modified authentication tag computation. The three-message flow is preserved but with PSK-specific content.",
      "type": "protocol"
    },
    {
      "title": "Quantum Resistance Enhancement",
      "description": "The PSK method provides quantum resistance by combining pre-shared symmetric keys with ephemeral Diffie-Hellman exchange. Even if the DH exchange is compromised by quantum attacks, the PSK component maintains security.",
      "type": "requirement"
    }
  ]


draft_name: draft-ietf-lake-ra
prompt_hash: 57890169374c75f2
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:46:48.947565+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-lake-ra | Remote attestation over EDHOC | 30pg
  Abstract: This document specifies how to perform remote attestation as part of
     the lightweight authenticated Diffie-Hellman key exchange protocol
     EDHOC (Ephemeral Diffie-Hellman Over COSE), based on the Remote
     ATtestation procedureS (RATS) architecture.





  Lightweight Authenticated Key Exchange                           Y. Song
  Internet-Draft                                                     Inria
  Intended status: Standards Track                             G. Selander
  Expires: 23 April 2026                                       Ericsson AB
                                                           20 October 2025


                       Remote attestation over EDHOC
                           draft-ietf-lake-ra-03

  Abstract

     This document specifies how to perform remote attestation as part of
     the lightweight authenticated Diffie-Hellman key exchange protocol
     EDHOC (Ephemeral Diffie-Hellman Over COSE), based on the Remote
     ATtestation procedureS (RATS) architecture.

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

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

     Source for this draft and an issue tracker can be found at
     https://github.com/lake-wg/ra.

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







  Song & Selander           Expires 23 April 2026                 [Page 1]


  Internet-Draft                  RA-EDHOC                    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.  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 Conten

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

response_json:
  [
    {
      "title": "RATS-EDHOC Integration",
      "description": "Integration of Remote ATtestation procedureS (RATS) architecture into the EDHOC lightweight authenticated Diffie-Hellman key exchange protocol. This enables remote attestation to be performed as part of the key exchange process.",
      "type": "protocol"
    },
    {
      "title": "Attestation Evidence in EDHOC Messages",
      "description": "Mechanism to embed attestation evidence within EDHOC protocol messages during the key exchange handshake. This allows verification of device trustworthiness during authentication.",
      "type": "mechanism"
    },
    {
      "title": "Lightweight Remote Attestation",
      "description": "Design pattern for performing remote attestation in resource-constrained environments by leveraging the existing EDHOC protocol structure. This avoids the overhead of separate attestation protocols.",
      "type": "pattern"
    },
    {
      "title": "COSE-based Attestation Format",
      "description": "Use of CBOR Object Signing and Encryption (COSE) format for encoding attestation evidence within EDHOC. This provides a compact and standardized way to represent attestation data.",
      "type": "mechanism"
    },
    {
      "title": "Attested Key Exchange",
      "description": "Architecture where the Diffie-Hellman key exchange is combined with attestation verification in a single protocol flow. This ensures both authentication and device trustworthiness establishment simultaneously.",
      "type": "architecture"
    }
  ]


draft_name: draft-ietf-lamps-attestation-freshness
prompt_hash: 4b458de243bdaaec
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:46:56.833844+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-lamps-attestation-freshness | Nonce-based Freshness for Remote Attestation in Certificate Signing Requests (CSRs) for the Certification Management Protocol (CMP), for Enrollment over Secure Transport (EST), and for Certificate Management over CMS (CMC) | 20pg
  Abstract: When an end entity includes attestation Evidence in a Certificate
     Signing Request (CSR), it may be necessary to demonstrate the
     freshness of the provided Evidence.  Current attestation technology
     commonly achieves this using nonces.

     This document outlines the process through which nonces are supplied
     to the end entity by an RA/CA for inclusion in Evidence, leveraging
     the Certificate Management Protocol (CMP), Enrollment over Secure
     Transport (EST), and Certificate Management over CMS (CMC).





  LAMPS Working Group                                        H. Tschofenig
  Internet-Draft                                              H. Brockhaus
  Intended status: Standards Track                                 Siemens
  Expires: 22 April 2026                                         J. Mandel
                                                                    AKAYLA
                                                                 S. Turner
                                                                     sn3rd
                                                           19 October 2025


    Nonce-based Freshness for Remote Attestation in Certificate Signing
    Requests (CSRs) for the Certification Management Protocol (CMP), for
   Enrollment over Secure Transport (EST), and for Certificate Management
                               over CMS (CMC)
                 draft-ietf-lamps-attestation-freshness-05

  Abstract

     When an end entity includes attestation Evidence in a Certificate
     Signing Request (CSR), it may be necessary to demonstrate the
     freshness of the provided Evidence.  Current attestation technology
     commonly achieves this using nonces.

     This document outlines the process through which nonces are supplied
     to the end entity by an RA/CA for inclusion in Evidence, leveraging
     the Certificate Management Protocol (CMP), Enrollment over Secure
     Transport (EST), and Certificate Management over CMS (CMC).

  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.







  Tschofenig, et al.        Expires 22 April 2026                 [Page 1]


  Internet-Draft   Freshness Nonces for Remote Attestation    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.

  T

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

response_json:
  [
    {
      "title": "Nonce-Based Evidence Freshness",
      "description": "A mechanism where RA/CA provides nonces to end entities for inclusion in attestation Evidence to demonstrate freshness. The nonce is supplied before CSR submission and included in the attestation Evidence.",
      "type": "mechanism"
    },
    {
      "title": "CMP Nonce Distribution Extension",
      "description": "Extension to Certificate Management Protocol (CMP) to enable nonce delivery from RA/CA to end entities for attestation freshness. Allows CMP to support attestation Evidence validation workflows.",
      "type": "extension"
    },
    {
      "title": "EST Nonce Distribution Extension", 
      "description": "Extension to Enrollment over Secure Transport (EST) protocol to provide nonces for attestation Evidence freshness. Enables EST to support remote attestation scenarios in certificate enrollment.",
      "type": "extension"
    },
    {
      "title": "CMC Nonce Distribution Extension",
      "description": "Extension to Certificate Management over CMS (CMC) to deliver freshness nonces for attestation Evidence. Integrates nonce-based attestation freshness into CMC certificate management workflows.",
      "type": "extension"
    },
    {
      "title": "Attestation Evidence CSR Integration",
      "description": "Pattern for embedding attestation Evidence containing freshness nonces within Certificate Signing Requests. Links remote attestation validation to certificate issuance processes.",
      "type": "pattern"
    }
  ]


draft_name: draft-ietf-lamps-e2e-mail-guidance
prompt_hash: 401040955552e363
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:47:04.101275+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-lamps-e2e-mail-guidance | Guidance on End-to-End E-mail Security | 68pg
  Abstract: End-to-end cryptographic protections for e-mail messages can provide
     useful security.  However, the standards for providing cryptographic
     protection are extremely flexible.  That flexibility can trap users
     and cause surprising failures.  This document offers guidance for
     mail user agent implementers to help mitigate those risks, and to
     make end-to-end e-mail simple and secure for the end user.  It
     provides a useful set of vocabulary as well as recommendations to
     avoid common failures.  It also identifies a number of currently
     unsolved usability and interoperability problems.





  lamps                                                 D. K. Gillmor, Ed.
  Internet-Draft                                                      ACLU
  Intended status: Informational                         B. Hoeneisen, Ed.
  Expires: 12 July 2025                                        pEp Project
                                                          A. Melnikov, Ed.
                                                                 Isode Ltd
                                                            8 January 2025


                   Guidance on End-to-End E-mail Security
                   draft-ietf-lamps-e2e-mail-guidance-17

  Abstract

     End-to-end cryptographic protections for e-mail messages can provide
     useful security.  However, the standards for providing cryptographic
     protection are extremely flexible.  That flexibility can trap users
     and cause surprising failures.  This document offers guidance for
     mail user agent implementers to help mitigate those risks, and to
     make end-to-end e-mail simple and secure for the end user.  It
     provides a useful set of vocabulary as well as recommendations to
     avoid common failures.  It also identifies a number of currently
     unsolved usability and interoperability problems.

  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://dkg.gitlab.io/e2e-mail-guidance/.  Status information for
     this document may be found at https://datatracker.ietf.org/doc/draft-
     ietf-lamps-e2e-mail-guidance/.

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

     Source for this draft and an issue tracker can be found at
     https://gitlab.com/dkg/e2e-mail-guidance.

  Status of This Memo

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






  Gillmor, et al.           Expires 12 July 2025                  [Page 1]


  Internet-Draft   Guidance on End-to-End E-mail Security     January 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 12 July 2025.

  Copyright Notice

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

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions R

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

response_json:
  [
    {
      "title": "Cryptographic Protection Flexibility Management",
      "description": "A mechanism to manage the extreme flexibility in cryptographic protection standards that can trap users and cause surprising failures. Provides structured approach to handle implementation choices without compromising security.",
      "type": "mechanism"
    },
    {
      "title": "End-to-End Email Security Vocabulary",
      "description": "A standardized set of terminology and vocabulary definitions for end-to-end email security implementations. Helps ensure consistent understanding across different mail user agent implementations.",
      "type": "pattern"
    },
    {
      "title": "Mail User Agent Implementation Guidance",
      "description": "Specific recommendations and guidance for mail user agent implementers to mitigate security risks in end-to-end email encryption. Focuses on making implementation decisions that improve user experience while maintaining security.",
      "type": "requirement"
    },
    {
      "title": "Common Failure Avoidance Recommendations",
      "description": "A set of specific recommendations designed to help implementers avoid common pitfalls and failures in end-to-end email security. Addresses known failure modes in cryptographic email implementations.",
      "type": "pattern"
    },
    {
      "title": "Usability and Interoperability Problem Identification",
      "description": "Systematic identification and cataloging of currently unsolved usability and interoperability problems in end-to-end email security. Provides framework for addressing known limitations.",
      "type": "requirement"
    }
  ]


draft_name: draft-ietf-lamps-est-renewal-info
prompt_hash: dd654715ddf3e266
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:47:11.372162+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-lamps-est-renewal-info | Certificate Renewal Recommendations for Enrollment over Secure Transport | 7pg
  Abstract: This document describes an extension to RFC7030, Enrollment over
     Secure Transport to give an indication to a end-entity device when it
     should start attempting to renew its certificates.

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





  LAMPS Working Group                                       R. Shekh-Yusef
  Internet-Draft                                                     Ciena
  Intended status: Standards Track                           M. Richardson
  Expires: 16 August 2026                         Sandelman Software Works
                                                              M. Ounsworth
                                                           Entrust Limited
                                                          12 February 2026


  Certificate Renewal Recommendations for Enrollment over Secure Transport
                    draft-ietf-lamps-est-renewal-info-00

  Abstract

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

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

  About This Document

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

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

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

     Source for this draft and an issue tracker can be found at
     https://github.com/lamps-wg/lamps-est-renewal-info.

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



  Shekh-Yusef, et al.      Expires 16 August 2026                 [Page 1]


  Internet-Draft                  est-renew                  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 16 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 car

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

response_json:
  [
    {
      "title": "EST Renewal Info Extension",
      "description": "An extension to RFC 7030 Enrollment over Secure Transport that allows EST servers to provide specific renewal timing recommendations to end-entity devices. This replaces the traditional client-decided 50% certificate lifetime renewal approach with server-provided guidance.",
      "type": "extension"
    },
    {
      "title": "Server-Directed Renewal Timing",
      "description": "A mechanism where the EST server provides explicit timing advice to clients about when to initiate certificate renewal requests. This addresses the problem where the traditional 50% lifetime rule becomes inappropriate for certificates with very short lifetimes.",
      "type": "mechanism"
    },
    {
      "title": "Short-Lifetime Certificate Renewal Optimization",
      "description": "A pattern specifically designed to handle certificate renewal for certificates with lifetimes measured in fractions of a year rather than years. The approach optimizes renewal timing to avoid premature renewal attempts that waste resources.",
      "type": "pattern"
    },
    {
      "title": "Dynamic Renewal Schedule Provision",
      "description": "An architecture component that enables EST servers to dynamically communicate optimal renewal schedules to clients based on certificate policies and operational considerations. This moves renewal timing decisions from static client-side rules to dynamic server-side recommendations.",
      "type": "architecture"
    }
  ]


draft_name: draft-ietf-lamps-private-key-stmt-attr
prompt_hash: 524f574920111cd8
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:47:17.414961+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-lamps-private-key-stmt-attr | An Attribute for Statement of Possession of a Private Key | 19pg
  Abstract: This document specifies an attribute for a statement of possession of
     a private key by a certificate subject.  As part of X.509 certificate
     enrollment, a Certification Authority (CA) typically demands proof
     that the subject possesses the private key that corresponds to the
     to-be-certified public key.  In some cases, a CA might accept a
     signed statement from the certificate subject.  For example, when a
     certificate subject needs separate certificates for signature and key
     establishment, a statement that can be validated with the previously
     issued signature certificate for the same subject might be adequate
     for subsequent issuance of the key establishment certificate.





  Network Working Group                                         R. Housley
  Internet-Draft                                            Vigil Security
  Intended status: Standards Track                            26 June 2025
  Expires: 28 December 2025


         An Attribute for Statement of Possession of a Private Key
                 draft-ietf-lamps-private-key-stmt-attr-09

  Abstract

     This document specifies an attribute for a statement of possession of
     a private key by a certificate subject.  As part of X.509 certificate
     enrollment, a Certification Authority (CA) typically demands proof
     that the subject possesses the private key that corresponds to the
     to-be-certified public key.  In some cases, a CA might accept a
     signed statement from the certificate subject.  For example, when a
     certificate subject needs separate certificates for signature and key
     establishment, a statement that can be validated with the previously
     issued signature certificate for the same subject might be adequate
     for subsequent issuance of the key establishment certificate.

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



  Housley                 Expires 28 December 2025                [Page 1]


  Internet-Draft     Statement of Private Key Possession         June 2025


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

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
       1.1.  ASN.1 . . . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
     2.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.  Attribute for Statement of Pos

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

response_json:
  [
    {
      "title": "Private Key Possession Statement Attribute",
      "description": "An X.509 certificate attribute that allows a certificate subject to make a signed statement claiming possession of a private key. This provides an alternative to traditional proof-of-possession mechanisms during certificate enrollment.",
      "type": "mechanism"
    },
    {
      "title": "Cross-Certificate Validation Pattern",
      "description": "A mechanism where a CA can validate a private key possession statement using a previously issued signature certificate for the same subject. This enables efficient issuance of additional certificates like key establishment certificates.",
      "type": "pattern"
    },
    {
      "title": "Statement-Based Proof of Possession",
      "description": "An alternative proof-of-possession method where CAs accept signed statements from certificate subjects instead of requiring direct cryptographic proof. This simplifies certain certificate enrollment scenarios.",
      "type": "protocol"
    },
    {
      "title": "Separate Certificate Use Case Support",
      "description": "Support for certificate subjects that need distinct certificates for different purposes (signature vs key establishment). The statement attribute facilitates obtaining multiple certificates for the same entity.",
      "type": "requirement"
    }
  ]


draft_name: draft-ietf-lamps-rfc5274bis
prompt_hash: 8b3eb69c6510eb3a
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:47:23.865712+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-lamps-rfc5274bis | Certificate Management Messages over CMS (CMC): Compliance Requirements | 14pg
  Abstract: This document provides a set of compliance statements about the CMC
     (Certificate Management over CMS) enrollment protocol.  The ASN.1
     structures and the transport mechanisms for the CMC enrollment
     protocol are covered in other documents.  This document provides the
     information needed to make a compliant version of CMC.

     This document obsoletes RFC 5274 and RFC 6402.





  LAMPS Working Group                                        J. Mandel, Ed
  Internet-Draft                                              AKAYLA, Inc.
  Obsoletes: 5274, 6402 (if approved)                        S. Turner, Ed
  Intended status: Standards Track                                   sn3rd
  Expires: 30 August 2026                                 26 February 2026


  Certificate Management Messages over CMS (CMC): Compliance Requirements
                       draft-ietf-lamps-rfc5274bis-11

  Abstract

     This document provides a set of compliance statements about the CMC
     (Certificate Management over CMS) enrollment protocol.  The ASN.1
     structures and the transport mechanisms for the CMC enrollment
     protocol are covered in other documents.  This document provides the
     information needed to make a compliant version of CMC.

     This document obsoletes RFC 5274 and RFC 6402.

  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-ietf-lamps-rfc5274bis/.

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

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

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







  Mandel, Ed & Turner, Ed  Expires 30 August 2026                 [Page 1]


  Internet-Draft               CMC: Compliance               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 30 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.

     This docu

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

response_json:
  [
    {
      "title": "CMC Compliance Requirements",
      "description": "Defines mandatory compliance statements and requirements for implementing the Certificate Management over CMS (CMC) enrollment protocol. Specifies what components and behaviors are required for a compliant CMC implementation.",
      "type": "requirement"
    },
    {
      "title": "CMC Enrollment Protocol",
      "description": "Certificate management protocol that operates over Cryptographic Message Syntax (CMS) for handling certificate enrollment operations. Provides a standardized approach for certificate requests and responses using CMS structures.",
      "type": "protocol"
    },
    {
      "title": "CMS-based Certificate Management",
      "description": "Architecture that leverages Cryptographic Message Syntax as the foundation for certificate management operations. Separates ASN.1 structures and transport mechanisms from compliance requirements.",
      "type": "architecture"
    },
    {
      "title": "RFC 5274 and RFC 6402 Obsolescence",
      "description": "Updates and consolidates previous CMC compliance specifications by obsoleting RFC 5274 and RFC 6402. Provides modernized compliance requirements in a single document.",
      "type": "extension"
    }
  ]


draft_name: draft-ietf-lamps-rfc7030-csrattrs
prompt_hash: 15d0aeb6a7009593
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:47:30.318252+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-lamps-rfc7030-csrattrs | Clarification and enhancement of RFC7030 CSR Attributes definition | 25pg
  Abstract: This document updates RFC7030, Enrollment over Secure Transport
     (EST), clarifying how the Certificate Signiing Request (CSR)
     Attributes Response can be used by an EST server to specify both CSR
     attribute Object IDs (OID) and also CSR attribute values, in
     particular X.509 extension values, that the server expects the client
     to include in subsequent CSR request.  RFC9148 is derived from
     RFC7030, and it is also updated.

     RFC7030 (EST) is ambiguous in its specification of the CSR Attributes
     Response.  This has resulted in implementation challenges and
     implementor confusion.  As a result, there was not universal
     understanding of what was specified.  This document clarifies the
     encoding rules.

     This document therefore also provides a new straightforward approach:
     using a template for CSR contents that may be partially filled in by
     the server.  This also allows an EST server to specify a subject
     Distinguished Name (DN).





  LAMPS Working Group                                   M. Richardson, Ed.
  Internet-Draft                                  Sandelman Software Works
  Updates: 70309148 (if approved)                                 O. Friel
  Intended status: Standards Track                                   Cisco
  Expires: 30 December 2025                                  D. von Oheimb
                                                                   Siemens
                                                                D. Harkins
                                                     The Industrial Lounge
                                                              28 June 2025


     Clarification and enhancement of RFC7030 CSR Attributes definition
                    draft-ietf-lamps-rfc7030-csrattrs-23

  Abstract

     This document updates RFC7030, Enrollment over Secure Transport
     (EST), clarifying how the Certificate Signiing Request (CSR)
     Attributes Response can be used by an EST server to specify both CSR
     attribute Object IDs (OID) and also CSR attribute values, in
     particular X.509 extension values, that the server expects the client
     to include in subsequent CSR request.  RFC9148 is derived from
     RFC7030, and it is also updated.

     RFC7030 (EST) is ambiguous in its specification of the CSR Attributes
     Response.  This has resulted in implementation challenges and
     implementor confusion.  As a result, there was not universal
     understanding of what was specified.  This document clarifies the
     encoding rules.

     This document therefore also provides a new straightforward approach:
     using a template for CSR contents that may be partially filled in by
     the server.  This also allows an EST server to specify a subject
     Distinguished Name (DN).

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







  Richardson, et al.      Expires 30 December 2025                [Page 1]


  Internet-Draft                  CSRAttrs                       June 2025


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

     This Internet-Draft will expire on 30 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 r

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

response_json:
  [
    {
      "title": "CSR Attributes Response Clarification",
      "description": "Clarifies the ambiguous encoding rules in RFC7030 for how EST servers specify CSR attribute Object IDs (OIDs) and attribute values including X.509 extensions. Resolves implementation challenges caused by unclear specification.",
      "type": "mechanism"
    },
    {
      "title": "CSR Template Approach",
      "description": "Introduces a new straightforward method using templates for CSR contents that can be partially pre-filled by the EST server. Provides an alternative to the original ambiguous CSR attributes specification.",
      "type": "mechanism"
    },
    {
      "title": "Server-Specified Subject DN",
      "description": "Enables EST servers to specify the subject Distinguished Name (DN) that clients should use in their certificate signing requests. Extends server control over certificate content beyond just extensions and attributes.",
      "type": "extension"
    },
    {
      "title": "Enhanced CSR Attribute Value Specification",
      "description": "Allows EST servers to specify not just CSR attribute OIDs but also the actual attribute values, particularly for X.509 extension values. Provides more granular control over expected CSR content.",
      "type": "mechanism"
    }
  ]


draft_name: draft-ietf-lisp-nexagon
prompt_hash: cb225712be3418ba
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:47:37.177636+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-lisp-nexagon | Geo-Intelligence Network Based On H3 and LISP | 21pg
  Abstract: Lisp-Nexagon is a geospatial intelligence network protocol designed
  to support physical-world applications such as transportation, public
  safety, and logistics. It combines the Locator/ID Separation Protocol
  (LISP) with the H3 spatial indexing system to enable distributed
  agents to report, aggregate, and disseminate geospatial state
  information.

  LISP Working Group                                           S. Barkai
  Internet-Draft                                               Oterra.ai
  Intended status: Informational                       B. Fernandez-Ruiz
  Expires: March 24, 2026                                    Nexar Inc.
                                                                R. Tamir
                                                                Ariga.io
                                                      A. Rodriguez-Natal
                                                                F. Maino
                                                           Cisco Systems
                                                    A. Cabellos-Aparicio
                                                   J. Paillisse-Vilanova
                                    Universitat Politecnica de Catalunya
                                                            D. Farinacci
                                                             lispers.net
                             September 24, 2025


               Geo-Intelligence Network Based On H3 and LISP
                        draft-ietf-lisp-nexagon-57.txt


  Abstract

  Lisp-Nexagon is a geospatial intelligence network protocol designed 
  to support physical-world applications such as transportation, public
  safety, and logistics. It combines the Locator/ID Separation Protocol
  (LISP) with the H3 spatial indexing system to enable distributed 
  agents to report, aggregate, and disseminate geospatial state 
  information.






  Barkai, et al.          Expires March 24, 2026             [Page 1]



  Internet-Draft                     LISP              September 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 or to cite them other than as "work in progress."
   This Internet-Draft will expire on October 1,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 Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in

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

response_json:
  [
    {
      "title": "LISP-H3 Integration",
      "description": "Combines LISP's Locator/ID Separation Protocol with H3 spatial indexing system for geospatial routing. Uses H3 hexagonal cell identifiers as LISP Endpoint Identifiers (EIDs) to enable location-based network addressing.",
      "type": "architecture"
    },
    {
      "title": "Geospatial State Aggregation",
      "description": "Mechanism for distributed agents to collect, aggregate, and disseminate location-based state information across the network. Enables real-time sharing of geospatial intelligence between network nodes.",
      "type": "mechanism"
    },
    {
      "title": "H3-based EID Addressing",
      "description": "Uses H3 hexagonal spatial index values as LISP Endpoint Identifiers to create location-aware network addresses. Provides hierarchical geographic addressing that scales from global to local resolution levels.",
      "type": "protocol"
    },
    {
      "title": "Physical-World Application Support",
      "description": "Protocol designed specifically for transportation, public safety, and logistics use cases requiring geospatial intelligence. Bridges network protocols with real-world geographic positioning and state tracking.",
      "type": "requirement"
    }
  ]


draft_name: draft-ietf-mailmaint-pacc
prompt_hash: b93991827c9e0e19
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:47:43.730450+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-mailmaint-pacc | Automatic Configuration of Email, Calendar, and Contact Server Settings | 38pg
  Abstract: This document specifies an automatic configuration mechanism for
     email, calendar, and contact user agent applications.  Service
     providers publish standardized configuration information that user
     agent applications retrieve and use to simplify server setup
     procedures.





  mailmaint                                                      D. Eggert
  Internet-Draft                                                 Apple Inc
  Intended status: Standards Track                              B. Bucksch
  Expires: 31 August 2026                                           Beonex
                                                              M. Diephouse
                                                                 Apple Inc
                                                          27 February 2026


  Automatic Configuration of Email, Calendar, and Contact Server Settings
                        draft-ietf-mailmaint-pacc-02

  Abstract

     This document specifies an automatic configuration mechanism for
     email, calendar, and contact user agent applications.  Service
     providers publish standardized configuration information that user
     agent applications retrieve and use to simplify server setup
     procedures.

  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.

  Copyright Notice

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










  Eggert, et al.           Expires 31 August 2026                 [Page 1]


  Internet-Draft    Auto-Config of Email Server Settings     February 2026


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

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.  Document Conventions  . . . . . . . . . . . . . . . . . . . .   3
     3.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
       3.1.  Server Requirements Summary . . . . . . . . . . . . . . .   5
       3.2.  Client Requirements Summary . . . . . . . . . . . . . . .   5
     4.  JSON Configuration  . . . . . . . . . . . . . . . . . . . . .   5
       4.1.  Example . . . . . . . . . . . .

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

response_json:
  [
    {
      "title": "PACC Discovery Mechanism",
      "description": "User agents discover configuration by querying well-known URIs at the email domain (/.well-known/pacc) to retrieve standardized server settings. This eliminates manual configuration by automatically locating service provider configuration data.",
      "type": "mechanism"
    },
    {
      "title": "JSON Configuration Schema",
      "description": "Standardized JSON format for publishing email, calendar, and contact server configuration including hostnames, ports, security settings, and authentication methods. Provides machine-readable server setup parameters for automated client configuration.",
      "type": "protocol"
    },
    {
      "title": "Multi-Service Configuration",
      "description": "Single configuration endpoint supports email (IMAP/POP/SMTP), calendar (CalDAV), and contact (CardDAV) services simultaneously. Reduces discovery overhead by consolidating multiple service configurations into one request.",
      "type": "architecture"
    },
    {
      "title": "Well-Known URI Pattern",
      "description": "Uses RFC 8615 well-known URI mechanism (/.well-known/pacc) for predictable configuration location discovery. Enables clients to construct configuration URLs directly from email domain names.",
      "type": "pattern"
    },
    {
      "title": "Automatic Server Setup Procedure",
      "description": "Defines step-by-step client process for retrieving and applying configuration data to eliminate manual server parameter entry. Streamlines user onboarding by automating technical setup details.",
      "type": "mechanism"
    }
  ]


