Esko Dijk <[email protected]> wrote: > On the one hand if we decide to use CoAP for a particular function then > we may expect implementers need to know CoAP as well and e.g. read RFC > 7252. Including thinking about security issues of unsecured-CoAP. The > benefit or re-use comes with that responsibility as well as the CoAP > protocol is far more rich/complex than what we actually need.
I guess one concern might be that in a GRASP-focused ACP network, the join proxy
might not otherwise speak CoAP.
For instance, maybe the join-proxy is actually an ACP-multi-Gb-ethernet ISP
appliance that has an 802.15.4 radio attached so that it can capture
environmental reports from sensors in the data center.
My two thoughts here are:
a) the join-proxy can use stateful mode, which avoids any CoAP knowledge.
b) the Registrar has to known CoAP anyway, but that knowledge is limited to
the Registrar.
So I think that we are in good hands.
> But if we fear that implementers not versed in CoAP are going to mess
> things up, we may want to write some additional guidance. Like how to
> deal with the various options the client may include.
I think it's okay: learning a bit of CoAP is not that hard.
You don't have to be an expert on it.
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
