IETF Meeting Minutes

Session Date/Time: 30 Jun 2026 14:00

Jim Mozley: Good morning.

Sean Turner: Morning.

Jim Mozley: Good morning. All right, it’s, it’s time. So, let’s get started. Um, Rafat, do you want to um, show, show yourself as well? I don’t know, just kind of to introduce the chairs?

Rifaat Shekh-Yusef: I am having some technical difficulties here getting the video going, so I’m not sure I can show myself. Can, can you hear me?

Jim Mozley: Uh yes, we can hear you. That’s fine.

Rifaat Shekh-Yusef: Yeah, I’m not sure what, what’s going on with the video here though, sorry.

Jim Mozley: Oh, well, that’s all right. You’re, you’re showing your, you’re showing yourself in terms of the icon anyway, so. Um, so, let’s, let’s get started to try and use everybody’s time well, and we have a, a reasonably, uh, reasonably busy agenda here. Um, I assume that’s, uh, Jaime, uh, you might want to turn your camera off for a few minutes, please, just not to distract people.

Jaime (장동호): Oh, sure. Uh, but there is some network problem, so I cannot activate my camera.

Jim Mozley: Your, your camera is, your camera is on right now.

Jaime (장동호): Oh, really? Can you see me?

Jim Mozley: Yes, we can see, we can see you. So, yeah, just please click the, the little green camera at the bottom of the screen for now, and, and we’ll, uh, we’ll get started with the chairs’ slides first.

Jaime (장동호): Okay, request slide.

Jim Mozley: No, no. No, no. Yeah, the—

Rifaat Shekh-Yusef: Don’t share. Don’t share.

Jim Mozley: Don’t share slides.

Jaime (장동호): Okay, okay, okay, okay.

Rifaat Shekh-Yusef: I’m going to—how about that? Now, now, his video is gone. Go ahead.

Jim Mozley: Okay, great. Um, well, well, thanks, everybody. Um, uh, let’s, uh, let’s get started with the agenda here. Uh, first of all, as usual, we’re going to, uh, note the, the Note Well. And, uh, we’ll talk about this for a little bit because, uh, I think there are some people here that are, are not entirely familiar with the, the IETF processes, and, uh, you should probably, uh, there’s a QR code there, and there’s, there’s some information, uh, here about what the, uh, uh, the different RFCs are. But, in general, uh, you’re expected to, uh, behave professionally, um, uh, you know, no, uh, harassment or, or other inappropriate behavior. We want, we want people to, to be professional. Um, all of your, your, uh, contributions to IETF, including your commentary in meetings like this, is covered by the, uh, rights contributors provide to the IETF Trust in RFC 5378. So, um, uh, you, you need to, if there are any things that are covered by patents and so forth, you need to disclose that, or you need to not participate in the discussion. Um, we’re, uh, very, very careful about intellectual property rights, and we want to make sure that everyone is transparent about that. Um, uh, there are, uh, there is some more detail about the, the way that our Internet standards process works in RFC 2026 and 2418, um, uh, and, and various updates to those. And, uh, also, this session is being recorded. Um, if you, uh, make, uh, commentary either written or, or verbal in this session, uh, if you, uh, have your, your video on or anything like that, that information is able to be shared as set out in the, in the privacy statement. So, if you have any questions about that, please talk with me or one of the other, one of the other working group chairs, or one of the Area Directors, um, and, and we’ll, we’ll try and clarify it further. But, we want to make sure that everybody is on the same page with that, uh, at the very beginning of, of this session especially. So, um, [cough] interim meeting to in-person participants is not applicable. Um, but, please make sure that your audio and video off are, uh, are off unless you’re chairing or presenting. Uh, of course, you can, you know, if you’re, uh, uh, if we’re in the discussion phase, and you’re in the queue, and, and, and get recognized, you can, uh, feel free to turn your audio and video on. Um, and we recommend the use of a headset, even though you don’t see me with one right now, it’s, I’m in a fairly quiet place. Um, please also state your name and, uh, uh, perhaps your affiliation if that’s relevant, uh, each time you begin speaking, just so that the people that are just listening to the audio and don’t have people’s, uh, voices, uh, cataloged can, uh, understand who you are. So, the focus of this session is to take various proposals that people have brought to IETF, and to, and to answer the dispatch question. Uh, and, here, here are some of the options that are available. We can, uh, uh, recommend a, a, a working group that exists, that, that maybe the work should go to, um, can think it’s appropriate to propose a, a, a new, a new working group, hold a Birds of a Feather session, um, there’s a, a, a track known as, uh, uh, Area Director sponsored, if the Area Director is willing, to, that, uh, publication can be done through as well, um, or there might just be need for more additional discussion, like a, a, a new mailing list or, or something like that. Um, another possibility is, is that people might say that this is really not appropriate work for IETF, for various reasons. Um, so, that, that’s really the focus of the session. We’re mostly engineers here, and we’re all excited about the technology, but what we need to do is focus on just covering as much of the, as much of the technology in order to frame the nature of the work. Please don’t get into, into details of, of exactly all of the nitty-gritties of, of the technology, because we won’t have time to do that, even though it’s fun. So, uh, we’re really focusing on answering the, the dispatch question here. And, so, here are the, the sessions that we have. Um, there are a couple of these, uh, at this point, um, number two and, uh, number six, that we don’t yet have any slides for, and, um, so, we will, we will table those, at least for the time being, um, and probably, probably not cover them at all, but we will jump between, we will jump from one to three to four to five, um, in this. Is there any further agenda bashing that should be done?

Jaime (장동호): Well, can we submit the files? The slide?

Jim Mozley: Um, yes, uh, we, we asked for the files, we asked for the slides yesterday, but, um, if you’ve got the, if you’ve got the slides, uh, one of the chairs will, will, will try and, we’ll try and get those up, and we can perhaps add them in at the last minute here. But, I mean, you need to have slides in order to make a presentation. Do you know how to do that?

Jaime (장동호): I have slides, but I don’t know where to send them to.

Jim Mozley: Uh well, there’s a, there’s a place on, on Datatracker to, to submit slides for the presentation. Otherwise, uh, you can email them to dispatch-chairs@ietf.org.

Rifaat Shekh-Yusef: I’ve just shared the link in the chat there, so go to that link.

Jim Mozley: Oh yeah, that’ll, that’ll work too. Is that all right? Okay. Let’s, uh, let’s move on to the, uh, on to the first presentation, TTTPS: Pre-Ingestion Proof of Time, uh, by Jaime Jorgan, and, uh, Jaime, you, we have a choice here. Uh, I can share the slides for you, uh, and give you control. That’s probably the smoothest thing to do, um, or, or you can share the slides. Your choice.

Jaime (장동호): Oh, please share my, uh, slide, and then—

Jim Mozley: Okay. Hold on, just a second.

Jaime (장동호): Okay.

Jim Mozley: Oh, okay, you just asked to share slides, which—

Jaime (장동호): Oh, I, I just, I just, I shared the slide to, to your, control to you. Can you—

Jim Mozley: Okay.

Jaime (장동호): Oh, thank you.

Jim Mozley: Okay, there you go, uh, you’ve got 15 minutes, which includes discussion, so please go through your 10 slides fairly quickly. I think we discussed that.

Jaime (장동호): Okay. Hello, everyone. Uh, it’s honor to join this IETF fellows’ meeting. I’m Jaime Jorgan. Uh, today, I’m presenting TTTPS: Pre-Ingestion Proof of Time for AI Agent. To put it simply, TLS proves who, and TTPs adds a verifiable proof of when, sealed before a record enters any system. Uh, next slide, please. And, let’s look at the core issue. Today’s time attestations is entirely self-attestation. Systems attest their own timestamp, meaning nothing proves when a record was actually sealed, and backdating remains completely undetectable. This is the exact gap TTPs closes. And, regulations like EU AI Act, and MIFIR, and FDA 21 CFR Part 11, all point at this exact same security gap. And, next slide. And, to be clear, the lineage of this work comes from signal integrity, not cryptocurrency speculation. We are moving principles established by Marcel Golay in 1949, the same error correction discipline used in the deep space missions like Voyager, Mars, and Cassini, and applying them strictly to time. This is pure engineering, not speculation. And, next slide, please. And, this is our core concept, pre-ingestion sealing. We seal the data at the exact moment of generation, before it hits ingestion. Traditional mechanisms like, uh, rfc3161, act as a post-detection, it’s, uh, by combining rfc3161 consensus with, uh, Ed25519, is backdating is cryptographically excluded, with a forgery probability of, uh, p less than 2 to the -128. And, next slide. Our architecture relies on three components, wrapped into a single record, with zero changes required to the underlying transport. As shown in the matrix, time utilizes rfc3161 consensus with no single operator. The logic relies on G-Score, G came from the Golay, and the synchronization happens via the GRG stack, uh, Golay, Rice, and Golay code, and HMAC. And, finally, the sealing utilizes TLS exporter, RFC 5705, achieving robust session binding without introducing any new extensions. And, next slide, please. And, we want to be entirely direct and honest about our deployment status. We have no confirmed production deployers right now. And, Section 15.4 is strictly a placeholder. However, we have solid experiment evidence. Our running code has processed almost, uh, over the 70k of the proof of time record, with the 55% of the AI-originated, with average performance metrics of, uh, uh, 47 milliseconds in turbo mode, and a 127 milliseconds in a full mode. Besides, as a concrete milestone as of today, June 30, 2026, IANA has provisionally registered the TTPs in URI scheme. You can find it listed in the official registry today. And, next slide, please. And, we have the exact same mathematical standards to our protocol design that we apply to the data itself. Our adaptive switch mechanism is fully verified in TLA+, with all invariants machine-checked. And, the G-Score logic is formalized in Coq, and is completely sort-free, turning our protocol claims into a formal proof. And, to be clear and honest, these machine-verified properties applies only to the lean and TLA+ models. And, next slide, please. And, the massive demand we are seeing is entirely regulatory-driven for now, spanning the EU AI Act, and MIFIR, and the FDA 21. TTPs seals the record to satisfy Section 11.10(e), while the KL improves the computation for Section 11.10(a). This target critical vulnerability windows in AI lifecycle, such as, uh, corpus poisoning, and the AI training data, supply chain insertion, and agent memory backdoors, as outlined in Appendix E.6. TTPs injects security right at the pre-ingestion phase, delivering object-proof rather than the just compliance policy. And, next slide, please. This brings us to our explicit ask for the dispatch community. We are presenting a well-defined temporal origin primitive with a formal spec, a RAND IP disclosure on the VCP 79, and open running code. And, for interoperability, Section 6.1 defines an abstract interface, and Section 6.3 establishes the observable external properties. And, following the precedent of RFC 8915, Section 6, two independent party can fully interoperate without needing to share or open source their internal our GRG implementation. Our target is an experimental RFC. So, and, we are not asking for the immediate endorsement of the technology itself, and, uh, we are asking the chairs and the room for the, uh, right reviewers for our draft. And, next slide, please. We already have a running code. Our experimental deployment on Basephelia has generated, generated more than 70k verified proof of time records, is proving the practical viability of the protocol. And, considering its experimental nature and our current patent status, we believe this independent submission track via the ISE is a very realistic and efficient alternative for issuing an experimental RFC. So, our explicit ask to the, uh, dispatch and, seek dispatch community today is for a expert review, specifically on our security consideration and abstract interface, and to ensure that the community sees no conflict, no conflict with ongoing IETF work, so, we very welcome any interested or reviewers to step forward. Thank you.

Jim Mozley: All right, then. Great, and, uh, we have a, we have a couple of people in the, in the, in the queue already, uh, so, uh, uh, go, go ahead, Muhammad.

Muhammad Usama Sardar: Okay. Thank you, chairs. Um, I would like to understand what exactly you mean by exporters. There are two kinds of exporters that’s provided by TLS, one is the early exporter, one is the standard exporter, and it really makes a lot of difference, I would say, to where this work would land because if you are kind of trying to do something within the TLS, it’s going to be, or going to go to TLS working group. If it’s going to be just using TLS exporters, it’s going to be somewhere outside of the TLS. So, first of all, I don’t see any connection why you specifically need TLS. Is there any plan to do it within the TLS handshake protocol? If yes, why, why, and what’s the need for doing that?

Jaime (장동호): Oh, yeah. So, why are using the TLS exporter is, uh, TLS, uh, TLS exporter is, uh, proves the, what content’s hash and ID, right? So, I, I seal with, uh, our proof of time record, uh, with the Ed25519, and this allows to the integrity, integrity of the whole session, and, uh, uh, also, manipulate, uh, integrity as well. That’s why I use, uh, TLS.

Muhammad Usama Sardar: Okay, so, so, just to say, I, I think it has no connection to TLS then. It could be ad-hoc protocol, you could do export, you, you could export from any protocol, that’s what I was trying to understand, so this doesn’t fall in TLS. Uh, very quickly, I would ask also from attestation perspective, so, I think it falls somewhere in RATS or in COSE. So, there are two working groups already where, which you could explore, uh, but I don’t have much understanding. Thanks.

Jaime (장동호): Okay, thank you.

Jim Mozley: Okay, Ekkar, you’re next.

Eric Rescorla: Yeah, hi. Uh, we exchanged some emails on this on the list. Um, I, I guess I’m pretty skeptical of both the value and the security properties of this, but that actually doesn’t matter at this moment, because if you want to take it to ISE, you can just do that, and so you don’t need anything from us at all. And so, um, I do not think any IETF action is warranted here, and I think you should feel free to take it to ISE, though, in my opinion, ISE should not publish it. Okay.

Jim Mozley: Uh, okay. And, um, I, just, just kind of to channel a little bit of, uh, what I’ve seen going on in the, um, in the, in the chat session, uh, there, there has been a, a suggestion that maybe a mailing list is appropriate in order to, uh, discuss this further, uh, it, you know, the, further discussion, uh, doesn’t really belong in the, in the dispatch or sex-dispatch list themselves, but, um, uh, you, you know, that, that is a, that is a potential option. Um, but, um, uh, if you’re going to the ISE, that’s probably not necessary.

Jaime (장동호): Well, thank you. Thank you for the guide.

Jim Mozley: Okay. Um, any other, any other discussion on this? All right. Um, thank you, Jaime. Let me, uh, change the deck here. Uh, we do not have a presentation for Artificial Intelligence Internet Protocol, so we’re going to be going, uh, directly to Secured Digital Lifecycle Protocol with Mark Norton.

M. Norton: Thank you. My name is Mark Norton, and I’m presenting the Secured Digital Lifecycle Protocol. This protocol is actually a protocol that applies physics to digital products, making them expire kind of like physical products, where you know what you’re getting before you buy it, and then, if you share with somebody, you’re giving up half of your, uses or half of your product to the person that you’re sharing it with. And by this happening, and doing so, eventually the product expires, making it harder to pirate. Mark, can I interrupt for a second? Do you have something in, some background noise or something like that? We’re hearing some, something, maybe a radio or television or something. All right, let me get that. Is that better? Yes, it is. Thank you very much. You’re welcome. Now, with this protocol, what it does is once a product is purchased or downloaded, it is assigned an individual product ID which stays with it throughout its whole life. And then, if you copy the product, the file, what happens is an appended child number is added to it, maintaining an individual ID but still, still address where it originated from. That way, somebody sharing, you’d, you’d still be able to track who’s out there illegally sharing the files. Mark, are we still on your title slide, or do you want me to advance the slides here? No, yeah, advance the slide, please. I’m not sure we— It looks like you’re through all of this. Yeah. No, okay, on its, individual ID, it consists of the distributor ID, customer ID, product ID, and product name, a download ID, date and time stamp, which will make the individual ID of the product. And then, as you copy the product, it also incorporates a child ID, so it’ll be like on, at the end of the date and time stamp, it’d have a .1 if it’s copied to a child, maintaining its individual ID pattern. Um, an upload is treated just like a copy, therefore, it loses half of its uses as it’s uploaded as well. On the objective, the objective is for it to add another layer to the stack. Do you have a headset or something that can, mute some of the background audio? Right, let me try. Sissy, I’m in a meeting. All right. I’m sorry. Okay. Are we on the right slide still? Yeah, next slide, please. Um, who is this for? It’s for anybody that sells or or distributes digital prod- products or content. Um, I know a lot of, I know there’s some people that are confusing this with like NFT or blockchain. This is not blockchain, it’s not DRM. Um, vendors needing verifiable provenance across multi-hop distribution would use this. Um, as I said, any distributor of digital products. Um, this is a self-contained security protocol is what it is, not using any outside sources for security, which is where all the other current security forms seem to get things wrong, as they leave open that window for hackers and crackers to get into. And as I said, this is completely on-board security, whose main purpose is to protect the content it’s securing, because an SDLP file would much rather kill itself, so to speak, in doing a bit drop than be exploited. You can change the file, the, the slide, thank you. My hope dispatching outcome is to be assigned to a working group, be in a BOF, or an already contained working group. Um, preferably, something looking in the lifecycle semantics. Okay. And this is, this is just the last slide, so. Yeah, this here, it defines legal states and enforces environment validation before use. Now, I wrote this protocol in hopes of it being another layer for the stack in between the, the transport layer and the applications layer. SDLP works in between the two, so even before an application touches it, it already knows how many uses it’s got, it knows who created it, it knows how many lives it’s got, or how many uses it has in its lifecycle, and it only knows what, how many uses it received, and it knows what rules to follow it by, like a child, a child file doesn’t know how many uses the original file came with, it only knows what it received, and the rules it must live by.

Jim Mozley: Okay, we’ve got a couple of people in the, in the queue now, so, thank you for your presentation, and, uh, Ted Hardie is first.

Ted Hardie: Uh thanks very much, uh, Ted Hardie, uh, no affiliation. Uh, I think the dispatch outcome here should be no action. Uh, the drafts as presented don’t have enough technical detail to really evaluate, and the binding to IETF work is is quite seriously unclear. Um, especially if the intent is to create a layer between uh the transport layer and the application layer, we would need to see a great deal more uh at least from the application side on how we were meant to consume this, and I think on a transport binding as well. So, I think at this stage, this is not mature enough to to bring into the process. Thanks.

Jim Mozley: All right, thank you. Uh, Rich Salz.

Rich Salz: Uh, yeah, hi. Um, hi Mark, sorry. Um, yeah, I know I, I appreciate because we corresponded offline about the struggles you had to get this through to the properly formatted and all of that. Um, is this, is it fair to say that this is one way an architecture for looking at uh rights management and control?

M. Norton: It’s not rights management because, I mean, I guess you can say it’s rights management because an SDLP object knows what it is or isn’t allowed to do. It’s not something that you got to write separate for a person to argue about, because the object knows what it can or can’t do. As I said, it knows what rules it has to follow.

Rich Salz: Yeah, but so one could take a program that follows those rules and strip out the code that checks those rules and therefore, I mean, there’s nothing inherent in here that controls the use of the information you have to obey the the rights management that’s embedded in the SDLP token. Is that correct?

M. Norton: Well, then, if somebody were to try and do it, then it triggers a tamper guard which then the file does a bit drop because, as I said, it would rather expire itself than be exploited.

Rich Salz: Um, okay. If it’s a file on a, okay, um, I’m not sure how a file does any actions if it’s just a collection of bits on a storage media, but okay.

Jim Mozley: Okay, uh, Ekkar, you’re next.

Eric Rescorla: Yeah, I, I, I think, you know, we could debate the technology here, but I don’t see any clear nexus to IETF work, um, and, um, and on the basis of these slides, I don’t see any evidence that like anybody is asking for an interoperable standard here that the IETF could specify, so I think the right answer is we do no action at all. Um, no, no working group, no BOF, no mailing list.

Jim Mozley: Okay, thank you. Kathleen?

Kathleen Moriarty: Hi, I also agree no action at all, and I recommend you take a look at other um initiatives like iota.org, i-o-t-a.org, um, look at Sigstore, SCITT, and other uh related areas. I think that would be helpful.

M. Norton: All right, thank you.

Jim Mozley: Okay. Um, I, I think that, uh, I think that covers it. It sounds like the, uh, um, sense of the meeting here is, is, uh, no action by IETF, but, uh, Kathleen just gave you a, a couple of other suggestions for directions to go with this. Thank you.

M. Norton: Thank you.

Jim Mozley: All right, the, uh, next presentation is Capability-Oriented Intent Routing Protocol, by, uh, Saurabh Verma, and I will get the right slides up here. So, Saurabh, are, are, I see you’re online, uh, go ahead and turn on your, uh, audio and, and perhaps video.

Saurabh Verma: Hi, can you hear me fine?

Jim Mozley: Yeah, that works.

Saurabh Verma: All right, give me one second. [cough] I am recovering from a bad cough, and, uh, my, my voice is not, [cough] uh, not very stable, but nonetheless, let me get started, let me get going. Um, [cough] all right, um, this is Saurabh Verma, I’m the author for the chirp-routing draft, and to start with, I want to quickly clarify that my current draft uses the term capability, and, when I’m referring to capability, I’m mostly implying a discoverable function [cough] or an action that another system can perform. Um, I know that the draft covers a fairly broad end-to-end model, and the early discussions on the mailing list indicated that we need to separate the work more clearly, in terms of, uh, like the core models, discovery, authorization, receipts, uh, transport binding, and maybe even federation. And, so, based on that, I’m not planning to walk through packet formats today. I’ll focus on the problem scope, the interaction path, the, work boundary so to say, and the guidance I’m looking for. All right, let’s go to next slide. [cough] So, the pattern I’m seeing is that agents, automated services, uh, devices, control systems, and similar endpoints, they increasingly need to interact with other endpoints based on what those other endpoints can do, and not necessarily where they are hosted. So, in many cases, consumer does not start with a host address or a pre-configured API endpoint. Instead, it starts with a need for capability, for example, [cough] verify an entity, run a sanctions screen, validate a motion plan, or produce an evidence package, or there’s so many different use cases. So, the starting question is not only can I connect to the server, it is also which endpoint is allowed to perform this function for me under my given policy context. Also, I think the right provider, uh, should and would depend on organization, trust domains, you know, locality, visibility policy, and other requirements. And, for sensitive or automated actions, the invocation usually needs more than connectivity. It would need, uh, scoped authorization, and need some record that ties the result back to the requester, the provider, the capability, and the context. So, this is the repeatable pattern that chirp is describing between transport connectivity and application, uh, logic. All right, let’s go to next one. [cough] All right, so, this slide captures the basic chirp flow, without getting into the wire formats. Um, the path is, uh, a provider advertises a capability, a requester or consumer asks for that capability, uh, visibility and policies are applied, and authorization object binds the requester, the provider, capability, and the policy context, and after this the request and the provider, they use a protected session to exchange the actual, uh, invocation payloads. And then, the fulfillment receipt ties the results back to the capability, the participants, and session context. [cough] Um, and then, the payload itself is opaque to chirp. It can be JSON, it could be a document package, a robotic command, or some other domain-specific message. Um, and the current draft has these pieces together, because they are connected, in, in a, actual interaction path. But, based on the mailing list discussion, I think the next revision needs to, separate these pieces more clearly for review. So, one area for next revision is to describe the architecture, discovery, authorization, receipts, and transport bindings, uh, somewhat more clearly, and then decide what should stay together versus move into separate documents. All right, so, let’s go to next one. [cough] So, there are existing protocols that already cover important parts of this stack. DNS gives us, uh, naming for host and services, TLS and QUIC can protect connections, [cough] HTTP APIs, uh, normally expose application-specific interfaces, um, authorization frameworks may apply, um, in parts, and then, service meshes are useful inside like managed environments, so to say. So, where applicable, these layers still in place, so, chirp is meant to sit around them, we’re not looking to replace them. And, the main gap that I see is the capability-oriented step around each of these layers, um, because, you know, at that point, a requester, he has a capability he needs to invoke, but it may not know which provider can perform it, whether that provider is visible in the current context, um, whether requester is authorized, or how the invocation should be tied back to the evidence. And, that is the interoperability layer chirp is focused on. Also, this model, it comes from, um, some implementation work, and current evaluation paths, uh, in Fintech compliance, and physical AI coordination. Um, I’m not, I’m not claiming that, uh, these are multiple independent implementations of the draft yet, but the pattern is coming from real systems. So, let’s go to last slide. So, I’ll close with this guidance I’m looking for, um, of course, my preferred outcome is additional community development and list discussions. More specifically, I think the next step should be, um, a revised architecture, or problem statement draft with clear use cases, scope boundaries, you know, related work mapping, and so on. And, the specific guidance I’m, kind of, capturing those in those questions, is that is the capability-oriented discovery and scope authorization problems, are we seeing them clearly? Does the related work map, [cough] looks like it’s the right starting point, or are there other areas that we should include? And then, which of these pieces should stay together, which should be split into focus drafts? And then, from security review perspective, where should the attention go first? I think the main areas are like discovery, visibility, authorization objects, receipts, and federation. So, that is what I wanted to cover, glad to take some questions and feedback. [cough]

Rifaat Shekh-Yusef: Can you guys still hear me?

Ted Hardie: Yeah, we can.

Rifaat Shekh-Yusef: Okay. Um, Jim, are you still there? Maybe we lost Jim here. Uh, Usama, go ahead.

Muhammad Usama Sardar: Yeah, thank you, chairs. Um, one question I have is I’m trying to understand better what this capability actually means, so it seems to me that you have, and, and the second term I’m confused about is the kind of the word you have is exporter, so there are two working groups already where which you could explore, uh, but I don’t have much understanding. Thanks.

Saurabh Verma: Okay, thank you.

Rifaat Shekh-Yusef: Okay, Ekkar, you’re next.

Eric Rescorla: Yeah, hi. Uh, we exchanged some emails on this on the list, um, I, I guess I’m pretty skeptical of both the value and the security properties of this, but that actually doesn’t matter at this moment, because if you want to take it to ISE, you can just do that, and so you don’t need anything from us at all. And so, um, I do not think any IETF action is warranted here, and I think you should feel free to take it to ISE, though, in my opinion, ISE should not publish it. Okay. Uh, I, I, I think, you know, we could debate the technology here, but I don’t see any clear nexus to IETF work, um, and, um, and on the basis of these slides, I don’t see any evidence that like anybody is asking for an interoperable standard here that the IETF could specify, so I think the right answer is we do no action at all. Um, no, no working group, no BOF, no mailing list.

Rifaat Shekh-Yusef: Okay, thank you, Kathleen?

Saurabh Verma: All right, thank you.

Rifaat Shekh-Yusef: Okay. Um, is Jim back? Jim?

Jim Mozley: Yes, Jim is back, but you’re doing great, so, um, I’ll run, I’ll run the slides, though, yes.

Rifaat Shekh-Yusef: Hand it, hand it back to you.

Jim Mozley: Oh, um, Ramachandra, did you want to do your own slides then?

Ramachandra Seethiraju: Um, I can share. I’ll try if I can, um, share if it works. I’d like to do it, otherwise, I can—

Jim Mozley: Okay, go for it.

Ramachandra Seethiraju: Okay. Let me figure out how to do that. Let’s see. Ah, you’ve asked to share the screen. Let’s see. Okay. Um, do you see anything? How to approve that?

Rifaat Shekh-Yusef: So, I think we need to share the slides and then hand it to him, right, so, uh, don’t, don’t share screen, right.

Jim Mozley: Right. Yeah. Okay.

Ramachandra Seethiraju: Okay.

Jim Mozley: And, I can, I can advance the slides, or I can give you control of the slides, but it’s probably easier if you just ask me to do the next slide.

Ramachandra Seethiraju: Okay, yeah, sure. I think that works. Uh, yeah, thank you for the opportunity to present. Um, I’m Ramachandra Seethiraju, and with me is my co-author Eric Osterweil as well. Um, our draft is about AI agent discovery. So, we know there’s a lot of work happening around AI agents and how they interact. But, our focus is on an earlier step. Before agents can interact, they first need a way to discover each other. So, this DAN draft explores one possible approach through DNS records, AI-DISC and, um, AI-INDEX. So, with that in context, let me start with the perspective that motivated this work. Can you go to the next slide, please? Uh, so, starting point for this work was a simple question: what information is actually required for agent discovery? So, not interaction, agent discovery. So, we believe inter-AI, inter-domain AI agents need a way to identify and discover each other that is fast, secure, stable, and scalable. So, um, so, that question also motivated a research effort, which is also referenced in this draft, where we explored how, uh, different discovery approaches can be evaluated and compared. Um, so, one, one so, one outcome out of that work was identifying what we believe to be like necessary and sufficient metadata required for agent discovery. So, in other words, uh, what is the minimum information necessary to successfully discover any agent? So, our draft proposes one possible answer to that question, that is through AI-INDEX and AI-DISC records. So, let me start with AI-DISC records. So, can you go to the next next slide, please? So, uh, so, AI-DISC is the primary record here in this proposal. It’s a DAN-like record. Conceptually, it associates an agent name with agent discovery metadata. So, the key idea is can the information, um, needed for agent discovery be associated directly with a name? So, as you can see here, AI-DISC record bundles small set of discovery-oriented metadata, like protocol, endpoint, course capabilities, and certificate binding information, and we also provide some extension mechanisms, um, for agent cards and such. So, as you can see, AI-DISC is not intended intended to replace NCP or A2A or any other runtime protocols. Those protocols already provide rich metadata once interaction begins, um, but AI-DISC focuses purely on earlier discovery stage. So, the capabilities here are like intentionally coarse, um, so, from the discovery perspective, the metadata needed for discovering an agent can be obtained directly from a single record associated with a name. Uh, so, so far, this assumes we already know the agent name. But, discovery has a second layer of problem, which is what if I don’t know an agent name at all? If you can go to the next slide. So, if we don’t know an agent name at all, what do we do? So, AI-INDEX record tries to, um, uh, provide a solution for that, which is why, um, through, like, AI-INDEX basically provides a DNS-based discovery mechanism like for publishing discoverable agent, agent names at the zone apex. So, in other words, a zone operator or can advertise the AI agents they wish to make them discoverable. Um, so, those names can be resolved through AI-DISC records, as you can see, intentionally the AI-DISC records is just a list of names, um, it does not provide any kind of discovery metadata, all the discovery metadata is still going to be in the AI-DISC records. Uh, so, in simple terms, AI-DISC answers tell me about an agent, but AI-INDEX record answers what agents exist in the zone. Uh, so, with both pieces in place, um, let me step back and like explain why we are bringing this work to this group, if we can go to the next slide. Oops. Oh, yeah, this one. [laughter] Uh, yeah, so, we believe this work is fundamentally about AI agent discovery, and as part of our effort, we compared the draft against, uh, DAN rec- the current DAN requirements and use cases, uh, drafts and found like substantial overlap with discovery problem space that DAN is exploring currently. So, uh, we believe, um, DAN explores, with I mean, we believe DAN contributes a particular architectural perspective for that discussion, and, uh, I think, um, specifically, DAN explores whether discovery information can be associated directly with names using existing Internet infrastructure. Um, so, uh, ultimately, we are looking for guidance on whether this work belongs within the DAN problem space and whether it is worth further discussion there. In the in the DAN working space. Yeah, thank you.

Jim Mozley: Okay, we’ve got a couple of people in the queue now, so, thank you for your presentation, and, uh, Ted Hardie is first.

Ted Hardie: Uh, thanks very much, uh, Ted Hardie, uh, no affiliation. Um, I think the dispatch outcome here should be no action. Um, so, there’s been a little discussion in the chat about just uh dispatching this to DAN. Uh, Ram, is there any reason you don’t think this belongs in DAN?

Ramachandra Seethiraju: Oh, we think it belongs to DAN working group, or any AI agent discovery, but the closest that we could find is DAN, because we have read the requirements, um, and use cases drafts of DAN and, uh, there is a, there is a very good overlap between what we are trying to solve and the requirements that are mentioned in DAN.

Ted Hardie: Then, then that seems like a reasonable way to go.

Ramachandra Seethiraju: Okay.

Rifaat Shekh-Yusef: Thanks. Uh, Ekkar.

Eric Rescorla: Yeah, I mean, I, I, I think, you know, we could debate the technology here, but I don’t see any clear nexus to IETF work. Um, and, um, and on the basis of these slides, I don’t see any evidence that like anybody is asking for an interoperable standard here that the IETF could specify, so I think the right answer is we do no action at all. Um, no, no working group, no BOF, no mailing list.

Rifaat Shekh-Yusef: Okay, thank you. Kathleen?

Kathleen Moriarty: Hi, I also agree no action at this time, and recommend you take a look at other, um, initiatives like iota.org, i-o-t-a.org, um, look at Sigstore, SCITT, and other, uh, related areas. I think that would be help-

M. Norton: All right, thank you.

Jim Mozley: Okay. Um, I, I think that, uh, I think that covers it, it sounds like the, uh, sense of the meeting here is, is, uh, no action by IETF, but, uh, Kathleen just gave you a, a couple of other suggestions for directions to go with this. Thank you.

M. Norton: Thank you.

Saurabh Verma: Hi, can you hear me?

Jim Mozley: Yeah, that works.

Saurabh Verma: All right, okay, you’ve got 15 minutes, which includes discussion, so please go through your 10 slides fairly quickly. I think we discussed that.

Muhammad Usama Sardar: Okay, so, so, just to say, I, I think it has no connection to TLS then. It could be ad-hoc protocol, you could do export, you, you could export from any protocol, that’s what I was trying to understand, so this doesn’t fall in TLS. Uh, very quickly, I would ask also from attestation perspective, so, I think it falls somewhere in RATS or in COSE. So, there are two working groups already where which you could explore, uh, but I don’t have much understanding. Thanks.

Saurabh Verma: Okay, thank you.

Rifaat Shekh-Yusef: Okay, Ekkar, you’re next.

Rifaat Shekh-Yusef: Okay, thank you, Kathleen?

Saurabh Verma: All right, thank you.

Rifaat Shekh-Yusef: Okay. Um, is Jim back? Jim?

Jim Mozley: Yes, Jim is back, but you’re doing great, so, um, I’ll run, I’ll run the slides, though, yes.

Rifaat Shekh-Yusef: Hand it, hand it back to you.

Jim Mozley: Oh, um, Ramachandra, did you want to do your own slides then?

Ramachandra Seethiraju: Um, I can share. I’ll try if I can, um, share if it works. I’d like to do it, otherwise, I can—

Jim Mozley: Okay, go for it.

Ramachandra Seethiraju: Okay. Let’s see. Ah, you’ve asked to share the screen. Let’s see. Okay. Um, do you see anything? How to approve that?

Rifaat Shekh-Yusef: So, I think we need to share the slides and then hand it to him, right, so, uh, don’t, don’t share screen, right.

Jim Mozley: Right. Yeah. Okay.

Ramachandra Seethiraju: Okay.

Jim Mozley: And, I can, I can advance the slides, or I can give you control of the slides, but it’s probably easier if you just ask me to do the next slide.

Jim Mozley: Okay, we’ve got a couple of people in the queue now, so, thank you for your presentation, and, uh, Ted Hardie is first.

Ted Hardie: Then, then that seems like a reasonable way to go.

Ramachandra Seethiraju: Okay.

Rifaat Shekh-Yusef: Thanks. Uh, Ekkar.

Eric Rescorla: Yeah, I, I, I think, you know, we could debate the technology here, but I don’t see any clear nexus to IETF work. Um, and, um, and on the basis of these slides, I don’t see any evidence that like anybody is asking for an interoperable standard here that the IETF could specify, so I think the right answer is we do no action at all. Um, no, no working group, no BOF, no mailing list.

Rifaat Shekh-Yusef: Okay, thank you. Kathleen?

M. Norton: All right, thank you.

M. Norton: Thank you.

Saurabh Verma: Hi, can you hear me?

Jim Mozley: Yeah, that works.

Saurabh Verma: All right, okay, you’ve got 15 minutes, which includes discussion, so please go through your 10 slides fairly quickly. I think we discussed that.

Muhammad Usama Sardar: Okay, so, so, just to say, I, I think it has no connection to TLS then. It could be ad-hoc protocol, you could do export, you, you could export from any protocol, that’s what I was trying to understand, so this doesn’t fall in TLS. Uh, very quickly, I would ask also from attestation perspective, so, I think it falls somewhere in RATS or in COSE. So, there are two working groups already where which you could explore, uh, but I don’t have much understanding. Thanks.

Saurabh Verma: Okay, thank you.

Rifaat Shekh-Yusef: Okay, Ekkar, you’re next.

Rifaat Shekh-Yusef: Okay, thank you, Kathleen?

Saurabh Verma: All right, thank you.

Rifaat Shekh-Yusef: Okay. Um, is Jim back? Jim?

Jim Mozley: Yes, Jim is back, but you’re doing great, so, um, I’ll run, I’ll run the slides, though, yes.

Rifaat Shekh-Yusef: Hand it, hand it back to you.

Jim Mozley: Oh, um, Ramachandra, did you want to do your own slides then?

Ramachandra Seethiraju: Um, I can share. I’ll try if I can, um, share if it works. I’d like to do it, otherwise, I can—

Jim Mozley: Okay, go for it.

Ramachandra Seethiraju: Okay. Let’s see. Ah, you’ve asked to share the screen. Let’s see. Okay. Um, do you see anything? How to approve that?

Rifaat Shekh-Yusef: So, I think we need to share the slides and then hand it to him, right, so, uh, don’t, don’t share screen, right.

Jim Mozley: Right. Yeah. Okay.

Ramachandra Seethiraju: Okay.

Jim Mozley: And, I can, I can advance the slides, or I can give you control of the slides, but it’s probably easier if you just ask me to do the next slide.

Ramachandra Seethiraju: Okay, yeah, sure. I think that works. Uh, yeah, thank you for the opportunity to present. Um, I’m Ramachandra Seethiraju, and with me is my co-author Eric Osterweil as well. Um, our draft is about AI agent discovery. So, we know there’s a lot of work happening around AI agents and how they interact. But, our focus is on an earlier step. Before agents can interact, they first need a way to discover each other. So, this DAN draft explores one possible approach through DNS records, AI-DISC and, um, AI-INDEX. So, with that in context, let me start with the perspective that motivated this work. Can you go to the next slide, please? Uh, so, starting point for this work was a simple question: what information is actually required for agent discovery? So, not interaction, agent discovery. So, we believe inter-AI, inter-domain AI agents need a way to identify and discover each other that is fast, secure, stable, and scalable. So, um, so, that question also motivated a research effort, which is also referenced in this draft, where we explored how, uh, different discovery approaches can be evaluated and compared. Um, so, one, one so, one outcome out of that work was identifying what we believe to be like necessary and sufficient metadata required for agent discovery. So, in other words, uh, what is the minimum information necessary to successfully discover any agent. So, our draft proposes one possible answer to that question that is through AI index and AI disc records. So, let me start with AI disc records, so can you go to the next next slide, please? So, uh, so, AI-DISC is the primary record here in this proposal. It’s a DAN-like record. Conceptually, it associates an agent name with agent discovery metadata. So, the key idea is can the information, um, needed for agent discovery be associated directly with a name? So, as you can see here, AI-DISC record bundles small set of discovery-oriented metadata, like protocol, endpoint, course capabilities, and certificate binding information, and we also provide some extension mechanisms, um, for agent cards and such. So, as you can see, AI-DISC is not intended intended to replace NCP or A2A or any other runtime protocols. Those protocols already provide rich metadata once interaction begins, um, but AI-DISC focuses purely on earlier discovery stage. So, the capabilities here are like intentionally coarse, um, so, from the discovery perspective, the metadata needed for discovering an agent can be obtained directly from a single record associated with a name. Uh, so, so far, this assumes we already know the agent name. But, discovery has a second layer of problem, which is what if I don’t know an agent name at all? If you can go to the next slide. So, if we don’t know an agent name at all, what do we do? So, AI-INDEX record tries to, um, uh, provide a solution for that, which is why, um, through, like, AI-INDEX basically provides a DNS-based discovery mechanism like for publishing discoverable agent, agent names at the zone apex. So, in other words, a zone operator or can advertise the AI agents they wish to make them discoverable. Um, so, those names can be resolved through AI-DISC records, as you can see, intentionally the AI-DISC records is just a list of names, um, it does not provide any kind of discovery metadata, all the discovery metadata is still going to be in the AI-DISC records. Uh, so, in simple terms, AI-DISC answers tell me about an agent, but AI-INDEX record answers what agents exist in the zone. Uh, so, with both pieces in place, um, let me step back and like explain why we are bringing this work to this group, if we can go to the next slide. Oops. Oh, yeah, this one. [laughter] Uh, yeah, so, we believe this work is fundamentally about AI agent discovery, and as part of our effort, we compared the draft against, uh, DAN rec- the current DAN requirements and use cases, uh, drafts and found like substantial overlap with discovery problem space that DAN is exploring currently. So, uh, we believe, um, DAN explores, with I mean, we believe DAN contributes a particular architectural perspective for that discussion, and, uh, I think, um, specifically, DAN explores whether discovery information can be associated directly with names using existing Internet infrastructure. Um, so, uh, ultimately, we are looking for guidance on whether this work belongs within the DAN problem space and whether it is worth further discussion there. In the in the DAN working space. Yeah, thank you.

Jim Mozley: Okay, we’ve got a couple of people in the queue now, so, thank you for your presentation, and, uh, Ted Hardie is first.

Ted Hardie: Then, then that seems like a reasonable way to go.

Ramachandra Seethiraju: Okay.

Rifaat Shekh-Yusef: Thanks. Uh, Ekkar.

Rifaat Shekh-Yusef: Okay, thank you. Kathleen?

M. Norton: All right, thank you.

M. Norton: Thank you.

Saurabh Verma: Hi, can you hear me?

Jim Mozley: Yeah, that works.

Saurabh Verma: All right, okay, you’ve got 15 minutes, which includes discussion, so please go through your 10 slides fairly quickly. I think we discussed that.

Jaime (장동호): Okay, thank you.

Jim Mozley: Okay, Ekkar, you’re next.

Rifaat Shekh-Yusef: Okay, thank you, Kathleen?

Saurabh Verma: All right, thank you.

Rifaat Shekh-Yusef: Okay. Um, is Jim back? Jim?

Jim Mozley: Yes, Jim is back, but you’re doing great, so, um, I’ll run, I’ll run the slides, though, yes.

Rifaat Shekh-Yusef: Hand it, hand it back to you.

Jim Mozley: Oh, um, Ramachandra, did you want to do your own slides then?

Ramachandra Seethiraju: Um, I can share. I’ll try if I can, um, share if it works. I’d like to do it, otherwise, I can—

Jim Mozley: Okay, go for it.

Ramachandra Seethiraju: Okay. Let’s see. Ah, you’ve asked to share the screen. Let’s see. Okay. Um, do you see anything? How to approve that?

Rifaat Shekh-Yusef: So, I think we need to share the slides and then hand it to him, right, so, uh, don’t, don’t share screen, right.

Jim Mozley: Right. Yeah. Okay.

Ramachandra Seethiraju: Okay.

Jim Mozley: And, I can, I can advance the slides, or I can give you control of the slides, but it’s probably easier if you just ask me to do the next slide.

Jim Mozley: Okay, we’ve got a couple of people in the queue now, so, thank you for your presentation, and, uh, Ted Hardie is first.

Ted Hardie: Then, then that seems like a reasonable way to go.

Ramachandra Seethiraju: Okay.

Rifaat Shekh-Yusef: Thanks. Uh, Ekkar.

Rifaat Shekh-Yusef: Okay, thank you. Kathleen?

M- M- I'm on the... I'm already clear on the record here. We did not endorse sending the first one to the IESG. He's going to on his own. That's not the same.

A: Yeah, yeah, we are yeah, like, he he raised that option and he's going to consider it, so it's up to him.

E: I'm just saying I want to make sure the summary says that, because the two are very different.

A: No, fair. Fair, thanks. Thanks, Ekkar.

Jim Mozley: Well, Ekkar, just, just kind of to clarify for myself, um, yeah, we didn’t endorse it, but, um, I mean, we, we did feel like that was a, that was a viable alternative, didn’t we?

Eric Rescorla: I, I mean, it's a viable alternative in that you could send, you know, the telephone book to the IESG and he might consider it. Um, it's not prohibited by some IETF process. I think it's a bad idea. I think the IESG shouldn't publish it, if that's your point.

Jim Mozley: Right, yeah. Well, we don’t have any, we don’t have any particular uh—

Eric Rescorla: Agreed. We have no, we have no jurisdiction over the IESG at all.

Jim Mozley: Right, it's just like, just like, you know, that we don't dispatch things to IRTF either, but, um, but, we can—

Eric Rescorla: Yeah, you and I are on the same page. I just—

Jim Mozley: We can point out that that is—

Eric Rescorla: Agreed. I just don't, I just like, I know Elliot cares what people think, and so I didn't want to have the thing be, he gets the message, this was endorsed by dispatch that they think is a great idea for him to publish. That's not what happened.

Jim Mozley: Right, okay, I, I, I agree with that. Yes. Um, Roman is in the queue.

Roman Danyliw: Yeah, I just wanted to get in the queue just to repeat a good bit of what we just talked about. We do not have the ability to dispatch something to the IESG, that is not part of the SDO, and what we are about here is deciding what to do something within the SDO. The IESG is independent of that and and the current IESG can choose to take a document, ignore the conflict review advice, they have that independence.

Jim Mozley: Fair enough. Um, Saurabh, I, I, I—

Saurabh Verma: Yeah, I had a very quick question. So, this was my first presentation to Dispatch, security dispatch, and I’m also new to IETF, so, I’m not very sure as to what, what the action item from the dispatch is for, uh, chirp? I do understand that, um, there is some kind of a discussion to be had, internally, uh, within the team, to figure out how do we address AI-based, uh, requests, right?

Jim Mozley: Right, well, there’s, there’s been some, some discussion about, you know, we, there are a number of AI-related, uh, uh, proposals that are, that are coming down, and, um, yours, yours doesn’t seem to have any, um, additional parties that are, that are interested in, interoperating using this protocol. So, um, you, you need to, to develop more of, more of a community, around, uh, the work that you’re trying to do, and then bring that back when you, when you have that community, and, uh, you know, some evidence that, uh, that it isn’t going to be kind of an orphan protocol.

Saurabh Verma: Got it. Okay. Yeah, okay, that makes sense. Thanks for clarifying.

Jim Mozley: Um, yeah, and, and somebody pointed out on the, uh, on the, on the chat that, uh, there’s, there’s an, uh, mailing list called agent-to-agent, agent, digit 2, agent, um, that, uh, might be a, a useful place for some of that discussion, because they’re, you know, they’re discussing, uh, um, essentially communication, in a broader sense, discussing communi- um, communications between, uh, AI agents. So, okay. Any other, any other business for the meeting today? Well, thank you all for participating. I was, uh, really pleased that we had, uh, this, uh, number of people show up at whatever time it is for them, uh, for, uh, an interim, and, uh, appreciate your, your participation, and, uh, we’ll see you at, uh, at Vienna. Many of you.

Rifaat Shekh-Yusef: Okay, thanks Jim. Thank you, all. Bye.