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)