Subject: Re: [Gen-art] Gen-ART review for draft-ietf-core-coap-14

From: Jari Arkko <[email-masked]>
Date: Tue, 23 Apr 2013 23:32:59 +0300

Dan:

Many thanks for your review. This is a big document and I believe important, and your observations on it are very valuable.

Carsten:

I've seen two responses (both from you and on March 28) to Dan's review. If I've understood correctly, you've responded to major issue 1 and minor issues 2-5, but what about major issues 2-3 and minor issue 1? (I'm searching for e-mails with the draft file name in subject line, so it is possible that I've missed issue tracker mails, for instance.)

For your convenience, here are the issues that I did not see a response to yet:

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

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 24 Apr 2013 00:41:23 +0200

Jari,

indeed, it seems we never replied to these two items.

>> 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 th…

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.

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

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

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 24 Apr 2013 07:49:57 +0000

Hi Carsten,

> 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-masked]]
> Sent: Wednesday, April 24, 2013 1:41 AM
> To: Jari Arkko
> Cc: Romascanu, Dan (Dan); [email-masked]; General
> Area Review Team; Barry Leiba; [email-masked]
> Subject: Re: [Gen-art] Gen-ART review for draft-ietf-core-coap-14
> 
> Jari,
> 
> >>> 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.
> 
> 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, ...).
> 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