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

[Adrian Farrel <[e-mail]>]

I agree about “common requirements among the artifacts.”

 

I thought that was what we had captured, but on re-reading I see that the text was misleading. I have made some clarifications.

 

Your text on “local gateway” has informed my proposed text in the current version “establishing the relationship.”

 

Cheers,

Adrian

 

From: Aijun Wang <[e-mail]> 
Sent: 07 May 2026 03:52
To: [e-mail]
Cc: [e-mail]
Subject: RE: [Dawn] Re: Comments to the DAWN proposed charter, 

 

Hi, Adrian:

 

The reason that the DAWN charter cover AI agents, tasks, datasets, services, and additional resource types together, is that there should be some commonality among them.

The discovery mechanism in DAWN should accomplish the “Greatest Common Divisor” of the discovery components and process, that can be used by all of them.

 

Then, should we find first what’s the common requirements among the above artifacts?

Some detail replies are inline below.

 

Aijun

 

From: [e-mail] <mailto:[e-mail]>  [mailto:[e-mail]] On Behalf Of Adrian Farrel
Sent: Thursday, May 7, 2026 12:27 AM
To: 'Aijun Wang' <[e-mail] <mailto:[e-mail]> >
Cc: [e-mail] <mailto:[e-mail]> 
Subject: [Dawn] Re: Comments to the DAWN proposed charter, 

 

Hi,

 

I think there are two stages in a gateway system:

*	How does the source entity find a suitable gateway that provides access to the/a target entity?
*	How does the gateway know about which entities it provides access to, and how does it route communications to them?

 

I imagine an architecture like…

*	Entities local to a gateway are discovered by the gateway
*	Remote entities discover gateways and the entities they serve
*	Remote entities send communications to the gateway which forwards them to a local entity

 

I suppose the first of these could be in scope for DAWN, but not necessarily.

I think the second case is definitely in scope for DAWN.

[WAJ] You mean how the entities discover gateway? It seems the process will be far different from how the entities find another communication peer?

 

The third item is definitely not in scope.

 

So, I wonder, rather than try to say what DAWN will focus on in a limiting way, can we come up with a form of words that says what is out of scope? Then we can add that to the charter text.

Something like:

   Additionally out of scope for DAWN are:

*	Communication between gateways and the local entities they serve

… but I suspect that doesn’t quite capture it for you, so please suggest text.

 

[WAJ] How about:

Additionally out of scope for DAWN are:

--AI agent gateway based registration, communication between AI agent gateway and the local entities they serve

 

Adrian

 

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

 

Hi, Arashmid:

 

Then, I suggest DAWN focus on non-gateway based discovery, in which they( “tasks, datasets, services, and additional resource types”) have more common characteristic.

 

Aijun

 

From: Arashmid Akhavain [mailto:[e-mail]] 
Sent: Tuesday, May 5, 2026 4:36 PM
To: Aijun Wang <[e-mail] <mailto:[e-mail]> >; [e-mail] <mailto:[e-mail]> ; 'Linda Dunbar' <[e-mail] <mailto:[e-mail]> >; [e-mail] <mailto:[e-mail]> 
Subject: RE: [Dawn] Re: Comments to the DAWN proposed charter, 

 

Hi Aijun,

 

DAWN problem statements and requirements must remain both solution and implementation agnostic. While DNS‑based mechanisms satisfy a subset of discovery scenarios, DAWN targets a broader and capability‑centric discovery mechanism.

The discovery mechanism enables entities to find other entities with a set of required capabilities. AI agents represent one entity class only.  Even within this class, agents may need to discover not only other agents but also tasks, datasets, services, and additional resource types. So, solution proposals including those that address scalability must address the general entity discovery problem space and not be limited to AI agents only.

 

Entities will be required to go through a set of processes to become eligible to discover others and to be discoverable themselves. Some of these processes may even happen before the discovery stage. Discovery of course might need to implement a validation block. These are all implementation details that we will eventually dive into and resolve. That said, it is important to note that while a distributed discovery architecture may introduce distinctions between access‑layer and core‑layer mechanisms, it does not inherently require entities to register with gateway nodes.

 

Best regards,

Arashmid

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

 

Hi, Adrian and Linda:

 

I agree that DAWN should start with the problem space and requirements.

 

However, we can see that discovery of the entities within the DNS system and discovery of the AI agents in a gateway-based network show considerable differences.

The latter is more tightly coupled with other protocols.  For example:

 

how AI agents register to gateways,

what information gateways can provide to AI agents,

and how to synchronize information among gateways.

 

All these protocol building blocks are the primary focus of the AI Agent Gateway approach for AI agent collaboration within DMSC ([e-mail] <mailto:[e-mail]> ).

 

Aijun

 

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 <https://tinyurl.com/2238mxn7> &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 

 

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 <https://github.com/danielkinguk/discovery/blob/main/DAWN%20Work%20Descriptio> &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

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 <https://datatracker.ietf.org/doc/dawn> &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),

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 <https://github.com/danielkinguk/discovery/blob/main/DAWN%20Work%20Descriptio> &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

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 <https://datatracker.ietf.org/doc/draft-mozleywilliams-dnsop-dnsaid/> &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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-mozley-aidiscovery%2F <https://datatracker.ietf.org/doc/draft-mozley-aidiscovery/> &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

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]>