Subject: [core] draft-ietf-core-interfaces-04

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 30 Mar 2016 19:01:16 +0200

Hi all,

I read through draft-ietf-core-interfaces-04. Overall, the document
raises a lot of questions and still needs lots of work. I wonder whether
this work has been adopted as a WG item a bit too early in the process
before enough experience has been gained with this type of
functionality. From an interoperability goal point of view I believe
this is exploring a territory, which I would call dynamic discovery.
Learning meta-data about resources offered by an IoT device is already
complex, particularly if one wants to do something with that data. Then,
dynamically discovering the interaction model is even harder.

The target audience for such a document are developers and, maybe even
system architects, who need to first understand the value of this
functionality. Currently, the document is IMHO only understandable to a
small number of experts due to the way it is written.

From the recent IAB IOTSI workshop I am wondering whether other solution
approaches are also viable or even more desirable. For example, Matthias
presented the HATEOS approach with
https://www.iab.org/wp-content/IAB-uploads/2016/03/2016-IAB-HATEOAS.pdf
that seems (in my limited understanding) tries to accomplish the same
goal. Michael described another approach in
https://www.iab.org/wp-content/IAB-uploads/2016/03/draft-koster-t2trg-hypertext-language-00.txt

https://www.iab.org/wp-content/IAB-uploads/2016/03/Thing-Description-as-Enabler-of-Semantic-Interoperability-on-the-Web-of-Things.pdf
describes the approach from the W3C.

While there is a lot of dynamic discovery happening without
pre-configuration but in the end, as these workshop position papers
illustrate, there is always some prior information that has to be
assumed. What is the level of pre-configuration needed with this
solution approach.

From a document status point of view this is a clear example of an
Experimental RFC. I am also not sure whether there is a normative
reference to SENML and whether WADL is the 'state-of-the-art' way to
describe the structure. What is purpose of the WADL in this document:
documentation, Code generation, testing?

I wonder whether we could spent some time during the CORE WG session to
discuss what goals we want to accomplish in the group regarding this
work and how to approach the topic overall given the work that has been
done so far. The suggestions Michael made in his status update to the
CORE mailing list regarding splitting the current document and getting
them aligned with the work in other organizations makes sense to me.

Ciao
Hannes