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

[Jim Schaad <[e-mail]>]

Peter,

In the current design it is easy for the RD to understand the remoteness of
an included endpoint, it would have a full URL to a different RD rather than
having a partial URL which resolves against the current RD.

That said, I am not in favor of the idea because of the searching problems.
I would rather just have a specialized synchronization API in a different
document.  (Which might be as easy as - I will publish any updates to the
following list of people.)

Jim


> -----Original Message-----
> From: peter van der Stok [mailto:[e-mail]]
> Sent: Monday, November 6, 2017 12:41 AM
> To: Jim Schaad <[e-mail]>
> Cc: 'Christian Amsüss' <[e-mail]>; draft-ietf-core-
> [e-mail]; 'core' <[e-mail]>
> Subject: Re: [core] Questions/Review on
draft-ietf-core-resource-directory-12
> 
> Hi Jim and Christian,
> 
> The discussion on a set of RDs is rather worrying to me.
> I do understand the remark by Jim that the end-points composing a group
could
> be stored on different RDs than the RD handling the group registration.
> The RD is not aware of the remoteness of the eps and the client has to
handle
> the distribution.
> It is not different from registering anchors to different hosts.
> 
> However, envisaging a set of RDs implies many protocols to keep entries
> synchronized and handle communication errors.
> I hope I misunderstood the intention of Christian.
> 
> Greetings,
> 
> Peter
> 
> >> 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.
> >