Automatic IETF Minutes

Markdown Version

Session Date/Time: 21 Jul 2026 12:00

[00:00:04] Unidentified Participant: Echo, which makes it difficult. Well, we're gonna have a

[00:00:09] Wes Hardaker: hard time hearing that microphone. Okay. I'm gonna choose lunch and we'll get started.

[00:00:40] Adrian Farrel: Welcome to the DAWN BoF. There are some seats around, so please find one or stand near the door so you can escape. I'm Adrian. This is Wes. And that's Eric and it's his fault. So this is aiming at a working group forming BoF under the title discovery of agents, workloads, and named entities, which makes DAWN. We're we're a little bit into the IETF week, so you should have seen this slide before. Just because this is a BoF doesn't mean you are not required to be nice to each other, Behave professionally. Follow the guidelines. If in doubt, click on the QR code or talk to the chairs on area director. Remembering that this is subject to the usual IETF IPR rules. Just because there is no working group yet, if you stand up and say something or even if you comment in the chat, you're subject to the IPR rules. Right. Usual stuff. We're being recorded. If you're in the room, you probably use MeetEcho Lite. If you're remote, use the full tool. In any case, keep yourself muted and keep the volume on your speaker turned off. Please join in with the note takers in in the the notetaking tool. And in particular, if you make a comment in the mic, come along a couple of minutes later and check that it was recorded the way you thought it should be. All the lovely materials including the slides. There is a data tracker page despite the fact that we are not a working group. It's found under the working group's pages. Do not let that confuse you. We are a BoF. There is a draft charter which is a stake in the ground. We will be running through that later. It's a starting point. It is not in any way reflecting consensus. Okay. As I said, this is a working group forming BoF. That means that the people who originally led it to happen believe and hope that there is sufficient focus and that a working group will be formed. Holding this BOF does not guarantee that there will be a working group, but they're entitled to dream. So what do the AD and the IESG hope to see in a working group BOF? Well, a well scoped problem that needs to be solved. Work that could belong in the IETF. A good body of people willing to work together to do the work and a reasonable likelihood of success. And in my opinion, that last point is the absolute killer here. We need to establish clear consensus to start standardizing the discovery architectures to move to a solution, and we need to just demonstrate sufficient focus that delivery would be possible probable. What is not in scope? This BoF must not try to select protocols or finalize implementation solutions today. Sure. Somewhere down the line, that has to happen, but that's not what happens in this BOF. And Wes and I will endeavor to be brutal. If you come to the microphone and say, my solution ID says, then you can expect us to to to jump on that. And we do understand there are lots of IDs proposing solutions and everybody would like to get their solution selected, but we're only gonna talk in the very broadest terms about the solution landscape. So here is our our agenda. You are open to bash that now if you have a severe problem with it. Silence is taken as consent. So questions that pop up during the meeting. Hopefully, the presentations will get you all excited, and there's all sorts of stuff you wanna talk about. Please don't until later. It's okay to ask the presenters simple questions for clarification along the lines of, you said fish, surely you meant dog, but don't get into technical or long debates. Don't present your thesis at the mic. Don't ask long technical questions or the chairs may get a little snippy. There's almost an hour in the second half of the meeting for everyone to have their say, then you can rant or preach. Then you can make points and ask questions about the present and we will let the presenters jump the queue to answer. And you can then say, tell us what should be in the charter or whatnot. Just use the meet echo queue like civilized people. But remember, there's a lot of you here, a lot of opinions, and an hour can go incredibly quickly if everybody takes two minutes. That's only thirty of you getting the comment, and that would not be fair. So really think before you go to the microphone, narrow down what is the thing I want to convey. What is my message? And your intellectual capability will be judged by your brevity. Along the way, the chairs will ask you to think about a few big questions, and we're gonna come back to these towards the end of the presentations. But have these in your mind as you listen. Should we be limiting ourselves to AI agents or should we generalize to similar entities? What are the first critical discovery items that will bootstrap future needs? Should we limit our discovery to a single organization, or we should we jump straight in Internet wide? And should we begin with DNS as a starting point, or should we investigate other options before we do protocol work? So keep all that in your head as the presentations go through.

[00:08:22] Wes Hardaker: Wes? A couple of extra quick points. Some of this will be repetitious, but that shows you how much we're really aiming for these things. We have a difficult line to draw today. Difficult line because on one hand, we could be overly prescriptive about the exact solution that we want in a landscape which is changing very rapidly, as you're all aware. On the other side, being overly broad would mean never really achieving anything and never done. Getting So we can't be overly prescriptive and we can't be overly generic. Everybody should note we are not talking about solutions today. I'm gonna repeat that. It's really for the third time because he said it once already. We are not gonna talk about solutions today. If you begin your sentence with, in my draft, we're gonna cut you off. Okay? So don't do that. And it's simply because there are so many. If everybody looks to their left and looks to the right, one of you probably has a draft that is being proposed for DAWN later on. Okay? We already know there's at least 24 draft candidates. So nobody is going to get to talk about their solution. In the end, the IESG needs a charter. It needs a charter that it can approve, which means it needs a charter that's going to be successful. To get this group off the ground, we need two primary points in addition to the other ones that he mentioned. Can we accurately describe a set of problems to be solved and have them concrete enough that we can write them down? And can we agree on the initial set of priorities that we're gonna hit first? The list will be long. We can put other stuff in the charter for it to be handled later. But we've gotta pick a small set to sort of build upon as sort of a set of building blocks. So we have two hours to accomplish those two tasks. So let's go. So first yep. We'll bring up the first presentation.

[00:10:42] Adrian Farrel: Oh, do we wanna take the queue? Yeah. Ramesh, thanks for being in the queue. We'll come, if you could come back into that later, we'll get through the presentations.

[00:10:58] Rashmit Ananthanarayanan: Hi, everyone. Rashmit here. I'm here to talk about the problem statement. Is that the

[00:11:03] Wes Hardaker: Yeah. Really close.

[00:11:04] Rashmit Ananthanarayanan: Alright. So maybe I should actually

[00:11:06] Unidentified Participant: do this instead.

[00:11:07] Rashmit Ananthanarayanan: Hello? That works? Yep. Excellent. My name is Rashmit and I'm here to talk about the problem statement and start some terminology so that we can actually keep going with the rest of the presentations. Some important terminologies that we probably will hear throughout the presentations, one of them is basically the entity. You will hear this term over and over again. So what we mean by entity is the participant in the ecosystem. This participant needs to be discovered or need to actually discover other entities. That's what the entity means. Discovery actually is the process that of finding entities that would exhibit a desired capability, service, function or specified properties. It will then obtain the information about these things and then makes them available as a set of information along with a set of candidates that will expose those type of capabilities. So now the word capability, a description of what an entity can do. A type of service that it provides, a type of function that it provides and the supported operation that it provides. Like, for example, what type of protocol it supports. Does it support H2A, for example, or is it for ACP or something else? Minimum discoverable information, MDI, it's this minimum set of information that an entity will is willing to expose to the rest of the ecosystem. It allows the discovery basically to go forward and and and and and provides it what what it needs to do as a list of candidates to the rest of the system. And the discovery substrate basically is the blob that is underneath this, is basically what is the is the infrastructure that enables entities to publish and and and advertise their capabilities and their MDIs and so on, forth, who maintains this and exposes the information to the broader ecosystem and provides retrieval mechanism for the other people, for the other entities to actually see this. Okay. So one of the things that we need to actually understand is that the network is evolving from just connecting devices and services to connecting AI entities. AI system basically are becoming a distributed and heterogeneous Internet applications. So they consist of things like AI agents, tools, network functions, compute, workflows, tasks, data sources, users and services. The figure in the right hand side is just a crude example of how these things will work or how they stack up against each other. So on the top, got the user and the bottom, got the compute resources and right in the middle is everything else. Again, it's a crude example, it's not the only thing. So there's a whole bunch of things that can happen along with this example. Entities, now along with this diagram, they need to first discover each other before they actually start initial interaction. This initial interaction could be discovery could be very simple. Essentially, I know the exact name of the other agent therefore or entity, then I can actually go right away to it. Or I want to discover it based on some capabilities. Today, frameworks, they devise their own discovery mechanisms. So interoperability is something questionable and there might be needed to be answered. So that's why we are here, are trying to see whether a common discovery mechanism is required to actually work along the side of different administration domain. Okay. So what does it look like today? What's the landscape today? So today, basically, often relies on certain things. Proprietary registries and vendor specific APIs, static configuration and manual onboarding, cloud and platform specific catalogs and application specific discovery mechanisms. So what we'll get if we continue with this trend, we will probably end up with a vendor lock in. We will probably end up with poor interoperability. We end up with limited cross domain discovery, and then it will actually increase the cost of operation because then we need custom discovery mechanism inter basically. That's why I think enabling a standardized discovery for entities that works in different administrative domain might be a good idea to actually go with. So some of the discovery challenges. This is this is something that, we think that discovery needs to answer. These type of questions. What is the entity type and classification? Where does it fit? What capability, functionality and other properties does it provide? Is the entity currently available? Some sorts of status information basically. What policies apply to it and who does own the entity? Because at one point, people might actually wanna actually address accountability. And communications, what communication security, etcetera, mechanism does it provide? So discovery basically is evolving from simply going from locating an endpoints to finding dynamic entities based on capabilities, policies, and other attributes. So what is DAWN all about? So DAWN basically is trying to address the following questions, or at least something similar to these things. How can different entities discover each other in an interoperable manner? How do entities advertise themselves? How do the entity convey their minimum discoverable information? How discovery platform works across different domains? How can discovery information be delivered with integrity and protected against interference, and how can we actually make sure that the queries and responses and the actual MDIs that are being submitted to the system are protected. What is not in DAWN's scope, at least from our point of view, is that AI models and behaviors, that's out. Entities, subsequent communications, interactions, including the interviews that will happen after the discovery is out. Entity selection mechanism is out. Authentication is out. It is important. It has to happen but not at the part of discovery. If I'm submitting an MDI, the discovery cannot be held responsible for validating the actual truth and trustworthiness of the information in there. That should happen way before the entity basically enters the system. Authorization and orchestration is up as well. Drawn basically focuses on the discovery only and nothing else. So existing mechanism, today basically if you want to find, resolve a name, you use DNS. Discover a local service, you use DNS and SD and MDNS. If you want to discover a workload there is plenty of vendor specific type of things. So what are the remaining work? Discovery basically discovering entities by properties is one of the remaining works. Defining the MDIs are the other part that is important. And basically if there is any sort of APIs that we want to define in a standard way, that's what we want to define in DAWN. DAWN basically addresses the remaining interoperability problems. However, it is not there to actually replace existing protocols. We use existing protocols as much as we can and only introduce new protocols or new mechanisms if needed, if the other ones cannot do the job. If you want to do this in the Internet scale, of course the scale itself is basically an important aspect that we have to address. As the number of these things are agents are increasing, the number of tasks is increasing, models are keep coming up, data sources are coming up, so and they are heterogeneous entities basically. So that's one of the challenges that we have to worry about. Trust and privacy is another aspect that we need to actually do. So before getting to that, about heterogeneously, of course, entities are different in type and specifications. However, what we want to do, we want to create a common mule that can actually take different loads. What are these loads? Are cards, basically. Cards, agent cards, task cards, model cards, resource cards and so on. So the objective is to actually create one mule, if it's possible, to carry all this information. And I think we have done that in the past in IETF as well in a different way, in a probably more limited scope. But hopefully, we can actually do this again here. So cross domain is another aspect that we have to actually address. And of course, protection and privacy of discovery queries I alluded to before. And then last but not least, do we need for example something like a pops up mechanism to actually notify entities that are searching for other entities or trying to discover on it? If the entity that is being discovered is busy, can we actually provide this additional service as a pops up to notify someone that, hey, your entity that you basically selected is now available. So the standardization and motivation for this work, as I said here, interoperability, that's why IETF can actually do the work. The fact that we have we want to create a common representation and semantics across vendors and domains. We are dealing with a distributed operation that Internet is and IETF is well suited to actually address. Security support talked to me about. And we want to leverage what we have in IETF. We have plenty of working groups that actually have done very good job, and we want to be reusing some of those stuff to actually start feeding the the the DAWN with different mechanism and enable it basically to to use those mechanisms. Naming and service discovery is one of them, identity and security mechanism, there are other application protocols, cross domain. These are all things that IETF basically has done well, and we wanna be able to use those and apply to DORN. As at the end, an Internet scale standard for entity discovery, that's what we wanna find out, out, whether we need one or not. That, I think I'm done.

[00:21:36] Wes Hardaker: Okay. So, thank you very much. Note that the terminology and the requirements are not yet fixed in stone. If you don't like a particular terminology word, it might change. So there's a queue already. We only want clarifying questions. And only if you think you've hit something that's a stopping point. Okay? If we spend all of our time on terminology, we are never gonna get to the two problem scope. There's a lot of discussion in the chat about solutions. That's probably not the right time to to be doing that either. So please keep your comments short. And please, if you are not gonna bring up something that you think is absolutely critical, remove yourself from the queue. DKG?

[00:22:19] Daniel Kahn Gillmor (DKG): Yeah. Sorry. Can you just remind us what MRI means and m r You

[00:22:24] Rashmit Ananthanarayanan: mean MDI? You mean MDI?

[00:22:25] Arnaud Taddei: MDI.

[00:22:26] Rashmit Ananthanarayanan: Yeah. So it's minimum discoverable information. It's what an entity basically exposes as a minimal set of information that allows other entities to actually see it and and and decide whether they wanna actually talk to this thing.

[00:22:39] Daniel Kahn Gillmor (DKG): And what is an MDR?

[00:22:42] Rashmit Ananthanarayanan: MDI? I didn't say MDR.

[00:22:44] Daniel Kahn Gillmor (DKG): MDR. Someone you said MDR earlier in the talk, and I I wrote in the chat, what are MDRs? Because you said they're MDRs. Slide two? Sorry. It wasn't on the slide. You said MDR, and I was trying to understand what that is. I I I'm basically still having a lot of trouble, understanding what is is is happening here because of the avalanche of terms that were thrown out. So I think what's happening here is you want some way to say, hey. I'm looking for someone who can give me, say, automated translation services and get an answer generically. And I don't understand how that's supposed to work sort of at Internet scale because there might be a million services that wanna offer Internet. It's it's sort of like asking, hey. Who has an a record? Yeah. But You can't get that answer. Right?

[00:23:35] Rashmit Ananthanarayanan: The the the reason behind this is basically one of the problems is the scalability. Like, because of there are millions of these things, we needed some things efficient to actually be able to discover these things based on some initial minimum discoverable information that they provide to the rest of the ecosystem.

[00:23:50] Wes Hardaker: Okay. So let's hold the solutioning until later. Usama?

[00:23:54] Usama: Usama, to you, Dresden. So I want a clarification on this entity. If you go to the next slide. So is it the so in AI, typically we have the data, we have the model, we have a user communicating with that, and then we have some tools. Could you say in this picture, what is your vision of the term entity that you used in the last slide?

[00:24:15] Rashmit Ananthanarayanan: So entity could be any of those things on the on the left hand side. You know, AI agent is an entity. Tool is an entity.

[00:24:19] Usama: But about the I'm talking about the figure. So anything in that figure is in the definition That's of your

[00:24:25] Rashmit Ananthanarayanan: one example. That's just one crude example of how the hierarchy will fit in. So you have a top level user, and then you have agents underneath it, and you have tools, services But

[00:24:35] Usama: maybe precisely, my question is yes or no. Is everything in this figure a part of your definition of entity or not? Yes

[00:24:44] Rashid: or no?

[00:24:44] Wes Hardaker: Yes. Yes. So let's save the exact terminology definition of what we're gonna call what until a later time. So I recognize your question. I it's not agreed upon yet. So this is sort of a starting scope for today. But, Linda?

[00:24:59] Linda Dunbar: Oh, okay. So I do have some clarification questions. In the first slide, you talk about entity consists of workload and services. What's the difference between workload and services? And as of, like, a task, to me, they are all similar. Like, they're using the different context.

[00:25:19] Rashmit Ananthanarayanan: Yeah. But they all have some sort of a description. Right? And this description basically is the MDI that they provide to the discovery substrates for advertising.

[00:25:28] Linda Dunbar: Right. But to me, they are just a software software

[00:25:31] Shuping Peng (Xu Ping): Yeah. They are. Platform.

[00:25:32] Rashmit Ananthanarayanan: Yeah. They are records, basically. Right?

[00:25:34] Linda Dunbar: Right. Right. Right. So I wonder why you have to differentiate them, just make it very confusing. Second, I sent that on the mailing list about discovering, like, compute resources. You look at the the cloud, the AWS that you they basically gave you a compute resource. Yes. Are you going to do this whole orchestration system system in this working group?

[00:25:53] Rashmit Ananthanarayanan: Not orchestration system. No, are not planning to do orchestration system. I was clear in this slide that actually I talked about orchestration is not part of DAWN. So what we want to do is that if you want to identify, find a compute, let's say you have a model and you have a data but the data place does not have enough compute. And a model comes in and it wants to actually find it along with the data, where can I actually train this model? You basically identify a particular compute node that can actually both of these guys can actually run the Vu on and basically train the model based on the data that is provided.

[00:26:24] Linda Dunbar: Correct. Then that's the entire AWS is providing that kind of service.

[00:26:28] Rashmit Ananthanarayanan: AWS, but AWS doesn't work with, let's say, Google.

[00:26:31] Eric Rescorla (Ekr): Right. Right.

[00:26:31] Linda Dunbar: Right? So you're going to do that in

[00:26:33] Rashmit Ananthanarayanan: this Exactly. Yep.

[00:26:34] Linda Dunbar: That's very, very big thing. Okay. Thank

[00:26:37] Wes Hardaker: you. Mhmm. That that's the problem. Ecker?

[00:26:42] Eric Rescorla (Ekr): Yes. So I'm also finding this a little hard to understand. So let me see if I can go with DKG's case. Is your thesis that I, I start with a question, who on the Internet can provide translation services, from French to English, and then I end up with what?

[00:26:58] Rashmit Ananthanarayanan: Sorry. I didn't get the question. Like

[00:27:01] Eric Rescorla (Ekr): Sure. What is your example use case? Give me an example use case. Starting with DKGs. So Is

[00:27:08] Rashmit Ananthanarayanan: just thinking about the example first. One simple Let me try first. Case that we can start is agent discovering another agent.

[00:27:15] Wes Hardaker: So so use case use cases are coming up in a minute, Edgar. So let's hold that for the time being. I I recognize the difficulty here.

[00:27:22] Eric Rescorla (Ekr): But this is an incomprehensible presentation without understanding the question I'm asking and the d d d g asked as well. Okay. Fine.

[00:27:30] Wes Hardaker: The the the the difficulty today is going to even be agreeing upon the use cases. I agree completely. So, I said that on the mailing list as much. Ramesh? Can't hear you, Ramesh.

[00:27:47] Rashmit Ananthanarayanan: I hear you.

[00:27:49] Ramesh Raskar: Ashmit, thank you for the presentation. I'm dialing in from Boston. My question is whether discovery bleeds into search or even semantic search. And if it does because I think it says very clearly on your slides that on the scope is discovery and not search. Right.

[00:28:05] Rashmit Ananthanarayanan: And if

[00:28:06] Ramesh Raskar: we do bleed into search, then we have to worry about the intent, and we need to have effectively working group on the intent as well. Because if it's, you know, identifier in an endpoint out, that would be discovery. But if you get into intent, that's a whole different conversation.

[00:28:21] Rashmit Ananthanarayanan: The quick answer is that, you I don't know. You know, I have a view of how things are supposed to happen, but I'd leave it to the working group to basically decide how far we have to actually go into this. So search, we have search engines already that actually do a very efficient job. The question is that, we need additional work in there? But I don't think we wanna do with search engines. Search engines is individual individual companies basically are doing their they have very efficient search engines already to actually deal with the situations.

[00:28:51] Ramesh Raskar: Yeah. Actually, just to clarify, my question was your slides seem to indicate that this working group should go into search because there's a notion of capability search, capability matching. So at one

[00:29:03] Unidentified Participant: point

[00:29:04] Wes Hardaker: So let's discuss that later when we get to the charter item. Yeah. So that's beyond terminology and sort of starting things requirements. We are going to shift to use cases next. The the larger discussion will happen later, I promise. So, Kihong? To clear the queue.

[00:29:29] Kihong: Sorry. Can you share the slides for me? Oh, sorry. Sorry. Frank, do you wanna stand out here? Okay. So yeah. So the slides is just based on the Internet draft here listed here, and Frank will provide some further microphone.

[00:29:48] Daniel King: Oh,

[00:29:48] Kihong: sorry. Frank just provided also some, further use cases, and I will switch to him for presentation later. So, yeah. Sorry. I think that's work.

[00:30:04] Wes Hardaker: Change the concept controller.

[00:30:09] Arnaud Taddei: Okay.

[00:30:13] Kihong: Still doesn't work. Okay. Works now. So, yeah, just like, Rashmi just mentioned about, like, the problems on trying to tackle, like, a fragmented ecosystem. So I will dive a bit further into the concrete examples here. So, basically, for DAWNG, so, you know, entity discovery, he just mentioned about many different kinds of entities. So, basically, we have grouped all kinds of use case into, for example, four basic categories. So to heads up, so the classification here does not mean to, you know, cover everything. And it's also not you know, this classification is not so not perfect or sub node to each other. So the main motivation here is to derive some, you know, common discovery requirements and, you know, there's different category here may bring out some unique or common implication on discovery aspect. So the first disc aspect will be capability oriented discovery here. So so the core question will be what specific functions or capabilities can the entity perform. So here is a very simple use case here. And Alice from company a wants to, you know, create a year end summary slide deck. So she contacted her, personal as AI assistant to help me design a a slide deck for me with charts and illustrations. So then for personal AI assistant, we'll, you know, try to find specific tools with capabilities like to chartering like like charting or to and table generation. So here, in this case, I'm holding us back to trying to define the specific attributes of the discovered entity. Here is a tool. So it may cover like multi attributes like service endpoints and capability description and what protocol you support. So the discoverable information here is very important in this case. So we the every use case need to care about. And the second discovery case will be sorry. Resource oriented discovery. So resource, like Linda just mentioned about, like computing resources. So it can be seen as a resource to implement those functions. So in this case, you know, the core question would be where are they and how I find them. So also a very I mean, easy example here is Alice. She wants to deploy two models and run, for example, one hand rendering tasks across them. And then the cloud ultrastrator agent will try to find where all these different kinds of or heterogeneous, like GPU resources with specific, I mean, I mean, resources. So here, the specific thing in this category will be that for the discoverable information, they may be static, for example, the hardware specs, or they might be dynamic attributes, for example, like current load or availabilities. So I will switch to Frank on the third category, cross domain I mean, domain aspects. Here.

[00:34:05] Frank Brockners: Yeah, really briefly, think Adrian said that already. So there is maybe the scope of a single organization or something local or internet wide. And maybe local is a more constrained environment, so a good starting point. So what are the use cases for those? So consider a nursing agent in a hospital. And you need to go and find an available nursing agent to serve a patient on a particular floor. Or think of a pick agent in a warehouse and you need to go and find an available pick agent that can go and drive a forklift. In all of these cases, all you want is to go and be presented with a roster of available pick agents, nursing agents, so that you can go and choose from that. So you're in an air gapped environment. It's highly dynamic. But yeah, well you're in semi trusted environment or a very trusted environment, so it's more constrained. And it might be easier to start off with as the initial step into that dawn.

[00:35:08] Kihong: Thank you, Frank. So following up by what Frank just proposed, another aspect on the the administrative domain will be how do we implement the discovery across organizations or tenants. So you use Alice and Bob case here. So Alice from company a wants you, you know, contact her personal AI assistant to schedule a meeting with her client, Bob, from company b. So in this case, the discovering entity, Alice's personal AI assistant, will initiate discovery and try to find Bob's personal AI assistant. So the discovery query here will be either to, I mean, to find Bob's assistance service endpoint or use trying to find the company piece directory and then locate the Bob's personal AI system. So in this cross domain scenario, so an important aspect will be how to build trust and delegation, the discoverable information across domains. And then we the solution also think about the disc the architectural specs on the design. So the next class class will be the applicability of the discovery into natural operations. For example, like, Alice, she's an operator now, and, she wants to locate the network, for example, a fault, fault or do analysis of root cause of it. So in this case, that, thick, sub thing is that a human or a user can also initiate the discovery rather than just I mean, the rather than the system agent. So it's also a part. So so before wrap up, so, you know, we we need to consider that for discovery is important, I mean, functional module or aspect that's separate from registration and communication. So we think about and analyze discovery use cases. We need to make keep that in mind. And, you know, to to wrap up, I mean sorry. It's always slow. So we can observe some important aspects from all of these four category of the use cases, and then we can derive some major categories categorization of the requirements, which then we'll present later. For example, like, entity classification and what properties the entity provide and about, like, architectural specs and also, like, the trust and security aspect of the information you trying to discover. So, I mean, that's it about the use case and the question.

[00:38:17] Wes Hardaker: Alright. Thank you very much. Clarifying questions, please. And the room acoustics are very echoey. So Eric, you're first. Please try and put pauses between your words.

[00:38:34] Eric Rescorla (Ekr): Thank you. I wish we'd seen this presentation first. It's somewhat more helpful. So you gave an example of local discovery, namely, does anyone, I guess, that works for the United States government know how to do this if I work for the United States government? And cross organizational discovery. Do you think Internet wide discovery is also in scope?

[00:39:10] Kihong: Exactly. I think, you know, the scalability of the discovery is very, I mean, urgent. There are many urgent marketing, urgency for some Internet scale discovery. I mean, exactly, I think that's

[00:39:24] Eric Vyncke: No. No.

[00:39:25] Eric Rescorla (Ekr): You you're saying scale, but I'm asking a different question. Like like, what I'm interested in is the is the actual question that the user of this service thinks they're asking. And the in the local case, it says anyone in my organization know how to do this. In the enterprise case, it is, does anyone in my organization or my partners know how to do this? And in the Internet case, it would seem to be, is there anyone in the Internet who knows how to translate French to English? And I'm asking, is that a question you really think people are trying to ask? And if so, is that is this part of the scope of this of this buff?

[00:39:58] Wes Hardaker: Thanks, Eric. When we get to the scope and the charter section, I think one of the big questions will be, you know, are we talking about local scope first versus internet wide scope first versus generic I don't even know where to start scope. The working group mailing list or the Boff mailing list sort of already ruled out the we don't know where to start part. But I think even local versus cross Internet is still under question. We'll get to the scope section of, like, what I said in the beginning, what is the one problem we can tackle first? Right? Hisham?

[00:40:33] Hisham Musa: Yeah. So Hisham, Musa here. I'm just wondering about one of the slides you have, like, a flowchart of the process. So intense yeah. I think the the previous one. So you have intense search discovery requests and then selection. Can can you clarify what would be the scope of DAWN out of those things, or are we going to work on all of them? Defining the protocols of how Alice can search, what the search structure is, and what is being discovered, and how do you discover it, or what exactly. So just something for people to think about just to clarify.

[00:41:08] Wes Hardaker: So his presentation had four use cases. These are not necessarily what's gonna go into the charter for the initial one. These are sort of things for the group in this room to consider. It is unlikely we will pick more than one. Right? The the there will be one problem to be solved first, or at least that's what I hear from the ADs.

[00:41:30] Hisham Musa: So just to clarify, it's not the use case itself. So the next slide, please, if you don't mind. So this discovery phase, intent search, discovery request, etcetera. So are we going to clarify everything within this group, or you think there is a piece for this group and something else for other groups to do?

[00:41:49] Kihong: Yeah. I think Dan will present the solution requirements, and he will deep dive into the whole flow later. But I will quickly tell you that I think discovery is large. So and Don will not solve all problems. So and the selection is exactly out of the scope. Thank you.

[00:42:06] Hisham Musa: Thank you.

[00:42:08] Wes Hardaker: Peter? Peter's gone. Rashid? And then, Osama, please get on deck.

[00:42:21] Rashid: Hi. Thank you for your presentation. My question my question is about how how we can establish trust during the during the discovery process.

[00:42:36] Kihong: Sorry. You mean establish trust. Right?

[00:42:39] Rashid: Yeah.

[00:42:40] Kihong: Okay. I think yeah. I wanna present this, I mean, this this slide in yesterday's side meeting on of the agent use case here. We also man this problem. I mean, the trust is a multilayer problem. We need you know, there are trust bet untrust about the entity of the trust and the entity provider trust and, you know, the information that you want to discover trust problems and then about cross domain trust. So many layers. So in DOS scope, I mean, only the discoverable information trust is in scope. So the the trust of the entity or trust of the entity provider is out of scope.

[00:43:23] Rashid: Thank you.

[00:43:23] Wes Hardaker: Okay. Thank you. Usama?

[00:43:27] Usama: Somat, you addressed. And as a disclaimer, I was there for the site meeting yesterday as well. So I gave a feedback yesterday to like, trust is multilayer as you described. I really hope that that should have been accounted here because I'm still seeing the same confusion that was there. Who is discovering what is still not clear to me in the trust context?

[00:43:48] Wes Hardaker: Trust is definitely one of the outstanding large scale issues that we need to tackle. Alright. Thank you very much. You wanna pull up the presentation? We are a bit over time. Sorry, Colin. So let's go on. Otherwise, we will never get to the meat of the discussion later. And Dan?

[00:44:21] Daniel King: Okay. Daniel King. So this presentation hopefully starts to provide a list of consolidated requirements that come from both the discussions around the problem statement, but also the use cases. And I think it's worth kind of pointing out that the use cases are almost categories at the moment. And what we need to do moving forward is present much more pragmatic or practical examples of how agent to agent and other type of entities will be deployed in order to understand the requirements that then help us select the solutions. So we know without repeating what Rashmit mentioned earlier, we know that there's no interpretable method for discovering different types of entities across administrative domains. There are clearly several types of domains. Some are Internet wide, others are relatively local, sort of enterprise specific. What we will want to do, I think, within DAWN is decide what are the near term use cases and those practical deployments without trying to boil the ocean and solve sort of Internet wide prop problems as well. What we're not trying to do with the problem statement and the well, let's let's actually, with the requirements doc document, it specifically state what solution should be selected in order to solve all of these different scenarios. I think that there will be the potential for multiple solutions that may be addressing specific requirements, not necessarily all of those requirements. So the requirements that we have right now can be categorized as sort of entity classification, properties, the the specific scenarios. There are protocol requirements, and then what we've sort of some of the more contentious issues that we're seeing on the discussion in in this meeting, at least in the chat, is around sort of trust and security. And I understand that there are existing technologies that can be applied here, and there are also particular aspects of security that are highly specific for the use case, but also apply to kind of bigger picture, maybe technology specific as well. So this is the a repeat, I guess, of Rashmit's problems to main state statement. This is really where DAWN is attempting to address initially, which is the discovering entity talks to something, an endpoint. That endpoint provides a catalog, a description, an index of capability. That capability may be an agent. It may be a task or intent. It may be a type of function. And this could be iterative. It could actually require several requirements as part of the life cycle and focusing on an agent example. There could be several iterations during that life cycle that require discovery capabilities. And I think within DAWN, what we're trying to do is narrow the problem space, identify, you know, what the immediate requirements are. When we start thinking about the life cycle, we need to identify the endpoint, the capability that we want, then there may be additional protocol requirements that actually provide capability information, attestation, verification, auditing. And I believe DAWN is not trying to solve all of those capabilities. What we're trying to do is say that those potential capabilities that are required will be either addressed by other working groups or even potentially other SDOs. And this is not necessarily a new activity in the ITF that's gonna solve that sort of entire problem space. So the document itself, it's relatively short. What what we've tried

[00:49:27] Unidentified Participant: to

[00:49:27] Daniel King: do with the requirements is classify them as I just mentioned. These requirements have come from the problem statement, some of the use case discussions, the list itself, and also other organizations such as the Linux Foundation, Agencik AI, fab Foundation, TMF as well. And these requirements, we've tried to kind of filter them to make sure that they only apply to applicable IETF tools and technology and and potentially sort of areas for enhancements based on sort of that IETF technology itself. We we know that these requirements will need to be sanity checked. We expect some of these requirements to be mandatory depending on the use case or the practical deployment. We also expect to add and remove requirements. And these requirements will hopefully help the potential working group, maybe DAWN, maybe other working groups in the future, identify solutions that will solve what we perceive to be an industry problem. So I think so we had oops. So we had discovery, protocol, scaling, resilience, trust, security, and, yeah, skate scaling. If you have a requirement or a set of requirements that you don't feel are represented in the document, then please message the list or message Adrian or myself. You know, we're not trying to sort of spend too much time thinking about the longer term use cases, what we would really like to do, and that's why, you know, we've invited operators, OTTs, application developers. We we really want to try to address the sort of the immediate problem, the immediate use cases. Maybe in the future, and it's certainly from looking at the chat today, there will be need for extending some of the discussion and maybe addressing some of the longer term scenarios. But as kind of Linda pointed out with the AWS example, you know, there may be some requirements that are just insoluble, and maybe they are better sort of suited to highly proprietary environments with some kind of mediation or gateway function. And then sort of just repeating myself here that the security and trust, maybe we should have categorized those on one slide and not necessarily talk about extensibility. But, certainly, security is a hot topic. And just because we can verify who we're talking to doesn't necessarily mean that we will provide that communication across a secure link or the information that's being exchanged will be secured if it's stored persistently at either sides of that communication channel. I think we need to kind of think about security from a sort of a meta perspective, but also with sort of within the bootstrap of that discovery session as well. Trust and maybe attestation, again, are kind of hot topics at the moment, maybe better suited in other working groups, reusing existing technology or emerging technologies, obviously, gonna be key here, but it seems to make sense that if we think about the various phases of agent to agent communication, we should sort of identify those as requirements, and we can help see those in those other discussions inside meetings that are kind of occurring. There is also if we're if we're performing attestation and we're requiring trust, then potentially at some point, we may need to audit some of this communication as well. Then there'll be information that needs to be stored and who has access to that. And how you verify that, again, could be documented as part of our requirements discussion. But it's not specifically things that we wanna solve from day one. I think I'm more or less on time.

[00:54:32] Wes Hardaker: Thank you very much. Note, we are not going to discuss those right now like the title says. That's gonna come soon. We are this close to an open mic for free for all, so let's give a little bit of time. Steven, clarifying questions, please.

[00:54:48] Stephen Farrell: You said that like you were suspicious of me or something.

[00:54:50] Wes Hardaker: I'm suspicious of about 300 people right now.

[00:54:56] Stephen Farrell: Dan, could you go back to slide four, please? I just want to clarify something. So the way I understood what you said, I think, was if you look at the two boxes on the left, that the putative dawn protocol would be like a vertical line between those. Is that what you meant?

[00:55:17] Daniel King: Pretty much. Yeah.

[00:55:19] Stephen Farrell: Okay. Thank you.

[00:55:20] Rashmit Ananthanarayanan: See?

[00:55:24] Wes Hardaker: What a great clarifying question, Peter?

[00:55:27] Daniel King: Peter.

[00:55:28] Peter: Yes. Hi. Clarifying question. Actually, you mentioned there's there's no authentication, and there's some indication that says secure metadata or parameters that help to do authentication, so that kind of things. So my direct question to that is that things like trust anchors and trust bundles, so like root CAs assigns downstream certificates Mhmm. And also some root keys that signs some ID tokens. Should the like, the organization is kind of exposing their abilities. So should that kind of trust bundle or trust anchors be considered in scope of registration discovery?

[00:56:11] Daniel King: I think it depends on the use case. That's kind of an easy get out, but there's a lot of kind of sophistication and capability there. And we may have to kind of signpost that in terms of capability that we want for DAWN, but it's it's not clear if that's mandatory or optional. Is it a must, or is it a nice to have at this point? But but if if when you are sort of starting up and you're bootstrapping, you're saying, I only want to talk to you if you can provide this additional capability in terms of trust later on in my life cycle, then, yeah, I guess that has to be sort of part of the initial sort of mandatory requirement. But how that's achieved and what mechanism is used, I don't care. Okay.

[00:57:04] Wes Hardaker: Usama, last question.

[00:57:06] Usama: Yeah. Very quickly, if you go to the slide where you had trust and security, I think it

[00:57:11] Daniel King: was And extensibility, I think.

[00:57:13] Usama: Yes, please.

[00:57:14] Rashmit Ananthanarayanan: Yeah.

[00:57:15] Usama: I don't like, again, the the the trust out of scope. So there is a lot of trust which we still need. We'd be if the agent is not secured, if I'm connecting to if I'm discovering some agents in my vicinity or wherever in the in the, let's say, on the Internet scale, But some of them are malicious, so I I I don't think that keeping trust out of scope is nice.

[00:57:37] Daniel King: Okay. That's that's a fair point.

[00:57:42] Wes Hardaker: Alright. Thank you very much. So we are going to shift now into sort of what we need out of this day. Right? What we need out of this day, I'll repeat for the fourth time, is not a solution. It is what is the first bit that we can bite upon. And we have some slides to talk about that.

[00:58:02] Adrian Farrel: Yeah. Notes to BoF chairs. Do not try to read the chat during the BoF. Moves far too fast. So, we put together, as I said at the top, a few key questions. I think there may be some other questions that have popped up and will show in the charter discussion as well. So, this is just intended to seed the discussion about of the charter and get us some focus. So recall, aiming as a working group forming BOF, is there a problem that needs to be solved? Is it an ITF problem? Does the community want to work on it? Is there enough focus to actually get somewhere? The chairs can only give advice and guidance at this point and the community will decide what it wants to do and then the ISG will decide whether the community has decided and what that is. So the chairs with some heavy guidance from the ISG advise focus. Focus, focus, focus. If there is going to be a charter, it needs to be focused on a small number of deliverables for quick delivery. And futures can be added as not currently in scope, but available for later recharter or maybe we could come out of this meeting with three charters. Eric, do you wanna go?

[00:59:48] Eric Vyncke: Yeah. Eric Vink, the responsibility for this BoF, I insisted to add the last bottom three lines because I fear the discussion can go in all direction, and you are not here to boil the ocean. So I'm simply explicating and repeating what you said.

[01:00:06] Adrian Farrel: So my initial four big questions and we've seen this reflected in some of the chat is, are we just focusing in on AI agents or similar entities, other things that could be discovered in a similar way with a similar description of their properties? What are the first critical discovery items to bootstrap future needs? And I think this term MDI comes in here. What is the basic set of information that you need to discover so that you can start talking to a remote entity to find out what it can do, what it wants to do to negotiate parameters. I've also seen in the chat this whole thing moving up from the land to the local environment to the enterprise, etcetera, etcetera, etcetera, all the way up to the Internet. Do we draw any lines or do we just go for the whole thing? And how do we decide where we're going for protocols? Quite often a BOF comes in with a protocol proposed protocol solution. That's not the case here, but it might help us if we were able to pick some broad category of protocol solution or do we need to go away and go through all the use cases and the requirements before we can establish what might be a useful protocol? I've got a slide on each of those points. I am only going to read the chair recommendations from those slides. You can read the rest. So for the AI agents or general entities, the chairs think that scoping in all types of entity will make the charter too wide, too difficult to achieve, making AI agents the initial focus will help the working group be able to deliver. At the same time, we should keep an eye open for general applicability. It's like, don't do anything that will break general applicability unless it's a really necessary optimization. For one of the first critical discovery items, the chairs reckon that we should scope in all elements of the ecosystem that would make the charter sorry. We should Right. We should scope out. How about that? We should read our slides before we project them. Scope out all elements of the charter in order to avoid making the charter too big to be acceptable. Focus on what is critical to discover that will bootstrap future needs. Keep a list of future work items for a possible recharter. Consider using other working groups or other topics for other topics existing or new working groups. So, you know, if you think identity is a absolutely fundamental thing here, if you think that the authentication of registration is absolutely fundamental, you are probably not wrong. But if we pile it all into one place, we may get disaster. So cooperating working groups with smaller focuses could be a better approach. Okay. Single organization or bigger picture, we think that the deployment models, all of these deployment models should be in scope. If, however, a specific problem or distinction is discovered, it should be called out so that we understand if we do this in the whole of the Internet, it will break. Or if we try to push this down into onto the LAN, it will break. DNS or all options. Our recommendation is make an initial attempt to use DNS probably with extensions as the discovery bootstrap. Pay attention to shortcomings and failings. It may be that DNS cannot hack it. That's okay. But if we don't try, we won't find out. Be informed by work that is going on in other places. Lastly, our straw man, as much focus as possible, small list of priority deliverables. Make a long list of items that are out of scope for now. Don't forget that other urgent work could happen in parallel working groups. And in the end, there needs to be a negotiation with the IESG discussing the charter that Wes will go through in a moment on the mailing list and with the AD. Okay. There appear to be 18 people in the list, in the queue just for this set of broad question slides. So so my position is no. And we'll move on to talk about the charter and then I'll keep this queue as it is. So if you're in the queue already, don't run away.

[01:05:52] Wes Hardaker: Yeah. So I think given lessons learned for the day, here's what we're going to do next. Can you drop your slides? And what I'm going to do, the charter was circulated on the mailing list. We are not going to go through it sort of step by step, which was sort of my original thought, but that's clearly not gonna work with now too many to count people. So what I'm gonna do is I'm gonna show sort of the structure. The reality is everybody in this room wants to talk about the scope. Right? That is gonna be the discussion. So the the charter actually has a number of different sections. Step one is the introduction. We don't need to nail the introduction in the background today. So I'll give a brief second so that you can read on each of these just so that you can see what's there, but we don't need to to debate over it. So the second section is the scope, and this is where we hit. Particular, I will leave it on this slide in a minute. I want to show you what the rest of it looks like first. So this is the scope that we'll talk about. And I think this is where the fight will really kinda take place, and we'll see what we can do to narrow it down to a scope that we think will work. There's a little bit more words beyond the scope. And then there's an out of scope section. I think that the the better words for out of scope would be future work. Right? There is nothing wrong with having a charter which has a list of items that are sort of tabled for now for the future, or the IESG can look at starting up in a different group, or we can put ideas to go forward in a different working group that already exists. I think there's three agent related buffs this week. So that so if something ends up in out of scope, that doesn't mean not soon. It means just not at the moment. And then there's deliverables, and we don't usually do that. So I'm gonna go back to the scope slide, and then we'll go through the mic line and see what happens. The important things that that we need to take away today are What are the building blocks? What's the one sort of problem case that we can hit upon that is the starting place? So with that, Rashid is first.

[01:08:37] Adrian Farrel: And just to say to everybody, try to keep yourself to a minute, please.

[01:08:44] Eric Rescorla (Ekr): Thank you.

[01:08:48] Adrian Farrel: Rashid?

[01:08:51] Wes Hardaker: If you are next after somebody, please get up and be ready to speak.

[01:08:58] Rashid: It's just is that I think logically, it should it should be defy trust trust trust boundary before before before defining before defining discovery process.

[01:09:19] Wes Hardaker: So we were not just for reference, we're not gonna answer. This is just a time for people to speak, and then we will listen. So the trust model, I think, has been a has been a big discussion, and we'll note that down as the and Eric will certainly be listening to where the predominant opinion seems to be. Linda?

[01:09:36] Linda Dunbar: Oh, I have a very quick question. Because ITF has a working group called the called the identity what is that? In identity workload identity, right, in multi system environment. Does DAWN plan to use that identity? They define that working group?

[01:09:57] Wes Hardaker: Did you catch that? WIMSE is the working group.

[01:10:01] Linda Dunbar: Yeah. WIMSE. WIMSE. Yeah. It's just simple.

[01:10:10] Adrian Farrel: So, I I would say to everybody, don't ask us questions. Make the points you want to make. Harish?

[01:10:21] Rashmit Ananthanarayanan: Sorry, Rash meant here to just reply to Linda's question. So, DAWNE will reuse whatever mechanism that it sees fit from IETF to actually solve this problem. Identity is an important part. As an entity, we need an identity. So if this identity is not going to be defined inside Discovery, it's going to be defined somewhere else, Discovery will use it. Same thing is for trust. There's a whole bunch of functional blocks that we have, that we need to rely on, and these functional blocks are not suited for the discovery itself. They happen outside discovery. Discoveries will be simply a customer of those things. So we encourage people to actually do that work inside those working groups so that it can enable discovery to use them, basically. Right?

[01:11:04] Wes Hardaker: Yokesh?

[01:11:05] Yogesh Deshpande: Hello. Hi, Yogesh. Deshpandiam. I think in slide two, you said only scope items which can be pushed into draft relatively quickly or something like that. What is your definition of relatively quickly in that in terms of time frame? That's my question. And secondly, are you trying to exclude things which may be important but cannot be done in a rather quick manner?

[01:11:28] Wes Hardaker: Can you say the last part again? I I think I'm gonna switch headphones.

[01:11:32] Yogesh Deshpande: More on to the time is also the importance or the relevance of the subject should also be taken into account in my view. Yeah.

[01:11:40] Wes Hardaker: So I I think that the tricky part for a timeline will be if we can get a charter that is agreed to quickly and the IESG can take it as a you know, charter, I think it can be spun up very quickly. If this room and the mailing list, you know, seem to be fractured in terms of, you know, what the scope is, we won't get a working group. It's it's that simple. And that happens all the time, unfortunately. Thank you. Eric, anytime you wanna jump up, free. I'm gonna see if I can switch to the phone.

[01:12:19] Eric Vyncke: Eric Vyncke again, responsibility. For the timing, in August, it's a day of months off. Right? So if we get to September discussion, we can get started the discussion at the IAB and AIG level in October, and we are ready to go in November in San Francisco. Right? It also does not prevent people to continue to work on draft, right, while we are chartering. Now if there are discussion everywhere, in March, we are not yet there.

[01:12:47] Wes Hardaker: Torlas?

[01:12:51] Adrian Farrel: Again, people, if you see yourself second in the queue, get up already.

[01:12:56] Toerless Eckert: Yeah. I can't see a discovery that in these days with AI that is as lame as any of the protocols we have. So I the the only thing I can see that that is really of interest is all the abilities to collect the database of all the relevant stuff and then have an AI front end that that I can ask the intelligent discovery question. Right? So where's the bloody curry war stand? In Vienna, in the vicinity of the Hilton that is open at 3AM. Right? So I mean, that's that comes from a big database. No individual discovery protocol I'm aware of is is going to answer these questions. And I think those are the questions, the more complex one we wanna see being able to answer. And so pulling the stuff together, having the standard data model for all of that, that stuff, I think that that that would be all very interesting. But then I'll front end it with an AI to to ask the questions.

[01:13:52] Daniel Kahn Gillmor (DKG): Hernan?

[01:13:54] Arnaud Taddei: Arnaud, just a question for this. So we only comment on the scope right now?

[01:14:00] Wes Hardaker: So the goal from for the next hour is what what does this room believe we need to do to create a successful working group? It seems like scope is the biggest item of discrepancy, but if you have other things that you wanna comment on, feel free. Okay. So I

[01:14:19] Arnaud Taddei: have five points. So on the scope, I would propose to add a sentence that the working group where we use existing identity and trust data models that we Yep. Alright. Hello? Yeah. Woah. So I have five phrases to contribute here. One in terms scope and one in other parts. So the phrase for scope is that the working group will reuse existing identity and trust data models, and we coordinate the structure of discovered information with related external work from other bodies rather than define new identity semantics. That's the first comment. Second comment is on the deliverables. I would like to see that information model no, coordination. So if you are coordinating, I would like to add ITUTSG seventeen and focus group TIDA that was just formed as a pre standardization body to address exactly these type of problems to help this group, not to compete with this group.

[01:15:28] Wes Hardaker: We only listed IETF related working groups, but we certainly recognize that the IAB has liaisons to a bunch of other groups like SG seventeen and others. So that's a valid point, and we can adjust the wording accordingly.

[01:15:40] Arnaud Taddei: Right. So

[01:15:42] Adrian Farrel: Sorry. That. Yeah.

[01:15:44] Arnaud Taddei: Yeah. But the focus group is not there. Anyway

[01:15:48] Wes Hardaker: Chairs cannot read their slides behind them. It doesn't work. Right.

[01:15:52] Arnaud Taddei: So on milestones, LG seventeen sent you a liaison statement. You can answer it as a first milestone by the end of August. Out of scope, if you go to out of scope, what we would like to propose is to add definition of trust frameworks and trust evaluation methods. The protocols convey the station evidence and results. It does not evaluate them. And to add identity life cycle management. And on deliverables

[01:16:30] Wes Hardaker: So, Arnaud, why don't you send the list of your proposed changes to the mailing list at this point? Because it'll get too long to read at the mic.

[01:16:37] Arnaud Taddei: Okay. So fact is that we can provide five contributions to this charter.

[01:16:41] Wes Hardaker: That would

[01:16:42] Rashmit Ananthanarayanan: be excellent.

[01:16:42] Wes Hardaker: Thank you very much. Ted?

[01:16:44] Ted Hardie: Ted Hardy. One thing that often works in the ITF to reduce the scope is to say, what's out there that's a proprietary solution where there is a set of people who want an interoperable solution that is not the proprietary solution? The current scope we've been talking about is either in Co, Cohait, or Oceanic. And I propose that what we do is to say, okay. For round one, look at where there are proprietary mechanisms out there that work. See if there is a group of people that wants to create an interoperable alternative. If there is no proprietary mechanism that currently works in the thing, don't put it in the charter. If there's no group of people who want an alternative, don't put it in the charter. Once you have narrowed it down to that, you know that there is an existence proof that there is engineering to be done, and there's a group of people who care. That is something you can actually narrow this down to to a set of scopes. And I will say, the current one, you have an ontology problem before everything else. Don't tackle the ontology problem. Find out what's being published by the proprietary people that people are using and succeeds, and says, how can we put this into an interoperable language that these set of people who need to interoperate will use?

[01:17:53] Rashmit Ananthanarayanan: Thank you.

[01:17:54] Wes Hardaker: You've forgotten how to do this at ATF speed while the world moves much faster. But, yes, thanks. Colin?

[01:18:01] Colin Jakes: Colin Jakes, can you back to the slide with the the other scope slide in scope slide?

[01:18:08] Rashmit Ananthanarayanan: Okay.

[01:18:10] Colin Jakes: Okay. So here so my feeling is the the biggest problem with this charter is actually these words within collaborating organizations. I think that some people interpret that to mean, you know, all the major, you know, cellular providers in in the world could be collaborating organizations and we're talking 5,000,000,000 endpoints, right, as is in the scope. Other people read that to mean like, you know, two buildings at at the same company or or or something like this. But I think that we really have to get a much better handle on everyone agreeing in the charter what that type of I'll call it the diameter of the network that we're talking about working across here before we're really gonna be able to get to agreement on on moving a charter forward. That's that's the the the key thing. Is that

[01:19:00] Wes Hardaker: Yeah. Agreed. I mean, even as was brought up earlier, right, are we talking within an organization or cross organization? And and I'm not sure that we've really had that discussion fully yet.

[01:19:10] Colin Jakes: Yeah. And I really don't think we know what an organization is in the context of this type of use case or requirement. So I think that those need to be defined much better.

[01:19:18] Rashmit Ananthanarayanan: Thank

[01:19:18] Wes Hardaker: you. Alright. Thank you. Jonathan?

[01:19:21] Jonathan Rosenberg: Jonathan Rosenberg. I I have similar comments as Ted and Colin. I think we should constrain the scope to exclude global Internet wide discovery. Exciting, pretty much unsolvable, impossible problem because of issues of trust, identity, payment. Don't solve unsolvable problems. I think this is solvable inside a domain and inside of a it was like an organization, a company, for example, largely defined by a trust boundary. And we have existing work that's been done. For example, if you want a directory of agents, looks a lot like LDAP or SCIM, we can solve these kinds of problems. So I think you have to narrow this down to be inside of a single domain or organization. Thank you. And pick agent or tool or whatever, just not random entity. Pick one thing.

[01:20:10] Kihong: Okay, Homme. Firstly, I'm trying to answer the question what would be the right minimum requirement because I see some inconsistency. I love the concept of the entity. And if I understand it correctly, the AI agent is a subset of that. And but, unfortunately, it's not also gonna with other part of subset, like task or workload. So the minimum requirement for the working group could be a specific capability, like how to do the computer or other things. But AI agent with a set of capabilities could be more than that and may not be a proper place for a minimum requirement. And I'm open to any answer to the minimum requirement.

[01:21:02] Wes Hardaker: Danny?

[01:21:04] Danny: Hi. Yeah. Just throughout all this, I've been locked on one specific problem, I guess, in scope that I think is gonna need to be figured out, which is when thinking about whether I guess this is a problem being solved for, we'll call it, like, personal or consumer use for, we'll call it, intra organizational. So, you know, same organization, but between different services, they have interorganizational. So that's like the calendar example of, you know, between two companies or Internet wide. Each of them is probably gonna end up with, like, different sets of solutions in place, maybe not like those the middle enterprise y ones, but the personal stuff and, like, whole Internet are probably gonna look different than all the, like, enterprise y stuff. And it's that seems really complicated.

[01:21:56] Wes Hardaker: Yeah. And I think that that goes back to the point a second ago of what's an organization. Right? Is an organization a household or a 200,000 per $200,000 company. 200,000 two forget it. Eijun?

[01:22:15] Eijun: Yeah. One let's say, for the scope of this working, I I I sort of focus first on the AI to discovery because this is the most our urgent use case. And for the workload and other namely, think that traditional DS can solve it very easily. And the the AI, you know, maybe bring some challenge for the for for the DNS basis with our other base solutions. So I think we so the folks first on the AI agent AI agent discovery.

[01:22:49] Wes Hardaker: Alright. Thank you. Steven, now it's your turn.

[01:22:51] Stephen Farrell: I got confused. So first, I agree with what Ted said. I think that, you know, going back around and doing this again seems like a more sensible outcome with a bit more precision and so on, what Ted said. I just don't see how you have I don't see anything here that indicates there's an answer for the query Warren was using in the example in the charts of finding an MRI and how that would possibly translate into a DNS thing such that you could start a working group working on DNS now that would make any sense at all. That just doesn't seem feasible to me. So I think that that goes back to some of the chair recommendations and so on. But if you followed all those chair recommendations, I think the outcome would be a bad outcome.

[01:23:33] Wes Hardaker: So so I'd like to notice, the chair, that I have said on the mailing list twice now that it would be good if people could say this is the use case we wanna solve first. All of my posts have been met with silence. And and so it's an interesting problem. Right? Because there's people that wanna talk about capabilities. There's people that wanna talk about, you know, how do I find the entity? There's people that wanna talk at the search level. There's people that wanna talk at the information model level. And unless we can identify, here's the use case and here's a solution to solve that use case, it's gonna be really hard to write a charter around it.

[01:24:12] Stephen Farrell: I I agree, but I'm not one of the proponents here. So maybe you're just being suspicious of me again.

[01:24:16] Wes Hardaker: I'm not a proponent.

[01:24:18] Adrian Farrel: In the context of a of another thread, Steven, we're always really grateful for your contributions, and we find everything that you say is particularly useful.

[01:24:30] Kihong: That was a new

[01:24:30] Adrian Farrel: one. Pradhyamra.

[01:24:33] Pradhyumna: Hi, everyone. Pradhyamra from MIT here. Again, following up on a bunch of previous comments, agree with Ted on his comments. I think there is a lot of existing work out there in this general space of agent discovery and the purview of DAWN that should be taken into account. One of the use cases that I would like to point out that I don't think has been discussed much is sort of general b two c use cases where not necessarily everyone has entities or assets on the same domain, such as cards and run times, and how we would address discovery across settings like this without shared routes and without sort of scoping these trust domains out specifically. So just bringing that up for the community to discuss.

[01:25:25] Wes Hardaker: Thank you. Ecker?

[01:25:30] Eric Rescorla (Ekr): Yeah. So first, in terms of framing, you know, the problem statement here is not find a pony in this set of words that somehow could be turned into a viable working group. The question at hand for this discussion is whether we should try to do anything here at all. So, like, I'm not really interested in trying to, like, reconstruct this into something that that that I think makes sense. The question is, is there something we should do? To that point, I would go back to the point Ted made and try to make it sharper. There's a huge amount of existing work in this general space. As you can see from the thing on the on the GitHub, I'm not sure how much of that Pam did for other someone else, but, like, it's incredibly useful to take a look at how long that list is, including outside the ITF. And so what we should be asking here are are there people who already deployed something in this general area who wanna interoperate and wanna bring that to the ITF and wanna work on it here? Or is there a critical mass of people who are what aren't unsatisfied with that and wanna build an interoperable version of things that already kind of exist? And we should do that exercise and find the use case that matches that. And if and if there's something there, then we should come back after that. The next point I wanna make is that the internal organization and the versus the Internet scale are totally different problems as Jonathan Rosenberg was pointing out, and it really helped, like, to try to clarify which of these people are actually trying to kill. And and as Jonathan said, I think the Internet scale one is just not at all positively soluble given any anything I've heard described here. Finally, I I can't help but get this point. This whole question on question four of should we use DNS? It's just, like, comically premature at this point, before you have any idea of what we're trying to accomplish. So I I I can't even, like, think about any world in which we'd wanna answer that question right now.

[01:27:05] Wes Hardaker: Thank you. Steven?

[01:27:08] Steven: Yes. I have a implementer's data point here. I build agents, buyer, seller, negotiating agents using an OpenClaw and Hermes. Lot of these do not have a trust, have a have a domain name, so there's no, nothing to anchor on. And so I wanted to bring that up as there was a, draft for, domain assistance that went on yesterday that helps you find those groups with no, domain. And but that's just the first level of trust. There is also who authorized that, and there's implementations like a auth. And then also what did they actually do, and believe there's a need for a verifiable action record that is anchored to a transferring service. We ran all this at the hackathon last weekend, and my so my charter ask is to consider that population with no domain and also have it composable such that we can reference by digest the auth as well as the conduct. And this makes sure that the that group of people are not second class citizens with trust, and happy to show this to anyone who would like to see it running. It's all running code, and it's open source.

[01:28:29] Wes Hardaker: I I think one of the big problems that has to be worked on here is the the the class of various things that need to be referred to is very large, so identifiers or domains or whatever is hard. I have heard both from people that say I, you know, I want the DNS because that's where to start. And I've heard from people saying I want dot well known, and I've heard from people saying I don't want dot well known because I'm not gonna run a web server. So we have to agree on at least one protocol that everybody's willing to run and what that is is gonna be a good question. Yari?

[01:29:00] Unidentified Participant: Yari, I come. So we are stuck between trying to find a simple thing to do easily and approve a charter and then the needs that many of us have for these complex cases. And we should not forget that we can already do some of the simple things with existing ITF protocols and, of course, other protocols as well. So what to do? First off, I think we can actually restrict the scope or the scenario to one, which is where we discover something from a known and trusted other party. And I think we should leave the rest out like random other parties on the Internet to turn off and others made the point already. Secondly, I think it will be useful to recognize there's some modularity in this space. We could actually build some initial components, have them be independent from each other and and then build on that on on them later. So I see three types of things that we could have. We should have an initial contact establishment mechanism like, you know, find me the agent's registry in domain x. And then we need to have a server, directory server registry that can record and serve rich information about the discovered entities and then a data format for that rich information. And then if you have this basic support, then on top of that, you could do all kinds of things from search and federation later. You don't have to do that initially. Thank you.

[01:30:25] Wes Hardaker: Naved.

[01:30:26] Naved: Thank you. This group depends on well defined functional identity. And I mentioned this on the list today. The requirement already states this. Rec six makes identifying the prop party responsible for the entity a must. That requirement assumes two things. First, that an I entity stays the same over time. And second, the responsible party can be identified later, And nothing in the current work talks about either. There's six questions on this slide. Everyone asks what the entity is or what could it do. No one's asking who's responsible for it. Yet that last bullet, attestation evidence, assumes that the entity stays the same, and the parties behind it stay the same. So we're all here in order to, like, prioritize the problems in front of us. SUM, as a list put it, says these these are problems that nothing will work unless we solve them first. And I think this is one of them. My ask is pretty narrow. The architecture requirement work should name identity accountability properties that Don depends on and then say whether Don owns them or it depends on adjacent work. And that should be happened before the protocol work begins. I'm not proposing a solution and I'm not adding the scope. I think having undocumented scope is gonna be scope creep later. Thanks.

[01:31:44] Wes Hardaker: Elliot.

[01:31:45] Elliot Lear: Thank you. I think as a couple of speakers have sort of noted, there are multiple solution spaces here. And Don probably doesn't need to scope down to to handle just one of them. So I would also leave room I would leave room for the possibility that there will be multiple outputs. With so many inputs, it also strikes me that we're gonna need some time with operational experience to see how these things consolidate. Having a common way to to evaluate each of these inputs might be very useful. And on the scope, what I'm seeing, you know, are is the beginnings of a way to do that evaluation. So one of the things you might wanna think about is creating the group saying, have at it, but let's evaluate and come up maybe with some common terminology to understand how to evaluate, and then revisit what should be standardized later.

[01:32:51] Wes Hardaker: So Elliot, you bring up a good point that I think we probably should have mentioned before now, which is that typically, for those that are new to the IETF, I suspect there's a number of you here, IETF working groups are short term groups. By short term, I mean three ish years. Three to five years. Right?

[01:33:07] Elliot Lear: Aren't you optimistic?

[01:33:10] Wes Hardaker: Look. I'm trying. You know, they're not long term research groups. They are types of engineering work that we can accomplish within a reasonable period of time with a group of people that fight for a while. But three to five years is sort of the sort of the ballpark for what does it take to go from nothing to a specification that we get implementation about. And and you're a 100% right that getting implementations out there other people have mentioned it too. Right? If we don't get interoperable implementations in other words, the specification's useless in an interoperability fashion if you don't get multiple people implementing it and interoperating. Right?

[01:33:50] Elliot Lear: So along those lines, I'll just amend my comments to say, admit drafts as working group drafts if you see multiple parties interested, and then say, let's experiment on them and, you know, evaluate. And this is new muscle for us, so it might take a little longer. We can experiment on process too. No. There's no real, you know, written rules here in that regard.

[01:34:13] Wes Hardaker: Three and a half years. Got it. Okay.

[01:34:15] Hisham Musa: Eight, bud. Okay.

[01:34:17] Dan Romascanu: Dan? Yeah. Dan Rutze. I I think I I'm not gonna repeat what others said before. Scope the questions that you have, I think it should start with narrowing either to an organ or to an administrative domain or to an organization because then the scope changes dramatically in the in the context. I also think that we're we're we're missing the point about what are the requirements. I think the requirements should come from the ecosystems that are already implemented and what are their interoperability needs rather than just kind of boiling the the auctions the ocean with idealistic use cases and requirements that may or may not happen in in the near future? Thank you.

[01:35:10] Wes Hardaker: Yeah. I will say in the in the deliverables, which we we skimmed over quickly earlier, you know, there are some preliminary things that I would expect a working group like this to do that would include terminology and architecture and requirements and things like that. So your your point is valid because I think the early planning of of something brand new like this requires, you know, an early agreement on what is actually being solved. And we won't get it all done here today. Ramesh?

[01:35:39] Rashid: You're muted.

[01:35:41] Wes Hardaker: You're muted. Yeah.

[01:35:45] Ramesh Raskar: Thanks. This is Ramesh Raskar, professor at MIT and also lead index work. Is it possible to share one slide on the screen?

[01:35:55] Wes Hardaker: Sorry. What?

[01:35:56] Ramesh Raskar: Can I share a slide on the screen?

[01:35:59] Wes Hardaker: No. We're not doing slide sharing right now. We don't talk about people's solutions. Sorry.

[01:36:04] Ramesh Raskar: Yeah. It's a it's a problem slide, but I think the question that has come up about, you know, do we start with DNS or not start with DNS? I think it's I think it can be discussed in other ways. I think I think the real question we should ask is what's the hybrid solution? So I think a problem statement would be what's a hybrid solution, especially to support b to b as well as b to c use cases. And then there's a subproblem, I think, that's worth introducing to this working group, which is when you don't make it DNS anchored, you get a split between, who maintains the identity, who maintains, let's say, the metadata, like agent card, and who maintains the runtime. And then you have a split of all these three, and the question is, how do you support all those three? So I just wanna make a make a a comment about an additional problem statement there is DNS anchored or not DNS anchored, maybe a hybrid solution. How do we do that? In that hybrid solution, how do you support the split amongst those three? And, you know, I think that this is the problem we have been grappling at the index as well. And so I think this is a very important problem that we need to solve.

[01:37:13] Wes Hardaker: Thank you. John?

[01:37:17] John Zinke: Hi. I'm I'm John Zinke from Akamai. Looking at the fourth slideshow, the requirements, slide four mentions the concept of query by name or query by attributes. And so if we're gonna limit the scope of this to, using DNS, as a as to to get a hold of an agent card, an MDI, from an agent's name, then you can sort of think of this as the the domain name or the sub the beginnings of the domain name, is is basically a scope, an a namespace, and it limits it. So if you're not going out to the whole Internet, you're just gonna say, I'm in this this limited space. And then from the rest of the domain name is either a explicit agent or a bunch of attributes that you're going to then, be looking up. And in the end, you're gonna get back an agent card. So if that's if that's what we're gonna limit, then that's something that's doable, then we're gonna need to extend DNS and get some more context information from the requester into the system, sort of like the eDNS zero, proposal, but no one passes those parameters around in in in in reality. So if we limit the scope to just saying, I wanna take a a name and get back an agent card, then we can also use DNS to get back a bunch of other records such as here's an SVBC records for getting ahold of a communications channel, how to do Dane and TLSA, and how to get back at, let's say, a negotiator that that's sort of a fancier version of a a authoritative name server. So limiting the scope into this one little, you know, make a request, get back a specific thing, might might be a doable thing for for this project.

[01:39:18] Wes Hardaker: Thanks. Thank you, John. So a little bit of context. We were asked to put DNS into the charter because that is sort of one of the discovery mechanisms that's in use within the ETF. People know what it is, know how to start, given that. I don't think there's anybody that believes all the information that DAWN needs to transmit can go over DNS. In fact, can tell you as somebody that works a lot on the DNS, it's not possible. Right? The DNS is not designed for bulk transfer. It's more likely that the DNS would be used to figure out where to go next to do the complete set of transactions. So that's you know, there are other mechanisms. Right? Certainly, blockchain and law and ledgers and things like that are now popular for starting places too, whether that happens or not. So just context for where the charter got started with the word DNS in it. Usama?

[01:40:08] Usama: Yeah. Usama, to you, Tristan. So just following up on what you exactly said. So it seems to me that a lot of the trouble here is that the space has not been fully explored, and which means that, to me, at least, that there is a need for forming a research group which could tackle some of the research problems and come up with some, let's say, some specific consolidated problems which are engineering problems which the engineering working groups can then solve. So I'm working closely with the IRTF chair who also also has some proposal, and we are collaborating together. And we are holding a side meeting just after this in Park Suite 4. And what I would suggest is, like, some of the some of the problem here, what attestation evidence, blah blah blah, that this is really rats. This doesn't really belong to a new working group. So it seems to me overall listening to all the presentations, number one, there was no related work at all. ITUT chair already mentioned that yesterday, also mentioned today. And I'm seeing that a lot of the scope problem is coming from not exploring the whole space which exists, what problem DNS has, what exactly needs to be done in the next stage. Forming a working group will be in my opinion, that would be really immature. So the stage would be that we form a research group which tackles the problem, helps it forming some specific problem which the working group then tackles or multiple it might be multiple working groups which then tackle, which will be easier and collaborative.

[01:41:40] Wes Hardaker: Thanks, Susama. We actually warned the eighties yesterday. They're gonna have to figure out how to take the results of three BoFs and then come up with, you know, a bunch of things that that work together and and research. Anything longer than three and a half years is going to have to be put somewhere else and that's not our responsibility in this group, unfortunately.

[01:41:59] Adrian Farrel: But I think that's an interesting question because the logical and staged approach of of working through all this denies any urgency. And we've got a trade off between all the things that we need to do and how we're gonna build a whole system. Sam?

[01:42:24] Sam Betts: Thank you. So Sam Betts, Cisco and maintainer of the AI catalog project. A couple of comments listening to everyone else. I think something we need to to make sure is captured is that there's there should be a split between making something available to be discovered and layering on how those things can be discovered. So when you think about, like, talking in the, like, DNS space, you've got the DNS is the, like, making things available to be discovered, and then they've also got the layering on it, like, the service discovery and all of the other components to add to the actual discovery piece. And so I see that split where you have sort of making things available to be discovered and when you take into account, like, what you might not have a web server, you might not have a domain. So you need something that can take all of that into account to make things available to be discovered, but not necessarily implementing the discovery piece, and then layering on top search or the other indexing to make these things available to be found. And the other comment was around scoping it down to just AI agents. So in the AI catalog project, we found that AI agents and tools were the two most interesting things that people are interested in finding today. So tools being MCP servers or or similar. So those two entities being able to find each other. So whether an AI just finding another AI agent or just finding a a tool that it can use, those are the two kind of main entities where we're seeing people want to be able to discover.

[01:44:05] Wes Hardaker: Alright. Thank you. Sam oops. Sorry. Not Sam. Oscar. Please keep comments to a minute or less.

[01:44:11] Adrian Farrel: Yeah. So I've locked the queue. Everybody has one minute.

[01:44:15] Oscar: Okay. So it's just two comments. So you have one in the scope is what functionality does a Discover entity provide. I would also add when regarding that functionality, who can use that functionality. I I might be able to advertise some functionalities, but I not might not be able to to use them. Only a director can use them in an organization or only a certain group of of users. And second one, we are assuming that all let's say, once something is discovered, it can be discovered across, say, different domain or different clusters. So maybe we can also include the limiting the advertisement of this entity or even some cases hiding the advertisement of some entities to depending on the user that is connected. So this can especially in enterprise organization, these types of questions are sometimes of of importance versus, say, a more general case where everything is more open and everything is discoverable. In enterprise, it's not not the case.

[01:45:21] Unidentified Participant: Thank you.

[01:45:24] Hisham Musa: Yeah. So my comment is about the scoping of what entities should we start off with. I think this question has two ways of thinking. Like, we can approach it either we look at the different entities that we can discover. We try to find a common dominant denominator. Sorry about the word. And if there is something common between them, then perhaps we can include those different subset of entities, and that's what we start off with. But if we cannot find such a thing, and the other approach would be is what is the current pressing scenarios that we need to address. And I think I agree with Sam. Depending on what we have today, we think that agents and tools and perhaps will add skills as well are depressing discoverable entities that we need to address. That's just a comment. Roberta?

[01:46:15] Roberta: Hey, folks. Roberta here. One of the things that I'm seeing here is that we need to start collaborating more together here. This is something that is pretty common to come here. And we know that everyone here has one different opinion, and we want to be heard and to be a part of this. Right? Everyone wants to to put, like, the flag into the AI thing. But in here, I think we have a we have an opportunity with this group to not let the AI thing get into groups that has, well, rounded scopes until we find the reason to those groups working on something that we propose. So this group can be a group that we can work into the subject fully and or and organizing together so we can really join forces in here and not, you know, let the AI take control of other agendas. And I think this group is really good for discovery because we have a lot of answers here that we don't have the full picture yet because it this is pretty brand new. Right? And this is why I think our hands on deck approach on this group and with this context might be really, really good for the organization itself. You know? So we don't flood the other groups with some of the subjects, but also because we don't know actually how part of those kind of stuffs will work. And, specifically, I I'm really interested and see how security will play off onto some of the stuff about skills, some of the stuff about agents. And I think discovery has a bunch of of issues that I'm really interested into working. But right now, we have lots of groups that those types of of works could be proposed, but no group that has the context of this, you know, this AI mass that we have. And we have the the one place that we could really collaborate and and argue. Right? Yeah.

[01:48:34] Unidentified Participant: I noticed in the scope, it's all about what is discovered and not how. And I'm kind of wondering, it's gonna be difficult to obstruct all those use cases into a common taxonomy. And I can see all these comments arguing about what should we focus on. And I'm I believe we have a better chance of success if we step away from the data model and just focus on the discovery and let the market solve the data model and then focus on that later. Because the discovery problem is something that we all know and we have across all the use cases, and we are all arguing about the data model. Thank

[01:49:13] Wes Hardaker: you. Xu Ping?

[01:49:14] Shuping Peng (Xu Ping): Hi, Xu Ping from Huawei. I think we would be better to narrow down the scope, have a clear focus. I mean, instead of looking at so many different types of entities, would be better if we could focus on the agent. And, also, regarding the scenarios, it would be better if we could start with someone some scenario that is manageable and easy to start with. And I think the solutions, the DNS or not, I think is largely depend on what scenarios we select first. Okay.

[01:49:50] Pradhyumna: Thank

[01:49:51] Wes Hardaker: you. Thank you. Rashmit.

[01:49:53] Rashmit Ananthanarayanan: So just a couple of clarification notes from what I heard. B two b and b two c is definitely something that we can take a look at and basically get inspired on and see whether we can actually take the use cases according to that and and figure out what what we can do in there. The second thing that I I heard from somebody in the audience about doing some homework, I think there's a gap analysis document and draft that actually can be useful in this case. If we do that, we might actually find out what is needed to be done, what needs to be added. DNS comes up a couple of times. DNS could be part of the solution. It might not be all the solution. It could be a hybrid solution. So we will definitely find out once we actually go to the working group if it happens. And but but it could be part of the equation. The the other thing I wanna actually just keep emphasizing on is that there are a whole bunch of functional groups blocks that actually cover this system. Authentication is one of them. It's think about, like, three GPP, how you actually enter the the the domain. Your phone basically authenticates with the network. Network authenticates with the with the phone, and then you enter the network. That is way out there before you actually discovery happens. Discovery basically just takes into account that you have already been verified. Your entity has already been authenticated. And then you are entering the system and basically your your discoverable object is available to be discovered by other people, by other entities. Now to start with, I think agents and and tools could be the starting point. But as the charter actually says, we we should devise a mechanism that could be easily extendable if required. If not, then we basically fix it to these two as much as we can. So extendable, but let's start from agents and tools that have immediate needs, and then we can extend it to other entities as required.

[01:51:47] Wes Hardaker: Thank you. Leslie?

[01:51:49] Leslie Daigle: Leslie Daigle, ThinkingCat Enterprises. I think that everybody in this room should read RFC thirty four zero four and its related documents, which is previous work on a DNS based dynamic delegation discovery service before ruling in or out whether or not the DNS is part of your solution. I don't know whether that work is leverageable for the requirements here, But from everything just discussed today, I can say that the working group that produced it went through a lot of the same thought processes. So definitely that work needs to be leveraged either to say, yeah, some of these ideas apply or to describe why not. Otherwise, you're reinventing the wheel.

[01:52:33] Wes Hardaker: Thanks, Leslie. And then, Rashid, you get the the last word before we are going to make Eric stand up next.

[01:52:39] Rashid: It's an offer of the of the scope. I have some comments that we I think that's it's it's a bit

[01:52:48] Wes Hardaker: Yeah. Get really close

[01:52:50] Rashid: Yeah. To Okay. I think that's my I I have some comments about the scope. I it will be better if we can we can we can add some mechanism about the about the the behavior after after discovery and and and interaction. Because the problem of observability is very important, sir.

[01:53:18] Wes Hardaker: Alright. Thank you. So we are at the end of the queue. We're going to ask our AD to speak here in a second, but I will reiterate more discussion on the mailing list about, you know, what we agree upon and what sort of the next steps would be would be fantastic. Right? You can go back to the message I posted on June 12 or something asking asking what is the what is the one use case that we wanna do? A lot of people have mentioned, I think starting with Ted, let's find, you know, something that's already in existence and then come up with an interoperable way to do something that is already being done sort of in industry and proprietary or at least, you know, within a boundary kind of way. But with that, Eric, what would you like to see next from this group?

[01:54:06] Eric Vyncke: First, let me try to give my point of view. So So it looks like it's clear that engineers like us likes complexity, right, trying to go and boil the ocean, which is my fear. I heard about a lot of fair discussion, agreement, but also a fair amount of disagreement, respectful disagreement. So that's perfectly fine. To be honest, I entered the room. I'm sure really about the outcome of the both and whether we'll be chartering something. I am way more positive now. We are not yet there. Don't take me wrong. But I'm way more positive. As many voice say, yeah. It's doable, but but but but but doable. So that's pretty cool. The in their operation, I think, is key and whether there is interest to the market. The trust is the elephant in the room. Right? We we need to figure out one way out of it. And just to be clear, the charter already said, yeah, we will be working with WIMSE, SCITT, and others at UT. That's important. The remark about DNS in the charter and is in the charter not mandatory. Right? If you look about the phrasing, the chair has been that we are proposing the charter has been very careful. It was based on an input of mine because in a similar case for the DM, Digital Emblem, both in the the group, unless until we set DNS, we were going everywhere. Once it was kind of agreed to put DNS, and again, it's it's not DNS. It's just a solution, just in the draft charter right now, but it basically unblock the DM working group once we say we start initially with this. And this is basically my point. I would leave the conclusion to the chairs. And thanks for everyone, 200 people in the room for this. And how many agent?

[01:55:58] Wes Hardaker: All right. Thank you very much. So with that, I think we have a direction. I hope that the IESG has a good time debating this week as a whole. It will be an entertaining, I think, next week for you guys with a longer than a two hour normal meeting. With that, thank you all for coming. We are gonna end early because opening the mics again would be crazy. So we're not going to. Adrian, any No.

[01:56:25] Adrian Farrel: Just thank you all for your mic cue discipline. That really made it possible for everyone to have their say.

[01:56:33] Wes Hardaker: So, we got a lot of feedback. We will take it and probably mess with the charter a little bit, but keep discussing on the list. Thank you very much.