Skip to main content

Group Communication for the Constrained Application Protocol (CoAP)
draft-ietf-core-groupcomm-25

Revision differences

Document history

Date Rev. By Action
2014-10-30
25 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2014-10-24
25 Barry Leiba Changed consensus to Yes from Unknown
2014-10-23
25 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2014-10-13
25 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2014-09-19
25 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2014-09-19
25 Amy Vezza IESG state changed to RFC Ed Queue from Approved-announcement sent
2014-09-19
25 (System) RFC Editor state changed to EDIT
2014-09-19
25 (System) Announcement was received by RFC Editor
2014-09-19
25 Amy Vezza IESG has approved the document
2014-09-19
25 Amy Vezza Ballot approval text was changed
2014-09-19
25 Amy Vezza Ballot approval text was generated
2014-09-18
25 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2014-09-18
25 (System) IANA Action state changed to Waiting on Authors from In Progress
2014-09-17
25 Barry Leiba Intended Status changed to Experimental from Informational
2014-09-17
25 Barry Leiba Notification list changed to : core-chairs@tools.ietf.org, draft-ietf-core-groupcomm@tools.ietf.org
2014-09-17
25 (System) IANA Action state changed to In Progress
2014-09-17
25 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2014-09-17
25 Amy Vezza IESG has approved the document
2014-09-17
25 Amy Vezza Closed "Approve" ballot
2014-09-17
25 Amy Vezza Ballot approval text was generated
2014-09-17
25 Barry Leiba IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2014-09-15
25 Martin Stiemerling [Ballot comment]
I happy to see it go as experimental.
2014-09-15
25 Martin Stiemerling [Ballot Position Update] Position for Martin Stiemerling has been changed to No Objection from Discuss
2014-09-12
25 Akbar Rahman New version available: draft-ietf-core-groupcomm-25.txt
2014-09-05
24 Kathleen Moriarty
[Ballot comment]
Thank you for updating the section on monitoring.  The description covering both targeted and pervasive attacks is very clear now and covers and …
[Ballot comment]
Thank you for updating the section on monitoring.  The description covering both targeted and pervasive attacks is very clear now and covers and explains the threats nicely.
2014-09-05
24 Kathleen Moriarty [Ballot Position Update] Position for Kathleen Moriarty has been changed to No Objection from Discuss
2014-09-02
24 Ben Campbell Request for Last Call review by GENART Completed: Not Ready. Reviewer: Ben Campbell.
2014-09-01
24 Akbar Rahman New version available: draft-ietf-core-groupcomm-24.txt
2014-08-29
23 Akbar Rahman New version available: draft-ietf-core-groupcomm-23.txt
2014-08-25
22 Gunter Van de Velde Closed request for Last Call review by OPSDIR with state 'No Response'
2014-08-25
22 Brian Haberman [Ballot comment]
Thanks for quickly addressing the issues raised.
2014-08-25
22 Brian Haberman [Ballot Position Update] Position for Brian Haberman has been changed to No Objection from Discuss
2014-08-24
22 (System) Sub state has been changed to AD Followup from Revised ID Needed
2014-08-24
22 Akbar Rahman IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2014-08-24
22 Akbar Rahman New version available: draft-ietf-core-groupcomm-22.txt
2014-08-21
21 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2014-08-21
21 Stephen Farrell
[Ballot comment]

Sorry, I only had time to quickly scan this.

- For a non MC IP addr, how does one know a URI is …
[Ballot comment]

Sorry, I only had time to quickly scan this.

- For a non MC IP addr, how does one know a URI is for a
group?

- 5.3.3: That draft-keoh draft is quite controversial in the
DICE WG. The question there is whether or not its at all
sensible to try do group security in the DTLS record layer. I
think you really ought recognise that, since its quite
possible that a very different solution will be needed in
reality.

- Thanks for 5.4! I think you should also note that even with
encryption providing confidentiality, traffic analysis could
be a powerful tool against CoAP and group communication, so
future work with CoAP and developers/deployers should also
take into account traffic analsyis. To use your fav example,
its not hard to detect the lights being turned on or off even
if that's done via ciphertext is it?
2014-08-21
21 Stephen Farrell [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell
2014-08-21
21 Jari Arkko
[Ballot comment]
Thank you for writing this document on this important topic. Iit is indeed something that many users of CoAP technology are wondering about. …
[Ballot 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?
2014-08-21
21 Jari Arkko Ballot comment text updated for Jari Arkko
2014-08-21
21 Jari Arkko
[Ballot comment]
Thank you for writing this document on this important topic. Iit is indeed something that many users of CoAP technology are wondering about. …
[Ballot 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. For information, I am also an implementor who has used multicast-based designs in CoAP (including support for security).

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?
2014-08-21
21 Jari Arkko [Ballot Position Update] Position for Jari Arkko has been changed to No Objection from No Record
2014-08-21
21 Jari Arkko
[Ballot comment]
Thank you for writing this document on this important topic. Iit is indeed something that many users of CoAP technology are wondering about. …
[Ballot 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. For information, I am also an implementor who has used multicast-based designs in CoAP (including support for security).

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 necessary in my opinion.

A few more detailed comments:

    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. 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.
2014-08-21
21 Jari Arkko Ballot comment text updated for Jari Arkko
2014-08-21
21 Pete Resnick
[Ballot comment]
I agree with others: I sure would like to see this be Experimental, see some implementation experience, and, when security issues are sussed …
[Ballot comment]
I agree with others: I sure would like to see this be Experimental, see some implementation experience, and, when security issues are sussed out, see it moved onto the Standards Track.

A few small comments; nothing earth-shattering:

2.7.2.1/2.7.2.2/2.7.2.6/2.7.2.7:

  ...the endpoint MUST effect registration...as soon as possible.
 
"MUST" do something "as soon as possible" does not seem like a testable requirement. What purpose is it serving?

2.8: These normative behaviors and guidelines look like they could use 2119 keywords. In particular, quite a few of those "should not"s look like they are meant as "SHOULD NOT"s. They obviously don't need to be, but I was wondering if there was something I was missing.
2014-08-21
21 Pete Resnick [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick
2014-08-20
21 Kathleen Moriarty
[Ballot discuss]
Overall, the draft is well written and although security is not present, the threats and proposed future solution discussion is good.

Section 5.4 …
[Ballot discuss]
Overall, the draft is well written and although security is not present, the threats and proposed future solution discussion is good.

Section 5.4 is specific to pervasive monitoring, but I think monitoring is better as it casts a wider net and could include pervasive monitoring concerns, but other concerns as well related to monitoring.  Monitoring could be targeted to observe specific organizations, people, or devices, that could also be used as part of a targeted attack.  Monitoring could also lead to privacy concerns if patterns of behavior are observed for individuals.

Thanks.
2014-08-20
21 Kathleen Moriarty
[Ballot comment]
I support the comments by others on the document not really being informational.  The lack of security controls is an issue, experimental would …
[Ballot comment]
I support the comments by others on the document not really being informational.  The lack of security controls is an issue, experimental would be good until it is resolved as there is a lot of work to be done in this space and it is active.
2014-08-20
21 Kathleen Moriarty [Ballot Position Update] New position, Discuss, has been recorded for Kathleen Moriarty
2014-08-20
21 Alissa Cooper [Ballot comment]
I agree with Richard/Martin that this doesn't seem like it is informational, and that experimental is probably the appropriate status.
2014-08-20
21 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2014-08-20
21 Adrian Farrel
[Ballot comment]
Martin has a good catch about updates to 7252 and I support his Discuss.

---

It would have been nice to have heard …
[Ballot comment]
Martin has a good catch about updates to 7252 and I support his Discuss.

---

It would have been nice to have heard about implementations of CoAP that
do group communication and whether they consider themselves consistent
with this I-D.
2014-08-20
21 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel
2014-08-20
21 Richard Barnes
[Ballot comment]
Given the complete lack of security mechanisms, I would be happier if this were Experimental, to be promoted to Standards Track once the …
[Ballot comment]
Given the complete lack of security mechanisms, I would be happier if this were Experimental, to be promoted to Standards Track once the group keying issues are addressed.
2014-08-20
21 Richard Barnes [Ballot Position Update] New position, No Objection, has been recorded for Richard Barnes
2014-08-20
21 Joel Jaeggli [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli
2014-08-19
21 Spencer Dawkins
[Ballot comment]
I share the concerns Martin listed in his Discuss, but that conversation is already underway.

I saw that Martin is questioning whether this …
[Ballot comment]
I share the concerns Martin listed in his Discuss, but that conversation is already underway.

I saw that Martin is questioning whether this document should be Informational, but

1.2.  Scope

  While [RFC7252] supports various modes of DTLS based security for
  CoAP over unicast IP, it does not specify any security modes for CoAP
  over IP multicast.  That is, [RFC7252] assumes that CoAP over IP
  multicast is not encrypted, nor authenticated, nor access controlled.
  This document assumes the same security model (see Section 5.1).
  However, there are several promising security solutions being
  developed that should be considered in the future for protecting CoAP
  group communications (see Section 5.3.3).

would make me uneasy about publishing it as standards-track in 2014. If this specification was Experimental, I'd feel better, but as the specification itself correctly points out:

5.4.  Pervasive Monitoring Considerations

  A key additional threat consideration for group communication is
  pointed to by [RFC7258] which warns of the dangers of pervasive
  monitoring.  CoAP group communication which is built on top of IP
  multicast should pay particular heed to these dangers.  This is
  because IP multicast is easier to intercept (e.g., and to secretly
  record) compared to unicast traffic.  Also, CoAP traffic is meant for
  the Internet of Things.  This means that CoAP traffic is often used
  for the control and monitoring of critical infrastructure (e.g.,
  lights, alarms, etc.) which may be prime targets for attack.

Approving it as a Proposed Standard seems to be begging for someone to deploy it without reading the warning labels ... would anyone who's planning to use CoAP group communications without security (beyond suggestions such as enabling WiFi security), be unwilling to use it at Experimental?

In this text:

2.3.  Port and URI Configuration

  A CoAP server that is a member of a group listens for CoAP messages
  on the group's IP multicast address, usually on the CoAP default UDP
  port, 5683.  If the group uses a specified non-default UDP port, be
  careful to ensure that all group members are configured to use that
  same port.  Therefore different ports for the same IP multicast
  address cannot be used to specify different CoAP groups.

I'm probably missing something, but I'm not understanding this. If I have two groups of IoT devices configured to use the same IP multicast address, and each group uses its own UDP port, what doesn't work?
2014-08-19
21 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2014-08-19
21 Brian Haberman
[Ballot discuss]
I have no issues with the goal of this document, but I do have some items I would like to talk about:

1. …
[Ballot discuss]
I have no issues with the goal of this document, but I do have some items I would like to talk about:

1. The text in section 1.2 implies that the primary multicast mode of operation is source-specific, but doesn't explicitly state that.  Is it intended that multicast is only done in an SSM mode?  If so, it would be good to provide explicit discussion of that (including references to relevant SSM RFCs such as 3569, 4604, and 4607).  If the goal is to also support ASM, that should be stated explicitly.

2. Does the multicast proxy forwarding described in RFC 4605 apply in section 2.1?

3. I am a little concerned with the SHOULD used in section 2.2 when discussing nodes joining the All-CoAP-Nodes multicast address.  What happens if a device does not join that group?  Will the protocol break?

4. Section 2.3 should allow a device to obtain the port number for the group from the URI schema referenced in section 2.2.

5. I see that the socket() API (RFC 3542) is referenced, but it is not discussed in terms of CoAP interacting with the group management protocols.  Is it assumed that implementers know that they are to use that API to indicate changes in group membership state to IGMP/MLD?
2014-08-19
21 Brian Haberman [Ballot comment]
The various discussions of reliable multicast in the document may benefit from an informative reference to a technique such as RFC 3940.
2014-08-19
21 Brian Haberman [Ballot Position Update] New position, Discuss, has been recorded for Brian Haberman
2014-08-18
21 Martin Stiemerling
[Ballot discuss]
Updated:

I have objections about this draft being published in its current form and with its current status. The draft updates protocol behavior …
[Ballot discuss]
Updated:

I have objections about this draft being published in its current form and with its current status. The draft updates protocol behavior of RFC 7252 in at least two Sections: 2.5 and also 2.7. But is never saying so and legally speaking also not requesting any update of RFC 7252.

Section 2.5 updates the handling of tokens for the mutlicast usage.
Section 2.7 adds a completely new functionality to the protocol.

This has also been nicely pointed out by the GENART reviewer: http://www.ietf.org/mail-archive/web/core/current/msg05535.html

Probably the document is heading for standards track instead of informational?

Further, I do see multiple playes where the RFC 2119 language is inappropriate:

2.2.  Group Definition and Naming

[...]

  All CoAP server nodes SHOULD join the "All CoAP Nodes" multicast
  group [RFC7252], Section 12.8) by default to enable CoAP discovery.
  For IPv4, the address is 224.0.1.187 and for IPv6 a server node joins
  at least both the link-local scoped address FF02::FD and the site-
  local scoped address FF05::FD.  IPv6 addresses of other scopes MAY be
  enabled.
Since this is (hopefully) just repeating what RFC 7252 say, it is just good to say:
"All CoAP server nodes should/are supposed to join the "All CoAP Nodes" multicast"
Also the "MAY be" is a "can be" in reality.

2.7.2.  Membership Configuration RESTful Interface

The " an OPTIONAL CoAP membership configuration RESTful" is misplaced, as this in informational draft, but this goes back to my general DISCUSS point above.

Further:
  To access this interface a client MUST use
  unicast CoAP methods (GET/PUT/POST/DELETE).  This interface is a
This MUST is not correct here. A sentence saying that only the unicast methods are useful in this respect is sufficient.

And here the contradiction is happening, as I do not see a MUST for DTLS in RFC 7252 and this text below is also not adding anything useful to the discussions what is needed to achieve interoperability, i.e., inappropriate for MUST in this place:
  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.
2014-08-18
21 Martin Stiemerling Ballot discuss text updated for Martin Stiemerling
2014-08-15
21 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Shawn Emery.
2014-08-15
21 Martin Stiemerling
[Ballot discuss]
I have no general objection to this draft being published, but I have a doubt about the normative language used in this informational …
[Ballot discuss]
I have no general objection to this draft being published, but I have a doubt about the normative language used in this informational draft. What does it mean that an informational draft is using RFC 2119 language to describe how CORE is being operated for multicast?

My confusion started in Section 2.5. Is this solely repeating what's anyway specified by CORE or is it giving different advice? Or is it trying to override the CORE spec? What is happening if there are inconsistent guidances?

I am not yet through with the whole document, but I would like to get a clarification about the above point before doing any further review of the draft.
2014-08-15
21 Martin Stiemerling [Ballot Position Update] New position, Discuss, has been recorded for Martin Stiemerling
2014-08-14
21 Barry Leiba IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
2014-08-14
21 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2014-08-13
21 Barry Leiba Ballot has been issued
2014-08-13
21 Barry Leiba [Ballot Position Update] New position, Yes, has been recorded for Barry Leiba
2014-08-13
21 Barry Leiba Created "Approve" ballot
2014-08-11
21 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed
2014-08-11
21 Pearl Liang
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-core-groupcomm-21.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon …
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-core-groupcomm-21.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA has a question about one of the actions requested in the IANA Considerations section of this deocument.

IANA understands that, upon approval of this document, there are two actions which IANA must completed.

First, Resource Type (rt=) Link Target Attribute Values subregistry of the Constrained RESTful Environments (CoRE) Parameters registry located at:

http://www.iana.org/assignments/core-parameters/

a new attribute value will be registered as follows:

Value: core.gp
Description: Group Configuration resource. This resource is used to query/manage the group membership of a CoAP server.
Reference: [ RFC-to-be ]

Second, in the application media types subregistry of the Media Types registry located at:

http://www.iana.org/assignments/media-types/

a new application media type will be registered as follows:

Name: coap-group+json
Template: application/coap-group+json [ as provided in [ RFC-to-be ] ]
Reference: [ RFC-to-be ]

IANA understands that these two actions are the only ones required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document
has been approved for publication as an RFC. This message is only to confirm what actions
will be performed.
2014-08-05
21 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Benson Schliesser
2014-08-05
21 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Benson Schliesser
2014-08-01
21 Tero Kivinen Request for Last Call review by SECDIR is assigned to Shawn Emery
2014-08-01
21 Tero Kivinen Request for Last Call review by SECDIR is assigned to Shawn Emery
2014-07-31
21 Jean Mahoney Request for Last Call review by GENART is assigned to Ben Campbell
2014-07-31
21 Jean Mahoney Request for Last Call review by GENART is assigned to Ben Campbell
2014-07-31
21 Amy Vezza IANA Review state changed to IANA - Review Needed
2014-07-31
21 Amy Vezza
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Group Communication for CoAP) to …
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Group Communication for CoAP) to Informational RFC


The IESG has received a request from the Constrained RESTful Environments
WG (core) to consider the following document:
- 'Group Communication for CoAP'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-08-14. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  CoAP is a specialized web transfer protocol for constrained devices
  and constrained 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.  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 file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-core-groupcomm/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-core-groupcomm/ballot/


No IPR declarations have been submitted directly on this I-D.


2014-07-31
21 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2014-07-31
21 Barry Leiba Placed on agenda for telechat - 2014-08-21
2014-07-31
21 Barry Leiba Last call was requested
2014-07-31
21 Barry Leiba Last call announcement was generated
2014-07-31
21 Barry Leiba Ballot approval text was generated
2014-07-31
21 Barry Leiba IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2014-07-31
21 (System) Sub state has been changed to AD Followup from Revised ID Needed
2014-07-31
21 Akbar Rahman New version available: draft-ietf-core-groupcomm-21.txt
2014-07-26
20 Barry Leiba Revised I-D needed to address AD review comments.
2014-07-26
20 Barry Leiba IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2014-07-21
20 Barry Leiba Ballot writeup was changed
2014-07-21
20 Barry Leiba Ballot writeup was generated
2014-07-21
20 Barry Leiba IESG state changed to AD Evaluation from Publication Requested
2014-07-21
20 Barry Leiba Notification list changed to : core-chairs@tools.ietf.org, draft-ietf-core-groupcomm@tools.ietf.org, core@ietf.org
2014-07-21
20 Carsten Bormann
1. Summary

This document provides (Informational) illustration and guidance on
how to use the CoAP protocol (RFC 7252) in a group communication
context, …
1. Summary

This document provides (Informational) illustration and guidance on
how to use the CoAP protocol (RFC 7252) in a group communication
context, including the use of IP multicast.
(The functionality for this is provided in the base specification,
however with very little guidance on good ways to use it.)

Carsten Bormann is the document shepherd.
Barry Leiba is the responsible Area Director.

2. Review and Consensus

The document was developed along with the base CoAP specification and
received review by a number of active WG members and implementers.
It is not easy to obtain extensive review of informational documents
from the community, but the shepherd is convinced that we have enough
WG-level review for publication as an Informational document.
Wider review (e.g., directorate reviews) has not yet been taken place.

3. Intellectual Property

There is no IPR disclosure referencing this document.  The authors
have indicated recently that they are not aware of patent claims
relating to this document.

4. Other Points

(There is an idnits false positive due to the mention of 224.0.1.187,
All CoAP Nodes; there are also idnits comments on what may seem like
references in the changelog to be removed by the RFC editor.)

Messages have been sent to core-parameters@ietf.org for core.gp and
media-types@iana.org for coap-group+json; the intention is that this
processing can go on in parallel.
2014-07-21
20 Carsten Bormann State Change Notice email list changed to core-chairs@tools.ietf.org, draft-ietf-core-groupcomm@tools.ietf.org
2014-07-21
20 Carsten Bormann Responsible AD changed to Barry Leiba
2014-07-21
20 Carsten Bormann IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2014-07-21
20 Carsten Bormann IESG state changed to Publication Requested
2014-07-21
20 Carsten Bormann IESG process started in state Publication Requested
2014-07-21
20 Carsten Bormann Changed document writeup
2014-07-21
20 Carsten Bormann Changed document writeup
2014-07-20
20 Akbar Rahman New version available: draft-ietf-core-groupcomm-20.txt
2014-07-20
19 Carsten Bormann Document shepherd changed to Dr. Carsten Bormann
2014-06-17
19 Akbar Rahman New version available: draft-ietf-core-groupcomm-19.txt
2014-03-03
18 Carsten Bormann IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Document
2013-12-22
18 Akbar Rahman New version available: draft-ietf-core-groupcomm-18.txt
2013-11-28
17 Esko Dijk New version available: draft-ietf-core-groupcomm-17.txt
2013-10-02
16 Akbar Rahman New version available: draft-ietf-core-groupcomm-16.txt
2013-09-27
15 Akbar Rahman New version available: draft-ietf-core-groupcomm-15.txt
2013-09-23
14 Akbar Rahman New version available: draft-ietf-core-groupcomm-14.txt
2013-09-19
13 Akbar Rahman New version available: draft-ietf-core-groupcomm-13.txt
2013-07-31
12 Carsten Bormann Intended Status changed to Informational from None
2013-07-30
12 Akbar Rahman New version available: draft-ietf-core-groupcomm-12.txt
2013-07-14
11 Akbar Rahman New version available: draft-ietf-core-groupcomm-11.txt
2013-07-09
10 Esko Dijk New version available: draft-ietf-core-groupcomm-10.txt
2013-05-29
09 Akbar Rahman New version available: draft-ietf-core-groupcomm-09.txt
2013-05-27
08 Akbar Rahman New version available: draft-ietf-core-groupcomm-08.txt
2013-05-07
07 Akbar Rahman New version available: draft-ietf-core-groupcomm-07.txt
2013-04-12
06 Esko Dijk New version available: draft-ietf-core-groupcomm-06.txt
2013-02-05
05 Akbar Rahman New version available: draft-ietf-core-groupcomm-05.txt
2012-12-20
04 Akbar Rahman New version available: draft-ietf-core-groupcomm-04.txt
2012-10-19
03 Akbar Rahman New version available: draft-ietf-core-groupcomm-03.txt
2012-07-10
02 Esko Dijk New version available: draft-ietf-core-groupcomm-02.txt
2012-03-09
01 Akbar Rahman New version available: draft-ietf-core-groupcomm-01.txt
2012-01-10
00 (System) New version available: draft-ietf-core-groupcomm-00.txt