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

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

On Thu, Nov 02, 2017 at 08:56:53PM -0700, Jim Schaad wrote:
> 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.  

I was envisioning a cluster where each node keeps the data registered
with the other ndoes in an eventually consistent cache; maybe I'll find
time to sketch that out a bit further before the meeting.

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

The example that's there is /rd-lookup/gp?ep=node1

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

I see. Both these questions (`WHERE ep.d=="example.com"` and `JOIN ...
WHERE group.d=="example.com"`) are, in the simple query language of
search parameters, expressed in the same way and returned as their
union.

We don't have a partitioning on the names to tell the intended query
apart. (d can be on both endpoint and group, and there's no registry for
link parameters so we can't rule out conflicts).

What we could do to mitigate that ambiguity is to make the query
language slightly more complext (so your endpoint queries might be
`?d=example.com&res→rt=foobar` vs. `?gp→d=example.com&res→rt=foobar`),
but that won't reduce the complexity but only make it more visible.

Do you think that the availability of search in both directions of the
tree is an issue for implementations (esp. distributed one), or is it
more a problem of specification or interface clarity that the meanig of
the query is not immediately obvious?

Best regards
Christian

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