# llm_cache

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


draft_name: draft-ietf-netconf-configuration-tracing
prompt_hash: b11754b1c4eb7e6f
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:47:51.106460+00:00
request_json:
Extract discrete technical ideas and mechanisms from 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-netconf-configuration-tracing | External Trace ID for Configuration Tracing | 19pg
Abstract: Network equipment are often configured by a variety of network
   management systems (NMS), protocols, and teams.  If a network issue
   arises (e.g., because of a wrong configuration change), it is
   important to quickly identify the root cause and obtain the reason
   for pushing that modification.  Another potential network issue can
   stem from concurrent NMSes with overlapping intents, each having
   their own tasks to perform.  In such a case, it is important to map
   the respective modifications to its originating NMS.

   This document specifies a NETCONF mechanism to automatically map the
   configuration modifications to their source, up to a specific NMS
   change request.  Such a mechanism is required, in particular, for
   autonomous networks to trace the source of a particular configuration
   change that led to an anomaly detection.  This mechanism facilitates
   the troubleshooting, the post-mortem analysis, and in the end the
   closed loop automation required for self-healing networks.  The
   specification also includes a YANG module that is meant to map a
   local configuration change to the corresponding trace id, up to the
   controller or even the orchestrator.





OPSAWG                                                       J. Quilbeuf
Internet-Draft                                                    Huawei
Intended status: Standards Track                               B. Claise
Expires: 7 May 2026                                       Everything OPS
                                                                 T. Graf
                                                                Swisscom
                                                                D. Lopez
                                                          Telefonica I+D
                                                                  Q. Sun
                                                           China Telecom
                                                         3 November 2025


              External Trace ID for Configuration Tracing
              draft-ietf-netconf-configuration-tracing-06

Abstract

   Network equipment are often configured by a variety of network
   management systems (NMS), protocols, and teams.  If a network issue
   arises (e.g., because of a wrong configuration change), it is
   important to quickly identify the root cause and obtain the reason
   for pushing that modification.  Another potential network issue can
   stem from concurrent NMSes with overlapping intents, each having
   their own tasks to perform.  In such a case, it is important to map
   the respective modifications to its originating NMS.

   This document specifies a NETCONF mechanism to automatically map the
   configuration modifications to their source, up to a specific NMS
   change request.  Such a mechanism is required, in particular, for
   autonomous networks to trace the source of a particular configuration
   change that led to an anomaly detection.  This mechanism facilitates
   the troubleshooting, the post-mortem analysis, and in the end the
   closed loop automation required for self-healing networks.  The
   specification also includes a YANG module that is meant to map a
   local configuration change to the corresponding trace id, up to the
   controller or even the orchestrator.

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/netconf-wg/configuration-tracing.







Quilbeuf, et al.           Expires 7 May 2026                   [Page 1]

Internet-Draft     Configuration Tracing via trace-id      November 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, o

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

response_json:
[
  {
    "title": "External Trace ID Extension",
    "description": "NETCONF capability extension that allows clients to include an external trace identifier in configuration requests. This trace ID propagates through the configuration change process to enable tracking back to the originating management system.",
    "type": "extension"
  },
  {
    "title": "Configuration Change Mapping Mechanism", 
    "description": "Automatic mapping system that links local configuration modifications to their external trace identifiers. Enables tracing configuration changes back to specific NMS change requests.",
    "type": "mechanism"
  },
  {
    "title": "Trace ID YANG Module",
    "description": "YANG data model that stores the mapping between local configuration changes and their corresponding external trace identifiers. Provides structured access to configuration tracing information up to controller/orchestrator level.",
    "type": "architecture"
  },
  {
    "title": "Multi-NMS Configuration Attribution",
    "description": "Pattern for distinguishing configuration changes from concurrent network management systems with overlapping intents. Maps respective modifications back to their originating NMS using trace identifiers.",
    "type": "pattern"
  },
  {
    "title": "Autonomous Network Tracing Requirement",
    "description": "Requirement for autonomous networks to automatically trace configuration changes that lead to anomaly detection. Supports closed-loop automation and self-healing network capabilities.",
    "type": "requirement"
  }
]


draft_name: draft-ietf-pim-zeroconf-mcast-addr-alloc-ps
prompt_hash: dac8a120f69e83a8
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:47:58.888412+00:00
request_json:
Extract discrete technical ideas and mechanisms from 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-pim-zeroconf-mcast-addr-alloc-ps | Zeroconf Multicast Address Allocation Problem Statement and Requirements | 11pg
Abstract: This document surveys current problems with existing protocols for
   automatically assigning multicast IP addresses in zero-configuration
   ("zeroconf") networking environments.  It addresses key challenges,
   such as link-layer address collisions, hardware limitations,
   multicast snooping inefficiencies, and the need to avoid manual
   configuration.  Based on these challenges, it derives requirements
   for a lightweight, decentralized solution for dynamically allocating
   unique multicast group addresses without central coordination.

   The document presents explicit requirements covering discovery,
   allocation, conflict detection and resolution, and lease management.
   It also evaluates considerations specific to IPv6 and IPv4 multicast
   address ranges, and identifies approaches that are unsuited for
   zeroconf deployment.  This foundation serves as a reference for
   developing future solutions for multicast address allocation that
   operate autonomously within local networks.





Network Working Group                                        N. Karstens
Internet-Draft                                                    Garmin
Intended status: Informational                              D. Farinacci
Expires: 21 August 2026                                      lispers.net
                                                              M. McBride
                                                               Futurewei
                                                        17 February 2026


Zeroconf Multicast Address Allocation Problem Statement and Requirements
             draft-ietf-pim-zeroconf-mcast-addr-alloc-ps-13

Abstract

   This document surveys current problems with existing protocols for
   automatically assigning multicast IP addresses in zero-configuration
   ("zeroconf") networking environments.  It addresses key challenges,
   such as link-layer address collisions, hardware limitations,
   multicast snooping inefficiencies, and the need to avoid manual
   configuration.  Based on these challenges, it derives requirements
   for a lightweight, decentralized solution for dynamically allocating
   unique multicast group addresses without central coordination.

   The document presents explicit requirements covering discovery,
   allocation, conflict detection and resolution, and lease management.
   It also evaluates considerations specific to IPv6 and IPv4 multicast
   address ranges, and identifies approaches that are unsuited for
   zeroconf deployment.  This foundation serves as a reference for
   developing future solutions for multicast address allocation that
   operate autonomously within local networks.

Status of This Memo

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

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

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

   This Internet-Draft will expire on 21 August 2026.




Karstens, et al.         Expires 21 August 2026                 [Page 1]

Internet-Draft  Zeroconf Mcast Addr Alloc Prblm Statemnt   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 d

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

response_json:
[
  {
    "title": "Link-Layer Address Collision Problem",
    "description": "Multiple different IP multicast addresses can map to the same MAC address due to limited bits in Ethernet multicast addressing. This causes unintended packet reception and filtering issues in zeroconf environments.",
    "type": "requirement"
  },
  {
    "title": "Decentralized Multicast Address Discovery",
    "description": "A mechanism for nodes to discover which multicast addresses are already in use on the local network without requiring central coordination. Essential for avoiding conflicts in zeroconf allocation.",
    "type": "mechanism"
  },
  {
    "title": "Conflict Detection and Resolution Protocol",
    "description": "Automated detection of multicast address conflicts and resolution mechanisms to ensure unique address allocation. Must operate without manual intervention in zeroconf networks.",
    "type": "protocol"
  },
  {
    "title": "Multicast Address Lease Management",
    "description": "Time-based allocation system for multicast addresses with automatic renewal and expiration mechanisms. Prevents permanent address reservation in dynamic zeroconf environments.",
    "type": "mechanism"
  },
  {
    "title": "Hardware-Limited Multicast Filtering",
    "description": "Network hardware constraints that limit the number of multicast addresses that can be efficiently filtered at the switch level. Affects multicast snooping performance and address allocation strategies.",
    "type": "requirement"
  }
]


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

draft-ietf-roll-enrollment-priority | Controlling Secure Network Enrollment in RPL networks | 10pg
Abstract: [RFC9032] defines a method by which a potential [RFC9031] enrollment
   proxy can announce itself as available for new RPL nodes to enroll on
   a network.  The announcement includes a priority for enrollment.
   This document provides a mechanism by which a Routing Protocol for
   Low-Power and Lossy Networks (RPL) Root can globally disable
   enrollment announcements or adjust the base priority for enrollment
   operations.





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


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

Abstract

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

Status of This Memo

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

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

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

   This Internet-Draft will expire on 28 July 2026.

Copyright Notice

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






Richardson, et al.        Expires 28 July 2026                  [Page 1]

Internet-Draft                 join-metric                  January 2026


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

Table of Contents

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

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

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


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

draft-ietf-sml-trust | Trust and security considerations for Structured Email | 7pg
Abstract: This document discusses trust and security considerations for
   structured email and provides recommendations for message user agents
   on how to deal with structured data in email messages.

Discussion Venues

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

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

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





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


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

Abstract

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

Discussion Venues

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

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

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

Status of This Memo

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

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

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

   This Internet-Draft will expire on 23 April 2026.

Copyright Notice

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



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


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

Table of Contents

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

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

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


draft_name: draft-ietf-sshm-mlkem-hybrid-kex
prompt_hash: 6c0469a3026c9a52
model: claude-sonnet-4-20250514
created_at: 2026-02-28T10:48:20.494456+00:00
request_json:
Extract discrete technical ideas and mechanisms from this IETF draft.
Return a JSON array. Each element: {"title":"short name","description":"1-2 sentences","type":"mechanism|protocol|pattern|requirement|architecture|extension"}

draft-ietf-sshm-mlkem-hybrid-kex | PQ/T Hybrid Key Exchange with ML-KEM in SSH | 15pg
Abstract: This document defines Post-Quantum Traditional (PQ/T) Hybrid key
   exchange methods based on the quantum-resistant Module-Lattice-Based
   Key-Encapsulation Mechanism (ML-KEM) standard and traditional
   Elliptic-curve Diffie–Hellman (ECDH) key exchange schemes.  These
   methods are defined for use in the SSH Transport Layer Protocol.





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


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

Abstract

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

Status of This Memo

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

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

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

   This Internet-Draft will expire on 30 August 2026.

Copyright Notice

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










Kampanakis, et al.       Expires 30 August 2026                 [Page 1]

Internet-Draft                   PQ SSH                    February 2026


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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   4
   2.  PQ/T Hybrid Key Exchange  . . . . . . . . . . . . . . . . . .   4
     2.1.  PQ/T Hybrid Key Exchange Method Abstraction . . . . . . .   4
     2.2.  PQ/T Hybrid Key Exchange Message Numbers  . . . . . . . .   5
     2.3.  PQ/T Hybrid Key Exchange Method Names . . . . . . . . . 

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

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


