Skip to main content

Minutes IETF103: t2trg

Meeting Minutes Thing-to-Thing (t2trg) RG Snapshot
Title Minutes IETF103: t2trg
State Active
Other versions plain text
Last updated 2018-11-22


Chairs: Carsten Bormann, Ari Keränen

Note takers: Christer Holmberg, chairs
Jabber scribe: Francesca Palombini


Intro, RG Status (Chairs)

Upcoming meetings:
Work meeting on Friday
Regular WISHI calls
Virtual meetings with OCF
Virtual meetings with OMA SpecWorks (pending)
IETF #104 (Prague)
WISHI hackathon continuation planned
Co-locating with academic conferences 2019 (pending)

RESTful Design for IoT status
FETCH/PATCH method considerations and Caching considerations added.
CoRE Apps draft for more details on how to define IoT hypermedia apps in a
structured way. Addition of IoT details discussed at IETF #102 (Montreal)

Next steps:
Experience from building IoT systems with (constrained) RESTful+ methods
W3C WoT, OMA SpecWorks, OCF, IoT platforms,....?
More outside reviews (e.g., from micro service community)
Ready for publication by IETF #105?

Report from WISHI and Hackathon (Chairs, various)

Since IETF #102
Four web meetings, discussing different things (see slide 12).
Notes on Semantics and Engineering principles (upcoming). Will be collected on
the wiki — may end up in a draft.

Hackathon at #103
4th time; 8 participants (2 remotely).
Connecting different eco systems.
Improvement of existing applications (TD, RD)
Semantics to binary data, hypermedia safety for IoT (not protocol safety, but
usage safety — is it safe to perform an action, and how is that information
provided to machines etc making decisions) Learnings: Semantics is hard(er than
you think) Pre-setup and testing for hackathons helps a lot Potential new
research topics

Padhu Subranami: Similar work on semantic interoperability ongoing in OMA
SpecWorks Ari: good to have a look at this together

brief update (Michael Koster)

SSN Workshop at ICSW2018
Actions, events, properties terms are heavily overloaded.
W3C CG Charter
Integration with
Developer tools
How to apply definitions to existing device ecosystems and FoI
definitions Work on API automation Setting up infrastructure for community to

Upcoming teleconferences
Guest speakers:
Dr. Amelie Gyrard: Semantic WoT -- survey on how semantics are used across
industry Bruce Nordman: Device descriptions for energy monitoring

Hannes Tschofenig:  saying that this is not a new standard. Same as if would
put LwM2M in the center and map everything else there. Had a star in the IoTSI
report. Everyone is saying they are the big star but not another standard.
Creates unfortunate situation, have in CoMI, that we do add another standard
that fragments the ecosystem. Ecosystem that focuses on standards based
solutions should have more collaboration across SDOs. Enemy is not another
standard rather than proprietary solutions. Better if we use what we have and
make best out of that. There's long list of data model standards that no one is

Padhu: Do you see the need to have multiple interoperability
mechanisms/definitions, or is it possible to use a single one?

Michael Koster: not making monolith, idea is that people from different app
domains can bring their own definitions. First time around was serialization
and tools. Also semantic categories. We want to find things that are common.
Have discovered that all standards do same thing; turn on light, set
brightness, etc. Hope to normalize based on semantics. In workshop we had
stars, discussed adaptation, normalization, translation. Need to support all of
those. Trying to bring things together and have new layer -- not competing on
same level of standards.

Zach Shelby: going to be controversial. As Internet engineers want to control
all bits and pieces. Recently started working with data scientists. All
millenials. Math people. Work with Python. Look at data in completely different
ways than we do. I see some warning signs on how people have to make use of the
data we generate. What tools they use. Use machine learning etc. Eventually
what matters it that someone can generate value out of the data. Data
scientists don't care of exact semantics. Dump all in big table and they'll
figure it out. Useful to have documentation of the semantics, where it comes
from, is it trustable. But don't care of every bit of information. Think that
big data collection and interpretation are different problems.

Michael: asking for in review of semantic categories to have data plane and
control plane separate. People who work on data can use just the semantics of
data. Have simple hints; not full ontology. Useful to have standard to not
worry about interaction model and just deal with data.

Zach: good point. Difference between control and data plane. Have been throwing
our tools to data scientists, showed SenML and they were impressed how much
information we have, units and all. So might not want to put the bar very high.

Dave Oran: how about interactions, as opposed to data? Interactions become data

Zach: need documents to explain how they relate. There ontologies maybe make
sense. But that's more for humans. New thing that has not been taken into
account. Big data has been main focus. Don't know the answer, so good thing for
the RG.

Matthias Kovatsch: don't see any conflict between what Zach said and what
Michael presented. Idea here is that you annotate small pieces of information
so that they are useful for data users. Not doing full world.
example where share small pieces of information annotated so that search
engines can make sense of that. Closed world assumption: just to identify and
know what we agree on and do operations on that information.

Carsten: many things you can do with IoT. One thing data gathering. Tools for
gathering inconsequential. Different area than what discussed on Saturday.
There might be actuations also that have significance, so should not get them
wrong. For example, get many calendar invitations by mail. The AI in the mail
program can also make appointments from plain text. Useful, but sometimes gets
wrong. Still need human in the loop. The direction we need: make easy for
developers to use data that may have high consequences.

W3C WoT update (Matthias Kovatsch)

Status update:
WoT mission & deliverables: e.g., architecture, TD, scripting API, security &
privacy guidelines TD Overview: Semantic annotations, data schema, hypermedia
     Enables powerful tools such as SPARQL queries
   Recent changes: features (event parameterization, URI templates), term
   alignment, new terms
W3C WoT Roadmap
W3C WoT workshop planned for May, to discuss the future work (new features etc)
Features under discussion
URI template abstraction - how far should it go?

Shu: How do you add a device identifier to a TD?

Matthias: we define ID field and you can put any URN/URL there. Gives you a
unique ID usable also in semantic web. Also plannning for model number / serial
number kind of construct.

Shu: but URL can change?

Matthias: here use URNs, names that can not be automatically resolved. Draft
from Jari Arkko on device URNs that is the best candidate on how to do that.
Only the identifier, not locator. There are mechanisms similar to CoRE RD to
resolve. How to discover TD is not defined. Can take most of the solutions from
CoRE WG to do discovery of TDs.

Shu: hard to build uniform platform for resolving the IDs?

Matthias: at Siemens do lots of prossional building systems. Many systems that
need to interact. Need consistent view of the system, e.g., for diagnostics
queries. But need to figure out what other things are needed. Currently for
integrators primarily. WoT has been very helpful.

core-apps, CoRAL — take on as RG documents? (Chairs, various)

CoRE Apps is a way to describe hypermedia driven applications. Alraedy
referenced by RESTful Design draft for guidance on defining hypermedia apps.
Planning to adopt as RG document.

Working on CoRAL in IRTF and IETF. Have used link format for representing link
information, but maybe useful to use CoRAL instead since it has more

CoRAL - The Constrained RESTful Application Language. Draft by Klaus H.
Hypermedia representation format for the hypermedia model descibed in
draft-hartke-core-apps Can be also used for composition. When have small amount
of information, more efficient to provide information in the file itself rather
than a link. CoRAL makes this efficient and clean. Concise form instead of
compression (that might be hard for most constrained devices). Content Data and
interaction model Compact, binary format: the interchange format. Main
deliverable. Lightweight, textual format (easy to read by humants) for
discussions and design. But have dangers, like hand-made examples that don't
really conform to the structure that would be present in the binary version.
URIs in CoRAL are IRIs. In binary format CIRIs: pre-parsed format.

Zach Shelby: looking through CoRAL. Was thinking "yet another text format". Why
can't use HTML5 links? "Forms" the answer? Why can't use actual text link
format that could be used to convert from/to CoRAL. Bigger web world would
benefit from a CoRAL-like thing.

Carsten: one of the submissions to IoTSI WS had title "Semantic noise hurts".
Since textual language is only for examples, is optimized for the purpose. JSON
and XML formats had the problem that could not reuse that. Always needed a
tool. Some time later RelaxNG was designed: compact syntax was defined. That's
the model we often have in mind. And the model that guided this design.

Zach: but why we couldn't use existing format? And make it useful rather than
inventing a new format only for text representation. Don't have to be pretty.

Carsten: link format a way to do that

Zach: can't HTML5 links do this?

Carsten: HTML5 has lots of other problems. And really presentation language.
But good research problem. Can you come up with HTML5 version that can be
written on whiteboard?

Zach: when working with RFC 6690, lots of effort was spent to work with web
guys. Don't see the two worlds as separate. Would be good to have a look did it

Matthias: I had big hopes that TD links part could use link-format JSON. And
JSON schema and others. Now hear that it's going to be own format. There will
be some JSON format that describes this. And we have these forms here. JSON
representation will pop up. And need to have translators.

Christian Amsüss: Make sure that all that can be expressed in CoRAL can also be
expressed in RDF. Could roundtrip to anything that can be captured in RDF, like

Matthias: In TD tried to combine links with JSON-LD. Hard work there.

Carsten: Coral->RDF->JSON-LD conversion possible

Matthias: JSON-LD underlies lots of expectations, e.g., that it's all triples

Carsten: JSON-LD really attempt to smuggle RDF to JSON minded people.

Matthias: maybe expect JSON-LD be full represention with triples. Can attach
meaning to existing JSON format. Can attach meaning that goes to machine
intelligence systems. Have interference compatibility.

Carsten: please all read the CoRAL draft, have all the information there. If
CoRE WG decides to pick up the work the binary one would be the normative. Also
good for the group to understand how CoRAL can be used for RD and pub/sub
broker. The RG should look at the wider use of CoRAL. How can be used for new
applications and do the translations. Form relations not yet fully defined.

Intro to Friday's work meeting (Chairs, various)

Agenda (slide 64)
Plenary Edge Computing discussion teasers:
Problem statement of IoT integrated with edge computing
EC an emerging technology in IoT
Use cases of EC in IoT video demos
Computing at the edge
Look at EC from a compute perspective to determine the network needs
What would it mean to deploy cloud applications (containers, VMs,...) at the
edge. Automated IoT security Enabling network access for IoT devices from the

(meeting ended)