Thanks for all advices!
> but, being CBOR based, defined in CDDL, there are no actual fixed fields.
> I question the need for a *new* message-oriented system.
The "fixed field" refers to the "MESSAGE_TYPE" and
"session-id" contained by all GRASP/cGRASP messages. The
"message-oriented" refers to the fact that cGRASP's reliability mechanism
operates at the message level, unlike the TCP's packet-level acknowledgements.
> the smallest integer is 1
> byte, and it stores 24 values. Might as well use them ...
The 1-byte CBOR can indeed be used for integers under 24. All the CBOR related
issues will be checked and corrected.
------------------ Original ------------------
From: "Brian E Carpenter"<[email protected]>;
Date: Mon, May 12, 2025 04:02 AM
To: "Michael Richardson"<[email protected]>; "Toerless
Eckert"<[email protected]>; "anima"<[email protected]>;
Subject: [Anima] Re: Adoption call for constrained GRASP (
draft-zhu-anima-lightweight-grasp )
A couple more comments:
On 11-May-25 21:45, Michael Richardson wrote:
>
> I have read draft-zhu-anima-lightweight-grasp-03.
> It's not my first time reading this draft.
> The draft is much improved.
> I do not see a need for this protocol myself, but if there are others who
> would implement it, then I have no objection to adoption.
>
> There are several classes of IoT deployments.
> These are somewhat related to the RFC7228(bis):
>
> The class 2/3 devices run Zyphyr,Contiki,RIOT-OS,Ariel, and make use of
> CoAP. These are what the *IETF* considers to be IoT, and it's mostly
e2e,
> (i.e, device to device).
> It would be lovely if such small devices could self-manage, but I'm
skeptical.
>
> Meanwhile, a lot of the IIoT verticales use class 4,10,15 devices.
> Yes, literally RPI sometimes. These are almost all device to cloud.
> Often mains powered, over WiFI, not 802.15.4.
> (and the latest lower power ethernet, obsoletes much of 802.15.4, which is
> now 15 years since standard, and 20 years since conception)
>
> So, when statements are made about how expensive TCP is in section 1, then
> this needs to be more clearly qualified.
>
> ***
> It would also be good to understand what your implementation experience is.
> ***
>
> Section 4 says:
>
> cGRASP has made modifications to the standard
GRASP by reducing the
> fixed fields and introducing a message-oriented
built-in reliability
> mechanism with the acknowledgment and
retransmission capability based
> on Nonce.
>
> but, being CBOR based, defined in CDDL, there are no actual fixed fields.
> I question the need for a *new* message-oriented system.
>
> ....
> the cGRASP Objective option is uniquely identified
by an 8-bit number
> (i.e., objective-num), with the remaining fields
keeping consistent
>
> but CBOR doesn't do 8-bit number fields. It has 1-byte (0-24), 2-byte
> (0-255), etc. Using smaller numbers means smaller fields.
There is no
> reason to limit things like this.
>
> } Instead of using the text string with indefinite length
(i.e.,
>
> I don't think 8990 says to use an indefinite length string.
> I think it was early in the CBOR space, so we didn't say anything about
that,
> but if you asked me, I'd say not to do that.
There's no maximum size specified in 8990, intentionally. But since cGRASP
says:
"Each generic cGRASP Objective MUST be assigned a unique objective number and
be made public to all cGRASP nodes when it's registered."
surely an IANA registry will be needed?
>
> The bit-packing in 4.2.1 is also inappropriate, the smallest integer is 1
> byte, and it stores 24 values. Might as well use them.
This is just copied from RFC 8990. The idea was that flags could be combined
arbitrarily.
Brian
> I see that 5.1 puts all cGRASP messages over CoAP. Good.
> But, given the difficulty of mapping things, maybe ... don't.
> Start over with CoAP thinking. How can it interact with OBSERVE,
COAPS(DTLS), OSCORE
> and EDHOC?
>
>
>
>
>
> --
> 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]
_______________________________________________
Anima mailing list -- [email protected]
To unsubscribe send an email to [email protected]
