Hi, Brain
Many thanks for your careful reading and very helpful comments. They help us
better understand how to position the AI-ASA gap analysis with respect to the
existing GRASP design and implementation experience.
1. Data-intensive communication and the role of GRASP
We agree that the old GRASP bulk-transfer draft should not be used as the main
basis for data-intensive AI-ASA use cases.
We think the issue should probably not be described as “GRASP needs to carry
continuous or large data streams”. A more appropriate view is that GRASP can
provide discovery and rendezvous between ASAs, while the actual data-intensive
exchange can be carried over a direct connection between agents.
Your GRASPy gsend() / grecv() implementation is very useful prior work in this
direction. It shows that a GRASP negotiation session can be used to help
establish a simple TCP-based communication path. We would like to study this
more carefully and learn from that experience.
2. GRASP usage pattern rather than GRASP extension
Your comment that this is not really a GRASP extension, but a use of GRASP for
discovery and rendezvous, is helpful in this case.
This suggests that the gap may be less about missing protocol machinery in
GRASP itself, and more about whether AI-ASAs need a commonly documented usage
pattern.
3. Point-to-point streaming vs. one-to-many distribution
One-to-many distribution of very large data is a separate problem, related to
the GRASP distribution draft.
This distinction is very useful. We should avoid mixing point-to-point AI-ASA
streaming with one-to-many distribution. These two cases may have different
requirements and should probably be discussed separately.
4. Dynamic Objectives and semantic interoperability
On Objectives, you pointed out that GRASP already allows objective-value = any,
and that privately defined Objectives do not need to be registered. You also
gave a clear example of dynamically generated private Objectives.
The remaining question we are considering is more about semantic
interoperability among AI-ASAs. Even if dynamic private Objectives are allowed
by GRASP, independently developed AI-ASAs may still need some common way to
understand the meaning, schema, intent, capability context, constraints, or
trust requirements of such Objectives. So this part may need to be reframed as
a convention or interoperability issue, rather than a limitation of GRASP
itself.
5. Possible next step
Based on your comments, I will update the draft again to correct the inaccurate
descriptions and better align the text with existing GRASP mechanisms.
At the same time, your comments suggest a possible follow-up direction. If the
WG thinks it is useful, we may consider writing a short document on an AI-ASA
communication pattern to show how to implement it.
------------------ Original ------------------
From: "Brian E Carpenter"<[email protected]>;
Date: Sat, Jul 4, 2026 03:54 PM
To: "anima"<[email protected]>;
"draft-han-anima-gap-analysis-ai-asa"<[email protected]>;
Subject: Re: I-D Action: draft-han-anima-gap-analysis-ai-asa-00.txt
【本邮件为外部邮件，请注意核实发件人身份，并谨慎处理邮件内容中的链接及附件】
Hi,
Thanks for this interesting draft. A couple of quick comments:
> The existing bulk-transfer draft
> [I-D.carpenter-anima-grasp-bulk] focuses mainly on
one-time transfers
> of large data blocks. Continuous, low-latency
delivery in streaming
> scenarios therefore requires further discussion.
That very old draft is really not the basis for data-intensive use cases.
However, when two agents have discovered each other via GRASP, they know each
other's address. It is rather easy to establish a direct TCP connection between
the two agents. In my original Python GRASP implementation, I implemented
support for this by adding gsend() and grecv() functions,
so that a GRASP negotiation session can switch to become a simple TCP
connection between the two agents. I did not consider TLS or QUIC but I am sure
this could be done too.
That's documented on page 17 of
https://github.com/becarpenter/graspy/blob/master/documentation/graspy.pdf .
There is a trivial example at
https://github.com/becarpenter/graspy/blob/master/ASA-examples/testclient.py
and
https://github.com/becarpenter/graspy/blob/master/ASA-examples/testserver.py
It isn't really a GRASP extension; it simply uses GRASP for discovery and
rendezvous. It assumes CBOR but I expect that CBOR will be the best way to
encode inter-agent messages anyway. Of course we could describe this in a draft
if you think it is useful.
(If you need one-to-many distribution of very large data, that is a new
problem, discussed as you say in the grasp-distribution draft.)
> Problem: Each Objective must also be registered in
advance. This
> static model cannot meet the need for AI-ASAs to
generate new
> Objectives dynamically or to describe the meaning of an
Objective by
> themselves. It therefore limits flexible and open
semantic
> interaction between LLM-based agents. Gap: The
current GRASP
> specification relies on strictly predefined CBOR
encodings and fixed
> semantic mappings for Objectives
A valid definition of the value of an objective is "objective-value = any". So
you can define a generic AI objective where there is no limitation on the CBOR
syntax of the value. You can also create privately defined objectives that do
not need to be registered (section 2.10.1 of RFC 8990). There is nothing to
prevent dynamic generation of privately defined objectives like
"example.org:xXhiq8BHe2KH8c4F". So I don't think this is a real problem.
Regards/Ngā mihi
Brian Carpenter
On 03-Jul-26 22:43, [email protected] wrote:
> Internet-Draft draft-han-anima-gap-analysis-ai-asa-00.txt is now available.
>
> Title: Problem Statement and Gap
Analysis for Autonomic Networking with AI- powered Autonomic Service Agent
> Authors: Mengyao Han
>
Tianyi Huang
>
Jing Zhao
> Name:
draft-han-anima-gap-analysis-ai-asa-00.txt
> Pages: 6
> Dates: 2026-07-03
>
> Abstract:
>
> This document presents a problem statement and gap
analysis of the
> technical challenges faced by the GeneRic
Autonomic Signaling
> Protocol (GRASP) [RFC8990] when it is used, within
the Autonomic
> Networking Infrastructure (ANI) defined by the
ANIMA Working Group
> [RFC8993], to support enhanced Autonomic Service
Agents that
> incorporate Large Language Model (LLM)
capabilities, referred to in
> this document as AI-ASAs.
>
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-han-anima-gap-analysis-ai-asa/
>
> There is also an HTMLized version available at:
>
https://datatracker.ietf.org/doc/html/draft-han-anima-gap-analysis-ai-asa-00
>
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
>
>
> _______________________________________________
> I-D-Announce mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
_______________________________________________
Anima mailing list -- [email protected]
To unsubscribe send an email to [email protected]
