Re: [core] 🔔 WGLC for Resource Directory

[Ted Lemon <[e-mail]>]

On May 22, 2019, at 5:03 AM, Peter van der Stok <[e-mail]> wrote:

Thanks for getting back to me—I know that there are a lot of demands on our time, so there’s no need to apologize for being asynchronous! :)

>> 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 problem with this approach is that as an implementor, I have no idea what to do.   If you aren’t solving my problem, then you should explicitly say that you aren’t solving my problem, so that I’m not left wondering. :)

However, to be clear, I am not really suggesting that you say nothing.   I am suggesting that we figure out what the correct thing is to say, so that implementors are not left guessing.   There is a huge problem in the IoT space with solutions that use existing standards in incompatible ways, so that even though everybody can say “we’re standards compliant,” there is no interoperability. 

If this isn’t addressed in IETF specifications, it’s unlikely to be addressed anywhere, because the IETF is the only place I know of where general interoperability is an explicit goal.   The issue is that each individual IoT stack vendor is happy to simply have their own infrastructure solution that interoperates with devices that implement their stack.   But as a network owner, I may either choose to or be forced to install devices that use different IoT stacks on my network.   The network infrastructure standards, of which Core RD is clearly one, should support each stack I need to support, and not require that I implement separate infrastructure for each stack.

I think pointing to the core-rd-dns-sd document isn’t a bad thing, but I don’t think that document actually does what you think it does, so there may be some new expectation-setting exercise required.