Re: [core] 🔔 WGLC for Resource Directory

Dear Chairs, RD authors, members,

Thank you for raising this point concerning section 4 of CoRE-RD draft.
Indeed, besides the diversity of options, there are also performance
issues, especially with the CoAP resource discovery approach. To deal with
this, we have proposed a new announce-based mechanism to discover RD
server(s) [1]. Section 1.3 of [1] points out some potential shortcomings of
section 4 of CoRE-RD and motivates the need of an announce-based mechanism
that can be generalized to announce other links (please see the discussion in
[2]).

[1]: https://tools.ietf.org/html/draft-djamaa-core-proactive-rd-discovery-00
[2]: https://mailarchive.ietf.org/arch/msg/core/s8bjwXJeipCm2PNkE_mS16GGBFw

All the best,
Badis

On Wed, 22 May 2019 at 11:04, Peter van der Stok <stokcons@bbhmail.nl>
wrote:

> Hi Ted,
>
> thanks for your comments, and apologies for the late reaction.
> Some discussions were needed.
>
> please see below;
>
> Greetings,
>
> peter
>
> Ted Lemon schreef op 2019-03-25 14:06:
>
> On Mar 21, 2019, at 5:32 PM, Jaime Jiménez <jaime.jimenez@ericsson.com>
> wrote:
>
> Please take some time to carefully review the latest version and provide
> feedback by *2019-04-17* , specially those of you that contribute to
> other organisations that make use of some version of the document.
>
> Carsten asked me to look at the CORE server discovery text.   It mostly
> looks good, although I don't understand why there are so many options.   If
> the intention is to have different profiles for different types of
> constrained networks, it would be good to say that explicitly.   It doesn't
> make much sense to pre-configure *devices* to discover the resource
> directory using different mechanisms.   If that is really what is intended,
> then how this is going to be managed should be discussed.
>
> <pvds>
> The intention is not to specify a set of normative profiles but to guide
> implementers and users of the resource directory, dependent on their
> installation. The text can be used to check the presence of at least one of
> the mentioned facilities before installing and using a resource directory
> in a given installation. We think this text is helpful because
> installations can be very different and many bundary conditions need to be
> satified in, for example, a building control installation.
> The text of section 4.1 is proposed to be:
>
>   A (re-)starting device may want to find one or more resource
>    directories for discovery purposes.  Dependent on the operational
>    conditions, one or more of the techniques below apply.  The use of
>    DNS-SD [RFC6763] is described in [I-D.ietf-core-rd-dns-sd].
>
>    The device may be pre-configured to exercise specific mechanisms for
>    finding the resource directory
> </pvds>
>
> The text about DNSSD is somewhat problematic:
>
>
>    3.  It may be configured to use a service discovery mechanism such as
>        DNS-SD [RFC6763 <https://tools.ietf.org/html/rfc6763>].  The present specification suggests configuring
>
>        the service with name rd._sub._coap._udp, preferably within the
>
>        domain of the querying nodes.
>
>
> DNSSD works by first enumerating services, then choosing a service from
> among those services, then connecting to that service.  It looks like the
> idea here is that the default server name will be "rd", but that isn't
> stated explicitly.   Some discussion about how devices are suppose to
> choose between advertised RD servers is necessary here.   If the intention
> is that only one RD server ever be present or discoverable, then you could
> say that enumeration is not done at all, but then this isn't much different
> than just using DNS to resolve the hostname.
>
> <pvds>
> We intend to broach this subject in the rd-dns-sd draft. Point 3 in
> section 4.1 of RD draft is therefore suppressed.
> Indeed the procedure for discovering a dns-sd service is the one you
> describe.
> Extra text is needed in rd-dns-sd draft to cover the case that not only
> the services described in the RD are discoverable via DNS but also the RD
> itself.
>
> Thanks for pointing this out
> </pvds>
>
> Based on the discussions that I've had in certain other standards bodies
> on how to use Core RD, I think that leaving this very loosely specified is
> probably not the right thing to do.   If in fact the intention is that
> other per-network-type specifications will decide how Core RD servers will
> be discovered on networks of the type discussed by those specifications,
> then this document should be written to explicitly support that use.   If
> this is the case, what is said here isn't general enough.
>
> I'm writing this with the goal of starting the discussion, rather than
> saying what needs to be said, because I haven't been privy to the
> discussion that led to the text as it is written in the current document.
> It would help to understand what the authors/wg had in mind when this text
> was written.
>
> Thanks!
>
> Thanks,
>
> Peter
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>