Subject: [core] Jari Arkko's No Objection on draft-ietf-core-groupcomm-21: (with COMMENT)

From: "Jari Arkko" <[email-masked]>
Date: Thu, 21 Aug 2014 07:11:04 -0700

Jari Arkko has entered the following ballot position for
draft-ietf-core-groupcomm-21: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-core-groupcomm/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for writing this document on this important topic. Iit is
indeed something that many users of CoAP technology are wondering about.

For context, the comments below are based on the in-depth Gen-ART review
for this document, by Ben Campbell - thank you! I have also read the
document myself. I have also implemented multicast-based functionality
for CoAP devices.

The document contains a lot very useful material. I do agree though with
Ben and my esteemed Area Director colleagues who have raised Discusses:
the document would be better classified as Experimental at this stage.
The re-classification though is something that the IESG can easily do.
But Martin and Ben, for instance, have provided additional useful
suggestions on how to change the text itself; some changes are also
necessary in my opinion.

A few more detailed comments. These are provided as-is, in the hopes that
they are useful. At this moment I have no specific Discuss-level
requirements for the draft, mainly because Brian and Martin already hold
Discusses that I would have otherwise held.

     all.bldg6.example.com                   "all nodes in building 6"
     all.west.bldg6.example.com              "all nodes in west wing,
 
I have found that it is often useful to separate communications
addressing and grouping from conceptual or application-specific grouping.
The gathering of nodes in a group - and the design of a network to
subnets - should be done based on communications convenience and
efficiency, but it should not necessarily dictate all application-level
groups that may be needed. To do so might in some cases lead to
inflexibility and undue constraints on the network design. It may not be
convenient to put all nodes in building 6 in one group, for instance, for
various reasons. I would like to advocate a two-level approach, multicast
for efficient reachability, but the application decisions are still based
on information about the resources (such as location), rather than who 
answered  a particular query on this multicast address. This also makes
it easy to perform queries  of any complexity in a reasonable manner,
e.g., "all sensors that have a reading higher than 27C".

   The non-idempotent CoAP method, POST, may only
   be used for group communication if the resource being POSTed to has
   been designed to cope with the unreliable and lossy nature of IP
   multicast.

This is certainly possible, and in my experience, very useful. The
document would be  most helpful if it could provide more guidance
regarding when a design is safe for use of POST.

   In the third case, typical in scenarios such as building control, a
   dynamic commissioning tool determines to which group a sensor or
   actuator node belongs, and writes this information to the node, which

Please make sure the document recognises the possibility that a device
may simultaneously belong to multiple groups.

   Also, a form of authorization (making use of DTLS-secured CoAP
   [RFC7252]) MUST be used such that only authorized controllers are
   allowed by an endpoint to configure its group membership.

Is this "MUST use a form, e.g., DTLS" or "MUST use DTLS, a form"? I'd
advocate the former...

   o  A server should not accept an IP multicast request that cannot be
      "authenticated" in some way (cryptographically or by some
      multicast boundary limiting the potential sources) [RFC7252].  See
      Section 5.3 for examples of multicast boundary limiting methods.

It is difficult for a server to know what boundary limitations may be in
place in other devices around it.

  2.9.  Congestion Control

This section talks mainly about what the servers should do. There is only
one rule about clients. Perhaps some additional guidance for the
frequency that clients can send multicast requests would be advisable,
unless it is already specified somewhere else.

  3.  Use Cases and Corresponding Protocol Flows

  3.1.  Introduction

I would have thought discovery of devices in the other direction, i.e., a
GET ./well-kown  to all-coap-nodes would have been an interesting use
case as well.

  5.  Security Considerations

I'm looking in particular at Sections 5.1 through 5.3. I'd like to say
that I have had very positive experiences about using group communication
with data object security, which is quite a lot better suited for group
communication than transport layer solutions. No individual channels have
to be established with the many group members. Messages can be signed
with the authority of the sender rather than tying the security to the
receiver. Forwarding through intermediaries retains security properties.
And so on. 

Perhaps this alternative should be mentioned. Indeed, other than for
low-security applications such as discovering network components, it is
difficult to imagine completely unsecured operation, particularly
considering that many if not most networks have a multitude of different
devices in them, and it is not in my opinion a workable long-term
solution to assume a firewall-based security model.

  8.  References

The group communication draft does not mention the observe draft, and the
observe draft does not mention multicast. Are there any feature
interaction issues that you might want to cover?

---

From: "Dijk, Esko" <[email-masked]>
Date: Thu, 28 Aug 2014 12:45:03 +0000

Hello Jari,

To respond on your last review remark:
> The group communication draft does not mention the observe draft, and the observe draft does not mention multicast. Are there any feature interaction issues that you might want to cover?

The -observe draft does not support multicast operation. It was studied a while ago, but not in scope (see http://trac.tools.ietf.org/wg/core/trac/ticket/237 ). So at present no interaction issues.

Regards,
Esko

-----Original Message-----
From: core [mailto:[email-masked]] On Behalf Of Jari Arkko
Sent: Thursday, August 21, 2014 16:11
To: The IESG
Cc: ben Campbell; [email-masked]; [email-masked]; [email-masked]
Subject: [core] Jari Arkko's No Objection on draft-ietf-core-groupcomm-21: (with COMMENT)

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)

Thank you for writing this document on this important topic. Iit is indeed something that many users of CoAP technology are wondering about.

For context, the comments below are based on the in-depth Gen-ART review for this document, by Ben Campbell - thank you! I have also read the document myself. I have also implemented multicast-based functionality for CoAP devices.

The document contains a lot very useful material. I do agree though with Ben and my esteemed Area Director colleagues who have raised Discusses:
the document would be better classified as Experimental at this stage.
The re-classification though is something that the IESG can easily do.
But Martin and Ben, for instance, have provided additional useful suggestions on how to change the text itself; some changes are also necessary in my opinion.

A few more detailed comments. These are provided as-is, in the hopes that they are useful. At this moment I have no specific Discuss-level requirements for the draft, mainly because Brian and Martin already hold Discusses that I would have otherwise held.

I have found that it is often useful to separate communications addressing and grouping from conceptual or application-specific grouping.
The gathering of nodes in a group - and the design of a network to subnets - should be done based on communications convenience and efficiency, but it should not necessarily dictate all application-level groups that may be needed. To do so might in some cases lead to inflexibility and undue constraints on the network design. It may not be convenient to put all nodes in building 6 in one group, for instance, for various reasons. I would like to advocate a two-level approach, multicast for efficient reachability, but the application decisions are still based on information about the resources (such as location), rather than who answered  a particular query on this multicast address. This also makes it easy to perform queries  of any complexity in a reasonable manner, e.g., "all sensors that have a reading higher than 27C".

This is certainly possible, and in my experience, very useful. The document would be  most helpful if it could provide more guidance regarding when a design is safe for use of POST.

Please make sure the document recognises the possibility that a device may simultaneously belong to multiple groups.

Is this "MUST use a form, e.g., DTLS" or "MUST use DTLS, a form"? I'd advocate the former...

It is difficult for a server to know what boundary limitations may be in place in other devices around it.

  2.9.  Congestion Control

This section talks mainly about what the servers should do. There is only one rule about clients. Perhaps some additional guidance for the frequency that clients can send multicast requests would be advisable, unless it is already specified somewhere else.

  3.1.  Introduction

I would have thought discovery of devices in the other direction, i.e., a GET ./well-kown  to all-coap-nodes would have been an interesting use case as well.

I'm looking in particular at Sections 5.1 through 5.3. I'd like to say that I have had very positive experiences about using group communication with data object security, which is quite a lot better suited for group communication than transport layer solutions. No individual channels have to be established with the many group members. Messages can be signed with the authority of the sender rather than tying the security to the receiver. Forwarding through intermediaries retains security properties.
And so on.

Perhaps this alternative should be mentioned. Indeed, other than for low-security applications such as discovering network components, it is difficult to imagine completely unsecured operation, particularly considering that many if not most networks have a multitude of different devices in them, and it is not in my opinion a workable long-term solution to assume a firewall-based security model.

  8.  References

The group communication draft does not mention the observe draft, and the observe draft does not mention multicast. Are there any feature interaction issues that you might want to cover?

_______________________________________________
core mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/core

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: Jari Arkko <[email-masked]>
Date: Thu, 28 Aug 2014 15:46:55 +0300

> The -observe draft does not support multicast operation. It was studied a while ago, but not in scope (see http://trac.tools.ietf.org/wg/core/trac/ticket/237 ). So at present no interaction issues.

Ok, that makes sense. Thanks. 

(Although the fact that it does not support multicast should perhaps be mentioned somewhere… IIRC the RFC doesn’t say that.)

Jari