Re: [core] 🔔 WGLC for Resource Directory

[Peter van der Stok <[e-mail]>]

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 <[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.
> 
> <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 [1]].  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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/core
 

Links:
------
[1] https://tools.ietf.org/html/rfc6763