Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by mx.ietf.org (Postfix) with ESMTPS id 3DE2B46 for ; Mon, 12 Oct 2026 15:05:43 +0000 (UTC) Authentication-Results: mx.ietf.org; dkim=pass header.d=or13.io header.s=google header.b=gSbGF8xI; arc=pass ("google.com:s=arc-20260327:i=1"); spf=pass (mx.ietf.org: domain of orie@or13.io designates 2607:f8b0:4864:20::1034 as permitted sender) smtp.mailfrom=orie@or13.io; dmarc=none Received: by mail-pj1-x1034.google.com with SMTP id 98e67ed59e1d1-3ab8309dcbaso1345944a91.1 for ; Mon, 12 Oct 2026 08:05:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1791817535; cv=none; d=google.com; s=arc-20260327; b=KeCKAX1VXiGbiPITwleaAfnSxI5AuUjhcDlsSmZ+/dH7pEO8PV/ddCUP9imU8lltbZ 6eB0dk07QIpUaByBdyjMS7Ms876uaZp8nqsVZGGeiee5xfVRjXhuXILYUf9n5aeXZ0mb INkqE/nM61VmNEXAIM9mFUobILg5PJ6XFDFYAEFgINeIeY7nKmklqjMSLVL0IR7j4v1j ntxrfNpOUziu/2Bilj+TUZSnxeI4rBxQQ/imm4p75z+eQlvT696eMlfH2svaS/LU34y0 o52npI1cIh23Y0iR7DmRTtwSa2PBzAE4IG5mYHfq0xgvED0VtEhVi1XlHAqOdc1OlQ6p WUQQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=Bpmez+DuM5SSDFmXn7gbUNYfevGAx7DQjNcMCmEz/to=; fh=8484Vlczs7iTqFBTr1sj+cJ7gPOX8szMa/qngZcTpdE=; b=Y+4Hvbc9d92D3j2kXvpSioZgEMZPtWmlAkDJHr2NFooo9L/7KGbGfP03ji4H77NV6p jbhwOOB+KuPqwyFYVHllNnxBiavfMz4bEpnMRWTXvKSqbgGWDVd2G9Khjr7/d6Sk5mbY fQ0FvWQZhNJbFYtEtiO2vuRgMwblbNKotoKKSFCScmqIKUiUbWTviaykcQ+bbqu51Ujz hKTiRnsZjgk6CFg78ryEdtnhcaVQY+PzgqGrh3+wsVUYpAcycPGYtD2Mv/NXCx0bTuqm q2/tvDhR51XMfJp9NbR5vyWHhqVqEtngVZEh65AJFYt389uOZyyAqgjU8dgM9Rl6IuuV DJrw==; darn=ietf.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=or13.io; s=google; t=1791817535; x=1792422335; darn=ietf.org; h=content-type:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to :content-type; bh=Bpmez+DuM5SSDFmXn7gbUNYfevGAx7DQjNcMCmEz/to=; b=gSbGF8xIx6PkQGifMuFYhNurqkg0h6RxYKgm6Zbpu9esnZUq0xQMy6pwuXCQRPg7dF lkUmDd97PacKHaPJ9IPP0SitJdjS4vAztBuNrdBI6jRgZJgkckiDOzGU5vHrM4JXpOPz nNOkchmFu8pHDkcr2/JqIKcWUIama3w0D4r4CqddkLOFG1v9l/jragFzXjJXCYOAcFld EdBH62GddbIYuP/9cj1+GwOaZXJfyhJTFKBMSVhKqnWSjts258uHuxjWGZuuF+vJg1Go mI4pHJSrXrtd1VJc+hQPDNFVJkpIVC/v1wT6fi5k0/1M130ulZMMrpcQnYqydomiNYOZ 6f4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791817535; x=1792422335; h=content-type:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=Bpmez+DuM5SSDFmXn7gbUNYfevGAx7DQjNcMCmEz/to=; b=n9NOAoT+LafuQZdOFa/P0G6yvYZcjzXzIVMsjZNIONPaxfovqgPqEk48k/5byMaAkm ZXE819mCQPl/VLl3o0kuI5WCn0Y/cv1qG+rpy68WTlafNC+qb8Ihm+3wipQQ51bJ5ms2 g4wqP2IsJ5GftayscwYjSEtliKg32SXOjEcwPq7ggaJrivcVH7McoL6a+d8C13EcOyLL 647moDLftbHqRN0dH6XDtPYUtgHu+ybrnPQKRG827updUTU8JV1EGP4FmO21CEOkeql7 Mc5OO699JunGyal8nFLWwcEtSDC/ZRXOiTZzTRsA2PzbdPjOhRyA/YX8tWxop7lywKzA +Pmw== X-Forwarded-Encrypted: i=1; AKwUvBwOhJR4fugJ4XnOr4nira1Kh1q5RXDjWPNA2UsfdpoZIUrqqp3XBlWiWAFTY3WXxu/H8IYr2UCTXg8u@ietf.org X-Gm-Message-State: AFq9FYKeuirBQTBsJ5ZNOSGH5d0godLOpqZQdsUugaFdSx1UuFFPBfu2 IeWkR80DUhuNWQ6MfYVQ3+U6OZT0fxrKvrf6FxeuxwKgvRDqYiGvwEWSLdbptvxn9OShk+WqVsr qkOXaAbMBtwa+2A3LHR1EBRXFYNBjfB7/YLVqLTjFIQ== X-Gm-Gg: AYBFou39UMoEE4+IePABNvuEK72/svE03m5sKiqf8/DiEIdrKAg7hP88Qr5IrQfkq8V Ki+78biXm1XDrdcJKvBgd0C3VTSV2HJ/0mejtIGJsi7aiY/iKwZgYrsTFQrsXdlqsgwgDwfCyOS ME3AZazrt1MN4gJAD2GEtub4Hx2QD+S1vnLFeEGC/+FdlaHyTf+8TFjNlNdANYZow5zcqNHiJI0 esCP7/HExw8GIjtIro1yCv7IXM1UYL/yeA43zGRXoenBcxVC5UvBcF3iKFL3wVXXATckAsC0zAD oUuUSvLJbdZwOR1FrGFycvJrP2nbWCIyFXgyt/0ImqA8ToIf3nnFuzBY3GnJM+ga/1fvB7qYxvX 42pEEBn2ucQWX X-Received: by 2002:a17:90b:1a8a:b0:3a0:cca0:4a8c with SMTP id 98e67ed59e1d1-3ab3a9529c8mr5560821a91.7.1791817534768; Mon, 12 Oct 2026 08:05:34 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Orie Date: Mon, 12 Oct 2026 10:05:22 -0500 X-Gm-Features: AclHuK8f-MK8Xsi7mcVfA-ZPlE0kgcyQ6GqlhsUxwzzpJwfz6BQ1ECvRA_zmZt0 Message-ID: To: tirumal reddy Content-Type: multipart/alternative; boundary="000000000000a99bcb065da607c3" X-Spamd-Bar: ------------------------ Message-ID-Hash: U56F45OW3AOUXCQNBY7UXVVPNKCN5FPF X-Message-ID-Hash: U56F45OW3AOUXCQNBY7UXVVPNKCN5FPF X-MailFrom: orie@or13.io X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: Iman Schrock , girish.sai1@gmail.com, nikhilreddy2619@gmail.com, agentproto@ietf.org X-Mailman-Version: 3.3.10 Precedence: list Subject: [Agentproto] Re: Topic: Existing practice, use cases, and deployment models List-Id: Agent Communication Protocols Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --000000000000a99bcb065da607c3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all, Thanks for the contributions. Our goal for this topic is to identify candidate starting points for the Use Cases and Requirements document. The discussion has identified two drafts for consideration: - draft-rosenberg-agentproto-usecases-00 - draft-agentic-ai-usecases-requirements-03 Thanks to the authors and reviewers for the recent updates to the latter draft and the proposed follow-up revisions addressing recovery and authorization. We have useful contributions toward a working group document, but have not yet established which draft should be its starting point. We would also welcome more input on telecom and 3GPP use cases. Please identify relevant drafts and sections, including updates to draft-stephan-ai-agent-6g and draft-ly-multi-agent-in6g, and explain what they would add to either candidate. Please comment on whether either draft provides a suitable starting point for adoption, what essential material is missing, or whether another draft should be considered. Regards, Orie and Leslie agentproto co-chairs On Mon, Oct 12, 2026 at 2:01=E2=80=AFAM tirumal reddy w= rote: > Hi Girish, Iman, Nicholas, Bradley, > > Thanks. For -04 I propose the following. > > Resumption, split in two: > > B1-7: On resumption, the protocol is required to enable the receiving > participant to verify that (1) the party resuming the dialog is the > participant whose exchange was interrupted, (2) the dialog context > presented is the current state of that dialog, and (3) the dialog has > not been terminated and its authorization has not been revoked. > > B1-8: If any check in B1-7 fails or cannot be completed, the dialog > is not resumed and the protocol is required to signal the reason. > > Authorization for any change to a dialog, as a common requirement: > > CMN-12: Before accepting a change to a dialog, a participant is > required to be able to verify that the change is authorized at that > time. If it cannot verify this, it is required to reject the change > and signal the reason. > > Operations in progress at an interruption, as text in Section 4.2: > > If a dialog is interrupted before the result of an operation reaches the > delegating agent, the > operation may or may not have completed. Resuming the dialog does not tel= l > the delegating > agent which. Before resending the operation, the delegating agent checks > its outcome with > the delegated agent or tool that performed it. > > Cheers, > -Tiru > > On Sun, 11 Oct 2026 at 05:55, Iman Schrock wrote= : > >> Hi Girish, >> >> Yes, both additions capture what I meant. Thank you for writing them up. >> >> The deciding participant needs to know before admission that a >> required input couldn't be established. Recording that only afterward >> doesn't close the gap. >> >> Tiru, could we carry these into the requirements text? The >> unresolved-operation case also fits mediator recovery under B5-2. The >> participant can retain operation state locally, with retry guarantees >> remaining with the tool or provider. >> >> Best, >> Iman >> >> On Sat, 10 Oct 2026 16:35:36 -0700, Girish Konda >> wrote: >> > Hey Folks, >> > >> > I've read draft-agentic-ai-usecases-requirements-03 >> > < >> https://datatracker.ietf.org/doc/html/draft-agentic-ai-usecases-requirem= ents-03 >> >, >> > and the resumption checks in B1-7 look good. Iman, here are the two >> > additions I offered to write up. >> > >> > 1. *Unresolved Downstream Operations:* "On resumption, the task >> > preserves the identity and unresolved status of a downstream >> operation >> > until its outcome can be established. Resuming the dialog does not = by >> > itself justify submitting that operation again." Restoring dialog >> context >> > isn't evidence that the earlier operation didn't happen. This doesn= 't >> > require carrying task context in the protocol. >> > 2. *Unavailable Authorization Inputs:* "If a required authorization >> > input cannot be established, the deciding participant accounts for >> that >> > fact in its admission decision under local policy. The protocol >> makes that >> > state available before admission, directly or by reference, >> separately from >> > an evaluated refusal, even when both lead to denial." >> > >> > Section 8 of my draft-konda-agentproto-evaluation-state-01 >> > < >> https://datatracker.ietf.org/doc/html/draft-konda-agentproto-evaluation-= state-01#section-8 >> > >> > maps these cases to B1-6/B1-7. Doug, Lars, we should keep the >> > authorization-context carry-or-reference requirement alongside this, >> > including what happens when a reference can't be resolved in time or >> > returns stale state. >> > >> > Thanks, >> > Girish >> > >> > On Fri, Oct 9, 2026 at 11:36=E2=80=AFPM tirumal reddy >> wrote: >> > >> > > Hi Nikhil, >> > > >> > > Most of this is now covered in >> > > draft-agentic-ai-usecases-requirements, updated to align with the >> charter: >> > > https://github.com/tireddy2/agentic-ai-ucreq2/pull/72 >> > > >> > > - Resumption after network interruption or change: B1-6 >> > > - On resumption, checking that the dialog has not been terminated or >> its >> > > authorization revoked, so continuity does not imply continued >> > > authorization: B1-7 >> > > - Correlation across hops: B3-13 >> > > - Recovery after intermediary failure: B5-2 >> > > - Identifier linkability across domains: Security Considerations >> > > >> > > The draft notes the linkability risk of identifiers shared across >> domains >> > > in Security Considerations. >> > > Comments on the text are welcome. >> > > >> > > -Tiru >> > > >> > > On Fri, 9 Oct 2026 at 16:47, Nikhil D >> wrote: >> > > >> > >> Dear Orie, Leslie, and colleagues, >> > >> >> > >> >> > >> Following my earlier note on dialog continuity across multiple >> agents and >> > >> trust boundaries, I have worked on a more detailed use case that I >> would >> > >> like to share for discussion. >> > >> >> > >> *Proposed use case: Privacy-Preserving Dialog Resumption Across >> > >> Administrative Trust Boundaries* >> > >> >> > >> Consider an enterprise AI agent that receives a task from a user an= d >> > >> delegates part of it to an agent operated by another organization. >> The >> > >> second agent may use external tools to complete its work. >> > >> >> > >> >> > >> Now suppose the task is interrupted because of a network failure or >> > >> gateway restart. When communication resumes, the agents need to >> identify >> > >> the original dialog and continue from the appropriate state. >> > >> >> > >> >> > >> The concern I see is that sharing the same persistent dialog >> identifier >> > >> across organizations could allow participants to correlate >> interactions >> > >> beyond what is necessary for the task. At the same time, removing o= r >> > >> changing identifiers without a reliable mapping could break dialog >> > >> continuity. >> > >> >> > >> >> > >> *Interoperability gap* >> > >> >> > >> Existing agent communication mechanisms may support task >> identification >> > >> and status recovery, but it is worth examining whether interoperabl= e >> dialog >> > >> resumption can be achieved across administrative boundaries without >> > >> requiring every participant to use the same globally visible >> identifier. >> > >> >> > >> *Candidate requirements* >> > >> >> > >> I suggest considering the following: >> > >> >> > >> 1. Participants should be able to resume an existing dialog usin= g >> the >> > >> minimum correlation information necessary. >> > >> 2. Dialog identifiers should be scoped appropriately when >> information >> > >> crosses administrative trust boundaries. >> > >> 3. The protocol should support recovery after intermediary >> failures >> > >> without incorrectly associating unrelated dialogs. >> > >> 4. Participants should be able to distinguish dialog continuity >> from >> > >> authorization to continue performing delegated actions. >> > >> 5. The system should define how to handle missing, stale, or >> invalid >> > >> correlation information during resumption. >> > >> >> > >> *Failure cases worth examining* >> > >> >> > >> A few situations may help evaluate these requirements: >> > >> >> > >> - An intermediary restarts and loses its local dialog mapping. >> > >> - A participant receives an outdated correlation reference. >> > >> - A dialog resumes after delegated authorization has expired or >> been >> > >> revoked. >> > >> - Two unrelated dialogs are incorrectly associated during >> recovery. >> > >> - A downstream participant receives more correlation information >> than >> >> > >> its role requires. >> > >> >> > >> I see this as a possible extension to the dialog lifecycle >> discussion in >> > >> Section 3.3.3 of draft-rosenberg-agentproto-usecases-00, with relat= ed >> > >> privacy and authorization considerations. >> > >> >> > >> >> > >> My intention is not to introduce a new authorization mechanism, but >> to >> > >> identify what dialog-management information is needed for safe and >> > >> interoperable resumption. >> > >> >> > >> I would appreciate feedback on whether this use case would be usefu= l >> for >> > >> the Use Cases and Requirements document. I would also be happy to >> refine >> > >> the technical text based on the group's comments. >> > >> >> > >> >> > >> Best regards, >> > >> >> > >> >> > >> Nikhil Reddy Donapati >> > >> Software Engineer >> > >> NeuroNet Solutions Inc. >> > >> >> > >> >> > >> >> > >> >> > >> On Thu, 8 Oct 2026 at 17:56, Iman Schrock > > >> 40emiliaprotocol.ai@dmarc.ietf.org> wrote: >> > >> >> > >>> Hi Girish, >> > >>> >> > >>> Yes, please carry both into the revision. Keeping the resubmission >> > >>> restraint as its own sentence makes the distinction clearer. >> > >>> >> > >>> You're also right about the decision itself. If a required >> > >>> authorization input cannot be established, that has to affect >> > >>> admission, not just leave a note afterward. It should remain >> > >>> distinguishable from an evaluated refusal, even when both lead to >> > >>> local denial. >> > >>> >> > >>> Thank you for offering to write this up. >> > >>> >> > >>> Best, >> > >>> Iman >> > >>> >> > >>> On Wed, 7 Oct 2026 12:49:08 -0700, Girish Konda < >> girish.sai1@gmail.com> >> > >>> wrote: >> > >>> > Hey Iman, >> > >>> > >> > >>> > Thanks for the write up. A couple of comments on the two bullets= . >> The >> > >>> split >> > >>> > keeps retrying an evaluation separate from repeating an operatio= n >> with >> > >>> side >> > >>> > effects, which is the distinction that matters at the tool >> boundary. >> > >>> > >> > >>> > 1. *Submission Is Not Resubmission:* Your 3.3.3 wording says >> > >>> resuming >> > >>> > the dialog doesn=E2=80=99t by itself justify submitting the o= peration >> > >>> again. I=E2=80=99d >> > >>> > keep that as its own sentence. The preservation is a state >> > >>> requirement and >> > >>> > the restraint is a behavioural one, and they won=E2=80=99t al= ways be >> read >> > >>> together. >> > >>> > 2. *Availability to the Decision, Not Only the Record:* 3.3.5 >> says >> > >>> > preserve that fact separately from an evaluated refusal. >> Preserving >> > >>> it in >> > >>> > the record is the audit half. Douglas Wadkins=E2=80=99s three= -part >> split on >> > >>> the >> > >>> > charter thread has the same distinction reaching the admissio= n >> > >>> decision, >> > >>> > since otherwise "could not establish" becomes a field without >> > >>> becoming an >> > >>> > input. >> > >>> > >> > >>> > I=E2=80=99m happy to write both up for whichever revision takes = them. >> > >>> > >> > >>> > Thanks, >> > >>> > Girish >> > >>> >> > >>> On Wed, 07 Oct 2026 12:49:08 -0700, Girish Konda < >> girish.sai1@gmail.com> >> > >>> wrote: >> > >>> > Hey Iman, >> > >>> > >> > >>> > Thanks for the write up. A couple of comments on the two bullets= . >> The >> > >>> split >> > >>> > keeps retrying an evaluation separate from repeating an operatio= n >> with >> > >>> side >> > >>> > effects, which is the distinction that matters at the tool >> boundary. >> > >>> > >> > >>> > 1. *Submission Is Not Resubmission:* Your 3.3.3 wording says >> > >>> resuming >> > >>> > the dialog doesn=E2=80=99t by itself justify submitting the o= peration >> > >>> again. I=E2=80=99d >> > >>> > keep that as its own sentence. The preservation is a state >> > >>> requirement and >> > >>> > the restraint is a behavioural one, and they won=E2=80=99t al= ways be >> read >> > >>> together. >> > >>> > 2. *Availability to the Decision, Not Only the Record:* 3.3.5 >> says >> > >>> >> > >>> > preserve that fact separately from an evaluated refusal. >> Preserving >> > >>> it in >> > >>> > the record is the audit half. Douglas Wadkins=E2=80=99s three= -part >> split on >> > >>> the >> > >>> > charter thread has the same distinction reaching the admissio= n >> > >>> decision, >> > >>> > since otherwise "could not establish" becomes a field without >> > >>> becoming an >> > >>> > input. >> > >>> > >> > >>> > I=E2=80=99m happy to write both up for whichever revision takes = them. >> > >>> > >> > >>> > Thanks, >> > >>> > Girish >> > >>> > >> > >>> > On Mon, Oct 5, 2026 at 7:21=E2=80=AFAM Iman Schrock < >> team@emiliaprotocol.ai> >> > >>> wrote: >> > >>> > >> > >>> > > Hi Girish, >> > >>> > > >> > >>> > > I=E2=80=99d use two linked bullets, following the split alread= y in >> Section 8 >> > >>> > > of your draft: >> > >>> > > >> > >>> > > 3.3.3: =E2=80=9COn resumption, the task preserves the identity= and >> unresolved >> > >>> > > status of a downstream operation until its outcome can be >> > >>> established. >> > >>> > > Resuming the dialog does not by itself justify submitting that >> > >>> > > operation again.=E2=80=9D >> > >>> > > >> > >>> > > 3.3.5: =E2=80=9CIf a required authorization input cannot be es= tablished, >> > >>> > > preserve that fact separately from an evaluated refusal, even >> when >> > >>> > > both lead to local denial.=E2=80=9D >> > >>> > > >> > >>> > > That keeps retrying an evaluation or status query separate fro= m >> > >>> > > repeating an operation with side effects. The tool or provider >> still >> > >>> > > supplies the retry guarantees. >> > >>> > > >> > >>> > > Best, >> > >>> > > Iman >> > >>> > > >> > >>> > > >> > >>> > > On Mon, 05 Oct 2026 02:41:00 -0700, Girish Konda < >> > >>> girish.sai1@gmail.com> >> > >>> > > wrote: >> > >>> > > > Hey Folks, >> > >>> > > > >> > >>> > > > A couple of comments on the Topic 1 input set and I agree >> with the >> > >>> shape >> > >>> > > of >> > >>> > > > the replies so far. Iman's response-loss case fits 3.3.3, >> Henri's >> > >>> MCP >> > >>> > > proxy >> > >>> > > > model is a useful deployment point, and Nikhil's continuity >> note >> > >>> belongs >> > >>> > > > with the dialog lifecycle. Lars has a candidate for the 3.3.= 5 >> > >>> grant gap >> > >>> > > and >> > >>> > > > Sumit has the cross-domain policy gap in 3.3.2. >> > >>> > > > >> > >>> > > > I don't think the missing piece is another authorization >> artifact >> > >>> yet. >> > >>> > > It's >> > >>> > > > an operational state the architecture has to preserve when >> any of >> > >>> those >> > >>> > > > artifacts cannot be evaluated. An unestablished input is a >> > >>> different fact >> > >>> > > > from a negative one, and collapsing them changes retry, >> ownership >> > >>> and >> > >>> > > > blast-radius accounting. I've written it up as >> > >>> > > > draft-konda-agentproto-evaluation-state-00, >> > >>> > > > >> > >>> > > >> > >>> >> https://datatracker.ietf.org/doc/draft-konda-agentproto-evaluation-state= / >> > >>> . >> > >>> > > > >> > >>> > > > We should settle which of 3.3.3 and 3.3.5 carries the >> > >>> unestablished-input >> > >>> > > > case, and I'm happy to write the bullet for whichever sectio= n >> it >> > >>> lands >> > >>> > > in. >> > >>> > > > >> > >>> > > > Thanks, >> > >>> > > > Girish >> > >>> > > > >> > >>> > > > On Sat, Oct 3, 2026 at 11:01=E2=80=AFPM tirumal reddy < >> kondtir@gmail.com> >> > >>> wrote: >> > >>> > > > >> > >>> > > > > Hi, >> > >>> > > > > >> > >>> > > > > "Agentic AI Use Cases and Requirements" draft >> > >>> > > > > >> > >>> > > >> > >>> >> https://datatracker.ietf.org/doc/draft-agentic-ai-usecases-requirements/ >> > >>> > > derives >> > >>> > > > > session (dialog) management, transport and security >> requirements >> > >>> from >> > >>> > > use >> > >>> > > > > cases reflected in A2A, MCP and deployed multi-agent >> frameworks. >> > >>> > > > > >> > >>> > > > > Candidate use cases (Section 4) are: >> > >>> > > > > >> > >>> > > > > a) Single agent invoking tools across domains >> > >>> > > > > b) Orchestrator delegation >> > >>> > > > > c) Long-running delegated task >> > >>> > > > > d) Multi-hop peer delegation >> > >>> > > > > e) Group consensus >> > >>> > > > > f) Mediator between agents and tools, including translatio= n >> to >> > >>> MCP and >> > >>> > > A2A >> > >>> > > > > >> > >>> > > > > The use cases are deployment-agnostic, so no >> deployment-specific >> > >>> use >> > >>> > > cases >> > >>> > > > > are included. Each use case lists its session (dialog) >> > >>> management, >> > >>> > > > > transport and security requirements; common requirements >> are in >> > >>> > > Section 3. >> > >>> > > > > >> > >>> > > > > Thanks, >> > >>> > > > > -Tiru >> > >>> > > > > >> > >>> > > > > On Fri, 2 Oct 2026 at 22:40, Orie wrote: >> > >>> > > > > >> > >>> > > > >> Hi, >> > >>> > > > >> >> > >>> > > > >> This is the first in a series of topics, as noted here: >> > >>> > > > >> >> > >>> > > > >> >> > >>> > > > >> >> > >>> > > >> > >>> >> https://mailarchive.ietf.org/arch/msg/agentproto/3_WBraJwt-jwDpZYb3uUoCR= MrA0/ >> > >>> > > > >> >> > >>> > > > >> Please identify Internet-Drafts describing existing >> systems, >> > >>> > > protocols, >> > >>> > > > >> use cases, or deployment models relevant to agentproto. >> > >>> > > > >> >> > >>> > > > >> Point to the sections that explain how users, agents, and >> tools >> > >>> > > interact, >> > >>> > > > >> what works today, and where interoperability gaps arise. >> > >>> > > Implementation and >> > >>> > > > >> deployment experience will help us assess these >> contributions. >> > >>> > > > >> >> > >>> > > > >> The expected output is a set of candidate use cases, >> deployment >> > >>> > > models, >> > >>> > > > >> and supporting references for **Use Cases and >> Requirements**, >> > >>> > > together with >> > >>> > > > >> deployment assumptions for the **Reference Architecture**= . >> > >>> > > > >> >> > >>> > > > >> Regards, >> > >>> > > > >> >> > >>> > > > >> Orie and Leslie >> > >>> > > > >> agentproto co-chairs >> > >>> > > > >> >> > >>> > > > >> _______________________________________________ >> > >>> > > > >> Agentproto mailing list -- agentproto@ietf.org >> > >>> > > > >> To unsubscribe send an email to agentproto-leave@ietf.org >> > >>> > > > >> >> > >>> > > > > _______________________________________________ >> > >>> > > > > Agentproto mailing list -- agentproto@ietf.org >> > >>> > > > > To unsubscribe send an email to agentproto-leave@ietf.org >> > >>> > > > > >> > >>> > > >> > >>> _______________________________________________ >> > >>> Agentproto mailing list -- agentproto@ietf.org >> > >>> To unsubscribe send an email to agentproto-leave@ietf.org >> > >>> >> > >> >> > >> > --000000000000a99bcb065da607c3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

Thanks for the contributions. Our goal for = this topic is to identify candidate starting points for the Use Cases and R= equirements document.

The discussion has identified two drafts for c= onsideration:

- draft-rosenberg-agentproto-usecases-00
- draft-ag= entic-ai-usecases-requirements-03

Thanks to the authors and reviewer= s for the recent updates to the latter draft and the proposed follow-up rev= isions addressing recovery and authorization.=C2=A0
We have useful cont= ributions toward a working group document, but have not yet established whi= ch draft should be its starting point.

We would also welcome more in= put on telecom and 3GPP use cases.=C2=A0
Please identify relevant= drafts and sections, including updates to draft-stephan-ai-agent-6g and dr= aft-ly-multi-agent-in6g, and explain what they would add to either candidat= e.

Please comment on whether either draft provides a suitable starti= ng point for adoption, what essential material is missing, or whether anoth= er draft should be considered.

Regards,

Orie an= d Leslie
agentproto co-chairs

On Mon, Oct 12,= 2026 at 2:01=E2=80=AFAM tirumal reddy <kondtir@gmail.com> wrote:
Hi Girish, Iman, Ni= cholas, Bradley,

Thanks. For -04 I propose the following.

Res= umption, split in two:

=C2=A0 B1-7: On resumption, the protocol is r= equired to enable the receiving
=C2=A0 participant to verify that (1) th= e party resuming the dialog is the
=C2=A0 participant whose exchange was= interrupted, (2) the dialog context
=C2=A0 presented is the current sta= te of that dialog, and (3) the dialog has
=C2=A0 not been terminated and= its authorization has not been revoked.

=C2=A0 B1-8: If any check i= n B1-7 fails or cannot be completed, the dialog
=C2=A0 is not resumed an= d the protocol is required to signal the reason.

Authorization for a= ny change to a dialog, as a common requirement:

=C2=A0 CMN-12: Befor= e accepting a change to a dialog, a participant is
=C2=A0 required to be= able to verify that the change is authorized at that
=C2=A0 time. If it= cannot verify this, it is required to reject the change
=C2=A0 and sign= al the reason.

Operations in progress at an interruption, as text in= Section 4.2:

If a dialog is interrupted before the result of an ope= ration reaches the delegating agent, the=C2=A0
operation may or may = not have completed. Resuming the dialog does not tell the delegating=C2=A0
agent which. Before resending the operation, the delegating agent checks its outcome with=C2=A0=
the delegated agent or tool that performed it.=C2=A0= =C2=A0

Cheers,
-Tiru

On Sun, 11 Oct 2026 at 05:55, Iman Schrock &l= t;team@emiliapr= otocol.ai> wrote:
Hi Girish,

Yes, both additions capture what I meant. Thank you for writing them up.
The deciding participant needs to know before admission that a
required input couldn't be established. Recording that only afterward doesn't close the gap.

Tiru, could we carry these into the requirements text? The
unresolved-operation case also fits mediator recovery under B5-2. The
participant can retain operation state locally, with retry guarantees
remaining with the tool or provider.

Best,
Iman

On Sat, 10 Oct 2026 16:35:36 -0700, Girish Konda <girish.sai1@gmail.com> wrote: > Hey Folks,
>
> I've read draft-agentic-ai-usecases-requirements-03
> <https://data= tracker.ietf.org/doc/html/draft-agentic-ai-usecases-requirements-03>= ,
> and the resumption checks in B1-7 look good. Iman, here are the two > additions I offered to write up.
>
>=C2=A0 =C2=A0 1. *Unresolved Downstream Operations:* "On resumptio= n, the task
>=C2=A0 =C2=A0 preserves the identity and unresolved status of a downstr= eam operation
>=C2=A0 =C2=A0 until its outcome can be established. Resuming the dialog= does not by
>=C2=A0 =C2=A0 itself justify submitting that operation again." Res= toring dialog context
>=C2=A0 =C2=A0 isn't evidence that the earlier operation didn't = happen. This doesn't
>=C2=A0 =C2=A0 require carrying task context in the protocol.
>=C2=A0 =C2=A0 2. *Unavailable Authorization Inputs:* "If a require= d authorization
>=C2=A0 =C2=A0 input cannot be established, the deciding participant acc= ounts for that
>=C2=A0 =C2=A0 fact in its admission decision under local policy. The pr= otocol makes that
>=C2=A0 =C2=A0 state available before admission, directly or by referenc= e, separately from
>=C2=A0 =C2=A0 an evaluated refusal, even when both lead to denial."= ;
>
> Section 8 of my draft-konda-agentproto-evaluation-state-01
> <h= ttps://datatracker.ietf.org/doc/html/draft-konda-agentproto-evaluation-stat= e-01#section-8>
> maps these cases to B1-6/B1-7. Doug, Lars, we should keep the
> authorization-context carry-or-reference requirement alongside this, > including what happens when a reference can't be resolved in time = or
> returns stale state.
>
> Thanks,
> Girish
>
> On Fri, Oct 9, 2026 at 11:36=E2=80=AFPM tirumal reddy <kondtir@gmail.com> wrote:=
>
> > Hi Nikhil,
> >
> > Most of this is now covered in
> > draft-agentic-ai-usecases-requirements, updated to align with the= charter:
> > https://github.com/tireddy2/agentic-a= i-ucreq2/pull/72
> >
> > - Resumption after network interruption or change: B1-6
> > - On resumption, checking that the dialog has not been terminated= or its
> > authorization revoked, so continuity does not imply continued
> > authorization: B1-7
> > - Correlation across hops: B3-13
> > - Recovery after intermediary failure: B5-2
> > - Identifier linkability across domains: Security Considerations<= br> > >
> > The draft notes the linkability risk of identifiers shared across= domains
> > in Security Considerations.
> > Comments on the text are welcome.
> >
> > -Tiru
> >
> > On Fri, 9 Oct 2026 at 16:47, Nikhil D <nikhilreddy2619@gmail.com> w= rote:
> >
> >> Dear Orie, Leslie, and colleagues,
> >>
> >>
> >> Following my earlier note on dialog continuity across multipl= e agents and
> >> trust boundaries, I have worked on a more detailed use case t= hat I would
> >> like to share for discussion.
> >>
> >> *Proposed use case: Privacy-Preserving Dialog Resumption Acro= ss
> >> Administrative Trust Boundaries*
> >>
> >> Consider an enterprise AI agent that receives a task from a u= ser and
> >> delegates part of it to an agent operated by another organiza= tion. The
> >> second agent may use external tools to complete its work.
> >>
> >>
> >> Now suppose the task is interrupted because of a network fail= ure or
> >> gateway restart. When communication resumes, the agents need = to identify
> >> the original dialog and continue from the appropriate state.<= br> > >>
> >>
> >> The concern I see is that sharing the same persistent dialog = identifier
> >> across organizations could allow participants to correlate in= teractions
> >> beyond what is necessary for the task. At the same time, remo= ving or
> >> changing identifiers without a reliable mapping could break d= ialog
> >> continuity.
> >>
> >>
> >> *Interoperability gap*
> >>
> >> Existing agent communication mechanisms may support task iden= tification
> >> and status recovery, but it is worth examining whether intero= perable dialog
> >> resumption can be achieved across administrative boundaries w= ithout
> >> requiring every participant to use the same globally visible = identifier.
> >>
> >> *Candidate requirements*
> >>
> >> I suggest considering the following:
> >>
> >>=C2=A0 =C2=A0 1. Participants should be able to resume an exis= ting dialog using the
> >>=C2=A0 =C2=A0 minimum correlation information necessary.
> >>=C2=A0 =C2=A0 2. Dialog identifiers should be scoped appropria= tely when information
> >>=C2=A0 =C2=A0 crosses administrative trust boundaries.
> >>=C2=A0 =C2=A0 3. The protocol should support recovery after in= termediary failures
> >>=C2=A0 =C2=A0 without incorrectly associating unrelated dialog= s.
> >>=C2=A0 =C2=A0 4. Participants should be able to distinguish di= alog continuity from
> >>=C2=A0 =C2=A0 authorization to continue performing delegated a= ctions.
> >>=C2=A0 =C2=A0 5. The system should define how to handle missin= g, stale, or invalid
> >>=C2=A0 =C2=A0 correlation information during resumption.
> >>
> >> *Failure cases worth examining*
> >>
> >> A few situations may help evaluate these requirements:
> >>
> >>=C2=A0 =C2=A0 - An intermediary restarts and loses its local d= ialog mapping.
> >>=C2=A0 =C2=A0 - A participant receives an outdated correlation= reference.
> >>=C2=A0 =C2=A0 - A dialog resumes after delegated authorization= has expired or been
> >>=C2=A0 =C2=A0 revoked.
> >>=C2=A0 =C2=A0 - Two unrelated dialogs are incorrectly associat= ed during recovery.
> >>=C2=A0 =C2=A0 - A downstream participant receives more correla= tion information than

> >>=C2=A0 =C2=A0 its role requires.
> >>
> >> I see this as a possible extension to the dialog lifecycle di= scussion in
> >> Section 3.3.3 of draft-rosenberg-agentproto-usecases-00, with= related
> >> privacy and authorization considerations.
> >>
> >>
> >> My intention is not to introduce a new authorization mechanis= m, but to
> >> identify what dialog-management information is needed for saf= e and
> >> interoperable resumption.
> >>
> >> I would appreciate feedback on whether this use case would be= useful for
> >> the Use Cases and Requirements document. I would also be happ= y to refine
> >> the technical text based on the group's comments.
> >>
> >>
> >> Best regards,
> >>
> >>
> >> Nikhil Reddy Donapati
> >> Software Engineer
> >> NeuroNet Solutions Inc.
> >>
> >>
> >>
> >>
> >> On Thu, 8 Oct 2026 at 17:56, Iman Schrock <team=3D
> >> 40emiliaprotocol.ai@dmarc.ietf.org> wrote:
> >>
> >>> Hi Girish,
> >>>
> >>> Yes, please carry both into the revision. Keeping the res= ubmission
> >>> restraint as its own sentence makes the distinction clear= er.
> >>>
> >>> You're also right about the decision itself. If a req= uired
> >>> authorization input cannot be established, that has to af= fect
> >>> admission, not just leave a note afterward. It should rem= ain
> >>> distinguishable from an evaluated refusal, even when both= lead to
> >>> local denial.
> >>>
> >>> Thank you for offering to write this up.
> >>>
> >>> Best,
> >>> Iman
> >>>
> >>> On Wed, 7 Oct 2026 12:49:08 -0700, Girish Konda <girish.sai1@gmail.com= >
> >>> wrote:
> >>> > Hey Iman,
> >>> >
> >>> > Thanks for the write up. A couple of comments on the= two bullets. The
> >>> split
> >>> > keeps retrying an evaluation separate from repeating= an operation with
> >>> side
> >>> > effects, which is the distinction that matters at th= e tool boundary.
> >>> >
> >>> >=C2=A0 =C2=A0 1. *Submission Is Not Resubmission:* Yo= ur 3.3.3 wording says
> >>> resuming
> >>> >=C2=A0 =C2=A0 the dialog doesn=E2=80=99t by itself ju= stify submitting the operation
> >>> again. I=E2=80=99d
> >>> >=C2=A0 =C2=A0 keep that as its own sentence. The pres= ervation is a state
> >>> requirement and
> >>> >=C2=A0 =C2=A0 the restraint is a behavioural one, and= they won=E2=80=99t always be read
> >>> together.
> >>> >=C2=A0 =C2=A0 2. *Availability to the Decision, Not O= nly the Record:* 3.3.5 says
> >>> >=C2=A0 =C2=A0 preserve that fact separately from an e= valuated refusal. Preserving
> >>> it in
> >>> >=C2=A0 =C2=A0 the record is the audit half. Douglas W= adkins=E2=80=99s three-part split on
> >>> the
> >>> >=C2=A0 =C2=A0 charter thread has the same distinction= reaching the admission
> >>> decision,
> >>> >=C2=A0 =C2=A0 since otherwise "could not establi= sh" becomes a field without
> >>> becoming an
> >>> >=C2=A0 =C2=A0 input.
> >>> >
> >>> > I=E2=80=99m happy to write both up for whichever rev= ision takes them.
> >>> >
> >>> > Thanks,
> >>> > Girish
> >>>
> >>> On Wed, 07 Oct 2026 12:49:08 -0700, Girish Konda <girish.sai1@gmail.co= m>
> >>> wrote:
> >>> > Hey Iman,
> >>> >
> >>> > Thanks for the write up. A couple of comments on the= two bullets. The
> >>> split
> >>> > keeps retrying an evaluation separate from repeating= an operation with
> >>> side
> >>> > effects, which is the distinction that matters at th= e tool boundary.
> >>> >
> >>> >=C2=A0 =C2=A0 1. *Submission Is Not Resubmission:* Yo= ur 3.3.3 wording says
> >>> resuming
> >>> >=C2=A0 =C2=A0 the dialog doesn=E2=80=99t by itself ju= stify submitting the operation
> >>> again. I=E2=80=99d
> >>> >=C2=A0 =C2=A0 keep that as its own sentence. The pres= ervation is a state
> >>> requirement and
> >>> >=C2=A0 =C2=A0 the restraint is a behavioural one, and= they won=E2=80=99t always be read
> >>> together.
> >>> >=C2=A0 =C2=A0 2. *Availability to the Decision, Not O= nly the Record:* 3.3.5 says
> >>>
> >>> >=C2=A0 =C2=A0 preserve that fact separately from an e= valuated refusal. Preserving
> >>> it in
> >>> >=C2=A0 =C2=A0 the record is the audit half. Douglas W= adkins=E2=80=99s three-part split on
> >>> the
> >>> >=C2=A0 =C2=A0 charter thread has the same distinction= reaching the admission
> >>> decision,
> >>> >=C2=A0 =C2=A0 since otherwise "could not establi= sh" becomes a field without
> >>> becoming an
> >>> >=C2=A0 =C2=A0 input.
> >>> >
> >>> > I=E2=80=99m happy to write both up for whichever rev= ision takes them.
> >>> >
> >>> > Thanks,
> >>> > Girish
> >>> >
> >>> > On Mon, Oct 5, 2026 at 7:21=E2=80=AFAM Iman Schrock = <team@emilia= protocol.ai>
> >>> wrote:
> >>> >
> >>> > > Hi Girish,
> >>> > >
> >>> > > I=E2=80=99d use two linked bullets, following t= he split already in Section 8
> >>> > > of your draft:
> >>> > >
> >>> > > 3.3.3: =E2=80=9COn resumption, the task preserv= es the identity and unresolved
> >>> > > status of a downstream operation until its outc= ome can be
> >>> established.
> >>> > > Resuming the dialog does not by itself justify = submitting that
> >>> > > operation again.=E2=80=9D
> >>> > >
> >>> > > 3.3.5: =E2=80=9CIf a required authorization inp= ut cannot be established,
> >>> > > preserve that fact separately from an evaluated= refusal, even when
> >>> > > both lead to local denial.=E2=80=9D
> >>> > >
> >>> > > That keeps retrying an evaluation or status que= ry separate from
> >>> > > repeating an operation with side effects. The t= ool or provider still
> >>> > > supplies the retry guarantees.
> >>> > >
> >>> > > Best,
> >>> > > Iman
> >>> > >
> >>> > >
> >>> > > On Mon, 05 Oct 2026 02:41:00 -0700, Girish Kond= a <
> >>> girish.sai1@gmail.com>
> >>> > > wrote:
> >>> > > > Hey Folks,
> >>> > > >
> >>> > > > A couple of comments on the Topic 1 input = set and I agree with the
> >>> shape
> >>> > > of
> >>> > > > the replies so far. Iman's response-lo= ss case fits 3.3.3, Henri's
> >>> MCP
> >>> > > proxy
> >>> > > > model is a useful deployment point, and Ni= khil's continuity note
> >>> belongs
> >>> > > > with the dialog lifecycle. Lars has a cand= idate for the 3.3.5
> >>> grant gap
> >>> > > and
> >>> > > > Sumit has the cross-domain policy gap in 3= .3.2.
> >>> > > >
> >>> > > > I don't think the missing piece is ano= ther authorization artifact
> >>> yet.
> >>> > > It's
> >>> > > > an operational state the architecture has = to preserve when any of
> >>> those
> >>> > > > artifacts cannot be evaluated. An unestabl= ished input is a
> >>> different fact
> >>> > > > from a negative one, and collapsing them c= hanges retry, ownership
> >>> and
> >>> > > > blast-radius accounting. I've written = it up as
> >>> > > > draft-konda-agentproto-evaluation-state-00= ,
> >>> > > >
> >>> > >
> >>> https://d= atatracker.ietf.org/doc/draft-konda-agentproto-evaluation-state/
> >>> .
> >>> > > >
> >>> > > > We should settle which of 3.3.3 and 3.3.5 = carries the
> >>> unestablished-input
> >>> > > > case, and I'm happy to write the bulle= t for whichever section it
> >>> lands
> >>> > > in.
> >>> > > >
> >>> > > > Thanks,
> >>> > > > Girish
> >>> > > >
> >>> > > > On Sat, Oct 3, 2026 at 11:01=E2=80=AFPM ti= rumal reddy <kond= tir@gmail.com>
> >>> wrote:
> >>> > > >
> >>> > > > > Hi,
> >>> > > > >
> >>> > > > > "Agentic AI Use Cases and Requir= ements" draft
> >>> > > > >
> >>> > >
> >>> https://da= tatracker.ietf.org/doc/draft-agentic-ai-usecases-requirements/
> >>> > > derives
> >>> > > > > session (dialog) management, transpor= t and security requirements
> >>> from
> >>> > > use
> >>> > > > > cases reflected in A2A, MCP and deplo= yed multi-agent frameworks.
> >>> > > > >
> >>> > > > > Candidate use cases (Section 4) are:<= br> > >>> > > > >
> >>> > > > > a) Single agent invoking tools across= domains
> >>> > > > > b) Orchestrator delegation
> >>> > > > > c) Long-running delegated task
> >>> > > > > d) Multi-hop peer delegation
> >>> > > > > e) Group consensus
> >>> > > > > f) Mediator between agents and tools,= including translation to
> >>> MCP and
> >>> > > A2A
> >>> > > > >
> >>> > > > > The use cases are deployment-agnostic= , so no deployment-specific
> >>> use
> >>> > > cases
> >>> > > > > are included. Each use case lists its= session (dialog)
> >>> management,
> >>> > > > > transport and security requirements; = common requirements are in
> >>> > > Section 3.
> >>> > > > >
> >>> > > > > Thanks,
> >>> > > > > -Tiru
> >>> > > > >
> >>> > > > > On Fri, 2 Oct 2026 at 22:40, Orie <= ;orie@or13.io> wro= te:
> >>> > > > >
> >>> > > > >> Hi,
> >>> > > > >>
> >>> > > > >> This is the first in a series of = topics, as noted here:
> >>> > > > >>
> >>> > > > >>
> >>> > > > >>
> >>> > >
> >>> https= ://mailarchive.ietf.org/arch/msg/agentproto/3_WBraJwt-jwDpZYb3uUoCRMrA0/
> >>> > > > >>
> >>> > > > >> Please identify Internet-Drafts d= escribing existing systems,
> >>> > > protocols,
> >>> > > > >> use cases, or deployment models r= elevant to agentproto.
> >>> > > > >>
> >>> > > > >> Point to the sections that explai= n how users, agents, and tools
> >>> > > interact,
> >>> > > > >> what works today, and where inter= operability gaps arise.
> >>> > > Implementation and
> >>> > > > >> deployment experience will help u= s assess these contributions.
> >>> > > > >>
> >>> > > > >> The expected output is a set of c= andidate use cases, deployment
> >>> > > models,
> >>> > > > >> and supporting references for **U= se Cases and Requirements**,
> >>> > > together with
> >>> > > > >> deployment assumptions for the **= Reference Architecture**.
> >>> > > > >>
> >>> > > > >> Regards,
> >>> > > > >>
> >>> > > > >> Orie and Leslie
> >>> > > > >> agentproto co-chairs
> >>> > > > >>
> >>> > > > >> _________________________________= ______________
> >>> > > > >> Agentproto mailing list -- agentproto@ietf.org<= br> > >>> > > > >> To unsubscribe send an email to <= a href=3D"mailto:agentproto-leave@ietf.org" target=3D"_blank">agentproto-le= ave@ietf.org
> >>> > > > >>
> >>> > > > > _____________________________________= __________
> >>> > > > > Agentproto mailing list -- agentproto@ietf.org
> >>> > > > > To unsubscribe send an email to agentproto-leave@= ietf.org
> >>> > > > >
> >>> > >
> >>> _______________________________________________
> >>> Agentproto mailing list -- agentproto@ietf.org
> >>> To unsubscribe send an email to agentproto-leave@ietf.org
> >>>
> >>
>
--000000000000a99bcb065da607c3--