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?
> 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.
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.
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.
> 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?
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?
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]
