[agent2agent] Re: [iesg] BoF request process and status [was: Re: bofreq-kuhlewind-agent-use-of-delegation-and-interaction-traceability-audit response]

[Roman Danyliw <[e-mail]>]

Hi Mirja!

I wanted to directly respond to this request:

> Anyway, I would really like to request the IESG to clarify the process here (in written form).
> We had so many discussions about support for new work in leadership and making at
> least the BoF process clear (not only the wording but also the two-dealing process) would
> already be an important step, I think.

Documentation on the process the IESG uses to manage BOF requests is found at https://wiki.ietf.org/group/iesg/bof-coordination-meetings.

Roman


From: Mirja Kuehlewind (IETF) <ietf=[e-mail]>
Sent: Monday, June 8, 2026 11:32 AM
To: Deb Cooley <[e-mail]>
Cc: [e-mail]; Henk Birkholz <[e-mail]>; Pamela Dingle <[e-mail]>; [e-mail]; The IESG <[e-mail]>
Subject: [iesg] BoF request process and status [was: Re: bofreq-kuhlewind-agent-use-of-delegation-and-interaction-traceability-audit response]

Warning: External Sender - do not click links or open attachments unless you recognize the sender and know the content is safe.

Hi Deb,

Thanks for your quick clarification. Actually, in my memory the wording used in the BoF coordination calls hasn't been that clear and I can remember multiple short discussions about this as different people used different wording. However, what’s visible to the outside is the status in the datatracker and if “deferred” is the agreed wording that that should be reflected there. But in my personal opinion that wording doesn’t reflect the actually process correctly as the IESG can only decide if a BoF is accepted for a specific meeting or not and than it’s on the proponent to send a new, separate request for the next meeting. While “defer” seems to me to imply that it will be automatically considered for the next meeting or something…

Anyway, I would really like to request the IESG to clarify the process here (in written form). We had so many discussions about support for new work in leadership and making at least the BoF process clear (not only the wording but also the two-dealing process) would already be an important step, I think.

Also I think this process needs more transparency, which is also why we decided to reply in public. The feedback we got as proponents is effectivly not after all not only directed at us but the community who is interested in this work and some of the questions simply need more community discussion. But also generally being transparent about communications that happens between the IESG and the Bot proponents would, I think, help the community to better understand the BoF process which seems a bit of a black box right now.

Happy to discuss this more with anybody from the IESG in Vienna (or before this)!

Mirja



On 6. Jun 2026, at 01:45, Deb Cooley <[e-mail]<mailto:[e-mail]>> wrote:

Just a quick note:  Defer is the word I've heard used for 2+ years when a BOF is not taken up for the current meeting cycle.  I guess we could have said your request was declined, but defer is the word I've seen used.

Deb


On Fri, Jun 5, 2026 at 4:57 PM Mirja Kuehlewind <[e-mail]<mailto:[e-mail]>> wrote:
Hi Deb, hi Chris,

Can you clarify what you actually mean by “deferred”? From my understanding (and the datatraker states) you can either accept or decline a BoF request. If the BoF request is declined for his meeting, the proponent can decide so submit, or not, a new request for the next meeting. Or does “defer” imply something else from your side?

Also my understanding of the two stage BoF deadline was that one could work on questions like your below in the two weeks in between for BoFs that are a promising but may not be quite clear yet (maybe this what you mean with “deferred”?). Before we had the two deadlines, especially for proposals that came in shortly before the deadline, there was no change to coordinate with the proponents and therefore one could only do a yes/no decision. Therefore the second deadline was introduced to have time to reach out and clarify things. However, this seems a bit late now give the second deadline is today and we received your input only recently. And it also seems you already made a decision without further exchange with us. If this understanding of the two BoF deadlines is not the intended process, we would like to request the IESG to clarify the process and intention of the two deadlines (maybe in an IESG statement)!

See below for answers to your questions.



On 3. Jun 2026, at 11:51, Deb Cooley <[e-mail]<mailto:[e-mail]>> wrote:

Mirja, Henk, and Pam,
The  Agent Use of Delegation and Interaction Traceability (AUDIT) BOF request is being deferred.

While the concept of auditing the actions of an agentic agent is a good concept, the current proposal is too broad.  The intent/policy concepts work better in a legal framework - not at the IETF.

The issues that need work:


1.      Objective: What question would be answered?  (Is the AI model operating correctly? Is its training data of proper provenance?  Are the actions correct?).  Polish what is ‘in scope’ and what is ‘out of scope’.  Be precise and concise.


You asked the question of what’s the gaol of auditing. However, that’s not the problem we try to solve. The objective of auditing are the same as today (effectively it needs to be flexible enough to address all of these cases). The problem we motivate in the BoF request and proposed charter is that today auditing systems are not able to capture all actions and relevant events for complex multiple domain (semi-)autonomous systems. The intention is to design a flexible system that further is able to evolve over time (by adding new record types on a need bases for different use cases and trust requirements) as these system are quickly evolving.

We also further clarified this in the proposed charter based on comunity feedback by adding the following sentence:

"The group will work on the minimal set of audit information and consider a registry to enable experimentation and fast deployment for additional data models.”

See here: https://github.com/mirjak/audit-bof-preparation/pull/21/changes



2.      Privacy: There are undoubtedly privacy issues in the audit space where the control of privacy in the face of 'reasoning traces' will be very difficult.  This is especially problematic when the concept of transparency logs is added.  It is better to build privacy in vice bolting it on later.

Yes, we absolutely agree that privacy is important and we need to consider it from the beginning. This was always the intention and we also had multiple people making the point that privacy is important and one of the core poinst for the working group. For me that is also one strong reason to have this work in the IETF because I think the expertise here is high! However, we wouldn't be able to address this entirely before chartering but based on the community feedback we added this to the charter explicitly, see here:

https://github.com/mirjak/audit-bof-preparation/pull/12/changes

Can you further specify the privacy issues you mention specifically for transparency logs?




3.      Audit protocols:  There are many places that audit protocols are being worked on - OCSF, CADF, OpenTelemetry.  It isn't clear whether this 'protocol' is targeting a new protocol or profiling existing work from other forums.

If you look at the architecture document as well as the charter, we don’t really aim for much of new protocols here. It’s about data models and extensions/profiles to existing (IETF) protocols (but OCSF could be used as well). We are also looking into OpenTelemetry and believe that the proposed audit architecture could be adopted there, as the identified challenges with existing logging apply. But that is an on-going effort. Specially OpenTelemtry came up multiple times in the discussion already and we respectively added the following sentence to the charter to explicitly address this:

"The working group may also define protocol-independent data representations intended for use by non-IETF logging, telemetry, or audit systems, while avoiding standardization of those external systems themselves.”

See here: https://github.com/mirjak/audit-bof-preparation/pull/21/changes




4.      Interoperability: The core of the IETF mission.  Please state the interoperability requirements, advantages and rationale (especially in the face of privacy concerns).

The charter says the following:

"Cross-domain interactions lack interoperable means to exchange or verify audit-relevant information about the participating agents and their interactions”

I’m not fully sure what you mean by interoperability requirements though? Isn't interoperability a requirement in itself for a proposal?




5.       Community: Where is the community related to this effort and are there implementers?

On the agent2agent mailing we already got a lot of positive feedback from people who are interested in this work, have a problem to solve, and would like to implement it. So it seems quite clear that there is a relevant community in the IETF. Further, we are currently (in preparation of a Bof) reaching actively out to more people who may have very concrete use cases and might be interested to implement. However, this is for me the main question to answer to have a BoF where we see who shows up and speaks up.





6.      Contrived linkages:

scitt: It is unclear to us why scitt - a software supply chain protocol - is useful here.  There are multiple examples of transparency systems - Certificate transparency, key transparency, and the SCITT transparency.  Why is scitt the right choice?  And what value does yet another transparency system offer here.
Certificate and key transparent do not apply as they are very specifically only addressing certs and keys. However, SCITT is a bit more generic as that it logs “signed statements” for "compliance”. We thought this is actually a reasonable match and therefore we could re-use that work and maybe specify a profile. We also send our BoF proposal of that reason to the scitt list and got at least one positive reply. However, we hope to have more discuss there.

Further, your question, listing those three examples for transparency logs in one go, already indicated that we should maybe not reinvent the wheel every time we need a transparency log. So again, we are really hoping to reuse as much as we can of existing work. This overlap with existing work in the IETF is for us a strong reason to have the work in the IETF. But I guess that is another BoF question to answer during the BoF.




rats: We can think of no reason why rats is mentioned.  The attestation of software doesn’t really seem to be in scope for rats.
RATS Attesters demonstrate that the audit-logs themselves are compliant (instead of a "trust us" self-assertion) and any environment running an autonomous system (AI agent) can take on an Attester role, include the record generating code into its TCB and demonstrate that the records are created in a believable manner. This is a starter scenario to keep the scope tight, but other scenarios are of course possible. The agent itself can be part of the TCB and thereby provide Evidence about tool calls, authentication events, and trustworthy workload identity provisioning directly where it happens. If confidential compute is involved, geo-location, spawning of sub-agents, and capabilities, such as key or platform attestation can be demonstrated via Evidence in a scalable manner. All these facets complement a robust audit framework where the results become part of the audit-log made transparent via a SCITT Transparency Service (e.g. Microsoft Signing Transparency).




vcon: We are unfamiliar with this work, why is it being mentioned?
VCon works on conversation records (see here: https://datatracker.ietf.org/wg/vcon/about/) At the last joint dispatch/secdispatch meeting Henk presented Verifiable Agent Conversation Records - VACR (https://www.ietf.org/archive/id/draft-birkholz-verifiable-agent-conversations-00.html) The VCon authors highlighted that it would be a perfect fit for their VCon Core desgin and Henk is currently working with them to create and align VCon CDDL to enable the use of VACR as a VCon extension. VACR is a candidate for the conversation record (representing an agent trajectory), as mentioned in the BoF request.





Way forward:

Spend some time tailoring this BOF request into a more polished request - scope it down to an achievable idea. We do recommend that the proponents spend a fair amount of time understanding the work that both oauth and wimse working groups do.  Those working groups should be consulted on a regular basis. Consider whether a profile of OpenTelemetry created within the OAUTH and/or WIMSE working groups might not fill the need.  If it won't, be prepared to explain the gaps.  A clear, distinct problem(s) statement will likely lead to a much stronger proposal.
Can you clarify a bit more what is not clear in the problem statement? Your points below didn’t really address the problem statement itself, except maybe point 1 but I hope I could clarify the misunderstanding of scope a bit more now.

As you can see, we already continued to work on the charter based on the community feedback that we got so far on the agent2agent list. We also looked into oauth and wisme, however, we don’t think this kind of work would be in scope for these groups and are now really surprised by this proposal. Oauth is just recharting and does a lot of good work that we would like to related to in order to audit authorization and delegation decision correctly, however, that is only a small part of the needed auditing. Creating a OpenTelemetry profile in outh or wimse seems an extremely wide stretch for their charters.

However, if that is what the community input would indicate during the BoF that is also a possible outcome. This would not be the first BoF where the outcome is not a new groups but work in existing groups. However, we believe this work is definitely broader than this and we believe a BoF would be very value to explicitly answer the question about community interest and relation to the IETF (or other works) before a group is chartered. That's also what the community feedback indicated to us so far and why we decided to put in a BoF request (rather than going to dispatch).

Mirja & Henk & Pam







Gather the community that is interested in implementing the protocol or idea you are proposing.



If the proponents would like a mailing list for this work, we would be happy to help with that.

Deb and Chris
Sec ADs