Re: [core] 🔔 WGLC for Resource Directory

[Ted Lemon <[e-mail]>]

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 <[e-mail]> wrote:
> 
> On Mar 21, 2019, at 5:32 PM, Jaime Jiménez <[e-mail] <mailto:[e-mail]>> 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.
> 
> 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!
>