Subject: [core] I-D Action: draft-ietf-core-groupcomm-06.txt

From: [email-masked]
Date: Fri, 12 Apr 2013 05:49:59 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Constrained RESTful Environments Working Group of the IETF.

	Title           : Group Communication for CoAP
	Author(s)       : Akbar Rahman
                          Esko Dijk
	Filename        : draft-ietf-core-groupcomm-06.txt
	Pages           : 33
	Date            : 2013-04-12

Abstract:
   CoAP is a RESTful transfer protocol for constrained devices and
   networks.  It is anticipated that constrained devices will often
   naturally operate in groups (e.g.  in a building automation scenario
   all lights in a given room may need to be switched on/off as a
   group).  This document provides guidance for how the CoAP protocol
   should be used in a group communication context.  An approach for
   using CoAP on top of IP multicast is detailed for both constrained
   and un-constrained networks.  Also, various use cases and
   corresponding protocol flows are provided to illustrate important
   concepts.  Finally, guidance is provided for deployment in various
   network topologies.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-core-groupcomm

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-core-groupcomm-06

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-core-groupcomm-06

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Rahman, Akbar" <[email-masked]>
Date: Sun, 14 Apr 2013 18:53:19 -0400

Hi Carsten/Andrew,

As per the direction from the last IETF in Orlando, Esko and I have
updated the Groupcomm I-D as listed below.  Please advise us on the next
steps.

Sincerely,

Akbar & Esko,

========================================================================
=====

   Changes from ietf-05 to ietf-06:

   o  Added a new section on commissioning flow when using discovery
      services when end devices discover in which multicast group they
      are allocated (#295).

   o  Added a new section on CoAP Proxy Operation (section 3.9) that
      outlines the potential issues and limitations of doing CoAP
      multicast requests via a CoAP Proxy (#274).

   o  Added use case of multicasting controller on the backbone (#279).

   o  Use cases were updated to show only a single CoAP RD (to replace
      the previous multiple RDs with one in each subnet).  This is a
      more efficient deployment and also avoids RD specific issues such
      as synchronization of RD information between serves (#280).

   o  Added text to section 3.6 (Configuring Group Membership in
      Endpoints) that clarified that any (unicast) operation to change
      an endpoint's group membership must use DTLS-secured CoAP.

   o  Clarified relationship of this document to [I-D.ietf-core-coap] in
      section 2.2 (Scope).

   o  Removed IPSec related requirement, as IPSec is not part of
      [I-D.ietf-core-coap] anymore.

   o  Editorial reordering of subsections in section 3 to have a better
      flow of topics.  Also renamed some of the (sub)sections to better
      reflect their content.  Finally, moved the URI Configuration text
      to the same section as the Port Configuration section as it was a
      more natural grouping (now in section 3.3) .

   o  Editorial rewording of section 3.7 (Multicast Request Acceptance
      and Response Suppression) to make the logic easier to comprehend
      (parse).

   o  Various editorial updates for improved readability.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Friday, April 12, 2013 8:50 AM
To: [email-masked]
Cc: [email-masked]
Subject: [core] I-D Action: draft-ietf-core-groupcomm-06.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
 This draft is a work item of the Constrained RESTful Environments
Working Group of the IETF.

Abstract:

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

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Fri, 19 Apr 2013 09:24:24 +0000

Dear list

Having had a closer look at the groupcomm draft, I would like to propose to register a proper hypermedia type for the group management protocol. We call us Constrained RESTful Environments, so we should follow the HATEOAS constraint for the central specifications. RD for instance has application/link-format for that.

How about "application/groupcomm+json" for the currently proposed format?

Ciao
Matthias

---

From: Zach Shelby <[email-masked]>
Date: Sun, 21 Apr 2013 21:48:41 +0300

Hi,

> How about "application/groupcomm+json" for the currently proposed format?

I agree, although maybe groupcomm is not all that descriptive. Would e.g. application/coap-group+json make more sense? 

Zach

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com @SensinodeIoT
Mobile: +358 40 7796297
Twitter: @zach_shelby
LinkedIn: http://fi.linkedin.com/in/zachshelby
6LoWPAN Book: http://6lowpan.net

---

From: "Dijk, Esko" <[email-masked]>
Date: Mon, 22 Apr 2013 14:52:48 +0000

Hello Matthias,

thanks for your look at the group management protocol. Could you explain perhaps why a specific content type is needed for this? A client that GETs such a resource presumably already knows (resource discovery) that the resource type is e.g. "core.gp", so that provides already the information what the interpretation of the returned content exactly should be. Why would the content-format be needed, just to repeat this information - is this related to the HATEOAS mentioned?

regards,

Esko

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kovatsch Matthias
Sent: Friday, April 19, 2013 11:24
To: [email-masked]
Subject: Re: [core] I-D Action: draft-ietf-core-groupcomm-06.txt

Dear list

Ciao
Matthias

________________________________
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: Carsten Bormann <[email-masked]>
Date: Mon, 22 Apr 2013 17:16:37 +0200

On Apr 19, 2013, at 11:24, "Kovatsch  Matthias" <[email-masked]> wrote:

> propose to register a proper hypermedia type

Indeed.

Several questions come to my (WG member) mind:

-- the format has both multicast names and addresses -- which ones are needed?  What if resolution disagrees?
-- a single /gp for all multicast groups may become unwieldy if multiple groups need adds and removes -- how does the manager of one group know what other groups the node should be in?
-- removes: the current text only has a PUT replacement of the whole group to do this.

More meta:

-- should we do this format in here?  This may be a bit beyond what an informational document does.
   On the other hand, we have a lot of informational media type registrations.

-- if we want to standardize this format, it this the right time?  
   The format would have to fit into other API-related formats, and I'm not sure we have found our style for these yet.

I'm very much for exploring this more, I'm just not sure what exactly the outcome should be at this point.

Grüße, Carsten

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Mon, 22 Apr 2013 15:37:28 +0000

> thanks for your look at the group management protocol. Could you explain
> perhaps why a specific content type is needed for this? A client that GETs
> such a resource presumably already knows (resource discovery) that the
> resource type is e.g. "core.gp", so that provides already the information what
> the interpretation of the returned content exactly should be. Why would the
> content-format be needed, just to repeat this information - is this related to
> the HATEOAS mentioned?

Yes, in the end, the information is the same. REST says, however, that the shared common knowledge must be stored in the media types. This is what actually decouples client and server, and allows clients to use services they were not explicitly written for (unlike a hardcoded "POST x to /path/y" which is simply an RPC). Resource types are good to find an entry link to an application, but going beyond that and specifying what methods to use on which URI completely conflicts with our RESTful banner. This is an old problem and there is a lot of discussion (e.g., http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven). 

Ciao
Matthias

---

From: "Dijk, Esko" <[email-masked]>
Date: Tue, 23 Apr 2013 11:43:08 +0000

Ok, thanks! So a separate media type seems best and RESTful.
Suppose we define 'application/coap-group+json' for that, the side effect is that a client not knowing this specific content-format can't deduce that it is in fact JSON format. (E.g. the client could integrate a generic-JSON-viewer-plus-editor that shows the information to a user. In this case it won't invoke the JSON-viewer anymore because the content is not recognized as being JSON).  So in a way, we also lose a bit of functionality/generality by this solution.

Esko

-----Original Message-----
From: Kovatsch Matthias [mailto:[email-masked]]
Sent: Monday, April 22, 2013 17:37
To: Dijk, Esko; [email-masked]
Subject: RE: [core] I-D Action: draft-ietf-core-groupcomm-06.txt

> thanks for your look at the group management protocol. Could you
> explain perhaps why a specific content type is needed for this? A
> client that GETs such a resource presumably already knows (resource
> discovery) that the resource type is e.g. "core.gp", so that provides
> already the information what the interpretation of the returned
> content exactly should be. Why would the content-format be needed,
> just to repeat this information - is this related to the HATEOAS mentioned?

Ciao
Matthias

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Tue, 23 Apr 2013 11:55:23 +0000

Hmm, that is a good point. The problem here lies more in the number registry for the Content-Format, I suppose.
Maybe we should have something similar to option numbers, so that specific bits indicate a "+json" or "+xml"?

In general, it is the point, though, that the media types must be pre-shared. A generic client would probably be like a Web browser that has plugins for new types or at least can make a lookup in the registry.

Ciao
Matthias

> Suppose we define 'application/coap-group+json' for that, the side effect is
> that a client not knowing this specific content-format can't deduce that it is in
> fact JSON format. (E.g. the client could integrate a generic-JSON-viewer-plus-
> editor that shows the information to a user. In this case it won't invoke the
> JSON-viewer anymore because the content is not recognized as being JSON).
> So in a way, we also lose a bit of functionality/generality by this solution.

---

From: "Dijk, Esko" <[email-masked]>
Date: Mon, 29 Apr 2013 07:43:45 +0000

> -- the format has both multicast names and addresses -- which ones are needed?  What if resolution disagrees?

The current solution has per entry an IP address and/or name, so it was intended as follows: if an IP address is given, this takes priority. (The name is just informational in this case.) If only a name is given, the CoAP endpoint has to do DNS resolution to obtain the IP address. (If it can't do DNS resolution - there's currently no way defined to detect/fix this.) We can update the text to reflect this.

> -- removes: the current text only has a PUT replacement of the whole group to do this.

Maybe a set of requirements is needed for the solution :)  that way we make explicit whether there's only a single manager involved or multiple may be present. Similar for the 'remove' function, or updating of individual entries. The assumption for this solution was always a single all-knowing manager to make the CoAP-device side as simple as possible.

Esko

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Carsten Bormann
Sent: Monday, April 22, 2013 17:17
To: Kovatsch Matthias
Cc: [email-masked]
Subject: Re: [core] I-D Action: draft-ietf-core-groupcomm-06.txt

Indeed.

More meta:

Grüße, Carsten