Thanks Michael.
Mostly agreement. Wanted to amend what i said in before re. cGRASP vs. GRASP:
I think cGRASP's purpose is to provide the GRASP services to rfc7228 devices
that
can not use GRASP but would also be able to use CoAP. I think CoAP would go all
the
way down to the ost constrained devices and networks, and the main reason why
those
devices may not use CoAP is NIH.
So when it comes to the larger network, i'd like to change my tune of "cGRASP
will
replace GRASP" rather to: cGRASP will amend GRASP deployment so all devices that
need to directly communicat to one such constrained devices will need to offer
their
services also on top of cGRASP. And only when all devices and all services have
this requirement will (TCP) GRASP be not required in the network. Kinda like
IPv4+IPv6
(dual stack) problem.
Cheers
Toerless
On Sun, May 11, 2025 at 10:45:57AM +0100, 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.
>
> 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.
>
> 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 <mcr+i...@sandelman.ca>, Sandelman Software Works
> -= IPv6 IoT consulting =- *I*LIKE*TRAINS*
>
>
>
--
---
t...@cs.fau.de
_______________________________________________
Anima mailing list -- anima@ietf.org
To unsubscribe send an email to anima-le...@ietf.org
