Draft: draft-ietf-core-groupcomm-bis

Commentary: 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 do n't quite understand how that 'd happen ; I see two possible interpretations : Use .wk / c to discover content of application groups , eg . by requesting , picking really only one response , and hoping that it 's just the content of the group resources and not everything on the host ( cf . -- 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 are n't really applicable here ) , I do n'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 do n't quite follow how this is not " as intended in  " : 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 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 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 is n'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 " " where authority component includes the application group : in this group communication example the sending client would normally DNS - resolve " " 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 does n'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 ca n'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 :    = group123 You would instead use an option :    = 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 do n'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 is n't present in the Group URI . if one has configured Group URIs of the form 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 does n'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 do n'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 .
Paragraph (version A):
It is possible for CoAP endpoints to discover application groups as
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
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.
Paragraph (version A):
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.
Paragraph (version A):
When secure communication is provided with Group OSCORE (see chap-
oscore), the approach described in I-D.tiloca-core-oscore-discovery
and also based on the RD can be used, in order to discover the
security group to join.
Paragraph (version B):
It is possible for CoAP endpoints to discover application groups as
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
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.
Paragraph (version B):
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.
Paragraph (version B):
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".
Paragraph (version B):
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".
Paragraph (version B):
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).
Paragraph (version B):
When secure communication is provided with Group OSCORE (see chap-
oscore), the approach described in I-D.tiloca-core-oscore-discovery
also based on the RD can be used, in order to discover the security
group to join.