[Dawn] Re: Comments to the DAWN proposed charter,

[Linda Dunbar <[e-mail]>]

Adrian,

Thank you for reading the draft so carefully and for the very helpful distinction between the two uses of "discovery."

To clarify, I did not intend either Agent Discovery or Gateway Discovery to fall within DAWN scope. In the AAP draft, "Gateway Discovery" is only meant as a local bootstrap mechanism for attachment, and "Agent Discovery" is simply used as background context.

What I was trying to ask is whether discovery of attachment related properties might fall within the DAWN charter.
If the discovery of those properties is considered in scope for DAWN, we will write a separate draft.

Thank you very much,

Linda



From: Adrian Farrel <[e-mail]>
Sent: Saturday, May 2, 2026 11:39 PM
To: Linda Dunbar <[e-mail]>; [e-mail]
Subject: RE: [Dawn] Re: Comments to the DAWN proposed charter,

Hi Linda,

I read your draft, and it seems to me that the term "discovery" is used for two different things:

  1.  Agent Discovery: "Directory Service: A service or registry that enables discovery of agents based on their capabilities and returns information associated with those agents". That seems pretty close to what DAWN is talking about. In your Figure 1, this seems to map to the interactions A and B. I think you also call this "Capability Discovery".
  2.  Gateway Discovery: "GW-DISCOVER: The Agent initiates discovery of a candidate  Agent Gateway using locally configured or bootstrap mechanisms". This is interactions C and D in your Figure 1. I don't think this is necessarily within the scope of DAWN. It feels more like a local matter that might be addressed (as you suggest later in the document) using a mechanism like Anycast.

In your discussion of capability discovery, you say "the Agent has identified the target agent(s) but may not know where those agents are currently attached in the network" but (presumably) in your Anycast approach, the Agent would have been told by the Discovery Service what Anycast address to use to attempt to find the gateway and so reach the target agent. You do later say "This enables discovery systems to return information about how and where an Agent is currently attached. "

So, to try to answer your question...

I'd start by saying that the scope of DAWN is whatever the community decides is the scope of DAWN. But as a starting point I'd say that type 1 discovery is in scope, but that type 2 discovery is out of scope.

You may find the recent discussion of "discovery scope" useful. As a working definition in the latest yet-to-be-posted version of the terminology draft, we have:
Discovery Scope: The explicit domain over which discovery is performed. Discovery scope may be specified in one or more dimensions, including but not limited to administrative identifiers (e.g., DNS domain names, AS numbers), trust domains, topological or distance metrics, geographic or jurisdictional boundaries, and temporal constraints. Discovery scope bounds the search space and supports scalability, relevance, and policy enforcement.

Best,
Adrian


From: Linda Dunbar <[e-mail]<mailto:[e-mail]>>
Sent: 02 May 2026 02:20
To: [e-mail]<mailto:[e-mail]>; 'Aijun Wang' <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: RE: [Dawn] Re: Comments to the DAWN proposed charter,

Adrian,

Thank you for the clarification, and yes, I have read the current DAWN drafts. I understand and agree that DAWN should begin with the problem space and requirements, and that the work should remain solution-agnostic at this stage.

I have been working on https://datatracker.ietf.org/doc/draft-dunbar-agent-attachment/,  which describes how an AI agent attached to an edge node or private network can establish attachment and derive attachment-related properties, such as its attachment point, serving domain, reachable endpoint information, and supported communication properties.

My question is whether the DAWN discovery problem space is intended to include attachment-related properties, since they can influence agent reachability and communication establishment within a controlled administrative domain..

Thanks,
Linda

From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of Adrian Farrel
Sent: Thursday, April 30, 2026 1:54 AM
To: 'Linda Dunbar' <[e-mail]<mailto:[e-mail]>>; 'Aijun Wang' <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: [Dawn] Re: Comments to the DAWN proposed charter,

Hi Linda,

I'm going to take a moment on this thread with its striking subject line to say: There is currently no proposed charter, but I will be drafting it tomorrow.

The short answer to your question is "no". DAWN needs to start by understanding the problem space and requirements. That's what the current DAWN drafts do:
https://datatracker.ietf.org/doc/dawn
You have read the drafts, haven't you? :-)

Those drafts make an attempt to be agnostic about solution technologies. If we stumbled on that, please shout. Although the problem space document has some sections that need to move into a future gap analysis draft that *do* talk about solution technologies.

Perhaps the boldest statement we make is that the solution should use existing IETF protocols where possible. (REQ-PROTO-2). Maybe "where possible" is both a dangerous snag and a useful "get out of jail free card." However, we believe that inventing new protocols to do what existing protocols already do (or can easily be made to do) is not a good idea (even if it is fun and secures our jobs).

Cheers,
Adrian

From: Linda Dunbar <[e-mail]<mailto:[e-mail]>>
Sent: 29 April 2026 17:34
To: Aijun Wang <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: RE: [Dawn] Comments to the DAWN proposed charter,

Is DAWN only limited to DNS based discovery?

Linda

From: Aijun Wang <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, April 28, 2026 6:46 PM
To: Linda Dunbar <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: RE: [Dawn] Comments to the DAWN proposed charter,

Hi, Linda:

The attachment-related information and the discovery mechanism should fall within the scope of DMSC, which adopts a gateway-based approach for multi-agent collaboration.
We cannot expect all the mentioned entities ("tasks, workloads (cf. WIMSE), endpoints (cf. CoRE), services, AI agents") to hold complete attachment-related information.
In fact, the DNS-based discovery mechanism (DAWN), which is more suitable for the above entities, is obviously different from the gateway-based approach (DMSC).

Aijun

From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of Linda Dunbar
Sent: Wednesday, April 29, 2026 8:03 AM
To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: [Dawn] Comments to the DAWN proposed charter,

Adrian,

Thanks for the detailed link for the DAWN proposed charter. I think it is really useful to have a home for discussing discovery for a broad class of "entities".

I have a couple of comments on the current scope and terminology.

First, the charter states:

"Discovery: A process by which an entity can find another entity... The purpose of this work effort is limited to just this element."

It would be helpful to clarify what information is expected to be returned by discovery. Existing systems, such as Google's A2A Agent Card, already include endpoint information that allows a client to contact the agent. However, an endpoint URL alone does not ensure that the communication path is reachable, policy-compliant, or optimal.
Therefore, I suggest the charter clarify that discovery may include basic communication properties, such as endpoint identifiers, URI/FQDN, supported protocols, and security requirements, while reachability verification, path selection, and communication optimization remain out of scope.

Second, agents may be dynamically attached to different access routers, gateways, or ingress points over time. Therefore, discovery may need to return attachment related properties in addition to static endpoint information. Such properties can help indicate where and how an entity is currently attached, and can provide the useful information for future routing or control-plane mechanisms to exchange attachment details and support more optimal path selection when attachment changes dynamically.

Therefore, I suggest adding a scoped work item on the attachment properties, for example:

Define how entities expose attachment related properties, including endpoint identifiers, supported protocols, attachment point identifiers, and domain information, and how such properties can be made available to discovery systems in a consistent and interoperable manner.

This would still stay within the discovery scope,  i.e., defining what attachment related information is available to discovery systems.

Best regards,
Linda

-----Original Message-----
From: Adrian Farrel <[e-mail]<mailto:[e-mail]>>
Sent: Friday, April 24, 2026 4:11 PM
To: Linda Dunbar <[e-mail]<mailto:[e-mail]>>
Subject: RE: [Dawn] Early heads-up on planned BoF request

Hi Linda,

I hate long URLs in text emails that wrap.
But I hate HTML emails even more!

Not too hard to see what you should have done to fix the problem, but here is a tiny URL that might help you:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftinyurl.com%2F2238mxn7&data=05%7C02%7Clinda.dunbar%40futurewei.com%7Ccafa223024b5446cd45808dea256b429%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C639126690523559245%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=UsDI41r%2FUgjk8gvn9s7e4MkHPAmAhmc0sB4jdLVDhYY%3D&reserved=0<https://tinyurl.com/2238mxn7>

Adrian

-----Original Message-----
From: Linda Dunbar <[e-mail]<mailto:[e-mail]>>
Sent: 24 April 2026 19:53
To: [e-mail]<mailto:[e-mail]>
Subject: RE: [Dawn] Early heads-up on planned BoF request

Adrian,

I can't find the document under this link 404 Page error:

broad description of the work topic at
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdanielkinguk%2Fdiscovery%2Fblob%2Fmain%2FDAWN%2520Work%2520Descriptio&data=05%7C02%7Clinda.dunbar%40futurewei.com%7Ccafa223024b5446cd45808dea256b429%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C639126690524371108%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=CLsgfj7sFAdsUoPVKkc%2BrRqzdSZwRA3bgnyPhL92KLg%3D&reserved=0<https://github.com/danielkinguk/discovery/blob/main/DAWN%20Work%20Descriptio>
n.md and I expect that that will provide some of the text for the charter.

Linda

-----Original Message-----
From: Adrian Farrel <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, April 23, 2026 10:02 AM
To: 'The IESG' <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: [Dawn] Early heads-up on planned BoF request

Hi IESG,

Per the entry in the "Important Dates" page for IETF 126:
> Working Group and BOF scheduling begins. To request a Working Group
> session, use the IETF Meeting Session Request Tool. If you are working
> on a BOF request, it is highly recommended to tell the IESG now by
> sending an email to [e-mail]<mailto:[e-mail]> to get advance help with the request.

So this is me letting you know that we are working on a BoF request for "Discovery of Agents, Workloads, and Named entities (DAWN)"

We currently have three I-Ds (see https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdawn&data=05%7C02%7Clinda.dunbar%40futurewei.com%7Ccafa223024b5446cd45808dea256b429%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C639126690524479290%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=UeyXwtSSjstj1mZJqR8F3Gd7LQORyj%2Ftu9VxIUBSLmg%3D&reserved=0<https://datatracker.ietf.org/doc/dawn>)
and plans for a couple more. But more work is needed on them.

We also have a broad description of the work topic at
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdanielkinguk%2Fdiscovery%2Fblob%2Fmain%2FDAWN%2520Work%2520Descriptio&data=05%7C02%7Clinda.dunbar%40futurewei.com%7Ccafa223024b5446cd45808dea256b429%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C639126690524552470%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=zoOl7N4Wv%2B7HpQl7NLzYHEEMosPhbPJH9rO62VNonAg%3D&reserved=0<https://github.com/danielkinguk/discovery/blob/main/DAWN%20Work%20Descriptio>
n.md and I expect that that will provide some of the text for the charter.

There is solution-specific work available at:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-mozleywilliams-dnsop-dnsaid%2F&data=05%7C02%7Clinda.dunbar%40futurewei.com%7Ccafa223024b5446cd45808dea256b429%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C639126690524620573%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=PbZhiOeH2l154akgvc6zlw8Lp47ojRzxUelJDdZq5K4%3D&reserved=0<https://datatracker.ietf.org/doc/draft-mozleywilliams-dnsop-dnsaid/>
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-mozley-aidiscovery%2F&data=05%7C02%7Clinda.dunbar%40futurewei.com%7Ccafa223024b5446cd45808dea256b429%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C639126690524689900%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=2qj0zLep5MnYIc5q4Kkp6uJ3MZ4MXGicXTYmfjugaNI%3D&reserved=0<https://datatracker.ietf.org/doc/draft-mozley-aidiscovery/>
This work was dispatched at DNS-Dispatch at IETF 125 with the result:
> Organise a BoF, also to further clarify the problem space and approach
> the DNSOP AD for further guidance.

While these I-Ds are focused on AI and have decided on a specific solution space, we believe they fit nicely within the DAWN remit and demonstrate both that a solution using existing IETF technology is possible and that there is serious interest in working on the problem.

The proponents would love to know which Area this fits in (ART because it is application-oriented, INT because DNS may be the solution?) and which AD would like to work with us on this.

Best,
Adrian

_______________________________________________
Dawn mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>