On 28-Jul-26 17:04, 韩梦瑶(联通集团本部) wrote:
Hi Brian and Michael,
I am currently revising our AI-ASA gap analysis draft. I agree with your
comments and will update the draft according to the meeting inputs. Your
comments would be very welcome.
> I realised there was a gap in the -00 draft, which I've fixed by
> inventing a new IANA registry. Briefly, when discovering a new agent,
> you need to know what "transport" protocol it talks.
Do we also need to identify the application-layer protocol (A2A, MCP, ACP,
etc.) used by the agent?
Rather than answering that directly, I think that Michael is correct that we need a more
flexible format than just "integer". Your comments, and what I have seen of the
SDP and DNS/SVCB work, suggests that Michael is right and allowing CBOR objects would be
best. CBOR is even more expressive than JSON so I'm sure it will cover the requirements.
Since GRASP is already a CBOR-based protocol, there is no backwards compatibility problem
at all - we can keep the integers already defined.
That isn't as simple as TCP vs UDP, as the original GRASP definitions
assumed. Most protocols of interest are *above* the traditional
transport layer and are not listed in the basic IANA protocol registry.
<https://datatracker.ietf.org/person/[email protected]>
In practice, an agent might use A2A over HTTP/2 over TLS/TCP, or HTTP/3 over
QUIC. A single value such as PROTO_HTTP may therefore not provide enough
information to establish the connection.
Understood.
Perhaps each identifier could represent a complete communication profile, with
its specification defining the application protocol, security mechanism, and
underlying transport. Alternatively, these could be represented separately.
Put it this way: if it can be expressed in JSON, it can easily be expressed in
CBOR, whch is actually more powerful than JSON.
> 258 PROTO_QUIC RFC9369
If this means QUIC in general, I think the reference should be RFC 9000. RFC
9369 specifically defines QUIC version 2.
259 PROTO_HTTP RFC9110
PROTO_HTTP seems ambiguous because RFC 9110 defines HTTP semantics, while the
actual connection could use HTTP/1.1, HTTP/2, or HTTP/3. Those choices imply
different underlying transports.
I know we struggled with something similiar as the BRSKI transports
multiplied. Where did that text go... ah.. into brski-discovery, section
3.5.2.2. We used/adapted the last parameter of the objective, the
objective-value, to disambiguate. I'm not entirely happy with this.
I would adapt your work here into brski-discovery.
For more transport details, I was also thinking of using |objective-value|. I’m
still a little unclear about this, though. Could you explain it a bit more?
Would it be enough to express it directly in the transport-proto field, if we
have full CBOR capability? If not, the discovery response does include an
objective value and that can be whatever we want - again, the flexibility of
CBOR is very helpful.
I’m very interested in this work, including the related agent or AI-ASA work on
grasp or BRSKI. Would it be okay to submit PRs and contribute to this work?
Absolutely okay, but we still need a bit more discussion on the above points.
Regards,
Brian
Regards,
Mengyao
|
|
------------------ Original ------------------
*From: * "Brian E Carpenter"<[email protected]>;
*Date: * Tue, Jul 28, 2026 04:26 AM
*To: * "Michael Richardson"<[email protected]>;
*Cc: * "anima"<[email protected]>;
*Subject: * [Anima] Re: Fwd: I-D Action:
draft-carpenter-anima-grasp-rendezvous-01.txt
【本邮件为外部邮件，请注意核实发件人身份，并谨慎处理邮件内容中的链接及附件】
On 27-Jul-26 21:27, Michael Richardson wrote:
>
> Brian E Carpenter <[email protected]> wrote:
> > I realised there was a gap in the -00 draft, which I've fixed by
> > inventing a new IANA registry. Briefly, when discovering a new agent,
> > you need to know what "transport" protocol it talks. That isn't as
> > simple as TCP vs UDP, as the original GRASP definitions assumed. Most
>
> True!
>
> > protocols of interest are *above* the traditional transport layer and
> > are not listed in basic IANA protocol registry. Apart from the SDP
> > parameters registry [1], there doesn't seem to be a registry for
> > this. SOo of course I invented one.
>
> I feel like maybe DELEG might have similiar issue as it's transport-security
> option moves forward: draft-hoffman-deleg-secure-transports-00 section 2.1,
> section 4.2
They seem to be a long way away from anything like JSON or CBOR formats though.
They rely on https://www.rfc-editor.org/info/rfc9460/#section-14.3
>
> > A diff from the previous version is available at:
> >
https://author-tools.ietf.org/iddiff?url2=draft-carpenter-anima-grasp-rendezvous-01
>
> You've used values >256.
> CBOR won't restrict you to just integers. You could strings, or even complex
> objects like an array, like for instance:
[{TCP,UDP},{CoAP,HTTP,HTTPS,OSCORE,EDHOC}]
> (as the pattern: [TCP,HTTPS] being a single value)
Yes. Doing that would be very natural for Python with its happy-go-lucky
approach
to typing, but I guess it would be a little more complicated for strongly typed
languages.
(The SDP proto registry has things like "UDP/MBMS-FEC/RTP/SAVP" in it, so
their problem was clearly similar.)
>
> I know we struggled with something similiar as the BRSKI transports
> multiplied. Where did that text go... ah.. into brski-discovery, section
> 3.5.2.2. We used/adapted the last parameter of the objective, the
> objective-value, to disambiguate. I'm not entirely happy with this.
> I would adapt your work here into brski-discovery.
Sounds good. PRs welcome (or should it be a separate draft?).
Brian
>
> --
> Michael Richardson <[email protected]>, Sandelman Software Works
> -= IPv6 IoT consulting =- *I*LIKE*TRAINS*
>
>
>
_______________________________________________
Anima 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]
