Minutes IETF105: t2trg
minutes-105-t2trg-00

T2TRG IETF 105

July 24th, 2019

Chairs: Carsten Bormann, Ari Keränen
Note takers: Ana Minaburo, Laurent Toutain, chairs

13:30 Chairs: Intro, RG status, upcoming meetings and activities

* No comments on the agenda

13:45 Chairs: Report from WISHI, Pre-IETF meeting with OMA, Hackathon, and
Morning side meeting

* Recent Activities: Hackathon, friday meeting and side meeting for CoRE
applications * After summer interim meetings will be continued, there is no
schedule right now * If there are good opportunities co-locating with academic
conference please tell chairs * Singapore meeting is a way to collaborate with
the local community such as the Singapore Smart Nation project * RG Doc Status:
IoT security draft is published as RFC RFC8576! * RESTfull design for IoT
updated to provide more references and details on server push, addition of
affordances and CoRAL details planned.

* Secure Bootstrapping is a key challenge identified by RFC8576; to be
discussed in the IoT security bootstrapping draft. Contact the authors if you
are interested to collaborate on this.

* WISHI virtual meetings focusing on hackathon and research agenda, moving
forward with 6 topics areas * Interested in modeling data, in the connectivity
area, and security and terminology * WISHI HACKATHON -- two focus areas: 1) IoT
data Model convergence and binary data extraction 2) IoT and hypermedia --
using One Data Model (OneDM) for model interoperability and convergence -- tool
available on line and in github -- Implementing SDF schema in CDDL -- New
proposal for JSON format of Coral -- Binary data extraction, Ivaylo will
present after -- Brewing coffee with hypermedia: looking at the old challenge
of automated coffee making with new tools and techniques. Used CoRAL for
describing the coffee machine with hypermedia. Now two open source
implementations using CoRAL and CoAP.

* Friday meeting with OMA
-- A good day meeting with tutorials and presentations of the OMA protocols and
data models. -- presentations are available in github.

No question from the room.

13:50 Michael Koster: Activities on data model convergence; W3C Community Group
on Schema extensions for IoT; schema.org update

* Extended schema.org for IoT semantics
* Open access to the models that will be developed
* Connect semantics to the description
* focus on sensors and actuators
* Based on properties, actions, and events (events can be asynchronous)
* Meta-model for interactions with properties (R/W) and parameters to do
actions and get a response * This is a meta model with capabilities to control
and provide functions * A capability interacts with an action, event or
property to get a data * This model can use other ontologies * prototype
definition in JSON-LD * Provides application layer vocabulary, and explains how
the operation function is used to express the semantic properties * There is a
submission process, if there is an interest to do a semantic description you
can submit it * Monthly teleconferences, tomorrow is for July * One Data Model:
SDOs and vendors don't want to compete in this space, need for convergence ->
common definition language -> semantics only, not an API description -> Swagger
and W3C WoT Thing Description can be protocol bindings for OneDM * Example of
JSON: same kind of definitions as in RDF but using JSON * Development of this
language is open. Welcome github issues on this. * ODM can be a link to
industry to help to developing descriptions to build Data Model representations

14:03 Michael McCool: W3C Web of Things WG/IG update

- Update
* Interest group and working group in W3C
* 2 documents: Architecture and Thing description published
* WoT is architectured around Building Blocks to create the WoT Architecture
* Scripting API for the use case to make easy to orchestration
* Security Actions and Schemes
* Different levels: Notes (informative) and REC (Normative) Track
* Information Model and representation for the metadata

- Architecture
* TD (thing Description) to describe the different capabilities
* Door handle is example of an affordance. Want to do a certain thing, "open
door". Different kind of handles to open and need to describe how to use the
handle. * Using JSON-LD 1.1. Much more usable than JSON-LD 1.0 (that was
designed purely for RDF). * The description has the IoT prefixes and the
structure LD 1.1 * Interesting to see how SDF and this works together. Compiler
could take SDF and compile it to TD with right kind of semantics. SDF and TD
are complementary mechanisms. TD attaches SDF to protocols and data schemas.

* Adopt JSON-LD 1.1
* Security meta data declares security mechanism
* Extensible mechanism to add options, and interactions with different levels
* Aligning the Schemas
* JSON schema is widely used

Dave Thaler: on JSON schema, closest thing is json-schema.org; web page states
"Forthcoming draft in final review". Michael: Yes, correct it is a draft, but
to extend to CBOR we used to describe JSON. The draft has expired, but many
organizations need it Carsten: anecdote: the JSON schema IETF draft -04 is used
as basis of appendix of doc that is getting done in security incident handling.
Also CDDL version. Newest versions of json-schema.org are submitted to IETF,
but have to check out which one to use. Michael: The draft has been refreshed
Carsten: but might be expired also Michael: We need to look at  the problem and
get more standardized solution. JSON schema is not perfect, but it's widely
used.

14:18 Ivaylo Petrov YANG Object Universal Parsing Interface
draft-petrov-t2trg-youpi

* Hackathon discussion about interoperability for the very constrained devices
and networks * binary formats are often used by these devices. To allow
interoperability, it is important to understand the data. YANG is a way to do
data modeling, and here is an attempt to use it to parse binary data. * can do
semantic annotation of the data, in YANG the parsing logic is included
(position, etc). Can read the binary data and produce JSON. * A playground is
implemented where people can submit their data. Info and links in the wishi
wiki page: https://github.com/t2trg/wishi/wiki/IETF-105-Hackathon#youpi * if
there's anyone interested and have some use cases, we can work together, and
get feedback

Carsten: on steps forward, second item is important: need to try tons of
examples. Very useful to have examples of Modbus etc. If have achieved certain
level of validation, this would be nice thing to go forward with. Laurent
Toutain: is it bi-directional? Ivaylo: yes, that is the idea Carsten: RFC 4997
(Formal Notation, https://tools.ietf.org/html/rfc4997) (for historical
perspective). Many questions that come up here are similar.

14:25 Christian Amsüss Transports for CoAP: new URI schemes of CoAP protocol
negotiation

CoRE WG has promised to deliver a URI scheme (and related mechanisms) for CoAP
over all the transports - SMS done based on OMA inputs and existing draft -
Single Scheme for all transport avoiding the URI aliasing - Need input. Inputs
are welcome in the different approaches on the github
  see  https://github.com/t2trg/transports
Carsten: Nice example of how to organize work, can use the RG repository for
free. It is an informal way to share and has what is necessary.

14:30 Dirk Kutscher: Why Edge and IoT will never happen!!

* IoT and Edge Computing are buzz words. Wide terms and need to be more
specific to talk about anything meaningful. * computing will be different in
different area (IIoT, agriculture, etc.) * Relevant use case from industry,
where computing and programming function is needed: virtualizing a Data Center.
Good to ask "where's the research here". * Identify interesting research topic
* The technical criteria is important, talk the same language, what do the
different terms means for each one Technical properties needed - interaction
model - what is edge computation: interception, CoAP request response? - how to
program - security and trust model

* These question are to be asked from the beginning
* ETSI Edge computation diagram: simply cloud computation on edge
* Often people mean with "edge computing" just doing something on the gateway
* Edge computation is extending the cloud to the edge and apply the same
technologies and concepts and also the same trust anchor. * Dependencies are
important to describe what we want * What could be interesting from T2T
perspective: we want to talk about computing with / for things. Don't want to
enforce centralized infra. For IETF, we have developed CoAP that is nice
example of a protocol that is rather minimal on complexity but can provide
different building blocks that enable different scenarios. Simple req/resp,
pub/sub, etc. Doesn't solve all problems but is really flexible. Interesting
approach also for computing with things. * Interesting directions:
    - decentralized secure computing from the beginning; not just bound to
    clouds
* In the cloud computing is cheap, overlays abstract node to node network
- But need additional infrastructure to find things, functions, and secure
objects - do not do overlay but integrate computing. - An interesting use case
about function off-loading data or triggered execution * Discuss in the
research group, what are the research question that are not already solved.
Where's the uncharted territory. What are the interaction and computation
models. Do we need to agree on execution model or APIs.

McCool: additional challenge for edge computing distributed is the security
model. How to run untrusted code on untrusted platform. How will that happen.
Will be techs to do that but need to manage the trust. How do I trust platform?
Which platforms / code sources can be trusted. Carsten: Reputations are
important. Interested in this context; one word that is said 50 times already:
events. Event happening, what do we do now. Only one event happening is not a
problem but when several happen, need something like the custody transfer. How
we run this in environment where we are not sure if they are going to work.
Reputation not just past behaviour but also how thing in its "thingness" will
act in particular environment. How to structure systems. We know most IoT
systems are not really engineered. Smart cities and homes will evolve over
time. Storage problems on where we put the data etc.

Eve: loved the talk. Liked about the pillars, or areas where to target. One of
the questions echoed next presentation: many building blocks but which are most
appropriate. That sit squarely in our domain. Need to think of that. Also edge
computing is completely misnomer. Not just computing but re-imagining data
center. There are requirements that far-away DCs can achieve. Which of those
are in our domain to work on. Also edge is part of continuum. Could be on thing
or in DC (or in between). One building block could be: edges and clouds are
collections of things. Could be federation of things. Protocols that federate
this is something I'd like to see.

Dirk: notion of re-imagine -- was wondering if we should start little bit
small(er). Eve: sure, edge challenges the "IoT == constrained devices". Could
talk about the very edge. May not provide all functionality of DC but for
example some storage. Focused on one and think about what those localized needs
are.

Hannes Tschofenig: Mentioned that there are activities ongoing in different
standards organizations. Different approach: look at deployments from folks in
the room, more an applied computer science approach -- what worked, what
didn't. Collect that input, may have interesting areas of investigations that
can feed back. Just talked to someone, probably 5 other companies in this room
that all have solutions (Microsoft, Amazon, etc.).

Carsten Bormann: Term "constrained" has been useful. Just have to think about
it in different sense than last 10 years. Talking to electrical engineering,
they look at me with large eyes when I say "constrained" because "all
engineering is within constraints". In Things, still have lots of constraints,
e.g., significant energy constraints, in levels of affordable protection,
levels of attention they can get etc. Set of new interesting constraints here.
Understanding them will help us from "redoing all the container stuff" to "what
do we need to do to make this a really significant part of reality".

Dave Wheeler: from Intel, talk with Eve quite a bit. Like what said about
constraints, but what trying to do with edge computing is taking those things
with constraints and construct computing capability near those without those
constraints. In DC compose things to platform on the fly. Have protocols and
security to do that in trusted way. Want to move compute but doesn't have the
GPU to do AI, will combine that with storage because it's convenient. That's
what want to do with edge. "Move DC to the edge". Big vision but can start
small. Let's look at the questions on the presentation and have a look at those
one by one.

Dirk: I'm familiar with these models; one task is constrained things for
gateways, not to ossify on the edge GW

McCool: building blocks approach: emerging properties. Data access mechanism
may not mean anything alone. But together with others could be privacy risk.
Can't necessarily compose things nicely. When look at the application have
additional constraints. Can't migrate computation across national boundaries
for example. Dirk: Yes

Michael Koster: We look at this commercially, and differences, and have a data
model. Appreciate what you say on edge vs. computing on the network.
Decomposing application functions to scenes / modes / routines. There is
semantic interop around "functions" and little elements of computation, and
elements of sensing. Dirk: sounds very cool

15:03 Yong-Geun Hong Problem Statement of IoT integrated with Edge Computing

History and major updates:
* presented in IETF 103 and showed 2 demos
* in IETF 104 Positive feed back that this should be done in the T2TRG; changed
draft name to reflect the real subject

Document is integration of a survey and gap analysis draft
- separated cloud and edge computing
- changes in the structure of the draft to give a more clear description
- includes lots of information and examples in the appendix A
- the gateway architecture does not cover all the edge computing but only a
particular way of doing edge computing - provides different edge computing
approaches

- Ask if this document can be adopted?

Carsten: are you planing to do another revision?
Yong: In current draft only edge GW based suggested. Also have discussed that
should provide other models. Also current kind of environments.

Carsten: who want to review the draft?
- Hannes
- Laurent
- Robin
- Michael & Michael

15:11 Yong-Geun Hong Edge IoT demo

* Large cloud companies have interest in Edge computing
based on EdgeX (open source project); provides a mapping between implementation
and architecture. * A 3 part scenario: sensing, device, computing * Provide
"intelligence": preprocessing, prediction, analyse, and control * trained in a
cloud network and implemented in a edge * Define "normal" and "abnormal" *
Normal may be a way of having the system working without any output noise *
Abnormal may be how the system reacts when there is output noise (error,
disruptions, etc) that makes the prediction and processing different. * What is
the prediction to make something, in each case how the system may detect an
error to make the correct prediction. In each use case the architecture
proposed is used

Yong shows the implementation they have done
Yong: opinions or comments?

Ari: A question about the data model: is that something home grown or a
standard? Yong: we are using JSON model which come from edgeX Ari: would it be
possible to use SenML? Would be interesting to give that a try and learn how
well it works and perhaps what could be improved Yong: EdgeX open source
projects, not a standard. I will try to contact to see if we can collaborate
with them

Carsten: Noise sensor is faster than temperature sensor, better for demo.
Someone should write a paper on what are good sensors for demos.

Carsten: something that also learned last Friday with OMA was that having 60s
min time for re-registrations may be very bad for test cases

McCool: would like to see standard ways to describe edge services and do AI.
Interesting standards related like ONNX. AI is especially interesting since not
Turing complete. Interesting way to deploy services with. Also how we extend
discovery mechanisms.

Bhumip Khasnabish (from jabber): why do you use Kafka?
Yong: Because Kafka was reliable for the demo with MQTT wireless

Eve: would echo McCool on discovery but one of the objects interested in is
data. Computation everywhere data gets scattered. Need mechanisms for existence
etc. Room for discovery mechanisms for objects like data.

McCool: edge as microservice model. Allows things like series transfers and
access control. Important to consider. Eve: was commenting also Dirk's
presentation; things put into this draft more problem statement, add a building
block to to find objects.

Carsten: like the Kafka question. Couple of hackathons ago was something demoed
that went to XMPP. Tried to build something with XMPP and in the end said
"screw it, we'll just build it with Kafka". We have interesting disconnect on
why not using standards here. Need to work on aligning realities on what you
can plug together. Open source projects and standards that can be plugged
together. Computing for things has high integration aspects.

(meeting adjourned)