Change:
well as CoAP groups, by using the RD-Groups usage pattern of the CoRE Resource Directory (RD), as defined in Appendix A of I-D.ietf-core- resource-directory.  In particular, an application group can be <del> registered to the RD, specifying the reference IP multicast address, hence its associated CoAP group.  The registration is typically performed by a Commissioning Tool.  Later on, CoAP endpoints can discover the registered application groups and related CoAP group, by using the lookup interface of the RD. CoAP endpoints can also discover application groups by performing a group discovery query using the /.well-known/core resource.  Such a request may be sent to a known CoAP group multicast address associated to application group(s), or to the All CoAP Nodes multicast address. </del> <ins> registered to the RD, specifying the reference IP multicast address of its associated CoAP group.  The registration of groups is typically performed by a Commissioning Tool.  Later on, CoAP endpoints can discover the registered application groups and related CoAP group(s), by using the lookup interface of the RD. CoAP endpoints can also discover application groups and/or CoAP groups using a GET request on the /.well-known/core resource.  Such a request may be sent to a known CoAP group multicast address that is associated to one or more application group(s), or to the All CoAP Nodes multicast address; and the request may be sent with or without a query component.  These particular details of the request are selected depending on the intented discovery action of the client and on the particular encoding of group names in names and/or attributes of resources which is application-specific.  The following types of request may typically be used: Discovery of all application groups that are part of a CoAP group. For example, in case the application group name is encoded in the URI path as "/grp/<groupname>" then the discovery query may use URI "/.well-known/core?href=/grp/*" and it is sent to the IP multicast address of the CoAP group.  The query matches any application group name.  The result of this query is a list of resources at CoAP servers that are a member of at least one application group associated to the CoAP group.  Each resource represents an application group membership at one CoAP server. Discovery of a particular application group with a known name. For example, in case the known application group name is "mygroup1" and is encoded in the URI path as "/grp/<groupname>" then the discovery query may use URI "/.well-known/core?href=/grp/ mygroup1" and it is sent to the IPv6 All CoAP Nodes multicast address of a particular chosen scope (e.g. site-local, or realm- local).  The result of this query is a list of resources at CoAP servers that are a member of "mygroup1".  Each resource represents the membership of the responding server to the application group "mygroup1". Discovery of all application groups of a particular type.  For example, in case the application group type is "mytype1" and is encoded as a resource type (rt) attribute of the application group resource, and the application group resource is "/grp/<groupname>" then the discovery query may use URI "/.well-known/ core?rt=mytype1" and it is sent to the All CoAP Nodes multicast address.  The query result is a list of resources at CoAP servers that have at least one application group of type "mytype1"; each server response identifies the membership to one or more application group(s) of type "mytype1" for that server.  Each resource in the list represents one membership of a server to one application group of type "mytype1". Discovery of all application groups that are configured on the client's 6LoWPAN wireless mesh network.  In the following example a request without query is used.  So, the URI "/.well-known/core" is used and the request is sent to the IPv6 All CoAP Nodes multicast address of realm-local scope.  Each CoAP server (including any application group members) will return a list of its resources, which in this example includes the resources used to encode the application group name.  If each application group resource is known to be "/g/<groupname>" then the client marks each returned resource under the root resource "/g" as a discovered application group.  Not using a query has the disadvantage that potentially a lot of response traffic will be generated on the mesh network, including responses from servers that are not a member of any application group.  But it may be needed in particular use cases, e.g. if some of the CoAP servers do not support the optional link format query functionality (as mentioned in Section 4.1 of RFC6690). Note that all the above examples are application-specific; there is currently no standard way of encoding application group names or CoAP group names in CoAP resources and/or CoRE link attributes at the CoAP server.  (The aforementioned registration and discovery of groups in the RD is only defined for use with an RD, not for discovery on CoAP servers without using an RD.) </ins> When secure communication is provided with Group OSCORE (see chap- oscore), the approach described in I-D.tiloca-core-oscore-discovery <del> and also based on the RD can be used, in order to discover the security group to join. </del> <ins> also based on the RD can be used, in order to discover the security group to join. </ins> In particular, the responsible OSCORE Group Manager registers its own security groups to the RD, as links to its own corresponding

Discussion:
Pr clarify appl group discovery for
Oops, this PR accidentally contains also the changes of the other PR for . (This should be ignored by readers...)
Current draft says: I don't quite understand how that'd happen; I see two possible interpretations: Use .wk/c to discover content of application groups, eg. by requesting URL, picking really only one response, and hoping that it's just the content of the group resources and not everything on the host (cf. -- URL was requested, but what comes back is coap://[fe80::f00]/.well-known/core actually). Send out a broad multicast and wait for links that describe groups. However, other than the RD Appendix A methods (which aren't really applicable here), I don't know of any description format to be used. Is "The description of the group may be provided in an application specific or a yet to be defined generic format." meant here?
Above PR expands the text with discovery use cases and examples. We may still expand this later on with discovery examples or the link format attribute(s) defined by draft-tiloca-core-oscore-discovery; but that is not done yet. (I would need some more time still to read that draft first)
Reading the paragraph after "An application group can be named in many ways", I was left a bit confused: Why should it be encoded in the Uri-Query? That'd need coordination among all applications running on that host (for it is interfering with the query argument space that's usually left for the application to use). The common partitioning of applications inside a host is left-to-right in the URI, and that puts it in the very last spot. I think I do see what is meant by the discouragement of using the Uri-Host, but doubt that it'd be immediately obvious to general readers. How I understand Uri-Host to be impractical here is that while the request is sent to a well-defined and named URI, the response is a representation of the same URI with the individual server's IP replaced into the authority component, and if two application groups on the same CoAP group use the same path, then there may be clashes, not on the request-response layer (where the responses are bound to request for a particular host name) but in the client's cache of the responses.

(And once one is at the point where application groups in the same CoAP group have a disjunct path set, one can do away with identification altogether and just address the unique path). I don't quite follow how this is not "as intended in RFC7252": It is an identifier for who is being addressed, and as such just part of the URI. (For example, if I define my lights group to be named URL and name the resource , then the host name is exactly the group name, and already needs to be put into the request unless there is known URI aliasing). See also URL on "send a Uri-Host" option, with the caveat that I'm a strong proponent of answer A2. Furthermore, the text seems to imply that virtual hosting is something a server would need to go out of its way to implement. It isn't: The Uri-Host option is critical, and a host needs to make the conscious decision to ignore that option; otherwise it's just as much part of finding the addressed resource as all the other Uri-* options are. The best practice is something I can get behind, although I suggest using no identifier on the wire (and just the disjunct set of resources) as a byte saving alternative when the administrative effort of ensuring path uniqueness can be afforded.
Thanks; we do need to improve the current text on these aspects. On Uri-Host and your example "URL" where authority component includes the application group: in this group communication example the sending client would normally DNS-resolve "URL" to a particular multicast IP address, then send the CoAP request to this multicast IP address destination, without including any Uri-Host Option. This works as long as you have a unique 1:1 association between application-group and CoAP-group. In case multiple application-groups map to a single CoAP-group, this doesn't work anymore : a client could be e.g. configured to always include the "Uri-Host" Option to indicate the hostname. Still not the preferred approach I would think. Btw I can't follow answer A2 on the CoAP-Faq, unfortunately: formulation is too complex. In some (common?) constrained use cases, the DNS name would not even be configured in the client and the client would just be configured directly with the IPv6 multicast address of the CoAP group to send it to.

Then, the application-group would need to be encoded in some way still, e.g. using the Uri-Path Option. Now what our original text tried to suggest is to "misuse" a Uri-Host Option for that. So instead of using an option like: Uri-Path = group123 You would instead use an option: Uri-Host = group123 So this is not a "real" URI hostname but rather a low-level hack to let the client's CoAP stack insert by force an additional option just before sending out the CoAP request. The receiver's CoAP stack would just parse it as the ID of the application-group and not really as a URI-host. Because this gets confusing and potentially messy (proven by the present discussion !) we don't recommend it. So, trying to reiterate if one has configured Group URIs of the form coap://[mcast-ip-address]/resource on the client then by default the Uri-Host Option would get elided. The above mentioned "hack" is to put it back to encode application-group. This has the issue that the application-group name isn't present in the Group URI. if one has configured Group URIs of the form URL on the client then normally by default the authority gets resolved to some IP multicast address before sending it out, and thus while sending it the Uri-Host Option is NOT included in the CoAP encoding but elided. So the receiving server doesn't see the application-group ID because it's not encoded in the request data. (We assume here that multiple application-groups use the same CoAP-group.) Maybe we should discuss this further; what's the effort here / who ensures it / unique between what and what?
Initial text proposed in above PR! We'll merge it in by tomorrow evening, as an improvement (hopefully). What is not included yet is a statement saying that we don't recommend using the non-Group-URI methods of encoding application group name. To do so we would need to clearly state why that is not recommended; still not clear at this moment what the disadvantages of these are.