Hi Carsten, > 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.
In this case I believe that the Security Considerations sections needs to mention the risks and the need for future work, also as a warning to the operators deploying the protocol so that they can take adequate protection measures by proprietary methods if the consider this necessary. Regards, Dan > -----Original Message----- > From: Carsten Bormann [mailto:[email protected]] > Sent: Wednesday, April 24, 2013 1:41 AM > To: Jari Arkko > Cc: Romascanu, Dan (Dan); [email protected]; General > Area Review Team; Barry Leiba; [email protected] > Subject: Re: [Gen-art] Gen-ART review for draft-ietf-core-coap-14 > > 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
