Suggested edits to the charter#61
Conversation
Few Editorial changes Added a suggestion to open the door to considering other potential candidate solutions besides DNS Included DNS-based WGs in the list of the WGs to coordinate with
| benefits from established trust models, supports proven delegation and | ||
| federation architectures, and allows organisations to independently | ||
| publish discovery information. | ||
| publish and manage discovery information. |
There was a problem hiding this comment.
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.
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.
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.
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.
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.
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.
| DNS as a likely initial protocol upon which to build a discovery | ||
| protocol. | ||
| communication, authentication and privacy. The WG will consider existing | ||
| IETF solutions, such as DNS, or solutions porposed under other organizations |
There was a problem hiding this comment.
I think there are several points here:
- The IETF has a discovery protocol (DNS) and should take that as the starting point
- If there are other existing IETF protocols that should be considered, we should call them out explicitly
- The IETF is typically not good at considering protocols made outside the IETF unless they are brought in by proponents, and even then it is unclear how the process of "fixing" those protocols would be done.
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."
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.
There was a problem hiding this comment.
i think we should leave this topic to the BoF.
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?
| The DAWN working group will seek to coordinate with other WGs and | ||
| external standards bodies as necessary. These may include WIMSE, | ||
| CORE, CATS, ITU-T SG17, 3GPP, and the Linux Foundation. | ||
| CORE, CATS, DNS-related WGs, ITU-T SG17, 3GPP, and the Linux Foundation. |
There was a problem hiding this comment.
It's a good point, but I think we have to call them out by name.
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.
|
I am actually confused now... If we wanted to start by DNS only, why we would even need to establish another working group? I guess we won't be needing the PS draft anymore either!? |
| protocol. | ||
| communication, authentication and privacy. The WG will consider existing | ||
| IETF solutions, such as DNS, or solutions porposed under other organizations | ||
| (e.g., Linux foundation) that address DAWN problem space as initial starting |
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).
Cherry-pick some of the proposed changes from #61
|
I made a Commit at b94bbfa to cherry-pick the changes we have agreement on. Please look. Other discussions should, as Wes says, come to the mic in the BoF and/or be raised on the list. |
4 participants
Few Editorial changes
Added a suggestion to open the door to considering other potential candidate solutions besides DNS Included DNS-based WGs in the list of the WGs to coordinate with