Draft: draft-ietf-core-resource-directory

Commentary: See issue discussion . Closes : Action if not commented on : merge . 
 copa -coap 
 Thanks , fixed and merged . 
 Preparing for the IETF100 presentation I reviewed the role of groups in the RD , and given they are introduced with a focus on being discoverable multicast groups , I think I may have left that out of consideration when generalizing the lookup operations . There might be a class of desirable lookup operations that queries for resources on a multicast address : " Which resources are there in a multicast group ? " , the answer to which question would be typed links targetting a multicast address ; in terms of -12 's lookup examples : Req : GET /rd - lookup / XXX&rt="light " < /west;rt="light";anchor="coap://[ff35:30:2001 : db8::1 ] " , < /east;rt="light";anchor="coap://[ff35:30:2001 : db8::1 ] " I 'm unsure as to how that query should be formed exactly , and which links should be listed ( those available on some devices ? those on all ? ) , but I think that those links should be in some form discoverable . Are such links something we want to make discoverable in an RD ? Do we have enough information to decide which resources are accessible in a group ? What metadata do we have on those links ? ( Eg . is it rt="light " if all nodes that have such a relative reference say it is ? ) If we ca n't or do n't want supply those links ( yet ) , is it justified to introduce groups as a " logical grouping of endpoints for the purpose of group communications " , when all there is to it w / rt group communication is the ability to tell its multicast address in a group attribute ? Strawman proposal assuming all links are valid candidates : Add an optional - to - implement lookup interface Group Resource ( ) . It returns only links whose anchor was originally a relative reference , and re - interprets them once for each addressed group the link 's endpoint is member of . Links that have become duplicate ( as keyed by target , anchor and rel ) are aggregated into one link , and their attribute lists are reduced to only those attributes common to all links in the aggregate . ( rt= , if= and ct= attributes are not filtered out when they mismatch between the aggregated links , but are limited to their intersection value set . ) The links are filtered after aggregation , and can match as aggregates , match their group or match an attribute present on all the endpoints whose links were aggregated . 
 Hi  , valid question . I seem to remember that in a distant past the links were specified with the group in the con parameter . That was then still possible . Add the links in the payload ? FYI : RFC 7390 specifies names and MC addresses . chrysn schreef op 2017 - 11 - 12 06:46 : 
 Hi  , not sure if I understood completely . A group lookup is like an ep lookup with multiple ep targets . The following seems a reasonable query to me : GET /rd - lookup / gp?con="coap://[ff35:30:2001 : db8::1 ] which returns all eps with the specified MC address . The next query can be specified to find the resources of the returned eps . Seems perfectly OK to me ; may be introduce such an example ? 
 Hi  , a proposed addition to RD section 7.4 lookup examples Section 7.3 of RD says : “ A search criterion matches an endpoint if it matches the endpoint itself or any of the groups it is contained in , and one on a resource if it matches the resource , the resource 's endpoint , or any of the endpoint 's groups . ” Accordingly , the following example is proposed : Suppose a group light exists with two registrations , with endpoint names  and mylt2 , where each registration contains one resource with rt = light . A resource lookup is wanted that requests the resources belonging to group lights . The RD returns the resources that are returned by the sequential invocation of the resource lookup of mylt1 and mylt2 . Req : GET /rd - lookup / res?gp = light&rt = light Res : 2.05 Content < coap://[2001 : db8:3::125]:/res/0;rt=”light”;ep=”myep1”;ct=40 ; anchor=”coap://[2001 : db8:3:125 ] : ” , < coap://[2001 : db8:3::127]:/res/0;rt=”light”;ep=”myep2”;ct=40 ; anchor=”coap://[2001 : db8:3:127 ] : ” 
 The last example proposed already works . What I 'm talking about in this issue is finding which resources there are that are , ie . which paths are reasonable to pack into a request going to a multicast address . As agreed in the last meeting , that issue can be solved by an additional document if the need arises . I 'm writing a one - paragraph PR to add a statement about this , but the issue can be closed both by accepting that PR and by rejecting it with " no reason to say that , because any extension can be later , no ned to enumerate them " . 
 Note from far - later : If we accept the new - groups branch , this issue will be trivially solved as each group can be queried for its resources at and similar . All the open questions of how to know which resources are shared are resolved by that data being explicitly input into the RD .
Paragraph (version A):
For groups, a Resource Directory as specified here does not provide a
lookup mechanism for the resources that can be accessed on a group's
multicast address (ie. no lookup will return links like
"<coap://[ff35:30:2001:db8::1]/light>;..." for a group registered
with "con=copa://[ff35...]").  Such an additional lookup interface
could be specified in an extension document.
Paragraph (version B):
For groups, a Resource Directory as specified here does not provide a
lookup mechanism for the resources that can be accessed on a group's
multicast address (ie. no lookup will return links like
"<coap://[ff35:30:2001:db8::1]/light>;..." for a group registered
with "con=coap://[ff35...]").  Such an additional lookup interface
could be specified in an extension document.