[dmsc] Re: New Version Notification for draft-feng-dmsc-intent-routing-requirements-00.txt

[Sumit Ahuja <[e-mail]>]

Chong,

On your four open questions, using an instrument from the agentproto
charter discussion that I think applies cleanly here. Mirja Kuehlewind
put it as: what needs to be standardised to survive cross-domain,
rather than remaining an implementation choice. It is a sharper filter
than asking what a mechanism ought to do, and it sorts your four
unevenly, which is useful.

Capability aggregation across domains does not survive as an
implementation choice. Two domains that summarise differently cannot
consume each other's advertisements at all, so the summarisation form
has to be common or there is nothing to interoperate on. That one is
settled by the test.

Session-agnostic delivery is settled by the test in the direction you
argue, and I think the argument is stronger than the one in your
rationale. A delivery layer that presumes a session requires both
parties to share that presumption, so the presumption itself becomes a
thing that must be agreed cross-domain. A layer that presumes nothing
requires no agreement. Session-agnostic is the choice that minimises
what has to be standardised, which is a better reason for it than
generality.

Bounded state I do not think is independent. It is a property of each
node's own resource use, which sounds local, but whether any node can
achieve it depends entirely on whether capability summarises. It reads
as a consequence of the aggregation answer rather than a separate
question.

Where the selection decision sits is the one the test does not settle,
and I think that is the correct outcome rather than a gap. Either
location works, and different deployments will want different ones for
reachability reasons you already give. What does not survive as an
implementation choice is that the two parties agree which location is
in force for a given interaction. REQ-8 already carries exactly that
pattern for the delivery endpoint: the handler declares, the
infrastructure honours the declaration, and nothing is mandated. The
selection location looks like the same shape, and if so the question
resolves to declare-rather-than-mandate rather than to picking a side.

One observation about the document as requirements rather than about
any individual requirement. Stating requirements and prescribing no
mechanism is the right discipline, and it has a failure mode: a
requirement that names a property without saying what would satisfy it
can be met vacuously, because there is no test to fail.

REQ-13 is where that bites hardest. Cross-boundary interoperation must
be explicitly authorised and policy-controlled. Authorised is
checkable. Policy-controlled is not, because nothing in the document
says what a policy expresses, and a requirement that cannot be failed
is not a yardstick. As written it is satisfied by an access list, and
equally satisfied by an implementation that declares a policy and
expresses nothing in it.

I am working on a mechanism draft addressing that requirement
specifically, which I expect to file next month. I raise it now rather
than on filing because the requirement is yours and the yardstick
should be able to judge whatever arrives against it, including this.

Sumit P. Ahuja
Main Labs


>> On Aug 14, 2026, at 05:37, chong feng <[e-mail]> wrote:
>> 
>> Hi all,
>> 
>> I have just submitted a short requirements draft for intent routing in
>> multi-agent systems:
>> 
>> draft-feng-dmsc-intent-routing-requirements-00
>> Requirements for Intent Routing in Multi-Agent Systems at Internet Scale
>> 
>> It tries to pin down one thing: what any mechanism that routes an agent's
>> intent to the right handler has to satisfy, independent of whether that
>> mechanism is a gateway, a directory, or a routing network. The requirements
>> are deliberately solution-agnostic. There is no prescribed architecture.
>> 
>> This grew out of reading the gateway requirements and the MACP discussion on
>> this list, and out of my own AIN work. A few of the requirements are points I
>> would genuinely like the list's view on, because they are the kind of thing
>> the scope discussion will eventually have to settle: bounded state, how
>> capability gets aggregated across domains, where the selection decision sits,
>> and whether the delivery layer should be session-agnostic.
>> 
>> Comments welcome, on the list or off.
>> 
>> Cheers,
>> Chong Feng
>> 
>> ---------- Forwarded message ---------
>> 发件人： <[e-mail]>
>> Date: 2026年8月14日周五 17:33
>> Subject: New Version Notification for
>> draft-feng-dmsc-intent-routing-requirements-00.txt
>> To: Chong Feng <[e-mail]>
>> 
>> 
>> A new version of Internet-Draft
>> draft-feng-dmsc-intent-routing-requirements-00.txt has been successfully
>> submitted by Chong Feng and posted to the
>> IETF repository.
>> 
>> Name:     draft-feng-dmsc-intent-routing-requirements
>> Revision: 00
>> Title:    Requirements for Intent Routing in Multi-Agent Systems at
>> Internet Scale
>> Date:     2026-08-14
>> Group:    Individual Submission
>> Pages:    11
>> URL:      https://www.ietf.org/archive/id/draft-feng-dmsc-intent-routing-requirements-00.txt
>> Status:   https://datatracker.ietf.org/doc/draft-feng-dmsc-intent-routing-requirements/
>> HTML:     https://www.ietf.org/archive/id/draft-feng-dmsc-intent-routing-requirements-00.html
>> HTMLized: https://datatracker.ietf.org/doc/html/draft-feng-dmsc-intent-routing-requirements
>> 
>> 
>> Abstract:
>> 
>>  The rapid proliferation of autonomous AI agents across enterprise and
>>  Internet-scale deployments creates a structural challenge that
>>  existing agent frameworks cannot address: how to enable any agent to
>>  reach and invoke any other agent's capabilities without pre-
>>  established bilateral integration, across organizational boundaries,
>>  at Internet scale.
>> 
>>  This document states the normative requirements for that problem.  It
>>  prescribes no solution, no specific mechanism, no message format, and
>>  no assumption of centralized or distributed architecture.  Its
>>  purpose is to establish a verifiable yardstick against which any
>>  claimed "intent routing" solution can be judged.
>> 
>> 
>> 
>> The IETF Secretariat
>> 
>