On 14-May-25 03:39, Toerless Eckert wrote:
On Tue, May 13, 2025 at 03:47:21PM +0100, Michael Richardson wrote:Toerless Eckert <t...@cs.fau.de> wrote: > 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 Which services? I think it's pretty important to understand why, and whether or not class 0,1,2 7228-class devices can even accomodate such a service.Right, I think cGRASP does target at the low end the same type of rfc7228 devices, that CoAP can also address. From my understanding, C0 is out of scope with typically no IP, < 10 KB RAM, < 100 KB ROM. C1 would be a basic CoAP device with < 50 KB RAM, < 250 KB Flash. and C2 would be smart IoT devices, maybe mesh network capable/forwarding going beyond that limit. C1/C2 should be able to support cBRSKI. cGRASP would extend the ANIMA framework for C1/C2 devices for use cases such as: 1. Where GRASP (unicast) primitives (synchronize, negotiate) make more sense in new code than the REST primitives of CoAP primitives - GET/PUT/POST/DELETE 2. When discovery/selection/group-communication is desired to be resilient/free of "servers" - aka: peer to peer via cGRASP flood/discovery primitives.
I think we could say more generically: when the functional requirement is peer-to-peer(s) rather than client-server. The Web paradigm (and therefore the REST paradigm) is entirely client-server. Until we get away from that, we cannot really speak of autonomy. Brian
Obviously, i think that 2. is the biggest novely of GRASP/cGRASP for which there is no equivalent at all yet. CoAP requires network wide multicast or server(s). As do any other IoT protocols i am aware of. an GRASP/cGRASP flooding mechanism could also support a bus signaling system without a broker, not only service announce/discover/select. (and it's reliable). So it would be very close to what i have seen in proprietary IoT systems such as eQ3 or z-wave. (Although there is some guessing involved on my part as these are proprietary). For the unicast communication, my personal feeling is that CoAP is very feature rich, trying to match a lot of complexity that has evolved for many different use-cases from the web. So maybe the benefit of using cGRASP unicast would really be for simple, lightweight - greenfield - use-cases. Cheers Toerless-- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS*
_______________________________________________ Anima mailing list -- anima@ietf.org To unsubscribe send an email to anima-le...@ietf.org
