Subject: [core] 🔔 WGLC for Resource Directory

From: Jaime Jiménez <[email-masked]>
Date: Thu, 21 Mar 2019 16:32:44 +0000

Dear Core WG,

This is the WGLC for the Resource Directory draft.

Both authors and chairs feel that the document is very mature at this point, it has gone through many reviews, interops and it has gathered sufficient feedback from the group.

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.

The draft is available at https://tools.ietf.org/html/draft-ietf-core-resource-directory and the working copy is at https://github.com/core-wg/resource-directory

During IETF 104 some of us will also meet at the hackathon to test our implementations; you can find (and join!) us during hackathon ours at https://jitsi.tools.ietf.org/rd-interop

Best Regards,
Jaime Jiménez

---

From: Ted Lemon <[email-masked]>
Date: Mon, 25 Mar 2019 14:06:04 +0100

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

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.

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.

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!

---

From: Ted Lemon <[email-masked]>
Date: Mon, 25 Mar 2019 14:09:52 +0100

Another thing to add here is that the spec also proposes using RA or DHCP to tell the client what RD server to contact.   However, in practice it appears that different IoT frameworks use different RDs.   If it is ever going to be the case that more than one IoT framework is in use on the same link, which I suspect is likely, then a method for differentiating between these is necessary.   This means that whatever is offered by DHCP or RA would need to have server address/tag pairs, rather than just addresses, with the tags used to select the RD server based on the IoT framework that is in use by a particular device.

> On Mar 25, 2019, at 2:06 PM, Ted Lemon <[email-masked]> wrote:
> 
> On Mar 21, 2019, at 5:32 PM, Jaime Jiménez <[email-masked] <mailto:[email-masked]>> wrote: