Subject: [core] Resource Directory - Filters on Lookup Resources

From: Jim Schaad <[email-masked]>
Date: Tue, 12 Sep 2017 16:46:15 -0700

I am working on figuring out how to deal with the filter properties when
working with the lookup resources and I am have problems because I don't
understand how some of them are supposed to be applied.  It may be that you
just did cut and paste more than you should have when specifying what lookup
resources they applied to.  An idea of how things are supposed to work would
be nice to see.

If I am doing a look up for groups, what does it mean to specify that you
are looking for a specific resource type?  Should this not be supported for
groups or does this mean that the RD is expected to only return those
endpoints where a resource exists of the specified resource type?

A similar question exists for the "res" query parameter.  For a group, does
this mean that the multicast address is being matched or a resource for some
endpoint in the group is being matched? 

You need to look at each of the items and determine what it means for each
lookup resource type and identity it for the reader.

Jim

---

From: peter van der Stok <[email-masked]>
Date: Fri, 15 Sep 2017 10:55:37 +0200

Hi Jim,

Really thanks for this detailed inspection of the RD draft.
The draft has had a long history of reviews, improvements and 
(forgotten) discussions.
See below.

> endpoints where a resource exists of the specified resource type?

The purpose of groups was to service MC requests.
That means that the path and rt on the receivers (group members) are 
identical.
So, if one ep supports that particular rt, I would expect that all eps 
do.

Do you want to extend the group concept? or suggest text in the group 
specification?

> endpoint in the group is being matched?

Is that answered above?

> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Jim Schaad <[email-masked]>
Date: Fri, 15 Sep 2017 15:15:32 -0700

See inline comments

> -----Original Message-----
> From: peter van der Stok [mailto:[email-masked]]
> Sent: Friday, September 15, 2017 1:56 AM
> To: Jim Schaad <[email-masked]>
> Cc: [email-masked]; [email-masked]
> Subject: Re: [core] Resource Directory - Filters on Lookup Resources
> 
> Hi Jim,
> 
> > I am working on figuring out how to deal with the filter properties
> > when working with the lookup resources and I am have problems because
> > I don't understand how some of them are supposed to be applied.  It
> > may be that you just did cut and paste more than you should have when
> > specifying what lookup resources they applied to.  An idea of how
> > things are supposed to work would be nice to see.
> >
> > If I am doing a look up for groups, what does it mean to specify that
> > you are looking for a specific resource type?  Should this not be
> > supported for groups or does this mean that the RD is expected to only
> > return those endpoints where a resource exists of the specified
> > resource type?
> 
> So, if one ep supports that particular rt, I would expect that all eps do.
> 

Just to be clear.  The rt parameter is not included as far as I can tell in
the group registration process.  Doing a query based on this parameter would
require looking at the resources registered for one or more endpoints in the
group.  My initial assumption was that the query only looked at attributes
that were assigned to the endpoint itself and not to the resources of the
endpoint.  I am also operating under the assumption that the attributes
assigned to an endpoint are the query parameters that were provided when the
resources were registered.  This means that one could include an rt query
parameter when the endpoint was registered which would be available for
filtering of endpoints.

Even doing a query based on the endpoints is a bit odd depending on how you
design the data model.  Is there a query on all groups - i.e. give me the
list of groups which meet this criteria (1), or is there only a query on
membership of groups - i.e. give me all endpoints that are members of some
group and meet the following criteria (2).

(1) GET /group-lookup?group-type=beta
(2) GET /group-lookup?et=alpha

I am not sure why you would make the assumption that all members of a group
are identical.  Consider a lighting group.  Members of the group would
include not only the light bulbs but also the switches as well.  It might
even include some type of alarm monitoring device which might take an action
based on a command issued on the group.  

> 
> >
> > A similar question exists for the "res" query parameter.  For a group,
> > does this mean that the multicast address is being matched or a
> > resource for some endpoint in the group is being matched?
> 
> Is that answered above?

No this doesn't really.  Consider the items below.  (1) says that it was to
know the group which is at  given multi-cast address.  (2) says give me the
set of endpoints that are in a group and which have a resource registered
which starts with the string "/lights".   It is not really a good thing to
try and support both of these so a choice really needs to be made.   Again -
what is the data model.

(1) GET /group-lookup?href=coap://multicast-address
(2) GET /group-lookup?href=/lights*

Jim

> 
> >
> > You need to look at each of the items and determine what it means for
> > each lookup resource type and identity it for the reader.
> >
> > Jim
> >
> >

---

From: Michael Koster <[email-masked]>
Date: Mon, 18 Sep 2017 00:12:07 -0700

HI Jim,

I want to start over to try to answer your questions, below.

> On Sep 12, 2017, at 4:46 PM, Jim Schaad <[email-masked]> wrote:
> 
It looks like some updates may have been missed in the group and group lookup sections. In addition to the points below, we should look it over carefully again. Thanks again for the careful review.

A group lookup (using the lookup resoure rd.lookup-group) returns a list of links to group resources where endpoints in the group contain resources that satisfy the match criteria. So if I specify a resource type in a group query, the result is expected to be a list of group resources where each group contains one or more endpoints that in turn contain one or more resources of the resource type specified in the query. We should specify that a group is included in the returned list of groups if any link in any endpoint in the group contains a matching target attribute e.g. "rt".

The examples of group lookups need to be corrected. The "href" value or string in angle brackets should contain the location path that was returned when the group is registered. I think we also need to clarify that registering a group with "con=" will set the multicast address for the group and will be returned on group lookups as "con=" rather than substituting the multicase address for the href location. (section 6.1) I guess the description of "con" is a copy/paste from the registration section. 

I think the statement about using an endpoint domain attribute as a group domain attribute may need to be removed. I think a group may contain endpoints with different domain attribute values.

> endpoint in the group is being matched? 
"res" is resource name, and I'm not sure exactly what that refers to elsewhere in the spec. I therefore presume it's a resource target attribute that the resource can be registered with and queried on. If so, we should provide an example.

> lookup resource type and identity it for the reader.
Yes, good point. We need to enumerate more of the matrix with examples. I believe all of the cross product of query parameters and lookup types are legal and sensible, but will look it over again and provide some more examples.

Best regards,

Michael

---

From: Michael Koster <[email-masked]>
Date: Mon, 18 Sep 2017 00:14:14 -0700

Sorry, that's resource type "core.rd-lookup-gp"

> On Sep 18, 2017, at 12:12 AM, Michael Koster <[email-masked]> wrote:
> 
> resoure rd.lookup-group)

---

From: Michael Koster <[email-masked]>
Date: Mon, 18 Sep 2017 07:01:48 -0700

After a little more thought, I think we should consider to include a table of lookup types vs. query parameters with pointers to examples. 

Best regards,

Michael

> I believe all of the cross product of query parameters and lookup types are legal and sensible, but will look it over again and provide some more examples.