Re: [core] 🔔 WGLC for Resource Directory

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

Hi Ted,

The central phrase being:
"The problem with this approach is that as an implementor, I have no
idea what to do", I like to elaborate a bit my view.

For me it is not an implementation problem but a box configuration
problem.
Let me cite two not completely fitting analogies: the plethora of YANG
modules, the plethora of communication standards.

Dependent of the type of router (home-net market or ISP market), the
router is configured with a set of YANG modules.
A smartphone, PC or tablet is equipped with a an appropriate set of
communication interfaces.
Interoprability is assured by the implementer for a given interface or
YANG module.

Going back to the RD. Interoperability is assured by the implementer for
a given discovery method.
SDOs (e.g. Faihair, Thread, OMA, and others )currently specify and
certify Internet stacks based on a selection of IETF standards. This
selection partially determines the set of appropriate discovery methods.
Actually, the SDO may select the RD being part of that stack and also
specify the required discovery method.

Does that make sense?

If so, should I mention in the text that a selection of supported
discovery methods for a given RD configuration may be specified by a
SDO?

Cheerio,

Peter
Ted Lemon schreef op 2019-05-22 15:51:

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