Jari, indeed, it seems we never replied to these two items.
>> 2 . The WG charter says: >> >>> 7) Consider operational and manageability aspects of the protocol and at >>> a minimum provide a way to tell if a Device is powered on or not. >> >> >> There is no mention in the protocol document (or other documents in core) >> about manageability and operational considerations. Maybe some work is being >> prepared, although I saw no core documents dealing with it. I believe that >> it would be good for the document to include either an Operational and >> Manageability Considerations section as recommended by RFC 5706 or, a short >> informational 'Future Work' section or appendix that mentions the need to >> deal with the operational and manageability aspects, and possibly point to >> work already done in the IETF for example on the coman mail list concerning >> management of constrained networks. >> >> 3. Section 4.8 defines a number of CoAP protocol parameters and derived >> parameters that according to 4.8.1 may be changed. Some of these parameters >> have limitations and their changes may affect the basic functionality of the >> nodes, the interaction between nodes or between nodes and servers, as well >> as the functioning in constrained environments. However there is no risk >> analysis in Section 11 (Security Considerations) about the threats related >> to mis-configuration of the modes and un-appropriate or malevolent changes >> in these parameters, and recommendations of security counter-measures on >> this respect. There is some discussion of this in the March 11 reply to the ops-dir review. It seems this message is not publicly archived. I'll dig it out and send it separately. Re the security considerations: As of today, we don't have mechanisms to effect any of these parameter changes. I believe any such mechanisms developed in the future will have to address the pertinent security considerations. >> Minor issues: >> >> 1. The WG charter says: >> >>> The WG will coordinate on requirements from many organizations including >>> OpenSG/NIST, ZigBee/HomePlug, IPSO Alliance, OASIS, SENSEI, >>> ASHRAE/BACnet; other SDOs and organizations. >> >> I am wondering whether the listed organizations were informed about the IETF >> conducting the Last Call on the protocol document. Maybe I missed some >> messages, but I see no feedback in the archives of the WG or IETF lists, or >> in the liaison statements page reflecting such interaction. The coordination on requirements was mostly done in 2010, and I'm not aware of any formal liaisons we picked up from that. Since then, we have had many people that were both in CoRE and in one or more the organizations listed (which now probably need to be complemented with OMA, ETSI and oneM2M, ...). ETSI even ran a couple of CoAP interops... I must admit that it simply didn't occur to me that we should do additional publicity for the IETF last call there — I was quite happy with the level of visibility that we have right now. Grüße, Carsten _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
