## 1 Introduction  
The Do-It-Yourself (DIY) movement is spreading beyond traditional domains, such as home painting, to more modern domains, such as programming. DIY programming gets especially interesting when it involves real-time data from the growing amount of smart objects with embedded sensors and when actuators can be triggered to perform real-world actions accordingly. It becomes even more interesting and appealing when access to these smart objects can be obtained over the ubiquitous Internet--leading to what is now mostly known as the Internet of Things (IoT). However, these smart objects are typically optimized for low-power consumption and low-cost. They are constrained in their processing capabilities (CPU, RAM, ROM,...) and thus unable to run standard Internet protocols. The networks that connect these objects together are often referred to as low power and lossy networks (LLNs). Connecting LLNs to the Internet, communicating with smart objects, and manipulation of sensor data and actuators was largely done in proprietary ways. Each vendor had its own set of protocols and tools to access, interpret and if needed manipulate sensor data and to trigger actuators. More recently a lot of effort has been put into the development of open standards that cover many aspects of communication and access to smart objects. At the networking layer 6 LoWPAN allows IPv6 communication with these objects through an adaptation layer [2]. At the application layer standards are being prepared to allow access to these objects in a RESTful way, similar to how most information on today's Internet is accessed over HTTP. The main driver behind this is the Internet Engineering Task Force (IETF). The IETF established the Constrained RESTful Environments (CoRE) working group with the aim of realizing the REST architecture in a suitable form for the most constrained nodes and networks. Constrained devices are turned into embedded web servers that make their resources accessible via the CoAP protocol. CoRE is aimed at machine-to-machine (M2M) applications such as smart energy and building automation [3]. Typically, each of the constrained servers has at least one CoAP resource that may be queried by clients to obtain information about the smart objects themselves (e.g., battery level), about the environment that they monitor (e.g., temperature of the room), or to trigger the objects to perform real-world actions (switch the light on). These CoAP resources are identified by a Uniform Resource Identifier (URI) such as coap://[aaaa::1]/temperature. Depending on the application, information from individual objects might not be sufficient, reliable, or useful. An application may need to aggregate and/or compare data from several nodes in order to obtain accurate results. In the same way, a single user request might need to trigger a series of actions on multiple actuators. This need to communicate with groups of objects is obvious in many IoT scenarios. For example, in a smart home, when you leave your bed during the night, you might want that the lights in the bedroom, hall and toilet turn on automatically until you go to bed again. Or, when suspicious movement is detected in the living area during the night, several actuators may be triggered such as an alarm going off and particular lights being turned on or made flashing. From these two simple examples, one can already see that the same lights can be parts of different groups according to the needs of the user. The needs can change regularly and thus the grouping and ungrouping of resources should be flexible and easy. Similar examples for the need of group communication can be found in virtually any IoT scenario. The need for group communication is very well recognized in the IETF. This can be clearly seen from the charter of the IETF CoRE Working Group.