This draft contains extensive extraneous background text and numerous redundant
elements -- a pattern common in LLM output. Did you use an LLM when preparing
this document?
It is difficult to extract the actual proposal from all of the unnecessary
description and tangential recommendations. However, this draft appears to
assume that the mapping from "common, human-readable name of a family of
agents" ("salesforce" in the example) to "domain name with information about
how to reach the right agent" (salesforce.com) is well-known without any
centrally managed registry. I would like to see more discussion of this
assumption, and how it is expected to be fulfilled.
The draft does not discuss HTTP ".well-known/", which is the solution I would
expect in this problem space. In general, .well-known/ is much easier to
provision, update, and secure than DNS zone contents. The only possible
explanation for why DNS might be preferred is given here
(https://www.ietf.org/archive/id/draft-mozleywilliams-dnsop-bandaid-00.html#section-2.1.8-3):
"This eliminates the need for a separate handshake or negotiation phase for
discovery, reducing latency and improving throughput in high-volume
environments."
However, this HTTP resource is highly cacheable, so in high-volume environments
these HTTP requests should be rare, resulting in minimal additional latency.
I am not able to understand the actual proposed record contents. It would help
if the diagrams could be formatted correctly. (They are corrupted by various
formatting errors in this version.) Some of the examples use values that do
not currently exist (e.g. alpn="a2a") or imply the use of new parameters whose
semantics are not clear.
--Ben Schwartz
________________________________
From: Behcet Sarikaya <[email protected]>
Sent: Thursday, October 16, 2025 2:29 PM
To: dnsop <[email protected]>
Cc: Jim Mozley <[email protected]>; Nic Williams <[email protected]>;
Roland Schott <[email protected]>
Subject: [DNSOP] Re: New Version Notification for
draft-mozleywilliams-dnsop-bandaid-00.txt
Hi all, We submitted our draft entitled: Brokered Agent Network for DNS AI
Discovery If a slot is available we will be happy to present it at IETF 124 in
Montreal. Your comments will be appreciated. Behcet in the name of the authors
On Thu,
Hi all,
We submitted our draft entitled:
Brokered Agent Network for DNS AI Discovery
If a slot is available we will be happy to present it at IETF 124 in Montreal.
Your comments will be appreciated.
Behcet
in the name of the authors
On Thu, Oct 16, 2025 at 3:56 AM
<[email protected]<mailto:[email protected]>> wrote:
A new version of Internet-Draft draft-mozleywilliams-dnsop-bandaid-00.txt has
been successfully submitted by Jim Mozley and posted to the
IETF repository.
Name: draft-mozleywilliams-dnsop-bandaid
Revision: 00
Title: Brokered Agent Network for DNS AI Discovery
Date: 2025-10-16
Group: Individual Submission
Pages: 37
URL:
https://www.ietf.org/archive/id/draft-mozleywilliams-dnsop-bandaid-00.txt<https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-mozleywilliams-dnsop-bandaid-00.txt__;!!Bt8RZUm9aw!_TlFCFU271HDl1Nz2GgMM7C9TBgi5tVFPnVpccnkILLxfNv6J3fmyOW_ukcXCvyKQ4KC9ND7RdpM4yeKUw$>
Status:
https://datatracker.ietf.org/doc/draft-mozleywilliams-dnsop-bandaid/<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-mozleywilliams-dnsop-bandaid/__;!!Bt8RZUm9aw!_TlFCFU271HDl1Nz2GgMM7C9TBgi5tVFPnVpccnkILLxfNv6J3fmyOW_ukcXCvyKQ4KC9ND7RdqsDbUhng$>
HTMLized:
https://datatracker.ietf.org/doc/html/draft-mozleywilliams-dnsop-bandaid<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-mozleywilliams-dnsop-bandaid__;!!Bt8RZUm9aw!_TlFCFU271HDl1Nz2GgMM7C9TBgi5tVFPnVpccnkILLxfNv6J3fmyOW_ukcXCvyKQ4KC9ND7RdrT4HWc1Q$>
Abstract:
The emerging field of agent-to-agent protocol standards introduces
new requirements in order to facilitate discovery, trust signaling,
session negotiation and communication. This document specifies a
method for utilizing the Domain Name System (DNS) to facilitate
scalable and interoperable discovery between AI agents. The proposed
mechanism, referred to as _Brokered Agent Network for DNS AI
Discovery_ (BANDAID), defines a structured DNS namespace and record
usage model to support metadata exchange and capability
advertisement.
BANDAID introduces a leaf zone convention (e.g.,
_agents.example.com<https://urldefense.com/v3/__http://agents.example.com__;!!Bt8RZUm9aw!_TlFCFU271HDl1Nz2GgMM7C9TBgi5tVFPnVpccnkILLxfNv6J3fmyOW_ukcXCvyKQ4KC9ND7RdpiL4k5CA$>)
containing Service Binding (SVCB) records (e.g.,
chat._agents.example.com<https://urldefense.com/v3/__http://agents.example.com__;!!Bt8RZUm9aw!_TlFCFU271HDl1Nz2GgMM7C9TBgi5tVFPnVpccnkILLxfNv6J3fmyOW_ukcXCvyKQ4KC9ND7RdpiL4k5CA$>)
that encode application-specific metadata.
These records enable agents to retrieve operational parameters prior
to initiating a session, supporting both targeted lookups and
capability-based discovery. The approach leverages existing DNS
infrastructure, including DNS Service Discovery (DNS-SD), DNSSEC, and
DANE, to provide integrity, authenticity, and automation without
requiring human intervention. Lastly, the draft for Domain Control
Validation (DCV) proposes a best current practice to prove an agent
is authorized to act on behalf of a domain.
_This document proposes no change to the structure of DNS messages,
and no new operation codes, response codes, resource record types, or
any other new DNS protocol values._
The IETF Secretariat
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
