T2TRG summary meeting at IETF 106, Singapore: Thursday 2019-11-21, 10:00–12:00
Note takers: Niklas Widell, Ivaylo Petrov (thank you!)
Slides: https://github.com/t2trg/2019-ietf106/
Notes: https://etherpad.tools.ietf.org/p/notes-irtf-106-t2trg
Ari introduced agenda for today. Any agenda bashing? No.
Ari gave description of scope of T2TRG and related groups.
WISHI WS on Friday before the IETF week was a joint activity with W3C Web of Things. Discussion on modeling data and interaction for IoT, REST-based hypermedia, and connectivity for IoT. Notes will be published. Material on Github.
Going forward, plan to continue with monthly WISHI calls. Have had workshops with OMA and OCF, these will likely continue. Plan for WISHI hackathon in Vancouver. Would like to co-locate with relevant academic conferences; suggestions welcome.
WISHI Status:
This was the seventh WISHI hackathon. Working with data model convergence and automatic translation with OneDM. Worked closely with W3C WoT on convergence and usage of resource directory.
Achievement: translation tools IPSO/OneDM (both directions). Set up automated CI in Github to ensure guideline conformance. Tools available in open source. Also had good discussion on architecture, and how to address general convergence across SDOs. For WoT a first TD Discovery implementation using CoRE RD. Finally, a discussion of Semantic Proxy (generalized automated mechanism for translation).
Overview: Constrained networks commonly used proprietary binary formats. Integration is hard.
Hackathon: experiments with encoding, look at CoAP decode with YOUPI.
Next: looking at models for well known binary protocols (e.g. modbus)
Overview: use cases and examples for edge computing in IoT. Current draft is merger of existing drafts, includes use cases, also gap analysis.
Updates: moved to Github (many authors). Change from edge “architecture” to edge “models” to avoid promoting any special model. Also, move from use case examples to deeper view of edge function analysis.
Next: a number of todos, hope to have next version, asks for reviewers.
Volunteered reviewers: Michael McCool, Marie-Jose Montpetit, Erik Nordmark, Eliot Lear, Laurent Toutain, …
Erik Nordmark: there are a couple of relevant open source projects. Regarding the draft, there are a number of use cases, will you increase the number of use cases?
Matthias: yes, but not complete list of use cases. We have quite an extensive appendix that lists projects. It is rather big.
Marie-Jose Montpetit: There seems to be a related interest in COINRG.
Matthias: Yes, presented there, should align
Michael: also relevant with respect to WoT Discovery.
Matthias: ACK
Michael Koster planned to talk about two activities: One Data Model (OneDM) and iotschema.org.
One Data Model is a federation of organization working under liaison agreement. Works on a common language for describing models. Will also define a set of common models.
When starting in 2018, lack of common data models was an inhibitor. Working in the open, models are available in Github. Create a common representation language and test that language on representative models.
Have had four face-to-face meetings during the year. The first version of modeling language approved in October so groups have started to contribute models. The language (SDF) is currently considered stable.
Models will be published under the BSD 3-clause license. Have already shown 2-way translation between IPSO and OneDM. Working on practical semantics: connect things so that they interoperate. Started with affordances, focus on abstract meta-model. Affordances are Properties, Actions, and Events (+ data types), plus structural constructs (Things, Views, Objects).
SDF (Simple Definition Format) is a JSON based DSL, using JSON-LD (example in slides).
Next steps — add more features to the language. Model conversion across vendors and SDOs.
Semantic proxy: use WoT TD to associate the metadata of the affordances with concrete protocol bindings. Semantic proxy allows for generalized translation between different models. There are a few pieces of software that can already do the proxying. Uses RDF to describe model of relationships between affordances.
IoT extensions for schema.org:
An interesting concept is Feature of Interest, for instance either a location or some piece of equipment. Allows describing things in more general terms, better connected to real world.
Have been integrated with WoT test cases, have used them for some time but works pretty well. Interesting apps built with Node-RED, will look further into discovery. Implementation available for Node-RED.
Schema.org integration: there are a number of issues (overlap of names). iotschema will define a large number of types for physical quantities (temperature, pressure etc.). Will need some kind of hierarchical model (TBD).
iotschema.org is now a Community Group in W3C, looking to align with One Data Model.
Looking at doing RDF conversion from OneDM. Trying to provide dev tools for SDFs and then be able to convert to RDF.
Going forward: set up experimental site, use namespaced area/org. Good to have widely available uploaded models.
(Question from Jabber): how to use the OneDM model files, do you attach to a device, how?
Michael Koster: They are being used as semantic annotations for W3C WoT Thing Descriptions (TD). They are attached to a description of a concrete thing that has address, etc. Used to orchestrate connection and how to use a connected thing. Complimentary to a MUD [Manufacturer Usage Description, RFC 8520] file. It describes to application what capabilities, etc.
Michael McCool: SDF file is like a class definition, while a TD is an instance description for a particular device. A MUD file describes network configuration. The system orchestration part is missing, including what meta needed.
Eve Schooler: It would be good to see how things come together online, great to see how things are pulled in. Also, with respect to namespaces, is there room for evolution.
Koster: great topic, evolution is the normal mode, a lot of discussion how to enable evolution while maintaining interoperability. Versioning is part of that. Requires right degree of granularity. It is an ongoing discussion.
Eve: I’d love to see an example using all the components, and then what happens when things change.
Eliot: Eve, stay tuned, big topic, we have a lot of building blocks, question is how to put them together (will be discussed later today).
Ari: The incoming WISHI calls could be a place to discuss those more. Anyone interested in those topics, please make sure to join the calls.
WoT Status: W3C Web of Things (WoT) has one Interest Group (IG) and one Working Group (WG). IG charter was renewed, and WG charter is in process of being renewed.
Michael McCool gave an overview of WoT building blocks. Architecture, Thing Descriptions (TDs), Security Guidelines, WoT Scripting API, WoT Binding Templates.
Architecture and TD are now at the stage of W3C Candidate Recommendations (use an anticipation of JSON-LD 1.1). Describe an abstract set of affordances (not just REST, also e.g., OPC-UA). Also, WG notes exist on Security, binding templates and scripting API.
Presented proposed new charter. Discovery: how to get access to metadata (either global or local) while preserving privacy and security. First introduction, then exploration (detailed metadata about services). Between these two authentication process. Plan to reuse existing solutions, are in process of gathering use cases. Did look into CoRE-RD. There are probably many ways to do this.
Identifier management: mitigate privacy risks, global vs. local identifiers (group in W3C working on that). Onboarding: in operational phase, but will look at other work in this area. Link relation type: define specific rel types for specific relationships. Also complex hypermedia controls.
Ari: questions/comments? We already have a lot of common interests between T2TRG and WoT. We will look at where it makes sense to do standardization.
McCool: We’re highly motivated to have things converged.
Eve: Can you comment on IoT-centric convergence, and thoughts about DNS & resource directory; how all aligns?
McCool: WoT TD has more complex description with metadata, not just links. Data hub in CoRE gives access to more data. Looking at combining RD with links to those. Try to avoid broadcasting metadata. Need to think what is needed in public vs. private directory. Looking at DNS-SD, CoRE-RD, DHCP. We can do semantic queries in prototype, but they are expensive and thus for advanced use cases. Looking at location based search.
Eliot: There are some considerations in general Internet assumptions. In DHCP have created YANG models from them. YANG can be nicely serialized (like JSON), can do other things like signing, encryption. Useful for privacy protection. Cannot serialize everything. This ties into the trust anchor discussion (EAP, EST). If you want to exchange info between devices, hard to set up trust anchors. Relates to zero-trust networking, do not assume anything.
McCool: YANG vs. whatever. Many ways to translate/encode; key is to be interoperable and share common data schema. The structured info is the thing. With respect to trust anchors, agree, need to figure out who to trust.
Eliot: Will stop there, leads into next topic.
McCool: will look at MUD and TD angle as well.
Ari: this topic can be addressed in a future WISHI call.
Ari: This agenda item relates to a discussion we had over the last couple of months. Question is how to coordinate among all the relevant IoT groups [in and around the IETF] and how to organize future work on the topic. Eliot takes the lead.
Eliot: Representing himself. Had a number of IoT onboarding side meetings at this IETF. Question of how to organize around IoT came up. There are many things going on in IETF (T2TRG, IoT directorate, multiple WGs) but also other orgs (W3C, IEEE, Thread, …). There are many building blocks, but lack of direction how to use them. Ignas (AD) had proposal at the side meeting (was discussed at IESG how to organize). The usual WG setup doesn’t fit, the intent would be to put the building blocks together in order to create a useful system. Includes tracking across SDOs. Deliverables would be architectural documents, but also spot gaps and overlaps, and include discussion of alternatives. With respect to architectural documents, this would be a change of policy.
However, there were voices raised against — the area would be broad and vague.
One idea would be to focus on, e.g., onboarding. There have been discussions this week (3 side meetings this week). Focused on the problem of multiple approaches. Looking at use cases, try to reduce set of inputs/outputs, common components where possible. This means that people will have to take some options off the table. Typically a problem to agree what to be taken off the table.
Lots of discussion of DPP/TEAP. Has nice properties. Common input, output is profile (of different kinds of) certificates. DPP has a label standard (useful thing).
Looked at TEAP, which is an EAP method. Can do on L2, while other mechanisms are on higher layers relying on being able to send HTTP or CoAP, even though you might not yet have a network address or be authenticated in the network. Authentication server driven authentication. Question is how to link DPP to TEAP (if DPP output is e.g., PSK).
A number of questions came up. Next step is to write architecture document, draft on wired onboarding.
Back to IoT onboarding WG. Is it a starting point. We’ve heard other onboarding (not just networking) earlier today, maybe this is a good starting point. Would be good to have a place to drive work into other groups. Also needs to track across SDOs (leverage where possible).
Ignas: Missed the start of the session.
Eliot (joking): I promised that it will be in the agenda next meeting as a WG/RG.
Ignas: Brief summary, lots of activity on components relevant to IoT. There is no place to combine the components. Gathering components and explaining to external SDOs is hard. Not clear to outside world that IETF works on IoT “solutions”. Probably we need a structure to work on the coordination to match the individual WGs’ output. One specific work item is IoT onboarding, that should be one of the candidate activities. The coordination with other SDOs etc. is not that obvious.
Dave Thaler: four comments. Onboarding, all in favor to support, but there is always the XKCD problem to align and agree, but avoid adding N+1st standard. On external people knowledge of IoT at IETF, it seems to be pretty visible on the IETF web page. On this group, some of the discussion, do we need any group with non-constrained charter? Yes, doesn’t T2TRG already do that, supports T2TRG today. IoT directorate is already doing some coordination across WGs, but also across SDOs (OCF). Already has info sharing.
Ari: quick comment, we have coordination in the IoT directorate, but those discussions are closed to members only, and are not very often (one before every IETF).
Eliot: With respect to coordination in IETF. We might want to evolve this group to be more bound to IETF. There are numerous instances of different mechanisms spawned in different groups, and where this is not spotted earlier, this could probably be avoided.
Mohit Sethi: People are enthusiastic in BoFs, but it is hard to get people to write the actual work (lack of inputs, blog posts, etc). Before starting new groups, shouldn’t we bring things here first?
Eliot: For IoT onboarding, three meetings, 20–25 people, good interest.
Mohit: IETF does building blocks. E.g., there are many security solutions and we let people decide for themselves. Suggestion to bring the documents to T2TRG and see interest as there is plenty of time.
Eliot: There is not enough agenda time as we are running out of it.
Erik: In IoT network onboarding, that seems to be engineering which can be done in WG. However more general onboarding is more complex.
Eliot: For example MUD.
Erik: there are different use cases etc. Not sure if there is a place in IETF to discuss general stuff. Needs to be some motivation, but IoT is quite broad.
Michael Richardson: We should use T2TRG more. Please publish schedule of meetings earlier. Many of the topics require lots of time. Also, T2TRG has spent quite some time on WISHI, but there are more topics than that. On systems topics, yes IETF does architecture (routers, end devices). For onboarding, there are system architectural questions that are unresolved. Other groups are looking at IETF to define. We can argue about the solution.
Eliot: in response to Mohit and Erik, any time you want to form a WG, there should be a couple of drafts already available. One action from all meetings: need architecture draft. But doesn’t mean it is not the only way things fit together. But one sane way.
Dirk Kutscher: There is an interesting balance between having a systems view and architecture specs and standards. Other groups quite often do reference architectures in forums or open source projects; there are many, but that could be one idea. IETF should probably not propose architectures, IETF would be good to enable such architectures; things that fit together. With respect to T2TRG, there seems to be some utility to update on ongoing work, OTOH, this is IRTF and place for research. Maybe not good idea to develop more towards surveying.
Mohit: We have bigger problems than setting up a new WG, with respect to the definition of the onboarding (several options mentioned BRSKI etc). What difference between bootstrap, onboarding, etc.
Eliot: Your mentioned mechanisms are roughly synonymous. A systems level view would be beneficial. Ignas, where to bring this up next?
Ignas: This is an IRTF group so I’m here as a tourist now. With respect to IoT onboarding group, more clear what to do next. Much higher contention for IoT systems group. It would be good to collect the different technical alternatives. Maybe proponents can write that up: describe how things differ, work together, and what is relevance.
Ari: We are out of time, let’s continue discussion later and on list. Clearly there’s interest to work more on these topics. Happy to host discussions at T2TRG but if there’s standards work to be done that would be obviously done at IETF side. Often we have lots of time available on agenda until around week before the meetings. If you give us heads-up we are usually able to accommodate your requests for discussion time. Now closing the meeting, thank you and see you next time.
Meeting ended 12:05.