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*
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list -- anima@ietf.org To unsubscribe send an email to anima-le...@ietf.org
