Re: [core] Questions/Review on draft-ietf-core-resource-directory-12

[Christian Amsüss <[e-mail]>]

Hello Jim,

responses inline:

On Tue, Oct 31, 2017 at 05:25:50PM -0700, Jim Schaad wrote:
> 1.  When creating a group registration, can the link to an endpoint be on a
> different resource directory?  This second RD could be either on a different
> machine or on the same machine (i.e. coap vs coaps).  If the answer is no,
> then do we need to think about some type of relation attribute in the case
> that multiple are listed somewhere?

I like to think so (having a more distributed model in mind), but we
haven't discussed it yet.

As for the specification, I think we should say that the CTs operating
on the tool working on the group "SHOULD refer to the endpoint
registrations either as a path-absolute relative reference (if it
obtained the reference from the Location option when it conducted the
registration itself), or use the reference as serialized when it
obtained the location from an endpoint lookup from the same RD origin".

This leaves the door open for federating RDs (where some endpoint
registrations are located at another RD host, but still available for
lookup at the closest host), but discourages blind mixing of
registration entities from unrelated RDs.

(Discussion about this can go continue on-list, but for tracking
purposes it's tracked at [85] too).

> 2.  Is there supposed to be an update/patch operation on groups or is this a
> replace operation ala what is done for endpoints?

Yes. Whatever will work for the more intricate resource link update
should also work for the more set-like group management.

Right now, groups can only be replaced by re-registering with the same
group name and a new set of links.

> 3. Are groups supposed to age out of existence?  Based on the current text I
> would say that this is a no.

So do I.

> 4.  Should have text on what happens to a group when an endpoint which ages
> out of existence.

Good point, taken up ([86]).

> 5.  When registering groups, is there a requirement that all of the
> endpoints be in the same domain as the group is?

That's the idea implied in the hierarchy, but probably answered better
by Michael or Peter who use the domain concept more than I do.

> 6.  In section 7.3 - First it would be better to be much more explicit on
> the set of items to be matched than the one statement that is current
> present.  From what is there, it is not clear to me that one would return a
> group if one of the resources of an endpoint in the group has the desired
> attribute.  However, based on everything else, it would appear to be true.
> Thus the search would be to go up the model (Figure 2) to all ancestor notes
> and down the tree to all descendent notes.  Is this a correct understanding?

That is a good point and an open issue[82], and indeed the
`/rd-lookup/gp?ep=node1` example contradicts the current text that only
covers going "up" in Figure 2.

I'm leaning strongly toward allowing both directions, ie. a query
parameter matches a candidate result entity if it matches on its
parameters or the link parameters of any of its containers or its
contents, transitively.

What worries me a bit is the performance impact of looking for possibly
matching resource attributes in any group lookup, but probably it
shouldn't.

> 7.  In section 7.3 - If doing a compound search criteria - Does all of the
> criteria need to be matched on ANY node in the search or ALL of the criteria
> on one node in the search?  Consider "?d=example.com&rt=foobar"  which would
> match the 'd' on the endpoint but the 'rt' on a resource.  So two questions
> - the first would be looking at two different items at two different levels
> (i.e. group and resource), the second would be two items at the same level
> (i.e. two different resources/endpoints which are children/grandchildren of
> me).

The quantifier sequence is "for each query parameter, there exists a
(suitably related) entity that matches the parameter". Each query
parameter can be satisfied by a different entity.

I don't fully understand the part after 'Consider', but
`?d=exmaple.com&rt=foobar` could give a single endpoint in an EP lookup
(which is the only endpoint to contain rt=foobar resources), but give
both its two rt=foobar resources in a resource lookup.

A query `?rt=foobar&rt=fnord` lookup could match on the endpoint lookup
interface (finding an endpoint that contains both a foobar and a fnord),
but might not give any result on the resource lookup interface if no
single resource has both types.

I'll try to make that clearer when addressing the abovementioned issue
of going up and down -- but did that answer your question?


Thank you for your comments
Christian

[82]: https://github.com/core-wg/resource-directory/issues/82
[85]: https://github.com/core-wg/resource-directory/issues/85
[86]: https://github.com/core-wg/resource-directory/issues/86

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom