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.

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*
> 
> 
> 



-- 
---
t...@cs.fau.de

_______________________________________________
Anima mailing list -- anima@ietf.org
To unsubscribe send an email to anima-le...@ietf.org

Reply via email to