Suggested edits to the charter #61
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -9,7 +9,7 @@ Entities may be tasks, workloads, endpoints, services, AI agents, etc. | |
|
|
||
| The principle use case of this working group will be focusing on how | ||
| an AI agent can find another AI agent with specific capabilities, or | ||
| how a workload orchestrator can locate compute resources in a | ||
| particular jurisdiction, or how a service consumer can discover | ||
| providers that support a required protocol version. In each case, an | ||
| entity needs knowledge of any other entity's specific properties | ||
|
|
@@ -24,12 +24,12 @@ To support these goals, an interoperable and generic discovery | |
| mechanism is needed that builds on existing protocols and tools, | ||
| benefits from established trust models, supports proven delegation and | ||
| federation architectures, and allows organisations to independently | ||
| publish and manage discovery information. | ||
|
|
||
| ## Scope | ||
|
|
||
| Discovery in the DAWN context is limited to being able to "find me an | ||
| entity to interact with" within collaborating organizations. This includes | ||
| communication about the following attributes: | ||
|
|
||
| - What is the entity's type and classification? | ||
|
|
@@ -41,9 +41,10 @@ communication about the following attributes: | |
|
|
||
| Where possible, any solutions work will be built in a modular way | ||
| using existing IETF protocols that provide support for any needed | ||
| communication, authentication and privacy. The WG will consider existing | ||
| IETF solutions, such as DNS, or solutions porposed under other organizations | ||
|
Collaborator
There was a problem hiding this comment. I think there are several points here:
Collaborator
Author
There was a problem hiding this comment. I see your point, yet not sure if the text we proposed contradicts what you have highlighted. I agree that the text could be more explicit about DNS, but the point is that I wanted to draw attention to the possibility of considering other solutions. As for external work outside IETF, I agree with you. hmmm, Would the following be more appropriate? say something like "The WG will consider existing IETF solutions, such as DNS and its extensions including DNSSEC, DNS-SD, DoH, DoT, etc as the starting point upon which discovery protocols would be built. The group may also consider solutions proposed under other organizations (e.g., Linux foundation) that address DAWN problem space to draw inspiration."
Collaborator
There was a problem hiding this comment. I think that you and I are not going to agree on this point. It is probably worth taking to the list for discussion. It's one of my two "Big Questions" (should we start with DNS? should we discover more than AI agents?). See https://mailarchive.ietf.org/arch/msg/dawn/E9euuIr7ZmSk00cudDcLFT-coL4/ The opinion of the chairs and AD is that the WG should start by attempting to use DNS plus extensions, but be aware that it might not do the job. The current text, I think says that. And we didn't want to immediately open the doors for discussion of other options until we find out that DNS doesn't do the job.
Collaborator
There was a problem hiding this comment. i think we should leave this topic to the BoF.
Collaborator
There was a problem hiding this comment. So, does this mean that even if we were to bring MCP, or discovery part of A2A or AGNTCY to the IETF, DAWN still wouldn't consider their working solutions because they are not DNS-based? |
||
| (e.g., Linux foundation) that address DAWN problem space as initial starting | ||
|
Collaborator
There was a problem hiding this comment. I'd suggest we don't add explicit org names in the main charter, but leave that to the work-with section at the bottom instead (when needed). |
||
| point upon which discovery protocols would be built. | ||
|
|
||
| Although initially focused on discovery of AI agents, agentic tools, | ||
| and agentic skills, the WG is | ||
|
|
@@ -84,7 +85,7 @@ roughly in this order: | |
|
|
||
| The DAWN working group will seek to coordinate with other WGs and | ||
| external standards bodies as necessary. These may include WIMSE, | ||
| CORE, CATS, DNS-related WGs, ITU-T SG17, 3GPP, and the Linux Foundation. | ||
|
Collaborator
There was a problem hiding this comment. It's a good point, but I think we have to call them out by name.
Collaborator
Author
There was a problem hiding this comment. sure, I think these are the active ones: DNSSD, DNSOP, ADD, DELEG. I can add them to the PR no problem. |
||
|
|
||
| ## Milestones | ||
|
|
||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not clear what "management of discovery information" means. It is probably not something the discovery protocol is responsible for, and it seems to open the door to "registration" and other important but out-of-scope functions
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmmm, I am thinking that organizations can publish their discovery information and also manage them as in if they want to update the published information, delete them, control who can access the information, etc. Maybe manage is not the right term. What I was aiming for is to say that "not only publish". If you think that makes sense, any alternative suggestions on how to reflect that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK. I agree this is an important piece of the ecosystem. Like the initial "publication" / "registration" making updates to or withdrawing this information is going to be a necessary component of the whole system.
But, it overly broadens the scope of DAWN to work on the protocol elements of this function. Indeed, compare with how information gets into the DNS for "normal" lookups.
I think that this is best handled by a (new?) I-D that describes the whole system from publication, through discovery and capabilities exchange, and into selection of agents. At the moment, I don't know where that I-D lives, but I think it would be of interest to people working in DAWN and AIProto
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Personal opinion: I think management will likely fall to the list of future items to work on, rather than something that should be tackled in the first DAWN round.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with keeping the scope narrow during the initial phase. Focusing solely on enabling Discovery clients to publish their discoverable information sounds like a reasonable starting point. That being said, should we explicitly list 'management' under out-of-scope items, or as a candidate for future phases?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am confused now. Are we saying that in phase one applications can post their entry in DAWN, but they will have no means to modify them and even remove them? Even DNS provides this functionality today.