[Agentproto] Re: Sussing out points of disagreement on the charter

["Mirja Kuehlewind (IETF)" <[e-mail]>]

I said failure because even if this is no failure,  you probably want to handle in the same way as you always would need some kind of timeout to not get stuck. It sounds like what you want is an indication from the other end of how to set the timeout. I could image something like this already exists in the HTTP protocol but I don’t have a pointer at hand. Wouldn’t that be sufficient on the communication layer?



> On 12. Aug 2026, at 17:43, Sumit Ahuja <sumit=[e-mail]> wrote:
> 
> Mirja,
> 
> You are probably right about the venue and I will not press it. Most of what I described is generic and audit plausibly owns the rest.
> 
> One correction, because I think the framing would mislead wherever it does land. It is not a failure. Nothing failed, nothing errored, and nothing is malformed. The work was accepted, is live, and is legitimately pending. Failure handling is triggered by an event, and here there is no event to trigger on.
> 
> The generic handler for that is a timeout, and the reason I do not think it closes the case is measured rather than argued. In the same evaluation, running a horizon shorter than the completable-lifetime distribution of the work right-censored roughly three quarters of the long-running units, and the bias was not symmetric: it fell hardest on the parties holding the longest commitments, because they pay cost throughout and collect at completion. A requester choosing a timeout without knowing that distribution gets systematic false positives concentrated on exactly the work most expensive to abandon, or waits indefinitely, and cannot tell from the protocol which it is doing.
> 
> So the handling advice is sound for failures and produces a wrong answer here, which is why I raised it as something other than a failure rather than as a failure someone forgot to handle. Where it belongs is a separate question and I defer to you on it.
> 
> Sumit P. Ahuja
> Main Labs
> 
>> On Aug 12, 2026, at 11:29, Mirja Kuehlewind (IETF) <ietf=[e-mail]> wrote:
>> 
>> Not sure that is a relevant case for session management. Any request can fail due to various reason and you need to always handle that. There is something relevant to audit here but again I don’t think that is related to session or lifecycle management.
>> 
>>> On 12. Aug 2026, at 17:18, Sumit Ahuja <sumit=[e-mail]> wrote:
>>> 
>>> Mirja,
>>> 
>>> I sent a reply on this thread before yours arrived and it did not answer the question you actually asked, which is the sharper one.
>>> 
>>> Your test is what needs to be standardized to survive cross-domain rather than being an implementation choice. I think that disposes of most of the session-lifecycle question, and one thing survives it. Here is the concrete example.
>>> 
>>> A unit of work is accepted in domain A and executes in domain B. B admits it and never schedules it. Nothing is malformed, no error is returned, no timeout necessarily fires, and the work is live and legitimately pending for as long as anyone cares to wait. From A's side the session was accepted and is in progress. From B's side nothing has gone wrong. A cannot distinguish still working from never started using anything the protocol carried, because what the protocol carried was acceptance.
>>> 
>>> Not hypothetical. In a pre-registered evaluation I ran, two priority-based scheduling policies at heavy mixed load, as modelled in a discrete-event simulator, scheduled 1 of 107 compliant long-running units of work with zero preemptions and completed none of them at any injection level, including no injection at all. Every one was admitted. None was rejected, revoked, or errored. Within a single domain that is a scheduling result and an operator sees it by looking at the scheduler. Across a boundary it is invisible, because the only thing A holds is what B said, and B said yes.
>>> 
>>> Why it passes your test rather than being an implementation choice: whether B schedules the work is entirely B's business and should stay that way. Whether A can tell that it did not is determined by what the protocol permits B to state and requires B to state, which is nobody's implementation choice and cannot be recovered by either side unilaterally.
>>> 
>>> What that implies for scope is narrower than session lifecycle, which is why I think your uncertainty about the term is well placed. Two things: that an acceptance can carry what was accepted, and that entering a state a relying party may need to reason about produces something rather than nothing, so that silence afterwards is an attributable claim by a named party rather than an ambiguity. Not the states, not the transitions, not full session semantics. That lands close to Rob's observation that the authority lifecycle is hard to avoid while full session semantics may be more than needed, arriving from a different direction.
>>> 
>>> One disclosure, since you are carrying the AUDIT charter prep and I would rather name the overlap than have you find it. I raised the adjacent version of this on agent2agent, that an evidence model built on events cannot express a commitment that was granted and never honoured. I think both cuts are real and they are different: AUDIT's question is what a record must contain, this one is what a protocol must carry. I have no view on whether either should wait for the other.
>>> 
>>> On separating proof of binding out to another working group I have no measurement and will leave it to Rob and others.
>>> 
>>> Sumit P. Ahuja
>>> Main Labs
>>> 
>>>> On Aug 12, 2026, at 10:05, Mirja Kuehlewind (IETF) <ietf=[e-mail]> wrote:
>>>> 
>>>> Hi Suresh, hi Rob, hi all,
>>>> 
>>>> I think all the points discussed below are needed in some way, but the real questions is: what needs to be standardized?
>>>> 
>>>> I think the correlation bit if the most important piece here that we identified as needed for inter domain workflows (without providing a clear definition of “workflow” at this point). Yes, proof of binding is needed as well but maybe we can separate this out and rely on existing (or new) work of other working groups?
>>>> 
>>>> On the session lifecycle question: Initially I thought this is the main piece but the more we talk about it, the less I’m actually sure what we mean. Do people have concrete examples what is needed, and again more importantly, what needs to be standardized here to survive cross-domain rather than just being an implementation choice?
>>>> 
>>>> Thanks!
>>>> Mirja
>>>> 
>>>> 
>>>> 
>>>>> On 12. Aug 2026, at 09:01, Rob Zagarella <[e-mail]> wrote:
>>>>> 
>>>>> Thanks for pulling these into focus - it really helps. Let me offer a perspective on a few of them from the angle of having built an implementation, which mostly means I've run into where these questions bite in practice rather than in principle.
>>>>> 
>>>>> On 1 (substrate vs semantics): the thing we kept running into is that shared semantics get two parties to agree on what they mean, but the guarantee that actually matters to a third party - being able to check that an action really did chain back to an authorised origin - isn't something semantics alone can carry. I don't think that means the charter has to pin a wire format; I've just found it hard to get interop to hold without committing to enough substrate to carry a verifiable binding, not only a shared vocabulary for describing one. Curious whether others have found a way to keep it purely semantic and still get that property.
>>>>> 
>>>>> On 3 (correlation vs proof of binding): this is the one I feel most strongly about, and I'll admit that's partly because it's where our work lives, so please weigh it accordingly. Correlation associates messages; what we found we actually needed was the ability for a relying party to verify that an action was authorised by, and stayed within the bounds set by, a defined origin - without having to trust either endpoint. Correlation didn't survive a dishonest or compromised participant in our testing, which felt like precisely the case the whole effort exists to cover. I'd genuinely like to be wrong about this if there's a lighter path, but I haven't found one - and it's the reason we ended up building a verified human at the root with each downstream action sealed and independently checkable against the authority it derives from. Happy to share what broke when we tried the lighter version.
>>>>> 
>>>>> On 2 (session lifecycle): the part that's felt unavoidable to us is the authority lifecycle specifically - issuance, continuation when contact is lost, revocation - which is exactly where the recent issue #49 thread has been converging. Full session semantics may be more than needed; the authority lifecycle has been hard to avoid.
>>>>> 
>>>>> On 6 (terminology): the small set the trust model rests on - authority, binding, continuation bound, resolution path - seems worth defining carefully, mostly because in our experience these are the words where a loose definition quietly turns into a security assumption. The continuation-bound thread this week is a live example of how much these particular terms reward precision.
>>>>> 
>>>>> On 4 and 5 I hold my views loosely - bilateral seems a reasonable starting scope as long as the binding model doesn't assume it, and sequencing a minimal binding-capable core first feels natural, but I'd defer to people closer to those pieces.
>>>>> 
>>>>> If it's useful to ground any of this in something already built rather than argued, I'm very happy to contribute text on the binding and authority-lifecycle parts - there's running code and a draft behind the position, and I'd rather it be pressure-tested than taken on faith.
>>>>> 
>>>>> Roberto Antonio Zagarella
>>>>> Violet Shores - VAC Protocol / Athena
>>>>> draft-zagarella-verified-human-root: https://www.google.com/url?q=https://datatracker.ietf.org/doc/draft-zagarella-verified-human-root/&source=gmail&ust=1786604005674000&sa=E
>>>>> draft-zagarella-autonomy-governor: https://www.google.com/url?q=https://datatracker.ietf.org/doc/draft-zagarella-autonomy-governor/&source=gmail&ust=1786604005674000&sa=E
>>>>> 
>>>>> On Wed, 12 Aug 2026 at 06:19, Suresh Krishnan <[e-mail] <mailto:[e-mail]>> wrote:
>>>>>> Hi all,
>>>>>>   We have received a lot of great comments during and after the BoF on the charter [0]. After the Bof, Brian [1] and Jonathan [2] have taken a shot at rewriting a more streamlined charter from the ground up based on the comments received. Since these are complete rewrites, I think we may have to dig in a bit deeper to see where the points of disagreement are. From my reading of these two proposals and the comments on github, these aspects seem to be some of the questions that we need to answer before we can work on more focused edits on the charter
>>>>>> 
>>>>>> 1. Is the output of the working group a substrate or only a set of semantics?
>>>>>> 2. Should the session lifecycle be in scope?
>>>>>> 
>>>>>> 3. Do we have to work on correlation only, or do we need proof of binding as well?
>>>>>> 
>>>>>> 4. Do we need to support point-to-multipoint or is bilateral communication sufficient?
>>>>>> 5. How many deliverables, what status, in what order?
>>>>>> 
>>>>>> 6. How much of the terminology should we define in the charter, and on the flip side how comfortable we are building on vaguely defined terms?
>>>>>> 
>>>>>> Are there other things we need to consider? Your inputs are greatly appreciated. 
>>>>>> 
>>>>>> Thanks
>>>>>> Suresh
>>>>>> 
>>>>>> [0] https://github.com/ietf-artarea/charters/blob/main/agentproto/charter.md
>>>>>> [1] https://github.com/ietf-artarea/charters/pull/77/
>>>>>> [2] https://github.com/jdrosen/aiproto-wg/pull/48
>>>>>> 
>>>>>> _______________________________________________
>>>>>> Agentproto mailing list -- [e-mail] <mailto:[e-mail]>
>>>>>> To unsubscribe send an email to [e-mail] <mailto:[e-mail]>
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> 
>>>>> _______________________________________________
>>>>> Agentproto mailing list -- [e-mail]
>>>>> To unsubscribe send an email to [e-mail]
>>>> 
>>>> _______________________________________________
>>>> Agentproto mailing list -- [e-mail]
>>>> To unsubscribe send an email to [e-mail]
>>> 
>> 
>