Thursday, July 16th 2020, 14:00-16:00 UTC
Chairs: Carsten Bormann, Ari Keränen
Carsten gave intro to T2TRG & IRTF. Major part of the agenda today: industry updates. In addition two longer talks before and after. WISHI calls are happening regularly (~monthly). Next one during IETF week on July 30th. Co-locating with academic conferences taking a break now. Maybe have to do something online.
Notes from the WoT meeting: https://hackmd.io/@rZ9WNHJ6TqOz-lqUmJbbfA/SJVqXysnU
Michael McCool (MMC): Active discussion ongoing around hypermedia controls in WoT, relates to dynamic vs. (mostly) static TDs. See for instance https://github.com/w3c/wot-thing-description/issues/899
MMC: Of course things like discovery etc. are also ongoing. More details in the WoT status update and F2F summary at the end of this call.
Followup to work presented in Singapore. Semantics driven connectivity. Bringing Detnet working to W3C WoT. Mainly wired technologies. Related to TSN standardized at IEEE. Requires detailed network configuration -- not just plugging in a cable. Centralized model used based on YANG. NETCONF the most common method for configuration available. OPC UA interesting and relevant technology here. Mostly used for management and configuration, but ongoing work to cover also controllers and end-devices in the field. To enable real-time apps, integrating with TSN. The OPC UA model is roughly similar to the web but some differences, e.g., bidirectional references and using things like bitmaps. Devices are provided with Thing Descriptions and annotations of device properties (e.g., speed) and these can be combined with QoS features. Application can request network configuration suitable for the case. Scheduler app makes configuration and pushes to network devices. Vocabulary of QoS; would like to followup with semantics folks and other folks using QoS. Would these apply also to other technologies? OPC UA was mapped to properties, actions, events. For data schema, JSON schema needs to be further annotated. No content type yet registered; working on experimental one. NETCONF binding was built on RESTCONF. Data schema has XML based features not supported by JSON. Need extension for the schema. In complex structure send some fields as attributes. Proof of concept using real equipment: robot flipping blue bolts. Running in TSN and uses WoT technologies for configuration.
MMC: any computer vision components here?
Matthias Kovatsch (MK): No UI for supervisory logic but separate tech, like digital twin
MMC: edge computing and AI looked at WoT may be applicable here
MK: .. have opens sourced code. For details, stay tuned for paper to be published in September.
MMC: roadmap for standardization? IETF or W3C WoT?
MK: open github issue for protocol bindings; planning to put pre-print on archive website and contribute from there. Currently not pushing to IEEE. Busy with other extensions.
MMC: WoT protocol bindings next step?
MK: yes, OPC UA interest. Started with client-server. Node OPC UA doesn't support pubsub yet. Working with C implementation now.
MMC: data modeling problems you ran into. We should revisit JSON Schema improvements.
MK: if have maintenance thread for schema, please point out. Good to solve these.
Carsten gave intro to segment (see slides).
We like to uncover technical issues and in particular research challenges. For example what discussed in Matthias' presentation wrt data models. This time covering many groups, next times maybe more focused on specific items.
(skipped, see below)
Project CHIP; players in smart home got together at Zigbee Alliance to bring IP protocol networks to smart home. Being done code-first approach. Open source repository to look at what has been contributed by different companies. Lots of code from Silicon Labs. Zigbee opening their data model. Cluster library published using BSD3 license. Now in XML but will talk later about ways to transform that. Not restricted to smart home. It's about certifying devices. Not network standards as we talk at IETF but conformance and interoperability. Whole stack approach using pieces from where ever we can get them. Currently debating incorporating CBOR instead of TLV, for example.
Also came out from Zigbee meeting late 2018. Organizations got together and listed issue: lack of common data model was major item. The liaison group was started to look at the problem. Already definitions of switches and door locks that we could adopt? But many of the models not that easy to adopt. Group decided to create a common language and metamodel to express the models and drive convergence. Instead of choosing single model became effort to drive convergence across industries. Language to build semantic definitions. Aligned with work at iotschema. Can be used with WoT TDs. Taking advantage of common alignment of models.
We have now language that we think is stable enough to create models. Have now about 200 models mainly from OMA and OCF but also Bluetooth, Zigbee, etc.
We didn't want the data models carry intellectual property with them. Wanted orgs to publish under BSD3 license. Phase two would be to provide common area for consolidation. Since everyone has agreed to use BSD3, we are opening up the group for everyone to publish. Will keep liaison structure just for organizational reasons. Open for business. We don't have all policies in place yet but want to invite people to collaborate and bring new models and develop the language etc.
MK: PCHIP question; is there a proper name?
MJK: calling PCHIP, but just WIP name. Will be actual brand name later. Huawei now also member there. There's open source repo. Can send pointers.
CB: will return to OneDM in the ASDF BoF segment. Can have more questions there.
About to release 1.2 of LwM2M spec. Works in application layer. Previous version was CoAP & UDP. Now being more transport agnostic, MQTT and HTTP needed in some use cases. New optimizations for bootstrap, registration, and info reporting interfaces. New LwM2M gateway feature that enables to manage brownfield devices. Also publishing new encoding format, LwM2M CBOR. New notification attributes and work on security layer. Also, when growing, have to figure out how to do versioning; getting more clear on that now. Leshan and Wakaama the reference implementations. Easy way to test and do hands-on.
IPSO fits at the data model level. IPSO group is working with the OneDM liaison group and has contributed all the models to the playground. IPSO has published a number of objects and reusable resources (see examples in the slides). Encourage new objects to use reusable resources when growing. We want to create objects that can work with LwM2M but also want to follow the broader industry. OneDM very interesting for this. Want to find a broader consensus on data models. Have published some tools and open source projects that can use to create and validate IPSO objects.
CB: things on the slides are links: can find more information there. Fun thing will be to see how all this comes together in OneDM context.
MJK: there are already open source tools that automatically convert between IPSO XML and OneDM. Automate the conversion.
Archived slides from June 2020 virtual F2F are available here. See in particular: * Plugfest summary * Security update * Discovery update * Lifecycle update * Use cases and Requirements (Architecture) * Thing description update
We have discussed discovery in length in earlier meetings. Had one week plugfest and one week of virtual f2f. Used VPN setup with RPi as a bridge to enable fully remote plugfest; with broadcast enabled. Want to coordinate with IETF hackathon on the tool since it would be useful in that context too.
Fraunhofer had prototype implementation of a WoT directory which we experimented with during the plugfest. Looking now into how to federate multiple directory services. Still much more work to be done for discovery, including "discoverer" service to help with populating directories if devices do not self-register. DNS-SD just one way to do an "introduction" service. The most basic introduction mechanism is to just give a URL. Notable that while some introduction mechanisms associate types with URLs some don't, so we need some way to distinguish directories from peer-to-peer discovery of devices self-hosting TDs (for example).
Another project accomplished in the plugfest was auto-population of nodes in NodeRED based on a query against a directory service. Can drag and drop build IoT orchestration.
We are currently looking at how to deal with dynamic resources in TDs. This shows up in things like actions and event subscriptions but also other APIs (including directories themselves, which are also Things). But putting constructed resources in a TD forces the use of dynamic TDs which complicates directories and also has privacy issues. So we are looking at various approaches here using (for instance) URI templates and hypermedia. There are however other reasons to have a means to update TDs and notify subscribers about it, for example we are looking into supporting rotating IDs to tackle some privacy issues (avoiding tracking).
During the plugfest we found out that JSON path implementations are not consistent. Had to use XPATH for plugfest due to implementation missing recursive queries. Problem with not having a spec for JSONPath and a need for implementations to meet some minimum functionality.
Security work on signing TDs, distributed IDs (DIDs), Oauth 2. Have added client and device flows recently, probably to be in TD 1.1 (but still under discussion).
Discussed and prioritized different use cases. Some are vertical (e.g., agriculture) and horizontal (e.g., accessibility). More agriculture, edge computing, smart city, and retail related use cases coming.
In the notes (see above) pointers to all the presentations for more details.
Recently, week ago, released a new version 2.2.0. New cloud API for cloud services. In IoT originally device-to-device communication. Then started to talk about bridging, and then use case with smart phone and want to talk to home: need remote access to cloud service. And suddenly have issue if one device is connected to one cloud and other in another cloud: need cloud-to-cloud integration. Also nice integration layer for the future. Was a decent amount of work. Huge step forward for cloud integrations. Also open source out there.
Have code running for devices: iotivity. Cloud stuff not needed to run on most constrained devices so it uses different code base, based on Go. The repo has Docker containers configured and instance of cloud to cloud integration to play with.
Another directional change: earlier talked about OCF as complete stack, including data models. Got indications by other vendors that what we do as framework is pretty nice. Now can also use "OCF core framework" and build your own resources and protocols on top. Can now use standardized framework that is secure. Hopefully step forward to market. Quite many IP projects that don't want to use standard but need to be secure. With OCF core framework want to enable this opportunity for non-standardized ecosystems or ecosystems that want to move to IP. Can transport your model on top of the framework. Also with cloud-to-cloud. Step forward for the whole industry to get more adoption for IoT.
For security, identified five different docs with security requirements and ranking ourselves against them. Trying to match much of them. Also step forward in recognizing that we are looking what legislation challenges are there.
Also doing quite a bit of collaboration with other standards. Recently IP-BLiS announced: collaboration of Bacnet, OCF, KNX. Moving forward for everyone to use IP. IB-BLiS will do good for IoT to move everyone to IP. Also security will come to play.
Also working heavily on OneDM. Also started out as liaison but now public. One of the things trying to do: to align data models across industries. Fits into that we have core framework: what ever models come out of OneDM can be just transported over OCF core framework.
MK: IP-BLiS continuation of Fairhair or how they relate?
WvdB: not continuation; was separate org with no IPR. IP-BLiS is a liaison org. We say it's marketing but will do tech work going forward. Making sure co-existence works but also to leverage to use OCF together with KNX and Bacnet. One thing we did in OneDM is looking at different orgs, what they are good at. Will do same thing in IP-BLiS. Leverage what each org is good at. Not continuation of Fairhair but principles from there will apply.
Skipped because Michael Richardson was unavailable, now squeezed out of the agenda.
Michael did do IoT dir presentation: https://codimd.ietf.org/iot-dir-ietf108-2020-07-09-notes#IoTSF-Richardson
IoTSF Will do series of training that will be announced next week. Also work on supply chain security but that is very young.
OneDM has been discussed many times already, but OneDM is not trying to be the 15th org so have not been doing press releases. Have been running in stealth mode. Lots of people at IETF, who have not been at T2TRG meetings, don't know about that yet. OneDM has come out now; website at https://onedm.org/ OneDM has done legal model to publish everything in BSD3. Also have common specification language: SDF. Currently used with models from 4 orgs, working on more. Lots of work done to pressure test the current language. SDF released as v1.0. But not complete yet. Not all features there. Not the normative specificity we want from a standard. Question: who does the work to lead SDF into standard? OneDM thinks that could be done at the IETF. IETF would define the format, but would not work much on the data models. Not fully excluded, like network management work, but IETF would then be one of the ecosystems contributing. OneDM is about harmonizing data models. BoF happening on Tuesday in 12 days. Non-WG forming BoF since some folks thought we should have the dialog on what SDF and OneDM are all about and if we can find a way for common process etc. Think we are now in good phase. But need to get people talking to each other. Hope to get people from all kinds of orgs coming in and telling how they can work together using the language and how IETF can standardize it.
Addressed comments from Thomas on the list; improvements mainly in section 3 of the draft. Improved doc structure: appendix move to another draft. Made -05 prior to call for adoption. Completed IoT edge function and security considerations sections. Completes the draft. Many editorial improvements made.
Authors believe the draft is complete. Introduces edge for IoT; why we need it. Describes architecture, major functions, and research challenges. Believe it's good context for research on the topic at IRTF. Proposed for adoption. Looking forward to reviews.
CB: have now adoption call running, can response there
Niket Agrawal (NA): last email on call for adoption mentioned the need for further reviews from volunteers. Is there a scope for adding comments on existing content in the draft or only minor edit modifications are welcomed at this stage?
XF: just a call for adoption; will be driven by the group after adoption. As personal input, e.g., research challenges listed are very good part where need input from people here. For example discussion on discovery good.
Eve Schooler (ES): if have interest to review, please do. Not at all fixed.
NA: Was recently working on the topic, could have some comments. Will propose on the mailing list.
XF: please indicate on the mailing list to indicate if we should adopt
MMC: link to list and draft? Will be reviewing this. Want to align WoT use cases with this.
The list: https://mailarchive.ietf.org/arch/browse/t2trg/ The draft: https://tools.ietf.org/html/draft-hong-t2trg-iot-edge-computing-05
XF: happy to integrate comments and grow the doc
MMC: also relevant activity at W3C that can point to
CB: questions that came up in previous discussion focused on two questions when we continue discussing as RG document 1) whether edge computing is sharp technical term or just marketing term - maybe one or more concepts behind that wanting to get out that could be applied beyond where the marketing term applies. Something we want to do in the RG: sharpen terminology. 2) Dirk Kutscher had nice outrageous opinion talk where he came up with number of requirements that need to be met for edge computing really to happen. May want to pick up and discuss that. Also non-technical success factors: good idea to think about those as well. Would like to see more input and discussion on the mailing list on these.
Probably will have summary meeting before or during IETF 109. Meanwhile have mailing list and will have regular WISHI calls on one of our subjects. Can also have calls on other topics.