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

[Jim Schaad <[e-mail]>]

> -----Original Message-----
> From: Christian Amsüss [mailto:[e-mail]]
> Sent: Thursday, November 2, 2017 2:27 AM
> To: Jim Schaad <[e-mail]>
> Cc: [e-mail]; 'core' <[e-mail]>
> Subject: Re: Questions/Review on draft-ietf-core-resource-directory-12
> 
> 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).

I really like the idea of being able to have entries in a group be on a
different server, right up to the point where I start trying to implement
the search algorithm that you have specified.  At that point my code is
suddenly making lots of potential queries to the other RD in order to find
out if some parent/child is going to have the attribute that I am looking
for.  

> > 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.

It's interesting, I was sure there was an example along the lines of

GET /rd-lookup/ep?rt=temperature-c

But I don't see it there now.

> 
> > 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.

It would be clearer if I said I was looking for a group or an end-point with
these parameters.  I probably should have used something other than d= to
something that was clearly only set on a group.

> 
> 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?

Yes, I think I understand the current desires.

Jim

> 
> 
> 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